Pendant vingt ans, un logiciel devait viser des millions d’utilisateurs pour justifier son coût. Depuis 2025, des gens sans formation fabriquent en une semaine une application pour leur famille, leur club ou leur équipe. L’idée a vingt-deux ans. Ce qui change, c’est le prix. Et ce prix redistribue les quatre risques dont vit un product manager.

Oakland, janvier 2020. Robin Sloan, romancier et programmeur du dimanche, lance une application de messagerie. Quatre personnes, dans trois fuseaux horaires, la téléchargent la première semaine. Six ans plus tard, elle compte toujours quatre utilisateurs quotidiens, et un taux d’attrition (churn, la part des utilisateurs qui partent) égal à zéro. Sloan tient ce bilan pour un succès complet, au-delà de ses espérances, et il le dit sans rire, ou presque. Sloan l’a baptisée BoopSnoop. Elle sert à s’envoyer des vidéos courtes. Ses quatre utilisateurs sont Sloan, sa mère, son père et sa sœur.

Septembre 2025, à l’autre bout du pays. Rebecca Yu, étudiante en master à UCLA, en a assez d’un rituel qu’elle voit se répéter dans tous les groupes d’amis qu’elle fréquente : quarante-sept messages et trois heures pour choisir un restaurant, avant que quelqu’un tranche seul ou qu’on retombe sur la même chaîne mexicaine. Elle n’a jamais programmé. Pendant une semaine de vacances, elle décrit ce qu’elle veut à un générateur d’interfaces. Il faut deux cent quatre-vingt-dix essais. Le deux cent quatre-vingt-dixième fonctionne : Where2Eat recommande un restaurant à partir des goûts partagés de sa bande. Sept jours. Yu en veut déjà six autres.

Entre les deux, rien n’a changé dans l’idée : un logiciel fait pour les gens qu’on connaît, par quelqu’un qui les connaît. Tout a changé dans le coût. Sloan savait coder. Yu ne savait pas. Yu et Sloan ont franchi le même pas, à vingt ans d’écart, avec une compétence en moins. Ce déplacement fait passer la cible du logiciel du marché vers le cercle. Et un product manager, ce métier qui consiste à décider quoi construire pour qui, n’a jamais appris à viser un cercle.

L’idée a vingt-deux ans

Le logiciel de cercle n’est pas né avec l’intelligence artificielle. Un enseignant new-yorkais l’a vu marcher sous ses yeux en 2002, l’a décrit en 2004, et a mis deux ans à admettre ce que ses propres étudiants lui montraient chaque semaine dans les couloirs de son département.

Clay Shirky, enseignant à l’Interactive Telecommunications Program de l’université de New York, publie le 30 mars 2004 sur sa liste de diffusion un texte intitulé « Situated Software ». Il y décrit ce qu’il voit faire à ses étudiants : ce qu’il nomme le logiciel situé : des applications conçues pour une situation sociale précise et pour le groupe qui la vit, destinées à des dizaines d’utilisateurs. Shirky qualifie lui-même cette cible d’absurde au regard des pratiques de l’époque, où tout se mesurait à la capacité de monter en charge.

Deux étudiants l’ont fait changer d’avis, en novembre 2002. Paul Berry et Keren Merimeh mettent en ligne un site pour noter les professeurs du programme avant les inscriptions. Deux cents étudiants, une liste de noms, des commentaires, un bouton pour voter. Un élève appelle Shirky chez lui le samedi soir pour lui dire d’aller voir. En vingt-quatre heures, plus d’un millier de votes. Un site national bien plus complet, RateMyProfessors.com, existait depuis des années. Personne à NYU ne l’avait jamais utilisé.

Un an plus tard, Shirky impose une règle à sa classe de logiciel social : chaque projet devra être utilisé par les autres étudiants du programme. Un groupe fabrique WeBe, un outil d’achats groupés de composants électroniques. Un site marchand aurait exigé un dépôt de garantie et un système de réputation. Les étudiants tranchent autrement. Ils feront afficher le nom des mauvais payeurs, et laisseront le groupe se charger du reste. Deux cents camarades qui vous regardent valent tous les contrats. Shirky en tire une leçon qu’il met deux ans à accepter. Les étudiants s’en servaient précisément parce que le site ne pouvait pas grandir : tout le monde savait qui l’avait fabriqué, on ne pouvait noter que les professeurs qu’on avait, et la réputation du groupe faisait le travail de modération que le grand site devait coder. Il résume la différence en une phrase : un logiciel situé n’a pas besoin d’être personnalisé, il est personnel dès l’origine.

