Le coût caché du "build vs buy" pour l'IA agentique dans les secteurs réglementés

Dans les secteurs réglementés, l'IA agentique doit être gouvernée via une plateforme intégrée plutôt que construite en interne, afin de limiter les coûts, les risques et la fragmentation.

Les secteurs réglementés connaissent bien ce scénario : une nouvelle capacité apparaît. Les équipes lancent alors des solutions ponctuelles, chacune pensée pour résoudre un problème précis. Très vite, l’organisation se retrouve à gérer quinze outils qui n’ont jamais été conçus pour fonctionner ensemble, et les équipes consacrent plus de temps à les intégrer qu’à produire des résultats utiles. C’est ce qui s’est passé avec les chaînes d’outils DevOps, et c’est exactement ce qui commence à se produire avec l’IA agentique.

Le coût progressif des plateformes construites en interne

Lorsque les outils de codage assistés par l’IA ont commencé à générer de vrais gains de productivité, beaucoup d’organisations ont eu le même réflexe : aller plus loin. Un assistant de code ici, une passerelle IA interne là, quelques modèles open source, un peu d’orchestration sur mesure, et soudain l’équipe parle d’une plateforme.

Il y a une raison à cela. Les équipes techniques ont naturellement tendance à construire, et ce réflexe n’est pas mauvais. C’est en construisant que les ingénieurs apprennent, que les équipes développent leurs compétences, et que les problèmes réellement nouveaux trouvent des réponses. La même énergie "do it yourself" qui a marqué les débuts du DevOps a permis de créer des outils et des pratiques remarquables.

Mais les organisations réglementées ont besoin d’une adoption de l’IA qui soit évolutive, gouvernable et cohérente à l’échelle de l’entreprise. Avant d’aller plus loin, il faut donc bien distinguer ce qui est en jeu.

Construire (build), c’est assembler des frameworks agentiques, des couches d’orchestration, une gouvernance personnalisée et l’infrastructure nécessaire pour faire fonctionner l’ensemble, y compris le calcul, le stockage, les bases de données et le réseau. L’organisation devient alors l’éditeur de sa propre plateforme.
Acheter (buy), c’est adopter une plateforme qui unifie déjà les modèles, les outils, l’orchestration et la gouvernance sur l’ensemble du cycle de développement logiciel. L’organisation devient alors utilisatrice de la plateforme.

Dans un environnement réglementé, cette distinction est capitale.

La véritable complexité se trouve dans la couche d’orchestration

Ce qui distingue l’IA agentique des générations précédentes d’outils, ce n’est pas le modèle lui-même, mais l’orchestration qui l’entoure. La pièce maîtresse de tout système IA moderne est désormais le framework agentique : la logique qui détermine quels outils appeler, dans quel ordre, avec quels garde-fous et avec quelle traçabilité.

C’est là que la fragmentation actuelle s’installe. Les équipes adoptent leurs propres frameworks agentiques et leurs propres outils de code, chacune faisant des choix rationnels à son niveau. Mais ces choix s’accumulent. Chaque framework adopté séparément crée un nouveau point d’intégration, une nouvelle faille potentielle de gouvernance et un nouveau silo que l’organisation devra absorber ou contourner.

Construire une plateforme interne d’IA agentique dans le secteur des banques ou des assurances suppose un engagement pluriannuel en ingénierie d’orchestration, avec un périmètre réglementaire que la plupart des organisations sous-estiment. Il faut d’abord gérer les frameworks agentiques : sélection, intégration, surveillance des dérives de comportement et gestion de l’obsolescence. Ce sont des responsabilités continues, sans véritable bouton d’arrêt. Vient ensuite le renforcement de la sécurité. Des agents qui accèdent au code et à l’infrastructure doivent répondre à des exigences bien supérieures à celles d’une intégration SaaS classique : protections contre les injections de prompt, sandboxing, intégration avec les outils SIEM et DLP, tests de type red team, etc.

Dans des frameworks comme DORA et la loi européenne sur l'intelligence artificielle, un système d’IA interne fonctionne comme un système réglementé. L’organisation définit alors elle-même la classification du risque, maintient la documentation et produit les éléments de preuve nécessaires à l’audit pendant toute la durée de vie du système. Chaque agent intégré au SDLC crée aussi, à sa manière, un mini-produit que les équipes doivent maintenir malgré les changements d’outils, de frameworks et d’organisation.

À cela s’ajoute un coût rarement pris en compte dans les premières analyses : tous les ingénieurs mobilisés sur la construction de la plateforme ne sont plus nécessairement disponibles pour moderniser une chaîne existante, réduire la dette de sécurité ou accélérer un programme de livraison critique.

Ce que l’ère du DevOps nous a appris

L’ère du DevOps offre un point de repère utile. Les équipes n’ont pas cherché à créer volontairement des chaînes d’outils fragmentées ; elles ont simplement pris des décisions progressives et rationnelles : un meilleur outil CI ici, un SCM privilégié là, un scanner de sécurité ajouté en complément, un gestionnaire de secrets séparé, un autre orchestrateur de déploiement.

Chaque choix faisait sens pris isolément. Mais, mis bout à bout, ces décisions ont créé une multiplication d’outils difficile à maîtriser : intégrations lourdes, gouvernance incohérente, doublons d’efforts et absence de vision unifiée sur le SDLC.

L’industrie a passé une grande partie de la décennie suivante à se consolider autour de plateformes, précisément parce que ces nombreux outils coûtaient cher et étaient difficiles à auditer.

L’IA agentique suit la même trajectoire. Les organisations qui font dès maintenant un vrai choix de plateforme, plutôt qu’une succession de choix ponctuels, gagneront des années de rattrapage en quelques mois.

