Commençons par une clarification que l’on esquive trop souvent. Quand on parle d’ESN — Entreprise de Services du Numérique — on parle en réalité d’un écosystème très hétérogène. Grossièrement, pour simplifier, je les classerai en quatre catégories, même si c’est réducteur. Les géants de l’intégration qui opèrent des projets SI à grande échelle pour le compte de grands comptes. Les cabinets de conseil en stratégie digitale qui conçoivent les transformations sans toujours les industrialiser. Les boutiques spécialisées par verticale — retail tech, fintech, healthtech — qui maîtrisent un métier en profondeur. Et il y a les pure players data et IA qui ont émergé ces dix dernières années sur la vague de la donnée.

Ces quatre profils n’ont pas le même point de départ face à la vague qui arrive. Ils n’ont pas les mêmes atouts, ni les mêmes vulnérabilités. Et la transformation qui s’amorce ne les affectera pas de la même façon ni au même rythme.

Ce qui est commun à tous ces acteurs, en revanche, c’est la pression exercée par la même lame de fond. Une lame de fond que Satya Nadella a résumée avec une brutalité remarquable lors de sa participation au BG2 podcast en 2024 : « SaaS applications are essentially CRUD databases with business logic. In the future, this logic will migrate to AI agents. » Ce n’est pas un provocateur qui parle, vous en conviendrez. C’est le CEO de Microsoft, l’un des principaux fournisseurs de SaaS au monde qui dit que son propre modèle est en train de se périmer.

Mais avant d’aller là où cette bascule conduit, il faut regarder en face là où en sont réellement la plupart des ESNs aujourd’hui. Parce que le chemin vers l’entreprise agentique commence rarement là où on le croit.

Un modèle financier déjà sous pression — avant même l’agentique

Les données 2025 sont sans appel. Selon l’étude Grand Angle ESN & ICT publiée par Numeum et KPMG, les revenus des ESN françaises ont reculé d’environ 2,1% en 2025 — contre des croissances annuelles supérieures à 6% entre 2021 et 2023. Ce n’est pas un trou d’air. C’est un retournement structurel.

Le mécanisme est simple et brutal. Le modèle historique des ESNs repose sur une équation : chiffre d’affaires = TJM × jours vendus × taux d’occupation. Pendant vingt ans, cette équation a fonctionné parce que les trois variables étaient favorables. Plus ce n’est le cas. Les directions achats ont massifié leurs dépenses, généralisé les contrats cadres avec des tarifs bloqués et des baisses tarifaires à chaque renouvellement — le TJM moyen baisse ou stagne. Les rémunérations des profils qualifiés (cloud, data, cybersécurité, IA) ont continué à progresser — le coût salarial augmente. Et avec le ralentissement des projets, les périodes d’inter-contrat s’allongent — le taux d’occupation baisse.

Ces trois mouvements simultanés créent un effet ciseaux : à chaque renouvellement de contrat, la marge se contracte mécaniquement, sans qu’aucune « mauvaise gestion » n’en soit responsable. La structure même du modèle produit l’érosion.

Ce constat a une conséquence que beaucoup refusent encore d’admettre : quand plus de 70% du chiffre d’affaires dépend encore de la régie pure, le modèle n’a pas commencé à changer. Et vendre plus n’est plus une stratégie de conquête — c’est une stratégie de défense sur un marché qui se rétrécit.

J’espère heurter personne, mais je crois qu’il est important d’avoir ce contexte en tête comme point de départ. Parce que l’IA agentique n’arrive pas dans un monde sain en quête de croissance supplémentaire. Elle arrive dans un monde sous pression, avec des équipes commerciales formées à la régie depuis quinze ans, des objectifs alignés sur le volume court terme, et des managers qui protègent leur P&L local plutôt que de mutualiser. C’est brutal, probablement un peu réducteurs, mais ce terreau conditionne tout ce qui suit.

Du SaaS au Service-as-a-Software : ce que Nadella a compris avant les autres

La citation de Nadella mérite qu’on s’y arrête, parce qu’elle contient une rupture de paradigme pas facile à vraiment digérer. Le SaaS classique est une interface sur une base de données avec de la logique métier. L’utilisateur interagit avec l’interface, déclenche des opérations, et les résultats s’affichent. C’est une architecture centrée sur l’humain comme opérateur.

Ce que Nadella pointe — et ce que le marché commence à appeler Service-as-a-Software — c’est le déplacement de la logique métier vers une couche d’intelligence qui exécute directement. L’interface devient secondaire, parfois inutile. Ce qui compte, ce n’est plus l’outil mis à disposition — c’est le résultat produit.

