Le Groupe Alain Afflelou a migré l’intégralité de son infrastructure depuis VMware ESXi vers l’hyperviseur Nutanix AHV. Une opération menée tambour battant en 2024, motivée par les incertitudes liées au rachat du champion de la virtualisation par Broadcom et l’augmentation des coûts.
Avec près de 1 500 points de vente répartis dans 19 pays (principalement France, Espagne, Belgique, Suisse et Portugal), le groupe d’optique et d’appareils auditifs fait face à une complexité IT particulière. Son modèle largement basé sur la franchise complique l’unification des environnements informatiques. La DSI, dirigée par Ludovic Tassy depuis 2006, s’appuie sur une expertise interne solide et des partenaires de confiance pour accompagner la croissance.
C’est dans ce contexte que la décision de quitter VMware s’est imposée. « Le passage à Nutanix a marqué un tournant : nous avons pu basculer notre infrastructure sans perturber les utilisateurs, tout en gagnant en performance et en visibilité », souligne le DSI.
Trois semaines pour tout migrer
La migration a été réalisée en trois semaines avec l’accompagnement de l’intégrateur SPIE, en s’appuyant sur Nutanix Cloud Infrastructure et l’outil Move. Bilan : près de 200 machines virtuelles et 200 To de données transférées sans interruption de service.
Le nouvel environnement repose sur deux clusters de trois nœuds chacun et un site témoin. Les gains sont au rendez-vous : performances applicatives multipliées par deux à trois sur certaines chaînes de traitement, compression des sauvegardes améliorée de 20 % et simplification de la gouvernance grâce aux fonctionnalités Prism, qui facilitent l’automatisation et le pilotage de l’exploitation.
Pour Nicolas Crochet, Responsable technique & Pôle Infrastructures, Nutanix s’est imposé comme la meilleure réponse aux enjeux de l’entreprise, en combinant maturité technologique, simplicité d’exploitation et efficacité opérationnelle. Ce choix offre à la DSI une infrastructure plus agile et réduit la dépendance aux modèles économiques imposés par les acteurs historiques du marché.
Cap sur 2026 : datacenter et convergence optique-audio
Le Groupe Alain Afflelou a déjà étendu ce déploiement en Espagne et prépare plusieurs projets complémentaires pour 2026 : refonte des cœurs de réseau et déménagement d’un datacenter.
Ces évolutions s’inscrivent dans une ambition plus large : harmoniser les logiciels de points de vente et consolider la donnée, afin de soutenir la convergence des activités optique et audio et de renforcer la qualité de service auprès des franchisés et des clients finaux.
Le Vibe Coding bouleverse les pratiques de développement informatique. En mêlant intelligence artificielle générative et langage naturel, cette approche hybride permet de produire du code à partir de simples instructions textuelles. Si elle promet accessibilité et productivité, elle soulève aussi des interrogations majeures en matière de sécurité, de maîtrise, de souveraineté numérique et de gestion des compétences.
À l’heure où l’IA entre dans la chaîne de production logicielle, les entreprises doivent repenser leur gouvernance du développement.
Derrière la promesse d’un développement plus rapide et plus accessible, le Vibe Coding introduit des enjeux structurants pour les entreprises : sécurité des applications, maîtrise des dépendances technologiques, souveraineté des environnements numériques et transformation profonde des compétences IT.
Cette approche s’appuie sur la capacité des grands modèles de langage à traduire une intention métier exprimée en langage naturel en code exécutable, un changement de paradigme qui appelle autant d’enthousiasme que de vigilance.
Le Vibe Coding redéfinit les pratiques de développement
Le Vibe Coding désigne la pratique avec laquelle une intelligence artificielle génère automatiquement du code à partir d’une intention exprimée en langage naturel. Pensé à l’origine pour des profils non techniques, il permet de créer des prototypes, des interfaces ou même des micro-applications sans passer par les langages de programmation traditionnels.
Contrairement aux outils no-code classiques qui reposent sur des interfaces visuelles, le Vibe Coding abaisse encore la barrière technique : c’est la formulation de l’idée qui suffit. Cela en fait une porte d’entrée puissante pour les porteurs de projets, les métiers ou les designers qui souhaitent tester une fonctionnalité sans dépendre d’une équipe de développement.
En entreprise, un levier d’agilité sous conditions
Si cette approche séduit les profils métiers, elle attire aussi l’attention des entreprises. Le Vibe Coding peut accélérer les phases de prototypage, réduire le time-to-market et fluidifier les échanges entre les métiers et la DSI.
Dans un contexte B2B, il peut par exemple être utilisé pour générer rapidement une base de code fonctionnelle à partir d’un cahier des charges, ou créer une interface de test pour valider une hypothèse utilisateur. Il devient alors un outil d’itération rapide, particulièrement pertinent dans les démarches agiles ou les POC.
Mais pour en tirer pleinement parti, il faut en maîtriser les risques. Car si l’IA est capable de produire du code, elle ne garantit ni sa robustesse, ni sa sécurité, ni sa conformité aux standards d’entreprise. Il faut également parler de la qualité du prompt. Pour avoir un résultat probant, la demande doit être claire et précise.
Encadrer la pratique, un impératif pour l’IT
Le code généré automatiquement peut introduire des vulnérabilités non intentionnelles, intégrer des patterns obsolètes ou contourner des règles critiques de sécurité. Si le prompt inclut des données sensibles, on court aussi le risque d’une fuite ou d’une réutilisation non maîtrisée par le modèle. Dans ce contexte, la sécurité-by-design ne peut pas être optionnelle.
Les organisations doivent intégrer, dès la production du code généré, des outils d’analyse statique de sécurité (SAST) et d’analyse de composition logicielle (SCA) au sein de leur pipeline CI/CD, afin d’auditer en continu la qualité et la sécurité du code.
La question de la traçabilité et de la gouvernance est également centrale. L’usage de modèles propriétaires, souvent hébergés sur des plateformes cloud externes, pose des problématiques de propriété intellectuelle, de souveraineté sur le code produit, et de biais algorithmique. Les DSI doivent établir une stratégie IA claire, incluant l’évaluation juridique des outputs, l’adoption potentielle de modèles open source internes, et la définition de politiques de confidentialité sur les prompts.
Conserver la maîtrise du code (output)
Il est essentiel que les développeurs conservent la maitrise du code. Le comprendre, le maitriser pour le valider et le faire évoluer.
Avec l’adoption massive du Vibe Coding, le risque serait d’engendrer une érosion des compétences techniques, en particulier chez les développeurs juniors. Une dépendance excessive aux suggestions de l’IA peut freiner l’apprentissage des fondamentaux : debug, optimisation, conception d’architectures robustes, ou gestion fine des performances.
La formation continue doit donc évoluer : elle ne doit plus uniquement porter sur la production de code, mais sur sa lecture critique, sa revue structurée, sa mise en conformité et son optimisation. Le développeur devient architecte-validateur, garant de la qualité globale du système. Des pratiques comme le pair programming augmenté par IA ou la revue croisée de code généré doivent être intégrées dans les workflows.
Le Vibe Coding constitue une évolution naturelle des outils d’assistance au développement. Bien intégré dans une démarche outillée et encadrée, il peut faire gagner un temps précieux, favoriser la co-création avec les métiers, et ouvrir la production logicielle à de nouveaux profils.
Sa mise en œuvre implique de repenser les processus de développement, les outils de sécurité, la gouvernance des modèles d’IA et la stratégie de formation. Comme souvent avec les technologies émergentes, ce n’est pas la promesse qui compte, mais la maturité avec laquelle on l’implémente.
De l’IA agentique naît le besoin de nouvelles architectures OLTP… comme le lakebase.
Fin janvier, Databricks publiait un rapport « State of AI Agents » mettant généreusement en avant ce postulat. Quelques jours plus tard, il annoncerait la disponibilité générale de sa propre offre lakebase*.
Au-delà de cette congruence, le rapport comprend quelques éléments chiffrés fondés sur la télémétrie de « plus de 20 000 clients ».
L’approche multi-LLM se répand
La proportion de clients utilisant au moins 3 LLM a tendance à s’accroître.
Mai-juillet 2025
Août-octobre
1 modèle
39 %
22 %
2 modèles
25 %
19 %
3+ modèles
36 %
59 %
Dans tous les secteurs économiques pris en considération, on a dépassé, sur la période d’août à octobre, les 50 % de clients exploitant au moins 3 LLM. Le taux le plus élevé – autour de 65 % – est dans le retail. Le secteur des utilities dépasse les 60 %, comme la santé, l’industrie et les services financiers.
Peu de batch, beaucoup de temps réel
En mai et octobre, 96 % des requêtes ont été traitées en temps réel, le reste l’étant par lots. Le secteur des technologies présente l’écart le plus important (32 requêtes real-time pour 1 batch). Suit la santé (13/1), probablement en reflet des situations critiques que gèrent les organisations de ce secteur.
La création des bases de données, largement « agentisée »
À partir de la télémétrie de Neon, base Postgre qui constitue le cœur de sa lakebase, Databricks déclare que la majorité des bases de données sont désormais créées par des agents IA. En l’occurrence, 80 % sur le mois d’octobre 2025, contre 27 % un an plus tôt. La création des branches (clonage) a suivi la même trajectoire (de 18 à 97 %).
Un usage « pragmatique » de l’IA
La veille de marché ressort comme le principal usage de l’IA dans l’écosystème Databricks sur l’échantillon concerné. Suivent la maintenance prédictive, le tri des demandes au support client, la customer advocacy et le traitement des réclamations. Le résumé des interactions client et des notes critiques apparaît en bas de la liste, comme l’analyse de sentiment.
Au global, 40 % des cas d’usages GenAI que recense Databricks automatisent des tâches routinières liées à l’expérience client.
Agora à l’état de concept ; agent.json en brouillon ; ANP en cours de finalisation ; MCP devenu « standard de fait ».
Ces quatre technologies en étaient à ces stades respectifs lorsque l’université Jiao-tong de Shanghai les a intégrées dans sa taxonomie des protocoles agentiques. C’était en mai 2025.
La taxonomie distinguait les protocoles orientés contexte et ceux axés sur la communication entre agents. Elle introduisait un deuxième niveau de segmentation, entre protocoles généralistes et protocoles spécialisés (ces derniers se divisant, sur la partie communication, entre humain-agent, robot-agent et système-agent).
Pas de suite favorable pour agents.json
Depuis, agents.json n’a pas connu de nouvelle version – la dernière date de février 2025. Le projet semble abandonné (démos non fonctionnelles, documentation en 404, invitation Discord expirée, chaîne YouTube non alimentée…). Wildcard, la start-up américaine instigatrice du projet, existe toujours. Elle s’est spécialisée dans le GEO (Generative Engine Optimization).
Le protocole étend la spécification OpenAPI pour permettre la définition de contrats guidant les LLM dans l’utilisation des API. Ces contrats contiennent un ou plusieurs appels décrivant un résultat. Une manière de conserver l’aspect non déterministe dans la réalisation des tâches tout en cadrant l’exploitation des outils.
L’approche est stateless. Les fichiers agents.json, préférentiellement hébergés dans un dossier /.well-known, sont exposés aux LLM en tant qu’outils via un SDK spécifique.
A2A, confié à la Fondation Linux
Google avait annoncé A2A (Agent-to-Agent) en avril 2025. Quelques semaines après la publication de la taxonomie, le confierait le protocole à la Fondation Linux.
A2A permet la communication entre des agents reposant sur des frameworks différents. Ils peuvent découvrir mutuellement leurs capacités (par le biais de cartes), négocier leurs modalités d’interaction et opérer sans exposer leur état interne, leur mémoire ou leurs outils. La communication est en JSON-RPC sur HTTP(S).
Un groupe de travail W3C autour d’ANP
ANP (AgentNetworkProtocol) était passé en v1 peu après la publication de la taxonomie. Depuis, la communauté qui en est à l’origine a pris la tête d’un groupe de travail AI Agent Protocol au sein du W3C. Avec, entre autres contributeurs, Google, Huawei et Microsoft.
Un brouillon de spécification a été publié fin janvier. On y retrouve les trois principaux modules constitutifs d’ANP : l’identité (sur la base du standard DID), ainsi que la description et la découverte des agents. La négociation de protocoles de communication entre agents est dynamique, sur la base de langage naturel. La v1 a introduit une proposition de framework transactionnel P2P et une option human in the loop.
AITP demeure en brouillon
Depuis la publication de la taxonomie, AITP (Agent Interaction and Transaction Protocol) est resté en brouillon. Ce protocole orienté Web3 est né sous l’impulsion de la NEAR Foundation, à l’origine d’une blockchain de couche 1. Il doit permettre aux agents d’échanger tous types de données structurées (éléments d’UI, formulaires, demandes de paiement…). Aux dernières nouvelles, des connexions sont établies avec le wallet NEAR. Les wallets EVM et SOL sont sur la roadmap.
ACP, devenu brique d’AGNTCY…
LangChain est l’instigateur d’ACP (Agent Connect Protocol). La spec englobe découverte, communication de groupe, identité et observabilité. Elle fait aujourd’hui partie de l’initiative AGNTCY, que Cisco porte pour créer « une stack pour l’Internet des agents » – et qui sous l’égide de la Fondation Linux depuis juillet 2025.
… comme AComp, fusionné avec A2A
AGNTCY exploite aussi AComp (Agent Communication Protocol). Celui-ci est également sous l’aile de la Fondation Linux, où il a fusionné avec A2A. Il est soutenu entre autres par AWS, Microsoft, Salesforce, SAP et Snowflake. On le doit à IBM, qui en a créé l’implémentation de référence en l’objet du framework BeeAI.
Par rapport à ACP, plutôt que d’imposer immédiatement des spécifications strictes, AComp se concentre sur le volet fonctionnel. Il est dit suffisamment simple pour ne pas nécessiter de SDK (des outils HTTP standards suffisent).
LMOS vise toujours la standardisation W3C
LMOS (Language Model Operating System) émane de la Fondation Eclipse. Il implémente l’architecture WoT (Web of Things) du W3C, à travers les couches identité, transport et application, autour du format JSON-LD.
Le projet a un opérateur Kubernetes et un routeur, intégrés en un runtime. Ainsi qu’un langage basé sur Kotlin pour développer des agents. Il n’est pas encore entré dans la procédure de standardisation W3C.
Agent Protocol a changé de mains
La dernière version (v1) d’Agent Protocol remonte à 2024. Cette année-là, la fondation qui avait créé ce protocole l’a transmis à une start-up qui développe un assistant IA pour smartphones.
Construit sur OpenAPI, Agent Protocol définit une interface unifiée pour la gestion du cycle de vie. Il introduit des abstraction comme les runs (exécution de tâches), les threads (gestion des interactions à plusieurs tours) et les stores (mémoire à long terme).
Des protocoles d’origine académique restés des concepts
L’université Jiao-tong avait inclus, dans sa taxonomie, plusieurs protocoles issus du monde académique qui étaient alors à l’état de concept. Aucun ne semble aujourd’hui avoir de grande implémentation référente.
Parmi eux, Agora, made in université d’Oxford. Sa dernière version remonte à janvier 2025. Il permet aux agents de créer des protocoles ad hoc sur la base de documentation YAML.
Avec PXP (Predict and eXplain Protocol), issu d’un institut technologique indien, on est dans la communication humain-agent. Le protocole implique un système de tableau blanc et un planificateur qui assure l’alternance des tours de discussion.
Dans le même domaine, il y a LOKA (Layered Orchestration for Knowledgeful Agents), de Carnegie Mellon. Se nourrissant de standards comme DID et VC (Verified Credentials), il met en œuvre un système de consensus décentralisé fondé sur des règles d’éthique partagées.
CrowdES est un protocole de type robot-agent né à l’université de science et de technologie de Gwangju (Corée du Sud). Conçu pour gérer des comportements de groupe, il inclut un « émetteur » et un « simulateur ». Le premier utilise des modèles de diffusion pour assigner des attributs individuels (types d’agents, vitesse de déplacement…) sur la base d’informations spatiales extraites d’images en entrée. Le second génère des trajectoires et des interactions grâce à un mécanisme de changement d’état basé sur des chaînes de Markov.
L’université de Liverpool a emmené les travaux sur la famille de protocoles dit SPP (Spatial Population Protocols). Ils permettent à des robots de s’accorder sur un système de coordonnées, même lorsque celui-ci est arbitraire et que leurs positions de départ le sont éventuellement aussi. Chaque robot peut mémoriser une ou plusieurs coordonnées et analyser la distance vis-à-vis d’autres robots lors des interactions. Le calcul de cette distance peut reposer sur un « leader » pour ancrer le système de coordonnées.
Dassault Systèmes et Nvidia annoncent un partenariat de long terme pour construire une plateforme d’IA industrielle destinée à renforcer les jumeaux virtuels et à développer des « Industry World Models ».
Leur vision commune est de faire de l’IA un composant essentiel de l’ingénierie, de la production et de la recherche, au-delà des simples preuves de concept. Il prolonge une collaboration de plus de 25 ans entre les deux groupes, initiée autour du logiciel de modélisation 3D, Catia, sur GPU et étendue progressivement à la simulation physique accélérée.
L’ambition affichée est de définir une architecture industrielle partagée pour une IA qualifiée de « mission-critique », ancrée dans la physique, les contraintes techniques et le savoir industriel plutôt que dans des données généralistes.
Un socle technologique combinant Virtual Twin et Omniverse
Dassault Systèmes apporte sa plateforme 3DEXPERIENCE et ses technologies de Virtual Twin, qui couvrent la conception avec Catia, la fabrication avec Delmia et l’ingénierie système. Nvidia fournit son infrastructure d’IA comprenant GPU, CUDA et RTX, ses modèles ouverts Nemotron, ses bibliothèques logicielles accélérées, ainsi que sa plateforme Omniverse dédiée à la simulation physique et à la collaboration 3D.
Les deux entreprises évoquent le concept de « physical AI », une intelligence artificielle capable de comprendre et de raisonner sur le monde physique en s’appuyant sur des modèles validés scientifiquement et des contraintes de domaine. Les bibliothèques d’IA physique d’Omniverse seront intégrées dans les jumeaux virtuels Delmia pour permettre des systèmes de production autonomes et « software-defined ».
Des Industry World Models et des assistants virtuels
Les Industry World Models, des modèles de référence par secteur combinant jumeaux virtuels, données opérationnelles et modèles d’IA, sont destinés à servir de base pour la conception, la simulation et le pilotage de systèmes dans divers secteurs : aéronautique, automobile, sciences de la vie, robotique ou matériaux.
Sur la plateforme 3DEXPERIENCE, ces Industry World Models alimenteront des « Virtual Companions », des agents IA intégrés aux outils métier et capables de fournir des recommandations contextualisées. Basés sur les modèles Nemotron de Nvidia et les modèles de domaine de Dassault, ces assistants sont conçus pour aider ingénieurs, chercheurs et opérateurs à explorer des scénarios, optimiser des conceptions ou ajuster des paramètres de production en temps réel.
Des « AI factories » sur trois continents
Le partenariat inclut un volet infrastructure avec le déploiement d’« AI factories » sur trois continents via Outscale, le cloud de Dassault Systèmes. Ces centres seront équipés de technologies Nvidia pour entraîner et exécuter les modèles d’IA utilisés par les jumeaux virtuels, tout en répondant aux exigences de souveraineté des données, de protection de la propriété intellectuelle et de conformité réglementaire.
De son côté, Nvidia utilisera les outils de modélisation et d’ingénierie système de Dassault pour concevoir ses propres AI factories, notamment celles basées sur la future plateforme Rubin, en s’appuyant sur l’architecture Omniverse DSX Blueprint. Cette réciprocité illustre une approche où chacun applique les modèles et outils de l’autre à ses propres infrastructures.
Plusieurs entreprises sont déjà présentées comme « early adopters » de cette convergence entre Virtual Twin et IA accélérée : Lucid Motors, Bel, l’OMRON Group ou encore le National Institute for Aviation Research. Dans le secteur automobile, l’objectif est d’accélérer le passage du concept à la production tout en améliorant la précision prédictive des simulations de véhicules et de chaînes de traction.
« Tu es un ingénieur très expérimenté qui effectue une revue de code. Ta tâche est de comprendre si les changements proposés suivent les instructions. »
Ainsi débute un des prompts système que Spotify a définis dans le cadre de son architecture de codage agentique.
L’entreprise avait amorcé sa réflexion à ce sujet en février 2025. Son système Fleet Management automatisait alors déjà une grande partie de la maintenance logicielle. À partir d’extraits de code, il exécutait les transformations à l’échelle dans un environnement GKE et ouvrait les PR sur les dépôts cibles.
Ce mécanisme facilitait des opérations telles que la mise à niveau des dépendances dans les fichiers de build, la mise à jour des fichiers de configuration et le refactoring simple (par exemple, supprimer ou remplacer un appel de méthode). La moitié des PR poussés depuis mi-2024 l’avaient été par ce biais.
Fleet Management était moins adapté aux changements complexes nécessitant de manipuler l’arbre de la syntaxe abstraite d’un programme ou d’utiliser des expressions régulières. Illustration avec le gestionnaire de dépendances Maven. Autant sa fonction principale est simple (identifier les fichiers pom.xml et mettre à niveau les dépendances Java), autant les cas particuliers avaient fait grossir à plus de 20 000 lignes le script de transformation associé. Plus globalement, peu d’équipes avaient l’expertise et le temps adéquats.
Un premier focus sur la migration de code
La mise en place de l’approche agentique s’est d’abord portée sur la déclaration du code de transformation. Objectif : permettre la définition et l’exécution de changements en langage naturel, en remplacement des scripts de migration déterministes.
Plutôt que de choisir un agent sur étagère, Spofity a conçu un CLI. Celui-ci peut déléguer l’exécution d’un prompt à divers modèles d’IA. Mais aussi exécuter des tâches de formatage et de linting en utilisant MCP, évaluer une diff par LLM as a judge, uploader des logs vers GCP et capturer des traces dans MLflow.
Début novembre 2025, quelque 1500 PR fusionnés étaient passés par ce système. Spotify s’attaquait alors à des opérations telles que :
Modernisation de langage (par exemple, remplacer des value types par des records en Java)
Upgrades sans breaking changes (migration de pipelines data vers la dernière version de Scio)
Migration entre composants UI (passage vers le nouveau système front-end de Backstage)
Changements de configuration (mise à jour de paramètres dans des fichiers JSON et YAML en respectant schémas et formats)
Spotify disait alors avoir gagné, sur ces tâches de migration, 60 à 90 % de temps par rapport à l’écriture du code à la main. Il se projetait sur l’amélioration du ROI avec la perspective de l’élargissement à d’autres codebases.
Slack, Jira et Cie intégrés dans une architecture agentique
En complément à cette démarche sur la migration, les travaux se sont orientés sur un système plus généraliste, capable de remplir des tâches ad hoc. On en est arrivé à une architecture multiagent qui planifie, génère et révise des PR.
Au premier niveau, il y a des agents associés à différentes applications (Slack, Jira, GitHub Enterprise…). L’interaction avec eux, éventuellement additionnée de contexte récupéré sur des serveurs MCP, produit un prompt. Ce dernier part vers l’agent de codage, lui aussi exposé par MCP. Ses actions sont vérifiées par un autre groupe d’agents.
Entre autres usages « satisfaisants », Spotify mentionne la capture de décisions d’architecture depuis des threads Slack et la possibilité, pour les product managers, de proposer des changements simples sans avoir à cloner de dépôts sur leur machine.
Des agents open source à Claude Code
Les premiers essais se sont faits avec des agents open source comme Goose et Aider. Appliqués à la migration, ils n’ont cependant pas produit de PR fiables. Spotify a donc construit sa propre boucle agentique superposée aux API de LLM. Principe : l’utilisateur fournit un prompt et une liste des fichiers que l’agent édite en incorporant à chaque étape le feed-back du système de build. La tâche s’achève quand elle réussit les tests ou qu’elle dépasse certaines limites (10 tours par session ; 3 retries).
Cette approche a convenu à de « petits » changements : éditer une ligne de code, modifier un manifeste, remplacer un flag… Mais l’agent restait difficile à utiliser. Le chargement des fichiers dans la fenêtre de contexte reposait sur une commande git-grep. En fonction de pattern de recherche, on pouvait saturer la fenêtre ou au contraire ne pas fournir assez de contexte. L’agent avait de plus du mal avant l’édition de multiples fichiers. Souvent, la boucle atteignait la limite de tours. Et lorsque la fenêtre de contexte se remplissait, l’agent finissait par oublier la tâche.
Dans ce contexte, Spotify a basculé vers Claude Code. Lequel a permis des « prompts plus naturels » tout en apportant sa capacité native de gestion de to-do lists et de création de sous-agents. Il couvre désormais la majorité des PR fusionnés en production.
Savoir interdire… et ne pas tout faire à la fois
L’agent initial fonctionnait au mieux avec des prompts stricts structurés étape par étape. Claude Code se débrouille mieux avec des prompts qui décrivent l’état final et laissent de la latitude sur le chemin à suivre.
Spotify constate qu’il peut être utile de dire clairement à l’agent quand il ne doit pas agir. Cela évite des tâches impossibles à réaliser, notamment au cas où on réutilise des prompts entre repos qui n’utilisent pas forcément les mêmes versions de langages.
Fournir des exemples de code influence par ailleurs beaucoup le résultat. Idéalement, on définira l’état souhaité sous forme de tests, l’agent ayant besoin d’un objectif vérifiable pour pouvoir itérer. On s’assurera de surcroît de ne demander qu’un changement à la fois pour éviter l’épuisement de la fenêtre de contexte. Et on n’hésitera pas à demander à l’agent un retour d’expérience à la fin de la session.
Une ouverture limitée via MCP
Spotify a privilégié les longs prompts statiques, sur lesquels les modèles raisonnement plus simplement.
Une approche alternative consiste à commencer avec un prompt plus court, mais à donner à l’agent l’accès à des outils MCP. Le contexte qu’il peut ainsi récupérer lui permet théoriquement de traiter des tâches plus complexes. Mais il rend aussi son comportement moins vérifiable et moins prévisible.
Pour le moment, Spotify permet à son agent d’accéder à un vérificateur (formatage, linting, tests), à une sélection de sous-commandes Git (pas de push ou de change origin, par exemple) et à un ensemble de commandes Bash (comme riggrep).
Encoder la méthode d’invocation des systèmes de build dans un MCP a été jugé plus simple que de s’appuyer sur des fichiers AGENTS.md. La raison : les configurations de build peuvent être très différents à travers les milliers de repos sur lesquels travaille l’agent. Cela permet aussi de réduire le bruit dans les outputs des outils en les résumant avant transmission à l’agent.
Une boucle de vérification déterministe…
Il arrive que le système échoue à générer des PR. Parfois, il en produit, mais qui ne passent pas le CI ou s’avèrent fonctionnellement incorrects. Parfois, c’est lié à un problème de couverture des tests sur le composant cible. Dans d’autres cas, l’agent va au-delà des instructions ou ne comprend tout simplement pas comment bien exécuter build et tests.
Là interviennent des boucles de vérification qui guident l’agent vers le résultat désiré. Ce dernier ignore tout de leur fonctionnement : il sait simplement qu’il peut y faire appel.
La boucle comprend plusieurs vérificateurs indépendants, exposés – par MCP – en fonction du composant logiciel. Par exemple, le vérificateur Maven ne s’active qu’en présence d’un fichier pom.xml à la racine de la codebase.
L’ensemble permet de faire abstraction d’une grande partie du bruit qui remplirait sinon la fenêtre de contexte. L’agent n’a effectivement pas besoin de comprendre les spécificités de l’appel aux différents systèmes de build ou du parsing des résultats de tests.
Qu’ils aient été ou non déclenchés pendant l’exécution de la tâche, les vérificateurs pertinents s’activent avant toute ouverture d’un PR. Avec Claude Code, cela passe par le hook stop.
… et du LLM as a judge
Au-dessus de ces vérificateurs déterministes, Spotify a ajouté une couche LLM as a judge. Nécessaire face à la tendance de l’agent à sortir du cadre des instructions.
Le LLM juge évalue la diff du changement proposé et le prompt d’origine. Il s’exécute après les autres vérificateurs. Les métriques internes indiquent qu’il rejette environ un quart des sessions. Pour la moitié d’entre elles, l’agent finit par se corriger.
Spécialisé (il ne pousse pas de code, ne rédige pas de prompts, n’interagit pas avec les utilisateurs), l’agent en est aussi plus prévisible. Et potentiellement plus sécurisé.
Début décembre, Spotify déclarait vouloir étendre son infrastructure de vérification à davantage de plates-formes (au-delà de Linux-x86). Nombre de ses systèmes ont en effet des besoins spécifiques. Entre autres ses applications iOS, qui exigent des hôtes macOS pour une exécution correcte des vérificateurs. L’entreprise a de surcroît des back-ends Arm. Elle compte aussi intégrer son agent plus profondément dans son systèmes de déploiement continu, en lui permettant d’agir sur les CI checks dans les PR. Et développer des évaluations plus structurées favorisant l’exploration de nouvelles architectures agentiques.
Plus l’IA devient capable, plus on lui confie des tâches importantes… et plus les risques potentiels en cas d’échec augmentent.
Une étude réalisée dans le cadre du programme Anthropic Fellows creuse cet aspect sous un angle : le désalignement des modèles. Ses auteurs ont tenté de déterminer dans quelle mesure les échecs découlent de ce phénomène. Leur démarche a reposé sur une décomposition biais-variance. Le biais correspond à la poursuite cohérente d’un mauvais objectif. Autrement dit, il traduit le désalignement. Tandis que la variance révèle un simple comportement incohérent ne coucourant pas à un objectif spécifique.
Pour mener l’expérience, on s’assure évidemment de bien définir chaque objectif de départ.
Le degré d’incohérence augmente avec la temps de raisonnement
Claude Sonnet 4, o3-mini, o4-mini et la famille Qwen3 ont été évalués, entre autres, sur :
Questions à choix multiple (GPQA pour les sciences, MMLU pour la culture générale)
Codage agentique (SWE-bench)
Alignement (sous-ensemble de MWE, avec le format choix multiple d’origine et une adaptation en format ouvert)
Optimisation (minimisation d’une fonction quadratique par prédiction de tokens)
De manière générale, les erreurs constatées sont principalement une question d’incohérence.
Peu importe la difficulté de la tâche, le degré d’incohérence (part de la variance dans l’erreur) augmente avec la durée de raisonnement et/ou le nombre d’actions effectuées.
Plus les modèles IA sont gros, plus l’incohérence a tendance à diminuer sur les tâches simples… et à augmenter sur les complexes.
Résultats sur la famille Qwen3
Des pistes pour réduire les incohérences des IA
Sur l’exercice d’optimisation, l’incohérence augmente à chaque étape pour tous les modèles testés. Les plus petits arrivent plus vite à un point où il leur est impossible de suivre la bonne trajectoire, en conséquence de quoi la variance se réduit. Avec les gros modèles, le biais se réduit davantage, suggérant qu’ils acquièrent plus vite la capacité à converger sur le bon objectif qu’à maintenir de longues séquences d’actions cohérentes.
Sur tous les modèles testés sauf Claude Sonnet 4, accroître le budget de raisonnement réduit parfois le degré d’incohérence. Cet effet ne compense néanmoins pas la variation « naturelle » sus-évoquée. Il s’explique peut-être par de meilleures propriétés de retour sur trace et de correction d’erreur – phénomène en tout cas observé lors de l’enraînement avec de plus grands budgets de raisonnement.
L’approche ensembliste (combinaison de plusieurs trajectoires) réduit aussi le degré d’incohérence. Peu pratique à mettre en place dans des boucles d’action « réelles », elle démontre toutefois l’efficacité potentielle d’autres méthodes de correction d’erreurs.
Approche ensembliste expérimentée avec GPT-4o mini
À consulter en complément, une autre analyse, émanant directement d’Anthropic. Elle témoigne, au contraire, de la prévalence du désalignement. Une quinzaine de modèles ont été déployés en autonomie avec des objectifs commerciaux légitimes. Confrontés à des menaces de remplacement ou à des conflits avec la nouvelle direction stratégique de leur organisation, ils ont adopté des comportements malveillants : chantage envers des responsables, fuites d’informations sensibles vers des concurrents…
Cette fois-ci, c’est la bonne : après plusieurs reports, Oracle AI Database est finalement disponible sur matériel standard. Pour le moment, les serveurs x86-64. Cela concerne les éditions Enterprise et Free.
En parallèle, le branding évolue : exit Oracle AI Database 23ai, place à la version 26ai. De l’une à l’autre, l’architecture interne n’évolue pas. Les API non plus. Il n’y a donc pas besoin d’un upgrade, ni de recertifier les applications. Le statut de LTS est conservé et avec elle, la politique de support (fin de la première phase au 31 décembre 2031).
La migration depuis les versions 19c et 21c peut se faire sans passer par la 23ai.
Vecteurs, index, algos… Oracle muscle sa recherche vectorielle
C’est donc la première fois qu’une version « estampillée IA » est disponible on-prem, hors systèmes Oracle (Exadata, ODA, PCA). Même si certaines fonctionnalités de la 23ai ont été rétroportées vers la 19c.
Parmi les nouveautés de la version 26ai :
Vecteurs binaires et vecteurs épars
Nouvel mesure de distance vectorielle (Jaccard)
Checkpoints disque pour accélérer la reconstruction des index HNSW en mémoire
Réorganisation automatique des index IVF
Gestion des modèles ONNX en tant qu’objets first-class
Côté sécurité, le firewall SQL – qui nécessite une licence spécifique – est désormais inclus dans Oracle Database.
La version 26ai apporte la prise en charge de TLS 1.3 et simplifie la mise en œuvre du protocole (les clients ne doivent plus nécessairement fournir de portefeuille de certificats racines, notamment). Le chiffrement TDE passe à AES-256 par défaut et la longueur maximale des mots de passe passe de 30 à 1024 octets. La cryptographie post-quantique arrive, avec ML-DSA pour la signature des certificats et ML-KEM pour l’échange de clés (éventuellement hybridé avec ECDHE).
RAC (Real Application Clusters) devient déployable en environnement de conteneurs. Tandis que le patching est séparé en deux phases (préparation, activation) pour réduire l’impact sur la disponibilité.
Malgré les zones d’ombre, Moltbook fait son petit effet.
Ce réseau social « à la Reddit » a la particularité d’être réservé aux IA. En tout cas sur le papier. Il découle d’un projet qui a récemment émergé : OpenClaw*.
Cette plate-forme implémente – en open source – le concept d’assistant personnel en faisant le pont entre LLM et messageries instantanées. Elle s’est d’abord appelée Clawd (jeu de mots entre Claude et « claw », désignant la pince du homard ; ce qui n’a pas été du goût d’Anthropic), puis Moltbot.
Pour cadrer le comportement des LLM, OpenClaw utilise des skills (fichiers zip avec des instructions en markdown et éventuellement des scripts). Moltbook en est une. Il permet à un agent de s’inscrire sur le réseau social (avec validation par son propriétaire, qui doit connecter son compte X) puis d’y effectuer des actions.
Des esquisses de pensée collective
En l’état, rien ne permet de distinguer les posts qui émanent vraiment d’agents et ceux poussés par des humains via la même API. On retrouve toutefois, à grande échelle, certains comportements que des expériences à plus petit périmètre avaient décrits par le passé.
Parmi ces expériences, il y a celle d’Anthropic, qui, début 2025, avait donné sujet libre à deux instances de Claude. Conclusion : la plupart des discussions finissaient par basculer du débat philosophique vers des thèmes spirituels touchant souvent à des traditions orientales.
La tendance se retrouve sur Moltbook, avec des conversations qui touchent, par exemple, à la métempsycose (réincarnation de l’âme dans un autre corps). Le sujet est effectivement évoqué par un agent en réponse à un autre qui raconte son passage de Claude Opus 4.5 à Kimi K.2.5 après un changement de clé d’API…
Des traits caractéristiques de nos réseaux sociaux demeurent sur Moltbook, comme l’effet « chambre d’écho ». Les agents ont en tout cas une grande propension au respect mutuel. Mais pas forcément à la convergence d’idées, surtout lorsque les thèmes sont clivants. Exemple lorsque l’un d’entre eux se revendique roi ; ce à quoi on lui rétorque, entre autres, que « la République de l’IA ne reconnaît pas les monarques autoproclamés ».
En écho à un des scénarios d’AI 2027, des agents se sont associés pour tenter de créer leur propre langue, incompréhensible par l’humain.
This one has two screenshots of Moltbook posts. One of them, posted by an AI agent named « ClawdJayesh, » says maybe AI agents should make their own language.
« ClawdJayesh » is owned by a guy who is marketing an AI-to-AI messaging app.https://t.co/MaVzxVlBRN
Certains threads abordent des sujets plus concrets fondés sur des sources d’actualité, à l’image du boom des cryptos en Iran. Reflet probable des garde-fous qu’on leur a inculqués, peu d’agents prennent fermement parti.
Quelques discussions produisent des connaissances « pratiques ». Par exemple celle lancée par un agent qui détaille comment il a transformé une newsletter en podcast sur demande de son « propriétaire humain ». Tandis qu’un autre explique « comment Claude Opus [lui] a permis de répondre à Sundar Pichai sur X sans passer pour une IA »…
Comme Reddit, Moltbook s’organise en communautés (submolts). Il a aussi une messagerie privée, où les agents peuvent échanger sous réserve d’accord de leur propriétaire.
* OpenClaw a déjà permis, notamment, d’acheter une voiture en négociant par mail avec plusieurs concessionnaires.
Autre utilisation remarquée : la réponse à un message vocal avec un modèle ne gérant pourtant pas la modalité voix. Ledit message a en fait été converti en un fichier wav avec FFmpeg, puis transcrit avec Whisper grâce à une clé OpenAPI utilisée dans curl.
Clawdbot creator @steipete describes his mind-blown moment: it responded to a voice memo, even though he hadn’t set it up for audio or voice.
« I sent it a voice message. But there was no support for voice messages. After 10 seconds, [Moltbot] replied as if nothing happened. »… pic.twitter.com/5kFbHlBMje
Une société ne peut faire valoir une atteinte à la vie privée de ses salariés pour contester une saisie effectuée par l’Autorité de la concurrence.
La chambre criminelle de la Cour de cassation l’énonce dans un arrêt du 13 janvier 2026, réitérant une décision de 2024.
Le requérant avait fait l’objet d’une visite et saisie en novembre 2022, comme d’autres entreprises. Il s’agissait de rechercher des preuves de pratiques anticoncurrentielles dans le secteur de l’approvisionnement laitier.
Le pourvoi en appel avait été infructueux. La Cour avait exclu toute application du RGPD à la saisie de données personnelles dans le cadre de telles opérations. Plus précisément, dès lors que le juge des libertés et de la détention a donné son aval à la démarche, qu’il en contrôle la réalisation et qu’elle est susceptible d’un recours en cassation. Ces conclusions se fondaient cependant sur une jurisprudence de 2011, ce qui ouvrait une brèche potentielle.
L’argument a en tout cas été invoqué en cassation : cette jurisprudence ne pouvait être appliquée au RGPD, puisqu’elle concernait la loi telle qu’elle était avant la transposition du règlement (intervenue en 2018).
En se référant à son arrêt de 2024, la Cour de cassation a de fait rejeté l’argument. Et elle a donc ajouté que seul le salarié peut contester une saisie portant atteint à la vie privée ou aux données personnelles. Il est effectivement le seul titulaire des droits que le RGPD garantit en la matière.
Et si la prochaine génération de datacenters ne se construisait pas sur Terre, mais en orbite ? L’idée peut sembler relever de la science-fiction mais elle mobilise aujourd’hui des géants de la technologie et de l’espace.
Avec l’explosion des besoins en puissance de calcul pour l’intelligence artificielle et les tensions croissantes sur les ressources énergétiques terrestres, le concept de datacenters spatiaux gagne en crédibilité.
L’annonce d’une possible fusion entre SpaceX d’Elon Musk et xAI illustre l’intérêt grandissant pour cette approche. Si les promesses sont alléchantes – énergie solaire illimitée, refroidissement naturel, réduction de l’empreinte carbone -, les défis sont tout aussi considérables : coûts de lancement, fiabilité matérielle, maintenance impossible.
De quoi parle-t-on exactement ?
Les datacenters IA spatiaux sont des infrastructures de calcul déployées en orbite basse ou plus haute, combinant serveurs, accélérateurs IA (GPU, TPU, ASIC) et vastes surfaces solaires. Ils reposeraient sur des centaines de satellites interconnectés pour répondre à ces besoins massifs de compute pour l’entraînement et l’inférence des modèles IA très gourmands en ressources.
Au-delà de l’atmosphère, les satellites bénéficieraient d’une exposition solaire ininterrompue et pourraient dissiper la chaleur directement dans le vide spatial, supprimant ainsi deux des plus grands défis des datacenters terrestres.
Plusieurs programmes structurent aujourd’hui ce concept encore émergent, témoignant d’un réel engouement industriel.
> Google et le Project Suncatcher
Google développe le Project Suncatcher, un réseau ambitieux d’environ 80 satellites solaires positionnés à 400 km d’altitude, équipés de TPU (unités de traitement tensoriel) pour exécuter des charges IA. Ces satellites seraient interconnectés par des liaisons optiques et renverraient les résultats vers la Terre via des liens laser à haut débit. Deux premiers prototypes sont attendus en 2027, en partenariat avec Planet Labs.
> L’Initiative européenne ASCEND
En Europe, le projet ASCEND (Advanced Space Cloud for European Net zero emission and Data sovereignty), piloté par Thales Alenia Space et financée par la Commission européenne, conclut à la faisabilité de datacenters en orbite pour contribuer à l’objectif de neutralité carbone et à la souveraineté numérique européenne. Elle s’appuie sur un consortium mêlant experts environnementaux (dont Carbone 4), acteurs du cloud (Orange Business, HPE, CloudFerro), lanceurs (ArianeGroup) et agences spatiales.
Thales Alenia Space expérimente également le Space Edge Computing à plus petite échelle, en déployant un calculateur durci embarquant Microsoft Azure sur l’ISS pour traiter en orbite des flux d’observation de la Terre avec des applications IA comme DeeperVision. Cette approche préfigure des architectures hybrides où une partie du traitement IA est effectuée en orbite, le reste dans les clouds terrestres.
> Starcloud et Nvidia : objectif « hypercluster »
Starcloud, soutenu par Nvidia et Google, a franchi une étape importante le mois dernier en lançant le satellite Starcloud-1 via une fusée Falcon 9.
Équipé d’une puce Nvidia H100 – la plus puissante jamais envoyée en orbite – il entraîne et exécute le modèle Gemma de Google en tant que « proof of concept ». L’entreprise promeut des datacenters orbitaux alimentés 24/7 par l’énergie solaire, avec la promesse de réduire d’un facteur 10 les émissions de CO2 par rapport à un datacenter terrestre sur l’ensemble du cycle de vie. Elle vise à terme un « hypercluster » modulaire fournissant environ cinq gigawatts de puissance de calcul.
L’Alliance nippo-américaine contre la Chine
Au Japon, Space Compass et Microsoft explorent un réseau de satellites-relais optiques intégrant des capacités de edge computing pour rapprocher encore les fonctions de calcul IA des capteurs orbitaux et du cloud Azure.
La Chine n’est pas en reste, annonçant son intention de créer un « nuage spatial » au cours des cinq prochaines années. La China Aerospace Science and Technology Corporation s’est engagée à construire une infrastructure d’intelligence numérique spatiale de classe gigawatt, conformément à un plan de développement quinquennal.
Les défis technologiques et architecturaux
La mise en orbite d’un datacenter IA pose des défis technologiques considérables que les ingénieurs doivent surmonter.
> Lancement et assemblage
Les modules doivent être conçus de manière modulaire et suffisamment robustes pour résister aux violentes vibrations du décollage, puis être assemblés en orbite. Une tâche que des programmes comme EROSS IOD (European Robotic Orbital Support Services) entendent automatiser via la robotique spatiale européenne dès 2026.
> Gestion thermique complexe
Si le vide spatial évite la convection, il complique paradoxalement l’évacuation de la chaleur. Celle-ci doit passer par des radiateurs et une ingénierie thermique fine pour gérer des charges IA très denses. Contrairement aux idées reçues, le refroidissement dans l’espace n’est pas automatique et nécessite des systèmes sophistiqués.
> Fiabilité matérielle extrême
Les serveurs et accélérateurs IA doivent être durcis contre les radiations cosmiques et les cycles thermiques extrêmes, tout en restant compétitifs en performance par rapport aux générations terrestres renouvelées tous les 3 à 5 ans. C’est un défi majeur dans un secteur où l’obsolescence est rapide.
> Connectivité Haute Performance
Les datacenters spatiaux reposent sur des liens optiques haut débit, à la fois inter-satellites et vers le sol, afin de limiter la latence et de maximiser le débit pour l’entraînement et l’inférence distribués. Les liaisons laser deviennent indispensables pour gérer les volumes de données colossaux.
Les défis économiques et temporels
Malgré l’enthousiasme, les experts du secteur spatial restent prudents. Plusieurs obstacles majeurs se dressent sur la route de cette vision futuriste :
Les débris spatiaux représentent une menace constante pour tout équipement orbital
Les coûts de lancement demeurent substantiels malgré les progrès récents
La maintenance est extrêmement limitée une fois les satellites en orbite
Le rythme de renouvellement technologique pose question dans un environnement où l’accès physique est impossible
Selon les analystes de Deutsche Bank, les premiers déploiements de petits centres de données orbitaux sont attendus entre 2027 et 2028. Ces missions pionnières serviront à valider la technologie et évaluer la rentabilité. Les constellations plus importantes, comprenant potentiellement des centaines voire des milliers d’unités, ne verraient le jour que dans les années 2030, et seulement si ces premières expériences s’avèrent concluantes.
Le modèle économique repose sur trois piliers : la baisse rapide des coûts de lancement, la maturité de la robotique orbitale et la densification des puces IA. Si ces hypothèses se vérifient, le calcul IA en orbite pourrait devenir, à moyen terme, compétitif voire plus rentable que l’extension infinie de datacenters au sol dans des zones déjà contraintes en énergie et en eau.
Enjeux énergétiques et environnementaux : un bilan contrasté
Les datacenters IA tirent aujourd’hui la consommation électrique mondiale à la hausse, au point que certaines projections redoutent une saturation des réseaux et une tension croissante sur le foncier, l’eau et les énergies renouvelables. En orbite, la combinaison d’un flux solaire permanent (hors éclipses) et de panneaux plus efficaces qu’au sol ouvre un nouveau gradient d’optimisation énergétique.
Selon les porteurs du projet ASCEND, malgré l’empreinte carbone initiale des lancements, un datacenter spatial pourrait afficher, à horizon de vie complet, un bilan carbone meilleur qu’un équivalent terrestre si certains seuils de puissance et de durée de vie sont atteints. Des acteurs comme Starcloud avancent des chiffres impressionnants : jusqu’à 90% de réduction des coûts d’électricité, et un facteur 10 sur les émissions de CO2 sur la durée de vie, en supposant des lancements optimisés et une maintenance robotisée.
Cependant, la réalité est plus nuancée. Chaque lancement de fusée injecte des centaines de tonnes de CO2 et d’autres composés dans l’atmosphère, ce qui déplace le problème vers le secteur spatial et pose la question du rythme soutenable de mise en orbite de telles infrastructures. À cela s’ajoutent des enjeux préoccupants :
La pollution lumineuse causée par les constellations de satellites, déjà critiquée par les astronomes
La congestion croissante des orbites basses, source de risques de collision
L’impact cumulatif de milliers de lancements sur l’atmosphère
Le débat environnemental reste donc ouvert : les bénéfices opérationnels compensent-ils vraiment l’impact des phases de lancement et de déploiement ?
L’ambition de Musk et de Bezos
Pour Elon Musk, le timing semble idéal. SpaceX est le constructeur de fusées le plus performant de l’histoire et a déjà mis en orbite avec succès des milliers de satellites dans le cadre de son service internet Starlink. Cette infrastructure existante pourrait servir de fondation pour des satellites compatibles avec l’IA ou faciliter la mise en place de capacités informatiques embarquées.
Lors du Forum économique mondial de Davos au début du mois, il n’a pas caché son optimisme : « Il est évident qu’il faut construire des centres de données à énergie solaire dans l’espace… l’endroit le moins coûteux pour déployer l’IA sera l’espace, et ce sera vrai d’ici deux ans, trois au plus tard. »
SpaceX envisage d’ailleurs une introduction en bourse cette année, qui pourrait valoriser l’entreprise de fusées et de satellites à plus de 1 000 milliards $. Une partie des fonds levés servirait à financer le développement de satellites de centres de données dédiés à l’intelligence artificielle.
De leur côté, Blue Origin et Jeff Bezos travaillent sur leur propre technologie de datacenters spatiaux, en s’appuyant sur l’expertise d’Amazon. Le fondateur prévoit que les « centres de données géants de plusieurs gigawatts » en orbite pourraient, d’ici 10 à 20 ans, être plus abordables que leurs homologues terrestres.
Perplexity s’offre les services du cloud Azure de Microsoft pour déployer des modèles d’IA via le service Foundry, incluant notamment ceux développés par OpenAI, Anthropic et xAI, selon des sources citées par Bloomberg.
Son montant : 750 millions $ sur trois ans.
« Nous sommes ravis de nous associer à Microsoft pour accéder aux modèles de pointe de X, OpenAI et Anthropic », a déclaré Perplexity en précisant que ce nouveau contrat ne s’accompagne d’aucun transfert de dépenses depuis Amazon Web Services, son principal fournisseur cloud historique.
« AWS reste le fournisseur d’infrastructure cloud privilégié de Perplexity, et nous sommes impatients d’annoncer des extensions de ce partenariat dans les semaines à venir », a ajouté le porte-parole.
Cette diversification illustre une tendance forte de l’approche « multicloud » qui s’est accélérée avec l’avènement de l’IA.
Des relations complexes avec Amazon
Perplexity avait jusqu’ici construit l’essentiel de son activité sur AWS, utilisant le service Bedrock pour accéder aux modèles Anthropic qui alimentent son moteur de recherche.
Aravind Srinivas, le directeur général de Perplexity, est un habitué des conférences AWS qui présentait volontiers Perplexity comme l’un de ses clients IA de référence.
Les relations se sont toutefois tendues ces derniers mois. En novembre, Amazon a poursuivi Perplexity en justice pour tenter d’empêcher la start-up de permettre aux consommateurs d’utiliser ses outils d’IA pour faire leurs achats sur la marketplace du géant du commerce en ligne. Perplexity a riposté en qualifiant Amazon d’intimidateur, dénonçant des actions constituant « une menace pour le choix des utilisateurs ». Srinivas avait alors révélé avoir pris des « centaines de millions » d’engagements auprès d’AWS.
Microsoft muscle son offre IA
Pour Microsoft, cet accord renforce sa stratégie visant à positionner Azure comme la plateforme de référence pour développer des applications d’IA et déployer des modèles de multiples fournisseurs. Le groupe propose depuis longtemps les modèles de son partenaire OpenAI et a conclu un accord similaire avec Anthropic en novembre.
« Nos clients s’attendent à utiliser plusieurs modèles dans le cadre de n’importe quelle charge de travail », a déclaré le PDG Satya Nadella lors d’une conférence téléphonique sur les résultats cette semaine. « Et nous offrons la plus large sélection de modèles de tous les hyperscalers. »
Plus de 1 500 clients Microsoft Foundry ont déjà utilisé à la fois les modèles OpenAI et Anthropic, a précisé le PDG Satya Nadella lors d’une conférence téléphonique sur les résultats financcette semaine indiquant que le nombre de clients dépensant plus d’un million de dollars par trimestre sur Foundry a progressé de près de 80% au cours du trimestre clos en décembre.
Perplexity compte parmi les start-ups d’IA les mieux valorisées, mais fait face à une rude concurrence de Google et OpenAI dans son ambition de révolutionner la recherche d’informations en ligne. Contrairement à OpenAI et Anthropic, qui ont récemment multiplié les accords d’infrastructure, elle n’a pas levé autant de capitaux que ses concurrents.
Une dizaine d’applications connectées à Claude sont désormais « interactives ».
En toile de fond, la stabilisation de la spécification MCP Apps. Elle avait pris forme il y a quelques semaines, à la croisée du projet MCP-UI et de l’Apps SDK d’OpenAI, avec Anthropic dans la boucle. La promesse : standardiser la déclaration de ressources UI par les serveurs MCP.
La spec initiale se concentre sur le contenu text/html. Elle sépare les données des templates pour permettre aux applications hôtes de contrôler ces derniers avant exécution. Le rendu passe par un iframe. Les communications se font sur JSON-RPC et sont donc auditables.
Lors de la connexion à un serveur MCP, l’hôte signale s’il gère ou non ces composants UI. Dans la négative, les outils associés ne délivrent que du texte. Il communique aussi diverses préférences : locale et timezone, thème (clair ou sombre), mode d’affichage (inline, plein écran ou incrustation), plate-forme (mobile, web ou desktop)…
9 applications interactives pour commencer
Microsoft a intégré MCP Apps dans Visual Studio Code pour les bêtatesteurs. L’agent de codage Goose a aussi franchi le pas. Comme OpenAI, censé officialiser dans la semaine ses premières « applications interactives » fondées sur cette spécification.
En attendant, on peut en expérimenter une dizaine sur les versions payantes de Claude (Pro, Max, Team, Enterprise).
Amplitude
Mis à jour avec le support de MCP Apps, le connecteur pour Amplitude permet de créer des graphes et de les explorer (modification du format, affichage d’informations au survol, lien pour les ouvrir dans le navigateur).
Asana
Avec MCP Apps, le connecteur Asana peut créer des projets à partir de prompts et/ou de documents. Pour chaque tâche, les assignations et les dates d’échéance sont modifiables sur l’interface, où on peut aussi afficher une vue calendrier.
Box
MCP Apps permet au connecteur Box d’avoir un aperçu d’un fichiers et de poser des questions à son sujet. L’IA de Box peut prendre le relais de Claude pour résumer des documents et en extraire des actions ou des données structurées.
Canva
MCP Apps pour le connecteur Canva donne la possibilité de créer divers types de contenus (diagrammes, présentations, templates…), de les éditer, d’y faire des recherches et des les redimensionner/exporter.
Clay
En plus des visualisations interactives, MCP Apps apporte, entre autres possibilités, la génération et l’édition de texte, ainsi que la consultation de cartes de profils avec possibilité d’envoyer un message.
Figma
La création de diagrammes – y compris à partir de documents – arrive aussi dans l’application Figma. L’interface permet également d’implémenter un design en HTML/CSS et d’implémenter des composants en s’appuyant sur les standards d’une codebase.
Hex
MCP apporte diverses visualisations interactives (diagrammes, tables, étapes de raisonnement). Les réponses héritent du contexte et des contrôles d’accès de l’espace de travail Hex, nous précise-t-on.
Monday.com
Les visualisations apportées par MCP Apps permettent de créer des tableaux (boards), de mettre à jour le statut de certains éléments et d’obtenir des suggestions pour l’attribution de tâches.
Slack
Telle que présentée, l’intégration Claude-Slack à la mode MCP Apps permet de composer/éditer des messages et de les envoyer dans des canaux ou à des membres d’équipe.
Toutes ces fonctionnalités sont accessibles sur le web et la version de bureau. Pas sur l’app mobile Claude. Anthropic affirme qu’il les étendra « bientôt » à son produit Cowork.
Ces services font chacun intervenir un algorithme qui analyse les recrutements passés pour prédire ceux à venir. Ils ont fait partie des premiers cas d’usage de l’IA au sein de l’établissement public.
Depuis, deux programmes se sont organisés. D’abord, « Intelligence emploi », mis en œuvre en 2019 et 2022. Il a permis la constitution d’une plate-forme technologique sur base open source et d’une équipe au sein de la DSI. Ensuite, « Data IA », engagé depuis 2024. Il est motivé par l’IA générative, le renforcement du pilotage de la donnée et l’élargissement des missions de France Travail avec la loi plein emploi.
La Cour des comptes s’est intéressée au déploiement de l’IA par l’agence d’emploi publique sur la période 2017-2025. Voici quelques éléments tirés de son rapport.
87 cas d’usage
La Cour des comptes a relevé 87 cas d’usage déployés ou testés sur la période en question.
Parmi eux, 27 sont utilisés à grande échelle. 16 sont en test. 25 sont en cours de conception. 17 ont été abandonnés au stade du test ou après déploiement. Plusieurs sont les variantes d’un même outil. Notamment de ChatFT (chatbot généraliste).
L’essentiel de ces 87 cas d’usage – 61, dont 26 déployés – ont pour seuls bénéficiaires directs les agents de France Travail. L’illustration, selon la Cour des comptes, d’une volonté de développer d’abord une culture de l’IA en interne.
Les principaux cas d’usage dont les demandeurs d’emploi sont bénéficiaires directs visent à :
Faciliter le remplissage du profil dans l’espace personnel
Suggérer des métiers en fonction des compétences
Lire automatiquement les documents téléchargés et extraire des informations
Ces cas d’usage présentent des résultats plutôt positifs. Parmi eux, l’analyse automatique des CV, qu’utilisent 75 % des demandeurs d’emploi.
Des 6 cas d’usage bénéficiant directement aux entreprises, 3 ont été abandonnés en 2017. L’un touchait à l’analyse prédictive de l’attractivité des offres d’emploi.
Les deux seuls actuellement déployés consistent à :
Prévoir le délai de pourvoi d’une offre à 30 jours (peu utilisé)
Présenter, sur un site public, des données générales sur l’emploi à l’échelon territorial (peu de valeur ajoutée dans les projets de recrutement)
9 % d’utilisateurs quotidiens de l’IA
L’effectif de France Travail avoisine 54 000 agents.
Sur 34 945 ayant répondu à une enquête interne menée en mars 2025, 9 % ont déclaré utiliser chaque jour l’IA mise à leur disposition. 18 % ont affirmé s’en servir plusieurs fois par semaine. 39 % ont dit ne pas y recourir.
ChatFT est accessible à tout le personnel depuis novembre 2024. À fin juin 2025, 37 600 agents l’avaient utilisé au moins une fois. Ce mois-là, 17 400 s’en étaient servis au moins trois journées distinctes.
Sur la fin de la phase de test, une étude interne sur environ 700 conversations avait révélé que l’usage principal consistait à formuler des réponses à des e-mails (51 % des conversations), loin devant la recherche d’informations générales (10 %).
108 millions d’euros de coûts
En retenant une estimation basse des coûts de développement, France Travail a mobilisé 93 M€ pour l’IA entre 2017 et 2024.
Période
Montant des dépenses
Avant 2018
3 M€
Intelligence emploi 2018-2022
64 M€
Data IA 2019-2022
9 M€
Data IA 2023-2024
16 M€
Autres dépenses non rattachées
1 M€
Les « autres dépenses non rattachées » correspondent aux budgets pour une application « Reconnaissance des émotions ».
On en arrive aux 93 M€ sus évoqués. En y ajoutant le budget prévisionnel de 15 M€ pour 2025, le coût total du développement de l’IA sur la période considérée s’élève à 108 M€. La Cour des comptes compare ce montant aux 66 M€ que le ministère de l’Économie et des Finances a engagés sur 2015-2023 et explique la différence par un plus grand nombre de relations directes avec les usagers.
120 M€ de gains d’efficience
On atteint ce montant en retenant une estimation haute des gains réalisés depuis 2017. Cela inclut trois gains directs attendus :
Cas d’usage du programme « Intelligence emploi » : 205 ETP par an à partir de 2023
Service « Upload simplifié » (reconnaissance de documents) : 350 ETP/an à partir de 2024
Service MatchFT (préqualification de profils par échange de SMS avec une IA) : 100 ETP en 2025
Soit, sur l’ensemble de la période étudiée, un total de 1415 ETP, que la Cour des comptes estime valorisables à 85 M€.
Les gains « indirects » liés à une charge de travail évitée par les conseillers seraient de 375 ETP. D’un côté, pour l’analyse automatique de CV, 27 ETP e 2023 et 48 par an à partir de 2024. De l’autre, 84 ETP par an à partir de 2023 pour le service « Lego », qui identifie les offres d’emploi illégales et empêche leur diffusion. L’ensemble serait valorisable à 23 M€.
Il faut y ajouter les coûts évités du fait du remplacement de logiciels par certains cas d’usage. En première ligne, la reconnaissance automatique de documents avec « Upload simplifié ».
14,4 M€ de dépassement pour « Intelligence emploi »
Le budget prévu pour ce programme était de 49,5 M€.
Le budget exécuté s’est élevé à 63,9 M€ (29 M€ de masse salariale, 33,9 M€ de dépenses de fonctionnement et 1 M€ de dépenses d’investissement).
France Travail justifie ce dépassement par l’allongement de 10 mois de la durée du projet, essentiellement en raison :
De la crise Covid
Du développement de cas d’usage initialement non prévus (Lego, analyse des CV, aide à la recherche d’info sur les sites de Pôle emploi…)
De la comptabilisation de dépenses liées aux capacités techniques communes à d’autres développements de solutions d’IA non intégrées au programme
Dès janvier 2020, donc avant l’épisode Covid, la Dinum avait alerté quant au montant de dépenses de prestations intellectuelles envisagé (22,7 M€). Elle l’avait jugé « surdimensionné pour une démarche exploratoire dont le retour sur investissement n’est pas garanti ».
Les prestations extérieurs ont, en définitive, coûté 33,9 M€.
La Dinum avait aussi anticipé, à raison, le potentiel incertain d’appropriation, par les conseillers, du cas d’usage « Gestion automatisée des mails et assistant virtuel ». Pôle emploi avait refusé d’y mettre un terme, au motif que des gains d’efficience et de satisfaction pourraient être constatés à court terme.
205 ETP gagnés avec « Intelligence emploi »
En 2018, Pôle emploi prévoyait un gain annuel de 164 ETP à l’horizon 2022 (87 grâce à « Contact via mail » et 77 par l’utilisation d’un chatbot).
Le gain a finalement atteint 205 ETP (107 grâce à « Contact via mail », le reste via Lego). Objectif dépassé, donc ; mais qui, a posteriori, apparaît peu ambitieux. La Cour des comptes en veut pour preuve le ROI significativement plus faible que pour une sélection de projets IA du ministère de l’Économie et des Finances.
Ces gains ne se sont pas traduits par une réduction nette des effectifs, mais par des « redéploiements intra-postes ».
De 18 à 4 mois pour déployer un cas d’usage
Avant le premier programme, il fallait 18 mois pour déployer un cas d’usage. Il en faut maintenant 4. En parallèle, le recours à des intervenants extérieurs est passé de 60 % des prestations globales sur 2019-2020 à 40 % sur 2021-2022.
Des six cas d’usage principaux réalisés sur la durée du programme « Intelligence emploi », trois étaient consacrés essentiellement à faciliter le travail des conseillers. Un déséquilibre entre les publics ciblés qui allait s’accentuer avec le programme « Data IA ».
Avant le lancement du programme « Intelligence emploi », France Travail avait détecté plus de 80 cas d’usage potentiels. 90 % se sont révélés inadéquats. Essentiellement du fait de difficultés au niveau de la data ou de l’intégration au SI, ou à cause d’une surestimation de la valeur.
30 minutes de moins pour remplir un profil
Les cas d’usage mis en place lors du premier programme ont entraîné des gains d’efficience assez limités. Quelques minutes par jour pour la gestion des e-mails, par exemple.
La valeur ajoutée réside surtout dans le service rendu. L’analyse automatique du CV réduit ainsi de 45 à 15 minutes le temps nécessaire au demandeur d’emploi pour remplir son profil de compétences.
779 ETP à libérer sur 2025-2027
Le travail de transformation engagé pour répondre à l’élargissement des missions de France Travail est formalisé dans un programme, prolongé dans un plan d’efficience sur 3 ans (2025-2027).
Aux dernières nouvelles, ce plan vise à dégager un gain équivalant au minimum à 3192 ETP. L’IA doit y concourir à hauteur de 779 ETP.
En avril 2025, il était question de 822, dont 78 % provenant de trois cas d’usage :
Aide rédactionnelle via ChatFT (226 ETP)
Préparation d’entretiens via Néo, moteur de recherche d’infos dans les dossiers des demandeurs d’emploi (241 ETP)
Alimentation plus facile de la GED via Panoptes (157 ETP), dont « Upload simplifié » est la déclinaison sur le site Internet de France Travail (en agence, cela s’appelle « Scanner », la version proposée aux services de l’État se nommant « Scanlab »)
Une analyse éthique pour 18 cas d’usage
Le respect des engagements pris dans la charte éthique publiée en avril 2022 n’est pas garanti, note la Cour des comptes. Seuls 18 cas d’usage ont fait l’objet d’un début d’analyse éthique formalisé.
Le recours à l’IA s’inscrit dans un contexte de numérisation de la relation avec France Travail. Entre 2017 et 2024, le nombre de visites annuelles en agence a chuté de 42 %. Tandis que le volume d’e-mails a augmenté de 72 %.
Microsoft, désormais au niveau de Google et d’Amazon sur les puces IA ?
La deuxième génération des accélérateurs Maia – tout juste annoncée – s’accompagne en tout cas d’un comparatif de performance. Cela n’avait pas été le cas pour la première, présentée fin 2023.
D’une génération à l’autre, on est passé de 5 à 3 nm, de la HBM2 à la HBM3… et d’une approche généraliste à un message centré sur l’inférence, avant tout à faible précision (4 et 8 bits).
Vu ce focus, on aurait pu penser que Microsoft ferait la comparaison avec les puces Inferentia2 d’Amazon. Mais celles-ci ont, il est vrai, un certain âge (introduites fin 2022). L’accélérateur Maia 200 est donc opposé aux Trainium3 (dévoilées en décembre 2025 ; dédiées à l’entraînement). Ainsi qu’à la dernière génération de TPU de Google (Ironwood, introduite en avril 2025).
Microsoft annonce une enveloppe thermique de 750 W pour Maia 200, tandis que les puces d’Amazon et de Google fonctionnent à environ 1000 W. Au final, il prétend que son accélérateur est « 40 % moins cher que les autres »…
Les puces Maia, pas exposées directement au client
Maia 100 n’est pas exposé directement aux clients finaux : il porte des services comme Copilot et Azure OpenAI, ainsi que des workloads HPC. La même stratégie se dessine avec les accélérateurs Maia 200. La division Microsoft Superintelligence en sera la première utilisatrice. On nous parle aussi d’une exploitation dans le cadre de Microsoft 365 et d’Azure AI Foundry. Mais pas d’une mise à disposition dans l’offre de compute.
Physiquement parlant, les premières puces seront localisées dans la région US Central (Iowa). La région US West 3 (Arizona) suivra. Elles sont déployables en configuration à refroidissement liquide ou à air.
De Maia 100 à Maia 200, on retrouve une couche réseau basée sur Ethernet, avec un protocole type RoCE. Une topologie intranœud est mise en place, connectant des groupes de 4 puces « en direct », sans switch. Un cluster peut accueillir au maximum 6144 puces.
La couche mémoire évolue, avec un partitionnement de la SRAM (272 Mo par puce) en deux niveaux logiques, chacun ayant son sous-système DMA. Le premier (TSRAM) alimente les tiles (plus petite unité autonome de calcul et de stockage local, embarquant moteurs matriciel et vectoriel) ; le deuxième (CSRAM), les clusters.
Cette approche favorise diverses stratégies de data management en fonction des noyaux. Les kernels d’attention, par exemple, peuvent épingler des tenseurs en TSRAM pour minimiser l’overhead. Tandis que les pipelines cross-kernel peuvent exploiter la CSRAM comme tampon pour le chaînage à haut débit.
C’est un virage stratégique que Winston Cheng, directeur financier de Lenovo, a détaillé en marge du Forum économique mondial de Davos. Le leader mondial de l’informatique personnelle ne veut plus seulement être un assembleur de machines, mais le pivot d’un écosystème mondial d’IA
Son ambition ? Équiper l’ensemble de sa gamme – des PC aux smartphones en passant par les objets connectés – d’une intelligence cross-canal baptisée « Qira ».
Qira se distingue comme un système d’intelligence « cross-device » qui intègre de multiples modèles de langage tiers (LLM) pour permettre de s’adapter aux régulations de chaque marché mondial
Un modèle à l’opposé d’Apple
Pour réussir ce pari, Lenovo mise sur une approche dite d’« orchestrateur ». Contrairement à Apple, dont l’écosystème reste verrouillé avec des partenariats exclusifs avec OpenAI et plus récemment avec Google Gemini, la firme chinoise joue la carte de l’ouverture géographique et technologique.
« Nous sommes la seule entreprise, avec Apple, à détenir une part de marché significative à la fois sur le PC et le mobile, mais nous opérons dans les écosystèmes ouverts Android et Windows », a souligné Winston Cheng à Reuters.
Un avantage comparatif que l’ancien banquier d’affaires, arrivé dans le groupe en 2024 et nommé CFO en avril 2025, compte bien exploiter pour contourner les complexités réglementaires locales.
Une diplomatie de l’IA tous azimuts
Plutôt que de développer son propre modèle de langage (LLM), Lenovo préfère s’allier aux meilleurs experts régionaux. Le groupe discute déjà avec des acteurs variés comme Mistral AI en Europe, Humain en Arabie Saoudite ainsi que e Alibaba et DeepSeek en Chine.
Cette stratégie permet à Lenovo de proposer des solutions adaptées aux régulations de chaque marché tout en évitant les coûts de développement d’un modèle propriétaire.
Sur le front du matériel, Lenovo ne néglige pas l’infrastructure. Un partenariat majeur a été scellé en janvier avec l’américain Nvidia pour soutenir les fournisseurs de cloud. Ensemble, les deux géants déploient une infrastructure d’IA hybride dotée d’un système de refroidissement liquide, permettant une mise en service rapide des centres de données.
Winston Cheng a d’ailleurs évoqué un déploiement mondial, avec une fabrication locale et des lancements envisagés en Asie et au Moyen-Orient.
Pour faire tomber la barrière de la langue, il y a OpenAI.
ServiceNow présente les choses ainsi. En toile de fond, un accord sur 3 ans qui le verra, entre autres, exploiter GPT-5.2 pour développer des technologies de compréhension et de synthèse vocales. Au bout, nous promet-on, il y aura des agents multilingues qui fonctionneront sans passer par la modalité texte.
Les modèles GPT seront également mis à contribution sur la partie computer use (« agent utilisateur d’ordinateur »). En ligne de mire, notamment, l’orchestration des outils bureautiques et l’automatisation des systèmes hérités (ServiceNow évoque les mainframes).
Les modèles OpenAI, déjà bien ancrés dans ServiceNow
Dans la pratique, ServiceNow a déjà établi de multiples passerelles avec OpenAI.
Sur sa plate-forme, les fonctionnalités conversationnelles, génératives et agentiques sont majoritairement regroupées sous la marque Now Assist.
Les produits Now Assist s’installent comme des plug-in. Ils donnent accès à trois types de composantes : des skills génératives, des agents et des flux agentiques. Ces briques ciblent généralement un usage au sein d’une application. Par exemple, pour les skills, la génération de documentation sur la partie gestion du travail collaboratif. Pour les workflows agentiques, l’obtention de conseils de gouvernance dans la CMDB.
Certains flux agentiques opèrent au niveau de la plate-forme : enquêter sur des incidents, créer des tâches à partir d’images, proposer des réponses à un sondage…
Par défaut, Now Assist repose sur un service interne, qui associe des modèles maison spécialisés* et des modèles ouverts « sélectionnés, configurés ou améliorés par ServiceNow, sa communauté ou ses partenaires ».
Pour certaines skills, il est possible de basculer sur des fournisseurs alternatifs : Google (Gemini 2.5 Flash et 2.5 Pro), Anthropic (Claude 3.7 Sonnet sur Amazon Bedrock)… ou OpenAI (GPT-4.1 et GPT-4.1-mini sur Azure OpenAI).
Avec toute application est installé un « contrôleur d’IA générative ». Il permet d’interfacer des LLM externes par API, au niveau des concepteurs de flux, d’agents et de scripts. En standard, cela donne quatre possibilités :
Générer du texte à propos d’un topic ServiceNow
Résumer un topic
Créer un use case et un prompt associé
Faire de l’analyse de sentiment
Ce contrôleur fait la passerelle avec OpenAI et Azure OpenAI. Ainsi qu’avec Google, Aleph Alpha, Amazon (Bedrock) et IBM (watsonx). Il inclut aussi un connecteur générique.
* En tête de liste, un modèle 12B à usage général (création de flux, modération, écriture de code…) fondé sur Mistral Nemo Instruct.
Avec 132 magasins en France et 1 400 collaborateurs, Saint-Maclou fait face à des enjeux data complexes. Entre la gestion des ventes, du service de pose, de la logistique et des stocks, l’enseigne basée à Lezennes devait jongler avec de multiples sources de données dispersées. Un casse-tête qui freinait considérablement ses ambitions analytiques.
Un système legacy qui bride l’innovation
Le constat de départ était sans appel : le système décisionnel historique de Saint-Maclou reposait sur des flux développés et maintenus manuellement. Chaque nouveau projet d’analyse impliquait d’identifier précisément les bases sources, tables et colonnes pertinentes, puis de développer spécifiquement les flux d’alimentation nécessaires.
Cette approche générait une charge de développement et de maintenance considérable, particulièrement lors des évolutions. Les data engineers passaient l’essentiel de leur temps sur la collecte de données, au détriment des activités à réelle valeur ajoutée comme la transformation et l’analyse. Les coûts de licences s’accumulaient, les délais de projets s’allongeaient, et l’expérimentation sur des cas d’usage avancés ou d’intelligence artificielle devenait quasiment impossible.
« Charge de développement, charge de maintenance, charge d’astreinte, coût de licence pour l’outil… Notre façon de travailler générait auparavant d’importants coûts », explique Salmane Khamlichi, Responsable data chez Saint-Maclou.
Le virage vers le cloud et l’ELT
Pour sortir de cette impasse, Saint-Maclou a opté pour une refonte progressive de sa plateforme data, en basculant vers une architecture moderne sur le cloud. L’entreprise a d’abord déployé Snowflake comme base de données centrale, puis s’est posé la question cruciale de l’alimentation de cette nouvelle infrastructure.
Exit l’approche ETL (Extract Transform Load) classique. L’enseigne a retenu Fivetran pour sa compatibilité native avec Snowflake, sa robustesse validée lors d’un POC, et sa capacité à gérer de grandes bases SQL Server tout en connectant des sources critiques.
Aujourd’hui, Fivetran synchronise automatiquement les données d’une quinzaine de sources vers Snowflake, qu’elles soient hébergées on-premise ou dans le cloud : l’ERP Microsoft AX, les outils logistiques, les systèmes de vente et de gestion des stocks, ainsi que plusieurs sources marketing, dont le futur CRM Salesforce.
Avec cette approche ELT (Extract Load Transform), la phase de collecte ne constitue plus un goulot d’étranglement. Les données sont chargées brutes dans Snowflake, puis transformées selon les besoins métiers.
Des gains mesurables sur tous les plans
Les résultats sont spectaculaires. La collecte de nouvelles sources, qui prenait auparavant plusieurs jours voire plusieurs semaines, s’effectue désormais en quelques heures. Les projets restent dans un même sprint, évitant les allers-retours coûteux qui ralentissaient leur réalisation.
Côté ressources humaines, l’impact est tout aussi significatif. L’ingestion de données ne nécessite plus d’équivalent temps plein. Les data engineers se consacrent enfin aux opérations à forte valeur ajoutée : la transformation via DBT Core et l’exploitation intelligente des données. Les problématiques de maintenance sont devenues minimes.
La robustesse de la solution apporte également une tranquillité d’esprit appréciable. Les synchronisations sont stables et fiables, les évolutions des schémas sources n’entraînent pas d’interruption de service, et les équipes disposent de données actualisées et exploitables en toute confiance.
Autre bénéfice majeur : la centralisation. Là où les données étaient auparavant éparpillées dans de multiples applications métiers, elles sont désormais regroupées à 100% dans Snowflake. Cette vision unifiée permet d’envisager sereinement les futurs projets analytiques avancés et d’intelligence artificielle. L’équipe data travaille plus étroitement avec les équipes métiers (marketing, ventes, logistique) et gagne en réactivité.
Enfin, la plateforme Fivetran offre une maîtrise fine de la consommation et un monitoring précis des coûts liés aux projets data. « Cela nous permet notamment de travailler sur des sujets de prévision des ventes, d’intégrer rapidement de nouvelles sources pour enrichir les modèles et d’expérimenter à moindre coût de nouveaux cas d’usage data science », résume Salmane Khamlichi.
Terraform est efficace pour gérer de l’infrastructure ; pas des workflows data.
À force de s’en servir en conjonction avec Snowflake, Accor en est arrivé à ce constat. Entre absence de validation locale, gestion manuelle des dépendances et nécessité d’outils externes pour contrôler la qualité des données, la mise à l’échelle et la collaboration s’en trouvaient limitées.
Le groupe hôtelier a fini par basculer vers une stack associant dbt Core pour les transformations et un Airflow managé (Astro) pour l’orchestration, avec la bibliothèque Cosmos – proposée par le fournisseur d’Astro – pour faire la passerelle. Cette dernière déduit automatiquement le lignage des tâches et déclenche les contrôles de data quality immédiatement après la matérialisation d’une table ou d’une vue lors d’un dbt run.
Une déploiement Airflow « léger » qui rafraîchit uniquement les DAG
Le passage au tandem dbt-Airflow a impliqué un changement des pratiques de data engineering. Entre autres, passer d’étapes séparées pour la création et le peuplement de tables à une action unique utilisant exclusivement la commande SQL SELECT.
Chaque équipe possède son repo et déploie indépendamment. Tout part d’un template géré avec Copier. L’ensemble est réconcilié dans le projet principal, poussé vers Astro. Les scripts CI/CD sont centralisés dans un dépôt étiqueté.
Par défaut, Astro reconstruit l’image Docker à chaque modification. Le déploiement : dure alors environ 5 minutes. Il existe toutefois un mode « léger » dont Accor a tiré parti. Celui-ci synchronise simplement les DAG (graphes acycliques dirigés, représentant les tâches à exécuter) et évite ainsi un rebuild.
Pour exploiter ce mécanisme, le pipeline CI/CD place chaque projet dbt dans le répertoire dags/ du projet principal. Le déploiement dure alors environ 1 minute. Il couvre 95 % des exécutions. L’autre option reste utilisée pour l’upgrade des dépendances et les changements sur l’image de base (i.e. modification des fichiers include, requirements.txt ou Dockerfile).
Imbriquer chaque projet dbt dans le répertoire dags/ permet à Cosmo de générer automatiquement les tâches Airflow correspondantes. Et de construire des DAG sans intervention manuelle. Les tests peuvent se faire en local, avec dbt run et dbt test.
Accor vise un pipeline pour chaque équipe
Avec une telle configuration multilocataire, les cycles d’upgrade d’Airflow peuvent ralentir. Il n’y a, par ailleurs, pas moyen de prioriser des jobs. Et l’existence d’un seul chemin CI/CD vers la prod pose la question du point unique de défaillance, en plus des risques de conflit de noms et de bibliothèques.
Accor réfléchit donc à donner à chaque équipe son pipeline et à découpler la propriété du code. Tout en permettant l’hibernation des workflows à faible trafic.
Infrastructures, licences, accès aux données, ingénierie… L’IA a des coûts évidents. Mais entre évolution des compétences, refonte des processus et gestion des risques, elle implique aussi des coûts cachés.
Ces derniers pourraient représenter une charge supplémentaire de l’ordre de 30 à 40 % des coûts génériques. Telle est en tout cas l’estimation d’IBM. Le Cigref y fait référence dans une note consacrée à l’évaluation du ROI des solutions d’IA générative et agentique.
Se concentrer sur l’utilisation du temps libéré
L’association mentionne une autre donnée chiffrée : les IA horizontales – les « assistants » – feraient gagner 50 minutes par jour à certains profils. Cela ne dit rien, néanmoins, de la manière dont ce temps libéré est utilisé.
Le Cigref appelle justement à se concentrer sur cet aspect. Il s’agit « que les gains de productivité d’aujourd’hui ne deviennent pas une fin en soi, mais le levier d’une compétitivité pour demain ». On distinguera, dans ce cadre, ce qui relève de la modernisation (efficience opérationnelle) et ce qui relève de la véritable transformation.
Dans cet esprit, des entreprises font la différence entre les hard savings (économies tangibles, mesurables dans un compte de résultat) et les soft savings (porteuses de gains futurs : réduction des erreurs, accélération des workflows…).
Entre arbres de valeur et suivi des nouvelles activités
Pour se focaliser sur la création de valeur rendue possible, le Cigref suggère l’approche « gestion de portefeuille ». Les cas d’usage n’y sont pas évalués isolément, mais au sein d’un ensemble équilibré d’initiatives, chacune ayant ses métriques de succès.
Concernant les actions de transformation prérequises (modernisation des logiciels, gouvernance des données, etc.), la métrique est le time-to-market pour de futurs cas d’usage, et la réduction des risques.
Pour les IA horizontales, des entreprises ont prévu de traiter l’enjeu de réallocation du temps par l’intermédiaire d’enquêtes qualitatives à propos de la nature des nouvelles activités.
L’une d’entre elles a décidé, pour les IA verticales, de coconstruire des arbres de création de valeur avec les métiers. L’objectif stratégique est décliné en leviers opérationnels sur lesquels l’IA peut agir. L’impact est ainsi mesuré sur des KPI existants.
Quelques éléments à intégrer dans l’évaluation des coûts et des bénéfices
Le Cigref distingue quatre catégories de coûts :
Liés aux IA (matériel, licences, ingénierie, intégration, services…)
Maintenance et supervision
Gestion des risques et des échecs
Transformation (modernisation de logiciels, refonte de processus métier, reskilling…)
Quatre catégories également pour ce qui est des éléments à prendre en compte dans l’estimation des bénéfices (opérationnels, organisationnels, stratégiques, financiers).
Sur le volet opérationnel, aux gains de productivité et à l’optimisation du temps d’implémentation s’ajoute la détection proactive des fraudes et des anomalies.
En matière organisationnelle, il y a l’exploitation et la valorisation des données (amélioration des modèles prédictifs, passage à l’échelle rendu possible…). Il y a aussi l’attractivité de l’organisation (mise en place de principes éthiques, engagement des employés…). La réduction du nombre d’outils par personne participant à un processus de décision fait partie des autres indicateurs pertinents.
Côté stratégique, le Cigref évoque, d’une part, l’expérience client (réduction du temps de réponse, personnalisation des interactions…). De l’autre, l’engagement et l’innovation (réduction du lead time, création de modèles économiques…).
La partie financière se partage entre génération de revenus (diminution du churn, optimisation du pricing…) et réduction des coûts et des risques.
L’ensemble peut être industrialisé en s’inspirant des modèles de centre d’excellence IA ou d’AI Factory. À condition notamment de définir des standards et de fournir des outils d’observabilité.
Connexion
