Quand l'IA construit presque tout, que reste-t-il au SaaS ?

Quand le code ne coûte presque plus rien, ce ne sont plus les fonctions qui protègent un SaaS mais les données, la confiance et la distribution, et qui lance un nouveau produit peut dépenser plus d’argent et de temps pour être trouvé que pour le construire.

Le SaaS (un logiciel qu’on paie par abonnement et qu’on utilise par Internet) continue d’exister. Mais continuera-t-il à se vendre quand l’IA écrira presque tout le code ? Je me pose souvent la question ces temps-ci. Ce texte n’est pas un article d’actualité, c’est mon opinion.

Des outils comme Claude Code ont accéléré la fabrication de logiciels de façon presque anormale. Ce qui prenait des semaines ou des mois se fait en quelques jours. Si l’on peut expliquer une idée à voix haute, brancher quelques API et avoir un produit qui tourne avant lundi, rien n’empêche quelqu’un d’autre de construire la même chose.

Prenons un SaaS simple à 29 dollars (environ 26 euros) par mois. Si sa fonction centrale peut être refaite avec un bon prompt et quelques heures de travail, qui continuera à payer ?

Ce qui a encore aggravé cette inquiétude, c’est REA, un projet open source dont on parle beaucoup sur GitHub.

REA (Reverse Engineer Anything) est un outil open source sous licence MIT qui relie des agents de programmation IA comme Claude Code, Codex et Cursor à des outils de rétro-ingénierie. La rétro-ingénierie consiste à démonter un programme dont on n’a pas le code source pour comprendre comment il fonctionne. L’agent utilise des outils d’analyse comme Ghidra, Hopper et IDA (des programmes qui rendent un fichier exécutable lisible) et explique, preuves à l’appui, le comportement d’un exécutable ou d’une appli. Le résultat n’est pas le code source d’origine, mais du pseudo-code (une réécriture lisible qui ressemble à du code) et de l’assembleur (des instructions proches de la machine). De plus, REA n’examine que ce qui se trouve côté utilisateur : applis de bureau ou mobiles, code front-end des sites web, micrologiciels. Le code serveur d’un SaaS qui ne tourne que chez l’entreprise n’est pas concerné.

Certains articles affirment que le projet a dépassé les 100 000 étoiles en une semaine, mais les chiffres varient selon les sources et je n’ai pas pu confirmer le nombre exact. Certains développeurs ont réagi par « On peut donc recopier une appli à partir de son binaire ? » et « Le fossé protecteur du logiciel (l’obstacle qui tient les concurrents à distance) a disparu. »

Ce qui m’a marqué n’est pas la performance de l’outil mais le changement de perception. Avant, « programmer est difficile » servait de rempart. Puis « il suffit de le construire » a vacillé, et maintenant s’ajoute « on peut observer le comportement sans le code source ». Entre une démo et un vrai produit, l’écart reste grand. Pourtant, quand on distribue un produit sur les appareils des utilisateurs, comme une appli de bureau ou mobile ou une extension de navigateur, il devient difficile de supposer sans y penser que « ma logique est secrète ». Le code qui reste sur un serveur ne peut pas être lu avec cet outil, mais les écrans et le comportement visibles se copient aussi facilement qu’avant. La valeur de savoir construire et celle de savoir cacher diminuent toutes les deux. Ce qui prendra leur place, je ne peux pas encore le dire.

La croissance du SaaS existant va-t-elle durer ?

Un SaaS bien installé ne disparaîtra pas du jour au lendemain. Les clients ont déjà mis leurs données et leurs flux de travail dedans, et, dans une entreprise, la phrase « changeons pour autre chose » est déjà un coût en soi. Les connexions, les droits, les audits et le support ne se remplacent pas du jour au lendemain par un clone (une copie refaite à l’identique) fait un week-end.

