L'échec du MBSE : longue vie au MBSE !
Pourquoi MBSE échoue (et comment le faire fonctionner réellement)
par Gian Giacomo Ermacora et Castrese Di Marino.
C'était autrefois le "Lean" puis le "Digital Twin". Mais suivre les tendances sans comprendre les bases est comme construire une maison du toit vers le haut. La justification la plus courante pour pourquoi vous ne faites pas vraiment MBSE est , Nous avons acheté le meilleur outil pour Model-Based Systems Engineering, mais après trois mois, personne ne l'utilisait.
Mais alors, Pourquoi ça arrive ??
Model Based Systems Engineering (MBSE), qui a évolué au cours des dernières périodes pour devenir l'acronyme MBS(S)E (c.-à-d., où le deuxième mot « Logiciel », faisant ainsi le terme tel que Model Based Systems et Software Engineering), est une approche de l'ingénierie complexe des systèmes basée sur l'utilisation de modèles formels comme source principale d'information, par opposition à l'utilisation plus traditionnelle de la documentation textuelle.
MBSE n'est pas un concept récent; en fait, les gens ont commencé à parler de Model Base dès vers les années 1970, puis avec l'émergence et la diffusion des systèmes de dessin CAO, le concept d'un modèle virtuel a de plus en plus évolué et s'est établi en ingénierie. Alors que le CAO définit l'objet physique et est le représentant parfait du domaine de la solution, le Model Based Systems Engineering, d'autre part, chevauche parfaitement les domaines de problèmes et de solutions. MBSE a été créé dans le but de permettre un flux naturel entre les domaines en raison de la vision holistique du système, de son comportement envers et depuis l'utilisateur et par rapport au monde qui l'entoure, ainsi que des relations (implicites/explicites ou extrinsèques/intrinsiques) avec les systèmes avec lesquels le Système d'Intérêt (SoI) se rapporte.
En termes formels, le MBSE a été défini comme l'application formelle de la modélisation pour soutenir les activités de définition des exigences, de conception, d'analyse, de vérification et de validation d'un système, à partir des étapes conceptuelles et tout au long de son cycle de vie.
Malheureusement, la réalité de l'adoption de MBSE (et de MBSSE) est beaucoup plus complexe.
De nombreuses organisations de toutes tailles ont entrepris des initiatives de MBSE, rencontrant de graves difficultés ou même des échecs des initiatives elles-mêmes, ne réalisant aucun des avantages escomptés.
Dans cet article, nous voulons examiner en profondeur les raisons de ces échecs, en articulant en particulier trois aspects clés, à savoir 1) les limites inhérentes au MBSE, 2) les questions critiques liées à la culture et aux outils organisationnels, et 3) certains cas concrets dans lesquels l'adoption du MBSE a échoué, ou n'a réussi que par des transformations organisationnelles radicales.
Les limites inhérentes au MBSE
Le principal objectif ambitieux du MBSE est de fournir une approche de modélisation pour décrire les caractéristiques d'un système complexe. Malheureusement, il a certaines limites qui, si elles ne sont pas bien comprises, peuvent entraver l'efficacité de l'ensemble de l'approche.
Ambiguïtés conceptuelles et normes immatures
Incroyablement, le terme MBSE lui-même génère souvent de la confusion. Comme mentionné dans l'ouverture de l'article, le concept de Model-Based n'est pas récent. En fait, au fil des ans, la communauté scientifique et du génie a proposé de nombreuses variantes et interprétations du terme. En fait, en ingénierie, le mot "model" est extrêmement générique; il peut inclure toute forme de représentation plus ou moins simplifiée, par exemple, des diagrammes, des simulations, des prototypes, etc. C'est précisément cette ambiguïté conceptuelle qui a conduit à de profonds malentendus, et non le moindre de ceux-ci est l'équation (erronée) "MBSE = SySML," c'est-à-dire la notion que l'adoption de MBSE signifie uniquement en utilisant SySML. La réalité suggère que SySML n'est qu'un des outils possibles, et cette équivalence a engendré des craintes et des incertitudes. À ce jour SySML, et il sera jusqu'à la version finale et officielle de la version 2.0, est une langue qui n'est en fait pas complètement mature et est -interprété de manière légèrement différente par de nombreux fournisseurs de logiciels. Il est souvent critiqué pour sa complexité et son incomplétude, au point que, à de nombreuses occasions, les gens préfèrent même utiliser des outils de dessin génériques, même comme Microsoft Visio, afin d'éviter la courbe d'apprentissage de SySML. Étant précisément un langage et non une méthode, SysML apporte avec elle la nécessité d'adopter une méthode de travail bien définie qui implique des ensembles de processus ci-dessous, qui, pour le rendre encore plus articulé, introduit un niveau supplémentaire de complexité, par exemple, l'adoption d'un cadre, qui, tout en dirigeant les opérations, d'une part, nécessite une rigueur d'étude et d'application.
Cette immaturité des normes et des méthodes entraîne souvent un manque d'orientation claire et partagée: en fait, même aujourd'hui, il n'y a pas de méthodologie universellement reconnue qui explique de manière pratique comment appliquer MBSE aux projets réels. En outre, la formation se limite souvent à des outils logiciels et à des langages spécifiques, tels que SysML, mais offre rarement des conseils étape par étape sur la façon de construire un modèle vraiment efficace et utile. En fait, les normes de référence fournissent des conseils sur ce qu'il faut faire, sur le type d'artefact à utiliser et, en fin de compte, sur les capacités du logiciel de soutien, mais elles s'arrêtent là, dans des directions simples, aussi précises et jusqu'à présent. Comme si la connaissance des règles de grammaire d'une ligne était suffisante pour engager la conversation.
Cela conduit souvent les équipes de projet à se sentir un peu perdues, obligées de prendre des décisions cruciales presque par essai et erreur. Jusqu'où devrions-nous aller ? Comment pouvons-nous vraiment répondre aux exigences?), surtout lorsqu'il n'y a pas de guide expérimenté pour le mentor. En d'autres termes, si nous examinons la question d'un point de vue pratique et méthodologique, le MBSE a encore plusieurs points non définis et une maturité qui n'a pas été pleinement atteinte; le risque réel, donc, est que nous finissons par créer des modèles qui ne sont pas très cohérents et, par conséquent, d'une efficacité limitée sur le terrain.
Rigidité et intégration limitée des instruments
Les outils logiciels utilisés pour MBSE à leur tour comportent d'autres limites inhérentes, souvent rigides et peu interopérables avec d'autres outils d'ingénierie déjà couramment utilisés dans divers domaines, de la gestion des exigences et de la chaîne d'outils Engineering Lifecycle Management à PLM et simulation physique.
Théorie voudrait que MBSE puisse enfin permettre le fil numérique qui est censé relier toutes les disciplines, mais nous savons que dans la pratique il tombe souvent précisément sur l'intégration. Des outils MBSE dédiés luttent pour dialoguer avec des logiciels spécialisés (CAO mécanique, environnements de simulation, outils de gestion de projet, etc.), provoquant une fragmentation potentielle au lieu de l'intégration. La solution naturelle est le transfert manuel de données entre les systèmes, ce qui entraîne des inefficacités et des erreurs. Même lorsqu'il existe des systèmes d'intégration, ils sont souvent soit des solutions coûteuses et hautement personnalisées, soit invasifs en ce qui concerne la définition des procédés.
Une autre question importante est celle de la convivialité : les outils MBSE ont des courbes d'apprentissage abruptes, les interfaces ne sont pas toujours intuitives et peuvent décourager les utilisateurs. Le besoin de compétences spécialisées pour utiliser efficacement ces outils signifie que les modèles MBSE restent potentiellement verrouillés dans les mains de quelques spécialistes. Par conséquent, le modèle risque de ne pas être consultable ou compréhensible par l'ensemble de l'équipe de projet : les intervenants non formés dans la langue officielle (p. ex. gestionnaires, fournisseurs ou même ingénieurs d'autres disciplines) peinent à interpréter des diagrammes SysML complexes.
Cela limite l'accessibilité du modèle et le démantele, risque de le garder confiné dans un silo au lieu de servir de Source unique de vérité. Mais quand le modèle est vraiment central (accessible, interrogeable, suivi), il n'est plus seulement un conteneur technique; il devient le point de référence commun pour l'analyse, la discussion et la prise de décision.
La valeur du MBSE émerge juste là: c'est-à-dire dans la capacité de fournir un seul, source d'information vérifiable, qui élimine l'ambiguïté, réduit les malentendus entre les différents rôles et permet un dialogue continu entre les domaines.
Sans cette condition, le risque est que chaque fonction retourne à la conversation à travers ses propres outils (documents, tableurs, présentations) et perde de l'alignement et de la cohérence.
Abstraction excessive et détachement de la réalité de l'ingénierie
L'abstraction est le mantra de MBSE : seulement Des modèles conceptuels de haut niveau, loin des solutions spécifiques ! ─ Mais qu'arrive-t-il au savoir-faire des entreprises ?
En fait, pousser trop loin dans l'abstraction peut conduire loin de la réalité concrète de l'ingénierie. Dans certains contextes industriels, il a été noté que si le MBSE n'est pas correctement intégré aux processus opérationnels (qui doivent être à leur tour prêts à recevoir le MBSE), on risque de se retrouver dans un silo séparé, parfois même comme un exercice de documentation formelle parallèle au travail pratique des ingénieurs.
Les équipes d'ingénieurs, en particulier celles qui sont très orientées vers les résultats, voient souvent les modèles MBSE comme quelque chose de théorique, éloigné du travail "real", presque un exercice académique qui ne se salit pas les mains avec des détails pratiques. Ce biais peut devenir un frein à l'adoption : le modèle finit par vivre dans un monde à part, sans vraiment affecter les décisions de conception quotidiennes. Et donc, paradoxalement, le sens même de MBSE est perdu.
Un autre risque associé à l'abstraction est le surmodelage : la tentation de représenter chaque détail du système, en poursuivant l'idée (souvent illusoire) d'une représentation numérique parfaite.
Cette croyance est en fait un piège conceptuel assez insidieux: l'idée largement répandue que pour qu'un modèle soit vraiment utile, il doit décrire tout au sujet du système, dans le moins de détails possible.
En réalité, essayer de modéliser chaque vis, chaque fil ou chaque partie d'un système complexe est tout simplement irréaliste. Les ressources - le temps, le budget, l'énergie - sont épuisées bien avant d'en arriver au fond. Le risque ? Perdre la vue du but du modèle lui-même : soutenir les décisions, ne pas devenir une entreprise encyclopédique.
La vraie valeur d'un modèle ne réside pas dans son exhaustivité encyclopédique, mais dans sa capacité à être une abstraction délibérée : il doit être suffisamment détaillé pour répondre aux questions de conception pertinentes, pas plus et pas moins.
Comme cela a également été souligné dans une étude de la NASA, il est essentiel de modéliser uniquement pour répondre à la question à l'étude.
Si ce principe est négligé, MBSE peut générer des modèles hypertrophes complexes à maintenir et encore plus difficiles à maintenir en phase avec l'évolution du système réel. Le résultat? Frustration, perte de confiance dans le modèle et la méthode.
Donc l'abstraction est la grande force de MBSE, mais comme tout outil puissant, il doit être utilisé judicieusement. Trop d'abstraction ou de mauvaise orientation peuvent produire des modèles déconnectés du monde réel et de la réalité commerciale, par conséquent, de peu d'utilité pour les décideurs opérationnels.
Critiques de la culture et des outils MBSE
La plupart des échecs dans l'adoption de MBSE découlent de facteurs organisationnels, culturels et liés aux outils, c'est-à-dire comment MBSE est introduit et soutenu dans l'entreprise.
Nous analysons ci-dessous les principaux problèmes critiques rencontrés.
Compétences organisationnelles insuffisantes
Le MBSE exige des figures professionnelles spécifiques avec un mélange de compétences moins que commun, à savoir la connaissance de l'ingénierie traditionnelle des systèmes, la maîtrise des langues de modélisation formelle, les compétences d'abstraction et en même temps la capacité de dialoguer avec d'autres disciplines.
De nombreuses organisations ont réalisé avec recul qu'elles n'avaient pas le capital humain nécessaire et, surtout, qu'elles avaient sous-estimé la nécessité de leur propre investissement dans les compétences et la formation.
Une étude d'analyse de rentabilisation note que le manque général d'ingénieurs MBSE expérimentés est l'un des principaux obstacles au succès de la mise en œuvre. En d'autres termes, vous pouvez acheter le meilleur outil sur le marché, mais si l'équipe ne possède pas (ou ne développe pas) les compétences nécessaires pour l'utiliser efficacement, l'initiative doit faire face à de sérieuses difficultés pour obtenir le succès souhaité.
Courbe d'apprentissage profonde et résistance au changement
Présenter MBSE implique de changer, d'une manière significative, la façon dont les équipes d'ingénierie fonctionnent, et il ne s'agit pas d'apprendre de nouveaux logiciels de modélisation, mais plutôt de faire un vrai changement de niveau.
Ce choc culturel est quelque chose, comme tout changement, qui peut générer une résistance considérable. Le syndrome de "ça a toujours été fait de cette façon" est un ennemi à ne pas sous-estimer: de nombreux ingénieurs ayant des années d'expérience dans les méthodes traditionnelles peuvent percevoir MBSE comme une imposition bureaucratique ou une mode de passage imposée d'en haut.
Les entreprises qui ont obtenu des succès significatifs au fil des ans avec l'approche traditionnelle centrée sur les documents ont tendance à «sancter» ces méthodes, en regardant avec suspicion toute innovation qui implique des risques, des efforts et des investissements.
Il est donc clair que sans une valeur immédiate claire, le personnel peut même se rebeller passivement, ignorer le modèle et continuer avec les anciens outils parallèles, à défaut de l'initiative en silence.
Un effet récurrent dans les projets d'introduction de MBSE est qu'il est perçu comme un fardeau supplémentaire, pas comme une façon plus intelligente de travailler. Si les équipes doivent encore écrire de la documentation traditionnelle - parce que les clients ou les processus existants le dictent - et en outre garder le modèle à jour, il est inévitable qu'elles le voient comme le double de l'effort, pas comme une aide.
Ceci conduit à l'une des erreurs les plus courantes: l'adoption superficielle du MBSE, où les outils et les formalismes sont introduits sans vraiment gérer le changement culturel nécessaire. Sans formation ciblée, tutorat sur le terrain et un peu de patience pour passer par l'inévitable phase d'installation, MBSE risque de s'écrouler contre les barrières les plus difficiles : la barrière mentale de -Je n'y crois pas et, pire encore, je n'ai pas le temps d'apprendre.
Incapacité à s'adapter aux processus hérités
Pour réussir, le MBSE exige souvent de revoir les processus établis d'une organisation, souvent affinés au fil des ans pour des produits spécifiques. Elle nécessite la mise en place d'une "re-ingénierie" du "way" une organisation développe ses systèmes et ses produits.
Cependant, lorsque l'adoption est présentée par des consultants externes ou des fournisseurs d'outils simplement comme s'il s'agissait d'une simple transition, tous les problèmes associés à l'adoption de MBSE émergent exactement comme décrit ci-dessus : conflit avec la réalité des processus en place, inadéquation de l'environnement et des moyens, peu ou pas de préparation dans les gens, détachement de la réalité commerciale, et finalement des récits trop abstraits et utopiques. Les promesses de changement sont systématiquement inaccomplies.
Une erreur fréquente est d'abandonner le MBSE en plus des workflows existants et établis sans y apporter de modifications, par exemple en ajoutant des processus de modélisation comme une phase autonome, sans réfléchir à la façon dont l'information peut alors circuler entre les disciplines. Ceci conduit à un modèle déconnecté; MBSE reste une branche sèche parallèle aux autres disciplines et processus techniques.
Une chose à garder à l'esprit est que MBSE implique et nécessite une approche centrée sur les données et intégrée, ce qui ne correspond tout simplement pas aux concepts centrés sur les documents.
L'organisation doit être prête à redéfinir les rôles, les produits livrables et les flux d'approbation autour du modèle, sur la douleur de créer une inadéquation: - les ingénieurs, habitués à certains outils et pratiques, peinent à intégrer les modèles MBSE dans la routine, avec le résultat que MBSE devient un effort parallèle et sous-utilisé au lieu d'une partie intégrante du processus.
Un exemple en est la gestion des exigences: dans de nombreuses entreprises, cher vieux Excel ou un outil legs qui fait maintenant partie de l'ADN de l'entreprise règne toujours suprême. Si vous introduisez MBSE sans réfléchir à la façon de l'intégrer à ces outils, vous finissez par devoir maintenir les exigences mises à jour en deux endroits à la fois - dans le système ancien et dans le nouveau modèle. Le résultat? Un vrai cauchemar opérationnel, gaspiller du temps, créer de la confusion et alimenter la tentation de tout abandonner et revenir à la méthode qui au moins fonctionne.
Ce n'est pas du tout rare, en effet: dans plusieurs projets, les gens finissent par abandonner l'utilisation de SysML, simplement parce qu'il est plus gênant ou moins familier que les outils qu'ils utilisent depuis le début. Le modèle, s'il n'est pas compréhensible et utilisable, génère de la distance au lieu de la convergence. SysML, avec son formalisme, peut être intimidant. Mais il est révélateur que le même sentiment émerge en CAO : l'interaction avec le modèle est toujours aussi lourde, déconnectée, parfois imposée. C'est un signe clair que le problème n'est pas (seulement) l'outil, mais comment la valeur du modèle est perçue dans le contexte de travail réel. Lorsque le nouvel outil ne s'intègre pas vraiment aux workflows existants, mais semble juste un ajout encombrant, son destin est scellé.
Le problème est que le MBSE, s'il ne prend pas la place d'un processus existant mais se contente de le suivre, risque de devenir un fardeau supplémentaire. Et dans les environnements où les processus ont été pourris pendant des années - avec des documents normalisés, des examens officiels, des listes de contrôle sculptées dans la pierre-introduction quelque chose de nouveau est comme essayer de tourner un pétrolier autour avec le gouvernail d'un dinghy. Il faut plus qu'un bon outil : il faut du courage organisationnel et une réelle volonté de changer.
L'acceptation réelle du MBSE ne signifie pas simplement l'ajout d'un modèle ici et là : cela signifie la remise en question de l'ensemble de la configuration opérationnelle de l'entreprise. Et cela, inutile de se retourner, est un énorme effort. À moins d'être soigneusement planifié - avec l'engagement de gestion approprié et la participation sérieuse des équipes de processus - le MBSE reste une initiative parallèle, bonne pour les diapositives mais non pertinente dans la pratique quotidienne.
INCOSE experts eux-mêmes le dire fort et clair: Il n'y a pas de modèles de processus clés en main pour vraiment intégrer MBSE dans les flux traditionnels. Chaque organisation doit élaborer sa propre formule, sur mesure, avec le soutien des bonnes personnes avec la bonne mentalité et la bonne préparation. Le problème ? Beaucoup ne le font pas, par peur ou par manque d'ingéniosité ou de compétences de base. Ou pire, chaque projet invente sa propre version extemporanée, générant confusion, désalignement et incohérence systémique.
Le résultat est que sans intervention décisive dans les processus établis - et les habitudes qui les soutiennent - le MBSE reste un organisme étranger, que le système d'entreprise finalement rejette comme une transplantation incompatible.
Manque de soutien de la haute direction
Un aspect souvent sous-estimé, mais crucial, est la participation active de la haute direction, en particulier afin que la haute direction soit claire sur les avantages au niveau des entreprises que ce type peut accorder en augmentant la compétitivité sur les marchés. L'adoption de MBSE n'est pas un simple changement d'outil; il ne s'agit pas de remplacer un logiciel par un autre. C'est une transformation structurelle qui met la main sur les rôles, les processus, les responsabilités et, surtout, la façon de penser et de travailler d'une organisation entière.
Lorsque cette révolution n'est pas comprise et soutenue par la haute direction, l'initiative s'éteint avant même qu'elle ne s'en aille. Dans plus d'un cas, il a été observé que la principale cause de l'échec n'était pas la technologie, ni la complexité de la méthode, mais l'absence totale d'un parrain interne, quelqu'un ayant l'autorité et la vision pour conduire le changement et le défendre en des temps difficiles.
À l'inverse, lorsque la direction croit vraiment en la valeur du MBSE, il se passe quelque chose d'autre : des ressources concrètes - le temps, les budgets de formation, l'investissement dans les bons outils - et les obstacles internes qui, autrement, pourraient mettre fin à toute tentative d'innovation. La transition, aussi complexe soit-elle, a de la place pour mûrir.
Le succès, dans ces cas, part du sommet, et ce n'est pas un slogan : c'est une réalité confirmée par tant de projets réussis. Mais pour que cela se produise, il est essentiel de communiquer la valeur de MBSE en termes qui parlent à l'entreprise: moins d'acronymes, plus d'impact sur le temps, le coût, la qualité, les marges. Si la narration reste technique, si les démos ne parlent que dans SysMLese, les décideurs tomberont bientôt de l'amour, et avec eux, ainsi le financement, la patience et le soutien.
En fin de compte, ce qui importe vraiment n'est pas seulement l'outil, mais le contexte qui l'accueille : les gens, les processus, l'état d'esprit et le courage de changer. C'est là que le vrai jeu de MBSE est joué. Et comme dans tout changement profond, sans leadership convaincu, ce n'est qu'une question de temps avant que tout retourne à la façon dont il était avant-ou pire, dans un limbe d'outils inutilisés et de promesses brisées.
Études de cas: défaillances et transformations nécessaires
Pour comprendre concrètement l'échec (ou le succès) du MBSE, il est utile d'examiner quelques cas réels ou emblématiques. Nous présentons ici des exemples qui mettent en évidence la façon dont l'adoption superficielle conduit à l'échec et, par contre, la façon dont l'adoption réussie nécessite de profonds changements organisationnels et de processus.
Tentative faible et échec
Un exemple classique de l'échec à adopter MBSE est celui de l'entreprise qui, séduit par l'enthousiasme du moment autour de SysML, décide de prendre le plongeon en achetant un outil de modélisation et en envoyant l'équipe à quelques cours rapides. Tout semble bien commencer, avec l'enthousiasme typique des nouvelles choses. Mais alors ? Alors les choses sont bloquées.
Le modèle commence à prendre forme, mais pendant ce temps les délais se profilent, les documents officiels continuent d'être requis dans Word ou Excel, et personne n'a vraiment repensé comment intégrer tout cela dans le flux de travail réel. Alors, peu à peu, les ingénieurs reviennent à leurs anciennes voies. Pas par paresse, mais par survie : le modèle ralentit, le client veut les fichiers habituels, et il y a de moins en moins de temps. En parlant aux ingénieurs en chef, presque toujours ce doute ou cette peur émerge, comment MBSE accélérera-t-il nos processus? - Il y a un échec à percevoir l'avantage à long terme en utilisant un modèle par rapport aux outils traditionnels, qui sont plus simples et plus largement utilisés, mais beaucoup moins performants sur de longues distances.
Pendant ce temps, la direction veille de loin, sans mettre un visage dessus, sans fournir le temps, les gens ou une vision claire. Le résultat? Le modèle n'est mis à jour que pour enregistrer les apparences, quand il est nécessaire pour faire une bonne impression ou fermer un audit. En fait, il devient un exercice dans le style, pas un outil utile.
C'est une histoire que nous avons déjà vue. Et il est également confirmé par plusieurs études: le MBSE, lorsqu'il est traité comme un simple changement d'outil et non comme un changement profond dans la façon de travailler, est condamné à l'échec. Les initiatives qui n'incluent pas de commanditaires forts, le temps de former vraiment les gens, et surtout une refonte des processus existants disparaîtront lentement.
La morale est simple et brutale: Si vous approchez MBSE comme si vous installiez de nouveaux logiciels, sans rien toucher d'autre, vous jetez simplement le temps et l'argent. Ce n'est pas la technologie qui fait la différence, mais le contexte dans lequel vous l'abandonnez : les gens, les processus, le soutien, la volonté de changer vraiment. Sans ces ingrédients, n'importe quel modèle, peu importe l'élégance, est destiné à se retrouver dans un tiroir.
Cas de la NASA - succès obtenus grâce à la transformation organisationnelle
L'extrême opposé des cas d'échec, il y a une expérience à raconter : celle du Centre spatial Johnson de la NASA (JSC). Dès 2009, le centre a décidé de parier sérieusement sur MBSE, l'adoptant dans des projets frontaliers. Mais ce n'est pas une promenade dans le parc. Les difficultés initiales étaient toutes là: résistance culturelle, inquiétude au sujet du risque et scepticisme généralisé à l'égard d'une approche perçue comme trop théorique ou compliquée.
La différence ? JSC n'a pas simplement installé un outil et a suivi deux cours. Elle a entrepris un travail approfondi, structuré et à plusieurs niveaux. Il a formé des figures clés, construit une infrastructure de support interne - un véritable groupe de référence MBSE - et défini des règles claires du jeu pour tous, avec des lignes directrices communes, des outils intégrés et des modèles réutilisables.
Ce n'était pas un projet d'IT, mais une transformation culturelle. Interne champions-ingénieurs avec la vision et le leadership- ont été identifiés pour conduire le changement du bas vers le haut et le faire se produire en équipes, jour par jour. Une communauté interne, le groupe d'utilisateurs SysML, a même été créée pour partager des expériences, résoudre des problèmes et contaminer l'organisation avec une nouvelle façon de penser.
Plus important encore, l'accent a été mis sur la démonstration de la valeur du MBSE dans la pratique. Pas en mots, mais dans les tâches quotidiennes : production automatique de rapports, suivi des exigences, interfonctionnement, visibilité logicielle et matérielle. Essentiellement, les ingénieurs ont commencé à voir comment le modèle pouvait vraiment simplifier leur travail, sans le compliquer.
C'était un long processus, loin d'être indolore. Pour y arriver, le JSC a dû revoir ses processus de développement, passant d'une logique de document statique à un modèle dynamique vivant capable d'évoluer avec le projet. Mais les résultats sont venus, et comment.
Un exemple concret ? Le projet Deep Space Habitat (DSH) - le module vivant pour les futures missions spatiales profondes. Là, le modèle SysML a permis une représentation intégrée des exigences, des fonctions et des composants, donnant à tous - des concepteurs aux intervenants - une vue unique, cohérente et actualisée du système en construction.
Ce modèle n'était pas un fichier supplémentaire. En raison de cette centralité, l'équipe a acquis plus de contrôle sur les changements, un meilleur suivi et une gestion beaucoup plus efficace des complexités interdisciplinaires. En effet, lorsque le modèle est vraiment au centre, multiplateforme, suivi et accessible, toute l'information et les connaissances y résident. Les outils logiciels ne sont plus des éditeurs simples, mais deviennent des environnements d'utilisation, de navigation et de collaboration. Les connaissances ne sont plus dispersées, les examens sont effectués par le biais du modèle et les décisions ont un contexte clair. Les avantages sont évidents : gestion de la complexité, meilleure compréhension, communication efficace.
La leçon est claire: MBSE peut en effet tenir ses promesses, mais seulement si elle est traitée pour ce qu'elle est: une transformation organisationnelle, pas un plug-in à ajouter à l'ancienne routine. Même à la NASA, s'il n'y avait pas eu d'investissement réel dans les compétences, les pratiques et la culture, le modèle serait resté un exercice universitaire. Au lieu de cela, il est devenu un outil vivant et utile. Comme il se doit.
Secteur automobile - le changement culturel comme clé du succès
Un autre cas intéressant vient du monde de l'automobile, où une entreprise avait décidé de se concentrer sur MBSE. Mais le début n'était pas le plus brillant. Le modèle SysML a été perçu par les équipes de conception comme une créature étrange et lointaine, presque une expérience académique a chuté d'en haut, complètement déconnecté de la réalité quotidienne de la CAO, des simulations, des itérations continues et des pressions de production.
Le résultat? Ingénieurs de systèmes modélisés d'un côté, spécialistes de détail continué sur leur chemin. Deux mondes qui ne se parlaient pas, et le modèle, aussi élaboré soit-il, restait utile pour faire une présentation, mais inutile pour résoudre de vrais problèmes.
Les responsables avaient toutefois le mérite de ne pas ignorer les signes. Au lieu de passer par des lignes directrices et des règlements, ils ont choisi une voie différente: impliquer les gens, vraiment. Ils ont organisé des ateliers mixtes, mettant des ingénieurs de systèmes et des concepteurs mécaniques, électriques, logiciels côte à côte. Objectif ? Pour se comprendre. Pour rendre le modèle non seulement formellement correct, mais pratiquement utile.
Au cours de ces rencontres, une chose intéressante s'est produite: ceux qui ont modélisé ont appris à parler simplement, en adaptant les vues du modèle aux vraies questions de leurs collègues. Et les autres, ceux qui ont d'abord tourné le nez, ont commencé à explorer le modèle avec curiosité, à poser des questions, à suggérer des améliorations. Lentement, ce fossé culturel s'est réduit. Le modèle a commencé à répondre à des questions concrètes, à simplifier les décisions, à gagner du temps en retravaillant inutilement. 5000 exigences sont devenues 500; les besoins du client ont été représentés clairement et efficacement, d'immenses fiches de données sont devenues des diagrammes dans une architecture claire, organisée, logique et fonctionnelle. L'information bien structurée est devenue une connaissance qui a évolué d'un niveau à l'autre avec une simplicité et une clarté extrêmes.
Dans quelques cycles de développement seulement, ce qui était considéré comme un fardeau est devenu un véritable outil de coordination. Les équipes parlaient la même langue. On prévient les problèmes plutôt que de les poursuivre. Et le modèle, d'être un organisme étranger, est devenu une partie intégrante de la façon de travailler.
Bien sûr, ça n'est pas arrivé par magie. Il a fallu de nouveaux espaces pour le dialogue, la formation mutuelle, et surtout la volonté de réviser les processus, en les adaptant pour que le MBSE ne soit pas un extra, mais le protagoniste un accessoire, mais un allié. Et comme c'est souvent le cas, le vrai changement a commencé quand nous avons cessé de penser en termes d'outils et commencé à travailler sur les gens. Les meilleurs outils (méthodologiques et logiciels) entre les mains de personnes mal préparées et insuffisamment formées et impliquées conduisent à une frustration coûteuse généralisée. D'autre part, si des personnes compétentes et compétentes peuvent accomplir des merveilles avec une feuille de papier, un crayon, une idée et un peu de temps, qu'est-ce qu'elles pourraient accomplir si elles avaient les bons outils?
Ces affaires nous apprennent quoi ? Que lorsque MBSE fonctionne, ce n'est jamais par accident. Tous les exemples réussis ont un dénominateur commun le plus bas: il y a une profonde transformation derrière eux, pas seulement une mise à niveau technologique. Nous parlons de nouvelles infrastructures numériques, d'intégrations entre des outils qui ne se parlaient pas avant, de formation structurée, de changement de processus et, surtout, de leadership qui croit en le changement et le stimule, jour après jour.
En revanche, chaque fois que le MBSE a été introduit de manière superficielle - en achetant un outil, en dessinant quelques diagrammes, peut-être en insérant quelques termes "trendy" dans des documents - les résultats ont été décevants, quand ils ne sont pas désastreux. Parce que le MBSE n'est pas un travail de peinture à donner sur une organisation existante.
C'est un travail de restructuration.
Et cela demande du temps, de la coordination et une vision claire.
Comme le disent de nombreux experts, il ne suffit pas de penser à l'aspect technique. Vous avez besoin d'une approche qui embrasse l'ensemble : les gens, les processus, la culture et les outils. C'est la seule façon de rendre le modèle central à la façon dont les systèmes complexes sont conçus, construits et gérés.
MBSE n'est pas une solution plug-and-play. Ça ne l'a jamais été. C'est un changement de paradigme, avec tout ce que cela implique. Et si vous le prenez à la légère, non seulement cela risque de ne pas produire de résultats, mais cela peut aggraver les choses, générant la confusion, les ressources gaspillées et la désillusion généralisée.
Résumé
L'échec de MBSE n'est pas la faute de l'approche. Ce n'est pas une faiblesse structurelle ou une fausse idée sous-jacente. Presque toujours, le problème réside dans la façon dont MBSE est adopté. Il est facile de tomber amoureux du concept, de penser que tout ce que vous avez à faire est d'introduire un outil de modélisation, ajouter quelques diagrammes et voila - système transformé. Mais malheureusement, ça ne marche pas comme ça.
MBSE n'est pas une baguette magique qui s'ajoute aux processus existants sans les toucher. C'est plus comme une chirurgie profonde : elle nécessite une préparation, des compétences spécifiques et, surtout, une réelle volonté de changer. Et cela ne s'applique pas seulement au niveau technique, mais au niveau culturel, organisationnel et humain.
Bien sûr, les limites sont là - SysML peut être hostile, les outils ne brillent pas toujours en termes de convivialité, l'abstraction parfois vous fait perdre contact avec le monde réel. Mais tout cela peut être géré, si on a le courage d'approcher l'adoption pour ce qu'elle est réellement : une révolution systémique. Des exemples concrets sont des outils PLM dont l'introduction a conduit à de forts affrontements, mais aujourd'hui ils sont énormément populaires et aujourd'hui indispensables des flux de travail des entreprises.
Voici le crux : aucune entreprise ne devrait affronter cette voie seule. C'est trop facile - et trop humain - de s'attacher à ses propres processus, à ses propres certitudes, à ses propres, c'est comme ça que nous l'avons toujours fait.Le risque, très élevé, est celui de plier le nouveau sur l'ancien : adapter le MBSE aux processus obsolètes, plutôt que de saisir l'occasion de les renouveler. Ce faisant, vous finissez par stériliser tout le potentiel de transformation de la méthode.
C'est pourquoi vous devez faire équipe avec des consultants expérimentés, qui non seulement connaissent les outils à l'intérieur, mais qui vivent et respirent des standards comme SysML, des cadres méthodologiques comme Arcadia, Harmony, MagicGrid, UAF, et savent accompagner une organisation à travers une profonde transformation. Nous ne parlons pas de formation technique, mais de véritable travail structuré de gestion du changement.
C'est précisément le cœur de la mission d'ONE-SYS : soutenir les entreprises dans cette transition, les aider à concevoir et à construire leur système MBSE d'une manière robuste, durable et véritablement intégrée dans leur fonctionnement quotidien. Nous le faisons tous les jours, côte à côte avec nos clients, transformant les ambitions en réalité et les modèles en valeur opérationnelle.
Parce que MBSE, s'il est adopté sérieusement, n'est pas seulement une évolution de l'ingénierie des systèmes : c'est un saut qui peut repenser la façon dont une entreprise entière conçoit, construit et exploite ses produits. Il s'agit d'un saut qui exige un leadership solide, un investissement dans la formation et une volonté de remettre en question les rôles, les responsabilités et les processus pris pour acquis.
Et il n'y a pas de raccourci. On ne peut pas essayer un peu de MBSE. Soit vous l'embrassez tout le chemin, comme un levier stratégique de transformation, soit vous finissez par nourrir la frustration - et le récit habituel des promesses brisées.
En conclusion, le point n'est pas de savoir si MBSE fonctionne. Le point est: êtes-vous prêt à l'affronter pour ce que c'est vraiment? Parce que si la réponse est oui, les résultats viennent. Et ils sont transformatifs. Une plus grande cohérence entre les exigences et la conception, moins de retravail, une véritable traçabilité et une organisation plus consciente, plus alignée, plus prête à faire face à la complexité des systèmes d'aujourd'hui et surtout de demain.
La première étape est simple, mais pas facile: arrêter de chercher des raccourcis et commencer à construire méthodiquement, avec la vision, avec l'expertise. Et sachez que vous n'êtes pas seul : c'est pour ça que One-SYS est là.
Sources utilisées dans l'article
Cloutier, R., & Bone, M. (2015). « Les défis et les recommandations de l'adoption du MBSE ».
Lien & #160;: https://incose.onlinelibrary.wiley.com/doi/abs/10.1002/j.2334-5837.2018.00561.x
Friedenthal, S., Burkhart, R., & Sampson, M. (2009). « INCOSE MBSE Initiative – La Feuille de route pour le déploiement ».
Lien & #160;: https://www.researchgate.net/publication/267687693_INCOSE_Model_Based_Systems_Engineering_MBSE_Initiative https://www.omg.org/sysml/INCOSE-INSIGHT-vol-12-issue-4-Dec_09-MBSE_Theme.pdf
Estefan, J. A. (2008). « Enquête sur les méthodes d'ingénierie par modèle (MBSE) proposées ».
Lien & #160;: https://www.omg.org/sysml/MBSE_Methodology_Survey_RevB.pdf
Paredis, C. J., et al. (2010). « An Overview of the SysML Modeling Language ». Proc. de l'atelier international INCOSE.
DOI: 10.162/sys.20179
Sandia National Laboratories (2016). «Model-Based Systems Engineering Adoption Assessment». Examen interne.
Lien & #160;: https://www.sandia.gov/digital-engineering/new-to-mbse/mbse-at-snl/
Mohammad Chami, Jean-Michel Bruel. Enquête sur les défis de l'adoption du MBSE. EMEA
Lien & #160;: https://hal.science/hal-02124402v1/document
NASA: rapports de mise en œuvre du MBSE et projets pilotes (incl. Cas de Deep Space Habitat).
Lien & #160;: https://maaz.ihmc.us/rid=1MHBN2Y38-P1TSZC-165K/Model-Based%20System%20Systems%20Pilot%20Program%20at%20NASA.pdf
Lien & #160;: https://arc.aiaa.org/doi/abs/10.2514/6.2012-5165
Lien & #160;: https://ntrs.nasa.gov/api/citations/20120014575/downloads/20120014575.pdf
Y COMPRIS le Groupe de travail du MBSE (2023).
Lien & #160;: https://www.incose.org/products-publications/se-related-resources/mbse-maturity-survey
Accenture (2024).
Lien & #160;: https://www.accenture.com/content/dam/accenture/final/markets/europe/document/Accenture-Future-of-MBSE.pdf
