L'article précédent se terminait sur un point qui mérite d'être répété : le moteur d'ingénierie des systèmes ne tourne pas une seule fois. Il effectue des cycles — à chaque phase de la vie d'un projet, à fidélité croissante. Cet article porte sur ces phases : à quoi sert chacune, ce qu'elle doit produire, et les portes de décision entre elles qui déterminent si le projet continue tout court.
La structure est celle de la NASA — sept phases, de la pré-phase A à la phase F, selon la NPR 7120.5E telle que présentée dans le manuel d'ingénierie des systèmes du domaine public — mais la logique est universelle : faire mûrir la définition avant d'engager l'argent, et forcer une décision explicite à chaque point où le coût de la poursuite fait un bond.
Les sept phases
| Phase | Nom | Objet | Ce qu'elle doit produire |
| Pré-A | Études conceptuelles | Produire un large éventail d'idées et de solutions de rechange ; établir la faisabilité du système souhaité | Des concepts réalisables — simulations, analyses, rapports d'étude, modèles, maquettes |
| A | Développement du concept et des technologies | Établir la faisabilité et l'intérêt du système proposé ; mettre sous référence les exigences système et le concept de mission | La définition du concept ; les exigences et le concept d'exploitation de référence ; les besoins technologiques |
| B | Conception préliminaire et achèvement technologique | Définir le projet avec assez de détail pour établir une référence initiale capable de répondre au besoin ; conception préliminaire par produit final | Conceptions préliminaires, spécifications et documents d'interface, prototypes, résultats d'études de compromis |
| C | Conception finale et fabrication | Achever la conception détaillée ; fabriquer le matériel et coder le logiciel | Les conceptions finales détaillées ; les composants fabriqués ; le logiciel développé |
| D | Assemblage, intégration, essais, lancement | Assembler et intégrer le système ; bâtir la confiance qu'il satisfait ses exigences ; le transférer à l'usage | Un système prêt pour l'exploitation, avec ses produits habilitants |
| E | Exploitation et maintien | Mener la mission et en maintenir le soutien | La mission, accomplie |
| F | Clôture | Exécuter le plan d'élimination ; analyser les données recueillies | Une fin de vie ordonnée |
Deux grands regroupements coiffent les phases. La formulation (pré-A à B) est celui où la définition mûrit pendant que les dépenses restent comparativement modestes. La mise en œuvre (C à F) est celui où l'argent part. La frontière entre les deux — le KDP C, l'approbation de mise en œuvre — est le moment où l'organisation décide formellement que la définition est assez mûre pour construire. Les lecteurs de notre article d'ouverture reconnaîtront la courbe d'engagement des coûts sous cette structure : la formulation est là où les coûts se déterminent ; la mise en œuvre, là où ils s'engagent.
Les points de décision clés : les phases ont des portes
Les phases sont séparées par des points de décision clés (KDP A à F, chacun donnant accès à la phase de la même lettre). Un KDP n'est pas une revue de l'ingénierie — c'est la décision de gouvernance que le projet a mérité sa phase suivante : définition assez mûre, risque assez bien compris, ressources réellement disponibles. Les revues d'ingénierie l'alimentent ; elles ne le remplacent pas.
Cette distinction — revue technique contre décision de porte — est l'une des idées les plus exportables de tout le cadre. Les projets qui laissent une revue de conception réussie tenir lieu de décision honnête de poursuite ou d'arrêt ont supprimé le seul mécanisme qui tue les projets condamnés pendant qu'ils sont encore peu coûteux à tuer.
Les revues, et la question que chacune pose
| Revue | Se situe | La question posée |
| MCR — Mission Concept Review | Fin de la pré-A | Cette mission mérite-t-elle une étude sérieuse ? |
| SRR — System Requirements Review | Phase A | Les exigences sont-elles complètes, cohérentes et traçables au besoin ? |
| SDR / MDR — System / Mission Definition Review | Fin de la phase A | La référence fonctionnelle est-elle assez solide pour concevoir contre elle ? |
| PDR — Preliminary Design Review | Fin de la phase B | La conception préliminaire satisfait-elle les exigences — et est-elle assez mûre pour s'engager à construire ? Alimente le KDP C |
| CDR — Critical Design Review | Dans la phase C | La conception détaillée est-elle assez complète pour fabriquer et coder contre elle ? |
| SIR — System Integration Review | Frontière C/D | Sommes-nous prêts à commencer l'intégration — produits, installations, procédures ? |
| ORR — Operational Readiness Review | Dans la phase D | Le système, les procédures et les gens sont-ils prêts à exploiter ? |
| FRR — Flight Readiness Review | Fin de la phase D | Tout est-il prêt pour s'engager au lancement ou au déploiement ? |
| DR — Decommissioning Review | Vers la phase F | Est-ce le moment, et le plan est-il en place, pour finir en sécurité ? |
Comment le moteur se projette sur les phases
Le manuel est précis là-dessus, et cette précision est utile. Le moteur complet — processus de conception et de réalisation — effectue cinq cycles de la pré-phase A à la phase D. Les premiers passages déroulent tout le moteur conceptuellement : dès la pré-phase A, les concepts sont « réalisés » sous forme de modèles, de maquettes et de simulations, puis confrontés aux exigences provisoires — une répétition méthodique, non la campagne formelle de vérification. Les phases C et D se partagent ensuite le moteur : C termine le côté gauche (exigences finales, conceptions finales, début de la fabrication), D déroule le droit (intégrer, vérifier, valider, transférer). Les processus de gestion technique effectuent sept cycles — chaque phase, de la pré-A à la F, parce que le risque, la configuration et les décisions ne s'arrêtent pas quand le développement s'arrête.
Lire tout cela en tant que fournisseur
- Sachez dans quelle phase se trouve votre client. Un fournisseur qui livre des réponses de conception détaillée dans la phase A de son client répond à des questions que personne n'a encore méritées — et brûle un espace de compromis dont le client a encore besoin.
- Vos livrables sont des preuves de revue. Quoi que dise votre énoncé de travaux, vos produits seront jugés selon ce dont la prochaine revue du client a besoin. Demandez quelle revue votre travail alimente ; cadrez en conséquence.
- Les frontières de phase sont le moment où les exigences bougent. Les décisions de KDP au-dessus de vous remodèlent les budgets et les références au-dessous. Contractez en conséquence — le trafic de modifications près des portes du client est structurel, pas de la malchance.
- Les noms de phases sont ceux de la NASA ; les questions sont celles de tous. Votre programme les appelle peut-être porte 2 et porte 3, ou PDR et CDR sous un processus ARP4754A. Faites la correspondance de vocabulaire une fois, et toute la structure se transfère.
Foire aux questions
Les sept phases s'appliquent-elles à tous les projets ?
Les questions s'appliquent ; le cérémonial se met à l'échelle. Un petit projet peut traverser une phase en quelques semaines, une seule revue en remplaçant plusieurs. Ce qui ne disparaît pas à l'échelle, c'est la séquence — un projet qui commence la fabrication pendant que ses exigences bougent encore a sauté la formulation, qu'on ait ou non nommé quelque chose « phase B ».
Que se passe-t-il exactement à un KDP ?
Une autorité de décision examine les preuves — maturité technique, posture de risque, réalisme des coûts et de l'échéancier — et décide si le projet se poursuit, se met en attente, se réoriente ou s'arrête. C'est un acte de gouvernance éclairé par les revues techniques, pas une revue technique de plus.
Pourquoi les phases C et D se partagent-elles le moteur ?
Pour la maîtrise de gestion. Terminer la conception et amorcer la fabrication (C), puis intégrer, démontrer et livrer (D), sont des régimes de risque différents, et le manuel précise que la scission existe pour resserrer la supervision de chaque moitié. Le moteur est le même ; la surveillance se resserre.
Quel rapport avec le PDR et le CDR sous l'ARP4754A ?
Direct — le processus d'assurance de développement de l'aviation civile mène des revues de conception avec la même intention, souvent les mêmes noms, ancrées dans la même logique de mériter l'engagement suivant. Le cadre de la NASA ajoute la couche explicite des KDP au-dessus des revues, que bien des programmes aérospatiaux laissent implicite.
La phase E relève-t-elle vraiment de l'ingénierie des systèmes ?
Oui, mais le travail change de caractère : ingénierie de maintien, réponse aux anomalies, et gestion des modifications — lesquelles réintègrent la phase antérieure appropriée pour être développées. Les processus de gestion technique traversent l'exploitation précisément parce que le système continue de changer après la livraison.
Si les portes de votre client ne cessent de vous surprendre — ou si votre propre projet a des revues mais pas de vraies décisions — c'est un problème structurel qui se règle, et c'est notre genre de travail. Écrivez-nous.