Coffee & Cake : Modèles, agents et harnais

Le modèle, l'agent et le harnais : qui fait quoi, au juste, quand une intelligence artificielle se met au travail.

Deux applications affichent fièrement le même modèle de langage. La première attend votre question et rédige une réponse. La seconde, quand vous lui confiez un problème, fouille des fichiers, ouvre un journal d'erreurs, modifie une ligne de code, lance un test, constate que le test échoue et repart dans une autre direction. Si le modèle est vraiment le même des deux côtés, d'où vient toute cette capacité supplémentaire ?

Pour répondre, il faut démêler trois idées que le grand mot d'intelligence artificielle a tendance à écraser : le modèle, l'agent, et le logiciel d'orchestration qui les entoure. Autant le dire tout de suite : le vocabulaire n'est pas parfaitement fixé. Selon les entreprises et les équipes de recherche, le mot agent ne recouvre pas exactement la même chose. Mais il existe une distinction pratique qui rend tout le sujet beaucoup plus lisible, et c'est elle que nous allons suivre.

Commençons par le modèle. Le modèle, c'est la composante entraînée, la mécanique qui a appris. À l'usage, il reçoit une entrée et produit une sortie. Pour un modèle de langage, l'entrée peut rassembler votre demande, des consignes, des messages précédents et la description des outils disponibles. La sortie peut être du texte ordinaire. Elle peut aussi prendre la forme d'une requête structurée qui dit, en substance : lis ce fichier, cherche cette expression, lance ce test.

Ce dernier point mérite qu'on s'y arrête. Demander un outil, ce n'est pas encore s'en servir. Si le modèle produit une requête pour consulter un journal d'erreurs, aucun journal n'a été ouvert. Le modèle a généré une sortie, exactement comme il aurait généré une phrase. Il faut encore qu'un autre logiciel reconnaisse cette requête, décide où l'envoyer, l'exécute et rapporte le résultat. Le modèle propose ; quelque chose d'extérieur dispose.

Passons à l'agent. Un agent se reconnaît sur une suite d'étapes, pas dans une réponse isolée. Il reçoit un objectif, choisit une action, observe ce qui s'est passé, puis ajuste la suite. Le même modèle peut être appelé de nombreuses fois au cours de cette séquence, et chaque résultat change ce qu'il voit à l'appel suivant. L'ingrédient nouveau n'est pas un petit personnage numérique caché dans la machine : c'est une boucle de rétroaction dans laquelle le modèle participe au choix du prochain pas.

Prenons un exemple concret, et gardons-le jusqu'au bout. Le formulaire de contact d'un site ne fonctionne plus : les messages partent dans le vide, et personne ne sait pourquoi. Quelqu'un demande à un agent de trouver la cause et de la corriger. Au premier tour, le modèle peut estimer qu'il lui faut le journal d'erreurs. Une fois le contenu sous les yeux, il repère une piste, choisit un fichier à inspecter, propose une modification, puis réclame un test. Le test échoue ; cet échec devient un indice de plus. Le modèle révise son hypothèse, examine un autre endroit du code et retente sa chance.

C'est cette séquence adaptative qui fait l'agent. Le chemin n'était pas écrit d'avance. Personne n'avait besoin de deviner quel fichier était cassé, quelle erreur allait surgir, ni combien d'essais seraient nécessaires. À chaque tour, le modèle choisit l'étape suivante à partir de ce que l'environnement vient de lui montrer.

Le contraste devient alors très utile. Imaginez un programme qui, systématiquement, interroge une base de données, résume les premiers résultats, puis envoie un message, toujours dans cet ordre. Un modèle peut rédiger la requête et le résumé, mais l'itinéraire, lui, est gravé dans le code. On parle plutôt, dans ce cas, d'un flux de travail prédéfini, un workflow comme on dit souvent. Si le modèle peut juger que les premiers résultats sont médiocres, chercher ailleurs, poser une question ou renoncer à envoyer quoi que ce soit, le système se rapproche de l'agent. L'autonomie est un curseur, pas un interrupteur.

Il nous manque encore une pièce. Qui a fourni au modèle la description de l'outil qui lit les journaux ? Qui a remarqué sa requête, exécuté l'outil, récupéré la sortie et glissé cette sortie dans l'appel suivant ? Qui a maintenu la tâche en vie d'un tour à l'autre ? Cette couche d'orchestration porte, en anglais, le nom de harness, littéralement le harnais. L'image est parlante : un harnais ne tire pas la charrue et ne remplace pas le cheval ; il relie sa force à la charge et transforme l'effort en travail utile. Le terme anglais s'est imposé dans le métier, alors gardons-le, en sachant simplement ce qu'il désigne : le logiciel qui entoure les appels au modèle et fait tourner la boucle.

