Construire un framework de model risk pour l'IA safety-critical

En 2018, un véhicule de test Uber à Tempe, Arizona, a heurté et tué une piétonne. Le système de perception l'a détectée 5,6 secondes avant l'impact mais n'a cessé de la reclasser : véhicule, puis inconnu, puis vélo. Le logiciel n'était pas conçu pour anticiper une personne traversant hors d'un passage piéton. C'est une défaillance de model risk, et aucune provision financière ne la couvre.

Les banques ont passé 25 ans à bâtir une discipline autour des modèles qui valorisent mal le risque. L'IA automobile a besoin de la même discipline, mais la fonction de perte est une vie humaine, pas un crédit douteux. Cette leçon adapte le model risk management (MRM) de niveau bancaire aux modèles de perception, de prédiction et de planification embarqués dans les véhicules.

Ce que « model risk » signifie ici

Le model risk est le risque de perte (financière, réputationnelle ou dommage physique) provenant d'un modèle faux ou mal utilisé. Le concept vient des guidances de la Federal Reserve américaine et de l'OCC (Office of the Comptroller of the Currency), SR 11-7, le texte fondateur du model risk management. Lisez l'original : il est court et étonnamment lisible (guidance SR 11-7).

SR 11-7 dit deux choses qui se transposent parfaitement à l'automobile :

1. Un modèle est toute méthode quantitative qui transforme des données d'entrée en une décision. Un classifieur de piétons en fait partie.
2. Le model risk vient de deux sources : le modèle peut être fondamentalement faux, et le modèle peut être mal utilisé. Les deux s'appliquent à un système de maintien de voie utilisé sur un type de route pour lequel il n'a jamais été validé.

La différence : un swap mal valorisé coûte de l'argent. Un piéton non détecté coûte une vie. On garde donc le framework et on relève le niveau d'exigence.

Le cadre réglementaire pour 2026

Vous construisez ce framework à l'intérieur d'un droit bien réel.

• Le Règlement ONU n° 157 (ALKS, Automated Lane Keeping Systems) et le Règlement ONU n° 171 (DCAS, Driver Control Assistance Systems) fixent des exigences contraignantes en Europe et dans la plupart des États membres de l'UNECE.
• ISO 26262 couvre la sécurité fonctionnelle (défaillances issues de pannes). ISO 21448 (SOTIF, Safety Of The Intended Functionality) couvre le problème plus difficile : le système n'a aucune panne mais échoue quand même parce que le monde l'a surpris. L'IA de perception vit essentiellement en territoire SOTIF.
• ISO/PAS 8800 (publiée en 2024) est la première norme spécifiquement dédiée à la sécurité de l'IA dans les véhicules routiers. C'est votre document d'ancrage.
• L'AI Act européen classe les composants de sécurité IA des véhicules comme à haut risque, mais renvoie largement au droit existant de l'homologation automobile plutôt que de le dupliquer.
• Aux États-Unis, la NHTSA (National Highway Traffic Safety Administration) intervient via les Federal Motor Vehicle Safety Standards et son Standing General Order imposant la déclaration des accidents pour les systèmes automatisés.

Nommez ces instances correctement quand vous parlez à un régulateur. Des références vagues signalent que vous n'avez pas lu les normes.

Étape 1 : classez vos modèles par impact sur la sécurité

Les banques classent les modèles par matérialité. Vous, vous classez par potentiel de dommage. Construisez une matrice simple combinant sévérité (gravité en cas de défaillance) et contrôlabilité (le conducteur ou le système peut-il rattraper la situation).

Le tier détermine l'intensité de la gouvernance. Le Tier 1 obtient une validation indépendante, des tests extensifs sur cas limites et une signature formelle. Le Tier 3 obtient une revue légère. Ne dépensez pas l'effort Tier 1 sur des modèles Tier 3, sinon votre équipe sécurité se noie et les vrais risques passent à travers.

Étape 2 : définissez l'operational design domain

L'ODD (Operational Design Domain) désigne les conditions précises dans lesquelles le modèle est validé pour fonctionner : types de routes, météo, luminosité, plage de vitesse, géographie. C'est votre contrôle le plus important.

La plupart des « défaillances IA » sont en réalité des violations d'ODD : un modèle utilisé hors de son enveloppe validée. Le cas de Tempe impliquait un système fonctionnant de nuit face à un scénario qu'il n'avait pas été conçu pour traiter.

Rédigez l'ODD comme un contrat. Exemple pour un highway pilot :

• Routes à chaussées séparées uniquement, sans trafic transversal
• Jour, temps sec ou pluie faible
• 30 à 130 km/h
• Marquages au sol nets et présents

Puis imposez-le dans le code. Le véhicule doit détecter qu'il sort de son ODD et rendre la main en sécurité.

Étape 3 : la validation indépendante

Principe central de SR 11-7 : l'équipe qui construit un modèle ne peut pas être la seule à le juger. Il vous faut un effective challenge exercé par un groupe doté d'autorité, de compétence et d'indépendance.

Pour un modèle de perception Tier 1, la validation indépendante signifie :

• Un jeu de test distinct que l'équipe de développement n'a jamais vu (un holdout), particulièrement riche en cas limites : piétons occultés, personnes en fauteuil roulant, poussettes, postures inhabituelles.
• Des tests adverses et sur cas extrêmes : brouillard, éblouissement solaire rasant, surfaces réfléchissantes, zones de travaux.
• La vérification du distributional shift : la performance chute-t-elle sur des populations ou des géographies sous-représentées dans les données d'entraînement ?

