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.
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.
Avec seulement 3 magistrats traitant les dossiers de cybercriminalité, la France accuse une véritable carence sur le volet judiciaire.
La CSNP (Commission supérieure du numérique et des postes) avait fait ce diagnostic au printemps 2021. Il était inscrit dans une série de recommandations sur la sécurité numérique. En toile de fond, la stratégie nationale pour la cybersécurité, annoncée quelques semaines plus tôt.
La CSNP notait que cette stratégie n’abordait pas le volet du traitement policier et judiciaire de la cybercriminalité. Elle encourageait les pouvoirs publics à étudier la création d’un parquet national cyber et à porter la même approche au niveau européen. Autres recommandations : consolider le dispositif des référents cybercriminalité auprès de chaque cour d’appel et dispenser aux magistrats des formations spécifiques.
La nouvelle stratégie nationale pour la cybersécurité, présentée le 29 janvier 2026, n’entre pas dans ce niveau de détail, mais l’État y promet un « renforcement de la réponse judiciaire ». Il s’engage, en parallèle, à mieux mobiliser d’autres leviers pour « décourager les agressions cyber » : sanctions, capacités cyber offensives et capacités de recueil de renseignement.
Où l’on parle désormais de féminisation du numérique
Un autre aspect non évoqué dans la stratégie précédente est la féminisation des métiers du numérique. Désormais, on nous promet un programme de mentorat spécifique pour les jeunes filles, capitalisant sur le retour d’expérience des initiatives existantes. En complément, il est question d’intégrer de la cybersécurité dans les dispositifs d’engagement civique à destination de la jeunesse.
Le sujet de la féminisation figurait dans les observations de la CSNP. La commission avait notamment appelé les pouvoirs publics à renforcer leurs soutiens à la fondation Femmes@Numérique… alors présidée par l’une de ses membres*.
Parmi ses recommandations figurait aussi l’accélération de la mise en œuvre des ambitions de l’Appel de Paris. À travers lui, la France avait, en 2018, impulsé un ensemble de principes et de valeurs communes pour un cyberespace « libre, sûr et ouvert ». La CNSP espérait que leur traduction en mesures opératoires soit portée auprès de l’UE dans le cadre de la présidence française en 2022.
La nouvelle stratégie nationale de cybersécurité (2026-2030) mentionne l’Appel de Paris. L’État affirme vouloir poursuivre l’animation de la communauté qui en est née. Et le soutien des initiatives internationales connexes visant à mettre en œuvre les principes. À ce titre, la France poursuivra son implication dans le processus de Pall Mall, destiné à contrer l’utilisation abusive des capacités d’intrusion cyber disponibles sur le marché.
Le Campus Cyber, aux abonnés absents
La stratégie de 2021 accordait une grande place au Campus Cyber, alors en phase de préfiguration. Une enveloppe de 148 M€ – dont la moitié en fonds publics – devait y être dédiée. L’État se projetait également sur les déclinaisons régionales de ce « lieu totem », en phase avec la mise en place des CSIRT territoriaux.
Pas de référence au Campus Cyber dans la nouvelle stratégie, quand bien même sont évoqués de nombreux enjeux que son action est censée couvrir.
A contrario, des organismes non cités dans l’ancienne stratégie le sont cette fois-ci. Parmi eux, l’InterCERT, pour le renforcement du partage d’informations techniques sur les menaces entre services de l’État et acteurs privés. Il y a aussi ceux qui n’existaient pas encore, comme l’INESIA et le 17Cyber. Le premier doit accompagner les initiatives d’investissement dans la recherche sur les risques et opportunités de l’IA. Le second fera l’objet d’une intégration dans un « portail national de la cybersécurité du quotidien ».
Des critères cyber dans les dispositifs d’aides d’État
Pour le grand public, on nous parle aussi d’un « filtre de cybersécurité […] visant à prévenir l’accès aux sites web malveillants ». Et d’une « marque nationale de prévention du risque numérique ». Elle portera des campagnes de sensibilisation sur le modèle de celles de la prévention routière.
Pour les entreprises, la feuille de route comprend un label de confiance destiné à valoriser les efforts de sécurisation. L’État envisage par ailleurs d’intégrer des critères de cybersécurité dans ses dispositifs d’aides, « à l’instar de France 2030 ».
Concernant les fournisseurs de produits et services de cybersécurité, la France affirme sa volonté de rechercher des synergies entre domaines civil et militaire. Entre autres ambitions figurent le soutien à la filière d’évaluation de sécurité et la maîtrise des technologies critiques dans le domaine de la cryptographie. L’accompagnement à la mise en œuvre du CRA (Cyber Resilience Act) est un autre objectif. Cela passera par un renforcement de la politique nationale de gestion coordonnée des vulnérabilités. Et par un soutien à la recherche sur la sécurité des produits open source.
* Christine Hennion, députée des Hauts-de-Seine sous le premier mandat d’Emmanuel Macron. Aujourd’hui conseillère municipale de Courbevoie.
Si la souveraineté numérique mobilise les décideurs politiques, l’enjeu n’est pas aussi partagé par les agents publics.
Selon une enquête Ipsos réalisée pour le cabinet Lecko, seuls 12% des agents publics interrogés attendent explicitement que leur administration privilégie la souveraineté dans l’évolution de leurs outils numériques de travail.
Pour l’écrasante majorité d’entre eux (88%), d’autres critères priment largement sur les considérations de souveraineté. Leur priorité numéro : l’efficacité des outils au quotidien. Qu’ils soient français, européens ou américains, les agents attendent des solutions qui fonctionnent, répondent à leurs besoins réels et leur permettent d’ accomplir leurs missions dans de bonnes conditions.
Cette position pragmatique se manifeste d’ailleurs par un phénomène révélateur : 60% des répondants reconnaissent avoir recours au « Shadow IT », c’est-à-dire à l’utilisation d’applications non validées par leur direction informatique. Une forme de vote avec les pieds qui prouve que les solutions officielles – qu’elles soient souveraines ou non – ne répondent pas toujours aux attentes du terrain.
L’efficacité avant la géopolitique
Ce faible niveau d’attente vis-à-vis de la souveraineté interroge à plusieurs niveaux. D’abord sur la maturité du sujet côté utilisateurs : le concept de souveraineté numérique, bien que globalement compris, ne résonne pas comme une urgence dans le quotidien professionnel. Les menaces juridiques liées à l’extra-territorialité des lois américaines, les risques pesant sur la confidentialité des données ou les enjeux d’indépendance technologique restent perçus comme des préoccupations lointaines, déconnectées des réalités opérationnelles.
Mais ce désintérêt questionne aussi la capacité des organisations publiques à porter une vision alternative crédible. Comment convaincre les agents d’adhérer à un projet de souveraineté si les solutions proposées n’offrent pas une expérience utilisateur équivalente ou supérieure à celle des géants américains ? Quelques pionniers dans le désert
Malgré ce contexte peu favorable, quelques collectivités tentent l’aventure. La Région Occitanie, la Ville de Marseille, Chamonix, Grenoble ou Lyon abandonnent progressivement les suites logicielles américaines au profit de solutions libres et open source. Ces initiatives restent toutefois marginales dans un paysage largement dominé par Microsoft, qui équipe 75% des organisations de plus de 250 collaborateurs.
Ces expériences pionnières, pour louables qu’elles soient, buttent sur les mêmes obstacles : la résistance au changement, les questions de compatibilité, et surtout le décalage entre l’ambition politique affichée et l’adhésion réelle des utilisateurs finaux.
Un triple défi à relever
Pour que la souveraineté numérique devienne une réalité dans les administrations françaises, trois défis majeurs doivent être relevés. D’abord, réconcilier les ambitions stratégiques des décideurs avec les attentes pragmatiques des agents. Ensuite, proposer des solutions souveraines qui ne soient pas perçues comme un sacrifice en termes d’efficacité ou d’ergonomie. Enfin, investir massivement dans la formation et l’accompagnement au changement pour faire comprendre les enjeux de long terme.
Sans adhésion du terrain, les projets de souveraineté risquent de rester au stade de l’intention politique, incapables de se traduire en transformation concrète des pratiques.
Attention, Wiz pourrait servir de cheval de Troie à Google.
La Commission européenne est d’autant plus alertée à ce sujet depuis qu’elle a commencé à examiner le projet d’acquisition. C’était début janvier. Au plus tard le 10 février, on saura si elle donne son feu vert ou si elle ouvre une enquête approfondie.
L’argument du « cheval de Troie » se résume ainsi : les solutions de Wiz donneraient à Google une visibilité sur l’usage des clouds concurrents. Et donc des informations potentiellement précieuses pour adapter son offre. Une situation similaire à celle d’Amazon vis-à-vis des vendeurs tiers sur sa marketplace.
À cet argument, le CISPE (Cloud Infrastructure Service Providers in Europe) en ajoute un autre : le risque de remise en cause de la neutralité de Wiz. Certes, Google a promis de la maintenir. Mais, à en croire le lobby des CSP européens, il aura la capacité – et l’intérêt – d’instaurer des conditions de licence plus favorables sur son propre cloud.
Le CISPE dit s’inquiéter d’autant plus que les services cloud n’entrent pour le moment pas dans le champ du DMA. Il invite Bruxelles à ne pas « répéter les erreurs commises » dans le dossier Broadcom-VMware.
Les États-Unis ont déjà validé
À 32 Md$, cette acquisition serait la plus chère que Google ait jamais réalisée, devant celles de Motorola Mobility (12,5 Md$ en 2012) et de Mandiant (5,4 Md$ en 2022). Elle suscite aussi des craintes de vente liée. Et plus globalement d’autopréférence : Wiz pourrait ne plus développer de solutions allant contre les intérêts commerciaux de Google.
Les autorités américaines ont déjà donné leur blanc-seing, en octobre 2025. Les conditions étaient semble-t-il plus favorables que l’année précédente, où Wiz avait d’ailleurs refusé une première offre de Google à 23 Md$. L’obstacle antitrust aurait joué, a fortiori à l’heure où Google était encore sous la menace d’un démantèlement.
Parmi les derniers grands projets M&A tech que l’UE n’a pas validés, il y a le rapprochement entre Adobe et Figma. Annoncé à 20 Md$, il fut abandonné fin 2023. Quelques semaines plus tard, Amazon avait renoncé à s’emparer d’iRobot, pour des raisons similaires.
Connexion