Ce qui change, c’est à quoi la croissance est attachée. Les produits qui ne se distinguaient que par leurs fonctions subiront d’abord la pression sur les prix. Les abonnements par siège, qui font payer chaque utilisateur, risquent aussi de moins bien fonctionner quand l’automatisation réduit le nombre de sièges. À l’inverse, un produit qui prend en charge jusqu’au bout le travail d’un secteur précis peut devenir plus solide. À mesure que les données s’accumulent et que les connexions s’approfondissent, l’abonnement mensuel devient moins de l’argent pour des fonctions et plus de l’argent pour ne pas porter soi-même le problème. Ce que REA a ébranlé, c’est l’idée que « personne ne voit le code, donc c’est sûr ». Pas l’idée que « nos données sont ici et nous travaillons chaque jour sur cet écran ».

Si l’on construit du neuf, quels risques prendre ?

Dire que construire est devenu bon marché, c’est dire que se lancer avec la même idée l’est devenu aussi. Je vois quatre risques.

Copie et prix.
Un produit fait pendant un week-end peut être refait pendant un week-end. La durée de vie de « j’ai été le premier » est devenue courte. Je crois que 29 à 99 dollars (environ 26 à 88 euros) par mois restent possibles. Mais si la raison de ce prix est « c’est difficile à programmer » ou « le code source est fermé », cela m’inquiète. Dès que les clients sentent qu’ils pourraient construire quelque chose de similaire, l’abonnement devient un luxe. Il faut convaincre qu’on prend en charge à leur place le coût de construire, de corriger et de protéger.

Maintenance.
Les démos sont faciles, l’exploitation reste difficile. Pannes, sécurité, paiements, demandes des clients, changements de modèles ou d’API : même si l’IA écrit le code plus vite, la question « qui est responsable ? » reste sans réponse. En solo, tout retombe sur une seule personne.

Choix du marché.
Vendre une fonction mince sur un marché large, c’est se heurter tout de suite à des outils plus gros et à des copies moins chères. Creuser un problème étroit donne un marché plus petit, demande de connaître le secteur et prend du temps pour bâtir la confiance. L’envie de voir vite du chiffre d’affaires et celle de choisir une place difficile à copier tirent souvent dans des sens opposés.

Distribution.
Plus il est facile de construire, plus il y a de produits que personne ne trouve. Aujourd’hui, un produit construit mais invisible est comme inexistant. Sans canal, même un produit fini et bien fait reste en stock.

Les produits affluent : le marketing va-t-il coûter plus cher ?

Je pense que oui, du moins si l’on veut acheter le même niveau d’attention. L’offre de produits a grandi, mais l’attention des gens, les résultats de recherche et la place dans les fils n’ont pas grandi autant. Quand s’empilent des pages d’atterrissage (la première page qui présente un produit) et des « ___ fait avec l’IA » qui se ressemblent, il en coûte plus aux clients pour choisir et plus aux vendeurs pour se faire retenir.

Quand le développement devient moins cher, des développeurs indépendants qui ne pouvaient pas payer de marketing peuvent s’acheter de la publicité, mais ils sont aussi plus nombreux à enchérir. Le goulot d’étranglement passe du développement au coût d’acquisition client (CAC, l’argent qu’il faut pour amener un nouveau client). Pour un produit à 29 dollars par mois, une petite hausse du CAC allonge le temps nécessaire pour rentrer dans ses frais. Construire prend un week-end, le marketing peut prendre des mois.

Un secteur étroit, un réseau de clients existant, le bouche-à-oreille et une expertise qui reste longtemps visible dans la recherche subissent moins la hausse des prix publicitaires. Cela ne veut pas dire que le marketing est bon marché, mais qu’on possède déjà sa distribution ou qu’on la bâtit soi-même.

Faut-il bien se faire voir des entreprises qui détiennent le trafic ?

Si le coût du marketing monte, la question suivante est de savoir s’il faut faire la queue devant les plateformes qui rassemblent les gens. Moteurs de recherche, boutiques d’applications, réseaux sociaux, places de marché, boutiques de modules des grands éditeurs de SaaS et, bientôt, les endroits où les assistants IA font des recommandations : le trafic se concentre devant quelques portes. Pour passer, il faut s’adapter à leurs règles, à leurs frais et à leur logique de recommandation. « Bien se faire voir » n’est pas de la flatterie, c’est plutôt se demander si son produit est aligné avec les intérêts de cette entreprise.

