Le pilote n’échoue pas à la fin. Il échoue à la première réunion.

Série « Comprendre l’IA », note 8 sur 12. La note 6 donnait l’ordre des étapes et la 7 mettait un prix sur chacune. Celle-ci explique ce qui se passe quand on ne les suit pas, avec ce qu’ont mesuré ceux qui ont étudié des centaines de projets ratés.

Jeudi, 17 h 30, un groupe hôtelier basé à Montreux. Le conseil examine le projet d’IA qu’il a approuvé il y a quatorze mois. Il y a eu un pilote dans un hôtel, avec un assistant qui répondait aux hôtes par chat. Le rapport de l’époque parlait de 92 % de satisfaction. Depuis, on a fait un second pilote dans un autre hôtel, on a changé une fois de fournisseur et on a engagé une personne pour « coordonner l’IA ». Il n’y a aucun hôtel où le système fonctionne en production. Le directeur général propose un troisième pilote, « cette fois avec des agents ». L’administrateur qui suit les finances demande combien on a dépensé. Personne n’a le chiffre sous la main.

La scène est imaginaire. Le schéma, le pilote qui s’enchaîne avec un autre pilote, se répète dans tant d’entreprises qu’il a ses propres études. Dans cette note, je vous donne les chiffres, les cinq causes que ces études retrouvent encore et encore, les symptômes qu’un conseil peut voir sans comprendre la technologie, et la sortie. Si vous avez lu les notes précédentes, vous reconnaîtrez chaque cause : c’est l’étape qui a été sautée.

Un pilote qui n’a pas de date de production n’est pas un pilote. C’est une démonstration coûteuse que l’on renouvelle chaque année.

Les chiffres.

En août 2024, la RAND Corporation a publié un rapport fondé sur 65 entretiens avec des scientifiques des données et des ingénieurs ayant au moins cinq ans d’expérience dans des projets d’IA. Son point de départ était une estimation qu’elle reprend avec prudence : selon certaines estimations, plus de 80 % des projets d’IA échouent, deux fois plus que les projets technologiques sans IA. Un an plus tard, en août 2025, le rapport du projet NANDA du MIT que je citais dans la note 6 l’a mesuré sous un autre angle : 95 % des pilotes d’IA générative n’avaient produit aucun impact mesurable sur le compte de résultat. Et Gartner, en juin 2025, a prévu que plus de 40 % des projets d’agents seraient annulés avant la fin de 2027.

Ce sont trois mesures différentes de la même chose, et il faut les lire avec soin : « échouer » veut dire quelque chose de différent dans chacune, et aucune n’est une expérience contrôlée. Mais la conclusion qu’elles partagent ne laisse aucun doute. La norme, en 2026, c’est qu’un projet d’IA n’arrive pas en production. Si le vôtre y arrive, ce ne sera pas grâce à la technologie. Ce sera pour avoir évité cinq choses.

Cause 1. Personne n’a compris le problème.

C’est la première que la RAND trouve et celle que je vois le plus. Le projet commence par la technologie, « faisons quelque chose avec l’IA », et cherche ensuite un problème auquel l’appliquer. Ou il commence par un problème mal compris : la direction veut réduire les appels au support, l’équipe technique construit un assistant pour y répondre plus vite, et personne ne s’est rendu compte que les appels existaient parce que la facture était confuse. Un assistant qui explique très bien une facture confuse ne réduit pas les appels. Une facture claire, oui, et c’est du logiciel ordinaire, ou du papier.

Le symptôme, depuis la direction : personne ne sait dire, en une phrase, quel chiffre doit changer et de combien. Si la réponse à « que mesure-t-on ? » est « la satisfaction » ou « l’efficacité », le problème n’est pas compris. Dans l’enquête d’IBM auprès de 2000 directeurs généraux de mai 2025, 64 % reconnaissaient avoir investi dans la technologie avant d’en comprendre vraiment la valeur, par peur de prendre du retard. C’est la cause 1 vue d’en haut.

