Se rendre au contenu

Commencer par le problème, pas par la solution

21 septembre 2026 par
Commencer par le problème, pas par la solution
YDC

 

Une bonne idée ne suffit pas : comment savoir ce qu’il faut réellement construire ?

Une idée peut être brillante, élégante, originale… et parfaitement inutile. 

Elle peut même arriver avec un nom provisoire, un logo et une présentation soignée avant d’avoir répondu à la question la plus importante : quel problème résout-elle, pour qui et dans quelle situation ? Avant de développer un produit, un service ou une fonctionnalité, il faut donc vérifier que l’on ne s’apprête pas à fabriquer une réponse à une question que personne ne se pose. 

La bonne démarche consiste à partir du problème, à identifier les incertitudes et à construire uniquement ce qui permet d’apprendre quelque chose d’utile.


Commencer par le problème, pas par la solution

Une idée se présente souvent sous la forme d’une solution : une application, une plateforme, un service, un objet, une automatisation ou une nouvelle fonctionnalité. 

Cette formulation donne immédiatement l’impression qu’il faut construire quelque chose. Pourtant, elle ne dit pas encore si le besoin est réel.

Il est plus utile de reformuler l’idée à partir de la situation rencontrée : qui rencontre quel problème, à quel moment et avec quelles conséquences ?

Dire qu’il faudrait « une plateforme pour aider les indépendants à mieux s’organiser » reste vague. 

Dire que certains indépendants perdent régulièrement du temps parce que leurs outils ne communiquent pas entre eux décrit déjà une situation concrète. 

La réponse ne sera peut-être pas une plateforme. 

Ce sera peut-être une intégration, une méthode, un service d’accompagnement ou une meilleure configuration d’outils existants.

Une idée solide doit donc pouvoir survivre à la remise en question de sa première forme. 

Si elle ne fonctionne qu’à condition de conserver exactement la solution imaginée au départ, elle est peut-être davantage attachée à son apparence qu’au problème qu’elle prétend résoudre.


Distinguer le problème réel du problème supposé

Un problème supposé est une difficulté que l’on imagine à la place des personnes concernées. 

Un problème réel se manifeste généralement dans leurs comportements, leurs arbitrages ou leurs renoncements.

Quelqu’un peut déclarer qu’une situation est pénible sans chercher à la résoudre.

Cela signifie peut-être que le problème est secondaire. 

À l’inverse, une personne peut ne pas formuler clairement sa difficulté, tout en consacrant du temps, de l’argent ou de l’énergie à la contourner.

Pour comprendre la situation, il faut observer plusieurs éléments :

- Que font réellement les personnes aujourd’hui ?

- Comment se débrouillent-elles sans la solution imaginée ?

- Qu’utilisent-elles à la place ?

- À quel moment le problème apparaît-il ?

- Que se passe-t-il lorsqu’elles ne le résolvent pas ?

- Ont-elles déjà essayé quelque chose ?

- Qu’est-ce qui les empêche de changer leurs habitudes ?

Cette observation permet de distinguer les déclarations générales des comportements significatifs. « C’est intéressant » signifie généralement que l’idée est intéressante. 

Cela ne signifie pas forcément : « Je vais l’utiliser », « Je vais modifier mes habitudes » ou « Je suis prêt à payer pour cela ».

L’enthousiasme est agréable. Il ne remplace pas une preuve.


 

Évaluer si le problème mérite vraiment d’être traité

Tous les problèmes ne justifient pas la construction d’une solution. 

Certains sont trop rares, d’autres trop peu importants, et certains sont gênants sans être suffisamment prioritaires pour déclencher une action.

Avant de construire, plusieurs critères permettent de mieux apprécier la situation.

La fréquence

Le problème se produit-il chaque jour, chaque semaine ou une fois tous les trois ans, généralement un mardi après-midi ? 

Un besoin occasionnel peut être pertinent, mais il ne se traite pas de la même manière qu’une difficulté récurrente.

L’intensité

Le problème provoque-t-il une simple irritation ou une véritable perte de temps, d’argent, d’opportunités ou de sérénité ? 

Une amélioration marginale ne déclenche pas les mêmes décisions qu’un problème qui bloque une activité.

L’urgence

Les personnes cherchent-elles une réponse maintenant, ou repoussent-elles le sujet indéfiniment ? 

Un problème important mais constamment reporté risque de rester dans la catégorie des bonnes résolutions, ce cimetière très fréquenté des projets prometteurs.

Les alternatives existantes

Les personnes disposent-elles déjà d’une solution acceptable ? 

Elle peut être manuelle, imparfaite ou peu élégante. 

Mais si elle fonctionne suffisamment bien, la nouvelle solution devra apporter une amélioration claire pour être adoptée.

Le coût de l’inaction

Que se passe-t-il si rien ne change ? 

Si les conséquences sont faibles, l’ambition du projet devra peut-être être revue. 

