# DO-178C : la liste des documents, à quoi ils servent et dans quel ordre les écrire

Source : https://consignestudio.fr/guides/do-178c-liste-des-documents/ · publié le 2026-10-27 · Antoine Despres, Consigne

Un dossier DO-178C compte cinq plans (PSAC, SDP, SVP, SCMP, SQAP), trois standards (exigences, conception, codage), les données de développement et de vérification, puis trois documents de clôture (SCI, SECI, SAS). On écrit le PSAC en premier, car il fixe tout le reste, et on tient la traçabilité au fil de l'eau. Voici chaque document, son rôle et les erreurs qui reviennent le plus.

## DO-178C en une minute

DO-178C (ED-12C en Europe) ne décrit pas une méthode de développement. Elle fixe des **objectifs** à atteindre pour qu'un logiciel embarqué soit accepté par l'autorité, les **activités** qui permettent de les atteindre et les **données** qui en apportent la preuve. Le nombre d'objectifs applicables et l'exigence d'indépendance dépendent du **niveau logiciel**, fixé par l'évaluation de sécurité du système.

| Niveau | Condition de panne la plus grave à laquelle le logiciel peut contribuer | Couverture structurelle attendue |
|---|---|---|
| A | catastrophique | MC/DC, décisions, instructions |
| B | dangereuse | décisions, instructions |
| C | majeure | instructions |
| D | mineure | aucune |
| E | sans effet | DO-178C ne s'applique pas au-delà de l'identification du niveau |

Les objectifs sont regroupés dans les dix tableaux de l'Annexe A (A-1 à A-10). Pour chaque objectif et chaque niveau, ils disent s'il s'applique, s'il doit être atteint avec indépendance, et la catégorie de contrôle (CC1 ou CC2) des données produites. Ce sont ces tableaux qu'il faut garder ouverts à côté de ses plans.

> L'usage parle de « DAL » pour le logiciel. Le sigle vient d'ARP4754A ; DO-178C dit « software level ». Les deux désignent la même chose dans la pratique.

## Les documents, regroupés par étape

### Les plans : ce que l'équipe va faire

| Document | Rôle | Section DO-178C |
|---|---|---|
| **PSAC** · Plan for Software Aspects of Certification | Le contrat avec l'autorité : quel logiciel, quel niveau, quels processus, quelles données, quels points particuliers | §11.1 |
| **SDP** · Software Development Plan | Processus d'exigences, de conception, de codage et d'intégration, environnement, critères de transition | §11.2 |
| **SVP** · Software Verification Plan | Revues, analyses, tests, couverture, indépendance, environnement de vérification, régression | §11.3 |
| **SCMP** · Software Configuration Management Plan | Identification, lignes de base, rapports de problème, archivage, reconstruction | §11.4 |
| **SQAP** · Software Quality Assurance Plan | Audits, autorité de l'assurance qualité, revue de conformité | §11.5 |

### Les standards : des règles numérotées et vérifiables

| Document | Rôle | Section |
|---|---|---|
| Standard d'exigences | Comment écrire une exigence de haut niveau vérifiable | §11.6 |
| Standard de conception | Règles d'architecture et d'exigences de bas niveau | §11.7 |
| Standard de codage | Sous-ensemble du langage, règles de complexité, interdits | §11.8 |

Un bon standard permet à un relecteur d'écrire « écart à EX-04 » plutôt que « exigence imprécise ».

### Les données de développement et de vérification

| Document | Rôle | Section |
|---|---|---|
| **SRD** · Software Requirements Data | Exigences de haut niveau, y compris les exigences dérivées | §11.9 |
| **SDD** · Design Description | Architecture et exigences de bas niveau | §11.10 |
| Code source et code objet | Avec leur identification en configuration | §11.11, §11.12 |
| **SVCP** · Verification Cases and Procedures | Cas et procédures de test, de revue et d'analyse | §11.13 |
| **SVR** · Verification Results | Résultats, couverture, analyses d'écarts | §11.14 |
| Rapports de problème | Formulaire, circuit, analyse d'impact sur la sécurité | §11.17 |
| Enregistrements d'assurance qualité | Audits, revue de conformité | §11.19 |

Si les exigences et les tests vivent dans un outil (Jira, Polarion, DOORS…), ces documents deviennent l'**export daté** de l'outil, avec la référence de la ligne de base.

### La clôture

| Document | Rôle | Section |
|---|---|---|
| **SCI** · Software Configuration Index | Tout ce qu'il faut pour reconstruire, recharger et revérifier le logiciel | §11.16 |
| **SECI** · Life Cycle Environment Configuration Index | L'environnement : compilateurs, options, outils, machines hôtes | §11.15 |
| **SAS** · Software Accomplishment Summary | La réponse point par point au PSAC : ce qui a été fait, les écarts, les rapports ouverts | §11.20 |