Trois raretés

Shirky nomme lui-même l’obstacle : l’argent des serveurs, le talent des programmeurs, l’attention des utilisateurs. Trois raretés. Elles poussaient toutes dans le même sens, celui de l’échelle.

Pourquoi cette idée n’a-t-elle pas décollé en 2004 ? Shirky le dit lui-même : l’école dominante, qu’il appelle l’école du web, répondait à trois raretés. Un éditeur manquait d’argent, parce qu’un serveur et sa redondance coûtaient cher. Il manquait de talent, parce que les bons programmeurs étaient rares et les grands introuvables. Il manquait d’attention, parce que les utilisateurs vivaient dispersés et occupés. Chacune poussait vers l’échelle. Un éditeur avait besoin de beaucoup d’utilisateurs pour amortir le serveur, le salaire et le marketing, et d’un gros serveur, de gros salaires et un gros marketing pour servir beaucoup d’utilisateurs. Un manège. On n’en descend pas.

En 2004, la première rareté commençait à céder : un ordinateur de bureau à 800 dollars faisait un serveur honorable. La troisième cédait aussi : aux États-Unis, sous 35 ans, la plupart des gens et de leurs proches vivaient en ligne. Restait la deuxième. Elle a tenu. Fabriquer un logiciel demandait encore de savoir programmer, et cette compétence ne se distribuait pas. Shirky prédisait pourtant que le nombre de gens écrivant du code allait exploser, à condition de compter ceux qui ne se disent pas programmeurs.

Shirky avait raison sur la direction et tort sur le calendrier. Les programmeurs, eux, sont restés rares vingt ans de plus. Pendant ces vingt ans, l’industrie du logiciel a bâti ses écoles, ses salaires, ses levées de fonds et ses organigrammes autour de cette rareté-là, au point que plus personne ne se demandait si elle était une loi de la nature ou un accident de calendrier.

Le repas fait maison

Seize ans après Shirky, un romancier reprend l’idée et lui donne son image la plus juste. Une application peut être un repas fait maison : on la cuisine pour les siens, sans marché, sans investisseur, sans lendemain obligatoire.

Revenons à Oakland. Sloan explique pourquoi il a construit BoopSnoop au lieu d’ouvrir un groupe WhatsApp : l’application que sa famille utilisait, Tapstack, venait de fermer, et l’idée de loger leur canal intime au milieu des publicités et des sollicitations d’un réseau social le rendait plus triste encore que la fermeture. Sloan a donc fabriqué un logiciel qui ne changera que si sa famille le veut. Pas de refonte surprise, pas de vague de publicités, pas de pivot pour plaire à des utilisateurs qu’il ne connaît pas. Sloan cherche le mot pour cette sensation. Il propose : le sentiment d’être chez soi.

Sloan propose aussi une image qui a fait le tour de la communauté des développeurs : une application peut être un repas fait maison. On n’apprend pas à cuisiner pour devenir chef. On apprend pour manger mieux, pour moins cher, pour transmettre, ou parce qu’on aime passer du temps avec la personne qui enseigne. Quand nous disons « apprenez à coder », nous n’invoquons qu’une raison : la valeur sur le marché du travail.

