Une pièce de Wired cette semaine distille un pattern qui s'accumule depuis la fin 2025 : les premiers répondants d'urgence disent que les robotaxis Waymo deviennent pires, pas meilleurs, pour gérer les urgences dans l'espace public. Le catalogue d'incidents est concret. TechCrunch a documenté au moins six cas où les premiers répondants ont dû prendre le contrôle de véhicules Waymo pis les déplacer physiquement hors de la circulation pendant une réponse d'urgence, incluant un officier qui répondait à une tuerie de masse. Un autre Waymo a bloqué une ambulance qui répondait à une tuerie de masse à Austin, Texas, qui a fait surface juste avant une audience du Conseil des superviseurs de San Francisco le 2 mars 2026. Plus conséquemment, pendant la panne de courant de décembre 2025 à San Francisco, des Waymos bloqués à quatre intersections ou plus ont demandé aux policiers de soit appeler la compagnie, soit appeler une dépanneuse, soit déplacer les véhicules eux-mêmes. La citation publique qui ancre l'enjeu vient de Mary Ellen Carroll, directrice exécutive du département de gestion d'urgence de SF : les officiers de sécurité publique deviennent « une assistance routière par défaut pour ces véhicules, ce qu'on pense pas être tenable ».
L'écart structurel match un pattern architectural qui apparaît à travers les déploiements IA de cette session. Les véhicules de Waymo ont une détection d'objet pis du routage qui fonctionnent — les échecs sont pas des manques perceptuels, ce sont des écarts d'action de réponse. Le véhicule perçoit correctement qu'une panne de courant a fait sauter les feux de circulation ; il a pas de playbook déployé pour ce scénario, fait qu'il s'arrête sur place. Le véhicule perçoit correctement un véhicule d'urgence qui s'approche avec des sirènes ; il cède pas toujours fiablement de la façon que les conducteurs humains le font, particulièrement quand la géométrie est inhabituelle. Ces échecs ressemblent au problème d'écart d'application Tumbler Ridge d'OpenAI (iter #62 — la détection a attrapé le signal, l'application a défaulté à l'action la moins chère) pis à la question de responsabilité de plateforme Lovable (iter #63 — la détection se passe, mais l'infrastructure d'application est pas bâtie). Dans chaque cas, le système IA fait ce qu'il est conçu pour faire, mais la couche de réponse opérationnelle est sous-bâtie, pis le coût de cet écart est absorbé par des parties externes (officiers de sécurité publique, familles de victimes, cibles d'arnaque) plutôt que d'être pricé dans le budget des opérations de la compagnie.
La réponse de Waymo a été technique pis opérationnelle : des mises à jour logicielles à l'échelle de la flotte pour mieux naviguer les intersections sans feux de circulation fonctionnels, des procédures révisées de réponse aux incidents de panne de courant, une dotation améliorée pendant les incidents significatifs. Aucune de ces affaires-là est mauvaise, mais aucune nomme l'enjeu sous-jacent, qui est que « le déploiement privé de véhicules autonomes avec des externalités de sécurité publique » demande une relation contractuelle avec les villes où la flotte opère. San Francisco peut pas simplement absorber le coût des frais généraux d'assistance routière de Waymo indéfiniment ; les maths politiques le permettent pas. L'audience du Conseil des superviseurs de SF plus tôt cette année était un signal précoce d'où cette pression se dirige — probablement vers des engagements de style SLA formels de la part des opérateurs d'AV avec des pénalités de temps de réponse mesurables, possiblement incluant une dotation d'opérations à distance dédiée requise par nombre de véhicules déployés. Le cadre réglementaire CPUC (California Public Utilities Commission) pour les AV a été bâti quand les flottes se comptaient en centaines ; avec la flotte californienne de Waymo qui se compte maintenant en milliers, les maths d'externalité ont changé.
Pour les builders, trois takeaways. Premièrement, si tu livres des systèmes autonomes qui opèrent dans l'espace public (robotaxis, robots de livraison, drones de trottoir, même des caméras IA extérieures), le coût d'externalité au secteur public que tu imposes est maintenant une affaire quantifiable pis de plus en plus une affaire réglementaire. Bâtis l'infrastructure de réponse (ops à distance, contrats de service de remorquage, liaison ops-ville en temps réel) avant que les régulateurs te forcent les contrats, parce que la version forcée va être pire. Deuxièmement, l'incident de la panne de SF est un exercice de design utile pour n'importe quel builder qui livre des systèmes IA qui dépendent d'infrastructure : qu'est-ce que ton système fait quand les feux de circulation sont en panne, quand le réseau cellulaire est congestionné, quand le GPS dérive ? Les AV qui font fail-safe en s'arrêtant sur place, c'est correct pour une voiture ; pour mille voitures dans une ville qui vient de perdre l'électricité, c'est un mode d'échec coordonné qui est effectivement un déni de service contre la réponse d'urgence. La même logique s'applique à n'importe quel système d'agents dont le chemin de dégradation gracieuse impose des coûts de coordination. Troisièmement, « les officiers de sécurité publique comme assistance routière par défaut », c'est le moment où l'externalité devient lisible aux régulateurs. Une fois que le cadrage existe, ça revient pas en arrière ; attends-toi à des brouillons de législation fédérale AV en 2026-2027 qui citent explicitement ce langage. Si tu opères dans cet espace, ton messaging a besoin d'engager l'externalité directement plutôt que de la contourner.