Après la régie : quatre modèles pour vendre une capacité, un service ou un résultat

L'IA ne signe pas la fin de la régie. Elle crée cependant un problème économique très concret pour les ESN : lorsque davantage de travail peut être produit, vérifié ou automatisé avec moins de temps humain, le nombre de jours consommés explique moins bien la valeur créée.

Le mouvement est déjà perceptible. En France, 72 % des ESN et sociétés d'ingénierie interrogées par Numeum et KPMG déclaraient en 2025 utiliser l'IA générative dans leur delivery. Au premier semestre 2026, 49 % des ESN interrogées par Numeum-Xerfi citaient la pression sur les prix parmi leurs principaux freins et 58 % disaient se repositionner par l'automatisation et l'IA.

Mais « sortir du TJM » ne conduit pas à un modèle unique. Le forfait, l'abonnement de capacité, le managed service et la monétisation d'actifs ne répartissent ni le risque, ni la marge, ni la responsabilité de la même manière.

L'après-régie n'est pas l'outcome-based. C'est le passage d'une unité de vente dominante, le jour, à un portefeuille de modèles contractuels choisis selon trois questions : que peut-on réellement contrôler, que peut-on mesurer, et que peut-on réutiliser ?

En bref

• •La régie ne disparaît pas. Elle reste rationnelle lorsque le périmètre est incertain, que l'expertise humaine est rare ou que le client veut garder la maîtrise du delivery.
• •L'IA fragilise surtout le lien entre effort et valeur. Si une même équipe produit davantage, vendre uniquement des jours expose soit le chiffre d'affaires du fournisseur, soit la confiance du client.
• •Quatre modèles méritent d'être distingués. Forfait agentique, capacité-as-a-service, managed service orienté résultat et asset-based service répondent à des situations différentes.
• •Les modèles hybrides seront probablement plus robustes que les bascules radicales. Une part fixe rémunère souvent la capacité et le risque ; une part variable, l'usage, le niveau de service ou le résultat.

Ce qui change vraiment : la régie est concurrencée, pas condamnée

Le signal sectoriel existe désormais explicitement. Lors de son premier Forum des ESN & ICT, en juin 2026, Numeum résumait l'évolution ainsi : la régie au TJM est de plus en plus concurrencée par des engagements fondés sur la capacité, le résultat ou le gain partagé. Il faut toutefois bien qualifier cette source : il s'agit d'une restitution d'échanges réunissant plus de 60 dirigeants du secteur, et non d'une enquête statistique démontrant le basculement de l'ensemble du marché.

Ce constat rejoint une tendance plus large dans les services intellectuels : un déplacement progressif du temps-homme vers des modèles outcome-based, Consulting-as-a-Service et asset-based — avec une mise en garde constante contre une lecture simpliste consistant à réclamer seulement une baisse des TJM au motif que l'IA accélère certaines tâches.

La transposition aux ESN doit néanmoins être prudente. Une ESN ne vend pas seulement de l'analyse ou un livrable intellectuel. Elle peut prendre la responsabilité d'un système en production, maintenir une application pendant des années, garantir une disponibilité, absorber des incidents ou intégrer des systèmes hétérogènes. La conclusion la plus mesurée est donc que le TJM peut subsister comme unité contractuelle, mais qu'il suffit de moins en moins à raconter toute la valeur de certaines prestations.

Le problème n'est pas le TJM en soi. C'est le TJM utilisé pour vendre un travail dont la valeur se décorrèle de plus en plus du nombre de jours nécessaires pour le produire.

Les données montrent une transformation du delivery, pas encore une révolution des revenus

Il serait tentant d'enchaîner trois raisonnements : l'IA augmente la productivité ; donc les ESN auront besoin de moins de personnes ; donc les clients n'achèteront bientôt plus de jours. Les données disponibles ne permettent pas d'aller aussi vite.

L'étude Numeum-KPMG 2025 montre une diffusion déjà importante de l'IA dans le delivery : 72 % des entreprises interrogées déclaraient l'utiliser, sur un échantillon de près de 200 ESN et sociétés d'ingénierie et de conseil en technologies. Cela documente une adoption, pas un niveau uniforme de productivité ni une évolution contractuelle équivalente chez tous les répondants.

L'enquête mondiale de Deloitte sur l'externalisation apporte un contrepoint encore plus utile. Parmi plus de 500 dirigeants, 83 % déclaraient utiliser l'IA dans les services externalisés. Pourtant, seulement 25 % observaient une réduction des coûts fournisseurs ou une amélioration de la qualité de service. Deloitte constate parallèlement une progression des modèles orientés résultats.

