---
title: "L'IA agentique — ce qui change vraiment par rapport à l'IA classique"
description: "Mémoire, outils, orchestration, boucle agir-observer : comprendre l'IA agentique de fond en comble pour un développeur qui veut aller plus loin que le prompt."
created: 2026-05-28T10:00:00+02:00
updated: 2026-05-28T10:00:00+02:00
tags: ["IA", "Agents", "Architecture", "Tooling"]
color: "#8b5cf6"
image: /images/blog/ia-agentique-cover.webp
card: /images/blog/ia-agentique-card.webp
---

Un modèle de langage répond à un message. Un agent, lui, poursuit un objectif.

C'est la distinction fondamentale, et elle est plus profonde qu'elle n'y paraît. Quand on utilise un LLM de façon classique — une question, une réponse — le modèle est passif. Il reçoit un texte, il produit un texte. L'action appartient à l'humain. Dans un système agentique, cette séparation s'efface : l'IA peut observer, décider, agir, puis observer à nouveau. Elle opère sur le monde, pas seulement sur du texte.

Ce changement de paradigme a des conséquences architecturales précises. Voici comment ça fonctionne.

## La boucle fondamentale : agir-observer

Un agent n'est pas un programme linéaire qui exécute des étapes dans un ordre fixe. C'est un système qui tourne en boucle. À chaque itération :

1. Il reçoit un **contexte** : état actuel du problème, mémoire des échanges précédents, résultats des actions passées.
2. Il **raisonne** : produit un plan ou identifie la prochaine action pertinente.
3. Il **agit** : appelle un outil, modifie un fichier, envoie une requête, écrit un message.
4. Il **observe** : récupère le résultat de l'action et l'intègre dans son contexte.
5. Il recommence, jusqu'à ce que l'objectif soit atteint ou qu'un point d'arrêt soit atteint.

Cette boucle ressemble structurellement à celle d'un programme classique avec une boucle événementielle — sauf que le moteur de décision est un LLM, capable de s'adapter à des situations non anticipées et d'interpréter des instructions en langage naturel.

