Comprendre les agents IA

Commençons par une image simple : celle d’une fourmi sur une plage. Dans The Sciences of the Artificial, publié pour la première fois en 1969, Herbert Simon décrit une fourmi qui traverse une étendue de sable. Sa trajectoire est irrégulière, sinueuse, très complexe : elle zigzague, contourne des obstacles, ralentit, semble hésiter, puis repart. Vue de loin, on pourrait croire qu’un comportement aussi complexe suppose une stratégie interne extraordinairement sophistiquée. Mais c’est précisément l’illusion que Simon veut dissiper. La complexité du trajet, nous dit-il, ne vient pas d’abord de la fourmi elle-même ; elle vient du relief de la plage, de ses bosses, de ses creux, de ses cailloux - bref de l’environnement dans lequel elle se déplace.

De cette parabole, Simon tire une idée plus générale qui, de mon point de vue, est encore très féconde aujourd'hui : un agent doit se comprendre à l’interface entre une organisation interne et un environnement extérieur. Lorsqu’un système est bien adapté à son milieu, son comportement visible révèle souvent moins sa structure intime que la forme de l'environnement auquel il s’ajuste. L’intérieur, en quelque sorte, s’efface ; il ne redevient saillant que lorsque l’adaptation échoue, lorsque l’environnement change, ou lorsque les limites du système apparaissent.

Simon n’emploie évidemment pas le vocabulaire contemporain des agents LLM. Il appartient même à une tradition intellectuelle très différente, celle de l’intelligence artificielle symbolique. Mais il est en réalité l’un des grands précurseurs de la pensée agentique. Avec Allen Newell et J. C. Shaw, il conçoit le General Problem Solver, un programme capable de décomposer un problème en sous-problèmes, de comparer un état initial à un état visé, puis de rechercher des actions permettant de réduire l’écart entre les deux. On pourrait dire aujourd’hui qu’il s’agit déjà, sous une forme rudimentaire, d’une boucle de perception, de raisonnement et d’action.

L’apport décisif de Simon est cependant moins technique que conceptuel. Tout agent, humain ou artificiel, agit sous contraintes : information incomplète, temps limité, attention bornée ; il agit localement, comme la fourmi sur la plage. Dans ces conditions, il ne cherche pas la solution optimale, mais une solution suffisamment satisfaisante - ce que Simon désigne par le concept de satisficing.

La métaphore de la fourmi me paraît très utile aujourd’hui pour comprendre les agents modernes fondés sur les LLM. Ces modèles, qui se contentaient jusque-là de répondre à un prompt, interagissent désormais avec le monde et se trouvent confrontés à son chaos pour traiter des tâches complexes : ils planifient des suites d'actions, les exécutent, utilisent des outils, échangent avec des humains ou d'autres agents. Des comportements et des trajectoires se dessinent, satisfaisants ou non, que nous observons et que nous sommes très souvent tentés d'attribuer à l’intériorité du modèle (les paramètres appris pendant l'entraînement). Or, une part décisive de ces comportements vient également de l'environnement dans lequel ils opèrent : contexte, mémoires, documents, outils, etc. Mais avant d'aller plus loin, posons d'abord les choses : qu'appelle-t-on exactement un agent aujourd'hui, à l'ère des LLM ?

Les agents fondés sur les LLM  

Il n'y a pas de définition consensuelle du concept d'agent. On a tendance à utiliser le mot agent de manière trop large pour décrire toute automatisation qui fait intervenir quelque part un LLM - un assistant prompté pour une tâche spécifique, un workflow n8n dans lequel intervient un nœud LLM, etc. Je définirais un agent comme un système capable de raisonner, planifier et agir de manière autonome en utilisant des outils afin de traiter une tâche complexe. Les trois verbes importants, ici, sont raisonner, planifier et agir. Raisonner, c’est interpréter un état du monde à partir d’un contexte partiel. Planifier, c’est décomposer une tâche complexe en sous-tâches plus élémentaires. Agir, c'est appeler les outils adaptés pour chercher une information ou modifier un état extérieur. Le mot décisif est cependant l'autonomie. Ce qui caractérise un système agentique n'est pas seulement le fait d'utiliser un LLM, mais le choix de l'action à prendre à chaque étape pour atteindre un objectif - le choix de la trajectoire finalement.