Si l’inaction entraîne des pertes importantes ou empêche une action essentielle, le besoin mérite une exploration plus approfondie.


Ne pas confondre demande et préférence

Une personne peut préférer une solution sans en avoir véritablement besoin. 

Elle peut trouver une interface plus agréable, un parcours plus simple ou une fonctionnalité supplémentaire intéressante. 

Mais la préférence ne suffit pas toujours à justifier la création d’un nouveau produit ou service.

La question utile est plutôt : qu’est-ce que cette solution permettrait de faire que l’on ne peut pas faire correctement aujourd’hui ?

Si la réponse est seulement « ce serait plus moderne », « ce serait plus joli » ou « ce serait plus pratique », le projet n’est pas nécessairement inutile. Mais sa valeur doit encore être précisée.

Plus pratique comment ? Pour qui ? Dans quelle situation ? Avec quel gain ? Par rapport à quelle alternative ?

Une amélioration devient plus convaincante lorsqu’elle est observable. Elle peut par exemple :

- réduire une étape ;

- éviter une erreur ;

- accélérer une tâche ;

- rendre une décision plus facile ;

- diminuer une incertitude ;

- permettre une action jusque-là trop compliquée ;

- regrouper des opérations dispersées ;

- rendre accessible un service existant.

La valeur n’a pas besoin d’être spectaculaire. Elle doit surtout être compréhensible et suffisamment importante pour justifier un changement.


 

Identifier les hypothèses cachées

Tout projet repose sur des hypothèses. 

Le risque apparaît lorsque ces hypothèses sont traitées comme des évidences.

On peut supposer que les personnes concernées rencontrent bien le problème, qu’elles le jugent important, qu’elles comprennent la solution, qu’elles sauront l’utiliser, qu’elles changeront leurs habitudes ou qu’elles accepteront son coût. 

On peut aussi supposer que le fonctionnement sera réalisable et que le projet pourra être distribué, maintenu et financé.

Tant qu’une hypothèse n’est pas vérifiée, elle doit rester une hypothèse.

Une formulation simple consiste à écrire : « Nous pensons que… » Puis à compléter la phrase. « Nous pensons que les petites équipes ont besoin d’un outil supplémentaire » n’a pas le même niveau de solidité que « nous avons observé que certaines équipes utilisent déjà plusieurs solutions pour contourner cette difficulté précise ».

Cette méthode ne rend pas l’idée moins intéressante. 

Elle permet simplement de savoir ce qui est établi, ce qui est supposé et ce qu’il faut encore apprendre.


Construire le minimum qui permet d’apprendre

Lorsqu’une idée semble pertinente, la tentation est de développer immédiatement une version complète. 

C’est souvent ainsi qu’un projet se retrouve avec quinze fonctionnalités, trois parcours utilisateurs, une feuille de route sur deux ans et aucun retour concret.

Le premier dispositif doit plutôt être le plus petit possible tout en permettant de répondre à une question importante. Par exemple :

- Les personnes comprennent-elles la proposition ?

- Rencontrent-elles réellement le problème décrit ?

- Acceptent-elles de tester la solution ?

- Sont-elles prêtes à consacrer du temps à son utilisation ?

- Une seule fonctionnalité suffit-elle à créer de la valeur ?

- Le processus peut-il fonctionner manuellement avant d’être automatisé ?

- L’idée répond-elle à un besoin ou seulement à une curiosité ?

Selon le projet, ce premier test peut prendre la forme d’une maquette, d’un exemple concret, d’un service réalisé manuellement, d’une page de présentation, d’un parcours simulé, d’un atelier ou d’un test limité à une seule situation.

L’objectif n’est pas de faire croire que le produit existe déjà. 

Il s’agit d’observer ce qui se passe lorsqu’une personne est confrontée à une proposition suffisamment concrète pour réagir.

Une maquette permet surtout de tester la compréhension. 

Un prototype permet d’examiner un usage. Une demande détaillée, une inscription, une prise de rendez-vous ou une transaction peuvent apporter des informations différentes sur l’engagement. 

Aucun de ces signaux ne répond à toutes les questions à lui seul.

Les travaux consacrés à l’expérimentation entrepreneuriale rappellent que les décisions de poursuite ou d’investissement dépendent précisément de ce que les tests permettent d’apprendre, et pas seulement de l’élégance de l’idée initiale.


Choisir le test en fonction de l’incertitude

Construire n’est pas toujours la meilleure manière de vérifier une idée. 

Le bon test dépend de la question à laquelle on cherche une réponse.

Si l’on veut savoir si le problème existe, il faut d’abord parler de la situation vécue, sans présenter une solution trop séduisante. S

inon, les personnes risquent de réagir à l’idée plutôt qu’à leur expérience réelle.

Si l’on veut vérifier que le parcours est compréhensible, une maquette peut suffire. 

