L'IA ne tuera pas le SaaS

Dans la série “L’IA va prendre nos emplois”, l’épisode actuel est “L’IA va tuer le SaaS”. À cause du vibe-coding. À cause d’OpenClaw. À cause de toute nouvelle technologie non testée dans des applications réelles.

Ma réponse courte : non.

Enfin, si le SaaS en question est encore un wrapper GPT, une pâle copie de ses concurrents, ou toute forme de produit à faible valeur ajoutée, la réponse pourrait être oui. Pour le mieux. Sauf si vous êtes un Enshittificateur (chapeau au Conseil Norvégien des Consommateurs pour cette campagne).

Je vais en fait saisir cette occasion pour réfléchir à ce que je crois être un grand SaaS, et comment l’IA peut le soutenir plutôt que le détruire.

Cela fait plus de 12 ans que j’ai la chance de travailler à la construction de produits SaaS qui ont trouvé leur force unique (appelez ça USP si vous voulez, même si l’acronyme n’est pas terrible) dans une chose : l’expertise. Ce n’est pas que les produits passés sur lesquels j’ai travaillé n’en avaient pas, mais Blackfire.io et Bump.sh ont vraiment trouvé là leur avantage concurrentiel.

L’expertise est votre avantage, l’ICP est votre coin d’entrée

Vous construisez un produit SaaS à partir d’une vision produit et d’une vision marché, idéalement avec un maximum de chevauchement pour un ICP donné.

En d’autres termes, vous construisez une solution pour un problème spécifique et, tant que vous voulez la monétiser, à travers une découverte basée sur le dollar.

Autant que la plupart des fondateurs tech avec lesquels j’ai travaillé avaient une vision claire d’une innovation, ce qui a vraiment apporté une valeur extraordinaire à leur produit, c’est le retour de leurs utilisateurs et clients.

Vous pouvez construire un MVP à partir de rien, à cause d’un problème que vous avez vous-même vécu et croyez que beaucoup d’autres rencontrent aussi. C’est par exemple l’histoire derrière Bump.sh. Ça a commencé avec son fondateur cassant quelque chose en production parce que ses changements d’API ne pouvaient pas être correctement communiqués au reste de l’équipe. Il a donc construit un outil qui, pour n’importe quelle technologie d’API (REST, event-driven, et sur la roadmap SOAP, gRPC et GraphQL) publie une documentation d’API toujours à jour, avec son changelog généré automatiquement.

Votre produit grandit vraiment quand vous le confrontez à votre ICP. Quand nous avons commencé à chercher le bon ICP pour générer de la croissance, nous avons vite réalisé que seule une partie de cette vision avait un réel potentiel de croissance. Et c’est grâce aux innombrables conversations que nous avons eues avec les clients et les leads (prêts à payer pour l’outil). Cette parenthèse est en réalité essentielle : je ne sous-estime pas le retour des utilisateurs gratuits et des communautés Open Source (il y a beaucoup d’esprits brillants là-dedans), mais construire des fonctionnalités pour lesquelles les gens ne paieront pas signifie la mort de votre produit en quelques mois.

Nous avons réalisé que de nombreuses entreprises adoptaient encore (parfois avec difficulté) OpenAPI pour les APIs REST, et donc notre promesse de “gérer les contrats d’API pour toutes les technologies” était encore loin. Nous avons donc concentré nos efforts sur OpenAPI et REST, de telle sorte que nous avons construit une expertise reconnue (nous avons même publié la toute première antisèche OpenAPI, et enfin un exemple de contrat d’API décent et à jour, après le vieillissant “Pet Store”).

Cette expertise se voyait depuis le tout premier contact que nous avions avec les leads, jusqu’aux relations durables avec des acteurs tech clés du marché, comme Elastic, MongoDB, Redpanda et Motorola Solutions. Collectivement, ils nous ont aidés à construire une boucle vertueuse. Chacun de nos clients nous a aidés à construire notre roadmap vers un produit cohérent avec un positionnement clair.

C’est aussi quelque chose que j’ai vécu de l’autre côté moi-même. J’ai essayé des outils incroyables qui m’ont aidé à me poser les bonnes questions sur ma pratique. Des questions que j’aurais autrement laissées de côté, me conduisant à échouer dans mes tâches.

