Gestion du périmètre et des exigences (PER)

Le périmètre est la frontière entre ce que l'on s'est engagé à faire et le reste. Les projets dérivent rarement par une grande décision ; ils dérivent par accumulation de « petits ajouts…

Guide≈ 6 min de lectureVérifiéLecture

Sur cette page

Pourquoi ce thème
Ce que mesure le thème
Les cinq niveaux
Jalons par niveau
Lecture détaillée par niveau
Atteinte partielle et notation
Passer au niveau suivant
Voir aussi

Niveau : 🟢→🔴 · Code : PER · Matrice : PI

Pourquoi ce thème#

Le périmètre est la frontière entre ce que l'on s'est engagé à faire et le reste. Les projets dérivent rarement par une grande décision ; ils dérivent par accumulation de « petits ajouts sans impact » qui, additionnés, doublent la charge. À l'inverse, un périmètre figé de façon rigide livre une solution conforme à un besoin qui a changé. Un thème mûr ne choisit pas entre rigidité et laxisme : il rend le changement visible, arbitré et chiffré.

Ce que mesure le thème#

Axe : de la demande informelle à un périmètre piloté par la valeur.
Indicateur clé : taux de dérive du périmètre (charge ajoutée non décidée / charge initiale), part des demandes traitées via un processus tracé.
Unité : % de dérive ; nombre de demandes traitées hors processus ; délai de décision sur une demande de changement.

Les cinq niveaux#

Niveau	Nom court	Promesse	Indicateur type (ordre de grandeur)
1	Par mail	Les demandes arrivent par tous les canaux ; on s'efforce de tout faire.	Dérive non mesurée ; > 50 % d'ajouts non décidés
2	Liste des demandes	Toutes les demandes sont au même endroit ; on sait ce qui est demandé et par qui.	70 à 90 % des demandes tracées
3	Backlog priorisé	Les exigences sont décrites, ordonnées par valeur, et tout changement passe par un arbitrage tracé.	≥ 95 % tracées ; décision < 1 semaine
4	Dérive mesurée	La dérive est suivie, chaque ajout est chiffré en coût et en délai avant acceptation ; les exigences sont traçables jusqu'à la recette.	Dérive non décidée < 10 % ; traçabilité ≥ 90 %
5	Piloté par la valeur	Le périmètre est un levier : on retire ce qui ne rapporte plus, on livre le minimum utile, et on mesure l'usage réel des fonctions livrées.	Fonctions inutilisées < 20 % ; usage mesuré par fonction

Jalons par niveau#