Concrètement, cela signifie que le besoin passe de « livrer un audit » à « améliorer la marge ». De « fournir un rapport » à « optimiser le mix média ». De « configurer un CRM » à « qualifier et activer les leads en continu ». Ce déplacement est brutal pour les acteurs du conseil traditionnel — parce qu’il remet en question non seulement leur offre, mais leur rapport fondamental à la valeur.

Mais ici, il faut être honnête sur un point que beaucoup esquivent. Nombreuses sont les ESNs qui ont tenté de packager des offres plus engageantes — centres de services avec SLA, managed services, forfaits — en gardant un delivery artisanal derrière. Ça tient un temps, puis ça explose, parce que la promesse dépasse la capacité réelle d’exécution. Vendre de la valeur sans changer la manière de produire est une imposture qui se révèle toujours — et souvent au pire moment, chez le client le plus stratégique.

Le passage vers le Service-as-a-Software n’est donc pas d’abord un saut technologique. C’est d’abord un saut d’industrialisation du delivery. Celles qui n’ont pas encore franchi ce premier cap trouveront dans l’agentique un accélérateur de leurs problèmes existants, pas une solution.

Une capability n’est pas un composant d’exécution. Elle en est l’ancrage.

C’est ici que la notion de Business Capability Mapping, que je défends depuis longtemps dans mes travaux sur l’alignement Business-SI, prend une dimension opérationnelle qu’elle n’avait pas encore.

Une capability est une capacité stable, répétable, à produire un outcome métier mesurable. Elle est stable — elle transcende les outils, les technologies, les organisations qui changent tous les dix-huit mois. Elle est mesurable — on peut en définir les KPIs, la comparer entre versions, en améliorer la performance. Elle est assignée à un humain responsable — jamais à un système.

Ce qui change avec l’ère agentique, c’est la façon dont une capability s’exécute. Jusqu’ici, elle s’exécutait principalement via des équipes humaines, aidées par des outils SaaS. Demain, une capability sera motorisée par une chorégraphie d’exécutions agentiques — des composants spécialisés qui collaborent, s’enchaînent, se supervisent mutuellement, avec une implication humaine plus ou moins avancée selon la nature des décisions.

Il faut être précis sur ce point, parce que la confusion est fréquente : un composant d’exécution agentique n’est pas une capability. Il en est un moteur partiel. La capability de « pricing dynamique » dans une enseigne de distribution est une entité stable qui repose sur une intention métier, des règles, des KPIs, et un Capability Owner humain. Elle sera exécutée demain par une chorégraphie intégrant un composant d’analyse de la position concurrentielle, un composant de vérification du stock disponible, un composant de calcul du prix optimal, et une gate de validation humaine pour les décisions au-delà d’un certain seuil d’impact. Chacun de ces composants est spécialisé, interchangeable, versionnable. Ensemble, ils servent la capability. Mais la capability, elle, transcende la configuration technologique du moment.

Cette distinction est fondamentale pour les ESNs qui veulent se positionner comme opérateurs de capabilities agentiques. Ce qu’elles opèrent, ce n’est pas de la technologie — c’est une capacité métier de leur client, motorisée par de la technologie. Et cette différence change radicalement la nature du service rendu, le niveau d’engagement sur les résultats, et les compétences requises.

Le Product Builder : le profil qui manque au passage à la production

Le défi que toutes les ESNs ambitieuses vont rencontrer est bien documenté par les praticiens qui l’ont déjà vécu : près de 95% des projets d’IA générative échouent à atteindre la production. Pas « échouent à scaler » — n’atteignent même pas la production. Les POC s’accumulent, les démos internes impressionnent, et entre le prototype qui fonctionne et le produit qui tourne en conditions réelles, le fossé reste immense.

Ce fossé n’est pas technologique. C’est un fossé de profil. Il manque dans la grande majorité des organisations — côté ESN comme côté client — quelqu’un capable de tenir simultanément la vision produit, la maîtrise technique et la capacité de construction. Quelqu’un qui transforme une idée en MVP fonctionnel à une vitesse qui permet de tester, valider et itérer. Quelqu’un qui « builde » pour découvrir les zones grises que la spécification ne révèle jamais — les cas limites, les exceptions métier, les règles implicites que personne n’avait formalisées.

Ce profil émerge aujourd’hui sous le nom de Product Builder — une figure hybride entre le Product Manager traditionnel, le data engineer, et l’architecte IA. Ce qui la distingue fondamentalement : elle ne spécifie pas pour que d’autres construisent. Elle construit pour que la spécification soit validée par la réalité. C’est un changement de séquence qui change tout.

