ISO 26262 : sécurité fonctionnelle automobile

Auteur Hugues Orgitello Mis à jour le 3 juillet 2026 ~13 min de lecture

Guide · ISO 26262

ISO 26262 est la norme internationale horizontale de sécurité fonctionnelle (Functional Safety, FuSa) appliquée aux systèmes électriques et électroniques des vehicules routiers. Publiée initialement en 2011 et révisée en 2018 (2e édition), elle est aujourd'hui la reference unanimement utilisée par les constructeurs automobiles (OEM) et leurs équipementiers (Tier 1, Tier 2) pour structurer la maitrise des dysfonctionnements électroniques susceptibles d'entraîner des situations dangereuses. Cette page expose la genèse de la norme, son articulation avec la norme générique mère IEC 61508 et avec ses normes soeurs (SOTIF ISO 21448, cybersécurité ISO/SAE 21434), la structure en dix parties, le mécanisme de classification ASIL, le cycle de vie de sécurité, la notion de Safety Element out of Context, et les mesures de confirmation requises.

Une dérivée sectorielle d'IEC 61508

ISO 26262 n'est pas un texte isole. Elle est l'une des principales dérivées sectorielles d'IEC 61508 (Functional safety of electrical/electronic/programmable electronic safety-related systems), la norme générique de sécurité fonctionnelle publiée par la CEI. IEC 61508 fournit le cadre conceptuel commun (SIL, lifecycle, séparation défaillances aléatoires / systématiques), et chaque secteur en derive sa norme adaptée : ISO 26262 pour l'automobile, IEC 61511 pour les industries de procede, EN 50128 / EN 50657 pour le ferroviaire embarque, DO-178C pour le logiciel d'aviation civile (sous l'angle de l'autorité FAA / EASA), IEC 62061 pour la machine.

Le passage de la base générique IEC 61508 a la version automobile ISO 26262 traduit plusieurs adaptations propres au secteur :

• une échelle de risque spécifique (ASIL A a D) calibrée sur les scenarios vehicule, et non sur la fréquence et la probabilité d'erreur typiques de l'industrie de procede,
• l'introduction explicite de la HARA comme entrée obligatoire du concept de sécurité, alors qu'IEC 61508 reste plus abstraite sur la méthode d'analyse de risque amont,
• la prise en compte structurelle de la chaine d'approvisionnement automobile, OEM, Tier 1, Tier 2, avec des livrables d'interface formalises (Hardware-Software Interface, Development Interface Agreement, Safety Manual),
• la reconnaissance des défaillances aléatoires permanentes et transitoires des semi-conducteurs comme un sujet de premier plan,
• une prise en compte du logiciel embarque plus intégrée, complémentaire mais pas redondante avec d'autres normes logiciel.

La 1re édition de 2011 couvrait les voitures particulières et les vehicules légers jusqu'a 3,5 tonnes. La 2e édition de 2018 a étendu le périmètre aux camions, bus et autocars. La 2e édition est aujourd'hui la reference unique.

Les dix parties d'ISO 26262

ISO 26262 est découpée en dix parties publiées ensemble, chacune ciblant un périmètre du cycle de vie ou un type d'analyse. Le numéro de partie est explicite dans les references croisées au sein du dossier de sécurité.

Partie	Titre	Contenu indicatif
Part 1	Vocabulary	Vocabulaire, définitions, acronymes ; base terminologique commune (ASIL, item, élément, fault, error, failure, HARA, FSC, TSC, SEooC, etc.)
Part 2	Management of functional safety	Gestion de la sécurité a l'échelle de l'organisation et du projet ; rôles (Functional Safety Manager, Functional Safety Assessor), Safety Culture, planification, livrables, mesures de confirmation
Part 3	Concept phase	Definition de l'item (item définition), Hazard Analysis and Risk Assessment (HARA), Safety Goals, Functional Safety Concept (FSC)
Part 4	System level	Specification de la sécurité au niveau système, Technical Safety Concept (TSC), exigences techniques de sécurité, intégration et essais système, validation par rapport aux Safety Goals
Part 5	Hardware level	Exigences matérielles, analyse quantitative des défaillances aléatoires (PMHF, SPFM, LFM), Hardware Safety Requirements, intégration et essais matériel
Part 6	Software level	Exigences logicielles, architecture logicielle, conception, verification, intégration et essais logiciel ; tables de techniques recommandées par ASIL
Part 7	Production, opération, service and decommissioning	Production en serie sous controle de sécurité, maintenance, mise hors service ; lien avec IATF 16949 (qualité)
Part 8	Supporting processes	Processus transverses, gestion des exigences, configuration, modification, documentation, qualification d'outils logiciel (Tool Confidence Level), qualification de composants logiciel et matériel, critères d'intégration de composants prequalifies
Part 9	Automotive safety integrity level (ASIL)-oriented and safety-oriented analyses	Decomposition d'ASIL, analyse des défaillances de cause commune et des dépendances, critères de coexistence d'éléments de criticité différente sur un même calculateur
Part 10	Guideline on ISO 26262	Lignes directrices, exemples d'application, notamment cadre du Safety Element out of Context (SEooC)

