Analyse de la valeur appliquée aux projets numériques
Les projets numériques dérapent rarement faute de technique. Ils dérapent parce qu'on a acheté des fonctionnalités au lieu d'exprimer des besoins. L'analyse de la valeur, née dans l'industrie, corrige précisément ce travers.
Le dossier de consultation compte deux cents exigences. Chacune a été demandée par quelqu’un, aucune n’a été hiérarchisée, et le budget ne permet manifestement pas de toutes les satisfaire. Les offres reçues seront donc incomparables, le titulaire retenu promettra tout, et l’arbitrage se fera pendant le projet, au pire moment. Ce scénario est l’un des plus fréquents dans les projets numériques, publics comme privés. L’analyse de la valeur a été inventée pour l’éviter.
Une méthode industrielle, utile au numérique
La méthode est née aux États-Unis dans les années 1940, chez General Electric, pour reconcevoir des produits en pénurie de matières. Son idée centrale est simple : un client n’achète pas un objet, il achète les fonctions que cet objet remplit. Si l’on sait nommer ces fonctions, on peut chercher la manière la moins coûteuse de les rendre, et renoncer à ce qui ne sert à rien.
En Europe, la démarche est normalisée. La norme NF EN 12973 traite du management par la valeur ; la norme NF EN 16271 décrit l’expression fonctionnelle du besoin et le cahier des charges fonctionnel. On n’a pas besoin de les appliquer à la lettre, mais elles fournissent un vocabulaire partagé, utile quand acheteurs, métiers et informaticiens doivent s’entendre.
La valeur s’y définit comme un rapport : la satisfaction des besoins, rapportée aux ressources consommées pour y parvenir. Augmenter la valeur, c’est soit mieux satisfaire le besoin à coût égal, soit le satisfaire autant à moindre coût. Dans un projet numérique, cela se traduit très concrètement : chaque fonctionnalité a un coût de développement, de formation, de maintenance et d’exploitation, et toutes ne rapportent pas autant.
On ne finance pas des écrans : on finance des services rendus à des personnes.
Du besoin aux fonctions
Le premier travail consiste à traduire les demandes en fonctions. Une fonction s’exprime par un verbe à l’infinitif et un complément, sans préjuger de la solution. « Un moteur de recherche plein texte » est une solution. « Permettre à un agent de retrouver un dossier à partir de n’importe quelle information connue » est une fonction. La différence paraît subtile ; elle change tout, car la seconde formulation admet plusieurs réponses, dont certaines beaucoup moins coûteuses.
On distingue habituellement :
- les fonctions principales, qui justifient l’existence du système (instruire une demande, délivrer un acte, suivre une production) ;
- les fonctions contraintes, qu’on ne choisit pas : réglementation, sécurité, accessibilité, interopérabilité avec l’existant ;
- les fonctions complémentaires, qui améliorent le service sans en être la raison d’être.
Chaque fonction reçoit ensuite des critères d’appréciation, un niveau attendu et une flexibilité. « Retrouver un dossier » devient mesurable : en moins de trente secondes, pour 95 % des recherches, avec une flexibilité forte ou faible selon l’enjeu. La flexibilité est l’outil de négociation : elle dit aux candidats où ils peuvent proposer moins pour coûter moins.
Hiérarchiser et chiffrer
Une fois les fonctions listées, deux questions guident l’arbitrage. Quelle est l’importance de chaque fonction pour les utilisateurs ? Combien coûte-t-elle ? La comparaison des deux révèle les déséquilibres.
| Fonction (exemple d’un service d’instruction) | Importance | Part du coût estimé | Lecture |
|---|---|---|---|
| Recevoir une demande complète en ligne | Forte | Moyenne | Équilibrée |
| Instruire la demande et tracer la décision | Forte | Forte | Équilibrée |
| Informer le demandeur de l’avancement | Forte | Faible | À renforcer : beaucoup de valeur pour peu de coût |
| Produire des statistiques personnalisables | Faible | Forte | À simplifier : un export suffit peut-être |
| Application mobile dédiée aux agents | Moyenne | Forte | À reporter ou remplacer par un site adapté au mobile |
Les valeurs de ce tableau sont illustratives : elles montrent la lecture, pas un résultat. Dans la pratique, l’importance se mesure en atelier, souvent par une pondération où chaque participant répartit des points, et le coût s’estime à partir de projets comparables ou de premières consultations du marché. L’objectif n’est pas la précision comptable, mais de faire apparaître les fonctions dont le coût est sans rapport avec leur importance.
Conduire la démarche en pratique
L’analyse de la valeur est un travail de groupe. Elle réunit un animateur, qui n’a pas d’intérêt dans la solution, les utilisateurs finaux, les responsables métier, un acheteur et un technicien capable d’estimer les coûts. Sans utilisateurs, on hiérarchise selon les préférences de la hiérarchie ; sans technicien, on chiffre au hasard.
Une séquence réaliste pour un projet de taille moyenne se déroule en quatre ateliers sur quelques semaines : un premier pour recenser les fonctions à partir des parcours réels des utilisateurs, un deuxième pour les caractériser (critères, niveaux, flexibilité), un troisième pour les hiérarchiser, un dernier pour confronter importance et coûts et décider des arbitrages. Le livrable est un cahier des charges fonctionnel, plus court et plus utile qu’une liste d’exigences.
- Un besoin exprimé sans enfermer dans une solution
- Des arbitrages faits avant le marché, pas pendant le projet
- Des offres comparables, car jugées sur les mêmes fonctions
- Un langage commun entre métiers, acheteurs et informaticiens
- Elle ne remplace pas la connaissance des processus réels
- Elle ne donne pas de coûts fiables sans estimation sérieuse
- Elle échoue si l’animateur défend déjà une solution
- Elle demande du temps aux utilisateurs, qu’il faut libérer
Trois pièges propres au numérique
Oublier le coût complet. Une fonctionnalité ne coûte pas seulement son développement. Elle coûte en tests à chaque mise à jour, en formation, en assistance, en hébergement et en sécurité pendant toute la durée de vie du système. Une fonction rarement utilisée mais complexe pèse ainsi plusieurs fois son prix initial.
Confondre fonction et habitude. Beaucoup de demandes reproduisent l’outil précédent ou le formulaire papier. « Imprimer le dossier complet » est souvent la trace d’un circuit de signature qu’un nouveau système pourrait supprimer. L’analyse des processus, en amont, aide à distinguer ce qui est un besoin de ce qui est un réflexe.
Négliger les fonctions contraintes. Sécurité, protection des données, accessibilité et réversibilité ne se négocient pas, mais leur niveau doit être fixé explicitement. Laissées implicites, elles reviennent en cours de projet sous forme d’avenants.
L’analyse de la valeur s’inscrit naturellement dans une démarche d’achat indépendante, où l’on cherche la meilleure réponse au besoin plutôt qu’à justifier un produit. C’est le cœur de notre approche de conseil neutre, et le prolongement direct du sourcing avant rédaction. Premier pas possible : reprendre la liste d’exigences de votre prochain projet et, pour chacune, se demander quelle fonction elle sert et ce qu’il en coûterait d’y renoncer.
Questions fréquentes
Quelle différence avec un cahier des charges classique ?
Un cahier des charges classique décrit souvent la solution attendue (écrans, modules, technologies). Le cahier des charges fonctionnel issu de l'analyse de la valeur décrit ce que le système doit permettre, avec des critères mesurables et une marge de négociation, ce qui laisse aux candidats la liberté de proposer mieux ou moins cher.
Combien de temps prend une analyse de la valeur ?
Pour un projet numérique de taille moyenne, quelques ateliers répartis sur trois à six semaines suffisent souvent. L'essentiel est de réunir les bonnes personnes, pas de multiplier les séances.
Peut-on l'appliquer à un projet déjà lancé ?
Oui. Appliquée en cours de projet, elle sert à arbitrer un dépassement de budget : on identifie les fonctions dont le coût est disproportionné par rapport à leur importance et on les simplifie ou les reporte.