L'expression « SaaS is dead » fait beaucoup parler d'elle ces derniers temps. L'argument est le suivant : puisque nous sommes dans une ère où l'IA peut écrire du code, nous devrions arrêter de payer des abonnements SaaS chaque mois et simplement construire en interne ce dont nous avons besoin.
Chez Emooove, mon entreprise, nous avons passé ces derniers mois entièrement consacrés au développement de nos systèmes internes. Pour l'avoir réellement fait, j'ai connu à la fois les réussites et les leçons douloureuses. Aujourd'hui, je souhaite partager mon point de vue sur le discours « SaaS is dead » à partir de cette expérience réelle.
Pour être clair, j'écris ceci du point de vue d'un utilisateur/concepteur de systèmes, et non d'un fournisseur de SaaS.
Une ère formidable où tout le monde peut construire des systèmes
D'abord, une prémisse : l'arrivée de Claude Code a véritablement inauguré l'ère où « n'importe qui peut construire un système ». Ce n'est pas une exagération.
Chez Emooove, une responsable de recrutement qui n'était avec nous que depuis deux mois a développé un ATS (système de suivi des candidatures) en interne. Elle n'est pas ingénieure et n'a aucune expérience en ingénierie. Malgré cela, elle a créé un système fonctionnel qui gère tout, de l'importation des candidatures à la gestion de la sélection, en passant par les tableaux de bord.
Nous développons également un système interne pour améliorer l'efficacité opérationnelle et la qualité de notre cœur de métier : les services d'agence commerciale. Je m'y consacre personnellement chaque jour et, moins de deux semaines après le lancement, je sens que nous sommes sur le point de créer quelque chose d'assez bon.
On comprend pourquoi les gens veulent dire « SaaS is dead » quand on peut construire en interne quelque chose qui coûterait sinon des dizaines ou des centaines de milliers de yens par mois en frais SaaS.
Cependant, tout n'est pas si rose
C'est là le point principal. Quand nous avons réellement essayé, ce n'était pas que du bonheur.
1. La maintenance est incroyablement difficile
Pour le meilleur et pour le pire, on peut construire les choses « à la volée », ce qui fait qu'elles prennent rapidement forme. Cependant, comme les besoins ne sont pas entièrement définis, de nombreux aspects restent approximatifs.
Dans le cas de notre ATS, nous avons vu, par exemple :
- Des candidatures censées être importées ne l'étaient pas.
- Les chiffres du tableau de bord étaient bugués sans qu'on sache pourquoi.
- Des boutons critiques manquaient, ce qui a paralysé les opérations.
Nous avons rencontré beaucoup d'« oublis que nous n'avons remarqués qu'après avoir commencé à utiliser le système ». Avec notre système interne d'aide à la vente, il y a même eu un matin où nous ne pouvions soudainement plus y accéder et où l'écran ne s'ouvrait pas.
Bien sûr, ces problèmes peuvent être corrigés dans une certaine mesure en définissant les besoins plus finement ou en apportant des améliorations au fil de l'eau. Mais pendant ce temps, le fonctionnement normal de l'entreprise est perturbé. Si l'on se lance en s'attendant à ce que ce soit « facile et rapide », on risque de se retrouver dans une situation délicate. J'ai compris qu'il ne faut pas se lancer avec l'état d'esprit « je construis, c'est fini », mais plutôt « je construis, puis je répare sans cesse ».
Comme notre volume de recrutement est modeste, nous pouvons nous en sortir même si l'ATS s'arrête un moment. Mais je frémis à l'idée qu'il s'agisse d'un système avec de nombreuses parties prenantes. Plus le nombre d'utilisateurs et l'ampleur de l'impact augmentent, plus la perte en cas de défaillance est importante et plus le niveau de difficulté s'envole.
On peut tolérer cela pour des systèmes internes, mais il faut être extrêmement prudent avant de construire quoi que ce soit destiné à la vente externe ou tourné vers le monde extérieur, comme un formulaire de contact.
2. L'UI/UX n'est jamais vraiment aboutie
J'ai réalisé cela en construisant le système moi-même : le rendu est assez médiocre.
Les écrans que l'IA génère du premier coup semblent « corrects », mais quand on les utilise réellement, les détails manquent de finesse. On peut éventuellement obtenir un beau résultat en donnant des instructions encore et encore, mais cela exige une obsession intense et beaucoup de temps. La plupart des gens feront probablement des compromis en cours de route.
Les interfaces SaaS sont soignées parce que des designers professionnels ont passé des années à intégrer les retours des utilisateurs ; ce n'est pas quelque chose qu'on obtient gratuitement.
3. Le problème de la sécurité
C'est la partie la plus effrayante.
Même les non-ingénieurs peuvent utiliser Claude Code pour créer des fonctions et de l'UI/UX avec une attitude « on improvise ». Mais peut-on rattraper la sécurité de la même manière ? En tout cas, pour moi, non. Authentification, gestion des permissions, réponse aux vulnérabilités — « fonctionner » et « être sécurisé » sont deux choses complètement différentes.
Dans notre cas, nous avons la chance d'avoir une personne expérimentée comme ingénieur sécurité, et nous veillons à ce qu'elle prenne en charge cette partie. Malgré tout, une part d'appréhension demeure. L'idée qu'une organisation sans experts mette des informations clients sur un système construit à la légère et le rende public me donne des sueurs froides.
La logique binaire « vivre ou mourir » est erronée
J'ai énuméré les points négatifs du développement interne, mais honnêtement, il y a aussi beaucoup de points positifs.
- On peut construire quelque chose qui correspond parfaitement à son activité.
- Si l'on veut corriger quelque chose, on peut le faire dès le lendemain.
- Il n'y a presque aucun coût mensuel.
- L'entreprise gagne en savoir-faire et en confiance : « nous savons construire des systèmes nous-mêmes ».
Le problème, c'est de vouloir simplifier la question en « le SaaS va-t-il vivre ou mourir ? ». Choisir le SaaS ou construire en interne dépend de la situation de l'entreprise. Fort de mon expérience, voici les cinq points à considérer :
Point 1 : Avez-vous des ingénieurs en interne ?
Si ce n'est pas le cas, vous échouerez dans des domaines comme la sécurité, que les non-ingénieurs ne peuvent pas gérer à la légère. Le plus effrayant, c'est de pouvoir créer des fonctions sans se rendre compte des dangers. Le point de bascule, c'est de savoir si vous pouvez trouver une personne expérimentée pour vérifier les domaines clés.
Point 2 : Le nombre de parties prenantes
S'il y en a trop, la perte en cas de défaillance est énorme et le niveau de difficulté augmente fortement. À l'inverse, les petites organisations peuvent expérimenter plus facilement, car elles peuvent simplement s'excuser si les choses s'arrêtent. Il est réaliste de commencer par des opérations dont l'ampleur de l'impact est limitée.
Point 3 : Systèmes externes ou internes
Avec des systèmes internes, le risque est limité si quelque chose arrive. En revanche, pour tout ce qui est externe, une seule fuite d'informations peut être irréversible. Alors que le SaaS permet de déléguer une partie de la responsabilité au fournisseur, avec le développement interne, tout est de votre responsabilité. La valeur de la « tranquillité d'esprit éprouvée » qu'offre le SaaS augmente pour tout ce qui est tourné vers l'extérieur.
Point 4 : Pouvez-vous dégager du temps pour la maintenance ?
La maintenance représente plus de travail qu'on ne l'imagine. Le développement interne, ce n'est pas « construire et c'est fini », mais « construire et réparer sans cesse ». Pouvez-vous vous lancer en ayant conscience de cela ? Si vous vous lancez sans conviction, vous serez enseveli sous les corrections et cela mettra la pression sur votre cœur de métier.
Point 5 : Aimez-vous / avez-vous envie de faire du développement avec l'IA ?
Au final, tout se résume à ça. C'est plus fastidieux et plus difficile qu'on ne le croit, et c'est frustrant quand l'IA n'écoute pas (rires). Pouvez-vous aller jusqu'au bout malgré tout ? C'est une époque formidable pour ceux qui aiment ça, mais je ne pense pas que l'on puisse tenir uniquement par sens du devoir.
Résumé : le SaaS n'est pas mort, il y a simplement plus d'options
J'ai utilisé le mot « échoué » dans le titre, mais plus exactement, nous avons « failli échouer à de nombreuses reprises ». Si nous poursuivons le développement interne, c'est parce que nous avons des ingénieurs expérimentés, que notre organisation est encore petite, que c'est principalement pour un usage interne, que nous sommes prêts à nous engager dans la maintenance et, surtout, parce que j'en ai envie. On peut dire que nous le faisons parce que nous évoluons dans un environnement privilégié où les cinq points sont réunis.
À l'inverse, une entreprise qui ne remplit pas ces conditions et qui prend « SaaS is dead » au pied de la lettre pour construire ses opérations principales en interne échouera véritablement.
Le SaaS n'est pas mort. C'est simplement que l'option « construire » est désormais ouverte à tous. Évaluez calmement la situation de votre entreprise et utilisez à la fois le SaaS et le développement interne. N'est-ce pas la bonne façon d'aborder cette époque à la fois pratique et précaire ?
