Rien, sur un premier programme DO-178C, ne produit plus d'anxiété par unité d'information que les mots l'autorité mènera une revue. Les équipes s'imaginent un examen. Ce qui se passe réellement s'apparente davantage à un échantillonnage structuré de preuves que vous êtes censé déjà détenir — et une fois compris ce qui est échantillonné et pourquoi, ces revues deviennent des événements d'ingénierie planifiables plutôt qu'un jugement qui plane.
Voici ce que chaque stade d'implication examine, ce que les examinateurs font réellement en séance, et ce qui tourne mal de façon récurrente.
À quoi servent les revues SOI
L'autorité de certification — ou, bien plus souvent, son délégué — ne peut lire chaque élément qu'un programme produit, et ne s'y essaie pas. Les revues de stade d'implication existent pour que les problèmes soient trouvés pendant qu'ils sont encore peu coûteux : un mauvais plan se corrige au SOI nº 1 pour le prix d'une révision de texte, et au SOI nº 4 pour le prix d'un glissement d'échéancier. Les quatre stades sont arrimés aux moments du cycle de vie où chaque catégorie de problème devient visible pour la première fois.
Deux faits désamorcent l'essentiel de l'anxiété. D'abord, le calendrier est proposé par vous, dans le PSAC — il ne s'agit pas d'inspections-surprises. Ensuite, la profondeur de l'implication de l'autorité est proportionnée au programme : le niveau logiciel, la nouveauté et vos antécédents déterminent l'attention que vous recevez. Un premier demandeur au niveau A doit s'attendre à plus de présence qu'un habitué au niveau C.
Les quatre stades, un à un
| Stade | Quand | Preuves sur la table | La vraie question |
| SOI nº 1 — Planification | Plans approuvés, avant le gros du développement | PSAC, SDP, SVP, SCMP, SQAP, les trois normes | Ce plan est-il crédible, complet et adapté au niveau logiciel ? |
| SOI nº 2 — Développement | Un corpus significatif d'exigences, de conception et de code existe | Exigences, données de conception, code, traçabilité, revues effectuées | Suivez-vous réellement vos propres plans et normes ? |
| SOI nº 3 — Vérification | Vérification en grande partie achevée | Cas et procédures d'essai, résultats, analyses de couverture, rapports de problèmes | La preuve de vérification est-elle complète, et se ferme-t-elle véritablement ? |
| SOI nº 4 — Final | Avant l'approbation | SAS, SCI, rapports de problèmes ouverts, derniers enregistrements de GC | Ce logiciel est-il prêt, et les problèmes connus restants sont-ils acceptables ? |
Ce que font réellement les examinateurs : tirer le fil
Les examinateurs échantillonnent. Le geste canonique — qu'il vaut la peine de répéter avant chaque SOI nº 2 et nº 3 — consiste à tirer un fil : choisir une exigence, plus ou moins au hasard, et la suivre vers le bas, de la conception au code, jusqu'au cas d'essai qui la sollicite et au résultat qui montre qu'il a réussi. Puis remonter dans l'autre sens : choisir un morceau de code et demander quelle exigence l'a demandé.
La logique de l'échantillonnage fait sa force : l'examinateur n'a pas choisi cette exigence parce qu'elle était particulière. Si le fil casse, l'hypothèse de travail est que d'autres fils sont cassés aussi, et l'échantillon s'élargit. C'est pourquoi la dette de traçabilité coûte si cher en revue — un seul lien rompu ne vous coûte pas un constat, il vous coûte la confiance de l'examinateur envers la matrice entière.
Constats, observations, et la suite
Les conclusions de revue sont consignées à des gravités différentes — en gros, les points qui doivent être résolus et suivis jusqu'à leur clôture, et les observations de moindre portée qu'il vaut la peine de corriger sans qu'elles bloquent. Ni l'un ni l'autre n'est un verdict sur le programme ; les deux sont la production normale d'une revue qui fonctionne. Ce qui endommage réellement un programme, ce n'est pas de recevoir des constats, c'est de recevoir deux fois le même — rien n'érode plus vite la confiance d'une autorité qu'une clôture qui n'a pas tenu.
Ce qui tourne mal de façon récurrente
- Un SOI nº 1 tenu trop tard. Les plans sont approuvés une fois le travail qu'ils régissent à moitié fait, et chaque écart devient rétroactif.
- La matrice de traçabilité construite pour la revue. Les examinateurs voient quand les liens ont été créés en masse le mois précédent ; le fil tiré trouve les coutures dans la première heure.
- Des exigences dérivées sans retour à la sécurité. Un classique du SOI nº 2, entièrement évitable.
- Une analyse de couverture qui s'arrête au chiffre. « 95 % atteints » sans explication des 5 % restants — code mort, code désactivé ou lacune d'essai — n'est pas une analyse, c'est une mesure.
- Des rapports de problèmes triés avec optimisme. Au SOI nº 4, la liste des problèmes ouverts se lit attentivement. Un rapport classé sans effet sur la sécurité avec une justification d'une ligne attire précisément l'examen qu'il espérait éviter.
- Présenter des preuves que personne en séance ne sait parcourir. Si la personne qui répond aux questions ne trouve pas l'élément discuté en moins d'une minute, la revue ralentit, et les revues lentes tournent mal.
Se préparer sans théâtre
La préparation qui fonctionne n'a rien de glorieux : tirez vos propres fils avant que l'examinateur ne le fasse. Choisissez dix exigences à travers les niveaux, suivez chacune jusqu'en bas et remontez, et corrigez ce qui casse. Faites de même à rebours depuis le code. Lisez la liste des problèmes ouverts comme le ferait un sceptique. Puis informez la personne qui sera en séance de l'état des lieux, y compris des points faibles — les examinateurs réagissent bien mieux à « nous le savons et voici le plan » qu'à leur propre découverte.
Rien de tout cela n'est propre à une autorité. La mécanique de l'engagement diffère entre la FAA, TCCA et l'AESA — qui mène la revue, sous quelle délégation — mais les preuves échantillonnées et la logique du fil tiré sont partout les mêmes.
Foire aux questions
Les revues SOI sont-elles obligatoires ?
Les stades constituent la forme normale de l'engagement de l'autorité sur un programme DO-178C, mais la profondeur et le formalisme sont proportionnés au niveau logiciel, à la nouveauté du produit et aux antécédents du demandeur. Le calendrier est proposé dans votre PSAC et convenu avec l'autorité ou son délégué.
Qui mène réellement la revue ?
Très souvent un délégué plutôt que l'autorité elle-même — un DER sur les programmes américains, un DAR ou un DAO au Canada, des privilèges d'organisme en Europe. Le modèle de délégation change la relation de travail, mais non les preuves examinées.
Combien de temps dure une revue SOI ?
Typiquement de l'ordre de quelques jours par stade, non de semaines — mais le coût de calendrier est dominé par la préparation et par la clôture de ce qui est trouvé, non par la revue elle-même. Budgétez la clôture, pas seulement la rencontre.
Que se passe-t-il si nous en échouons une ?
« Échouer » est le mauvais cadre. Les revues produisent des constats, les constats reçoivent des plans de clôture, et le programme continue. Les issues réellement mauvaises sont les constats qui se rouvrent après clôture, et les constats systémiques — quand un fil cassé s'élargit en doute sur l'ensemble des preuves.
Les revues SOI peuvent-elles se tenir à distance ?
Fréquemment, surtout au stade de la planification, et les revues sur dossier de données soumises sont courantes. Attendez-vous à au moins un engagement sur place ou en prise directe aux stades ultérieurs, où l'examinateur veut conduire lui-même les preuves. La formule se convient au cas par cas.
Vous préparez une première revue SOI — ou vous tenez un constat sur lequel vous aimeriez un second avis avant d'y répondre ? Écrivez-nous.
