La voiture autonome l'a vue 5,6 secondes avant l'impact — et n'a toujours pas su ce qu'elle était

J'étais assis dans une salle de réunion fin 2023, en train de regarder une vidéo qui allait changer à jamais ma façon de penser la sécurité de l'IA. Les images provenaient d'un robotaxi Cruise à San Francisco. Une piétonne avait été percutée par une voiture conduite par un humain, projetée sur la trajectoire du véhicule autonome, puis coincée sous celui-ci. Le robotaxi s'est arrêté — brièvement — puis a commencé à se ranger sur le bord de la route, traînant la femme sur 20 pieds d'asphalte.

Le silence est tombé dans la salle. Quelqu'un de mon équipe a dit : « La voiture a cru qu'elle avait subi une collision latérale. » Et cette phrase — la voiture a cru — est devenue le germe de tout ce que nous construisons chez Veriprajna depuis.

Parce que la voiture n'a rien « cru » du tout. Elle a exécuté un sous-programme de classification, obtenu la mauvaise réponse et déclenché une manœuvre préprogrammée qui a transformé un accident survivable en quelque chose de bien pire. Il n'y a eu aucun raisonnement. Aucune conscience. Aucune architecture de sécurité capable d'intercepter un diagnostic catastrophiquement erroné avant qu'il ne devienne une catastrophe.

C'est l'écart que je m'efforce sans cesse d'expliquer aux investisseurs, aux clients et à mes confrères ingénieurs : la distance entre une IA qui fonctionne bien en démonstration et une IA qui se comporte de manière sûre quand le monde cesse de coopérer. J'ai commencé à l'appeler l'écart Perception-Logique — l'espace entre ce qu'un système autonome voit et ce qu'il comprend réellement. Et en ce moment, cet écart tue des gens.

Que s'est-il passé quand l'IA a eu près de six secondes et a quand même échoué ?

Le crash d'Uber ATG à Tempe, en Arizona, en mars 2018, est le cas sur lequel je reviens le plus souvent, parce que c'est l'illustration la plus pure de la façon dont un système probabiliste peut disposer de toutes les données nécessaires et commettre malgré tout une erreur fatale.

Les capteurs du véhicule ont détecté Elaine Herzberg — une piétonne poussant un vélo en travers d'une route sombre — environ 5,6 secondes avant l'impact. À 43 mph, cela représente à peu près 378 pieds de distance. Largement de quoi permettre à n'importe quel système de freinage compétent d'arrêter la voiture.

Mais l'IA n'arrivait pas à décider ce qu'elle avait sous les yeux. Pendant ces 5,6 secondes, le système de perception a reclassé Herzberg à plusieurs reprises : d'abord comme « objet inconnu », puis comme « véhicule », puis comme « vélo ». Chaque reclassification n'était pas qu'un simple changement d'étiquette — c'était une réinitialisation complète de la trajectoire prédite de l'objet. Le système développait pour ainsi dire une amnésie chaque fois qu'il changeait d'avis.

Je me souviens d'avoir lu le rapport du NTSB pour la première fois et de m'être senti physiquement mal. Pas à cause de l'issue — même si elle était dévastatrice — mais à cause du mécanisme. L'IA n'a déterminé qu'un freinage d'urgence était nécessaire que 1,3 seconde avant l'impact. La physique a rendu le reste inévitable.

Une IA qui peut voir un obstacle pendant près de six secondes sans parvenir à décider ce que c'est n'a pas un problème de capteurs. Elle a un problème d'architecture.

Ce qui a aggravé les choses — ce qui m'a mis en colère, honnêtement — c'est d'apprendre qu'Uber avait délibérément désactivé le système anticollision installé en usine sur le Volvo XC90. La voiture était livrée avec un freinage d'urgence automatique du constructeur. Uber l'a désactivé pour éviter ce qu'ils appelaient un « comportement erratique du véhicule ». Ils voulaient une conduite plus fluide pour leur logiciel expérimental, alors ils ont supprimé la seule couche de sécurité déterministe qui aurait pu sauver une vie.

