Demandez à cinq ingénieurs ce qu'est l'ingénierie des systèmes et vous obtiendrez une caricature — la paperasse, les revues, les gens qui réclament des documents — et quatre variantes de celle-ci. La caricature persiste parce que la mauvaise ingénierie des systèmes ressemble vraiment à cela. La bonne est tout autre chose : c'est la discipline responsable du système dans son ensemble — cette chose qui existe au-delà de ses parties, là où vivent les exigences, les interfaces et les défaillances.
Cet article ouvre notre série sur l'ingénierie des systèmes. Il s'appuie sur le Systems Engineering Handbook de la NASA (SP-2016-6105 rév. 2) — une référence du domaine public écrite pour les programmes les plus exigeants qui soient — et sur ce qu'exige l'application de cette discipline dans des équipes bien plus petites que celles de la NASA.
Le métier, en une phrase
L'ingénierie des systèmes est la discipline méthodique qui conçoit, réalise et gère un système sur tout son cycle de vie pour qu'il accomplisse sa raison d'être — en sécurité, dans les contraintes de coût, d'échéancier et de risque, et au jugement des personnes à qui il est destiné.
Deux mots de cette phrase font tout le travail. Système : ni le logiciel, ni le boîtier, mais le tout — matériel, logiciel, personnes, procédures, et leurs interactions. Raison d'être : la mesure du succès est l'intention des parties prenantes, non la conformité à une spécification qui peut elle-même être erronée. Une grande part de la discipline existe pour empêcher que ces deux choses — le tout, et l'intention — ne se perdent discrètement pendant que chacun travaille sur sa partie.
Le moteur d'ingénierie des systèmes : dix-sept processus, trois métiers
L'exigence procédurale NPR 7123.1 de la NASA organise la discipline en dix-sept processus techniques communs, répartis en trois ensembles. Le regroupement importe davantage que le compte : quatre processus conçoivent le système, cinq le réalisent, et huit gèrent l'effort technique à travers tout le reste.
| Groupe | Processus | Ce que fait le groupe |
| Conception du système (1–4) | Définition des attentes des parties prenantes · Définition des exigences techniques · Décomposition logique · Définition de la solution de conception | Transforme l'intention en exigences mises sous référence, et les exigences en conception, à chaque niveau de la structure du système, du haut vers le bas |
| Réalisation du produit (5–9) | Réalisation du produit · Intégration du produit · Vérification du produit · Validation du produit · Transfert du produit | Construit ou achète les produits du niveau le plus bas, puis intègre, démontre et livre chaque niveau, du bas vers le haut |
| Gestion technique (10–17) | Planification technique · Gestion des exigences · Gestion des interfaces · Gestion des risques techniques · Gestion de configuration · Gestion des données techniques · Évaluation technique · Analyse de décision | La boucle de contrôle transversale : planifie le travail technique, gère ce qui change, mesure l'avancement et appuie les décisions |
La forme du moteur encode les deux mécaniques centrales de la discipline. Les processus de conception s'appliquent en descendant la structure du système — système, sous-système, composant — jusqu'à ce que chaque pièce soit définie assez précisément pour être construite, achetée ou réutilisée. Les processus de réalisation s'appliquent ensuite en remontant la même structure, intégrant et démontrant chaque niveau. Et le moteur entier fonctionne de manière itérative (réappliqué au même produit pour corriger un écart) et récursive (réappliqué à chaque niveau de la structure, puis à chaque phase du cycle de vie). Ces deux mots sont ceux de la NPR 7123.1 elle-même, et ils constituent la réponse honnête à « quand l'ingénierie des systèmes est-elle terminée ? » — pas avant le dernier niveau, de la dernière phase.
Les phases, brièvement
La NASA mène ses projets à travers une séquence fixe de phases de cycle de vie — des études conceptuelles de la pré-phase A jusqu'à la clôture de la phase F — séparées par des points de décision clés et jalonnées par les grandes revues. Le moteur ne tourne pas une seule fois : il effectue un cycle à chaque phase, chaque passage faisant mûrir la définition, du concept réalisable au système déployé. La structure des phases et ses revues méritent leur propre article plus loin dans cette série ; ce qui compte ici, c'est le principe que les mêmes processus se répètent avec une fidélité croissante, plutôt que chaque phase n'ait sa méthode exotique.
Pourquoi les premières phases dominent le coût
L'argument économique de la discipline tient dans une seule image. Les coûts sont engagés tard — le matériel, l'intégration, les campagnes d'essais. Mais ils sont déterminés tôt, par des décisions de concept et d'architecture prises quand la courbe des dépenses paraît encore innocente. Les problèmes découverts tard coûtent radicalement plus cher à corriger, et une réduction de portée prise tard épargne moins que la même réduction prise tôt.
C'est la même asymétrie qui traverse notre série DO-178C — l'architecture ne coûte rien pendant l'évaluation de sécurité et coûte une fortune après le gel de la conception — parce que c'est le même fait sous-jacent : les décisions se figent bien avant que leurs conséquences n'arrivent. L'ingénierie des systèmes concentre la réflexion en amont précisément parce que le levier est en amont, qu'on y réfléchisse ou non.
Ce que l'ingénierie des systèmes n'est pas
- Pas la gestion de projet. Le coût, l'échéancier, la dotation et l'acquisition relèvent de la planification et du contrôle de projet. Les deux disciplines s'emboîtent — le risque technique nourrit le risque programmatique, le plan technique alimente l'échéancier — mais l'autorité de l'ingénierie des systèmes porte sur la référence technique, non sur le budget.
- Pas la somme des ingénieurs de discipline. Un projet peut avoir d'excellentes équipes logiciel, structures et thermique, et échouer quand même aux coutures. Quelqu'un doit posséder le tout ; ce n'est pas une propriété à temps partiel des parties.
- Pas de la documentation. Les éléments — exigences, définitions d'interfaces, études de compromis, matrices de vérification — sont le résidu des décisions, conservé pour que les décisions survivent au roulement du personnel et aux audits. Produire le résidu sans les décisions, c'est la caricature, et elle mérite sa réputation.
- Pas réservée aux programmes à l'échelle de la NASA. Les processus se réduisent ; ce qui ne se réduit pas, c'est de les sauter. Un fournisseur de quatorze personnes a quand même des parties prenantes, des interfaces, du risque et de la configuration — il ne peut simplement pas se payer un service pour chacun. L'adaptation, et non l'omission, est l'ajustement honnête, et elle a son propre article dans cette série.
Pourquoi cela compte pour un fournisseur visé par la certification
Pour les lecteurs venus de notre série DO-178C, voici le pont que toute cette série ne cessera de construire : la preuve de certification, c'est l'allure que prennent les produits du moteur d'ingénierie des systèmes quand une autorité les lit. Les attentes des parties prenantes et les exigences techniques deviennent les exigences système que l'ARP4754A répartit et que le DO-178C trace. La vérification et la validation deviennent la preuve échantillonnée lors d'une revue de stade d'implication. La gestion de configuration, le risque et l'évaluation technique sont les mêmes processus intégraux que le DO-178C revendique comme les siens. Un fournisseur dont le moteur d'ingénierie des systèmes fonctionne a déjà parcouru l'essentiel du chemin vers un processus certifiable avant que quiconque prononce le mot conformité — et un fournisseur qui en est dépourvu finit par acheter les deux, sous pression d'échéancier, en même temps.
Foire aux questions
L'ingénierie des systèmes, n'est-ce pas que de la paperasse ?
La paperasse est le résidu, non le travail. Le travail consiste à décider ce que le système doit faire, comment il se décompose, quelles sont ses interfaces et comment vous saurez qu'il fonctionne — puis à consigner ces décisions pour qu'elles survivent au roulement, à l'intégration et à l'audit. Des documents produits sans ces décisions derrière eux, c'est la caricature, et ils n'aident personne.
Qu'est-ce que la NPR 7123.1 ?
L'exigence procédurale de la NASA pour l'ingénierie des systèmes — le document qui définit les dix-sept processus techniques communs et en impose l'usage sur les programmes de la NASA. Le Systems Engineering Handbook (SP-2016-6105) en est le compagnon explicatif : la NPR dit quoi, le manuel dit comment et pourquoi. Les deux relèvent du domaine public.
Quel est le lien avec l'ARP4754A ?
L'ARP4754A est la norme d'assurance de développement de l'aviation civile pour les aéronefs et les systèmes — même territoire, mis en forme pour la certification. Le moteur de la NASA et l'ARP4754A décrivent des vues compatibles de la même discipline : définition et répartition des exigences, décomposition, intégration, vérification et validation. Une équipe à l'aise dans l'un reconnaît l'autre immédiatement ; cette série tracera explicitement les correspondances.
Les petites équipes en ont-elles vraiment besoin ?
Les petites équipes ont besoin des processus ; elles ne peuvent se payer le cérémonial. Le mode d'échec des petits fournisseurs n'est pas l'excès de processus — c'est de découvrir à l'intégration, ou lors d'une revue client, que personne ne possédait les interfaces ni la référence d'exigences. Adapter le moteur à une petite équipe fait l'objet d'un article ultérieur de cette série, parce que c'est l'essentiel de ce qui rend la discipline utilisable hors de la NASA.
Nous faisons déjà du DO-178C. Est-ce redondant ?
Non — c'est en amont. Le DO-178C suppose que quelqu'un a remis au logiciel des exigences bien formées et réparties, et reprendra ses produits dans un processus de niveau système. Ce quelqu'un, c'est cette discipline. Une ingénierie des systèmes faible est la cause première la plus fréquente des programmes DO-178C coûteux : l'instabilité des exigences, les changements d'interface tardifs et les hypothèses sans propriétaire naissent tous au-dessus du logiciel.
Si votre programme a des pièces solides et des coutures fragiles — ou si un client vous demande des preuves d'ingénierie des systèmes que vous n'avez jamais eu à produire — c'est exactement le travail que nous faisons, dans les deux langues officielles. Écrivez-nous.