Le Framework GSD : Comment Faire en Sorte que les Agents IA Livrent Vraiment
L'agent qui livre réellement n'est pas celui qui tourne avec le meilleur modèle. Selon une étude de mars 2026 de Morphllm ayant testé 15 agents de codage IA, le même modèle sous-jacent obtient des scores de 17 problèmes d'écart selon le framework d'agent qui l'encapsule. Le scaffolding est la variable. Le modèle est presque anecdotique.
Le framework GSD (Get Shit Done) pour les agents IA est la formulation la plus claire de cette idée que nous ayons vue. Développé par Lex Christopherson et popularisé par la vidéo AI Labs "GSD Is the Missing Piece For Claude Code", GSD n'est pas un autre outil de codage IA avec des opinions arrêtées. C'est une philosophie de scaffolding construite sur une prémisse simple : les agents échouent au niveau du workflow, pas au niveau de l'intelligence.
Cet article décompose le framework GSD, pourquoi il fonctionne, ce dont les pipelines d'agents en production ont réellement besoin — et ce que nous avons appris en gérant plus de 25 agents cron autonomes quotidiennement chez Context Studios.
Pourquoi la Plupart des Pipelines d'Agents Échouent
Les données Morphllm méritent qu'on s'y arrête. Claude Code obtient 80,9% sur SWE-bench Verified avec le bon scaffolding et la bonne orchestration. Le même modèle de base dans un pipeline d'agents mal structuré peut obtenir 17 points de moins sur le même ensemble de benchmarks. Cet écart n'est pas un écart de modèle. C'est un écart d'architecture.
La plupart des pipelines d'agents meurent du même ensemble de problèmes :
Chaos de la fenêtre de contexte. Sans gestion d'état explicite, l'agent accumule du bruit au fil des tours. Au moment où il atteint l'étape critique — l'édition de fichier, l'appel API, la migration de base de données — il a perdu la spécification originale dans une mer de raisonnements intermédiaires.
Critères de succès ambigus. Un agent avec des instructions vagues satisfera la lettre de la demande tout en manquant l'esprit. "Mettre à jour le flux d'authentification" mène à un comportement imprévisible. "Ajouter une vérification pour les tokens expirés dans auth/middleware.ts, retourner 401 si expiré, exécuter la suite de tests auth, confirmer que les 47 tests passent" ne l'est pas.
Pas de boucles fail-fast. Les développeurs humains vérifient constamment leur travail. Les agents, sans étapes de vérification explicites, hallucineront un succès et continueront. Le bug est livré.
Pas de chemins de récupération. Quand un agent se heurte à un mur — timeout, erreur d'outil, sortie inattendue — il n'y a pas de plan de secours. Le pipeline reste suspendu silencieusement ou plante sans sauvegarder les résultats partiels.
GSD adresse les quatre problèmes.
Ce qu'est le Framework GSD
GSD est un système de développement piloté par les spécifications, construit entièrement sur les capacités natives de Claude Code. Il a accumulé plus de 23 000 étoiles GitHub. L'ensemble du système tourne sur environ 50 fichiers Markdown, un helper CLI Node.js, et deux hooks. Pas de runtime propriétaire. Pas de lock-in de framework.
Le système est organisé autour de six commandes slash qui correspondent à un workflow linéaire :
/gsd:new-project— capture l'idée et génère les spécifications/gsd:discuss-phase— clarifie les exigences avant d'écrire du code/gsd:plan-phase— découpe le travail en tâches atomiques et exécutables/gsd:execute-phase— exécute ces tâches, avec parallélisme si possible/gsd:verify-work— valide la sortie par rapport aux critères de succès explicites/gsd:complete-milestone— archive l'état et publie
Derrière ces commandes se trouvent 29 compétences, 12 agents personnalisés et 2 hooks. Chaque commande est un fichier Markdown avec un frontmatter YAML et des sections balisées XML. Le balisage XML n'est pas cosmétique : l'entraînement de Claude traite les frontières XML comme des signaux structurels, ce qui rend le modèle mesurément plus fiable pour suivre des instructions en plusieurs étapes.
GSD cible Claude Code, OpenCode et Gemini CLI de manière équivalente. La philosophie de scaffolding se transfère entre les agents.
Les Quatre Principes GSD
La valeur en production du framework provient de quatre décisions architecturales que tout système d'agents peut adopter.
1. Spécification avant exécution. Chaque workflow GSD commence par une spécification lisible par machine — pas une description en langage naturel d'un objectif, mais un document structuré avec des contraintes, des critères de succès et des permissions d'outils. La commande /gsd:discuss-phase existe spécifiquement pour faire émerger les ambiguïtés avant qu'une seule ligne de code s'exécute.
2. Recherche parallèle, synthèse séquentielle. Pendant la phase de recherche, quatre agents s'exécutent simultanément — chacun étudiant une dimension différente du problème : stack technique, fonctionnalités, architecture, cas limites. Chacun écrit ses résultats dans un fichier séparé. Un agent synthétiseur traite ensuite ces résultats séquentiellement, et un roadmapper produit le plan final. Ce pattern fan-out/fan-in limite la charge sur la fenêtre de contexte de chaque agent. Cette approche est similaire à la façon dont Claude Code analyse les pull requests en parallèle.
3. État persistant à travers les réinitialisations de contexte. GSD écrit tout dans un répertoire .planning/ : définition du projet, exigences, feuille de route et état actuel. Des commits Git ont lieu après chaque étape. Une commande /gsd:resume-work relit cet état après une réinitialisation. L'agent ne repart jamais de zéro.
4. Étapes déterministes gérées par des scripts. Des scripts Bash gèrent les tâches nécessitant une fiabilité exacte : vérification d'existence de fichiers, calcul de numéros de phases, validation du nombre de tests. LLM pour le jugement, script pour le déterminisme — cette frontière est l'une des décisions de conception les plus importantes dans un système d'agents en production.
Réalité de Production : Ce que Nous Avons Appris avec 25+ Agents Quotidiens
Context Studios exploite plus de 25 agents autonomes sur des planifications cron chaque jour. Collecte de renseignements, audits SEO, pipelines de contenu, rondes d'engagement social. Nous le faisons depuis assez longtemps pour avoir accumulé des patterns d'échec que la documentation GSD ne couvre pas encore, car ils n'émergent qu'à l'échelle de la production.
La gestion des timeouts est une discipline. Nous avons ajusté cinq jobs cron séparés cette semaine parce que les agents atteignaient systématiquement leurs limites d'exécution. Un pipeline d'agents bien conçu nécessite des budgets de timeout explicites à chaque phase : la phase de recherche obtient N secondes, la phase d'exécution M secondes, la phase de vérification P secondes. Sans budgets par phase, l'agent brûle toute la fenêtre temporelle sur la première étape et échoue au pire moment.
L'anti-pattern Edit-sur-grands-fichiers. Nous avons eu deux échecs de pipeline consécutifs liés à la même cause racine : un agent utilisant des outils d'édition de fichiers sur de grands fichiers sans les lire d'abord. L'agent supposait la structure du fichier à partir du contexte, appliquait une édition ciblée et corrompait le fichier. Nos pipelines incluent maintenant une contrainte explicite read-before-edit dans les instructions de scaffolding.
Les vérifications préalables du navigateur ne sont pas optionnelles. Plusieurs de nos agents d'automatisation dépendent d'une session de navigateur. Un navigateur mort est un échec silencieux — l'agent s'exécute pendant 20 minutes, signale un succès, et n'a en réalité rien fait. Ajouter une vérification de santé du navigateur comme première étape de tout pipeline dépendant d'un navigateur élimine toute cette classe d'échecs.
Auto-guérison plutôt que récupération manuelle. Nous intégrons des chemins de récupération directement dans notre scaffolding d'agents. Si le chemin principal échoue, il y a un fallback. Si le fallback échoue, le résultat partiel est sauvegardé et signalé pour révision plutôt que rejeté. Claude Code /loop adopte une approche similaire au niveau de la session — état persistant à travers les réinitialisations de contexte.
Les 3 outils qui ont changé notre façon de coder avec les agents IA couvre la partie outillage — cet article concerne la discipline.
Construire Son Propre Scaffolding de Style GSD
Vous n'avez pas besoin d'adopter GSD dans son intégralité. Les principes sont séparables.
Commencez par écrire des critères de succès explicites pour chaque tâche d'agent. Pas "écrire des tests pour le module auth" mais "écrire des tests pour le module auth avec une couverture ≥ 90% sur auth/middleware.ts, avec tous les tests existants encore en succès." Ce seul changement élimine la plus grande classe d'échecs d'agents.
Ensuite, ajoutez des gates de vérification. Après chaque étape majeure, l'agent doit vérifier que la sortie attendue existe et correspond à la spécification. C'est ce que la commande /gsd:verify-work de GSD automatise.
Ensuite, ajoutez la persistance d'état. Après chaque étape vérifiée, écrivez l'état actuel sur le disque. Utilisez des commits Git comme points de contrôle.
Enfin, tracez explicitement la frontière LLM/script. Tout ce qui doit être exactement juste va dans un script. Tout ce qui nécessite du jugement va au modèle.
Les données Morphllm confirment ce que cette architecture prédit : le système d'agents qui structure correctement ces décisions surpassera celui qui fait tourner un modèle nominalement plus puissant mais avec un scaffolding faible.
FAQ
Qu'est-ce que le framework GSD pour les agents IA ? GSD (Get Shit Done) est un système de développement piloté par les spécifications, construit sur les capacités natives de Claude Code. Il utilise 50 fichiers Markdown, 6 commandes slash et 2 hooks pour orchestrer un workflow de développement complet de l'idée au code livré. Aucun runtime personnalisé requis.
Pourquoi le scaffolding est-il plus important que le modèle IA ? L'étude Morphllm a montré que le même modèle obtient des scores variant de 17 problèmes selon la qualité du scaffolding. Le scaffolding détermine comment le modèle reçoit les tâches, gère le contexte, vérifie les sorties et récupère des échecs.
Quelles sont les causes les plus fréquentes d'échec des pipelines d'agents IA en production ? Les quatre causes principales : (1) épuisement de la fenêtre de contexte par mauvaise gestion d'état, (2) critères de succès vagues, (3) étapes de vérification manquantes, (4) pas de chemins de récupération lors d'erreurs ou timeouts.
Comment GSD gère-t-il les réinitialisations de contexte ?
GSD écrit tout l'état du projet dans un répertoire .planning/ et effectue des commits après chaque étape. Une commande /gsd:resume-work relit cet état après une réinitialisation.
Le framework GSD fonctionne-t-il avec d'autres modèles que Claude ? Oui. L'architecture GSD cible Claude Code, OpenCode et Gemini CLI de manière équivalente. Les principes de scaffolding se transfèrent à tout système d'agents.
Combien d'agents simultanés un pipeline de style GSD peut-il gérer ? La phase de recherche de GSD utilise par défaut quatre agents parallèles. Le pattern fan-out/fan-in est évolutif. Nos propres pipelines basés sur cron font tourner plus de 25 agents quotidiennement avec des planifications indépendantes et des contextes isolés.
Le Standard de Production a Changé
L'écart de benchmark Morphllm — 17 problèmes, même modèle, scaffolding différent — est la preuve la plus claire disponible que la barre de qualité pour le travail des agents ne concerne plus quel modèle vous utilisez. Il s'agit de la qualité avec laquelle vous définissez le travail, contraignez l'exécution, vérifiez la sortie et récupérez des échecs.
GSD est une implémentation de cette idée. Les principes qui la sous-tendent sont disponibles pour tout développeur prêt à écrire des spécifications explicites, ajouter des gates de vérification et persister l'état à travers les réinitialisations.
Les agents qui livrent de manière fiable sont ceux avec des critères de succès clairs. C'est vrai aussi pour les ingénieurs humains.