Cette décision hante ce secteur. C'est le péché originel qui consiste à traiter la sécurité de l'IA comme un problème de réglage plutôt que comme une discipline d'ingénierie.

Pourquoi la même défaillance se reproduit-elle dans des voitures différentes ?

Après le crash d'Uber, je m'attendais à ce que le secteur en tire les leçons. Plus précisément, je m'attendais à ce que les entreprises construisent des architectures dans lesquelles une défaillance de perception ne pourrait pas se propager en cascade jusqu'à une défaillance de décision. Où il existerait des limites de sécurité strictes qu'aucun logiciel expérimental ne pourrait outrepasser.

Au lieu de cela, nous avons eu Cruise.

L'incident d'octobre 2023 à San Francisco différait de celui d'Uber dans ses détails, mais lui était identique dans son architecture. Une Nissan conduite par un humain a percuté une piétonne, la projetant sur la trajectoire d'un robotaxi Cruise. Le véhicule Cruise l'a heurtée et s'est arrêté. Jusque-là, le système fonctionnait — imparfaitement, mais dans les limites prévues.

Puis la logique post-impact s'est enclenchée. La détection d'impact du système n'était pas assez fine pour distinguer un écrasement frontal d'une collision latérale. Il a classé l'événement comme un impact latéral. Et la réponse préprogrammée à un impact latéral était : se ranger sur le bord de la route pour ne pas bloquer la circulation.

La voiture s'est rangée. Avec un être humain coincé dessous. Elle l'a traînée sur 20 pieds à environ 7 mph avant de détecter un « patinage excessif des roues » — qu'elle a interprété comme une panne mécanique, pas comme une personne.

J'ai passé une semaine après cet incident à débattre avec mon équipe de ce qu'aurait dû être la bonne architecture de réponse. L'un de nos ingénieurs — un type brillant, très porté sur les méthodes formelles — insistait pour dire que le problème était soluble avec une meilleure fusion de capteurs. « Si le système avait eu une détection d'occupation sous le châssis, disait-il, il aurait su. »

Il avait raison. Mais il passait aussi à côté de l'essentiel. La défaillance plus profonde, c'est que le système n'avait aucune notion d'incertitude quant à son propre diagnostic. Il a classé l'impact, puis il a agi sur la base de cette classification avec une confiance totale. Il n'existait aucun état intermédiaire du type « je ne suis pas sûr de ce qui vient de se passer, donc je ne devrais rien faire tant que je ne le sais pas ». L'architecture ne laissait aucune place au doute.

C'est ce que je veux dire quand je parle de l'écart Perception-Logique. Il ne s'agit pas seulement de mieux voir. Il s'agit de savoir quand on ne sait pas.

La dissimulation faisait partie de l'architecture, elle aussi

Ce qui s'est passé après l'incident du traînage par Cruise est presque aussi révélateur que l'incident lui-même. Les enquêtes ont établi que la direction générale était « obnubilée par la correction du récit médiatique inexact » plutôt que de se montrer transparente avec les régulateurs. Des employés ont admis avoir montré aux régulateurs une vidéo de l'accident tout en sachant que des problèmes de connexion internet empêchaient souvent la partie du traînage de se lire.

Cruise a finalement payé une amende pénale de 500 000 dollars pour avoir soumis de faux rapports à la NHTSA. Son permis d'exploitation en Californie a été révoqué.

Si j'en parle, ce n'est pas pour accabler Cruise, mais parce que cela révèle quelque chose de structurel dans la façon dont le secteur traite la sécurité. Quand votre système d'IA est une boîte noire — quand même vos propres ingénieurs ne peuvent pas expliquer pleinement pourquoi il a pris telle décision à tel moment précis — la tentation de contrôler le récit au lieu de corriger l'architecture devient irrésistible.

La transparence n'est pas une stratégie de communication pour les véhicules autonomes. C'est une exigence technique. Si vous ne pouvez pas auditer chaque décision prise par votre IA dans une situation de crise, vous n'avez pas un système de sécurité — vous avez un passif.

