Le SaaS n'est pas mort - il recrute des Forward Deployed AI Engineers

L’article de Steve Banker dans Forbes du 16 mai est le titre d’enterprise software le plus citable de l’année jusqu’ici. Danny Lukus, deployment strategist chez Palantir, a dit à la salle que le SaaS est mort - en pointant comme pièce à conviction numéro un toutes les équipes finance du Fortune 500 qui font tourner leurs opérations dans Excel. “On a des humains qui font de l’intégration de données manuelle et qui créent leur propre logique. Beaucoup de mauvaises choses arrivent en conséquence.” Dans la foulée, le CTO Shyam Sankar a affirmé que l’AI FDE - le Forward Deployed Engineer alimenté par IA de Palantir - alimente désormais des migrations SAP ECC vers S/4HANA “en seulement 2 semaines.”

Le marché prend ça au sérieux. Les valeurs logicielles ont perdu plus de 300 milliards de dollars en deux jours pendant le récent sell-off “SaaSpocalypse”. Le chiffre d’affaires Q1 de Palantir a grimpé de 85% à plus de 6,5 milliards d’ARR. Le poids des ventes et du marketing dans le chiffre d’affaires s’est effondré de 60% à 23%. Le net dollar retention est à 139%. Les chiffres sont assez inhabituels pour forcer le reste de l’industrie à prendre la thèse au sérieux, même quand la thèse est à moitié cuite.

Voici ce que je pense être la bonne lecture. “SaaS is dead” est le mauvais titre. Le bon titre, c’est que l’IA brouille la frontière entre logiciel sur mesure et logiciel packagé, et que les éditeurs SaaS qui gagneront la prochaine décennie seront ceux qui associeront un cœur de plateforme solide à des Forward Deployed AI Engineers - et, point crucial, qui réinjecteront chaque mission client dans la plateforme. Cette dernière clause, c’est la partie que tout le monde rate, et c’est elle qui décide si vous finissez en plateforme ou en cabinet de conseil.

Cet article, c’est ce que je pense que les éditeurs SaaS classiques doivent vraiment faire.

Ce que Palantir fait vraiment différemment

Pour pouvoir débattre utilement de la mort du SaaS, il faut d’abord être précis sur ce que Palantir fait que presque aucun autre éditeur ne fait. Les trois pièces comptent individuellement et comptent davantage ensemble.

1. L’Ontology

L’Ontology est le moat structurel de Palantir. Ce n’est pas un data lake. C’est une représentation sémantique et exécutable de la logique, des actifs et des processus d’une entreprise - un jumeau numérique contre lequel les agents IA et les humains opèrent. Là où un entrepôt de données traditionnel se place sous la couche applicative, l’Ontology se place au-dessus, en mappant les données de SAP, Oracle, des systèmes maison et des sources opérationnelles dans un modèle métier unifié qui sait ce que signifient un contrat, une usine, une pièce ou un client dans les termes spécifiques de votre entreprise.

C’est la partie que les concurrents sont les plus lents à saisir. L’Ontology se compose. Chaque workflow construit par-dessus rend le suivant moins cher. Chaque agent IA pointé dessus rend la logique métier plus durable. C’est pourquoi le 139% de net dollar retention de Palantir est structurellement différent du 110% NDR d’un SaaS typique. Les clients dépensent 39% de plus chaque année non parce qu’ils ont acheté plus de sièges, mais parce que l’Ontology est devenue davantage la manière dont ils opèrent.

2. Le Forward Deployed Engineer

Palantir ne livre pas un produit en laissant les clients se débrouiller. Ils embarquent des ingénieurs à l’intérieur des environnements client et leur font construire les workflows de production par-dessus la plateforme. L’équipe structurée est précise :

Delta (engineer) écrit du code de production, navigue dans des données cassées, implémente le système.
Echo (strategist) comprend la réalité politique et opérationnelle du client, en s’assurant que le travail est effectivement adopté.

