Chaque programme DO-178C commence de la même façon : cinq plans et trois normes, rédigés avant que le travail intéressant ne débute, examinés par des gens qui n'étaient pas dans la pièce au moment de la rédaction. La tentation est de les traiter comme un droit d'entrée — des documents à franchir. Cet instinct coûte cher.
Les plans sont l'endroit où un programme s'engage sur ce qu'il fera ; tout ce qui suit est jugé par rapport à eux. Cet article parcourt chaque document — à quoi il sert réellement, qui le lit, et où les revues SOI nº 1 trouvent les problèmes.
L'ensemble, et comment il se tient
L'idée structurelle : le PSAC s'écrit pour l'autorité de certification — un exposé autonome du système, du niveau logiciel, du cycle de vie et de la démonstration de conformité prévue. Les quatre autres plans s'écrivent pour l'équipe, avec la profondeur dont l'équipe a besoin, et le PSAC les résume et y renvoie. Les trois normes sont les recueils de règles de l'équipe, invoqués par les plans et appliqués par les revues.
Les cinq plans, un à un
| Plan | Lecteur principal | La question à laquelle il doit répondre |
| PSAC — Plan for Software Aspects of Certification | L'autorité de certification ou son délégué | Cette voie vers la conformité est-elle crédible et complète pour un logiciel de ce niveau ? |
| SDP — Software Development Plan | L'équipe de développement | Comment les exigences deviennent-elles conception, code et logiciel intégré — avec quelles méthodes, quels environnements et quels critères de transition ? |
| SVP — Software Verification Plan | L'équipe de vérification | Comment les revues, analyses et essais satisferont-ils les objectifs de vérification — indépendance et résolution de la couverture comprises ? |
| SCMP — Software Configuration Management Plan | Tout le monde, en continu | Comment les références, les modifications, les rapports de problèmes et les livraisons sont-ils maîtrisés — pour les preuves autant que pour le code ? |
| SQAP — Software Quality Assurance Plan | L'assurance qualité, et l'autorité | Comment la conformité à tous les autres plans sera-t-elle assurée de façon indépendante, avec enregistrements ? |
Deux d'entre eux méritent un commentaire particulier, parce qu'ils sont chroniquement sous-écrits.
Le SCMP ne porte pas sur le code. Il régit chaque élément du cycle de vie — exigences, plans, procédures d'essai, résultats, configurations d'outils. Le constat de gestion de configuration le plus fréquent : une référence de code impeccable entourée de preuves sans maîtrise — des exigences dans un tableur sans historique, des résultats dans un dossier nommé final_v2.
Le SQAP n'est pas une formalité. L'assurance qualité est le système immunitaire du processus — la fonction qui vérifie si l'équipe fait ce que disent les plans, pendant qu'il est encore temps de corriger. Un SQAP qui décrit l'assurance qualité comme « la revue de documents » a déjà annoncé à l'examinateur qu'elle sera décorative.
Les critères de transition : les phrases porteuses
Les trois normes
| Norme | Ce qu'elle contraint | À quoi ressemble la qualité |
| Normes d'exigences | La rédaction des exigences : notation, structure, identification, attributs obligatoires | Des règles qu'un examinateur peut vérifier mécaniquement — pas des aspirations du type « les exigences seront claires » |
| Normes de conception | Les contraintes d'architecture et de conception : notations, limites de complexité, motifs permis et interdits | Des contraintes traçables à de vrais modes de défaillance, pas un guide de style |
| Normes de codage | Le sous-ensemble du langage, les constructions interdites, le nommage, les seuils de complexité | Souvent bâties sur un sous-ensemble de l'industrie — adopté délibérément, chaque écart justifié |
Le piège des normes : en adopter plus qu'on ne peut en faire respecter. Chaque règle de votre norme de codage est la promesse que quelqu'un — ou un outil qualifié — la vérifie. Une norme de 200 règles sans analyse statique branchée dessus, ce sont 200 constats qui attendent un examinateur muni d'un plan d'échantillonnage. Adoptez ce que vous ferez réellement respecter, et justifiez l'adaptation ; une norme courte honnêtement appliquée vaut mieux qu'une norme exhaustive honorée par son inobservation.
Où les revues SOI nº 1 trouvent réellement les problèmes
- Les plans se contredisent entre eux. Le SVP promet une indépendance que la structure d'équipe du SDP ne peut fournir ; le PSAC nomme un outil que le SDP ne mentionne jamais. Les examinateurs lisent l'ensemble côte à côte précisément parce que les auteurs le font rarement.
- Les plans contredisent la réalité. Le SDP décrit un processus que l'équipe n'a jamais déroulé — généralement un gabarit hérité d'un autre programme, avec les hypothèses du projet précédent encore à l'intérieur.
- Des critères de transition vagues. Voir ci-dessus.
- L'usage d'outils sans position de qualification. Chaque outil qui élimine, réduit ou automatise une étape du processus exige une position déclarée — qualifié, ou sa sortie vérifiée de façon indépendante. Le silence ici est un constat qui s'aggrave au SOI nº 3.
- Les exigences d'indépendance du niveau non dotées en personnel. Le plan écrit « avec indépendance » là où les objectifs l'exigent ; l'organigramme le rend arithmétiquement impossible.
Bien les écrire, à peu de frais
Les plans récompensent une discipline précise : écrivez ce que vous ferez, puis faites ce que vous avez écrit. Les corollaires sont pratiques. Rédigez les plans avec les personnes qui les exécuteront, non pour elles. Gardez le PSAC autonome mais mince — il résume, il ne duplique pas. Prévoyez une passe de cohérence sur l'ensemble avant qu'un regard externe ne s'y pose. Et traitez les révisions de plans comme normales : un plan révisé sous gestion de configuration en cours de programme est en bonne santé ; c'est le plan qui n'a jamais changé pendant que le programme changeait qui est suspect.
Foire aux questions
Peut-on regrouper les plans en moins de documents ?
Oui — les petits programmes les combinent couramment, et le souci de la norme est que l'information de planification existe, soit cohérente et soit suivie, non le nombre de pages ni la reliure. Ce qui ne rétrécit pas, c'est le rôle du PSAC : l'exposé destiné à l'autorité doit toujours tenir debout seul.
Les plans doivent-ils être approuvés par l'autorité avant de commencer ?
Le PSAC est soumis à l'autorité, et les programmes prudents veulent son retour avant d'engager de grosses dépenses sur sa foi — c'est en grande partie l'objet du SOI nº 1. Développer pendant que le sort du PSAC est inconnu est un pari d'échéancier : parfois raisonnable, toujours à prendre consciemment.
Peut-on réutiliser les plans d'un programme précédent ?
Comme structure de départ, oui ; mot à mot, non. Les examinateurs reconnaissent instantanément les plans hérités — le nom du système précédent dans un paragraphe non retouché est un classique. Chaque phrase réutilisée demeure un engagement ; assurez-vous que c'en est un que ce programme entend tenir.
Qui devrait rédiger le PSAC ?
Quelqu'un qui comprend à la fois l'ingénierie et la conversation de certification — c'est un document technique à fonction diplomatique. En pratique, il est souvent rédigé par la liaison de certification ou un ingénieur senior, puis revu par tous ceux dont il engage le travail.
Qu'est-ce qui change dans les plans aux niveaux logiciels inférieurs ?
L'ensemble documentaire est le même ; les engagements qu'il contient rétrécissent avec les objectifs. Un SVP de niveau D est court parce que la vérification de niveau D est courte. L'erreur consiste à copier un ensemble de plans de niveau A pour un programme de niveau D — vous serez audité sur tout ce que vous avez écrit, y compris la rigueur que vous n'aviez jamais besoin de promettre.
Nous rédigeons, révisons et réparons des ensembles de plans de certification — y compris la passe de cohérence qui attrape les constats du SOI nº 1 avant l'autorité. Écrivez-nous.