Il y a une scène que je connais par cœur. Une équipe présente un assistant d’IA générative, un LLM branché sur la documentation interne. La démonstration est brillante, les questions trouvent leurs réponses, la direction applaudit. Trois semaines de travail. Puis quelqu’un demande : « On le met en production quand ? » Et le silence qui suit dure parfois six mois.
Ce silence n’est pas une anomalie. Le rapport du MIT publié en 2025 sous le titre The GenAI Divide estime que 95 % des pilotes d’IA générative en entreprise n’ont aucun impact mesurable sur le compte de résultat, malgré 30 à 40 milliards de dollars investis. Gartner prévoyait dès juillet 2024 qu’au moins 30 % des projets d’IA générative seraient abandonnés après la preuve de concept avant fin 2025, pour quatre raisons : données de mauvaise qualité, contrôles de risque insuffisants, coûts qui dérapent, valeur métier floue. Aucune de ces raisons n’est technique. Toutes sont organisationnelles.
Le prototype ment un peu
Un prototype fonctionne parce qu’il a été construit pour fonctionner. Les documents ont été choisis, les questions aussi, et la personne qui pose les questions sait ce qu’elle cherche. La production, c’est l’inverse : des documents en vrac, des utilisateurs qui n’ont rien demandé et des questions formulées de travers.
Le problème n’est donc pas le modèle. Sur les cas que nous voyons, changer de fournisseur de modèle déplace rarement le résultat de plus de quelques points. Ce qui déplace le résultat, c’est le travail que personne ne veut faire : trier, dater, nommer un responsable, mesurer.
La donnée d’abord, le prompt ensuite
Le premier chantier est toujours documentaire. Les sources sont dupliquées, périmées ou contradictoires. Deux procédures décrivent le même processus avec des versions différentes, et l’assistant choisit l’une ou l’autre selon la formulation de la question. Un utilisateur qui reçoit une réponse fausse une fois ne revient pas.
Avant de toucher au moindre prompt, il faut donc construire un référentiel propre : une source par sujet, un propriétaire nommé, une date de validité, un processus de mise à jour. Ce travail prend des semaines, il est ingrat, et il est la condition de tout le reste. C’est aussi un travail que les métiers doivent porter avec la data : personne d’autre ne sait quelle procédure est la bonne.
Mesurer avant d’optimiser
La deuxième erreur classique consiste à améliorer l’assistant à l’intuition. Un dirigeant essaie trois questions, trouve une réponse bancale, et l’équipe passe une semaine à réécrire le prompt. Le lendemain, une autre personne trouve un autre défaut. On tourne en rond.
La sortie de ce cercle passe par un jeu de questions de référence, deux cents suffisent souvent, validé par les métiers, avec la réponse attendue. Chaque changement de modèle, de prompt ou de découpage des documents est évalué automatiquement contre ce jeu. On ne discute plus d’impressions, on lit un score. Et l’on affiche le coût par requête à côté, parce qu’un assistant qui coûte trois fois plus pour deux points de qualité n’est pas une amélioration.
Il faut aussi accepter un fait inconfortable : les utilisateurs se méfient, et ils ont raison. L’enquête 2025 de Stack Overflow auprès des développeurs, pourtant les premiers utilisateurs de ces outils, montre que 46 % d’entre eux se disent méfiants quant à l’exactitude des réponses de l’IA, contre 33 % qui leur font confiance. Un assistant qui ne cite pas ses sources et n’admet jamais qu’il ne sait pas ne franchira pas ce mur de défiance.
L’adoption est un travail, pas un résultat
Le rapport du MIT dit une chose que je trouve juste : les 5 % de projets qui réussissent ont choisi des cas d’usage précis, souvent en back-office, là où la friction existait déjà, et ont mesuré le changement de la façon de travailler plutôt que le nombre de licences activées.
Sur le terrain, cela veut dire choisir un premier usage étroit, avec des utilisateurs volontaires, un canal de retour simple et des corrections visibles chaque semaine. Le jour où les utilisateurs commencent à corriger eux-mêmes les documents sources parce qu’ils ont vu l’assistant se tromper, l’outil est adopté. Avant, c’est un gadget de direction.
On ne déploie pas un assistant. On installe une habitude, et une habitude se construit avec des gens, pas avec une licence.
Cédric Gérard, Directeur Associé
Sécurité et coûts : les deux sujets que l’on repousse
Deux chantiers sont systématiquement remis à plus tard, et ils reviennent toujours au pire moment. La sécurité d’abord : quelles données partent vers le modèle, où sont-elles hébergées, qui peut interroger quoi, comment gère-t-on les données personnelles et les secrets glissés dans un document. Ces questions relèvent du RGPD et de la politique de sécurité, pas d’un réglage technique, et elles se traitent avant la première ouverture aux utilisateurs.
Les coûts ensuite. L’inférence se paie à l’usage, et l’usage explose quand l’outil plaît. Le rapport Flexera 2026 sur le cloud note que le gaspillage estimé des dépenses cloud repart à la hausse, à 29 %, en partie à cause de la complexité introduite par l’IA. Sans suivi du coût par requête et par équipe, un assistant interne devient une ligne de facture que personne ne pilote. C’est le même réflexe que le FinOps appliqué au cloud : un propriétaire, un budget, une revue.
Ce que nous en retenons chez Voxalia
Notre pôle Data & IA n’arrive pas avec un modèle miracle. Il arrive avec une méthode et des personnes qui ont déjà vu ces projets échouer et réussir : cadrage d’un cas d’usage précis, chantier documentaire porté par les métiers, jeu de tests de référence, suivi des coûts, sécurité traitée en amont, et un accompagnement des utilisateurs qui dure après la mise en production. Parce que l’IA révèle les limites des profils plus qu’elle ne les remplace, nous choisissons d’abord les personnes qui décident.
C’est moins spectaculaire qu’une démonstration en trois semaines. C’est aussi la seule façon que nous connaissions de passer du côté des 5 %.
Questions fréquentes
Pourquoi les projets d’IA générative échouent-ils en entreprise ?
Rarement à cause du modèle. Le MIT relève l’absence d’impact mesurable pour 95 % des pilotes ; Gartner cite la qualité des données, les contrôles de risque, les coûts et une valeur métier floue. Ce sont des décisions d’organisation, pas des limites techniques.
Combien de temps faut-il pour mettre un LLM en production ?
Comptez plusieurs mois après un prototype de quelques semaines : le référentiel documentaire, le jeu de tests de référence, la sécurité et l’accompagnement des utilisateurs prennent l’essentiel du temps.
Quelles données peut-on confier à un LLM ?
Celles que la politique de sécurité et le RGPD autorisent : pas de données personnelles sans base légale, pas de secrets dans les documents indexés, et un hébergement dont on connaît la localisation. Ces questions se règlent avant la première ouverture aux utilisateurs.
Sources
- MIT NANDA, The GenAI Divide: State of AI in Business 2025, présenté par Forbes dans MIT finds 95% of GenAI pilots fail because companies avoid friction.
- Gartner, communiqué du 29 juillet 2024, Gartner predicts 30% of generative AI projects will be abandoned after proof of concept by end of 2025.
- Stack Overflow, 2025 Developer Survey, section AI (46 % de méfiance, 33 % de confiance dans l’exactitude des réponses).
- Flexera, State of the Cloud Report 2026 (gaspillage cloud estimé à 29 %).
