Validation des idées d'application : ce qu'une entreprise doit décider avant d'investir

La plupart des applications d'entreprise n'échouent pas à cause d'un mauvais code. Cela échoue parce que personne n’a validé, avant de signer le contrat, si le produit résolvait un problème pour lequel quelqu’un était prêt à payer.

J’ai vu ce scénario se répéter dans des entreprises de tailles très différentes. Un directeur apporte une idée convaincante, l'équipe crée un périmètre, le domaine technologique estime les délais et les coûts et le budget est approuvé. Six mois plus tard, il existe une belle application fonctionnelle, dans les délais prévus, et presque personne ne l'utilise. Le projet a été un succès dans l'exécution et un échec dans le produit.

Ce texte est pour ceux qui décident. Si vous approuvez un budget, exigez des résultats ou comptabilisez la facture en fin de trimestre, la validation d'idée n'est pas une formalité technique que l'équipe produit résout seule. Il s’agit d’une décision d’allocation de capital, et elle mérite la même rigueur que celle que vous appliqueriez à tout autre investissement pertinent.

Pourquoi la validation est une décision financière, pas un détail de produit

La création de logiciels coûte cher, mais le coût de leur création constitue rarement le risque le plus important. Le plus grand risque est le coût d’opportunité : chaque équipe affectée à une application dont personne ne veut est une équipe qui ne résout pas un autre problème réel de l’entreprise.

Lorsqu’une organisation décide d’investir dans une application sans valider l’idée, elle fait un pari. Les paris font partie de toute entreprise. Le problème est de parier gros sans aucune preuve, alors qu’il serait possible de parier bas d’abord, d’acheter des informations bon marché et ensuite seulement de décider si cela vaut la peine de parier gros.

La validation, vue sous cet angle, est une gestion des risques. Vous dépensez peu pour savoir si le problème existe, si le public s’en soucie et si le modèle ferme ses portes, avant d’engager l’intégralité du budget. C'est la différence entre tester la température de l'eau et plonger tête première.

La thèse : l'entreprise doit acheter des preuves avant d'acheter un produit

Ma position est simple. Avant d’approuver la construction d’une application, l’entreprise doit exiger la preuve de trois choses : que le problème est réel et pertinent, qu’il existe un public disposé à changer de comportement et qu’il existe un chemin plausible pour revenir.

Aucune de ces trois réponses ne nécessite de créer l’intégralité de l’application. Il est possible de répondre à toutes ces questions avec un petit investissement et un court laps de temps. Quiconque inverse cet ordre, construit d’abord, découvre plus tard, sous-traite au marché une question à laquelle il aurait pu répondre au bureau, pour une fraction du coût.

Cela ne signifie pas bloquer l’innovation par la bureaucratie. Cela signifie que l’enthousiasme du promoteur de l’idée doit être confronté à des preuves avant de devenir une ligne budgétaire.

Ce que l'entreprise doit valider avant d'approuver l'investissement

Le problème est réel et vaut de l'argent

La première question n’est pas « l’application est-elle une bonne idée ? », mais « quel problème, de qui, à quelle fréquence et à quel prix ? ». Un problème qui vous dérange justifie rarement un produit. Un problème qui coûte cher, qui arrive fréquemment et qui n'a pas de bonne solution, c'est celui du retour.

Dans une entreprise, cela signifie parler aux personnes confrontées au problème, aux clients, aux opérateurs, aux services internes, avant toute maquette. Si la douleur n’apparaît pas de manière cohérente dans ces conversations, l’application ne la créera pas.

L’erreur courante ici est de valider la solution plutôt que le problème. Demandez « utiliseriez-vous une application qui fait X ? » et presque tout le monde dit oui, par politesse. Demandez : « Comment résolvez-vous ce problème aujourd'hui et combien cela vous coûte ? » et la vérité apparaît.

Il existe un public et il est prêt à changer de comportement

Chaque application nécessite un changement d'habitude de la part de ceux qui l'utilisent. Changer les habitudes est difficile, même lorsque la solution est meilleure. Valider signifie comprendre si la douleur est suffisamment grande pour vaincre l’inertie.

Un test honnête consiste à observer si les gens essaient déjà de résoudre le problème par eux-mêmes, avec des feuilles de calcul, des groupes de messages, des processus manuels improvisés. Cet effort spontané est le signe le plus fiable d’une demande réelle. Là où se trouve la gambiarra, il y a généralement un marché.

