Le plus difficile dans l’autonomie, ce n’est pas la voiture. C’est le service.

La plupart des discussions sur l’autonomie commencent au même endroit : capteurs, perception, planification, et le mot magique « l’IA ». Et elles s’arrêtent souvent là — comme si de meilleurs modèles suffisaient à combler l’écart entre un pilote en environnement maîtrisé et un vrai service dans une capitale.

Copenhague s’apprête à tester cette hypothèse, en pleine lumière. Le sujet n’est pas de savoir si une stack de conduite autonome sait tenir sa voie. Le vrai sujet, c’est de savoir si le Danemark est prêt à opérer l’autonomie comme un service régulé : avec un centre de contrôle sur le territoire, des décisions auditables, et une réponse crédible à une question simple : qui est responsable quand personne ne conduit ?

Le débat danois l’a résumé sans détour en une phrase : nous ne voulons pas d’un type au hasard avec un joystick qui contrôle 40 voitures. Ce n’est pas une punchline. C’est la question de modèle opérationnel, formulée en langage clair.

La stack d’autonomie est la partie la plus simple, parce qu’elle est lisible

« Simple », toutes proportions gardées. Construire une autonomie sûre, c’est de l’ingénierie difficile. Mais c’est une ingénierie lisible. On peut la benchmarker, la simuler, mesurer les disengagements, et livrer des améliorations. On peut affecter des équipes, des tickets et des budgets. On peut en tracer les limites.

Assurer un service dans une ville dense, c’est autre chose. C’est désordonné, politique, et saturé de cas limites qui ne sont pas des « problèmes d’IA » :

• Que faire d’un passager qui refuse de sortir d’un véhicule alors que la course est terminée ?
• Que se passe-t-il lorsqu’un policier fait un signe de la main qui contredit le marquage au sol ?
• Qui décide d’interrompre l’exploitation pendant une tempête, et sur quelles preuves s’appuie cette décision ?
• Comment démontrer, a posteriori, ce que le système a « vu » et pourquoi il a agi ainsi ?

C’est pour cela que le centre de contrôle compte. Pas comme accessoire marketing, mais comme l’endroit où la responsabilité se concentre. Le projet de créer un centre de contrôle au Danemark n’est pas un détail de mise en œuvre. C’est le vrai produit.

Le remote-ops n’est pas une personne devant des écrans : c’est un système de commandement

On imagine souvent les remote operations comme du télé-driving : un humain reprend la main quand la voiture bloque. Cette image est à la fois trop simple et trop risquée. Dans un service urbain régulé, le remote-ops doit ressembler à de l’incident command, pas à du jeu vidéo.

Le basculement est le suivant : l’équipe à distance ne doit pas « conduire la voiture ». Elle doit piloter le système. Elle prend des décisions bornées, sous des règles, avec journalisation, escalade et passations.

Une manière pragmatique de le concevoir consiste à distinguer trois capacités :

• Assistance : l’équipe à distance apporte du contexte et donne une autorisation, par exemple pour valider une manœuvre prudente ou contourner une rue bloquée.
• Recovery : l’équipe à distance déclenche un arrêt en sécurité, dépêche une intervention terrain, ou coordonne avec les autorités. Ici, chaque minute compte.
• Containment : l’équipe à distance peut réduire le périmètre opérationnel, suspendre le service dans une zone, ou rapatrier les véhicules vers une zone sûre.

Sans cette séparation, vous recréez le risque du « joystick au hasard ». Non pas parce que la personne serait incompétente, mais parce que le système exige des exploits au lieu de fournir un cadre.

Ce qu’il faut spécifier avant d’ajouter des véhicules

Avant de débattre de la taille de flotte, posez par écrit le modèle de remote-ops. Pas comme une mise en scène de conformité, mais comme un outil d’alignement et d’audit. Pour démarrer, voici une checklist :

• Span of control : combien d’interventions simultanées un spécialiste remote peut-il gérer en sécurité, et quelles preuves l’établissent ?
• Intervention taxonomy : quels événements déclenchent l’intervention du remote-ops, et lesquels doivent rester intégralement autonomes ?
• Escalation paths : qu’est-ce qui déclenche l’activation d’un incident commander, une notification juridique, ou l’implication d’un interlocuteur côté ville ?
• Training and certification : quelles compétences sont requises, comment les tester, et comment les maintenir ?
• Logs and replay : quelles données sont conservées, pendant combien de temps, et qui y a accès ?

Notez ce qui manque : l’architecture des modèles. Non pas qu’elle soit secondaire, mais ce n’est généralement pas le premier point de rupture dans un service public.

Le safety case n’est pas un PDF : c’est un contrat vivant avec le réel

Dans les environnements régulés, on traite souvent le « safety case » comme de la paperasse. En pratique, c’est l’argumentaire qui relie les hypothèses à l’exploitation. Il dit : voici le domaine que nous affirmons couvrir, voici les dangers, voici les contrôles, et voici comment nous surveillons que ces contrôles fonctionnent encore.

Copenhague oblige à se poser une question inconfortable : que prétend exactement le système ? Un service de robot-taxi, ce n’est pas « la conduite autonome ». C’est :