Les Parties 3 a 7 forment la colonne vertébrale du cycle en V de sécurité. La Partie 8 contient des chapitres transverses très fréquemment cites (qualification des outils, qualification des composants prequalifies). Les Parties 9 et 10 sont des annexes thematiques.

La classification ASIL (S, E, C)

ASIL designe Automotive Safety Integrity Level. Quatre niveaux croissants sont définis (A, B, C, D), plus une catégorie QM (Quality Managed) pour les scenarios qui n'imposent pas d'exigence de sécurité fonctionnelle au sens de la norme et restent geres au titre de la qualité (IATF 16949).

Le niveau ASIL d'un Safety Goal resulte du croisement, au sein de la HARA, de trois parametres indépendants.

Parametre	Sigles	Interpretation
Severite	S0, S1, S2, S3	Severite des conséquences potentielles, des aucune lésion (S0) a des lésions vitales mortelles ou critiques (S3)
Exposition	E0, E1, E2, E3, E4	Probabilite que le scenario opérationnel se presente, de incredible (E0) a très fréquent (E4)
Controlabilite	C0, C1, C2, C3	Capacite du conducteur (ou d'un tiers concerne) a contrôler la situation dangereuse et éviter le dommage, de très contrôlable (C0) a difficile a contrôler (C3)

Le croisement est tabule dans la Partie 3, annexe ASIL détermination table. Les combinaisons donnant un risque très faible aboutissent a QM ; les combinaisons cumulant sévérité, exposition et faible controlabilite aboutissent a ASIL D.

Severite	Exposition	C1	C2	C3
S1	E1	QM	QM	QM
S1	E2	QM	QM	QM
S1	E3	QM	QM	A
S1	E4	QM	A	B
S2	E1	QM	QM	QM
S2	E2	QM	QM	A
S2	E3	QM	A	B
S2	E4	A	B	C
S3	E1	QM	QM	A
S3	E2	QM	A	B
S3	E3	A	B	C
S3	E4	B	C	D

Cette table de la Partie 3 est, en pratique, le passage le plus repete d'ISO 26262 dans la littérature pedagogique. Elle merite d'être lue avec deux précautions : (1) les classes S, E, C sont des classes définies par la norme, leur attribution s'appuie sur des exemples normatifs mais reste sujette a interprétation et doit être justifiée documentairement ; (2) la cotation se fait par scenario, pas par item global, un même item pouvant porter des Safety Goals d'ASIL différents selon les dangers analyses.

La décomposition d'ASIL

La Partie 9 introduit le mécanisme de décomposition d'ASIL. Un exigence de niveau eleve peut être dérivée en deux exigences de niveau inférieur portées par des éléments suffisamment indépendants, par redondance et séparation de cause commune. Les décompositions admises sont notées sous la forme ASIL X (Y) avec, par exemple :

• ASIL D peut être decompose en ASIL B (D) + ASIL B (D), ou en ASIL C (D) + ASIL A (D), ou en ASIL D (D) + ASIL QM (D),
• ASIL C peut être decompose en ASIL B (C) + ASIL A (C), ou en ASIL C (C) + QM (C),
• et ainsi de suite jusqu'au niveau ASIL A.

La décomposition n'est pas une diminution gratuite de la rigueur. Elle est conditionnée a une démonstration formelle d'indépendance entre les éléments decomposants (absence de défaillances de cause commune, séparation physique et logique, qualification indépendante). En pratique, la décomposition est utilisée pour rendre réaliste la conception d'un Safety Goal ASIL D en s'appuyant sur deux canaux ASIL B indépendants, par exemple un canal de commande et un canal de surveillance.

Le cycle de vie de sécurité

ISO 26262 organise le cycle de vie produit en phases formellement enchainees. La structure est conforme au cycle en V utilise dans la plupart des normes de sécurité fonctionnelle. Le séquencement type, simplifie ici, comporte les étapes suivantes.

1. Definition de l'item (Item Definition, Partie 3). Description fonctionnelle, frontières, interfaces, environnement opérationnel, hypothèses d'usage.
2. HARA (Partie 3). Identification des dangers, scenarios, cotation S/E/C, dérivation des Safety Goals et de leur ASIL.
3. Functional Safety Concept (FSC, Partie 3). Stratégie de sécurité au niveau fonctionnel, dérivation des Functional Safety Requirements (FSR), allocation aux éléments (calculateurs, capteurs, actionneurs).
4. Technical Safety Concept (TSC, Partie 4). Spécification technique des exigences de sécurité (TSR), architecture système, allocation matérielle et logicielle, définition de la Hardware-Software Interface (HSI agreement).
5. Developpement matériel (Partie 5). Conception, analyse quantitative des défaillances aléatoires (calcul PMHF, métriques SPFM et LFM), verification, intégration matériel.
6. Developpement logiciel (Partie 6). Spécification, architecture, conception détaillée, codage, verification et intégration logiciel ; choix des techniques en fonction de l'ASIL.
7. Integration système (Partie 4). Intégration progressive, verification de la conformité aux TSR et FSR, essais de validation au niveau système.
8. Validation au niveau item (Partie 4). Démonstration que les Safety Goals sont respectes dans l'environnement vehicule cible.
9. Production et exploitation (Partie 7). Lancement serie sous controle de sécurité ; coordination avec le système qualité IATF 16949.
10. Maintenance, modification, retrait (Partie 7 et Partie 8). Gestion des modifications, releases logicielles, retrait controle.

Chaque phase produit des work products (livrables) explicitement nommes par la norme. Le dossier de sécurité (Safety Case) consolide l'ensemble des work products et la chaine d'arguments démontrant que le risque résiduel est acceptable. Le Safety Case n'est pas un document final ajoute en bout de chaine, il est construit en parallèle tout au long du projet.

Safety Element out of Context (SEooC)

Le concept de SEooC (Safety Element out of Context) est décrit en Partie 10. Il répond a une réalité économique du secteur : un fournisseur de semi-conducteur ou d'un RTOS ne developpe pas son composant pour un projet vehicule précis, mais pour un marche. Il ne peut donc pas, par construction, suivre la HARA d'un item dont il ignore les details.

La Partie 10 organise le mécanisme suivant :

• le fournisseur formule des hypothèses sur l'usage cible (Assumed Use Case) et un ASIL vise (par exemple un MCU SEooC ASIL B ou ASIL D),
• il developpe l'élément en suivant les exigences correspondantes des Parties 4, 5 et 6 sous ces hypothèses,
• il fournit un Safety Manual décrivant les hypothèses, les mécanismes de sécurité implémentés, les contraintes d'intégration, les diagnostics couverts, les métriques matérielles obtenues,
• l'intégrateur (typiquement le Tier 1 qui livre un calculateur a l'OEM) verifie au moment de l'intégration que les hypothèses du SEooC restent valides pour l'item réel et derive ses propres exigences de sécurité a partir du Safety Manual.

