Le projet que j'ai failli rater : quand le client change 3 fois de scope
Je vais être direct : ce projet, je l'ai mal géré. Pas techniquement, mais côté cadre. Je le raconte parce que la leçon vaut plus que la victoire.
Le contexte
Une plateforme interne pour une équipe RH : gestion des candidatures, entretiens, feedbacks. Devis initial : 4 semaines. Livraison réelle : 9 semaines. Marge brûlée, énergie brûlée, relation abîmée.
Les trois glissements
Semaine 2. "Ce serait bien d'ajouter le suivi des offres, tant qu'on y est." J'ai dit oui. Une journée de plus, pas grave.
Semaine 4. "Finalement, il faut que ça marche pour trois entités juridiques différentes." Là, j'aurais dû arrêter et refaire un devis. J'ai laissé filer, en me disant qu'on rattraperait.
Semaine 6. "Est-ce qu'on pourrait aussi générer les contrats en PDF ?" J'ai fini par dire non, mais trop tard : les deux premiers glissements avaient déjà fait exploser le budget temps.
Ce que j'ai compris
Un client qui change de scope n'est pas un mauvais client. C'est un client qui découvre son besoin en voyant le produit prendre forme. C'est normal, c'est même sain.
Ce qui n'est pas sain, c'est un builder qui confond urgence et priorité stratégique. Chaque demande semblait urgente. Aucune ne l'était vraiment.
Ce que je fais aujourd'hui
Trois règles, appliquées sans exception :
- Toute demande hors scope est écrite dans un doc "post-MVP" partagé, avec estimation.
- Un point de scope hebdo de 15 minutes : on tranche ensemble ce qui entre, ce qui sort.
- Un budget "flex" de 10 % du temps total, alloué explicitement aux petits ajouts. Au-delà, on renégocie ou on reporte.
Ce cadre a l'air rigide. Il ne l'est pas : il libère la relation. Le client sait où il va, moi aussi.