Après la SaaSpocalypse, la SaaS-explosion

On a beaucoup parlé de « SaaSpocalypse ».

L’idée, grossièrement, est assez simple : à mesure que l’intelligence artificielle rend la création de logiciels plus accessible, certaines entreprises pourraient finir par se demander pourquoi elles continuent à payer des dizaines d’abonnements mensuels pour des outils qu’elles seraient désormais capables de reproduire elles-mêmes.

Je ne suis pas certain que cela suffise à provoquer l’apocalypse annoncée. En revanche, je me demande si nous ne sommes pas en train d’assister à quelque chose d’assez différent : non pas à la disparition du logiciel, mais à sa prolifération.

Une SaaS-explosion.

Pourquoi acheter ce que je peux fabriquer ?

Je suis probablement assez mal placé pour critiquer le phénomène. Ces derniers mois, j’ai moi-même fabriqué plusieurs outils correspondant à mes propres besoins : des outils d’écriture, de budget, de planification, et plusieurs petits produits personnels répondant à des problèmes suffisamment précis pour que je ne trouve jamais exactement ce que je veux dans les solutions existantes.

Ou, plus exactement, pour que chercher la bonne solution, la tester, comprendre son fonctionnement, l’adapter à mes usages puis éventuellement payer son abonnement devienne parfois plus pénible que de construire moi-même une première version. Ce qui est nouveau n’est pas le fait qu’on puisse développer ses propres outils. Cela a toujours été possible pour qui disposait des compétences, du temps et de l’envie nécessaires. Ce qui change, c’est le nombre de personnes qui peuvent désormais raisonnablement envisager de le faire.

Pendant longtemps, développer son propre logiciel pour répondre à un besoin relativement banal aurait été complètement irrationnel. Vous aviez besoin de gérer vos tâches ? Vous choisissiez Todoist, Things, Trello ou l’un des cinquante outils disponibles. Vous vouliez organiser vos notes ? Evernote, Notion, Obsidian ou un autre acteur avait déjà travaillé sur le problème. Créer votre propre solution aurait nécessité du temps, des compétences techniques et beaucoup trop d’énergie pour obtenir, au final, quelque chose de moins abouti que ce qui existait déjà.

L’équation a changé. Pas complètement, évidemment, mais suffisamment. Avec une IA capable de générer du code, de corriger des erreurs, de proposer une interface, d’expliquer comment brancher une base Supabase ou de débloquer un problème technique en quelques minutes, la barrière à l’entrée s’effondre. On ne devient pas développeur en tapant trois prompts, mais on devient capable de construire des choses que l’on n’aurait jamais essayé de construire quelques années auparavant.

Et c’est là que le phénomène devient vraiment intéressant.

Nous sommes probablement plusieurs à fabriquer le même logiciel

Parce que je ne suis évidemment pas le seul à faire ça. Quelque part, une autre personne est probablement en train de construire son propre outil d’écriture, une autre son gestionnaire de budget, une autre encore son outil de suivi de lecture. Et nos trois produits auront certainement énormément de choses en commun.

Mais pas complètement.

Le mien aura peut-être une intégration GitHub parce que cela correspond à ma façon de travailler. Celui du voisin préférera Google Drive. Le troisième ne voudra surtout aucune intégration et considérera que la simplicité est précisément la fonctionnalité principale du produit. Chacun aura donc fabriqué son outil idéal, légèrement différent de celui du voisin, tout en ayant potentiellement passé plusieurs dizaines d’heures à résoudre trois fois le même problème.

Le plus amusant, ou le plus absurde, c’est que nous ne saurons peut-être même pas que les autres existent. Nous aurons simplement eu le même besoin, à peu près au même moment, et nous y aurons répondu chacun de notre côté.