La tension entre les deux est voulue. Ce qui ressemble à du conseil vu de l’extérieur est en réalité la construction délibérée de données de patterns : chaque déploiement apprend à Palantir ce qui est spécifique à ce client et ce qui est généralisable. La raison pour laquelle ce modèle n’est pas un piège services - c’est la partie que la plupart des analystes ratent - c’est la fonction explicite de reconnaissance de patterns. Le vrai métier du FDE, c’est d’identifier les abstractions qui reviennent et de les réinjecter dans la plateforme.

3. AI FDE : Forward Deployed Engineers en mode agent

Fin 2025 et tout au long de 2026, Palantir a étendu le modèle FDE à l’IA elle-même. L’AI FDE est un agent qui pilote Foundry en langage naturel : il construit des pipelines de données, gère des repos, monte des objets d’Ontology, exécute des transformations. L’affirmation de Sankar sur les migrations SAP en deux semaines est en aval de ça - ce qui prenait un an de travail FDE humain plus les équipes client prend désormais quelques semaines de travail AI FDE plus un pont humain beaucoup plus mince.

C’est la partie que le cadrage “SaaS is dead” pointe vraiment, même s’il la sous-vend. Le vrai changement n’est pas que l’IA remplace le SaaS. Le vrai changement, c’est que l’IA effondre le coût de la couche sur mesure qui s’est toujours assise par-dessus le SaaS, et cet effondrement change les maths de chaque deal d’enterprise software.

Pourquoi “SaaS Is Dead” est provocatricement faux

Le slogan est du bon marketing et de la mauvaise analyse. Trois choses sont vraies en même temps, et le slogan n’en honore qu’une seule.

Vrai : Le SaaS purement packagé, sans couche d’intégration ni logique spécifique au client, se heurte à un mur structurel. Le point de Forbes sur chaque équipe finance qui fait tourner Excel par-dessus son SaaS est le symptôme, pas le diagnostic. Le logiciel packagé a toujours exigé un build côté client pour vraiment coller. Ce build a historiquement été fait par des consultants, des équipes ingénierie internes, ou dans le pire des cas, par Excel. L’IA n’élimine pas cette couche. Elle en effondre le coût, ce qui change qui capte la valeur créée.

Vrai : Le logiciel purement sur mesure ne scale pas. Chaque dollar que Palantir facture pour une mission FDE est un dollar qu’un concurrent pourrait dépenser sur ses propres ingénieurs, sur un Big Four, sur un cabinet de conseil, ou sur des équipes internes. La raison pour laquelle Palantir gagne, ce n’est pas parce que leurs FDE sont moins chers. Ils ne le sont pas. La raison, c’est que le travail produit par le FDE se compose en actif plateforme (l’Ontology et les abstractions au niveau plateforme). Si on retirait la boucle de feedback plateforme, Palantir serait Accenture en sweat à capuche.

Vrai : La frontière entre sur mesure et packagé devient fluide, pas inexistante. Le bon modèle mental pour la prochaine décennie d’enterprise software, c’est une plateforme plus un service qui se transforme en plateforme, avec l’IA qui compresse les deux moitiés. Le SaaS, dans ce monde, ne meurt pas. Il évolue vers la structure package plus déploiement plus boucle de feedback dont Palantir est l’exemple le plus bruyant.

Si vous êtes CEO d’un SaaS et que vous prenez le titre “SaaS is dead” au pied de la lettre, vous allez surréagir. Si vous prenez le shift sous-jacent au sérieux, vous allez commencer à reconstruire votre business model autour d’une structure que le SaaS classique résiste depuis quinze ans.

Les trois choses que le SaaS classique doit faire

Voici le playbook opérationnel que je remettrais à n’importe quelle équipe de direction d’un SaaS classique en train d’essayer de comprendre quoi faire cette année et l’année prochaine. Il y a trois mouvements, dans l’ordre, et chacun ne fonctionne que si le précédent est en place.

Mouvement 1 : Garder la plateforme forte - et la rendre digne d’être composée

Le premier instinct d’un CEO de SaaS qui lit l’histoire Palantir va être faux. L’instinct va être : “il faut qu’on ajoute un onglet IA et un chatbot.” C’est exactement le mouvement qui ne marche pas.

Ce qui marche, c’est d’investir dans le substrat de la plateforme pour qu’elle puisse absorber une logique spécifique au client de plus en plus complexe sans gonfler le cœur. Trois propriétés comptent par-dessus tout :