![La boucle agir-observer : contexte, mémoire et outils alimentent le LLM qui agit sur le monde, l'observation referme la boucle](/images/blog/ia-agentique-diagram.webp)

## La mémoire : ce qui différencie un agent d'un script

Un script lit des paramètres et produit un résultat. Un agent accumule de l'état au fil du temps.

La mémoire dans un système agentique prend plusieurs formes :

**Mémoire à court terme** — la fenêtre de contexte du LLM. Tout ce qui s'y trouve est directement accessible au modèle : l'historique des échanges, les résultats des outils appelés, les instructions système. Elle est volatile : elle disparaît quand la session se termine.

**Mémoire à long terme** — des fichiers persistants sur disque. Un agent peut écrire dans des fichiers de mémoire entre deux runs, relire ce qu'il a appris lors d'exécutions précédentes, et adapter son comportement en conséquence. C'est ce qui permet à un agent de s'améliorer dans le temps : il accumule des leçons, des conventions, des erreurs à ne pas répéter.

**Mémoire sémantique** — une base vectorielle, pour les systèmes plus élaborés. Plutôt que de lire toute la mémoire à chaque run, l'agent effectue une recherche par similarité pour récupérer les informations les plus pertinentes au contexte courant. Utile quand la mémoire devient trop volumineuse pour tenir dans le contexte.

La distinction entre mémoire court terme et long terme est critique pour comprendre pourquoi un agent peut être cohérent à l'intérieur d'une session mais incohérent d'une session à l'autre si la mémoire persistante n'est pas gérée.

## Les outils : comment l'agent agit sur le monde

Un LLM seul ne peut que produire du texte. Les outils sont ce qui lui donne une capacité d'action.

Techniquement, un outil est une fonction que l'agent peut appeler, dont le LLM connaît la signature (nom, paramètres, description), et dont le résultat est réintégré dans le contexte. Du point de vue du modèle, appeler un outil ressemble à écrire une ligne de code — il sait ce que la fonction fait, il choisit de l'appeler avec les bons paramètres, et il reçoit la valeur de retour.

Les outils courants dans un système agentique :

- **Lecture/écriture fichiers** — l'agent peut lire le code source, modifier des fichiers, créer de nouveaux documents.
- **Exécution de commandes** — lancer des scripts, des tests, des builds, des migrations.
- **Appels API** — interroger des services externes, créer des issues, poster des messages.
- **Recherche** — grep dans le codebase, recherche web, requêtes base de données.
- **Sous-agents** — appeler d'autres agents spécialisés, déléguer des sous-tâches.

La liste des outils disponibles définit le périmètre d'action de l'agent. Un agent de code review qui n'a accès qu'à la lecture de fichiers ne peut pas fusionner une PR. Cette contrainte est une fonctionnalité, pas une limitation : elle permet de calibrer précisément ce qu'un agent est autorisé à faire.

## L'orchestration : plusieurs agents, une mission

Un seul agent peut couvrir un domaine. Plusieurs agents orchestrés peuvent couvrir un processus entier.

L'orchestration est la coordination de plusieurs agents spécialisés vers un objectif commun. Chaque agent a un rôle défini, un périmètre d'outils limité, des instructions précises. L'orchestrateur — qui peut lui-même être un LLM — décompose la mission globale en sous-tâches et les assigne aux bons agents.

Cette architecture a des propriétés intéressantes :

**Spécialisation** — un agent de contenu n'a pas besoin de savoir déployer en production. La spécialisation réduit les risques d'hallucination en domaine non maîtrisé et produit des outputs plus fiables dans le domaine couvert.

**Parallélisme** — des agents indépendants peuvent travailler simultanément sur des tâches non conflictuelles. Ce qui prendrait plusieurs heures de façon séquentielle peut être compressé en minutes.

**Auditabilité** — chaque agent laisse une trace de ses actions. Dans un système comme [KittyClaw](https://kittyclaw.dev), chaque mouvement de ticket, chaque commentaire, chaque commit est attribué à l'agent qui l'a produit. On peut rejouer l'historique et comprendre pourquoi le système a pris telle ou telle décision.

**Robustesse** — un agent qui échoue n'impacte pas les autres. Le système peut gérer l'erreur localement (retenter, escalader à un humain, passer à la tâche suivante) sans que l'ensemble s'effondre.

## Le harnais : l'infrastructure d'exécution

L'orchestrateur et le harnais jouent des rôles distincts qu'il est utile de ne pas confondre.

L'**orchestrateur** décide quoi faire et quand : il décompose l'objectif global, sélectionne l'agent approprié pour chaque sous-tâche, assigne le travail et gère les dépendances. Il opère au niveau de la logique métier.

Le **harnais** est l'infrastructure qui exécute concrètement chaque agent. Il prend en charge :

- **L'injection de contexte** — charger les fichiers de skill, de mémoire persistante et les instructions système avant de lancer l'agent. L'agent ne reçoit pas un prompt nu, il reçoit un environnement préparé.
- **La gestion des permissions** — définir quels outils sont disponibles dans ce run précis : lecture seule, écriture limitée à un répertoire, accès API autorisé ou non.
- **Le cycle de vie** — lancer l'agent en réponse à un déclencheur, surveiller son exécution, capturer son output, gérer les timeouts et les erreurs.
- **La traçabilité** — enregistrer chaque action de l'agent de manière structurée, pour audit et débogage.

Dans [KittyClaw](https://kittyclaw.dev), cette séparation est explicite : l'engine de dispatch est l'orchestrateur (il lit les tickets, applique les règles d'assignation, déclenche les runs), et le harness est ce qui enveloppe chaque invocation de `claude` CLI — en injectant le preamble, la skill, la mémoire, et en reportant le résultat sur le ticket correspondant.

Cette distinction a une conséquence pratique : on peut changer de modèle LLM sans toucher à la logique d'orchestration, et on peut modifier les règles d'assignation sans toucher à l'environnement d'exécution de chaque agent.

## Le coût en tokens : ne pas déléguer au LLM ce qu'un script peut faire

Les systèmes agentiques ont un coût opérationnel qui n'existe pas dans les usages classiques des LLM : chaque étape de la boucle agir-observer passe l'intégralité du contexte courant dans le modèle. À mesure que la session avance — historique des échanges, résultats des outils appelés, mémoire injectée — le contexte grossit, et le coût en tokens croît avec lui.

Un agent qui exécute 20 étapes sur un contexte de 50 000 tokens peut représenter plusieurs millions de tokens facturés sur une seule tâche. Sur un projet avec des dizaines d'agents qui tournent en parallèle, la facture peut devenir significative très vite.

La règle d'or est simple : **ne pas demander au LLM ce qu'un script déterministe peut faire**.

Si le résultat d'une action est prévisible à partir de règles fixes — changer le statut d'un ticket quand un commit est pushé, poster un commentaire automatique quand une CI passe au vert, archiver un fichier selon une convention de nommage — alors c'est le travail d'une automation, pas d'un agent.

[KittyClaw](https://kittyclaw.dev) applique ce principe au niveau de son moteur d'automations. Les déclencheurs simples (`ticketInColumn`, `statusChange`, `ticketCommentAdded`) sont traités directement par des règles sans invoquer de LLM. Le modèle n'est appelé que pour les tâches qui nécessitent effectivement du jugement : lire le contenu d'un ticket et décider quoi faire, analyser du code et produire une review, écrire un article à partir d'un brief.

```json
{
  "trigger": { "type": "ticketInColumn", "columns": ["Todo"] },
  "conditions": [{ "type": "assignedTo", "slugs": ["content-writer"] }],
  "actions": [
    { "type": "moveTicketStatus", "to": "InProgress" },
    { "type": "runAgent", "agent": "content-writer" }
  ]
}
```

Dans cet exemple, le mouvement de colonne et le lancement de l'agent sont orchestrés par le harness sans toucher à un LLM. L'agent lui-même est invoqué une seule fois, avec un contexte propre, pour faire le travail qui justifie son existence.

Ce principe de sobriété token n'est pas seulement une question de coût. C'est aussi une question de fiabilité : moins de contexte inutile dans la fenêtre, moins de risque que l'agent se perde dans des informations non pertinentes. Un agent bien délimité — avec un contexte ciblé et des automations qui prennent en charge les étapes mécaniques — produit des résultats plus cohérents qu'un agent généraliste à qui on a tout confié.

## Ce qui ne change pas : le jugement humain

L'IA agentique est puissante parce qu'elle peut agir sans supervision constante. Elle est risquée pour exactement la même raison.

Un agent bien configuré reste dans son couloir. Mais les cas limites existent : une ambiguïté dans la spec, un état du système inattendu, une décision qui aurait des conséquences irréversibles. Sans mécanisme de délégation vers un humain, l'agent continue — soit en improvisant, soit en se bloquant silencieusement.

Les systèmes agentiques matures intègrent des points de contrôle humains explicites. Ce n'est pas un aveu de faiblesse du système : c'est une conception intentionnelle. Le design idéal n'est pas un agent totalement autonome, mais un agent autonome dans son périmètre et transparent sur ses limites.

C'est là que l'orchestration humaine garde toute sa valeur : non pas pour faire ce que les agents font bien, mais pour prendre les décisions que les agents ne devraient pas prendre seuls.

---

*Ce texte est l'article de fond de référence sur l'IA agentique pour le blog Ekioo. Les retex opérationnels (pièges de parallélisme, mémoire, visibilité) sont dans [L'hygiène des systèmes agentiques](/blog/hygiene-systemes-agentiques). La mise en pratique multi-projet est dans [Cadence plutôt que volume](/blog/cadence-agents-5-projets).*