Le logiciel payé qui ne livre rien : quand 80 % des fonctions ne servent à personne

Vous financez le développement d'un logiciel, votre équipe ou votre prestataire livre fonctionnalité après fonctionnalité, et pourtant le résultat déçoit. Ce n'est pas une impression : les études montrent que jusqu'à 80 % des fonctionnalités d'un produit logiciel ne sont presque jamais utilisées. C'est un développement sur deux, parfois plus, payé pour rien. La cause n'est pas technique, et le maillon manquant a un nom précis : le Product Owner.

Une PME investit dans le développement d'un outil sur mesure, ou dans l'évolution d'une plateforme existante. Les semaines passent, le budget file, l'équipe technique livre consciencieusement ce qu'on lui a demandé. Puis vient l'usage réel, et la douche froide : les utilisateurs n'exploitent qu'une poignée d'écrans, ignorent la moitié des fonctions, et réclament des choses simples qui, elles, n'ont jamais été priorisées. Le logiciel fonctionne parfaitement. Il ne sert simplement pas à grand-chose. Ce gâchis a une origine unique : personne n'a tranché ce qui comptait vraiment.

Le chiffre que l'industrie connaît et tait

Les données sont connues des professionnels et rarement dites aux clients. Le Standish Group, en analysant l'usage réel des fonctionnalités dans les applications d'entreprise, a établi que 64 % d'entre elles sont rarement ou jamais utilisées, dont 45 % jamais. Plus récemment, l'éditeur Pendo, à partir des données d'usage de centaines de produits logiciels et de dizaines de milliers d'applications, a trouvé pire encore : environ 80 % des fonctionnalités sont rarement ou jamais utilisées, et seulement 12 % environ génèrent 80 % de l'usage quotidien. Traduit en argent, cela signifie que la majorité de l'effort de développement de la plupart des produits finance des choses que les utilisateurs ne valorisent pas assez pour s'en servir.

Le vrai problème : personne ne dit non

Pourquoi construit-on tant de choses inutiles ? Parce que, dans la plupart des projets, chaque partie prenante ajoute ses demandes sans que personne n'arbitre. Le commercial veut telle option, la comptabilité telle autre, un client important a réclamé une fonction, le dirigeant a eu une idée en réunion. Faute d'un responsable qui hiérarchise et refuse, le périmètre gonfle, l'équipe technique exécute tout, et le budget se dissout dans des fonctionnalités que personne n'utilisera. Le développement logiciel n'échoue presque jamais par manque de compétence technique : il échoue par excès de choses construites et par absence de priorisation. On confond activité et valeur.

Le Product Owner, ce chaînon décisif

Dans les méthodes agiles, un rôle existe précisément pour résoudre ce problème : le Product Owner. Sa mission n'est pas de coder, c'est de décider. Il détient et hiérarchise le carnet des demandes, il traduit le besoin métier en priorités claires pour l'équipe technique, et surtout il tranche : ce qu'on fait maintenant, ce qu'on repousse, ce qu'on ne fera jamais. Il fait le pont entre le dirigeant qui connaît la valeur business et les développeurs qui connaissent le coût technique. C'est lui qui garantit que chaque euro de développement va vers ce qui rapporte, et non vers ce qui encombre. Sans ce rôle tenu fermement, un projet logiciel dérive presque toujours vers le catalogue de fonctions inutiles.

Pourquoi les PME n'ont pas ce rôle, et comment l'avoir

La plupart des PME n'ont pas de Product Owner. Le dirigeant n'a ni le temps ni toujours la méthode, l'équipe technique se retrouve à décider des priorités métier qu'elle ne maîtrise pas, et le prestataire externe construit ce qu'on lui commande sans challenger la pertinence. Le résultat est prévisible. Pourtant, ce rôle n'exige pas un recrutement à temps plein : il exige de la méthode, de la présence aux moments clés, et le mandat de trancher. C'est exactement ce qu'un Product Owner à temps partagé apporte, en cadençant le développement, en tenant la priorisation, et en protégeant le budget contre l'inflation des demandes. Le retour sur investissement se mesure vite : moins de fonctions construites, davantage de fonctions utiles.

Construire moins, livrer plus de valeur