Un vrai modèle de données, pas une base de données en forme de CRUD. La plupart des couches de données SaaS sont conçues pour le cas d’usage canonique et résistent à la déviation. Une plateforme construite pour se composer a un modèle sémantique - types d’objets, relations, propriétés dérivées, historique des changements - qui peut absorber le cas limite du prochain client sans forker le schéma. Vous n’avez pas besoin de l’appeler Ontology. Vous devez en construire une.
Composabilité API-first. Chaque action que la plateforme exécute doit être adressable par du code, pas seulement par l’UI. C’est la condition de base pour que les agents l’utilisent, et c’est aussi le prérequis pour que des Forward Deployed AI Engineers fassent quoi que ce soit qui se compose.
Extensibilité honnête. Les extensions spécifiques au client ont besoin d’un chemin first-class qui ne forke pas le cœur. La plupart des architectures SaaS permettent la “personnalisation” uniquement via un feature toggle ou une table de configuration. Ce n’est pas ce dont l’ère agentique a besoin. Vous avez besoin d’un sandbox où la logique client peut être écrite, exécutée, gouvernée et - point critique - promue dans la plateforme quand elle le mérite.

Si vous ne pouvez pas faire le Mouvement 1, aucun Mouvement 2 ne vous sauvera. Vous deviendrez un business de services avec un vernis SaaS.

Mouvement 2 : Ajouter des Forward Deployed AI Engineers comme couche de service

C’est le mouvement contre lequel le SaaS classique va le plus résister, parce qu’il ressemble à du chiffre d’affaires de services. Les investisseurs détestent le chiffre d’affaires de services. Les boards détestent le chiffre d’affaires de services. Les dirigeants ont passé vingt ans à retirer le chiffre d’affaires de services de leur P&L sur la route du pure-play SaaS.

Cet instinct est maintenant faux, et la raison pour laquelle il est faux, c’est que la structure de coût des services s’est effondrée. Un Forward Deployed AI Engineer n’est pas un consultant humain facturable. C’est un ingénieur humain travaillant avec des agents à cinq à dix fois le throughput - parfois bien plus sur certains workflows. L’économie de “mission style FDE plus agents niveau AIP plus levier plateforme” ne ressemble pas à un business de services à 30% de marge brute. Elle ressemble à un business plateforme à haute marge avec un bras de delivery intégré.

Concrètement, ce que ça veut dire pour un éditeur SaaS classique :

Recruter (ou construire) une fonction Forward Deployed AI Engineering. Petite, senior, autorisée à vivre dans les environnements clients. La fiche de poste est plus proche d’un staff engineer que d’un solutions architect. Ils écrivent du code de production, ils implémentent des workflows dans la plateforme, ils instrumentent les résultats, ils pairent avec les équipes client.
Les équiper d’agents dès le premier jour. L’automatisation style AI FDE est la seule façon dont les maths fonctionnent. Sans agents à levier significatif, vous recréez un cabinet de conseil à 30% de marge brute. Avec des agents, vous gardez des marges de niveau plateforme.
Ne vendez pas la mission. Bundlez-la. Inscrivez la mission FDE dans l’onboarding et dans l’expansion. Les clients ne veulent pas acheter du logiciel puis signer un SOW de services. Ils veulent acheter une capacité opérationnelle. Si vous faites en sorte que la mission FDE ressemble à un SOW, votre vélocité de vente s’effondre. Si vous faites en sorte qu’elle ressemble aux quatre-vingt-dix premiers jours de livraison de valeur, l’expansion accélère.

Le modèle de No Rules Rules et de mon article sur les empowered teams s’applique ici autant qu’à l’intérieur de votre propre org. Les Forward Deployed AI Engineers empowerent les clients de la même manière que les empowered product teams sont empowered à l’intérieur de votre org. Vous leur donnez du contexte - le problème métier, les données du client, les workflows à transformer - et vous les laissez résoudre. Ce que vous ne faites pas, c’est centraliser la prise de décision dans un comité produit qui n’a pas les données du client.

Mouvement 3 : Tout réinjecter dans la plateforme

