Agents éphémères : j'ai tenté de supprimer la maintenance de mes agents IA — voilà ce que j'ai trouvé

Pendant plusieurs semaines, j'ai maintenu un RAG personnel qui pilote Claude Code sur mes projets. Au départ : quelques agents, quelques skills, un système de rules. Simple.

Aujourd'hui : 176 fichiers agents répartis en globaux et locaux, 24 fichiers CLAUDE.md, 10 fichiers de rules, 1 117 skills indexés en base vectorielle. Et surtout — la conviction croissante que je passais plus de temps à corriger des incohérences entre fichiers qu'à produire du code.

C'est dans ce contexte que j'ai décidé de tester une approche radicalement différente : les agents éphémères. Plus de fichiers à maintenir. L'IA génère l'agent dont elle a besoin, en temps réel, depuis les skills disponibles dans le RAG. Zéro friction, couverture illimitée.

La réalité est plus nuancée. Voici ce que j'ai mesuré.

Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.

Le problème réel : 210 fichiers de configuration d'IA à maintenir

Agents statiques vs dynamiques : ce que signifie "maintenir" un agent

Un agent .md dans Claude Code, c'est un fichier Markdown qui décrit un rôle, un processus, des compétences, des règles. C'est intentionnel, versionnable, testable. C'est aussi un fichier qui vieillit.

Quand vous modifiez une convention de nommage, vous devez la propager dans potentiellement des dizaines d'agents. Quand un agent global et sa variante locale d'un projet divergent, il n'existe aucun mécanisme automatique pour vous en avertir. Quand deux projets utilisent des agents "équivalents" définis séparément, la cohérence dépend de la mémoire de l'équipe.

Dans mon système :

Le signal d'alarme : auto-sync à 0 déclenchements

210 fichiers de configuration d'IA à maintenir à la main. Avec un hook auto-sync-rules censé détecter les dérives — qui affiche 0 déclenchements sur les 7 derniers jours.

C'est insoutenable à l'échelle.

Ce que promettent les agents éphémères

Le pipeline en 8 étapes de /compose

La commande /compose dans Claude Code implémente un pipeline en 8 étapes pour générer des agents à la volée :

1. Traduction du prompt (FR→EN pour la recherche vectorielle)
2. Recherche enrichie (searchAgentEnriched()) : embeddings + graphe de connaissance
3. Repondération par la conscience de session (Markov + continuité)
4. Early-exit si un agent statique score > 0.55
5. Filtre de cohérence (élimination des domaines divergents)
6. Synthèse LLM via qwen3:4b local : génération du rôle, du domaine, du startup
7. Directive domain-aware avec steps injectés selon le contexte
8. Contrat de sortie BMAD V6

La promesse de couverture illimitée sans friction

La promesse : pour chaque tâche, un agent ad-hoc, parfaitement calibré, construit depuis la base de connaissances. Pas de fichier à créer, couverture illimitée.

Les données réelles : 61 % d'échec

Un taux d'échec de 61 %

Sur 74 tâches éphémères enregistrées dans ma base agent_tasks :

done   : 29  (39 %)
failed : 45  (61 %)

Sur deux agents éphémères créés, un seul aboutit. Ce n'est pas une anomalie ponctuelle. C'est le taux de base.

Cause racine : confusion agents/skills dans le pool RAG

Le problème ne vient pas de la qualité du modèle de génération, ni du seuil de similarité. Il vient d'une confusion fondamentale dans la structure du pool RAG.

La fonction searchAgentEnriched() — chargée de sélectionner les skills pour l'agent éphémère — ne filtre pas par type d'entrée. Elle retourne indistinctement :
- Des skills (section_type = 'skill' ou 'learned-skill') — ce qu'on veut
- Des définitions d'agents (section_type = 'role') — ce qu'on ne veut pas

Résultat : le champ skills_used de l'agent éphémère contient des noms d'agents au lieu de noms de skills.

// Agent éphémère "prod-ssh-key-expert" → FAILED
"skills_used": ["mgrr-agent-debate-generator", "kotlin-code-writer"]

// Agent éphémère "db-sql-auditor" → FAILED
"skills_used": ["mgrr-agent-sql-auditor", "mgrr-agent-kg-visualizer"]

L'agent éphémère est constitué sur des pointeurs vers d'autres agents, pas des compétences. C'est structurellement invalide.

Les agents qui réussissent : un effet de cohérence accidentelle

Les agents qui fonctionnent présentent tous une caractéristique commune : leurs skills sélectionnés sont sémantiquement homogènes et centrés sur le même domaine.

// Agent éphémère "rag-monitoring-optimizer" → DONE
"skills_used": ["mgrr-agent-rag-optimizer", "mgrr-agent-rag-search",
                "mgrr-agent-monitoring-kpis"]

