- L’intégration de SaaS est censée permettre aux développeurs de se concentrer uniquement sur leur produit, mais en réalité, il existe à chaque fois cinq coûts cachés (taxes)
- Avant l’adoption, des coûts en temps, en complexité et en charge mentale apparaissent en continu à chaque étape : découverte, inscription, intégration, développement local, exploitation
- En choisissant non pas un SaaS, mais une plateforme intégrée (Cloudflare, Supabase, etc.), on peut réduire fortement ces coûts répétitifs et cette complexité
- Le vendor lock-in étant une réalité inévitable, il vaut mieux préserver son flux de développement (Flow) sur une seule plateforme intégrée plutôt que de mélanger plusieurs services
- Au final, le plus important n’est ni le framework ni le service en lui-même, mais le logiciel que je veux construire
Le SaaS n’est que du vendor lock-in avec un meilleur branding
- On dit souvent aux développeurs de « se concentrer uniquement sur le développement du produit », mais dans les faits, adopter des fournisseurs SaaS pour l’auth, les files d’attente, le stockage de fichiers ou l’optimisation d’images entraîne diverses contraintes
- Il n’y a pas que le coût financier : il y a aussi la perte de temps, les frictions et la fatigue mentale.
1. Taxe de découverte (Discovery Tax)
- Avant d’adopter un service SaaS, il faut comprendre quelles fonctionnalités et quelle valeur il vend réellement
- Il faut évaluer des éléments détaillés comme le périmètre de résolution du problème, la compatibilité avec la stack existante, un prix raisonnable au regard de l’échelle, la clarté de la documentation ou encore des choix d’implémentation atypiques
- Ce travail de recherche se partage mal, se répète difficilement à partir d’expériences passées, et repose en grande partie sur des décisions subjectives
- Il faut soi-même juger si le message marketing correspond à son besoin et si le service sera réellement utile
2. Taxe d’inscription (Sign-Up Tax)
- Une fois le service choisi, il faut fournir son e-mail et ses informations de carte bancaire
- Il faut vérifier si la facturation à l’usage est possible ou si seul un lock-in par abonnement est proposé
- Les structures tarifaires opaques posent problème, par exemple quand l’accès au dashboard pour les membres de l’équipe entraîne des coûts supplémentaires
- Il faut aussi vérifier s’il est possible de tester sans essai gratuit, ou si un paiement est exigé dès le départ
- Avant même d’écrire une ligne de code, une relation contractuelle se crée déjà avec le fournisseur
3. Taxe d’intégration (Integration Tax)
- Lors de l’adoption réelle, il faut forcément lire la documentation, installer des bibliothèques, brancher le framework et résoudre des problèmes supplémentaires hors documentation
- On se heurte souvent à des conflits d’outils ou à des problèmes imprévus
- Quand un SaaS ne vise que le plus petit dénominateur commun, davantage de travail est nécessaire avec des stacks récentes ou des environnements spécialisés
4. Taxe de développement local (Local Development Tax)
- On ne sait pas toujours clairement si le service SaaS prend en charge l’environnement local
- Il faut pouvoir disposer d’un émulateur local ou stubber le service pour les tests
- Pour vérifier certaines fonctionnalités, des mécanismes comme le tunneling cloud peuvent être nécessaires, ce qui complique la configuration de l’environnement
- Il devient inévitable d’avoir des configurations distinctes entre production, staging et local
5. Taxe de production (Production Tax)
- Après l’intégration du service, de nouvelles contraintes apparaissent en environnement de production
- Il faut aussi gérer l’usage éventuel en staging ou en environnement de preview de PR, la gestion des clés API, le monitoring, les logs, les alertes, etc.
- Il faut se préparer à des erreurs ou incohérences absentes en développement mais présentes uniquement en exploitation réelle
- La responsabilité du maintien de la stabilité du service finit, au bout du compte, par retomber sur le développeur
Conclusion
- Le slogan du SaaS moderne, c’est « ne réinventez pas la roue », mais chaque service ajouté apporte aussi sa propre friction
- Adopter un service n’est pas une simple intégration, c’est un contrat ; cela augmente les dépendances et transforme l’architecture. Le vendor lock-in est inévitable, et le remplacement d’un service implique souvent une réécriture importante du code.
- Ainsi, plutôt que de répéter sans cesse ce type de décision, il est plus efficace de choisir dès le départ une plateforme tout-en-un
- Ce qui compte, c’est le logiciel que le développeur veut réellement construire
- Des plateformes intégrées comme Cloudflare et Supabase fournissent base de données, files d’attente, images et stockage dans le même environnement, ce qui réduit fortement les taxes évoquées plus haut.
- Plus besoin de passer d’un fournisseur à l’autre en permanence (context switching)
- Les problèmes liés à la manipulation des clés API deviennent moins fréquents
- Le besoin de gérer la compatibilité et les branches de configuration selon les environnements est minimisé
- Elles offrent une expérience d’intégration cohérente entre développement et production
- Ces plateformes donnent l’impression que tout tourne sur la même machine et réduisent au minimum la distance entre le code et les services, ce qui permet de retrouver cette fluidité de développement (« Flow ») qu’aucun SaaS ne parvient à offrir.
L’important n’est pas le choix du framework ou du service, mais le logiciel que je veux construire et la préservation de ce flux (Flow)
2 commentaires
Supabase est souvent cité comme un bon exemple, mais dans ce cas, quels SaaS faudrait-il éviter ?
Avis Hacker News
Cela revient à voir le « rent seeking » d’Adam Smith à l’ère moderne, mais à une échelle gigantesque
Je pense que ce type de comportement économique est nuisible socialement, qu’il faut l’éviter et même le criminaliser
À l’inverse, l’extrême du logiciel gratuit pose aussi un problème économique, car l’effort du créateur du logiciel n’est pas proportionnel à la valeur obtenue par l’utilisateur
L’idée défendue est qu’il faut acheter le logiciel séparément et conclure à part un contrat de service, afin que chacun apporte une valeur réellement distincte
Le problème, avec le SaaS, c’est que tout cela est regroupé en un seul bloc, et que l’emballage finit par devenir anormalement déformé par rapport au service lui-même
Si j’y croyais à ce point, l’idée serait de créer moi-même un SaaS puis de monter une entreprise qui le déploie et l’exploite en on-premise, tout en le proposant à un tarif comparable au SaaS actuel
Si des entreprises pouvaient conserver le contrôle de leurs données, éviter le vendor lock-in, tout en offrant la même qualité, les mêmes garanties et le même prix que le SaaS, elles pourraient dominer le marché
Je me pose souvent cette question : ne suffirait-il pas de fournir uniquement le binaire et de laisser les utilisateurs l’exécuter sur AWS, GCP ou Cloudflare Workers ?
De mon point de vue, le SaaS est séduisant en tant que développeur, mais je le déteste en tant que consommateur, ce qui me place dans un dilemme éthique
Si je vendais du logiciel, que se passerait-il si l’utilisateur le redistribuait sans autorisation ? Je ne pourrais pas contrôler la distribution comme avec le SaaS
Je suis partisan du FOSS (open source), mais comme vous le dites, ce modèle a aussi des problèmes économiques
Je réfléchis aussi à des systèmes du type émission de licence via GitHub Sponsors, ou à un modèle où certains projets seraient sous SSPL, puis passeraient en BSD/MIT en cas d’achat de licence, un peu comme l’ancien Redis
Mais je me demande si des gens achèteraient réellement dans ce cadre si je l’appliquais moi-même ; j’envisage aussi de prendre en charge les deux approches, mais je n’ai pas de réponse claire et je cherche des conseils
À titre de référence, j’ai créé des projets comme un outil permettant à n’importe qui de créer gratuitement une cryptomonnaie, une fonctionnalité pour transformer YouTube en blog, ou encore un stockage illimité utilisant la communauté YouTube et les vidéos comme alternative à Google Photos, tout en réfléchissant aussi à des améliorations en matière de confidentialité. Si vous avez des idées de monétisation, je suis preneur
La plupart des SaaS impliquent, du point de vue du fournisseur, des coûts continus d’hébergement, de support, de R&D, etc.
J’ai donc du mal à adhérer à la logique selon laquelle cette structure relèverait du « rent seeking »
On ne peut pas dire que tout le SaaS relève du rent seeking ; en revanche, le « stickiness » du logiciel lui-même s’en rapproche par nature
La plupart des éditeurs SaaS recherchent cette stickiness, mais ce n’est pas une propriété propre au SaaS
De mon côté, je vends mon produit SaaS à des clients prêts à l’acheter à un prix raisonnable sur le marché
Le vendor lock-in, en général, c’est ce qu’on ressent quand, en interne, on demande « pourquoi n’adoptons-nous pas l’outil NEWTHING ? » et qu’on nous répond qu’on est déjà engagés pour cinq ans avec Oracle, Microsoft, IBM ou Salesforce, donc qu’on n’a pas vraiment le choix
Puis, au bout d’une dizaine d’années, on finit réellement complètement attaché à ce fournisseur, dans une situation où il devient impossible d’en changer
Si l’entreprise survit dix ans, c’est presque une bénédiction, ou au pire un problème ennuyeux ; mais au démarrage, je conseillerais plutôt de ne pas perdre de temps à choisir une multitude d’outils et de sélectionner rapidement une plateforme sur laquelle se concentrer
Même dans ce cas, certains estiment qu’il vaut mieux abstraire ces services derrière des interfaces standardisées
Une fois cette abstraction en place, il suffit plus tard de fournir une implémentation alternative pour passer à un autre service
C’est une approche tournée vers l’avenir, mais beaucoup d’entreprises ne s’y préparent pas assez aujourd’hui
Je pense que la réduction au minimum des dépendances est l’un des facteurs les plus importants pour améliorer la pérennité d’un produit et d’une activité
Dans mon précédent poste, j’étais chargé d’intégrer à notre produit une expérience de signature électronique de type DocuSign
Nous avons discuté avec les principaux fournisseurs, comme DocuSign et Adobe, mais nous avons constaté que leurs API avaient trop de contraintes et répondaient mal aux besoins du produit et des clients ; nous avons donc décidé de l’implémenter nous-mêmes en interne
En général, recréer un outil comme DocuSign est une mauvaise idée, mais notre produit bénéficiait déjà de la confiance de nos clients, donc la barrière à l’adoption était faible
La mise en œuvre en interne a représenté beaucoup de travail au départ, mais lorsqu’il a fallu apporter rapidement de petites adaptations réellement alignées sur les besoins des clients, nous avons pu réagir vite ; avec un fournisseur externe, cela aurait été une bien plus grosse opération, donc ce choix était le bon
Je comprends l’auteur comme disant que le SaaS est du vendor lock-in et qu’il ne faut donc pas en acheter
Pourtant, dans le texte, il recommande justement de tout miser sur une plateforme précise, Cloudflare
Au final, quel que soit le choix, tout devient lock-in, et même avec l’open source ou le self-hosting, remplacer une solution implique souvent de réécrire une grande quantité de code
Il y a toutefois une différence entre utiliser des fonctionnalités spécifiques à un fournisseur et un « vrai lock-in » : le lock-in apparaît quand changer coûte plus de temps et d’argent que de conserver l’existant
Si le logiciel est faiblement couplé et bien cohésif, il est plus facile de remplacer une partie précise
Parce que lorsque l’interface est simple, le remplacement l’est aussi
Donc le choix consistant à dire « tout est lock-in, alors autant s’attacher encore plus fermement à une seule plateforme » est confortable pour les développeurs, mais c’est une mauvaise stratégie du point de vue de la direction ; il faut se concentrer sur la flexibilité de l’entreprise et sa capacité à évoluer
Du point de vue d’un entrepreneur, il faut choisir des solutions qui apportent à l’entreprise de la flexibilité et une capacité de changement ; c’est pour cela qu’il est absurde de se retrouver lié à un SaaS sans alternative
Au démarrage, ou lorsqu’il n’y a pas encore de revenus, il est plus avantageux d’utiliser une plateforme qu’un SaaS, et quand l’entreprise grandit et entre dans une phase de scale, il faut alors penser aussi aux changements technologiques de long terme
J’utilise souvent Cloudflare Workers et j’écris mon code pour qu’il reste portable partout
On peut aussi l’exécuter localement avec
wrangler dev, et en pratique il peut fonctionner en pure Node/Bun/Deno sans modifications majeuresL’OP (l’auteur du post) ne s’oppose pas au SaaS en soi — puisqu’il recommande au final des solutions as a service comme Cloudflare ou Supabase — ; son vrai point concerne plutôt le coût opérationnel et la charge relationnelle liés au fait de signer et de gérer trop de contrats avec trop de fournisseurs
Moins il y a de fournisseurs et de dépendances, plus l’exploitation est simple
Imaginer implémenter chaque fonctionnalité uniquement avec la bibliothèque standard est une projection trop idéale, et en pratique extrêmement difficile
L’idée principale est de recommander l’usage d’une seule plateforme au départ, plutôt que de mélanger une multitude de services dès le début
Si je préfère Cloudflare, c’est parce que les bindings y sont standardisés à la manière de
fetch, et quefetchme donne dans l’univers du web une sensation proche de celle des pipes UnixCertains y voient une ironie : vouloir éviter le vendor lock-in en mettant tout sur une seule plateforme, au point de se lier encore plus fortement à une seule entreprise
Le SaaS a lui aussi un coût de dispersion, une sorte de « taxe »
À l’inverse, on peut considérer que cette discussion relève presque d’un plaidoyer pour l’open source
Avec l’open source et le self-hosting, la plupart des « taxes » évoquées dans le texte — découverte, inscription, intégration, coûts liés au développement local — disparaissent
Quant à la production tax de l’open source, elle peut selon moi être compensée par un écosystème vivant, des plugins et un écosystème modulaire
En reprenant l’analogie entre religion et secte : si l’on peut exporter ses données dans un format standard et partir, alors ce n’est pas du vendor lock-in
Les clients se sentent moins prisonniers lorsqu’ils peuvent récupérer leurs propres données, mais le problème est que trop de services SaaS rendent cela impossible
Pour l’instant, je publie surtout sous MIT et je garde les éléments importants en privé
La limite du SaaS, c’est qu’il empêche les clients de bénéficier des avantages du « coût marginal quasi nul » du logiciel
Les acteurs du SaaS répercutent certes une partie de ce gain en baissant les prix, mais dès qu’on atteint une base d’utilisateurs suffisante et un prix unitaire élevé, ce sont au final les utilisateurs du SaaS qui y perdent
En revanche, au début de la vie d’une startup, construire soi-même est un choix imprudent, et le SaaS est une stratégie très intelligente lorsqu’on est dans une phase de « survie » et de minimisation des coûts initiaux
Ce n’est qu’une fois l’entreprise développée et le SaaS profondément intégré au quotidien que surgissent les problèmes de lock-in, de migration et de coûts de transition
En ce sens, le problème du SaaS est aussi, au fond, un effet secondaire du succès
C’est précisément pour cela que ce modèle SaaS est si répandu
C’est un business model extrêmement séduisant : il génère des revenus récurrents comme une rente, tout en donnant du pouvoir sur la fixation des prix