Le mécanisme SEooC est aujourd'hui un standard de fait pour les MCU, SoC et bibliothèques logicielles certifiées du marche automobile. Sa correcte utilisation suppose une lecture attentive du Safety Manual, en particulier des assumptions et des conditions d'usage, dont la violation invalide l'argument de sécurité.

ISO 26262 face a ses normes soeurs

Plusieurs normes voisines, fréquemment citées ensemble, doivent être distinguées pour éviter les confusions.

Norme	Champ	Articulation avec ISO 26262
IEC 61508	Securite fonctionnelle générique (SIL 1 a 4)	Norme mère générique ; ISO 26262 en est la dérivée automobile. Le mapping ASIL / SIL n'est pas mathématique, doit être justifie projet par projet.
ISO 21448	SOTIF, Safety Of The Intended Functionality	Norme soeur, traite des limitations de la fonction prévue (limites des capteurs, cas non prévus en conception) ; cible en particulier les ADAS et la conduite automatisée. Complémentaire et non redondante.
ISO/SAE 21434	Cybersecurite vehicule	Norme soeur, traite de la cybersécurité vehicule. Alimente la conformité UN-ECE R155 et R156. Necessite une coordination explicite avec l'equipe FuSa lorsque la menace cyber peut entraîner une conséquence de sécurité.
IATF 16949	Qualite, automobile	Systeme de management qualité spécifique automobile (derive d'ISO 9001). ISO 26262 et IATF 16949 sont complémentaires : la qualité cible la conformité repetable, la sécurité fonctionnelle cible la maitrise du risque. La Partie 7 d'ISO 26262 fait le lien avec la production serie.

A ces normes s'ajoutent les règlements UN-ECE (sous l'égide du Forum WP.29 de la CEE-ONU), juridiquement contraignants en homologation, en particulier :