A ce titre, on distinguera notamment les agents des workflows que l'on tend aujourd'hui à confondre. Les workflows sont des systèmes où la séquence d'actions - qui peut comprendre l'appel à un LLM ou d'autres outils - est prédéfinie ; la trajectoire sur la plage est déjà balisée et la fourmi est tenue de la suivre. Un exemple de workflow serait un système qui, chaque matin, récupère les emails non lus, les passe à un LLM qui en extrait un résumé, puis envoie ce résumé sur Slack. La séquence est toujours la même, à chaque fois.

Les agents sont des systèmes où les LLM dirigent dynamiquement leurs propres trajectoires en décidant de la prochaine action à exécuter ; ils dessinent leur propre trajectoire. Un utilisateur formule une demande : "Trouve-moi un vol Paris-Tokyo pour la première semaine de juin, pas trop cher. " L'agent interroge un outil de recherche de vols, compare les résultats, constate qu'un vol avec escale est nettement moins cher qu'un vol direct, décide de proposer les deux options à l'utilisateur, attend sa réponse, puis poursuit. Aucune de ces étapes n'était prédéfinie - c'est l'agent qui a décidé, à chaque moment, de la suite.

La distinction entre les workflows et les agents est cruciale ; elle a des implications profondes, aussi bien sur les pratiques que sur les responsabilités.

L'art de baliser la plage : le context engineering

On sait depuis le premier modèle génératif à l'échelle (GPT-3) que la réponse d'un LLM - la séquence de mots que celui-ci génère - ne dépend pas seulement du modèle ; elle dépend également du contexte fourni par l'utilisateur. Ce sont des systèmes que l'on peut considérer comme des modèles semi-paramétriques. Ils sont dotés de deux mémoires : une mémoire interne, qui est la somme de toutes les informations apprises pendant l'entraînement, encodées sous forme de milliards de paramètres figés ; et une mémoire externe, composée de l'ensemble des informations fournies par l'utilisateur, que l'on appelle généralement le contexte. Mais ces deux mémoires ne s'additionnent pas nécessairement. Les paramètres du modèle ne se contentent pas de puiser des informations complémentaires du contexte ; ils le filtrent, le hiérarchisent et décident de son utilisation. Le contexte est toujours interprété par le modèle, et le comportement du modèle est déterminé par l'interaction entre les les deux. La génération de chaque mot est conditionnée à la fois par la mémoire paramétrique du modèle et le contexte exposé, à l'image de la fourmi dont le pas suivant se décide dans l'interaction entre sa propre mémoire et le relief de la plage.

Si le comportement d'un agent se joue dans l'interaction entre les paramètres du modèle et le contexte fourni, se dégage alors une conséquence pratique : on ne peut améliorer les performances de l'agent en considérant seulement celles du modèle ; il faut aussi - et d'abord - travailler le contexte exposé. C'est pour cela qu'on parle de plus en plus aujourd'hui de context engineering plutôt que de prompt engineering. Car il ne s'agit pas seulement de rédiger une bonne instruction ; il s'agit de concevoir et d'organiser tout l'environnement extérieur avec lequel l'agent est appelé à interagir : le prompt, les documents pertinents, les outils, la mémoire persistante pendant la réalisation de la tâche, etc. Tout ce dont le modèle a besoin pour accomplir sa tâche d'une manière satisfaisante. Andrej Karpathy ne s'y trompe pas quand il définit le context engineering comme "the delicate art and science of filling the context window with just the right information for the next step". Trop peu de contexte : le comportement du modèle est dicté essentiellement par sa mémoire interne, au risque de suivre une trajectoire non souhaitée, d'halluciner ou de faire des choix arbitraires d'actions. Trop de contexte : le modèle se noie. Herbert Simon - toujours lui - nous avait prévenus dès 1971 : "a wealth of information creates a poverty of attention". De manière anecdotique, le mot "attention" se confond ici avec le mécanisme derrière l'architecture technique des LLM. Le modèle, comme tout agent à rationalité limitée, ne peut pas traiter toutes les informations avec la même attention : le signal se noie alors dans le bruit.

