DO-178C, IEC 62304, ISO 26262 : pourquoi les outils ne suffisent pas

Le débat, en une phrase

Les éditeurs d'outils ont largement structuré le discours sur la certification logicielle : acheter la bonne suite de vérification, et la conformité suivrait. Or un outil ne produit pas une preuve de conformité. La traçabilité exigence → code → test, la justification des choix d'architecture et la maîtrise du code existant restent un travail d'ingénierie.

C'est le constat que nous faisons chez PointerLab sur des projets C++ et Qt soumis à des référentiels exigeants. Cet article le documente avec des sources publiques.

1. Pourquoi la question se pose : ce que disent les chiffres

Le logiciel est devenu l'une des premières causes de défaillance des dispositifs critiques. Quelques repères publics, datés et sourcés :

Ces chiffres concernent le médical parce que les données de rappel y sont publiques. Ils illustrent un point général : plus les systèmes embarquent de logiciel, plus la conformité logicielle devient un sujet de sécurité à part entière, et plus les régulateurs et les auditeurs attendent des preuves solides.

Note méthodologique : les périmètres et les méthodes de comptage diffèrent d'une étude à l'autre (période, définition de « logiciel », source). Ces chiffres ne sont pas additionnables ; ils indiquent un ordre de grandeur.

2. Trois normes, une même logique : la criticité détermine la preuve

Que vous développiez un calculateur de bord, un dispositif médical ou un composant automobile, la logique est la même : plus la défaillance est grave, plus la démonstration doit être rigoureuse.

DO-178C : jusqu'à 71 objectifs

La DO-178C a été publiée en décembre 2011 (RTCA/EUROCAE). Le niveau de logiciel (DAL) est déterminé par le processus d'évaluation de la sécurité du système, qui précède l'application de la norme (Wikipedia). Le nombre d'objectifs à satisfaire en découle, tel que le rapportent plusieurs synthèses de l'Annexe A de la norme (Tonex) :

Les exigences de couverture par niveau sont détaillées dans la synthèse de Rapita Systems. La traçabilité bidirectionnelle entre exigences, conception, code, tests, résultats et rapports de problèmes est, elle, obligatoire (arc42 Quality).

À noter : les nombres d'objectifs sont ceux de l'Annexe A de la DO-178C, repris ici d'après des synthèses secondaires. La norme elle-même est payante : pour un dossier de certification, référez-vous au document RTCA d'origine.

IEC 62304 : trois classes, et le legacy dans la norme depuis 2015

L'IEC 62304 définit le cycle de vie du logiciel de dispositif médical. Son Amendement 1, publié en juin 2015, a réécrit la règle de classification de sécurité (clause 4.3) vers une approche fondée sur le risque, et a ajouté une clause 4.4 dédiée au logiciel hérité (legacy software) (synthèse CASRAI ; sommaire de l'édition 1.1, ANSI). L'amendement permet aussi de classer au niveau des éléments logiciels et pas seulement du système entier (MedDeviceGuide), ce qui autorise une ségrégation de l'architecture : une décision de conception, donc d'ingénierie.

ISO 26262 : des méthodes graduées par ASIL

La partie 6 de l'ISO 26262 couvre le développement au niveau logiciel, avec des méthodes recommandées ou fortement recommandées selon l'ASIL. Pour la couverture de code, le MC/DC est fortement recommandé à l'ASIL D et recommandé aux niveaux inférieurs (clause 9.4.4 de la partie 6) ; l'analyse statique est fortement recommandée aux ASIL B, C et D (Verifysoft ; Qt Quality Assurance).

Point clé : aucune de ces trois normes ne dit « utilisez tel produit ». Elles demandent de démontrer que le logiciel fait ce qu'il doit et que vous pouvez le prouver. Cette démonstration est un livrable, pas une fonctionnalité d'outil.

3. Ce que les outils font bien

Soyons clairs : sans outils, la vérification d'un projet réel est intenable. Ils apportent :

