Accueil › Glossaire › Think-Act-Observe

Think-Act-Observe

Think-Act-Observe (Penser-Agir-Observer) est la boucle cognitive fondamentale qui structure le fonctionnement de tout agent IA : le LLM réfléchit à la situation (Think), exécute une action via un outil (Act), observe le résultat retourné par l’environnement (Observe), puis recommence le cycle jusqu’à la résolution de la tâche.

Ce n’est pas un framework spécifique ni un papier académique : c’est le pattern universel qui sous-tend tous les agents LLM. Le ReAct de Yao et al. (2023) l’a formalisé académiquement sous le nom « Thought-Action-Observation ». Le Plan-Execute l’étend avec une phase de planification. Le Reflexion l’enrichit avec une mémoire épisodique. Mais tous reposent sur cette même boucle fondamentale.

L’analogie la plus parlante : les humains ne résolvent pas les problèmes complexes en un seul élan. Ils réfléchissent, agissent, observent le résultat, et ajustent. Préparer un voyage : vous réfléchissez (« quel temps fera-t-il ? »), agissez (consultez la météo), observez (il pleuvra), et réfléchissez à nouveau (« je dois prendre un imperméable »). Think-Act-Observe reproduit ce cycle naturel à la vitesse d’un LLM.

Les trois phases en détail

Think (Penser)

Le LLM analyse l’état actuel de la conversation, les résultats des actions précédentes, et l’objectif global. Il génère une trace de raisonnement en langage naturel : son « monologue intérieur ».

Cette phase sert à : décomposer le problème en sous-problèmes, évaluer la progression vers l’objectif, identifier les informations manquantes, décider de la prochaine action à entreprendre, et gérer les cas d’erreur (« la recherche précédente n’a pas retourné l’information attendue, je dois reformuler ma requête »).

La qualité de cette phase de pensée détermine directement la qualité des actions. Un agent qui « pense » superficiellement (« je vais chercher ») produit des actions moins pertinentes qu’un agent qui raisonne en profondeur (« l’utilisateur demande l’âge du Premier ministre du Manitoba, je dois d’abord identifier qui occupe ce poste actuellement, puis trouver sa date de naissance »).

Dans les modèles « thinking » (Claude Opus 4.6 adaptive thinking, GPT-5.4 Thinking), cette phase est partiellement internalisée dans l’architecture du modèle via des thinking tokens dédiés. Dans le prompting classique, elle est encouragée par des instructions comme « réfléchis étape par étape avant d’agir » intégrées dans le system prompt.

Act (Agir)

Sur la base de sa réflexion, l’agent exécute une action concrète. Cette action peut être :

Un appel d’outil via le function calling : recherche web, exécution de code, requête base de données, appel API, manipulation de fichier. L’agent génère un JSON structuré qui spécifie l’outil et ses arguments.

Une réponse finale à l’utilisateur : quand l’agent juge avoir suffisamment d’informations pour répondre, l’action consiste à formuler la réponse et terminer la boucle.

Une délégation à un sous-agent : dans les systèmes multi-agents, l’action peut être d’assigner une sous-tâche à un agent spécialisé.

L’action est le moment où l’agent passe du raisonnement interne à l’interaction avec le monde extérieur. C’est aussi le moment le plus risqué : une action mal formulée (mauvais arguments d’outil, mauvaise API appelée) peut produire des résultats erronés ou des effets de bord indésirables.

Observe (Observer)

L’environnement exécute l’action et retourne un résultat. Ce résultat est l’observation : les résultats d’une recherche web, la sortie d’un script Python, la réponse d’une API, un message d’erreur.

L’observation est ajoutée au contexte de l’agent et déclenche un nouveau cycle Think. L’agent doit interpréter l’observation : le résultat est-il pertinent ? Contient-il l’information recherchée ? Y a-t-il une erreur à gérer ? Faut-il une action supplémentaire ?

C’est cette capacité d’intégrer le feedback de l’environnement qui distingue un agent d’un LLM statique. Le LLM seul « imagine » les réponses ; l’agent les obtient du monde réel et raisonne dessus.

Analogies avec d’autres boucles

Le Think-Act-Observe n’est pas une invention de l’IA. C’est la formalisation d’un pattern cognitif universel que les humains et les organisations utilisent depuis des décennies.

OODA Loop (militaire)

