J’ai remplacé en 20 minutes avec un LLM un micro-SaaS à 120 $ par an

• J’étais sceptique face à l’idée que les SaaS seraient remplacés par des LLM, jusqu’à ce que je remplace moi-même en 20 minutes, avec mon propre code, un service d’affichage de témoignages LinkedIn/X facturé 120 $ par an
• Le service remplacé était laissé à l’abandon avec un système de paiement cassé depuis 2023, et le support client se contentait d’envoyer des liens brisés
• En utilisant Codex, j’ai fait évoluer le système vers une approche modulaire qui sépare les témoignages dans un fichier JSON et génère le HTML au moment du build, avec un résultat visuel identique à l’existant
• Pour un développeur, c’est un travail rapide et intéressant, mais pour un non-développeur, la validation du code produit par un LLM peut constituer une barrière à l’entrée
• Les micro-SaaS statiques qui n’apportent pas de valeur continue sont les plus exposés au risque d’être remplacés en premier à l’ère des LLM

---

Scepticisme initial face à la thèse du remplacement des SaaS par les LLM

• L’idée centrale de cette théorie : les SaaS sont des produits purement logiciels, et comme les LLM réduisent drastiquement le coût et le temps nécessaires pour créer du logiciel sur mesure, la plupart des éditeurs SaaS finiraient par disparaître
• En réponse, on peut objecter qu’un logiciel RH comme Workday n’est pas juste un logiciel : c’est aussi un service qui garantit la conformité réglementaire selon les pays (indemnités de congé, fiches de paie, etc.) et qui est continuellement mis à jour pour suivre les évolutions internes comme externes

Expérience avec Shoutout.io et raison du départ

• J’ai utilisé Shoutout.io pendant 4 ans, pour 120 $ par an, afin d’afficher sur pragmaticengineer.com une section de témoignages basée sur des publications LinkedIn et X
• Je ne me connectais qu’environ une fois par an, la dernière fois pour vérifier la facture annuelle dans le cadre de mes notes de frais
• La section de paiement était cassée et laissée telle quelle depuis 2023 ; j’ai envoyé un e-mail au support, qui m’a renvoyé un lien brisé
• Le fait de ne même pas pouvoir vérifier le montant facturé l’année suivante a été le déclencheur direct de mon départ du SaaS

Un remplacement en 20 minutes avec Codex

• L’approche n’a pas consisté à reconstruire tout le SaaS existant, mais uniquement mon cas d’usage précis : afficher les témoignages, en ajouter de nouveaux et conserver le design
• J’ai demandé à Codex d’établir un plan pour supprimer la dépendance au tiers et héberger la solution dans un dépôt GitHub
• Les témoignages ont été gérés dans un fichier JSON séparé, puis convertis en HTML via une approche modulaire à l’étape de build au moment de la compilation
• Entre l’ajout de l’étape de build locale, la configuration du trigger de build Netlify, les tests, les ajustements UX, la création du schéma et le déploiement, l’ensemble a pris 20 minutes
• Le résultat final est visuellement identique à l’ancien, avec suppression totale de la dépendance à un service tiers
• Quand l’équipe support a enfin envoyé un lien valide (2 heures plus tard), la migration était déjà terminée

Ce que cela implique pour les ingénieurs logiciel

• Les développeurs sont déjà à l’aise pour utiliser la ligne de commande et des agents IA afin d’insérer des témoignages dans une codebase et d’en vérifier le résultat lors des futures mises à jour, mais pour les non-développeurs, la validation du code généré par un LLM reste une barrière à l’entrée
• Les développeurs peuvent « porter » un SaaS vers leur propre code beaucoup plus vite que les non-développeurs
  • Au premier essai, Codex l’a mal implémenté avec un modèle flexbox, et il a fallu décider soi-même du framework de layout UI
  • Un non-développeur pourrait aussi y parvenir, mais cela prendrait probablement plus de temps
• Réécrire soi-même une fonctionnalité tierce est à la fois amusant et formateur, et permet de constater concrètement les capacités réelles de l’outil

Ce que cela implique pour le business du SaaS

• Reconstruire tout un SaaS n’a rien à voir, en termes de difficulté, avec le fait de ne reconstruire qu’un cas d’usage spécifique
  • Shoutout propose plus de 10 fois plus de fonctionnalités, notamment l’ajout de citations depuis plus de 10 plateformes, l’authentification, les paiements, etc.
• Les SaaS statiques qui, une fois déployés, n’apportent pas de valeur continue sont les plus faciles à remplacer
  • À l’inverse, dès qu’il existe des fonctions de support métier en temps réel — conformité, analytique, alertes, etc. — le remplacement devient bien plus difficile
• La rentabilité du business d’achat-revente de SaaS pourrait diminuer
  • Shoutout a été créé en 2020 par un développeur indépendant, vendu en 2022 à un product studio, puis revendu en 2025 à un autre développeur
  • Du point de vue de l’utilisateur, rien n’a changé en dehors d’un système de paiement cassé
  • Les acquéreurs espéraient peut-être faire croître le chiffre d’affaires sans investir, mais lorsqu’un produit est laissé à l’abandon, les utilisateurs partent et arrive alors le moment où il devient facilement remplaçable avec un LLM
• À une époque comme celle-ci, laisser traîner des « Broken Windows » est bien moins tolérable qu’auparavant