• L'analyse statique : contrôle de règles de codage. Pour le C++, la référence a évolué : MISRA C++:2023, publié en octobre 2023, remplace MISRA C++:2008 et succède aux lignes directrices AUTOSAR C++14 (Perforce). Il compte 179 lignes directrices (175 règles et 4 directives) pour C++17 (All About Industries ; site MISRA).
• La mesure de couverture : instructions, décisions, MC/DC. Le MC/DC exige que chaque condition d'une décision influence indépendamment son résultat (Qt Quality Assurance).
• L'automatisation des tests et la production de rapports.
• La gestion des exigences et la modélisation.

Les outils actuels supportent d'ailleurs bien MISRA C++:2023 (par exemple MathWorks Polyspace ou Parasoft C/C++test). Le problème n'est donc pas la qualité des outils, mais ce qu'on leur demande de prouver.

Un outil répond à la question : « le code respecte-t-il ces règles ? ». L'auditeur pose une autre question : « pourquoi ce logiciel est-il sûr ? ».

4. Ce qu'un outil ne produit pas

4.1 La traçabilité qui a du sens

Chaque exigence doit être reliée à son implémentation et à ses tests, et inversement. Un outil peut stocker ces liens. Il ne peut pas décider :

• qu'une exigence est bien décomposée (atomique, vérifiable, non ambiguë) ;
• qu'un test vérifie réellement l'exigence qu'il prétend couvrir ;
• que le code ne contient rien d'orphelin ou de non exigé.

Une matrice de traçabilité remplie automatiquement mais sémantiquement fausse est pire qu'une matrice incomplète : elle donne une fausse assurance. Et en DO-178C, la couverture structurelle ne remplace pas les tests dérivés des exigences : elle sert à détecter ce que ces tests n'ont pas exercé, ce qui suppose des tests de qualité en amont.

4.2 La justification des choix d'architecture

Pourquoi ce partitionnement ? Pourquoi cette gestion de la mémoire, ce modèle de tâches, cette stratégie d'erreur ? Les référentiels attendent des décisions argumentées : isolation des fonctions critiques, maîtrise du déterminisme, limitation de la complexité.

Un exemple concret côté Qt : le Qt Safe Renderer est un composant d'affichage certifié par TÜV NORD pour l'ISO 26262 (ASIL D), l'IEC 61508 (SIL 3) et l'IEC 62304 (classe C), qui isole les éléments d'interface critiques dans un sous-système indépendant (Qt Group). C'est précieux. Mais la certification porte sur ce composant ; décider quels éléments d'IHM sont critiques, comment les isoler du reste, comment le prouver dans votre architecture et votre analyse de risques reste de votre côté du dossier.

4.3 La qualification de l'outil lui-même

Paradoxe : l'outil de vérification peut devoir être lui-même qualifié. Choisir un outil, c'est accepter une charge de justification.

DO-178C / DO-330. La DO-330 définit cinq niveaux de qualification d'outil (TQL-1 à TQL-5). Le niveau dépend de l'impact possible d'une erreur de l'outil et du DAL du logiciel : TQL-1, le plus élevé, concerne les outils pouvant insérer une erreur dans un logiciel de niveau A ; TQL-5, le plus bas, ceux qui ne peuvent qu'omettre de détecter une erreur (AdaCore). Pour un logiciel de niveau A, le critère « l'outil peut insérer une erreur » mène au TQL-1, le critère « l'outil automatise la vérification » au TQL-4 (matrice DO-178C, SoS-VO).

ISO 26262-8, clause 11. Le niveau de confiance de l'outil (TCL) découle de deux paramètres : l'impact de l'outil (TI) et la capacité à détecter ses erreurs (TD). TCL 1 n'exige pas de qualification ; TCL 2 et 3 l'exigent, avec quatre méthodes possibles dont l'intensité dépend de l'ASIL (itemis ; Bagnara, Univ. Roma). Détail important : le TI, le TD et donc le TCL dépendent du cas d'usage précis de l'outil dans votre projet (OneSpin / Semiconductor Engineering). Un « kit de qualification » du fournisseur ne dispense donc pas de votre propre analyse d'usage.

IEC 62304. Les composants tiers sont gérés comme SOUP (software of unknown provenance), avec leurs obligations propres (MedDeviceGuide).

Les éditeurs le reconnaissent d'ailleurs : la qualification DO-330 est décrite par certains comme un processus complexe et long, d'où l'offre de kits dédiés (Parasoft, centre d'apprentissage DO-178C). Un kit réduit l'effort ; il ne le supprime pas.