• R155 sur la gestion de la cybersécurité vehicule (CSMS),
• R156 sur la gestion des mises a jour logicielles (SUMS),
• l'ensemble R157 sur les systèmes ALKS (Automated Lane Keeping Systems).

Cote Union européenne, le règlement (UE) 2019/2144 (Général Safety Regulation, GSR) impose un ensemble de fonctions de sécurité obligatoires sur les nouveaux vehicules immatricules dans l'UE (assistance intelligente a la vitesse, freinage d'urgence autonome, surveillance d'angle mort, etc.), dont la conception sous-jacente releve typiquement d'ISO 26262. Le GSR ne cite pas ISO 26262 comme norme harmonisée au sens du marquage CE, le cadre d'homologation des vehicules reposant sur le règlement type-approval (UE) 2018/858 et sur les règlements UN-ECE plutôt que sur le mécanisme de marquage CE.

La chaine d'approvisionnement automobile

ISO 26262 reconnaît formellement l'organisation industrielle du secteur, structurée en trois niveaux principaux. Cette structure conditionne la distribution des livrables.

• L'OEM (constructeur vehicule) porte la responsabilité globale du vehicule et de l'item integre. Il realise la HARA et fixe les Safety Goals et ASIL. Il peut sous-traiter l'item, integre les livraisons et porte le Safety Case final.
• Le Tier 1 (équipementier de rang 1) reçoit du OEM les Safety Goals et les Functional Safety Requirements, et livre un sous-système ou un calculateur complet (ECU). Il porte le Technical Safety Concept et derive les exigences vers ses fournisseurs.
• Le Tier 2 (composant) livre typiquement un semi-conducteur, un RTOS, un bibliothèque logicielle, généralement sous forme de SEooC. Il livre un Safety Manual et les métriques associees.

Plusieurs livrables d'interface formalisent les echanges entre niveaux, dont les principaux sont :

• le Development Interface Agreement (DIA) qui repartit responsabilités et activités entre les parties,
• la HSI Agreement (Hardware-Software Interface) qui fige le contrat entre l'equipe hardware et l'equipe software d'un même élément,
• le Safety Manual du SEooC, comme décrit plus haut.

Sur des programmes récents, l'OEM developpe parfois son propre calculateur (in-house), ce qui efface temporairement la séparation OEM / Tier 1 sans annuler la logique de DIA, formalisée alors entre equipes internes.

Les mesures de confirmation

La Partie 2 d'ISO 26262 définit trois mesures de confirmation cumulatives, dont l'application est exigée a partir de certains ASIL et selon des niveaux d'indépendance graduellement renforces (I0, I1, I2, I3).

• Confirmation Review. Revue de confirmation d'un livrable spécifique (HARA, FSC, TSC, etc.) par une personne qualifiée indépendante de l'auteur. L'objectif est de vérifier que le livrable satisfait son intention et les exigences de la norme. L'indépendance attendue varie selon l'ASIL : pour ASIL D, l'organisation requiert une indépendance organisationnelle (I3).
• Functional Safety Audit. Audit de l'application effective des processus de sécurité définis dans le Safety Plan. L'audit verifie le "comment on fait", pas le "ce qu'on a fait". Realise par un auditeur indépendant du projet.
• Functional Safety Assessment (FSA). Evaluation globale du caractère suffisant de la démonstration de sécurité, généralement en fin de phase ou de programme. Le Functional Safety Assessor (assesseur de sécurité fonctionnelle) est indépendant du projet et porte un jugement motive sur le Safety Case complet. Pour ASIL D, l'indépendance attendue est I3, c'est-a-dire une indépendance organisationnelle complete.

Ces trois mesures sont distinctes mais articulees. Une non-conformité identifiée lors d'une Confirmation Review se traite en local ; une non-conformité récurrente identifiée lors d'un audit peut déclencher une remédiation processus ; un FSA négatif en fin de programme empeche la libération pour production serie.

