Ce matin, pendant que je préparais le café, j’ai construit un produit numérique prêt pour la production.
Pas un prototype posé là pour la forme, pas une maquette assortie du « on peaufinera plus tard » implicite. Quelque chose de vivant, avec un domaine, un backend qui tourne, une interface utilisable. Quelque chose qu’un vrai utilisateur peut ouvrir maintenant et utiliser.
J’y ai mis 17 minutes. Je n’ai pas écrit une ligne de code. J’ai parlé à un outil d’IA.
Le résultat est music-map.uk, une application qui répond à une question que vous ne vous êtes peut-être jamais posée : à quoi ressemble ce coin du monde, en musique ?
Et non, ce billet ne parle pas de music-map. Ou plutôt, pas du produit en lui-même. Il parle de ce que cela signifie qu’une telle chose puisse exister comme ça, pendant que l’eau du café est en train de monter.
La distinction qui change tout
Une mise au point s’impose, sinon on a l’impression que je raconte une histoire qui existe déjà depuis des années, juste avec un peu plus d’enthousiasme.
Il existe des outils grand public qui promettent exactement cela : tu ouvres un navigateur, tu décris l’idée, et en quelques clics tu as une app. Lovable, Bubble, Glide, Softr. L’écosystème est immense et grandit en permanence.
Le problème, c’est qu’aujourd’hui il reste un écart assez net entre « j’ai construit quelque chose qui ressemble à une app » et « j’ai construit quelque chose qui tient en production ». Je ne dis pas ça par snobisme, ni comme un jugement sur ces produits. Pour certains usages, ils sont excellents.
C’est une question de substance : robustesse, scalabilité, contrôle sur le code généré, capacité d’intervenir quand quelque chose casse, vraie ownership de l’infrastructure. Cette sensation très concrète de savoir où sont les pièces et ce qui se passe si l’une d’elles cesse de fonctionner.
Moi, j’ai utilisé des outils pensés pour des gens qui savent déjà, d’une manière ou d’une autre, ce qu’ils sont en train de construire. Des outils qui supposent que tu as un contexte technique, que tu sais lire une erreur, que tu peux prendre des décisions d’architecture quand on te les met sous le nez.
Cette différence est encore énorme. Et c’est exactement le point.
Le b2b ne me fait pas peur, pour l’instant
Pendant que je finissais mon café, la question qui plane toujours sur le secteur, même quand on fait semblant de l’ignorer, m’est tombée dessus : est-ce que ça va me prendre mon boulot ?
Côté b2b, la réponse, telle que je la vois aujourd’hui, est non. Du moins, pas dans le sens catastrophique que la narration mainstream affectionne.
Parce que le travail b2b bien fait n’a jamais été « écrire du code ». C’est comprendre le contexte d’un client, traduire des besoins souvent confus en exigences techniques précises, garantir qu’un système tienne sous pression, naviguer dans la compliance et les normes, entretenir des relations de confiance dans la durée.
Au quotidien, chez Oltrematica, j’ai sur la table en même temps une migration de Python vers Laravel 12, des frameworks de conformité au Cyber Resilience Act, des plateformes SBOM pour des clients qui doivent rendre compte de leur logiciel à des organismes publics, et des solutions liées à la Product Liability Directive qui entrera en vigueur en 2026. Ce n’est pas le genre de chose qu’on règle en 17 minutes de conversation.
L’IA a changé comment je fais ce travail. La vitesse sur certaines tâches a augmenté de façon presque embarrassante. Mais la valeur que j’apporte n’était pas dans la frappe du code. Elle était dans le fait de savoir quoi écrire, pourquoi, et surtout quoi éviter.
Cette partie, pour l’instant, n’a pas disparu. Elle s’est peut-être même renforcée, parce qu’elle me laisse plus d’espace pour penser.
Le grand public, c’est une autre histoire
Côté grand public, en revanche, je suis moins serein. Pas parce que les apps disparaissent demain, mais parce que la forme du marché me semble changer.
Si tu prends la courbe d’adoption classique — innovateurs, early adopters, majorité précoce, majorité tardive, retardataires — et que tu te demandes où on en est avec les outils d’IA pour développer du logiciel, il en sort quelque chose d’étrange.
Pour ceux qui développent, on est déjà dans la majorité précoce. Beaucoup les utilisent tous les jours, l’intégration aux workflows est réelle, la productivité se mesure.
Pour un utilisateur non technique, en revanche, on est encore entre innovateurs et tout premiers early adopters. Le seuil technique reste élevé. Pas aussi élevé qu’il y a dix ans, mais assez pour exclure la plupart des gens.
Et ce seuil baisse chaque mois. Pas toujours de façon linéaire. Parfois il y a un saut, parce que quelqu’un trouve une interface qui marche vraiment, ou parce qu’un modèle devient assez capable pour gérer l’ambiguïté du langage naturel sans te forcer à le corriger toutes les deux minutes.
Quand ce seuil descendra assez bas pour qu’une personne ordinaire — qui ne sait pas ce qu’est un serveur et ne veut pas le savoir — le franchisse, le marché grand public du logiciel changera de manière irréversible.
Le vrai « produit » des apps grand public
Je vais essayer de le dire simplement.
Pendant les quinze dernières années, une app grand public a fonctionné comme ça : quelqu’un avait une idée, et seules les personnes qui avaient les compétences techniques — ou l’argent pour les acheter — réussissaient à la transformer en produit. Ensuite, ce produit était distribué et utilisé par d’autres.
La valeur était dans l’exécution, oui. Mais en dessous, il y avait autre chose : la distance.
La distance entre avoir une intention et pouvoir l’utiliser.
Cet écart, entre « je voudrais » et « je peux », a été le marché. Les apps grand public existaient parce qu’il y avait une barrière technologique entre celui qui savait construire et celui qui voulait utiliser.
Si cette distance s’annule — si n’importe qui peut décrire ce qu’il veut et recevoir en retour un logiciel fonctionnel calibré sur ses besoins — que reste-t-il du modèle classique ?
Je ne dis pas que les apps disparaissent demain. Je dis que le mécanisme qui a soutenu une part énorme du grand public pourrait cesser de fonctionner plus vite que prévu.
Le logiciel sur mesure va-t-il devenir la norme ?
Une idée me trotte dans la tête depuis quelques mois. Elle me semble radicale, mais peut-être seulement parce qu’on est habitués à l’inverse.
Dans le monde physique, la production de masse a du sens parce que la personnalisation coûte cher. Une chaise sur mesure coûte beaucoup plus qu’une chaise Ikea. Tu acceptes donc un compromis et tu achètes quelque chose de standard, « assez bien ».
Le logiciel a fonctionné de la même manière. Une app de prise de notes est conçue pour des millions de personnes, donc elle fait des choix qui conviennent à beaucoup et sont parfaits pour très peu. Tu l’achètes parce que jusqu’à hier, te la construire sur mesure coûtait des années ou des milliers d’euros.
Mais si le coût de la personnalisation s’effondre presque à zéro ?
Si je peux décrire comment je veux vraiment mon app de notes, avec les catégories que j’utilise, le flux que je préfère, intégrée aux outils que j’ai déjà, est-ce que ça a encore un sens d’acheter celle pensée pour des millions d’utilisateurs ?
Peut-être que oui, par confort. Peut-être que non, si la différence entre « m’adapter » et « l’avoir comme je la veux » devient trop évidente.
Je me demande si le logiciel de masse aura le même destin que la musique commerciale à l’ère du streaming. Il reste, certes, mais il cesse d’être au centre de tout, parce qu’à côté grandissent des expériences plus personnelles, plus sur mesure.
Qui pourrait résister
Si ce scénario se vérifie — et j’y mets un « si », non pas parce que je doute de la direction, mais parce que la vitesse et la forme du changement sont vraiment incertaines — il existe des modèles grand public qui semblent plus solides que d’autres.
Les plateformes de réseau, par exemple. Twitter, LinkedIn, WhatsApp. Leur valeur n’est pas dans l’app en elle-même, mais dans le fait que tous les autres y sont. Tu ne peux pas avoir ta version personnalisée d’un réseau, parce qu’un réseau sans réseau n’est qu’une interface vide.
Ensuite, il y a les services à données propriétaires. Spotify ne vend pas un lecteur de musique. Il vend l’accès à des catalogues, à des métadonnées, à des licences, à des algorithmes nourris de milliards d’écoutes. Ça ne se génère pas avec un prompt.
Et il y a les produits où la confiance et la compliance font partie du paquet. Finance, santé, juridique. Même si une IA te générait le logiciel parfait, la question reste : qui prend la responsabilité ? Qui certifie ? Qui répond quand quelque chose tourne mal ?
Enfin, peut-être, les produits haut de gamme avec une UX exceptionnelle. Certaines expériences sont soignées d’une manière qui ne se résume pas à « ça marche », c’est de la qualité perçue. Notion, Linear, Figma. Répliquer des fonctionnalités est une chose. Répliquer cette cohérence, ce détail, cette confiance esthétique et opérationnelle, en est une autre.
Ce qui risque de souffrir le plus, en revanche, ce sont les utilitaires de niche. Les apps qui « font une seule chose », les micro-SaaS à 9,99 € par mois qui vivent parce qu’ils résolvent un problème spécifique mieux que les autres. Si je peux me la construire en une heure, ce prix commence à trembler.
La barrière qui reste, pour l’instant
Il y a une objection légitime, et je la perçois aussi.
Les gens ne veulent pas construire leurs propres choses. Ils veulent les utiliser.
C’est vrai. Et ça le sera probablement encore un bon moment. Il y a le confort, la confiance, l’économie cognitive. Rien que formuler clairement ce que l’on veut, c’est déjà un effort, alors itérer, corriger, choisir…
Mais cette barrière n’est pas stable. Elle baisse avec l’habitude. Elle baisse avec de meilleures interfaces. Elle baisse avec l’éducation numérique. Et elle baisse surtout quand l’avantage d’avoir quelque chose sur mesure devient assez évident pour justifier l’effort, pendant que cet effort, lui, continue de diminuer.
Pour moi, le point d’inflexion ne sera pas « l’outil est devenu accessible ». Ce sera « la première fois que quelqu’un que je connais me montre ce qu’il a fait en 20 minutes, et que je me dis : je pourrais le faire moi aussi ».
Ce moment arrive. Pour certaines personnes, il est déjà arrivé.
Ce que l’on pourrait voir dans les prochaines années
Je ne suis pas analyste, je n’ai pas de boule de cristal. Prenez ces lignes comme des intuitions informées, pas comme des prévisions.
Je pense qu’on verra une première vague de produits grand public qui ne s’achètent plus, mais se construisent. D’abord dans les segments les plus tech-friendly — développeurs, designers, étudiants — puis par cercles concentriques.
Je pense qu’on verra une pression énorme sur les prix des micro-SaaS. Pas parce qu’ils deviennent inutiles, mais parce qu’il devient difficile de justifier un abonnement quand la même utilité est générable à la demande. Survivront ceux qui offrent quelque chose qui ne se génère pas facilement : des données, du réseau, de la confiance, une intégration profonde aux écosystèmes existants.
Et je pense qu’apparaîtront de nouveaux intermédiaires. Pas des « constructeurs d’apps », mais des curateurs et distributeurs d’intentions de logiciel. Des gens qui empaquettent des prompts, des configurations, des flux déjà testés, pour que d’autres puissent créer sans partir de zéro. Une sorte de marketplace de templates, mais plus profonde, plus opérationnelle.
Il y aura aussi, sans doute, des tentatives de réglementation, plus ou moins maladroites, sur certains scénarios particuliers.
Le café du matin comme métaphore
Je reviens au point de départ, parce que c’est là que la sensation est restée.
Ce n’est pas la vitesse qui m’a vraiment frappé. C’est le coût cognitif. J’étais distrait, je faisais autre chose, j’avais la tête sur deux choses en parallèle. Ce n’était pas une session de travail. Ce n’était pas « aujourd’hui, je construis un produit ».
Et pourtant le résultat est suffisamment bon pour rester en ligne.
Pour moi, c’est ça le signal. Le fait que produire du logiciel est en train de devenir quelque chose que tu fais en parallèle d’autre chose, comme envoyer un mail ou lancer une recherche Google. Une action qui ne demande plus un contexte dédié, une compétence spécifique, une énergie mentale particulière.
Quand une chose devient comme ça, sa place dans la hiérarchie cognitive et culturelle change. Et avec elle change le marché qui a poussé autour.
Le logiciel devient une intention. Pas encore pour tout le monde, pas encore de façon stable, mais la direction est celle-là, et la vitesse augmente.
Alors la question qui me reste, ce matin, est la suivante.
Si tu construis un produit grand public, la valeur est-elle dans la distance technologique entre toi et ton utilisateur, ou dans quelque chose qui existe encore quand cette distance n’existe plus ?
Si tu n’as pas de réponse claire, c’est peut-être le moment d’en trouver une.
Ce qu'il faut retenir
Le b2b tient parce que la valeur n’a jamais été dans la frappe du code, elle était dans le contexte.
Côté grand public, le seuil technique baisse chaque mois : quand une personne ordinaire le franchit, le marché ne revient pas en arrière.
Survivront ceux qui ont un réseau, des données propriétaires, une confiance régulée ou une UX irréductible ; les micro-SaaS à 9,99 € meurent.
Le logiciel devient une action que l’on accomplit en parallèle d’autre chose, comme envoyer un mail.
Questions & réponses
Que signifie « le logiciel devient une intention » ?
Que la distance entre « je voudrais une app qui fait X » et « il existe une app qui fait X » est en train de s’effondrer. 17 minutes pour construire une application grand public fonctionnelle — domaine, backend, interface — sans écrire une ligne de code, en utilisant uniquement le langage naturel et un agent IA. Ce n’est pas du prototypage rapide : c’est la transformation du code, de chose écrite à instruction exprimée. Le médium du logiciel est en train de changer.
Qu'est-ce qui change dans le marché grand public quand un logiciel coûte 17 minutes ?
L’économie du marginal change. Une app qui résout le problème de dix personnes ne valait pas la peine d’être construite : les coûts de développement exigeaient un marché de millions. Aujourd’hui, la construire coûte autant qu’écrire un long e-mail. Cela ouvre le marché aux longues traînes extrêmes : logiciels de niche, personnels, temporaires. Et le modèle venture capital, qui tenait tant que le développement était cher, devient encore plus fragile.
Ce n'est qu'une démo, non ? Le vrai logiciel est plus complexe.
Vrai et faux à la fois. Le logiciel d’entreprise reste complexe : compliance, intégrations, échelle. Mais le logiciel grand public simple — celui qui a été le cœur du marché SaaS pendant des années — ne l’est plus. Une part énorme des apps grand public existantes pourrait être recréée en quelques heures. Ça ne rend pas le logiciel complexe obsolète, ça déplace la frontière concurrentielle : la différenciation va là où la complexité reste irréductible.
Que devrait faire un product manager face à cette transition ?
Distinguer nettement, dans son produit, ce qui est « logiciel simple » de ce qui est « logiciel irréductiblement complexe ». Le premier sera commoditisé — d’ici 18 mois, un concurrent le réplique en un après-midi. Le second est la vraie base de défense. Investir dans le second, arrêter d’accumuler le premier. Et réévaluer les produits qui n’ont pas de sens économique aujourd’hui parce qu’ils sont petits : ils pourraient en avoir demain.
L'auteur
