L'article d'ouverture de cette série présentait le moteur d'ingénierie des systèmes de loin : dix-sept processus, trois groupes, appliqués en descendant puis en remontant la structure du système. Celui-ci parcourt le moteur pour de bon — ce que chaque processus produit réellement, comment la récursivité fonctionne en pratique, et où les équipes l'appliquent de travers.
La source demeure la NPR 7123.1 et le Systems Engineering Handbook de la NASA (SP-2016-6105 rév. 2), tous deux du domaine public. Le moteur est la formulation de la NASA, mais ce qu'il formalise n'a rien de propre à la NASA : c'est l'anatomie de tout développement discipliné, rendue assez explicite pour être enseignée, auditée et adaptée.
Le moteur, à nouveau — cette fois avec les flux
Lisez le moteur comme une machine à deux ports. Les exigences entrent par le niveau supérieur ; les produits réalisés et démontrés en ressortent vers ce même niveau. Entre ces deux ports, les processus de conception convertissent des attentes en une définition constructible, et les processus de réalisation convertissent cette définition en un produit prouvé. Les huit processus de gestion technique ne sont pas une phase : ils sont le système de commande de la machine, en marche chaque fois qu'elle tourne.
La conception du système : processus 1 à 4
| Processus | Ce qu'il fait | Le produit qui compte |
| 1 · Définition des attentes des parties prenantes | Établit qui sont les parties prenantes et ce dont elles ont réellement besoin — attentes, concept d'exploitation, mesures d'efficacité | Un énoncé mis sous référence de ce que signifie réussir, avant qu'on n'écrive une exigence |
| 2 · Définition des exigences techniques | Convertit les attentes en exigences techniques complètes et vérifiables | La référence d'exigences — le contrat auquel tout l'aval répond |
| 3 · Décomposition logique | Décompose les exigences en modèles logiques et en exigences dérivées pour le niveau inférieur | La structure : quelles fonctions existent, comment elles se relient, ce qui circule entre elles |
| 4 · Définition de la solution de conception | Choisit et définit la conception qui satisfait les exigences — y compris la décision faire/acheter/réutiliser par élément | Une définition assez complète pour construire, acheter ou réutiliser — ou pour transmettre au niveau inférieur |
La discipline cachée dans ce groupe, c'est le refus de sauter des paliers. Les attentes ne sont pas des exigences ; les exigences ne sont pas une conception. Chaque conversion est un endroit où l'erreur se détecte à peu de frais — et chaque conversion sautée, un endroit où l'erreur survit jusqu'à l'intégration. Les lecteurs de notre série DO-178C reconnaîtront la même échelle à trois barreaux que la norme logicielle impose entre exigences système, exigences de haut niveau et conception.
La réalisation du produit : processus 5 à 9
| Processus | Ce qu'il fait | La distinction qu'il protège |
| 5 · Réalisation du produit | Construit, achète ou réutilise les produits du niveau le plus bas | Là où la conception devient enfin matériel et code |
| 6 · Intégration du produit | Assemble les produits d'un niveau en celui du niveau supérieur | L'intégration est un processus, avec sa planification et ses preuves — pas un événement de calendrier |
| 7 · Vérification du produit | Démontre que le produit satisfait ses exigences | « L'avons-nous bien construit ? » — contre les exigences |
| 8 · Validation du produit | Démontre que le produit répond aux attentes des parties prenantes dans son environnement prévu | « Avons-nous construit la bonne chose ? » — contre l'intention |
| 9 · Transfert du produit | Livre le produit au niveau suivant, ou à l'utilisateur, avec ses preuves | Le produit et sa démonstration voyagent ensemble |
La gestion technique : processus 10 à 17
Les huit processus transversaux — planification technique, gestion des exigences, gestion des interfaces, gestion des risques techniques, gestion de configuration, gestion des données techniques, évaluation technique et analyse de décision — sont ceux qu'on écarte le plus volontiers comme des frais généraux, et ceux dont l'absence coûte le plus cher. Trois méritent une mention pour la régularité avec laquelle on les sous-estime :
- La gestion des interfaces, ce sont les coutures rendues explicites — le registre des ententes sur ce qui traverse chaque frontière. La plupart des surprises d'intégration sont des ententes d'interface qui n'existaient que dans deux têtes, dont l'une est partie.
- L'évaluation technique, c'est ainsi que le programme sait où il en est réellement — des revues et des mesures contre le plan, non contre l'optimisme. C'est la version interne de ce que font, à l'externe, les revues échelonnées d'une autorité.
- L'analyse de décision, c'est la discipline de l'étude de compromis : options, critères, données, recommandation, trace. Son produit est la réponse à la question préférée de l'auditeur, des années plus tard : pourquoi est-ce conçu ainsi ?
La récursivité : l'idée qui en fait un moteur
Ce qui en fait un moteur plutôt qu'une liste de contrôle, c'est que toute la machine s'applique à chaque niveau de la structure du système. Le niveau système déroule les processus 1 à 4 et transmet des exigences vers le bas ; chaque sous-système déroule les mêmes processus sur ce qu'il a reçu ; les composants de même, jusqu'à ce que chaque élément soit défini assez précisément pour être construit, acheté ou réutilisé. Puis la réalisation remonte l'échelle en sens inverse — réaliser en bas, intégrer, vérifier, valider et transférer vers le haut, niveau par niveau, jusqu'à ce que le système qui émerge au sommet soit celui que les parties prenantes avaient demandé.
La NPR 7123.1 jumelle la récursivité à l'itération — re-dérouler un processus sur le même produit lorsqu'un écart est découvert — et les deux ensemble répondent à la question que pose chaque nouvelle équipe : non, on ne déroule pas le moteur une seule fois. Il tourne à chaque phase du cycle de vie, à fidélité croissante, et le manuel est explicite : le moteur tourne dans chaque phase, des études conceptuelles jusque tard dans le développement.
Comment les équipes l'appliquent de travers
- Le dérouler une fois, au sommet. Un magnifique référentiel d'exigences au niveau système, puis la foire en dessous. La valeur du moteur tient précisément à ce que sous-systèmes et composants reçoivent le même traitement.
- Traiter les processus de gestion comme une phase documentaire. Une gestion de configuration qui commence à la livraison, une gestion des risques qui commence à la première crise — les processus transversaux ne fonctionnent qu'en continu.
- Laisser la décomposition devenir de la dictée. La décomposition logique transmet des exigences, pas des conceptions. Quand le niveau supérieur spécifie la conception du niveau inférieur, on écarte de la décision les personnes qui connaissent le mieux ce niveau.
- Confondre récursivité et bureaucratie. Au niveau d'un composant, la passe du moteur peut tenir en un après-midi et deux pages. La méthode se met à l'échelle ; le cérémonial doit suivre. Cette discipline d'adaptation a son propre article plus loin dans la série.
- Sauter la validation parce que la vérification a réussi. Voir l'encadré ci-dessus — la fusion la plus courante et la plus coûteuse.
Le lien avec la certification
Pour le lecteur en route vers la certification : le moteur est l'endroit d'où provient réellement l'ensemble d'éléments qu'une autorité échantillonne. Les attentes des parties prenantes et les exigences techniques mises sous référence deviennent les exigences système que l'ARP4754A répartit ; la décomposition produit les exigences d'élément que le DO-178C trace ; les enregistrements de vérification et de validation deviennent la preuve dans laquelle une revue échelonnée tire ses fils ; et les processus de gestion technique sont, presque nom pour nom, les processus intégraux du DO-178C. Bien faire tourner le moteur ne ressemble pas simplement à une préparation à la certification — c'est la préparation, organisée selon une autre table des matières.
Foire aux questions
Les dix-sept processus s'appliquent-ils à tous les projets ?
Les processus s'appliquent ; leur profondeur s'adapte. La NPR 7123.1 est une exigence procédurale de la NASA, et la NASA elle-même l'adapte projet par projet. Ce qui ne survit pas à une adaptation honnête, c'est la suppression pure et simple d'un processus — un projet sans gestion des interfaces n'a pas un processus plus léger, il a un risque sans gestion.
Dans quel ordre les processus se déroulent-ils ?
La numérotation est une anatomie, pas un échéancier. Les processus de conception se déroulent du haut vers le bas, la réalisation du bas vers le haut, et la gestion en continu — avec itération chaque fois qu'un écart renvoie du travail en arrière. Sur un vrai programme, plusieurs niveaux se trouvent simultanément à des points différents du moteur.
Quel rapport entre le moteur et le cycle en V ?
C'est la même idée dessinée autrement. La branche gauche du V, ce sont les processus de conception appliqués en descendant la structure ; la branche droite, la réalisation qui remonte ; le moteur ajoute ce que le V laisse implicite — les processus de gestion qui traversent l'ensemble, et la récursivité explicite à chaque niveau.
Quelle différence entre la décomposition logique et la conception ?
La décomposition établit quelles fonctions doivent exister et comment elles se relient — un modèle de la structure du problème. La définition de la solution de conception choisit comment ces fonctions seront réalisées. Les garder séparées préserve l'espace des compromis : décomposez d'abord et vous pouvez encore comparer des conceptions ; concevez d'abord et la décomposition ne fait plus que justifier.
Par où un petit fournisseur devrait-il commencer ?
Par les processus 1, 2 et 11 — connaître ses parties prenantes, mettre sous référence des exigences vérifiables, et gérer les changements qui leur arrivent. Ces trois-là, faits honnêtement, entraînent derrière eux l'essentiel du reste du moteur ; et ce sont exactement les trois dont l'absence est détectée le plus vite par la diligence d'un client, ou par une revue de type SOI.
Si l'on demande à votre organisation, pour la première fois, des preuves d'ingénierie des systèmes à ce niveau de rigueur — ou si votre moteur existe sur papier et non en pratique — c'est le travail que nous faisons, dans les deux langues officielles. Écrivez-nous.