ID	Jalon	Preuve vérifiable
PI-PER-1.1	Une description du produit attendu existe (même minimale).	Document ou ticket racine.
PI-PER-1.2	Les demandeurs sont identifiables.	Demandeur noté sur 90 % des demandes récentes.
PI-PER-1.3	Le refus ou le report d'une demande est possible.	Exemple de demande reportée.
PI-PER-2.1	Toutes les demandes sont dans un outil unique.	Absence de demande « hors outil » sur un mois.
PI-PER-2.2	Chaque demande a un statut (nouvelle, acceptée, refusée, livrée).	Colonne de statut renseignée.
PI-PER-2.3	Le périmètre est comparé à celui du cadrage à chaque jalon.	Mention du périmètre dans les revues.
PI-PER-3.1	Un backlog unique est ordonné par une règle de priorité connue.	Règle écrite ; ordre vérifiable.
PI-PER-3.2	Les exigences sont écrites de façon vérifiable (critères d'acceptation, exemples).	10 éléments choisis : critères testables.
PI-PER-3.3	Toute demande de changement suit un processus : évaluation, arbitrage, trace.	Registre des changements avec décisions.
PI-PER-3.4	Le Definition of Ready (ou équivalent) évite d'entamer des exigences floues.	Critères d'entrée appliqués.
PI-PER-4.1	L'impact (charge, délai, risque) de chaque changement est chiffré avant décision.	Fiche d'impact de 5 changements.
PI-PER-4.2	La dérive de périmètre est mesurée et reportée au comité.	Indicateur de dérive à chaque revue.
PI-PER-4.3	Traçabilité exigence → développement → test → livraison.	Chaîne reconstituable pour 5 exigences.
PI-PER-4.4	Les exigences obsolètes sont retirées explicitement.	Éléments clos « abandonnés » avec motif.
PI-PER-5.1	L'usage réel des fonctions livrées est mesuré (télémétrie, journaux, rapports consultés).	Tableau d'usage par fonction ou rapport.
PI-PER-5.2	Les fonctions peu utilisées sont retirées ou simplifiées.	Au moins un retrait documenté dans l'année.
PI-PER-5.3	Le périmètre est découpé en tranches minimales de valeur (livraison incrémentale).	Releases successives avec valeur identifiable.
PI-PER-5.4	Le sponsor arbitre sur la valeur : « ajouter X implique de retirer Y ».	Décisions d'échange (trade-offs) tracées.

Lecture détaillée par niveau#

Niveau 1. Signes : demandes par couloir, mail, messagerie ; l'équipe cède pour éviter les conflits. Gain : rapidité d'accueil. Ne garantit pas : cohérence, ni de pouvoir finir. Difficulté : 1/5. Effort : 1/5.

Niveau 2. Signes : une liste unique ; on peut répondre à « où en est ma demande ? ». Gain : fin des demandes perdues. Ne garantit pas : l'ordre des priorités ni l'impact sur la charge. Difficulté : 2/5. Effort : 1/5.

Niveau 3. Signes : un backlog ordonné ; la règle de priorité est discutée en clair ; un changement ne passe pas « par la petite porte ». Gain : stabilité de l'équipe, priorités compréhensibles. Ne garantit pas que les exigences soient justes. Difficulté : 3/5. Effort : 2/5.

Niveau 4. Signes : fiche d'impact par changement ; indicateur de dérive. Gain : le sponsor décide en connaissance de cause. Ne garantit pas que le périmètre apporte de la valeur. Difficulté : 4/5. Effort : 3/5.

Niveau 5. Signes : retraits de fonctions, usage mesuré, livraison par tranches. Gain : concentration sur ce qui compte, réduction de la dette fonctionnelle. Ne garantit pas la bonne stratégie produit. Difficulté : 5/5. Effort : 4/5.

Atteinte partielle et notation#

Règle commune : voir README.

0,5 : backlog ordonné mais règle de priorité tacite ; processus de changement réservé aux gros changements.
1 : la pratique est visible sur 5 éléments pris au hasard.
Un 5 partiel : usage de rapports mesuré (via les journaux du service) et un retrait de fonction l'an dernier, mais pas de télémétrie sur tous les périmètres. Score ≈ 4,4.

🧪 Exemple

Rapports Power BI de la force de vente : sur 60 rapports livrés, les journaux d'usage montrent que 18 ne sont pas ouverts depuis 6 mois. Décision : retirer 12, fusionner 6. Gain : charge de maintenance et de recette divisée d'un tiers environ (ordre de grandeur de cet exemple fictif).

⚠️ Piège

Backlog cimetière. Symptôme : 800 éléments, dont la moitié a plus d'un an ; la priorisation devient fictive. Cause : on ne supprime jamais. Remède : durée de vie maximale, purge trimestrielle, fermeture avec motif.

⚠️ Piège

Goodhart : avec « zéro changement non tracé » comme objectif, les demandes sont découpées pour passer sous le seuil du processus (salami slicing). Surveiller la somme des petits changements par thème.

💡 Astuce d'expert

Dans un projet data, les exigences fonctionnelles cachent des exigences sur les données (historique, fraîcheur, granularité) qui pèsent plus lourd que les écrans ; voir Cadrage, valeur et cas d'usage.

Passer au niveau suivant#

Moyens possibles (facultatifs)

1 → 2 : un seul canal d'entrée (formulaire, boîte à tickets), statuts simples.
2 → 3 : backlog avec règle de priorité (valeur, risque, coût du retard), critères d'acceptation, comité de changement léger ; voir Scrum en pratique et fondamentaux.
3 → 4 : fiche d'impact, liens entre work items dans Azure DevOps / TFS, indicateur de dérive.
4 → 5 : télémétrie d'usage, revue trimestrielle d'utilité, livraison par tranches (méthodes agiles et lean).

🤖 IA

L'IA reformule des exigences ambiguës, génère des critères d'acceptation candidats et détecte des contradictions entre demandes ; elle ne sait pas quelles exigences ont de la valeur pour vos utilisateurs, et des critères générés « plausibles » mais non validés créent une fausse précision.

Voir aussi#

Thèmes voisins : 01 Cadrage · 03 Planification · 08 Qualité et recette · 11 Budget et valeur.
Autres matrices : Documentation et transmission du savoir (DL) · Recette et validation métier (data) · Visualisation et UX (BI).
Pratique : Fondamentaux · Scrum en pratique · Méthodes agiles et lean · Outils de planification · Glossaire.

✻ Rédigé par Claude Sonnet 5.5