Le Crédit Agricole se construit une plateforme souveraine d’IA hybride

Une architecture IA modulaire et intégrée

Pour CAGIP, ce portefeuille d’utilisateurs lui impose une stratégie d’équilibriste, compare Julien Legrand, Product Manager Data & IA. En effet, l’entreprise doit jongler en permanence entre la « mutualisation pour pouvoir réduire les coûts et la démutualisation pour permettre des passages à l’échelle. »

C’est dans ce contexte que CAGIP s’est attelé à la conception progressive de son écosystème IA, composant par composant, et plateforme par plateforme en privilégiant une stratégie modulaire. Pour s’éviter les inconvénients d’une solution d’IA monolithique, CAGIP a fait un choix d’architecture qui repose sur l’assemblage de plateformes spécialisées, complémentaires et intégrées.

La première pierre de cet édifice est la plateforme MLOps, avec la solution Dataiku en son centre. L’offre comprend un portefeuille complet. Parmi les services IT proposés, un accompagnement par « une squad de six personnes qui va venir travailler avec les équipes métiers pour s’assurer que les projets avancent et aboutissent. »

S’y ajoutent des garanties sur « la disponibilité, la sécurité et le bon fonctionnement des services ». Pour CAGIP, cet encadrement à la fois humain et opérationnel est essentiel pour garantir le succès technique des projets, mais aussi leur adoption et leur pérennité.

Une plateforme « Flexible Lakehouse » pour l’accès aux données

Pour alimenter ses modèles ML – et d’autres usages –, encore faut-il fournir un accès fluide et sécurisé aux données. C’est le rôle de la plateforme « Flexible Lakehouse ». Son objectif est de faciliter le partage de données à grande échelle en s’appuyant sur un standard universel comme SQL, tout en offrant des capacités de stockage et de traitement de très gros volumes.

L’enjeu principal, au-delà de la puissance, est de packager cet écosystème complexe « pour que ce soit le plus simple à utiliser possible », et masquer la complexité technique pour les utilisateurs finaux, explique Julien Legrand.

Une problématique réseau à ne pas négliger

Dataiku est interconnecté à ce « Flexible Lakehouse ». Pour un fonctionnement optimal, la performance du réseau est impérative. Un sous-dimensionnement introduirait une latence qui dégraderait les traitements de données.

CAGIP doit donc assurer une intégration à faible latence et à haute performance entre ses plateformes. Grâce à ces briques, le GIP maintient une infrastructure on-promis, mais de plus en plus hybride.

Face au débat « cloud vs on-premise », CAGIP revendique le pragmatisme. Pour l’entité, il ne s’agit pas d’une opposition, mais d’une complémentarité rendue indispensable par les besoins métiers, par le cycle de vie des projets et par les contraintes réglementaires du secteur bancaire.

« Ces deux environnements ne s’opposent pas », insiste Maxime Dupas, Squad Lead Data MLOps et GenAI de CAGIP. La finalité n’est pas de chercher à remplacer le cloud public, mais de « proposer dans certains cas une solution on-premise et dans d’autres cas une solution cloud. »

La flexibilité qui en découle permet de répondre au cas par cas aux problématiques des utilisateurs – qu’il s’agisse d’une expérimentation rapide ou de l’industrialisation d’un processus critique.

On-premise et cloud, complémentaires et transparents

Les métiers militent également en faveur de l’hybridation. Ils se sont d’abord tournés vers le cloud pour sa « disponibilité rapide » et sa « simplicité de déploiement », notamment pour les premiers projets d’IA générative. Mais un choix d’environnement n’est toutefois pas irréversible. L’étape du passage à l’échelle est souvent synonyme de nouvelles contraintes (réglementaires, de coût, de souveraineté) et donc d’un retour au on-prem. C’est à ce moment que CAGIP intervient.

« Nous reprenons les projets. Pour les métiers, nous restons sur la même plateforme. Le changement s’opère au niveau des infrastructures sous-jacentes. » Cette approche conserve l’environnement de travail de l’utilisateur tout en changeant le socle d’exécution, garantissant ainsi rapidité et scalabilité, note Maxime Dupas.

L’objectif cible de CAGIP est de répliquer les avantages du cloud sur son infrastructure privée. Cela se traduit par exemple par la volonté de proposer des plateformes où les utilisateurs « ne payent que ce qu’ils consomment réellement. »

Un stack technique on-premise pour l’IA générative

Pour fournir des services d’IA générative souverains, CAGIP a repris la même approche et a bâti une stack technique complète, structurée en plusieurs couches interdépendantes. De l’infrastructure matérielle jusqu’à l’application finale, l’objectif est de disposer d’un service maîtrisé de bout en bout.

Couche 1 : l’infrastructure et l’orchestration des GPU