Il existe un chemin de retour qui ferme le compte

C’est là que la prise de décision en entreprise diffère de l’enthousiasme. Une application peut résoudre un problème réel sans toutefois avoir de sens financier. La validation doit estimer, même de manière grossière, le retour sur investissement : nouveaux revenus, réduction des coûts, fidélisation de la clientèle, efficacité interne.

Si personne autour de la table ne peut expliquer comment l'application paie sa propre facture dans un délai raisonnable, ce n'est pas un détail à résoudre plus tard. C'est une raison pour ne pas encore l'approuver.

Comment valider avec peu d'argent et un délai court

La validation est bon marché par rapport à la construction. Des entretiens avec de vrais clients, une page de capture pour évaluer l'intérêt, un prototype navigable sans code derrière, un pilote manuel où l'équipe explique en coulisses ce que l'application ferait, toutes ces tactiques génèrent des preuves à un coût marginal.

Le but n’est pas de prouver que l’idée est bonne. Il essaie de le réduire avec le moins de dépenses possible. Une idée qui survit à des tentatives honnêtes d’invalidation est une idée dans laquelle il vaut la peine d’investir. Les équipes qui valident pour confirmer ce qu’elles voulaient déjà entendre ne valident pas, elles recueillent des applaudissements.

Un petit projet pilote, avec un groupe limité d'utilisateurs réels, donne souvent lieu à plus de mois de discussions internes. C'est aussi là que l'entreprise découvre des coûts cachés : intégration avec les systèmes existants, support, formation, maintenance, éléments qui apparaissent rarement dans le devis initial et qui pèsent sur le budget réel.

Les risques que la validation n'élimine pas, mais rend visibles

La validation réduit le risque, et non le réduit à zéro. Cela vaut la peine d'être honnête sur les limites.

Le premier risque est de valider de manière convaincante le mauvais problème. Un sponsor influent peut guider la conversation vers la réponse que vous souhaitez. C'est pourquoi la validation a besoin d'indépendance : celui qui collecte les preuves ne peut pas être celui qui a le plus envie d'entendre « oui ».

La seconde est une fausse précision. La recherche avec de jolis chiffres donne un sentiment de certitude, mais les décisions en matière de produits sont basées davantage sur des signaux qualitatifs cohérents que sur des mesures initialement gonflées. Soyez prudent avec les diapositives pleines de pourcentages qui ne résistent pas à une question.

Le troisième est culturel. Dans les organisations où remettre en question les idées du patron est risqué, la validation devient un théâtre. L’équipe fait semblant de tester, tout le monde fait semblant de croire, et le véritable apprentissage n’arrive que lorsque le produit est déjà sur le marché et que l’argent est dépensé. La validation ne fonctionne que lorsque l'entreprise accepte d'entendre un « non » dès le début, y compris de la part de ceux qui ont proposé l'idée.

Il y a aussi la question des données et de la conformité. Si l'application collecte des informations auprès des clients ou des citoyens, LGPD entre dans le compte dès la validation, et non comme un tampon à la fin. Découvrir tardivement que le modèle de données est juridiquement irréalisable est coûteux et évitable.

Valider, c'est protéger la concentration, pas retarder l'innovation

L’objection la plus courante à la validation est que cela prend du temps. Dans la pratique, ce qui retarde vraiment l’innovation, c’est de construire une mauvaise chose et de devoir recommencer. Une validation bien faite est le moyen le plus rapide de réaliser le bon investissement, car elle élimine les paris précoces qui coûteraient cher et ne rapporteraient pas grand-chose.

La question qu'un dirigeant devrait se poser avant d'approuver le budget d'une application n'est pas « combien coûte la construction ? » La question est : « Que devons-nous savoir pour être sûrs que cela vaut la peine d'être construit, et quel est le moyen le moins cher de le savoir ? » Quiconque apprend à poser cette question arrête de financer des produits orphelins et commence à financer des paris avec des preuves.

Si votre entreprise est sur le point d'investir dans une application et que la conversation a commencé par la portée technique plutôt que par le problème commercial, cela vaut peut-être la peine de faire une pause et de valider d'abord. J'ai d'autres textes sur le blog sur les feuilles de route de validation et de construction de produits, et je suis disponible pour échanger des idées avec n'importe qui à ce point de décision.