Un distributeur industriel de 40 personnes disposait d’un agent IA de devis fonctionnel en une semaine. Il lisait une demande d’achat entrante, rapprochait les lignes de commande d’une liste de prix et rédigeait un devis qui semblait prêt à partir. Le directeur commercial était conquis sur-le-champ. Huit mois plus tard, l’agent dormait toujours dans un dossier de test, et l’équipe établissait ses devis comme depuis dix ans.
Rien ne clochait dans le modèle. Le raisonnement tenait la route, et chaque demande d’exemple que le développeur lui soumettait revenait impeccable. Ce qu’il n’avait pas encore fait, c’était survivre au contact du terrain : l’ERP qu’il devait interroger, les exceptions tarifaires que personne n’avait jamais écrites, et une équipe commerciale qui n’allait pas envoyer à un client un chiffre dont elle ne pouvait pas se porter garante.
Cet écart porte désormais un nom : le dernier kilomètre de l’IA. C’est la distance entre un modèle qui brille en démo et un système qu’une entreprise fait tourner, sans supervision, sur du travail réel. La plupart des projets IA qui s’enlisent en silence ont un modèle qui fait son travail. Là où ils échouent, c’est sur tout ce qui doit se passer après.
Le chiffre que tout le monde cite, et ce qu’il mesure vraiment
Une étude du MIT largement citée a mis un chiffre sur ce phénomène : environ 95 % des pilotes d’IA générative en entreprise n’ont montré aucun impact mesurable sur le compte de résultat. Le rapport attribuait ce déficit à un « learning gap » dans la façon dont les outils étaient adoptés et intégrés, plutôt qu’à une faiblesse des modèles.
Le chiffre s’est répandu vite, et les critiques aussi. La plupart visaient la méthodologie : l’étude reposait sur quelques centaines d’entretiens et une revue de déploiements publics, des termes comme « pilote » et « impact sur le P&L » n’ont jamais été définis rigoureusement, et une étude qui ne mesure que le retour financier immédiat sous-estimera les progrès dans les workflows où le gain arrive d’abord en erreurs évitées ou en cycles raccourcis avant d’atteindre le compte de résultat. Traitez ces 95 % comme un signal approximatif sur l’endroit où les projets IA se bloquent, pas comme un fait établi à citer en conseil d’administration.
Ce qui survit à la critique, c’est la direction du constat, et elle correspond à ce qui s’observe régulièrement sur le terrain. Le goulot d’étranglement a rarement grand-chose à voir avec la capacité du modèle à accomplir la tâche en principe. Il tient presque toujours à tout ce qu’il faut pour qu’il l’accomplisse de manière sûre et répétée, au sein de systèmes qui existaient bien avant l’achat d’une licence IA.
Combler cet écart relève normalement d’un travail d’ingénierie soutenu, ancré dans le fonctionnement de l’entreprise, plutôt que d’un déploiement ponctuel. C’est la prémisse d’un service d’ingénierie IA embarquée : une présence technique qui reste au cœur du workflow jusqu’à ce que le système fasse ses preuves, au lieu d’une livraison unique.
Ce que « le modèle fonctionne » ne vous dit pas
Une démo répond à une seule question : le modèle peut-il produire une bonne sortie avec une entrée propre et bien formée ? C’est un signal réel et utile. C’est aussi une petite fraction de ce que la production exige.
Voici ce qui sépare une démo fonctionnelle d’un logiciel qu’une entreprise laisse tourner sans surveillance :
- Les systèmes de référence. Le modèle a besoin d’un accès direct et authentifié à ce qui détient la vérité : l’ERP, le CRM, la base tarifaire, la GED. La plupart de ces systèmes exposent des API, mais la couverture est inégale, les limites de débit sont réelles, et « dispose d’une API » n’équivaut pas à « un agent peut lire et écrire de façon fiable les données dont il a besoin ».
- La longue traîne des demandes réelles. Appelez ça les 20 % désordonnés, un ordre de grandeur plutôt qu’une mesure : les entrées malformées, les lignes ambiguës et les cas limites qu’un jeu de démo trié sur le volet ne montre jamais, mais qui surgissent dès que le volume réel arrive.
- Une suite d’évaluation. Un moyen documenté et reproductible de répondre à « est-ce que ça fonctionne toujours ? », au-delà de l’intuition après quelques contrôles ponctuels.
- Permissions et sécurité. Un compte de service avec juste assez d’accès pour faire le travail et pas plus, validé par le responsable de la sécurité, avec une réponse claire sur ce qui se passe quand l’agent touche des données qu’il ne devrait pas voir.
- L’insertion dans le workflow. L’agent doit se glisser dans la façon dont les gens travaillent aujourd’hui : qui relit ses sorties, à quel moment du processus, et que se passe-t-il quand il se trompe ?
- La confiance des équipes. La plus difficile à planifier. Des personnes échaudées par un mauvais chiffre ou un outil qui promettait trop ne délégueront pas leurs arbitrages simplement parce que l’ingénierie affirme que la précision est bonne.
Chacun de ces points peut bloquer un projet à lui seul. En pratique, ils se cumulent : corriger l’intégration ERP fait remonter des problèmes de qualité de données, ce qui change ce que la suite d’évaluation doit vérifier, ce qui change ce que l’équipe commerciale accepte de valider sans relecture.
Pourquoi les chatbots génériques et les copilotes sur étagère calent ici
C’est aussi pourquoi acheter une licence de chatbot généraliste ou un copilote sur étagère comble rarement l’écart à lui seul. Ces outils résolvent la moitié « modèle » de l’équation et vous laissent toute l’autre moitié.
| Chatbot générique / copilote | Un système qui a franchi le dernier kilomètre | |
|---|---|---|
| Accès à vos systèmes de référence | Généralement aucun, ou un plugin superficiel | Accès authentifié et cadré, construit pour le workflow visé |
| Gestion des cas limites | Se rabat sur une supposition plausible | Signale ce qu’il ignore et escalade |
| Évaluation | Benchmarks éditeur sur des tâches génériques | Une suite de tests bâtie sur vos propres cas historiques |
| Sécurité et permissions | Des droits larges et génériques par défaut | Moindre privilège, validé par votre équipe IT |
| Confiance des équipes | Gagnée nulle part en particulier | Gagnée sur vos propres données avant le go-live |
Un assistant généraliste peut rédiger un devis d’apparence plausible. Il n’a aucun moyen de vérifier ce devis contre votre liste de prix, votre stock actuel ou la remise que votre direction financière a approuvée le trimestre dernier pour ce compte précis. Il ne peut pas vous dire quand il devine. L’écart tient à ce pour quoi un produit générique est conçu ; la qualité du raisonnement n’y est pour presque rien.
Un distributeur de 40 personnes apprend la différence à ses dépens
Retour à l’agent de devis du début. L’entreprise est un cas composite, bâti sur des schémas récurrents chez des distributeurs comparables qui automatisent la prise de devis, et elle montre comment les six chantiers ci-dessus se déroulent sur un projet réel.
La démo a demandé environ une semaine à un développeur, et elle était bonne : extraction propre des spécifications depuis l’e-mail d’un client, un brouillon correctement formaté, des prix plausibles sur la poignée de demandes utilisées pour la construire.
Puis le projet a rencontré la réalité de l’entreprise, de quatre manières distinctes.
La liste de prix comportait des exceptions que personne n’avait documentées. Environ un cinquième des demandes réelles impliquait un SKU abandonné avec un substitut officieux, un supplément de fret régional appliqué de façon incohérente selon qui traitait la commande, ou une remise de lot dont un commercial se souvenait et un autre non. Rien de tout cela ne figurait dans la liste de prix de référence de la démo.
L’intégration ERP était le vrai projet. Les prix courants et les niveaux de stock vivaient dans un ERP, pas dans la feuille de calcul exportée utilisée pour la démo. S’y connecter signifiait mapper des champs, négocier des limites de débit d’API et gérer le fait qu’un prix en cache pouvait dériver en silence de ce que l’ERP affichait une minute plus tard.
L’équipe commerciale ne lui faisait pas confiance, à raison. Les commerciaux avaient déjà été échaudés par un outil de tarification qui avait envoyé un mauvais chiffre à un client. Ils voulaient voir et approuver chaque brouillon avant qu’il n’atteigne le client, et un moyen simple de corriger tout ce qui semblait anormal. La conception devait traiter cette exigence comme un contrôle légitime, pas comme une friction à automatiser.
Le jeu d’évaluation est venu de 200 devis historiques. Plutôt que de se fier à « ça m’a l’air bon », l’équipe a extrait 200 devis passés, en a caviardé les données clients et s’en est servie comme référence : l’agent reproduit-il la même logique tarifaire, attrape-t-il les mêmes exceptions, signale-t-il les mêmes lignes qu’un humain aurait signalées ? C’est ce jeu de tests, bien plus que la démo initiale, qui a permis au directeur commercial de valider, à terme, le fonctionnement de l’agent sans relecture pour la catégorie de devis la plus simple.
L’agent finalement mis en service, des mois plus tard, tournait sur le même modèle que la démo de la première semaine. La différence, c’était tout ce qui l’entourait : une connexion à l’ERP, une liste d’exceptions documentée, un workflow d’approbation réclamé par l’équipe commerciale et une suite de tests bâtie sur l’historique de l’entreprise. La démo n’a jamais été la partie difficile.
Ce que franchir le dernier kilomètre exige vraiment
Quelques pratiques reviennent systématiquement dans les projets qui traversent cet écart.
Le développement piloté par les évaluations. Construisez le test avant la fonctionnalité. Hamel Husain soutient que les équipes qui sautent cette étape finissent incapables de dire si un changement a amélioré ou dégradé le système, et chaque décision suivante devient une supposition. Extraire un échantillon représentatif de cas historiques réels et définir à quoi ressemble une réponse correcte, avant d’écrire la logique de l’agent, change tout le processus de construction : vous construisez vers une cible mesurable plutôt que vers une démo qui a juste l’air convaincante.
Le context engineering sur les données réelles de l’entreprise. Anthropic décrit le context engineering comme la curation des informations mises à la disposition du modèle au moment de l’inférence, par opposition à la simple rédaction d’un bon prompt. Appliqué à un système d’entreprise, cela signifie ancrer le modèle dans vos propres listes de prix, votre correspondance passée et l’historique des comptes plutôt que dans sa connaissance générale d’entraînement, et choisir délibérément ce qu’il voit et ce qui ne ferait qu’ajouter du bruit.
Les architectures hybrides. Les systèmes les plus fiables ne demandent pas à un modèle de langage de faire respecter des règles métier strictes. Un prix plancher, un seuil d’approbation, une exigence de conformité : tout cela relève d’un code déterministe qui passe ou échoue, sans place pour l’interprétation. Le travail du modèle, c’est la partie qui exige réellement du jugement, comme lire une demande ambiguë ou rédiger un texte qu’un humain relira. Séparer clairement les deux est ce qui rend le comportement d’un agent assez prévisible pour lui faire confiance à grand volume.
Quelqu’un d’organisationnellement proche du travail. Les spécifications ratent des choses. La personne qui traite les suppléments de fret chaque jour connaît une exception que le cahier des charges ne mentionne jamais, et le découvrir en semaine deux coûte bien moins cher qu’après le go-live. Les projets qui réussissent ont généralement quelqu’un, collaborateur interne ou ingénieur du prestataire travaillant sur site avec l’équipe, assez proche du workflow pour repérer ce genre de lacune avant qu’elle ne devienne un incident de production.
Rien de tout cela n’est exotique. C’est plus proche d’une pratique disciplinée du génie logiciel que de quoi que ce soit de spécifique aux grands modèles de langage. La différence, c’est que les projets IA sautent souvent ces étapes parce que la démo avait l’air si convaincante que les sauter semblait sans risque.
Pourquoi cela produit toujours le même modèle de delivery
Regardez où les fournisseurs qui ont le plus d’expérience de déploiement d’IA en entreprise ont mis leur argent, et un schéma apparaît. En juin 2026, AWS a engagé un milliard de dollars dans un programme de forward deployed engineering, en plaçant des ingénieurs directement chez les clients et les partenaires qui les servent, pour combler des écarts d’intégration comme ceux décrits plus haut. Salesforce s’est engagé à constituer une équipe de 1 000 ingénieurs dédiés pour sa gamme Agentforce, pour la même raison. OpenAI a formalisé une fonction similaire au sein de sa propre organisation en 2025.
Ce n’est pas une coïncidence. Si la partie difficile d’un projet IA est l’intégration aux systèmes, la gestion des cas limites et la confiance des équipes plutôt que la qualité du modèle, alors le modèle de delivery doit garder les ingénieurs près du métier jusqu’à ce que cette confiance soit gagnée, ce qui prend bien plus de temps que de livrer une démo. C’est un arrangement commercial différent de l’achat d’un logiciel sur étagère, et il mérite d’être compris pour lui-même : voir Qu’est-ce qu’un forward deployed engineer ? pour le fonctionnement réel de ce rôle et de ce modèle de delivery.
Ce diagnostic est aussi plus étroit que la question de savoir pourquoi les projets d’agents IA échouent en premier lieu. Beaucoup de projets n’amènent jamais un modèle fonctionnel jusqu’à une vraie démo, pour des raisons étrangères au dernier kilomètre : un périmètre indéfini, pas de responsable côté métier, pas de méthode convenue pour mesurer le succès avant de construire. Pourquoi les projets d’agents IA échouent couvre ce risque au niveau du projet, avec une checklist pour l’éviter. Cet article suppose que vous avez franchi cette barre et pose la question suivante : votre modèle fonctionne, alors pourquoi ne fait-il pas encore tourner l’entreprise ? La réponse, presque à chaque fois, ce sont les six chantiers qui séparent une démo de la production, et il faut bien que quelqu’un fasse ce travail.
Questions fréquentes
Qu'est-ce que le problème du dernier kilomètre de l'IA ?
C'est l'écart entre un modèle d'IA qui performe bien en démo ou en preuve de concept et un système qui tourne de manière fiable dans les workflows réels d'une entreprise. Le raisonnement du modèle est généralement au point quand la démo est livrée ; ce qui manque, c'est l'intégration aux systèmes réels, le traitement des cas limites désordonnés, une suite d'évaluation, des permissions correctes, l'insertion dans le workflow et la confiance des équipes. Combler cet écart est un projet logiciel et organisationnel plutôt qu'un problème de modélisation.
Est-il vrai que 95 % des pilotes IA échouent ?
Une étude du MIT largement citée rapportait qu'environ 95 % des pilotes d'IA générative en entreprise ne montraient aucun impact mesurable sur le compte de résultat, et attribuait ce déficit principalement à des lacunes d'intégration plutôt qu'à la qualité des modèles. L'échantillon et les définitions de l'étude ont été contestés par d'autres chercheurs ; traitez donc ce chiffre comme un signal directionnel sur l'endroit où les projets IA se bloquent plutôt que comme un référentiel sectoriel précis.
Pourquoi les chatbots IA génériques ou les copilotes sur étagère sous-performent-ils au travail ?
Ils arrivent sans aucune connaissance des listes de prix, des systèmes de référence, de la gestion des exceptions ou des règles d'approbation d'une entreprise donnée. Un assistant générique peut rédiger un texte plausible, mais il ne peut pas vérifier un chiffre dans votre ERP, signaler une demande qui sort de votre politique de remise, ni gagner la confiance d'une équipe déjà échaudée par une mauvaise réponse.
Que faut-il concrètement pour franchir le dernier kilomètre de l'IA ?
En pratique : une suite d'évaluation bâtie sur des cas historiques réels avant de confier de nouveaux cas à l'agent, du context engineering qui ancre le modèle dans vos propres données plutôt que dans sa connaissance générique, une architecture hybride où le code déterministe fait respecter les règles strictes pendant que le modèle gère les arbitrages, et quelqu'un d'assez proche du travail quotidien pour repérer ce qu'un cahier des charges ne voit pas.
En quoi le problème du dernier kilomètre diffère-t-il d'un projet IA simplement mal cadré ?
Les deux se recoupent, mais ce ne sont pas les mêmes échecs. Un mauvais cadrage est un risque organisationnel qui peut couler un projet avant la moindre ligne de code. Le problème du dernier kilomètre suppose que le périmètre et le modèle sont tous deux raisonnables et pose une question plus étroite : pourquoi un modèle qui fonctionne techniquement met-il encore des mois à devenir un logiciel que l'entreprise fait réellement tourner sans surveillance ?