Le Colonel John Boyd a développé la boucle OODA (Observe-Orient-Decide-Act) pour expliquer comment les pilotes de chasse prennent l’avantage : non pas en ayant de meilleurs plans, mais en bouclant plus vite que l’adversaire. Pour les agents IA, cette « maniabilité cognitive » se traduit par la latence et la fiabilité de la boucle d’inférence. Un agent qui peut s’orienter dans un nouvel environnement (un codebase inconnu, par exemple) et décider d’une action correcte en quelques secondes a un avantage massif.

PDCA (gestion de la qualité)

Le cycle de Deming (Plan-Do-Check-Act) est le template de la précision industrielle. Les architectures Plan-and-Solve reproduisent ce cycle en forçant l’agent à générer un plan multi-étapes avant d’exécuter. L’auditabilité et la réduction des erreurs à long horizon en sont les bénéfices directs.

Sprints Agile

Les méthodologies Agile sont explicitement itératives : les sprints sont des boucles, le daily standup est un mécanisme de feedback, la rétrospective est l’observation qui informe l’itération suivante. La préférence Agile pour « répondre au changement plutôt que suivre un plan » est exactement la philosophie des systèmes agentiques.

Variantes et extensions

La boucle en cinq étapes (Oracle)

Oracle propose une version étendue en cinq phases : Perceive (recevoir l’input), Reason (raisonner sur les options), Plan (décomposer en sous-tâches si nécessaire), Act (exécuter), Observe (évaluer le résultat). La séparation entre Reason et Plan est utile pour les tâches complexes où la décomposition est une étape distincte du raisonnement sur l’action immédiate.

Think-Act-Learn (robotique)

Le framework Think-Act-Learn (2025) étend la boucle à la robotique en ajoutant un module « Learn » : après l’observation, l’agent effectue une analyse causale de ses échecs et génère des stratégies correctives qui sont stockées pour les interactions futures. C’est une fusion de Think-Act-Observe avec le Reflexion.

LATS (Language Agent Tree Search)

LATS combine la boucle Think-Act-Observe avec une recherche arborescente Monte Carlo. À chaque étape, l’agent explore plusieurs branches d’actions possibles, évalue chaque branche, et ajoute une étape de réflexion pour identifier les erreurs de raisonnement. C’est le pattern le plus performant sur les tâches complexes (code, QA interactive) mais aussi le plus coûteux en ressources.

Implémentation en production

Avec LangGraph

L’implémentation standard dans LangGraph utilise un graphe avec un nœud ThoughtNode (génère le raisonnement), un nœud CallModelNode (exécute l’action/outil), et un nœud ObservationNode (évalue le résultat et décide de boucler ou terminer). Les arêtes conditionnelles gèrent la logique de sortie.

L’ajout explicite d’un ThoughtNode séparé (plutôt que de laisser le raisonnement implicite dans la génération) apporte trois bénéfices concrets : la transparence (on peut lire le raisonnement de l’agent), la réduction des coûts (le raisonnement guide les actions, évitant les appels d’outils inutiles), et des conditions de sortie propres (quand l’Observation décide que la réponse est complète, la boucle s’arrête immédiatement).

Avec Hugging Face smolagents

Le cours agents de Hugging Face décrit le cycle comme le fonctionnement par défaut de tout agent : les règles et guidelines sont intégrées dans le system prompt, qui inclut explicitement le format Thought-Action-Observation attendu par le modèle. L’agent produit un Thought, puis un Action (en JSON), le système exécute l’action et injecte l’Observation, et le cycle reprend.

Exemples concrets de la boucle

Agent météo (simple, 2 cycles)

L’utilisateur demande « Quel temps fait-il à Lyon ? »

Cycle 1 : Think : « L’utilisateur veut la météo actuelle à Lyon. Je dois utiliser l’outil météo. » → Act : get_weather(city="Lyon") → Observe : « 12°C, couvert, vent 15 km/h. »

Cycle 2 : Think : « J’ai les informations nécessaires. Je peux répondre. » → Act : Final Answer « Il fait actuellement 12°C à Lyon avec un ciel couvert et un vent de 15 km/h. »

Agent de recherche multi-hop (complexe, 4+ cycles)

L’utilisateur demande « Quel réalisateur français a remporté la Palme d’Or la plus récemment, et quel est son prochain film ? »

Cycle 1 : Think : « Je dois trouver le dernier réalisateur français ayant gagné la Palme d’Or. » → Act : Search(« dernier réalisateur français Palme d’Or ») → Observe : « Jacques Audiard, Emilia Pérez, 2024. »