Au minimum, le harness assemble le contexte du moment, appelle le modèle, interprète la réponse, achemine une éventuelle requête d'outil, rapporte l'observation, et recommence. Il peut faire davantage : choisir quelles consignes et quels outils sont visibles, entretenir la mémoire de la session pour que le travail déjà accompli ne s'évapore pas, remonter les erreurs sous une forme compréhensible, marquer une pause pour demander une autorisation, ou arrêter la boucle après trop de tours.

Attention toutefois à ne pas tout lui attribuer. Le harness n'est pas forcément l'endroit où chaque action se produit. C'est un outil distinct qui lit réellement le journal. C'est un environnement d'exécution séparé qui fait réellement tourner le test, souvent un espace isolé où une commande maladroite n'abîmera pas le reste. Et c'est une mémoire de session qui peut conserver la trace de ce qui a déjà été fait. Les produits assemblent ces pièces de mille façons, et c'est une des raisons pour lesquelles le vocabulaire glisse autant. L'image simple à garder : le harness organise la circulation entre le modèle et ces éléments extérieurs.

Revenons une dernière fois au formulaire de contact. Le modèle demande le journal ; le harness transmet ; l'outil ouvre le journal et renvoie son contenu ; le harness place ce contenu dans l'appel suivant. Le modèle choisit un fichier ; le harness fait suivre là aussi. Plus tard, le modèle propose une modification et réclame un test ; la modification et le test se déroulent hors du modèle, dans les outils et l'environnement d'exécution, tandis que leurs résultats reviennent par le harness. Modèle, agent et harness ne sont pas trois produits concurrents : ce sont trois regards portés sur le même travail, à des étages différents.

Voilà pourquoi changer le harness peut transformer ce qui ressemble à l'intelligence d'un agent. Donnez au même modèle des outils vaguement décrits et un contexte encombré de détails inutiles, et il trébuchera. Donnez-lui des outils clairs, un contexte bien choisi et des retours d'environnement exploitables, et il ira au bout de la tâche. Le modèle n'a rien appris de plus ; le système est simplement devenu plus facile à piloter pour lui.

L'inverse existe aussi. Un harness accumule parfois des béquilles pour contourner la faiblesse d'un modèle précis. Remplacez ce modèle par un successeur plus capable, et ces béquilles deviennent du poids mort, voire une source de confusion. De leur côté, certains modèles sont spécifiquement préparés à produire tel ou tel format de requête d'outil. On peut distinguer les étages, mais ce ne sont pas des pièces parfaitement indépendantes qu'on échangerait toujours sans conséquence.

Quelques idées reçues se dissipent alors d'elles-mêmes. Un agent n'est pas nécessairement un modèle d'un genre spécial : c'est le plus souvent un modèle placé dans une boucle, avec un objectif, des outils, des observations et une marge de choix. Un harness n'est pas seulement une longue consigne posée au début : la consigne est un ingrédient, mais le harness gère aussi les appels répétés et les liaisons avec l'environnement. Et un agent n'a pas besoin d'une équipe d'autres agents : un seul modèle dans une boucle toute simple suffit, et un agent utile peut très bien s'arrêter pour laisser un humain trancher.

Le nom du modèle, à lui seul, ne dit pas non plus ce que vaut l'agent fini. Un modèle privé d'accès aux fichiers ne réparera jamais le formulaire. Un système qui égare le résultat du test refera indéfiniment la même erreur. Deux agents bâtis sur le même modèle peuvent différer parce que l'un dispose de meilleurs outils, d'une mémoire mieux tenue, d'un budget d'essais plus généreux ou d'une manière plus saine de rebondir après un échec. Quand on vous vante ce qu'un agent a accompli, le modèle compte, mais le harnais dans lequel il travaillait compte tout autant.

Enfin, davantage d'autonomie n'est pas automatiquement un progrès. Pour une tâche stable, aux étapes connues, un flux prédéfini est souvent plus rapide, moins cher et plus prévisible. Laisser le modèle choisir chaque tour apporte de la souplesse, mais multiplie les appels et permet à une erreur précoce d'en entraîner d'autres. Le bon réglage n'est pas le système le plus autonome : c'est le système le moins ouvert qui suffit encore à absorber l'incertitude réelle du travail.

Alors, la prochaine fois qu'on vous présente un agent d'intelligence artificielle, posez trois questions. Quel modèle génère les décisions ? Qui choisit l'étape suivante : du code figé, une personne, ou le modèle à la lumière de ce qu'il vient d'observer ? Et que met le harness autour de tout cela : quels outils, quel contexte, quelle mémoire, quels retours, quelles conditions d'arrêt ?

Ces questions en disent bien plus long que l'étiquette. Le modèle apporte la capacité apprise. L'agent, c'est cette capacité lancée vers un but, à travers une séquence qui s'adapte. Le harness transforme la séquence en un lien de travail avec le monde. Une fois ces étages séparés, on voit beaucoup plus clairement ce qu'un système sait vraiment faire, et d'où vient, au juste, son intelligence apparente.