Chronique annoncée de la fin du SaaS ?

Dans cet épisode nous allons nous demander si le SaaS est un mode de fonctionnement destiné à disparaître.

L’histoire de l’informatique d’entreprise est faite de vagues technologiques qui se succèdent. Elle est peut-être aussi faite de balanciers qui partent dans un sens puis dans un autre.

On centralise, puis on décentralise, puis on recentralise. Les guerres de pouvoir et de territoires en interne se déplacent, mais elles perdurent. Ainsi va la nature humaine, elle se bat pour le contrôle de la ressource.

On fait soi-même puis on abandonne l’idée de développer en interne. Alors on achète à l’extérieur. Les rapports de force sur le marché se déplacent là aussi mais ils perdurent eux aussi. Ainsi vont les marchands, ils se battent entre eux et orientent les besoins de leurs marchés.

Dans cette grande tradition, après la commercialisation de logiciels en mode licence et maintenance, depuis les années 2000, le mode SaaS – Software As A Service – est devenu la norme.

Il n’a d’ailleurs pas été poussé que pour des raisons liées à la technologie mais aussi parce que le mode de commercialisation sous forme d’abonnement c’est bon pour la valorisation.

Mais maintenant qu’on nous annonce les prouesses d’agents IA supposés capables de coder seuls, sommes-nous à l’aube d’une nouvelle ère ? Alors, chronique annoncée de la fin du SaaS, c’est quoi l’histoire ?

Commençons par le début. Sur un plan purement technique, nous ne sommes pas assez compétents pour formuler un avis affirmé. Dit concrètement, est-ce qu’un ensemble d’agents IA spécialisés, orchestrés dans une plateforme qui permet de les piloter et organiser leur travail peut modifier la donne du marché ?

On imagine volontiers, avec des plateformes comme Dust, des outils comme Claude Code et des IA toutes aussi puissantes les unes que les autres que des IA peuvent être spécialisées qui pour rédiger des spécifications, écrire du code, faire des batteries de tests, etc.

Et que l’ensemble pourrait être géré finalement sans connaître les méandres de tel ou tel langage. Voilà la bonne idée, il n’y aurait donc plus besoin d’être spécialisé en la matière.

Est-ce donc à dire qu’il devient beaucoup plus facile de fabriquer et maintenir un logiciel avec des moyens humains plus légers donc plus réactifs ? C’est une thèse que certains avancent.

Freddy Mallet par exemple, entrepreneur spécialiste de ce sujet, affirme dans un de ses posts que « le code source n’a plus aucune valeur » et prédit le temps où les entreprises s’empareront de cette facilité pour aller plus vite que leurs concurrents.

Il note d’ailleurs – et c’est frappant – que la part de Claude Code dans les commits publics sur Git est déjà de 4%. Il balaye aussi le contre-argument selon lequel du code généré par de l’IA serait non maintenable au motif que « si ce sont des agents qui maintiennent le code, la lisibilité humaine n’est plus le sujet ».

On peut être d’accord ou pas avec cette perspective, les experts informatiques en débattront on n’en doute pas. Mais sans être spécialiste on peut formuler aussi d’autres remarques pour éclairer le sujet.

La première remarque, qui milite en faveur de la fin du SaaS, Freddy Mallet la pointe aussi. Si tu ne le fais pas, tes concurrents le feront, l’enjeu de la réactivité et de la vitesse au centre en effet.

Après tout, si c’est techniquement possible, alors nul doute que certaines entreprises feront le choix de reprendre la main plutôt que de dépendre d’un écosystème qui leur laisse parfois que peu de choix et cherche inévitablement à les rendre captifs.

On peut même admettre que certaines entreprises feront le choix d’accepter des imprécisions ou des risques – comme ceux de la maintenabilité ou de la scalabilité des outils développés par de l’IA – au motif que la valeur tirée par ailleurs est supérieure.

Après tout le « make or buy » est un principe qui s’applique aussi et des arbitrages en termes de risques peuvent être faits également.

Dans cette optique, des entreprises moins exposées ou de tailles intermédiaires ou petites pourraient en effet bien être tentées.

Mais deux autres remarques peuvent aussi être formulées. Si la question de la « lisibilité » de ce que l’IA produit comme code – donc, dit autrement, du côté boîte noire du truc – n’est pas centrale pour certaines entreprises, pour d’autres c’est différent.

Dès qu’il y a nécessité de retracer, de transparence, de conformité et de capacité à en témoigner en toute circonstance, le sujet devient plus brûlant et la question du SaaS ou du code IA se posera en termes de risques et de responsabilité.

Dit simplement, l’IA n’endosse pas de responsabilité. La truelle n’est pas responsable du mur du maçon qui s’effondre. Mais un fournisseur endosse une responsabilité – certes encadrée donc limitée – mais qui peut être engagée. C’est ce à quoi sert une garantie décennale.

C’est un argument qui peut peser dans la balance d’un décideur entre faire faire par ses équipes avec du code généré et maintenu par de l’IA ou avoir recours à une solution SaaS d’un fournisseur, même si ce dernier utilise de l’IA lui aussi d’ailleurs.

Le troisième éclairage relève du fait que les orientations que prend un marché ne proviennent pas seulement de mutations techniques qui rendent possibles ce qui ne l’était pas auparavant.

Le SaaS s’est peut-être en réalité plus imposé sur le marché d’abord parce qu’il répondait aux intérêts des protagonistes et des équilibres de marché entre les attentes de ceux qui investissent et les besoins et risques de ceux qui achètent.

Il en sera donc vraisemblablement de même. A supposer – et on le répète on laisse l’affaire dans les mains des avis d’experts – que cela soit possible et que le code devienne une commodité, est-ce pour autant que c’est ce qui conduira les entreprises à faire le choix de réinternaliser ?

Ce n’est pas si sûr. Les arguments de réactivité plaident en effet en faveur d’une forme de « réinternalisation » facilitée par l’IA mais la combinaison de la responsabilité de l’entreprise, des risques et des équilibres financiers notamment entre Capex et Opex peut aussi changer ce point de vue.

Alors bien sûr il faut être vigilant à ce que Freddy Mallet appelle des « croyances limitantes ». C’est le meilleur moyen en effet de ne rien transformer jusqu’au moment où il est trop tard, d’autres l’ont fait.

Mais constater des limites à quelque chose n’est pas en soi une croyance limitante. Cela ne le devient que si l’on s’appuie sur le constat de ces insuffisances pour se limiter dans l’exploration concrète du potentiel qui est devant soi.

La conscience du risque n’est limitante que si on ne le prend pas !

Or, ce que l’IA fait désormais en matière de code est sans aucun doute non seulement très impressionnant mais aussi très prometteur quant à l’autonomie que cela peut offrir, d’abord en termes de productivité pour des éditeurs, d’autonomie pour les entreprises aussi.

Mais comme on sait que les boules de cristal sont fragiles, on se gardera bien de formuler une prédiction sur l’avenir du SaaS.

Si ce n’est que les croyances en tout genre joueront un rôle important, notamment celles des acheteurs sur lesquelles les acteurs de l’offre sauront jouer à merveille parce que ça c’est immuable.

En résumé, l’IA ouvre un potentiel très prometteur quant à la capacité des entreprises à être autonomes en matière de développement logiciel. Même si cette opportunité est techniquement possible, d’autres facteurs pourraient néanmoins en limiter le pouvoir de modification du marché du SaaS.

J’ai bon chef ?

Oui tu as bon mais on ne va pas en faire toute une histoire.