[Temps de lecture : 8 minutes]
Imaginez : vous investissez 100 000€ dans le développement d’une application. À la livraison, vos équipes n’utilisent que la moitié des fonctionnalités. L’autre moitié ? Des écrans que personne ne visite, des boutons sur lesquels personne ne clique, des modules entiers développés pendant des semaines et qui dorment dans un coin de l’interface.
Ce n’est pas un scénario catastrophe. C’est la réalité statistique de la majorité des projets logiciels.
45%
jamais utilisées
19%
Rarement utilisées
16%
parfois utilisées
20%
régulièrement utilisées
Source : Standish Group — Étude sur l’utilisation réelle des fonctionnalités logicielles.
Cause n°1 – On a demandé au décideur, pas à l’utilisateur
C’est la cause racine numéro 1, et de loin. Le cahier des charges est rédigé par le dirigeant, le directeur commercial ou le DSI. Pas par les personnes qui vont utiliser l’outil 8 heures par jour.
Le dirigeant pense en termes de tableaux de bord, de reporting et de contrôle. L’utilisateur pense en termes de rapidité de saisie, de nombre de clics et de contournements de bugs. Les deux visions sont légitimes, mais si on ne construit que la première, l’outil sera utilisé par le dirigeant une fois par mois et détesté par les équipes tous les jours.
Struxis a accompagné une PME qui avait déployé plieurs CRM en 3 ans – abandonnés à chaque fois. Le diagnostic a révélé que les commerciaux n’avaient jamais été consultés. Le problème n’était pas l’outil, c’était l’absence de recherche utilisateur.
L’antidote Struxis
- Interviewer 3-5 utilisateurs représentatifs AVANT toute spécification
- Créer des personas basés sur des usages réels, pas des hypothèses
- Cartographier les parcours utilisateurs actuels (avec les contournements, les fichiers Excel, les post-it)
- Valider les fonctionnalités par ceux qui les utiliseront, pas par ceux qui les financent
Cause n°2 – Le périmètre est défini par accumulation, pas par soustraction
Lors des ateliers de cadrage, chaque participant ajoute ses besoins. Le commercial veut un module de devis. Le comptable veut l’export automatique. Le DG veut un dashboard. Le support veut un ticketing. Personne ne retire rien. Le backlog gonfle, sprint après sprint.
C’est le phénomène classique du « feature creep » : l’accumulation progressive de fonctionnalités qui semblent toutes « importantes » mais dont la moitié ne sera utilisée que par 1 personne, 1 fois par trimestre.
Le problème n’est pas d’avoir des idées. C’est de ne pas savoir dire non. Ou plutôt : de ne pas avoir de méthode pour arbitrer.
La fonctionnalité la plus puissante est celle qu’on ne développe pas. Chaque ligne de code a un coût de maintenance à vie.
L’antidote Struxis
- Prioriser avec la méthode MoSCoW : Must Have (MVP) / Should Have / Could Have / Won’t Have
- Définir le MVP comme l’ensemble minimal qui résout le problème principal - pas la liste de tout ce qui serait « bien »
- Documenter les exclusions aussi précisément que les inclusions (si quelqu’un demande « pourquoi c’est pas dedans », la réponse est écrite)
- Règle Struxis : si une fonctionnalité n’est utilisée que par < 20% des utilisateurs, elle sort du MVP
Cause n°3 – On confond « demande » et « besoin »
Un utilisateur dit : « Je veux un bouton pour exporter en PDF ». La réponse classique : on développe un export PDF. La bonne réponse : « Pourquoi avez-vous besoin d’un export PDF ? »
Souvent, la vraie réponse est : « Parce que je dois envoyer un récap’ à mon manager chaque vendredi. » La vraie solution n’est pas un bouton PDF. C’est un email automatique envoyé chaque vendredi.
Quand on prend les demandes des utilisateurs au pied de la lettre sans creuser le « pourquoi », on développe des solutions techniques à des problèmes mal formulés. Le résultat : des fonctionnalités qui répondent à la lettre de la demande mais pas à l’esprit du besoin.
Avant de spécifier une fonctionnalité, poser 5 fois la question « Pourquoi ? » pour remonter à la cause racine du besoin. C’est souvent au 3ème ou 4ème « pourquoi » que la vraie solution apparaît – et elle est rarement celle imaginée au départ.
L’antidote Struxis
- Toujours creuser le problème derrière la demande (technique des 5 Pourquoi)
- Formuler les besoins sous forme de problèmes à résoudre, pas de solutions à développer
- Rédiger des user stories au format « En tant que [persona], je veux [action] AFIN DE [bénéfice] »
- Si le « afin de » n’est pas clair, la fonctionnalité n’a pas sa place dans le backlog
Cause n°4 – On confond « demande » et « besoin »
Dans la majorité des projets que Struxis audite, le premier contact de l’utilisateur avec le produit a lieu… à la livraison. Pas avant. Le décideur a validé le cahier des charges, le prestataire a développé, et le jour du déploiement, tout le monde découvre que l’interface ne correspond pas aux usages réels.
Modifier un wireframe prend 10 minutes. Modifier un prototype navigable prend 1 heure. Modifier un écran développé prend 1 à 5 jours. Modifier un module en production prend 2 à 4 semaines.
Plus on attend pour tester, plus la correction coûte cher. C’est la loi fondamentale de tout projet logiciel.
Wireframe
100€
10 min pour corriger
Prototype
500€
1 heure pour corriger
Développé
5 000€
1–5 jours pour corriger
En production
20 000€+
2–4 semaines pour corriger
L’antidote Struxis
- Créer des wireframes de toutes les pages clés AVANT le développement
- Construire un prototype navigable et le tester auprès de 3–5 utilisateurs représentatifs
- Itérer sur le prototype jusqu’à ce que les retours soient positifs - c’est 100x moins cher que de corriger après
- Prévoir un cycle de recette structuré à chaque sprint, pas seulement à la fin
Cause n°5 – On ne mesure pas l’usage après la livraison
Le projet est livré. Le PV de recette est signé. Le prestataire envoie sa dernière facture. Tout le monde passe à autre chose.
Personne ne mesure combien de fonctionnalités sont réellement utilisées. Personne ne sait si le module de reporting qui a coûté 15K€ est consulté une fois par semaine ou une fois par an. Personne n’analyse les parcours réels des utilisateurs pour détecter les zones mortes de l’application.
Résultat : quand vient le temps de la V2 ou de l’évolution, on repart du même cahier des charges gonflé, sans tirer les leçons de la V1. Et le cycle du gaspillage recommence.
Ce qui ne se mesure pas ne s’améliore pas. Si personne ne sait quelles fonctionnalités sont utilisées, personne ne peut décider lesquelles méritent d’être améliorées — ou supprimées.
L’antidote Struxis
- Intégrer des analytics simples dès le lancement (pages vues, clics, parcours)
- Planifier un bilan d’usage à 1 mois, 3 mois et 6 mois post-livraison
- Identifier les zones mortes (fonctionnalités avec < 5% d’utilisation) pour décider : améliorer, simplifier ou supprimer
- Utiliser les données d’usage pour nourrir le cadrage de la V2 - pas les intuitions
Synthèse : les 5 causes du gaspillage fonctionnel
# | Cause | Conséquence | Antidote Struxis |
1 | On demande au décideur, pas à l’utilisateur | Outil déconnecté du terrain | Recherche utilisateur + personas |
2 | Périmètre par accumulation | Feature creep + budget explosé | Priorisation MoSCoW stricte |
3 | Demandes prises au pied de la lettre | Solutions au mauvais problème | 5 Pourquoi + user stories |
4 | Aucun test avant développement | Découvertes tardives = coûteuses | Wireframes + prototype testé |
5 | Pas de mesure d’usage post-livraison | On reproduit les mêmes erreurs | Analytics + bilan d’usage régulier |
La méthode Struxis : ne construire que ce qui compte
Chez Struxis, la lutte contre le gaspillage fonctionnel est intégrée à chaque étape du processus :
01
Comprendre
Interviews utilisateurs, observation des usages réels, cartographie des irritants. Pas d’hypothèses.
02
Prioriser
MoSCoW impitoyable. Si ce n’est pas un Must Have, ça sort du MVP. Les exclusions sont documentées.
03
Tester
Wireframes et prototype testés AVANT le dev. On corrige à 100€, pas à 20 000€.
04
Mesurer
Bilan d’usage post-livraison. Les données nourrissent la V2, pas les intuitions.
« Le coût d’une fonctionnalité inutile ne s’arrête pas à son développement. Elle coûte en maintenance, en complexité, en formation, en confusion pour l’utilisateur. Chaque feature non construite est une économie permanente. »
Le vrai KPI d’un projet réussi
Le succès d’un projet IT ne se mesure pas au nombre de fonctionnalités livrées. Il se mesure au nombre de fonctionnalités utilisées.
Un outil avec 15 fonctionnalités dont 14 sont utilisées quotidiennement vaut infiniment plus qu’un outil avec 60 fonctionnalités dont 30 dorment.
Le rôle de Struxis est de faire en sorte que chaque euro investi en développement produise de la valeur réelle – pas du code mort.
Votre application contient des zones mortes ?
Struxis propose un diagnostic flash (1-2 jours, 700-1 500€) pour cartographier l’usage réel de votre outil, identifier le gaspillage et recommander les actions prioritaires.