Cause 2. Il n’y avait pas de données, ou elles étaient mauvaises.

La deuxième cause de la RAND est l’absence des données nécessaires pour entraîner ou alimenter le système. Dans l’IA générative d’aujourd’hui, il n’y a presque jamais rien à entraîner, mais il faut donner au modèle les bons documents, et ici reviennent les 3 % de la Harvard Business Review de la note 6 : la plupart des entreprises n’ont pas leurs données en état. L’assistant de l’hôtel de Montreux répondait avec la politique d’annulation de 2022 parce que c’était celle que quelqu’un avait téléversée. Quand un hôte s’est plaint, l’équipe a accusé le modèle.

Le symptôme : le fournisseur demande les documents et l’entreprise met des semaines à les réunir, ou en livre sept versions. L’étape 2 de la note 6 n’a pas été faite, et aucun modèle ne la fait pour vous.

Cause 3. On a construit la technologie et pas l’infrastructure.

La RAND le décrit comme le fait de se concentrer sur la technologie la plus récente plutôt que sur ce qui entoure le modèle : la connexion avec les systèmes de l’entreprise, la journalisation, la gestion des versions, la maintenance. C’est le poste 6 de la note 7, celui que personne ne budgète. Le pilote fonctionnait sur l’ordinateur portable du fournisseur ; la production exigeait qu’il parle au système de réservation, qu’il garde une trace de chaque réponse et que quelqu’un le maintienne. C’était un autre projet, et personne ne l’avait approuvé.

Le symptôme : la démonstration est impressionnante et la question « comment cela se connecte-t-il à notre système de réservation ? » reçoit un « cela se verra dans la phase suivante ». La phase suivante, c’est le vrai projet. Le pilote était la partie facile.

Cause 4. Le problème était trop difficile pour l’IA d’aujourd’hui.

La quatrième cause de la RAND est la plus inconfortable : il y a des problèmes que l’IA actuelle ne résout pas, et les organisations les choisissent parce que ce sont les plus séduisants. Vous vous souvenez de la frontière dentelée de la note 4 et de l’horizon d’une heure de la note 5. Un assistant qui répond aux questions fréquentes d’un hôtel est à l’intérieur de la frontière. Un assistant qui négocie avec un hôte une compensation pour une chambre bruyante, avec du jugement, une politique et un ton, est à l’extérieur. Le pilote de Montreux mesurait la satisfaction sur le premier type de conversation et échouait en silence sur le second, où les hôtes finissaient par appeler la réception.

Le symptôme : la tâche choisie est celle qui fait le plus envie, pas celle qui se répète le plus. Et les 92 % de satisfaction ne disent pas sur quelles conversations ils ont été mesurés.

Cause 5. L’organisation n’a pas changé.

La cinquième cause, que la RAND formule comme l’absence d’une infrastructure de personnes et de processus, est celle qui explique la plupart des pilotes qui fonctionnaient techniquement. Le système est bon ; personne ne l’utilise, ou on l’utilise sans lui faire confiance, ou on l’utilise et personne ne contrôle. C’est l’adoption de 50 % du calcul de la note 7, celle qui transformait six mois de retour en treize. Le cas Klarna que j’ai raconté dans la note 4 en est la version la plus visible : la technologie faisait sa part, et l’entreprise a découvert l’année suivante qu’elle avait retiré les personnes là où il en fallait.

Le symptôme : le projet a un responsable technique et n’a pas de responsable métier avec le chiffre dans son objectif annuel. Quand le pilote se termine, le responsable technique passe au pilote suivant, et le processus se refait comme avant.

Le piège du pilote éternel.

