Il y a quelques jours, on m’a envoyé un dessin qui tourne beaucoup en ce moment. À gauche, « avant l’IA » : une poignée de développeurs indépendants, et en face une foule de clients ravis, billets à la main. À droite, « après l’IA » : une marée de développeurs devant leur ordinateur, et dans un coin, trois clients recroquevillés qui ne savent plus où donner de la tête.
Le dessin est drôle. Il résume assez bien ce qu’on appelle depuis quelques mois la SaaS apocalypse : l’idée que l’IA générative permet désormais à n’importe qui de produire son propre logiciel, et que les éditeurs SaaS n’ont plus qu’à fermer boutique. Je pense que le constat est juste sur un point, et faux sur l’essentiel. Il y a bien plus de gens capables d’écrire du code. Il n’y a pas beaucoup plus de gens capables de construire un produit.
Ce que le SaaS résout vraiment
Un logiciel en SaaS, c’est un logiciel qu’on n’installe pas, qu’on ne maintient pas soi-même, et qu’on paie à l’usage. Vu de loin, on achète des écrans et des fonctionnalités. Vu de près, on achète tout autre chose :
la continuité (le service tourne ce matin, il tournera dans cinq ans) ;
la sécurité et la conformité (hébergement, sauvegardes, droits d’accès, RGPD, audits) ;
l’évolution (les mises à jour, les nouvelles obligations réglementaires intégrées sans que vous ayez à y penser) ;
la connaissance métier accumulée auprès de dizaines ou de centaines de clients qui ont eu le même problème que vous avant vous.
C’est ce dernier point qu’on oublie le plus souvent. Un bon éditeur ne vend pas du code, il vend des années d’erreurs déjà commises par d’autres, et corrigées.
Les enjeux du SaaS aujourd’hui
Soyons honnêtes, le secteur ne traverse pas une période tranquille. Les budgets logiciels sont passés au crible, les directions financières comptent les licences, et l’IA change la façon dont on construit comme la façon dont on utilise un outil. Un éditeur qui se contente d’empiler des fonctionnalités va souffrir, c’est certain.
Mais l’enjeu n’est pas de savoir si un logiciel peut être généré. C’est de savoir qui s’en occupe ensuite. Qui répond quand un utilisateur ne comprend pas un écran ? Qui corrige la faille découverte un vendredi soir ? Qui adapte l’outil quand la réglementation change en cours d’année ? La valeur du SaaS s’est déplacée du code vers le service qui l’entoure.
Pourquoi il faut un humain et un logiciel
Un besoin client n’arrive jamais sous la forme d’une spécification propre. Il arrive sous la forme d’une frustration : « je passe trois jours à préparer mon budget », « je ne sais jamais quel contrôle est en retard ». Transformer cette frustration en un outil utile demande quelqu’un qui écoute, qui reformule, qui challenge, et qui dit parfois non.
Le logiciel apporte la rigueur, la répétabilité, la mémoire. L’humain apporte le discernement : comprendre ce qu’il ne faut pas automatiser, accompagner le changement sur le terrain, expliquer une donnée à un comité de direction. On peut avoir l’un sans l’autre. On obtient alors soit un outil que personne n’utilise, soit un expert qui passe ses journées dans des tableurs.
L’IA ne supprime pas cette équation. Elle rend la partie logicielle plus rapide à produire, ce qui rend la partie humaine encore plus décisive.
Le piège des outils faits maison
C’est le scénario que je vois arriver dans beaucoup d’organisations. Un collaborateur motivé, un assistant IA, un week-end. Le lundi, une petite application tourne et règle un vrai problème. Tout le monde applaudit. Six mois plus tard, on en compte douze, écrites par huit personnes différentes, et plus personne ne sait très bien ce qu’elles font.
On a déjà connu ce film avec Excel. Je l’ai décrit dans un précédent article sur le fléau d’Excel dans l’immobilier : un outil pratique qui devient, fichier après fichier, un frein stratégique. Les applications générées par IA ont exactement la même pente, avec des conséquences plus lourdes :
La sécurité. Des clés d’API en clair dans le code, des bases de données ouvertes, des données personnelles ou financières hébergées on ne sait où. Personne n’a fait de revue, personne n’a testé.
La dépendance à une personne. Le jour où l’auteur change de poste ou quitte l’entreprise, l’outil devient une boîte noire que personne n’ose toucher.
La fragmentation de la donnée. Chaque outil a son propre référentiel. On recrée les silos qu’on avait mis des années à casser.
La conformité. RGPD, traçabilité, droits d’accès, réversibilité : rien de tout ça n’est prévu, parce que ce n’était pas le sujet du week-end.
Le coût caché. Le temps passé à maintenir, corriger et contourner n’apparaît dans aucun budget. Il est pourtant bien réel.
Attention, je ne jette pas la pierre à ceux qui expérimentent. C’est même plutôt une excellente nouvelle. Un collaborateur qui automatise un rapport hebdomadaire, qui se fabrique un petit script pour nettoyer un export ou qui teste une idée en quelques heures, règle un vrai irritant. Il gagne du temps, il comprend mieux son propre besoin, et il arrive souvent avec des idées bien plus claires que n’importe quel cahier des charges.
Tout est une question de périmètre. Un outil personnel, sans données sensibles, qui peut disparaître demain sans conséquence : foncez. Un outil partagé par une équipe, qui manipule des données clients ou financières, et dont dépend une décision : là, il faut changer de catégorie. Le problème ne commence pas avec l’expérimentation, il commence quand le prototype devient la production sans que personne ne l’ait décidé.
Ce qu’un vrai projet logiciel doit inclure
Quand on construit un logiciel qui doit durer, le code n’est qu’une des briques. Chez nous comme chez tout éditeur sérieux, un produit mobilise plusieurs métiers qui ne se remplacent pas les uns les autres :
Le Product Manager porte la vision : quel problème on résout, pour qui, et pourquoi maintenant. Il arbitre ce qu’on ne fera pas.
Le Product Owner traduit cette vision en priorités concrètes, rédige les besoins, valide ce qui est livré avec les utilisateurs.
L’UX designer s’assure que l’outil sera compris et adopté. Un logiciel puissant mais incompréhensible ne sert à rien sur le terrain.
Les développeurs construisent, mais surtout conçoivent une architecture qui supportera la dixième fonctionnalité aussi bien que la première.
La maintenabilité passe par les tests, la documentation, les revues de code. C’est ce qui permet de faire évoluer l’outil sans tout casser.
La sécurité se pense dès le départ : authentification, chiffrement, gestion des droits, sauvegardes, surveillance des vulnérabilités.
Le support et l’accompagnement font le lien avec les utilisateurs après la mise en ligne, là où commence vraiment la vie d’un logiciel.
Une IA peut aider chacun de ces métiers à aller plus vite. Elle ne fait pas disparaître le besoin qu’ils existent, ni qu’ils se parlent.
Apocalypse ou bulle ?
Revenons au dessin. Il montre une explosion du nombre de gens qui produisent du logiciel. Ce qu’il ne montre pas, c’est la suite. Dans quelques mois, quelques années peut-être, beaucoup d’organisations vont découvrir que leurs outils maison ne passent pas un audit de sécurité, ne suivent pas la dernière évolution réglementaire, ou ne fonctionnent plus depuis que leur auteur est parti.
On est, à mon avis, dans une bulle de confiance. Pas une bulle technologique : l’IA est un vrai progrès et elle change notre métier en profondeur. Une bulle de perception, où la facilité à produire un premier résultat donne l’illusion que le reste est aussi simple. Ce n’est pas un monde tout rose. C’est un monde où il est plus facile de démarrer, et toujours aussi difficile de durer.
Les éditeurs qui s’en sortiront seront ceux qui l’ont compris : le logiciel se génère, le service se construit. Les clients recroquevillés dans le coin du dessin ne cherchent pas plus de code. Ils cherchent quelqu’un de fiable à qui confier un problème. C’est exactement ça, le SaaS.