• un système de dispatch
• un système de paiement et d’identité
• un système de santé de flotte et de maintenance
• un système d’assistance à distance et de gestion d’incidents
• un système de support client
• un système de conformité et d’audit

Le véhicule n’est qu’un composant. Le safety case doit couvrir le service de bout en bout, y compris la manière dont les humains interagissent avec lui sous pression.

J’ai vu des produits connectés échouer sur le terrain non parce que le code embarqué était faux, mais parce que les passations n’étaient pas définies. Un agent support a deviné. Un ingénieur a improvisé. Un log partiel a fait naître des débats sans fin. La correction n’a jamais été « une meilleure IA ». La correction, c’était des frontières plus nettes, une meilleure instrumentation, et moins de décisions ambiguës au moment critique.

Si vous voulez que l’autonomie devienne ennuyeuse (au bon sens du terme), vous devez rendre le safety case opérable : il doit guider la formation, l’alerte et les gates de release. C’est aussi pour cela que j’aime considérer les spécifications formelles comme des outils de gestion d’incidents, et non comme des preuves académiques, comme je l’explique dans Formal Specs Are Incident Tools, Not Academic Proofs.

La responsabilité est la contrainte de design que personne ne veut porter

Tout projet d’autonomie finit par buter sur la responsabilité. Pas comme note juridique en bas de page, mais comme contrainte structurante du système.

La question « qui est responsable ? » se pose à plusieurs niveaux :

• Décisions en temps réel : si le remote-ops valide une manœuvre, est-ce « conduire » ou « superviser » ?
• Conception du système : si un mécanisme de sécurité manque, qui a validé ce manque ?
• Exploitation : si le service continue dans des conditions hors du domaine déclaré, qui a pris cette décision ?
• Modèle commercial : qui est le fournisseur du service sur le papier, et que pense acheter le client ?

Si le cas de Copenhague compte, c’est parce qu’il parle explicitement de contrôle et d’examen, pas seulement de nouveauté. L’article indique clairement que le déploiement envisagé constitue un pas plus important que les projets précédents, et que le dispositif sera examiné et requiert un centre de contrôle au Danemark. Le Danemark se rapproche ainsi de la vraie question : approuve-t-on une démo technologique, ou délivre-t-on une licence pour un service avec une responsabilité opposable ?

Si c’est vous qui rendez des comptes pour introduire l’autonomie dans un cadre régulé, traitez la responsabilité comme une exigence produit. Elle va structurer votre organigramme, vos contrats fournisseurs, votre logging, votre assurance et votre communication client. L’ignorer ne fait que la repousser au premier incident.

Un modèle d’autonomie compatible avec Copenhague : le minimum à exiger

Oubliez les grandes déclarations sur le fait « d’être le premier ». Une ville doit exiger un modèle opérationnel minimal viable, qui rende les échecs maîtrisables et les décisions auditables. Si vous évaluez un fournisseur, un partenaire, ou votre propre plan, je pousserais cinq exigences non négociables.

1. Autorité d’incident sur le territoire : pas seulement une salle d’écrans, mais une fonction nommée, capable d’arrêter l’exploitation, de contacter les autorités et de déclencher l’escalade.
2. Interventions à distance bornées : une taxonomie écrite, avec des contrôles techniques qui empêchent le télé-driving improvisé en dehors des cas autorisés.
3. Observability de bout en bout : télémétrie véhicule, captures de perception quand c’est pertinent, actions remote-ops et interactions client, le tout rattaché à une chronologie unique.
4. Discipline de release alignée sur les claims de sécurité : les changements qui touchent le safety case passent par une revue explicite et un déploiement progressif. Traitez-le comme une release pipeline, pas comme un feature toggle. On retrouve la même logique côté logiciel, que j’ai abordée dans Default-On Agentic Coding Is a Release Pipeline Change, Not a Feature Toggle.
5. Responsabilité commerciale claire : l’entité qui encaisse doit être celle qu’on peut tenir pour responsable, sinon vous construisez un labyrinthe de défausse.

Cette liste n’est pas exhaustive. C’est le plancher. Si vous n’êtes pas capable d’expliquer ces points clairement, vous n’avez pas encore un service ; vous avez un prototype avec des passagers.

Mon point de vue : réguler le service, pas la magie

L’autonomie arrivera à Copenhague, sous une forme ou une autre. La question est de savoir si elle arrive comme un service public sérieux et inspectable, ou comme un montage fragile qui n’a l’air sûr que jusqu’au premier incident complexe.

« L’IA dans le véhicule » continuera de progresser, avec ou sans approbation danoise. Pour Copenhague, le facteur différenciant est ailleurs : sait-on définir une manière robuste d’exploiter le système dans son ensemble — remote-ops avec un véritable commandement, safety cases qui évoluent avec la réalité, et responsabilité explicite plutôt que sous-entendue.

Si vous êtes fondateur, dirigeant ou cadre senior et que vous construisez un service régulé, à proximité des enjeux de sécurité, gardez ce prisme : le cœur technique est rarement le goulot d’étranglement. Le goulot, c’est le modèle opérationnel qui rend vos promesses défendables, vos incidents gérables, et vos responsabilités claires.