Pourquoi une petite solution utile vaut souvent mieux qu’un grand projet impossible à valider
Un grand projet peut sembler plus sérieux parce qu’il mobilise davantage de fonctionnalités, de ressources et de parties prenantes.
Pourtant, cette ambition devient risquée lorsqu’elle empêche de vérifier rapidement si le problème est bien compris et si la solution apporte réellement de la valeur.
À l’inverse, une petite solution utile permet d’observer les usages, de recueillir des retours concrets et de décider avec moins de suppositions.
L’enjeu n’est donc pas de choisir entre ambition et simplicité, mais d’identifier la plus petite solution capable de réduire une incertitude importante.
Le vrai risque n’est pas de commencer petit
Commencer par une solution limitée est souvent présenté comme une démarche prudente.
Mais le principal risque d’un projet ne vient pas nécessairement de la modestie de sa première version.
Il peut surtout venir du fait de construire longtemps avant d’avoir vérifié que le problème existe dans les termes posés, que les utilisateurs le jugent suffisamment important et qu’ils sont prêts à changer leurs habitudes.
Plus un projet progresse sans confrontation avec le réel, plus ses hypothèses deviennent difficiles à remettre en cause.
Des ressources ont été engagées, une feuille de route a été annoncée, des décisions ont été prises et plusieurs équipes attendent un résultat.
Le projet continue alors parfois moins parce que les éléments sont convaincants que parce qu’il est devenu difficile de reconnaître qu’une partie du raisonnement initial était fragile.
Les travaux consacrés à l’escalade de l’engagement étudient précisément ce phénomène : la tendance à poursuivre un projet malgré des signaux défavorables, notamment lorsque du temps, de l’argent ou du capital politique ont déjà été investis.
Cela ne signifie pas que tout grand projet est mal engagé.
Cela rappelle simplement que l’investissement passé ne constitue pas, à lui seul, une raison suffisante pour continuer.
Une petite solution ne supprime pas ce risque.
Elle permet de l’exposer plus tôt, avec un coût de correction généralement plus limité.
Un grand projet rassemble plusieurs hypothèses
Un projet de grande ampleur n’est presque jamais une seule idée à vérifier.
Il rassemble plusieurs paris qui peuvent se renforcer ou se fragiliser mutuellement.
Il faut parfois supposer que :
- le problème est réellement important ;
- les personnes concernées le comprennent de manière comparable ;
- elles accepteront une nouvelle façon de travailler ;
- la solution proposée répondra à leurs attentes ;
- elles sauront l’utiliser sans accompagnement excessif ;
- l’organisation pourra l’intégrer dans ses pratiques ;
- les contraintes techniques seront maîtrisables ;
- le modèle économique ou opérationnel sera viable.
Un cahier des charges détaillé ne prouve pas qu’une demande existe.
Une architecture technique ambitieuse ne prouve pas qu’un usage sera adopté.
Une présentation convaincante ne prouve pas qu’un problème mérite une réponse aussi complexe.
La difficulté tient au caractère imbriqué de ces hypothèses.
Si le problème est mal défini, une interface plus élégante ne suffira pas.
Si les utilisateurs ne perçoivent pas la valeur proposée, une automatisation plus performante ne changera pas nécessairement leur comportement.
Si le fonctionnement réel n’est pas compris, le risque est d’automatiser trop tôt une procédure qui devra ensuite être entièrement repensée.
La première étape consiste donc à identifier les hypothèses les plus risquées, puis à chercher le moyen le plus simple de les confronter au réel.
Valider ne signifie pas tout prouver
Le mot « validation » peut donner l’impression qu’une première expérimentation doit démontrer que le projet fonctionnera dans toutes les situations.
Ce n’est généralement ni possible ni nécessaire.
Au début, une solution sert surtout à réduire une incertitude importante.
Selon le contexte, il peut s’agir de vérifier :
- si le problème est effectivement rencontré ;
- si les utilisateurs lui accordent suffisamment d’importance ;
- si une première réponse leur paraît utile ;
- si le parcours est compréhensible ;
- si une action attendue est réellement effectuée ;
- si la solution peut s’intégrer dans les pratiques existantes ;
- si le fonctionnement opérationnel est compatible avec les contraintes du terrain.
Chaque question appelle un moyen d’observation différent.
Un entretien aide à comprendre une situation, mais ne démontre pas qu’un usage sera durable.
Une démonstration peut susciter de l’intérêt, mais ne prouve pas qu’une personne utilisera régulièrement la solution.
Un prototype peut révéler un problème de compréhension, sans permettre de conclure sur la viabilité économique ou technique de l’ensemble du projet.
Les référentiels de conception de services recommandent d’ailleurs de tester en priorité les hypothèses les plus risquées, plutôt que de chercher à reproduire immédiatement toute la solution finale.
La bonne question n’est donc pas seulement : « Comment construire rapidement ? » Elle est aussi : « Qu’avons-nous besoin d’apprendre, et quelle expérience peut nous l’apprendre ? »
Une petite solution n’est pas une version dégradée
Réduire le périmètre ne consiste pas à retirer des fonctionnalités au hasard jusqu’à obtenir un produit moins complet.
Une petite solution utile doit conserver le mécanisme essentiel de la valeur promise.
Si la solution est censée aider une personne à accomplir une tâche, la première version doit permettre d’observer cette tâche.
Si elle doit faciliter une décision, elle doit offrir un support réel à cette décision.
Si elle doit faire gagner du temps, il faut pouvoir examiner si elle réduit effectivement la difficulté ou la durée du parcours.
Une version minimale mais inutilisable n’apprend pas grand-chose.
Elle peut même conduire à une conclusion injuste : « Les utilisateurs ne sont pas intéressés », alors qu’ils ont simplement été confrontés à une expérience trop incomplète pour percevoir l’intérêt de la proposition.
La réduction pertinente porte donc sur le périmètre, pas nécessairement sur l’utilité.
Il est possible de limiter :
- le nombre de cas couverts ;
- le nombre d’utilisateurs concernés ;
- le nombre de canaux ;
- le niveau d’automatisation ;
- le nombre d’intégrations ;
- la richesse de l’interface ;
- la zone géographique ou organisationnelle ;
- la quantité de données traitées.
En revanche, il faut préserver ce qui permet de tester l’hypothèse centrale.
Une solution réduite doit être limitée, mais suffisamment réelle pour produire une observation interprétable.
Le manuel peut parfois précéder l’automatisé
Lorsqu’un service nécessite plusieurs opérations en coulisses, certaines peuvent parfois être réalisées manuellement au début.
Cette approche demande davantage d’intervention, mais elle permet d’observer les demandes réelles, les exceptions et les difficultés qui n’auraient pas été anticipées.
Elle aide notamment à distinguer deux questions souvent confondues :
1. Les utilisateurs ont-ils besoin de ce service ?
2. Faut-il automatiser entièrement sa production ?
La première question mérite parfois une réponse avant d’investir lourdement dans la seconde.
Un fonctionnement manuel n’est pas toujours adapté.
Il peut être trop coûteux, impossible à déployer, difficile à sécuriser ou incompatible avec un besoin élevé de rapidité et de fiabilité.
Mais lorsque les risques sont maîtrisables, il peut constituer une étape d’apprentissage utile.
Il permet de découvrir ce qui doit être standardisé, ce qui doit rester flexible et ce qui n’apporte finalement aucune valeur.
Le principe n’est pas de défendre le manuel contre l’automatisé.
Il consiste à éviter d’automatiser un fonctionnement encore mal compris.
Construire moins peut être plus exigeant
Une petite solution n’est pas forcément plus facile à concevoir.
Elle impose souvent des choix que les grands projets peuvent repousser :
- quel problème traiter en premier ;
- pour quel utilisateur ;
- dans quelle situation ;
- avec quel résultat attendu ;
- quelles limites accepter temporairement ;
- quelle hypothèse tester avant les autres.
Un grand périmètre peut donner l’impression de préserver toutes les options.
Il peut aussi rendre les désaccords moins visibles.
Les utilisateurs peuvent attendre une chose, les équipes opérationnelles une autre et les décideurs une troisième.
Une solution restreinte oblige à expliciter la priorité retenue.
Cette contrainte améliore parfois la qualité du raisonnement.
Elle sépare ce qui est indispensable de ce qui est seulement souhaitable.
Elle permet également de repérer plus tôt les divergences sur la définition du problème, les critères de réussite et les responsabilités.
La petite taille du projet ne garantit donc pas sa pertinence.
Elle crée plutôt un cadre dans lequel les choix doivent être formulés plus clairement.
La taille du projet doit être proportionnée au niveau de certitude
Il ne faut pas transformer la préférence pour les petites solutions en nouvelle règle simpliste.
Certaines situations justifient une construction importante dès le départ.
Une infrastructure critique, une obligation réglementaire, une exigence de sécurité ou une forte interdépendance technique peuvent rendre une approche progressive difficile ou peu pertinente.
La bonne question est plutôt la suivante : le niveau d’investissement est-il proportionné à ce qui est déjà établi ?
Un projet de grande ampleur peut être cohérent lorsque :
- le besoin est solidement documenté ;
- les utilisateurs sont clairement identifiés ;
- les contraintes techniques et réglementaires sont connues ;
- les dépendances rendent une solution provisoire peu utile ;
- le coût d’une étape intermédiaire serait supérieur à celui d’une construction complète ;
- le risque de ne pas agir est élevé et bien caractérisé.
À l’inverse, un projet mérite probablement d’être réduit lorsque son périmètre repose surtout sur des suppositions, lorsque ses critères de réussite sont flous ou lorsque personne ne sait précisément quelle observation permettrait de décider de la suite.
Le problème n’est donc pas la grandeur en elle-même.
C’est l’écart entre la complexité engagée et le niveau de certitude disponible.
Une expérimentation utile doit pouvoir changer la décision
Une expérimentation n’a de valeur que si ses résultats peuvent modifier la suite du projet.
Avant de commencer, il est utile de définir les décisions possibles :
- poursuivre dans la même direction ;
- élargir le périmètre ;
- modifier la solution ;
- changer de public ;
- traiter un autre problème ;
- suspendre le projet ;
- l’abandonner.
Cette dernière possibilité est importante.
Si une expérimentation ne peut aboutir qu’à une poursuite, elle sert moins à apprendre qu’à justifier une décision déjà prise.
Il n’est pas nécessaire de fixer un seuil chiffré dans tous les cas.
En revanche, l’équipe doit savoir quelle observation serait suffisamment significative pour remettre en cause l’hypothèse de départ.
Sans ce cadre, les retours risquent d’être interprétés de manière opportuniste : un signal positif devient une confirmation, un signal faible est minimisé et un échec est attribué uniquement à l’exécution.
Préparer à l’avance les décisions possibles ne rend pas le projet plus pessimiste.
Cela protège la valeur de l’apprentissage.
Un signal positif ne constitue pas toujours une validation solide
Une personne peut apprécier une idée sans l’utiliser.
Elle peut utiliser une solution une fois sans y trouver suffisamment de valeur pour changer durablement ses habitudes.
Elle peut aussi déclarer qu’un problème est important sans accepter le temps, le coût ou les contraintes nécessaires à sa résolution.
Il faut donc distinguer plusieurs niveaux :
- l’intérêt exprimé ;
- l’intention d’utiliser ;
- l’utilisation effective ;
- la répétition de l’usage ;
- la valeur obtenue ;
- l’intégration dans un fonctionnement réel.
Aucun de ces signaux n’est inutile, mais ils ne répondent pas à la même question.
Un entretien peut renseigner sur la perception d’un problème.
Une observation en situation peut éclairer les pratiques réelles.
Une expérimentation dans la durée peut aider à évaluer la répétition de l’usage.
Une analyse opérationnelle peut révéler les coûts et les contraintes invisibles dans un prototype.
Cette distinction évite de confondre enthousiasme initial et validation solide.
Elle permet aussi de ne pas demander à une petite solution de prouver davantage qu’elle ne le peut.
Le bon critère : la prochaine incertitude critique
La question « Quelle est la plus petite version du produit ? » n’est pas toujours la plus pertinente.
Il peut être plus utile de demander : « Quelle est l’incertitude qui menace le plus le projet, et quelle est la plus petite solution capable de la réduire ? »
Si le doute porte sur le besoin, il faudra peut-être observer les pratiques existantes.
S’il porte sur la compréhension de la proposition, un prototype ou une simulation pourra suffire.
S’il porte sur l’usage récurrent, il faudra observer la solution dans la durée.
S’il porte sur la faisabilité opérationnelle, une expérimentation en conditions réelles sera probablement nécessaire.
S’il porte sur la viabilité économique, l’intérêt déclaré ne constituera pas une preuve suffisante.
Cette manière de raisonner évite de transformer la petite solution en recette universelle.
Elle la replace dans une démarche de décision : réduire l’incertitude la plus importante avant d’ajouter de la complexité.
Ce qu’il faut retenir
Construire une petite solution utile ne signifie pas renoncer à l’ambition.
Cela signifie éviter d’investir pleinement dans des hypothèses qui n’ont pas encore été suffisamment examinées.
Une solution réduite peut permettre de :
- rendre un problème concret ;
- observer les comportements plutôt que les seules intentions ;
- détecter plus tôt les erreurs de compréhension ;
- apprendre avant d’automatiser ;
- limiter le coût des changements de direction ;
- décider à partir d’éléments réels.
Cette approche n’a toutefois de sens que si la solution reste suffisamment utile, si les résultats sont interprétés avec prudence et si l’expérimentation peut conduire à plusieurs décisions, y compris celle de modifier ou d’arrêter le projet.
La question n’est donc pas de construire le plus petit projet possible.
Elle est d’obtenir le meilleur apprentissage possible avant de rendre le projet plus grand.
Commencer petit ne réduit pas nécessairement la vision.
Cela peut simplement éviter de confondre une ambition légitime avec une promesse déjà considérée comme acquise.
Avant d’élargir un projet, identifiez l’hypothèse qui menace le plus sa réussite.
Cherchez ensuite la plus petite expérience capable de la confronter au réel, puis définissez à l’avance les décisions que ses résultats pourront réellement modifier.
