L’ingénierie est-elle devenue trop complexe pour rester efficace ?

L’ingénierie n’a jamais été aussi puissante. Outils de simulation performants, capacités de calcul considérables, architectures numériques sophistiquées, intelligence artificielle, systèmes de gestion des exigences, équipes d’experts dans presque tous les domaines. Et pourtant, une question mérite d’être posée : sommes-nous devenus plus efficaces ?

Dans beaucoup de projets industriels, la réponse n’est pas aussi évidente qu’elle devrait l’être. Les systèmes que nous développons sont devenus plus complexes — c’est un fait, et le MBSE et l’ingénierie basée sur les modèles répondent à cette complexité produit. Mais il existe une seconde complexité, moins visible et souvent plus coûteuse : celle que l’organisation elle-même ajoute au projet. Procédures, comités, outils, référentiels, matrices de responsabilités, réunions de synchronisation. Cet article s’intéresse à cette complexité-là.

L’INCOSE souligne que la complexité concerne autant l’organisation qui conçoit un système que le système lui-même. Dans les grands projets, cette complexité organisationnelle peut devenir un facteur majeur d’inefficacité. La bonne question n’est donc peut-être pas :

« Comment gérer davantage de complexité ? »

Mais plutôt :

« Comment éviter de fabriquer nous-mêmes une complexité inutile ? »

Un rappel : la complexité produit est incontournable

Prenons un véhicule moderne. Ce qui reposait il y a quelques décennies sur des systèmes mécaniques et électriques relativement indépendants est aujourd’hui un véritable système de systèmes : propulsion électrifiée, batterie haute tension, électronique de puissance, calculateurs, logiciels embarqués, ADAS, cybersécurité, connectivité, interfaces homme-machine, systèmes thermiques, recharge, réglementation. Chaque fonction possède ses propres contraintes. Et surtout, ces fonctions interagissent : une modification de la batterie peut affecter le refroidissement, une évolution logicielle peut modifier la consommation, une exigence réglementaire peut imposer une refonte d’architecture.

C’est ce qui distingue un système complexe d’un simple assemblage. Cette dimension est traitée en profondeur dans notre article sur le MBSE. Concentrons-nous maintenant sur la seconde couche.

La complexité que l’organisation ajoute au projet

Nous savons relativement bien gérer la complexité technique : nous avons des méthodes, des modèles, des outils et des spécialistes. Nous maîtrisons beaucoup moins bien la complexité organisationnelle.

Un projet peut réunir plusieurs directions, plusieurs métiers, plusieurs sites, plusieurs entreprises, plusieurs fournisseurs, plusieurs niveaux de décision, plusieurs outils, plusieurs référentiels et plusieurs cultures professionnelles. Chacun possède sa propre vision du problème. Chacun optimise naturellement son propre périmètre. Et c’est ainsi qu’apparaît un phénomène bien connu :

Chaque partie du système peut être optimisée alors que le système global se dégrade.

C’est le piège classique de l’optimisation locale :

• Le responsable thermique optimise son système thermique.
• L’électronicien optimise son architecture.
• Le spécialiste logiciel optimise son code.
• Le responsable coût optimise le prix de revient.
• Le responsable qualité sécurise ses critères.
• Le chef de projet protège son planning.
• Tous font correctement leur travail.

Mais qui s’assure que l’ensemble fonctionne correctement ? C’est l’une des raisons pour lesquelles l’intégration entre ingénierie système et management de projet est devenue un enjeu majeur, et pourquoi la question de la dérive de projet est indissociable de celle de la complexité organisationnelle.

Le paradoxe des processus : sécuriser peut complexifier

Face à la complexité, notre réflexe naturel est d’ajouter du contrôle. Un problème apparaît ? On crée une procédure. Une erreur survient ? On ajoute une validation. Une interface fonctionne mal ? On ajoute une réunion. Une décision est contestée ? On ajoute un comité. Une information est perdue ? On crée un nouvel outil.

Et progressivement, le système de management devient lui-même complexe. On obtient alors : plus de processus → plus de réunions → plus de reporting → plus de validations → plus de délais. Mais pas nécessairement plus de maîtrise.

Il faut être clair : le problème n’est pas le processus. Un projet complexe a besoin de processus. L’INCOSE rappelle d’ailleurs que le niveau de formalisation des activités d’ingénierie doit être adapté au niveau d’incertitude, de complexité, aux besoins de communication et aux conséquences d’une erreur. Autrement dit, la bonne question n’est pas « faut-il formaliser ? », mais « quel niveau de formalisation est utile ? » Un processus qui sécurise une décision critique crée de la valeur. Un processus qui oblige cinq personnes à valider une décision sans valeur ajoutée crée uniquement de la friction.

La complexité la plus dangereuse est celle qu’on ne voit plus

Il existe une différence fondamentale entre « complexité nécessaire » et « complexité subie ». La première provient du système à concevoir. La seconde provient de notre manière de travailler.