Sur les systèmes d’exécution agentique, ce rôle prend toute sa dimension. Plus un système est autonome, plus il exige de rigueur dans le cadrage — et cette rigueur ne peut s’acquérir qu’en construisant, en confrontant les cas limites, en documentant les zones grises. Le Product Builder est la personne qui fait le lien entre le métier qui imagine, la donnée qui alimente, et l’ingénierie qui industrialise. Pour les ESNs qui veulent opérer des capabilities agentiques, c’est un profil central — pas accessoire.

Mais attention à une erreur symétrique. Le Product Builder ne suffit pas seul. Il prépare le passage à la production. Il produit ce que Converteo appelle le « dossier de passation » — le contrat de confiance entre le Product et la Tech. Une fois ce passage franchi, quelqu’un d’autre prend le relais : l’AgentOps Engineer, responsable du run en production. Et au-dessus des deux, ancré dans le métier et non dans la technologie : le Capability Owner. Ces trois rôles sont indissociables. Une ESN qui déploie sans Capability Owner livre de la technologie sans responsabilité métier. Une ESN qui déploie sans Product Builder accumule de la dette de conception. Une ESN qui déploie sans AgentOps Engineer n’a pas d’exploitation — elle a des POC en production.

La verticalisation : la condition de la pertinence

Il y a une tentation, dans les ESNs qui abordent le sujet agentique, de proposer des offres transverses — des plateformes génériques, des méthodologies universelles, des catalogues d’agents « toutes industries ». C’est exactement la mauvaise réponse au bon diagnostic.

Ce qui distingue une capability motorisée par de l’exécution agentique d’un outil SaaS générique, c’est précisément sa contextualisation. La capability de « gestion des promotions » dans la grande distribution n’a rien à voir avec la capability de « gestion des promotions » dans le consumer goods. Les données ne sont pas les mêmes. Les règles métier ne sont pas les mêmes. Les exceptions ne sont pas les mêmes. Les seuils d’escalade humaine ne sont pas les mêmes. Et les KPIs d’outcome ne sont pas les mêmes.

Un agent de pricing dynamique dans le retail alimentaire doit comprendre la saisonnalité des catégories fraîches, les contraintes de marge nette par référence, les règles promotionnelles négociées avec les distributeurs, et les signaux de position concurrentielle par zone de chalandise. Un agent de pricing dans l’e-commerce de mode doit comprendre la gestion des collections, la dépréciation des stocks en fin de saison, la sensibilité des segments clients au prix, et l’impact des campagnes d’acquisition payante sur la demande. Ce n’est pas le même agent. Ce n’est pas la même capability. Et ce n’est certainement pas la même expertise.

Les ESNs qui tireront leur épingle du jeu dans l’opération de capabilities agentiques sont celles qui auront choisi leurs verticales — deux ou trois, pas dix — et qui auront investi dans la connaissance métier suffisamment profonde pour que leurs composants d’exécution soient crédibles aux yeux des Capability Owners clients. La généralité est le refuge des acteurs qui n’ont pas encore choisi. La verticalisation est la condition de la pertinence.

Je suis convaincu qu’à l’ère agentique il faut renoncer à être tout pour tout le monde et éviter de surfer sur les tendances du moment. Il faut choisir et maitriser qui l’on est, et prouver que l’on peut l’exécuter.

Le verrou que ni la vision ni la technologie ne déverrouillent

Il y a dans l’histoire des transformations d’ESNs une constante décourageante : le diagnostic est presque toujours juste. Les dirigeants savent qu’il faut sortir de la régie, industrialiser le delivery, vendre de la valeur, se spécialiser. Ce n’est pas la vision qui manque. C’est l’exécution.

Les plans de transformation échouent pour des raisons très humaines et très concrètes. Les commerciaux formés à la régie depuis quinze ans savent que dans le passé elle leur a permis de toucher de belles primes. Les managers savent staffer vite. Les consultants sont habitués à leur autonomie. Les BU protègent leur P&L. Proposer des offres packagées, mutualiser, standardiser, travailler en transverse — tout cela bouscule des zones de confort ancrées depuis deux décennies. Et les résistances ne sont pas frontales : on retarde, on contourne, on « adapte », on explique que « chez nous, c’est différent. »

Le verrou central est souvent là où on ne regarde pas : les incentives. Si on continue à rémunérer les commerciaux sur le volume court terme, ils feront du court terme. Si on évalue les managers sur leur marge locale, ils refuseront la mutualisation. Si on récompense les héros qui « sauvent » les projets en crise, personne ne prendra le temps de documenter les processus. Les comportements sont rationnels. Ils s’adaptent au système de récompense. Beaucoup de transformations échouent parce qu’elles ignorent cette dimension totalement humaine et très logique.

