IA agentique : 'build vs buy' dans les secteurs réglementés

L'importance d'une plateforme intégrée pour l'IA agentique

Dans les secteurs où la régulation est stricte, l'implémentation de l'IA agentique doit se faire via une plateforme intégrée. Cette approche permet de limiter les coûts, de réduire les risques et d'éviter la fragmentation des outils. Les entreprises de ces secteurs sont souvent confrontées à un dilemme : construire leurs propres solutions ou adopter des plateformes existantes. Ce choix est crucial pour la gestion efficace des technologies émergentes.

Les organisations réglementées ont souvent vu l'émergence de nouvelles capacités technologiques. Cela conduit à la création de solutions ponctuelles, chacune conçue pour résoudre un problème spécifique. Cependant, cette approche entraîne rapidement une prolifération d'outils disparates qui ne fonctionnent pas ensemble de manière harmonieuse. Les équipes passent alors plus de temps à intégrer ces outils qu'à produire des résultats concrets. Ce phénomène a été observé avec les chaînes d'outils DevOps et se répète actuellement avec l'IA agentique.

Les défis des plateformes construites en interne

Lorsque les outils de codage assistés par l'IA ont commencé à montrer des gains de productivité significatifs, de nombreuses organisations ont cherché à aller plus loin. Elles ont commencé à assembler divers éléments : un assistant de code ici, une passerelle IA interne là, des modèles open source, et une orchestration sur mesure. Rapidement, elles se retrouvent à parler de la création d'une plateforme complète.

Ce réflexe de construction est naturel pour les équipes techniques. Il leur permet d'apprendre, de développer leurs compétences et de résoudre des problèmes inédits. Cependant, dans les secteurs réglementés, il est crucial que l'adoption de l'IA soit évolutive, gouvernable et cohérente à l'échelle de l'entreprise. Avant de se lancer, il est essentiel de bien comprendre les enjeux.

Construire une plateforme signifie assembler des frameworks agentiques, des couches d'orchestration, une gouvernance personnalisée, et l'infrastructure nécessaire, 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. En revanche, acheter une plateforme existante signifie adopter une solution qui intègre déjà modèles, outils, orchestration et gouvernance sur l'ensemble du cycle de développement logiciel. Dans un environnement réglementé, cette distinction est cruciale.

L'orchestration : le cœur de la complexité

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

La fragmentation actuelle s'installe à ce niveau. Chaque équipe adopte ses propres frameworks et outils de code, faisant des choix rationnels à son niveau. Cependant, ces choix s'accumulent, créant de nouveaux points d'intégration, des failles potentielles de gouvernance et des silos que l'organisation doit gérer.

Construire une plateforme interne d'IA agentique dans des secteurs comme la banque ou l'assurance nécessite un engagement pluriannuel en ingénierie d'orchestration. Cela implique de gérer les frameworks agentiques, de surveiller les dérives de comportement et de gérer l'obsolescence. Ces responsabilités sont continues et ne peuvent être mises en pause.

La sécurité est également un enjeu majeur. Les agents qui accèdent au code et à l'infrastructure doivent respecter des exigences de sécurité bien supérieures à celles d'une intégration SaaS classique. Cela inclut des protections contre les injections de prompt, le sandboxing, l'intégration avec les outils SIEM et DLP, et des tests de type red team.

Dans des frameworks comme DORA et la législation européenne sur l'intelligence artificielle, un système d'IA interne est considéré comme un système réglementé. L'organisation doit alors définir la classification du risque, maintenir la documentation et produire les preuves nécessaires à l'audit tout au long de la vie du système. Chaque agent intégré au SDLC crée également un mini-produit que les équipes doivent maintenir malgré les évolutions des outils, des frameworks et de l'organisation.

Un coût souvent négligé dans les premières analyses est que les ingénieurs mobilisés pour construire la plateforme ne sont plus disponibles pour moderniser une chaîne existante, réduire la dette de sécurité ou accélérer un programme de livraison critique.

Les leçons de l'ère DevOps

L'ère du DevOps offre un parallèle intéressant. Les équipes n'ont pas cherché à créer volontairement des chaînes d'outils fragmentées. Elles ont 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 avait du sens pris isolément. Mais mis bout à bout, ces décisions ont conduit à 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, car ces nombreux outils coûtaient cher et étaient difficiles à auditer. L'IA agentique suit une trajectoire similaire. Les organisations qui choisissent dès maintenant une véritable plateforme, plutôt qu'une succession de choix ponctuels, gagneront des années de rattrapage en quelques mois.

Trois questions pour orienter les décisions

Plutôt que de se concentrer sur un débat générique "build vs. buy", il est utile de se poser 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. Cependant, 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 illustrent 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.

Les avantages d'une plateforme intégrée

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.