Revolut fait des modèles auto-hébergés sa solution par défaut pour le développement assisté par IA, sans renoncer aux services commerciaux.
Lors de la conférence AI Engineer NYC, David Abitbol, son responsable des opérations IA, a présenté cette stratégie et les optimisations nécessaires à sa mise en production.
Selon lui, Revolut sert GLM-5.3 à environ 2 000 ingénieurs sur 56 GPU Nvidia B200, avec un coût moyen agrégé proche de 0,30 dollar par million de tokens. Il indique que la facture représente environ un dixième des dépenses antérieures auprès d’Anthropic et d’OpenAI.
Ce ratio ne constitue toutefois ni un tarif universel de l’auto-hébergement ni une comparaison à charge de travail strictement identique. La présentation ne fournit pas de ventilation permettant de déterminer précisément quels coûts d’infrastructure et d’exploitation entrent dans le calcul, ni de vérifier le coût total de possession.
Claude Code et Codex restent accessibles pour les exceptions.
Productivité : une causalité non démontrée
Les résultats de productivité concernent une étape antérieure. Le passage à GLM-5.1, au printemps 2026, coïncide avec des améliorations annoncées d’environ 60% du temps de codage et de 70% du lead time. Ce dernier mesure le délai entre la prise en charge d’une fonctionnalité et sa fusion dans le code, prête à être déployée mais pas nécessairement son déploiement effectif.
La comparaison interne ne permet pas d’isoler l’effet du changement de modèle. David Abitbol avance notamment qu’un accès moins contraint par les budgets de tokens encourage l’utilisation de l’IA pour les tâches périphériques, comme la recherche d’informations dans les courriels, Jira ou Confluence.
Ces chiffres ne constituent donc pas un benchmark contrôlé de GLM-5.3 face à Claude ou Codex.
Optimiser avant d’ajouter des GPU
Le retour d’expérience porte autant sur le service d’inférence que sur le modèle. A nombre de GPU constant, Revolut rapporte une hausse de 76% des requêtes par seconde et une baisse de 88% du délai avant le premier token, passé de 14,26 à 1,68 seconde. L’objectif opérationnel est de rester sous trois secondes.
Les leviers évoqués comprennent la quantification FP4 sur les GPU Blackwell, le parallélisme tensoriel et la réutilisation du cache. David Abitbol recommande aussi d’examiner le décodage spéculatif et la séparation entre traitement du contexte d’entrée et génération des tokens, sans établir que chaque technique est effectivement déployée chez Revolut.
Concernant le contexte, il estime qu’environ 256 000 tokens répondent aux besoins décrits, plutôt que de réserver systématiquement la capacité maximale d’un million. L’enjeu est de préserver la mémoire disponible pour traiter plusieurs requêtes simultanément.
maUn dispositif multimodèle et supervisé
GLM-5.3 étant textuel, le responsable des opérations IA préconise de router les demandes nécessitant la compréhension d’images vers un autre modèle. Des API compatibles avec celles d’OpenAI permettent parallèlement de connecter les modèles hébergés aux outils de développement utilisés par les ingénieurs.
Sur la sécurité, Revolut met en avant des environnements isolés, des règles d’approbation pour les opérations restreintes et une télémétrie permettant d’enquêter sur les incidents. David Abitbol distingue également l’hébergement des poids sur une infrastructure choisie par l’entreprise du recours au service distant du développeur du modèle.
Les passkeys sont une excellente solution… quand on ne fait pas de Bring Your Own ID ni de fédération d’identités.
Avis tranché pour Fabien Schwebel, RSSI d’Europcar. Il en a fait part aux Assises de la sécurité, tout en présentant l’option alternative retenue par l’entreprise : des clés FIDO2 (Yubico).
Le projet avait démarré en 2021 sur un « reste de budget ». Europcar avait du MFA, mais « à l’ancienne », pour reprendre les mots de Fabien Schwebel. En l’occurrence, du Google Authenticator, « avec des codes qui se transmettaient ». Un déploiement vulnérable au phishing (risque de récupération des tokens de session), en plus de ne pas avoir éliminé les mots de passe.
Il fut décidé de développer ce projet en synergie avec un autre, visant à mettre en œuvre le SSO (Red Hat). Les clés physiques sécuriseraient l’accès à ce portail, qui débloquerait ensuite l’accès aux applications.
Les passkeys dans Chrome, cadeau empoisonné pour Europcar
Europcar a donc écarté les passkeys. En premier lieu parce qu’il s’agissait, a fortiori à l’époque, d’un « standard très fermé, [avec un] vendor lock-in très important », selon Fabien Schwebel. « La clé est dans votre iCloud, dans votre Entra ID, etc. et l’utilisateur ne peut pas changer d’écosystème. » De surcroît, précise-t-il, on viole un principe fondamental de cryptographie, « qui est que la clé ne doit pas se déplacer ». Effectivement, si un utilisateur se connecte sur un nouveau device, sa clé est téléchargée dans le TPM local.
La promotion des passkeys par les éditeurs de logiciels a posé des problèmes à Europcar. Son RSSI pointe en particulier Google, qui a fini par en faire la méthode d’authentification par défaut dans Chrome. Testant les versions bêta du navigateur, l’entreprise l’a vu venir. « On n’est pas passé loin d’un serpent qui se mord la queue et peut-être de centaines de milliers d’appels au service desk. » Et pour cause : Europcar utilise Google Workspace, dont elle a fait sa messagerie principale. Ses employés se seraient retrouvés dans la situation d’enrôler sur leur compte Google une passkey destinée à déverrouiller ce même compte…
Des clés biométriques pour les admins Active Directory
Europcar a aussi écarté l’idée de faire du FIDO2 avec ses téléphones et ses ordinateurs. Motif : le fallback nécessaire pour couvrir les cas où un utilisateur aurait à changer d’appareil représente une vulnérabilité.
L’entreprise est partie sur du Type-C pour simplifier la gestion des stocks. Pour les appareils encore en Type-A, elle a acheté des adaptateurs. Elle n’a pas généralisé les clés biométriques, sensiblement plus chères, mais en a distribué à des populations spécifiques comme les administrateurs de solutions de sécurité ou de Tier 0 Active Directory.
Faire sans mots de passe… et sans identifiants ?
La première cinématique d’authentification implémentée restait sur du login / mot de passe au niveau du SSO. Elle impliquait d’enregistrer la clé sur toutes les applications en aval.
Dans un deuxième temps, le FIDO2 est remonté au sein de l’IdP. La YubiKey étant considérée comme sécurisée, le mot de passe a été retiré – pas pour tous les cas d’usage, néanmoins. Cela a permis d’autoriser le BYOD pour certaines applications (pas d’exposition de mot de passe sur des devices non sécurisés).
Au moment de déployer le projet, il n’y avait pas, d’après Fabien Schwebel, d’authentification forte dans Windows, au sens où l’utilisateur pouvait choisir de se connecter avec son mot de passe. Europcar en est donc resté à une authentification classique sur le poste. C’est une fois la session ouverte que les clés entrent en jeu.
Après le passwordless, la troisième étape est le usernameless. Tirant parti du fait que la clé peut stocker l’identifiant de l’utilisateur, elle est encore « naissante » chez Europcar, mais fait « énormément gagner en buy-in ».
Se calquer à la logistique existante
Europcar a environ 2700 agences. Il compte un peu plus de 9000 employés, hors staff saisonnier et « hikers » (qui déplacent les véhicules, les nettoient, etc.).
Les populations sans accès au SI peuvent utiliser un authentificateur de plate-forme. C’est-à-dire un module intégré dans un appareil – typiquement, leur smartphone. Les autres ont une YubiKey (les VIP en ont deux, celle de secours restant à leur domicile).
Europcar a exploité au maximum sa logistique existante (distribution du matériel informatique, des uniformes, des badges…). Aux tiers offshore qui ont leur propre approvisionnement en hardware, il a imposé d’utiliser de l’authentification FIDO2 cross-platform.
Brander les clés pour réduire leur valeur sur le marché secondaire
Les clés sont livrées vierges. Il y a un processus d’auto-enrôlement (les collaborateurs reçoivent notamment un one-pager avec un QR Code). Il y a des contournements, reconnaît Fabien Schwebel. Mais il y a aussi des mesures dissuasives. Par exemple, l’expiration du mot de passe tous les 30 jours.
Pour parer aux pertes (un taux de « quelques pourcents »), les agences ont des clés en réserve. Excepté dans les plus grandes, le support informatique est à distance. La présence des collègues favorise cependant l’authentification auprès du help desk. Ce qui n’empêche pas Europcar de faire du red teaming, dans plusieurs langues.
Pour diminuer leur valeur sur le marché secondaire, les clés sont brandées. « En imprimé projeté, [donc] si techniquement, on peut gratter, cela [les] endommage… » Europcar pratique en plus la refacturation des équipes locales. Autrement dit, le manager paye ses clés. « Si un employé en perd deux en trois semaines, ça coûte cher sur le P&L de la station… »
Sessions Citrix et profils multiples
Les stations de travail n’étant généralement pas fixes, Europcar s’appuie sur des sessions Citrix flottantes.
Les utilisateurs peuvent se servir de leur YubiKey pour protéger des comptes personnels. L’entreprise ne l’encourage pas, ne serait que parce que la clé doit être restituée à la fin du contrat. Elle exploite toutefois la capacité à stocker plusieurs profils pour permettre aux utilisateurs de se connecter aussi sur des comptes génériques.
Le déploiement des clés physiques a permis de négocier avec les auditeurs un délai d’expiration allongé pour les mots de passe (1 an au lieu de 60 jours).
Europcar garde l’œil sur l’écosystème applicatif, dont Google, qui met suffisamment en avant les passkeys dans Chrome pour que l’utilisateur d’une clé physique ait à « cliquer sur la petite option un peu grisée »…
L’IA mathématicienne montre des progrès notables. Et si elle finissait par casser le chiffrement post-quantique ?
Questionné à ce propos lors des Assises de la cybersécurité, Philippe Coué n’a pas nié l’existence d’un tel risque. Mais cela ne doit pas, affirme-t-il, empêcher le Crédit Agricole de se préparer au fameux Q-Day. Une échéance encore hypothétique à laquelle les ordinateurs quantiques deviendraient suffisamment puissants pour briser les algorithmes de chiffrement asymétriques actuels.
Des échéances à 2030 et 2035
Philippe Coué est group COO cybersecurity & risk IT. « Chargé de tout ce qui est transformation, sensibilisation, innovation sur les sujets et risques IT », comme il se définit lui-même.
Voilà « un an et demi, deux ans » que le Crédit Agricole réfléchit au sujet du chiffrement post-quantique. En tant que banque systémique, il a des échéances à 2030 pour ses assets critiques et à 2035 pour le reste de son parc. Il s’agit pour le moment de recommandations – qu’on trouve notamment dans une feuille de route du G7. Pas encore d’obligations réglementaires. « Mais la BCE commence déjà à nous poser des questions ».
Un premier PoC « crypto-agile » dans les assurances
Le Crédit Agricole a aussi commencé à travailler avec ses partenaires technologiques sur une roadmap, tout en intégrant dans chaque nouveau contrat des clauses d’exigence PQC. Il en est à la phase d’inventaire. Laquelle a démarré par le recensement, à un niveau macro, des principaux usages du chiffrement et des données nécessitant une protection sur plus de 10 ans.
Un PoC avec CryptoNext Security a débuté au premier semestre 2026. Il couvre un périmètre « restreint mais représentatif ». En l’occurrence, une application dans le domaine des assurances, avec « des métiers en France et à l’étranger [et] des technologies différentes ».
« Le but, c’est de profiter du passage au post-quantique pour introduire la notion d’agilité cryptographique », explique Florent Grosmaitre, président de CryptoNext. C’est-à-dire d’aller vers une cryptographie configurable, pilotée de manière centralisée, le choix de l’algorithme se faisant à l’exécution sur la base d’une politique.
Un agent intercepte les appels crypto et récupère l’algorithme depuis le serveur de politiques.
Le Crédit Agricole n’y est pas encore : « Aujourd’hui, passer d’un algorithme à l’autre dans nos infrastructures, c’est une montagne, parce que la cryptographie est codée en dur », résume Philippe Coué.
L’hybridation, un moyen, pas une fin
Pour les applications dont il n’a pas le code, le groupe explore un mécanisme alternatif de surchiffrement TLS. Il consiste à faire passer le flux d’origine dans un tunnel post-quantique géré par proxy.
Si l’hybridation n’est pas la cible, elle a été testée avec la filiale CACEIS, spécialisée dans les services financiers pour les investisseurs institutionnels. Elle pourra consistuer un palliatif « si on n’arrive pas à migrer dans les temps, comme c’est malheureusement souvent le cas »…
Le Crédit Agricole compte structurer un mode programme pour 2027, avec un budget, tout en élargissant le périmètre aux paiements et à la banque d’investissement. Quant à la possibilité que les principales librairies cryptographiques finissent par embarquer directement la crypto-agilité, Philippe Coué adopte la même posture que sur l’IA mathématicienne : « On se doit d’expérimenter. »
Des questions architecturales non résolues en l’état
« Je n’aimerais pas le dire, mais on a un manque d’agilité dans nos mises en place d’environnements de test, admet l’intéressé. On est très industriels. […] On n’a pas encore cet esprit où ces environnements lab nous permettraient de tester à la voler des nouvelles technologiques, des nouveaux use cases ».
La première expérimentation a été « plus technique que métier ». Évoquer l’impact du chiffrement post-quantique sur les performances est donc « un peu prématuré », assure Philippe Coué. Ce qui est certain, c’est que des « questions architecturales » se posent, les options expérimentées présentant un point de défaillance unique…
Transformer un back-end de stockage… pour finalement se rendre compte qu’il est beaucoup moins mis en difficulté par une flotte d’agents que par une flotte d’humains.
C’est arrivé à Sekoia dans le cadre de ses expérimentations sur Elevate, son module de SOC agentique, passé en disponibilité générale fin septembre. L’entreprise en a rendu compte lors des Assises de la sécurité. Elle était accompagnée de son premier testeur : SPIE.
Le groupe européen, fournisseur de services multitechniques dans l’énergie et les communications*, est client de Sekoia depuis février 2024. Il a expérimenté ce « SOC agentique » à partir de juillet 2026.
Sa sécurité opérationnelle s’organise ainsi :
Un MSSP pour le triage de niveau 1 en 24/7
Automatisation du traitement via SOAR aussi bien côté MSSP qu’en interne
Niveaux 2 et 3 gérés en interne (une dizaine de personnes dans le département SecOps groupe + équipes SecOps des filiales)
Sur son périmètre global, SPIE reçoit environ 43 000 alertes par mois. Certaines – typiquement, celles qui font trop de bruit – ne sont pas gérées par le MSSP.
Plus précise, l’IA « gaspille » moins de ressources
Sur la zone France, Sekoia a « entre 12 et 15 Po de données » à disposition de Roy, l’agent d’Elevate. En prévision de la charge que ce dernier générerait, l’entreprise a « complètement transformé » son back-end de stockage, d’après son Georges Bossert. CTPO (Chief Technology and Product Officer).
La pression n’a pas été celle attendue. « Les agents sont beaucoup plus performants que les humains d’un point de vue technologique », pour reprendre les mots de Georges Bossert. Leurs recherches sont « extrêmement précises », sur les timelines nécessaires, avec les bons filtres. « Avec les agents, on a des temps de recherche beaucoup plus courts malgré le volume beaucoup plus élevé. »
Le même impact devrait être constaté sur les technologies tierces. C’est justement le « gros sujet » actuel de Sekoia : donner à Roy l’accès à son catalogue d’intégrations.
SPIE a dû faire sans. Dimitri Farcy, head of SecOps, donne un exemple : les recherches d’IOC étaient limitées à la CTI de Sekoia. Dans un autre registre, il souligne l’absence de traitement en masse via les cases – une fonctionnalité que Sekoia affirme toutefois avoir sur sa roadmap.
96 % de verdicts inchangés… mais beaucoup de « vrais positifs » qui n’en étaient pas
Si c’était à refaire, SPIE fournirait davantage de contexte dès le départ (instructions personnalisées pour décrire l’environnement), ciblerait plus tôt les alertes à score élevé et connecterait le module CAASM Reveal à davantage de sources.
Le groupe se dit néanmoins satisfait des résultats. Il avance deux indicateurs en particulier : 96 % des verdicts inchangés par les analystes**, et des équipes SOC « entre 2 et 5 fois plus rapides ».
Le retour d’expérience présenté aux Assises de la sécurité couvre un peu plus de 35 000 alertes. Son volet principal en englobe environ 10 000, traitées en septembre. Sur la base des 80 règles de détection que SPIE avait fournies, l’intégralité des prédictions de faux positifs se sont révélées justes.
Elevate s’est avéré moins bon sur les vrais positifs : des 411 prédits, seuls 2 en étaient. À ce sujet, Dimitri Farcy met un bémol. Il évoque la présence de « faux positifs bénins », en conséquence desquels on entreprend tout de même des actions. « Typiquement, un bot qui va nous scanner », en conséquence de quoi on bloque une adresse IP. « Sur les 409 [faux positifs], c’est très souvent le cas », assure l’intéressé. Et de rappeler que SPIE avait choisi de ne pas fournir de contexte à Roy, ayant décidé de s’en servir pour améliorer ses règles de détection. Preuve en serait que les verdicts erronés ont culminé en début de mois, après quoi la prise en compte du filtrage sur les règles de détection a « grandement amélioré la véracité ».
Recentrer le niveau 1 sur la couverture
À date, Elevate fournit un verdict, mais ne réalise pas lui-même d’actions. « Le but, c’est qu’on puisse le configurer demain pour le faire, explique Maxime Hugon, solutions architect chez Sekoia. Pour ça, j’ai construit, à la demande de Dimitri, un playbook qui permet, en fonction du verdict et du niveau de confiance associé à une investigation, de faire de l’auto-close d’une alerte ou de réaliser des actions de containment ».
Dans ce contexte, Dimitri Farcy admet que « le niveau 1 est voué en grande partie à disparaître pour se concentrer sur la partie couverture. » « Cela fait partie de l’accompagnement qu’on se doit d’apporter à nos collaborateurs, renchérit Sébastien Louis, RSSI groupe de SPIE. L’objectif n’est pas de déstaffer, mais de faire monter le niveau de valeur ajoutée des tâches confiées aux personnes. L’augmentation de la couverture et [la] boucle vertueuse d’amélioration continue, c’est là-dessus qu’on va se positionner. »
Cette « boucle vertueuse » reposera notamment sur les runbooks « agentiques » qu’Elevate génère automatiquement pour chaque règle. Les analystes peuvent les éditer pour ajouter des requêtes qui affineront le verdict.
Par rapport aux runbooks classiques qui définissent les étapes et leur ordre, ceux d’Elevate :
Décrivent les questions importantes
Définissent les hypothèses à considérer
Indiquent signaux et éléments de contexte
Orientent vers les sources et les outils utiles
Déterminent ce qu’il faut avoir établi pour pouvoir conclure
Dans ce schéma, « l’analyste a un rôle de maintien d’une méthodologie d’investigation », résume Dimitri Farcy. Georges Bossert lui fait écho : « Cet effort d’explication redonne un intérêt à travailler sur la méthodologie d’investigation. »
SPIE prévoit des « discussions avec [son] MSSP » sur le partage de la valeur
« On a développé l’infrastructure à base de nos propres GPU [et] de modèles choisis et constamment réévalués disponibles sur le marché avec des benchmarks », commente le CTPO de Sekoia. Quant à savoir de quels modèles il s’agit, on repassera. L’entreprise préfère mettre en avant tout ce qu’il y a autour. Y compris ce qui est encore sur la feuille de route. Par exemple :
Agents améliorant les règles de détection, les parseurs, les runbooks, la définition des cases, etc.
Mode conversationnel à l’issue de la boucle agentique dans l’optique de guider Roy dans la remédiation
Gestion des tâches (créer, suspendre, reprendre et suivre des tâches d’investigation lorsqu’une réponse dépend d’une action, d’une donnée ou d’un événement futur)
Association d’agents et de playbooks déterministes
Du côté de SPIE, on prévoit « des discussions avec [le MSSP] pour prendre la juste mesure des gains […] et voir comment on arrive à se partager cette valeur additionnelle », détaille Sébastien Louis.
Avant d’annoncer la GA d’Elevate, Sekoia l’a déployé chez 1000 clients. Il annonce un temps moyen d’investigation de 88 secondes, pour 90 % de verdicts non modifiés. « On n’est pas aussi bons que chez SPIE, où il y a eu tout un travail de choix des règles et ainsi de suite, justifie Georges Bossert. Là, ç’a été beaucoup plus ‘je clique sur le bouton, j’active sans configuration’ »…
* SPIE a lui-même la casquette de MSP à travers sa filiale de services informatiques SPIE ICS.
** 11 analystes ont été sollicités. Sekoia a présenté des résultats plus détaillés pour une quinzaine de règles, sur un sous-ensemble d’environ 5000 alertes. La précision pondérée atteint 94,4 %. SPIE a validé 100 % des verdicts dans trois cas : désactivation de service, énumération des partages réseau et modification d’un groupe AD à privilèges.
Pour les 100 ans de son usine de Lons-le-Saunier (Jura), Bel a franchi un cap technologique avec l’annonce d’un « jumeau numérique » de La Vache qui rit.
Le jumeau rassemble dans un même environnement virtuel les ingrédients, la formulation, les propriétés physico-chimiques, la perception sensorielle et les préférences des consommateurs. Les équipes peuvent y simuler des milliers de combinaisons de recettes et ne lancer des essais physiques au pilote que sur les plus prometteuses.
Anne Pitkowski, directrice recherche et application chez Bel, résume l’intérêt de l’outil : prédire le goût et la perception sensorielle d’une recette. Il s’agit par exemple de savoir si elle sera plus ou moins fondante, salée ou crémeuse et si elle conviendra à un palais américain ou vietnamien. La marque compte déjà plus d’une centaine de déclinaisons dans le monde.
Le développement d’un produit alimentaire repose traditionnellement sur une succession d’essais, suivis d’analyses et de dégustations. Bel présente la simulation comme un complément à cette expertise, pas un remplacement. Le groupe vise aussi une amélioration continue du profil nutritionnel et de l’empreinte environnementale de ses produits.
Deux ans de développement
La technologie a été conçue par les équipes recherche, innovation et développement de Bel. Elle doit être déployée à l’échelle industrielle à l’horizon 2028 et le groupe espère sortir à cette date les premières recettes issues de l’outil.
Selon Les Echos, deux ans de développement ont été nécessaires avec un important travail de remontée et de tri des données internes. Le montant investi n’est pas détaillé mais Bel parle d’un investissement « lourd ».
D’autres briques sont déjà en service. Des solutions de microbiologie prédictive et des outils d’aide à la formulation, issus de travaux avec des partenaires externes, sont utilisés dans les nouveaux développements.
Dassault Systèmes, partenaire depuis 2024
Le projet découle de l’accord annoncé en juillet 2024 (signé au quatrième trimestre 2023) entre Bel et Dassault Systèmes.
Cet accord prévoit le déploiement de la solution « Perfect Production », fondée sur la plateforme 3DEXPERIENCE, dans 11 usines du groupe. Il s’appuie sur des briques de gestion des opérations de fabrication (MOM) et de gestion du cycle de vie produit (PLM), sur les sciences de l’alimentation et des matériaux, et sur l’IA.
Les technologies de jumeaux numériques de Dassault sont déjà employées dans l’aéronautique, l’automobile et les sciences de la vie.
La numérisation de l’usine (jumeau, capteurs, analyseurs) reste en phase d’expérimentation. Elle vise notamment à réduire les pertes et à gérer la variabilité du lait, une matière première vivante. Le groupe répète qu’il ne s’agit pas de remplacer l’humain.
Antoine Fiévet, président de Bel, reconnaît le risque auprès des Echos. Le groupe investit chaque année des dizaines de millions d’euros dans cette démarche data et tech, « avec des retours qui restent à démontrer ». Avec 3,8 milliards d’euros de chiffre d’affaires, Bel pèse moins que Lactalis ou Danone. « Nous sommes trop petits pour ne pas innover », justifie-t-il.
BNP Paribas s’offre un accès élargi à l’écosystème IA de Google Cloud, avec en tête d’affiche Gemini Enterprise et les modèles Gemini. Un accord signé pour cinq ans doit accompagner la banque dans sa montée en puissance sur l’IA agentique.
CIB en première ligne
C’est Corporate & Institutional Banking (CIB), la division dédiée aux grandes entreprises, qui ouvre le bal. Les modèles Gemini vont venir muscler LLM@CIB, l’assistant IA maison déjà utilisé par plus de 65 000 collaborateurs.
Côté agents à proprement parler, le premier chantier concerne la préparation des dossiers d’analyse crédit, où l’IA viendra épauler les équipes plutôt que les remplacer, du moins pour l’instant. La banque lorgne aussi sur d’autres terrains : vente, trading, recherche, structuration.
Et il y a déjà un cas d’usage qui tourne ailleurs dans le groupe. Chez Nickel, la filiale de paiement de proximité, un outil baptisé Nickel Assist s’appuie sur un modèle Gemini pour aider environ 200 conseillers clientèle à répondre plus vite aux clients, en s’appuyant sur les procédures internes.
Une stratégie multi-cloud réaffirmée
L’accord ne signifie pas un virage à 100 % vers Google Cloud. BNP Paribas joue depuis longtemps la carte du multi-cloud et du multi-modèle. Il s’ajoute aux aux autres fournisseurs, notamment avec IBM Cloud (un contrat renouvelé pour dix ans en 2025) et Oracle, autour d’Exadata Cloud Customer hébergé dans les data centers du groupe.
Marc Camus, DSI du groupe, rappelle que banque préfère garder la main pour choisir projet par projet le modèle et l’infrastructure qui collent le mieux à ses besoins de sécurité, de qualité et de budget. L’arrivée de Google Cloud dans l’équation, dit-il, élargit juste le men
Comme toujours, l’adoption de l’IA s’accompagne d’un discours très appuyé sur le contrôle. BNP Paribas inscrit le nouveau contrat dans le cadre de ses règles internes de sécurité et de gouvernance des données. Chaque agent devra être identifié individuellement avec un accès limité aux seules ressources dont il a besoin pour sa tâche.
BNP Paribas prévoit aussi de s’appuyer sur cette collaboration pour muscler son programme de formation interne à l’IA, à la fois sur les bases pour le plus grand nombre et sur des compétences plus pointues, comme la conception d’agents spécialisés.
Un modèle moins cher au token ne l’est pas forcément à la requête.
BCPE a pu le vérifier sur la modération de l’assistance client… grâce à son benchmark interne.
Mikaël Le Bars (photo) dirige l’équipe expertises transverses IA au sein du centre d’expertise data science du groupe. Au salon Big Data & AI Paris 2026, il est revenu sur le développement de ce benchmark.
À la racine, il y avait la volonté ne pas « payer l’évaluation à chaque projet […] sans rien posséder à la fin ». Il y avait aussi les limites des benchmarks publics.
Certaines de ces limites se manifestent dans la qualité des tests. Il arrive notamment que des données de référence soient fausses. Illustration dans FrontierMath. Lorsqu’il en a publié la v2 en juin, Epoch AI a reconnu que 42 % des problèmes de la v1 contenaient des erreurs.
En parallèle, nombreux sont les benchmarks arrivant à saturation : ils deviennent trop « simples » pour les principaux modèles, qui y atteignent les scores maximaux. Dans son dernier AI Index, Stanford estime que le phénomène touche près de la moitié des 60 benchmarks les plus populaires.
Les modèles ont aussi une tendance au surapprentissage : ils « collent » à certains benchmarks, si bien qu’une modification, même mineure, peut suffire à faire chuter les performances. Des chercheurs d’Apple en ont donné des illustrations sur un dérivé de GSM8K.
Se pose également le problème de la gouvernance des classements. Les fournisseurs de modèles peuvent tester plusieurs versions avant d’en publier une… qui n’est pas forcément celle proposée aux clients. On en a par ailleurs vu certains financer des benchmarks (OpenAI avec FrontierMath, par exemple). S’y ajoute un certain « anglocentrisme ». MMLU en témoigne. Plus d’un quart des questions exigent une « pensée occidentale » et 85 % des références géographiques se focalisent sur l’Amérique du Nord ou l’Europe.
Un framework orienté objets
Pour identifier les périmètres métiers, l’équipe de Mikaël Le Bars s’est basée sur tous les projets sur lesquels avait travaillé BPCE – y compris PoC et idéations. Elle a déterminé les compétences attendues dans chaque projet (modération, traduction, détection des intentions…) et les a découpées en tâches sur lesquelles évaluer les modèles (classification, reconnaissance vocale, extraction d’entités…).
Deuxième étape : identifier les datasets à disposition. Et éventuellement procéder à des labellisations. « Sur un des projets, on a tous enregistré du texte qu’on devait lire », explique Mikaël Le Bars.
Aux métriques à l’état de l’art (BLEU et METEOR pour la traduction, faux positifs et faux négatifs pour l’extraction de données sensibles…), BPCE a ajouté des métriques propres à ses activités. Par exemple, pour la transcription audio, le taux d’erreurs sur les termes spécifiques au milieu bancaire.
Le priorisation se fait selon l’usage, les données internes disponibles et la criticité, en prenant en compte le coût, la latence et la robustesse des systèmes mis en place.
L’implémentation s’est faite avec un framework orienté objets. Il permet de développer des composants évolutifs, pour recevoir de nouveaux datasets, modèles ou métriques.
Le code est déployé dans plusieurs environnements en fonction de la criticité des données et de la disponibilité des modèles. Chaque exécution est horodatée et identifié par version de modèle, de jeu de données et de prompt. Un protocole commun permet d’exporter les résultats en CSV dans un tableau de bord pour les métiers.
La configuration est plus importante que le modèle
Entre autres éléments dont les benchmarks publics ne rendent pas forcément compte, il y a l’impact de chaque composante d’un pipeline sur la justesse des réponses. En la matière, BPCE évoque un de ses cas d’usage, sur l’extraction d’informations à partir de documents financiers. Son constat : la configuration est plus importante que le modèle. Celui-ci n’a qu’un impact de 1 à 4 points de pourcentage. Contre 12 à 17 points pour l’embedding, 10 à 20 pour la phase de chunking / récupération et 14 à 21 pour l’OCR.
L’intérêt des métriques internes est apparu en particulier sur la transcription audio. Plus précisément, le traitement d’une conversation téléphonique comportant la consigne « virer 45 000 € sur le compte 8837 ». Un modèle peut oublier le mot « le » tandis qu’un autre comprendra 40 000 au lieu de 45 000. Dans la pratique, les deux erreurs ne se valent pas. Mais une métrique standard comme le WER (Word Error Rate), très utilisé dans les benchmarks publics, produira le même score pour l’un et l’autre modèle. Y ajouter des aspects tels que la ponctuation et les termes métier permet de faire une différence.
L’agentique, un gros morceau en perspective
Au fil des évaluations, BPCE a conclu que le classement obtenu en conditions nominales ne résiste ni au bruit, ni aux accents, ni aux données hors distribution.
Quant à ce qu’a coûté la démarche : « Pas mal, d’abord en temps humain », entre labellisation, codage et déploiement selon Mikaël Le Bars. Mais « on échange des coûts subis contre un coût choisi ». Et 70 % du code est réutilisable.
BPCE réfléchit à impliquer davantage les entités du groupe (la solution est disponible sur le dépôt intenre). Notamment en permettant aux utilisateurs d’uploader leurs modèles et de configurer des prompts. Un passage en open source est envisagé à moyen ou long terme. Autre perspective : élargir le benchmark aux systèmes agentiques – pas encore déployés en interne. Le défi est singulier : il ne faudra pas évaluer que le résultat final, mais aussi l’enchaînement des actions réalisées pour y parvenir.
Cisco a mis à disposition de la quasi-totalité de ses 90 000 salariés un agent IA individuel dès le lancement de son exercice fiscal 2027. Il ne s’agit pas d’une expérimentation limitée à quelques directions, mais d’un déploiement uniforme, présenté en interne comme une brique d’infrastructure durable plutôt que comme un projet pilote.
Baptisé MyAgent, l’outil est accessible depuis une application de bureau ou mobile et s’intègre à Webex, la plateforme de visioconférence maison, ainsi qu’à Outlook, Jira et SharePoint, selon les précisions apportées par Cisco .
L’outil repose sur Circuit, une plateforme d’IA interne que Cisco décrit comme sécurisée, gouvernée et agnostique vis-à-vis des modèles utilisés, censée donner aux salariés un accès maîtrisé aux LLM approuvés, aux agents et aux données de l’entreprise.
Chaque instance est strictement personnelle et ne reçoit d’instructions que de l’utilisateur auquel elle est rattachée. Toute action ayant un effet à l’extérieur du système nécessite une validation humaine explicite.
Myagent fonctionne selon un modèle piloté par l’intention. L’utilisateur définit un objectif, un contexte et un résultat attendu et MyAgent détermine seul l’enchaînement des étapes nécessaires pour y parvenir. Il dispose également d’une mémoire persistante, censée conserver les préférences et l’historique des interactions d’un salarié dans la durée.
Cisco indique par ailleurs que les interactions agentiques sur sa plateforme Circuit ont progressé de près de 350 % d’un trimestre sur l’autre avant le lancement généralisé de MyAgent ( fin juillet).
Un routage multi-modèles pensé pour maîtriser les coûts
Pour éviter une explosion de la facture liée aux modèles d’IA les plus puissants, Cisco a construit une couche d’orchestration interne qui répartit chaque requête vers le modèle jugé le plus pertinent selon la nature de la tâche, la latence tolérée et le niveau de fiabilité requis.
Selon les informations disponibles :
entre 50 % et 60 % des requêtes sont traitées par des modèles « open-weight », hébergés en interne sur des serveurs GPU appartenant à Cisco ;
entre 20 % et 30 % relèvent d’automatisations logicielles classiques, sans recours à un modèle génératif ;
seule une part résiduelle des appels sollicite des modèles de fondation externes, tels qu’Azure OpenAI, Claude d’Anthropic ou Gemini de Google.
« Cela ne va pas brûler une tonne de tokens avec des modèles frontier », assure Mark Patterson, son directeur financier, dans une interview à Fortune, revendiquant cette architecture comme un levier de discipline budgétaire autant que technique.
Le suivi de la consommation de tokens repose, lui, sur un outil de supervision issu de Splunk, rachetée par Cisco en 2023.
Gouvernance et sécurité des accès
MyAgent n’est pas censé disposer d’un accès sans restriction au SI. Cisco l’inscrit dans une architecture de gouvernance qui détermine quels modèles, systèmes et données l’agent peut utiliser et quelles actions il peut effectuer. L’objectif est de dissocier la capacité de l’agent à décider des étapes d’une tâche de son autorisation à exécuter effectivement ces opérations.
Cette couche de contrôle est complétée par les mécanismes de sécurité de Cisco, regroupés notamment sous la marque AI Defense, destinés à surveiller les interactions entre les utilisateurs, les modèles et les agents. L’enjeu est notamment de détecter des tentatives de manipulation des instructions, des comportements malveillants ou encore des transferts de données vers des ressources non autorisées.
Des usages concentrés sur la finance et le reporting réglementaire
Les cas d’usage mis en avant par la direction de Cisco se situent en priorité dans des fonctions à forte valeur ajoutée documentaire :
Rédaction réglementaire. Selon Mark Patterson, entre 80 % et 90 % de la première version de la section « Management’s Discussion and Analysis » (MD&A) des documents déposés auprès du régulateur boursier américain (SEC) est désormais générée par l’IA.
Pilotage financier. Le directeur financier utilise un tableau de bord baptisé « CFO cockpit », alimenté par l’IA, qui agrège les performances par produit, zone géographique et segment client, et suggère des actions correctives.
Veille concurrentielle. L’agent personnel de Mark Patterson compare automatiquement les performances de Cisco à celles de ses pairs sur des indicateurs comme la croissance du chiffre d’affaires, le bénéfice par action (EPS) ou les dépenses de recherche et développement.
Gestion de la messagerie. De façon plus transversale, les salariés s’appuient sur leur agent pour résumer leurs e-mails, filtrer les messages indésirables et pré-rédiger des réponses.
Analyse de marché. Certains agents sont également mobilisés pour synthétiser l’actualité financière et esquisser des anticipations de mouvements boursiers.
Un « client zéro » pour les offres IA de Cisco
Au-delà de l’usage interne, ce déploiement sert également de vitrine commerciale. Cisco se positionne comme son propre client de référence à grande échelle pour ses offres d’agents IA ( notamment Webex AI Agents) ainsi que pour son infrastructure réseau et sécurité optimisée pour l’intelligence artificielle.
Mais plusieurs questions restent en suspend.
D’abord sur le coût du programme. Des estimations non confirmées évoquent une facture annuelle de l’ordre de 900 millions de $ en consommation de tokens, soit environ 200 $ par salarié et par semaine. Un chiffre à prendre avec toutes les réserves qui s’imposent en l’absence de confirmation officielle.
Ensuite, sur l’impact à moyen terme sur l’emploi. La direction dément tout lien direct entre le déploiement des agents et les 4 000 suppressions de postes annoncées en mai dernier présentées par Cisco comme une opération de « réallocation des ressources » vers les segments jugés stratégiques
Mais la séquence des annonces, combinée aux déclarations d’autres dirigeants du secteur sur des sujets comparables, laisse ouverte la question d’une transformation plus profonde des métiers au sein du groupe.
Avec une équipe technique de 5 personnes, l’application Yuka qui évalue la qualité des produits alimentaires et cosmétiques, gère plus de 70 scans par seconde et 68 millions d’utilisateurs à travers le monde.
Alors que l’application mobile ne cesse de croître avec plus de 5 millions de produits référencés dans 13 pays, sa plateforme technique vient de franchir une étape majeure en passant de Symfony 4 à Symfony 7, avec l’aide de SensioLabs à l’origine de Symfony.
Trois enjeux majeurs ont dicté cette modernisation :
Optimiser les performances en intégrant les derniers standards du langage PHP et de Symfony. Yuka a mis en place des systèmes de mise en cache avancés réduisant drastiquement le nombre de requêtes serveurs et les coûts d’infrastructure.
Garantir la sécurité de l’application avec les derniers correctifs de sécurité et un support garanti jusqu’à fin 2028.
Faciliter le recrutement en évoluant sur les technologies les plus récentes du marché pour attirer plus facilement les meilleurs talents.
Une montée de version étape par étape
Selon SensioLabs, la migration ne s’est pas faite en une seule fois.
Initialement bâtie sur Symfony 4 et sur EasyAdmin 1 pour son interface d’administration, l’application a gravi les versions une à une : Symfony 5, puis 6, puis 7 avec en parallèle une montée d’EasyAdmin jusqu’à sa version 4.
Ce chantier s’est accompagné d’une mise à jour de tout l’environnement technique, avec le passage de PHP 7.4 à PHP 8.3 et celui de l’ORM Doctrine, passé de sa version 2 à sa version 3.
Ce séquençage précis a permis de suivre les bonnes pratiques recommandées par Symfony et d’éviter les mauvaises surprises, alors que le passage aux dernières versions de Symfony et d’EasyAdmin nécessitait un travail important de refactoring du code, du fait de l’évolution des standards et de la nécessité d’adapter les personnalisations d’EasyAdmin.
Une occasion d’outiller et de fiabiliser le code
Au-delà de la seule montée de version, ce chantier a aussi été l’occasion pour Yuka de renforcer ses pratiques de développement.
Toujours selon SensioLabs, l’équipe a notamment mis en place une chaîne d’intégration continue (CI) qui n’existait pas auparavant, harmonisé ses pratiques de code grâce aux outils PHPStan, Rector et PHP CS Fixer, et renforcé sa couverture de tests.
Des revues de code régulières et des tests de non-régression ont également été instaurés pour garantir la performance et la qualité du code sur le long terme.
Cette modernisation a aussi été l’occasion pour Yuka de contribuer concrètement à l’écosystème open source. Les contributions ont porté sur plusieurs bundles tiers, dont NzoUrlEncryptorBundle, kreait/firebase-bundle et algolia/search-bundle, ainsi que sur EasyAdminBundle lui-même.
« Il était essentiel pour nous de ne pas rester bloqué sur une version vieillissante. Grâce à l’architecture de Symfony, nous avons pu moderniser simplement notre socle technique et propulser notre application à l’échelle mondiale », résume François Martin, cofondateur et CTO de Yuka.
La ville de Gentilly (Val de Marne – 94) s’appuyait depuis longtemps sur un environnement construit autour des outils Microsoft, aussi bien pour la bureautique que pour l’intranet, sous SharePoint.
Dès 2020, la collectivité entame une réflexion sur la réduction de sa dépendance aux solutions extra-européennes. Le chantier avance progressivement, au rythme d’un inventaire des outils et applications utilisés par les services.
« Nous avons progressivement engagé une réflexion globale sur notre système d’information afin de privilégier des solutions que nous maîtrisons davantage et qui répondent mieux à nos enjeux de souveraineté », indique Dominique Joseph-Eugène, DSI de la Ville de Gentilly.
Une cyberattaque comme point de bascule
En 2025, une cyberattaque touche une partie du système d’information de la collectivité et le paralyse pendant plusieurs mois. L’incident pousse la Ville à relancer et accélérer plusieurs chantiers déjà engagés, dont celui des outils collaboratifs.
« Cet épisode a été un véritable électrochoc. Il nous a obligés à remettre à plat notre environnement numérique et à accélérer certaines transformations déjà engagées », ajoute Dominique Joseph-Eugène.
Remplacer SharePoint
La collectivité choisit de remplacer son intranet SharePoint par Jamespot, une plateforme collaborative hébergée en France.
Le projet, relancé après la cyberattaque, est mis en service fin 2025. Il fait passer l’intranet d’un fonctionnement essentiellement descendant à un espace intégrant une dimension de réseau social d’entreprise, où les agents peuvent commenter et partager l’information, en plus d’y accéder.
« Nous sommes passés d’un intranet essentiellement descendant à une véritable plateforme collaborative. L’information circule mieux, mais surtout, les agents peuvent désormais participer et contribuer. Cela change profondément la manière de travailler », souligne Axel Burklé, chargé de communication interne.
Un projet parti des besoins du terrain
Avant de choisir un outil, la ville de 19 000 habitants a mené un diagnostic auprès de ses équipes pour identifier leurs besoins réels. Les demandes qui en sont ressorties portaient sur davantage d’échanges, des outils plus interactifs et une information moins descendante.
« Le projet n’est pas parti d’un outil, mais d’un besoin. Les agents ont exprimé ce qui leur manquait au quotidien, et cela a fortement facilité l’adhésion », précise Axel Burklé.
Environ 480 agents, soit près de 60 % des effectifs concernés, sont aujourd’hui connectés à la plateforme Jamespot. L’adoption reste progressive, en particulier du côté des agents de terrain, moins équipés en accès numériques que les postes administratifs.
Une transition qui reste partielle
Le remplacement de l’intranet s’inscrit dans une démarche plus large de reprise en main du système d’information. La collectivité dit privilégier désormais des solutions françaises ou européennes pour une partie croissante de ses outils, avec l’objectif de gagner en interopérabilité et de réduire sa dépendance à un écosystème unique.
Certaines briques Microsoft restent toutefois encore en place, la bascule se faisant progressivement plutôt que d’un bloc.
« La souveraineté est devenue un enjeu très concret pour les collectivités. Il ne s’agit plus seulement d’un principe, mais d’une réalité opérationnelle qui impacte directement notre architecture, nos choix technologiques et notre capacité à maîtriser nos données », conclut Dominique Joseph-Eugène.
Atos va déployer Microsoft 365 Copilot à l’ensemble de ses 56 000 salariés répartis dans 54 pays.
Le socle technologique retenu est Microsoft 365 E7, une suite qui réunit en une seule solution Microsoft 365 Copilot, les fonctionnalités de sécurité et de conformité de Microsoft 365 E5, ainsi que Microsoft Agent 365.
Atos devient ainsi le premier intégrateur de systèmes français d’envergure mondiale à déployer cette solution, et l’une des premières entreprises au monde à opérer entièrement la suite Microsoft 365 E7 depuis sa disponibilité générale. Un positionnement de « client zéro » assumé, qui vise autant à transformer le groupe en interne qu’à crédibiliser son offre auprès de ses clients.
« C’est l’investissement technologique le plus significatif qu’Atos ait réalisé dans ses équipes depuis une génération », affirme Frédéric Aubrière, directeur numérique et information du groupe( photo).
Gouvernance des agents, un enjeu central
Au-delà de Copilot dans les outils du quotidien ( Outlook, Teams, Word, Excel, PowerPoint, SharePoint), Atos déploie également Microsoft Copilot Studio et Microsoft Foundry pour concevoir et exploiter des agents dédiés à ses services IT, à ses fonctions métier et à ses clients.
La gouvernance de ces agents constitue l’un des points névralgiques du dispositif. Via Microsoft Agent 365, Atos entend gérer une population déjà estimée à 19 000 agents IA au sein d’une solution unique, couvrant aussi bien les agents agissant au nom des utilisateurs que ceux opérant avec leurs propres identifiants. L’ensemble est intégré aux flux de travail de sécurité déjà en place dans le groupe.
Pour une entreprise présente dans des secteurs hautement réglementés ( défense, services financiers, santé, administration publique), cette consolidation de l’identité, de la sécurité et de la conformité en un plan de contrôle unifié est une condition sine qua non du déploiement.
La stratégie d’Atos repose sur trois piliers : l’IA agentique pour les environnements critiques, la souveraineté numérique et la cybersécurité. En se transformant d’abord lui-même, le groupe entend industrialiser ces capacités avant de les proposer à ses clients, notamment dans les secteurs réglementés où la confiance dans l’infrastructure est non négociable.»
Ces capacités seront intégrées aux studios d’IA agentique souveraine qu’Atos est en train de constituer, avec pour ambition déclarée de mettre l’IA en production en toute sécurité dans des organisations complexes.
Dix ans après avoir entamé sa transition vers une architecture Zero Trust, Alstom annonce l’extension de son partenariat avec Zscaler. L’occasion pour le groupe, spécialisé dans la mobilité ferroviaire, de revenir sur un chantier technologique de fond et d’en détailler les prochaines étapes.
D’une infrastructure héritée à un modèle distribué
Au départ, le constat est classique pour un groupe de cette taille : une infrastructure de sécurité périmétrique reposant sur des VPN, des pare-feu et des environnements VDI, difficile à faire évoluer au rythme des opérations internationales.
« La transformation de notre sécurité a commencé avec un objectif clair : offrir à tous nos collaborateurs, où qu’ils soient, un accès sécurisé aux applications d’entreprise », résume Yann Barera, Global Head of Network chez Alstom.
La complexité s’est encore accentuée au fil des fusions-acquisitions et cessions qui ont rythmé la vie du groupe ces dernières années, rendant la gestion d’une infrastructure centralisée d’autant plus difficile à tenir. Le passage à une architecture ZTNA (Zero Trust Network Access) a permis à Alstom de remplacer progressivement ces mécanismes d’accès hérités et de standardiser les connexions aux applications métier, quel que soit le lieu de travail des collaborateurs.
Des besoins qui s’élargissent : sites industriels, terrain, IA
Au-delà de la sécurisation des postes de travail, Alstom étend aujourd’hui son usage à d’autres périmètres. Les agences et usines font l’objet d’un déploiement spécifique pour connecter et sécuriser les équipements IoT et OT dans le cadre des politiques de sécurité du groupe.
Côté terrain, le développement de l’activité de maintenance impose de nouvelles contraintes. Les techniciens intervenant dans des environnements sans Wi-Fi stable doivent pouvoir accéder aux systèmes d’information via le réseau mobile. Alstom a pour cela déployé une solution de connectivité cellulaire sécurisée (Z-SIM).
L’essor des outils d’intelligence artificielle en entreprise ouvre un nouveau front. « Avec la montée en puissance de l’IA, il nous fallait des fonctionnalités supplémentaires pour encadrer les nouveaux usages », indique Yann Barera. Alstom a ainsi adopté un module de prévention des fuites de données spécifiquement orienté vers les usages GenAI, dans l’objectif de maintenir une visibilité sur les flux et de protéger la propriété intellectuelle.
Monitoring de l’expérience réseau en temps réel
Pour réduire les délais de résolution lors d’incidents réseau, les équipes IT d’Alstom s’appuient sur un outil de supervision qui agrège des indicateurs en temps réel sur l’état du réseau et des terminaux. « Nous nous appuyons également sur les fonctions de monitoring pour améliorer en continu la qualité de notre réseau », précise Yann Barera.
L’ensemble de ces déploiements témoigne d’une évolution progressive mais cohérente : partir d’une problématique d’accès sécurisé pour les collaborateurs, puis étendre le modèle aux sites, aux équipements industriels et désormais aux usages IA. Le tout sans reconstruire l’infrastructure à chaque fois.
Avignon Tourisme gère un périmètre particulièrement vaste : Palais des Papes, Pont d’Avignon, Office de Tourisme, Centre des Congrès et Parc des expositions. Autant de lieux où l’accès à la connectivité est devenu aussi central que l’organisation même des visites ou des événements. Avec près d’un million de visiteurs chaque année et des pics estivaux très marqués, la fiabilité du réseau conditionne directement l’expérience sur le terrain.
Une infrastructure qui a dû changer d’échelle
À l’origine, l’infrastructure réseau se limitait à un périmètre restreint, principalement centré sur les besoins internes. Au fil du temps, l’arrivée de la fibre, la centralisation de certains services et la montée en puissance du digital dans le tourisme ont poussé l’organisation à reprendre son architecture de fond en comble. Il s’agissait désormais de relier des sites distants, de supporter des usages plus intensifs et de garantir une continuité de service quasi systématique.
Le développement du tourisme d’affaires et la tenue de grands événements ont ensuite accéléré le besoin de montée en capacité. Les salles de congrès, les espaces d’exposition ou les aires de visite doivent aujourd’hui pouvoir encaisser des milliers de connexions simultanées, entre professionnels, visiteurs et systèmes internes, sans dégrader la qualité de service.
Une architecture unifiée basée sur NETGEAR
Pour structurer cette évolution, Avignon Tourisme a retenu les solutions NETGEAR, intégrées progressivement à chaque étape de la transformation. L’infrastructure compte aujourd’hui environ 75 équipements répartis sur l’ensemble des sites, formant une architecture cohérente du cœur du réseau jusqu’aux points d’accès locaux.
Les switches de cœur et d’agrégation soutiennent la montée en débit et la transition vers des architectures 10 Gigabit, tandis que les couches de distribution et d’accès assurent une couverture adaptée aux contraintes de chaque lieu. La standardisation sur une même gamme permet de simplifier la supervision, de limiter la diversité des outils et de réduire la complexité d’exploitation sur un environnement multi‑sites.
Le choix d’une évolution progressive a eu un avantage majeur : la stabilité du service. L’infrastructure a été modernisée sans rupture technologique majeure, ce qui a permis de maintenir une continuité de service importante pour les utilisateurs finaux. Dans un contexte où chaque incident réseau peut impacter des événements ou des flots de visiteurs, cette continuité est un facteur clé.
Un déploiement progressif
Comme l’explique Pascal Borel, responsable informatique d’Avignon Tourisme, les équipements ont été adoptés au fur et à mesure de l’évolution des activités. Cette logique progressive a permis de conserver les investissements déjà réalisés tout en accompagnant les nouveaux besoins.
Aujourd’hui, le réseau n’est plus vu seulement comme un support technique, mais comme un maillon direct de l’expérience visiteur. À l’horizon 2026, la digitalisation du parcours de visite du Palais des Papes devrait illustrer cette mutation, en s’appuyant sur l’infrastructure déjà en place. Visites interconnectées, contenus numériques, guides mobiles ou services temps réel devront tous reposer sur une connectivité stable et homogène.
DynamoDB pour gérer le contexte, S3 pour centraliser les configurations d’agents, Lambda pour orchestrer les outils et l’observabilité… À l’origine, il y avait un peu de tout ça dans la plate-forme GenAI de La Centrale.
Cette v1 a permis la mise en prod d’une vingtaine de cas d’usage. Parmi eux, la création de descriptions à partir des données de véhicules pour rendre les annonces plus attractives. Ou l’aide au pricing pour les vendeurs professionnels. Elle s’est cependant révélée inadaptée pour faire du multi-agent. Et, dans une certaine mesure, du multifournisseur. Il fallait en tout cas un certain « effort d’implémentation » pour sortir de l’écosystème Bedrock et se brancher en direct avec OpenAI, par exemple.
Quoique flexible (couche applicative au-dessus de l’API Converse), cette plate-forme était par ailleurs de moins en moins pertinente à mesure que les frameworks du marché gagnaient en maturité, selon Fabien Roussel, head of architecture chez Groupe La Centrale.
Des agents en tant qu’outils
Pour la v2, La Centrale a basculé sur AgentCore, en y associant Strands Agents, un SDK open source (Python, NodeJS) made in AWS.
« On peut faire du multi-agent sans faire nous-mêmes le code de collaboration », explique Fabien Roussel. Il ajoute que Strands Agents fournit des intégrations natives avec OpenAI & Cie. Ainsi qu’avec AgentCore (exemple avec la brique de gestion de la mémoire : « Ce n’est pas nous qui allons coder le GET et le PUT »).
Ce socle a permis d’améliorer l’assistant de recherche de véhicules que La Centrale avait déployé en 2024. Notamment grâce au pattern agent as tool : Strands Agents peut encapsuler des agents en tant qu’outils.
Sur cet assistant de recherche, l’agent principal (l’orchestrateur) qualifie la demande de l’utilisateur, y répond s’il le peut et délègue sinon à des agents spécialisés… traités, donc, en tant qu’outils. D’une part, Caraguide, spécialisé dans le conseil auto, à l’appui d’un RAG basé sur Caradisiac, le site éditorial du groupe. De l’autre, Free Text Search, qui normalise les données véhicule puis appelle l’API de recherche.
Chaque agent est déployé dans son runtime, avec une mémoire à court et long termes.
« Environ 1 $ » pour adapter des articles
Caradisiac porte un autre cas d’usage : la transformation de son contenu éditorial pour l’intégrer sur La Centrale. À la fois pour l’aide à la décision des utilisateurs en début de parcours et pour améliorer le positionnement sur les moteurs de recherche.
Le processus implique une vingtaine d’agents. Il prend environ 10 minutes par article. Coûts LLM : environ 1 $ (les coûts de compute sont négligeables, affirme Fabien Roussel).
Les agents travaillant ensemble, ils partagent un runtime.
Les deux cas d’usage exploitent des serveurs MCP managés déployés avec AgentCore Gateway.
La Centrale a opté pour un serveur MCP par domaine. Une gateway pour tous les outils n’était pas envisageable (« On explose le contexte »). Une gateway par outil ne l’était pas non plus (« C’est trop fin, trop petit, on ne peut pas scaler »).
Pour l’authentification des agents, c’est de l’OAuth 2 avec Cognito derrière. Pour l’authentification entre la passerelle et les outils, cela dépend : clés pour les API, IAM pour les fonctions Lambda.
Au-delà des déploiements dans AgentCore Runtime, le système gère aussi les agents externes.
Romain Dachy a rejoint Domitys il y a un an, peu après l’acquisition complète du groupe par AG2R La Mondiale, finalisée en février 2025. Fort d’un parcours de près de trente ans dans l’IT, il arrive avec la mission claire de moderniser un système d’information qui n’a pas suivi la croissance de l’entreprise.
Son constat est sans ambages. « On a eu une constellation d’applications installées progressivement sans forcément de vision globale. On a coutume de dire : on n’a pas un système d’information, on a de l’informatique. » décrit-il.
Résultat : des applications qui ne communiquent pas entre elles, des données qui circulent en double ou en triple, des processus métiers encore largement portés par Excel, et des pans entiers d’activités non outillés.
Une situation qui s’explique historiquement. Quand Domitys ne comptait que dix ou quinze résidences, ces pratiques étaient acceptables. Aujourd’hui, avec plus de 200 résidences, 5 000 collaborateurs et une cible fixée à 220 établissements d’ici fin 2027, elles ne le sont plus.
S’y ajoute un autre constat organisationnel : des sous-ensembles d’activités IT étaient portés par des directions métiers, en dehors de la DSI. L’un des objectifs de la transformation est précisément de recentraliser l’ensemble des activités informatiques au sein de la direction des systèmes d’information.
Une feuille de route sur 6 ans et une dizaine de projets
À l’issue d’une étude de schéma directeur menée dès son arrivée, Romain Dachy a obtenu en début d’année la validation du conseil de surveillance pour lancer la transformation. La feuille de route s’étale sur six ans et regroupe une dizaine de projets structurants.
La cybersécurité a été le premier chantier engagé, et pour cause : l’adossement à AG2R La Mondiale impose des exigences fortes, même si Domitys n’est pas soumis aux mêmes contraintes réglementaires que son actionnaire.
En un an, les équipes ont déployé le MFA, sécurisé l’ensemble du parc PC selon les standards du groupe, et mis en place un SOC avec un outil SIEM. Les prochaines étapes porteront sur le MDM et une refonte complète de l’IAM. « C’est un bon exemple de ce que nous apporte AG2R La Mondiale : on n’a pas eu à se poser la question des outils. Si on avait tout fait seuls, on y serait encore. » indique le DSI.
Viennent ensuite, pour 2026, deux chantiers étroitement liés : la transformation data et la refonte du CRM. Sur la data, la priorité n’est pas encore l’intelligence artificielle mais le préalable indispensable : la gouvernance, la qualité de la donnée et la mise en place de référentiels d’entreprise.
CRM, Data…construire une vision à 360 degrés du client
« Dans un premier temps, il faut remettre les données au propre », résume Romain Dachy. Une plateforme data viendra dans un second temps pour ouvrir la voie aux cas d’usage IA. Sur le CRM, l’enjeu dépasse la simple prospection commerciale : il s’agit de construire une vision à 360 degrés du client, couvrant l’ensemble du cycle de vie en résidence.
La feuille de route comprend également la mise en place d’un ERP finance pour consolider comptabilité, facturation et achats aujourd’hui éparpillés sur plusieurs applications mais également d’un SIRH centralisé, et d’un projet ITSM visant à industrialiser les processus internes de la DSI, de la gestion des tickets d’incidents aux méthodes projet.
L’objectif transversal de tous ces chantiers est identique : libérer les collaborateurs en résidence des ressaisies et des tâches manuelles, pour qu’ils consacrent davantage de temps aux résidents. « L’idée, c’est d’avoir un système digital pour le collaborateur, pas forcément pour le client. »
L’opportunité de l’IA
Interrogé sur le calendrier de sa transformation, Romain Dachy formule une réponse inattendue : l’entreprise arrive au bon moment. « C’est l’avantage d’être en retard : on peut rattraper des pans entiers du SI en rebattant les cartes, notamment avec une approche IA. Celui qui peut faire de l’agentique aujourd’hui, c’est aussi celui qui avait anticipé un SI flexible il y a deux ou trois ans. »
La GenAI sera intégrée progressivement dans les nouveaux processus, notamment sur le CRM, sans pour autant être un objectif en soi. Romain Dachy se montre volontairement prudent : « On ne va pas mettre de l’IA partout pour des questions de coût, de ROI. Il faut savoir résister aux sirènes de la mode. » Il cite en exemple le cas de Microsoft Copilot, dont les retours à grande échelle restent décevants selon lui.
Cloud souverain et alignement sur AG2R La Mondiale
Sur le sujet de l’infrastructure, Domitys s’aligne sur les choix technologiques de son actionnaire. Pour la data, le choix s’est porté sur Google Cloud au travers de l’offre S3NS de Thales, qui répond aux exigences de souveraineté portées par AG2R La Mondiale. « L’offre S3NS coche toutes les cases : les capacités Google en matière de data, et l’approche souveraine apportée par Thales. Notre actionnaire nous a imposé cette direction, et ça me va bien, d’autant plus vu les dernières postures des États-Unis. »
Pour le reste du SI, Domitys conserve une approche hybride avec ses propres data centers. La DSI de cinquante personnes réalise elle-même ses projets, en s’appuyant sur les équipes architecture et les contrats cadres d’AG2R La Mondiale, sans en dépendre pour l’exécution.
Le DSI de demain : partenaire, innovateur, recruteur de mindsets
Sur la posture du DSI, Romain Dachy est catégorique : « Un DSI qui n’accompagne pas ses métiers passe à côté de quelque chose. » La transformation qu’il mène est partie des irritants exprimés par les directions métiers, et il entend que ses équipes deviennent leurs partenaires de confiance. « Un DSI moderne doit être aussi data, aussi innovation, pour anticiper les mouvements à opérer sur son système d’information. »
Il observe également que le mouvement s’est fait dans les deux sens : les directions métiers, notamment sous l’effet de l’IA générative, ont aussi développé une culture technologique plus affûtée. « On voit des directions métiers qui prennent la réflexion sur l’automatisation et qui amènent l’informatique dans la boucle. »
Gérer 70 aéroports répartis dans 14 pays, accueillir 320 millions de passagers par an et générer 4,5 milliards € de revenus : le défi opérationnel de Vinci Airports est à la mesure de son empreinte mondiale.
Le groupe a engagé une transformation data et IA d’envergure, en s’appuyant sur Google Cloud Platform.
Une dépendance à la maîtrise des flux
Le modèle de Vinci Airports repose sur deux piliers : les redevances aéronautiques, qui représentent environ 50 % des recettes, et les revenus commerciaux générés par les dépenses des passagers (duty-free, restauration, parkings), qui en constituent 30 à 40 %.
Cette structure impose d’anticiper avec précision les flux de passagers. De cette capacité prédictive découlent en cascade le dimensionnement des équipes, le calibrage de l’offre commerciale, les projections financières et la stratégie d’investissement.
La difficulté résidait dans l’extrême hétérogénéité du réseau. Chaque aéroport dispose de ses propres systèmes informatiques, de ses contraintes locales et de ses spécificités opérationnelles. Les données étaient dispersées, non standardisées et cloisonnées.
Une Data Factory pour fédérer les données du réseau
Cette infrastructure centralise la collecte de données issues de systèmes hétérogènes dans 14 pays, automatise les contrôles de qualité et harmonise les structures de données pour permettre des comparaisons fiables entre les plateformes.
L’architecture retenue s’appuie sur les briques éprouvées de Google Cloud : BigQuery pour le stockage et l’analyse de données massives, Vertex AI pour l’entraînement et le déploiement des modèles prédictifs, Cloud Run et Streamlit pour mettre à disposition des interfaces métier accessibles, Cloud Storage pour la gestion centralisée des modèles et Cloud Build pour l’intégration continue.
Ce choix architectural permet aux aéroports de conserver leurs outils locaux tout en exposant leurs données dans un référentiel commun, où elles sont nettoyées, structurées et exploitables pour alimenter des tableaux de bord, des analyses et des modèles d’IA.
Trois cas d’usage au cœur de la transformation
Le premier et principal cas d’usage porte sur la prédiction du trafic de passagers. Des modèles prédictifs multi-échelles ont été conçus pour répondre aux besoins de chaque niveau de management : projections annuelles pour la direction générale, vues hebdomadaires ou journalières pour les équipes opérationnelles, et analyses localisées par aéroport. Ces modèles croisent l’historique de trafic, des variables exogènes et des signaux faibles pour simuler des trajectoires et optimiser les arbitrages.
Le deuxième axe concerne l’efficacité opérationnelle. En analysant les cartes d’embarquement scannées, il est désormais possible d’anticiper les arrivées aux postes de sécurité. Croisées avec les capacités de traitement des files, ces données permettent d’ajuster les effectifs en temps réel, avec pour objectif de maintenir les temps d’attente sous les dix minutes.
Le troisième cas d’usage touche à l’optimisation commerciale. En croisant les données de trafic et les comportements d’achat, Vinci Airports identifie des profils de consommation selon les typologies de passagers et les destinations. Un voyageur britannique en transit ne dépense pas de la même façon qu’un passager français sur un vol domestique : ces patterns permettent de recommander aux commerçants des ajustements d’assortiment adaptés au profil de leur clientèle effective.
La qualité des données au coeur du projet
Artefact est intervenu dès les premières étapes du projet avec une approche collaborative impliquant les équipes opérationnelles dès le premier jour.
Cette démarche est décrite par Benoît Forest, directeur des Opérations et Data de Vinci Airports, comme une condition sine qua non : « Le timing d’embarquement des équipes opérationnelles est très important. Il doit commencer dès le jour un. Cela garantit que les data scientists comprennent les préoccupations métier et intègrent des besoins très opérationnels dans la conception des solutions. »
La qualité des données a constitué un autre enjeu majeur avec la mise en place des dispositifs automatisés de détection des fichiers manquants, de contrôle de la structure des données et de tests d’intégrité, avec alertes automatiques en cas d’anomalie.
Ces garde-fous, opérés entièrement dans Google Cloud Platform, préviennent les dérives silencieuses qui érodent la confiance des métiers dans les modèles.
« Je pense que le succès de ce projet réside dans la compréhension du défi stratégique métier, la définition du périmètre, le déploiement de la solution, la formation, et aujourd’hui l’outil est utilisé quotidiennement par les équipes métier », résume Benoît Forest.
Un cap vers l’IA générative
Vinci Airports engage ensuite une deuxième phase orientée vers la prédiction systématisée et l’IA générative. Trois cas d’usage sont à l’étude : un assistant GPT intégré aux tableaux de bord, un mode de requêtage conversationnel des bases de données, et un système d’extraction automatique de contenu documentaire (procédures, audits, rapports).
L’ambition est de dépasser les limites des dashboards Power BI actuels pour permettre à chaque collaborateur d’interroger directement l’ensemble des données via des agents IA autonomes, capables d’apporter des réponses à des questions complexes sans nécessiter de développement supplémentaire.
« L’IA nous permet ici de passer de l’intuition locale à la connaissance partagée, sans remplacer les équipes, mais en leur donnant les moyens de gagner du temps et de se concentrer sur la prise de décision », conclut Benoît Forest.
Connexion
