Tu ouvres un sujet de bac SI, tu vois un diagramme avec des boîtes, des flèches en pointillés et des stéréotypes entre guillemets, et là tu te dis : « c'est bon, je reconnais un diagramme SysML ». Sauf que le piège n'est presque jamais de reconnaître le diagramme. Il est de lire correctement ce qu'il raconte, et de le relier à l'analyse fonctionnelle et aux chaînes d'énergie / d'information du système. Dans cet article, on passe en revue les erreurs qui coûtent le plus de points, avec des exemples concrets (vélo à assistance électrique, store automatisé, robot mobile) et une méthode pour les éviter.
Rappel express : ce qu'est vraiment SysML en SI
SysML (Systems Modeling Language) est un langage de modélisation graphique normalisé, dérivé d'UML, utilisé pour décrire un système pluritechnique. En Sciences de l'Ingénieur, il sert à représenter trois grandes choses : ce que le système doit faire (le besoin et les exigences), comment il est structuré (les blocs qui le composent) et comment il se comporte (les états, les interactions, les flux).
Attention à une confusion fréquente : un diagramme SysML n'est pas un schéma électrique ni un plan mécanique. C'est un modèle : une représentation simplifiée et normée, destinée à communiquer une information précise. Le même système réel peut être décrit par plusieurs diagrammes complémentaires, chacun répondant à une question différente.
Les diagrammes que tu rencontres le plus souvent en spé SI sont :
- le diagramme des exigences (requirement diagram) : il formalise les contraintes que le système doit respecter ;
- le diagramme des cas d'utilisation (use case diagram) : il montre les services rendus par le système à ses acteurs ;
- le diagramme de définition de blocs (BDD, Block Definition Diagram) : il décrit la structure, la composition et les relations entre blocs ;
- le diagramme d'états (state machine diagram) : il décrit les états d'un constituant et les transitions entre ces états ;
- le diagramme de séquence : il montre l'ordre chronologique des échanges entre blocs.
Chaque diagramme a une sémantique propre. Le premier piège, et le plus répandu, c'est de les mélanger.
Les 7 pièges classiques sur les diagrammes SysML
Piège 1 — Confondre exigence et solution technique
Dans un diagramme des exigences, on écrit ce que le système doit faire ou subir, jamais comment on le réalise. Une exigence du type « le store doit remonter en moins de 10 s » est correcte : elle est vérifiable. En revanche, « le store doit utiliser un moteur pas-à-pas » n'est pas une exigence, c'est une solution de conception. Elle appartient au diagramme de définition de blocs, pas au diagramme des exigences.
Repère utile : une exigence commence souvent par « le système doit… » et se termine par un critère mesurable (une valeur, une tolérance, une condition). Si tu peux la vérifier par un essai ou un calcul, c'est une bonne exigence.
Piège 2 — Mettre des verbes d'action dans un diagramme de cas d'utilisation
Un cas d'utilisation représente un service rendu à un acteur, formulé du point de vue de l'utilisateur. On écrit « L'utilisateur peut commander la montée du store », pas « Le moteur tourne ». Le moteur est un constituant interne : il n'apparaît pas dans un diagramme de cas d'utilisation. Les seuls éléments autorisés sont les acteurs (humains ou systèmes externes) et les cas d'utilisation (ovales).
Erreur vue très souvent : dessiner le capteur de fin de course comme un acteur. Non : c'est un composant du système, il appartient à la chaîne d'information interne.
Piège 3 — Oublier les stéréotypes et les relations
En SysML, les stéréotypes sont les étiquettes entre guillemets qui précisent la nature d'un élément : <<requirement>>, <<block>>, <<actor>>, <<system>>. Les oublier, c'est rendre le diagramme ambigu : on ne sait plus si une boîte est un composant, un acteur ou une exigence.
Les relations aussi ont un sens précis :
- composition (losange plein) : le bloc enfant ne peut pas exister sans le parent ;
- agrégation (losange vide) : relation plus faible, l'enfant peut exister indépendamment ;
- dépendance (flèche en pointillés) : un élément dépend d'un autre sans en être un composant ;
- généralisation (flèche triangle vide) : relation « est un type de ».
Mettre une composition là où il faut une agrégation, c'est une erreur de sens qui se voit tout de suite dans une copie.
Piège 4 — Ne pas relier les blocs aux chaînes d'énergie et d'information
C'est le piège spécifique aux Sciences de l'Ingénieur. Un BDD bien fait doit permettre de retrouver la structure du système : chaîne d'énergie (alimenter, distribuer, convertir, transmettre) et chaîne d'information (acquérir, traiter, communiquer). Si ton diagramme montre un bloc « moteur » sans lien avec l'alimentation ni avec le bloc de commande, il manque l'essentiel : la circulation des flux.
Astuce : après avoir dessiné ton BDD, demande-toi « où est l'énergie ? où est l'information ? ». Si tu ne peux pas répondre, ton diagramme est incomplet.
Piège 5 — Mélanger diagramme d'états et diagramme d'activités
Le diagramme d'états décrit les états stables d'un constituant (par exemple : Arrêté, Montée, Descente, Bloqué) et les événements qui provoquent une transition. Le diagramme d'activités décrit un enchaînement d'actions avec des décisions. Ce ne sont pas les mêmes objets : un état n'est pas une action.
Exemple concret sur un store automatisé : « Montée » est un état (le moteur tourne dans un sens). « Démarrer le moteur » est une action. Si tu écris « Démarrer le moteur » dans une case d'état, c'est faux.
Piège 6 — Négliger les flux dans le diagramme de séquence
Un diagramme de séquence se lit de haut en bas, dans l'ordre chronologique. Chaque flèche représente un message échangé entre deux lignes de vie. Erreur classique : dessiner des flèches dans le désordre, ou oublier les messages de retour. Un échange complet, c'est une demande et une réponse (ou au moins un accusé de réception).
Sur un robot mobile, la séquence typique est : Capteur → Microcontrôleur (acquisition), Microcontrôleur → Driver (commande), Driver → Moteur (puissance), puis retour d'information du capteur pour la régulation.
Piège 7 — Confondre le modèle et le système réel
Un diagramme SysML est une vue partielle du système. Il ne montre jamais tout à la fois. Si tu essaies de tout mettre dans un seul diagramme, tu obtiens une usine à gaz illisible. La bonne pratique est de produire plusieurs diagrammes complémentaires, chacun centré sur une question : Que doit faire le système ? De quoi est-il composé ? Comment évolue-t-il ?
Méthode pas à pas : analyser un système avec SysML
Voici la démarche que tu peux appliquer en devoir comme à l'épreuve écrite, sur n'importe quel système du programme (vélo à assistance électrique, portail automatique, drone, barrière de parking…).
Étape 1 — Identifier le besoin et les acteurs
Commence par une phrase simple : « Le système X rend le service Y à l'utilisateur Z. » Puis liste les acteurs (utilisateur, opérateur de maintenance, éventuellement un système externe comme le réseau électrique). Cela te donne la matière du diagramme des cas d'utilisation.
Étape 2 — Formaliser les exigences
Traduis le cahier des charges en exigences vérifiables. Chaque exigence doit avoir un identifiant (Exi_1, Exi_2…) et un critère mesurable. Relie-les à des blocs par des relations de satisfaction ou de vérification.
Étape 3 — Construire le BDD
Décompose le système en blocs principaux, en respectant la séparation chaîne d'énergie / chaîne d'information. Utilise les stéréotypes et les bonnes relations (composition, agrégation, dépendance).
Étape 4 — Décrire le comportement
Choisis le bon diagramme : diagramme d'états pour un constituant qui évolue dans le temps, diagramme de séquence pour un échange entre blocs. Ne mélange pas les deux.
Étape 5 — Vérifier la cohérence
Relis tes diagrammes en te posant trois questions : les exigences sont-elles couvertes ? Les blocs du BDD apparaissent-ils dans les diagrammes de comportement ? Les flux d'énergie et d'information sont-ils cohérents d'un diagramme à l'autre ?
Si tu veux t'entraîner sur cette méthode, tu trouveras des exercices corrigés et des fiches de synthèse sur AlloSI. Les formules utiles et les cours complets complètent bien la révision.
Exemple concret : le vélo à assistance électrique
Prenons un VAE (vélo à assistance électrique). Voici comment les pièges se matérialisent sur ce système.
- Cas d'utilisation : acteurs = cycliste, éventuellement chargeur. Cas = « pédaler avec assistance », « recharger la batterie », « régler le niveau d'assistance ». Erreur à éviter : mettre « moteur » comme acteur.
- Exigences : « L'assistance doit se couper au-delà de 25 km/h » (exigence réglementaire), « L'autonomie doit dépasser 50 km en mode éco ». Pas « utiliser un moteur brushless » : c'est une solution.
- BDD : blocs « Batterie », « Contrôleur », « Moteur », « Capteur de pédalage », « Capteur de vitesse », « Afficheur ». La chaîne d'énergie va de la batterie au moteur via le contrôleur. La chaîne d'information va des capteurs au contrôleur puis à l'afficheur.
- Diagramme d'états du contrôleur : Arrêté → Assistance active → Assistance coupée (survitesse) → Arrêté. Les transitions sont déclenchées par des événements (démarrage, vitesse > 25 km/h, arrêt du pédalage).
- Diagramme de séquence : Capteur de pédalage → Contrôleur (effort), Contrôleur → Moteur (consigne de couple), Capteur de vitesse → Contrôleur (retour vitesse).
Sur ce seul exemple, tu vois que chaque diagramme a un rôle précis. Si tu mets le capteur de vitesse comme acteur dans le cas d'utilisation, ou si tu écris « moteur » dans le diagramme d'états, tu perds des points alors que tu connais le système.
Conseils de méthode pour le bac SI
Avant l'épreuve : réviser efficacement
Ne relis pas tes diagrammes en les survolant : refais-les à blanc. Prends un système du programme (store, robot, portail) et dessine de mémoire le BDD, le diagramme des exigences et le diagramme d'états. Compare ensuite avec ton cours. C'est le meilleur moyen d'ancrer la sémantique de chaque diagramme.
Entraîne-toi aussi à lire un diagramme qu'on te donne : que représente chaque bloc ? Quelle est la nature de chaque relation ? Quel flux circule ? Cette compétence est directement évaluée dans les sujets.
Le jour J : la check-list anti-pièges
- Ai-je bien identifié le type de diagramme attendu par la question ?
- Mes stéréotypes sont-ils présents et corrects ?
- Mes exigences sont-elles vérifiables (pas des solutions) ?
- Mes acteurs sont-ils externes au système ?
- Mes relations (composition, agrégation, dépendance) ont-elles le bon sens ?
- Mes blocs respectent-ils la séparation chaîne d'énergie / chaîne d'information ?
- Mes états sont-ils bien des états (pas des actions) ?
- Mes séquences sont-elles chronologiques et complètes (aller-retour) ?
Cette check-list prend deux minutes et sauve souvent plusieurs points. Pour aller plus loin sur la méthode d'analyse et la préparation du grand oral SI, le réseau Allo Education propose des ressources complémentaires sur Allolycée et des fiches transversales sur Allobac.
Erreur de raisonnement à éviter absolument
Ne confonds pas modélisation et calcul. Un diagramme SysML ne remplace pas une étude mécanique ou énergétique : il l'organise. Par exemple, la statique, la cinématique et la dynamique sont trois branches complémentaires de la mécanique, pas trois modèles concurrents. SysML te sert à structurer le problème, pas à te dispenser des lois de la physique.
Conclusion : SysML, c'est une langue, pas un dessin
Les pièges sur les diagrammes SysML en SI viennent presque tous d'une même cause : on dessine sans se demander ce que représente chaque élément. Un bloc, un acteur, une exigence, un état, un message : chacun a une définition précise et une place précise. Si tu maîtrises cette grammaire, tu lis n'importe quel diagramme et tu produis des modèles justes, même sur un système que tu découvres le jour de l'épreuve.
Alors entraîne-toi régulièrement, refais des diagrammes à blanc, et garde en tête la question magique : « est-ce que ce que j'écris décrit le système, ou est-ce que je décris une solution ? ». Avec cette rigueur, tu transformes un exercice piégeux en exercice gagnant. Bon courage pour ta spé SI !