Un outil SaaS est construit à partir des besoins d’une communauté plus large, qui peut penser à des besoins et des problèmes auxquels vous n’avez pas encore pensé, et donc vous aider à les résoudre de façon proactive. Et les solutions viennent de l’expertise des créateurs du SaaS, qui sont entièrement dédiés à résoudre le problème (pas un travail à mi-temps comme vous le feriez en vibe-codant un projet parallèle).

Construire ou acheter, l’équation n’a pas beaucoup changé

Il ne fallait pas attendre l’explosion de l’IA de ces dernières années pour faire face à une telle question : construire ou acheter ? Elle a toujours été là.

Maintenant gardez ça à l’esprit. Même si les projets Open Source font actuellement face à des défis massifs avec les agents IA qui permettent aux gens d’ignorer leurs dépôts (ce qui complique la monétisation), une chose était vraie et je crois le sera toujours : il était possible de monétiser les projets Open Source avec des versions payantes parce que le code n’est que l’implémentation. C’est le “comment”, et un peu du “quoi”, mais pas le “pourquoi”.

Vous aviez l’option de choisir entre “acheter” et “prendre un projet Open Source ou construire moi-même”. Vous avez maintenant l’option de choisir entre “acheter” et “construire de zéro avec l’IA”. Les choses n’ont pas beaucoup changé ici. Sauf peut-être que vous ratez l’intelligence collective que votre LLM pourrait ne pas trouver (c’est toujours une boîte noire, aucune garantie qu’il ait récupéré les bonnes informations sauf si vous le lui dites).

Construire est maintenant bien moins cher, grâce à l’IA et au “vibe-coding”. Mais construire signifie :

• vous faites toujours autre chose que votre travail principal
• ce n’est jamais juste construire, c’est aussi entretenir et faire évoluer (pensez au “Coût Total de Possession”)
• vous ne bénéficiez pas de l’intelligence collective : c’est seulement vous derrière votre ordinateur, filtré par votre LLM et la vision en tunnel qu’il induit.

Je ne veux pas dire que vous ne devriez jamais construire vous-même. Je dis simplement que vous devriez être extra prudent, car maintenant c’est plus facile et plus tentant. Vous pourriez très bien faire une erreur plus vite en commençant seul.

Faire des choses qui n’auraient pas été faites autrement

OK, laissons un peu de place à l’IA. Dans certains cas, je crois vraiment que c’est la bonne solution. Et j’ai mon propre exemple. Récemment, j’ai reconstruit mon site web.

C’était auparavant un blog Wordpress. En décembre, après tout le travail fait sur ce sujet chez Bump.sh, j’ai réalisé que Wordpress était trop limité pour mon cas d’usage, sauf à payer des montants élevés en abonnements et quelqu’un pour faire un thème qui répondrait à mes besoins.

Maintenant il tourne sur Hugo, et trouve ses racines de design dans Hugoplate comme template. Mais clairement, Claude a aidé. Depuis une version initiale qui ressemblait BEAUCOUP à la démo Hugoplate, j’ai utilisé Claude Code pour faire d’innombrables ajustements.

Maintenant bien sûr, comme vous le voyez sur la capture d’écran, il y a ce CTA “Need Customization?” sur la démo Hugoplate. Suis-je coupable d’avoir utilisé un LLM plutôt que de cliquer dessus et de payer pour ma personnalisation ? Malheureusement, je ne pouvais tout simplement pas me permettre le budget, en venais juste de créer mon entreprise en tant qu’indépendant.

Pour moi le compromis “ne pas construire et ne pas acheter” s’est rapidement transformé en “construire ou ne pas acheter”, avec une décision évidente.

Et dans ce cas, je n’étais tout simplement pas le bon ICP pour Zeon Studio.

C’est aussi quelque chose que l’IA n’a pas changé.

Bien sûr, on peut toujours se demander : qu’en est-il des grandes entreprises qui ont le budget pour ça ? Qu’en est-il de tous leurs employés qui vont commencer à construire des petites choses là où un tiers l’aurait fait pour eux, ou qui les auraient conduits à embaucher davantage ?

Remplacer, responsabiliser, ou simplement changer le problème ?

Croyez-moi, je suis très sensible à ces deux questions. Et je n’aurai pas d’opinion tranchée à ce sujet. Peut-être juste une question de plus : laisser les employés actuels faire leurs “outils rapides et corrections” par eux-mêmes pourrait-il aider à stabiliser le marché de l’emploi ? Cela pourrait-il nous aider à éviter la folie qui s’est produite après le Covid, où des investissements massifs ont été faits, créant des centaines de milliers d’emplois du jour au lendemain, pour que quelques mois plus tard les entreprises réalisent avoir tout fait de travers et licencient massivement ?

