IA agentique

De la réponse à l'action

Un chatbot rend un texte et s'arrête. Un système agentique poursuit un but : il lit une demande, choisit une étape, appelle un outil, observe le résultat, puis décide de la suite. La boucle se répète jusqu'à un critère d'arrêt ou jusqu'à ce qu'une personne reprenne la main. Les outils peuvent être une recherche documentaire, un tableur, une messagerie ou une API métier existante. Un enchaînement de requêtes prévu à l'avance n'est pas agentique : il manque la décision prise après observation du résultat.

La différence tient à l'initiative. Le modèle ne se contente pas de compléter une phrase, il produit une suite d'actions dont chacune dépend de la précédente. Cela suppose une mémoire de travail, un format d'appel d'outils et des règles de permission. Le protocole MCP, proposé pour décrire ces outils de façon standard, répond à ce besoin de cadre commun entre les modèles et les systèmes déjà en place. Sans ce cadre, chaque intégration réinvente son format d'appel, avec les erreurs que cela suppose.

Où cela devient utile

Les usages rentables concernent rarement des tâches nobles. Trier un flux de courriels, extraire les pièces d'un dossier, préparer une relance, comparer un devis à un tarif catalogue, rassembler des informations dispersées : ce sont des travaux répétitifs, à étapes identifiables, avec un résultat contrôlable. L'agent y apporte de la régularité, pas du jugement. Le gain se mesure en temps de traitement et en oublis évités. Un agent qui trie mille courriels par jour ne remplace personne, mais supprime une tâche que personne n'aime faire.

La condition est que le processus soit déjà décrit. Un agent ne répare pas une organisation floue : il reproduit l'ambiguïté plus vite. Il faut donc cartographier les étapes, nommer les cas d'exception, définir qui tranche. Les projets qui échouent commencent souvent par l'outil et découvrent le processus en cours de route, quand l'ordre inverse donne des résultats plus sûrs. Un processus décrit en une page, avec ses cas normaux et ses exceptions, vaut mieux qu'un cahier des charges interminable.

Les limites à prévoir

Une erreur isolée dans un dialogue se voit. Dans une chaîne de dix étapes, elle se propage et devient difficile à localiser. D'où l'importance des traces : chaque appel d'outil, chaque réponse intermédiaire, chaque décision doit être enregistré. Le coût suit la même pente, puisqu'une boucle peut multiplier les appels sans que personne ne l'ait prévu. Des plafonds d'itérations et de dépense sont nécessaires dès le premier prototype. Une trace lisible par un humain, et non un journal technique, permet de comprendre ce qui s'est passé.

Les permissions méritent le même soin. Un agent qui peut envoyer un courriel, modifier un fichier ou passer une commande doit disposer du minimum nécessaire, sur un périmètre limité. Les actions irréversibles justifient une confirmation humaine. Enfin, tout contenu lu par l'agent, courriel, page web ou pièce jointe, doit être traité comme une source non fiable, susceptible de contenir une instruction hostile. La révocation de ses accès doit rester possible en quelques minutes, sans arrêter le service.