LinkedIn CV
Use case 07

Agent
Factory

Après 6 agents construits, les mêmes erreurs revenaient : paths hardcodés, années figées, documentation oubliée en fin de session. La Factory standardise la création en 6 phases séquentielles. Phase 6 dans un bloc finally : la doc ne peut plus être oubliée.

6
Phases
séquentielles
3
Fichiers générés
par Claude
0
Doc oubliée
Phase 6 en finally
Patterns · Standards · Reproductibilité
6+
agents construits avec les mêmes anti-patterns, mêmes bugs sans standard
01
Process · Industrialisation · Productivité

Sans standard,
chaque agent repart de zéro

Après plusieurs agents construits, les mêmes anti-patterns revenaient : paths hardcodés, années fixées en dur, documentation oubliée, monitoring non branché. La Factory standardise la création pour ne plus reproduire ces erreurs et capitaliser sur ce qui a déjà été appris.

Avant Chaque agent créé manuellement : structure ad hoc, doc à la fin (quand elle existe), intégration Monitor oubliée
Après 9 questions d’interview → plan validé → 3 fichiers générés par Claude → écriture sécurisée → Monitor branché → docs forcées
Ce que ça révèle
Standardiser n’est pas brider la créativité, c’est capitaliser sur ce qu’on a déjà appris. Chaque pattern codifié dans la Factory vient d’un bug réel détecté par le Monitor. Ce n’est pas de la théorie, c’est de l’expérience encodée.
Interview · Plan · Génération · Écriture · Monitor · Docs
6
phases séquentielles, rien n’est skippable
02
CLI · Séquentiel · Validation explicite

6 phases,
rien n’est skippable

Chaque phase produit un livrable validé avant de passer à la suivante. Aucun fichier n’est écrit sans confirmation. La Phase 6 est exécutée dans un bloc finally : les docs sont toujours mises à jour, même si le reste échoue.

Phase 1
Interview (9 questions)
Nom, description, type, APIs utilisées, variables d’env, outils, mode interactif/planifié, dossier destination, alias zshrc. Chaque réponse est enregistrée dans une spec dict.
Phase 2
Plan validé
Récap complet affiché dans le terminal. O/N global avant toute génération. Possibilité de corriger la spec avant de continuer.
Phase 3
3 générations Claude
agent.py (code complet basé sur agent_starter.py), CLAUDE.md (documentation basée sur AGENT_TEMPLATE.md), .env.example (variables commentées). Chaque fichier affiché avant écriture, O/N/M par fichier.
Phase 4
Écriture sécurisée
py_compile exécuté sur agent.py avant de continuer. Double-check taille fichier après écriture. Un agent avec une erreur de syntaxe ne sort jamais de la Factory.
Phase 5
Intégration Monitor
Patch automatique de monitor.py (AGENTS[] + API_TESTS{}) via regex. Diff affiché, O/N. Syntaxe Python vérifiée après le patch. Le nouvel agent est immédiatement monitoré.
Phase 6
Docs forcées (finally)
AGENTS_RELIABILITY.md + MEMORY.md mis à jour automatiquement. Exécuté dans un bloc finally : même si les phases précédentes échouent ou sont interrompues, la documentation est toujours à jour.
Ce que ça révèle
Séquencer et valider à chaque étape, c’est exactement ce qu’un PM fait quand il découpe un produit en milestones. La Factory applique la même logique à la création d’outils : rien ne sort sans avoir été vérifié, rien n’est skippé sous prétexte de gagner du temps.
Patterns issus des audits Monitor
5
anti-patterns réels encodés dans le code généré
03
Anti-patterns · Expérience encodée · Prévention

Ce qui est
encodé

Ces règles ne viennent pas de bonnes pratiques théoriques. Chacune vient d’un bug réel détecté par le Monitor sur les agents en production. Elles sont injectées dans chaque agent généré.

Règle 1
Check de path au démarrage
Tout agent qui dépend d’un dossier externe vérifie son existence au démarrage avec un message d’erreur explicite. Origin : paths hardcodés cassant le chargement des .env (Veille PM, mars 2026).
Règle 2
Pas d’année fixée en dur
datetime.now().year obligatoire, jamais une année hardcodée. Un agent conçu en 2026 tourne potentiellement en 2027 : ses requêtes ne doivent pas être périmées.
Règle 3
Fail fast si tout échoue
Si toutes les analyses échouent, arrêt propre sans rapport partiel. Ne jamais sauvegarder un historique si les résultats sont tous invalides.
Règle 4
Création de répertoires
Path.mkdir(parents=True, exist_ok=True) avant toute écriture de fichier. Ne jamais supposer qu’un dossier existe déjà.
Règle 5
Anti-doublon sur les listes
Si l’agent maintient une liste (MEMORY.md, historique JSON, BDD), vérifier l’unicité avant insertion. Origin : doublons dans MEMORY.md détectés lors d’un audit Monitor.
Ce que ça révèle
Un processus de création qui encode les leçons du monitoring ferme la boucle entre production et développement. Ce que le Monitor détecte, la Factory l’évite. C’est exactement ce qu’un PM appelle un feedback loop.
Finally · O/N · py_compile
3
arbitrages, chacun avec son rejet et sa conséquence
04
Arbitrages · Trade-offs · Conséquences documentées

Ce qui a été
arbitré

01
Phase 6 dans finally vs Documentation optionnelle
La documentation est la partie la plus souvent oubliée dans la création d’agents. En la plaçant dans un bloc finally, elle s’exécute même si les phases précédentes échouent ou sont interrompues. La dette documentaire est structurellement impossible.
Sans ce choix : le code et la documentation divergent dès la première session, ce qui est exactement le problème qu’on cherchait à éviter.
02
O/N explicite à chaque étape vs Génération entièrement automatique
Chaque fichier généré est affiché avant écriture. L’utilisateur valide (O), skippe (N) ou corrige (M). La Factory ne décide jamais seule. Cette contrainte ralentit le processus mais garantit que ce qui est écrit est exactement ce qui était voulu.
Sans ce choix : des fichiers générés incorrects écrasés sans revûe, avec des bugs introduits silencieusement.
03
py_compile avant écriture vs Vérification manuelle
Chaque agent.py généré est vérifié syntaxiquement avant d’être écrit sur le disque. Un agent avec une erreur de syntaxe ne sort jamais de la Factory : la vérification est systématique, pas optionnelle.
Sans ce choix : des agents avec des erreurs de syntaxe sont écrits et ne fonctionnent pas au premier run, avec perte de temps et perte de confiance dans le processus.
Ce que ça révèle
Un outil de création qui n’est pas rigoureux sur lui-même produit des agents qui ne le sont pas non plus. Les contraintes de la Factory (validation, vérification, documentation forcée) sont les mêmes qu’on attend des agents qu’elle crée.