Dev, IA

Les agents IA ne codent pas pour toi : ils orchestrent. Voici comment ça marche vraiment

Alexandre

·02/03/2026·

Durée de lecture : 14 min

J'ai dit à Claude "ajoute les images OG au blog". 30 secondes plus tard : 4 fichiers créés, un endpoint généré, les meta tags modifiés, le build qui passe. Je n'ai touché à rien.

Un agent de code n'écrit pas du Swift à ta place — il orchestre 6 systèmes en parallèle, lit 12 fichiers, exécute 4 commandes Bash, détecte une erreur, corrige et recommence. Tout seul.

J'ai déjà raconté comment je bosse avec Claude Code au quotidien — le CLAUDE.md, les slash commands, les 6 agents. Mais je t'ai jamais expliqué ce qui se passe vraiment sous le capot. Pourquoi c'est différent d'un chatbot qui génère du code. Et surtout : les vraies limites après 8 mois d'utilisation intensive.

Plongée technique dans l'architecture des agents de code en 2026 : boucle agentic, coordination multi-agents, protocole MCP.

Agent vs chatbot : la différence est dans la boucle

Un chatbot, c'est simple. Tu poses une question, il te répond, fin. Même les modèles les plus puissants fonctionnent comme ça : input texte, traitement, output texte. Aucune action dans le monde réel.

Un agent de code, c'est une autre espèce. C'est un système qui peut agir. Lire des fichiers, exécuter des commandes Bash, modifier du code, lancer des tests, interroger des bases de données. Et surtout, il boucle : il observe le résultat de ses actions et ajuste son raisonnement en conséquence.

La boucle classique d'un agent de code :

1. RAISONNER  →  analyser la demande et le contexte
       ↓
2. PLANIFIER  →  décider quelles actions exécuter
       ↓
3. AGIR       →  appeler des outils (Read, Write, Bash, Grep...)
       ↓
4. OBSERVER   →  lire le résultat des actions
       ↓
5. AJUSTER    →  corriger si nécessaire
       ↓
6. RECOMMENCER jusqu'à complétion

Anthropic appelle ça la boucle outil-raisonnement-action (tool-reasoning-action loop). C'est ce qui différencie fondamentalement un agent d'un copilote. Un copilote te suggère du code que tu copies-colles. Un agent le modifie directement, teste que ça compile, détecte les erreurs, les corrige, et te prévient quand c'est fini.

Concrètement, quand je demande à Claude Code d'ajouter un bouton refresh sur ma page admin, voici ce qui se passe :

Il lit le fichier concerné (AdminMarketingPage.tsx)
Il cherche les patterns existants dans le projet (hooks custom, composants, icônes)
Il modifie le fichier en ajoutant le bouton selon les conventions du projet
Il vérifie que le build TypeScript passe
Si erreur, il ajuste et réessaye

Tout ça en 30 secondes. Sans que j'aie à lui dire "regarde ce fichier, comprends ce pattern, respecte cette convention". Il le fait tout seul parce qu'il a accès aux outils et qu'il boucle.

Un chatbot te répond. Un agent agit, observe, corrige et reboucle. C'est la boucle qui change tout.

Les 4 briques qui font tourner un agent

Quand j'ai compris l'architecture, j'ai réalisé que mes 6 agents partagent les mêmes briques de base. Ce qui change entre eux, c'est leur spécialisation et leur contexte.

1. Le module de planification

C'est ce qui décompose une demande complexe en sous-tâches. Quand je dis "ajoute les images Open Graph auto-générées sur le blog + des articles similaires en bas de page", l'agent ne se jette pas sur le code. Il découpe : créer l'endpoint d'image, modifier les meta tags, créer le composant d'articles similaires, intégrer le tout.

2. La mémoire de contexte

