Centre de services agentique : accélérer le delivery sans industrialiser la dette
Un centre de services devient agentique quand la chaîne entière devient mesurable et contrôlable, pas quand la part de code généré devient spectaculaire
Le centre de services agentique ne se résume pas à mettre Claude Code, Copilot ou des agents dans les mains des développeurs. À mesure que la production accélère, le risque se déplace vers ce qui encadre cette production : qualité du contexte, tests, capacité de review, droits de décision, déploiement, observabilité et coût complet. Pour une ESN, l'enjeu n'est donc pas seulement de produire davantage. Il est de construire une chaîne de delivery capable d'absorber cette vitesse sans multiplier les défauts, les reprises, les coûts cachés et les dépendances.
La thèse défendue ici est la suivante : un centre de services devient réellement agentique lorsque l'ensemble de la chaîne de production devient mesurable, contrôlable et réversible, pas lorsque la part de code générée par l'IA devient spectaculaire.
En bref
- •Les signaux de transformation sont réels. En France, 72 % des ESN et ICT interrogées par Numeum et KPMG déclaraient déjà utiliser l'IA générative dans leurs processus de delivery en 2025. Numeum et Xerfi estiment par ailleurs que les gains de productivité liés à l'IA dans les ESN pourraient passer de 15 % en 2025 à 22,3 % en 2027. Ces données sont déclaratives ou prospectives : elles ne constituent pas une mesure causale uniforme de la productivité.
- •Accélérer une étape ne garantit pas d'accélérer le système. Le rapport DORA décrit l'IA comme un amplificateur des forces et des faiblesses de l'organisation. Une adoption plus forte peut augmenter le débit tout en augmentant aussi l'instabilité du delivery.
- •Le goulot change de place. Plusieurs cas observés montrent un déplacement de l'écriture du code vers les specs, les évaluations, la review, la décision et la merge queue — un constat surtout documenté dans des organisations à forte culture engineering, qui ne peut pas être généralisé tel quel.
- •Le vrai KPI n'est donc pas « combien de code l'IA produit ». C'est le coût complet d'un changement accepté et exploitable : temps humain, modèles, licences, tests, review, rework, incidents, exploitation et maintenance des actifs agentiques.
Le piège : automatiser la production avant d'avoir industrialisé le contrôle
Un centre de services traditionnel a déjà ses fragilités : documentation incomplète, tests insuffisants, handoffs nombreux, dépendance à quelques sachants, dette technique, backlog qui grossit plus vite qu'il ne se résorbe.
L'IA ne supprime aucune de ces fragilités par magie. Elle peut au contraire leur donner plus de débit.
C'est précisément le point mis en avant par le rapport DORA 2025 : l'IA agit d'abord comme un amplificateur du système sociotechnique existant. Les meilleurs résultats ne viennent pas du déploiement isolé d'un outil, mais de la qualité du système organisationnel qui l'entoure.
Pour une ESN, la conséquence est importante. Une équipe capable de générer deux fois plus de changements mais incapable de les tester, de les revoir, de les mettre en production ou de les observer n'a pas doublé sa capacité de delivery. Elle a potentiellement doublé sa file d'attente.
Ce phénomène apparaît dans plusieurs cas de développement agentique : lorsque les agents produisent davantage de code, le goulot se déplace vers la décision, les spécifications, les évaluations et la review.
L'unité industrielle à optimiser n'est plus le développeur ni même la génération de code. C'est la chaîne complète qui transforme un besoin en comportement fiable en production.
Le marché confirme le mouvement, mais pas encore la promesse d'une productivité automatique
La transformation du delivery n'est plus marginale.
Dans l'étude Grand Angle ESN & ICT 2025, réalisée par Numeum et KPMG auprès de près de 200 ESN et ICT implantées en France, 72 % des répondants déclaraient déjà utiliser l'IA générative dans leurs processus de delivery.
L'Observatoire Numeum-Xerfi publié en juillet 2026 va plus loin. Sur 296 acteurs du numérique, dont 151 ESN, et 116 DSI, il estime les gains de productivité associés à l'IA dans les ESN à 15 % en 2025 et projette 22,3 % en 2027. Mais la même étude souligne que ces gains restent difficiles à transformer en marge : 35 % des ESN interrogées anticipaient une baisse de leur marge opérationnelle au premier semestre 2026, dans un contexte où 49 % citaient la pression sur les prix parmi leurs principaux freins.
Produire plus vite et gagner plus d'argent sont deux sujets différents.
Un centre de services peut améliorer localement la productivité du développement tout en voyant augmenter les licences et coûts d'inférence, le temps de review, le nombre de reprises, les investissements de plateforme, les coûts de sécurité et de conformité, ainsi que la maintenance des agents, prompts, connecteurs et jeux d'évaluation.
La transformation industrielle du delivery ne peut donc pas être pilotée par le seul taux d'adoption des outils ou par le nombre de pull requests produites.
Ce que montrent réellement Doctolib, Qonto et Anthropic
Les cas les plus spectaculaires deviennent dangereux lorsqu'on leur fait dire davantage qu'ils ne prouvent.
Doctolib : industrialiser l'environnement avant de généraliser l'usage
Le passage de 600 ingénieurs de Doctolib à un fonctionnement agentic-first en janvier 2026, après une année de pilote, ne repose pas uniquement sur des outils individuels : une équipe plateforme maintient notamment le tooling et les fichiers de contexte dans les dépôts, une fonction de formation accompagne les équipes et une équipe centrale pilote l'adoption. Certains ingénieurs orchestrent plusieurs agents simultanément.
Ce que le cas montre : un passage à l'échelle demande un environnement commun, du contexte, des règles et une capacité d'accompagnement.
Ce qu'il ne montre pas : que 600 ingénieurs utilisant des agents équivalent à un gain de productivité mesuré. L'adoption quasi totale n'est pas une mesure de l'impact.
La distinction est fondamentale pour un centre de services. « 90 % de nos développeurs utilisent l'IA » décrit un équipement. Pas une performance industrielle.
Qonto : déplacer l'évaluation avant le bug
Chez Qonto, l'intégration d'évaluations dans la CI et environ 800 modifications de code autonomes par mois en mars 2026 s'appuient sur un principe simple : distinguer un produit IA qui fonctionne d'un produit IA suffisamment fiable pour être mis en production. La stratégie IA y est structurée et pilotée explicitement.
Ce que le cas montre : lorsqu'un agent contribue au code, l'évaluation ne peut pas rester une activité finale. Elle doit entrer dans le pipeline de développement.
Ce qu'il ne montre pas : que cette organisation est supérieure à une architecture plus distribuée, ni que les niveaux de performance peuvent être comparés d'un produit à l'autre.
Pour une ESN, la leçon n'est donc pas « copier Qonto ». Elle est plus simple : si l'agent entre dans la chaîne de production, les évaluations doivent entrer dans la chaîne de production avec lui.
Anthropic : le meilleur cas pour comprendre le nouveau goulot, et le pire pour faire un benchmark
Anthropic constitue l'un des cas les plus avancés : son CPO a déclaré que 90 à 95 % du code de Claude Code était écrit par Claude Code lui-même et que la part de pull requests générées par l'IA avait imposé une refonte de la merge queue. Les ingénieurs passent davantage de temps à superviser et revoir qu'à produire directement.
Le signal est utile : quand la production devient abondante, la capacité rare se déplace vers l'intégration et le jugement.
Mais Anthropic est aussi une organisation AI-native, à utiliser comme référence plutôt que comme cible directement transposable aux organisations historiques. Une ESN gérant des centaines d'applications legacy, plusieurs clouds, des SLA clients et quinze années de dette technique ne travaille pas dans le même environnement.
Le contre-exemple qui oblige à rester prudent : l'IA peut aussi ralentir
La littérature empirique interdit aujourd'hui d'utiliser un taux de productivité universel.
Dans une expérience randomisée publiée en 2025, METR avait observé que 16 développeurs open source expérimentés travaillant sur leurs propres dépôts mettaient 19 % de temps supplémentaire lorsqu'ils étaient autorisés à utiliser les outils IA étudiés.
METR a depuis fortement nuancé la portée temporelle de ce résultat. En février 2026, l'organisation estimait probable que les outils plus récents produisent davantage de gains, mais jugeait ses nouvelles données insuffisamment fiables pour mesurer correctement leur ampleur, notamment à cause de biais de sélection et de l'utilisation simultanée de plusieurs agents.
Ce contre-exemple ne prouve évidemment pas que l'IA ralentit le développement en général. Il prouve quelque chose de plus utile pour un dirigeant de centre de services : le gain dépend du type de tâche, de la codebase, de l'expérience, de la qualité du contexte et du coût de vérification.
Une architecture industrielle sérieuse ne doit donc pas commencer par une promesse de « +30 % de productivité ». Elle commence par une baseline.
La chaîne minimale d'un centre de services agentique
L'Agentic Factory peut être pensée comme un système industriel de delivery, et non comme une collection de chatbots ou de copilotes individuels : elle articule contexte, orchestration, engineering toolchain, qualité, contrôle humain, observabilité et capitalisation.
Contexte → Agents → Tests & évaluations → Review → Déploiement → Observabilité → Apprentissage
| Étape | Ce que la machine peut faire | Ce qui doit rester explicite côté humain | Dette créée si l'étape est faible |
|---|---|---|---|
| Contexte | Rechercher code, tickets, docs, logs et règles. | Définir la source de vérité, les permissions et les contraintes. | Agent rapide mais systématiquement mal informé. |
| Agents | Analyser, découper, coder, documenter, préparer des tests. | Définir le périmètre d'autonomie et les opérations interdites. | Agents dupliqués, prompts incontrôlés, dépendances opaques. |
| Tests & évaluations | Générer et exécuter tests, scénarios et contrôles. | Définir les critères d'acceptation et les cas critiques. | Faux sentiment de qualité, régressions invisibles. |
| Review | Pré-review, lint, analyse statique, comparaison aux conventions. | Juger architecture, métier, sécurité et arbitrages. | Merge queue saturée ou validation superficielle. |
| Déploiement | Préparer pipeline, feature flags, canary et rollback. | Autoriser les changements à risque selon leur réversibilité. | Incidents plus rapides et rayon d'impact plus large. |
| Observabilité | Corréler logs, changements, coûts et anomalies. | Décider des seuils, escalades et interventions. | Impossible de comprendre après coup ce qui s'est passé. |
| Apprentissage | Proposer corrections et capitaliser les patterns. | Décider ce qui devient un actif standard. | Répétition des erreurs et accumulation d'une dette agentique. |
Le contexte devient une infrastructure de production
Un agent n'est performant que sur le contexte auquel il a accès.
Dans un centre de services, ce contexte dépasse largement la documentation technique : le code et son historique, les conventions d'architecture, les incidents passés, les règles métier, les dépendances, les exigences non fonctionnelles, les décisions antérieures, les contraintes contractuelles, les politiques de sécurité et les données de test.
La documentation cesse progressivement d'être uniquement un livrable destiné aux humains. Elle devient une partie de l'infrastructure d'exécution.
Cela change aussi les responsabilités. Un document périmé n'est plus seulement désagréable pour le prochain développeur : il peut contaminer automatiquement des dizaines de productions agentiques.
Le centre de services doit donc commencer à traiter la qualité du contexte comme il traite déjà la qualité du code.
Les agents doivent recevoir des droits, pas une liberté abstraite
L'expression « agent autonome » est trompeuse si elle masque une question plus concrète : autonome pour faire quoi ?
Analyser un incident, préparer un correctif, lancer un test, modifier une configuration de production ou effacer une base de données ne sont pas des décisions équivalentes.
Le bon niveau d'autonomie dépend notamment de quatre critères : réversibilité, impact potentiel, confiance dans les évaluations et capacité d'observation.
L'ANSSI recommande que les interactions critiques d'un système d'IA avec le système d'information puissent être contrôlées par un humain et que les opérations à privilèges soient explicitement définies et validées. Elle recommande également de sécuriser la chaîne de déploiement et de séparer correctement les environnements.
Un centre de services agentique n'est donc pas un centre de services sans humains. C'est un centre de services où le niveau d'autorité de chaque acteur, humain ou agent, est formalisé.
Les tests changent de rôle : de contrôle final à frontière d'autonomie
Dans un delivery classique, les tests servent principalement à vérifier une production.
Dans un delivery agentique, ils remplissent une deuxième fonction : ils déterminent jusqu'où on peut laisser la machine agir.
Une tâche parfaitement spécifiable, bien testée et facilement réversible peut obtenir beaucoup d'autonomie. Une migration critique avec peu de tests, une forte dépendance métier et un rollback coûteux en obtient beaucoup moins.
C'est pourquoi l'arrivée de l'agentique peut paradoxalement rendre la discipline engineering plus importante, pas moins.
ISG observe en Europe une extension de l'usage de GenAI depuis la génération de code et l'assurance qualité vers des cycles de développement et de maintenance plus complets, dans des modèles de delivery hybrides où humains et systèmes IA travaillent ensemble, avec des enjeux de transparence et de contrôle.
Le Cigref, dans son guide sur les impacts contractuels des projets d'IA, recommande lui aussi de documenter tests, performances, écarts et mesures correctives et d'adapter la recette aux particularités des systèmes d'IA.
Plus l'ESN promet de l'autonomie, plus elle doit être capable de démontrer les conditions dans lesquelles cette autonomie est sûre.
La review est probablement le prochain problème de capacité
Il existe une idée trompeuse derrière beaucoup de business cases : si un développeur produit deux fois plus vite, l'équipe produit deux fois plus.
Pas nécessairement.
Si les agents génèrent davantage de changements : le nombre de PR augmente, davantage de décisions architecturales arrivent simultanément, les experts les plus rares sont sollicités davantage, le coût de compréhension du code généré peut augmenter, et la merge queue peut devenir le vrai délai de livraison.
Alan fournit un signal intéressant : dans son programme ouvrant la contribution à des non-ingénieurs, la review est explicitement considérée comme le goulot et la décision de merger demeure côté engineering. Le cas documente plus de 350 PR mergées par des non-ingénieurs, mais pas encore un ROI dur permettant de conclure à une performance globale.
Avant d'acheter davantage de capacité de génération, un directeur de delivery devrait mesurer sa capacité de validation.
Dans certaines équipes, le prochain investissement rentable ne sera peut-être pas un agent supplémentaire. Ce sera davantage de tests, une meilleure architecture, un spécialiste sécurité ou du temps de review senior.
Le déploiement doit devenir proportionnel au risque
L'automatisation complète n'est pas un objectif en soi. Elle est rationnelle lorsque l'action est bien comprise, faiblement risquée et facilement réversible.
Le centre de services peut donc organiser plusieurs niveaux : automatique pour des opérations standard parfaitement couvertes ; automatique avec surveillance lorsque le rollback est simple ; validation humaine obligatoire lorsque les impacts sont importants ; double validation ou traitement exclusivement humain lorsque les opérations sont critiques.
Cette gradation évite deux erreurs symétriques : imposer une validation humaine inutile à chaque micro-action, ce qui détruit l'intérêt de l'agentique ; ou rechercher une autonomie maximale alors que le système n'est pas suffisamment observable pour l'assumer.
L'observabilité ne doit plus surveiller seulement l'application
Il ne suffit plus de savoir que l'application est tombée à 14 h 03.
Il faut pouvoir reconstruire quel agent a agi, avec quel modèle et quelle version, à partir de quel contexte, quels outils il a appelés, quels tests ont réussi, quelle review a été effectuée, quel humain a autorisé l'action, combien le traitement a coûté et quel rework a ensuite été nécessaire.
Cette traçabilité n'est pas uniquement un sujet de conformité. C'est ce qui permet de faire progresser industriellement le système.
Sans elle, les équipes ne savent pas si un incident provient du modèle, d'une mauvaise donnée de contexte, d'un connecteur, d'un prompt, d'une règle d'orchestration, d'un test absent ou d'une mauvaise validation humaine. Et sans diagnostic, il n'y a pas d'apprentissage. Seulement de l'automatisation accumulée.
La dette agentique : six dettes qui peuvent se cacher derrière un delivery plus rapide
Une part importante des recommandations sur la maîtrise de la « dette IA » insiste sur la nécessité de combiner industrialisation, gouvernance, actifs réutilisables, observabilité et responsabilité humaine.
Transposé au centre de services, le risque n'est pas uniquement d'ajouter de la dette technique classique. Il est d'en ajouter plusieurs nouvelles.
La dette de contexte apparaît lorsque les agents s'appuient sur des connaissances périmées, fragmentées ou contradictoires.
La dette d'évaluation apparaît lorsque la production augmente plus vite que les jeux de tests et les critères permettant de vérifier sa qualité.
La dette d'orchestration apparaît lorsque chaque équipe accumule ses agents, prompts et automatisations sans propriétaire ni standard commun.
La dette de review apparaît lorsque la file de validation grossit jusqu'à transformer les contrôles humains en approbations superficielles.
La dette fournisseur apparaît lorsqu'un workflow critique devient dépendant d'un seul modèle, d'un prix d'inférence ou d'une API sans solution de repli.
La dette d'observabilité apparaît lorsqu'une organisation possède de nombreux agents en production sans être capable de reconstruire précisément leurs actions.
Le paradoxe est simple : une organisation peut afficher un excellent gain de vélocité tout en accumulant simultanément chacune de ces dettes.
Mesurer le coût complet, pas seulement les heures économisées
C'est probablement le changement de pilotage le plus important pour une ESN.
Le business case classique compare souvent « temps avant IA – temps après IA ». Ce calcul est trop pauvre pour un centre de services. Le bon indicateur est le coût complet d'un changement accepté en production.
Coût humain de cadrage + coût des agents et modèles + licences et plateforme + tests et évaluations + review + déploiement + observabilité + rework + incidents + maintenance des actifs agentiques.
Cette approche explique pourquoi les ESN peuvent simultanément observer des gains de productivité et constater qu'ils restent difficiles à convertir en marge.
Elle évite aussi un piège commercial. Une ESN qui économise trois heures de développement mais ajoute deux heures de review, davantage de calcul, une licence supplémentaire et 45 minutes de rework n'a pas obtenu le gain annoncé par son outil. Elle a déplacé son coût.
Les KPI à suivre
Un centre de services agentique devrait au minimum suivre quatre familles de métriques.
Flux : lead time complet, fréquence de livraison, temps d'attente avant review, âge des blocages.
Qualité : change failure rate, défauts échappés, rollback, taux de rework, first-time-right.
Agentique : taux d'automatisation de bout en bout, taux d'exception, taux d'acceptation sans reprise significative, temps humain de supervision.
Économie : coût complet par changement accepté, coût d'inférence, coût des exceptions, marge après coûts IA, taux de réutilisation des actifs.
Le pourcentage de code généré peut rester intéressant. Mais il devient une métrique secondaire.
Le centre de services agentique ne doit pas devenir une usine centrale qui redevient un goulot
Six modèles d'organisation de l'IA ont été observés dans le corpus sectoriel, et aucun n'est universel. Deux enseignements sont particulièrement utiles ici : le besoin fréquent d'un socle central et la nécessité de conserver de l'autonomie dans les équipes.
Pour une grande ESN, centraliser toutes les compétences agentiques dans une seule équipe créerait rapidement un nouveau centre de tickets. À l'inverse, laisser chaque centre de services fabriquer ses propres agents, ses propres règles et sa propre infrastructure rendrait impossible la maîtrise du risque et des coûts.
Le modèle le plus plausible est donc fédéré.
Le niveau central possède ce qui doit être commun : modèles autorisés, sécurité, registre des agents, observabilité, standards d'évaluations, FinOps, composants de plateforme et gouvernance. Les centres de services possèdent ce qui dépend du client : contexte, règles métier, tests spécifiques, runbooks, seuils d'autonomie et arbitrages opérationnels. Les experts humains gardent l'autorité sur les décisions critiques et les exceptions.
Cette architecture reste une déduction organisationnelle, pas un standard sectoriel démontré : des entreprises réussissent avec davantage de centralisation, d'autres avec une diffusion plus distribuée.
Ce que l'on ne peut pas encore affirmer
- •Qu'un centre de services agentique nécessite mécaniquement moins de personnes. Les cas observés ne démontrent pas une baisse généralisée des effectifs ; plusieurs entreprises continuent de recruter.
- •Qu'un taux élevé de code généré entraîne mécaniquement un meilleur delivery. Les résultats de DORA et METR montrent au contraire l'importance du contexte organisationnel et la diversité des effets.
- •Que le legacy sera prochainement développé ou maintenu sans humains. ISG documente la progression de l'IA dans le cycle ADM européen, mais décrit des formes hybrides et souligne que les entreprises utilisent notamment la GenAI pour moderniser de manière ciblée des systèmes legacy à forte valeur plutôt que pour les remplacer intégralement.
- •Que la supervision humaine est une phase transitoire appelée à disparaître. Dans les environnements critiques, les recommandations de sécurité françaises vont dans le sens inverse : davantage de maîtrise des privilèges et de contrôle des interactions sensibles.
La promesse crédible n'est donc pas le « centre de services autonome ». C'est le centre de services capable de distribuer intelligemment le travail et l'autorité entre humains et agents.
Auto-diagnostic : votre centre de services est-il prêt à devenir agentique ?
Contexte
- •Avons-nous une source de vérité identifiable pour le code, les règles métier, les incidents et les décisions d'architecture ?
- •Savons-nous détecter qu'une information fournie à un agent est périmée ?
- •Les permissions d'accès au contexte sont-elles définies par client, environnement et niveau de sensibilité ?
Agents et autonomie
- •Chaque agent en production possède-t-il un propriétaire identifiable ?
- •Avons-nous défini ce qu'il peut faire seul, ce qui nécessite une validation et ce qui lui est interdit ?
- •Pouvons-nous remplacer un modèle ou désactiver un agent sans reconstruire tout le workflow ?
Tests et évaluations
- •Les critères d'acceptation sont-ils écrits avant que l'agent produise ?
- •Les cas critiques et les non-régressions sont-ils testables automatiquement ?
- •Mesurons-nous les faux positifs, faux négatifs et reprises humaines ?
Review
- •Mesurons-nous le temps d'attente avant review ?
- •La capacité de review augmente-t-elle au même rythme que la capacité de génération ?
- •Les reviewers disposent-ils du temps et du contexte nécessaires pour réellement comprendre les changements proposés ?
Déploiement et risque
- •Chaque opération agentique possède-t-elle un niveau de risque et de réversibilité ?
- •Les actions critiques nécessitent-elles l'autorité humaine appropriée ?
- •Avons-nous un rollback testé et suffisamment rapide ?
Observabilité
- •Pouvons-nous reconstruire la chaîne complète ayant conduit à un changement en production ?
- •Connaissons-nous le modèle, le contexte, les outils, les tests et les validations utilisés ?
- •Pouvons-nous relier un incident à une action agentique précise ?
Économie
- •Connaissons-nous le coût complet d'un changement avant et après agentification ?
- •Les coûts de modèles, licences, review, rework et incidents sont-ils intégrés dans notre marge ?
- •Mesurons-nous la réutilisation et le coût de maintenance de nos actifs agentiques ?
Organisation
- •Le niveau central fournit-il des standards sans devenir le nouveau goulot ?
- •Les équipes delivery conservent-elles suffisamment d'autorité sur le contexte et les décisions client ?
- •Les managers savent-ils superviser simultanément le débit, la qualité, les exceptions et l'apprentissage des équipes ?
Si l'essentiel des réponses concerne encore le choix des outils plutôt que ces questions, le centre de services est probablement équipé pour l'IA, mais pas encore organisé pour un delivery agentique.
La conviction
Le centre de services agentique change l'économie du delivery parce qu'il rend la production plus abondante.
Mais l'abondance de production ne rend pas la qualité abondante.
Lorsque les agents codent plus vite, les actifs les plus rares deviennent le contexte fiable, les évaluations, la capacité de review, le jugement sur les exceptions et la responsabilité de mise en production.
C'est pourquoi la transformation industrielle ne devrait pas commencer par la question « combien de développeurs pouvons-nous augmenter avec des agents ? », mais par : « quelle chaîne sommes-nous capables de rendre plus autonome sans perdre notre capacité à comprendre, contrôler et assumer ce qu'elle produit ? »
La prochaine différence entre deux centres de services ne se fera pas seulement sur la qualité de leurs agents. Elle se fera sur la qualité du système de contrôle construit autour d'eux.
Envie d'en discuter avec Dryve ?
Ces prises de position nourrissent notre approche du recrutement IT à l'ère de l'IA. Parlons de votre contexte.