C’est le mouvement qui décide si vous devenez une plateforme ou un cabinet de conseil. C’est aussi la partie que Palantir a clouée, la partie que la plupart des éditeurs lourds en services ratent, et la partie pour laquelle le SaaS classique a le fit culturel le plus proche de quiconque dans l’industrie - s’il fait le mouvement délibérément.

La discipline est la suivante : chaque mission Forward Deployed AI Engineering produit trois artefacts. Un, un déploiement client opérationnel. Deux, un ensemble enregistré de patterns - abstractions, primitives, cas limites - qui sont apparus pendant le travail. Trois, et le plus important, la décision de promotion : lesquels de ces patterns appartiennent à la plateforme, et lesquels restent sur mesure ?

La décision de promotion a besoin d’un forum explicite. Chez Palantir, d’après ce que je crois comprendre, ça se passe par une boucle serrée entre les équipes de déploiement et le platform engineering. Dans une boîte SaaS classique, je mettrais exactement cette boucle en place, cadence hebdomadaire, pas d’exceptions :

Qu’est-ce que nos FDE ont construit chez les clients cette semaine ?
Lesquels de ces patterns vont réapparaître chez les cinq prochains clients ?
Qui possède la promotion de ces patterns dans la plateforme ?

Le flywheel est identique à ce que Kief Morris a décrit comme le flywheel agentique dans mon article précédent, juste appliqué à la relation éditeur-client au lieu de la boucle d’ingénierie interne. La mission client est la source de données. La plateforme est le harness. Le processus de promotion est l’agent qui améliore le harness à partir des données. Le moat composé, c’est la plateforme elle-même, qui s’enrichit à chaque mission.

Si vous faites bien le Mouvement 3, votre plateforme s’améliore plus vite que celle des concurrents qui ne collectent que de la télémétrie. Si vous faites mal le Mouvement 3, vous faites pousser un business de services que les concurrents vont copier en dix-huit mois.

Ce que ça veut dire en pratique

Laissez-moi rendre l’abstrait concret avec trois prédictions et trois pièges.

Trois prédictions pour le SaaS sur les 24 prochains mois

Chaque SaaS leader de sa catégorie ajoute une fonction Forward Deployed AI Engineering. Ça ne s’appellera pas toujours comme ça. Salesforce va le rebrander. SAP va le caser dans une nouvelle tier. La forme sera la même : ingénieurs seniors, plus agents, embarqués chez les clients, payés à l’intérieur du contrat plateforme plutôt qu’en SOW séparé. Ceux qui l’exécutent comme un investissement plateforme plutôt que comme une ligne services gagneront.
Le pattern Ontology devient le nouveau différenciateur. Celui qui possède la couche sémantique des données opérationnelles d’un client possède le moat de l’ère IA. Surveillez de près les éditeurs SaaS qui publient discrètement des modèles de données orientés objet, des surfaces de logique métier exécutables et des APIs adressables par les agents. Ce sont eux qui construisent le moat, même s’ils ne le marketent pas comme ça.
Le SaaS point-solution horizontal pur se fait écraser. Les éditeurs qui vendent une seule feature - notes de frais, signatures électroniques, modules CRM mono-usage - sont ceux qui ont le plus à perdre. Leurs clients peuvent désormais générer la fonctionnalité équivalente avec un ingénieur IA compétent en quinze jours. Les éditeurs qui survivent sont ceux qui ont une gravité de données profonde, des modèles sémantiques et des moats d’intégration. Tous les autres deviennent une feature à l’intérieur de la plateforme de quelqu’un d’autre.

Trois pièges à éviter

Le piège de l’onglet IA. Coller Claude ou GPT dans votre app existante et appeler ça SaaS IA-enabled. Ça ne change pas votre économie. Les clients le savent.
Le piège du services-creep. Laisser les FDE devenir un cabinet de conseil facturable. Au moment où votre org FDE a un P&L séparé avec des marges style services, la boucle de feedback plateforme meurt parce que personne n’est incentivé à réinjecter le travail sur mesure dans la plateforme. Gardez la fonction FDE à l’intérieur du platform engineering, avec l’ownership de l’économie plateforme.
Le piège du fork-the-product. Laisser le build sur mesure d’un gros client vivre pour toujours comme branche spéciale. C’est comme ça que les éditeurs SaaS sont morts dans les années 1990 et c’est comme ça qu’ils mourront dans les années 2030. La discipline de tirer les patterns dans la plateforme, c’est ce qui garde l’architecture cohérente.

