Automobile · Franchir la barre de sécurité et de validation pour l'IA que vous mettez en production

Un conducteur dort. La voiture roule à 70 mph sur une autoroute, au crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →épuscule. Un camion devant perd un matelas, qui tombe sur la voie. La fonction de conduite par IA dispose d'environ une seconde pour percevoir l'objet, le classifier, prédire sa trajectoire, planifier une manœuvre et exécuter un freinage ou un changement de voie. Si elle y parvient, personne ne le remarque. Si elle échoue, l'entreprise fait face à un décès, un rappel et un tribunal.

La vraie question pour toute équipe automobile qui livre de l'IA n'est pas « est-ce que ça marche en démo ? ». C'est « peut-on prouver que c'est assez sûr pour être vendu, immatriculé et défendu ? » Cette preuve porte un nom dans le secteur : l'homologation (l'approbation formelle qui vous autorise à vendre légalement un véhicule sur un marché), plus un safety case défendable.

Cette leçon parcourt les trois piliers que les équipes utilisent pour franchir cette barre.

Pilier 1 : ISO 26262 et la sécurité fonctionnelle

ISO 26262 est la norme internationale de sécurité fonctionnelle pour les véhicules routiers. La « sécurité fonctionnelle » signifie que le système se comporte de façon sûre même lorsqu'un composant tombe en panne. Pensez à un capteur qui meurt, à une puce qui inverse un bit, à un logiciel qui plante.

L'outil central est l'ASIL, l'Automotive Safety Integrity Level. Chaque danger est noté de A (le plus bas) à D (le plus élevé), selon trois facteurs :

• Sévérité : quelle est la gravité du dommage ?
• Exposition : à quelle fréquence le véhicule se trouve-t-il dans cette situation ?
• Contrôlabilité : un conducteur ou le système peut-il éviter le dommage ?

Une défaillance du brake-by-wire à vitesse autoroutière est ASIL D. Un plafonnier bloqué relève de la gestion qualité, sans aucune cotation de sécurité.

Voici la friction avec l'IA. ISO 26262 a été écrite pour des systèmes que l'on peut spécifier intégralement. Vous pouvez rédiger une exigence pour un algorithme d'antiblocage et tester chaque branche. Un réseau de neurones entraîné sur des millions d'images n'a pas de spécification aussi propre. Vous ne pouvez pas énumérer tout ce qu'il a appris.

Les équipes ne certifient donc pas le réseau lui-même selon la 26262 classique. Elles l'enveloppent dans une architecture qu'elles *peuvent* certifier :

• Un moniteur de sécurité redondant, à base de règles, qui prend la main sur l'IA si elle commande quelque chose de dangereux.
• Une « enveloppe de sécurité » plus simple et vérifiable, qui garantit que la voiture ne dépasse jamais ses limites physiques, quoi que veuille l'IA.

L'IA propose. La couche certifiée dispose.

Pilier 2 : la SOTIF, quand rien n'est cassé mais le dommage survient quand même

ISO 26262 couvre les défaillances. Mais l'IA a un mode de défaillance plus inquiétant : tout fonctionne exactement comme prévu, et le système fait pourtant la mauvaise chose.

C'est le domaine de la SOTIF (Safety Of The Intended Functionality), normalisée sous ISO 21448. La SOTIF existe parce qu'un système de perception sans aucun défaut matériel peut quand même mal interpréter un camion blanc devant un ciel lumineux, ou ne pas reconnaître un piéton dans une posture inhabituelle.

La SOTIF divise le monde en quatre cases :

1. Scénarios sûrs connus (ceux pour lesquels vous avez conçu).
2. Scénarios dangereux connus que vous avez trouvés et corrigés.
3. Scénarios dangereux inconnus : ceux qui vous font mal.
4. Scénarios sûrs inconnus (surprises sans conséquence).

Tout le travail d'ingénierie consiste à réduire la case 3. On y parvient en exploitant les edge cases, en menant une analyse de scénarios structurée et en faisant passer les cas dangereux inconnus dans la colonne connus-et-traités.

Le Forum mondial de l'UNECE pour l'harmonisation des règlements sur les véhicules publie le cadre réglementaire adopté par de nombreux marchés, et il référence de plus en plus les deux normes pour les homologations de conduite automatisée.

Pourquoi les edge cases dominent le budget

La vérité inconfortable : le dernier 1 % des scénarios consomme l'essentiel de l'effort de validation. La conduite autoroutière normale est facile. Ce qui casse les systèmes, c'est la longue traîne : un cheval sur la route, un passage souterrain inondé, un ouvrier de chantier faisant des signes contradictoires, des véhicules d'urgence avec des feux inhabituels.

Vous ne pouvez pas les éliminer par conception à l'avance. Vous devez les trouver, puis prouver que votre système les gère.

Pilier 3 : des milliards de miles simulés

Comment trouver des événements rares ? Vous ne pouvez pas les faire advenir économiquement en roulant. Une analyse très citée de RAND soutenait que prouver qu'un système autonome est plus sûr que les humains par la seule conduite réelle pourrait exiger des centaines de millions, voire des milliards de miles, ce qui prendrait des décennies à des flottes entières. Considérez ces chiffres précis comme des estimations, mais la direction ne fait pas débat : les miles réels sont trop lents et trop coûteux pour les événements rares qui comptent le plus.

La charge de travail bascule donc vers la simulation.