5. Le legacy C++ : là où se joue la certification

La plupart des projets ne partent pas d'une page blanche. Ils héritent de dizaines ou centaines de milliers de lignes de C++, écrites avant que la certification ne devienne un sujet, avec des idiomes anciens, des dépendances Qt, peu de documentation et peu de tests.

Ce que révèle un scan : l'affaire Toyota comme étude de cas

L'ordre de grandeur de ce qu'un analyseur peut remonter sur un code hérité est illustré par un dossier public célèbre. Lors du procès Bookout c. Toyota (Oklahoma, 2013), l'expert Michael Barr (Barr Group) a témoigné sur le logiciel de contrôle moteur. Selon ses analyses et celles de la NASA, rapportées dans les documents d'expertise :

• l'analyse de la NASA, sur 35 règles MISRA-C vérifiées et sur la partie du code accessible, a relevé 7 134 violations ; Barr, en vérifiant le code contre MISRA-C:2004, en a relevé 81 514 (Safety Research & Strategies) ;
• 67 fonctions dépassaient une complexité cyclomatique de 50, seuil au-delà duquel une fonction est jugée difficilement testable ; la fonction d'angle du papillon atteignait 146 pour environ 1 300 lignes (EDN ; PVS-Studio) ;
• le code comptait plus de 10 000 variables globales (Safety Research & Strategies) ;
• la norme interne de Toyota n'avait retenu que 11 règles MISRA-C (EDN).

Précision : ce dossier concerne du C, pas du C++, et ces chiffres proviennent de témoignages d'experts dans un contentieux. Nous les citons pour une raison précise : montrer qu'un scan produit des dizaines de milliers d'alertes sur un vieux code, et que la violation de règles n'est qu'un symptôme. Les causes sont architecturales et processuelles (complexité, état global partagé, absence de revue et de suivi des défauts). Aucun outil ne les corrige.

Ce que demande réellement la remise en conformité

Lancer un analyseur est la première minute. Le travail commence ensuite :

1. Trier : séparer les défauts réels du bruit, hiérarchiser par risque.
2. Décider : refactorer, isoler ou justifier, composant par composant.
3. Reconstituer : exigences, conception, documentation manquantes.
4. Limiter le risque : suite de tests de non-régression avant toute modification.
5. Argumenter : constituer le dossier de preuve.

Les référentiels offrent des voies pour le code existant, mais toutes exigent un dossier argumenté :

• l'IEC 62304 traite explicitement le logiciel hérité (clause 4.4, depuis 2015). Le raisonnement dépend de la classe du dispositif et de celle du composant : si le dispositif et le legacy relèvent tous deux de la classe C, le traiter comme un SOUP peut ne pas suffire. Et si une modification touche le legacy, il ne peut plus être traité comme tel (Spyrosoft) ;
• l'ISO 26262 connaît le principe de l'usage éprouvé (partie 8), qui demande lui aussi des preuves (Cadence, à propos de la partie 8) ;
• en DO-178C, le crédit d'historique de service est possible mais encadré, et l'autorité de certification reste décisionnaire.

Et le C++ moderne ?

L'arrivée de MISRA C++:2023 (C++17) est une bonne nouvelle pour les projets modernes, mais elle crée un chantier de migration : tous les écarts ne se correspondent pas un à un entre MISRA C++:2008, AUTOSAR C++14 et MISRA C++:2023, et certaines règles sont plus strictes (Qt / Axivion). Migrer un historique de conformité demande de la méthode, pas seulement une nouvelle configuration d'outil.

6. Le piège de « l'achat d'abord »

Le scénario est classique :

1. une direction budgétise une suite d'outils ;
2. l'équipe passe des mois à l'installer et à la configurer ;
3. l'audit révèle que les lacunes sont ailleurs : exigences, architecture, preuves de vérification, qualification des outils.

L'outil automatise ce qui est déjà bien défini. Déployé avant que le processus ne soit clair, il industrialise le désordre. À l'inverse, un processus clair rend le choix d'outil presque trivial : on sait ce qu'il doit produire, à quel niveau de rigueur, et qui portera la qualification.