Voici une porte de validation minimale exprimée en code. L'idée est que l'acceptation est explicite et non négociable, pas une impression.

def perception_gate(metrics, odd_ok):
    # Seuils d'acceptation Tier 1 (illustratifs, fixés par l'équipe sécurité)
    return (
        metrics["pedestrian_recall"] >= 0.995 and
        metrics["false_negative_rate_night"] <= 0.005 and
        metrics["worst_subgroup_recall"] >= 0.99 and
        odd_ok  # le modèle détecte correctement les limites de l'ODD
    )

Les seuils sont fixés par votre chief safety officer, pas choisis pour flatter le modèle. Notez le worst_subgroup_recall : une moyenne qui masque un sous-groupe faible, c'est un procès en préparation.

🎬 [VIDEO: "How Tesla's Autopilot and Full Self-Driving Actually Work" - youtube.com - décryptage clair du pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → perception-planification dans un système réel]

Étape 4 : des gates de gouvernance qu'un CSO signera

Une governance gate est un point de contrôle où un modèle ne peut pas passer à l'étape suivante sans signature documentée. Votre chief safety officer (CSO) est personnellement responsable, la gate doit donc lui fournir des preuves défendables.

Concevez trois gates :

Gate A : du développement à la validation. Exige un safety case complet : une argumentation structurée, étayée par des preuves, démontrant que le système est acceptablement sûr pour son ODD. ISO/PAS 8800 l'attend. Exige aussi un ODD documenté et une fiche décrivant la provenance des données d'entraînement.

Gate B : de la validation au déploiement limité. Exige la validation indépendante réussie, les résultats sur cas limites, l'analyse par sous-groupes et un plan de monitoring. Le déploiement est d'abord géolocalisé ou en shadow mode.

Gate C : du déploiement limité au déploiement complet. Exige des données terrain issues du déploiement limité montrant que la performance réelle correspond aux résultats de laboratoire, plus une procédure d'incident et de rollback.

Chaque gate produit un artefact signé. Quand la NHTSA ou un tribunal demande « comment avez-vous décidé que c'était sûr ? », vous remettez le safety case. C'est la différence entre une décision défendable et un titre de presse.

Étape 5 : surveillez après le déploiement

La banque a appris à ses dépens que les modèles se dégradent. Un modèle de 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 →édit entraîné avant 2008 a échoué pendant la crise. Les modèles de perception se dégradent aussi, par data drift : nouveaux designs de véhicules, nouvelles formes de trottinettes, marquages effacés, variations saisonnières.

Mettez en place un monitoring continu :

• Suivi des désengagements : à quelle fréquence l'humain reprend la main, et pourquoi. Un taux qui monte signale une dérive d'ODD ou une dégradation du modèle.
• Enregistrement des quasi-accidents : freinages d'urgence, approches rapprochées. Ce sont des indicateurs avancés, avant l'accident réel.
• Shadow evaluation : faites tourner un modèle candidat en silence à côté de la production, comparez les décisions, ne déployez que s'il est strictement meilleur sur les métriques de sécurité.

Un exemple chiffré. Supposons que votre flotte parcoure 2 millions de km par mois et enregistre 40 désengagements liés à la sécurité. Soit 1 pour 50 000 km. Si le mois suivant ce chiffre monte à 80 désengagements sur la même distance (1 pour 25 000 km), le taux a doublé. C'est un déclencheur d'investigation, pas un motif d'attendre l'accident. Fixez le seuil d'alerte à l'avance et par écrit, pour que personne n'en discute pendant un incident.

Étape 6 : assumez le chemin de défaillance

Chaque modèle Tier 1 a besoin d'un fallback défini : ce que fait le système lorsqu'il est incertain ou qu'il sort de son ODD. Les options incluent une manœuvre à risque minimal (ralentissement contrôlé et arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êt dans un endroit sûr) ou une reprise en main par le conducteur, minutée, avec alertes croissantes.

Le chemin de défaillance fait partie du framework de model risk, ce n'est pas une réflexion après coup. Un modèle de perception qui échoue proprement vers un arrêt sûr présente moins de risque qu'un modèle plus précis qui échoue silencieusement.

Points clés

• Adaptez, n'importez pas. Les principes de SR 11-7 (un modèle peut être faux ou mal utilisé ; effective challenge indépendant ; monitoring continu) se transposent directement. La fonction de perte passe de l'argent aux vies : relevez les seuils et formalisez les signatures.
• Classez par dommage, puis alignez l'intensité de gouvernance sur le tier. Ancrez tout sur ISO/PAS 8800, ISO 21448 (SOTIF) et les Règlements ONU pertinents.
• L'ODD est votre contrôle principal. La plupart des défaillances sont un modèle validé utilisé hors de son enveloppe. Rédigez l'ODD comme un contrat opposable et détectez les violations de limites dans le code.
• Les gates produisent des artefacts signés. C'est un safety case documenté qui rend l'approbation d'un CSO défendable face à la NHTSA, aux régulateurs et aux tribunaux.
• Surveillez la dérive et définissez le chemin de défaillance. Suivez les désengagements et les quasi-accidents avec des seuils d'alerte prédéfinis, et assurez-vous que chaque modèle Tier 1 bascule vers une manœuvre à risque minimal.