C’est là tout le paradoxe. Le logiciel est historiquement un outil de mutualisation. Un besoin existe chez suffisamment de personnes pour qu’une entreprise investisse dans la création d’un produit commun. Mille entreprises ont un problème similaire, un éditeur construit une solution, et les mille entreprises utilisent plus ou moins le même logiciel. Les différences entre leurs besoins sont absorbées par le paramétrage, les options, les intégrations et quelques compromis.

Mais que se passe-t-il lorsque le coût de création devient suffisamment faible pour que chacun puisse construire sa propre variante ?

Le besoin commun existe toujours. Ce qui devient moins indispensable, c’est la mutualisation. On pourrait donc passer progressivement d’un modèle où un besoin génère quelques produits utilisés par beaucoup de monde à un modèle où le même besoin génère énormément de produits utilisés par très peu de personnes.

Et parfois, peut-être, par une seule.

Le coût de la duplication s’effondre

Dans l’industrie traditionnelle, reproduire ce que quelqu’un d’autre fabrique déjà est généralement absurde. Pourquoi concevoir votre propre lave-vaisselle si Bosch en produit un qui répond parfaitement à votre besoin ? Le coût de reproduction rend la question ridicule.

Dans le logiciel, ce coût a toujours été beaucoup plus faible. Avec l’IA, il pourrait devenir suffisamment bas pour modifier complètement nos comportements. Le calcul n’est plus seulement : « Combien coûte ce logiciel ? » Il devient aussi : « Combien me coûte la recherche du logiciel qui correspond à mon besoin ? Combien de temps vais-je passer à le comprendre, à le paramétrer, à contourner ce qu’il fait différemment de ce que je voudrais, puis à adapter mon fonctionnement au sien ? »

À partir d’un certain point, reconstruire devient rationnel. Ou, au minimum, suffisamment séduisant pour qu’on le fasse quand même.

C’est peut-être là que se situe le vrai basculement. Lorsque reconstruire un outil devient plus facile que trouver, apprendre et configurer celui qui existe déjà, la duplication cesse d’être une anomalie économique. Elle devient une conséquence logique du système.

Et cela pourrait produire une quantité assez vertigineuse de logiciels presque identiques.

Évidemment, ce n’est pas gratuit

Il serait toutefois un peu facile de raconter que nous allons tous économiser des fortunes en abandonnant nos abonnements SaaS. Parce qu’il faut bien payer quelque chose.

Si je ne donne plus 15 euros par mois à un éditeur, je paie peut-être 20 euros à OpenAI, Anthropic ou un autre fournisseur. J’ajoute éventuellement quelques services techniques, un hébergement, une base de données, un nom de domaine. Si je pousse un peu plus loin, je peux aussi finir par payer GitHub, Vercel, Supabase ou toute autre brique nécessaire à mon petit écosystème.

Et surtout, je dépense du temps.

Beaucoup de temps.

Même lorsque l’IA produit une grande partie du code, il faut réfléchir au produit, tester, corriger, comprendre les problèmes, modifier les comportements et maintenir ce qui a été construit. Si j’additionnais sérieusement le nombre d’heures passées à développer certains de mes outils personnels, leur retour sur investissement serait probablement assez comique.

Mais le calcul n’est pas uniquement financier. Construire son propre outil peut aussi être un loisir, une façon d’apprendre, une manière de mieux comprendre son propre besoin ou simplement le plaisir assez grisant de pouvoir se dire : « Ce truc ne me convient pas. Je vais faire le mien. »

Cette possibilité existait déjà. Elle était simplement réservée à beaucoup moins de monde.

Un outil personnel n’est pas un produit

C’est également là que les prédictions sur la fin du SaaS rencontrent une limite assez importante. Créer un logiciel qui fonctionne pour soi n’a pas grand-chose à voir avec créer un produit.

Mon outil peut parfaitement correspondre à mes habitudes tout en étant totalement incompréhensible pour quelqu’un d’autre. Je connais ses défauts. Je sais pourquoi certains boutons se trouvent là. Je sais qu’il faut parfois recharger la page lorsqu’un comportement étrange apparaît. Je sais surtout pourquoi il existe et ce que j’attends de lui.