Cycle 2 : Think : « Jacques Audiard est le réalisateur. Maintenant je dois chercher son prochain film. » → Act : Search(« Jacques Audiard prochain film 2026 ») → Observe : résultats pertinents.

Cycle 3 : Think : « J’ai les deux informations. Je formule la réponse. » → Act : Final Answer avec les détails.

Agent de code auto-correcteur (itératif, 5+ cycles)

Claude Code face à un test qui échoue :

Cycle 1 : Think : « Le test test_login_redirect échoue avec une 404. Je dois examiner la route de login. » → Act : read_file(« src/routes/auth.py ») → Observe : contenu du fichier.

Cycle 2 : Think : « La route /login redirige vers /dashboard mais le test attend /home. Je dois corriger le test ou la route. » → Act : read_file(« tests/test_auth.py ») → Observe : le test attend /home.

Cycle 3 : Think : « D’après la spec, la redirection doit aller vers /home. Je corrige la route. » → Act : edit_file(« src/routes/auth.py », changement) → Observe : fichier modifié.

Cycle 4 : Think : « Je relance les tests pour vérifier. » → Act : run_tests(« test_login_redirect ») → Observe : test passed.

Cycle 5 : Think : « Le test passe. La correction est complète. » → Act : Final Answer « Corrigé : la route /login redirige maintenant vers /home. »

Cet exemple illustre la puissance de la boucle : chaque observation nourrit le raisonnement suivant, et l’agent converge vers la solution par itérations successives.

Défis de la boucle agentique

Goal drift (dérive d’objectif)

À mesure que la fenêtre de contexte se remplit de résultats d’outils et de traces de raisonnement, l’instruction originale est « poussée hors de vue ». L’agent peut commencer à optimiser pour une sous-tâche en oubliant l’objectif principal. Les contre-mesures : rappeler l’objectif dans chaque cycle, compacter le contexte régulièrement, écrire l’objectif dans un fichier de référence que l’agent relit.

Boucles infinies

Un agent qui rencontre une erreur persistante (« Permission Denied ») peut réessayer indéfiniment la même action. La détection de boucle (si les 3 dernières actions sont identiques ou très similaires, forcer un changement de stratégie) et une limite stricte d’itérations (5-15 selon la complexité) sont les garde-fous essentiels.

Coût de la boucle

Les agents consomment environ 4× plus de tokens que les interactions de chat standard. Dans les systèmes multi-agents, ce facteur peut atteindre 15×. Chaque itération Think-Act-Observe ajoute du contexte et un appel LLM. La métrique pertinente en production n’est pas le coût par token mais le coût par tâche accomplie : un agent qui consomme 15× plus de tokens mais résout un problème sans intervention humaine est moins cher qu’un chatbot qui nécessite une escalade.

Observabilité

Débugger une exécution de 20 itérations nécessite de reconstituer les traces de raisonnement, les appels d’outils et les résultats à travers de multiples cycles. Les outils d’observabilité (LangSmith, Langfuse, Arize Phoenix) permettent de tracer, rejouer et interpréter les décisions de l’agent. C’est l’un des avantages majeurs de Think-Act-Observe : chaque étape est explicite et inspectable, contrairement à un LLM qui produit une réponse en une seule passe opaque.

Bonnes pratiques

Intégrez le format dans le system prompt. Décrivez explicitement le cycle Thought-Action-Observation dans les instructions du LLM, avec des exemples du format attendu. Les frameworks comme LangChain et smolagents le font automatiquement, mais si vous implémentez from scratch, ce prompting est essentiel.

Rendez les pensées optionnelles mais encouragées. Toutes les étapes ne nécessitent pas un raisonnement profond. Parfois l’agent peut agir directement (« la réponse est évidente, je réponds »). Mais pour les situations ambiguës ou les erreurs, le raisonnement explicite est indispensable.

Gardez un historique complet mais compacté. Chaque cycle ajoute du contenu au contexte. Pour les boucles longues (10+ cycles), résumez les cycles anciens pour libérer du contexte tout en conservant les informations clés.

Mesurez le coût par tâche, pas par token. Un agent qui boucle 8 fois et résout un problème complexe est plus rentable qu’un chatbot qui échoue et nécessite une intervention humaine. Calibrez vos limites d’itérations en fonction de la valeur business de la tâche.