Chapitre 3

PRD et piloté par la documentation

Maîtrisez les principes fondamentaux du développement piloté par la documentation, apprenez à utiliser l’IA pour rédiger des PRD, développez une pensée structurée et faites de la documentation la boussole du développement.

Idée clé : la documentation est le contexte

À l’ère de la programmation assistée par l’IA,La documentation n’est pas une charge, mais le contexte dont l’IA a besoin pour comprendre les exigences。 Un bon PRD permet à l’IA de comprendre précisément les besoins et de générer un code conforme aux attentes. Après avoir découvert le workflow VibeCoding dans le chapitre précédent, apprenons maintenant à rédiger une documentation lisible par l’IA.

Pourquoi les PRD sont nécessaires

Dans le développement traditionnel, le PRD était un outil de communication pour l’équipe. À l’ère du codage assisté par l’IA, le PRD estL’IA comprend le contexte des besoins。

Développement traditionnel

  • • Le PRD sert à la communication d’équipe
  • • La compréhension des besoins repose sur des discussions humaines
  • • La documentation et le code peuvent facilement diverger
  • • Les modifications doivent être synchronisées manuellement

L’ère de la programmation IA

  • • Le PRD est le contexte de l’IA
  • • L’IA lit directement le PRD et génère le code
  • • Documentation en tant que code, synchronisation des versions
  • • Les modifications déclenchent automatiquement les mises à jour du code

Valeur pilotée par la documentation

Réduire les retouches: Écrire d’abord la documentation, puis laisser l’IA la comprendre avant de coder afin d’éviter les écarts de compréhension
Améliorer la qualité: Les documents structurés permettent à l’IA de générer un code plus précis
Traçabilité : contrôle de version des documents, historique des modifications clair
Collaboration d’équipe: La documentation est le langage commun de l’équipe et réduit les coûts de communication

Méthode de pensée structurée : Sequential Thinking

Rédiger un PRD ne se fait pas en un jour ; ce qu'il faut, c'estPensée structurée. Utilisez la méthode Sequential Thinking pour décomposer les problèmes complexes en étapes gérables.

Flux de travail Sequential Thinking

1

Décomposition du problème

Décomposer les exigences complexes en plusieurs sous-problèmes, chacun pouvant être résolu indépendamment

2

Réflexion étape par étape

Réfléchir progressivement à chaque sous-problème et consigner le processus de réflexion

3

Valider les hypothèses

Vérifier chaque hypothèse pour s'assurer que la logique est correcte

4

Solution intégrée

Intégrer les solutions de chaque sous-problème en une solution complète

5

Optimisation itérative

Optimisez et améliorez continuellement la solution en fonction des retours

Exemple pratique : fonctionnalité de connexion utilisateur

Étape de réflexion 1 : Décomposer le problème
• Comment l’utilisateur saisit-il le compte et le mot de passe ?
• Comment vérifier l’identité de l’utilisateur ?
• Comment conserver l’état après une connexion réussie ?
• Comment gérer un échec de connexion ?
Étape de réflexion 2 : approfondir progressivement
• Frontend : validation des formulaires, messages d’erreur, états de chargement
• Back-end : chiffrement des mots de passe, génération de jetons, gestion des sessions
• Sécurité : protection contre les attaques par force brute, protection CSRF
Étape de réflexion 3 : plan d’intégration
Intégrer les solutions des trois dimensions front-end, back-end et sécurité pour concevoir une fonctionnalité de connexion complète

Utiliser l’IA pour aider à la pensée structurée

Utilisez l’outil Sequential Thinking MCP ou une méthode de réflexion similaire pour demander à l’IA de vous aider à :

  • •Décomposer les problèmes complexes: l’IA vous aide à identifier les sous-problèmes clés
  • •Enregistrer le processus de réflexion: chaque étape de réflexion est enregistrée et traçable
  • •Logique de validation：L’IA vous aide à vérifier les failles logiques
  • •Optimisation itérative：Améliorer continuellement la solution en fonction des retours

Guide de rédaction du PRD

Le PRD (Product Requirements Document) est une description complète des exigences du produit. À l’ère du codage par IA, les PRD doiventStructuré, exploitable et lisible par l’IA。

Structure centrale du PRD

1. Présentation du produit

Obligatoire

Positionnement du produit, utilisateurs cibles, valeur essentielle, objectif en une phrase

2. Exigences fonctionnelles

Obligatoire

