Il y a un problème de vocabulaire dans l'IA d'entreprise
Et ce n'est pas un détail.
Quand un DSI dit "on veut déployer un agent IA", et que son prestataire répond "pas de problème", ils ont souvent en tête deux objets techniques complètement différents. L'un pense à un assistant conversationnel amélioré. L'autre parle d'un système qui prend des décisions autonomes, appelle des APIs, orchestre des sous-processus, et repart de lui-même en cas d'erreur. Ce sont deux choses qui n'ont presque rien en commun, hormis le fait qu'elles tournent sur un LLM.
Cette confusion coûte cher. Gartner estime que 40% des projets d'IA agentique seront abandonnés d'ici deux ans. Deloitte relève que moins d'une entreprise sur dix arrive à déployer ces systèmes en production réelle. Ce n'est pas un problème de technologie. C'est un problème de cadrage.
La seule vraie question : qui tient le volant ?
Pour distinguer ces systèmes, oubliez les features, les prix, et les demos. Posez une seule question : qui contrôle le flux d'exécution ?
Dans une automatisation classique (Make, n8n, Zapier), c'est le développeur qui a tout câblé au design. Le système suit des rails. Si quelque chose sort du rail prévu, il plante et vous prévient. C'est prévisible, transparent, et franchement très utile pour beaucoup de cas d'usage.
Dans un chatbot (ChatGPT, Copilot en mode conversation), c'est l'utilisateur qui guide à chaque tour. Le système réagit. Il ne décide rien seul. La trajectoire est itérative, pas autonome.
Un agent IA, c'est différent. Le modèle reçoit un objectif, et décide lui-même des outils à appeler, dans quel ordre, avec quelle logique. La boucle tourne sans que vous ayez à intervenir entre chaque étape.
Un workflow agentique pousse ça plus loin : plusieurs agents se coordonnent, se délèguent des tâches, réallouent les ressources si un sous-agent échoue. Le modèle ne gère plus une tâche, il gère la coordination entre des tâches.
Plus d'autonomie, plus d'opacité
Plus vous montez dans cette échelle, plus vous gagnez en capacité. Et plus le système devient opaque.
Le paradoxe que personne ne vous dit
Voici quelque chose d'un peu inconfortable : plus un agent est autonome, moins vous comprenez par quel chemin il est arrivé à son résultat.
Un chatbot qui se trompe, vous le voyez tout de suite. Un workflow agentique qui dérive silencieusement, en prenant des micro-décisions légèrement désalignées sur des milliers d'itérations, produit un livrable qui a l'air correct. L'audit humain ne voit rien. Et pourtant, quelque chose cloche.
C'est ce qu'on appelle l'érosion silencieuse. Ce n'est pas un bug spectaculaire. C'est une accumulation de petits glissements qui passent sous le radar parce que le résultat final est plausible.
L'absence d'erreurs visibles n'est pas une preuve de maîtrise.
Et l'amnésie, on en parle ?
Les agents sont excellents sur des tâches courtes. Sur des processus qui durent des heures ou des jours, l'historique se pollue. L'agent commence à oublier les contraintes posées au début. Il reproduit des erreurs antérieures. Il redevient générique.
Même une fenêtre de contexte d'un million de tokens ne règle pas ça, parce que ce n'est pas un problème de volume, c'est un problème de structure. Noyer un agent sous l'intégralité de son journal de bord ne lui donne pas plus de lucidité.
La solution : des points d'arrêt structurés
Imposez des points d'arrêt où le système recompile ce qui a été décidé, l'état exact de l'environnement, et les contraintes du prochain cycle. Pas un dump brut. Une synthèse chirurgicale.
Comment ne pas se faire vendre du "agent washing"
Le terme "agentique" est devenu un argument marketing comme "cloud" l'était en 2012. Si un prestataire vous présente une solution dite agentique, posez-lui trois questions précises.
Adaptabilité : le système peut-il modifier son plan seul face à un obstacle imprévu, sans casser le workflow ? Pas juste gérer une erreur prévue : s'adapter à quelque chose qu'on n'avait pas anticipé.
Interopérabilité : peut-il coordonner plusieurs outils et APIs sans configuration manuelle et rigide en amont ? Sinon, c'est de l'automatisation classique avec un habillage LLM.
Traçabilité : existe-t-il un journal de bord auditable de toutes ses décisions intermédiaires, pas seulement du résultat final ?
Le test décisif
Un seul "non" parmi ces trois, et ce n'est pas un agent.
Adaptabilité et gouvernance ne s'opposent pas
C'est là que beaucoup de projets se perdent. On lit "adaptabilité" et "interopérabilité" et on pense : liberté totale. Puis on lit "gouvernance" et "contraintes" et on pense : rigidité. En réalité, ce sont deux couches qui ne se touchent pas.
L'adaptabilité, c'est la liberté tactique de l'agent : comment il atteint l'objectif, dans quel ordre il appelle ses outils, comment il contourne un obstacle. La gouvernance, c'est la définition stratégique de son terrain de jeu : à quelles données il accède, quelles décisions il peut prendre seul, où il doit s'arrêter et demander une validation humaine.
Un agent bien architecturé est libre dans ses rails. Pas libre de choisir ses rails. C'est cette distinction qui sépare un système fiable d'un système qui fonctionne en démo et dérive en production.
Ce que ça change pour vous
Si vous déployez du vrai agentique, la compétence qui compte n'est pas de savoir construire un agent. C'est de savoir le piloter sur la durée sans qu'il dérive.
Ça implique :
- Une architecture de gouvernance posée avant le premier déploiement
- Des protocoles de passation de contexte entre cycles
- Des limites d'accès définies au cadrage, pas ajoutées après coup
- Une supervision continue, pas parce que l'agent est dangereux, mais parce qu'un système autonome sans observabilité est inutilisable à l'échelle
C'est probablement le chantier le plus sous-estimé des projets IA en ce moment.