Chez Veriprajna, nous avons fait des audits de sécurité explicables un pilier de notre travail d'architecture. Chaque décision prise par l'IA, en particulier après un impact, est consignée dans un format déterministe et inviolable que les régulateurs peuvent auditer en temps réel. Non pas parce que nous serions plus vertueux que Cruise — mais parce que nous avons vu ce qui arrive quand l'alternative est « laissons la vidéo parler d'elle-même ».

J'ai décrit le cadre technique complet qui sous-tend cette approche dans notre livre blanc interactif, y compris les modes de défaillance précis que nous avons catalogués chez Uber, Cruise, Tesla et Waymo.

Que signifie réellement le pari du « tout-caméra » de Tesla pour la sécurité ?

L'approche de Tesla en matière de conduite autonome est philosophiquement différente de celle d'Uber ou de Cruise, et les défaillances le sont aussi. Mais elles se font écho.

Le système Full Self-Driving de Tesla repose entièrement sur des caméras — pas de LiDAR, pas de radar. Elon Musk a qualifié le LiDAR de « béquille ». Le pari est que des réseaux de neurones suffisamment avancés peuvent reconstruire une compréhension 3D complète du monde à partir de simples images 2D, comme le fait la vision humaine.

C'est une idée élégante. Je la trouve même intellectuellement séduisante. Mais la NHTSA a ouvert plus de 40 enquêtes sur des accidents liés au FSD entre 2024 et 2025, portant sur 2,9 millions de véhicules, et le constat est accablant.

Dix-huit plaintes distinctes concernent des véhicules qui ont grillé des feux rouges ou n'ont pas détecté l'état des signaux. Plusieurs signalements décrivent des voitures s'engageant dans les voies de circulation en sens inverse. Une collision mortelle survenue en 2023 s'est produite dans l'éblouissement du soleil sur de l'asphalte mouillé — des conditions où le rapport signal/bruit optique tombe en dessous de ce que n'importe quel système de caméras peut interpréter de façon fiable.

J'appelle cela le théâtre de la capacité : le système se comporte à merveille dans des conditions optimales, créant une illusion de compétence qui s'effondre dès qu'on s'approche des limites. Journée ensoleillée, route dégagée, intersection standard ? Sans faute. Soleil rasant, chaussée mouillée, traversée piétonne inhabituelle ? Le système ne se dégrade pas progressivement. Il échoue brutalement.

Le problème n'est pas que l'approche tout-caméra ne puisse pas fonctionner en théorie. Le problème, c'est que Tesla la déploie à grande échelle sans ce que j'appellerais des portes d'assurance (Assurance Gates) — des limites strictes qui empêchent l'IA de prendre des décisions à fort enjeu lorsque sa confiance tombe en dessous d'un seuil vérifié. Si la saturation due à l'éblouissement dépasse un certain pourcentage, le système devrait refuser de conduire, et non deviner plus fort.

Comment prouver qu'une IA ne tuera personne ?

C'est la question qui m'empêche de dormir la nuit. Pas au sens figuré — littéralement. Il y a eu une période, l'an dernier, où je menais des expériences de vérification formelle jusqu'à 2 heures du matin, en essayant de trouver la frontière entre « suffisamment testé » et « prouvé sûr ».

Les tests logiciels traditionnels fonctionnent en boîte noire : on fait passer au système N scénarios, et s'il les réussit tous, on le met en production. Mais les véhicules autonomes ne rencontrent pas N scénarios. Ils rencontrent le monde physique tout entier, avec tout son chaos, ses cas limites et des humains qui font des choses inexplicables. Aucune quantité de tests de scénarios ne peut couvrir cet espace.

La vérification formelle adopte une approche différente. Au lieu de demander « le système a-t-il réussi ces tests ? », elle demande « existe-t-il une seule entrée capable de produire une sortie non sûre ? » Des outils comme Marabou et α,β-CROWN peuvent représenter un réseau de neurones sous la forme d'un ensemble de contraintes mathématiques, puis chercher — de manière exhaustive — des violations.

