La plupart des projets d’agents IA n’échouent pas bruyamment. Ils échouent silencieusement – une démo qui a impressionné le comité de direction, un pilote qui a tourné pendant trois mois, un canal Slack qui finit par devenir silencieux. Personne n’annule officiellement le projet. Il cesse simplement d’être mentionné lors des revues de roadmap.
Le rapport State of AI 2025 de McKinsey chiffre ce phénomène : 62% des organisations expérimentent avec des agents IA. Seules 23% les déploient réellement à l’échelle. C’est dans l’écart entre ces deux chiffres que la majorité des budgets IA disparaissent silencieusement.
Les prévisions de Gartner sont encore plus directes : plus de 40% des projets d’IA agentique seront abandonnés d’ici fin 2027 – non pas parce que la technologie ne fonctionne pas, mais en raison de coûts qui dérapent, d’une valeur business mal définie et de contrôles de risque insuffisants.
Ce n’est pas un problème technologique. C’est un problème de méthode. Et une fois qu’on l’a observé plusieurs fois, il devient prévisible.
The pattern: what a stalled pilot actually looks like
Le schéma : à quoi ressemble un pilote bloqué
Une fois les détails mis de côté, la plupart des projets d’agents IA bloqués partagent la même structure.
Une équipe – souvent la DSI, parfois un chef de produit motivé avec une ligne budgétaire – construit un proof of concept en s’appuyant sur une API LLM standard. Cela fonctionne lors de la démo. Le système répond aux questions que l’équipe avait pensé à tester. La direction est impressionnée. Un communiqué de presse est parfois rédigé, voire envoyé.
Puis vient la réalité de la production. Les données dont l’agent a besoin vivent dans six systèmes différents, dont la moitié ne sont pas documentés. Le workflow « simple » qu’il devait automatiser comporte en réalité quatorze cas particuliers que personne n’avait mentionnés en réunion de lancement. La conformité demande qui est responsable lorsque l’agent se trompe, et personne n’a de réponse claire.
Six mois plus tard, le pilote est toujours un pilote. Pas parce que quelqu’un a décidé de l’arrêter – parce que personne n’a décidé de continuer non plus.
Trois éléments qui distinguent les agents qui passent en production de ceux qui restent au placard
Lors des appels de découverte que nous menons avec des entreprises évaluant des partenaires en agents IA, les trois mêmes écarts reviennent – quasiment indépendamment du secteur ou de la taille de l’entreprise.
1. Aucune fondation de données structurée
C’est de loin le point d’échec le plus fréquent, et il reste invisible jusqu’à ce que le pilote soit déjà en cours.
Une équipe construit un prototype performant sur un jeu de données propre et soigneusement sélectionné – une poignée de documents témoins, une base de test bien organisée. Les résultats sont excellents. Puis on le confronte à l’environnement réel : des dossiers SharePoint avec trois conventions de nommage différentes, un ERP avec des formats de champs incohérents, des contrats dispersés entre fils d’e-mails et drives partagés sans aucune métadonnée.
L’agent n’est pas défaillant. La fondation de données sous-jacente n’a jamais existé sous une forme qu’un agent – ou honnêtement, un nouvel employé – pourrait exploiter de manière fiable.
Nous avons mené plusieurs appels de découverte avec des entreprises ayant déjà testé un « premier pilote » utilisant une API LLM généraliste directement sur leurs documents bruts, sans couche de récupération, sans stratégie d’indexation, sans cartographie des droits d’accès. Le pilote semblait prometteur la première semaine. À la quatrième semaine, l’équipe avait discrètement cessé de faire confiance à ses réponses.
2. Des chatbots passifs au lieu de workflows intégrés
Le second écart est architectural, pas technique. De nombreux pilotes de première génération sont construits comme une fenêtre de chat greffée sur les systèmes existants – un endroit où les employés peuvent poser des questions, sans véritable connexion aux workflows où les décisions se prennent réellement.
Le résultat est un outil que les gens essaient une fois, trouvent modérément intéressant, puis oublient. Il répond aux questions. Il n’agit pas – il ne déclenche pas d’approbation, ne met pas à jour un enregistrement, ne signale pas une anomalie pour révision.
Les agents qui survivent jusqu’en production sont conçus dans le sens inverse : intégrés directement au workflow, avec des entrées, des sorties et des chemins d’escalade clairement définis. Un agent qui vérifie une facture et la route pour approbation lorsque quelque chose semble anormal résout un problème différent d’un chatbot qui peut répondre à des questions sur les factures si on le sollicite gentiment.
3. La gouvernance traitée comme un sujet secondaire
Le troisième écart apparaît plus tard, mais s’avère souvent fatal une fois rencontré. Un pilote qui fonctionnait bien à petite échelle se heurte à un mur dès que le juridique, la conformité ou la sécurité posent les questions évidentes : qui a autorisé cet agent à accéder à ces données ? Que se passe-t-il en cas d’erreur ? Existe-t-il une piste d’audit ? Cela respecte-t-il le RGPD ou l’AI Act européen ?
Si ces questions sont posées pour la première fois après que le pilote a montré des résultats prometteurs, les réponses ne sont généralement pas prêtes – et le projet stagne pendant que l’organisation se précipite pour adapter une gouvernance à une architecture qui n’a pas été conçue pour cela.
Les agents construits avec validation humaine intégrée, traçabilité complète et hébergement conforme UE dès le premier jour ne rencontrent pas ce mur. Ils ont été conçus pour le franchir dès le départ.
À quoi ressemble un modèle de workflow agentique
L’alternative au chatbot greffé est ce que nous appelons un modèle de workflow agentique : un agent conçu autour d’un processus métier spécifique dès le départ, et non adapté après coup à une pile technologique existante.
La différence se manifeste de trois manières concrètes :
L’agent a un périmètre défini, pas un mandat ouvert. Au lieu de « répondre à toute question sur nos documents », le brief devient « vérifier les factures entrantes par rapport aux bons de commande et signaler les écarts au-delà d’un seuil défini ». Un périmètre restreint permet d’évaluer l’agent selon des critères de réussite clairs dès la première semaine.
L’agent se connecte aux systèmes, pas seulement à une fenêtre de chat. Il lit l’ERP, y écrit en retour, déclenche une notification lorsqu’une révision humaine est nécessaire. Le workflow ne change pas pour s’adapter à l’agent – l’agent est construit pour s’adapter au workflow existant.
Les décisions de l’agent sont traçables dès le départ. Chaque action est enregistrée. Chaque escalade inclut le raisonnement qui l’a déclenchée. Quand la conformité demande « que s’est-il passé ici et pourquoi », la réponse existe déjà – elle n’a pas besoin d’être reconstituée après coup.
C’est aussi pourquoi un proof of concept de quatre semaines, correctement délimité, tend à surperformer un pilote ouvert de six mois. Un périmètre restreint avec des exigences de données claires et une métrique de succès définie permet soit de valider le cas d’usage, soit de l’écarter rapidement – au lieu de dériver dans le pilot purgatory pendant deux trimestres avant que quelqu’un n’admette l’échec.
Vous voulez voir à quoi ressemble ce processus de bout en bout ? Consultez notre guide pour mettre en œuvre l’automatisation IA dans votre entreprise, y compris comment choisir le bon cas d’usage pilote et à quoi ressemble un calendrier réaliste de 4 à 8 semaines.
Un schéma récurrent dans nos appels de découverte – anonymisé, mais cohérent
Un schéma revient suffisamment souvent pour mériter d’être nommé : une entreprise de taille moyenne lance un pilote initial en connectant une API LLM généraliste directement à ses documents internes – sans architecture de récupération, sans couche de contrôle d’accès, sans chemin d’escalade défini. Le pilote démontre que « l’IA peut répondre à des questions sur nos politiques internes ». Il ne démontre pas que les réponses sont fiables, auditables ou délimitées selon ce que chaque employé devrait réellement pouvoir voir.
Six mois plus tard, le pilote est toujours un pilote. L’entreprise a dépensé un budget et construit un scepticisme interne envers l’IA en tant que catégorie – non pas parce que l’idée de départ était mauvaise, mais parce que la première tentative a été conçue comme une démo, pas comme une infrastructure de production.
Lorsque nous reconstruisons ces projets, le point de départ n’est presque jamais « construire un modèle plus intelligent ». C’est « construire la fondation de données et la couche de gouvernance que la première version n’a jamais eues » – puis délimiter un pilote restreint et mesurable au-dessus de cette base. La technologie n’a jamais été le goulot d’étranglement. C’était la fondation.
Comment éviter le pilot purgatory : une checklist pratique
BAvant de délimiter votre prochain pilote d’agent IA, quatre questions méritent une réponse honnête :
La fondation de données est-elle réellement prête ? Pas « avons-nous les données quelque part » – sont-elles structurées, accessibles via API, et cartographiées selon les droits d’accès qui devraient régir qui (ou quoi) peut les consulter ?
Le pilote est-il délimité sur un seul processus mesurable – ou sur une capacité ouverte ? « Automatiser la vérification des factures pour nos 10 principaux fournisseurs » est un pilote. « Rendre notre base de connaissances interrogeable par IA » est un projet de recherche déguisé en pilote.
La gouvernance est-elle intégrée dès la conception, ou prévue pour plus tard ? Si la conformité, le juridique et la sécurité n’ont pas examiné l’architecture avant le démarrage du pilote, ils l’examineront après – à un coût bien plus élevé en temps et en confiance.
L’agent s’intègre-t-il dans un workflow réel, ou se contente-t-il de répondre à des questions ? Si la métrique de succès est « les gens trouvent ça intéressant », c’est un projet différent de « cela réduit le temps de traitement de X% ». Un seul des deux survit à une revue budgétaire.
Si vous ne pouvez pas répondre clairement aux quatre questions, ce n’est pas une raison d’abandonner le projet – c’est précisément le point de départ. Un POC correctement délimité de 4 semaines est conçu pour répondre exactement à ces questions avant d’engager davantage de budget.
Pour les entreprises françaises éligibles : la mise en œuvre d’agents IA via ITSharkz peut être éligible au Crédit d’Impôt Recherche / Crédit d’Impôt Innovation (CIR/CII), soit une réduction de 30% sur les dépenses qualifiées. ITSharkz dispose de l’agrément CIR/CII.
→ Découvrez comment ITSharkz conçoit et construit des agents IA prêts pour la production – de la fondation de données au déploiement.
Résumé
L’écart entre 62% qui expérimentent et 23% qui déploient à l’échelle n’est pas un écart technologique. C’est un écart de fondation – dans les données, dans l’architecture et dans la gouvernance.
Trois points à retenir :
- La plupart des pilotes n’échouent pas parce que le modèle est faible. Ils stagnent parce que la fondation de données sous-jacente n’a jamais été construite pour supporter un usage en production.
- Un chatbot qui répond à des questions est un produit différent d’un agent intégré à un workflow. Seul le second survit à une revue budgétaire.
- Une gouvernance intégrée dès le premier jour est plus rapide, pas plus lente. Adapter la conformité après coup à une architecture qui n’a pas été conçue pour cela – voilà ce qui tue réellement les calendriers.
Si vous évaluez par où commencer, notre guide pour mettre en œuvre l’automatisation IA détaille comment choisir le bon cas d’usage pilote et à quoi ressemble un calendrier de production réaliste.
Échangez avec ITSharkz sur la délimitation d’un pilote conçu pour atteindre la production – pas seulement pour impressionner lors d’une démo.
→ Planifier un appel
