Un agent d’IA équivaut à un modèle d’IA associé à une sangle de contrôle : quelle est la fonction de cette sangle et pourquoi ?
Un agent est un modèle associé à une sangle de contrôle. Découvrez comment ces sangles ajoutent des outils, de la mémoire, des boucles et des garde-fous, en quoi diffèrent les agents à poids ouvert et open source, et pourquoi les évaluations sont importantes.
Pendant un certain temps, l’histoire des progrès de l’intelligence artificielle a été racontée à travers les mises à disposition de nouveaux modèles : des modèles de base de plus en plus grands et performants qui apparaissaient tous les quelques mois. Cette histoire est incomplète. Un modèle de langage, qu’il soit grand ou petit, fournit une intelligence brute, mais la mesure dans laquelle cette intelligence parvient à l’utilisateur dépend du logiciel qui l’entoure. Ce logiciel est appelé un « harness », et de nombreuses études montrent qu’il peut être tout aussi important que le modèle lui-même. Des recherches récentes sur l’adaptation de ces « harness » à des modèles plus petits indiquent qu’un « harness » soigneusement ajusté peut permettre à un modèle compact de retrouver une grande partie des performances d’un modèle avancé pour les tâches professionnelles, à un coût bien moindre. Consultez les chiffres exacts dans les articles originaux, mais la tendance est cohérente avec ce que constatent les professionnels : le modèle le plus puissant ne produit pas toujours le système le plus performant.
Ainsi, la compétition porte de plus en plus sur celui qui conçoit le meilleur système d’accompagnement, et non seulement sur celui qui crée le modèle le plus grand.
Pourquoi un modèle intelligent a encore besoin d’un système d’accompagnement
Un modèle de langage peut produire une réponse. Seul, il ne peut pas parcourir un dossier, choisir parmi des outils, conserver une mémoire de travail entre les appels, vérifier ce qu’il a écrit, se remettre d’une erreur ou continuer à travailler vers un objectif. Ce sont ces lacunes que les agents existent pour combler. Dans un agent, un système d’accompagnement entoure le modèle et transforme son intelligence en actions structurées, reproductibles et orientées vers un objectif.
Modèle contre agent
Un modèle prend une entrée et produit une sortie, puis sa tâche est terminée. Un agent continue de travailler après la première réponse. Il lit des fichiers, utilise des outils, exécute des commandes, se souvient des résultats précédents, prend des décisions et poursuit à travers plusieurs étapes jusqu’à ce que la tâche soit achevée.
Comment cela peut-il se produire alors qu’un modèle est conçu uniquement pour prédire la sortie suivante ? Grâce au « harness », le système d’ingénierie entourant le modèle. Celui-ci décide quel contexte est transmis au modèle, quels outils sont disponibles, comment les appels aux outils se déroulent, ce qui est mémorisé, quand le modèle est à nouveau appelé, et quelles actions sont refusées ou nécessitent une validation.
Le « harness » crée également le cycle de fonctionnement :
Le cycle se déroule ainsi : le modèle lit ce qui se trouve dans son contexte, choisit une action, appelle un outil, examine la réponse reçue, l’intègre à son contexte et recommence.
C’est ce cycle qui distingue la simple réponse de l’achèvement d’une tâche. Il peut également être relié à un planificateur ou à un déclencheur externe, de sorte que l’agent démarre automatiquement à un moment donné ou lorsqu’un événement se produit.
L’équation : agent = modèle + harness
Le modèle est la partie qui prédit. Selon le contexte qui lui est donné, il produit la sortie ou l’action suivante la plus utile. Le « harness » est le logiciel qui l’entoure et qui transforme cette capacité brute en un comportement contrôlé et en plusieurs étapes.
Regardez ce qui se passe lorsque le même modèle est intégré dans différents « harness » :
- Avec un simple « harness » de chat, il devient un assistant de conversation.
- Ajoutez des recherches sur le Web, du récupération d’informations, une évaluation des sources et une vérification des citations, et il devient un agent de recherche.
- Donnez-lui un dépôt de code, un éditeur, un terminal et des outils de test, et il devient un agent de codage.
- Connectez-le aux données des clients, aux règles commerciales, aux outils de messagerie, aux déclencheurs et aux étapes d’approbation, et vous obtenez un agent opérationnel.
Le modèle n’a jamais changé. Le framework, lui, si. Cela explique également pourquoi deux produits basés sur le même modèle de base peuvent se comporter de manière très différente. L’un récupère les preuves appropriées, choisit l’outil adéquat, se remet des essais infructueux, maintient son contexte organisé et vérifie le résultat. L’autre perd des informations clés, continue d’utiliser l’outil incorrect ou proclame sa victoire sans vérification. La capacité d’un produit ne peut pas être jugée uniquement sur son modèle : le modèle définit ce que le système peut comprendre, tandis que le framework détermine ce qu’il peut accomplir.
Distinguer les différentes couches
Les gens utilisent souvent indifféremment les termes « modèle », « agent » et « framework », bien qu’il s’agisse de couches distinctes.
Codex et Claude Code illustrent bien ce modèle parmi les agents de codage. Chacun associe les modèles propres au fournisseur à un ensemble d’outils gérant le contexte du répertoire, l’accès aux fichiers, les outils, les commandes de shell, la mémoire, l’exécution, les retours d’essai et les boucles de répétition. OpenCode, Goose, Pi, Letta et AutoGPT suivent le même modèle que les environnements d’exécution ou les frameworks, et ils diffèrent par les modèles pris en charge, les ensembles d’outils, les architectures mémoire et le degré d’ouverture.
L’agent représente le système complet, le modèle fournit l’intelligence, et cet ensemble d’outils règle la manière dont cette intelligence interagit avec le monde extérieur.
Les poids ouverts et le logiciel open source sont des choses différentes
Des produits tels que Codex et Claude Code sont des agents prêts à l’emploi dans lesquels le modèle et l’outil d’interface sont développés et ajustés ensemble par une seule entreprise. Un agent à poids ouvert, quant à lui, combine un modèle téléchargeable avec un outil d’interface existant ou personnalisé. Cela permet aux développeurs d’avoir un contrôle plus grand sur le déploiement, les outils, la mémoire, la confidentialité, les coûts et le comportement. Les poids du modèle peuvent être exécutés sur votre propre infrastructure et, si la licence le permet, être affinés. Une combinaison typique est Goose avec un modèle à poids ouvert comme gpt-oss-120b, ou OpenCode avec un modèle Qwen ou Gemma.
Un agent open source est quelque chose de différent : le code de l’outil d’interface est public. Tout le monde peut lire et modifier la manière dont il formule les demandes au modèle, les outils qu’il propose, la façon dont il stocke la mémoire, le fonctionnement de ses boucles, les éléments qu’il intègre, ainsi que la gestion des permissions et du contexte. OpenCode, Goose et AutoGPT sont des exemples d’outils d’interface ouverts.
Ces deux aspects sont indépendants :
- Un framework open source peut encore appeler un modèle propriétaire via une API. OpenCode peut faire fonctionner des modèles GPT ou Claude, de sorte que son interface, sa logique de contrôle et l’exécution des outils sont ouverts, tandis que le cerveau du modèle reste fermé.
- Un modèle à poids ouverts n’est pas un agent en soi. Un modèle comme gpt-oss-20b peut prédire et prendre des décisions, mais il ne peut pas parcourir des dossiers, exécuter des outils, conserver l’état d’une tâche ou terminer un flux de travail tant qu’un framework comme Goose, OpenCode ou un cadre personnalisé ne l’entoure pas.
En termes simples : un agent open source est un framework ouvert associé à n’importe quel modèle compatible, tandis qu’un agent à poids ouverts est un framework associé à des poids téléchargeables.
Pourquoi les écosystèmes ouverts sont importants
Divers laboratoires publient désormais des modèles à coût abordable et de poids ouvert, accompagnés d’outils open source pour les agents, créant ainsi des écosystèmes ouverts hybrides. De telles publications ont fait des stacks ouverts de sérieux concurrents pour les agents de codage propriétaires sur certains benchmarks, bien qu’ils ne soient pas systématiquement supérieurs dans tous les cas. Les évaluations menées par les fournisseurs montrent souvent que leurs modèles propriétaires restent en tête sur plusieurs tests de codage. Ce qui est important, ce n’est pas qu’un modèle batte tous les autres, mais plutôt le fait qu’un modèle à coût abordable et de poids ouvert, associé à un outil soigneusement conçu, puisse concurrencer des systèmes fermés coûteux.
Ce qu’un bon outil contient
Les performances proviennent de la combinaison du modèle et de l’outil, et cet outil se compose de plusieurs éléments :
- Sélection du contexte. Choix de ce qui est inclus dans chaque appel au modèle, afin que le fichier, l’enregistrement ou le document pertinent soit présent et que les éléments indésirables ne le soient pas.
Choix de conception qui façonnent un système d’assistance
Chaque framework prend des décisions qui fixent discrètement les limites de ce que l’agent peut faire, et certains méritent une attention précoce.
Quel nombre d’outils, et comment sont-ils décrits ? Fournir à un modèle vingt outils superposés nuit généralement plus que de lui en donner cinq bien définis. Les noms, les descriptions et la structure des arguments constituent en réalité des indications ; par conséquent, des définitions d’outils peu claires entraînent des appels incorrects.
Quelle quantité de données à mémoriser ? Des historiques trop longs éliminent le contexte utile. Les frameworks ont généralement tendance à raccourcir, résumer ou stocker des notes en dehors du prompt pour les récupérer lorsque c’est pertinent. Ce qui est conservé, et pour quelle durée, influence fortement la capacité de l’agent à rester cohérent sur une tâche longue.
Où placer l’élément humain. Certaines actions, comme la lecture d’un fichier, peuvent être automatisées en toute sécurité. D’autres, telles que la suppression de données ou l’envoi d’argent, nécessitent une étape d’approbation. Définir ces règles relève d’une décision de conception et non d’une décision liée au modèle.
Qu’est-ce qui compte comme terminé. Une boucle a besoin d’une règle de fin, comme le passage des tests, une réponse vérifiée ou un budget d’étapes. Sans cela, l’agent s’arrête prématurément ou continue de fonctionner.
Une manière pratique de commencer
Si vous développez un agent, commencez par le plus petit ensemble de composants capable d’accomplir une tâche réelle du début à la fin : un modèle, deux ou trois outils, une boucle avec une limite de pas et une définition écrite du succès. Ensuite, collectez dix à vingt tâches réelles, exécutez-les, analysez les traces et corrigez d’abord les échecs les plus fréquents. Le remplacement du modèle viendra plus tard, une fois que vous saurez que l’ensemble de composants n’est pas le facteur limitant. Cette séquence vous empêche d’attribuer les problèmes au modèle alors qu’ils résident en réalité dans les outils qui l’entourent.
Comment fonctionne l’accès aux fichiers
Un modèle ne peut pas accéder directement aux fichiers d’un ordinateur. L’outil de gestion fournit des fonctionnalités contrôlées permettant de lister les dossiers, de rechercher des noms de fichiers, de récupérer du contenu pertinent, d’ouvrir et d’éditer des fichiers, d’exécuter du code et de sauvegarder les résultats. Le modèle choisit ensuite les informations ou actions dont il a besoin. L’outil de gestion valide et exécute cette demande, renvoie le résultat et l’ajoute au contexte. Ce processus se répète jusqu’à ce que le modèle décide que la tâche est terminée :
Le modèle demande une action, l’outil de gestion l’exécute, le résultat est renvoyé, puis le modèle choisit la prochaine action.
Par exemple, si l’on lui demande de corriger un test qui échoue, le modèle peut demander une liste des dossiers, puis ouvrir le fichier de test, ainsi que le module à tester, proposer des modifications et demander une exécution de test. À chaque étape, l’outil de gestion détermine si la demande est autorisée, l’exécute et rapporte ce qui s’est passé.
L’outil d’évaluation est tout aussi important
Construire un outil pour l’agent ne représente que la moitié du travail. L’autre moitié consiste en un outil d’évaluation permettant de déterminer si l’agent fonctionne correctement. Cet outil teste, dans des conditions similaires à celles en production, si le système complet est capable de choisir les bons outils, de se remettre des pannes, de garder les coûts sous contrôle, de respecter les règles de sécurité et d’achever les tâches de manière fiable. Il s’agit là de bien plus que de simplement réussir un test isolé.
Un outil pour l’agent comprend de nombreuses composantes interagissantes, et chacune d’elles peut cacher une régression : les prompts, les règles de contexte, les outils, les politiques de mémoire, les boucles de planification, la vérification, les permissions et les mécanismes de récupération. Sans un ensemble d’évaluation, une équipe ne peut pas savoir si modifier l’une de ces composantes a été bénéfique ou si cela a introduit discrètement une nouvelle faille. Ainsi, ces deux outils forment un cycle de rétroaction :
- Réunir des tâches représentatives, y compris des flux de travail réalistes, des cas difficiles et des échecs déjà rencontrés.
- Mettre en marche l’ensemble du système, le modèle actuel et l’outil de gestion.
- Examiner les résultats : succès, traces, appels d’outils, erreurs, coûts et latence.
- Changer un composant, qu’il s’agisse d’une instruction, d’un outil, d’un modèle, d’une politique de mémoire, d’une boucle ou d’une règle de routage.
- Réaliser à nouveau les évaluations sur des tâches non utilisées et des cas de régression.
- Conserver uniquement les modifications qui améliorent de manière vérifiable l’équilibre souhaité entre précision, fiabilité, sécurité, vitesse et coût.
En bref : construire, évaluer, identifier les défauts, améliorer l’outil de gestion, évaluer à nouveau.
Lecture d’une trace
L’évaluation est la plus simple lorsque l’on peut voir ce que l’agent a réellement fait. Un journal d’activité utile enregistre chaque appel au modèle, l’outil demandé, les arguments, le résultat retourné, les tokens utilisés ainsi que le temps écoulé. Lorsqu’une tâche échoue, cherchez dans le journal d’activité la première étape incorrecte et non la dernière. Souvent, la cause racine se trouve tôt : un fichier manquant dans le contexte, une description vague de l’outil ou une hypothèse erronée reprise par toutes les étapes suivantes. Corriger ce seul point suffit généralement à résoudre toute une série d’échecs, c’est pourquoi l’analyse du journal d’activité est l’une des habitudes les plus productives que puisse adopter une équipe.
Le modèle reste-t-il important ?
Oui. Les modèles plus récents améliorent constamment leur capacité de raisonnement, de codage, de suivi d’instructions, leur précision dans l’utilisation des outils, leur capacité de traitement du contexte, leur vitesse, leur efficacité en termes de coûts et leurs compétences multimodales ; un framework ne peut pas créer de manière fiable une capacité que le modèle ne possède pas. Mais le modèle n’est plus l’ensemble du produit.
Lorsque plusieurs modèles sont suffisamment performants pour une tâche, le framework peut expliquer la majeure partie de la différence restante entre les produits. La recherche permettant de trouver le bon fichier, des outils dont les actions sont évidentes, un système de gestion de l’état qui se souvient des travaux terminés, une vérification permettant d’identifier les modifications erronées, des permissions empêchant des étapes dangereuses et un mécanisme de récupération permettant de surmonter les pannes : tous ces éléments contribuent ensemble.
Cela suggère une division simple du travail, qui constitue également une liste de contrôle utile pour évaluer n’importe quel projet d’agent. Demandez ce que le modèle peut raisonnablement faire, ce que l’outil d’intégration doit ajouter pour que cette capacité se manifeste de manière fiable, et quels éléments les évaluations fournissent pour prouver que c’est bien le cas.
- Le modèle définit la limite maximale de ce que le système peut accomplir.
- L’outil d’intégration transforme cette limite en résultats fiables et reproductibles.
- L’évaluation confirme si le système final a réellement atteint cet objectif, ce qui est une question distincte de la question de savoir si le modèle est intelligent.
C’est pourquoi tant d’efforts en ingénierie logicielle sont aujourd’hui axés sur les outils d’intégration et les évaluations. C’est grâce à ces outils qu’une équipe peut créer un avantage durable, par le biais d’un contexte privé, d’outils plus sûrs, de workflows adaptés au domaine, de mécanismes de mémorisation, de récupération en cas d’erreur et d’une expérience utilisateur optimisée.
La réponse à la question centrale
Un modèle peut-il devenir un agent véritable et fonctionnel sans cadre d’action ? Non. Un modèle seul ne dispose pas de l’environnement nécessaire pour exécuter des actions, se connecter à des systèmes externes, mémoriser les étapes accomplies, observer l’effet de ses décisions et continuer à travailler vers un objectif. Le modèle représente le cerveau et le moteur de raisonnement. Le cadre d’action, quant à lui, correspond au corps, aux outils, à la mémoire, aux boucles de rétroaction, aux permissions et aux contraintes qui transforment les prédictions en actions contrôlées.
En une phrase : un agent IA est un modèle IA associé à un cadre d’action.