Une propriété de sécurité pourrait ressembler à ceci : pour toute entrée possible dans une plage de « faible visibilité », la commande de freinage ne doit jamais descendre en dessous d'un seuil minimal. Si le solveur trouve un contre-exemple — une entrée précise qui viole la propriété — vous avez identifié une vulnérabilité avant qu'elle ne tue quelqu'un.

Une nuit, nous exécutions une vérification sur un modèle de perception et le solveur a renvoyé un contre-exemple qu'aucun d'entre nous n'avait anticipé. Une combinaison très précise d'angle d'éclairage et de distance à l'objet qui faisait tomber la confiance de freinage à presque zéro. Ce n'était pas un scénario que l'un d'entre nous aurait songé à tester. Le solveur l'a trouvé parce qu'il ne devinait pas — il prouvait.

Ce moment a cristallisé quelque chose pour moi. Les tests demandent « est-ce que ça marche ? ». La vérification demande « est-ce que ça peut échouer ? ». Ce sont des questions fondamentalement différentes, et l'IA critique pour la sécurité exige la seconde.

Les tests vous disent ce que votre IA fait. La vérification vous dit ce qu'elle ne peut jamais faire. Pour les systèmes critiques pour la sécurité, seule la seconde question compte.

Le hic, c'est que les réseaux de neurones actuels sont énormes — des millions de paramètres — et que la vérification exhaustive de grands réseaux est calculatoirement intraitable. Nous répondons à cela par l'élagage de neurones : la suppression systématique des neurones redondants qui ne contribuent pas à la précision mais rendent le réseau trop complexe à vérifier. Le résultat est un modèle plus léger, à la fois performant et mathématiquement prouvable.

Pour le détail technique complet de notre pipeline de vérification — y compris la méthodologie du solveur SMT et l'approche d'élagage — voir notre article de recherche détaillé.

Quand le problème n'est pas l'IA — mais le monde

Waymo a enregistré plus de 56 millions de miles et affiche des taux de blessures nettement inférieurs à ceux des conducteurs humains. Selon la plupart des indicateurs, l'entreprise est en tête du secteur. Et pourtant, Waymo a mis au jour un mode de défaillance auquel personne dans l'industrie du véhicule autonome n'était préparé : le monde lui-même refusant de coopérer.

Lors d'une panne de courant à Los Angeles en 2025, des dizaines de robotaxis Waymo se sont retrouvés bloqués à des intersections plongées dans le noir. Les véhicules étaient programmés pour traiter les feux éteints comme des stops à quatre voies — la réponse légale correcte. Mais quand des dizaines de véhicules autonomes arrivent tous à la même intersection éteinte, chacun attendant poliment son tour et chacun demandant simultanément une assistance humaine à distance, on obtient ce que j'ai commencé à appeler le piège de l'indépendance : chaque véhicule se comporte correctement isolément tout en créant collectivement un embouteillage qu'aucun véhicule individuel ne peut résoudre.

Le centre d'assistance à distance a été submergé. Des robotaxis bloquaient d'autres robotaxis. Le système qui fonctionnait parfaitement avec une voiture à une intersection s'est effondré une fois passé à l'échelle d'une flotte dans une urgence à l'échelle d'une ville.

Et puis il y a le problème dont personne ne veut parler publiquement. Lors des troubles civils à Los Angeles début 2025, des foules s'en sont prises à des véhicules Waymo — pneus lacérés, vitres brisées, voitures incendiées. Les véhicules, programmés pour une « sécurité passive », se sont simplement arrêtés lorsqu'ils étaient encerclés par des personnes. Ce qui est exactement la mauvaise réponse quand les gens qui vous entourent cherchent à détruire le véhicule avec des passagers à l'intérieur.

Cela a conduit à des discussions sérieuses sur ce que certains chercheurs appellent un « mode d'échappement au danger » — la capacité pour un véhicule autonome de commettre des infractions mineures au code de la route (monter sur un trottoir, franchir un feu rouge) afin de protéger ses passagers de la violence. Cela exige de repenser fondamentalement la hiérarchie éthique de l'IA, et c'est un problème qu'aucune amélioration des capteurs ou des processeurs ne peut résoudre.