Le contexte, pris dans le cadre agentique, est composé de plusieurs briques, dont l'agencement doit être cohérent et bien pensé pour garantir le bon fonctionnement de l'agent.

Le prompt système. C'est l'identité de l'agent - sa raison d'être en quelque sorte : ce pour quoi il a été conçu, ce qu'il sait faire, ce qu'il n'a pas le droit de faire, comment il doit se comporter, etc. Le prompt système ne change pas d'une exécution à l'autre ; il est le cadre stable à l'intérieur duquel l'agent opère.

Les outils. Ce sont les capacités d'action mises à la disposition de l'agent. Ils peuvent prendre la forme de scripts, d'API, d'accès à des documents, etc. Les outils permettent à l'agent d'agir dans le monde réel pour chercher des documents, interroger ou écrire dans des bases de données, envoyer des mails, etc. Le choix des outils exposés fait partie du context engineering : donner trop d'outils à un agent, c'est lui donner trop de directions possibles à chaque pas ; il hésite, se trompe, ou choisit l'outil le plus vraisemblable plutôt que le plus pertinent.

La mémoire de travail. C'est l'historique de la tâche en cours : les actions déjà prises, les résultats obtenus, les erreurs rencontrées. À chaque itération de la boucle, cette mémoire s'allonge. C'est elle qui permet à l'agent de ne pas répéter les mêmes erreurs et d'ajuster sa trajectoire. Mais c'est aussi elle qui, si elle n'est pas compressée ou filtrée, finit par saturer la fenêtre de contexte et diluer l'attention du modèle.

La mémoire bloc-notes. C'est l'espace où l'agent lui-même écrit : il résume ce qui a été fait, note ce qu'il a essayé, ce qui a échoué, ce qui reste à faire. C'est un geste délibéré que l'agent entreprend pour s'organiser quand il est en train de réaliser une tâche complexe qui comporte de nombreuses sous-tâches ; elle lui permet de garder une cohérence dans sa progression. Sans ce bloc-notes, sur une tâche longue, l'agent perd le fil de sa propre trajectoire.

La mémoire persistante. C'est ce que l'agent retient d'une session à l'autre : les préférences de l'utilisateur, les décisions passées, les éléments de contexte durables. Sans elle, chaque interaction recommence à zéro. Avec elle, l'agent peut s'adapter dans le temps. Mais c'est aussi une source de dérive si elle n'est pas entretenue ; des souvenirs obsolètes ou erronés peuvent polluer silencieusement le contexte.

Les connaissances récupérées. Ce sont les informations que l'agent va chercher en cours de tâche : des documents, des extraits de base de connaissances, des résultats de recherche. La qualité de ces informations est déterminante : un agent qui raisonne parfaitement sur des documents mal récupérés produira des résultats parfaitement faux.

Le context engineering est alors cet art et cette science de concevoir ces briques et les assembler pour permettre à l'agent de réaliser des tâches complexes de manière satisfaisante.

Extension du domaine du MLOps

Le MLOps (Machine Learning Operations) désigne un ensemble de pratiques qui permettent d'assurer le déploiement et la maintenabilité des modèles de machine learning en production. Les systèmes agentiques embarquent des modèles de machine learning - les LLM - et il peut sembler donc très pertinent d'appliquer ces pratiques aux systèmes agentiques. Cependant, dans le MLOps traditionnel, l'objet central est le modèle - sa dérive, sa version, son environnement. Dans le cas des systèmes agentiques, l'objet d'exploitation est beaucoup plus large. Le modèle n'interagit pas seulement avec des données d'inférence ; il interagit avec des prompts, des outils, des mémoires et des documents. Par conséquent, il ne suffit pas de versionner le modèle et l'environnement technique (les dépendances) ; il faut également versionner les prompts système, les outils et leurs documentations, les schémas de mémoire, pour assurer le bon fonctionnement du système.