Il y a un prix à payer. Si les classements ou les règles d’API changent, ou si la plateforme ajoute elle-même une fonction semblable, la visibilité peut disparaître en une nuit. Pourtant, il est difficile de s’en passer. Rassembler des abonnés avec sa seule distribution est un travail plus lourd que le développement. Je pense donc que confier son trafic à une seule porte, c’est faire de cette porte son entreprise. S’appuyer sur une plateforme tout en gardant en main une partie de la relation client, des données et des voies de sortie, c’est un compromis. Lui confier toute sa visibilité, c’est de la location.

Faut-il de l’argent pour développer ?

Pour le seul développement, c’est plutôt l’inverse. Les outils de programmation IA, le cloud, les paiements et les modèles ont abaissé le seuil pour construire un produit et le mettre en ligne. En 2026, au stade du prototype, « il faut des fonds pour développer » est de moins en moins vrai.

Ce qui reste est une autre sorte d’argent : de quoi se faire voir, attendre, et encaisser pannes et clients. Quand le CAC monte, que les frais de plateforme s’ajoutent et que la guerre des prix commence, il faut de la trésorerie pour tenir jusqu’au bénéfice. L’usage de l’argent passe de l’achat de code à l’achat de temps. L’autofinancement (grandir avec l’argent qu’on gagne soi-même, sans investisseurs) n’est pas devenu impossible : le tronçon à franchir est passé du développement à la distribution et à la survie. Avec beaucoup d’argent, on peut acheter ce tronçon avec de la publicité et des recrutements. Avec peu, il faut choisir plus tôt une distribution moins chère : un marché étroit, des relations existantes ou du contenu.

Pour conclure

Je n’ai pas encore de réponse. Mais la direction est un peu plus nette. Pour qui construit du neuf, le risque est moins l’échec technique que de se retrouver du côté de ce qui est facile à construire, facile à copier et facile à noyer. Ce que d’autres ne rattrapent pas en un week-end, c’est la compréhension du problème du client, les connexions et les données, la confiance et la distribution. Ces quatre éléments ont toujours été en dehors du code. Un produit doit donc, selon moi, répondre dès le départ à trois questions : « Pourquoi cet abonnement est-il difficile à résilier ? », « Comment sera-t-il découvert ? » et « À qui ne louerai-je pas cette visibilité ? ». Construire est devenu bon marché, et ce qui vient après est devenu cher.

Ce qui pourrait changer pour les développeurs

Ce qui suit est notre estimation et nos conseils, fondés sur le point de vue personnel de ce texte.

• Vérifiez ce qui justifie votre prix. Regardez si le stockage des données, les connexions, la responsabilité et la confiance le portent, plutôt que « c’est difficile à programmer » ou « le code source est fermé ».
• Si vous distribuez sur les appareils des utilisateurs, avec une appli de bureau ou mobile ou une extension de navigateur, supposez que la logique centrale peut être lue de l’extérieur et décidez quelles parties déplacer vers un serveur.
• Décidez avant de construire où vous rencontrerez vos clients. Ne confiez pas toute votre visibilité à une seule plateforme et gardez en main une partie de la liste de clients et des données.
• Si l’argent manque, choisissez d’abord une distribution qui coûte peu en publicité : un marché étroit, des relations existantes ou du contenu.

À surveiller ensuite

• Dans quelle mesure des outils de rétro-ingénierie comme REA servent réellement à copier des produits commerciaux, et quelles règles les éditeurs et les plateformes mettent en place en réponse.
• Si les critères selon lesquels les assistants IA et les boutiques d’applications recommandent des outils deviennent publics.

La conversion en euros s’appuie sur le taux de change du 16 octobre (1 dollar ≈ 0,89 euro) et n’est qu’un ordre de grandeur.

Sources

• REA: Reverse Engineer Anything (GitHub)