J'ai abordé ce sujet lors d'une réunion avec un client potentiel, et quelqu'un a dit : « Vous ne pouvez pas simplement utiliser GPT pour gérer des cas limites comme celui-là ? » Je crois que mon expression en a dit plus que mes mots. C'est un problème d'architecture décisionnelle qui exige un raisonnement éthique formel, pas un chatbot.

Pourquoi ne peut-on pas simplement tester jusqu'à atteindre la sécurité ?

On me pose constamment cette question. « Si Waymo a 56 millions de miles de données, cela ne suffit-il pas comme test ? »

Non. Et la raison est mathématique, pas philosophique.

L'espace des scénarios de conduite possibles est pour ainsi dire infini. On peut parcourir 56 millions de miles sans jamais rencontrer la combinaison précise d'éblouissement solaire, d'asphalte mouillé et de piéton habillé de façon inhabituelle qui fait échouer votre système de perception. Les cas limites ne sont pas des versions rares de scénarios courants — ce sont des scénarios qui existent dans les interstices entre tout ce que vous avez déjà vu.

C'est pourquoi le paysage réglementaire passe de « montrez-nous vos résultats de tests » à « montrez-nous vos preuves de sécurité ». La norme ISO 21448, connue sous le nom de SOTIF — Safety of the Intended Functionality, la sécurité de la fonctionnalité prévue — a été conçue spécifiquement pour traiter les dangers qui surviennent lorsque l'IA fonctionne exactement comme elle a été programmée mais rencontre un environnement qu'elle ne sait pas gérer. Il ne s'agit pas d'une défaillance matérielle. Il s'agit des limites intrinsèques de l'IA confrontées au monde réel.

Et la norme ISO/PAS 8800, devenue fin 2024 la principale norme pour l'IA dans les véhicules routiers, va plus loin : elle impose de gérer l'ensemble du cycle de vie de l'IA, de l'acquisition des données à la surveillance après déploiement. L'ère du « on déploie et on voit ce qui se passe » touche à sa fin, du moins pour les entreprises qui veulent opérer légalement dans l'UE, aux États-Unis et sur les grands marchés asiatiques.

Chez Veriprajna, nous structurons notre travail autour de l'objectif d'amener nos clients dans ce que la SOTIF appelle le quadrant « connu/sûr » — en identifiant systématiquement les conditions déclenchantes, en cartographiant les états environnementaux qui provoquent des erreurs de perception, et en utilisant une simulation haute-fidélité pour injecter des cas limites qu'il serait trop dangereux de tester sur des routes réelles.

La vraie différence entre un wrapper et une solution

J'ai passé ces dernières années à regarder le secteur de l'IA se scinder en deux camps, et la fracture ne cesse de s'élargir.

D'un côté, il y a l'économie des wrappers — des entreprises qui construisent des interfaces conversationnelles par-dessus de grands modèles de langage, en optimisant la vitesse de déploiement et l'expérience utilisateur. Une partie de ce travail est réellement utile. L'essentiel n'a aucune pertinence pour les applications critiques pour la sécurité.

De l'autre côté, il y a ce que j'appelle l'ingénierie IA profonde : l'intégration de la vérification formelle, de la résilience par fusion de capteurs et d'architectures de sécurité déterministes. C'est plus lent. C'est plus difficile. C'est moins impressionnant en démonstration. Et c'est la seule approche capable de survivre au contact du monde physique.

La pièce maîtresse technique de ce basculement, c'est la perception en vue de dessus (Bird's-Eye-View) avec des réseaux d'occupation. Au lieu de traiter les flux de caméras individuels et d'essayer de les recoudre — un processus qui perd de l'information à chaque couture — la perception BEV transforme les données multi-caméras et LiDAR en une grille 3D unifiée vue d'en haut. Et au lieu de demander « qu'est-ce que cet objet ? », les réseaux d'occupation demandent « cet espace est-il occupé ? ».