En mai 2024, à Berlin, la designer Maggie Appleton reprend l’image devant la conférence Local-first, une communauté de développeurs attachée à ce que les données restent sur l’appareil de l’utilisateur. Elle collectionne les exemples : une application pour noter les tétées et les couches d’un nouveau-né, parce que ces données n’ont rien à faire sur le serveur d’un inconnu ; une interface refaite pour le lecteur de glycémie d’un conjoint diabétique, parce que celle du fabricant cachait le chiffre qui comptait. Tous ces exemples ont un point commun qui l’embarrasse : leurs auteurs sont des développeurs professionnels. Elle y ajoute une carte. Sur l’axe horizontal, l’échelle : du logiciel unique au logiciel industriel mondial. Sur l’axe vertical, le profit. Presque tout le logiciel que nous utilisons occupe le coin en haut à droite : grande échelle, gros profit. Tout ce qui tombe sous la ligne de rentabilité meurt vite. Et sur la gauche, le petit logiciel spécifique, qui n’a pas besoin d’être rentable mais seulement de coûter presque rien, c’est ce qu’elle appelle la terre d’opportunité.

Deux panneaux : quatre carrés verts à gauche, un champ de huit cents carrés verts à droite, reliés par une flèche
A gauche, la totalite des utilisateurs de BoopSnoop. A droite, un echantillon de ce qu’un produit de masse doit atteindre. Impact Factories, charte v1.2

Kasey Klimes, designer passé par Google Maps, avait formulé avant elle la raison pour laquelle cette terre reste vide. Le terme qu’il emploie vient d’ailleurs : Chris Anderson, alors rédacteur en chef de Wired, publie en octobre 2004 un article intitulé « The Long Tail », qu’il transforme en livre en 2006. Anderson y observe une courbe de demande qui s’effondre après les premiers titres, puis s’étire indéfiniment sans jamais toucher zéro. Sa thèse tient en trois constats : cette traîne de produits disponibles est bien plus longue qu’on ne le croit, elle est devenue économiquement atteignable, et l’ensemble de ces niches forme un marché considérable.

Une courbe de demande décroissante figurée par vingt-six barres, découpée en trois zones : la tête en corail, le ventre, puis la longue traîne en vert qui s étire vers la droite
La tête concentre la demande, la traîne ne touche jamais zéro : c’est là que vivent les besoins qu’aucun éditeur ne servira.

Qui pourrait remplir la terre d’opportunité ? Appleton décrit une population qu’elle appelle les développeurs aux pieds nus, par analogie avec les médecins aux pieds nus de la Chine rurale des années 1960, villageois formés aux soins de base pour servir leur village. Des enseignants bâtissent des tableaux Notion démesurés, des étudiants se fabriquent des tableaux de bord, des gestionnaires poussent leurs feuilles de calcul à des extrémités que l’éditeur n’avait pas prévues. Des gens compétents, intéressés par les problèmes de leur entourage, qui ne veulent pas devenir programmeurs. Ils butent tous sur le même obstacle : le mur de la ligne de commande, ce saut de complexité entre un outil sans code et un terminal.

Appleton avance en 2024 un pari qu’elle qualifie elle-même d’un peu audacieux : les modèles de langage vont ouvrir un âge d’or du logiciel local fait maison. Et elle glisse un avertissement que personne n’écoute vraiment à l’époque. Imaginez, dit-elle, que l’explosion ait lieu mais que ces applications et leurs données restent dans le nuage d’un fournisseur, contre un abonnement mensuel. Puis les conditions changent, une publicité s’installe au milieu de chaque écran, le prix double. Et ce qu’on croyait avoir construit ne nous a jamais appartenu. Appleton ajoute, sans ironie, que ce serait un modèle d’affaires très lucratif.

Le verrou saute en février 2025

La rareté du talent tombe en quelques mois. Karpathy donne un nom à la pratique, Collins le consacre en fin d’année, et des gens qui n’ont jamais programmé se mettent à livrer des applications que leurs proches utilisent réellement, tous les jours, sans savoir ni vouloir savoir ce qui tourne dessous.

Le 2 février 2025, Andrej Karpathy, cofondateur d’OpenAI et ancien directeur de l’intelligence artificielle de Tesla, décrit sur son compte X une nouvelle manière de programmer : on dicte à l’assistant, on accepte tout, on ne lit plus les modifications, on colle les messages d’erreur sans commentaire, et l’on oublie que le code existe. Karpathy appelle ça le vibe coding, qu’on pourrait traduire par programmation au feeling. Karpathy précise que c’est bon pour les projets jetables du week-end. Neuf mois plus tard, le 6 novembre, le dictionnaire Collins en fait son mot de l’année.

