14/08/2026

Pourquoi les ingénieurs en exigences hésitent-ils à s'engager pleinement dans l'approche MBSE ? – Garantir une architecture pérenne dans l'ingénierie des exigences

Apprenez à gérer les craintes légitimes liées aux perturbations et à la complexité, et découvrez comment réduire les risques avant de mettre en œuvre pleinement l'ingénierie des systèmes basée sur des modèles.

Savoir-faire
Exigences

Dans la sixième partie de cette mini-série d’Iain Cunningham, nous mettons en lumière les raisons valables pour lesquelles les équipes hésitent à adopter pleinement l’ingénierie des systèmes basée sur les modèles (MBSE).

Vous développez des systèmes complexes pour relever les défis de demain. Lorsque la motivation s'estompe, la promesse d'une MBSE complète peut sembler être la solution idéale – pourtant, la crainte des perturbations, de la complexité et d'une couverture insuffisante en retient plus d'un. Nous sommes convaincus que l'ingénierie exige de la clarté, et non des conjectures. Découvrez pourquoi cette hésitation constitue une réaction rationnelle face aux expériences passées, et apprenez à gérer les risques afin de mettre en place une architecture à l'épreuve du temps.

Lorsque vous envisagez d'améliorer la traçabilité, qu'est-ce qui vous préoccupe le plus : les perturbations, la complexité ou la perte de contrôle ?

Dans l’article précédent de cette série, nous avons examiné ce qu’implique concrètement une approche solide de la traçabilité, tant en termes de structure, de couverture, de preuves de vérification que de continuité dans le temps. La prochaine étape logique consiste à mettre en pratique ces enseignements. Cependant, dans la réalité, de nombreuses organisations et de nombreux ingénieurs en exigences hésitent.

Ce n’est pas le fruit du hasard. Cette hésitation repose généralement sur l’expérience.

La traçabilité couvre plusieurs dimensions à la fois. Les exigences doivent rester structurées, la couverture doit rester visible et les preuves de vérification doivent être fiables d’une version à l’autre et d’une itération à l’autre. Parallèlement, de nombreuses équipes utilisent plusieurs outils, ce qui rend plus difficile la mise en relation des exigences, de la conception, des cas de test et des résultats d’exécution.

Il en résulte une tension entre le potentiel d’amélioration et le risque de compliquer les choses, et ce de trois manières :

Les trois risques liés à une mise en place précipitée de la traçabilité

  • Le risque de perturber la structure et la responsabilité : les ingénieurs en exigences sont les gardiens de l’intention. Ils savent que des changements importants peuvent introduire de la complexité avant que l’organisation ne soit prête. Ce qui commence comme une amélioration devient rapidement une charge supplémentaire.
  • Le risque de compromettre la couverture et la clarté de la vérification : dans des environnements fragmentés, l’introduction prématurée de nouveaux outils peut nuire à l’interprétation de la couverture. Lorsque la chaîne allant de l’exigence au cas de test, puis au résultat d’exécution, n’est pas claire, la confiance s’effrite et les équipes se rabattent sur des solutions manuelles de contournement.
  • Le risque de perdre la continuité entre les versions et les workflows : si la traçabilité ne se comporte pas de manière cohérente entre les branches parallèles et les exigences en constante évolution, les équipes perdent confiance. L’effort consiste alors à reconstituer ce qui a été vérifié, sous une pression temporelle considérable.

Si ces risques ne sont pas pris en compte dès le début, le résultat est bien connu. L’adoption ralentit, les parties prenantes se désengagent et la traçabilité relève davantage de la théorie que de la pratique. Ce sont finalement les ingénieurs en exigences qui se retrouvent à nouveau à porter ce fardeau, en assurant la cohérence de la structure et en reconstituant les preuves d’un système à l’autre.

À un niveau plus profond, cette hésitation n’est pas une résistance au changement. Il s’agit d’une réaction rationnelle face aux expériences passées. La plupart des organisations ont déjà tenté d’améliorer la traçabilité et y ont trouvé davantage de complexité que de clarté. Pour être couronnée de succès, toute amélioration doit réduire les risques avant de réduire les efforts.

Lorsque nous considérons l'hésitation comme une résistance au changement, nous ignorons les risques réels qui pèsent sur nos processus d'ingénierie. La véritable innovation naît lorsque nous réduisons les risques avant de réduire les efforts, en offrant à chaque ingénieur chargé des exigences les performances en temps réel dont il a besoin pour développer en toute confiance.
Iain Cunningham
Vector GB

Si vous rencontrez des difficultés similaires dans votre environnement, il peut être utile de prendre du recul et d’identifier les domaines où ces risques sont aujourd’hui les plus manifestes. Un changement modeste et ciblé s’avère souvent plus efficace qu’une transformation de grande envergure.

Dans le dernier article de cette série, nous passerons de l’hésitation à l’action. Nous examinerons une approche pratique visant à renforcer la structure, à améliorer la visibilité et à assurer la continuité, sans pour autant nécessiter une transformation complète dès le premier jour.

D’après votre propre expérience, quel a été jusqu’à présent le principal obstacle à l’amélioration de la traçabilité, et pourquoi ? Participez à la discussion et contribuez à façonner l’avenir de la conception des systèmes. Suivez Iain Cunningham sur LinkedIn et partagez vos expériences dans les commentaires de son article original.