Je pensais autrefois que la création d'un agent IA revenait essentiellement à envoyer un prompt à un chatbot. On formule bien la question, le modèle répond, et on s'arrête là. Puis j'ai déployé quelques applications. La réalité m'a frappé de plein fouet. Un LLM n'est pas un agent. Un LLM prédit le prochain token. C'est la boucle qui crée l'agent.

Pensez à la préparation d'un thé. Vous ne lancez pas une commande unique appelée make_tea() pour ensuite vous en aller. Vous remplissez la bouilloire, vous réalisez que la pression du robinet est faible, vous attendez, vous l'allumez, vous remarquez que l'interrupteur est cassé, vous passez à un autre brûleur, vous vérifiez la vapeur, vous versez, vous goûtez, et vous ajoutez peut-être du miel parce que les feuilles ont infusé trop longtemps. L'objectif ne change jamais, mais les étapes, si. Vous observez, vous ajustez et vous réessayez. Les agents IA fonctionnent exactement de cette manière.

Le cycle qui crée l'agentivité

La boucle n'est pas une théorie abstraite. C'est le cœur opérationnel de tout système qui agit en votre nom. Voici ce à quoi cela ressemble concrètement :

  • Penser : Le modèle raisonne sur l'objectif et décide de ce dont il a besoin. Un utilisateur demande : « Dois-je prendre un parapluie à Portland demain ? ». Le modèle identifie qu'il a besoin d'une prévision météo et d'un lieu.
  • Agir : Le modèle invoque un outil. Il peut appeler une API de géocodage pour résoudre « Portland », puis interroger un endpoint météo avec les coordonnées.
  • Observer : Le modèle lit la sortie de l'outil. L'API a-t-elle renvoyé une prévision JSON, une erreur 403 ou une page de maintenance HTML ?
  • Mettre à jour : En fonction de ce qu'il voit, le modèle révise son plan. Si le géocodeur a renvoyé Portland, Maine au lieu de Portland, Oregon, le modèle doit lever l'ambiguïté. Si l'API est hors service, il peut passer à une source de secours ou demander à l'utilisateur.
  • Penser à nouveau : Le cycle redémarre avec le nouveau contexte.

Il ne s'agit pas de cinq fonctions distinctes que l'on écrit une fois pour toutes. C'est un moteur continu qui tourne jusqu'à ce que l'objectif soit atteint ou qu'un arrêt forcé soit déclenché. Le modèle n'exécute pas de code comme un script. Il raisonne sur l'état du monde, choisit une action, lit la conséquence et décide de la suite. C'est là toute la différence entre une complétion de texte sophistiquée et un agent qui mène sa mission à bien.

Pourquoi tous les frameworks se ressemblent

Si vous avez passé du temps sur LangGraph, CrewAI ou AutoGen, vous avez probablement remarqué qu'ils finissent par se confondre. LangGraph modélise le flux comme un graphe persistant de nœuds et d'arêtes. CrewAI organise les agents en rôles et en équipes. AutoGen orchestre des conversations multi-agents. Un emballage différent, mais le même squelette.

Ils se ressemblent parce qu'ils sont tous conçus autour de ce même principe de boucle. LangGraph structure explicitement le cycle sous forme de transitions d'état entre les appels d'outils et les inférences du modèle. CrewAI enveloppe la boucle à l'intérieur d'agents basés sur des rôles, mais chaque membre de l'équipe suit toujours un cycle de planification, d'action et d'observation. AutoGen sert d'intermédiaire pour les messages entre les acteurs, pourtant chaque tour reste une variation de génération, exécution, réflexion et routage.

Ces frameworks se concentrent sur la boucle car c'est là que réside l'agentivité. Le modèle sous-jacent peut être GPT-4, Claude ou un modèle open-weight affiné. Sans la boucle, vous avez un compléteur de phrases très coûteux. Avec la boucle, vous avez un système capable de persister vers un objectif à travers de multiples tentatives.