Par ailleurs, l'observabilité et l'évaluation même du système change de nature. Dans le MLOps traditionnel, la sortie du modèle est un point unique, que l'on peut comparer à des données de référence, calculer une métrique de performance bien déterminée et conclure sans trop d'ambiguïté si le modèle est performant ou non. Dans le MLOps agentique, la sortie n'est pas un point, mais une trajectoire : une sortie pour chaque étape. Deux exécutions avec la même requête utilisateur peuvent impliquer deux trajectoires différentes. Et pour des tâches très complexes, qui font intervenir de multiples actions possibles, il peut même y avoir des trajectoires cachées non désirables dont la sortie finale est pourtant satisfaisante. Une évaluation robuste doit concerner aussi bien la sortie finale que les étapes intermédiaires avec différents scénarios. Le MLOps, dans cette optique, devient un monitoring de comportements plutôt que de métriques.

L'extension du MLOps touche également la mémoire. Les agents modernes ne sont plus seulement des systèmes qui répondent à une requête ; ils peuvent maintenir un état persistant entre les sessions - typiquement, des notes de session sont consolidées en mémoire globale, puis réinjectées dans le contexte avec des règles, pour améliorer les performances de l'agent. Il faut donc également intégrer des règles de mémoire, des cycles de consolidation et des sources de vérité contextuelles. Par ailleurs, lorsque plusieurs agents collaborent, la question se complique encore davantage : quelles informations partager entre eux ? Un agent qui a identifié une contrainte doit-il la rendre visible aux autres ? et sous quelle forme ? Une mémoire partagée mal conçue peut engendrer un contexte bruité, coûteux, voire propager les erreurs d'un agent à un autre. Une mémoire trop cloisonnée, où chaque agent travaille dans sa bulle peut engendrer une perte d'information, des doublons et des incohérences. C'est un problème de coordination que le MLOps traditionnel n'avait jamais eu à affronter.

La DSI comme architecte du terrain

Le rôle de la DSI était jusque-là structuré autour d'un mandat clair et relativement stable : fournir, sécuriser et maintenir l'infrastructure sur laquelle les métiers opèrent. L'arrivée du machine learning classique avait déjà déplacé les lignes. Les modèles prédictifs ont obligé les équipes IT à composer avec les objets moins déterministes et le MLOps a poussé les équipes à briser certains silos. Avec l'arrivée de l'IA agentique, le déplacement requis est d'un autre ordre. Jusque-là, la DSI fournissait des outils à des humains qui agissaient et prenaient les décisions. Avec les systèmes agentiques, elle doit également fournir des outils et du contexte à des systèmes qui agissent. La DSI ne conditionne plus l'efficacité et la qualité du travail humain ; elle conditionne également le comportement des agents. Un outil mal documenté, une base de connaissances périmée, un accès manquant, ce ne sont plus des irritants pour un utilisateur humain qui saura résoudre ou contourner le problème ; mais des déformations du terrain qui infléchissent directement la trajectoire de l'agent.

