Post-SaaS : l’application est morte ? Vive le code !

Partner Data, AI & Agentic chez Converteo, Julien Ribourt accompagne les organisations dans la définition et la mise en œuvre de leur stratégie à l’ère de la data et de l’IA. Expert des transformations agentiques et des écosystèmes de données, il développe des approches sur mesure pour faire de l’intelligence artificielle un moteur de performance et d’innovation.

Beaucoup a déjà été écrit sur la correction massive des valeurs software début 2026 et sur la menace que les agents IA font peser sur le modèle SaaS. Ce débat est largement couvert. Ce qui me semble moins exploré, c’est la lecture architecturale : pas « qu’est-ce qui va disparaître ? », mais « qu’est-ce qui émerge à la place, et comment c’est construit ? »

La décomposition de l’application SaaS

Une application SaaS classique est un triptyque : base de données, logique métier, interface utilisateur. En mai 2025, Satya Nadella a décrit ce triptyque : « les applications SaaS sont essentiellement des bases de données CRUD avec de la logique métier. La logique métier va migrer vers les agents. » McKinsey a formalisé l’idée dans un archétype « post-SaaS » où l’agent interroge directement les dépôts de données via API, commoditisant la couche applicative.

Mais ce que ni l’un ni l’autre ne détaillent, c’est ce que cela  exige de la couche de données. Pourtant, c’est bien là que l’essentiel se joue.

La donnée interrogeable : ni un data lake, ni un contrat d’interface

Quand on dit « les agents interrogent les données via API », il ne s’agit pas de pointer un LLM vers un data lake brut. Un agent a besoin de données structurées, sémantiquement typées, accessibles via un contrat d’interface stable : schémas déclarés et versionnés (JSON Schema, Protobuf), API documentées avec contrat OpenAPI, couches de metadata, gouvernance de la fraîcheur et des droits.

Le cas Klarna illustre cette logique. En septembre 2024, Siemiatkowski annonce la fermeture de Salesforce et Workday et la consolidation de 1 200 applications SaaS. Le récit médiatique parle de « remplacement du SaaS par l’IA ». La réalité est plus instructive.

Klarna a extrait les données clients, transactions et produits qui vivaient dans Salesforce pour les consolider dans un graph database Neo4j, rendu cette couche interrogeable par l’IA interne, puis généré de nouvelles interfaces à la demande avec Cursor. Le résultat, c’est la suppression de centaines de licences SaaS et la réduction de la dépendance à des interfaces propriétaires qui, in fine, n’étaient que des surcouches graphiques sur des données que Klarna possédait déjà.

Cette logique, toutefois, vise d’abord les SaaS dont la valeur se réduit à une interface sur des données que l’entreprise possède, et non les plateformes à haute criticité architecturale (ERP, systèmes transactionnels, PLM) dont la proposition repose sur la scalabilité, la fiabilité infra et une logique métier profondément intégrée. L’enjeu n’est pas de tout remplacer, mais d’identifier les outils dont l’usage réel de l’utilisateur final ne justifie plus le coût de la licence.

Le point important, c’est que ce schéma ne dépend pas de Neo4j ni de Cursor. Il est reproductible dès lors que trois conditions sont réunies :

• des données consolidées dans une couche structurée et gouvernée (qu’il s’agisse d’un graph database, d’un data warehouse, ou d’un ensemble de microservices) ;
• une surface d’accès standardisée que les agents peuvent interroger (API REST, SQLou un protocole MCP qui normalise la connexion entre LLM et sources de données) ;
• et la capacité à générer des interfaces à la volée plutôt que de les acheter en licence.

L’interface éphémère et le « everything as code »

Si l’agent peut générer l’interface, alors l’interface n’a plus besoin d’être un produit permanent. Karpathy décrit avoir vibe-codé des applications éphémères pour trouver un seul bug. Le code est soudainement gratuit, éphémère, jetable après usage unique. Si le coût marginal du code tend vers zéro, l’application devient un artefact généré à la volée, un .jsx, un dashboard Streamlit, un markdown interactif, exécuté puis jeté.

Ce mouvement converge avec le précédent vers un principe que je propose de lire comme l’extension de l’Infrastructure as Code à toute la pile applicative : une couche de données basse, structurée, gouvernée, exposée via API versionnées ; une couche d’agents qui orchestre ; une couche de rendu éphémère, générée à la demande. Tout est déclaratif, versionnable. Le coût se déplace du « seat » vers le « compute », plus efficient, plus aligné avec la valeur produite.

Quel impact pour vous ?

En conséquence, la couche de données structurées et gouvernées devient le vrai actif. Si vos données sont dispersées dans plusieurs  SaaS avec leurs schémas propriétaires et leurs exports CSV bancals, vous êtes dépendants d’interfaces que des agents rendront superflues. En revanche, si elles sont consolidées et accessibles via des contrats stables, vous pourrez y brancher n’importe quel agent, aujourd’hui ou demain.

Bien sûr, construire ce data layer reste un chantier lourd : les agents sont probabilistes,la couche déterministe reste indispensable, et Sinofsky a raison de rappeler que chaque vague tech a multiplié la demande de software. Il y aura plus de logiciel que jamais, mais plus éphémère, plus modulaire, et ancré dans des fondations de données plus solides. Bienvenue dans  l’ère du « everything as code. »