C'est le CLAUDE.md, les conventions du projet, l'historique de la session. J'ai déjà parlé du CLAUDE.md en détail dans mon article précédent, mais pour faire simple : sans mémoire, un agent génère du code générique. Avec, il respecte l'architecture existante et évite les erreurs récurrentes. C'est ce qui fait la différence entre un agent utile et un agent qui fait n'importe quoi.

3. L'interface outils

Les outils natifs de Claude Code : Read (lire des fichiers), Write (créer), Edit (modifier), Bash (exécuter des commandes), Grep (chercher dans le code), Glob (trouver des fichiers), WebSearch (recherche web), Agent (spawner des sous-agents). Chaque agent peut avoir un sous-ensemble d'outils différent selon son rôle.

4. Le moteur de réflexion

C'est la capacité d'auto-critique. L'agent exécute une action, observe le résultat, et se demande : "est-ce que ça répond à la demande ? Est-ce que le build passe ? Est-ce que ça respecte les conventions ?" Si non, il recommence. C'est le composant le plus sous-estimé, et c'est ce qui sépare un bon agent d'un mauvais.

Pourquoi 6 spécialistes valent mieux qu'un généraliste

Pendant 2 mois, j'ai utilisé Claude Code avec un seul agent. Ça marchait. Puis un matin de janvier, je lui demande : "ajoute les images Open Graph auto-générées sur le blog + des articles similaires en bas de page + corrige le sitemap." 20 minutes plus tard, j'ai un endpoint qui génère des images... en Swift. Dans le backend Express. Avec des imports SwiftUI en plein milieu du code TypeScript. L'agent avait tout mélangé.

C'est là que j'ai compris : un agent qui fait tout, c'est comme un dev qui gère iOS + backend + QA + sécu en même temps. Ça n'existe pas. Pourquoi l'IA serait différente ?

6 agents au lieu d'un, c'est pas de l'over-engineering. C'est une équipe senior au lieu d'un stagiaire qui fait tout.

Mon setup dans .claude/agents/ :

.claude/agents/
  maestro.md         # Chef d'orchestre — ne code JAMAIS
  impl-ios.md        # Dev iOS senior (SwiftUI/Swift 6)
  impl-backend.md    # Dev backend (Express/TypeScript)
  review.md          # Gardien qualité (pre-commit, score /100, pre-merge)
  test.md            # QA automatisé (détection, exécution, analyse)
  audit.md           # Auditeur dette technique

Agent	Contexte chargé	Outils activés	Sortie attendue
maestro	Architecture globale, roadmap	Aucun (délègue uniquement)	Plan d'exécution + agents mobilisés
impl-ios	Conventions SwiftUI, Design System	Read, Write, Edit, Bash	Code Swift valide + tests
impl-backend	Express, Sequelize, ref.conf.json	Read, Write, Edit, Bash	Endpoints + migrations
review	Guidelines qualité, OWASP top 10	Read, Grep, Glob	Score /100 + corrections
test	Suites de tests existantes	Read, Bash, Grep	Résultats + couverture
audit	Historique du codebase	Read, Grep, Glob	Rapport dette technique

Le gain est double. Chaque agent a un contexte réduit (il ne charge que ce dont il a besoin), donc il raisonne mieux. Et les agents ne se polluent pas entre eux : les détails d'implémentation iOS ne viennent pas encombrer le contexte du dev backend.

Comment les agents collaborent sans se marcher dessus

Le vrai défi, c'est pas de faire 6 agents. C'est de les faire collaborer sans qu'ils se marchent dessus.

Le pattern superviseur

Mon maestro est le point d'entrée. Il ne code pas. Il ne rédige pas. Il analyse, décide, délègue et valide. Sa description :


Tu es le Maestro de l'équipe Livate.
Tu ne codes PAS. Tu ne rédiges PAS de spec.
Tu analyses, tu décides, tu délègues, tu coordonnes,
et tu valides le résultat.

