Récemment, le gold plating en gestion de projet a été évoqué dans l’article “Top 15 des requêtes Jira JQL qu’un Product Owner doit maîtriser“, très pratiqué en entreprise mais peu nommé, je dédie cet article à ce sujet aussi passionnant que toxique.
En gestion de projet comme en agile, une croyance persiste : livrer plus que demandé serait toujours une bonne chose. Une fonctionnalité en bonus, une amélioration non prévue, un “tant qu’à y être”… Intention louable. Résultat souvent contre-productif.
Ce phénomène porte un nom : le gold plating que l’on peut traduire en français la surqualité.
Dans cet article, je te propose de comprendre ce qu’est réellement le gold plating, pourquoi il apparaît si souvent dans les équipes, et surtout comment l’éviter sans tomber dans une logique de livraison médiocre ou minimaliste.
À lire dans cet article
- Qu’est-ce que le gold plating, exactement ?
- Pourquoi le gold plating est si fréquent en projet et en agile
- Gold plating et valeur : une confusion persistante
- Pourquoi le gold plating est un vrai risque projet ?
- Agile et gold plating : un paradoxe courant
- Comment prévenir le gold plating (sans tuer la qualité)?
- Checklist : sommes-nous en train de faire du gold plating?
- Conclusion – Le courage de livrer moins
Qu’est-ce que le gold plating, exactement ?
En gestion de projet, le gold plating désigne le fait d’ajouter des fonctionnalités, du travail ou de la qualité non demandés, sans validation explicite du client ou du Product Owner, en pensant créer davantage de valeur.
Dans le PMBOK, c’est clairement identifié comme une mauvaise pratique.
Ce que le gold plating n’est pas
Il est important de lever les confusions fréquentes :
- ❌ Ce n’est pas de l’innovation validée
- ❌ Ce n’est pas une amélioration demandée par le métier
- ❌ Ce n’est pas une optimisation priorisée dans le backlog
- ❌ Ce n’est pas de la qualité attendue
Pourquoi le gold plating est si fréquent en projet et en agile
Le gold plating ne vient presque jamais d’une mauvaise intention. Au contraire.
Les causes humaines
- volonté de bien faire
- peur de décevoir
- recherche de reconnaissance
- fierté professionnelle mal canalisée
Les causes organisationnelles
- critères de succès flous
- backlog imprécis
- absence de limites claires
- gouvernance produit faible
- confusion entre autonomie et absence de cadre
Gold plating et valeur : une confusion persistante
Une des racines du problème vient d’une équation fausse mais très répandue :
- plus d’effort = plus de valeur
En réalité :
- plus de fonctionnalités ≠ plus d’utilisation
- plus de complexité ≠ meilleure expérience
- plus de qualité perçue ≠ valeur mesurable
Pourquoi le gold plating est un vrai risque projet?
Contrairement aux idées reçues, le gold plating augmente le risque, il ne le réduit pas.
Impacts concrets
- dérive des délais
- dépassements de coûts
- dette technique déguisée
- complexité inutile
- perte de focus sur l’objectif initial
- frustration côté métier (“ce n’est pas ce qu’on avait demandé …”)
- double frustration côté métier (“… et en plus, en attendant, personne n’a travaillé sur nos priorités !”)
Agile et gold plating : un paradoxe courant
L’agilité n’immunise pas contre le gold plating. Parfois, elle l’amplifie.
Les pièges classiques
- “on est autonome, donc on décide”
- “on améliore en continu”
- “on anticipe les besoins futurs”
Comment prévenir le gold plating (sans tuer la qualité)?
Prévenir le gold plating ne consiste pas à brider les équipes, mais à clarifier les attentes.
Leviers efficaces
- Definition of Done claire et explicite
- critères d’acceptation orientés valeur, pas solution
- validation PO systématique pour tout ajout
- priorisation stricte
Checklist : sommes-nous en train de faire du gold plating?
Avant d’ajouter “un petit plus”, pose-toi ces questions :
- Cette fonctionnalité a-t-elle été demandée explicitement ?
- A-t-elle été priorisée par le Product Owner ?
- Répond-elle à un problème utilisateur identifié ?
- Avons-nous un critère de succès mesurable ?
- Que se passe-t-il si on ne la livre pas maintenant ?
- Qui a validé cet ajout ?
- Est-ce une hypothèse ou un fait ?
Conclusion – Le courage de livrer moins
Livrer moins ne signifie pas livrer mal. Cela signifie livrer juste et utile. Le professionnalisme en projet et en agile ne se mesure pas à la quantité livrée, mais à la capacité à respecter le besoin réel et non pas celui qu’on imagine. Et comme tout signal, il mérite d’être écouté, pas maquillé. 😉
Laisser un commentaire