Le succès ici n'est pas une victoire du pipeline. C'est un domaine (RAG/monitoring) suffisamment bien représenté pour que même un retrieval imparfait tombe sur des entrées cohérentes.

SKILL_THRESHOLD trop permissif : pourquoi 0.3 ne suffit pas

SKILL_THRESHOLD = 0.3 (cosinus minimal pour inclure un skill) accepte des associations sémantiques faibles. Un filtre de cohérence post-hoc ne peut pas compenser un retrieval initial défaillant : si les candidats sont mauvais dès l'entrée, filtrer les domaines divergents ne change pas leur invalidité de fond.

L'absence de boucle de rétroaction (feature documentée mais non implémentée)

La documentation de /compose mentionne une fonctionnalité R4 : blacklister les combinaisons de skills qui échouent 2+ fois. Elle n'est pas implémentée. Aucune donnée de blacklist n'existe. Le pipeline reproduit les mêmes erreurs indéfiniment, sans aucune capacité d'apprentissage opérationnel.

Ce phénomène — que l'on peut appeler skill drift — est particulièrement insidieux : les skills du RAG évoluent (nouveaux patterns, nouvelles compétences apprises), mais les agents éphémères continuent à être constitués selon les mêmes associations défaillantes. Sans boucle de rétroaction, la qualité ne s'améliore pas malgré l'enrichissement continu de la base de connaissances.

Contrôle vs couverture : l'antagonisme fondamental

Ce n'est pas une opposition binaire. C'est un spectre avec deux extrêmes, chacun avec ses compromis.

Les agents fixes encodent une connaissance intentionnelle et validée : la compréhension qu'a l'utilisateur de son propre système. Ils sont testables, auditables, versionnables via git. Mais à 176 agents, la charge cognitive est réelle.

Les agents éphémères visent la composition sans friction : un agent ad-hoc pour chaque tâche, sans fichier à créer. Mais la promesse repose sur une hypothèse non vérifiée — que le système RAG peut inférer correctement la bonne composition depuis la sémantique du prompt. À 61 % d'échec, cette hypothèse est falsifiée.

Ce que cela signifie pour les CTOs

4 questions de gouvernance à se poser maintenant

Si vous construisez ou gérez un système d'agents IA en production, voici les questions que vous devez vous poser maintenant :

Q1 — Quel est le cas d'usage légitime de vos agents dynamiques ?
Si le succès est conditionné à un domaine homogène et bien représenté dans votre base de connaissances, vos agents dynamiques sont une feature de niche, pas un outil généraliste.

Q2 — Combien de fichiers de configuration d'agents maintenez-vous réellement ?
La surface de maintenance actuelle est souvent sous-estimée. Comptez agents, prompts systèmes, configurations de routing, fichiers d'instructions. Multipliez par le nombre de projets.

Q3 — Avez-vous de l'observabilité sur vos agents ?
Un agent dynamique qui échoue 61 % du temps sans alerting, sans feedback loop, sans tableau de bord — c'est un problème invisible. Ce qu'on ne mesure pas ne s'améliore pas.

La troisième voie : agents semi-définis

La réponse à Q4 n'est pas binaire. Les agents semi-définis offrent un compromis viable : l'utilisateur définit le rôle et les contraintes (partie stable, versionnée en git), l'IA sélectionne les skills dans ce périmètre (partie dynamique, tirée du RAG). Contrôle sur l'essentiel, flexibilité sur la composition. C'est aujourd'hui la direction la plus prometteuse pour les équipes qui veulent sortir de l'impasse maintenance vs couverture.

Conclusion

L'approche éphémère est séduisante parce qu'elle promet de résoudre un problème réel : la dette de maintenance des systèmes d'agents IA. Mais la promesse ne tient que si l'infrastructure sous-jacente — pool RAG, seuils, boucles de rétroaction, observabilité — est correctement construite.

Ce que j'ai appris : ce n'est pas le modèle de fichier .md qui est le problème. C'est l'absence d'outillage pour le gérer à l'échelle. Supprimer les fichiers sans résoudre le problème de fond revient à masquer la dette, pas à l'éliminer.

La vraie question pour les CTOs n'est pas "agents fixes ou éphémères ?" C'est : "Quelle est notre stratégie de gouvernance pour les composants d'IA qui pilotent nos systèmes ?"

Articles liés :

- RTK : l'outil qui m'a révélé combien mes commandes gaspillaient de tokens

- Monitoring RAG et conscience d'optimisation

- Fusion d'appels fonction : tokens, latence et oublis

Qui suis-je ?

Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.

J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.

Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.

L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.

La technologie, les méthodes, le management sont le cœur de mes compétences.

Vous pouvez me faire confiance sur ces points là.

Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr

Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100 % IA