La réponse courte
Le "Scope Creep" survient lorsque l'écart entre ce qui a été promis et ce qui a été réellement construit est imperceptible. Trois mécanismes permettent d'y remédier : un "baseline" (périmètre de référence) documenté et visible par tous, un formulaire de demande de modification d'une demi-page incluant une estimation de l'effort, et une règle d'échange selon laquelle tout ajout déplace un élément de taille similaire ou consomme un budget de modification alloué au préalable. Sans ces trois éléments, chaque "petite demande" se fond dans le sprint et n'est découverte qu'à la date d'échéance.
Pourquoi cela se produit-il particulièrement avec Salesforce ?
Salesforce est suffisamment flexible pour que presque toute demande paraisse peu coûteuse. L'ajout d'un champ prend deux minutes, ce qui rend difficile d'expliquer à une partie prenante pourquoi ce n'est pas si simple. Mais ce champ entraîne une validation, des autorisations, une colonne dans un rapport, un mappage dans la migration, une ligne dans la formation et un test en UAT. Le coût réel est cinq à dix fois supérieur au temps de construction, et c'est précisément cet écart que personne ne voit au moment de la demande.
Cadre de contrôle en quatre éléments
| Composant | Ce qu'il inclut | Qui est responsable | Livrable |
|---|---|---|---|
| Baseline figé | Liste des fonctionnalités, scénarios et "Out of Scope" explicites | Product Owner | Document signé à la fin du Discovery |
| Demande de Modification (Change Request) | Description, motivation commerciale, estimation de l'effort, impact sur la date | Demandeur + Tech Lead | Formulaire d'une demi-page |
| Comité de Modifications | Discussion hebdomadaire de 30 minutes sur toutes les demandes ouvertes | Sponsor, PO, Tech Lead | Décision : approuvé / rejeté / pour la prochaine vague |
| Budget de modification | 10 % à 20 % du périmètre, alloué au début du projet | Sponsor | Suivi hebdomadaire du solde |
Le pouvoir de l'« Out of Scope » explicite
L'élément le plus crucial dans le document de "Baseline" n'est pas ce qui est inclus, mais ce qui est explicitement exclu. Des phrases comme "l'intégration au système de paie n'est pas incluse dans la première phase" ou "la migration des activités antérieures à 2022 n'est pas incluse" permettent d'économiser des semaines de discussion. La règle : tout ce qu'une partie prenante pourrait supposer à tort être inclus – doit figurer dans la liste des exclusions sous son nom complet.
Comment dire "oui" sans en payer le prix
Un rejet catégorique aboutit à un projet livré à temps, mais qui ne sert à personne. L'approche efficace consiste à accepter chaque demande dans un registre, à l'évaluer de manière transparente et à laisser la partie prenante choisir : l'intégrer maintenant au détriment d'un autre élément, attendre la prochaine phase, ou consommer du budget de modification. Lorsque le choix est transparent, la discussion passe de l'émotionnel à l'économique – et en pratique, environ un tiers des demandes sont abandonnées dès que le coût est visible.
Des informations complémentaires sur la définition du "Baseline" sont disponibles dans Définition du MVP et le Guide de Discovery CRM.
Risques courants et actions préventives
Le risque principal est un contrôle trop lourd. Un processus qui exige trois formulaires et deux semaines d'attente pousse les équipes à le contourner – et les modifications continuent, simplement sans documentation. Une demi-page et une discussion hebdomadaire constituent le plafond pratique.
Un deuxième risque est le glissement technique : des décisions architecturales prises au cours d'un sprint qui étendent le périmètre ("Scope") sans que quiconque ne parle de "modification". C'est pourquoi toute modification architecturale significative doit passer par le même comité. Un troisième risque est un Sponsor absent : lorsqu'il n'y a personne pour dire "non" avec autorité, chaque demande reçoit un "nous allons examiner" – ce qui équivaut précisément à un "oui".
Comment mesurer le succès ?
Quatre indicateurs sont suivis dans un rapport hebdomadaire : le nombre de demandes ouvertes, le pourcentage approuvé, la modification cumulative du périmètre par rapport au "Baseline", et le solde du budget de modification. Un projet sain présente une modification cumulative allant jusqu'à 15 % et un solde budgétaire positif lors de la phase d'UAT. Une modification cumulative supérieure à 30 % est le signe que le "Discovery" était trop superficiel, et non que l'équipe manque de discipline.