Maestro ne code jamais. Il analyse, délègue, coordonne et valide. Comme un CTO qui ne touche plus au code depuis 3 ans.

Exemple réel : la feature OG images

La semaine dernière, j'ai demandé : "ajoute les images Open Graph auto-générées sur le blog + des articles similaires en bas de page."

Etape 1 — le maestro analyse :

Il identifie 2 features indépendantes, évalue la complexité, et décide de paralléliser.

Etape 2 — il délègue en parallèle :

Agent: impl-backend
Tâche: Créer l'endpoint /api/og/route.tsx (image OG dynamique)

Agent: impl-ios
Tâche: Créer SimilarArticles.tsx + intégration [slug]/page.tsx

Etape 3 — les sous-agents agissent :

impl-backend lit la doc de @vercel/og, crée le fichier, ajoute les meta tags, teste la génération d'image.

impl-ios lit ArticleCard.tsx pour comprendre le design existant, crée le composant, l'intègre en bas de page, vérifie la cohérence visuelle.

Etape 4 — le maestro valide :

Les 2 sous-agents retournent un résumé concis (pas tout le code, juste le résultat). Le maestro vérifie que le build passe, que les conventions sont respectées, et lance le commit.

Sauf que. Le build passe, mais quand je teste l'image OG sur Twitter Card Validator, elle s'affiche en 404. Pourquoi ? Parce que impl-backend a créé l'endpoint mais a oublié de mettre à jour la config qui bloque les routes /api/* non autorisées. Un truc qu'un dev aurait vu en 2 secondes parce qu'il connaît l'infra. Il a fallu que je lui dise : "vérifie les middlewares et la config de route."

Résultat final : 4 fichiers créés/modifiés, 1 config ajustée, 25 minutes au lieu de 20. Pas magique, mais toujours 10x plus rapide qu'à la main.

Le scope mémoire : éviter la pollution

Chaque sous-agent retourne un résumé de 200 tokens max au maestro. Exemple : quand impl-backend crée un endpoint, il ne retourne pas les 150 lignes de code. Il retourne :


Endpoint /api/og/route.tsx créé
- Génère une image 1200x630 avec titre + excerpt
- Utilise @vercel/og
- Meta tags ajoutés dans [slug]/page.tsx

Le maestro sait que c'est fait, mais son contexte n'est pas pollué par les détails d'implémentation. C'est ce qui permet d'enchaîner les features sans saturation.

MCP : le protocole qui connecte l'IA au monde extérieur

Claude Code sait lire des fichiers, exécuter des commandes Bash, chercher dans le code. Mais pour taper dans GitHub, Figma, ta base de données ou Google Analytics, faut brancher le Model Context Protocol (MCP). C'est le système de plugins standardisé qui connecte l'IA au reste du monde.

Comment ça marche

Un serveur MCP, c'est un petit processus qui tourne en arrière-plan et expose des outils via une API standardisée. Claude peut appeler ces outils comme s'ils étaient natifs.

Exemple avec GitHub. Tu configures le serveur dans .claude/mcp.json :


