Qu’est-ce que pdd-kit ?
pdd-kit, d'Itai Gendler, est un toolkit open source pour ce qu'il appelle le Product-Driven Development. Au lieu d'une spec par fonction, il garde un unique répertoire product-model/ dans le dépôt qui décrit le produit en entités, interfaces, domaines, capacités, parcours, règles métier et variations. Les agents et les humains lisent ce modèle partagé, et une étape de vérification confronte le code à celui-ci.
Il s'installe avec npx pdd-toolkit install et livre une interface de rapport basée sur Nuxt pour parcourir le modèle, plus des blueprints comme un exemple travaillé de tableau kanban. L'auteur le positionne face au développement guidé par les specs comme spec-kit et OpenSpec : là où ceux-ci écrivent une spec jetable pour chaque changement, pdd-kit maintient un seul modèle vivant à côté du code.
Le dépôt est sous licence MIT avec environ 97 étoiles GitHub, et le paquet npm pdd-toolkit est à la version 0.38.0 (25 octobre 2026). C'est un projet récent à mainteneur unique, créé en juillet 2026.
pdd-kit vaut-il le coup ?
La prémisse de pdd-kit est que le produit existe déjà, dispersé dans les tickets, docs, chats et le code, et que chaque agent de codage le reconstruit de zéro et différemment à chaque fois. Sa réponse est d'écrire ce produit une fois, comme un modèle suivi dans git, et de le faire lire aux agents. C'est une vraie distinction face à spec-kit et OpenSpec, qui produisent une spec fraîche par fonction ; pdd-kit garde les entités, parcours et règles métier comme des documents permanents que toute l'équipe et chaque agent partagent.
Le modèle est structuré plutôt qu'en prose libre. Le répertoire product-model/ sépare les entités, interfaces, domaines, capacités, parcours, règles métier (formulées comme « max 3 par commande », « seuls les managers remboursent ») et variations pour les feature flags ou les paliers d'offre. Une interface de rapport le rend, et le blueprint du tableau kanban livre un modèle complet sans code derrière lui, pour qu'un lecteur voie la forme avant d'adopter la méthode. Parce que le modèle et le code changent dans la même pull request, la dérive entre ce qu'est le produit et ce que fait le code est censée apparaître en revue.
Le poids est le même que celui de tout workflow de spec, déplacé plus tôt : quelqu'un doit écrire et maintenir le modèle, et un modèle en retard sur le code est pire que pas de modèle, parce que les agents lui feront confiance. Le propre cadrage de pdd-kit, que « terminé » signifie que le code correspond au modèle approuvé, ne tient que si le modèle reste à jour, et rien ne l'impose sinon la discipline des relecteurs.
La limite honnête est l'adoption. À environ 97 étoiles et dix forks, avec un mainteneur unique et des versions qui avancent vite (0.38.0 fin octobre), c'est un projet précoce qui prouve une idée, pas un standard établi. Le concept est plus intéressant que celui de spec-kit ; le dossier n'en est qu'une fraction, et une équipe qui parie son processus sur pdd-kit parie sur une seule personne qui continue de livrer.
Là où il fait la différence
Une équipe SaaS de quatre ingénieurs dont les règles produit vivent dans Slack et trois docs périmés
Donner à leur agent de codage une seule source de la façon dont le produit se comporte réellement
Lancez npx pdd-toolkit install, mappez le dépôt existant en un modèle de produit, et gardez les parcours et règles métier sous product-model/ pour que l'agent les lise avant de construire. Gratuit ; le coût est les heures pour écrire le premier modèle et la discipline de le mettre à jour à chaque pull request.
Un responsable technique qui introduit le codage par agent sur un produit aux règles de facturation complexes
Empêcher les agents de réinventer différemment la logique de remboursement et de taxe à chaque fois
Encodez les règles comme règles métier et variations dans le modèle ; l'étape de vérification confronte un changement à celles-ci. Le gain croît avec la complexité du domaine, si bien qu'une appli CRUD ne rentabilisera pas l'effort de modélisation.
Un développeur qui compare pdd-kit à spec-kit pour un nouveau projet
Choisir entre une spec par fonction et un modèle de produit permanent
Parcourez le blueprint du tableau kanban et l'interface de rapport pour voir le format du modèle, puis pesez un projet de 97 étoiles contre l'adoption bien plus large de spec-kit avant de standardiser une équipe dessus.
Avant de vous engager
- Mise en route
- npx pdd-toolkit install dans le dépôt, puis mappez une base de code existante en un modèle de produit ; l'interface de rapport le parcourt et des blueprints comme kanban-board montrent le format. Node et un agent de codage pris en charge sont les seuls prérequis.
- Intégrations
- Fonctionne via le modèle propre de votre agent de codage ; positionné aux côtés des outils guidés par les specs (spec-kit, OpenSpec) plutôt que de remplacer l'agent. Le modèle et le code sont relus ensemble dans git.
- Données et confidentialité
- Tourne localement et écrit du Markdown dans votre dépôt ; le contenu du modèle va au fournisseur de modèle propre de votre agent. Aucune télémétrie n'est décrite dans le README. Licence MIT ; aucun avis de sécurité publié.
- Coût à grande échelle
- Pas d'édition payante. Le vrai coût est d'écrire et de maintenir le modèle de produit, et le temps des relecteurs pour le garder au pas du code à chaque changement.
- Limites
- Environ 14 issues ouvertes ; mainteneur unique ; cadence de publication rapide qui change les commandes ; aucune valeur sur des produits sans vraie complexité de domaine, où le surcoût de modélisation dépasse le bénéfice.
Les points forts
- Un modèle de produit persistant, pas une spec réécrite par fonction
- Entités, parcours, règles et variations structurés dans git
- Interface de rapport et un blueprint de tableau kanban dont s'inspirer
- Étape de vérification qui confronte le code au modèle approuvé
Les points faibles
- Environ 97 étoiles ; mainteneur unique et non éprouvé en conditions réelles
- Un modèle périmé trompe les agents plus que l'absence de modèle
- Le rythme de publication rapide fait bouger les commandes et templates
- Le surcoût ne paie que sur des produits à vraie complexité de domaine
Idéal pour
Les équipes sur agents de codage qui veulent une seule définition de produit vivante dans git plutôt qu'une spec écrite puis jetée par fonction.
Alternatives à pdd-kit
pdd-kit : questions fréquentes
- pdd-kit vaut-il le coup ?
- Une idée plus affûtée que la plupart des outils de spec, un modèle de produit persistant plutôt que des specs jetables, porté par un projet de 97 étoiles qu'une seule personne maintient. Nous lui donnons 3.7 sur 5.
- Combien coûte pdd-kit ?
- Gratuit et open source (MIT).
- Quels sont les inconvénients de pdd-kit ?
- Environ 97 étoiles ; mainteneur unique et non éprouvé en conditions réelles; un modèle périmé trompe les agents plus que l'absence de modèle; le rythme de publication rapide fait bouger les commandes et templates; le surcoût ne paie que sur des produits à vraie complexité de domaine.
- À qui s’adresse pdd-kit ?
- Les équipes sur agents de codage qui veulent une seule définition de produit vivante dans git plutôt qu'une spec écrite puis jetée par fonction.
- Combien coûte pdd-kit pour une équipe ou en production ?
- Pas d'édition payante. Le vrai coût est d'écrire et de maintenir le modèle de produit, et le temps des relecteurs pour le garder au pas du code à chaque changement.
- pdd-kit est-il sûr pour les données de l’entreprise ?
- Tourne localement et écrit du Markdown dans votre dépôt ; le contenu du modèle va au fournisseur de modèle propre de votre agent. Aucune télémétrie n'est décrite dans le README. Licence MIT ; aucun avis de sécurité publié.
- Quelles sont les meilleures alternatives à pdd-kit ?
- Les alternatives les plus proches que nous avons testées sont Spec Kit, Elephant-Goldfish Model et BMAD Method.
Réponses vérifiées le 30 oct. 2026.