La bascule : du texte à l’action
Tant qu’un système IA produit du texte, une erreur coûte une relecture. Dès qu’il appelle une fonction qui écrit dans votre base, une erreur coûte une correction comptable, un client mécontent, ou un contrôle.
C’est pour cela que la question « chatbot ou agent ? » n’est pas une question de vocabulaire. Elle détermine :
- Ce qu’on mesure. Pour un assistant, la pertinence de la réponse. Pour un agent, le taux d’actions justes, et le coût d’une action fausse.
- Ce qu’on autorise. Un assistant a besoin d’accès en lecture. Un agent a besoin de droits d’écriture, donc d’un périmètre défini action par action.
- Ce qu’on garde. Un agent doit produire un journal exploitable en audit, pas seulement un historique de conversation.
Les quatre briques d’un agent
Un agent utilisable en production tient sur quatre éléments, et l’oubli de n’importe lequel le rend non déployable.
Les outils. La liste fermée des fonctions que l’agent peut appeler, chacune avec son schéma d’entrée validé. Pas d’exécution de code arbitraire, pas de requête libre en écriture. L’agent choisit parmi des actions que vous avez écrites.
L’état. Où en est le dossier, avant et après l’action. Un agent sans notion d’état recommence, duplique, relance deux fois. La lecture de l’état est aussi importante que l’écriture.
Le graphe. Les chemins validés que l’agent est autorisé à suivre, avec les vérifications à passer à chaque étape. C’est ce qui remplace « le modèle décidera bien » par « voilà ce qui est permis ».
Le seuil. Le niveau de confiance en dessous duquel l’agent ne fait rien seul et passe la main. Réglé par usage, pas globalement.
Pourquoi le graphe, plutôt que la liberté
Un agent purement libre, un modèle, une liste d’outils, et « débrouille-toi », fonctionne en démonstration et échoue en production, pour une raison simple : sur les cas standards il trouve un chemin correct, et sur les cas rares il en invente un. Or c’est sur les cas rares qu’un métier a des règles.
Nous décrivons donc l’activité dans un graphe : les états possibles d’un dossier, les transitions permises, les vérifications obligatoires avant chaque transition, et les points où un humain doit valider. L’agent ne devine pas le chemin, il l’exécute. La différence entre une réponse plausible et une action qu’on peut laisser passer en production est là.
Un exemple concret, sur le rapprochement bancaire : les écritures importées passent par l’identification de la contrepartie, puis par un score de confiance. Au-dessus du seuil, l’affectation est automatique. En dessous, le dossier part en file de validation humaine avec la proposition et sa justification. Le graphe complet est visible sur la page du système.
Monter l’autonomie, plutôt que la donner
On ne lâche pas un agent en liberté, on augmente son autonomie par paliers.
| Mode | Ce que fait l’agent | Quand |
|---|---|---|
| À la demande | L’utilisateur demande, l’agent exécute et montre ce qu’il a fait | Dès le premier jour |
| Déclenché | Sur événement ou horaire : l’import de nuit, la relance récurrente | Dès que le mode à la demande est stable |
| Déterministe | Aucune interprétation permise, chemin figé : conformité, facturation, opérations régulées | Quand le workflow est mesuré |
| Autonome | L’agent lit l’état du métier et agit, sous supervision humaine | Une fois la confiance établie sur un volume représentatif |
Un workflow commence flou. On vérifie, on note, et il passe en automatique seulement une fois stable. Cette progression est le seul chemin que nous ayons vu tenir chez des clients qui ont des comptes à rendre.
Ce qu’un agent ne doit pas faire
Trois interdits que nous appliquons systématiquement, parce qu’ils sont la source de la majorité des incidents que nous avons vus ailleurs :
- Exécuter une requête d’écriture libre. Toutes les écritures passent par des fonctions que vous avez écrites, avec leurs contrôles.
- Agir sans que l’action soit annulable ou tracée. Si une action ne peut pas être annulée, elle passe par validation humaine.
- Cacher son incertitude. Un agent qui ne sait pas doit le dire et passer la main, pas produire l’action la plus probable.
Agent, RAG, MCP : comment ça s’assemble
Ces trois briques sont souvent confondues alors qu’elles répondent à des questions différentes.
- Le RAG est comment l’agent sait : il apporte la connaissance de vos documents et de vos données au moment de la décision.
- Le MCP est comment l’agent agit : un protocole standard pour exposer vos fonctions métier comme des outils appelables.
- L’agent est ce qui décide : quel outil, dans quel ordre, jusqu’où sans demander.
Un système sérieux a les trois. Un système qui n’a que le RAG répond bien et ne fait rien. Un système qui n’a que les outils agit vite et se trompe.
Le déployer chez vous
Nos systèmes tournent sur votre infrastructure, une image conteneurisée déployée sur OVH, AWS, GCP ou sur site, avec des modèles locaux quand la souveraineté l’exige, y compris en réseau isolé. La mesure se fait par tenant, ce qui permet aux éditeurs de logiciels de refacturer l’usage à leurs clients.