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.
L’intelligence artificielle générative n’est pas seulement un outil de productivité pour les entreprises. Selon une étude publiée par l’ANSSI, elle est une arme supplémentaire dans l’arsenal des cybercriminels et des groupes d’espionnage étatiques.
L’agence nationale de la sécurité des systèmes d’information s’est penchée exclusivement sur les intelligences artificielles génératives. Parmi eux, les fameux grands modèles de langage (LLM) incarnent ce qu’on appelle l’usage dual de l’IA : un même outil peut servir à défendre comme à attaquer.
Certes, l’ANSSI n’a pas encore identifié de cyberattaque totalement autonome pilotée par une IA contre des cibles françaises. Mais l’agence le dit clairement : l’IA permet déjà aux attaquants d’améliorer « significativement le niveau, la quantité, la diversité et l’efficacité » de leurs opérations, surtout contre les systèmes mal protégés. Les modèles sont désormais utilisés tout au long de la chaîne d’attaque, de la reconnaissance initiale jusqu’à l’exploitation finale des données volées.
Des faux profils générés en masse
Les opérateurs de modes opératoires d’attaque (MOA) réputés liés à l’Iran auraient utilisé l’IA générative Gemini de Google à des fins de reconnaissance contre des experts et organisations d’intérêt. En 2024, les opérateurs du MOA Charcoal Typhoon, réputé lié à la Chine, auraient quant à eux utilisé des services d’IA générative pour générer du contenu d’hameçonnage, ciblant notamment Taïwan, la Thaïlande, la Mongolie, le Népal et la France.
Entre 2024 et 2025, les opérateurs du MOA Lazarus, réputé lié à la Corée du Nord, auraient également eu recours à l’IA générative pour créer de faux profils d’entreprises et d’employés sur les réseaux sociaux. L’ANSSI a par ailleurs observé plusieurs sites Internet apparemment générés par IA, servant à héberger des charges malveillantes ou à effectuer de la caractérisation, c’est-à-dire du profiling des internautes. De nombreux cybercriminels exploitent également des services de deepfakes pour quelques dizaines de dollars à des fins d’usurpation d’identités.
Malwares « intelligents »
En 2024, le MOA TA547 aurait utilisé un script PowerShell généré par un LLM pour compromettre une entreprise allemande. Des chercheurs de l’université de New York ont par ailleurs développé PromptLock, un prototype de rançongiciel utilisant dynamiquement des prompts pour générer des scripts à l’exécution, permettant d’exfiltrer et de chiffrer les données.
Google a également identifié Promptflux, un code malveillant polymorphique particulièrement sophistiqué qui prompte l’API Gemini pour réécrire entièrement son code source toutes les heures afin d’éviter la détection. Le développement de tels codes suggère cependant des capacités relativement sophistiquées de la part des développeurs.
En février 2025, le département de cyberdéfense ukrainien a affirmé que des opérateurs russes auraient utilisé des services d’IA générative pour analyser massivement les données exfiltrées de leurs victimes et identifier les informations d’intérêt.
L’IA n’est pas encore autonome… mais ça progresse vite
L’utilisation de l’IA générative pour certaines étapes complexes de la chaîne d’infection, comme la recherche de vulnérabilités, reste limitée. Pour l’instant. L’identification d’une faille de sécurité et le développement de la preuve de concept associée dépendent encore largement de compétences humaines. La plupart des systèmes d’IA générative commerciaux restent trop instables et trop limités pour identifier des vulnérabilités jour-zéro rapidement et en quantité. À l’heure actuelle, aucun cas avéré d’exploitation de vulnérabilité jour-zéro découverte grâce à un modèle d’IA générative n’a été documenté.
Mais les choses bougent très vite. En novembre 2024, le système BigSleep a démontré son efficacité pour la recherche de vulnérabilités dans des codes sources. Plus inquiétant encore, en juin 2025, le système XBOW, développé par d’anciens ingénieurs de GitHub, a soumis des centaines de vulnérabilités, dont certaines critiques, sur différents programmes de bug bounty, après avoir scanné simultanément des milliers d’applications web. La course est lancée.
42 groupes de hackers d’État utilisent déjà l’IA
Un large spectre d’acteurs offensifs utilise désormais les services d’IA générative. En janvier 2025, Google révélait que son modèle Gemini avait été utilisé entre 2023 et 2024 par des groupes cybercriminels ainsi que par au moins 10 modes opératoires d’attaque liés à l’Iran, 20 liés à la Chine, 9 liés à la Corée du Nord et 3 liés à la Russie.
L’utilisation de ces technologies varie considérablement selon les objectifs et le niveau de maturité des acteurs. Pour les groupes les plus sophistiqués, l’IA générative devient un nouveau cadre pratique, similaire à l’utilisation d’outils malveillants génériques comme Cobalt Strike ou Metasploit. Elle leur permet notamment de générer du contenu en masse dans plusieurs langues, de développer du code non signant, d’effectuer des recherches sur des cibles plus rapidement, et potentiellement d’automatiser complètement une chaîne d’attaque à court ou moyen terme.
Pour les hackers moins expérimentés, l’IA générative constitue avant tout un formidable outil d’apprentissage et offre un gain de productivité en répondant à des questions techniques. Dans tous les cas, le verdict est sans appel : l’IA générative permet aux acteurs malveillants d’agir plus rapidement et à plus grande échelle.
WormGPT et FraudGPT
Les modèles d’IA générative comme ChatGPT disposent de garde-fous techniques empêchant leur utilisation à des fins illégales. Les acteurs malveillants cherchent néanmoins à contourner ces limitations par des méthodes d’ingénierie de prompt incluant des formulations ambiguës, des mots-clés spécifiques ou l’utilisation de scénarios fictifs. Ces techniques évoluent constamment et constituent un défi majeur pour les développeurs.
Le « jailbreak » : contourner les barrières morales de l’IA
Dès 2023, des chercheurs en sécurité parvenaient déjà à détourner ChatGPT pour développer un code malveillant polymorphique. En 2024, la situation s’est aggravée avec l’apparition de services de jailbreak-as-a-service comme EscapeGPT ou LoopGPT sur les forums cybercriminels. Moyennant quelques dollars, n’importe qui peut désormais accéder à des prompts préfabriqués pour faire cracher à ChatGPT ce qu’il refuse normalement de produire.
Les IA « débridées » du crime organisé
Mais pourquoi se fatiguer à contourner les protections quand on peut acheter une IA sans aucune limite ? Dès 2023, des services d’IA générative sans garde-fous tels que WormGPT, FraudGPT ou EvilGPT ont fleuri sur les forums cybercriminels ou via des canaux Telegram. Le prix du ticket : environ une centaine de dollars par mois. Des modèles plus récents comme WormGPT 4 seraient même directement entraînés sur des jeux de données spécifiques aux activités cybercriminelles, incluant du code malveillant et des modèles d’hameçonnage. L’industrialisation du crime numérique est en marche.
Quand l’IA devient elle-même la cible : les nouvelles vulnérabilités
Les catégories d’acteurs malveillants susceptibles de cibler spécifiquement les systèmes d’IA semblent similaires à celles qui s’attaquent aux systèmes d’information conventionnels. Mais les systèmes de LLM pourraient être vulnérables à de nouveaux vecteurs d’attaque inédits.
Lors de l’entraînement du modèle, des attaquants peuvent introduire des données corrompues ou fausses. Lors de l’intégration du modèle, il est possible d’y implémenter des portes dérobées. Enfin, lors de l’interrogation du modèle, également appelée inférence, des acteurs malveillants peuvent injecter de fausses informations pour altérer la réponse ou récupérer des informations confidentielles.
« Empoisonnement » des modèles : 250 documents suffisent pour corrompre une IA
Bien qu’aucun incident majeur n’ait été porté à la connaissance de l’ANSSI, le risque est réel et documenté. Des acteurs malveillants pourraient manipuler, modifier et interagir avec les données d’entraînement d’une IA générative. Une telle compromission pourrait mener à l’utilisation de ces modèles à des fins d’altération de données ou au sabotage de systèmes opérationnels.
Le plus inquiétant ? La multiplication de contenus fallacieux générés par IA sur Internet pourrait progressivement polluer les données d’entraînement des modèles et contribuer à diffuser de fausses informations à grande échelle. Une analyse conjointe du UK AI Security Institute et du Alan Turing Institute a d’ailleurs démontré une faille vertigineuse : il serait possible d’empoisonner des modèles d’IA générative à partir de seulement 250 documents malveillants. Pire encore, ce nombre resterait stable indépendamment de la taille des données d’apprentissage du modèle. Autrement dit, corrompre GPT-4 ou GPT-5 nécessiterait le même effort.
L’ANSSI a également observé certains modèles d’IA intégrant dès leur conception des limitations ou des éléments de censure. Dans le cadre du sommet pour l’IA 2024, Viginum a par ailleurs publié un rapport sur les défis et opportunités de l’IA dans la lutte contre les manipulations de l’information.
Attaques par la chaîne d’approvisionnement : le cheval de Troie version IA
Certaines attaques à l’encontre de modèles d’IA pourraient constituer une nouvelle forme redoutable d’attaque par chaîne d’approvisionnement. Des modèles d’IA générative disponibles en sources ouvertes et spécialisés dans la génération de code peuvent être malveillants ou compromis dès le départ, et exécuter du code arbitraire pour installer une porte dérobée dès leur téléchargement. Un piège parfait pour les développeurs pressés.
Les attaquants peuvent également exploiter des failles au sein d’agents Model Context Protocol (MCP), utilisés pour connecter les LLM à des outils externes et à des sources de données. Ces serveurs, qu’ils fonctionnent en local ou à distance, peuvent étendre dangereusement la surface d’attaque s’ils ne sont pas suffisamment sécurisés.
Pratique émergente et particulièrement sournoise, le slopsquatting, consiste à récupérer des noms de paquets imaginés par des IA lors d’hallucinations, puis à en diffuser des versions malveillantes. Les attaquants exploitent ainsi les erreurs de l’IA pour introduire des paquets malveillants dans la chaîne d’approvisionnement logicielle. Quand l’IA se trompe, les hackers en profitent.
100 000 comptes ChatGPT piratés
Les systèmes d’IA participent à l’augmentation de la surface d’attaque, d’autant plus lorsqu’ils sont intégrés dans des contextes logiciels plus larges, déployés dans des environnements classifiés ou utilisés dans certains flux opérationnels de l’entreprise. En l’absence d’un cloisonnement rigoureux physique et des usages, la compromission du système d’IA pourrait mener à l’atteinte à la confidentialité des données qu’il traite et à l’atteinte à l’intégrité des systèmes d’information auxquels il est connecté.
L’utilisation de comptes d’IA par les salariés dans un contexte professionnel peut exposer des informations sensibles à des risques considérables. Entre 2022 et 2023, plus de 100 000 comptes utilisateurs de ChatGPT ont été compromis par des acteurs cybercriminels à l’aide d’infostealers comme Rhadamanthys, puis revendus sur des forums.
Les employés peuvent involontairement générer des fuites de données en fournissant à l’IA des informations sensibles, voire confidentielles. L’exemple le plus emblématique ? En juin 2023, des salariés de Samsung ont divulgué des informations sensibles sur la technologie des semi-conducteurs en utilisant ChatGPT. L’enfer est pavé de bonnes intentions… et de prompts mal réfléchis.
De la RAM aux CPU, une pénurie peut en cacher une autre.
Sur la RAM, la situation est avérée. Elle découle essentiellement de la demande en GPU, dans le cadre de la « course à l’IA » que se livrent les hyperscalers.
Concernant les CPU, il y a des signaux du côté d’Intel. Depuis quelques mois, l’entreprise emploie, dans sa communication publique, le mot shortage, qu’on peut traduire par « manque »… ou « pénurie ». Elle ne le projette pas tant sur le marché dans son ensemble que sur sa propre incapacité à suivre la demande.
Davantage de cœurs… ou de serveurs ?
Un premier avertissement était tombé en octobre 2025 : la « pénurie » de CPU allait atteindre un pic au premier trimestre 2026. À la fois sur l’informatique cliente et le datacenter. La demande a été plus importante que prévu sur les anciens procédés de gravure (Intel 10 et Intel 7), nous expliquait-on alors. D’une part pour les Xeon. De l’autre pour les Core, dans le contexte de la transition vers Windows 11.
À trois mois d’intervalle, le discours n’a globalement pas changé. La demande en Xeon reste insatisfaite à l’heure où l’activité « datacenter et IA » connaît une croissance séquentielle sans précédent depuis plus d’une décennie. >>Intel affirme qu’il y a encore six mois, tout laissait anticiper une hausse du nombre de cœurs par serveur ; pas du nombre de serveurs tout court. Or, après communication avec des clients, c’est la deuxième option qui se dessine, potentiellement pour plusieurs années.
Le yield (taux de production de CPU « utilisables » par rapport au nombre de wafers) renforce la difficulté à délivrer. Intel explique en tout cas que cet indicateur est en dessous de ses attentes. Au final, il ne cache pas son intention de prioriser les serveurs aux PC. Pour ces derniers, la production se concentrerait sur le milieu et le haut de gamme, tout en sourçant davantage de wafers en externe. Il est également question de livrer en priorité les clients qui sont aussi parvenus à obtenir de la mémoire.
La perspective de l’IA sur CPU
Au sujet du marché des serveurs, Omdia va dans le même sens qu’Intel. Le cabinet d’études estime que 15,9 millions d’unités seront livrées en 2026, contre 14,4 millions en 2025.
Les fabricants de processeurs ont, ajoute-t-il, d’autant plus de mal à suivre qu’ils doivent alterner entre les processus de gravure. Quant à TSMC, il a possiblement donné la priorité aux puces IA par rapport aux CPU. Bilan : ces derniers pourraient, selon une estimation jugée « prudente », voir leurs prix augmenter de 11 à 15 % en 2026.
L’IA elle-même tend à se déporter sur les CPU, en conséquence de la rareté et de la cherté des GPU. DeepSeek a récemment ouvert des perspectives dans ce domaine avec son architecture Engram. Censée apporter un « deuxième cerveau » aux LLM, elle s’appuie sur une table de connaissances stockée en mémoire CPU, sans dégradation majeure par rapport à de l’inférence GPU pure.
Intel communique aussi à ce propos. Il est, par exemple, revenu sur l’exploitation de puces Xeon par une agence gouvernementale américaine pour faire tourner des SLM (Mistral 7B, Mixtral 8x7B et Llama 3.1-8B) avec OpenVINO.
AMD, qui maintient à son catalogue des CPU d’anciennes générations, ne parle pas officiellement de pénurie. Par rapport à Intel, il a potentiellement plus de marge pour réallouer si nécessaire sa capacité de production, avec les cartes graphiques Radeon comme variable d’ajustement.
« 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.
L’ancien temps est révolu. Celui où vous deviez configurer indépendamment chaque brique de votre infrastructure, effectuer manuellement le déploiement de vos environnements, et gérer jour après jour le cycle de vie de vos machines. Place à une gestion beaucoup plus agile et automatisée avec Dell Automation Platform (DAP) et Dell Private Cloud (DPC).
Le portail : Zero Touch Onboarding
Mettons-nous en situation pour comprendre concrètement à quoi ressemble le quotidien d’un administrateur dans ce nouveau modèle de gestion IT. Imaginons que vous souhaitiez déployer une infrastructure de cloud privé, mêlant des environnements VMware, pour héberger vos applications existantes, et des clusters OpenShift pour les applications cloud natives.
Vous avez commandé les serveurs Dell PowerEdge et les baies Dell PowerStore dont vous aviez besoin, puisque rappelons-le, l’approche composable vous permet de déployer indépendamment des ressources de calcul ou de stockage pour être au plus proche de vos exigences réelles. Lorsque vos équipements arrivent, vous les connectez à votre réseau… et c’est à peu près tout.
Il vous suffit ensuite d’accéder au portail Dell Automation Platform pour découvrir que vos nouveaux équipements ont été automatiquement onboardés. Le portail est le plan de contrôle qui va donner toute la visibilité sur l’inventaire matériel, l’état de santé des composants et la conformité du parc. Vous n’avez plus qu’à les assigner à l’orchestrateur pour que leurs ressources rejoignent le pool global et puissent être automatiquement allouées à vos futurs workloads. Bienvenue dans le Zero Touch Onboarding.
Le catalogue : des blueprints prêts à l’emploi
Vos ressources sont prêtes à être consommées. Dell Private Cloud lui, est prêt à entrer en jeu. Car c’est ici que l’intégration des deux solutions va apporter toute sa valeur. Dell Private Cloud va proposer un catalogue de « blueprints », c’est-à-dire un ensemble de fichiers YAML/Python basés sur le standard TOSCA (Topology and Orchestration Specification for Cloud Applications) qui décrit la topologie (serveurs, stockage, réseau, hyperviseur, etc.), les dépendances et les paramètres nécessaires.
Des blueprints existent pour déployer un cloud privé, des infrastructures IA ou encore des environnements Edge. Il est également possible de créer ses propres blueprints. Dans notre cas, vous allez pouvoir rattacher vos licences dans DAP, puis sélectionner les blueprints « Dell Private Cloud deploying VMware » et « Dell Private Cloud deploying Red Hat OpenShift », et laisser DAP faire le reste.
L’orchestrateur : des dizaines d’étapes manuelles automatisées en quelques minutes
Une fois le blueprint sélectionné dans l’interface de DPC, c’est l’orchestrateur de DAP qui entre en scène en arrière-plan. L’orchestrateur constitue le plan de gestion et va exécuter le scénario de déploiement complet décrit dans le blueprint. Par exemple : création d’un cluster vSphere sur PowerEdge, configuration du stockage Dell, mapping des LUN, intégration aux outils de management, etc. Il élimine ainsi le risque d’erreur humaine et remplace des dizaines d’étapes manuelles par un workflow unique et automatisé, déroulé en seulement quelques minutes.
Mais son rôle ne s’arrête pas là : il assure également la gestion du « Jour 2 ». Si une mise à jour de firmware est nécessaire ou si vous devez étendre votre cluster, l’orchestrateur pilote l’opération en toute transparence, garantissant que votre infrastructure reste toujours performante et sécurisée.
Plein cap sur l’après HCI
Dell Automation Platform et Dell Private Cloud sont donc les deux piliers de la nouvelle infrastructure composable qui vient bousculer l’hyperconvergence. Ensemble, les deux logiciels vont permettre aux entreprises de considérablement simplifier et accélérer la modernisation de leur IT, en automatisant les opérations de déploiement, de configuration et de gestion.
Mais ils vont en plus garantir la pérennité des investissements. Grâce à l’agnosticité vis‑à‑vis des systèmes d’exploitation et hyperviseurs tiers, qui évite tout verrouillage technologique, la même infrastructure Dell PowerEdge peut être réutilisée et accueillir de nouvelles images au fil du temps. C’est une nouvelle ère qui commence en 2026.
Pendant plusieurs mois, Notepad++ a servi à diffuser des malwares.
Son développeur l’a officialisé cette semaine. Dans les grandes lignes, la compromission de l’infrastructure d’hébergement a permis la distribution de mises à jour malveillantes.
Une chronologie des événements commence à se dessiner. Apparaissent trois phases, marquées par autant de chaînes d’exécution. Parmi les cibles figurent une entité gouvernementale aux Philippines, une organisation financière au Salvador et un fournisseur IT au Viêtnam.
Phase 1 : une faille dans ProShow mise à profit
La première phase s’est étalée sur fin juillet-début août.
L’interception et la modification du trafic du gestionnaire de mises à jour de Notepad++ entraînait le téléchargement et l’exécution d’un installeur NSIS d’environ 1 Mo. Au lancement, celui-ci créait un dossier et un fichier texte en son sein, y inscrivait des informations système, les téléversait sur temp.sh et envoyait l’URL vers un serveur C2.
Un downloader déposait ensuite plusieurs fichiers dans le même dossier. Dont une version légitime de logiciel ProShow… souffrant d’une vulnérabilité qui permettait de lancer un shellcode.
Ce code déchiffrait un downloader Metasploit qui récupérait et lançait un implant Cobalt Strike. Lequel communiquait avec un autre C2.
Entre fin juillet et début août, quelques éléments ont changé. Essentiellement les URL de l’implant Cobalt Strike et du C2 associé.
Phase 2 : passage à l’interpréteur Lua
La deuxième phase a commencé mi-septembre et s’est achevée à la fin du mois.
La mise à jour malveillante de Notepad++ demeurait hébergée sur le même serveur. Il s’agissait toujours d’un installeur NSIS, mais plus léger (140 ko). La collecte d’infos système suivait le même schéma que lors de la première phase.
À partir de là, les choses changeaient. Exit ProShow, place à des fichiers liés à l’interpréteur Lua. Dont un exécutable qui lançait un script localisé dans un fichier .ini.
Ce script plaçait, en mémoire exécutable, du shellcode lancé via la fonction API EnumWindoStationsW. On retrombait alors sur la chaîne « Metasploit + Cobalt Strike », avec des URL similaires.
Sur la fin de la période, des fichiers de mise à jour avec des hashs différents sont apparus. Et la collecte d’infos système était divisée en plusieurs commandes.
Phase 3 : sideload de DLL dans un exécutable Bitdefender
La troisième phase a couvert le mois d’octobre.
À cette occasion, le serveur hébergeant les mises à jour malveillantes a changé. On restait sur des fichiers NSIS, mais sans capture d’infos système. Le chargement du shellcode était cette fois-ci réalisé par charge latérale d’une DLL dans un exécutable : BluetoothService.exe. Derrière ce nom se cachait une version légitime de Bitdefender Submission Wizard.
Le shellcode était déchiffré avec une routine embarquée. Il en résultait une backdoor. Rapid7 l’a appelée Chrysalis, en référence aux multiples couches (chiffrement en enveloppe, construction de noms de cibles à la volée, hachage d’API, URL au format des endpointsDeepSeek…) compliquant la détection de ses actions.
Un des loaders exploite un syscall non documenté associé à Microsoft Warbird, un framework d’obscurcissement de code. Il n’y a pas de chargement direct de Cobalt Strike. Mais l’implant a bien été trouvé sur une machine infectée, téléchargé là aussi via un downloader Metasploit, via des URL au format similaire à celles rencontrées lors des deux premières phases.
Des similitudes avec une analyse antérieure incitent à attribuer cette troisième phase – et potentiellement l’ensemble de la campagne – au mode opératoire Lotus Blossom, dit lié à la Chine. Actif depuis au moins 2009, il s’est livré à des actions d’espionnage en Asie du Sud-Est. Et plus récemment en Amérique centrale, avec un focus sur gouvernements, télécoms, aviation, médias et infrastructures critiques.
Il y a dix ans, l’hyperconvergence (ou HCI, pour HyperConverged Infrastructure) bousculait les codes du datacenter. En fusionnant le calcul et le stockage au sein d’une même plateforme, des solutions comme Dell VxRail ont tenu une promesse forte : briser les silos historiques de l’architecture 3-tiers traditionnelle.
Cette architecture a séduit par sa simplicité d’administration et son déploiement rapide. Pour beaucoup d’entreprises, l’hyperconvergence était la réponse idéale à la complexité de gestion des environnements virtualisés. Mais en 2026, l’intégration monolithique qui faisait la force du HCI commence à montrer des limites face aux nouveaux enjeux des entreprises
Objectifs 2026 : réduire la dépendance et les coûts
Le paysage IT a changé ces dernières années et pousse les DSI à réévaluer la pertinence du modèle HCI. Ces derniers souhaitent en premier lieu se libérer du « vendor lock-in », autrement dit, de la dépendance à un fournisseur, qui peut être importante dans un environnement hyperconvergé qui impose un hyperviseur spécifique. Les évolutions récentes des modèles de souscription logicielle ont mis en exergue cette problématique : l’augmentation des coûts de licence « au cœur » ou « au processeur » amène les entreprises à optimiser le nombre de serveurs physiques pour réduire leur facture logicielle.
L’autre enjeu majeur est le besoin croissant d’agilité. L’évolutivité de l’hyperconvergence est basée sur un modèle scale-out, qui consiste à ajouter des nœuds additionnels lorsque les besoins augmentent. Ce qui revient donc à augmenter simultanément les capacités de calcul et de stockage. À l’ère de l’IA et des Data Lakes, les besoins en stockage croissent souvent beaucoup plus vite que les besoins en puissance de calcul. Le résultat peut être un surprovisionnement coûteux pour l’entreprise. L’arrivée massive des containers et des charges de travail gourmandes en GPU renforce également la nécessité d’une infrastructure plus modulaire que ce que permettent les clusters HCI actuels.
L’évolutivité du 3-tiers et la simplicité du HCI (sans les coûts)
Le 3 tiers d’hier est-il donc redevenu la bonne solution d’aujourd’hui ? Pas tout à fait. Car en cassant les silos IT, l’hyperconvergence a apporté une simplicité de gestion des différentes briques qu’il est crucial de conserver. C’est ici que l’infrastructure composable entre en jeu, en proposant une architecture de cloud privé, qui sépare physiquement les ressources, comme dans le modèle 3-tiers, mais conserve une couche logicielle d’orchestration et d’automatisation, comme avec l’hyperconvergence.
Cette couche logicielle, incarnée par Dell Automation Platform (DAP), va donc offrir la même simplicité de gestion « en un clic » que le HCI, mais sur des composants que l’on peut faire évoluer indépendamment. L’ensemble des ressources sont ensuite réunies dans un pool logique unique qui permet à l’administrateur de composer à la demande l’infrastructure dont il a besoin. Et pour simplifier le déploiement, il peut sélectionner dans un catalogue des « blueprints », c’est-à-dire des environnements déjà testés et préconfigurés, pour l’IA par exemple, mais aussi créer ses propres blueprints, afin d’automatiser le déploiement d’environnements pensés spécifiquement pour ses besoins
VMware et OpenShift : deux mondes, une seule infrastructure
Cette infrastructure composable (on parle aussi parfois de d’infrastructure « désagrégée ») présente trois bénéfices majeurs par rapport à l’hyperconvergence. D’abord, elle offre une plus grande granularité en permettant d’ajuster indépendamment la puissance de calcul et la capacité de stockage, ce qui élimine le surprovisionnement et garantit une plus grande adéquation entre les investissements et les besoins.
Autre point fort, cette approche est totalement agnostique et permet de faire cohabiter machines virtuelles, conteneurs ou serveurs bare metal. Avec une infrastructure composable, vous pouvez connecter une seule baie de stockage de type Dell PowerStore, à dix serveurs Dell PowerEdge différents, dont cinq tournent sous VMware et cinq autres sous Red Hat OpenShift par exemple, le tout piloté par la console unique de DAP.
Moins de serveurs, moins de licences, donc moins de coûts. En associant granularité et agnosticisme, l’infrastructure composable génère d’importantes économies. D’après une étude réalisée par le cabinet Principled Technologies, une infrastructure composable permet de réduire le TCO de plus de 20 % sur 5 ans par rapport au HCI. Une belle revanche !
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 à 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égie de leur organisation, ils ont adopté des comportements malveillants : chantage envers des responsables, fuites d’informations sensibles vers des concurrents…
SpaceX va acquérir xAI dans le cadre d’un échange d’actions qui valorise l’ensemble du nouvel groupe autour de 1 250 milliards $.
Cette opération de fusion-acquisition complète intègre xAI au sein de SpaceX, qui devient ainsi la maison mère d’une plateforme combinant fusées, réseau Starlink, intelligence artificielle Grok et services numériques associés. Les actionnaires de xAI recevront des titres SpaceX selon un ratio prédéfini.
La transaction intervient à un moment stratégique, en amont d’une introduction en Bourse envisagée pour SpaceX. L’opération valorise SpaceX proche de 1 000 milliards $ et xAI autour de 250 milliards. Cette consolidation vise à simplifier la structure capitalistique et à renforcer le profil de croissance perçu par les investisseurs.
Une intégration verticale espace-IA
L’enjeu industriel majeur réside dans le couplage des capacités d’intelligence artificielle de xAI avec les activités spatiales de SpaceX. Les modèles Grok et les infrastructures d’entraînement de xAI sont appelés à intervenir dans la conception de lanceurs, la planification de missions et la gestion de la chaîne logistique.
Le projet le plus ambitieux consiste à utiliser Starlink et des centres de données en orbite pour héberger et exécuter des modèles d’IA. L’objectif est de réduire la dépendance aux data centers terrestres, optimiser la consommation énergétique et limiter les contraintes de refroidissement.
L’IA de xAI doit également améliorer la conception des fusées, la détection d’anomalies en vol, la maintenance prédictive et l’optimisation des trajectoires, créant des boucles de rétroaction entre données de vol et entraînement des modèles. La fusion consolide par ailleurs les capacités duales civil-défense du groupe. SpaceX dispose déjà de nombreux contrats avec le Pentagone et les agences de renseignement, tandis que xAI commence à nouer des partenariats dans la défense, notamment pour des usages en logistique et analyse de renseignement.
Une diversification des revenus
Sur le plan commercial, cette fusion vise à justifier des multiples de valorisation plus élevés en présentant aux marchés une histoire de croissance unifiée avant l’introduction en Bourse. Au-delà des lancements et de Starlink, le nouvel ensemble ambitionne de proposer des offres de services d’IA adossées à l’infrastructure spatiale : connectivité augmentée, traitement de données en orbite, services temps réel pour entreprises et gouvernements.
Face aux autres acteurs de l’IA, xAI peine à rivaliser en part de marché avec OpenAI ou Anthropic. Mais son ancrage dans un actif industriel rentable et stratégique comme SpaceX lui confère un positionnement différenciant, basé sur la maîtrise conjointe de l’infrastructure physique et des modèles d’IA.
La taille et la nature stratégique du nouvel ensemble devraient accroître son pouvoir de négociation vis-à-vis des États et grands comptes. Cette concentration expose néanmoins le groupe à un contrôle accru sur les questions de concurrence, de sécurité nationale et de gouvernance des systèmes d’IA.
À l’heure du codage par IA, il est d’autant plus important de s’assurer que les contributeurs comprennent ce qu’ils proposent.
Un des ateliers de la FOSDEM 2026 a abordé cet aspect. Le contexte : une réflexion au sujet de la charge qui pèse sur les mainteneurs de projets open source.
Référence y est faite dans une discussion sur GitHub. Avec une question : que pourrait faire la plate-forme pour motiver les contributeurs à passer du temps sur les explications (descriptions de problèmes et de features) plutôt que sur la soumission de code ?
Là n’est cependant pas le thème principal de cette discussion. À travers elle, GitHub fait plutôt part de ses perspectives concernant la gestion des PR.
À court terme, il propose aux mainteneurs des options pour les désactiver complètement, les restreindre aux collaborateurs et les supprimer depuis l’UI.
Sur le long terme, GitHub envisage une solution « intermédiaire » permettant de conditionner l’ouverture de PR au respect de critères. Il songe aussi à exploiter l’IA pour évaluer le respect des standards/guidelines des projets.
Pour les guidelines, la source de vérité pourrait être le fichier CONTRIBUTING.md.
GitHub invité à envisager la désactivation automatique de Copilot
Beaucoup de projets veulent partager du code sans créer un entonnoir de contributions publiques, confirme un participant qui approuve les perspectives à court terme. Les mesures de contournement actuelles – des bots qui ferment les PR – ajoutent du bruit et sont peu intuitives, précise-t-il. Et de suggérer, concernant la vision à plus long terme, de pouvoir faire la différence entre contributeurs passagers et contributeurs externes de confiance sans avoir à donner d’accès collaborateur complet.
On suggère aussi à GitHub de quoi restreindre les contributeurs « nouveaux » – par exemple, dont la première interaction remonte à moins de 48 heures – à un seul PR. Ou encore d’obliger la liaison de tout PR à un ticket ou à une discussion.
Sur le volet IA, on suggère à GitHub un système de seuils configurables au niveau du dépôt ou de l’organisation. Et la désactivation automatique de Copilot sur les repos dont la politique interdirait l’usage.
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é.
Pas besoin de scripts ; juste des fichiers de configuration décrivant l’état des hôtes.
Telle était la promesse de CFEngine lorsqu’il émergea dans les années 90. Avec son langage dédié, l’outil devait faciliter la maintenance des environnements BSD et System V (UNIX) en les organisant en classes. Il s’agissait déjà de répondre à la fragmentation des systèmes d’information…
Liste de contrôle d’accès NT. Issu de la documentation de CFEngine 1.6, sorti en 2000.
Dans les années 2000, Puppet et Chef sont arrivés sur le même créneau, chacun avec son langage basé sur Ruby. L’un et l’autre fonctionnaient en mode pull, le client contactant régulièrement le serveur pour récupérer la configuration. On ne parlait pas encore de DevOps, mais d’automatisation du travail des sysadmins.
Architecture simplifiée de Puppet telle que présentée en 2010.
Au début des années 2010, AWS pousse le templating JSON/YAML avec CloudFormation. Ansible décline le concept en playbooks. Terraform l’adopte avec son propre langage (HCL) et le porte à l’échelle de déploiements multifournisseurs.
Template CloudFormation créant une instance EC2. Exemple donné début 2011, quelques semaines après le lancement du service.Exemple de configuration Terraform que HashiCorp donnait en 2014, peu après le lancement du produit.Playbook Ansible donné en référence en 2015, juste avant que la start-up se vende à Red Hat.
Face aux limites des langages dédiés et de l’option « tout YAML » apparaissent des outils comme Pulumi, qui adaptent les langages impératifs (Go, Python…) à la gestion d’infrastructure.
La recette IaC déclinée sur l’observabilité…
Avec ce bagage, l’approche « as code » s’est développée sur d’autres pans des systèmes informatiques : documentation, sécurité, politiques organisationnelles… ou encore observabilité. Dashboards, alertes, logs, traces, métriques, SLO/SLI, etc. deviennent autant d’éléments « codifiés » sur le même plan que l’infra ; et, in fine, déployés en parallèle, avec un repo Git comme « source de vérité ».
Corollaire de cette convergence, l’observability as code (OaC) porte globalement les mêmes promesses que l’infrastructure as code (IaC). À commencer par les bénéfices de l’automatisation.
Sur le papier, outre la réduction du potentiel d’erreurs humaines, on a des configurations reproductibles favorisant la cohérence entre environnements et la mise à l’échelle dans le contexte d’architectures dynamiques (microservices, workloads IA). On crée par ailleurs une boucle de rétroaction avec l’IaC, en bénéficiant de la traçabilité de Git – lequel permet aussi, en théorie, une reconstruction rapide de la stack d’observabilité.
… avec un bouquet d’abstractions
En parallèle de leurs API, les principales solutions d’observabilité sont pilotables via Terraform, grâce à un provider. Elles proposent aussi d’empaqueter des configurations en charts Helm et d’utiliser des CRD pour définir des artefacts en tant qu’objets Kubernetes standards.
À cheval entre ces deux univers, il y a le projet Upjet. Celui-ci transforme les providers Terraform en providers Crossplane, tout en générant les contrôleurs de réconciliation et la documentation API avec des exemples de manifestes.
Du côté de Grafana, on expérimente actuellement une fonctionnalité Git Sync. Elle assure une synchronisation bidirectionnelle l’UI et le Git, avec la possibilité d’imposer que les changements réalisés sur l’interface passent par des PR. Pour le moment, certains artefacts ne sont pas pris en charge (alertes, panels…) et seul GitHub est géré (authentification par PAT uniquement).
Grafana a aussi, dans sa boîte à outils, un SDK Foundation orienté sur les langages à typage fort (on définit des dashboards en chaînant des appels de méthodes). Il a également une bibliothèque qui met en œuvre Jsonnet. Cette extension de JSON a été influencée par plusieurs langages de configuration utilisés chez Google. Elle facilite les regroupements logiques de configurations avec ajustement des variables à la volée pour contextualiser les artefacts.
À partir de Jsonnet, Prometheus a créé les mixins. Ce format encapsule des alertes/règles et des dashboards Grafana en compagnie du code avec lequel ils sont déployés.
Autre langage qui a ses racines chez Google : CUE (Configure, Unify, Execute). Il s’est en l’occurrence inspiré du langage utilisé pour configurer Borg, le prédécesseur de Kubernetes. En son cœur, une technique communément exploitée en linguistique informatique pour gérer grammaires et lexiques : l’unification de graphe. Types et valeurs sont fusionnés en un seul concept et ordonnés en une hiérarchie unique.
Associatif, CUE est aussi commutatif et idempotent : peu importe leur ordre, les valeurs produisent toujours le même résultat. On s’en servira typiquement pour la validation de schémas ou de données. Les types agissent alors comme des contraintes, réconciliables depuis plusieurs sources sans avoir à effectuer d’importations.
Des stacks open source aux plates-formes d’observabilité
À petite échelle, un pattern traditionnel de déploiement de l’OaC repose sur la pile open source* Prometheus/Grafana/Loki/Jaeger. Souvent en monorepo avec un dossier pour les artefacts d’observabilité, un déploiement Helm ou CI/CD simple et une synchro par Git Sync ou API/webhooks.
À un deuxième niveau, chaque équipe possède son repo et sa configuration d’observabilité (« You build it, you run it »). Le déploiement peut impliquer Kustomize. Cet outil de gestion intégré à Kubernetes se distingue de Helm en permettant de surcharger toute valeur d’une configuration de base.
À ce même niveau, on voit souvent apparaître une gestion GitOps (réconciliation automatisée avec Flux ou Argo CD). Et le recours au collecteur OpenTelemetry pour standardiser la collecte sans modifier la couche d’instrumentation.
Viennent ensuite les plates-formes d’observabilité. À ce niveau, les identités machine se généralisent dans les pipelines. Et, avec elles, les systèmes de promotion automatisée, le contrôle de cardinalité (liste blanche de tags, politiques d’échantillonnage avec des outils comme Cribl et Vector) voire l’exploitation d’eBPF.
« Tout le monde échantillonne la data. La seule raison pour laquelle on le fait, c’est le coût de stockage », explique à ce sujet Stéphane Estevez, EMEA Market Advisor observabilité chez Splunk. Sa société, poursuit-il, a l’avantage de la taille : « Par rapport à nos concurrents, nos économies d’échelle ne sont pas les mêmes. On peut se permettre d’être compétitif tout en garantissant toutes les données ».
Vodafone en est arrivé à ce dernier stade. Il a plus précisément mis en place des modules d’observabilité Terraform. Ses développeurs consomment en self-service (ils n’ont qu’à déclarer les variables) et peuvent les modifier par PR.
Vu le nombre de développeurs, de services et d’artefacts d’observabilité, il a fallu diviser le fichier d’état (Terraform mettait sinon 17 minutes à s’exécuter).
Accepter la codebase comme « source de vérité »
Que ce soit pour créer un dashboard lors d’un incident ou modifier des seuils afin de « faire taire » des alertes, dans une approche OaC, l’utilisation de l’UI soulève la question de la réconciliation avec la partie as code. Une des réponses consiste à n’autoriser que ce qui passe par cette dernière, au minimum en production. Une autre, à verrouiller les états pour éviter les corruptions.
« Si on pousse la logique OaC, il faut accepter que la source de vérité, c’est ce qui est dans la codebase », confirme Pejman Tabassomi, Field CTO EMEA de Datadog.
Quant à enrichir l’OaC avec du machine learning, ce n’est pas forcément si évident. IBM, qui a son Cloud Pak for AIOps (évolutions des outils de Tivoli), en témoigne par la voie d’Éric Cattoir. L’intéressé fait partie d’une équipe technique au niveau EMEA couvrant les sujets regroupés sous la marque IT Automation. « On a essayé de faire des modèles basés sur l’analyse des logs, explique-t-il. On s’est aperçu que cette fonctionnalité dépend beaucoup de la structure et de la stabilité des fichiers. Chez certains clients, ça a nécessité beaucoup de rééducation des modèles, car il y avait trop de variabilité entre leurs systèmes ».
* Dans le domaine de l’open source, le projet Perses, en sandbox à la CNCF, pousse une spécification ouverte pour la visualisation des données d’observabilité. Pour le moment, métriques Prometheus, traces Tempo, logs Loki et profilage Pyroscope. Il inclut un vérificateur statique, un opérateur Kubernetes et un CLI pour réaliser des actions dans les pipelines CI/CD. Des SDK Go et CUE implémentent l’approche « as code ».
Son développeur en fait part dans le cadre d’un point de situation concernant une attaque subie l’an dernier.
Entre juin et novembre, des utilisateurs ont été ciblés par l’intermédiaire de WinGUp, le gestionnaire de mises à jour intégré.
Ce dernier ne récupère pas directement les updates. Il se connecte à une URL qui lui fournit un fichier XML contenant le lien de téléchargement.
En compromettant le serveur partagé où était hébergée cette URL, des tiers – dits « probablement » à la solde de la Chine – ont pu intercepter le trafic. Puis modifier le lien de téléchargement et ainsi diffuser des fichiers malveillants… dont le gestionnaire de mises à jour n’a pas suffisamment contrôlé l’authenticité.
Début septembre, après une opération de maintenance (update du kernel et du firmware), les attaquants ont perdu l’accès au serveur. Ils ont toutefois conservé, pendant plusieurs semaines, les authentifiants des services hébergés.
La campagne aurait cessé le 10 novembre. On a connaissance d’une poignée de victimes, toutes ayant des intérêts en Asie orientale. Une conséquence possible des prises de position politiques du développeur de Notepad++. Nombre de nouvelles versions se sont effectivement accompagnées de messages de soutien aux Ouïghours ou à l’indépendance de Taïwan.
Notepad++, renforcé en plusieurs temps
La version 8.8.8 de Notepad++, publiée mi-novembre, avait apporté un premier correctif. Celui-ci force le préfixe de domaine de l’URL pour en empêcher la modification à la volée.
Début décembre, la version 8.8.9 a renforcé la validation d’authenticité et d’intégrité des fichiers téléchargés.
La version 8.9.2, attendue dans un mois environ, ajoutera la vérification du certificat et de la signature du fichier XML.
La version 8.8.7 avait introduit la signature de tous les binaires (dont WinGUp) avec un certificat GlobalSign. Depuis, il n’y a plus besoin d’installer le certificat racine de Notepad++. Cela a évité des faux positifs (on a recensé des cas de blocage par Avast, Defender, Trellix, etc.).
À consulter en complément, un point sur le protestware (détournement de logiciels à des fins politiques) réalisé peu après le début de la guerre en Ukraine.
Jean-Philippe Famin succède à Olivier Nautet et rejoint le Comité exécutif de l’IT du Groupe. Par ailleurs, il rapportera directement à Marc Camus, DSI du Groupe BNP Paribas.
Olivier Nautet quitte ses fonctions après 21 années au sein de BNP Paribas. En effet, il a décidé de se consacrer à un nouveau projet professionnel.
Missions
Dans son nouveau mandat, Jean-Philippe Famin poursuivra plusieurs travaux stratégiques. Il structurera notamment le pilotage des risques IT et Cyber à l’échelle du Groupe. Ainsi, il garantira le plus haut niveau de sécurité des systèmes d’information. De plus, il renforcera leur résilience.
« Nous nous réjouissons de l’arrivée de Jean-Philippe Famin dans ses nouvelles fonctions », déclare Marc Camus. « Les enjeux de cybersécurité sont ambitieux et structurants. Les opportunités le sont tout autant. Nous sommes convaincus que son expertise sera un atout majeur. Son engagement l’est également. » — Marc Camus, DSI du Groupe BNP Paribas
Parcours professionnel
Jean-Philippe Famin rejoint BNP Paribas en juin 2007. Il intègre alors les Fonctions IT. Il se spécialise dans le domaine de la messagerie bancaire.
Quatre ans plus tard, il rejoint l’Inspection Générale en tant qu’Inspecteur. Cette expérience lui permet d’obtenir une vision globale des entités de BNP Paribas.
Fin 2014, il intègre le département IT de BNP Paribas Real Estate. Il pilote le budget informatique. Simultanément, il assure la coordination internationale.
Il devient ensuite responsable de la Production Informatique et de la Sécurité. Puis, fin 2017, il accède au poste de CIO de BNP Paribas Real Estate.
Depuis mai 2020, il dirige la filière Production Security. Il l’a d’ailleurs fondée au sein du département Production. Son mandat couvre l’échelle de la Banque. Enfin, il bénéficie du soutien du CTO et du CISO du Groupe.
Le directoire de CDC Habitat a nommé Stéphane Duparay au poste de directeur des systèmes d’information (DSI) Groupe.
Après avoir débuté sa carrière dans le secteur industriel, il rejoint en 1998 le laboratoire pharmaceutique Cephalon, où il occupe pendant dix ans des fonctions IT en France et en Europe.
En 2008, il intègre SYSTRA, leader mondial des infrastructures de transport public, en tant que directeur des systèmes d’information Groupe. Pendant 15 ans, il y pilote la transformation digitale, la cybersécurité et l’intégration IT de 13 sociétés, accompagnant la croissance internationale du Groupe.
Depuis octobre 2024, Stéphane Duparay a occupé les fonctions de directeur numérique et risques du Groupe ADSN.
Il est diplômé de l’École Supérieure d’Ingénieur de Marseille (ESIM / ISMEA) et de Polytech Grenoble.
6 jours pour réagir face au « scandale ICE », c’est le temps qu’il a fallu à Capgemini. Et d’annoncer sa décision de vendre sa filiale américaine qui a signé et exécuté le contrat avec l’agence fédérale américaine. Selon le syndicat CFTC, elle a été adopté à l’issue d’un conseil d’administration exceptionnel convoqué durant le week-end.
Le 25 janvier, Aiman Ezzat, son directeur général avait choisi son compte LinkedIn pour expliquer que le groupe qu’il dirige n’avait quasiment aucun pouvoir de contrôle sur cette filiale américaine ( ce n’est pas la seule) baptisée Capgemini Government Solutions (CGS).
Exit donc toute responsabilité sur la signature du contrat avec l’Immigration and Customs Enforcement (ICE) pour un montant de 4,8 millions $. Son objet clairement indiqué dans les documents officiels publiés par l’agence fédérale américaine des achats, consistait à fournir des « services de recherche de personnes (skip tracing) pour les opérations d’exécution et d’expulsion ».
Un contrat interdit par la Charte éthique
La révélation avait provoqué de vives critiques émanant de ministres et de responsables politiques mais aussi des syndicats maison. Le 29 janvier, la CGT a ainsi lancé une pétition » Exigeons la fin de la collaboration entre Capgemi et l’ICE » qui a déjà reçue plus de cinq mille signatures.
Le 1er février, c’est finalement un communiqué officiel de quatre lignes, le seul depuis le début de l’affaire, qui annonce :
« Capgemini a estimé que les contraintes légales habituelles imposées aux Etats-Unis pour contracter avec des entités fédérales menant des activités classifiées ne permettaient pas au Groupe d’exercer un contrôle approprié sur certains aspects des opérations de cette filiale, afin d’assurer un alignement avec les objectifs du Groupe. Le processus de cession de cette entité, qui représente 0,4% du chiffre d’affaires estimé du Groupe en 2025 (moins de 2% de son chiffre d’affaires aux Etats-Unis), sera initié immédiatement. » Aucune date et aucune valorisation de la vente n’est évoqué.
Pas de regret exprimé non plus sur la dimension éthique de l’affaire. Pourtant, la CFTC est formelle : « La charte étique du groupe interdit ce genre de prestation attentatoire à la liberté et aux droits des personnes. Normalement, si les acteurs de cette affaire avaient respecté cette charte, ils n’auraient pas répondu à cet appel d’offre, ni signé le contrat.».
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.
L’année 2025 a marqué un tournant décisif dans l’adoption de l’intelligence artificielle en entreprise. Selon » l’étude annuelle de la transformation des organisations » du cabinet Lecko, nous assistons au passage de l’expérimentation à l’intégration structurelle de l’IA dans le flux de travail quotidien. Mais cette transformation s’accompagne de défis majeurs et de paradoxes qui obligent les organisations à repenser profondément leurs modes de fonctionnement.
De l’outil isolé à l’architecture IA cohérente
Les organisations ne peuvent plus se contenter de « choisir une IA ». Elles doivent désormais concevoir une architecture IA cohérente, capable d’articuler des modèles spécialisés comme Claude, GPT ou Mistral, des couches d’orchestration et des connecteurs de données basés sur le RAG (Retrieval Augmented Generation) pour garantir la fiabilité des réponses.
Cette évolution traduit une maturité nouvelle : l’IA ne se déploie plus au coup par coup, mais s’inscrit dans une stratégie d’ensemble.
L’avènement de l’IA agentique
Lecko e met en lumière le passage de l’IA générative simple à l’IA agentique, une évolution majeure qui transforme radicalement les processus métiers. Contrairement aux outils d’assistance classiques, un agent IA est capable d’exécuter des tâches de manière autonome, comme planifier une réunion ou traiter un processus RH, en interagissant directement avec l’environnement de travail.
Cette autonomie repose sur trois caractéristiques essentielles : la capacité d’analyse de situations complexes, l’élaboration de stratégies et l’interaction directe avec les outils existants comme les CRM, ERP ou agendas. L’IA agentique vise la substitution complète de tâches, et non plus seulement leur amélioration ou leur facilitation.
Une spécialisation par métiers
L’IA s’intègre désormais au cœur des processus spécifiques de chaque département.
Dans les ressources humaines, des solutions comme Workday Illuminate déploient des agents spécialisés pour automatiser le recrutement ou rédiger des contrats. ServiceNow Now Assist automatise le résumé d’incidents et la génération de workflows pour les équipes IT. Les équipes commerciales bénéficient d’agents capables de qualifier des leads ou de préparer des devis de manière autonome.
En 2026, la valeur se déplace vers des plateformes agentiques capables d’orchestrer plusieurs agents simultanément. Les éditeurs comme Jalios, Jamespot, LumApps ou Microsoft proposent des studios « low-code » permettant aux métiers de fabriquer leurs propres agents sur mesure. Des « méta-agents » ou concierges IA dirigent les requêtes vers l’agent le plus pertinent, interrogeant simultanément différentes bases de données.
Selon Gartner, en 2028, 15 % des décisions professionnelles quotidiennes seront prises de manière autonome par des agents IA. Cette perspective souligne l’ampleur de la transformation en cours.
Le paradoxe de la productivité
L’un des enseignements les plus importants de l’étude concerne ce que Lecko appelle le « paradoxe de la productivité ». Contrairement aux attentes, l’IA n’améliore pas automatiquement les rythmes de travail. Pour obtenir un gain réel, il faut viser les tâches de substitution, où l’IA remplace effectivement une action humaine, plutôt que les tâches de confort ou de renfort.
Si les gains de temps promis par l’IA ne sont pas utilisés pour substituer des tâches récurrentes, ils restent invisibles au niveau de l’organisation et peuvent même entretenir l’hyperconnexion. L’IA agit ainsi comme un révélateur : elle ne peut transformer les processus que si le patrimoine documentaire est sain et bien structuré. Elle devient inefficace si les règles métiers sont floues ou les données mal organisées.
Lutter contre le bruit organisationnel
Le bruit organisationnel, défini comme le surplus de sollicitations numériques non filtrées et non priorisées qui fragmentent l’attention, est l’un des fléaux de l’environnement de travail moderne. L’IA agentique offre plusieurs leviers pour le combattre.
Des systèmes comme l’Assistant Teamwork de Jamespot proposent des résumés intelligents de notifications et une priorisation des messages. Des outils comme Staffbase ou Sociabble utilisent l’IA pour segmenter les audiences et personnaliser les flux, évitant de diffuser des informations non pertinentes aux collaborateurs terrain.
L’émergence de méta-agents orchestrateurs permet de router les requêtes vers le bon agent spécialisé, évitant les allers-retours inutiles dans le système d’information. Des plateformes comme LumApps avec son Agent Hub ou Elium centralisent les connaissances pour répondre en langage naturel, réduisant le bruit lié aux recherches infructueuses.
L’écosystème agentique gagne également en attractivité en proposant des innovations comme le « zéro fichier » ou la structuration des connaissances, ce qui réduit structurellement la place centrale de l’email, premier vecteur de pollution informationnelle en entreprise.
L’optimisation des réunions : promesses et limites
L’IA peut contribuer à limiter l’inefficacité des réunions, mais avec des nuances importantes. Les outils actuels comme Copilot, Leexi ou Fireflies excellent dans la transcription, la génération de comptes-rendus et l’extraction de plans d’actions. En fournissant des synthèses préalables, l’IA permet de raccourcir les réunions et de limiter le nombre de participants nécessaires.
Cependant, l’étude souligne une limite technique majeure : la réunion hybride est particulièrement difficile à traiter pour l’IA, qui peine à identifier correctement les personnes présentes physiquement par rapport à celles en ligne.
De plus, l’IA agit comme un miroir de l’efficacité organisationnelle. Une réunion mal structurée ou sans animateur produira une synthèse médiocre. Le déploiement de l’outil seul ne suffit pas à améliorer les rythmes de travail ; il doit s’accompagner d’un questionnement sur la nécessité même de la réunion.
Les risques et limites de l’IA générative
L’étude alerte sur plusieurs risques significatifs.
Paradoxalement, l’IA peut aggraver la pollution informationnelle si elle n’est pas accompagnée d’une transformation des pratiques. La facilité de production peut saturer davantage l’environnement numérique, créant un effet « tapis roulant » où une part croissante des contenus est générée automatiquement sans forcément apporter de valeur ajoutée.
Le phénomène du « Shadow AI » est également préoccupant : environ 49 % des utilisateurs en entreprise ont recours à l’IA sans en informer leur hiérarchie, ce qui contribue à fragmenter la Digital Workplace et complique la maîtrise des flux d’informations.
Des études alertent également sur une baisse des capacités cognitives et mémorielles des utilisateurs. La présence d’une IA peut encourager les participants à être moins attentifs, comptant sur le résumé automatique pour rattraper ce qu’ils ont manqué, un effet qualifié « d’endormissement au volant ».
Enfin, l’impact environnemental est colossal : la consommation d’électricité des data centers pourrait doubler d’ici 2026, soulevant des questions urgentes sur la soutenabilité de cette révolution technologique.
Connexion