7. Notre approche chez PointerLab

Nous partons de la démonstration à produire, puis nous choisissons les outils qui la servent, pas l'inverse.

Notre positionnement est volontairement neutre vis-à-vis des éditeurs : nous travaillons avec les outils que vous avez déjà ou que votre contexte impose, et nous vous aidons à en tirer des preuves recevables. Notre expertise C++ et Qt nous place là où le legacy et les IHM critiques se rencontrent.

8. Checklist : sept questions avant d'acheter un outil

1. Avons-nous des exigences vérifiables et correctement décomposées ?
2. Connaissons-nous le niveau de criticité (DAL, classe, ASIL) de chaque composant ?
3. L'état de notre code legacy a-t-il été évalué, et par qui ?
4. L'outil devra-t-il être qualifié (TQL, TCL) et qui portera ce dossier ?
5. Le kit de qualification du fournisseur couvre-t-il notre cas d'usage précis ?
6. Avons-nous un jeu de règles de codage choisi (par exemple MISRA C++:2023) et une stratégie de migration depuis l'existant ?
7. Qui, dans l'équipe, saura défendre les preuves face à un auditeur ?

Si vous répondez « non » ou « on ne sait pas » à plusieurs de ces questions, le sujet n'est pas l'outil.

9. Questions fréquentes

Un outil « certifié » rend-il mon projet certifiable ? Non. Un outil « qualifié » ou « précertifié » réduit l'effort de qualification de l'outil lui-même. Le produit que vous développez doit toujours démontrer sa conformité. La qualification dépend de votre usage (itemis).

Peut-on certifier du C++ ? Oui, c'est pratiqué. Cela demande un sous-ensemble de langage maîtrisé (aujourd'hui MISRA C++:2023), une architecture déterministe et des preuves de vérification adaptées au niveau visé.

Le MC/DC est-il obligatoire ? En DO-178C, il l'est pour le DAL A (Wikipedia). En ISO 26262, il est fortement recommandé à l'ASIL D et recommandé aux niveaux inférieurs (Qt Quality Assurance).

Mon code existant doit-il être réécrit ? Pas nécessairement. Les référentiels prévoient des voies pour le logiciel préexistant, mais elles demandent un dossier argumenté. Une évaluation préalable permet de décider quoi garder, isoler ou refaire.

En résumé

Les outils sont nécessaires, jamais suffisants. La certification est une démonstration d'ingénierie : exigences, architecture, code, preuves, et une équipe capable de les défendre. C'est là que se joue la conformité à la DO-178C, à l'IEC 62304 ou à l'ISO 26262.

Vous préparez une certification ou héritez d'un code C++ critique ? Parlons-en : PointerLab vous aide à cadrer le périmètre, évaluer l'existant et construire un dossier de conformité solide.

Contacter PointerLab →

Sources

Normes et référentiels

• DO-178C, présentation et niveaux (Wikipedia) · Niveaux d'assurance et couverture (Rapita Systems) · Objectifs par niveau (Tonex)
• DO-330 et niveaux TQL (AdaCore) · Matrice TQL (SoS-VO)
• IEC 62304 Ed. 1.1, sommaire (ANSI) · Guide IEC 62304 (CASRAI) · Legacy et IEC 62304 (Spyrosoft)
• ISO 26262, partie 6 (Verifysoft) · Qualification d'outils ISO 26262 (itemis) · Tool confidence levels (Synopsys)
• MISRA C++:2023 (MISRA) · Introduction (Perforce) · Migration depuis 2008 / AUTOSAR (Qt)

Données de rappels et études de cas

• Alemzadeh et al., défaillances informatiques des dispositifs médicaux
• FDANews, 24 % des rappels 2011
• AuntMinnie, rappels de dispositifs de radiologie
• Becker's, index Stericycle T3 2018
• Toyota : synthèse du témoignage (Safety Research & Strategies) · EDN, « Toyota's killer firmware »

Outils et composants cités

• Qt Safe Renderer, sécurité fonctionnelle · MC/DC (Qt Quality Assurance)
• Polyspace, MISRA C++:2023 (MathWorks) · Parasoft, qualification DO-330