Introduire de l'IA dans le delivery n'implique ni automatiquement un meilleur service, ni automatiquement une meilleure marge, ni automatiquement un nouveau contrat.

ISG observe de son côté que les agents GenAI entrent progressivement dans le développement et la maintenance applicative européens — développement, tests, gestion applicative —, ce qui renforce la possibilité technique d'industrialiser certains engagements de service. Son étude 2025 porte sur 33 fournisseurs européens de services ADM.

Un signal organisationnel complète ce tableau : dans un panel de trente entreprises observées, un modèle « humain sur les exceptions » apparaît, où l'automatisation absorbe les cas standards et les humains prennent en charge les situations incertaines. Roundtable en est un cas parlant : selon un témoignage recueilli, un processus portant sur 1 000 SPV peut être trié automatiquement pour ne faire remonter à l'humain qu'une quinzaine ou une vingtaine de cas problématiques. Ce cas montre qu'un volume opérationnel peut se décorréler du volume de travail humain. Il ne démontre pas qu'un client acceptera de payer cette capacité selon un nouveau modèle, ni que la qualité du tri serait transposable à n'importe quel processus.

C'est précisément là que commence la question du business model.

Quatre modèles après la régie

Ces quatre modèles ne constituent pas une taxonomie reconnue du marché. Ils forment une grille de lecture construite à partir des modèles observés dans les services intellectuels et des travaux sectoriels ESN.

Modèle 1 — Le forfait agentique : vendre une transformation bornée plutôt que les jours nécessaires

Le forfait n'a évidemment pas attendu l'IA. Ce qui change est la capacité du prestataire à réduire fortement l'effort consacré à certaines étapes : analyse d'une base de code, génération de tests, documentation, premiers correctifs, migrations ou conversions standardisées.

Dans un contrat au forfait, le fournisseur peut théoriquement conserver une partie du gain de productivité : si le prix est lié au périmètre accepté et non au nombre de personnes mobilisées, produire plus efficacement améliore sa marge.

C'est ce qui rend le forfait agentique intéressant. Le terme désigne ici un forfait dans lequel une partie significative du delivery est confiée à des agents, avec des critères d'acceptation et une supervision humaine conçus dès le contrat.

Ce modèle devient crédible lorsque trois éléments peuvent être stabilisés : le périmètre, les critères d'acceptation et les conditions de réversibilité. Une migration bien spécifiée, l'augmentation d'une couverture de tests, le refactoring d'un composant identifié ou la production d'une documentation structurée s'y prêtent davantage qu'une transformation dont le client découvre encore le besoin.

Le point décisif n'est donc pas « combien de code l'IA peut-elle écrire ? ». Il est : « sommes-nous capables de dire objectivement si le travail livré est correct ? »

L'IA augmente sinon un risque classique du forfait : produire vite quelque chose qu'il faudra reprendre longtemps.

Le fournisseur doit alors intégrer les tests, les évaluations, la non-régression, la sécurité et la review humaine dans son coût complet. La marge réelle n'est pas simplement le prix du forfait moins les salaires. Elle doit aussi intégrer les modèles utilisés, le calcul, les licences, les contrôles de qualité et la maintenance des outils agentiques.

Modèle hybride pertinent : forfait de réalisation + enveloppe en régie pour les zones non spécifiables. La régie n'est alors pas l'ancien modèle conservé par défaut ; elle sert explicitement à financer l'incertitude.

Modèle 2 — La capacité-as-a-service : ne plus vendre cinq personnes, vendre une capacité disponible

Le deuxième modèle répond au défaut symétrique du forfait : beaucoup de besoins numériques sont impossibles à figer suffisamment tôt.

Une équipe produit, un domaine data ou une plateforme interne peuvent savoir qu'ils auront besoin d'une capacité durable de développement et de maintenance sans pouvoir préciser aujourd'hui l'ensemble des features des six prochains mois.

La régie répond historiquement très bien à cette incertitude : le client achète des personnes et décide ensuite de leur utilisation.

La capacité-as-a-service cherche à conserver cette flexibilité tout en changeant l'objet vendu. Le client n'achète plus nominativement cinq développeurs pendant un trimestre. Il achète, par exemple, une capacité de delivery dans un domaine donné, associée à des délais de réponse, des classes de service, une gouvernance et des critères de qualité.