Si l’on veut savoir si le service produit réellement un résultat, il faut tester une expérience complète, même sur un nombre limité de cas. 

Si l’on veut mesurer un engagement, il faut observer une action concrète adaptée au contexte.

La question n’est donc pas seulement : « Que peut-on construire ? » Elle est aussi : « Quelle incertitude doit-on réduire en priorité ? »

Cette approche évite de développer ce que l’on sait déjà faire simplement parce que c’est confortable, au lieu de tester ce que l’on ne sait pas encore.

La qualité d’un test dépend également de sa conception : hypothèse précise, participants pertinents, comportement observé et critère de décision défini à l’avance. 

Un test mal ciblé peut produire beaucoup de réactions tout en apportant peu d’informations fiables. 


 

Savoir quoi ne pas construire

La validation ne sert pas uniquement à confirmer une idée. 

Elle peut aussi éviter de développer une solution qui ne répond pas au bon problème.

Il peut apparaître que le problème est réel mais concerne une autre cible, que la cible est intéressée mais pas prête à changer, que la solution est pertinente mais trop complexe, ou qu’une seule fonctionnalité suffit là où l’on imaginait un produit complet.

Il peut aussi devenir évident qu’une réponse humaine est préférable à un outil, que le moment n’est pas le bon ou que le modèle économique ne tient pas.

Arrêter, réduire ou réorienter n’est pas nécessairement un échec. 

C’est parfois la première décision réellement fondée du projet. 

Une expérimentation utile ne protège pas l’idée initiale contre toute remise en question ; elle aide à trouver une réponse pertinente à une situation donnée.


Adapter l’effort au niveau de certitude

Il n’existe pas une seule bonne manière de construire. 

Le niveau d’effort doit dépendre de ce que l’on sait déjà et de ce qui reste incertain.

Lorsque le problème est encore flou, il faut privilégier l’observation et les échanges. 

Lorsque le problème est clair mais que la solution reste incertaine, il faut tester plusieurs réponses. 

Lorsque l’usage semble pertinent mais que la faisabilité pose question, il faut examiner les contraintes techniques, opérationnelles et économiques.

Lorsque la solution fonctionne dans un cadre limité, il faut encore vérifier si elle peut être reproduite sans perdre sa valeur.

Construire trop tôt peut coûter cher. 

Construire trop tard peut aussi retarder inutilement l’apprentissage. 

Le bon moment n’est pas celui où l’idée semble parfaite. 

C’est celui où un prototype peut apporter une information que la réflexion seule ne permet plus d’obtenir.


Une méthode simple en cinq étapes

Pour passer d’une idée à une décision plus éclairée, on peut utiliser ce cadre :

1. Décrire la situation

Qui rencontre le problème ? Quand ? Dans quelles circonstances ? Que fait cette personne aujourd’hui ?

2. Formuler l’hypothèse

Quel problème pense-t-on résoudre ? Pourquoi estime-t-on qu’il est important ? Qu’est-ce qui n’est pas encore vérifié ?

3. Choisir la preuve utile

Faut-il observer, interroger, simuler, faire tester, réaliser manuellement ou proposer une première transaction ?

4. Construire le minimum nécessaire

Quelle est la plus petite version permettant d’obtenir une réponse fiable à la question prioritaire ?

5. Décider à partir des résultats

Faut-il poursuivre, modifier, réduire, changer de cible, changer de solution ou arrêter ?

Cette dernière étape est essentielle. Un test qui ne mène à aucune décision reste une expérience intéressante, mais il ne fait pas réellement avancer le projet.


Ce qu’il faut retenir

Une bonne idée n’est pas un plan de construction. C’est le début d’une enquête.

Avant de développer une solution complète, il faut comprendre le problème, observer les comportements, identifier les hypothèses et choisir la forme de test adaptée à l’incertitude principale.

Le premier objectif n’est pas de prouver que l’idée est brillante. Il est de savoir si elle répond à une situation réelle, pour des personnes identifiables, avec une valeur suffisamment claire pour justifier un changement.

Parfois, la meilleure chose à construire n’est donc pas le produit imaginé au départ. C’est une version plus simple, plus ciblée, plus concrète — voire une autre réponse entièrement.

Une idée mérite d’être construite lorsqu’elle résiste à la réalité, pas seulement lorsqu’elle fonctionne très bien dans une présentation où personne ne pose de question difficile.


Avant de lancer la construction, prenez quelques minutes pour écrire le problème visé, les hypothèses encore incertaines et le plus petit test capable de les éclairer. Cette étape peut vous faire gagner du temps — ou vous éviter d’en consacrer beaucoup à une idée qui n’a pas encore rencontré la réalité.


 


Partager cet article
Étiquettes

CREEZ DES VIDEOS 

A SUCCES

Vous cherchez à créer des vidéos captivante grâce à l'IA.

Essayer VEHUB.


Pourquoi l’automatisation ne règle pas les problèmes d’une entreprise mal structurée