Comment ça s’articule avec tout ce que j’ai écrit par ailleurs

Je trouve frappant le nombre de fils de la série agentique qui convergent vers cet article. Carte rapide :

Diriger l’IA est un problème d’empowerment - le playbook des empowered teams appliqué aux relations éditeur-client, et le flywheel agentique appliqué à l’amélioration plateforme.
Le Vibe Coding en Prod est un Problème de Management - le FDE qui travaille avec des agents, c’est exactement le modèle leaf-nodes-and-trunks joué à travers les codebases clients.
L’Act 2 de GitLab - La restructuration agentique passe au grand jour - la validation par une entreprise cotée que empowered teams plus contexte connecté plus cadence agent est la forme opérationnelle.
Le dernier goulot d’étranglement - un Forward Deployed AI Engineer peut maintenant faire ce qu’une équipe de cinq faisait en 2023. La frontière plateforme-services dans l’enterprise software est en aval de ce changement.
Architecture IA à trois niveaux - l’AI FDE est la tier LLM-agent qui orchestre les primitives plateforme déterministes.

Le pattern à travers tout ça est le même : le rôle humain se concentre sur l’architecture, le contexte et le jugement ; la couche agentique compresse le coût de tout le reste ; et la structure gagnante est celle qui capte la compression sous forme de valeur plateforme composée plutôt que sous forme de marge services one-shot.

Palantir a repéré ça plus tôt que quiconque et a construit la boîte autour. Le SaaS classique peut copier le pattern. La fenêtre pour le faire est étroite.

À retenir

Le SaaS n’est pas mort. Le slogan est faux, l’analyse est incomplète, et le titre aura l’air ridicule dans cinq ans. Mais le shift sous-jacent qu’il pointe est réel. Le coût de personnaliser du logiciel packagé s’effondre. La frontière entre plateforme et service se brouille. Les boîtes qui gagneront la prochaine décennie d’enterprise software seront celles qui associeront une plateforme solide à des Forward Deployed AI Engineers - et qui réinjecteront chaque mission dans la plateforme.

Si vous dirigez un SaaS classique, votre travail est clair. Renforcer le substrat plateforme. Construire une petite fonction Forward Deployed AI Engineering, senior, équipée d’agents. Inscrire la mission dans la relation client plutôt que dans un SOW séparé. Le plus important : construire le forum hebdomadaire qui transforme chaque mission client en IP plateforme.

Les boîtes qui font ça en 2026 posséderont leur catégorie en 2030. Les boîtes qui prennent “SaaS is dead” au pied de la lettre, paniquent et ajoutent un onglet IA seront acquises ou mangées par celles qui ne l’ont pas fait.

Références

Palantir Says SaaS Is Dead - Steve Banker, Forbes - L’article qui a déclenché cet article
Résultats Palantir Q1 2026 - SaaStr - Les chiffres derrière la rhétorique
AI FDE Overview - Palantir docs - Le Forward Deployed Engineer alimenté par IA dans leurs propres mots
A Comprehensive Analysis of Palantir’s Forward Deployed Engineering Model - Diogo Silva Santos, Medium - La meilleure deep dive sur le modèle FDE
Palantir as Signal - Visser Labs - L’argument structurel sur plateforme versus SaaS
Palantir’s Forward Deployed Engineer Model Drove 640% Returns - MindStudio - Sur Anthropic et OpenAI qui copient maintenant le modèle
Diriger l’IA est un problème d’empowerment - La thèse des empowered teams que cet article étend à la relation éditeur-client
L’Act 2 de GitLab - La restructuration agentique passe au grand jour - L’équivalent côté plateforme de ce mouvement, joué par une entreprise cotée
Le dernier goulot d’étranglement - Pourquoi un Forward Deployed AI Engineer peut maintenant faire ce que faisait une équipe