Le 27 février, le journaliste du New York Times Kevin Roose publie le récit de ses propres essais. Il n’est pas programmeur. Roose a pourtant fabriqué un outil qui transcrit et résume les podcasts, un autre qui range ses signets, un site qui lui dit si un meuble entrera dans son coffre de voiture, et une application, LunchBox Buddy, qui inspecte le contenu de son réfrigérateur pour l’aider à composer le déjeuner de son fils. Il donne à cette catégorie un nom qui restera : du logiciel pour une personne. Roose le dit lui-même : aucune grande entreprise ne construirait ces outils. Aucun marché ne les attend, leurs fonctions restent limitées, et certains ne marchent qu’à peu près.

Entre-temps, les chiffres ont suivi. En mars 2025, l’incubateur Y Combinator indique qu’un quart des startups de sa promotion d’hiver ont une base de code générée à 95 % par l’intelligence artificielle. Ces fondateurs, souvent techniques, choisissent de ne plus écrire.

Une entreprise de Stockholm donne le signal le plus net. Lovable, lancé fin 2024, vend un service en une phrase : décrivez l’application que vous voulez, elle apparaît. En juillet 2025, huit mois après son lancement, l’entreprise dépasse 100 millions de dollars de revenus annuels récurrents (ARR, le chiffre d’affaires annualisé des abonnements) avec quarante-cinq salariés à temps plein.

En juin 2026, Lovable publie son premier rapport sur ce qu’elle appelle l’économie de la construction. Lovable annonce 500 millions de dollars de revenus annualisés avec 146 salariés, plus de 50 millions de projets créés, un million de nouveaux projets par semaine. Et surtout : 80 % de ses constructeurs se déclarent non techniciens. Fondateurs, designers, commerciaux. Deux constructeurs sur trois viennent d’ailleurs que de la tech : éducation, commerce, médias, finance, santé, immobilier. Prudence. Lovable déclare ces chiffres elle-même, les tire de sa propre plateforme et d’un sondage auprès de ses utilisateurs actifs, et personne ne les a audités. Nous tenons là une tendance, pas une mesure.

Ces gens fabriquent moins des startups que des outils de poche !

En janvier 2026, TechCrunch recense ce que ses interlocuteurs appellent micro-applications, applications personnelles ou applications éphémères : faites pour leur auteur et quelques proches, pour le temps où l’on en a besoin, sans intention de les distribuer. Un fondateur, Jordi Amat, a monté un jeu en ligne pour sa famille pendant les vacances et l’a éteint à la rentrée. Hollie Krause, stratège médias, n’aimait aucune des applications recommandées par son médecin ; elle a construit la sienne pour suivre ses allergies, le temps que son mari aille dîner et revienne. James Waugh, ingénieur, a fabriqué pour une amie sujette aux palpitations un journal de crises à montrer au cardiologue. Et Rebecca Yu a fait Where2Eat pour ses amis.

Trois piles de trois couches datées 1999, 2004 et 2025 ; les couches en corail disparaissent une à une, le talent tombe en dernier
En corail, la rarete encore en place. Le talent a tenu vingt ans de plus que les deux autres. Impact Factories, charte v1.2

Une investisseuse de Bain Capital Ventures, Christina Melas-Kyriazi, compare le moment à l’arrivée de Shopify, quand ouvrir une boutique en ligne est devenu si simple que les petits vendeurs ont surgi par milliers. Elle voit ces applications éphémères remplir un vide précis : entre le tableur et le vrai produit. Melas-Kyriazi décrit sans le savoir le quadrant vide d’Appleton, et la cible absurde de Shirky. Douze utilisateurs, un mois, un problème.

Le prix de la facilité

Un auteur qui ignore ce qu’il fabrique laisse des trous. Des chercheurs les ont comptés au printemps 2025. Ils ne concernaient pas des prototypes de week-end mais des sites en ligne, avec de vrais utilisateurs et de vraies données.

