Le contexte — quand l’électronique tient le volant
Une voiture moderne, ce sont plus d’une centaine de calculateurs qui commandent le freinage, la direction assistée, la transmission, et désormais l’assistance à la conduite. Quand l’électronique décide, une défaillance ne fait plus caler le moteur : elle peut tuer.
L’affaire des accélérations involontaires Toyota, autour de 2009-2010, a cristallisé la question — non pas tant par sa cause réelle (largement attribuée à des tapis et pédales) que par celle qu’elle a posée à toute l’industrie : comment prouver qu’un système de commande électronique est sûr ? ISO 26262, publiée en 2011, est la réponse normative : adapter la sécurité fonctionnelle au monde automobile, où le volume, le coût et la variabilité d’usage changent les règles.
ISO 26262 : l’IEC 61508 de l’automobile
ISO 26262 — « Véhicules routiers — Sécurité fonctionnelle » — est la déclinaison automobile de l’IEC 61508. Elle couvre les systèmes électriques et électroniques (E/E) des véhicules de série. Sa première édition date de 2011 ; la deuxième (2018) a élargi le périmètre aux poids lourds, bus et deux-roues motorisés, et ajouté une partie dédiée aux semi-conducteurs.
Comme toute la famille 61508, elle repose sur un cycle de vie de sécurité, mais avec un vocabulaire et des métriques propres au domaine.
ASIL : l’échelle, déterminée par le risque
Là où le procédé parle SIL et les machines PL, l’automobile parle ASIL — Automotive Safety Integrity Level : QM (quality managed, pas d’exigence de sécurité), puis A, B, C, D (le plus exigeant).
L’ASIL ne se choisit pas, il se détermine par l’analyse HARA (Hazard Analysis and Risk Assessment), en combinant trois paramètres pour chaque situation dangereuse :
- Gravité (S0-S3) : de l’absence de blessure à des blessures mortelles ;
- Exposition (E0-E4) : la probabilité de se trouver dans la situation (autoroute pluvieuse, marche arrière…) ;
- Contrôlabilité (C0-C3) : la capacité du conducteur à éviter le dommage.
Le croisement des trois donne l’ASIL. Une situation grave (S3), fréquente (E4) et incontrôlable (C3) appelle l’ASIL D.
Le cycle en V et le dossier de sécurité
ISO 26262 structure le développement en cycle en V : définition de l’item, HARA, concept de sécurité fonctionnelle, puis concept de sécurité technique, développement système / matériel / logiciel, et remontée par l’intégration, la vérification et la validation.
Le tout est consigné dans un safety case (dossier de sécurité) qui argumente que l’item est sûr. Spécificité automobile : les mesures de confirmation — revues de confirmation, audit de sécurité fonctionnelle, et évaluation (assessment) — avec des degrés d’indépendance croissants selon l’ASIL. Plus l’ASIL est élevé, plus l’évaluateur doit être indépendant de l’équipe de conception.
Les concepts propres à l’automobile
Quatre notions structurent la pratique :
- Décomposition ASIL : répartir une exigence ASIL D sur deux éléments indépendants de niveau inférieur (par ex. ASIL B(D) + ASIL B(D)), à condition de prouver leur indépendance. Cela rend atteignable ce qui serait trop coûteux d’un seul bloc.
- SEooC (Safety Element out of Context) : développer un composant sans véhicule cible précis, sur la base d’hypothèses d’usage, qu’un intégrateur validera ensuite. C’est le modèle des fournisseurs de rang 1.
- FTTI (Fault Tolerant Time Interval) : le temps entre l’apparition d’un défaut et le dommage. La détection du défaut et le passage en état sûr doivent tenir dans cette fenêtre.
- Métriques matériel : l’automobile ne mesure pas la PFD mais des taux de couverture et une probabilité horaire.
| Métrique | ASIL B | ASIL C | ASIL D |
|---|---|---|---|
| SPFM (défauts à point unique couverts) | ≥ 90 % | ≥ 97 % | ≥ 99 % |
| LFM (défauts latents couverts) | ≥ 60 % | ≥ 80 % | ≥ 90 % |
| PMHF (défaillance dangereuse/heure) | < 10⁻⁷ | < 10⁻⁷ | < 10⁻⁸ |
Les calculateurs réduction de risque vers SIL et taux de défaillance vers MTBF restent utiles pour raisonner en ordres de grandeur.
SOTIF (ISO 21448) : quand la fonction « marche » mais ne suffit pas
ISO 26262 traite les défaillances : un composant tombe en panne. Mais l’ADAS et la conduite autonome posent un autre problème : le système fonctionne exactement comme conçu, et c’est la conception elle-même qui est insuffisante — une caméra qui ne reconnaît pas un piéton à contre-jour, un radar trompé par un reflet. Aucune panne, mais un danger.
C’est l’objet de SOTIF — ISO 21448 (Safety Of The Intended Functionality) : la sécurité de la fonction voulue, face aux limites de performance et aux usages détournés prévisibles. Pour un véhicule autonome, SOTIF est au moins aussi critique qu’ISO 26262 : on ne peut plus tout ramener à une panne. Les deux normes se complètent.
Cybersécurité : ISO/SAE 21434
Un véhicule connecté est attaquable, et une attaque peut devenir un danger physique. ISO/SAE 21434 est le pendant cybersécurité d’ISO 26262 — Road vehicles — Cybersecurity engineering. Sécurité fonctionnelle, SOTIF et cybersécurité forment désormais un triptyque indissociable du développement véhicule.
Les enjeux
L’enjeu humain est direct : freinage, direction, ADAS — la défaillance se mesure en vies.
L’enjeu industriel est l’échelle : un défaut systématique se réplique sur des millions de véhicules ; un rappel coûte des centaines de millions. La rigueur du processus n’est pas un luxe, c’est une assurance.
L’enjeu réglementaire monte avec l’autonomie : homologation, responsabilité, et un cadre (dont l’EU AI Act pour les fonctions d’IA) qui se durcit.
Les erreurs à ne pas faire
| Erreur | Pourquoi on la commet | Pourquoi c’est dangereux |
|---|---|---|
| Croire qu’ISO 26262 couvre l’ADAS à lui seul | C’est LA norme de sécu auto | 26262 traite les pannes, pas l’insuffisance fonctionnelle — il faut SOTIF (21448) |
| Décomposer en ASIL sans prouver l’indépendance | Réduire le coût d’un ASIL D | Sans indépendance réelle, une cause commune ruine la décomposition |
| Traiter un SEooC sans vérifier les hypothèses | Réutiliser un composant « déjà sûr » | Les hypothèses d’usage du fournisseur peuvent ne pas tenir dans votre véhicule |
| Oublier le FTTI | On détecte le défaut… trop tard | Une détection plus lente que la fenêtre de tolérance ne protège pas |
| Séparer sécurité et cybersécurité | Deux équipes, deux mondes | Une faille cyber peut déclencher le danger que la sécu fonctionnelle visait à empêcher |
Les bonnes pratiques
Mener un HARA rigoureux par situation, et en déduire l’ASIL — ne pas le « choisir » par habitude.
Traiter ensemble ISO 26262 (pannes), SOTIF (insuffisance fonctionnelle) et ISO/SAE 21434 (cyber), surtout pour l’ADAS et l’autonome.
Justifier toute décomposition ASIL par une indépendance démontrée.
Vérifier les hypothèses d’un SEooC dans le contexte réel d’intégration.
Dimensionner la détection de défaut et le passage en état sûr pour tenir dans le FTTI.
Documenter un safety case argumenté et organiser les mesures de confirmation avec l’indépendance requise par l’ASIL.
Checklist de revue
- Définition de l’item claire et bornée
- HARA documenté (S, E, C) et ASIL déterminé par fonction
- Concepts de sécurité fonctionnelle puis technique tracés
- Décomposition ASIL justifiée par une indépendance prouvée
- Hypothèses SEooC vérifiées au niveau intégration
- Métriques matériel atteintes (SPFM, LFM, PMHF) pour l’ASIL visé
- FTTI couvert par détection + état sûr
- SOTIF (ISO 21448) traité pour les fonctions ADAS/autonomes
- Cybersécurité (ISO/SAE 21434) intégrée
- Safety case et mesures de confirmation avec indépendance adéquate
Pour aller plus loin
- La fiche ISO 26262 et la norme mère IEC 61508.
- Les autres variantes : IEC 61511 — procédés et IEC 62061 & ISO 13849 — machines, sur le socle IEC 61508.
- Les calculateurs réduction de risque vers SIL et taux de défaillance vers MTBF.
Une dernière chose. L’automobile a poussé la sécurité fonctionnelle à l’échelle de masse, puis l’a obligée à se dépasser : avec l’autonomie, prouver qu’un système ne tombe pas en panne ne suffit plus — il faut prouver que, même en marchant parfaitement, il fait ce qu’il faut. C’est tout le saut d’ISO 26262 vers SOTIF, et le vrai défi de la décennie.