Une architecture complexe peut être justifiée par les performances attendues. Une organisation complexe ne l’est pas forcément. Une matrice de responsabilités détaillée peut être utile. Une matrice dans laquelle personne ne sait qui décide devient contre-productive. Un outil de gestion des exigences peut être indispensable, mais si personne ne sait quelle exigence est prioritaire, l’outil ne résout rien.

La complexité devient dangereuse lorsqu’elle cesse d’être visible :

• On ne voit plus les interfaces.
• On ne voit plus les dépendances.
• On ne sait plus qui prend la décision.
• On ne sait plus pourquoi une exigence existe.
• On ne sait plus quelle contrainte est fondamentale.

Et surtout : on ne sait plus distinguer ce qui est important de ce qui est simplement devenu obligatoire.

Le risque de la « technocratie de l’ingénierie »

À mesure que les systèmes deviennent complexes, nous multiplions les spécialistes. C’est logique, mais l’accumulation d’expertise ne produit pas automatiquement de l’intelligence collective. Un projet peut réunir les meilleurs experts du monde et prendre de mauvaises décisions.

Pourquoi ? Parce que l’expertise est généralement verticale. Le spécialiste connaît parfaitement son domaine. Mais il ne connaît pas nécessairement les conséquences de ses décisions sur les autres domaines. La véritable difficulté n’est donc plus de disposer de compétences. Elle consiste à faire circuler la compréhension entre ces compétences. C’est là que l’ingénierie système joue un rôle essentiel — non pas pour remplacer les spécialistes, mais pour permettre à leurs expertises de converger vers une solution cohérente.

Passer de l’optimisation des métiers à l’optimisation du système

Dans une organisation traditionnelle, chaque métier possède ses objectifs. Mais le produit, lui, n’a qu’un objectif : répondre au besoin pour lequel il a été conçu. Le client ne se demande pas si le problème vient du logiciel, de la batterie, du système thermique ou de l’électronique. Il juge le système dans son ensemble.

C’est cette performance globale qu’il faut protéger. Cela suppose de raisonner systématiquement en termes de :

besoin → fonction → architecture → interfaces → performances → risques → validation.

Simplifier ne signifie pas rendre le système simpliste

Il serait dangereux d’en déduire qu’il suffit de « simplifier ». Un système complexe ne peut pas toujours être rendu simple. En revanche, son fonctionnement peut être rendu compréhensible. C’est une différence essentielle. L’objectif n’est pas de supprimer la complexité inhérente au problème, mais plutôt de :

• La rendre visible ;
• L’organiser ;
• Identifier les interactions critiques ;
• Maîtriser les interfaces ;
• Clarifier les responsabilités ;
• Hiérarchiser les décisions ;
• Réduire les dépendances inutiles.

La complexité devient alors quelque chose que l’on peut piloter.

5 questions auxquelles tout projet complexe devrait pouvoir répondre

Avant d’ajouter un nouvel outil, une nouvelle réunion ou une nouvelle procédure, cinq questions simples peuvent être posées :

1. Quel est le véritable objectif du système ? Pas le livrable. Pas le jalon. Pas le document. L’objectif.
2. Quelles sont les contraintes réellement critiques ? Tout ne peut pas être prioritaire.
3. Quelles interfaces peuvent faire échouer le système ? Les interfaces sont souvent plus dangereuses que les composants eux-mêmes.
4. Qui possède réellement la décision ? Une responsabilité partagée entre cinq personnes est parfois une responsabilité qui n’appartient à personne.
5. Comment savons-nous que nous réussissons ? Un indicateur de production n’est pas nécessairement un indicateur de performance système.

Alors, l’ingénierie est-elle devenue trop complexe ?

Pas exactement. Les systèmes sont devenus plus complexes. Les technologies sont plus interdépendantes. Les projets sont plus internationaux. Les cycles de développement sont plus rapides. Les contraintes réglementaires, économiques, environnementales et industrielles se superposent. Cette complexité est réelle et ne disparaîtra pas. Le véritable danger est ailleurs :

C’est lorsque notre organisation, nos processus et nos outils deviennent plus complexes que le problème que nous cherchons à résoudre.

À ce moment-là, l’ingénierie ne maîtrise plus la complexité : elle la reproduit.

La performance n’est pas l’absence de complexité

L’ingénierie de demain ne cherchera pas à éliminer la complexité. Elle saura faire la différence entre complexité nécessaire et complexité inutile. Elle saura conserver une vision système tout en permettant à chaque expert de rester concentré sur son domaine. Elle saura utiliser les processus sans devenir prisonnière des processus. Elle saura exploiter les outils sans confondre l’outil avec la maîtrise. Et surtout, elle saura remettre la décision technique au centre du projet.

La complexité est parfois inévitable. La confusion, elle, ne devrait jamais l’être.

---

Chez DG Consulting, la performance d’une organisation d’ingénierie ne repose pas seulement sur la somme des expertises disponibles, mais sur la capacité à faire converger ces expertises vers une compréhension commune du système, des priorités et des décisions à prendre. Pour en parler, contactez-nous.