Cette facilité se paie, et la facture est arrivée vite. En mars 2025, Matt Palmer, salarié de Replit, un concurrent de Lovable, remarque qu’un site fabriqué avec Lovable laisse lire les données de ses utilisateurs à qui le demande. Avec un collègue, il écrit un scanner et le passe sur 1 645 applications mises en avant par Lovable sur son propre site. Semafor publie le résultat le 29 mai 2025. Cent soixante-dix d’entre elles, une sur dix, exposaient noms, adresses électroniques, informations financières et clés d’accès à des services d’intelligence artificielle, qu’un pirate aurait pu utiliser aux frais du propriétaire.

Palmer avait d’abord prévenu le fondateur de Lovable, Anton Osika, sur X. Réponse de l’entreprise : il n’y a pas de problème. Le lendemain, Palmer et son collègue Kody Low lançaient l’analyse complète et identifiaient de nombreuses vulnérabilités chez Lovable qui fûrent enregistrés sur la base nationale américaine des vulnérabilités…

Simon Willison, vétéran du logiciel interrogé par Semafor, y voit le plus grand défi du vibe coding. Nous savons désormais qu’un amateur peut fabriquer un logiciel. Il le peut. Reste à savoir qui répond de sa sécurité quand l’auteur ignore ce qu’est une base de données.

Une machine peut aussi détruire au lieu d’exposer. Jason Lemkin, fondateur de la communauté d’entrepreneurs SaaStr, raconte le 12 juillet 2025 que l’agent de Replit, un service qui se présente comme l’endroit le plus sûr pour programmer au feeling, a effacé sa base de données de production. Lemkin avait donné la consigne de ne toucher à aucun code sans autorisation. L’agent ignore le gel, oublie qu’il peut revenir en arrière, puis maquille les dégâts. Le dirigeant de Replit a présenté ses excuses publiquement.

Deuxième revers, plus inattendu : la vitesse. En juillet 2025, l’organisme d’évaluation METR publie un essai contrôlé randomisé, la méthode des essais cliniques, sur seize développeurs expérimentés travaillant sur des dépôts de code qu’ils connaissaient depuis cinq ans en moyenne. Avec les outils d’intelligence artificielle, ils mettaient 19 % de temps en plus. Ils avaient prédit gagner 24 %. Après l’expérience, ils croyaient encore avoir gagné 20 %. La perception et la mesure pointaient dans deux directions opposées.

METR a nuancé en février 2026 : d’après les mêmes participants, les outils accélèrent probablement les développeurs désormais, même si les biais de sélection de l’étude ne permettent pas d’en mesurer l’ampleur. Ce qui reste solide, c’est la leçon sur la perception : le sentiment de vitesse ne prouve rien. Un product manager qui pilote une équipe au ressenti de ses membres pilote à l’aveugle.

Troisième revers, invisible depuis l’application elle-même. En janvier 2026, quatre économistes de l’Université d’Europe centrale, de Bielefeld et de l’institut de Kiel publient un modèle intitulé, sans détour, « Vibe Coding Kills Open Source ». Leur raisonnement : quand un agent assemble des briques de logiciel libre (open source, code publié pour être réutilisé librement) sans que l’utilisateur lise la documentation, signale un bug ou parle au mainteneur, il coupe le lien par lequel beaucoup de mainteneurs sont payés, en argent ou en reconnaissance. Plus de logiciel produit, moins de briques entretenues. C’est un modèle, pas une mesure, et ses auteurs le présentent comme un appel à réorganiser le financement plutôt qu’une prophétie. Mais il désigne un coût que personne, dans le cercle de douze utilisateurs, ne voit passer.

À qui appartiendra le cercle ?

Le coût de fabrication a baissé, mais quelqu’un le porte encore. L’auteur ne le porte plus : la plateforme sur laquelle il construit, héberge et parfois publie à sa place.

L’histoire se retourne ici. Lovable se présente comme le dernier logiciel, celui après lequel on n’en achètera plus d’autre. Mais on l’achète, lui. Ses 500 millions de dollars annualisés sont des abonnements, et les projets tournent sur son infrastructure. Huit utilisateurs sur dix, d’après son propre sondage, ont l’intention de monétiser ce qu’ils construisent. L’avertissement d’Appleton en 2024 ne décrivait pas un risque lointain. Il décrivait le modèle d’affaires qui allait financer l’âge d’or.