Couplages avec d'autres pages

ISO 26262 ne se substitue pas au cadre réglementaire général. Plusieurs articulations sont pertinentes :

• pour le cadre du marquage CE des produits électroniques non-vehicule (radio, EMC, cyber), voir la page CE ;
• pour le calendrier projet et la combinaison des étapes de certification, voir le calendrier de certification ;
• pour le glossaire complet des termes utilises (ASIL, HARA, SEooC, Safety Goal, FSC, TSC, FSA), voir le glossaire.

Voir aussi

• Recharge VE : conformité IEC 61851, ISO 15118 et OCPP
• EN 50128 et EN 50657 : logiciel ferroviaire
• DO-178C et DO-254 : logiciel + matériel avionique
• DO-326A et ED-202A: cybersécurité avionique

Un cas concret de le cadrage normatif amont d'un projet electronique automobile ? AESTECHNO peut auditer votre conception et votre plan de certification. Nous contacter →

Quelques écueils observes

Sans constituer un guide d'implémentation, plusieurs erreurs reviennent dans les retours de programmes :

• Confondre ASIL et SIL. Le mapping IEC 61508 / ISO 26262 n'est pas mathématique. Importer un composant "SIL 2" d'un projet industriel et le considérer ASIL B sans analyse de transfert est une approximation risquee.
• HARA decoree. La HARA n'est pas un livrable de conformité, elle est l'entrée du concept. Une HARA réalisée en fin de projet pour caler les ASIL sur la conception déjà figée est l'erreur amont la plus courante.
• SEooC mal integre. Reutiliser un MCU SEooC ASIL D sans relire le Safety Manual ni vérifier la validité des assumptions d'usage est une cause frequente de non-conformité a l'intégration. Le Safety Manual fait partie du dossier de sécurité de l'intégrateur.
• Decomposition d'ASIL sans démonstration d'indépendance. Une décomposition n'est valable que si l'indépendance des éléments est démontrée (séparation physique, séparation logique, absence de cause commune). Une décomposition revendiquée sans démonstration ne sera pas acceptée par un FSA serieux.
• Confusion FuSa / SOTIF. Une limite capteur en conditions dégradées (brouillard, contre-jour) n'est pas un dysfonctionnement au sens d'ISO 26262. Elle releve d'ISO 21448 (SOTIF). Tenter d'encoder un cas SOTIF en Safety Goal ISO 26262 conduit a des résultats qui ne tiennent pas.
• Confusion FuSa / cybersécurité. Une menace cyber qui peut entraîner une conséquence de sécurité doit être traitée a la fois sous ISO/SAE 21434 (périmètre menace, ETS, traitement du risque cyber) et sous ISO 26262 (conséquence de sécurité, Safety Goal). La coordination entre les deux equipes est explicitement attendue par les deux normes.
• Confusion FuSa / qualité (IATF 16949). La conformité qualité ne dispense pas de la sécurité fonctionnelle, et inversement. Les deux systèmes coexistent et se référencent mutuellement (Partie 7 d'ISO 26262, lien avec IATF 16949).

Pour aller plus loin

Cette page expose le cadre général d'ISO 26262. Plusieurs sujets méritent des pages dédiées :

• la HARA pas a pas, avec exemples de cotation S/E/C documentes,
• la métrique matérielle ASIL (PMHF, SPFM, LFM) et son calcul concret,
• ISO 21448 (SOTIF) et son articulation avec les ADAS et la conduite automatisée,
• ISO/SAE 21434 et les règlements UN-ECE R155 / R156, sous l'angle de l'homologation,
• la qualification d'outils logiciel (Tool Confidence Level) au sens de la Partie 8.

Sources & références

1. ISO 26262:2018, Road vehicles, Functional safety , ISO www.iso.org/standard/68383.html
2. ISO 21448:2022, Road vehicles, Safety of the intended functionality , ISO www.iso.org/standard/77490.html
3. ISO/SAE 21434:2021, Road vehicles, Cybersecurity engineering , ISO www.iso.org/standard/70918.html
4. UN-ECE WP.29, vehicle regulations including R155 and R156 , UNECE unece.org/transport/vehicle-regulations
5. Règlement (UE) 2019/2144 (Général Safety Regulation, GSR) , EUR-Lex eur-lex.europa.eu/eli/reg/2019/2144/oj
6. IEC 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems , IEC webstore.iec.ch/publication/22273