Quand le vrai travail commence

Les démos locales semblent magiques. La production est l'endroit où la magie se confronte au chaos. Une fois le prototypage dépassé, on cesse de résoudre des problèmes d'IA pour commencer à résoudre des problèmes d'ingénierie système.

Les échecs d'outils sont inévitables. Les API expirent (timeout). Elles renvoient du JSON malformé. Elles renvoient des erreurs 500 enveloppées dans du HTML. Si votre boucle fait aveuglément confiance à chaque sortie d'outil, votre agent va halluciner un succès ou sombrer dans la confusion. Vous avez besoin d'une logique de réessai, de coupe-circuits et d'une validation de schéma sur chaque charge utile de retour.

La mémoire devient obsolète. Votre agent se souvient que la base de données préférée de l'utilisateur est PostgreSQL, mais l'équipe d'infrastructure a migré vers un nouveau cluster la nuit dernière. Sans mécanisme pour rafraîchir ou expirer le contexte, l'agent émettra avec assurance des commandes vers des points de terminaison morts. La mémoire nécessite des horodatages, des scores de confiance et la capacité de s'invalider elle-même.

Les boucles infinies sont des tueurs silencieux. Un agent cherche sur le web, ne trouve rien d'utile, affine légèrement la requête, cherche à nouveau, ne trouve rien, et recommence. Sans un plafond d'itérations maximal ou une détection de doublons sémantiques, il consommera des tokens et de l'argent pendant que l'utilisateur attend. Vous devez construire des garde-fous : des limites strictes sur les tentatives, des vérifications de divergence et des chemins d'escalade vers l'humain.

Les données non pertinentes étouffent le raisonnement. Les pipelines de Retrieval-Augmented Generation déversent souvent cinquante paragraphes de documentation vaguement liée dans la fenêtre de contexte. L'agent s'étouffe sous le bruit et sélectionne le mauvais outil ou hallucine un paramètre. Vous avez besoin de filtrage, de classement et d'une synthèse concise avant même que le modèle ne voie le texte récupéré.

Un agent a besoin de plus que de l'intelligence. Il a besoin d'un système : une mémoire gérée, un suivi d'état explicite, des garde-fous stricts et une télémétrie observable. Plus le modèle est performant, plus le système environnant doit l'être. Un modèle puissant au sein d'une boucle fragile ne produit que des échecs plus articulés.

Aller jusqu'au bout

La véritable intelligence des agents ne consiste pas à trouver la bonne réponse dès la première tentative. Il s'agit de naviguer dans l'écart entre l'intention et le résultat lorsque rien ne se passe comme prévu. La première tentative est facile. N'importe qui peut coder un chemin idéal. La partie difficile, c'est la quatrième itération, quand l'API principale est hors service, que la fenêtre de contexte rétrécit, que l'utilisateur s'impatiente et que l'agent doit toujours fournir quelque chose d'utile.

Cette persistance est ce qui distingue une démo d'un produit. C'est la capacité d'apprendre de chaque étape, non pas en mettant à jour les poids du modèle en temps réel, mais en mettant à jour le plan. L'agent maintient l'objectif constant tandis que les tactiques changent. C'est le principe de la boucle en action.

Alors, l'avenir appartient-il à des modèles plus grands ou à de meilleures boucles d'exécution ? L'échelle aide certainement. Un modèle plus capable raisonne mieux à chaque cycle. Mais un modèle plus petit fonctionnant dans une boucle serrée, observable et résiliente surpassera presque toujours un modèle géant à qui l'on demande de tout résoudre en une seule fois. La boucle est ce qui transforme la prédiction en action. Investissez là-dedans.

Source : The Looping Principle: A Simple Mental Model for Understanding AI Agents

Pour plus de discussions de ce type, rejoignez la communauté d'apprentissage GyaanSetu sur Telegram.