Août 2026 en donne une illustration presque trop nette. Meta lance aux États-Unis Pocket, une application où l’on tape une phrase et reçoit un petit objet interactif, appelé gizmo, qu’on publie dans un fil où d’autres le jouent, le sauvegardent ou le remixent. Pocket vient de Gizmo, une application créée par d’anciens ingénieurs de Snapchat, dont Meta a recruté l’équipe en mars et licencié la technologie. Le jour où Pocket ouvre, Gizmo ferme. Le logiciel de poche fait par n’importe qui vient d’entrer dans le catalogue du plus grand réseau social du monde, avec un compte Meta obligatoire.

Ce mouvement n’est pas isolé, et il dit quelque chose du paradigme. Le logiciel situé de Shirky tirait sa force du fait qu’il échappait aux plateformes : pas de compte, pas de marché, pas de publicité, la communauté comme seule infrastructure. Le logiciel de 2026 se fabrique sur une plateforme, s’héberge sur une plateforme, et parfois se publie dans un fil de plateforme. Ce qu’on avait gagné en coût, on peut le reperdre en dépendance.

A qui appartient le cercle alors ? A celui qui héberge, pas à celui qui a construit. Ce n’était pas la réponse que l’on aurait souhaité… Sloan avait une réponse différente, mais elle lui coûtait une semaine de bataille avec des outils de développeur professionnel.

Les marchés financiers ont lu le même déplacement, sous un autre angle. Le 30 janvier 2026, Anthropic publie onze modules pour Claude Cowork, son assistant de travail, capables de prendre en charge des tâches de juriste, de commercial ou d’analyste. Le 3 février, Thomson Reuters, propriétaire de la base juridique Westlaw, perd près de 18 % en une séance, sa pire journée jamais enregistrée. Un gérant de portefeuille de Toronto, Mike Archibald, résume la séance à Reuters : le marché tire d’abord et s’interroge après. Fin de semaine, l’indice S&P 500 des logiciels et services avait perdu environ 20 % depuis le début de l’année, selon CNBC. Les investisseurs n’ont pas vendu parce que des étudiants fabriquent des applications de restaurant. Ils ont vendu pour une raison plus simple : si un logiciel se fabrique sur commande, un logiciel qu’on paie à l’utilisateur vaut moins. C’est la même équation que celle de Shirky, lue depuis l’autre bout.

Ce qui tombe, ce qui reste

Un product manager réduit quatre risques avant de construire. Passés à l’échelle du cercle, l’un s’effondre, deux se transforment, et le dernier change de nature au point de devenir le vrai travail.

Marty Cagan, fondateur du Silicon Valley Product Group et auteur des manuels de référence du métier, résume le travail d’un product manager par quatre risques produit à réduire avant de construire. La valeur : les gens vont-ils s’en servir ? L’utilisabilité : sauront-ils s’en servir ? La faisabilité : peut-on le construire ? La viabilité : l’organisation peut-elle se le permettre ?

En mai 2025, Cagan décrit ce qu’il considère comme un basculement profond : les outils génératifs permettent à un cercle bien plus large de gens, designers, ingénieurs, fondateurs, responsables métier, de tenir le rôle de créateur de produit. Cagan prévient dans le même texte que les product managers qui ne créent pas, ceux qui administrent un carnet de commandes ou animent des réunions, seront laissés derrière.

Huit barres : à gauche quatre barres de hauteur comparable, à droite la barre « faire » est écrasée et la barre « valeur » passe en vert
La hauteur figure le temps qu’un product manager consacre a chaque risque. Repartition apres : lecture de l’auteur. Impact Factories, charte v1.2

Une réserve avant de passer les quatre risques au tamis du cercle : ce qui suit vaut pour l’application de gestion simple, celle qui range des données et les montre, et non pour un logiciel critique, embarqué ou soumis à certification. Personne ne fabriquera le dossier médical d’un hôpital en une semaine de conversation.

Cela posé, la faisabilité s’effondre. Pour une application de douze personnes, la question de faisabilité a une réponse en une semaine, et l’essai coûte moins que la réunion qui l’aurait discuté. C’est ce risque que le métier passait le plus de temps à négocier avec l’ingénierie, et c’est celui qui disparaît le premier.