Le contrat porte davantage sur ce que le système de delivery peut absorber que sur la présence quotidienne de chaque individu.

Cette logique se rapproche du Consulting-as-a-Service, mais la transposition ESN doit être plus opérationnelle : un service numérique doit préciser ce qui entre dans la capacité, ce qui se passe lorsque la demande la dépasse, comment sont traitées les urgences, comment la qualité est mesurée et qui porte la responsabilité de la production.

L'intérêt économique est double. Le client gagne une enveloppe plus prévisible. L'ESN peut choisir librement son mix de seniors, juniors, spécialistes et agents tant qu'elle respecte ses engagements.

Mais ce modèle a un anti-pattern évident : la régie maquillée en abonnement.

Si la proposition commerciale reste « quatre développeurs et un Tech Lead », simplement facturés mensuellement sous l'étiquette « capacity », rien n'a réellement changé. La capacité doit être décrite par le service rendu, son débit, ses contraintes et ses niveaux de qualité, pas uniquement par des ETP invisibilisés.

Ce modèle convient particulièrement lorsque l'incertitude produit reste élevée et que l'outcome final dépend encore fortement des décisions du client. Il évite alors de demander au fournisseur de garantir un résultat sur lequel il n'a pas assez de contrôle.

Modèle hybride pertinent : abonnement de capacité + facturation d'un dépassement exceptionnel + bonus limité sur certains indicateurs de delivery.

Modèle 3 — Le managed service orienté résultat : vendre une performance que l'on peut réellement piloter

Le managed service change davantage la répartition des responsabilités.

Le prestataire ne fournit plus seulement une capacité de produire. Il prend en charge un processus ou un système dans la durée : maintenance applicative, cloud, service desk, sécurité, exploitation d'une plateforme, qualité applicative ou opérations métier.

L'IA renforce l'intérêt de cette logique parce qu'elle permet d'absorber une partie du volume standard sans faire croître proportionnellement les effectifs : tri automatique, premiers diagnostics, classification d'incidents, suggestions de correction, production de tests ou surveillance prédictive.

Mais « orienté résultat » ne signifie pas forcément « payé uniquement au résultat ». C'est même souvent une mauvaise idée.

Dans un système informatique réel, la disponibilité, le MTTR, la fréquence de livraison ou le coût d'exploitation dépendent aussi du legacy du client, de la qualité des données, d'autres fournisseurs, des arbitrages métiers ou des changements de périmètre.

Transférer tout ce risque à l'ESN conduit soit à des prix très élevés, soit à des conflits interminables sur l'attribution des résultats.

Le modèle le plus défendable est donc souvent hybride : socle fixe d'exploitation + engagements SLA/SLO + part variable plafonnée sur quelques performances que le fournisseur peut réellement influencer.

La question clé est ici celle du contrôle. On peut raisonnablement engager un fournisseur sur le délai de prise en charge d'un incident s'il possède l'exploitation. Il est beaucoup plus difficile de l'engager sur la croissance du chiffre d'affaires d'un produit si le pricing, le marketing, le produit et la distribution restent contrôlés par le client.

Plus l'outcome s'éloigne du périmètre contrôlé par l'ESN, plus le contrat doit redevenir prudent.

Modèle 4 — L'asset-based service : vendre plusieurs fois ce qui était auparavant reconstruit à chaque mission

Le quatrième modèle est celui qui modifie le plus directement l'économie d'une ESN.

Un connecteur, une bibliothèque sectorielle, un moteur de migration, un dispositif d'évaluations, un agent de diagnostic, un accélérateur de conformité ou un cockpit opérationnel peuvent être construits lors d'une première mission puis réutilisés.

Au lieu de recommencer intégralement le delivery, l'ESN capitalise et monétise une propriété intellectuelle — une logique d'asset-based consulting : des actifs réutilisables peuvent être monétisés par licence, abonnement ou consommation.

Pour une ESN, le modèle économique peut combiner quatre couches : droit d'usage de l'actif, intégration initiale, exploitation et maintenance, puis éventuellement consommation variable.

Le cas Palantir est instructif parce qu'il brouille depuis longtemps la frontière entre logiciel et services. La documentation officielle de l'entreprise indique que ses plateformes sont développées selon une méthodologie de Forward Deployed Engineering, dans laquelle des ingénieurs travaillent au contact des environnements opérationnels des clients.

