Comparatif
Deep Work Plan et les alternatives
Choisissez la couche adaptée à votre situation. Chaque alternative est décrite selon ses propres termes, chaque fait remonte à sa documentation officielle, et la page indique quand elle a été revue pour la dernière fois. C’est une carte, pas un classement.
Comment lire cette page
Trois valeurs décrivent chaque capacité. Elles disent où se trouve une capacité dans un outil, et non si l’outil est bon.
- Intégré
- Optionnel ou via extension
- Hors périmètre
Dernière révision:
Les alternatives, selon leurs propres termes
Outils de développement piloté par la spécification
-
Outils de développement piloté par la spécification
GitHub Spec Kit
Transforme une fonctionnalité en spécification exécutable via une constitution, une spec, un plan et une liste de tâches, piloté par des commandes slash qui s’intègrent à plus de cinquante agents de code, et peut vérifier que les artefacts restent cohérents entre eux avant que l’implémentation ne commence.
Équipes qui veulent un flux répétable — spécifier, planifier, décomposer en tâches, implémenter — au sein de l’agent qu’elles utilisent déjà.
-
Outils de développement piloté par la spécification
OpenSpec
Capte chaque changement comme une proposition avec des specs delta (ajoutées, modifiées, supprimées) et des exigences RFC 2119 avec scénarios, puis les archive en spécifications vivantes, avec un validateur qui vérifie la complétude de la proposition et la couverture des scénarios avant d’accepter un changement.
Équipes qui travaillent sur des systèmes existants et veulent que les spécifications grandissent un changement à la fois.
-
Outils de développement piloté par la spécification
Amazon Kiro
Un IDE agentique et une CLI dont les specs passent des exigences de style EARS au design puis aux tâches, avec des fichiers de guidage et des hooks déclenchés par les événements de l’éditeur, et qui peut générer des spécifications pour une base de code existante afin de détecter les manques dans les exigences avant que le design ne commence.
Développeurs qui veulent le développement piloté par la spécification intégré à leur éditeur, avec des outils adossés à AWS.
Frameworks de workflow d’agents
-
Frameworks de workflow d’agents
BMAD Method
Un framework agile de rôles d’agents spécialisés (analyse, produit, architecture, développement, qualité) qui produit des briefs, des exigences, des documents d’architecture et des fichiers de stories, avec une Definition of Done qui exige que chaque story soit relue par un coéquipier ou un agent réviseur IA avant d’être considérée comme terminée.
Équipes qui aiment les cérémonies fondées sur les rôles et veulent un cycle agile complet pour le travail des agents.
-
Frameworks de workflow d’agents
Superpowers
Une bibliothèque de skills et un flux de travail pour le brainstorming, la planification en petites étapes test-first, l’exécution avec des sous-agents et la revue avant achèvement, intégrée à davantage d’hôtes d’agents de code qu’aucune autre alternative de cette page, plus une revue en deux étapes par sous-agents (conformité à la spec, puis qualité du code) à chaque tâche.
Développeurs qui veulent une exécution disciplinée pilotée par les tests au sein de leur agent de code.
-
Frameworks de workflow d’agents
GSD Core
Un système de planification avec un répertoire .planning, des identifiants d’exigences, des plans par phase, une exécution à contexte neuf et une passe de vérification contre les livrables observables par l’utilisateur extraits du résumé de chaque plan, pensé pour lutter contre le context rot en exécutant recherche, planification et exécution dans des sous-agents jetables et en détectant les vérifications obsolètes par empreinte de contenu.
Développeurs en solo et petites équipes qui veulent l’ingénierie du contexte et la vérification avec peu de cérémonial.
-
Frameworks de workflow d’agents
Gentle-AI
Configure les agents de code que vous utilisez déjà avec une mémoire persistante qui route aussi entre sessions et modèles, des skills sélectionnées, des serveurs MCP, des personas et, en option, du Spec-Driven Development ou du Receipt-Driven Development. Sa configuration est écrite par défaut dans les réglages globaux de l’agent ; une installation limitée au workspace est optionnelle.
Développeurs qui veulent un écosystème d’agents configuré, capable de se souvenir du travail entre sessions et de produire des preuves à la demande.
AI-native SDLC
-
AI-native SDLC
AI-native SDLC de Claude
Un cycle en six étapes, de Plan et Design à Build, Test, Deploy et Maintain, avec une approbation humaine obligatoire à chaque étape, des artefacts durables commités dans le dépôt entre les étapes, une passe de revue dédiée et étiquetée sécurité avant le déploiement, et des evals continues qui publient des indicateurs de livraison avancés et retardés.
Équipes qui évaluent le playbook de livraison logicielle de bout en bout de Claude Code et sa boucle de feedback en production.
Modes de planification natifs des éditeurs
-
Modes de planification natifs des éditeurs
Modes de planification natifs des éditeurs
Claude Code, Codex, Cursor et Gemini CLI livrent des modes de planification, des fichiers d’instructions et des skills construits sur les standards ouverts et multi-éditeurs AGENTS.md et Agent Skills, même si le comportement exact du mode plan dépend encore de l’éditeur, du client et de la version. Agent Skills, en particulier, ne charge qu’un court résumé au démarrage et les instructions complètes seulement à l’activation, gardant hors du contexte les capacités inutilisées.
Toute personne qui veut la planification au sein d’un seul agent sans adopter de méthodologie.
Ce qu’apporte Deep Work Plan
-
Indépendant de l’outil et natif du dépôt
Le harness et le plan sont des fichiers dans votre dépôt, lus par tout agent qui suit les standards AGENTS.md et Agent Skills. Changer d’agent ne fait pas perdre le plan.
-
Une validation choisie depuis ce que chaque tâche a touché
Chaque tâche déclare sa surface touchée et exécute les tests du comportement modifié et de ses consommateurs, s’élargissant à la suite complète quand l’impact ne peut pas être borné. Zéro test sélectionné n’est jamais une réussite.
-
Un seul Final Review, avec une passe de sécurité
Un plan se clôt par une revue de sécurité de l’ensemble des changements accumulés, y compris une revue locale obligatoire du diff, et par une validation de l’état final. Les constats critiques bloquent l’achèvement.
-
Un état qui survit aux sessions et aux agents
Cases à cocher du README, journaux de tâches, index de travail borné et fichier d’état lisible par machine sont écrits à chaque frontière, pour qu’une autre session ou un autre agent poursuive depuis le disque. Même une création de plan interrompue est récupérable.
-
Un vérificateur de conformité pour le dépôt lui-même
Un script en lecture seule vérifie le harness et chaque plan par rapport à la spécification, comprend les deux cycles de vie des plans et sort avec un code adapté à la CI.
-
Charge d’instructions mesurée et publiée
Un script livré dans le dépôt publie deux mesures par flux — le paquet d’entrée chargé au début d’une session, et le parcours de bout en bout une fois que ses déclencheurs réels se produisent — plus ce que chacun exclut, afin que le chiffre d’entrée seul ne soit jamais lu comme le coût total d’une exécution. Les résultats, hausses comprises, sont publiés en octets, jamais en pourcentages de tokens ou de coût.
Limites assumées
Deep Work Plan n’a pas de mécanisme de spécification vivante ou delta ; OpenSpec et les outils similaires y sont plus forts. Aucun benchmark indépendant de la méthodologie n’existe encore ; une évaluation interne à agents frais s’est déjà déroulée sous un protocole figé, à petite échelle — une charge de travail, deux fonctionnalités par configuration, une seule machine — et ses résultats sont publiés dans les deux sens : les agents sur des arbres porteurs de harness lisaient moins d’octets dans les deux tâches, et les sessions de la version actuelle consommaient moins d’entrée et de sortie de modèle rapportées par le harness que celles de la version majeure précédente, tandis que la direction nette des tokens par charge de travail était mitigée et qu’aucun avantage de temps d’horloge n’est revendiqué. Le registre de charge d’instructions mesure des octets chargés, pas des tokens, un coût ou des résultats, et son chiffre de paquet d’entrée ne plafonne pas ce qu’une exécution lit. DWP se limite volontairement au dépôt : ce n’est ni un système de mémoire inter-projets, ni un framework d’agents basé sur des rôles, ni un IDE, et ne se positionne donc pas non plus sur ces terrains — associez-le à un outil qui couvre ce besoin quand le travail l’exige.
Aidez-nous à garder cette page exacte
Aidez-nous à garder cette page exacte
Cette page est revue à la date indiquée et corrigée sur demande. Si la description de votre outil est obsolète ou incomplète, ouvrez une issue et nous la corrigerons.