La séduction de la technologie disponible
Quand une capacité nouvelle apparaît — le GPS dans les téléphones hier, les modèles de langage aujourd'hui — une cohorte de fondateurs se demande aussitôt : « qu'est-ce que je peux construire avec ça ? » La question paraît saine. Elle est l'exacte inversion de celle qui produit des entreprises viables.
Une technologie disponible exerce une attraction propre. Elle est nouvelle, impressionnante, elle donne le sentiment d'être en avance. Bâtir avec elle procure une satisfaction immédiate — on touche à l'état de l'art. Cette satisfaction est le piège : elle se confond avec la certitude de faire quelque chose d'utile. Levels prend l'exemple des applications qui ont déferlé quand les smartphones ont intégré le GPS : des dizaines d'apps pour localiser ses amis en temps réel. La technologie rendait la chose possible, donc on la faisait. Mais le problème n'existait pas — et la plupart de ces apps sont mortes.
Color : 41 M$ levés avant lancement, 1 M de téléchargements, moins de 100 000 utilisateurs actifs six mois plus tard, note 2/5, fermeture fin 2012. La technologie marchait. Le besoin, non.
La même capacité, montée à l'endroit
Le contraste éclaire tout. Le même GPS, dans les mêmes téléphones, a donné Uber. La différence n'est pas technique — c'est l'ordre des facteurs. Uber ne part pas de « on a du GPS, qu'en faire ? » mais d'un problème ancien et douloureux : trouver une voiture quand on en a besoin, sans savoir où elle est ni quand elle arrive. Le GPS n'est plus le point de départ, il est l'outil qui résout un problème préexistant.
Google lui-même a buté sur la nuance. Google Latitude, son service de partage de position lancé en 2009, a été fermé en 2013 faute d'adoption — arrivé avant que le besoin et les usages ne soient là. La même fonction, réintégrée à Google Maps des années plus tard une fois le comportement mûr, a trouvé sa place. Ni la technologie ni l'entreprise n'étaient en cause : seul l'ordre — solution avant problème — condamnait le produit.
Ce que ça indique — Une technologie ne crée pas de valeur par elle-même ; elle en crée en réduisant la friction d'un problème que des gens avaient déjà. La capacité doit arriver après le problème, jamais avant.
Pourquoi l'erreur est invisible de l'intérieur
Ce qui rend ce piège redoutable, c'est qu'il ne ressemble pas à une erreur pendant qu'on le commet. Partir de la solution produit un objet réel : un prototype qui fonctionne, une démo qui impressionne, une équipe qui avance, parfois des dizaines de millions levés. Tous les signaux internes sont au vert. Le seul signal manquant est externe — et il ne manque que plus tard, quand le produit lancé ne rencontre personne.
La solution en quête de problème est l'exact opposé du critère de réalité : elle accumule des preuves de construction là où il faudrait des preuves d'usage. Elle répond brillamment à « est-ce que ça marche techniquement ? » et jamais à « est-ce que quelqu'un en a besoin ? ». Or seule la seconde question décide — et c'est celle que 42 % des startups mortes n'ont pas su résoudre, l'absence de besoin marché restant la première cause d'échec recensée.
Partir de la solution coche toutes les cases internes — prototype, démo, financement — et rate la seule externe : le besoin. On peut brûler 41 millions sans jamais s'en apercevoir.
Pourquoi 2026 aggrave le piège au lieu de l'atténuer
Quand bâtir était cher et long, la difficulté filtrait une partie des solutions inutiles : on réfléchissait à deux fois avant d'investir un an. Ce filtre a sauté. Un prototype se sort désormais en quelques heures, sans savoir coder. Plus rien ne freine la production de réponses à des questions que personne ne pose.
Le résultat est déjà visible : des marchés saturés d'outils techniquement compétents et fonctionnellement orphelins, où « propulsé par l'IA » est devenu un bruit de fond plutôt qu'une promesse. L'effondrement du coût de construction ne récompense pas ceux qui construisent le plus vite — il punit ceux qui construisent sans problème, plus vite qu'avant.
Ce que ça indique — Plus construire est facile, plus le piège de la solution sans problème est facile à tomber dedans. La discipline du problème d'abord devient un avantage rare précisément parce que la construction ne l'est plus.
Ce que ça change dans la première question
La discipline tient dans l'inversion d'une seule question de départ. Non pas « que puis-je faire avec cette technologie ? » mais « quel problème documenté mérite d'être résolu — et cette technologie est-elle le meilleur moyen de le résoudre ? ».
Cette formulation a une conséquence désagréable pour l'enthousiaste : elle autorise la réponse « aucun ». Il est parfaitement possible qu'une technologie nouvelle ne soit, pour un fondateur donné, la bonne réponse à aucun problème qu'il connaît vraiment. L'admettre n'est pas un manque d'audace — c'est refuser de construire une solution que le réel n'a pas demandée.
Le problème d'abord. La technologie ensuite, et seulement si elle est le meilleur moyen. L'ordre inverse produit des objets admirables dont l'unique défaut est de n'être attendus par personne — et parfois, une montagne jetée à la figure d'un marché qui n'en voulait pas.
Sources
- Color Labs : 41 M$ levés (25 M$ Sequoia, 9 M$ Bain, 7 M$ dette SVB), lancement 24 mars 2011, chute à < 100 000 utilisateurs actifs en septembre 2011, fermeture le 31 décembre 2012, acqui-hire Apple ~7 M$ — Fast Company, Wikipedia.
- Google Latitude : lancement 5 février 2009, fermeture le 9 août 2013 — Wikipedia.
- CB Insights, The Top 20 Reasons Startups Fail — 42 % « no market need ». PDF CB Insights.
- Pieter Levels, MAKE : The Indie Startup Manual — readmake.com (chapitre Idea, section Always start from the problem, not the solution).
- Sur l'usage externe comme seul critère de réalité : voir la ressource La preuve qu'un projet existe.