La base de l’édifice repose sur la « conteneurisation sur OpenShift. » Au-dessus de cette couche, l’orchestrateur permet de distribuer les GPU. Le composant gère la priorisation des tâches, l’allocation dynamique des ressources en fonction des pics d’activité et la gestion de quotas par entité.

Couche 2 : le « LLM as a Service »

Cette deuxième couche transforme l’infrastructure brute en services directement consommables par les équipes projet. C’est ici qu’est née l’offre « LLM as a service », dont la vocation est « d’exposer des modèles qui sont inférés et/ou entraînés en on-prem. »

Cet écosystème de services est complété par des briques essentielles, comme le stockage objet avec MinIO et les bases de données vectorielles, des composants clés pour les applications de RAG (Retrieval-Augmented Generation), avec PostgreSQL et l’extension PG Vector.

En parallèle, CAGIP reste en veille active et mène des tests avec d’autres plateformes, dont Mistral AI et Prisme.ai, une solution française pour challenger et enrichir sa stack.

La couche applicative et le « Chat Sécurisé »

La couche supérieure est la plus visible pour l’utilisateur final. Elle se matérialise par la mise en place d’un « chat GPT sécurisé en interne de Crédit Agricole ».

L’ambition pour cet applicatif est d’offrir une flexibilité totale de déploiement, que ce soit dans le cloud, ou en on-prem, afin de répondre aux différents enjeux de sécurité et de localisation des données de chaque entité du groupe.

Le « GPU as a Service » pour transformer une contrainte en service mutualisé

L’offre « GPU as a Service » est l’illustration la plus emblématique de la démarche de CAGIP : transformer un cauchemar (logistique) interne en un service mutualisé et créateur de valeur. C’est l’histoire d’une contrainte technique majeure qui s’est transformée en opportunité stratégique.

Des problématiques multiples et critiques ont conduit à la création de l’offre, à commencer par les délais d’approvisionnement rédhibitoires en GPU. Après sa commande, CAGIP aura dû patienter un an et demi pour les réceptionner. Pire, lors d’une livraison, les fournisseurs « avaient oublié de mettre les câbles d’alimentation », retardant encore la mise en service. « Double effet Kiss Cool » : des GPU coûteux, mais qui restaient inutilisés tout en consommant de l’énergie. Un paradoxe difficile à accepter, puisque dans le même temps, d’autres métiers exprimaient un besoin urgent pour ces mêmes ressources.

Face à ce constat, CAGIP a mis en place un « cluster mutualisé » de GPU, régi par des notions de « priorité par entité, de distribution, de quota et d’over quota. »

Le GIP a identifié plusieurs bénéfices à une telle mutualisation :

• Une approche « RSE by design », en commandant des quantités raisonnées et en optimisant l’usage de chaque carte.

• Une « réduction des coûts » grâce à des commandes groupées et une capacité de négociation accrue.

• Une offre « facturée à l’heure de consommation de GPU », reproduisant le modèle économique des fournisseurs de cloud public.

• La réutilisation des « data centers existants qui n’étaient pas adaptés initialement à des GPU », grâce à des techniques de refroidissement innovantes.

• Le développement d’une expertise interne précieuse pour conseiller les métiers sur le juste dimensionnement de leurs besoins en calcul.

Mais cette approche mutualisée comporte aussi des défis, justifiant une vigilance constante, notamment au niveau réseau. L’usage intensif des GPU génère un trafic considérable, ce qui a obligé les équipes à « brider au niveau réseau la bande passante pour éviter de faire tomber l’ensemble des offres. »

La confidentialité est une autre problématique. Certaines entités exigent une « isolation physique » de leurs environnements. Une contrainte supplémentaire à intégrer dans l’architecture du cluster.

Enfin, la dépendance fournisseur. Le marché reste dominé par Nvidia. Or Nvidia priorise ses acheminements ; les licornes de l’IA et hyperscalers sont généralement servis les premiers.

Consolidation et enrichissement des offres IA en 2026 / 2027

CAGIP n’en a pas encore terminé avec l’IA. Sa vision pour 2026 est de rendre l’hybridation totalement transparente. L’objectif est qu’un data scientist, depuis son environnement Dataiku on-prem, puisse « consommer du GPU dans le cloud public le temps d’une expérimentation. »

Cette capacité de « cloud bursting » répond à un double enjeu : satisfaire rapidement un besoin ponctuel sans attendre un approvisionnement on-premise, tout en permettant de « dimensionner un besoin en termes d’infra » en vue d’une future industrialisation.

L’ambition finale pour 2027 est de parvenir à « avoir de l’IA intégrée à tous les niveaux, quelle que soit la typologie de besoin », trace Julien Legrand. « Le but, c’est que toutes les ressources puissent être accessibles par le maximum de personnes le plus simplement possible. »