Liste des fonctionnalités, user stories, priorités, critères d’acceptation

3. Exigences non fonctionnelles

Obligatoire

Exigences en matière de performance, de sécurité, de disponibilité et de scalabilité

4. Définition des interfaces

Obligatoire

Entrées/sorties, structures de données, gestion des erreurs, spécifications de l’API

5. Contraintes et hypothèses

Obligatoire

Contraintes techniques, limitations de ressources, prérequis, non-objectifs

6. Critères d’acceptation

Obligatoire

Acceptation fonctionnelle, acceptation des performances, acceptation de la sécurité, liste de contrôle DoD

Principes de PRD lisibles par l’IA

❌ Description floue
Fonction de connexion utilisateur - Les utilisateurs peuvent se connecter - Après connexion, ils peuvent accéder au système
✅ Description structurée
Fonction de connexion utilisateur Objectif : permettre aux utilisateurs de se connecter au système avec leur compte et leur mot de passe Entrée : username (string), password (string) Sortie : token (string), userInfo (object) Erreurs : 401 Mot de passe incorrect, 429 Requêtes trop fréquentes Acceptation : saisir le bon mot de passe renvoie un token, un mot de passe incorrect renvoie 401

Bonnes pratiques pour rédiger un PRD

  • Objectifs clairs: Chaque fonctionnalité doit répondre à « pourquoi est-ce nécessaire » et à « un objectif en une phrase »
  • Définir les non-objectifs：indiquer clairement ce qu’il ne faut pas faire afin d’éviter la dérive du périmètre
  • Description structurée: utiliser le format Markdown avec une structure hiérarchique claire
  • Testabilité: les exigences doivent pouvoir être vérifiées et testées, et inclure des critères d’acceptation
  • Contrôle de version: Les PRD doivent être versionnés comme du code (Git)
  • Mise à jour continue : Mettre à jour rapidement la documentation lorsque les exigences changent, afin de maintenir la documentation et le code synchronisés

Développement piloté par les specs

Spec-Driven Development met l’accent surÉcrire d’abord la spécification, puis le code。 La spécification est le contexte, permettant à l'IA de mieux comprendre les besoins et de générer un code conforme aux attentes.

Processus de développement traditionnel

1Discussion des exigences
2Codage direct
3Découvrir les problèmes
4Retouches et modifications

Flux piloté par les specs

1Rédiger la Spec
2Validation de la revue
3Codage basé sur la Spec
4Validation selon la spec

Éléments clés de la Spec

1
Objectifs: Quel problème cette fonctionnalité résout-elle ? Quel est l’objectif en une phrase ?
2
Non-objectifs：que ne fait pas cette fonctionnalité ? Clarifier les limites
3
Définition de l'interface: entrée/sortie, structures de données, gestion des erreurs, spécifications d’API
4
Critères d’acceptation (Acceptance Criteria): Qu’est-ce qui est considéré comme terminé ? Inclut l’acceptation fonctionnelle et l’acceptation des performances

Générer un Spec à l’aide de l’IA

Laissez l’IA générer un Spec à partir des exigences, puis vous le relisez et l’optimisez :

Exemple de prompt :
Aidez-moi à générer un Spec pour une fonctionnalité de connexion utilisateur, comprenant : 1. Objectifs et non-objectifs 2. Définition de l’interface (entrées/sorties, gestion des erreurs) 3. Critères d’acceptation 4. Contraintes techniques

WBS Structure de découpage du travail

Le WBS (Work Breakdown Structure) décompose les projets complexes en petites tâches gérables. À l’ère du codage assisté par l’IA,La décomposition des tâches permet à l’IA d’exécuter étape par étapepour augmenter le taux de réussite.

Principe de décomposition

Principe MECE
Mutuellement exclusif et collectivement exhaustif (Mutually Exclusive, Collectively Exhaustive)
Granularité modérée
Chaque tâche peut être terminée en 1 à 3 jours, ce qui convient à une exécution pas à pas par l’IA
Livrable
Chaque tâche a un livrable clair, vérifiable
Dépendances claires
Clarifier les dépendances entre les tâches et déterminer l’ordre d’exécution

Exemple : fonctionnalité de connexion utilisateur

Structure WBS :
Fonction de connexion utilisateur ├─ Page de connexion front-end │ ├─ Développement des composants UI │ ├─ Validation du formulaire │ └─ Messages d'erreur ├─ Développement de l'API back-end │ ├─ API de connexion │ ├─ Génération de Token │ └─ Gestion de session └─ Tests ├─ Tests unitaires └─ Tests d'intégration

