Use case 06 · Systèmes & outillage IA
J’ai structuré la production IA comme une équipe produit : rôles définis, standards, gates obligatoires. 12 projets livrés en 3 mois. Rien n’entre ni ne sort sans passer par un contrat d’output.
Tout brief n'appelle pas les mêmes compétences. Le PM lit le contexte, active les agents nécessaires et maintient les autres en réserve.
Activer juste, c'est gagner en vélocité tout en maîtrisant sa consommation en tokens.
J’ai conçu et j’opère un pipeline de production IA composé de 9 agents spécialisés : PM, designer, frontend, backend, reviewer, QA, secu, ops, copywriter. Chaque agent a un rôle documenté, un domaine exclusif, et un output contract : ce qu’il produit, dans quel format, selon quels standards.
Chaque décision qui engage la qualité ou la sécurité passe par une validation humaine. Certaines transitions sont automatiques. D’autres sont bloquées jusqu’à validation explicite. C’est ce qui sépare un système de production d’un ensemble d’outils qui fonctionnent à peu près.
12 projets livrés via ce pipeline en 3 mois : sites statiques, agents Python, dashboards clients, guides HTML, scripts d’automatisation. Un agent transversal trace la consommation tokens de chaque livrable. Les agents permanents (cron, Notion) rejoignent la flotte via un process dédié en 6 phases qui intègre le monitor et la documentation dès la création.
L’agent secu est séparé du reviewer. Ce n’est pas une question de niveau : c’est une question de posture. Le reviewer vérifie que le code fait ce qu’il doit faire. Le secu vérifie qu’il ne peut pas être détourné. Un agent qui doit tenir les deux positions en même temps tient mal les deux.
La régression prompt est le risque invisible du pipeline IA. J’ai mis en place deux verrous. Un reviewer valide chaque modification de prompt avant déploiement en vérifiant qu’aucune règle existante n’a été supprimée et qu’aucune contradiction n’a été introduite. Le QA valide les output contracts après chaque changement. Rien ne passe sans validation explicite.
L’agent secu pense comme un attaquant. Son rôle n’est pas de vérifier la qualité du code : c’est de trouver ce qui peut être exploité, détourné, ou exposé involontairement. Il audite le code, les flux de données, les surfaces d’attaque spécifiques aux systèmes LLM. Son verdict est un gate : rien ne part chez un client sans qu’il soit passé.
Premier audit en production : l’agent Brisquard, livré à un CEO de cabinet executive search. Trois findings. Un critique : les analyses stratégiques générées par l’agent étaient publiées sur un dashboard public, sans authentification. N’importe qui avec le lien pouvait y accéder. Deux risques : des articles RSS externes pouvant modifier les instructions du modèle (prompt injection), et une adresse email hardcodée directement dans le code source. Tout corrigé avant livraison.
check-agents est un agent Python qui audite chaque jour tous les agents en production. Il teste le code, les appels API live, et produit un score sur 4 critères : Fonctionnel (ça tourne ?), Précis (les outputs sont corrects ?), Stable (pas de dérive entre les runs ?), Couvrant (tous les cas sont traités ?).
Le résultat est un rapport HTML avec l’historique des scores, les régressions détectées entre les runs, et une liste de corrections proposées, validées O/N par une décision humaine. Ce score sort d’une mesure réelle.
Scores en production au 29 avril 2026 : Agent Veille PM 91%, Agent Spotify 90%.
Un agent dédié trace la consommation de tokens par tâche, détecte les anomalies et produit un rapport HTML après chaque projet. L’objectif est de savoir si une tâche coûte plus que prévu, et pourquoi. L’objectif est de comprendre, pas de rogner.
Ce qui rend l’outil utile sur la durée, c’est la mémoire cross-projets. Les baselines s’accumulent projet après projet. À partir du 3e projet tracké, les recommandations deviennent comparables : on sait si un brief mieux structuré réduit les itérations, si un type de livrable est systématiquement plus coûteux, si on progresse.
Chaque run du monitor écrit ses scores dans scores_history.json. La comparaison entre deux runs est automatique : toute baisse de score génère un flag dans le rapport. La tendance sur plusieurs runs est visible.
C’est la seule façon de savoir si une correction introduite quelque part dégrade autre chose. Pas un tableau de bord pour paraître sérieux. Le monitor est lui-même soumis au même standard que les agents qu’il surveille.
Trois niveaux de modèles, trois usages distincts. Haiku absorbe les tâches mécaniques : recherches, lookups, formatage, analyse de logs. Sonnet est le modèle par défaut pour le développement, la review, le QA, le copy. Opus est réservé aux décisions qui coûtent cher à défaire : audit sécurité, architecture, debug sans piste.
Le PM recommande un modèle au démarrage de session si le brief le justifie. Matthieu garde la décision finale. Ce n’est pas du contrôle par principe : c’est parce que le choix du modèle change ce qui est produit, pas seulement ce que ça coûte.
Les outputs d’un LLM valent ce que vaut le contexte qu’on lui donne. J’ai structuré mon espace de travail en 5 zones (Inbox, Projects, Casquettes pour les responsabilités continues, Resources, Archive) pour que le contexte soit toujours disponible, structuré et à jour.
Chaque projet a un CLAUDE.md : fichier d’initialisation que Claude lit en premier à chaque session. Il contient l’état du projet, les contraintes non négociables, les décisions prises et leur rationale, la stack, les fichiers clés. En 30 secondes de lecture, l’agent est contextualisé sans qu’on lui réexplique depuis le début.
MEMORY.md est un fichier d’index persistant chargé automatiquement à chaque session Claude Code. Il contient l’état des projets actifs, les décisions structurantes, les scores des agents, les URLs en production, les credentials et leurs chemins.
Les « casquettes » organisent les responsabilités continues : chaque domaine (portfolio, agents, veille, UMAMI…) a sa propre fiche. La _knowledge/ centralise les patterns réutilisables : stack de référence, prompts validés, anti-patterns encodés, templates.
Le Garden Wiki complète le dispositif : base de connaissances partagée (People, Companies, Meetings, Projects) auto-mise à jour par garden sync && garden tend.
CLAUDE.md structuréIntégrer l’IA dans un squad sans structure produit, ça donne du bruit. Pas de rôle owner sur les agents, pas de critère de qualité partagé, pas de détection quand une modification casse autre chose. Le premier mois ça avance. Après, la dette s’accumule.
Les patterns de ce pipeline sont directement adoptables dans un squad : rôles avec domaines exclusifs, gates humains sur les décisions critiques, scoring continu pour distinguer « ça tourne » de « ça fonctionne ». Ce sont des réflexes de management produit. Ils s’appliquent aux agents exactement comme aux équipes.
Le risque invisible dans tout pipeline IA, c’est la régression silencieuse. Un prompt modifié pour améliorer un agent en dégrade un autre. Sans comparaison entre les runs, ça passe inaperçu jusqu’à ce qu’un client le signale. Le scoring N-1 automatique est le premier mécanisme que n’importe quelle équipe devrait mettre en place.