Il y a une sixième cause que la RAND ne liste pas parce que ce n’est pas une cause technique, et que je mets en premier : le pilote n’avait pas de date de production. Un pilote est une expérience avec une question, un délai et une décision à la fin : il passe en production, on le change ou on le ferme. Un pilote sans ces trois choses est un endroit confortable où une organisation peut dire qu’elle « est dans l’IA » sans rien risquer, et où un fournisseur peut facturer des phases. Quatorze mois et trois pilotes, c’est le symptôme complet.

La sortie est mécanique et se trouve dans la note 6 : un processus avec un chiffre qui est mauvais aujourd’hui, cinquante cas de référence, un mode ombre avec une date de fin, un contrôle par paliers et un responsable métier. Le mode ombre, c’est le pilote bien fait : il a une question (« combien en réussit-il sur cent ? »), il a un délai (« quatre semaines ») et il a une décision (« s’il réussit plus de 90 % du sûr et envoie le douteux à des personnes, on allume le 1er du mois »). Il n’est pas plus cher qu’un pilote. C’est un pilote qui se termine.

• Un chiffre avant une technologie. Si l’on ne peut pas dire quel chiffre change et de combien, on n’approuve pas.
• Des documents avant une démonstration. Tant que l’archive n’est pas propre, toute démonstration mesure le fournisseur, pas votre entreprise.
• La production dès le premier jour. La connexion avec vos systèmes, la journalisation et la maintenance se budgètent dans l’offre, pas « dans la phase suivante ».
• À l’intérieur de la frontière. Le processus le plus répété et le plus ennuyeux, pas le plus spectaculaire. Le spectaculaire vient ensuite, avec ce qu’on a appris.
• Un responsable avec le chiffre dans son objectif. Métier, pas technique. Avec l’autorité pour changer la façon dont son équipe travaille.
• Une date et une décision. Tout pilote se termine par l’un de trois mots : allumer, changer ou fermer. Et la date est écrite avant de commencer.

1. Aujourd’hui

   Demandez le chiffre que personne n’avait sous la main

   Combien a été dépensé en IA ces deux dernières années, licences, conseil et heures internes comprises. Comparez-le avec ce qui est en production.

2. Cette semaine

   Faites le test de la phrase

   Pour chaque projet en cours : quel chiffre change, de combien et pour quand. Ce qui ne tient pas en une phrase s’arrête jusqu’à ce que cela tienne.

3. Ce mois-ci

   Transformez chaque pilote en mode ombre avec une date

   Quatre semaines, cinquante cas, un seuil de réussite et l’une de trois décisions à la fin.

4. Ce mois-ci

   Nommez un responsable métier par processus

   Avec le chiffre dans son objectif annuel. Le responsable technique aide ; il ne décide pas.

Comment je l’aborde.

Je ne fais pas de pilotes. Je fais des modes ombre de quatre semaines, avec le chiffre écrit avant et la décision fixée à la fin, et le projet inclut dès le premier jour la connexion, la journalisation et la maintenance, parce que sans elles il n’y a pas de production, il y a une démonstration. Quand une entreprise me montre son troisième pilote, la première chose que je demande, c’est le chiffre de la dépense. Presque toujours, avec ce chiffre, le premier processus de production serait déjà payé deux fois.

Pensez au dernier projet pilote de votre entreprise, d’IA ou d’autre chose. Quelqu’un a-t-il écrit, avant de commencer, quel chiffre il fallait obtenir pour continuer ? Et quelqu’un se souvient-il lequel ?

Si la réponse est non, le pilote n’a peut-être pas échoué. Peut-être n’a-t-il jamais eu de moyen de réussir. Ce qui inquiète, c’est que cette décision a été prise lors de la première réunion, et que presque personne ne se souvient de l’avoir prise.

Note suivante : la loi. Ce que le règlement européen sur l’IA exige de votre entreprise, ce qui change en Suisse, ce que dit la protection des données sur le fait de coller un rapport dans un assistant et les dates qui vous concernent vraiment, sans alarme et sans conseil juridique.