Comment un agent décide quoi faire ensuite (Planning vs Reactive)

On ne lui donne pas d’instruction. On ne lui explique pas l’ordre des actions.
Sur cette page
  1. Planning : quand l’agent pense à l’avance
  2. Reactive : quand l’agent agit selon la situation
  3. Différence en pratique
  4. En code, cela ressemble à ça
  5. 1) Planning : d’abord le plan, puis l’exécution
  6. 2) Reactive : pas à pas selon la situation
  7. Analogie du quotidien
  8. Ce que cela signifie en pratique
  9. En bref
  10. FAQ
  11. Et ensuite

Quand un agent reçoit une tâche, il ne sait pas à l’avance quelles étapes mènent au résultat.

On ne lui donne pas d’instruction. On ne lui explique pas l’ordre des actions.

Il doit décider lui-même quoi faire ensuite.


À ce stade, deux approches sont possibles.

L’agent peut préparer un plan à l’avance avec plusieurs étapes et le suivre.
Ou il peut agir selon la situation, en choisissant l’étape suivante pendant l’exécution.

Les deux options peuvent mener au résultat.

Mais elles ne fonctionnent pas de la même manière.

Et c’est exactement ce qui détermine comment l’agent se comporte quand quelque chose ne se passe pas comme prévu.

Diagram

Planning : quand l’agent pense à l’avance

Dans cette approche, l’agent essaie d’abord de comprendre quelles étapes peuvent mener au résultat.

Il reçoit une tâche et construit un plan d’action approximatif.

Par exemple :

  1. Trouver les données nécessaires
  2. Les traiter
  3. Produire un rapport
  4. Envoyer le résultat

Puis seulement après il exécute les étapes une par une.


Cette approche fonctionne bien quand :

  • La tâche est claire
  • Les données sont disponibles
  • Et il y a peu de chances qu’un problème survienne

L’agent ne prend pas une décision à chaque étape.
Il avance selon ce qu’il a décidé à l’avance.

Reactive : quand l’agent agit selon la situation

Dans cette approche, l’agent ne construit pas de plan à l’avance.

Il regarde la situation et choisit l’étape suivante sur le moment.

Par exemple :

  • Il essaie d’abord d’obtenir les données
  • Si ça ne marche pas, il cherche une autre source
  • Si les données sont suffisantes, il passe au traitement

Autrement dit, il ne décide pas tout le chemin d’un coup.

Il avance étape par étape en vérifiant en continu :

"Qu’est-ce qui a changé après l’action précédente ?"

Et sur cette base, il choisit la suivante.


Cette approche est plus flexible.

Si quelque chose échoue, l’agent ne casse pas.
Il change simplement d’action.

Différence en pratique

Agent IA : Planning vs Reactive

L’approche Planning essaie de trouver le chemin à l’avance.
L’approche Reactive le trouve pendant l’exécution.


Dans le premier cas, l’agent dit :

"Voilà ce que je vais faire pour atteindre le résultat."

Dans le second :

"Je fais ça, puis je regarde ce qui change."


Planning peut être plus rapide si tout se passe comme prévu.

Mais si quelque chose se passe mal, le plan peut casser.
Et l’agent devra le reconstruire.


Reactive agit plus lentement.

Mais il s’adapte mieux aux changements.

Il ne suppose pas que tout marchera du premier coup.

Et c’est pour cela qu’il continue souvent d’avancer là où un plan s’arrête.

PlanningReactive
ApprocheCherche le chemin à l’avanceCherche le chemin en cours
Mode d’action"Voilà ce que je vais faire""J’essaie et je regarde"
VitessePlus rapide si tout fonctionnePlus lent
En cas d’erreurLe plan casseEssaie une autre option
AdaptationIl faut reconstruire le planS’adapte pendant l’exécution

En code, cela ressemble à ça

Ci-dessous, le même principe en format simple :
Planning construit d’abord un plan, tandis que Reactive choisit l’étape suivante après chaque résultat.

D’abord, nous avons des actions (outils) que l’agent peut exécuter :

PYTHON
def search_docs(state: dict):
    return {"notes": "docs-found"}


def call_api(state: dict):
    return {"api_data": "fresh-data"}


def write_report(state: dict):
    return {"report": "ready"}


TOOLS = {
    "search_docs": search_docs,
    "call_api": call_api,
    "write_report": write_report,
}


def run_action(action: str, state: dict):
    return TOOLS[action](state)

1) Planning : d’abord le plan, puis l’exécution

Ici, l’agent décide tout le parcours à l’avance :

PYTHON
state = {}
plan = ["search_docs", "call_api", "write_report"]

for action in plan:
    result = run_action(action, state)
    state.update(result)

# state -> {"notes": "...", "api_data": "...", "report": "ready"}