Simulation par scénarios. Les équipes construisent une bibliothèque de scénarios paramétrés (une insertion, un piéton traversant hors passage, un véhicule en panne) et balayent chaque variable : vitesse, distance, luminosité, météo, adhérence. Un scénario devient des milliers de tests.

Resimulation (rejeu de logs). Chaque mile parcouru par une flotte réelle devient un actif. Vous enregistrez les données capteurs, puis vous les rejouez sur les nouvelles versions logicielles pour détecter les régressions. La mise à jour qui a corrigé l'insertion sur autoroute a-t-elle cassé le comportement en parking ?

Génération synthétique d'edge cases. Là où les données réelles manquent, vous les générez : météo rare, types d'objets rares, placements adverses auxquels aucun testeur humain ne penserait.

Le livrable n'est pas « nous avons beaucoup roulé ». C'est un argument de couverturecouvertureLe nombre de personnes uniques exposées à votre message sur une période donnée. Contrairement aux impressions, le reach compte chaque personne une seule fois, quel que soit le nombre d'expositions.Voir la définition complète → : nous avons exploré systématiquement l'operational design domain et montré que la fonction reste sûre sur l'ensemble de celui-ci.

L'operational design domain (ODD) est l'enveloppe précise dans laquelle le système est approuvé pour fonctionner : quelles routes, quelles vitesses, quelle météo, quels moments de la journée. Un système homologué uniquement pour les autoroutes à chaussées séparées, par temps clair et sous 60 mph, a un ODD étroit, et c'est souvent une qualité, pas une faiblesse. Un ODD serré est plus facile à valider et plus facile à défendre.

🎬 [VIDEO: "How Waymo Uses Simulation to Test Self-Driving Cars" - youtube.com - un regard sur la simulation de conduite à grande échelle et les tests par scénarios]

Le lien entre tout cela : le safety case

Les trois piliers alimentent un seul livrable : le safety case. C'est une argumentation structurée et auditable démontrant que le système est acceptablement sûr, appuyée sur des preuves. Les régulateurs le veulent. Votre propre direction juridique le veut. Les assureurs le veulent.

Une structuration courante est l'arbre claim, argument, evidence. En pseudocode, cela ressemble à ceci :

CLAIM: The lane-keeping function is acceptably safe within its ODD.
  ARGUMENT: All identified hazards are mitigated to target ASIL.
    EVIDENCE: HARA (Hazard Analysis and Risk Assessment) document
    EVIDENCE: ASIL-D safety monitor verification results
  ARGUMENT: Residual SOTIF risk is acceptably low.
    EVIDENCE: 4.2M scenario-simulation runs, pass rate + failure triage
    EVIDENCE: field monitoring plan for unknown-unsafe cases
  ARGUMENT: The ODD is enforced at runtime.
    EVIDENCE: geofence + weather-degradation handover logic tests

Notez ce que cela vous apporte dans un contentieux. En cas de problème, la question est rarement « le système était-il parfait ? ». Aucun système ne l'est. La question est « l'entreprise a-t-elle agi de façon responsable au regard de l'état de l'art ? » Un safety case traçable, montrant que vous avez identifié le danger, conçu une mesure d'atténuation et validé celle-ci, est votre meilleure preuve que oui.

Ce que cela implique pour votre façon de construire

La barre de validation remodèle toute l'organisation produit, pas seulement l'équipe sécurité.

Les pipelines de données deviennent une infrastructure de sécurité. Chaque mile de flotte rejouable est un actif de validation. Les équipes qui loggent richement et de façon interrogeable valident plus vite.

Le field monitoring ne s'arrête jamais. La SOTIF est un cycle de vie, pas une porte de lancement. Vous livrez, puis vous surveillez les cas dangereux inconnus qui n'apparaissent qu'à l'échelle, puis vous corrigez et revalidez. Les mises à jour over-the-air resserrent cette boucle, mais chaque mise à jour rouvre la question de la validation.

L'étroit bat le large. Un ODD bien délimité que vous pouvez défendre entièrement est souvent livré des années avant un ODD ambitieux que vous ne pouvez pas défendre. Beaucoup de fonctions d'aide à la conduite en production réussissent précisément parce qu'elles refusent de fonctionner hors de leur enveloppe.

Le safety case est un document business. Il conditionne l'accès au marché, façonne les conditions d'assurance et plafonne l'exposition en responsabilité. Les dirigeants qui le traitent comme de la paperasse valorisent mal le risque.

Points clés

• ISO 26262 traite les défaillances ; la SOTIF traite le comportement correct-mais-erroné. L'IA a besoin des deux, car un réseau de neurones sans défaut peut quand même mal percevoir le monde.
• Vous ne pouvez pas certifier un réseau de neurones directement, alors vous l'enveloppez. Un moniteur de sécurité vérifiable et une enveloppe de sécurité fondée sur la physique vous permettent d'offrir des garanties que l'IA elle-même ne peut pas fournir.
• La simulation est le seul moyen économique d'atteindre les événements rares qui comptent. Balayages de scénarios, rejeu de logs et edge cases synthétiques construisent un argument de couverture, pas un simple total de kilomètres.
• Un ODD étroit et appliqué est un avantage concurrentiel. Définir exactement où le système fonctionne accélère la validation, l'approbation et la défense.
• Le safety case est votre clé d'homologation et votre bouclier de responsabilité. Un enchaînement traçable claim, argument, evidence vaut mieux qu'une démo parfaite quand un régulateur ou un tribunal vous demande comment vous saviez que c'était sûr.