Diagramme de séquence UML : comment le construire pas à pas
Résumé
En atelier de spécification, le chef de produit, l'analyste et le développeur décrivent le même parcours de paiement. Chacun le raconte à sa façon, et personne ne sait vraiment qui prévient le client quand la banque refuse la carte. Trois semaines plus tard, le cas est découvert en recette, et il faut reprendre le développement.
Le diagramme de séquence sert à éviter ce type de malentendu. Il oblige à écrire, étape par étape, qui échange quoi avec qui, y compris dans les cas d'erreur. Vous trouverez ici la notation à connaître, une méthode pour construire votre premier diagramme, trois exemples détaillés et les erreurs les plus fréquentes.
Passez du schéma à l'exécution
Transformez chaque étape validée de vos scénarios en tâches assignées, reliées par leurs dépendances et suivies jusqu'à la livraison.
Qu'est-ce qu'un diagramme de séquence ?
Le diagramme de séquence (en anglais, sequence diagram) est l'un des diagrammes de l'UML, ou Unified Modeling Language, le langage de modélisation normalisé par l'Object Management Group. Il appartient à la famille des diagrammes comportementaux, qui décrivent ce que fait un système, et plus précisément au groupe des diagrammes d'interaction. C'est le diagramme d'interaction le plus utilisé en pratique.
Sa représentation graphique repose sur un principe simple : les participants sont alignés en haut, le temps s'écoule vers le bas, et des flèches horizontales représentent les échanges de messages. La séquence des messages se lit donc de haut en bas, dans l'ordre chronologique. Le diagramme de séquence UML montre ainsi les interactions entre les objets d'un système pour un scénario donné.
Quel diagramme UML pour quelle question ?
Le diagramme de séquence ne remplace pas les autres diagrammes UML : il répond à une question précise. Pour une vue d'ensemble des types de diagrammes, consultez notre guide du diagramme UML.
Diagramme | Question à laquelle il répond | Famille |
|---|---|---|
Diagramme de cas d'utilisation | Que peuvent faire les acteurs avec le système ? | Comportemental |
Diagramme de séquence | Dans quel ordre les participants échangent-ils des messages pour réaliser un scénario ? | Comportemental (interaction) |
Diagramme de communication | Quels participants sont reliés entre eux et quels messages circulent ? | Comportemental (interaction) |
Diagramme d'activité | Quelles étapes et quelles décisions composent un processus ? | Comportemental |
Diagramme de classe | Quelles classes composent le système et comment sont-elles liées ? | Structurel |
À quoi sert un diagramme de séquence ?
Détailler un cas d'utilisation. Il décrit pas à pas ce qui se passe quand un acteur déclenche une fonctionnalité.
Concevoir ou documenter une intégration. Il montre comment une application, une API et une base de données collaborent.
Préparer les tests. Chaque branche du diagramme correspond à un scénario de test, y compris les cas d'erreur.
Aligner les équipes métier et techniques. Le diagramme sert de référence commune pendant les ateliers et la recette.
La notation du diagramme de séquence
La notation tient en quelques éléments. Les tableaux ci-dessous décrivent leur représentation et leur rôle, du plus courant au plus spécifique.
Participants, ligne de vie et activation
Élément | Représentation | Rôle |
|---|---|---|
Acteur | Silhouette en bâtonnets, en haut du diagramme | Entité externe qui déclenche ou reçoit les échanges : un utilisateur, un autre système. |
Objet ou participant | Rectangle portant un nom, par exemple : Panier ou Service de paiement | Élément du système qui participe au scénario. |
Ligne de vie | Ligne verticale en pointillés sous chaque participant | Représente l'existence du participant au fil du temps. |
Barres d'activation | Rectangles fins posés sur la ligne de vie | Indiquent la période pendant laquelle le participant exécute un traitement. |
Destruction d'un objet | Croix (X) à l'extrémité de la ligne de vie | Signale que le participant cesse d'exister, par exemple une session fermée. |
Les types de messages
Les messages sont les flèches, ou connecteurs, qui relient les lignes de vie. La forme de la flèche indique la nature de l'échange.
Type | Représentation | Signification | Exemple |
|---|---|---|---|
Message synchrone | Trait plein, pointe pleine | L'émetteur attend la réponse avant de poursuivre. | verifierStock(article) |
Message asynchrone | Trait plein, pointe ouverte | L'émetteur continue sans attendre la réponse. | envoyerConfirmation(e-mail) |
Message de retour | Trait en pointillés, pointe ouverte | Renvoie une valeur de retour ou une confirmation à l'émetteur. | stock = 12 |
Message de création | Trait en pointillés vers le rectangle d'un nouveau participant | Crée un participant en cours de scénario. | créer(Commande) |
Message réflexif | Flèche qui part et revient sur la même ligne de vie | Le participant s'appelle lui-même. | calculerTotal() |
Les messages synchrones correspondent à un appel bloquant, comme une requête qui attend sa réponse. Un message asynchrone correspond plutôt à un événement déposé dans une file ou à une notification. Les messages de retour sont facultatifs : ajoutez-les seulement lorsqu'ils apportent une information utile.
Les fragments combinés
Un fragment combiné est un cadre qui entoure une partie du diagramme et précise la logique qui s'y applique. Son opérateur figure dans le coin supérieur gauche, et ses conditions, appelées gardes, sont écrites entre crochets.
Opérateur | Signification | Exemple de garde |
|---|---|---|
alt | Alternative : un seul des scénarios s'exécute, selon la condition. | [paiement accepté] / [paiement refusé] |
opt | Option : le bloc ne s'exécute que si la condition est vraie. | [client abonné à la newsletter] |
loop | Boucle : le bloc se répète tant que la condition est vraie. | [pour chaque article du panier] |
break | Interruption : si la condition est vraie, le bloc s'exécute et le reste du scénario est abandonné. | [3 tentatives échouées] |
par | Parallèle : les blocs s'exécutent en même temps. | Envoi de l'e-mail et mise à jour du stock |
Le cadre ref n'est pas un fragment combiné au sens strict : il renvoie à un autre diagramme de séquence. Il permet de découper un scénario long en plusieurs diagrammes lisibles, par exemple « ref : authentification » en tête d'un parcours de commande.
Diagramme de séquence système ou diagramme détaillé ?
Dans les cours et les projets français, on distingue souvent deux niveaux de diagramme de séquence. Ils n'interviennent pas au même moment du projet.
Diagramme de séquence système | Diagramme de séquence détaillé | |
|---|---|---|
Participants | Les acteurs et le système, vu comme une boîte noire. | Les acteurs et les composants internes : interface, services, base de données. |
Moment | Analyse du besoin, à partir d'un cas d'utilisation. | Conception, avant ou pendant le développement. |
Question | Quels échanges l'acteur a-t-il avec le système ? | Comment les composants collaborent-ils pour répondre ? |
Lecteurs | Métier, chef de produit, analyste. | Architectes, développeurs, testeurs. |
Le diagramme de séquence système découle directement d'un cas d'utilisation ou d'une user story. Il est volontairement simple. Le diagramme détaillé vient ensuite, une fois les choix techniques connus.
Comment faire un diagramme de séquence en 7 étapes
La méthode ci-dessous s'applique à un diagramme système comme à un diagramme détaillé. Elle part d'un scénario concret et ajoute la complexité progressivement.
1. Choisissez un scénario précis
Un diagramme raconte une seule histoire. Formulez-la en une phrase, avec un déclencheur et un résultat attendu : « le client valide son panier et reçoit une confirmation de commande » plutôt que « gestion des commandes ».
2. Identifiez les acteurs et les participants
Listez uniquement les participants qui échangent des messages dans ce scénario. Placez l'initiateur à gauche, puis l'interface, la logique métier et enfin les données ou les services externes à droite. Cet ordre limite les flèches qui se croisent.
3. Tracez le scénario nominal
Décrivez d'abord le cas où tout se passe bien, message par message, de haut en bas. Donnez à chaque message un nom explicite : un verbe d'action métier (« vérifier la solvabilité ») ou le nom de l'opération technique (« verifierSolvabilite() »).
4. Précisez le type de chaque message
Pour chaque flèche, indiquez si l'émetteur attend une réponse (message synchrone) ou non (message asynchrone). Ajoutez les messages de retour lorsqu'ils transportent une information utile à la suite du scénario.
5. Ajoutez les variantes avec les fragments combinés
Une fois le scénario nominal validé, encadrez les conditions (alt, opt), les répétitions (loop) et les interruptions (break). C'est à cette étape que l'on traite les erreurs : carte refusée, service indisponible, délai dépassé.
6. Faites relire le diagramme
Soumettez le diagramme aux personnes qui connaissent chaque participant : métier, développeurs, exploitation. Une relecture de trente minutes suffit souvent à repérer un message oublié ou une responsabilité mal attribuée.
7. Reliez le diagramme aux exigences et aux tests
Associez chaque branche du diagramme à une exigence et à un cas de test. Le diagramme devient alors un outil de recette, et pas seulement un schéma de conception.
Exemples de diagrammes de séquence
Chaque exemple de diagramme de séquence ci-dessous est présenté sous forme de tableau : une ligne par message, dans l'ordre chronologique. Les scénarios sont fictifs. Reproduisez-les dans l'outil de votre choix pour obtenir la représentation graphique.
Exemple 1 : connexion d'un utilisateur
Participants : l'utilisateur (acteur), l'application mobile, le service d'authentification, la base des comptes et le service de messagerie.
N° | Émetteur → destinataire | Message | Type | Fragment |
|---|---|---|---|---|
1 | Utilisateur → Application | saisir identifiants | Synchrone | loop [3 tentatives max.] |
2 | Application → Service d'authentification | connecter(e-mail, mot de passe) | Synchrone | loop |
3 | Service d'authentification → Base des comptes | lireCompte(e-mail) | Synchrone | loop |
4 | Base des comptes → Service d'authentification | compte | Retour | loop |
5 | Service d'authentification → Application | jeton de session | Retour | alt [identifiants valides] |
6 | Service d'authentification → Application | erreur « identifiants incorrects » | Retour | alt [identifiants invalides] |
7 | Service d'authentification → Service de messagerie | envoyerAlerteSécurité() | Asynchrone | break [3 échecs] |
Le fragment loop limite les tentatives, le fragment alt sépare connexion réussie et échec, et le fragment break interrompt le scénario après trois échecs. L'alerte de sécurité est asynchrone : le service d'authentification n'attend pas l'envoi de l'e-mail pour répondre.
Exemple 2 : diagramme de séquence système d'une commande en ligne
Participants : le client (acteur) et le système de vente en ligne, vu comme une boîte noire.
N° | Émetteur → destinataire | Message | Type | Fragment |
|---|---|---|---|---|
1 | Client → Système | ajouterAuPanier(article, quantité) | Synchrone | loop [pour chaque article] |
2 | Système → Client | panier mis à jour, total | Retour | loop |
3 | Client → Système | validerCommande(adresse) | Synchrone | |
4 | Système → Client | récapitulatif et frais de port | Retour | |
5 | Client → Système | payer(moyen de paiement) | Synchrone | |
6 | Système → Client | confirmation et numéro de commande | Retour | alt [paiement accepté] |
7 | Système → Client | refus de paiement | Retour | alt [paiement refusé] |
À ce niveau, la banque, le stock et l'entrepôt n'apparaissent pas : seuls comptent les échanges entre le client et le système. Le diagramme détaillé ouvrira ensuite la boîte noire pour montrer les services internes.
Exemple 3 : validation d'une demande d'achat
Participants : le demandeur, l'outil de gestion des achats, le manager, le service achats et le fournisseur. Le seuil de 5 000 € est fictif.
N° | Émetteur → destinataire | Message | Type | Fragment |
|---|---|---|---|---|
1 | Demandeur → Outil | soumettreDemande(article, montant) | Synchrone | |
2 | Outil → Manager | demande à valider | Asynchrone | |
3 | Manager → Outil | décision | Retour | |
4 | Outil → Demandeur | notification de refus | Asynchrone | alt [refusée] |
5 | Outil → Service achats | validation complémentaire | Asynchrone | alt [validée], opt [montant > 5 000 €] |
6 | Service achats → Fournisseur | bon de commande | Asynchrone | alt [validée] |
7 | Fournisseur → Service achats | accusé de réception | Retour | alt [validée] |
8 | Outil → Demandeur | commande passée | Asynchrone | alt [validée] |
Ce dernier exemple ne décrit pas un logiciel mais un processus métier impliquant plusieurs équipes. C'est souvent sous cette forme que le diagramme de séquence est utile aux chefs de projet : il rend visibles les validations, les responsabilités et les temps d'attente.
Bonnes pratiques et erreurs courantes
Erreur | Conséquence | Bonne pratique |
|---|---|---|
Modéliser tout le système sur un seul diagramme | Diagramme illisible, que personne ne met à jour | Un diagramme par scénario, relié aux autres par des cadres ref |
Décrire l'algorithme interne d'un composant | Le diagramme reproduit le code ligne à ligne | Rester au niveau des échanges entre participants |
Oublier les cas d'erreur | Les cas limites sont découverts en recette | Ajouter les branches alt et break pour chaque erreur connue |
Confondre message synchrone et asynchrone | Mauvaise conception des temps d'attente et des délais | Vérifier le type de chaque flèche avec l'équipe technique |
Nommer les messages de façon vague | « traitement », « envoi » : impossible de savoir ce qui circule | Un verbe d'action et ses paramètres principaux |
Quels outils pour faire un diagramme de séquence ?
Les outils se répartissent en trois familles. La plupart proposent des modèles de diagrammes de séquence à adapter.
Famille | Exemples | Quand les choisir |
|---|---|---|
Diagramme sous forme de texte | PlantUML, Mermaid | Pour les équipes techniques qui versionnent leurs diagrammes avec le code. |
Outils visuels | draw.io, Lucidchart, Microsoft Visio | Pour dessiner rapidement et co-construire en atelier avec le métier. |
Ateliers de modélisation UML | Enterprise Architect, Visual Paradigm | Pour les grands projets qui maintiennent la cohérence entre tous les diagrammes UML. |
Quel que soit l'outil, conservez le diagramme validé là où l'équipe travaille : dans le brief du projet ou attaché aux tâches concernées. Un diagramme rangé dans un dossier à part est rarement mis à jour.
Du diagramme de séquence au plan d'action avec Asana
Un diagramme de séquence validé décrit qui fait quoi, dans quel ordre et sous quelles conditions. Ce sont exactement les informations nécessaires pour planifier l'exécution. Dans Asana, chaque élément du diagramme trouve sa traduction.
Dans le diagramme | Dans Asana |
|---|---|
Participant (équipe, service, personne) | Responsable de la tâche ou équipe assignée |
Message qui demande une action | Tâche, avec une échéance et une description issue du diagramme |
Ordre chronologique des messages | Dépendances entre tâches, visibles dans la vue Chronologie |
Fragment alt (validation, refus) | Tâche d'approbation, avec la suite prévue pour chaque décision |
Fragment loop (relance, contrôle répété) | Tâche récurrente ou règle automatisée |
Diagramme validé | Pièce jointe du brief de projet, consultable par toute l'équipe |
Reprenons l'exemple de la demande d'achat. La validation du manager devient une tâche d'approbation, le contrôle du service achats ne se déclenche que pour les montants concernés, et l'envoi du bon de commande dépend des deux validations. L'équipe suit l'avancement sur un diagramme de Gantt sans recopier le scénario à la main.
FAQ
Voici les réponses à trois questions fréquentes sur le diagramme de séquence.
Les deux sont des diagrammes d'interaction et peuvent représenter le même scénario. Le diagramme de séquence met l'accent sur l'ordre chronologique, lu de haut en bas. Le diagramme de communication met l'accent sur les liens entre les participants, disposés librement, et numérote les messages pour indiquer leur ordre.
Oui, à condition de rester léger. En agile, on dessine un diagramme de séquence au moment où une user story le demande, souvent pendant l'affinage du backlog, pour clarifier une intégration ou des cas d'erreur. Il complète les critères d'acceptation sans devenir une documentation exhaustive.
UML ne fixe aucune limite. En pratique, un diagramme reste lisible jusqu'à six ou sept lignes de vie. Au-delà, découpez le scénario en plusieurs diagrammes reliés par des cadres ref, ou passez à un diagramme de séquence système qui regroupe les composants internes.
Diagramme de séquence : ce qu'il faut retenir
Un bon diagramme de séquence raconte un seul scénario, avec ses participants, ses messages dans l'ordre chronologique et ses cas d'erreur. Quelques éléments suffisent : lignes de vie, barres d'activation, trois types de messages et une poignée de fragments combinés.
Commencez par le diagramme de séquence système, faites-le relire, puis détaillez. Une fois le diagramme validé, servez-vous-en pour répartir le travail : chaque participant a un responsable, chaque message une tâche, chaque condition une décision.
Transformez vos scénarios en plan d'exécution
Répartissez les tâches, reliez-les par leurs dépendances et suivez chaque validation dans un même projet partagé avec toutes les équipes.
