J’ai construit du logiciel pendant vingt ans. J’ai livré des projets, fait des sprint plannings, configuré des pipelines, écrit des spécifications, débattu d’architectures. Le logiciel est ma vie professionnelle.
Et c’est de cette position, pas de celle du critique externe ou du commentateur du lundi matin, que je vous dis ce que notre industrie refuse d’entendre : la plupart du logiciel qui existe ne devrait pas exister.
Pas parce qu’il est mal fait. Une partie l’est, oui, mais ce n’est pas le sujet. Il ne devrait pas exister parce qu’il ne résout aucun problème. Ou en résout un que personne n’a. Ou en résout un déjà résolu, et plus mal. Ou, cas le plus fréquent et le plus insidieux, il crée le problème qu’il prétend ensuite résoudre.
Le cimetière des problèmes inventés
Ouvre ton téléphone. Compte les apps. Combien utilises-tu vraiment ? Combien résolvent un problème réel dans ta vie ? Et combien existent parce que quelqu’un a monté un pitch deck convaincant, levé un round, construit ce que personne n’avait demandé ?
Phénomène pas marginal. Modèle dominant des quinze dernières années.
Le cycle : on identifie un « pain point » (presque toujours une gêne mineure élevée en tragédie existentielle), on construit un MVP, on lève des fonds, on recrute des devs, on scale. À un moment le logiciel existe, a des utilisateurs, génère du revenu. Mais personne ne s’est arrêté pour se demander si le monde en avait besoin. La question était hors-sujet. La question pertinente : ça croît ?
J’ai vu des apps pour partager des listes de courses entre colocs. Des plateformes de prise de RDV chez le coiffeur avec IA. Du SaaS pour gérer ses plantes d’appartement. Des marketplaces pour échanger des vêtements usagés pour chien. Je n’invente pas. Chacun a reçu des financements, eu une équipe de devs, consommé des serveurs, de l’énergie, du temps humain.
Le problème n’était pas qu’ils étaient laids. Certains étaient techniquement impeccables. Le problème : ils n’avaient pas de raison d’exister. Et personne ne le disait, parce que dire ça, c’était être celui qui « ne comprend pas l’innovation ».
L’impôt caché
Le logiciel n’est jamais gratuit. Même quand il ne coûte rien à l’utilisateur, il coûte au monde.
Énergie. Chaque app inutile tourne sur des serveurs qui consomment de l’électricité. Chaque SaaS inutile a une base répliquée sur trois zones, du monitoring, un CDN global. Le cloud n’est pas un nuage : un hangar plein de machines qui chauffent, en Irlande ou en Virginie, sur un réseau électrique aux limites physiques.
Attention. Chaque logiciel inutile installé sur un téléphone rivalise avec tout le reste pour cette attention : le travail, les relations, le sommeil, l’ennui productif, la pensée non structurée. Et l’attention est finie. Chaque app inutile la vole à plus important.
Complexité. Chaque logiciel ajoute une interface, un login, un mot de passe, encore des notifications, encore des CGU que personne ne lit, encore un flux de données personnelles parti on ne sait où. La complexité de notre environnement numérique grossit chaque année — pas parce que les problèmes se multiplient, mais parce que les solutions se multiplient plus vite que les problèmes.
Talent. Le coût qui me met le plus en colère. Il y a dans le monde des devs au talent extraordinaire qui passent leurs journées à optimiser le funnel d’une app pour commander du café avec trois taps en moins. Des gens qui pourraient construire du logiciel qui sauve des vies, rend l’éducation accessible, améliore la santé publique. Ils optimisent la couleur d’un bouton « Acheter ».
Pas leur faute. Le marché paie mieux le bouton. Mais c’est un gaspillage si obscène qu’il faudrait avoir la décence de le nommer.
« Mais le marché décide »
L’objection. Si un logiciel existe et a des utilisateurs, le marché a décidé qu’il sert. La main invisible, l’offre, la demande, etc.
Sauf que faux. Le marché du logiciel ne fonctionne pas comme celui des pommes.
Premier : le coût marginal de distribution est près de zéro. Un logiciel touche des millions d’utilisateurs sans que la qualité ou la nécessité ne soient testées par un vrai feedback. Un primeur qui vend des pommes pourries fait faillite en une semaine. Une app qui ne résout rien peut survivre des années, financée par le VC, jusqu’au prochain round ou à l’acquéreur.
Deuxième : le modèle pub a découplé valeur et prix. Quand l’utilisateur ne paie pas, le produit n’a pas besoin d’être utile pour lui. Il doit être utile à l’annonceur. Et pour l’annonceur, c’est l’attention qui compte, pas la satisfaction. Des logiciels qui rendent les gens malheureux mais collés à l’écran sont d’énormes succès commerciaux. Le marché « a décidé » qu’ils servent. Mais ce marché-là est malade.
Troisième : les network effects créent des monopoles naturels. Une fois que tout le monde utilise une plateforme, tu ne peux pas ne pas l’utiliser. Pas parce qu’elle est bonne, parce que tout le monde y est. Le marché n’a pas « décidé » que WhatsApp est le meilleur moyen de communiquer. Il a décidé que c’est le moyen par lequel tout le monde communique — chose toute différente.
L’acte radical de ne pas construire
Dans la culture tech, construire est toujours positif. « Makers gonna make. » « Ship it. » « Build in public. » Le verbe construire a une aura sacrée, et qui construit est par définition du bon côté de l’histoire.
Mais il y a un acte plus courageux : décider de ne pas construire.
Décider que le monde n’a pas besoin d’un nouveau task manager. Qu’un Excel fait mieux que ton app. Que le problème n’est pas un problème. Que ton talent et ton temps sont mieux ailleurs.
Les meilleurs techs que j’ai connus étaient ceux capables de dire « pas besoin ». Pas par paresse, pas par cynisme. Par respect. Pour le problème, l’utilisateur, la complexité du réel. Ils savaient qu’ajouter du logiciel à un contexte ajoute de la complexité, des dépendances, de la maintenance, de la dette technique. Et que le faire sans raison forte est un acte d’irresponsabilité déguisé en productivité.
La philosophie Unix le disait il y a quarante ans : fais une seule chose, et fais-la bien. Pas « fais tout ». Pas « fais des trucs nouveaux parce que tu peux ». Une seule chose. Le reste, laisse-le.
Le logiciel qui devrait exister
Je ne dis pas que le logiciel est l’ennemi. Ce serait dire que l’écriture est l’ennemi parce qu’il existe de mauvais livres.
Le logiciel qui devrait exister est celui qui élargit les capacités humaines sans créer de dépendance. Qui résout un problème réel et vérifiable. Qui marche pour qui l’utilise, pas pour qui le vend. Qu’on peut arrêter d’utiliser sans conséquence. Qui n’a pas besoin de te capturer pour justifier son existence.
Le logiciel qui devrait exister est celui dont on remarquerait l’absence s’il disparaissait demain. Pas l’absence compulsive du toxico, mais l’absence concrète de qui a perdu un outil utile. Comme perdre un bon couteau de cuisine. Comme perdre un vélo fiable.
C’est la métrique à utiliser : s’il disparaît, le sentirais-tu ? Si la réponse est « probablement non », il ne devrait pas exister. Si la réponse est « je ne saurais même pas qu’il est parti », ce logiciel gaspille les ressources de la planète et le temps de qui l’a construit.
La responsabilité de qui construit
À chaque décision de construire, on prend une décision sur des ressources réelles. Temps de devs. Énergie des serveurs. Attention des utilisateurs. Complexité de l’écosystème numérique. Dans un monde aux ressources finies et aux problèmes énormes, construire de l’inutile n’est pas neutre. C’est du gaspillage actif. Une mauvaise allocation d’intelligence humaine.
L’ingénieur civil doit justifier l’utilité d’un pont. L’architecte doit prouver qu’un bâtiment répond à un besoin. Le médecin ne prescrit pas un médicament parce qu’il existe. Pourquoi le logiciel devrait-il être différent ? Pourquoi accepterions-nous que 90 % de ce que nous construisons finisse oublié dans un App Store, ignoré par ses créateurs après six mois, abandonné avec les données des utilisateurs dedans et les serveurs encore allumés ?
La vraie innovation, en 2026, n’est pas de construire plus. C’est de construire moins, mieux, pour de meilleures raisons.
Et avoir le courage de dire, parfois, « non, ça on ne le fait pas ». Pas parce qu’on ne peut pas. Parce que ça ne sert pas.
Le luxe de la soustraction
Il y a un concept en architecture que le monde du software n’a jamais appris : la valeur du vide.
Un bon architecte ne remplit pas chaque mètre carré. Il sait que l’espace vide n’est pas une absence. C’est de la respiration. De la possibilité. La place qu’il faut à qui habite pour bouger, penser, vivre. Un bâtiment plein jusqu’au dernier centimètre n’est pas un chef-d’œuvre d’efficacité. C’est une prison.
Notre paysage numérique est un bâtiment plein jusqu’au dernier centimètre. Chaque espace est occupé par une app, un service, une plateforme, une notification. Pas de respiration. Pas de vide. Pas de silence.
Et au milieu de tout ce bruit, le logiciel vraiment utile, celui qui résout les vrais problèmes, se perd. Devient invisible. Pas parce qu’il est moins bon, mais parce qu’il est submergé sous des tonnes de logiciel qui ne devrait pas exister.
La soustraction est un acte créatif. Choisir de ne pas construire est une décision de design. Et dans une industrie qui ne sait pas dire non à rien, c’est peut-être la compétence la plus rare et la plus précieuse.
Le meilleur logiciel que j’aie jamais écrit est celui que j’ai décidé de ne pas écrire.
Ce qu'il faut retenir
S’il disparaît demain et personne ne le remarque, il ne devrait pas exister — c’est la seule métrique honnête.
Le venture capital a remplacé « le monde en a besoin » par « ça croît » : quinze ans de talent ingénierique gaspillés en aval du pitch deck.
« Le marché décide » est faux quand la distribution coûte zéro, l’attention est le produit et les network effects font de l’habitude un monopole.
Chaque app inutile externalise des coûts : énergie des serveurs, attention des gens, bande cognitive, devs qui auraient pu construire ailleurs.
La soustraction est un acte créatif. Ne pas construire est une décision de design — et dans une industrie qui ne sait pas dire non, peut-être la compétence la plus rare qu’il reste.
Questions & réponses
Comment distinguer un logiciel qui résout un vrai problème d'un logiciel qui l'invente ?
Le premier : s’il disparaît, quelqu’un le remarque vraiment — une activité reste inachevée, un travail devient impossible. Le second : s’il disparaît, on se débarrasse d’une app dont on ignorait ne pas avoir besoin. Si demain disparaissaient toutes les apps de gestion des plantes d’appartement, aucune plante ne mourrait : les gens se remettraient à arroser sans rappel hebdomadaire.
Pourquoi le modèle VC a-t-il produit autant de logiciel inutile ?
Parce que l’objectif déclaré (« résoudre des problèmes ») a été remplacé par l’objectif opérationnel (« croître »). Le pitch deck convainc avec TAM, MVP, funnel. Aucun moment du processus ne demande sérieusement : le monde en a vraiment besoin ? Résultat : 15 ans de compétence ingénierique appliquée à des fondations conceptuelles souvent nulles.
Quel est le mal si une app existe, a des utilisateurs et génère du revenu ?
Le coût externalisé. Chaque app marginale consomme de l’attention humaine, de l’électricité, de la capacité de calcul, du temps de devs qui pourraient travailler à quelque chose d’utile, de l’espace cognitif. Multipliez ces petites érosions par des millions d’apps et le total est une économie de l’attention et de l’environnement gravement compromise. Pas par méchanceté — par inertie de modèle.
Cet article est-il anti-tech ?
Non. Il est écrit par quelqu’un qui fait du logiciel depuis vingt ans, de l’intérieur, pas un critique externe. La proposition est opérationnelle : avant d’écrire du code, trois questions honnêtes — un problème existe-t-il vraiment, était-il déjà résolu, ma solution le résout-elle mieux ou moins bien. Si la troisième réponse est « moins bien », ne le construis pas. Pas un manifeste, une invitation à retrouver le sens de ce qu’on construit.
L'auteur