Pour les ESNs, comme pour toutes les entreprises, l’entrée dans le monde de l’agentique marque d’abord et avant tout une rupture dans l’organisation.

C’est un point sur lequel il faut être lucide : Stackmint.ai — dont nous parlerons en conclusion — est une infrastructure de gouvernance de l’exécution agentique. Ce n’est pas un levier de changement culturel. Il gouverne l’exécution une fois que les humains ont décidé de changer de modèle. Mais si les incentives n’ont pas changé, si les Capability Owners ne sont pas désignés et impliqués, si le delivery reste artisanal en amont — l’infrastructure ne peut pas compenser ce qui manque en amont d’elle.

La séquence compte. Avant de déployer une infrastructure de gouvernance agentique, une ESN a intérêt à s’assurer qu’elle a résolu le premier problème : savoir industrialiser ce qu’elle promet.

Ce que personne ne construit seul — l’infrastructure de gouvernance comme condition finale

Une fois ces prérequis posés — industrialisation du delivery, verticalisation assumée, profils adaptés, incentives alignées — reste une pièce que les ESNs les plus ambitieuses risquent de vouloir construire en interne par réflexe d’indépendance. C’est l’infrastructure de gouvernance de l’exécution agentique.

Opérer une capability agentique en production, c’est accepter que des composants d’exécution prennent des décisions à grande vitesse, sur des données dont la fraîcheur, la qualité et la cohérence sémantique n’ont peut-être pas été vérifiées. C’est accepter que ces décisions produisent des effets dans les systèmes réels — prix modifiés, commandes passées, clients contactés — avant qu’aucun humain n’ait eu le temps de les valider. Et c’est accepter que le modèle économique à la performance — abonnement, usage, résultats partagés — ne tienne que si l’audit trail de chaque décision est complet, immuable, et opposable.

Ces exigences ne s’improvisent pas. Elles nécessitent une infrastructure conçue pour ça : des contrats d’exécution versionnés et immuables qui définissent ce que chaque composant est autorisé à faire. Un Data Contract qui vérifie, avant chaque exécution, que les données d’entrée satisfont les conditions de qualité, de sémantique et de fraîcheur déclarées par le Capability Owner. Des gates de supervision humaine qui se déclenchent automatiquement selon des seuils prédéfinis. Un audit trail append-only qui rend chaque décision rejouable des années après sa production.

La tentation de construire tout cela en interne est compréhensible. Elle reproduit pourtant l’erreur du SaaS : investir massivement dans ce qui ne différencie pas — l’infrastructure — au lieu de se concentrer sur ce qui différencie vraiment — la connaissance métier verticale, la relation client, la capacité à qualifier des capabilities et à les faire vivre dans le temps.

C’est précisément ce que Stackmint.ai construit — l’infrastructure d’exécution gouvernée pour l’entreprise agentique. Pour les ESNs qui veulent opérer des capabilities agentiques pour leurs clients, Stackmint est le plan de contrôle transverse qui transforme l’ambition en réalité opérationnelle responsable. Pas un outil à configurer — une infrastructure à adopter pour que l’opération tienne en production, à l’échelle, dans le temps.

La question que toute ESN qui veut se positionner comme opérateur de capabilities agentiques gagnerait à se poser n’est pas « quelle technologie d’IA utilisons-nous ? » C’est : « avec quelle infrastructure de gouvernance allons-nous opérer ces capabilities de façon à pouvoir nous engager sur des résultats ? » Et avant même cette question : « avons-nous industrialisé notre delivery au point de pouvoir tenir la promesse ? »

La réponse à ces deux questions dessine le positionnement concurrentiel de la décennie qui vient. Les ESNs, cabinets de conseil, intégrateurs — quelle que soit leur forme — ne vendront plus du conseil. Ils vendront de l’exécution. Pas de l’exécution déclarative — de l’exécution gouvernée, traçable, et engagée sur des résultats. Ce n’est pas la même chose. Et personne ne peut prétendre y être sans avoir résolu, dans cet ordre, le problème de l’industrialisation, le problème du profil, et le problème de la gouvernance.

« Du SaaS au Service-as-a-Software, la frontière entre le conseil et l’exécution se déplace. Ceux qui auront résolu dans l’ordre : l’industrialisation du delivery, la verticalisation de l’offre, l’alignement des incentives, la formation des Product Builders et des Capability Owners, et l’adoption d’une infrastructure de gouvernance — ceux-là auront un avantage que ni les outils ni les modèles ne pourront combler. Les autres auront de bons slides. »