Une source d’inspiration, d’un article de la Harvard Business Review : “L’IA ne réduit pas le travail, elle l’intensifie”.

C’est aussi mon expérience (je serais curieux d’entendre si vous avez vécu une expérience différente) : j’ai commencé à faire de nouvelles choses. J’ai été plus rapide sur d’autres. Je n’aurais jamais engagé quelqu’un pour le faire pour moi ; ça m’a juste aidé à être plus efficace. Et pourtant, régulièrement, je me demande :

• “Oups, ai-je bien vérifié cette dernière phrase que j’ai envoyée par email après avoir demandé à mon bot de peaufiner ma formulation ?”
• “Aurais-je dû passer tout ce temps à jouer avec mon bot, ou aurais-je été bien plus rapide à prendre une décision seul ?”
• “Pourquoi suis-je si épuisé aujourd’hui ?” (avant de réaliser que j’ai passé toute la journée à livrer d’innombrables choses, avec presque aucune pause)

L’IA, c’est poser la bonne question

Après avoir fait ma due diligence, je peux aussi affirmer une chose : il n’y a aucune magie avec l’IA. Premièrement, comme je l’ai mentionné, c’est une calculatrice élaborée. Mais c’est davantage Artificiel qu’Intelligence.

J’ai maintenant utilisé ChatGPT, Gemini, Mistral et Claude. J’ai créé un petit site web (mais avec des exigences strictes), j’ai créé du contenu marketing et du contenu d’outreach commercial hautement personnalisé, j’ai automatisé des tâches.

Parmi les outils que j’ai utilisés qui proposent directement de “laisser l’IA travailler pour vous”, j’ai toujours été extrêmement prudent. Le principal défaut que j’y vois est que, surtout quand vous voulez commencer à automatiser une tâche donnée, vous définissez un prompt et l’oubliez. C’est comme créer un GPT, un Gem et équivalents, le laisser vous donner le résultat et ne faire aucune vérification.

Eh bien, c’est peut-être surestimer soi-même. Avez-vous posé la bonne question ? N’avez-vous jamais eu cette situation, dans une conversation avec une autre personne, où vous avez dit “désolé, je n’étais pas clair” ?

Sans même parler des hallucinations, votre question doit être super précise si vous voulez faire confiance à la réponse d’un LLM. Oui, il existe de bonnes méthodes pour minimiser les risques lors de l’écriture d’un prompt, comme CODE (Contexte, Objectif, Détails, Exemples). Mais :

1. itérer sur le résultat peut corriger ce qui a mal tourné, et ça arrive assez souvent
2. itérer sur le résultat peut vous mener bien plus loin que vous ne l’imaginiez
3. dans tous les cas, votre expertise, issue de tout le travail que vous avez fait, de toutes les conversations que vous avez eues, vous permettra de poser des questions que d’autres n’auraient pas été capables de formuler.

L’IA peut vous compléter, mais vous devez lui donner le bon point de départ.

Attendons, pour prendre du recul

L’IA, les LLMs et tous les hashtags associés : tout bouge extrêmement vite en ce moment, changeant du jour au lendemain. Tout le monde essaie d’en faire sens. Beaucoup sont soit dans une peur de manquer quelque chose, soit en train d’essayer de trouver cette opportunité qui les rendra millionnaires.

Anecdote amusante : les choses bougent tellement vite que Claude et ChatGPT n’avaient aucune idée de ce qu’était OpenClaw dans des conversations que j’ai eues avec eux au cours des deux derniers jours. J’ai dû les forcer à vérifier. Alors que je voyais ce matin un article affirmant que son adoption explosait.

“Une fois que l’excitation de l’expérimentation s’estompe, les travailleurs peuvent trouver que leur charge de travail a discrètement augmenté et se sentir étirés par la jonglerie de tout ce qui est soudainement sur leur assiette.” (HBR). Et tous les inconvénients qui vont avec.

L’IA ne tuera pas le SaaS. Elle donne aux créateurs de SaaS des super-pouvoirs. Elle vous donne des super-pouvoirs. Assurez-vous juste qu’elle ne vous rende pas Enshittificateur.

Image de une par Tahlia Doyle.