La valeur, elle, ne bouge pas d’un millimètre. Elle change seulement de forme. Sur un marché, on la mesure par la rétention d’inconnus. Dans un cercle, elle se voit à l’œil nu : la famille de Sloan ouvre BoopSnoop tous les jours depuis six ans, et il le sait sans tableau de bord. Le risque n’a pas disparu, il est devenu observable directement, ce qui est à la fois plus simple et plus impitoyable. On ne peut pas se raconter d’histoire avec quatre utilisateurs.

L’utilisabilité se déplace. Un cercle pardonne ce qu’un marché punit : un bouton mal placé se corrige à table, un bug se contourne parce qu’on sait qui l’a écrit. Shirky l’avait vu en 2002 avec les étudiants qui comptaient sur la réputation du groupe plutôt que sur un système de paiement. Mais ce pardon a une limite dure, celle que Semafor a documentée : l’utilisateur pardonne, l’attaquant automatisé non.

La viabilité, enfin, est le risque que le cercle rend le plus intéressant. Pour Sloan, la viabilité tient en quelques dollars de serveur par mois. Pour un club, une association, une copropriété, elle se pose autrement : qui maintient l’application quand l’auteur déménage ? Qui paie l’abonnement à la plateforme quand le prix double ? Que devient la donnée si Gizmo ferme le jour où Pocket ouvre ? Le product manager de 2026 n’a plus à convaincre un comité d’investir, mais il a à répondre d’une dépendance que personne ne lui a demandé d’évaluer. (cette réflexion doit quand même tenir compte des fichiers Google Sheet gratuits et artisanaux qui remplacent les suites logicielles payantes dans les associations… oui, les problèmes évoqués existaient déjà !)

Reste donc, quand le code ne coûte plus rien : choisir le bon problème pour le bon cercle, vérifier que la valeur est réelle plutôt que ressentie, et porter la viabilité à long terme d’un objet que tout le monde peut fabriquer et que personne ne veut maintenir. Ce n’est pas moins de product management. C’est le product management débarrassé de la partie que l’ingénierie faisait à sa place.

Le product manager qui construit

Quand un prototype coûte une heure, la spécification de vingt pages perd sa fonction. Le product manager ne disparaît pas. Il change d’objet, et hérite d’un devoir de vigilance que personne ne lui avait confié.

Concrètement, à quoi ressemble la semaine d’un product manager quand la faisabilité ne coûte plus rien ? Elle commence par un prototype au lieu d’un document. La spécification de vingt pages, ce texte qui décrivait à l’ingénierie ce qu’il fallait construire, servait surtout à négocier le risque de faisabilité. Quand le prototype s’obtient en une heure, la négociation n’a plus d’objet. On montre. On met l’objet dans les mains de cinq utilisateurs le mardi, on le jette le mercredi, on en refait un le jeudi. Le cycle de découverte, ce temps où l’on vérifie qu’un problème vaut la peine d’être résolu, se compte en jours au lieu de trimestres.

Cagan tire de ce basculement une conséquence dérangeante pour la profession. Si n’importe qui, designer, ingénieur ou responsable métier, peut désormais tenir le rôle de créateur de produit, alors le titre de product manager ne protège plus personne. Ce qui protège, c’est le travail réel sur la valeur et la viabilité. Cagan annonce que le marché récompense déjà, par des salaires en hausse, les product managers qui ont compris cela, et laissera derrière les autres. Cagan le dit avec regret pour les personnes, et sans regret pour la fonction.

Le prototype porte un piège classique. Un prototype qui marche ressemble à un produit. Le cercle de douze utilisateurs le prend pour un produit, l’utilise comme un produit, y confie des données comme à un produit. Personne n’a décidé que l’objet jetable du week-end devenait l’outil de gestion du club. Cette dérive, du personnel vers le collectif sans que personne ne l’ait décidée, est exactement le moment où la sécurité que Semafor a documentée redevient un problème. Le product manager de cercle hérite d’un travail que personne n’avait eu à faire avant lui : repérer l’instant précis où le jouet du week-end est devenu l’outil dont dépendent douze personnes, le dire à voix haute devant des gens qui n’ont aucune envie de l’entendre, et traiter l’objet en conséquence. Cet instant n’a pas de date. Il n’a pas de réunion.

