Lancer un projet d'IA ne demande plus un grand programme. Brancher un modèle sur des documents internes et montrer au comité de direction une réponse juste peut tenir dans un pilote de quelques semaines. L'amener jusqu'à un outil sur lequel une organisation peut compter tous les jours relève d'un autre travail, plus long et moins spectaculaire.
Dmitri Dolgov, codirecteur général de Waymo, a consacré sa carrière à cet écart. Entré dans la conduite autonome par l'Urban Challenge, l'une des compétitions de véhicules autonomes du DARPA Grand Challenge, il a rejoint en 2009 le projet de voiture autonome de Google, devenu Waymo. Son entretien à AI Ascent 2026, la conférence de Sequoia Capital, raconte comment un service passe de l'essai au produit. La conduite autonome sert ici de terrain d'observation. Le chemin qu'il décrit concerne tout projet d'IA lancé dans une entreprise.
Pourquoi un pilote réussi ne suffit-il pas à faire un produit ?
Un pilote démontre le début d'une courbe alors qu'un produit en exige la fin. Dolgov le dit de la conduite autonome, un problème « very easy to get started » (très facile à démarrer) qu'il reste « very difficult to take it all the way to a real product » (très difficile à mener jusqu'à un vrai produit).
Le début de la courbe et sa longue traîne
Dolgov tire de cette asymétrie sa lecture des cycles d'enthousiasme qu'a traversés son secteur. Une percée technique produit des progrès très rapides sur les premières parties du problème et attire des investissements tout aussi rapides. Il cite trois vagues successives, les réseaux convolutifs, les transformeurs puis les grands modèles de langage. Chacune « reshapes the early part of the curve » (redessine le début de la courbe) sans que la suite bouge. Elle « doesn't change the long tail of it », précise-t-il, la longue traîne restant intacte.
La longue traîne désigne les situations rares, nombreuses et imprévisibles qu'un système rencontre une fois sorti de son terrain d'essai. Dolgov en raconte deux, une jeune femme en trottinette électrique qui chute juste devant la voiture et un piéton caché derrière un bus et détecté grâce au signal lidar passé sous le véhicule. Aucune démonstration ne les contient. Un produit doit les traiter tous les jours.
Ce que cela change pour un projet d'entreprise
Un modèle plus récent rend la démonstration plus convaincante sans traiter pour autant les exceptions d'un processus réel. La facture arrivée sans bon de commande, le client qui écrit dans une autre langue, la règle métier que personne n'a jamais écrite forment la longue traîne d'un service client ou d'un service achats. Attendre le modèle suivant revient à parier qu'il réglera ce que, selon Dolgov, aucune des percées précédentes n'a réglé.
Une question aide à tenir cette distinction en comité. Sur notre sujet, qu'est-ce que l'outil rend facile et qu'est-ce qu'il laisse tel quel ? La première partie de la réponse justifie le pilote. La seconde décrit le travail qui reste à faire pour obtenir un produit.
Qu'est-ce qui sépare une démonstration d'un produit ?
Une fiabilité que les moyens de la démonstration ne suffisent pas à produire. Dolgov oppose les premiers 90 % aux « neuf » suivants, le vocabulaire d'ingénieur qui compte la fiabilité en 99 %, 99,9 % puis 99,99 %. Il reconnaît qu'il est tentant de viser d'abord la capacité pour atteindre vite les 90 %. Mais la façon d'obtenir ces premiers 90 % « is totally different problem » (est un problème totalement différent) de la façon d'obtenir les décimales suivantes.
Ce dont un produit a besoin et dont une démonstration se passe
Dolgov illustre ce point par l'architecture de Waymo. Selon lui, un modèle qui va directement des capteurs aux décisions a de vraies qualités mais ne suffit pas à lui seul pour un produit entièrement autonome déployé à grande échelle. Waymo l'a donc complété par des représentations intermédiaires structurées. Ces représentations permettent des fonctions dont on peut se passer pour construire « a prototype, a demo, or a small scale deployment » (un prototype, une démonstration ou un petit déploiement). Il cite une « extra validation at runtime » (validation supplémentaire pendant l'exécution) et des protocoles d'entraînement et d'évaluation plus riches.
Transposé à un projet d'entreprise, le constat devient une liste de questions que la démonstration n'oblige pas à poser. Qui contrôle le résultat une fois l'outil en service ? Sur quel jeu de cas réels, exceptions comprises, l'outil a-t-il été évalué ? Que se passe-t-il quand il se trompe ? Un processus linéaire ne sait pas se rattraper quand une étape échoue. Une chaîne où l'IA remplace une étape hérite de cette fragilité.
Produire, éprouver, juger
Le modèle de fondation de Waymo alimente trois fonctions que Dolgov nomme « the driver, the simulator, and the critic », le conducteur, le simulateur et le critique. Il les décrit comme des tâches liées mais distinctes. L'un agit, l'autre fabrique le monde où l'on s'entraîne et s'évalue, le troisième juge.
La séparation vaut au-delà de la technique. Dans un pilote d'entreprise, produire le résultat, l'éprouver dans des conditions proches du réel et juger s'il est acceptable gagnent à être confiés à des personnes différentes, nommées dès le départ. Ce travail de contrôle a un prix que le budget d'un pilote doit prévoir, puisque vérifier coûte plus cher que produire à l'ère de l'IA.
Comment fixer à un pilote des objectifs qui font apprendre ?
En les choisissant pour ce qu'ils obligent à comprendre, pas pour ce qu'ils permettent de montrer. Waymo en offre un exemple daté. En 2009, une douzaine de personnes démarrent le projet de Google avec un but que Dolgov résume par « learning the problem space », apprendre l'espace du problème.
Les deux objectifs de 2009
L'équipe s'en fixe deux. Le premier consiste à parcourir 100 000 miles au total en autonomie complète, un volume inédit à l'époque selon Dolgov. Le second impose dix itinéraires de 100 miles chacun dans la baie de San Francisco, choisis pour leur difficulté, à parcourir de bout en bout sans une seule intervention du conducteur de sécurité resté au volant. Il a fallu environ dix-huit mois pour tenir les deux.
Ces objectifs sont bornés, mesurables et difficiles. Ils ne promettent aucun chiffre d'affaires. Le second touche déjà à la longue traîne, puisque la moindre intervention sur un itinéraire difficile fait échouer l'épreuve. Au terme de ces premières années, raconte Dolgov, l'équipe s'est convaincue que le sujet valait d'être poursuivi et a commencé à construire un produit entièrement autonome.
Ce qu'un pilote d'entreprise peut en retenir
Un pilote d'IA peut recevoir le même type d'objectif. Traiter de bout en bout un échantillon de dossiers réels choisis pour leur difficulté, sans reprise manuelle, dit davantage qu'un taux de satisfaction recueilli après une démonstration. Écrire ce résultat attendu avant de commencer oblige aussi à le relire ensuite. Apprendre de ses livraisons devient le vrai coût à l'ère de l'IA. La prédiction écrite en est la première condition.
Un pilote qui ne dit pas à quelles conditions il passera en production reste une démonstration.
Dolgov garde de ces débuts le souvenir des années sans doute les plus enthousiasmantes de sa vie professionnelle. Il décrit une équipe qui travaillait « 24/7 », écrivait le logiciel et montait le matériel le jour puis testait la nuit, en apprenant à une vitesse qu'il juge folle. Ce qui se transpose dans une entreprise tient à la densité d'apprentissage d'une équipe resserrée qui touche à toutes les parties du problème, bien plus qu'à ses horaires.
Pourquoi poser la sécurité dès le premier jour ?
Parce qu'elle se loge dans des choix qu'on ne refait pas à la fin. Dolgov explique que pour construire un système comme celui de Waymo « safety has to be the non-negotiable foundation » (la sécurité doit être la fondation non négociable), à intégrer dans tout ce que l'on fait dès le premier jour. Il cite l'architecture du modèle, la recette d'entraînement et d'évaluation, puis l'état d'esprit de l'équipe.
La liste mérite d'être lue jusqu'au bout. La sécurité y commence dans la technique et finit dans la culture. Dolgov y revient une seconde fois dans la même réponse, en parlant de la sécurité comme « the non-negotiable fundamental layer from day one », la couche fondamentale non négociable dès le premier jour.
La sécurité d'un projet d'IA en entreprise
Un outil d'IA interne ne met pas des piétons en danger. Il engage pourtant d'autres conséquences qu'on ne répare pas après coup, la fuite d'une donnée client, une décision individuelle prise sans supervision humaine, une erreur reproduite des milliers de fois avant d'être vue. Ces sujets se posent au lancement du pilote. La matrice de Farmer oblige à décider à l'avance du risque qu'on refuse, avant que l'enthousiasme d'une démonstration ne le fasse accepter par défaut.
Le cadre de ces choix se prépare au niveau de l'entreprise. Une charte d'usage de l'IA écrite pour l'organisation elle-même dit quelles données peuvent entrer dans un outil, quelles décisions restent humaines et qui répond d'un résultat faux. La cybersécurité de l'IA relève du CODIR autant que de la DSI, pour la même raison. Un pilote qui démarre sans ce cadre devra le rencontrer plus tard, au moment où le reprendre coûtera le plus.
Que disent les chiffres de Waymo et comment les citer ?
Ils montrent une montée en échelle très lente puis très rapide, à condition de les lire avec leur date et leur auteur. Tous ceux du tableau ci-dessous sont donnés par Dolgov dans l'entretien. Ce sont des chiffres d'exploitation déclarés par l'entreprise, sans source tierce citée dans l'échange.
| Repère | Ce que dit Dolgov | Ce que cela mesure |
|---|---|---|
| 2009, le démarrage | Une douzaine de personnes, deux objectifs d'apprentissage tenus en environ dix-huit mois. | La taille de l'équipe et la durée de la phase d'exploration. |
| Premier service public | Huit ans entre les premières opérations entièrement autonomes et un service ouvert au public dans quatre villes. | La durée du passage de l'essai au produit. |
| 2026 | Quatre villes ouvertes en un seul jour, quelques semaines avant l'entretien. | La vitesse de déploiement une fois le produit établi. |
| Trajets cumulés | Plus de 20 millions de trajets entièrement autonomes, 10 millions d'entre eux sur les sept derniers mois. | Un total depuis le lancement du service et non un rythme annuel. |
| Exploitation | 11 villes en exploitation entièrement autonome, plus de 4 millions de miles par semaine. | Le volume d'activité à la date de l'entretien. |
| Sécurité | Plus de 13 fois plus sûr qu'un conducteur humain sur les collisions causant des blessures graves, dans les villes où Waymo opère, sur plus de 170 millions de miles. | Une comparaison construite par l'entreprise, rapportée aux miles parcourus. |
La transition de phase
La ligne qui compte le plus pour un dirigeant tient à l'écart entre huit ans pour ouvrir quatre villes et un seul jour pour en ouvrir quatre autres. Dolgov y voit une transition de phase dans la façon dont l'entreprise grandit. La moitié du cumul de trajets date des sept derniers mois, ce qu'il commente d'un « that's what exponential scaling looks like ». On peut y lire que la phase lente a construit ce qui rend la phase rapide possible.
Citer un chiffre de sécurité sans le déformer
Le facteur 13 a un périmètre précis. Il porte sur une catégorie de collisions, celles qui causent des blessures graves. Il se compare à un conducteur humain dans les villes où Waymo circule, sur plus de 170 millions de miles en autonomie complète. Dolgov l'énonce dans l'entretien mis en ligne le 1er mai 2026. Pour le reprendre, il faut le reprendre entier, avec sa métrique, sa population de comparaison, son volume de miles et sa date. Séparé de ces éléments, il devient un slogan. Dolgov lui-même borne les capacités de son système au milieu d'une anecdote sur une capacité inattendue, en rappelant qu'il ne voit pas à travers les objets solides.
La même discipline vaut pour les chiffres qu'un fournisseur annonce sur un outil d'IA. Taux de réussite, gain de temps, précision, chacun appelle les mêmes questions. Mesuré sur quoi, comparé à qui, sur quel volume, à quelle date et par qui ?
Comment passer du pilote au déploiement ?
Par étapes, en réduisant un risque après l'autre avant d'accélérer. Interrogé sur les cinq à dix prochaines années, Dolgov décrit un changement de régime. Waymo est passé d'une « intentional sequential de-risking » (réduction des risques volontairement séquentielle) du système et des parties clés de l'activité à une « rapid parallel global commercialization » (commercialisation rapide, parallèle et mondiale).
L'ordre des étapes
L'ordre compte autant que les étapes. Chez Waymo, le déploiement en parallèle vient après une réduction des risques menée une chose après l'autre. Dans une entreprise, cela revient à étendre un outil à d'autres équipes seulement une fois tranchées les questions de données, de contrôle et de responsabilité sur le premier périmètre. La vitesse d'absorption d'une organisation ne se force pas. Multiplier les pilotes simultanés ne l'augmente pas.
Gagner la confiance avant de déployer
Selon Dolgov, ouvrir une nouvelle ville demande de collecter les données, de caractériser l'environnement et de valider le système. Il ajoute qu'une part significative du travail consiste à engager la conversation avec les communautés locales, parce que le service est nouveau. Il le résume ainsi, « it's on us to earn the trust », c'est à nous de gagner la confiance.
La charge de la preuve est placée du côté de celui qui arrive. Transposée à une organisation, la phrase désigne les équipes dont un outil d'IA va modifier le travail. Leur parler avant le déploiement, leur montrer sur quels cas l'outil a été éprouvé et qui le corrige quand il se trompe fait partie du passage en production, au même titre que la validation technique.
D'où je parle
Depuis 2012, j'accompagne des équipes, des managers et des CODIR et je pratique la facilitation, dans une carrière commencée en 1998 dont quatorze ans à manager des équipes. Je travaille le sujet de l'IA en organisation depuis fin 2024. Je travaille aussi un principe organisationnel autour de l'IA, selon lequel la question n'est plus quoi produire mais comment nous allons le produire.
Par où commencer avec un pilote déjà lancé ?
Par l'écriture de ce qu'il doit démontrer. Un pilote en cours peut encore recevoir ce qu'on a oublié de lui donner au départ, dans l'ordre qui suit.
- Écrire le critère de sortie. Une phrase qui dit ce que le pilote doit avoir démontré, sur quel volume et à quelle date, pour que la décision de passer en production se prenne.
- Constituer un jeu de cas réels. Des cas choisis pour leur difficulté, exceptions comprises, sur lesquels l'outil sera évalué, comme les itinéraires difficiles de 2009.
- Nommer les personnes qui produisent, éprouvent et jugent. Trois fonctions distinctes confiées à des personnes différentes.
- Fixer les conséquences refusées. Les données qui n'entrent pas dans l'outil, les décisions qui restent humaines, la personne qui peut arrêter l'outil.
- Ouvrir la conversation avec les équipes concernées. Avant le déploiement, avec les cas d'épreuve et les règles de correction sous les yeux.
Aucun de ces gestes ne demande un modèle plus performant. Tous demandent une décision de dirigeant.
Questions fréquentes
Rien ne l'impose. Selon Dmitri Dolgov, codirecteur général de Waymo, chaque percée technique redessine le début de la courbe sans changer sa longue traîne. Un modèle plus récent rendra la démonstration plus convaincante. Les cas rares de votre processus resteront à traiter par l'évaluation, le contrôle et la correction.
Ceux qu'on a écrits avant de le lancer. Un résultat mesurable sur un jeu de cas réels choisis pour leur difficulté, un dispositif de contrôle une fois l'outil en service, des conséquences refusées tranchées et une personne capable d'arrêter l'outil. Sans critère écrit, la décision se prend sur l'impression laissée par la démonstration.
Aucune durée ne vaut pour tous les projets. La durée découle de l'objectif d'apprentissage fixé au départ. Chez Waymo, les deux objectifs de 2009 ont demandé environ dix-huit mois à une douzaine de personnes, sur un problème d'une ampleur exceptionnelle.
C'est ce que déclare l'entreprise, sur un périmètre précis. Dolgov parle de collisions causant des blessures graves, comparées à celles d'un conducteur humain dans les villes où Waymo opère, sur plus de 170 millions de miles en autonomie complète. Le chiffre se cite avec ces éléments et sa date, l'entretien mis en ligne le 1er mai 2026.
Une personne nommée avant le lancement du pilote et dotée de l'autorité pour dire oui, non ou pas encore. Elle s'appuie sur le critère de sortie écrit au départ et sur l'avis de ceux qui ont éprouvé et jugé l'outil, distincts de ceux qui l'ont construit.
Par une phrase qui dit ce que le pilote doit avoir démontré, sur quel volume et à quelle date. Si l'équipe ne parvient pas à l'écrire, le blocage tient au cadrage plus qu'à la technique. Pour relire ce critère ensemble sur votre contexte, réservons un échange de 30 minutes.
Votre pilote d'IA attend son passage en production ?
Que vous soyez dirigeant, manager ou DRH, un premier échange permet de clarifier ce que votre pilote doit démontrer avant d'engager la suite.
Réserver un échange découverte (30 min)