Trois questions pour guider les décisions

Plutôt que d’aborder le sujet à travers un débat générique "build vs. buy", il convient de s'appuyer sur trois questions fondamentales :

Le besoin est-il réellement unique ? Construire se justifie lorsque l’organisation a des workflows qu’aucun éditeur ne prend en charge, des modes de déploiement qu’aucune plateforme ne peut satisfaire, et une vraie volonté d’investir dans l’ingénierie de plateforme comme capacité durable. Cela dit, les plateformes modernes prennent de plus en plus en charge les environnements réglementés grâce à des déploiements cloud, auto-hébergés ou monolocataires dédiés. Pour des objectifs comme accélérer les revues de code, migrer des pipelines, traiter les alertes de sécurité ou automatiser les tests, les plateformes existantes apportent déjà des résultats chez des organisations comparables.
Quelle charge réglementaire l’organisation peut-elle réellement assumer ? Construire revient à devenir propriétaire du système au sens des frameworks de risque ICT, fournisseur d’IA au sens des réglementations émergentes, et responsable du comportement des modèles, de la documentation et du suivi. Acheter n’efface pas la responsabilité réglementaire, mais déplace les obligations liées à la plateforme vers un fournisseur spécialisé et permet aux équipes conformité de se concentrer sur les usages de l’IA plutôt que sur l’infrastructure.
Quel est le calendrier ? Si le board attend des résultats visibles au sein des équipes d’ici 12 à 24 mois, un chantier interne qui s’étale sur plusieurs années est en décalage dès le départ avec cette attente.

Les chiffres montrent bien cet écart. Pour une organisation réglementée d’environ 200 développeurs, construire une plateforme interne sur une base d’IA cloud coûte généralement autour de 1,2 million d’euros la première année, en incluant les efforts d’ingénierie, l’infrastructure, l’intégration, la sécurité et la conformité. Il faut compter 6 à 12 mois avant d’avoir un projet réellement prêt pour la production, et 2 à 3 personnes à temps plein dédiées pour en maintenir la stabilité. En pratique, le premier vrai cas d’usage arrive au bout de 12 à 18 mois, au minimum.

À l’inverse, une plateforme d’IA agentique conçue pour cet usage revient à environ 380 000 à 425 000 euros pour le même nombre de développeurs, avec un déploiement initial en quelques jours et des gains de productivité précoces de 15 à 25 % une fois les agents intégrés dans les workflows quotidiens. Le premier cas d’usage arrive alors en quelques semaines, et non au bout de quelques années.

Cet écart représente la différence entre livrer un retour sur investissement de l’IA au cours de l’exercice fiscal de la même année et expliquer au board pourquoi l’organisation est encore en train de développer l’infrastructure.

Ce qu’une plateforme intégrée apporte réellement

Une bonne plateforme résout quatre problèmes que les approches construites en interne gèrent mal de façon récurrente.

L’agnosticisme vis-à-vis des modèles et des outils : l’écosystème de l’IA agentique évolue trop vite pour parier sur un seul modèle ou un seul framework. Une plateforme capable de prendre en charge n’importe quel modèle backend et de s’intégrer proprement aux outils de codage existants donne aux organisations de la liberté sans perdre en cohérence. La plateforme devient alors la couche de gouvernance, et non un frein à l’adoption.
Des garde-fous fiables autour d’agents non déterministes : les systèmes agentiques sont, par nature, probabilistes. Il est donc possible de les intégrer dans des workflows déterministes qui imposent des revues de code, des scans de sécurité et des contrôles de conformité avant qu’un contenu généré par l’IA n’arrive en production. Les agents accélèrent l’exécution des tâches, tandis que la plateforme assure la responsabilité. Cette logique apparaît déjà dans les services financiers. Barclays utilise par exemple des assistants d’IA pour aider les équipes de développement sur la génération de code, l’explication de code, la génération de tests et la refactorisation, ainsi que sur l’analyse des causes profondes pour résoudre plus vite les jobs en échec. L’enjeu n’est pas seulement d’ajouter de l’IA au développement, mais de l’inscrire dans une plateforme DevSecOps commune, avec les workflows et les contrôles nécessaires à une adoption maîtrisée.
La personnalisation dans un framework gouverné : la plupart des utilisateurs accèdent aux agents via un catalogue partagé et obtiennent immédiatement de la valeur dans un environnement gouverné. Les utilisateurs les plus avancés peuvent adapter les agents à leur contexte en ajustant les prompts système et certains paramètres, sans écrire une ligne de code. Les équipes qui ont de vrais besoins différenciés peuvent créer leurs propres flow d’agents et les publier dans le catalogue, afin de transformer un travail interne en capacité collective.
L’IA au service de toute l’organisation : la productivité des équipes de développement est souvent le point d’entrée, mais rarement le plafond. La plateforme peut aussi servir les chefs de projet, les ingénieurs infrastructure, les testeurs, les équipes de sécurité et de conformité avec des agents adaptés à leurs besoins, tout en restant dans la même couche de gouvernance.

Où placer la personnalisation dans l’architecture ?

La personnalisation est un besoin légitime dans les secteurs réglementés. L’enjeu n’est pas de l’exclure, mais de déterminer où elle est vraiment nécessaire. Une orchestration intelligente assure cohérence et souplesse, sans imposer d’uniformité. Tout le monde évolue dans la même couche de gouvernance, avec un degré de flexibilité adapté aux besoins.

La consolidation observée dans le DevOps s’applique directement ici. Le vrai coût ne venait pas des outils eux-mêmes, mais des décisions techniques accumulées plus vite que les organisations ne pouvaient les gouverner. L’IA agentique mérite la même rigueur.