La démo que tout le monde a adorée
22 août 2026
Près de la moitié des preuves de concept en IA sont abandonnées avant d’atteindre la production. Très peu ont échoué. La plupart ont fonctionné. Dans des conditions qui n’allaient jamais se reproduire.
Mars, puis dix-huit mois
La démo se passe bien. Elle se passe toujours bien. C’est le propre d’une démo. Le comité directeur est sincèrement impressionné, convient qu’il faut mettre ça en production, et demande un plan.
Puis le plan rencontre l’édifice. Le pilote tournait sur un extrait que quelqu’un avait nettoyé à la main pendant deux fins de semaine. Les données de production comportent les huit pour cent embêtants dont personne n’avait parlé. La révision de sécurité a une file d’attente et prend quatre mois. Les deux ingénieurs qui l’ont bâti sont bons, ce qui explique qu’on les ait déjà affectés ailleurs. Le système dans lequel il doit écrire appartient à une équipe qui n’a jamais été dans la salle. Et vers le onzième mois, le commanditaire change de poste, et le nouveau demande, raisonnablement, pourquoi on dépense encore là-dessus.
Rien de dramatique ne se produit. Aucune décision d’annulation, aucun post-mortem, aucune leçon consignée. C’est l’éléphant que nous appelons Pilote : un succès en vase clos qui n’atteint jamais la production, ni les résultats financiers.
Les preuves
Près de la moitié ne franchissent jamais la frontière
46 %
des preuves de concept en IA sont abandonnées avant même d’atteindre la production
S&P Global Market Intelligence, 2025 — sondage auprès de plus de 1 000 organisations en Amérique du Nord et en Europe. Cité par l’intermédiaire de CIO Dive, une source secondaire nommée : le rapport primaire n’est pas récupérable publiquement, ces chiffres portent donc une dévaluation à un saut de vérification.
Un taux d’abandon de 46 %, n’est-ce pas simplement ce à quoi ressemble l’expérimentation ?
C’est la bonne objection et elle mérite une réponse franche : oui, les expériences sont censées mourir. Une organisation dont toutes les preuves de concept atteignent la production ne réussit pas, elle est timide. Elle ne tente que ce dont elle savait déjà que ça marcherait. Une preuve de concept qui établit à peu de frais qu’une idée ne tient pas est un bon résultat, et 46 % n’aurait rien de remarquable si c’était ce que ce chiffre décrivait.
Or ce n’est surtout pas le cas, et c’est la distinction que le chiffre global masque. Deux populations entièrement différentes cohabitent dedans. La première : des expériences qui ont échoué de façon instructive. Le modèle n’était pas assez juste, les données n’appuyaient pas la thèse, l’économie ne tenait pas. Ce sont des gains, acquis à bon compte.
La seconde : des pilotes qui ont fonctionné et n’ont quand même pas été livrés. Ceux-là n’ont rien appris à l’organisation, sinon qu’elle n’arrive pas à faire franchir à quoi que ce soit la frontière entre la démonstration et l’exploitation. Cette leçon n’est jamais consignée, alors on la réapprend l’an prochain avec une autre technologie. Le chiffre qui mérite d’être présenté à un conseil n’est pas combien de preuves de concept ont été abandonnées. C’est combien des abandonnées avaient déjà fait leurs preuves.
Pourquoi la frontière est-elle si difficile à franchir ?
Parce qu’un pilote est, par conception, dispensé de presque tout ce que la production exige. Ce sont ces dispenses qui l’ont rendu assez rapide pour être approuvé. Il obtient les meilleures personnes disponibles plutôt que celles qui l’exploiteront. Il obtient des données triées à la main et discrètement réparées. On lui permet de sauter l’intégration, parce qu’un écran suffit à faire la démonstration. Il tourne hors des processus de conformité et de sécurité, au motif raisonnable que rien de réel n’est encore en jeu. Et on l’autorise à ignorer les cas limites, qui en production ne sont pas des limites du tout mais une fraction permanente du volume.
Chacune de ces dispenses est sensée prise isolément. Ensemble, elles font que le pilote n’a pas testé ce qui était incertain. Ce qui était incertain n’a jamais été de savoir si la technologie pouvait produire le résultat. Un fournisseur vous l’aurait montré. Ce qui était incertain, c’est de savoir si cette organisation-ci, avec ces personnes, ces données et ces contrôles, peut l’exploiter un mardi ordinaire.
Les dispenses expirent donc toutes en même temps, et le travail reporté devient le vrai projet : plus gros que le pilote, non budgété, et désormais porté par celui qui a la malchance de l’avoir entre les mains.
Comment savoir si le Pilote est dans votre salle ?
La signature est un projet qui n’échoue jamais et ne finit jamais.
- Une preuve de concept a été déclarée réussie, et personne ne peut dire ce qu’elle est devenue.
- Les données du pilote ont été préparées à la main, et personne n’a chiffré ce que ça coûterait en continu.
- Les gens qui l’ont bâti ne sont pas ceux qui l’exploiteraient, et on ne l’a jamais envisagé autrement.
- La sécurité, la conformité et l’équipe propriétaire du système sont convoquées après la démo plutôt qu’avant.
- L’organisation a mené plusieurs pilotes sur le même thème d’une année à l’autre, chacun repartant de zéro.
Faut-il donc cesser de faire des pilotes ?
Non. Changez ce à quoi sert le pilote. Cessez de vous en servir pour savoir si la technologie fonctionne, la question sur laquelle vous êtes le moins incertain et que la démo d’un fournisseur tranche déjà. Servez-vous-en pour savoir si vous pouvez l’exploiter.
Concrètement, cela veut dire retirer délibérément les dispenses plutôt que d’en profiter. Des gens ordinaires plutôt que l’équipe la plus forte disponible. De vraies données, fraction embêtante incluse. L’intégration réelle, même sommaire. La conversation de conformité au départ, quand elle est bon marché, plutôt qu’au quatrième mois, quand elle est un mur. Un pilote bâti ainsi est moins impressionnant en mars et infiniment plus instructif, parce que lorsqu’il fonctionne, vous avez déjà démontré la seule chose qui faisait doute.
C’est pourquoi nous définissons ainsi l’étape du milieu d’un mandat : le projet pilote est la formation. Si les personnes qui exploiteront la chose ne sont pas celles qui la démontrent, alors ce qui a été démontré ne se transfère pas, et vous avez acheté une démonstration plutôt qu’une capacité.
Comment faire sortir le Pilote de la salle ?
Les trois mêmes gestes que nous appliquons à chaque éléphant, pointés sur celui-ci.
Cartographier
Faites l’inventaire du cimetière avant de commander quoi que ce soit de neuf. Pour chaque preuve de concept des deux dernières années : a-t-elle fonctionné, et a-t-elle été livrée ? Les quatre cases de cette grille vous disent si vous avez un problème de technologie, de sélection ou de franchissement. Les organisations sont d’ordinaire très sûres de savoir lequel, et d’ordinaire dans l’erreur.
Démontrer
Menez le prochain dans les conditions de la production dès la première semaine : les gens qui l’exploiteront, les données telles qu’elles arrivent, l’intégration réelle, et la conformité dès le départ. Définissez « terminé » comme un mois de fonctionnement entre les mains de ses propriétaires. Ça paraîtra plus lent que la démo dont vous avez l’habitude. C’est la seule version qui finit.
Passer à l’échelle
Étendez ce qui a survécu au contact d’un mardi ordinaire, et consignez ce que le franchissement a coûté, parce que ce montant est ce qui rendra honnête la prochaine analyse de rentabilité. Une organisation qui connaît son propre coût de franchissement cesse de confondre une démonstration avec une décision.
Découvrez ce que sont devenues vos preuves de concept
The Elephant Safari nomme votre troupeau en dix questions et le classe selon ce qu’il vous coûte. Ou partez plutôt du problème d’affaires : avoir payé pour de l’IA que personne n’utilise. Sortez le Pilote de la salle. Prouvez que vous pouvez l’exploiter.
Chaque chiffre de cet article remonte à une source primaire. La voir dans Savoir