Une recherche du MIT de 2026 a montré qu’environ 95 pour cent des pilotes GenAI en entreprise ne produisent aucun retour mesurable au compte de résultat, et qu’environ 88 pour cent n’atteignent jamais la production. La cause n’est presque jamais la qualité du modèle. Environ 80 pour cent du travail entre un pilote réussi et un système en fonctionnement relève de l’ingénierie des données, de la gouvernance, de l’intégration aux processus et de la mesure — précisément les parties qu’un pilote type saute. Les organisations qui franchissent l’étape rapportent environ 3,70 dollars pour chaque dollar dépensé, en partant de près de 41 pour cent la première année pour atteindre environ 124 pour cent la troisième.
Pourquoi presque aucun pilote n’atteint le compte de résultat
Le chiffre de 95 pour cent induit en erreur si on le lit comme « les modèles n’ont pas fonctionné ». Dans la plupart des cas, le modèle fonctionnait très bien. Ce qui a échoué, c’est que le pilote a prouvé une chose alors que l’organisation devait en décider une autre.
Un pilote type teste si le modèle sait exécuter une tâche. La décision qui se trouve derrière porte sur le fait de savoir si le processus métier va changer, qui va cesser de faire quoi, comment cela se mesure chaque mois et qui répond quand le système se trompe. Ce sont deux questions entièrement différentes, et c’est la seconde qui apparaît dans les comptes.
C’est aussi de là que vient le fameux partage 80/20. La partie qui ressemble au projet — choisir un modèle, écrire des prompts, faire une démo — représente environ un cinquième du travail. Les quatre cinquièmes restants consistent à nettoyer et exposer les données, à gérer les permissions et la classification de l’information, à se connecter aux outils dans lesquels l’équipe travaille déjà, et à construire la mesure. Un pilote qui n’a touché aucun de ces quatre volets n’a pas réduit le risque. Il l’a seulement repoussé.
Un test à faire avant de commencer. Écrivez en une phrase la décision qui sera prise à la fin du pilote, et le chiffre qui la tranchera. Si vous ne pouvez pas écrire cette phrase, ce que vous préparez est une démonstration, pas un pilote. Les démonstrations sont légitimes — simplement, ne budgétez pas l’une comme l’autre et n’en attendez pas de retour.
Ce que les pilotes mesurent et ce qu’ils devraient mesurer
Cet écart se répète dans presque toutes les organisations, et c’est en général la raison pour laquelle le pilote a réussi et le projet est mort.
| Ce qui est réellement mesuré | Pourquoi cela ne suffit pas | Ce qu’il faut mesurer à la place |
|---|---|---|
| Précision du modèle sur un jeu de test | Le jeu de test a été construit à partir des cas auxquels vous avez pensé, pas du trafic réel | Taux de réussite sur un échantillon aléatoire du dernier mois de trafic réel, cas bizarres inclus |
| Temps gagné, tel que les utilisateurs l’estiment | Les estimations déclaratives sont systématiquement gonflées et n’apparaissent dans aucune ligne budgétaire | Temps de cycle de bout en bout mesuré, avant et après, sur la même classe de tâche |
| Satisfaction dans un sondage | Mesure l’enthousiasme pour la nouveauté, qui retombe après environ six semaines | Taux de retour en semaine six parmi les utilisateurs actifs en semaine une |
| Coût des tokens pendant le pilote | Reflète un faible volume et des cas commodes | Coût par unité de travail à plein volume, reprises, recherche et escalade humaine comprises |
| « L’équipe adore » | Ne distingue pas un simple confort d’un outil dont on ne peut plus se passer | Ce qui se passe si vous le coupez pendant une semaine. C’est le seul test qu’on ne peut pas truquer |
La dernière ligne a l’air désinvolte mais c’est la plus solide de la liste. Un outil que vous pouvez éteindre une semaine sans la moindre plainte ne survivra pas au budget annuel, et il n’y a aucune raison d’y investir un trimestre de plus.
Quatre niveaux de ROI, et un seul compte
Quand un dirigeant demande quel est le retour, il existe quatre réponses possibles et elles ne se valent pas. Savoir les distinguer, c’est ce qui sépare un pilote refinancé d’un pilote arrêté.
| Niveau | Exemple | Apparaît dans les comptes | Quand c’est légitime |
|---|---|---|---|
| Heures gagnées | Chaque agent gagne 40 minutes par jour | Non. Les heures n’ont pas disparu, elles sont passées sur une autre tâche | Uniquement si vous pouvez montrer où sont allées ces heures et ce qui en est sorti |
| Capacité libérée | La même équipe traite 30 pour cent de volume en plus | Indirectement, comme une croissance qui n’a demandé aucun recrutement | Quand il existe une demande réelle pour cette capacité |
| Coût direct supprimé | Moins d’heures de prestataires, un outil externe en moins, moins d’heures supplémentaires | Oui, immédiatement | Toujours. C’est le niveau le plus facile à défendre |
| Revenu ajouté | Plus de leads qualifiés, cycle de vente plus court, moins d’attrition | Oui, avec un décalage d’un à deux trimestres | Quand il existe un groupe de contrôle, ou au moins une base historique propre |
La plupart des pilotes rapportent le premier niveau en espérant qu’il sera lu comme le troisième. Faites l’inverse : construisez le pilote autour du troisième ou du quatrième niveau, même si le périmètre est bien plus petit. Une économie annuelle prouvée de 40 000 dollars vaut mieux qu’un million théorique.
Un pilote de six semaines sur lequel on peut vraiment décider
La structure qui fonctionne est plus courte que ce que la plupart des organisations prévoient et exige davantage en amont.
Semaine 1 — définir la décision et la base de référence. La phrase de décision, le chiffre qui la tranche, et une mesure de l’état actuel sur exactement cette métrique. Sans base de référence mesurée, il n’y a rien à comparer à la fin, et c’est, curieusement, l’étape la plus souvent sautée.
Semaines 2 et 3 — la version la moins chère qui répond à la question. Acheter avant de construire. Les données du marché montrent que démarrer la phase de preuve avec un composant sur étagère produit un ROI 3,2 fois supérieur, et que construire avant de valider fait perdre environ 14 mois en moyenne. Nous avons traité ce point dans construire ou acheter une capacité IA.
Semaines 4 et 5 — trafic réel, utilisateurs réels. Pas un laboratoire. Un groupe défini qui travaille avec l’outil dans son quotidien, cas moches compris et escalades comprises.
Semaine 6 — décider. Étendre, réduire ou arrêter. Les trois issues doivent être également légitimes dès le premier jour, sinon le résultat est connu d’avance.
Le budget de mesure n’est pas optionnel. Allouez au moins 15 pour cent du budget du pilote à la mesure elle-même : collecte de la base de référence, échantillonnage manuel hebdomadaire de la qualité, et suivi du coût par unité de travail. Un pilote sans budget de mesure se termine en dispute sur des impressions, et une dispute sur des impressions tranche toujours en faveur du statu quo.
Quand arrêter un pilote, et pourquoi cela fait gagner de l’argent
Arrêter tôt n’est pas un échec, c’est un mécanisme de rendement à part entière. Quatre signaux justifient l’arrêt avant la sixième semaine.
- Le taux de réussite sur trafic réel est nettement inférieur à celui du jeu de test interne, et l’écart ne se referme pas après deux tours de correctifs. C’est presque toujours le signe que les données ne sont pas dans un état qui permet la tâche.
- Le coût par unité de travail à plein volume dépasse l’alternative humaine. Le prix, le cache et le routage peuvent changer cela, mais si l’écart est un multiple plutôt que quelques dizaines de pour cent, c’est l’architecture qui est en cause, pas la tarification.
- Les utilisateurs reviennent d’eux-mêmes à l’ancien processus, sans qu’on le leur demande. C’est le signal le plus précoce et le plus honnête disponible.
- Personne ne prendra la responsabilité du processus après le pilote. Sans propriétaire, rien n’atteint la production, aussi bons que soient les chiffres.
Une organisation qui arrête deux pilotes par trimestre au bout de six semaines, au lieu de les traîner un an, libère du budget pour la troisième tentative — et c’est précisément le mécanisme qui sépare les organisations affichant 3,70 dollars par dollar de toutes les autres.
D’où vient l’écart entre 41 pour cent et 124 pour cent
Ces deux chiffres décrivent les mêmes organisations à des moments différents, et la différence entre eux n’est pas un meilleur modèle. Ce sont trois choses ennuyeuses.
La première est le coût. La capacité identique devient nettement moins chère avec le cache, le traitement par lots et le routage entre modèles — empiler les trois réduit une facture d’inférence de 60 à 80 pour cent sans rien changer à l’expérience utilisateur. La première année, vous payez plein tarif parce que vous mesurez au lieu d’optimiser.
La deuxième est le périmètre. Le premier cas d’usage résout un problème. La troisième année, la même infrastructure, la même gouvernance et la même classification de l’information servent cinq cas d’usage, et le coût fixe se divise. C’est pourquoi l’investissement dans la couche de données paraît beaucoup trop cher la première année et paraît évident la troisième.
La troisième est le processus lui-même. La première année, l’outil est ajouté à un processus existant : il ajoute donc du coût avant d’en retirer. Ce n’est qu’une fois le processus réécrit autour de lui — des étapes disparaissent, des validations fusionnent, des rôles changent — que le grand retour apparaît. Les organisations qui n’atteignent jamais ce stade restent près de 41 pour cent et concluent que l’IA n’a pas payé.
Les trois reposent sur la même base : un modèle de coût complet de la fonctionnalité, que nous avons exposé dans ce que coûte vraiment une fonctionnalité IA, et une tarification connectée à cette structure de coût, que nous avons traitée dans tarifer un produit adossé à un modèle. Si vous cadrez un pilote en ce moment, définissez les critères d’acceptation dans la même réunion que la décision.
Construire le dispositif de mesure et de décision autour d’un pilote fait partie du travail de planification financière et de croissance que nous menons avec nos clients.
Questions fréquentes
Pourquoi 95 pour cent des pilotes IA échouent-ils ?
Une recherche du MIT de 2026 a montré qu’environ 95 pour cent des pilotes GenAI en entreprise ne produisent aucun retour mesurable au compte de résultat et qu’environ 88 pour cent n’atteignent jamais la production. La cause principale n’est pas la qualité du modèle mais le fait que le pilote a testé une capacité technique au lieu de tester un changement du processus métier. Environ 80 pour cent du travail entre pilote et production relève de l’ingénierie des données, de la gouvernance, de l’intégration aux outils existants et de la mesure — les parties que la plupart des pilotes sautent entièrement.
Combien de temps doit durer un pilote IA ?
Six semaines suffisent pour décider et valent généralement mieux que six mois. Une semaine pour définir la décision et mesurer la base de référence, deux semaines pour la version la moins chère qui répond à la question, deux semaines sur trafic réel avec des utilisateurs réels, et une semaine pour décider. Un pilote plus long ne produit pas plus de certitude. Il rend seulement l’arrêt plus coûteux et politiquement plus difficile.
Comment mesure-t-on le ROI d’un projet IA ?
Séparez quatre niveaux : heures gagnées, capacité libérée, coût direct supprimé et revenu ajouté. Seuls les deux derniers apparaissent au compte de résultat. Mesurez l’état actuel sur exactement la même métrique avant de commencer, comparez le coût par unité de travail à plein volume en incluant les reprises et l’escalade humaine, et allouez au moins 15 pour cent du budget du pilote à la mesure elle-même.
Quand faut-il arrêter un pilote de façon anticipée ?
Dès que l’un des quatre signaux apparaît : le taux de réussite sur trafic réel est nettement inférieur au jeu de test interne et ne se referme pas après deux tours de correctifs, le coût par unité de travail est un multiple de l’alternative humaine, les utilisateurs reviennent d’eux-mêmes à l’ancien processus, ou personne ne prendra la responsabilité du processus après le pilote. Arrêter vite libère du budget pour la tentative suivante, ce qui est le véritable mécanisme de rendement.
Pourquoi le retour passe-t-il de 41 pour cent la première année à 124 pour cent la troisième ?
Trois raisons, dont aucune ne concerne le modèle. Le coût d’inférence baisse de 60 à 80 pour cent une fois le cache, le traitement par lots et le routage entre modèles empilés. Le coût fixe d’infrastructure se divise entre davantage de cas d’usage tournant sur la même gouvernance et les mêmes données. Et surtout, le processus métier est réécrit autour de l’outil au lieu que l’outil soit greffé sur un processus existant — tant que cela n’arrive pas, l’outil ajoute du coût avant d’en retirer.
À lire ensuite
Réduire le coût d’inférence de 60 à 80 pour cent — c’est le levier qui fait passer le rendement de 41 à 124 pour cent : cache, traitement par lots et routage entre modèles.