Ce cas montre la puissance potentielle d'une combinaison entre actif logiciel propriétaire et capacité humaine de déploiement. Il ne démontre pas que toutes les ESN doivent devenir des éditeurs, ni que cette combinaison produit mécaniquement de meilleures marges.

La difficulté est précisément là : passer de « nous avons développé un accélérateur » à « nous possédons un produit maintenable et vendable » est un changement d'organisation.

Un actif monétisable doit avoir un propriétaire, une roadmap, des versions, des tests, une politique de sécurité, un coût de maintenance, des conditions de licence et un modèle de support. Sinon, le patrimoine d'IP se transforme rapidement en cimetière de POC, de prompts et de scripts non maintenus.

L'autre difficulté est contractuelle. Dans les projets IT, les clients demandent fréquemment des droits importants sur le code produit. Il faut donc distinguer précisément les actifs préexistants de l'ESN, ce qui est co-construit et ce qui appartient spécifiquement au client.

Modèle hybride pertinent : licence ou abonnement de l'actif + forfait d'intégration + managed service de maintien en condition opérationnelle.

Le vrai choix ne porte pas sur quatre modèles, il porte sur trois questions

Il serait tentant d'afficher une nouvelle offre « outcome-based » parce qu'elle semble plus moderne qu'une offre en régie. Ce serait reproduire avec le business model une erreur déjà fréquente avec l'IA : partir de la solution avant d'avoir caractérisé le problème.

Plus l'incertitude est élevée, plus vendre du temps ou de la capacité reste rationnel. Plus le résultat est contrôlable et mesurable, plus il devient possible de vendre un service ou une performance. Plus la solution est répétable, plus il devient possible de vendre un actif.

Pourquoi les modèles hybrides devraient dominer la transition

Les quatre modèles ne s'excluent pas. Un même compte peut en combiner plusieurs.

Une phase de discovery peut rester au TJM parce que le problème lui-même n'est pas stabilisé. Une modernisation bien spécifiée passe ensuite au forfait. L'outil construit pendant cette phase devient un actif sous licence. Et l'exploitation de la nouvelle plateforme est transférée dans un managed service avec SLA.

Ce scénario n'est pas un compromis provisoire. Il peut constituer une architecture contractuelle durable.

Cette hybridation protège aussi les deux parties contre une mauvaise répartition du risque.

Le client n'a aucun intérêt à payer indéfiniment davantage parce que le fournisseur utilise plus d'humains qu'il n'en faudrait. Mais le fournisseur ne peut pas davantage garantir un résultat dont la moitié des déterminants restent entre les mains du client.

Le contrat devient donc moins une question de « nouvelle tarification IA » qu'une architecture explicite des responsabilités.

Pour les achats, le sujet n'est pas de demander « combien de jours l'IA économise ? »

La pression acheteur sur le TJM est compréhensible. Si une partie du travail est automatisée, pourquoi continuer à payer exactement comme avant ?

Mais cette question peut conduire à une mauvaise optimisation. Une prestation moins chère peut produire davantage de rework, transférer les coûts de review au client ou masquer une automatisation insuffisamment contrôlée. À l'inverse, un prestataire ne peut pas utiliser l'IA comme justification abstraite pour conserver l'intégralité du gain de productivité tout en ne changeant aucun engagement.

Les achats doivent donc déplacer la discussion vers cinq objets : la baseline, les critères de qualité, la répartition humain-agent, les responsabilités et la propriété intellectuelle — passer d'une négociation essentiellement centrée sur le prix du temps à une lecture de la preuve, de l'impact, de la gouvernance et des actifs laissés au client.

Pour le fournisseur, cette transparence peut sembler risquée. Elle est pourtant une condition pour capter une partie de la valeur créée par l'IA.

On défend difficilement un nouveau modèle de prix en gardant l'ancien modèle de preuve.

Changer de modèle de revenu oblige à changer l'ESN elle-même

Une nouvelle tarification ne tient pas longtemps si l'organisation reste pilotée comme une société de placement de ressources.

Le commercial rémunéré presque exclusivement sur le nombre de consultants staffés aura naturellement intérêt à défendre la régie. Le manager évalué sur le taux d'occupation hésitera à investir du temps dans un actif réutilisable. La BU dont le P&L ne distingue pas les coûts de modèles, de calcul et de maintenance ne connaîtra pas la marge réelle d'une offre agentique.