Si des outils servent à éliminer, réduire ou automatiser une activité sans que leur sortie soit vérifiée par ailleurs, il faut aussi les qualifier (§12.2). La qualification suit DO-330, qui a ses propres plans et données.

## L'ordre d'écriture qui évite les reprises

1. **Confirmer le niveau** avec l'équipe système. Il vient de l'évaluation de sécurité, pas d'un choix du logiciel.
2. **Écrire le PSAC**, au moins dans les grandes lignes. Il fixe ce que les autres plans détailleront.
3. **Inventorier les outils** et décider de leur qualification. C'est souvent là qu'un projet découvre un coût caché.
4. **Écrire SDP, SVP, SCMP, SQAP et les trois standards.**
5. **Revoir les plans** en interne, puis soumettre le PSAC à l'autorité.
6. **Développer** en tenant la matrice de traçabilité à jour au fil de l'eau : exigence système, exigence de haut niveau, de bas niveau, code, test.
7. **Vérifier** : chaque test se rattache à une exigence ; la couverture structurelle se mesure sur les tests fondés sur les exigences, pas sur des tests écrits pour la couverture.
8. **Clôturer** : SCI, SECI, revue de conformité par l'assurance qualité, SAS.

## Les revues avec l'autorité (SOI)

En pratique, l'autorité ou l'organisme qui agit pour elle intervient à quatre moments, les « stages of involvement ». Ils ne sont pas définis par DO-178C elle-même mais par les documents de l'autorité (FAA Order 8110.49A, et côté EASA l'AMC 20-115 en vigueur).

| Revue | Ce qu'on vous demandera |
|---|---|
| SOI 1 · planification | Plans et standards cohérents, approuvés, en configuration ; points particuliers justifiés |
| SOI 2 · développement | Un échantillon d'exigences, de conception et de code, revu, tracé, en configuration |
| SOI 3 · vérification | Un échantillon de cas, procédures, résultats, couverture, rapports de problème |
| SOI 4 · finale | SCI, SECI, SAS, revue de conformité |

La meilleure répétition : choisissez vous-même une exigence système et suivez-la jusqu'au test et à son résultat. C'est exactement ce que fera l'autorité.

## Les dix erreurs qui reviennent le plus

1. Plans écrits pour l'autorité, pas pour l'équipe, puis non suivis.
2. PSAC soumis trop tard, après le début du développement.
3. Indépendance annoncée mais non tenue (revue clôturée par l'auteur).
4. Exigences de haut niveau qui décrivent la conception.
5. Exigences invérifiables : « rapidement », « suffisant ».
6. Exigences dérivées non transmises au processus système.
7. Traçabilité reconstituée à la fin du projet.
8. Tests écrits à partir du code pour atteindre la couverture.
9. Outils de vérification utilisés pour supprimer une activité sans qualification.
10. Assurance qualité rattachée au chef de projet, sans pouvoir de blocage.

## Ce qui change vraiment selon le niveau

Un bon plan de niveau D ressemble à un bon plan de niveau A, avec moins d'objectifs et moins d'indépendance. Les différences qui pèsent le plus :

| Point | A | B | C | D |
|---|---|---|---|---|
| Couverture structurelle | MC/DC, décisions, instructions | décisions, instructions | instructions | aucune |
| Analyse du couplage données et contrôle | oui | oui | oui | non |
| Code objet non traçable au source | à analyser | non | non | non |
| Indépendance de la vérification | forte | forte | selon l'Annexe A | selon l'Annexe A |

> Avant de supprimer une activité parce qu'elle « ne s'applique pas à votre niveau », vérifiez-le dans les tableaux de l'Annexe A de votre exemplaire. C'est la norme qui fait foi.

## Partir d'un dossier structuré

Le [kit DO-178C en français](https://consignestudio.fr/modeles-do-178c/) fournit ces 17 documents en gabarits Word, déclinés pour les niveaux A à D, avec des consignes de rédaction, un exemple fictif complet, les checklists de revue en Excel et une matrice de traçabilité préréglée. Il renvoie aux sections de la norme sans en reproduire le texte, et ne remplace ni l'autorité ni l'expérience. La checklist de revue des plans (niveau C) est gratuite sur la même page. Pour la traçabilité seule, la [matrice de traçabilité des exigences](https://consignestudio.fr/matrice-tracabilite-exigences/) existe aussi en édition gratuite.

## Sources

- RTCA DO-178C / EUROCAE ED-12C, Software Considerations in Airborne Systems and Equipment Certification, 2011 (sections citées par leur numéro, texte non reproduit)
- RTCA DO-330 / EUROCAE ED-215, Software Tool Qualification Considerations
- FAA Order 8110.49A, Software Approval Guidelines
- EASA AMC 20-115D, Airborne software development assurance using EUROCAE ED-12 and RTCA DO-178