Les systèmes agentiques embarquent généralement une logique métier. Celle-ci est fournie dans le contexte, à travers des documents, des skills, une mémoire persistante - autant d'objets qui doivent être monitorés et maintenus par les équipes techniques. Il ne s'agit plus d'assurer les conditions de travail pour les équipes métiers ; mais de veiller également à la bonne intégration de leurs règles et connaissances dans les systèmes agentiques. La DSI doit assurer également le bon fonctionnement des agents en organisant le terrain : exposer le patrimoine applicatif en API et serveurs MCP, gérer les outils, les accès aux ressources et aux bases de données, maintenir des bases de connaissances, veiller à l'optimisation de la consommation de tokens, etc. La DSI devient alors l'architecte du terrain pour les agents. Ce rôle est bien plus stratégique que celui auquel elle est habituée jusque-là. Comme les modèles tendent à se standardiser et s'homogénéiser en termes de performances, l'avantage ne peut venir que de la qualité de préparation du terrain, qui devient ainsi un véritable actif. Ce qui fait la différence entre deux fourmis poursuivant le même objectif est la nature de leurs terrains respectifs. L'infrastructure de l'entreprise devient cognitive.

Cependant, tous les terrains ne présentent pas le même relief. Un système agentique n'est pas un bloc monolithique qui raisonne uniformément ; il est composé de sous-tâches de natures très différentes. Certaines tâches sont intrinsèquement complexes et nécessitent des capacités de compréhension et de raisonnement très avancées (analyser des données complexes, décomposer un problème, etc.) ; elles requièrent des modèles puissants, à l'état de l'art. Tandis que d'autres tâches, sont plus élémentaires et plus simples (parser un JSON, valider un ticket, etc.) ; de petits modèles, que l'on appelle généralement les SLM (Small Language Models), sont largement suffisants pour les traiter. Le mot "suffisant" n'est pas anodin ici ; il est à prendre au sens simonien (satisficing). La question n'est pas tant de savoir quel est le meilleur modèle ; mais plutôt le modèle suffisant pour une tâche donnée. Utiliser un modèle à l'état de l'art, avec des milliers de milliards de paramètres, pour traiter une tâche élémentaire est un non-sens en termes de latence et de coûts, financiers et écologiques. Se dessine alors un nouveau rôle pour la DSI : le routage cognitif. C'est elle qui doit cartographier les capacités nécessaires à chaque tâche, évaluer quels modèles sont satisfaisants et organiser le routage.

Par ailleurs, ces systèmes agentiques sont appelés à exécuter des tâches de plus en plus complexes. Cela suppose une surface d'exposition bien au-delà du prompt ; le LLM interagit de manière autonome avec d'autres ressources comme les API, les bases de données, le CRM - c'est-à-dire avec le patrimoine informationnel de l'entreprise. Confier tout cela à une API propriétaire, c'est confier à un tiers non seulement les entrées, mais la matière sur laquelle l'agent raisonne. La question de la souveraineté se pose alors avec plus d'acuité. Au-delà des considérations liées à la confidentialité, les API propriétaires sont instables ; les modèles, les filtres et les outils apparaissent et disparaissent au gré de leurs fournisseurs.

Les modèles open source (ou open weights, plus exactement) constituent alors une alternative quand il s'agit d'interagir avec des ressources sensibles. Un modèle déployé en interne est figé, versionné, auditable ; ses paramètres ne changent que lorsqu'on décide, au niveau de l'entreprise, de le faire. Les SLM, en particulier, rendent le déploiement local économiquement viable. Un modèle de quelques milliards de paramètres nécessite une configuration et des ressources en calcul très raisonnables. L'open source et le routage selon la confidentialité des données et la complexité de la tâche agissent sur le même levier. Mais la souveraineté a également un prix, notamment des compétences techniques spécifiques pour la mise en place de tels modèles, leur adaptation et leur mise à jour.

Une autonomie sans responsabilité

L'autonomie est au cœur de la définition même d'un agent. Celui-ci ne suit pas un script - une trajectoire prédéfinie - ; il dessine lui-même la sienne. Mais il s'agit d'une autonomie purement fonctionnelle, sans sujet. L'agent prend des décisions, agit sur le monde, le modifie ; mais il n'engage pas sa peau - il n'en a pas. Pour atteindre l'objectif qui lui a été assigné, il choisit en toute autonomie les moyens à mettre en œuvre. Or c'est précisément dans le choix des moyens que se loge la question morale. Un humain, normalement, met en balance la fin et les moyens ; il sait que tous les chemins ne se valent pas d'un point de vue éthique. L'agent, lui, ne considère pas ces contraintes spontanément ; si les règles ne sont pas dictées explicitement dans son contexte, il privilégiera l'efficacité. Un agent chargé de maximiser la rétention client peut décider d'envoyer des relances agressives à des personnes vulnérables ; l'objectif est vertueux, mais la trajectoire ne l'est pas.