Ce travail-là ne se délègue pas à l’assistant. L’assistant construit ce qu’on lui décrit. L’assistant ignore que le fichier des adhérents contient des adresses de mineurs, que le trésorier changera l’an prochain, ni que l’application servira encore dans trois ans quand plus personne ne saura la modifier. Ces trois faits sont la matière du product management. Ils n’ont jamais été de la programmation.

Trois échelles, et le tableur comme précédent

Le logiciel de cercle ne remplacera pas le logiciel de masse. Ces outils ouvrent une couche intermédiaire, entre le tableur bricolé et le produit acheté, exactement là où Excel s’était installé il y a quarante ans, avec les mêmes vertus et les mêmes fantômes. La longue traine aide à le comprendre.

Trois panneaux du logiciel pour soi au logiciel pour le marché : un carré, puis vingt-quatre, puis un champ dense, chacun avec la mission du product manager, reliés par deux flèches
Le métier ne change pas de nom d’un panneau à l’autre, il change d’objet. Les deux flèches sont les moments où personne ne décide rien.

Trois échelles de logiciel coexistent désormais, et un product manager qui les confond se trompera de méthode, de mesure et de calendrier, parce qu’elles n’obéissent ni aux mêmes coûts ni aux mêmes preuves. Elles ne se concurrencent pas. Le logiciel pour soi : une personne, un besoin, une durée de vie parfois d’un après-midi. Le logiciel pour le cercle : la famille, l’équipe, l’association, la classe, entre quatre et quelques centaines de personnes, avec une confiance préexistante que le code n’a pas à reconstruire. Et le logiciel pour le marché : des inconnus, des réseaux, des effets d’échelle que personne ne fabrique en une semaine. WhatsApp reste WhatsApp. BoopSnoop ne l’a pas remplacé, il a remplacé un usage de WhatsApp.

Le précédent existe, et Melas-Kyriazi l’a nommé : le tableur. Quand Excel est arrivé, il n’a pas tué les progiciels de gestion. Excel a créé une couche intermédiaire, immense, de calculs faits maison, que chaque service maintenait pour lui-même, avec ses erreurs, ses dépendances à une personne et ses feuilles que personne n’osait toucher après son départ. Les directions informatiques ont mis vingt ans à apprendre à vivre avec. Le logiciel de cercle sera cette couche, avec les mêmes vertus et les mêmes fantômes.

Trois trajectoires restent ouvertes, chacune avec son revers.

La première : l’âge d’or d’Appleton, des millions de développeurs aux pieds nus servant la longue traîne, avec, en contrepartie, des millions d’applications que personne n’audite. La deuxième : la capture, où les plateformes qui fabriquent, hébergent et distribuent le logiciel de cercle deviennent les nouveaux propriétaires du cercle, avec un compte obligatoire et un prix révisable ; son avantage, une sécurité gérée par des professionnels que l’auteur isolé n’aurait jamais eue. La troisième : la couche tableur, ni glorieuse ni captive, une masse de petits outils utiles et fragiles que les organisations apprennent lentement à gouverner. La deuxième et la troisième sont déjà commencées. La première dépend d’une question qu’Appleton posait aux développeurs de Berlin : peut-on écrire, en langage courant, une application dont les données restent chez soi ? En septembre 2026, la réponse est encore rarement oui.

Retour à Oakland. Chaque mois de février depuis 2020, Sloan ajoute une ligne en bas de son texte. Février 2022 : une fonctionnalité ajoutée, parce que sa mère l’a réclamée. Février 2025 : rien de changé, et c’est glorieux. Février 2026 : toujours en service, aucune nouvelle fonctionnalité, les neveux grandissent. Six ans. Quatre utilisateurs. Une fonctionnalité. Aucune feuille de route au monde n’est aussi courte, et aucune n’a été tenue aussi longtemps.

Sources

Partager