Le scope creep (élargissement progressif du périmètre) est la première cause de dérapage budgétaire dans les projets d'application. Voici comment ça se produit, et la méthode pour garder le contrôle sans freiner l'innovation utile.
Le scope creep, la cause #1 de dérapage
Le scope creep (élargissement progressif du périmètre en cours de projet) est la première raison pour laquelle les projets d'application dépassent leur budget. Sans discipline, 30 à 50 % de dépassement est la norme, pas l'exception.
Ce n'est pas que les prestataires sont mauvais ou les clients gourmands : c'est mécanique. À chaque démo, à chaque retour utilisateur, de nouvelles idées émergent. Sans process pour arbitrer, elles s'ajoutent toutes au projet en cours.
D'où viennent les nouvelles demandes
| Source | Type de demande typique |
|---|---|
| Démos en cours de projet | « Tiens, et si on ajoutait... », « Ce serait bien si... » |
| Retours utilisateurs | « Les commerciaux voudraient aussi voir... » |
| Direction qui découvre | « Important d'avoir ça pour le board » |
| Veille concurrentielle | « Tel concurrent a ça, il nous faut pareil » |
| Tests utilisateurs | Vrais bugs UX qui justifient correction (légitimes) |
| Évolutions techniques externes | Mise à jour d'API tierce qui change quelque chose |
La discipline pour garder le contrôle
Toute demande hors du périmètre cadré passe par un arbitrage explicite, pas par une décision informelle en réunion.
Évaluer impact vs coût
Quelle valeur la demande apporte ? Combien de temps de dev ? Si le ratio est mauvais, report en backlog post-MVP.
Comparer au périmètre initial
C'est de la correction de cadrage (le besoin était mal vu) ou une vraie nouveauté ? Une vraie nouveauté = avenant explicite.
Proposer un avenant chiffré
Si la demande est validée, avenant écrit : coût supplémentaire, décalage de planning, validation des deux parties. Pas d'ajout informel qui n'est jamais facturé.
Le MVP doit rester strict
Le piège classique : transformer le MVP en v1.5 en cours de projet. Tout ce qui n'est pas indispensable au lancement doit aller dans le backlog post-MVP, pas dans la première version.
Question à se poser pour chaque feature en cours :
- Sans cette feature, l'utilisateur peut-il utiliser l'app ?
- Sans cette feature, le MVP résout-il toujours le problème métier principal ?
- Cette feature peut-elle être ajoutée dans une v1.1 sans tout casser ?
Si oui aux trois : backlog post-MVP. Si non à l'une : on garde.
Pour cadrer un projet avec une discipline qui évite le scope creep, prévoyez un premier appel. Voir aussi cadrer un MVP en 6 semaines.
Questions fréquentes
Comment savoir si une demande est un scope creep ou un vrai besoin ?
Trois questions : (1) C'était dans le périmètre cadré au démarrage ? (2) Si on ne le fait pas, le MVP est-il toujours utile ? (3) Quel impact attendu vs coût ? Une vraie nouvelle valeur urgente justifie un avenant. Une « bonne idée » sans urgence va dans le backlog post-MVP.
Le prestataire peut-il refuser une demande hors-périmètre ?
Pas refuser : proposer un avenant (coût + délai supplémentaire). Le client décide s'il signe l'avenant ou reporte en post-MVP. Un prestataire qui accepte tout « gratos » soit sacrifie sa marge, soit la livraison globale en pâtit. Un avenant explicite est sain pour les deux parties.
Comment éviter le scope creep dès le démarrage ?
Trois choses : (1) cadrage rigoureux avec hypothèses explicites et exclusions claires, (2) backlog post-MVP partagé dès le début (tout ce qui n'est pas v1 y va), (3) processus d'avenant écrit et accepté par les deux parties. Avec ça, le scope creep reste contenu.