2) Reactive : pas à pas selon la situation

Ici, l’agent regarde l’état après chaque étape et décide quoi faire ensuite :

PYTHON
def choose_next_action(state: dict):
    if "notes" not in state:
        return "search_docs"
    if "api_data" not in state:
        return "call_api"
    if "report" not in state:
        return "write_report"
    return None


state = {}

while True:
    action = choose_next_action(state)
    if action is None:
        break

    result = run_action(action, state)
    state.update(result)

# state -> {"notes": "...", "api_data": "...", "report": "ready"}

Dans cet exemple, les deux approches donnent un résultat.
La différence est quand la décision sur l’étape suivante est prise.

Exemple complet d’implémentation avec LLM connectée

PYPython
TSTypeScript · bientôt

Analogie du quotidien

Imagine que tu vas dans une nouvelle ville.

Tu peux :

  • Préparer l’itinéraire à l’avance
  • Ou t’orienter selon la situation

Planning, c’est quand tu ouvres la carte et que tu construis le trajet jusqu’au bout.

Tu sais :

  • Où tourner
  • Où t’arrêter
  • Comment contourner un pont

Et tu suis simplement le plan.

Mais si la route est bloquée, tu dois t’arrêter et recalculer l’itinéraire.


Reactive, c’est quand tu roules sans plan complet.

Tu vois un embouteillage, tu tournes.
Tu ne trouves pas une rue, tu en prends une autre.

Tu ne connais pas tout le trajet à l’avance.

Mais tu peux changer rapidement de direction si quelque chose ne marche pas.


C’est pareil pour un agent.

Il peut :

  • Soit construire un plan
  • Soit réagir à la situation

Et il choisit l’approche selon la tâche.

Ce que cela signifie en pratique

Planning fonctionne bien quand :

  • La tâche est claire
  • L’environnement est stable
  • Et il y a peu de chances que quelque chose change

Reactive fonctionne mieux quand :

  • Les données peuvent être incomplètes
  • Les outils échouent parfois
  • Ou la situation change pendant l’exécution

Dans les systèmes réels, l’agent combine souvent les deux approches.

Il peut préparer un plan global, puis réagir si quelque chose s’en écarte.

Et c’est ce qui détermine s’il s’arrête après la première erreur ou trouve un autre chemin vers le résultat.


En bref

En bref

Un agent peut :

  • Planifier plusieurs étapes à l’avance (Planning)
  • Ou choisir l’action selon la situation (Reactive)

Planning est plus rapide si tout se passe comme prévu.
Reactive est plus flexible quand quelque chose change.

Dans les tâches réelles, l’agent combine généralement les deux approches.

FAQ

Q: Un agent IA planifie-t-il toutes les étapes à l’avance ?
A: Pas toujours. Il peut construire un plan ou choisir l’action suivante directement pendant l’exécution.

Q: Qu’est-ce qui est mieux : Planning ou Reactive ?
A: Planning est plus rapide en environnement stable, Reactive fonctionne mieux quand la situation change.

Q: Un agent utilise-t-il une seule approche ?
A: Dans les tâches réelles, l’agent combine souvent Planning et Reactive selon la situation.

Et ensuite

Maintenant tu sais comment l’agent choisit ses actions.

Mais même la meilleure approche ne garantit pas qu’il fera toujours le bon choix.

Pourquoi ?

Parce que l’agent fonctionne sur un modèle, et qu’un modèle a ses limites.

Et c’est précisément à cause de ces limites qu’un agent peut :

  • Faire des erreurs
  • Rater un élément important
  • Ou choisir le mauvais outil
⏱️ 7 min de lectureMis à jour Mars, 2026Difficulté: ★★☆
Suite pratique

Exemples d’implémentation du patron

Passe à l’implémentation avec des projets d’exemple.

Intégré : contrôle en productionOnceOnly
Ajoutez des garde-fous aux agents tool-calling
Livrez ce pattern avec de la gouvernance :
  • Budgets (steps / plafonds de coût)
  • Permissions outils (allowlist / blocklist)
  • Kill switch & arrêt incident
  • Idempotence & déduplication
  • Audit logs & traçabilité
Mention intégrée : OnceOnly est une couche de contrôle pour des systèmes d’agents en prod.
Auteur

Cette documentation est organisée et maintenue par des ingénieurs qui déploient des agents IA en production.

Le contenu est assisté par l’IA, avec une responsabilité éditoriale humaine quant à l’exactitude, la clarté et la pertinence en production.

Les patterns et recommandations s’appuient sur des post-mortems, des modes de défaillance et des incidents opérationnels dans des systèmes déployés, notamment lors du développement et de l’exploitation d’une infrastructure de gouvernance pour les agents chez OnceOnly.