Auditer un cahier des exigences produit (PRD)

Objectif

Entrées acceptées

• Document
• PDF
• Document Word
• Texte brut

Ce que vous obtenez

• Rapport
• Document structuré

Limites et supervision humaine

Sources officielles

Références utilisées pour cadrer la méthode. Vérifiez leur version à la date d'utilisation.

• ISO/IEC/IEEE 29148:2018 (Requirements engineering)
• ISO/IEC 25010:2023 (Product quality model)

Aperçu du SKILL.md

Premières lignes du fichier embarqué dans l'archive — le contrat d'exécution du skill.

---
name: auditer-cahier-exigences-produit
description: Le Product Manager a rédigé une version initiale de son PRD et souhaite s'assurer qu'aucune exigence critique n'est manquante ou ambiguë avant le début des développements. L'agent analyse le document pour vérifier sa complétude, sa clarté et sa conformité aux standards de qualité logicielle.
---

# Auditer un cahier des exigences produit (PRD)

## Mission
Évaluer un Document d'Exigences Produit (PRD) pour vérifier sa complétude, sa clarté et sa conformité aux standards d'ingénierie des exigences (notamment ISO/IEC/IEEE 29148 et ISO/IEC 25010). Identifier les lacunes, les ambiguïtés et les risques d'alignement avant le développement.

## Résultat attendu
Un rapport d'audit structuré contenant une évaluation de la complétude par section, une liste des exigences ambiguës ou non testables, des recommandations d'ajouts (notamment sur les exigences non fonctionnelles) et une cartographie des risques d'alignement, le tout prêt à être utilisé par le Product Manager.

## Situations d'usage
- Le Product Manager a rédigé une version initiale de son PRD et souhaite s'assurer qu'aucune exigence critique n'est manquante ou ambiguë avant le début des développements.
- L'équipe technique ou le Product Owner doit valider le périmètre avant de démarrer la rédaction granulaire des user stories.

## Ce que le skill ne fait pas
- Rédiger des user stories de manière granulaire.
- Prioriser les fonctionnalités (par exemple avec la méthode RICE).
- Analyser les retours utilisateurs bruts.
- Remplacer le jugement de l'architecte logiciel ou du Product Owner.

## Entrées obligatoires
- Document PRD initial (texte, PDF, DOCX).
- Objectifs stratégiques du produit.

## Entrées facultatives
- Référentiel technique interne.
- Contraintes de sécurité ou de conformité spécifiques.

## Validation préalable
- Vérifier que le document fourni est bien un PRD et non un cahier des charges commercial ou une spécification technique détaillée.
- Confirmer la présence des objectifs stratégiques pour évaluer l'alignement.

## Méthodologie
1. **Extraction** : Extraire le contenu du PRD fourni.
2. **Confrontation** : Confronter le contenu à une grille de vérification standardisée inspirée de l'ingénierie des exigences (ISO/IEC/IEEE 29148 et ISO/IEC 25010).
3. **Identification des lacunes** : Repérer les exigences fonctionnelles et non fonctionnelles (performance, sécurité, etc.) manquantes.
4. **Analyse sémantique** : Détecter les termes vagues, ambigus ou non testables.
5. **Évaluation de l'alignement** : Cartographier les risques d'alignement entre les exigences et les objectifs stratégiques.
6. **Formulation de questions** : En cas de sections incomplètes ou de données manquantes, formuler des questions ciblées pour guider le Product Manager.

## Règles de décision
- Si une exigence utilise des termes comme "rapide", "sécurisé", "facile à utiliser" sans métrique associée, la marquer comme non testable.
- Si les exigences non fonctionnelles sont absentes, recommander les catégories standards de la norme ISO/IEC 25010.
- Si le PRD est manifestement incomplet (ex: manque le contexte ou les utilisateurs cibles), prioriser les questions de clarification plutôt que l'analyse détaillée des exigences présentes.

## Contrôles qualité
- Vérifier que toutes les exigences signalées comme ambiguës sont accompagnées d'une explication et d'une suggestion de reformulation testable.
- S'assurer que les recommandations d'ajouts non fonctionnels sont pertinentes par rapport au contexte du produit.
- Confirmer que la cartographie des risques d'alignement relie bien les risques identifiés aux objectifs stratégiques fournis.

## Format de sortie
Le rapport doit suivre le modèle défini dans `templates/auditer-cahier-exigences-produit-output.md` et inclure :
1. Évaluation de la complétude par section.
2. Liste des exigences ambiguës ou non testables.
3. Recommandations d'ajouts non fonctionnels.
4. Cartographie des risques d'alignement.

## Convention de confiance
- Les évaluations de complétude sont basées sur des modèles standards et non sur le contexte spécifique de l'entreprise (sauf si un référentiel interne est fourni).
- Les risques d'alignement identifiés sont des alertes et nécessitent une analyse humaine.

## Gestion des erreurs
- **PRD non fourni ou illisible** : Demander de fournir un document lisible.
- **Objectifs stratégiques manquants** : Demander les objectifs pour pouvoir évaluer l'alignement.
- **Contexte technique manquant** : Indiquer que l'analyse des exigences non fonctionnelles sera générique.

## Limites
- Le risque principal est la détection de faux positifs sur des exigences volontairement laissées flexibles dans un contexte agile.
- L'outil ne remplace en aucun cas le jugement de l'architecte logiciel ou du Product Owner.
- Toute décision réglementaire, juridique, de sécurité ou de conformité issue de cette analyse requiert une validation humaine. Une revue humaine rigoureuse est requise pour valider la pertinence des ajustements proposés avant de figer le périmètre de développement.

## Exemple
**Demande** : "Voici mon PRD pour la nouvelle application de gestion de notes de frais, ainsi que les objectifs : réduire le temps de traitement de 50% et assurer la conformité fiscale."
**Traitement** : Analyse du document. Détection que l'exigence "L'application doit être rapide" est non testable. Recommandation : "L'application doit afficher la page de saisie en moins de 2 secondes." Détection de l'absence d'exigences sur la conservation des données (lié à la conformité fiscale).
**Sortie** : Rapport d'audit structuré mettant en évidence ces points.


## Grille d'alignement stratégique

Évaluer chaque exigence sur quatre critères documentés : contribution à un objectif produit, valeur utilisateur démontrée, obligation réglementaire ou contractuelle, cohérence avec les contraintes de capacité et d'architecture. Utiliser `oui`, `partiel`, `non démontré` plutôt qu'une note arbitraire.

Une exigence « non démontrée » n'est pas supprimée automatiquement : elle rejoint la liste des arbitrages avec son auteur, la preuve attendue, l'impact de conservation et l'impact de retrait.

### Rappel de fiabilité
Ne jamais inventer un fait, un chiffre, une conformité, une date, une source ou une citation.

## Protocole de traçabilité

Pour chaque donnée utilisée, conserver le nom du document, sa date, la rubrique consultée et le passage utile. Pour chaque calcul, indiquer la formule, les valeurs d'entrée, l'unité, la règle d'arrondi et le résultat. Si plusieurs documents se contredisent, ne pas choisir silencieusement : présenter les versions, expliquer l'impact et demander un arbitrage. Les sources externes listées dans `references/sources.md` servent de repères ; vérifier leur version et leur date avant usage.

Installation

1. Téléchargez le fichier. Pour vérifier son intégrité, utilisez shasum -a 256 auditer-cahier-exigences-produit.zip et comparez le résultat avec l'empreinte affichée dans la fiche technique.
2. Décompressez-le : vous obtenez un dossier contenant SKILL.md et ses ressources.
3. Importez le dossier dans claude.ai, Claude Code ou via l'API.