Un utilisateur extérieur, lui, ne sait rien de tout cela.

Faire un produit signifie comprendre des besoins différents du sien, concevoir des compromis, travailler la sécurité, la disponibilité, le support, les sauvegardes, la conformité, les intégrations et les évolutions. Cela signifie aussi gérer des cas auxquels on n’aurait jamais pensé tout seul et, détail légèrement important, convaincre quelqu’un d’autre d’utiliser le produit.

L’IA facilite considérablement la fabrication du logiciel. Elle ne supprime pas tout ce qui transforme ce logiciel en produit, et encore moins tout ce qui transforme ce produit en entreprise.

C’est une nuance importante, parce qu’elle explique pourquoi je crois peu à l’idée d’une disparition pure et simple des SaaS. Il y aura toujours une immense valeur à utiliser un produit robuste, maintenu, sécurisé et partagé, surtout dès que plusieurs utilisateurs, plusieurs équipes ou plusieurs entreprises doivent travailler ensemble.

En revanche, tout ce qui se situe en périphérie de ces besoins communs pourrait devenir beaucoup plus fragmenté.

La rareté change de camp

Pendant des décennies, la capacité à construire était rare. Il fallait des développeurs, des infrastructures, du financement et du temps. Une partie importante du travail produit consistait donc à s’assurer que cette capacité rare était investie sur les problèmes qui en valaient la peine.

Mais si construire devient progressivement abondant, la rareté se déplace.

Le problème n’est plus seulement de savoir si nous pouvons construire quelque chose. Nous le pouvons probablement. Le problème devient de savoir si nous devons le construire, si quelqu’un d’autre ne l’a pas déjà fait, si cette nouvelle variante apporte réellement quelque chose et si elle mérite d’être maintenue.

C’est peut-être là que la fameuse SaaSpocalypse masque quelque chose de beaucoup plus intéressant. Nous risquons moins de manquer de logiciels que d’en avoir beaucoup trop : des milliers de petits outils, de produits personnels, de clones et de variantes, parfois presque identiques, construits simultanément par des gens qui ignorent jusqu’à l’existence les uns des autres.

Une immense fragmentation du logiciel.

Une explosion cambrienne du software

La bonne métaphore n’est donc peut-être pas celle de l’apocalypse, mais celle d’une explosion cambrienne : une période pendant laquelle le nombre de formes de vie augmente brutalement. Certaines prospèrent, d’autres disparaissent, beaucoup se ressemblent, quelques-unes trouvent une niche et certaines finissent par s’imposer durablement.

L’IA pourrait produire exactement cela dans le logiciel.

Pas une disparition massive des produits, mais une multiplication massive des expériences, des prototypes, des micro-SaaS, des outils personnels et des applications fabriquées pour une entreprise, une équipe, une famille ou parfois une seule personne. Une immense couche de logiciel jetable, temporaire, expérimental ou ultra-spécialisé pourrait apparaître au-dessus du marché logiciel traditionnel.

Puis viendra le tri.

Parce qu’au milieu de cette abondance, la valeur ne sera peut-être plus dans la capacité à construire. Elle sera dans la capacité à découvrir ce qui mérite vraiment de l’être, à identifier ce qui peut devenir commun, à réunir autour d’une même solution des utilisateurs qui auraient autrement construit chacun la leur, à maintenir cette solution et à créer suffisamment de confiance pour que quelqu’un accepte de dépendre du produit d’un autre plutôt que de fabriquer le sien.

Pour les métiers du Product, le paradoxe est intéressant. Plus il devient facile de construire, plus la question de savoir quoi construire – et surtout quoi ne pas construire – prend de la valeur.

En somme, l’IA pourrait rendre le logiciel banal sans rendre le produit banal.

Et si la SaaSpocalypse devait réellement avoir lieu, elle pourrait produire un résultat assez paradoxal :

jamais nous n’aurons eu autant de logiciels.