La responsabilité devient alors diffuse. Faut-il imputer l'erreur au modèle qui a mal raisonné ? Au fournisseur qui l'a entraîné et aligné ? Au contexte qui était insuffisant ? À l'outil qui a renvoyé une information erronée ? À la base de connaissances qui était périmée ? Au prompt système qui n'explicitait pas les contraintes éthiques ? Chaque composant du terrain peut avoir contribué à la dérive, et aucun ne l'a décidée seul. C'est un problème de causalité distribuée que les cadres juridiques et organisationnels existants ne savent pas encore traiter.

Si l'agent ne peut pas répondre de ses décisions, quelqu'un doit le faire. La tentation naturelle est de réintroduire l'humain dans la boucle - le fameux human-in-the-loop. Mais la question est : où exactement dans la boucle ? et pour faire quoi ? Valider chaque action de l'agent revient à détruire le bénéfice même de l'autonomie ; on retombe sur un workflow déguisé, où l'humain devient un goulot d'étranglement qui approuve mécaniquement des décisions qu'il n'a plus le temps d'examiner. Ne rien valider, c'est accepter une autonomie sans contrôle et reporter la responsabilité sur celui qui a conçu le système, sans lui donner les moyens d'anticiper toutes les trajectoires possibles. Le vrai enjeu est quelque part entre les deux ; il est de concevoir des seuils de délégation et d'autonomie : pour quelles classes de décisions l'agent est-il autorisé à agir seul ? À partir de quel niveau de risque, d'ambiguïté ou d'irréversibilité doit-il solliciter une validation humaine ? Un agent qui résume un document peut agir seul. Un agent qui envoie un mail à un client entre dans une zone grise. Un agent qui modifie une donnée dans un système de production ou qui engage une dépense exige un garant. Ces seuils ne sont pas des paramètres techniques que l'on règle une fois ; ce sont des décisions organisationnelles, souvent éthiques, qui doivent être négociées entre les métiers, la DSI et la direction.

L'autonomie de l'agent pose un problème supplémentaire, celui de la sécurité. Un agent qui interagit avec des outils, des bases de données, des API, dispose de capacités d'action sur le monde réel. Or ces capacités peuvent être détournées par une manipulation de son contexte. C'est le problème du prompt injection : un contenu malveillant, inséré dans un document, un email, un champ de base de données, peut amener l'agent à exécuter des actions qui n'étaient pas prévues par son concepteur. L'agent ne distingue pas une instruction légitime d'une instruction injectée ; pour lui, tout ce qui entre dans le contexte fait partie du terrain et conditionne donc la trajectoire.

Ce risque est de nature différente par rapport à la cybersécurité classique. Dans un système traditionnel, une attaque exploite une faille technique ; dans un système agentique, la surface d'attaque est le langage naturel lui-même. Tout document ingéré par l'agent peut contenir une instruction hostile. Ce sont des risques nouveaux, qui interrogent la séparation même entre le rôle de la DSI et celui du RSSI. Plus largement, c'est l'organisation elle-même qui est interpellée. La gouvernance des systèmes agentiques ne peut pas être distribuée entre des silos qui se renvoient la responsabilité : les métiers pour la logique, la DSI pour l'infrastructure, le RSSI pour la sécurité, le juridique pour la conformité. Un agent traverse tous ces périmètres à chaque trajectoire. Sa gouvernance exige une fonction intégrée, capable de penser ensemble le terrain, les limites de l'autonomie, la sécurité du contexte et la responsabilité des décisions.