Le scope creep commence avant le premier commit
Le scope creep, cette dérive progressive du périmètre d'un projet, a mauvaise réputation en cours d'exécution. Mais la cause première ne se situe presque jamais dans l'exécution. Elle se situe dans la rédaction des specs, au moment où le périmètre a été décrit de façon trop vague pour qu'on puisse dire, plus tard, ce qui en faisait partie et ce qui n'en faisait pas partie.
Les causes concrètes du scope creep dans les specs
- Des exigences formulées comme des objectifs plutôt que comme des livrables
- L'absence de critères d'acceptation par fonctionnalité
- L'absence d'exclusions explicites
- Les décisions prises oralement et jamais reportées dans le document de référence
Pourquoi un scope modulaire limite le scope creep
C'est le principe que suit l'assistant IA de Devizy : la structuration en modules, plafonnés à cinq, puis en sous-tâches, avec un signalement automatique dès qu'un module dépasse dix sous-tâches, produit un document où chaque brique de travail est isolée et nommée. Une demande qui n'apparaît dans aucune ligne est, par construction, hors périmètre initial et donc identifiable comme un ajout à chiffrer séparément.
Verrouiller le périmètre au moment de la rédaction
- Lister explicitement ce qui est exclu de la version en cours
- Définir un critère de validation concret par sous-tâche
- Geler le scope avant de demander les devis
- Dater et versionner chaque modification du document de référence
Le devis ligne à ligne comme garde-fou
Un devis comparable, ligne par ligne, entre plusieurs prestataires sert de référence tout au long du projet : chaque ligne acceptée correspond à un engagement précis, ce qui rend visible, à tout moment, l'écart entre ce qui a été chiffré et ce qui est en train d'être demandé.