Cette distinction compte énormément. Si le système d'Uber ATG avait suivi l'espace occupé plutôt que d'essayer de classer des objets, peu importait qu'il ait pensé qu'Herzberg était une piétonne, un vélo ou un objet inconnu. L'espace était occupé. L'espace se trouvait sur la trajectoire du véhicule. Freiner.

De même, si le véhicule Cruise avait exécuté une détection d'occupation sous son châssis, il aurait su que quelque chose se trouvait sous la voiture, quelle qu'ait été sa classification de l'impact. L'espace occupé aurait annulé la manœuvre de rangement sur le bas-côté.

La question n'est pas « qu'est-ce que cet objet ? » — c'est « cet espace est-il occupé ? ». Ce simple recadrage aurait pu empêcher les deux catastrophes de véhicules autonomes les plus notoires de la dernière décennie.

Nous utilisons des architectures Transformer — la même technologie fondamentale que celle qui se cache derrière GPT — mais pas pour la conversation. Nous nous en servons comme moteurs de raisonnement spatial qui fusionnent des données de capteurs hétérogènes en ce que nous appelons une toile partagée (Shared Canvas). L'auto-attention temporelle permet au système de se souvenir de l'endroit où se trouvait un objet même pendant des occlusions temporaires — une piétonne qui marche derrière un camion garé ne disparaît pas de la conscience du modèle simplement parce que les caméras ne peuvent pas la voir pendant deux secondes.

La leçon à 8,5 millions de dollars

Le règlement à l'amiable d'Uber ATG s'est élevé à 8,5 millions de dollars. L'amende pénale de Cruise était de 500 000 dollars — un chiffre qui est loin de rendre compte de l'arrêt des opérations, du préjudice de réputation ou de la souffrance humaine. L'enquête de la NHTSA sur Tesla porte sur 2,9 millions de véhicules. Le coût moyen mondial d'une seule violation de données atteint désormais 4,44 millions de dollars.

Quand j'additionne ces chiffres, la conclusion est inconfortable pour les adeptes du « move fast and break things » : le wrapper d'IA bon marché est l'erreur la plus coûteuse qu'une entreprise puisse commettre. Non pas parce qu'il ne fonctionne pas — il fonctionne très bien dans des environnements contrôlés. Mais dès l'instant où il rencontre le monde non contrôlé — la route sombre, la confusion post-impact, l'éblouissement du soleil sur l'asphalte mouillé, la foule en colère — l'absence d'architecture de sécurité déterministe transforme une limite logicielle en catastrophe humaine.

Certains contestent parfois notre approche en disant que la vérification formelle est trop lente, trop coûteuse, trop académique pour les délais de déploiement du monde réel. Je comprends l'objection. La vérification coûte cher en calcul. Élaguer les réseaux pour les rendre vérifiables prend du temps. Construire des architectures de sécurité dotées de portes d'assurance strictes demande plus de travail que d'emballer une API.

Mais je demanderais à ces gens de regarder la vidéo du traînage par Cruise. De lire le rapport du NTSB sur la mort d'Elaine Herzberg. De regarder les 18 plaintes pour feu rouge grillé dans l'enquête sur le FSD de Tesla. Et ensuite de me dire que « trop lent » est une critique valable d'une approche conçue précisément pour empêcher ces issues-là.

L'ère de la construction de systèmes autonomes fondée sur l'espoir probabiliste touche à sa fin. Non pas parce que les régulateurs l'imposent — même s'ils le font — mais parce que la physique du monde réel l'exige. Un système d'IA qui franchit mille intersections parfaitement puis grille un feu rouge à la mille et unième n'est pas sûr à 99,9 %. Il n'est pas sûr, point. La sécurité n'est pas un pourcentage. C'est une propriété — une propriété qui tient dans toutes les conditions vérifiées, ou qui ne tient pas du tout.

C'est le basculement autour duquel je construis Veriprajna. Pas de meilleurs wrappers. Pas de démonstrations plus rapides. De l'assurance déterministe pour des systèmes où une défaillance n'est pas un rapport de bug — c'est un bilan de morts.