{
  "servers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Une fois configuré, Claude peut lister les issues, créer des pull requests, commenter des reviews, merger un PR. Tu dis juste "crée une PR pour cette feature", et Claude utilise l'outil MCP correspondant.

MCP, c'est USB-C pour les agents IA. Un seul protocole, tous les outils deviennent compatibles. Fini le bricolage.

Cas d'usage concrets

Figma → Code : le serveur MCP Figma permet à Claude de lire les designs, extraire les couleurs, les espacements, et générer du code SwiftUI ou React qui respecte la maquette.

Base de données : le serveur MCP PostgreSQL permet à Claude d'interroger directement ta BDD, analyser les schémas, générer des migrations. "Quels utilisateurs n'ont jamais commenté d'article ?" → Claude exécute la requête et te donne la réponse.

Analytics : un serveur MCP custom peut exposer l'API Google Analytics 4. Claude analyse tes stats de trafic, détecte des anomalies, propose des optimisations SEO.

Les 3 pièges du MCP (que j'ai tous fait)

L'explosion de complexité. Plus tu ajoutes de serveurs MCP, plus Claude a d'outils disponibles. Passé un certain point, il devient confus et choisit mal ses outils. Ma règle : maximum 5 serveurs MCP actifs. Au-delà, crée des agents spécialisés avec des subsets d'outils.

Les erreurs silencieuses. Un serveur MCP mal configuré peut échouer sans que Claude te prévienne. J'ai déjà eu des sessions où Claude essayait d'utiliser l'outil GitHub MCP, ça échouait en silence, et il passait à autre chose. Résultat : la PR n'était jamais créée. Ma règle : toujours vérifier manuellement les actions critiques.

Les fuites de credentials. Les serveurs MCP ont besoin de tokens. Si tu les mets en dur dans .claude/mcp.json, tu risques de les commiter par erreur. Ma règle : variables d'environnement uniquement, et tout ce qui est dans .claude/ va dans .gitignore.

Retour d'expérience : les gains concrets

Maintenant que tu connais l'architecture, parlons de la vraie question : est-ce que ça marche ?

Métrique	Avant Claude Code	Avec Claude Code	Gain
Feature moyenne	1-2 jours	1-2 heures	10x
Refactor backend	1 semaine	1 journée	5x
Rédaction article blog	3-4 heures	1 heure	3x
Audit SEO complet	1 journée	30 minutes	15x

Mais ce n'est pas juste une question de vitesse. C'est aussi la qualité. Avant, mes commits étaient brouillons. Je mélangeais plusieurs features, j'oubliais de mettre à jour la doc, je laissais des console.log() traîner. Maintenant, Claude suit un checklist strict : build, tests, lint, doc, message de commit structuré. Mon historique Git est 10x plus propre.

Quand Claude est meilleur que moi

Les fichiers de config. Docker Compose, Tailwind, TypeScript, ESLint, Liquibase. Claude connaît toutes les options, ne fait pas de typo, et respecte les conventions. Mon docker-compose.yml de 150 lignes, je ne l'ai jamais écrit à la main.

Les tests unitaires. Ecrire des tests, c'est rébarbatif. Claude les génère en 10 secondes, couvre les edge cases, mocke les dépendances proprement. Mon taux de couverture a explosé.

Les migrations de versions. Migrer de Next.js 14 à 15, c'est des centaines de petits changements. Claude lit le changelog, identifie les breaking changes, et refactor le projet en 2 heures. A la main, ça m'aurait pris 2 jours.

Les tâches répétitives. Renommer 50 variables dans 20 fichiers. Ajouter un champ dans 15 interfaces TypeScript. Tout ce qui est mécanique, Claude le fait en 30 secondes sans se plaindre.

Les 5 trucs que l'IA rate encore

C'est pas magique. 5 situations où Claude galère :

1. Les décisions produit

Claude ne sait pas pourquoi tu construis cette feature. Il peut t'implémenter un système de notification push en 30 minutes, mais il ne te dira jamais si c'est vraiment ça dont tes utilisateurs ont besoin. La vision produit, c'est 100% toi.

2. Les bugs obscurs

La semaine dernière, un crash intermittent de l'app iOS. Uniquement sur iPhone 12 mini, en mode sombre, après 20 minutes d'utilisation. Claude a proposé 10 solutions, aucune ne marchait. J'ai fini par débugger manuellement avec Instruments et Xcode. Les bugs qui dépendent d'un état global complexe, c'est encore un job d'humain.

3. L'over-engineering

Le piège classique. Y'a 3 jours, je demande un simple tri sur la liste des articles du blog. Par date décroissante, c'est tout. Je reçois : un système de tri configurable avec 3 enums pour les priorités (DATE, VIEWS, LIKES), un cache pour stocker l'ordre, des logs détaillés à chaque appel, et un fichier de config pour activer/désactiver les algos. 187 lignes pour un .sort() qui en prenait 12.

J'ai appris à être ultra spécifique : "Trie la liste par date décroissante. Un seul .sort(), rien d'autre." Pas de place pour l'interprétation. Un agent non cadré, c'est un dev qui veut briller sur Hacker News au lieu de livrer.

4. Les performances

Claude produit du code qui marche, mais pas forcément du code optimisé. Il ne va pas détecter qu'une requête SQL fait 3 boucles imbriquées au lieu d'un seul JOIN. Ou qu'un composant React se re-render 50 fois par seconde. Les optimisations de perfs, c'est encore un job de senior dev.

5. La sécurité

Le plus vicieux. Claude peut te générer un endpoint Express qui marche parfaitement, passe tous les tests, et qui expose une faille évidente. Exemple réel : un endpoint /api/users/:id qui ne vérifiait pas que l'utilisateur connecté avait le droit de modifier cet ID. N'importe qui pouvait modifier n'importe quel profil.

Anthropic a lancé Claude Code Security en février 2026 pour détecter ce genre de trucs. Mais un audit manuel reste indispensable sur tout ce qui touche à l'auth, les paiements, ou les données sensibles.

Un agent génère du code qui marche. Pas du code qui résiste à 10 000 utilisateurs. La différence, c'est 3 ans d'expérience en prod.

Ce qui arrive dans les 12 prochains mois

Les agents de code, c'est plus une beta pour geeks. C'est mainstream. Et voici 4 trucs que je vois arriver dans les 12 prochains mois.

Les équipes d'agents deviennent la norme

Anthropic le dit dans leur rapport 2026 sur le coding agentique : on passe d'agents individuels à des équipes coordonnées. Dans 1 an, avoir un seul agent sera considéré comme archaïque. Tout le monde aura un orchestrateur + 5-10 agents spécialisés.

Le MCP devient un standard universel

Microsoft, Google, OpenAI, Anthropic convergent tous vers le Model Context Protocol. En 2027, n'importe quelle app SaaS aura un serveur MCP officiel. Figma, Notion, Linear, Stripe, Vercel. Tu pourras piloter toute ta stack depuis un terminal.

Ce que j'attends : une mémoire long-terme

Aujourd'hui, Claude oublie tout entre deux sessions (sauf ce qu'il y a dans le CLAUDE.md). J'aimerais qu'il se souvienne que je préfère TypeScript strict, que j'utilise React Query, que je déteste les ternaires imbriquées. Qu'il s'adapte à moi au fil des semaines, sans que j'aie à tout re-documenter dans le CLAUDE.md.

Le dev devient architecte de systèmes agentiques

Le code devient une commodité. N'importe qui peut générer 10 000 lignes en 1 heure. Ce qui a de la valeur, c'est savoir quoi construire, comprendre les besoins utilisateurs, structurer le contexte pour les agents, et valider la qualité du code généré.

Le dev de 2027 passe plus de temps à lire du code qu'il n'a pas écrit qu'à en taper. Il orchestre, il valide, il corrige. Le clavier devient secondaire.

En 2027, tu auras un agent qui veille sur ton repo pendant que tu dors. Et un autre qui audite le premier.

5 conseils si tu te lances

1. Commence petit. Ne configure pas 10 agents dès le premier jour. Commence par 1 agent généraliste, ajoute un CLAUDE.md solide, et itère. Quand un type de tâche revient souvent (tests, refactor, audit), là tu crées un agent dédié.

2. Documente tes patterns. Le CLAUDE.md, c'est ton meilleur investissement. 2 heures à y mettre l'architecture, les conventions, les erreurs récurrentes. Mets-le à jour chaque semaine. C'est ce qui fait la différence entre un agent qui génère du code random et un agent qui respecte ton projet.

3. Valide toujours les actions critiques. Jamais de merge automatique, jamais de déploiement automatique, jamais de suppression sans validation manuelle. Les agents sont puissants, mais ils font des erreurs. Un humain doit avoir le dernier mot sur ce qui va en production.

4. Commit avant chaque refactor. Quand Claude casse 12 dépendances en voulant "nettoyer", tu reviens en arrière en 10 secondes. Git est ton filet de sécurité.

5. Laisse explorer avant de coder. Avant "implémente X", demande "comment fonctionne Y dans le projet ?". Claude va lire les fichiers, comprendre les patterns, et son implémentation sera cohérente avec l'existant.

Conclusion

Les agents de code, ce n'est pas un copilote amélioré. C'est un changement de paradigme. On passe de "je tape du code" à "je structure du contexte et j'orchestre des agents".

La boucle agentic. Les 4 briques. Le multi-agents. Le protocole MCP. C'est l'infrastructure invisible qui change la donne. Et la vraie valeur n'est plus dans la ligne de code — elle est dans la vision produit, la compréhension des besoins utilisateurs, et la capacité à piloter une équipe d'agents sans se faire embarquer dans de l'over-engineering.

8 mois que je bosse comme ça. Une app en prod. Un blog. Un backend. Tout ça en solo. Pas parce que l'IA a tout codé, mais parce que j'ai arrêté de coder et que j'ai commencé à orchestrer.

Et toi, tu codes avec des agents ? Tu galères avec quoi ? Le contexte qui sature ? L'over-engineering ? Dis-le moi sur X, LinkedIn ou en commentaire.

Alex

À retenir

Un chatbot te répond. Un agent agit, observe, corrige et reboucle. C'est la boucle agentic qui change tout.
6 agents spécialisés, c'est pas de l'over-engineering. C'est une équipe senior au lieu d'un stagiaire qui fait tout.
MCP, c'est USB-C pour les agents IA. Un seul protocole, tous les outils deviennent compatibles.
L'IA rate encore 5 choses : over-engineering, duplication, sécurité, tests d'intégration, et UX. Le dev reste indispensable.
La valeur n'est plus dans la ligne de code. Elle est dans la vision produit et la capacité à orchestrer.

← Retour aux articles

Commentaires

Tu as un avis sur cet article ?

Crée un compte gratuit en 10 secondes pour commenter, laisser des likes et recevoir les prochains articles directement dans ta boîte mail.

Pas encore de compte ?

Les agents IA ne codent pas pour toi : ils orchestrent. Voici comment ça marche vraiment

Agent vs chatbot : la différence est dans la boucle

Les 4 briques qui font tourner un agent

Pourquoi 6 spécialistes valent mieux qu'un généraliste

Comment les agents collaborent sans se marcher dessus

Le pattern superviseur

Exemple réel : la feature OG images

Le scope mémoire : éviter la pollution

MCP : le protocole qui connecte l'IA au monde extérieur

Comment ça marche

Cas d'usage concrets

Les 3 pièges du MCP (que j'ai tous fait)

Retour d'expérience : les gains concrets

Quand Claude est meilleur que moi

Les 5 trucs que l'IA rate encore

1. Les décisions produit

2. Les bugs obscurs

3. L'over-engineering

4. Les performances

5. La sécurité

Ce qui arrive dans les 12 prochains mois

Les équipes d'agents deviennent la norme

Le MCP devient un standard universel

Ce que j'attends : une mémoire long-terme

Le dev devient architecte de systèmes agentiques

5 conseils si tu te lances

Conclusion

À retenir

Articles similaires

10 leviers pour diviser ta facture de tokens par 5 (Copilot, Claude Code, Cursor)

Le vibe coding trap : 97 % des apps générées par IA ne sont jamais déployées

Comment j'ai divisé par 2 ma consommation de tokens sur Claude Code

Commentaires

Commentaires