On ne devient pas asset-based parce qu'on a une bibliothèque d'accélérateurs. On le devient lorsqu'on accepte de financer, gérer et vendre certains de ces accélérateurs comme des produits.

De même, on ne devient pas outcome-based parce qu'une proposition commerciale contient un bonus. On le devient lorsque les opérations sont assez mesurées pour distinguer ce qui relève réellement de la performance du fournisseur.

Ce qui pourrait invalider la thèse d'un « après-régie »

Il existe au moins quatre raisons de ne pas extrapoler trop vite.

D'abord, les gains de productivité de l'IA restent très variables. Une forte adoption ne garantit pas une amélioration du coût complet, comme le montre l'écart entre les 83 % d'utilisateurs de l'IA dans l'outsourcing interrogés par Deloitte et les 25 % constatant une baisse des coûts fournisseurs ou une amélioration de la qualité.

Ensuite, la régie possède un avantage économique profond : elle est simple à comprendre et permet au client de garder le risque de périmètre. Plus l'environnement est incertain, moins le transfert de ce risque à un fournisseur est gratuit.

Troisièmement, les clients ne cherchent pas toujours davantage d'externalisation. Deloitte indique que 70 % des organisations interrogées avaient réinternalisé sélectivement certaines activités au cours des cinq années précédentes, même si une large majorité prévoyait simultanément de maintenir ou d'augmenter ses investissements en outsourcing.

Enfin, l'asset-based peut recréer un problème que les achats connaissent déjà bien : le lock-in. Plus un prestataire vend une plateforme propriétaire, plus il doit être capable d'expliquer la réversibilité, la portabilité des données et la frontière entre son actif et le patrimoine du client.

Ces limites ne renversent pas la thèse. Elles la précisent.

Il n'y aura probablement pas un modèle « après la régie ». Il y aura un marché où la régie cesse d'être la réponse automatique à des problèmes qui peuvent désormais être mieux contractualisés autrement.

Auto-diagnostic : votre offre peut-elle réellement sortir de la régie ?

• •Nous savons définir une baseline avant le début de la prestation.
• •Nous pouvons mesurer la qualité autrement que par le respect du staffing et du planning.
• •Nous savons distinguer les résultats que nous contrôlons de ceux qui dépendent principalement du client.
• •Nos critères d'acceptation permettent de vérifier objectivement une production réalisée en partie par des agents.
• •Notre offre de « capacité » est exprimée en service et en niveau de performance, pas simplement en ETP rebaptisés.
• •Pour un managed service, nous connaissons le taux d'exception, le rework et le coût réel de la supervision humaine.
• •Les coûts de modèles, de calcul, de licences et de contrôle qualité sont intégrés dans notre calcul de marge.
• •Nous savons quels composants de nos projets constituent réellement une propriété intellectuelle réutilisable.
• •Chaque actif que nous voulons commercialiser possède un propriétaire, une politique de maintenance et des droits d'usage clairs.
• •Nos commerciaux savent négocier une combinaison de fixe, capacité, usage et performance, pas seulement un TJM.
• •Nos contrats rendent explicites les responsabilités humaines, les conditions de réversibilité et la frontière entre nos actifs et ceux du client.
• •Nous savons expliquer au client pourquoi le nouveau prix est plus cohérent avec la valeur, sans simplement invoquer l'IA.

Si plusieurs réponses restent négatives, le problème n'est probablement pas encore le choix du pricing. Il est dans la maturité du delivery, de la mesure ou de la propriété intellectuelle.

La conviction

L'IA rend possible une transformation importante du modèle économique des ESN, mais le point de départ n'est pas la technologie.

Le vrai changement est que l'effort humain devient une mesure moins fiable de certaines prestations.

Lorsque le travail est spécifiable, il devient possible de vendre un périmètre et une preuve. Lorsque le besoin reste mouvant, il est possible de vendre une capacité plutôt que des individus. Lorsque le fournisseur maîtrise réellement un processus, il peut vendre un niveau de service et prendre une part raisonnable du risque de performance. Lorsque la solution se répète, il peut transformer son savoir-faire en actif et créer un revenu qui ne dépend plus directement du nombre de jours produits.

La régie conserve sa place là où l'incertitude, l'expertise rare ou la gouvernance client la rendent rationnelle.

La question stratégique pour une ESN n'est donc pas « comment sortir de la régie ? ». Elle est : « pour chaque offre, qu'est-ce que nos clients devraient réellement acheter chez nous : du temps, une capacité, un service, un résultat ou un actif ? »