Agent IA en entreprise : ce qui marche, ce qui échoue

Un agent est un programme qui décide d’enchaîner des appels à des outils pour atteindre un but formulé en langage naturel. La définition contient déjà le risque : ce qui rend un agent utile — sa latitude — est aussi ce qui rend son comportement difficile à garantir. Tout le travail consiste à réduire cette latitude jusqu’au point où le service devient prévisible, sans le rendre inutile.

Ce qui marche

Les réussites diffèrent par leur objet et se ressemblent par leur préparation. Quelques traits reviennent, et aucun ne porte sur le choix du modèle.

Un périmètre étroit et mesurable

Les projets qui aboutissent partent d’une tâche que l’on sait décrire en une phrase, avec un critère de réussite écrit avant la première ligne de code : la demande est classée dans la bonne file, la réponse contient la référence du dossier, le document est extrait sans intervention. Un périmètre étroit permet de constater un progrès ; un périmètre large permet seulement d’en discuter.

Des données déjà propres

Un agent branché sur une base à jour, dont les champs ont un sens stable, produit des réponses exploitables dès les premiers essais. Branché sur un dossier partagé où cohabitent quatre versions d’un même tarif, il produit des réponses fausses avec exactement la même assurance. Le modèle n’arbitre pas entre deux vérités contradictoires : il en choisit une. Quand la donnée n’est pas prête, la remettre en ordre est le projet — l’agent vient après.

Une reprise humaine explicite

Les agents qui durent savent s’arrêter. Un seuil de confiance, des motifs d’escalade, un bouton de reprise : la conversation passe à une personne, avec l’historique et un résumé, sans que l’utilisateur ait à répéter sa demande. La reprise n’est pas un aveu d’échec, c’est ce qui rend l’automatisation acceptable pour ceux qui devront vivre avec.

Des journaux dès le premier jour

Sans traces, impossible de savoir pourquoi une réponse a été produite, donc impossible de l’améliorer. Nous enregistrons dès la première version l’entrée reçue, les outils appelés, leurs paramètres, leurs résultats et la décision finale. C’est aussi ce qui permet de répondre à la question qui suit toujours un incident : combien de fois cela s’est-il produit, et depuis quand ?

Un cas d’usage où l’erreur coûte peu

Pour un premier agent, mieux vaut une tâche dont l’erreur se rattrape en une minute qu’une tâche qui engage l’entreprise. Trier, résumer, préparer un brouillon, proposer un classement : l’acte final reste humain. La confiance se construit sur ce terrain, puis le périmètre s’élargit. Jamais l’inverse.

Un propriétaire côté entreprise

Un agent sans propriétaire dérive : les consignes vieillissent, les données changent de forme, les cas non prévus s’accumulent sans que personne ne les regarde. Les projets qui tiennent ont, chez le client, une personne identifiée qui relit les journaux, tranche les cas limites et décide quand élargir le périmètre. Ce rôle demande peu de temps ; il n’est pas facultatif pour autant.

Ce qui échoue

Les échecs se ressemblent bien davantage, et ils sont rarement techniques. Cinq motifs reviennent.

• L’agent « qui fait tout ». Un assistant censé répondre à la clientèle, rédiger les devis, relancer les impayés et alimenter le CRM échoue partout à la fois, et personne ne sait dire où.
• Le branchement sur des données que personne ne maintient. Un connecteur ne répare pas un référentiel abandonné : il en diffuse les erreurs plus vite et plus loin.
• L’absence de critère de réussite. Sans seuil défini à l’avance, l’évaluation se réduit à des impressions, et le projet s’arrête au premier désaccord.
• La démonstration jamais mise en production. Un prototype validé en réunion, puis laissé de côté faute de propriétaire, de budget d’exploitation ou d’accès réels aux systèmes.
• La confusion entre démonstration impressionnante et service fiable. Dix cas choisis réussissent toujours ; ce sont les cas non choisis qui décident du sort du projet.

Ces cinq échecs ont une racine commune : la latitude laissée à l’agent n’a jamais été bornée, ni par le périmètre, ni par les données, ni par un critère. Ce n’est pas un défaut de modèle, et un modèle plus récent ne le corrige pas.

Un dernier motif, plus discret, mérite d’être cité : l’agent livré sans budget d’exploitation. Un service qui appelle un modèle a un coût récurrent, des versions qui changent sous lui et des consignes à réviser. Le traiter comme un projet qui se termine, plutôt que comme un service qui s’exploite, revient à programmer son abandon.

Les garde-fous qui tiennent

1. Un jeu d’outils restreint. L’agent n’accède qu’aux fonctions nécessaires à sa tâche, en lecture par défaut, avec des écritures nommément autorisées.
2. Une validation humaine avant toute action irréversible : envoi vers l’extérieur, écriture en base, engagement commercial, suppression. L’agent prépare, une personne confirme.
3. L’aveu d’ignorance rendu possible, et même valorisé. Un agent doit pouvoir signaler qu’il ne dispose pas de l’information et passer la main ; sans cette issue, il comblera le vide.
4. Des limites d’exécution : nombre d’étapes, durée, coût par tâche. Une boucle qui s’emballe doit s’arrêter d’elle-même, pas être découverte sur une facture.
5. Un jeu de cas de test figé, rejoué à chaque changement de consigne, d’outil ou de modèle. C’est le seul moyen de savoir qu’une amélioration n’a rien cassé ailleurs.

Aucun de ces garde-fous n’est propre à l’IA : ce sont ceux de n’importe quel service qui écrit dans des systèmes de production. C’est précisément parce qu’un agent semble converser que l’on oublie de les lui appliquer.

Démarrer petit, et pour de bon

La bonne première itération ressemble rarement à ce qui a été imaginé en réunion. Elle prend une tâche réelle, souvent ingrate, choisie parce qu’elle revient chaque jour et parce que son résultat se vérifie. Elle est mise entre les mains de ses utilisateurs pendant quelques semaines, avec ses journaux, sa reprise humaine et son critère de réussite.

Trois issues sont possibles, et les trois sont utiles : le service tient et le périmètre s’élargit ; le service tient mais l’usage ne suit pas, et le besoin était donc ailleurs ; le service ne tient pas, et l’on sait à quel maillon — la donnée, la consigne, l’outil ou le cadrage. Un projet arrêté au bout de trois semaines pour une raison identifiée coûte bien moins cher qu’un chantier défendu par principe pendant six mois.

Un agent n’est pas un produit que l’on installe, c’est un service que l’on exploite.

C’est pourquoi nous commençons toujours par regarder l’existant : les données réellement disponibles, les outils déjà en place, la personne qui reprendra la main, et ce qui se passe le jour où la réponse est fausse. La technologie vient ensuite, et elle est rarement le point difficile.