Utiliser l’IA pour aider à décomposer les tâches

Laissez l’IA décomposer le PRD en une liste de tâches exploitables :

Exemple de prompt :
Veuillez décomposer le PRD suivant en une liste de tâches WBS : [Coller le contenu du PRD] Exigences : 1. Chaque tâche doit avoir une granularité appropriée (réalisable en 1 à 3 jours) 2. Définir clairement les dépendances entre les tâches 3. Chaque tâche doit avoir des critères d’acceptation clairs

DoD Définition de terminé

DoD (Definition of Done) définit les critères d’acceptation de l’achèvement d’une tâche. À l’ère de la programmation par IA,La DoD peut être vérifiée automatiquement , garantissant une qualité homogène.

Liste de contrôle DoD standard

Le code a passé tous les tests (tests unitaires, tests d’intégration)
Le code a passé la revue de code (revue par IA + revue humaine)
La documentation a été mise à jour (PRD, documentation API, README)
Respecter les normes de codage (ESLint, Prettier, TypeScript)
Déployé dans l’environnement de test et vérifié avec succès
Accepté par le chef de produit (les fonctionnalités sont conformes au PRD)

Vérifications DoD automatisées par IA

Utiliser des outils d’IA pour vérifier automatiquement la liste de contrôle DoD et améliorer l’efficacité :

Revue de code
Utilisez des outils de revue de code IA (comme Cursor, GitHub Copilot) pour vérifier automatiquement la qualité du code
Génération de tests
Utilisez l’IA pour générer des cas de test et garantir la couverture de code
synchronisation des documents
Utiliser l’IA pour vérifier la cohérence entre la documentation et le code, et mettre automatiquement la documentation à jour

La valeur du DoD

  • • Assurance qualité: Garantir que toutes les tâches répondent à un standard de qualité uniforme
  • • Réduire les retouches: détecter les problèmes tôt et éviter les modifications ultérieures
  • • Consensus d’équipe: Tout le monde a une compréhension commune de ce que signifie « terminé »
  • • Traçabilité: consignez clairement l'état d'achèvement de chaque tâche
  • • Adapté à l’IA: Des critères d’acceptation clairs indiquent à l’IA quand la tâche est terminée

Documentation en tant que code

À l’ère de la programmation assistée par l’IA,La documentation doit être gérée comme du code：gestion de versions, revue de code, vérifications automatisées, intégration continue.

Gestion des versions des documents

Gérer la documentation avec Git
docs/prd/
├── user-login.md
├── user-profile.md
└── README.md
  • • Les modifications de la documentation sont soumises via PR, revue de code
  • • Synchroniser les versions des documents et les versions du code
  • • Historique des modifications clair et traçable

Vérification automatisée des documents

Intégration CI/CD
  • • Vérifier si le format du PRD est conforme aux normes
  • • Vérifier la cohérence entre la documentation et le code
  • • Générer automatiquement la documentation API
  • • Vérifier l’intégrité du document (champs obligatoires)

La documentation comme contexte

Les documents ne sont pas seulement des enregistrements, mais aussiL’IA comprend le contexte des besoins。 Une bonne documentation permet à l’IA de comprendre précisément les besoins et de générer un code conforme aux attentes. La documentation et le code doivent être mis à jour de manière synchronisée afin de conserver leur cohérence.

Résultats d’apprentissage

À la fin de ce chapitre, vous pourrez :

  • 1Comprendre les principes fondamentaux du développement piloté par la documentation et maîtriser l’idée que la documentation est le contexte
  • 2Maîtriser les méthodes de pensée structurée (Sequential Thinking) et être capable de décomposer des problèmes complexes
  • 3Peut rédiger des documents PRD lisibles par l’IA, incluant des exigences produit complètes
  • 4Maîtriser le processus de développement piloté par la spec et comprendre l’idée que la spécification est le contexte
  • 5Capable d’effectuer une décomposition efficace des tâches (WBS) et de gérer l’avancement du projet
  • 6Comprendre l’importance du DoD et être capable de définir des critères d’acceptation clairs
  • 7Maîtriser les méthodes de gestion du document as code et établir un processus de contrôle de version des documents
Chapitre précédent : Guide d’utilisation de l’IAChapitre suivant : mode de développement natif à l’IA