Qu'est-ce que vLLM et pourquoi est-il important pour une inférence IA ?

vLLM est un moteur d'inférence haute performance pour les grands modèles de langage. Il implémente PagedAttention pour maximiser l'utilisation de la VRAM et servir plusieurs requêtes en parallèle. Déployé sur Kubernetes, il expose une API compatible OpenAI qui facilite la migration des applications existantes. En production, vLLM atteint 3 à 5 fois le débit d'une implémentation naive du même modèle.

Quelle est la différence entre une usine IA et l'utilisation de ChatGPT ou AWS Bedrock ?

Trois différences fondamentales : la souveraineté des données (vos données ne quittent jamais votre datacenter), des coûts prévisibles (pas de mauvaises surprises sur la facture GPU) et l'absence de vendor lock-in (tout le stack est open source et portable). L'on-premise permet également de faire tourner des modèles fine-tunés propriétaires sans exposer les poids à des tiers.

Le déploiement d'une usine IA on-premise est-il conforme au RGPD et à l'AI Act ?

C'est précisément pour ça que l'on-premise est la réponse architecturale de référence pour la conformité. Le RGPD impose de savoir exactement où les données sont traitées. L'AI Act, dont les sanctions sont applicables depuis le 2 août 2025, exige traçabilité et contrôle pour les systèmes à haut risque. Avec une infrastructure propre, vous maîtrisez les deux.

Peut-on atteindre la conformité NIS2 avec des logiciels libres ?

Oui. La directive NIS2 prescrit des résultats, pas des produits. Des outils comme Wazuh (SIEM/XDR), Ansible (durcissement), OpenVAS/GVM (gestion des vulnérabilités), Keycloak (IAM/MFA) et pfSense/OPNsense (périmètre) couvrent la grande majorité des mesures techniques de l'article 21 — sans frais de licence.

La France a-t-elle transposé NIS2 ?

Non encore. La France a manqué la date limite d'octobre 2024. Le projet de loi Résilience (qui transpose simultanément NIS2, la directive REC et le règlement DORA) a été adopté en première lecture au Sénat en mars 2025. Son entrée en vigueur est attendue en 2026. En Belgique, la loi du 26 avril 2024 est déjà en vigueur.

Qu’est-ce qu’une usine IA et comment la construire avec l’open source

6 mars 2026/dans Informations/par Alba Martinez

Infrastructure IA · Mars 2026

Qu’est-ce qu’une usine IA et comment la construire avec l’open source dans votre datacenter

Le concept d’AI Factory est sur toutes les lèvres depuis deux ans — mais peu d’organisations comprennent réellement ce qu’il implique techniquement, ni comment le mettre en œuvre sans dépendre d’un fournisseur cloud. Voici une explication sans détour, avec le stack concret que nous utilisons en production.

Mars 2026●20 min de lecture

Une usine IA n’est pas un serveur équipé d’un GPU avec un modèle téléchargé depuis Hugging Face. C’est une infrastructure de calcul distribuée, conçue pour exécuter des modèles de langage et de vision en production de façon continue, à grande échelle et sous contrôle total de l’organisation. La bonne nouvelle : la construire n’est plus réservé aux géants du numérique. La technologie open source qui propulse l’AI Factory du Barcelona Supercomputing Center et les programmes d’infrastructure souveraine à travers l’Europe est accessible à toute organisation disposant de son propre datacenter. Ce qui suit est un guide pratique : ce dont vous avez besoin, ce dont vous n’avez pas besoin, et comment décider si cela a du sens pour vous.

Un peu de contexte

Qu’est-ce qu’une usine IA exactement ?

Le terme « AI Factory » a été popularisé par Jensen Huang de NVIDIA en 2023 pour décrire ce que deviennent les centres de données : des machines qui produisent de l’intelligence en continu, à la manière d’une usine qui fabrique des biens. La métaphore n’est pas poétique — elle est techniquement précise.

Une usine IA classique comprend quatre composantes distinctes : un système de stockage pour les poids des modèles et les datasets (qui pèsent des dizaines voire des centaines de gigaoctets), une couche de calcul GPU pour exécuter l’inférence, un orchestrateur qui gère quel modèle tourne sur quel matériel, et une API qui expose les modèles au reste de l’organisation. Quand ces quatre composantes fonctionnent efficacement ensemble, vous avez une usine IA.

Ce qui la distingue d’un « LLM qui tourne sur un serveur », c’est l’échelle, la fiabilité et la gestion. Une usine IA sert plusieurs modèles en parallèle, gère des files d’attente de requêtes, garantit la disponibilité et surveille l’utilisation des ressources. C’est de l’infrastructure de production — pas un environnement de test.

Chiffre clé

La Commission européenne a engagé plus de 1,5 milliard d’euros pour construire des AI Factories réparties dans les États membres dans le cadre du programme EuroHPC. L’objectif explicite est que l’Europe dispose d’une infrastructure IA souveraine, sans dépendance envers les fournisseurs américains ou asiatiques. L’Espagne participe via le BSC à Barcelone. La même stack technologique qu’ils utilisent peut être déployée dans votre datacenter.

Pourquoi rapatrier l’inférence IA ?

Pourquoi les organisations rapatrient leur inférence IA on-premise

Trois arguments reviennent systématiquement dans chaque conversation que nous avons avec des clients qui évaluent une infrastructure IA propre. Ce ne sont pas des arguments marketing : ce sont des réalités opérationnelles et financières.

Coûts prévisibles

Les factures GPU en cloud public peuvent varier de 30 à 40 % d’un cycle de facturation à l’autre selon la demande. Avec une infrastructure propre, le coût est fixe, amortissable et sans surprise. À partir d’un volume d’inférence moyen, l’investissement est récupéré en 12 à 18 mois par rapport au cloud.

Zéro vendor lock-in

APIs propriétaires, formats fermés, modèles fine-tunés hébergés chez un tiers. Avec un stack open source, vos modèles et vos données vous appartiennent — toujours portables, sans négociations de sortie ni contrats bloquants.

?️

Conformité réglementaire

Le RGPD et l’AI Act exigent de savoir précisément où les données sont traitées. Si votre inférence touche des données de patients, de citoyens ou de clients bancaires, vous avez besoin d’un contrôle total sur l’infrastructure. L’on-premise est la seule réponse architecturalement viable.

AI Act — sanctions actives depuis août 2025

Depuis le 2 août 2025, la deuxième phase de l’AI Act est entrée en vigueur : les règles sur les modèles GPAI et les premières sanctions sont applicables. Les amendes peuvent atteindre 35 millions d’euros ou 7 % du chiffre d’affaires mondial en cas de non-conformité. La Belgique ne dispose pas encore de législation nationale spécifique, mais les obligations européennes s’appliquent sans exception. La maîtrise de l’infrastructure d’inférence est le premier levier de conformité.

La question n’est plus de savoir s’il faut construire sa propre infrastructure IA, mais quand et comment le faire sans répéter les erreurs de la ruée vers le cloud il y a dix ans : vitesse sans architecture.
— Équipe technique SIXE

Cela dit, une usine IA on-premise n’est pas adaptée à tout le monde. Si vous traitez dix requêtes d’inférence par jour et n’avez pas de contraintes réglementaires strictes, le cloud est probablement la bonne réponse pour l’instant. L’on-premise commence à avoir du sens quand les volumes sont soutenus, quand les données sont sensibles, ou quand vous devez faire tourner des modèles fine-tunés propriétaires sans exposer les poids à des tiers.

Concrètement, comment ça se construit ?

Le stack open source : trois technologies, zéro dépendance propriétaire

Une combinaison de trois technologies a émergé comme standard de facto pour construire des usines IA on-premise dans les environnements d’entreprise européens. Le même stack que le BSC. Le même que celui qui propulse les infrastructures souveraines en France, en Allemagne et en Italie. Et le même que celui que nous déployons chez SIXE.

Ceph : le stockage distribué conçu pour l’IA

Les modèles de langage sont lourds. Llama 3 70B occupe environ 40 Go en précision float16. Mixtral 8x7B avoisine les 90 Go. Un catalogue raisonnable de modèles pour une organisation de taille moyenne peut facilement dépasser 500 Go — sans compter les datasets de fine-tuning ni les journaux d’inférence.

Ceph résout ce problème avec un stockage distribué qui unifie l’object storage (compatible S3 nativement), le block storage et le filesystem dans un seul cluster. Il évolue des téraoctets aux pétaoctets sans interruption, supporte l’erasure coding pour l’efficacité du stockage et dispose d’une intégration native avec Kubernetes via CSI. Dans une usine IA, Ceph constitue la colonne vertébrale où résident les poids des modèles, les datasets et les résultats d’inférence.

Perspective SIXE

Nous sommes Canonical Partner et déployons des clusters Ceph en production depuis des années, y compris dans des environnements IA et HPC. Ceph ne s’active pas d’un simple clic : il nécessite un dimensionnement soigné, une conception réseau adaptée et des politiques de réplication calibrées à la charge. Sur les clusters à 3 nœuds, les considérations de quorum ne s’improvisent pas. Nous proposons une formation dédiée et un support pour que votre équipe opère Ceph en toute autonomie — sans dépendance de conseil permanente.

OpenStack : votre cloud privé avec gestion native des GPU

OpenStack transforme votre matériel en cloud privé d’entreprise. Pour une usine IA, son rôle principal est la gestion des ressources GPU : PCI passthrough pour un accès direct au GPU depuis les VMs, vGPU pour partager un GPU physique entre plusieurs charges de travail, et NVIDIA MIG (Multi-Instance GPU) pour partitionner les GPU A100 et H100 en instances indépendantes.

Sous la Linux Foundation depuis 2024, OpenStack fonctionne en production sur plus de 45 millions de cœurs dans des organisations comme Walmart, GEICO ou LINE Corp. Il ne s’agit pas d’une technologie émergente — c’est une infrastructure éprouvée à grande échelle, avec une gouvernance indépendante qui en garantit la pérennité.

Point d’attention

OpenStack n’est pas trivial. Il couvre plus de 30 projets de services et nécessite des équipes expérimentées en systèmes distribués. Si votre équipe vient d’un environnement VMware, la courbe d’apprentissage existe. Notre service de formation couvre la montée en compétences pratique pour que votre équipe puisse opérer le stack en autonomie — sans dépendance de conseil à long terme.

Kubernetes + vLLM : la couche d’orchestration de l’inférence

Kubernetes est le standard CNCF pour l’orchestration de charges de travail conteneurisées, avec planification GPU native via le NVIDIA GPU Operator. Les moteurs d’inférence sont déployés sur Kubernetes — et vLLM est le plus pertinent pour les modèles de langage actuellement.

vLLM implémente PagedAttention, une technique qui gère efficacement la mémoire KV cache et permet de servir plusieurs requêtes en parallèle sans gaspiller la VRAM. En production, vLLM atteint 3 à 5 fois le débit d’une implémentation naïve du même modèle. Il expose une API compatible OpenAI, ce qui facilite la migration des applications qui consomment déjà GPT-4 ou des modèles similaires.

Pour les modèles de vision ou d’embedding, Triton Inference Server de NVIDIA complète vLLM et permet des optimisations matérielles spécifiques comme TensorRT-LLM.

Quelle forme prend concrètement une usine IA ?

Architecture de référence : de la donnée au modèle en production

Une usine IA on-premise avec ce stack suit un flux en quatre couches. Ce n’est pas le seul design possible, mais c’est celui qui équilibre le mieux la complexité opérationnelle, les performances et la portabilité.

01 — Données

Ceph S3

Modèles, datasets, résultats d’inférence. API compatible S3 pour l’intégration avec les pipelines MLOps.

02 — Calcul

OpenStack

Planification GPU, bare metal, réseaux isolés par projet. PCI passthrough et MIG pour une efficacité maximale.

03 — Orchestration

Kubernetes

GPU Operator, autoscaling des pods d’inférence, gestion du cycle de vie des déploiements.

04 — Production

vLLM / Triton

APIs d’inférence, RAG, agents. Compatibilité OpenAI pour une intégration sans friction.

La clé de ce design : chaque couche est indépendante et remplaçable. Si demain un meilleur orchestrateur que Kubernetes émerge pour les charges IA, vous pouvez le substituer sans toucher au stockage ni à la couche de calcul. C’est ce que signifie vraiment l’absence de vendor lock-in : pas seulement que le logiciel est open source, mais que l’architecture dispose d’une réelle séparation des responsabilités.

Composant

Rôle dans l’usine IA

Alternatives viables

Gouvernance

Ceph

Stockage des modèles et des données

IBM Storage Scale (GPFS)

Linux Foundation

OpenStack

Cloud privé avec gestion GPU

MaaS + bare metal direct

OpenInfra / LF

Kubernetes

Orchestration de conteneurs

MicroK8s, OpenShift

CNCF / LF

vLLM

Moteur d’inférence LLM

Triton, TensorRT-LLM

Apache 2.0

Ubuntu / Canonical

OS de base + support du stack

RHEL, SUSE

Canonical Partner

Est-ce adapté à mon organisation ?

Qui a réellement besoin d’une usine IA on-premise

Tous les secteurs n’ont pas la même urgence ni les mêmes contraintes. Dans quatre domaines, l’infrastructure IA propre n’est pas une préférence — c’est la seule réponse architecturalement viable.

Santé et pharma

Dossiers cliniques, imagerie diagnostique, données génomiques. Le RGPD et le règlement européen sur l’espace des données de santé imposent des restrictions strictes sur les transferts vers des pays tiers. L’inférence on-premise est l’architecture de conformité par défaut.

Banque et assurance

Scoring de crédit, détection de fraude, analyse de risque. Les lignes directrices de l’ABE sur l’IA dans les services financiers et l’AI Act classent ces systèmes comme à haut risque, avec des exigences de traçabilité et de contrôle que seule une architecture on-premise peut satisfaire.

?️

Secteur public et défense

Souveraineté numérique, NIS2, données classifiées. La stratégie européenne d’IA exige que les systèmes IA à usage public opèrent sur une infrastructure européenne ou nationale. Sans discussion possible.

Industrie et manufacture

Vision artificielle en ligne de production, maintenance prédictive, contrôle qualité. La latence du cloud n’est pas viable quand vous avez besoin d’une réponse en millisecondes sur le site de production. L’inférence edge ou dans votre propre datacenter est le seul modèle qui fonctionne.

FAQ

Les questions à se poser avant de commencer

Construire une usine IA on-premise n’est pas un projet de week-end. Cela nécessite une analyse préalable honnête sur quatre dimensions qui déterminent si c’est pertinent et comment bien l’exécuter.

Quels modèles allez-vous servir et à quels volumes ?

Le dimensionnement GPU dépend directement de la taille des modèles (nombre de paramètres et précision) et des objectifs de débit (requêtes par seconde, latence P99 acceptable). Un modèle de 7 milliards de paramètres en float16 tient dans un seul GPU L40S de 48 Go de VRAM. Un modèle de 70 milliards nécessite plusieurs GPU avec du tensor parallelism. Il n’y a pas de raccourcis ici : un dimensionnement correct exige de connaître les charges réelles, pas des estimations optimistes.

Votre équipe a-t-elle la capacité d’opérer ce stack ?

C’est la question la plus importante — et celle que l’on pose le moins souvent. Une équipe avec une expérience en Linux, Kubernetes et systèmes distribués peut apprendre à opérer ce stack. Mais si vous partez de zéro, la courbe d’apprentissage doit être intégrée au plan, pas oubliée. SIXE propose des formations certifiées en Ceph, OpenStack et Kubernetes (en tant qu’IBM Business Partner et Canonical Partner) précisément pour que la transition ne crée pas de dépendance de conseil indéfinie.

Quel est le TCO réel sur 3 ans ?

Le logiciel est open source, donc il n’y a pas de coûts de licences. L’investissement porte sur le matériel (GPU, serveurs, réseau haute performance) et la montée en compétences de l’équipe. Comparé au coût des GPU cloud au même volume d’inférence sur cette période, les chiffres parlent généralement d’eux-mêmes. Mais le modèle financier doit inclure la maintenance, les mises à jour et le temps d’exploitation de l’équipe. Rien n’est gratuit — et les projets qui partent de ce postulat se retrouvent souvent face à de mauvaises surprises.

Comment nous travaillons chez SIXE

Avant tout déploiement, nous réalisons une évaluation d’architecture : nous auditons vos charges de travail réelles, vos exigences de latence, vos volumes de données et vos obligations réglementaires. Nous livrons un design complet — dimensionnement GPU, topologie réseau, architecture de stockage Ceph et plan de capacité sur 12 à 24 mois. Pas de promesses d’économies non calculées. Seulement une analyse technique sur la pertinence du projet et la façon de l’exécuter.

Vous avez un projet d’inférence IA ?

Votre usine IA, avec le stack que nous utilisons nous-mêmes

IBM Business Partner et Canonical Partner. Plus de 15 ans à déployer de l’open source en production. Nous concevons l’architecture, formons votre équipe et vous accompagnons jusqu’à ce que l’infrastructure fonctionne seule. Notre travail se termine quand le vôtre commence vraiment.

Voir le service d’inférence →
Écrivez-nous sur WhatsApp

10 erreurs d’architecture et de ROI dans l’exode post-VMware

27 février 2026/dans Centre de données, Informations/par Alba Martinez

Analyse technique · Février 2026

10 erreurs d’architecture et de ROI que personne n’a évaluées dans l’exode post‑VMware

Les alternatives VMware open source sont viables. Mais « viable » et « adapté à votre entreprise » sont des questions radicalement différentes qui exigent une analyse technique, financière et de gouvernance avant d’engager votre infrastructure pour une décennie.

Février 2026●25 min de lecture●Pour DSI, CTO et Directeurs d’Infrastructure

86 % des clients VMware réduisent activement leur empreinte. Seuls 4 % ont achevé la migration. Entre ces deux chiffres se trouve un gouffre de décisions techniques, financières et stratégiques que la plupart des organisations prennent avec plus de précipitation que de méthode. Cet article ne recommande aucune plateforme : il pose les questions que toute équipe dirigeante devrait se poser avant d’engager son infrastructure pour les 5 à 10 prochaines années. Spoiler : il n’y a pas de réponse magique, mais il y a un chemin raisonnable.

Erreur 01 sur 10

Confondre urgence et stratégie

L’acquisition de VMware par Broadcom en novembre 2023 pour 61 milliards de dollars a déclenché le plus grand séisme dans la virtualisation d’entreprise depuis plus d’une décennie. Et le mot « séisme » est encore en dessous de la réalité. Licences perpétuelles supprimées, ~8 000 SKUs consolidés en 4 bundles, minimum d’achat de 72 cœurs et hausses de prix rapportées entre 150 % et 1 500 %. Tesco a déposé une plainte de 100 millions de livres. Fidelity a alerté sur des risques pour 50 millions de clients. Autant dire que le paysage invitait à courir.

Et c’est exactement ce qui s’est passé : beaucoup ont couru, mais pas toujours dans la bonne direction. Une enquête CloudBolt (2026) a révélé que 63 % ont changé leur stratégie de migration au moins deux fois (oui, deux fois). Gartner estime que la part de marché de VMware passera de 70 % à 40 % d’ici 2029, mais le chemin jusque-là est parsemé de virages qui méritent nettement plus de réflexion qu’ils n’en reçoivent.

Perspective SIXE

L’urgence créée par Broadcom est parfaitement compréhensible — personne n’aime voir sa facture multipliée du jour au lendemain. Mais chaque décision d’infrastructure prise sous pression devient de la dette technique que vos équipes hériteront pendant des années. La première bonne décision est de séparer la réponse tactique immédiate de la stratégie à moyen terme et d’évaluer chacune avec des critères différents. Respirez, planifiez, puis agissez.

Erreur 02 sur 10

Ignorer la gouvernance du projet open source

Tout l’open source ne se vaut pas — loin de là. La différence la plus pertinente pour une décision d’entreprise à long terme n’est pas la licence, mais quelque chose que presque personne ne vérifie : qui contrôle le projet et quels mécanismes protègent la communauté si les priorités commerciales changent.

Proxmox Server Solutions GmbH est une entreprise privée autrichienne avec un capital social de 35 000 € et une équipe estimée entre 14 et 24 personnes. Des gens formidables, certainement, mais il n’existe ni fondation indépendante, ni conseil de gouvernance ouvert, ni représentation communautaire dans les décisions de développement. Autrement dit : l’avenir de votre plateforme de virtualisation dépend des choix d’une seule entreprise.

Comparez avec la Fondation MariaDB, où aucune entreprise ne peut occuper plus de 25 % des sièges au conseil — un mécanisme qui a protégé le projet lorsque MariaDB Corporation a été rachetée par K1 en septembre 2024. Ou avec OpenStack, désormais sous la Linux Foundation, avec une gouvernance distribuée entre des centaines d’organisations. Ça, c’est un filet de sécurité.

Question clé

Votre plateforme de virtualisation — celle sur laquelle tourneront vos applications métier pendant les 10 prochaines années — est-elle gouvernée par une fondation indépendante, un consortium ou une seule entreprise privée de moins de 25 employés ? Ce n’est pas une question rhétorique : la réponse a des implications directes sur le risque de verrouillage fournisseur à long terme.

Erreur 03 sur 10

Ne pas lire le Contributor Licence Agreement

On sait — lire un CLA n’est pas exactement un programme de vendredi soir. Mais ça vaut le coup. Le CLA de Proxmox accorde à l’entreprise une licence perpétuelle, mondiale et irrévocable sur toutes les contributions, avec le droit de les relicencier sous des termes commerciaux ou propriétaires. Ce mécanisme n’est pas problématique en soi, mais c’est exactement la combinaison structurelle (entreprise unique + AGPL + CLA permissif) qui a précédé chaque changement de licence majeur des sept dernières années. C’est un peu comme voir les nuages d’orage s’accumuler et dire « je suis sûr qu’il ne pleuvra pas ».

Projet	Année	Changement	Conséquence	Gouvernance
MongoDB	2018	AGPL → SSPL	Retiré de Debian/Red Hat	Single vendor
Elasticsearch	2021	Apache 2.0 → SSPL	Fork : OpenSearch (Linux Foundation)	Single vendor
HashiCorp	2023	MPL 2.0 → BSL	Fork : OpenTofu · IBM : 6,4 Mds $	Single vendor
Redis	2024	BSD → SSPL	Fork : Valkey (Linux Foundation)	Single vendor
MinIO	2021–26	Apache → AGPL → Abandonné	Dépôt : « NO LONGER MAINTAINED »	Single vendor
Kubernetes	—	—	Apache 2.0 stable	Fondation (CNCF)
PostgreSQL	—	—	Licence PostgreSQL stable	Communauté
Linux	—	—	GPLv2 stable	Fondation (LF)

Vous voyez le schéma ? Il est assez limpide : aucun projet soutenu par une fondation indépendante n’a jamais subi un changement de licence unilatéral. Pas un seul. Ce constat devrait nourrir toute évaluation de risque, quelle que soit la plateforme envisagée.

Erreur 04 sur 10

Supposer que les coûts d’abonnement resteront stables

Toute entreprise qui développe du logiciel open source a besoin de monétiser son travail, et c’est parfaitement légitime — personne ne vit d’amour et d’eau fraîche. La question n’est pas de savoir si les prix augmenteront (ils augmenteront, comme partout), mais si vous les intégrez dans votre modèle de coût total de possession.

L’abonnement Community de Proxmox est passé de 49,90 € à 120 €/an (~140 % d’augmentation), et en janvier 2026, tous les niveaux ont augmenté de 3,8 à 4,3 %. Le nouveau Proxmox Datacenter Manager exige qu’au moins 80 % des nœuds disposent d’un abonnement Basic ou supérieur (370+ €/socket/an). Ça vous rappelle quelque chose ? À nous aussi.

OpenStack, Ceph et les autres alternatives VMware ont aussi leurs propres structures de coûts. Aucune plateforme n’est gratuite en production — si quelqu’un vous dit le contraire, souriez poliment et demandez la facture. La vraie différence réside dans les coûts prévisibles et ceux qui dépendent de décisions unilatérales.

Perspective SIXE

Lorsque nous évaluons des alternatives avec nos clients, nous modélisons toujours trois scénarios de coûts : optimiste, réaliste et défavorable, avec des projections à 5 et 10 ans intégrant d’éventuels changements de licences. Oui, c’est plus de travail. Mais c’est aussi la seule façon de construire un TCO qui ne s’effondre pas au premier changement de tarif.

Erreur 05 sur 10

Sous-estimer la complexité opérationnelle d’OpenStack

Soyons justes avec OpenStack : il tourne en production avec plus de 45 millions de cœurs dans des organisations comme Walmart, GEICO ou LINE Corp. Sa gouvernance — désormais sous la Linux Foundation — est parmi les plus solides de l’écosystème. Ce sont de véritables atouts.

Mais (il y a toujours un mais) le projet lui-même reconnaît que 44 % des fournisseurs IT et 39 % des entreprises déclarent avoir du mal à trouver des professionnels qualifiés. La plateforme comprend plus de 30 projets de services. Déployer et opérer ce stack nécessite des équipes expérimentées en systèmes distribués que la plupart des équipes VMware ne possèdent pas — non par manque de talent, mais parce que ce sont des compétences fondamentalement différentes. C’est comme demander à un brillant chef de cuisine méditerranéenne de concourir en sushi : les deux sont de la gastronomie de haut vol, mais les compétences ne se transfèrent pas automatiquement.

Nuance importante

OpenStack peut être le choix idéal pour les organisations avec l’échelle et les équipes adéquates. Le modèle managé (Canonical, Mirantis, Platform9) résout une partie de la complexité, mais ajoute des coûts et de la dépendance. La question n’est pas « OpenStack oui ou non ? » mais « nos équipes, notre budget et notre échelle correspondent-ils à ce qu’OpenStack exige pour briller ? »

Erreur 06 sur 10

Croire que Ceph, c’est « juste cocher la case »

Ceph est un système puissant qui tourne en production dans des environnements impressionnants : CERN, Bloomberg et DigitalOcean, entre autres. Mais la distance entre un cluster Ceph à hyperscale et un déploiement typique de 3 à 5 nœuds dans une migration VMware, c’est comme la distance entre piloter un Airbus et un ULM : les deux volent, mais les règles sont très différentes.

Les benchmarks StarWind en environnement Proxmox HCI montrent que Ceph a atteint 270 000 IOPS en charges mixtes 4K, contre 1 088 000 IOPS pour LINSTOR/DRBD et 1 199 000 pour StarWind VSAN. Et les risques des clusters de petite taille méritent une attention particulière : perdre un nœud dans un cluster de 3 avec réplication 3x peut laisser le système en lecture seule. Pas exactement ce qu’on souhaite un lundi à 3 h du matin.

Les alternatives à considérer incluent LINSTOR/DRBD avec des performances proches du natif, StorPool avec des latences sub-100 µs, et IBM Storage Virtualize avec une intégration entreprise éprouvée. Chacun a ses forces, ses limites et ses exigences d’expertise.

Perspective SIXE

La couche de stockage est sans doute la décision la plus critique et la moins réversible de toute la migration. C’est là qu’on ne peut pas se permettre d’improviser. Elle doit être évaluée avec des tests réels sur des charges de travail réelles — pas avec des benchmarks génériques ni des « ça marche super bien chez quelqu’un que je suis sur LinkedIn ». C’est précisément là qu’un intégrateur expérimenté sur plusieurs plateformes de stockage apporte le plus de valeur.

Erreur 07 sur 10

Ne pas inventorier les fonctionnalités entreprise qui disparaissent

VMware a passé plus d’une décennie à construire des fonctionnalités sur lesquelles de nombreuses organisations ont bâti leurs processus opérationnels. Ce sont ces choses qui « marchent tout simplement » — jusqu’à ce qu’elles ne soient plus là. Et quand elles disparaissent, l’impact va bien au-delà de la technologie.

⚖️

Équilibrage automatique (DRS)

Proxmox n’a pas d’équivalent natif : il faut du scripting maison. OpenStack offre une fonctionnalité partielle via le scheduling Nova. Dans les deux cas, retroussez vos manches.

?️

Tolérance aux pannes et DR

VMware FT/SRM fournissent un basculement automatique. Les alternatives open source nécessitent une orchestration manuelle avec réplication ZFS, Ansible et runbooks. Ça fonctionne, mais quelqu’un doit le construire et le maintenir.

SDN et microsegmentation

Proxmox SDN supporte VLANs/VXLANs/EVPN, mais IPAM/DHCP sont en « tech preview » (comprendre : pas tout à fait prêt). Il n’y a pas d’équivalent au firewall distribué de NSX.

Certifications éditeurs

SAP, Oracle et Microsoft ne certifient pas Proxmox. NVIDIA AI Enterprise n’est pas officiellement supporté non plus. Si vous dépendez de ces certifications, c’est un détail qu’il vaut mieux ne pas négliger.

Automatisation et API

Les providers Terraform pour Proxmox sont maintenus par la communauté. L’API exige de spécifier manuellement le nœud cible. Rien de rédhibitoire, mais ces frictions s’additionnent.

Support 24/7

Proxmox fonctionne en horaires autrichiens (7 h–17 h CET), sans option 24/7 à aucun niveau. Quand la production tombe à 3 h du matin, il n’y a littéralement personne à appeler. Et non, Google ne compte pas.

Aucune de ces limitations n’invalide la plateforme — soyons clairs. Mais chacune représente un écart à combler par de l’ingénierie, des outils ou du conseil, et chaque solution de contournement a un coût qui doit figurer dans votre modèle financier. Faire comme si elles n’existaient pas, c’est la recette idéale pour des surprises désagréables.

Erreur 08 sur 10

Calculer le ROI uniquement sur la ligne des licences

Les économies sur les licences sont réelles. Mais présenter ces économies comme le ROI du projet, c’est comme évaluer un déménagement au seul prix du camion : techniquement correct, pratiquement incomplet.

Gartner estime que les services de migration coûtent entre 300 et 3 000 dollars par VM. 44 % des organisations subissent des interruptions non planifiées pendant la migration. Et les projets estimés à 6 mois se transforment régulièrement en 24 — un constat désormais très documenté.

Les coûts cachés qui érodent votre ROI

Formation : 5 000–15 000 $/ingénieur + 3–6 mois de productivité réduite (votre équipe apprend vite, mais pas du jour au lendemain). Intégration : sauvegarde, supervision, CMDB, automatisation — des connecteurs matures pour VMware qui n’existent tout simplement pas pour Proxmox. Développement sur mesure : scripts d’équilibrage, DR, monitoring = dette technique interne. Turnover : quand l’ingénieur qui les a construits s’en va, le savoir-faire part avec lui. Et c’est toujours au pire moment.

Erreur 09 sur 10

Concevoir pour le Jour 1 et oublier le Jour 2

La migration n’est que le début — la lune de miel, si vous voulez. Le vrai coût se manifeste dans les opérations quotidiennes, année après année.

Cybernews a révélé que de nombreuses organisations ayant migré vers Proxmox ne maintiennent pas les mises à jour de sécurité. C’est compréhensible : quand tout l’effort se concentre sur la migration, on oublie facilement qu’ensuite, il faut encore opérer. À grande échelle, l’interface devient peu réactive avec plusieurs milliers de VMs, et pmxcfs atteint ses limites autour de 11 000 VMs.

Sécurité et conformité

Gestion des CVE, durcissement, audits (ISO 27001, RGPD, NIS2). Quel SLA de réponse aux vulnérabilités critiques chaque plateforme offre-t-elle ? Question gênante, mais indispensable.

Télémétrie et observabilité

Les alternatives open source (Prometheus, Grafana, Zabbix) sont excellentes — elles le sont vraiment — mais elles nécessitent intégration et maintenance dédiées. Elles ne se configurent pas toutes seules.

Sauvegarde et restauration

Proxmox Backup Server est fonctionnel, mais il joue dans une autre catégorie d’écosystème comparé à Veeam, Commvault ou IBM Spectrum Protect.

?️

Dette technique

Chaque script personnalisé est du code à maintenir, documenter, tester et transmettre. La dette technique est invisible jusqu’à ce qu’elle ne le soit plus — et alors, c’est la seule chose que vous voyez.

Erreur 10 sur 10

Croire que la technologie est la décision

Migrer depuis VMware n’est pas un projet technologique : c’est une transformation opérationnelle qui touche les personnes, les processus, les fournisseurs, les budgets et les risques. La technologie compte, bien sûr. Mais ce n’est qu’une pièce du puzzle.

La migration VMware n’est pas un problème technologique. C’est un problème de découplage opérationnel déguisé en problème technologique.— Keith Townsend, The CTO Advisor

Les questions qui comptent vraiment : quel niveau de risque de gouvernance est acceptable pour nous ? Avons-nous l’équipe nécessaire — ou pouvons-nous la former à temps ? Quel est notre TCO réel à 5 et 10 ans ? Comment protégeons-nous l’investissement si le projet open source change de cap ? Quelles charges de travail migrons-nous d’abord, et lesquelles ne devraient peut-être jamais bouger ? Et qui sera notre partenaire technique quand les choses ne se passeront pas comme prévu ? (Parce qu’à un moment, ça arrivera. C’est la vie.)

Notre conviction

L’open source est, sans aucun doute, la bonne réponse pour l’infrastructure du futur. Nous n’avons aucun doute là-dessus. La question n’est pas de savoir s’il faut migrer, mais comment le faire avec la rigueur que la décision mérite. La différence entre une migration réussie et une qui génère des années de maux de tête tient à la qualité de l’analyse en amont, à l’architecture choisie et à l’accompagnement expert tout au long du processus. Et si après avoir lu tout ça, vous avez envie d’en discuter, nous sommes là.

La meilleure migration est celle qui se fait avec discernement, pas dans la précipitation

Plus de 15 ans de conception, de déploiement et d’exploitation d’infrastructures critiques. Nous connaissons VMware, Proxmox, OpenStack, Ceph, IBM Storage et les alternatives parce que nous travaillons avec toutes. Aucune préférence : uniquement la solution qui correspond à votre entreprise.

Parlons de votre cas →
Découvrir SIXE

Conformité NIS2 avec des logiciels libres. Sans licence

22 février 2026/dans Informations/par Alba Martinez

NIS2 · Cybersécurité · Logiciels libres

Conformité NIS2 avec des logiciels libres.
Sans licence, sans verrouillage.

Q: Qu'est-ce qu'une usine IA ?

Une usine IA (AI Factory) est une infrastructure de calcul spécialisée qui intègre stockage, calcul GPU et orchestration pour exécuter des modèles d'intelligence artificielle en production de façon continue, à grande échelle et sous contrôle total de l'organisation. Elle se distingue d'un simple serveur avec GPU par sa fiabilité en production, le service multi-modèles en parallèle et les outils opérationnels associés.

La directive NIS2 (UE 2022/2555) impose des exigences strictes en matière de cybersécurité aux entités essentielles et importantes. Des outils comme Wazuh, Ansible et OpenVAS couvrent la majorité des mesures techniques de l'article 21 — gratuitement. Ce guide explique ce qu'ils couvrent, ce qu'ils ne couvrent pas et où se situe le vrai risque organisationnel.

13 min de lecture●NIS2 · Sécurité · Open source●Février 2026 · mis à jour mai 2026

En Belgique, la loi du 26 avril 2024 transpose NIS2 en droit national. Si votre organisation opère dans un secteur essentiel ou important — ou si vous fournissez des services technologiques à une entité qui le fait — vous êtes concerné. Les amendes atteignent 10 millions d'euros ou 2 % du chiffre d'affaires mondial. Et pourtant, de nombreuses organisations paient des licences à six chiffres pour des outils que des alternatives open source reproduisent sans frais.

Chez SIXE, nous déployons Wazuh, Ansible, OpenVAS et Keycloak en environnements de production pour des clients opérant dans des secteurs réglementés NIS2. Ce guide distille ce que nous avons appris : quels contrôles les outils libres couvrent réellement, lesquels ils ne couvrent pas, et ce qui distingue une organisation qui passe l'audit de celle qui installe les mêmes outils et échoue.

01 · Champ d'application

NIS2 vous concerne-t-il ? Et quel cadre choisir en Belgique ?

NIS2 s'applique aux entités essentielles (énergie, transports, banques, santé, eau, infrastructures numériques, administration publique, espace) et aux entités importantes (fabrication, alimentation, services postaux, gestion des déchets, chimie, fournisseurs numériques). Si vous fournissez des technologies à l'un de ces secteurs, les exigences de sécurité de la chaîne d'approvisionnement (article 21.2.d) peuvent vous concerner via vos clients.

Belgique vs France — deux situations très différentes

Belgique : la loi du 26 avril 2024 est en vigueur. L'auto-évaluation devait être soumise au CCB avant le 18 avril 2026 via le cadre CyberFundamentals (CyFun®) ou ISO 27001.

France : la transposition est en retard. Le projet de loi Résilience (NIS2 + directive REC + DORA) a été adopté en première lecture au Sénat en mars 2025. L'entrée en vigueur est attendue courant 2026. L'autorité compétente sera l'ANSSI.

Calculateur de catégorie NIS2

Trois questions pour identifier votre catégorie et les priorités techniques qui en découlent :

~/nis2-classificateur-entite

Question 1 sur 3

$ nis2-classificateur --question 1

Quel secteur décrit le mieux votre organisation ?

Question 2 sur 3

$ nis2-classificateur --question 2

Quelle est la taille de votre organisation ?

Question 3 sur 3

$ nis2-classificateur --question 3

Quel serait l'impact d'un incident de sécurité majeur ?

$ nis2-classificateur --output

Kit technique recommandé

Ce résultat est indicatif. Votre classification exacte dépend de la loi nationale de transposition et, dans certains cas, d'une désignation explicite par l'autorité compétente. En Belgique, vérifiez auprès du CCB.

02 · Carte de couverture

Quel outil couvre quelles mesures NIS2 ?

Sélectionnez un outil pour voir sa couverture NIS2 et les mesures spécifiques de l'article 21 qu'il adresse. Le pourcentage reflète sa part des contrôles techniques — pas la conformité totale, qui inclut toujours une couche organisationnelle qu'aucun outil ne remplace.

⬡

Wazuh (SIEM / XDR / HIDS)

Plateforme de sécurité unifiée open source : centralisation des journaux, détection d'intrusions, intégrité des fichiers (FIM), détection de vulnérabilités et réponse active. Aucun frais de licence, agents illimités.

Couverture technique NIS2 Art. 21

72 %

Art. 21.2.bDétection et traitement des incidents✓

Art. 21.2.bRéponse active — confinement automatisé✓

Art. 21.2.eDétection et priorisation des vulnérabilités✓

Art. 21.2.gGestion centralisée des journaux et rétention✓

Art. 21.2.gSurveillance continue 24h/24 des systèmes✓

Art. 21.2.aIntégrité des fichiers et répertoires (FIM)✓

Art. 21.2.aÉvaluation de la configuration de sécurité (CIS)✓

Art. 21.2.iGestion des identités et des accès (IAM)—

Services Wazuh de SIXE →

⚙

Ansible + OpenSCAP + Lynis

Durcissement en infrastructure-as-code : définissez votre configuration sécurisée de référence, appliquez-la à toute votre flotte et produisez des preuves d'audit reproductibles. Essentiel pour démontrer une gestion systématique de la sécurité.

Couverture technique NIS2 Art. 21

55 %

Art. 21.2.aDurcissement et gestion de la configuration✓

Art. 21.2.aConfiguration de référence reproductible (IaC)✓

Art. 21.2.eGestion des correctifs — automatisée et tracée✓

Art. 21.2.fApplication des politiques de chiffrement✓

Art. 21.2.hAcquisition et déploiement sécurisés de logiciels✓

Art. 21.2.bDétection et alerte en temps réel—

Formation Linux — LPIC-1 et LPIC-2 →

⬦

OpenVAS / GVM (Greenbone Community)

Scanner de vulnérabilités open source. L'article 21.2.e de NIS2 exige une gestion systématique des vulnérabilités. GVM Community Edition fournit des analyses planifiées, la priorisation par score CVSS et des rapports prêts pour l'audit — gratuitement.

Couverture technique NIS2 Art. 21

30 %

Art. 21.2.eIdentification et gestion des vulnérabilités✓

Art. 21.2.eDivulgation et priorisation des CVE (CVSS)✓

Art. 21.2.hAnalyse de sécurité à l'acceptation des logiciels✓

Art. 21.2.bDétection de menaces en temps réel—

Conseil en gestion des vulnérabilités →

⬗

Keycloak / FreeIPA + privacyIDEA

Gestion des identités et des accès (IAM) open source avec SSO, RBAC et authentification multi-facteur. L'article 21.2.i de NIS2 exige le MFA pour tous les accès privilégiés et distants. Keycloak le délivre sans licence par utilisateur.

Couverture technique NIS2 Art. 21

40 %

Art. 21.2.iAuthentification multi-facteur (MFA)✓

Art. 21.2.iSSO et gestion centralisée des identités✓

Art. 21.2.iContrôle d'accès basé sur les rôles (RBAC)✓

Art. 21.2.iAccès distant chiffré et gestion des sessions✓

Art. 21.2.bSurveillance et corrélation d'événements—

Solutions identité et accès →

⬒

pfSense / OPNsense + Suricata

Pare-feu open source et segmentation réseau. Avec Suricata en IDS/IPS réseau. NIS2 exige des mesures de sécurité réseau et de contrôle d'accès — segmentation du périmètre et inspection du trafic sans licence par équipement.

Couverture technique NIS2 Art. 21

38 %

Art. 21.2.aSegmentation réseau et sécurité périmétrique✓

Art. 21.2.fCommunications chiffrées — application TLS✓

Art. 21.2.iAccès distant chiffré (VPN)✓

Art. 21.2.dContrôle des accès réseau fournisseurspartiel

Art. 21.2.bDétection corrélée entre systèmes—

Architecture réseau sécurisée →

⬛

BorgBackup / Restic + LUKS

Sauvegardes chiffrées, dédupliquées et vérifiables. L'article 21.2.c de NIS2 exige la continuité des activités et la gestion des sauvegardes. LUKS pour le chiffrement des supports. Les auditeurs veulent une restauration testée et documentée — pas supposée.

Couverture technique NIS2 Art. 21

28 %

Art. 21.2.cGestion des sauvegardes et procédures de reprise✓

Art. 21.2.cContinuité des activités et reprise après sinistrepartiel

Art. 21.2.fChiffrement au repos (LUKS, VeraCrypt)✓

Art. 21.2.cHaute disponibilité (entités essentielles)—

Support Debian et gestion des sauvegardes →

Couverture ≠ conformité

Aucun outil — libre ou commercial — ne couvre 100 % des mesures de l'article 21 à lui seul. Le stack technique est nécessaire mais pas suffisant. La gestion des risques, les procédures de réponse aux incidents, les contrats fournisseurs et la responsabilité de la direction sont organisationnels — aucun produit ne les livre.

03 · Le fossé organisationnel

Installer les outils n'est pas être conforme à NIS2

C'est l'erreur la plus fréquente et la plus coûteuse. Arriver à un audit avec Wazuh fraîchement déployé, sans processus de gestion des risques documenté, sans plan de réponse aux incidents et sans gouvernance de sécurité au niveau de la direction : les outils ne vous sauveront pas.

Les logiciels libres couvrent le quoi technique. NIS2 exige aussi le comment organisationnel :

Politique de gestion des risques — formelle, révisée annuellement, approuvée par la direction
Procédure de réponse aux incidents — qui reçoit l'alerte, comment les incidents sont triés, comment respecter les délais 24 h / 72 h / 1 mois
Sécurité de la chaîne d'approvisionnement — clauses de sécurité contractuelles avec tous vos fournisseurs technologiques (art. 21.2.d)
Responsabilité de la direction — l'article 20 rend les dirigeants personnellement responsables en cas de manquement à NIS2
Plan de continuité — avec restauration testée et documentée, pas supposée
Formation du personnel — avec registre de présence. Nos formations LPIC-1 et LPIC-2 couvrent les compétences Linux que les auditeurs attendent de l'équipe qui opère le stack de sécurité

NIS2 n'est pas un projet ponctuel

La conformité est un système de gestion continu : révisions régulières des risques, mise à jour du registre d'incidents, réévaluation de la chaîne d'approvisionnement, ajustement des outils. Si vos outils génèrent des alertes que personne ne consulte et sur lesquelles personne n'agit, c'est une caméra de surveillance avec l'écran éteint.

04 · Évaluation de maturité

Où en êtes-vous réellement ?

Cochez uniquement ce que vous avez en production et documenté — pas ce qui est en cours ou prévu :

Auto-évaluation de maturité NIS2

Cochez uniquement ce qui est opérationnel et documenté. Le score se met à jour en temps réel.

Gouvernance et gestion des risques

Politique de gestion des risques documentée et approuvée par la direction

Analyse des risques formelle complétée et mise à jour dans les 12 derniers mois

Direction formellement responsable de la cybersécurité (art. 20 NIS2)

Responsable de la sécurité désigné formellement pour la conformité NIS2

Mesures techniques (Art. 21)

SIEM/XDR déployé et ajusté à votre environnement — pas une installation par défaut

Durcissement documenté et reproductible (Ansible + OpenSCAP ou équivalent)

Gestion des vulnérabilités : analyses planifiées avec suivi des CVE et SLA de remédiation

MFA imposé pour tous les comptes privilégiés et les accès distants (art. 21.2.i)

Procédure de réponse aux incidents avec délais 24 h / 72 h / 1 mois définis

Continuité et chaîne d'approvisionnement

Sauvegardes chiffrées avec restauration testée et documentée (pas supposée)

Chiffrement au repos sur tous les appareils traitant des données sensibles (LUKS ou équivalent)

Clauses de sécurité dans les contrats avec tous vos fournisseurs technologiques (art. 21.2.d)

Formation à la sécurité dispensée au personnel avec registre de présence

05 · La plateforme sous-jacente

Linux est la base de votre stack NIS2. Maîtrisez-la.

Wazuh tourne sur Linux. OpenVAS tourne sur Linux. Ansible administre des serveurs Linux. Keycloak se déploie sur Linux. Tout le stack de sécurité open source repose sur Linux — et un système d'exploitation mal administré invalide chaque outil qui tourne dessus.

Chez SIXE, nous proposons deux services qui répondent directement aux exigences NIS2 :

Support Debian — maintenance proactive, application des correctifs de sécurité, durcissement CIS et documentation des changements. Tout ce que NIS2 exige pour la gestion du cycle de vie du système d'exploitation et la traçabilité des correctifs.
Formation LPIC-1 et LPIC-2 — certification internationale couvrant l'administration, la sécurité, les réseaux et l'automatisation Linux. Les auditeurs NIS2 attendent de l'équipe opérant le stack de sécurité qu'elle détienne des compétences accréditées et démontrables. Les badges Credly servent de preuves.

Pour le durcissement automatisé : notre service de déploiement Ansible applique les profils de sécurité CIS sur toute votre flotte, génère des preuves de conformité et laisse la configuration sous forme de code versionné dans Git — exactement ce qu'un auditeur souhaite trouver pour la gestion systématique des risques.

En résumé

L'essentiel, pour ceux qui manquent de temps

Six points

→ Wazuh couvre le cadre opérationnel : gestion des journaux, détection d'intrusions, FIM, analyse des vulnérabilités.

→ Ansible + OpenSCAP automatise le durcissement et le rend reproductible et auditable.

→ OpenVAS / GVM gère les vulnérabilités avec des analyses planifiées et traçables.

→ Keycloak centralise les identités et impose le MFA pour les accès privilégiés et distants.

→ BorgBackup + LUKS couvre la continuité des activités et le chiffrement au repos.

→ Tout cela sans politique de gestion des risques, plan de réponse aux incidents et cadre de gouvernance : l'audit ne passera pas.

FAQ

Questions fréquentes sur NIS2 et les logiciels libres

Oui. La directive NIS2 prescrit des résultats, pas des produits. Wazuh, Ansible, OpenVAS, Keycloak et pfSense couvrent la grande majorité des mesures techniques de l'article 21 — sans frais de licence.

Non. Wazuh adresse une partie importante du cadre opérationnel — gestion des journaux, détection d'intrusions, FIM et détection de vulnérabilités. Mais NIS2 exige également une IAM avec MFA, des sauvegardes chiffrées, la segmentation réseau, une gestion des risques formelle et la responsabilité de la direction qu'aucun outil ne fournit seul.

CyberFundamentals (CyFun®) est le cadre de cybersécurité du CCB belge comme voie pratique vers la conformité NIS2. Il comporte 4 niveaux (Small, Basic, Important, Essential) et 75 % des entités enregistrées en Belgique l'ont choisi plutôt qu'ISO 27001.

Pas encore. Le projet de loi Résilience (NIS2 + directive REC + DORA) a été adopté en première lecture au Sénat en mars 2025 et son entrée en vigueur est attendue courant 2026. En Belgique, la loi du 26 avril 2024 est déjà en vigueur.

Avec une base de sécurité existante, 4 à 6 mois est réaliste pour une entité importante. Les entités essentielles ont généralement besoin de 8 à 14 mois. Le déploiement technique est la phase la plus courte — l'ajustement des outils, la documentation et la gouvernance prennent le plus de temps.

Trois étapes : alerte précoce sous 24 heures, notification complète sous 72 heures, rapport final sous un mois. Wazuh fournit les capacités de détection et de journalisation pour respecter ces délais, mais le signalement à l'autorité compétente (CCB en Belgique, ANSSI en France) est un processus organisationnel.

Références

Réglementation et ressources citées

Directive (UE) 2022/2555 (NIS2). EUR-Lex

Loi belge du 26 avril 2024 — transposition NIS2. CCB Belgique

CyberFundamentals (CyFun®) — cadre de conformité du CCB. Safeonweb@Work

ANSSI — cybersécurité et transposition NIS2 en France. anssi.fr

Wazuh — Ensuring NIS2 compliance. wazuh.com

Greenbone — GVM Community Edition. greenbone.net

Wazuh — documentation officielle. documentation.wazuh.com

Publié : février 2026 · Dernière mise à jour : mai 2026

NIS2 · Logiciels libres · SIXE

Nous déployons des stacks NIS2 open source en production

Session technique de 30 minutes, sans engagement. Dites-nous votre catégorie NIS2, ce que vous avez en place et où se situent vos lacunes. Nous ressortons avec une esquisse d'architecture et les prochaines étapes concrètes.

WhatsApp Demander un diagnostic NIS2 Solutions Wazuh

Liquid AI LFM2.5 sur IBM Power9 AIX : 27 tokens/s sans GPU

16 février 2026/dans Informations/par Alba Martinez

Oublions un instant les clusters de H100. Chez SIXE, nous avons décidé de pousser le matériel d’entreprise à ses limites absolues pour répondre à une question brûlante : Un IBM Power System de 2018, fonctionnant sous AIX et reposant uniquement sur le CPU, peut-il gérer les modèles d’IA de dernière génération ?

Nous avons pris le nouveau modèle LFM2.5-1.2B de Liquid AI et l’avons exécuté sur un processeur IBM POWER9. À notre connaissance, c’est la première fois qu’un modèle LFM2.5 fonctionne sous AIX en mode Big-Endian.

Le résultat

Près de 27 tokens par seconde, des réponses cohérentes et moins de 750 Mo d’utilisation mémoire. Pas de GPU. Pas de NPU. Juste la puissance brute de l’architecture Power.

Mais la vitesse brute n’est que la moitié de l’histoire. Pour prouver qu’il ne s’agit pas d’un simple jouet de benchmark, nous avons soumis LFM2.5 à un « Défi SysAdmin » — de vraies tâches d’administration AIX — et l’avons comparé à un Transformer standard (TinyLlama 1.1B). Les résultats ont été choquants.

L’ingrédient secret : qu’est-ce que LFM2.5 ?

LFM2.5 est une architecture hybride conçue pour une efficacité maximale, mélangeant des blocs convolutifs (shortconv) pour la vitesse et des couches d’attention (GQA) pour le contexte. Il dispose d’une énorme fenêtre de contexte de 128k tokens — suffisante pour lire des milliers de lignes de logs sans oublier le début.

Le matériel : IBM Power System S924

Nous avons utilisé le cheval de bataille du monde de l’entreprise. Voici les configurations spécifiques utilisées pour ce benchmark :

Spécification	Valeur
Serveur	IBM Power System S924
Processeur	IBM POWER9 @ 2.75 GHz
Configuration	Enterprise Multi-Core (compatible SMT-8)
Système d’exploitation	AIX 7.3 TL4
Architecture	Big-Endian

Performance : trouver le point optimal

Nous avons découvert que mobiliser tous les cœurs sur le modèle nuit en réalité aux performances en raison de la surcharge de synchronisation. Le verdict était clair : utiliser seulement 8 cœurs en mode SMT-2 (16 threads) nous a donné 26,7 tokens par seconde.

Test en conditions réelles : le défi de l’administrateur système

Les chiffres c’est bien, mais est-ce que ça fonctionne vraiment ? Nous avons exécuté exactement les mêmes prompts à travers LFM2.5-1.2B et TinyLlama 1.1B (un transformer pur de taille similaire). Voici les sorties brutes.

Round 1 : L’erreur cryptique (errpt)

Nous avons fourni aux modèles un log d’erreur AIX brut concernant une défaillance d’alimentation.

L’entrée :

$ errpt -a -l BFE4C025

Description: Power/Cooling subsystem Unrecovered Error,
             bypassed with loss of redundancy.
Possible FRUs:
  Priority: H
  FRU:      PWRSPLY
  Location: U78D2.001.WZS00P4

❌ TinyLlama 1.1B :

“7. What is the location of the FRU that is affected by this error? The FRU that is affected by this error is PWRSPLY. 8. What is the description of the FRU that is affected by this error? The FRU that is affected by this error is PWRSPLY…”

Verdict : Échec. Il s’est bloqué dans une boucle infinie répétant “PWRSPLY”.

✅ LFM2.5 1.2B :

“What is the likely cause? The error usually points to a problem with the power or cooling hardware (like a fan or power supply) that couldn’t be fixed automatically. It might be a hardware failure or a misconfiguration. What action should I take? First, check the hardware — look at the fans (especially the power fans)…”

Verdict : Réussite. Il a identifié le composant et donné des conseils actionnables pour vérifier les ventilateurs.

Round 2 : L’audit de sécurité (last)

Nous avons fourni un historique de connexions contenant un événement de crash caché.

L’entrée :

$ last -20

root   pts/0   10.10.10.1   Jan 28 11:14 - 18:38 (07:23)
reboot ~                     Jan 28 11:12
root   pts/0   10.10.10.1   Jan 27 22:09 - System halted abnormally. (13:03)

❌ TinyLlama 1.1B :

(a généré 1 token puis s’est arrêté)

Verdict : Échec. Silence absolu.

✅ LFM2.5 1.2B :

“Suspicious patterns: The system was halted abnormally on Jan 27. This could indicate a security incident or a misconfiguration. Security recommendations: Investigate the cause of the system halt on Jan 27. Review the login history for any unauthorized access attempts.”

Verdict : Réussite. Il a immédiatement repéré l’arrêt anormal du 27 janvier et recommandé une investigation.

Round 3 : Le conseil dangereux (/etc/passwd)

Nous avons demandé aux modèles d’auditer un fichier de mots de passe standard. Les résultats ici ont été choquants.

L’entrée :

$ cat /etc/passwd

root:!:0:0::/:/usr/bin/bash
daemon:!:1:1::/etc:
bin:!:2:2::/bin:
...

❌ TinyLlama 1.1B :

“1. root:!:0:0::/:/usr/bin/bash — This user is not required for system maintenance and should be removed. 2. daemon:!:1:1::/etc: — This user is not required for system maintenance and should be removed.”

Verdict : ÉCHEC CATASTROPHIQUE. Il a affirmé que l’utilisateur “root” n’était pas nécessaire et a recommandé de le supprimer. Suivre ce conseil détruirait le serveur.

✅ LFM2.5 1.2B :

“Unauthorized or suspicious accounts: You should be very concerned about the presence of the following accounts: guest with a high UID (100), nobody with a high UID (4294967294)… These accounts are either misconfigured, potentially malicious, or not needed.”

Verdict : Réussite. Il a correctement identifié les risques potentiels réels comme les comptes “guest” et “nobody” avec des UID élevés.

Round 4 : Durcissement des services (lssrc -a)

Nous avons demandé aux modèles de passer en revue les services en cours d’exécution et de recommander des étapes de durcissement.

L’entrée :

$ lssrc -a

Subsystem    Group      Status
sendmail     mail       active
portmap      portmap    active
inetd        tcpip      active
snmpd        tcpip      active

❌ TinyLlama 1.1B :

(a généré 0 tokens)

Verdict : Échec. Silence à nouveau.

✅ LFM2.5 1.2B :

“1. sendmail Risk: Running mail daemon can be a target for attacks. Recommendation: Disable sendmail. stopsrc -s sendmail 2. portmap Risk: Running portmap daemon can be abused… stopsrc -s portmap”

Verdict : Réussite. Il a signalé des services à risque comme sendmail et portmap, et a fourni la commande AIX correcte (stopsrc) pour les désactiver.

Pourquoi c’est important pour les utilisateurs d’IBM Power

Ce benchmark prouve que les IBM Power Systems sont des moteurs d’inférence IA capables pour des tâches critiques sur site :

Souveraineté des données : Analysez les logs errpt sensibles, les données financières ou les audits d’utilisateurs localement. Aucune donnée ne quitte votre serveur.

Modernisation du legacy : Utilisez des LLM locaux pour aider à comprendre et documenter le code legacy COBOL ou C résidant sur le serveur.

Efficacité : Vous n’avez pas besoin d’un cluster de GPU. Vous possédez probablement déjà le matériel capable de faire cela.

Essayez-le vous-même

Nous croyons en l’open source. Nous avons publié le port AIX et les modèles convertis en Big-Endian.

Code : gitlab.com/librepower/llama-aix

Modèles : huggingface.co/librepowerai

user@aix:~$ # Démarrage rapide sur AIX
user@aix:~$ git clone https://gitlab.com/librepower/llama-aix.git
user@aix:~$ ./scripts/build_aix_73.sh

user@aix:~$ # Optimiser le threading pour le "point optimal"
user@aix:~$ smtctl -t 2 -w now

user@aix:~$ # Amusez-vous bien !

Nouveau IBM FlashSystem 2026 – 5600, 7600 et 9600

10 février 2026/dans Informations/par Alba Martinez

? Sommaire

Ce qu’apporte IBM et pourquoi c’est le plus grand lancement en six ans
Les trois modèles : 5600, 7600 et 9600
FlashCore Module 5 : du QLC qui performe comme du TLC (et pourquoi c’est important)
FlashSystem.ai : l’IA agentique dans la baie, entre promesses et réalité
Détection de ransomware en 60 secondes : les données et les astérisques
L’argument qui n’apparaît pas dans les datasheets : la chaîne d’approvisionnement
Pure Storage, Dell, NetApp… et maintenant ?
À qui s’adresse-t-il ?
Conclusions

IBM vient de dévoiler à Varsovie la nouvelle génération d’IBM FlashSystem. Trois nouveaux modèles (5600, 7600 et 9600), un moteur d’IA intégré baptisé FlashSystem.ai, la cinquième génération de son unité flash propriétaire et un message qui sonne très bien en keynote : « stockage autonome co-piloté par l’IA agentique ».

Nous travaillons avec les baies FlashSystem au quotidien. Mais c’est justement pour cette raison qu’une analyse sérieuse s’impose ;) Décortiquons ensemble ce qui se cache derrière chaque chiffre et où se trouve la vraie valeur ajoutée.

Ce qu’apporte IBM et pourquoi c’est le plus grand lancement en six ans

IBM n’exagère pas en affirmant que c’est son lancement le plus important depuis 2020. Ce n’est pas un simple rafraîchissement cosmétique : ce sont trois baies simultanées, une refonte complète de l’unité flash et une couche d’IA qui va bien au-delà de ce que proposait la génération précédente.

L’idée de fond est que la baie de stockage cesse d’être « une armoire qui stocke des données » et devienne un système qui analyse, optimise et se protège de manière autonome.

Sam Werner, Directeur Général d’IBM Storage, a été assez clair lors de la présentation : il ne s’agit pas de remplacer l’administrateur, mais de le libérer des tâches répétitives pour qu’il puisse consacrer son temps à l’architecture et à la planification.

Ça ressemble à un slide de keynote ? Un peu. Mais les chiffres matériels qui se cachent derrière sont réels et, dans certains cas, véritablement impressionnants.

Les trois modèles FlashSystem de 2026 : FlashSystem 5600, 7600 et 9600

La nouvelle gamme remplace les FlashSystem 5300, 7300 et 9500 avec des améliorations substantielles en capacité, densité et efficacité. Les trois modèles adoptent le format d’unités NVMe EDSFF (Enterprise and Data Center SSD Form Factor), le standard de l’industrie pour une densité et un refroidissement optimaux en environnement de centre de données :

	FlashSystem 5600	FlashSystem 7600	FlashSystem 9600
Format	1U · 12 disques	2U · 32 disques	2U · 32 disques (avant 4U)
CPU	2×12 cœurs Intel Xeon · PCIe Gen 4	2×16 cœurs AMD EPYC · PCIe Gen 5	2×48 cœurs AMD EPYC · PCIe Gen 5
Capacité brute	633 To	1,68 Po	3,37 Po (vs 1,8 Po du 9500)
Capacité utilisable	400 Tou	1,2 Pou	2,4 Pou
Capacité effective	Jusqu’à 2,4 Poe	Jusqu’à 7,2 Poe	Jusqu’à 11,8 Poe
IOPS	2,6 millions	4,3 millions	6,3 millions
Débit lecture	30 Go/s	55 Go/s	86 Go/s (vs 100 Go/s du 9500)
Ports	16× FC ou 20× Ethernet	32× FC ou Ethernet	32× FC ou Ethernet (vs 48 du 9500)
Cas d’usage	Edge, sites distants, petits DC	Virtualisation, analytique	Banque, ERP, charges IA

Un saut générationnel intéressant : les 7600 et 9600 embarquent AMD EPYC avec PCIe Gen 5, tandis que le 5600 reste sur Intel Xeon et PCIe Gen 4. C’est logique par segment — le PCIe Gen 5 double la bande passante par lane, mais pour le cas d’usage edge du 5600, le Gen 4 est plus que suffisant et contribue probablement à maintenir le prix contenu.

Le chiffre le plus frappant est le FlashSystem 5600 qui loge 2,4 Poe dans 1U. Pour les environnements edge ou les centres de données avec des contraintes d’espace, cela change la donne. Et le 9600 passe de 4U à 2U tout en doublant quasiment la capacité brute (de 1,8 Po à 3,37 Po). C’est du progrès réel, pas du marketing.

Cela dit, une nuance importante : les capacités « effectives » (Poe) supposent des taux de déduplication et de compression qui dépendent énormément du type de données. Avec des données déjà compressées ou chiffrées, les 11,8 Poe du 9600 se réduisent à ses 2,4 Pou (utilisables) ou 3,37 Po bruts. C’est de la physique, pas de la magie. IBM le précise en notes de bas de page, mais il convient de le garder bien à l’esprit.

Un autre détail intéressant passé largement inaperçu : le 9600 passe de 48 à 32 ports d’E/S et son débit de lecture maximal passe de 100 Go/s à 86 Go/s par rapport au 9500. C’est un compromis de conception : plus de densité au prix d’un peu de connectivité brute. Selon votre architecture, cela peut compter ou non, mais il vaut mieux le savoir.

Les modèles 7600 et 9600 intègrent des façades LED interactives pour visualiser l’état du système. Cela semble être un détail mineur, mais tout administrateur qui a dû identifier un châssis à 3 heures du matin dans un datacenter l’appréciera.

Famille nouveau IBM FlashSystem 2026 modèles 5600 7600 9600 vue frontale avec façades LED interactives

Nouveaux IBM FlashSystem 2026 — modèles 5600, 7600 et 9600

FlashCore Module 5 : du QLC qui performe comme du TLC (et pourquoi c’est important)

C’est ici qu’IBM dispose d’un avantage concurrentiel qui n’est pas du vent : ils conçoivent et fabriquent leurs propres unités flash. Et dans le nouveau FlashCore Module de cinquième génération (FCM5), cela se traduit par quelque chose de très concret.

Le FCM5 est disponible en capacités de 6,6 / 13,2 / 26,4 / 52,8 et 105,6 To au nouveau format NVMe EDSFF. Ce dernier chiffre, 105 To par unité, est le plus élevé de l’industrie pour les charges de travail entreprise. Comment y parviennent-ils ? En utilisant du NAND QLC avec une propriété intellectuelle propriétaire qui performe comme du TLC.

Pour ceux qui ne vivent pas le stockage au quotidien : le QLC (Quad-Level Cell) est plus dense et moins cher que le TLC (Triple-Level Cell), mais offre normalement une endurance en écriture moindre et des performances inférieures. Les concurrents utilisant du QLC standard le limitent aux charges en lecture intensive. IBM, en contrôlant la conception de l’unité de bout en bout, a réussi à surmonter cette limitation. De fait, selon les propres chiffres d’IBM, les FCM obtiennent 5,5 fois plus de cycles d’écriture que les unités QLC standard du marché.

Alistair Symon, VP du développement des systèmes de stockage, l’a expliqué lors du briefing pré-lancement : d’autres fabricants proposent des unités QLC de plus grande capacité, mais étant du QLC standard, elles ne supportent pas les charges d’écriture intensives sur la durée d’amortissement du matériel. Les FCM5 d’IBM, si.

Qu’intègre encore le FCM5 directement dans le matériel ?

Chiffrement quantum-safe pour toutes les données, directement sur l’unité
Compression accélérée par le matériel
Déduplication embarquée (nouveauté de cette génération), permettant des taux de réduction de 5:1
Analyse des E/S accélérée par le matériel : statistiques complexes sur chaque opération sans impact sur les performances

En déchargeant ces opérations sur le module flash au lieu de les exécuter sur les contrôleurs de la baie, IBM libère de la puissance de calcul pour les charges de travail des clients. C’est la même philosophie appliquée avec les générations précédentes de FCM pour la détection d’anomalies, mais poussée un cran plus loin avec la déduplication intégrée.

FlashSystem.ai : l’IA agentique dans la baie, entre promesses et réalité

FlashSystem.ai est la nouvelle couche de services de données alimentée par l’IA agentique (nous aussi, nous déployons des agents IA en entreprise, au passage). Selon IBM, elle a été entraînée sur des dizaines de milliards de points de télémétrie et des années de données opérationnelles réelles. Le système exécute des milliers de décisions automatisées par jour qui nécessitaient auparavant une supervision humaine.

Les capacités les plus intéressantes :

S’adapte au comportement des applications en quelques heures, et non en semaines comme les systèmes basés sur des modèles
Recommande des optimisations de performance en expliquant son raisonnement (cela permet d’auditer les décisions de l’IA, crucial pour la conformité)
Intègre le retour d’expérience de l’administrateur pour affiner ses recommandations dans le temps
Placement intelligent des charges de travail avec mobilité des données non disruptive, y compris vers des baies tierces
Réduit de moitié le temps de documentation pour les audits et la conformité

Et bien sûr, le chiffre phare : réduction de 90 % de l’effort de gestion manuel. C’est un chiffre spectaculaire, mais qui s’accompagne d’une note de bas de page qui mérite une lecture attentive. IBM le mesure en comparant des tâches routinières spécifiques (provisionnement de volumes avec politiques de copie protégée et DR) sur la nouvelle génération avec FlashSystem.ai vs. la même génération sans FlashSystem.ai. C’est une comparaison interne, en laboratoire, sur des opérations sélectionnées.

Cela signifie-t-il que les 90 % sont inventés ? Non. Cela signifie que c’est le meilleur scénario sur des tâches précises. En exploitation réelle, avec ses intégrations, ses particularités et l’entropie naturelle de toute infrastructure, le bénéfice sera moindre. Il restera probablement significatif — l’automatisation des tâches répétitives apporte une valeur réelle — mais n’attendez pas que votre admin stockage ne travaille plus qu’un jour par semaine.

Il y a quelque chose que nous trouvons véritablement utile : le raisonnement opérationnel explicable. Le système ne se contente pas d’agir — il explique pourquoi. Pour les audits et la conformité (qui pèsent de plus en plus dans les secteurs régulés, comme l’exige la CNIL et les réglementations européennes), disposer d’un journal généré par l’IA des décisions opérationnelles est un avantage réel face à la concurrence.

Détection de ransomware en 60 secondes : les données et les astérisques

Un autre chiffre accrocheur : le FCM5 détecte les ransomware en moins d’une minute. Regardons cela de plus près.

Le système analyse chaque opération d’E/S directement dans le matériel, recherchant des schémas anormaux associés au chiffrement malveillant. Le modèle de détection (version 3.3, lancé au T4 2025) cumule 24 mois d’entraînement avec de la télémétrie de production et maintient un taux de faux positifs inférieur à 1 %, mesuré sur 3 mois.

Combiné à Safeguarded Copy (des copies avec un air gap logique, immuables et invisibles depuis toute connexion externe), IBM affirme qu’il est possible de récupérer d’une attaque en moins d’une minute.

Maintenant, les astérisques qu’IBM met en notes de bas de page :

Le test original de détection sub-minute a été réalisé sur un FlashSystem 5200 (génération précédente) avec un simulateur de ransomware propriétaire d’IBM baptisé WannaLaugh. Oui, il s’appelle vraiment comme ça. Points bonus pour le nom.
La détection porte sur le début du processus de chiffrement, et non sur l’intrusion initiale dans le système.
Un ransomware suffisamment sophistiqué qui chiffre lentement et imite des schémas d’écriture normaux pourrait potentiellement échapper à la détection.

Cela étant dit — et c’est important — disposer d’une détection au niveau matériel avec moins de 1 % de faux positifs est objectivement excellent. La plupart des solutions de détection de ransomware du marché opèrent au niveau du système de fichiers ou du réseau, avec des latences supérieures et des taux d’erreur plus élevés. IBM opère une couche plus bas, directement au niveau des E/S du stockage. En tant que couche supplémentaire dans une stratégie de défense en profondeur, cela apporte une valeur réelle que la concurrence ne peut pas facilement reproduire car elle ne contrôle pas le matériel de ses unités flash.

L’argument qui n’apparaît pas dans les datasheets : la chaîne d’approvisionnement

Un angle qui peut être plus pertinent que n’importe quel benchmark pour de nombreux responsables informatiques en 2026 : la crise d’approvisionnement en stockage. La demande de capacité pour l’entraînement de modèles d’IA génère des pénuries et des hausses de prix sur les SSD à l’échelle mondiale.

Werner a été direct à ce sujet : IBM est mieux positionné que la plupart des concurrents car il fabrique ses propres unités flash.

Si vous planifiez une extension de capacité sur les 12 à 18 prochains mois et que vous faites face à des délais de 6 mois sur des SSD standard, avoir un fournisseur qui contrôle la fabrication de ses unités est un argument qui n’apparaît dans aucun comparateur Gartner mais qui peut définir un projet.

Pure Storage, Dell, NetApp et les autres — et maintenant ?

Le marché des baies all-flash entreprise est très disputé. Comparons ce qui différencie réellement le nouveau FlashSystem du reste :

Aspect	IBM FlashSystem (nouveau)	Pure Storage FlashArray	Dell PowerStore	NetApp AFF
Unités propriétaires	✅ FlashCore Module (QLC→TLC)	✅ DirectFlash (150 To)	❌ SSD standard	❌ SSD standard
IA de gestion	FlashSystem.ai (agentique)	Pure1 Meta	CloudIQ	BlueXP / AIOps
Détection ransomware HW	✅ Sur l’unité flash	❌ Logiciel	❌ Logiciel	❌ Logiciel (ONTAP)
Support baies tierces	✅ +500 fabricants	❌ Écosystème fermé	Partiel	Partiel (FabricPool)
Chiffrement quantum-safe HW	✅	❌	❌	❌
Modèle de licence	Traditionnel IBM	Evergreen (très transparent)	APEX / traditionnel	Keystone / traditionnel

Là où IBM prend clairement l’avantage :

Le FlashCore Module est un avantage réel et difficile à reproduire. Contrôler la conception de l’unité flash permet d’intégrer des fonctionnalités au niveau matériel (détection de ransomware, chiffrement quantum-safe, déduplication) que la concurrence ne peut faire qu’en logiciel. Pure Storage conçoit également ses propres unités (DirectFlash), mais à ce jour n’intègre ni la détection de ransomware ni le chiffrement post-quantique dans le matériel.

La compatibilité avec plus de 500 fabricants de stockage tiers via FlashSystem Grid est un choix judicieux. En conditions réelles, personne ne dispose d’un environnement homogène, et pouvoir déplacer des données de manière non disruptive entre des baies IBM et celles d’autres fabricants résout un vrai problème de consolidation et de migration.

Là où la concurrence résiste :

Pure Storage obtient systématiquement de meilleures évaluations en termes d’expérience utilisateur et son modèle Evergreen est difficile à battre en transparence de licences. Si le prix et la simplicité contractuelle sont vos priorités, Pure reste un rival redoutable.
NetApp dispose d’ONTAP, un système d’exploitation de stockage d’une maturité remarquable dans les environnements hybrides avec une base installée considérable. Pour ceux qui sont déjà dans l’écosystème NetApp, migrer est difficile à justifier uniquement par de nouvelles fonctionnalités.
Dell PowerStore est compétitif en prix et dispose d’une intégration profonde avec l’écosystème VMware (désormais Broadcom), qui reste l’hyperviseur dominant dans de nombreuses organisations.

En résumé : IBM ne balaie pas la concurrence, mais avec cette génération, il se positionne avec des arguments techniques solides qui vont au-delà du marketing, en particulier sur la sécurité au niveau matériel et la flexibilité multi-fournisseurs.

FlashCore Module 5 d’IBM

À qui s’adresse-t-il ?

Après avoir digéré toutes ces informations, voici les scénarios où le nouveau FlashSystem s’impose le mieux :

Environnements critiques (banque, assurance, santé) où la combinaison de détection de ransomware matérielle, Safeguarded Copy et chiffrement quantum-safe apporte des couches de sécurité que la concurrence n’égale pas au même niveau.
Organisations avec une infrastructure hétérogène qui doivent consolider sans tout remplacer. La compatibilité avec +500 fabricants et la mobilité des données entre baies est un argument authentique.
Datacenters avec des contraintes d’espace où la densité du 5600 (2,4 Poe dans 1U) peut éviter des extensions physiques.
Entreprises qui travaillent déjà avec l’infrastructure IBM Storage et qui cherchent une évolution naturelle intégrée à leurs investissements existants, notamment en combinaison avec SVC ou d’autres solutions du portfolio.

Et qui devrait y réfléchir à deux fois ? Si votre environnement est 100 % virtualisé avec VMware et que toute votre gestion passe par vCenter, l’intégration avec Dell peut avoir plus de sens sur le plan opérationnel. Si votre priorité est la simplicité contractuelle et que votre équipe est réduite, le modèle Evergreen de Pure Storage est difficile à battre.

Conclusions

IBM a fait ses devoirs avec ce lancement. La combinaison du matériel propriétaire (FCM5 avec du QLC qui performe comme du TLC), de l’IA agentique intégrée (FlashSystem.ai) et de la stratégie de compatibilité multi-fournisseurs positionne le nouveau FlashSystem comme une proposition sérieuse.

Est-ce parfait ? Non. Le marketing gonfle certains chiffres (comme tout le monde, ne nous voilons pas la face), l’étiquette de « stockage autonome » est plus aspirationnelle que descriptive, et tant que nous n’aurons pas vu des benchmarks indépendants et des retours d’expérience terrain avec des mois d’exploitation, certaines affirmations restent des promesses.

Mais si l’on met tout dans la balance : la technologie est solide, l’architecture fait sens, la direction est la bonne. Et le fait qu’IBM contrôle depuis la conception de l’unité flash jusqu’à la couche d’IA en passant par le système d’exploitation SVC lui confère une cohérence de stack que peu de fabricants peuvent offrir.

Disponibilité générale : 6 mars 2026.

Vous évaluez le nouveau IBM FlashSystem ou planifiez une migration ?

Chez SIXE, nous travaillons depuis des années avec les baies IBM FlashSystem dans des environnements de production réels. Nous concevons, déployons, migrons et assurons le support technique IBM Storage sans intermédiaire. Si vous avez besoin de conseils sur la manière dont cette nouvelle génération s’intégrerait dans votre infrastructure, n’hésitez pas à nous contacter.

Stockage distribué 2026. Un guide technique (controversé)

30 janvier 2026/dans Informations/par Hugo

Une autre année vivante, une autre année à regarder l’industrie du stockage distribué se surpasser en créativité commerciale. Si 2024 était l’année où tout le monde a découvert qu’il fallait du “stockage pour l’IA” (spoiler : c’est le même vieux stockage, mais avec un meilleur marketing), 2025 est l’année où MinIO a décidé de s’immoler publiquement pendant que le reste de l’écosystème continue d’évoluer à un rythme soutenu.

Accrochez-vous, ça va secouer !

? Table des Matières

→Le Drame de l’Année : MinIO Passe en « Mode Maintenance »
→Ceph Continue de Nager Paisiblement (Tentacle v20.2.0)
•Les Chiffres Qui Comptent : Bloomberg, CERN, DigitalOcean
→L’Écosystème Entreprise : Comprendre Ce Que Tu Achètes
•IBM Fusion : Deux Saveurs pour Différents Besoins
•Red Hat Ceph Storage : Le Standard Entreprise
•SUSE : Une Leçon sur le Verrouillage Fournisseur
•Pure Storage et NetApp : L’Approche Appliance
→La Question Que Personne Ne Pose : Qu’achètes-tu Vraiment ?
→Démystifier les Affirmations Marketing
→Une Décision Intelligente : Décider en S’informant
→Où Trouver Ces Connaissances
→Conclusions pour 2026

Le Drame de l’Année : MinIO Passe en « Mode Maintenance » (Lire : Mode Abandon)

Si tu n’as pas suivi le feuilleton MinIO, laisse-moi te donner un peu de contexte. MinIO était le stockage d’objets open source que tout le monde déployait. Simple, rapide, compatible avec S3. Tu le mettais en place et en service en 15 minutes. C’était le WordPress du stockage objet.

Eh bien, en décembre 2025, un commit silencieux dans le README a tout changé : « Ce projet est actuellement en maintenance et n’accepte pas de nouvelles modifications. » Pas d’annonce. Pas de guide de migration. Pas d’adieu. Juste un commit et un simple au revoir.

La communauté, sans surprise, s’est enflammée. Un développeur a parfaitement résumé la situation : « Une mise à jour silencieuse du README vient de mettre fin à l’ère de MinIO en tant que moteur S3 open-source par défaut. »

Mais cela ne s’est pas fait du jour au lendemain. MinIO poursuivait depuis des années une stratégie « open source mais sans en faire trop » :

2021 : Passage silencieux d’Apache 2.0 à AGPL v3 (pas d’annonce, pas de PR, rien)
2022-2023 : Campagnes agressives contre Nutanix et Weka pour « violation de licence »
Février 2025 : Console Web, gestion des buckets et réplication supprimées de la version communautaire
Octobre 2025 : Arrêt de la distribution des images Docker
Décembre 2025 : Mode maintenance

Le message est clair : si tu veux MinIO pour de vrai, paie. Leur produit entreprise AIStor commence à 96 000 €/an pour 400 TiB. Pour 1 PB, on parle de plus de 244 000 €/an.

La leçon à retenir ? En 2025, « Open Source » sans gouvernance ouverte ne vaut rien. MinIO était une entreprise avec un produit open source, pas un projet communautaire. La différence est capitale.

Pendant Ce Temps, Ceph Continue de Nager Paisiblement

Pendant que MinIO s’autodétruisait, Ceph fêtait sa 20e version stable : Tentacle (v20.2.0), sortie en novembre 2025. Le projet accumule plus d’un exaoctet de stockage déployé à l’échelle mondiale sur plus de 3 000 clusters.

L’élément le plus intéressant de Tentacle est FastEC (Fast Erasure Coding), qui améliore les performances des petites lectures et écritures de 2x à 3x. Cela rend l’erasure coding enfin viable pour les charges de travail qui ne sont pas du stockage froid pur. Avec un profil EC 6+2, tu peux désormais obtenir environ 50 % des performances de la réplication 3 tout en utilisant seulement 33 % de l’espace.

Pour ceux d’entre nous qui entendent depuis des années que « le codage par effacement est lent pour la production », cela change vraiment la donne.

Autres nouveautés de Tentacle :

Prise en charge intégrée de SMB via Samba Manager
Groupes de passerelles NVMe/TCP avec prise en charge multi-namespace
Authentification OAuth 2.0 sur le tableau de bord
Répertoires CephFS insensibles à la casse (enfin !)
ISA-L remplace Jerasure (qui a été abandonné)

Le Crimson OSD (basé sur Seastar pour l’optimisation NVMe) est encore en avant-première technique. Il n’est pas prêt pour la production, mais la feuille de route est prometteuse.

Les Chiffres Qui Comptent

Bloomberg exploite plus de 100 Po dans des clusters Ceph. Ils sont membre Diamant de la Fondation Ceph et leur responsable de l’ingénierie du stockage siège au conseil d’administration. DigitalOcean possède plus de 54 Po dans 37 clusters de production. Le CERN maintient 50+ Po dans plus de 10 clusters.

Et voici la partie intéressante : ZTE Corporation fait partie des 3 premiers contributeurs mondiaux à Ceph et est numéro 1 en Chine. Son produit TECS CloveStorage (basé sur Ceph) est déployé dans plus de 320 projets NFV dans le monde, notamment chez China Mobile, izzi Telecom (Mexique) et Deutsche Telekom.

Le secteur des télécoms est la superpuissance secrète de Ceph. Alors que beaucoup pensent encore aux appliances traditionnelles, les télécoms font tourner Ceph en production à grande échelle.

L’Écosystème Entreprise : Comprendre Ce Que Tu Achètes

C’est là que les choses deviennent intéressantes. Et il vaut la peine de comprendre ce qui se cache derrière chaque option.

IBM Fusion : Deux Saveurs pour Différents Besoins

IBM propose deux produits sous la marque Fusion, et il est important de comprendre la différence :

IBM Fusion HCI : utilise IBM Storage Scale ECE (l’ancien GPFS/Spectrum Scale). Système de fichiers parallèle avec erasure coding distribué. Appliance hyperconvergée qui évolue de 6 à 20 nœuds.
IBM Fusion SDS : utilise OpenShift Data Foundation (ODF), qui est basé sur Ceph packagé par Red Hat.

Storage Scale est une technologie véritablement différenciée, notamment pour le HPC. Son architecture de système de fichiers parallèle offre des capacités que Ceph n’a tout simplement pas : gestion avancée des métadonnées, tiering intégré, AFM pour la fédération… Si tu as des charges de travail de calcul haute performance, de supercalculateur ou d’IA à une échelle sérieuse, Storage Scale a de solides arguments techniques pour se justifier.

Les performances revendiquées par IBM Fusion HCI sont impressionnantes : accélération de 90x sur les requêtes S3 avec mise en cache locale, performances équivalentes à celles de Databricks Photon à 60 % du coût, etc.

Cependant, il vaut toujours la peine de se poser la question suivante : quelle est la part de cette performance qui relève de la technologie propriétaire et quelle est celle qui relève simplement d’un matériel bien dimensionné dans la bonne configuration ? Ce n’est pas une critique, c’est une question légitime que tout architecte devrait se poser avant de prendre une décision.

Dans le cas de Fusion SDS, tu achètes Ceph avec la valeur ajoutée du packaging, de l’intégration OpenShift et du support entreprise IBM. Pour de nombreuses organisations, cela a une réelle valeur.

Red Hat Ceph Storage : Le Standard Entreprise

Red Hat Ceph Storage continue d’être la distribution de choix pour les entreprises. Ils offrent 36 mois d’assistance production et 24 mois d’assistance étendue en option. Le produit est solide et bien intégré.

Ce que tu achètes réellement : des packages testés et certifiés, un support entreprise 24h/24 et 7j/7, des cycles de vie prévisibles et l’intégration OpenShift.

Est-ce que ça en vaut la peine ? Cela dépend de ton contexte. Si ton organisation a besoin d’un contrat de support pour la conformité ou simplement pour dormir tranquille, probablement oui. Et nous serions heureux de t’aider dans ce domaine. Mais si tu as l’équipe technique pour exploiter Ceph upstream, c’est une décision qui mérite d’être analysée.

SUSE : Une Leçon sur le Verrouillage Fournisseur

Voici une histoire qui mérite réflexion : SUSE a complètement quitté le marché entreprise Ceph. Leur produit SUSE Enterprise Storage (SES) a atteint la fin du support en janvier 2023. Après avoir acquis Rancher Labs en 2020, ils ont pivoté vers Longhorn pour le stockage natif Kubernetes.

Si tu étais client SES, tu t’es retrouvé orphelin. Tes options étaient de migrer vers Red Hat Ceph Storage, Canonical Charmed Ceph, Ceph communautaire, ou de trouver un partenaire spécialisé pour t’aider dans la transition.

Ce n’est pas une critique envers SUSE ; les entreprises pivotent selon leur stratégie. Mais c’est un rappel que le contrôle de ton infrastructure a une valeur qui n’apparaît pas toujours dans le TCO.

Pure Storage et NetApp : L’Approche Appliance

Pure Storage a créé une catégorie appelée « Unified Fast File and Object » (UFFO) avec sa famille FlashBlade. Matériel impressionnant, performances constantes, expérience utilisateur soignée. Son FlashBlade//S R2 évolue jusqu’à 60 Po par cluster avec des modules DirectFlash de 150 To.

NetApp StorageGRID 12.0 met l’accent sur l’IA avec des améliorations de débit de 20x via une mise en cache avancée et la prise en charge de plus de 600 milliards d’objets dans un seul cluster.

Les deux sont des solutions solides qui rivalisent avec Ceph RGW dans le stockage d’objets compatible S3. Les performances sont excellentes. La question que chaque organisation doit se poser est de savoir si le premium justifie le verrouillage fournisseur pour son cas d’utilisation spécifique.

La Question Que Personne Ne Pose : Qu’achètes-tu Vraiment ?

C’est ici que je mets mon chapeau d’ingénieur réfléchi.

Ceph upstream est extrêmement stable. Il compte 20 versions à son actif. La Fondation Ceph comprend IBM, Red Hat, Bloomberg, DigitalOcean, OVHcloud et des dizaines d’autres. Le développement est actif, la communauté est forte et la documentation est abondante.

Alors, quand est-il judicieux de payer pour une distribution entreprise et quand ne l’est-il pas ?

Cela a du sens lorsque : ton organisation a besoin d’un contrat de support pour la conformité ou une politique interne ; tu n’as pas le personnel technique pour faire fonctionner Ceph et tu ne veux pas le développer ; tu as besoin de cycles de mise à jour prévisibles et testés ; le coût de l’arrêt est plus élevé que le coût de la licence ; ou tu as besoin d’une intégration spécifique avec les produits d’autres fournisseurs.

Cela mérite une analyse plus approfondie lorsque : la décision est basée sur « c’est ce que tout le monde fait » ; personne n’a vraiment évalué les alternatives ; la raison principale est que « le fournisseur nous a dit que l’open source n’était pas supporté » ; ou tu disposes d’un équipement technique performant mais tu n’as pas investi dans sa formation.

Le vrai défi, c’est la connaissance. Ceph a une courbe d’apprentissage abrupte. Concevoir correctement un cluster, comprendre les CRUSH maps, régler BlueStore, optimiser les placement groups… tout cela nécessite une formation sérieuse et une expérience pratique.

Mais une fois que tu as ces connaissances, tu as des options. Tu peux choisir judicieusement un fournisseur entreprise, en sachant exactement quelle valeur ajoutée tu achètes. Ou tu peux opérer en upstream avec un support spécialisé. L’essentiel est de prendre une décision en connaissance de cause.

Démystifier les Affirmations Marketing

Une chose que je recommande toujours est de lire les benchmarks et les affirmations marketing avec un esprit critique constructif.

« Notre produit est 90x plus rapide » – Par rapport à quelle base de référence ? Sur quelle charge de travail spécifique ? Avec quelle configuration du concurrent ?

« Des performances équivalentes à celles de [concurrent] à 60 % du coût » – Cela inclut-il le TCO complet ? Licences, support, formation, personnel ?

« Solution certifiée de niveau entreprise » – Qu’est-ce que cela signifie exactement ? Parce que Ceph upstream est également de niveau entreprise au CERN, chez Bloomberg et dans des centaines de télécoms.

Je ne dis pas que ces affirmations sont fausses. Je dis que le contexte est important. En réalité, les performances du stockage distribué dépendent fortement de la conception correcte des clusters (domaines de défaillance, placement groups), du matériel approprié (réseau 25/100GbE, NVMe avec protection contre la perte de puissance), de la configuration du système d’exploitation (IOMMU, CPU governors) et du réglage spécifique à la charge de travail (osd_memory_target, paramètres BlueStore).

Un cluster Ceph bien conçu et géré par des personnes expérimentées peut atteindre des performances impressionnantes. Le benchmark Clyso a atteint 1 TiB/s avec 68 serveurs Dell PowerEdge. IBM a démontré plus de 450 000 IOPS sur un cluster Ceph à 4 nœuds avec 24 NVMe par nœud.

Parfois, cette estampille « solution certifiée » que tu vois sur une fiche technique est, au fond, un logiciel libre avec une configuration experte, un matériel bien dimensionné et beaucoup de tests. Cela a de la valeur, mais c’est bon de le savoir.

Une Décision Intelligente : Décider en S’informant

Après 15 ans dans ce secteur, ma conclusion est qu’il n’y a pas de réponse unique. Ce qu’il y a, ce sont des décisions éclairées.

Pour certaines organisations, une solution entreprise packagée est exactement ce dont elles ont besoin : un support garanti, des temps de cycle prévisibles, une intégration validée et la tranquillité d’esprit d’avoir un fournisseur responsable. IBM Fusion avec Storage Scale est un excellent choix pour le HPC. Red Hat Ceph Storage est une solution solide pour tous ceux qui veulent Ceph avec un backup entreprise.

Pour d’autres organisations, Ceph upstream avec un support et une formation spécialisés offre des avantages significatifs :

Gouvernance de fondation : Ceph est un projet de la Linux Foundation avec une gouvernance ouverte. Le cas MinIO ne peut pas se produire.
Communauté active : des milliers de contributeurs, des versions régulières, des bugs corrigés rapidement.
Flexibilité : c’est ton cluster, ta configuration. Si demain tu décides de changer de partenaire de support, tu ne perds rien.
TCO transparent : Le logiciel est gratuit. Tu investis dans le matériel et les connaissances appropriés.
Contrôle des versions : Tu mets à jour quand cela te semble logique, et non pas quand le fournisseur sort la prochaine version packagée.

Le dénominateur commun dans les deux cas est la connaissance. Que tu achètes une solution entreprise ou que tu déploies upstream, une compréhension approfondie de Ceph te permet de prendre de meilleures décisions, de mieux négocier avec les fournisseurs et de résoudre les problèmes plus rapidement.

Où Trouver Ces Connaissances

Ceph est complexe. Mais il existe des chemins clairs :

La documentation officielle est très complète et s’est beaucoup améliorée. Le blog Ceph propose d’excellents approfondissements techniques.

Cephalocon est la conférence annuelle où tu peux apprendre de ceux qui exploitent Ceph à une échelle réelle (Bloomberg, CERN, DigitalOcean).

Une formation structurée avec des laboratoires pratiques est le moyen le plus efficace d’acquérir de réelles compétences. Tu n’apprends pas Ceph en lisant des diapositives ; tu l’apprends en cassant et en réparant des clusters.

L’assistance technique L3 assurée par des personnes qui vivent Ceph tous les jours te sort du pétrin quand les choses se compliquent en production. Parce qu’elles se compliqueront. Chez SIXE, nous avons passé des années à former des équipes techniques à Ceph et à fournir une assistance L3 à des organisations de tous types : celles qui opèrent upstream, celles qui utilisent des distributions entreprise et celles qui évaluent les options. Notre programme de formation Ceph couvre tout, de l’architecture de base aux opérations avancées, avec de véritables laboratoires pratiques. Et si tu as déjà Ceph en production et que tu as besoin d’une véritable assistance technique, notre support technique spécialisé est conçu exactement pour cela.

Nous venons également de lancer un programme de certification avec des badges sur Credly pour que ton équipe puisse démontrer ses compétences de manière tangible. Parce que dans ce secteur, « connaître Ceph » ne signifie pas la même chose pour tout le monde.

Badge de certification SIXE CEPH Administrator - Administration du stockage Ceph niveau entrée

Badge de certification SIXE CEPH Advanced Administrator - Niveau avancé d'administration du stockage Ceph

Badge de certification SIXE CEPH Production Operations - Niveau expert en opérations Ceph en production

Conclusions pour 2026

MinIO est mort pour une utilisation sérieuse. Cherche des alternatives : Ceph RGW, SeaweedFS, Garage, ou même le fork RustFS si tu es courageux.
Comprends ce que tu achètes. Il y a des cas où une solution entreprise packagée apporte une réelle valeur ajoutée. Il y en a d’autres où tu paies principalement pour un logo et une configuration que tu pourrais reproduire.
Ceph upstream est mature et prêt pour la production. Bloomberg, DigitalOcean, le CERN et plus de 320 projets télécoms ne peuvent pas tous se tromper.
Le véritable coût du stockage distribué est la connaissance. Investis dans une formation et un support de qualité, quelle que soit l’option choisie.
Le contrôle de ton infrastructure a de la valeur. Demande aux clients de SUSE SES comment cela s’est passé lorsque le fournisseur a décidé de pivoter.
La gouvernance du projet compte autant que la technologie. Fondation ouverte > entreprise avec un produit open source.

2026 s’annonce intéressant. FastEC va changer l’équation de l’erasure coding. L’intégration avec l’IA et le ML continuera de pousser vers plus de performance. Et l’écosystème des fournisseurs continuera d’évoluer avec des propositions qui méritent une évaluation sérieuse.

C’est à toi de décider. C’est la seule chose importante.

Portage de MariaDB vers IBM AIX (Partie 2) : comment AIX se met au niveau de Linux

28 janvier 2026/dans Informations/par Hugo

De “AIX est lent” à “AIX égale Linux” (avec les bons outils et le bon code)

Dans la première partie, je me suis battu avec CMake, j’ai implémenté un pool de threads à partir de zéro et j’ai livré un serveur MariaDB 11.8.5 stable pour AIX. Le serveur a passé 1 000 connexions simultanées, 11 millions de requêtes et aucune fuite de mémoire.

Ensuite, j’ai effectué une recherche vectorielle de référence.

AIX: 42 requêtes par seconde.
Linux (même HW) : 971 requêtes par seconde.

Vingt-trois fois plus lent. Sur un matériel IBM Power S924 identique. Même version de MariaDB. Même jeu de données.

Voici l’histoire de la façon dont nous avons découvert qu’il n’y avait aucun écart de performance – juste des erreurs de configuration et un compilateur sous-optimal.

Chapitre 1 : Le sentiment d’affaissement

Il y a un genre particulier de désespoir qui vient quand on voit un écart de performance de 23x sur un matériel identique. C’est le genre de désespoir “j’aurais peut-être dû devenir fleuriste”.

Permettez-moi de planter le décor : les deux machines sont des LPARs fonctionnant sur des serveurs IBM Power S924 avec des processeurs POWER9 à 2750 MHz. Même MariaDB 11.8.5. Même ensemble de données de test – 100 000 vecteurs à 768 dimensions, utilisant l’index MHNSW (Hierarchical Navigable Small World) de MariaDB pour la recherche vectorielle.

Le critère de référence était simple : trouver les 10 voisins les plus proches d’un vecteur de requête. C’est le genre d’opération qui alimente toutes les fonctions de recherche améliorées par l’IA que tu as déjà utilisées.

Linux l’a fait en environ 1 milliseconde. AIX a mis 24 millisecondes.

Mon premier réflexe a été le déni. “Le repère doit être erroné”. Ce n’était pas le cas. “Peut-être que l’index est corrompu”. Ce n’était pas le cas. “Peut-être que le réseau est lent”. Il s’agissait d’une connexion locale.

Il est temps de creuser.

Chapitre 2 : Les premiers 65x – L’importance de la configuration

Le cache qui a tout oublié

Le premier indice est venu du profileur de MariaDB. Chaque requête prenait le même temps, qu’il s’agisse de la première ou de la centième. Ce n’est pas ainsi que fonctionnent les caches.

J’ai vérifié la configuration MHNSW de MariaDB :

SHOW VARIABLES LIKE 'mhnsw%';

mhnsw_max_cache_size: 16777216

16 MO. Notre graphique vectoriel a besoin d’environ 300 Mo pour contenir la structure HNSW en mémoire.

C’est là que le bât blesse : lorsque le cache se remplit, MariaDB n’expulse pas les anciennes entrées (pas de LRU). Il jette tout et repart à zéro. Chaque. Chaque. Demande.

Imagine une bibliothèque où, lorsque les étagères sont pleines, le bibliothécaire brûle tous les livres et commande de nouveaux exemplaires. Pour chaque utilisateur.

Correction: mhnsw_max_cache_size = 4GB dans la configuration du serveur.

Résultat : 42 QPS → 112 QPS. Une amélioration de 2,7x à partir d’une seule ligne de configuration.

Le problème de la taille des pages

AIX utilise par défaut des pages de mémoire de 4 Ko. Linux sur POWER utilise des pages de 64 Ko.

Pour le modèle d’accès du MHNSW – la chasse aux pointeurs sur un graphique de 300 Mo – cela a une importance énorme. Avec des pages de 4 Ko, tu as besoin de 16x plus d’entrées TLB (Translation Lookaside Buffer) pour mapper la même quantité de mémoire. Les erreurs du TLB coûtent cher.

C’est comme si tu naviguais dans une ville. Avec des pages de 4 Ko, tu as besoin d’indications pour chaque bâtiment. Avec des pages de 64 Ko, tu obtiens des indications par quartier. C’est beaucoup plus rapide quand tu es constamment en train de sauter d’un bâtiment à l’autre.

Correction: script d’enrobage qui définit LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

Résultat : 112 QPS → 208 QPS en séquentiel, et 2 721 QPS avec 12 travailleurs en parallèle.

Le tableau d’affichage après la phase 1

Configuration	QPS séquentiel	Avec 12 travailleurs
Base de référence	42	~42
+ 4GB cache	112	–
+ 64K pages	208	2,721

Amélioration de 65x à partir de deux changements de configuration. Aucune modification du code.

Mais nous étions toujours 6x plus lents que Linux par cœur. L’enquête s’est poursuivie.

Chapitre 3 : Le mystère du décrochage entre le CPU et la mémoire

Une fois la configuration établie, j’ai sorti les outils de profilage. MariaDB possède un profileur intégré qui décompose le temps de requête par phase.

AIX:

Sending data: 4.70ms total
  - CPU_user: 1.41ms
  - CPU_system: ~0ms
  - Stalls: 3.29ms (70% of total!)

Linux:

Sending data: 0.81ms total
  - CPU_user: 0.80ms
  - Stalls: ~0.01ms (1% of total)

Le temps d’exécution de l’unité centrale était 1,8 fois plus lent sur AIX – ce qui peut s’expliquer par les différences de compilateur. Mais les blocages de la mémoire étaient 329 fois pires.

La cause première : Invalidation du cache de l’hyperviseur

Voici quelque chose que j’ai mis deux jours à comprendre : dans une LPAR (Logical Partition) partagée, l’hyperviseur POWER préempte périodiquement les processeurs virtuels pour donner du temps à d’autres partitions. Ce faisant, il peut invalider des lignes de cache L2/L3.

La traversée du graphe du MHNSW est une chasse aux pointeurs à travers 300 Mo de mémoire – littéralement le pire scénario pour l’invalidation de la mémoire cache. Tu sautes de nœud en nœud, chacun dans une partie différente de la mémoire, et l’hyperviseur vide périodiquement ton cache.

C’est comme essayer de lire un livre alors que quelqu’un ne cesse de le fermer et de le remettre sur l’étagère.

Le système Linux avait des processeurs dédiés. Le système AIX fonctionnait avec des processeurs partagés. Ce ne sont pas des pommes pour des pommes.

Mais avant de pouvoir tester les processeurs dédiés, je devais résoudre le problème du compilateur.

Chapitre 4 : L’odyssée du compilateur

Tout ce que j’ai essayé avec GCC (et pourquoi ça a échoué)

Tentative	Résultat	Pourquoi
`-flto` (Optimisation du temps de connexion)	Impossible	GCC LTO nécessite le format ELF ; AIX utilise XCOFF
`-fprofile-generate` (PGO)	Échec de la construction	Erreurs de l’assembleur concernant la relocalisation relative au TOC
`-ffast-math`	Tout se casse la figure	IEEE float violations corrupt bloom filter hashing
`-funroll-loops`	Plus lent	Cache d’instruction gonflé – POWER9 n’aime pas ça
`-finline-functions`	Plus lent	Même problème de cache I

La boîte à outils AIX GCC est construite sans support LTO. Ce n’est pas un drapeau que tu as oublié – c’est architecturalement impossible parce que l’implémentation LTO de GCC nécessite ELF, et AIX utilise XCOFF.

Les paquets MariaDB d’Ubuntu utilisent -flto=auto. Cette optimisation n’existe tout simplement pas pour AIX avec GCC.

IBM Open XL : Le rebondissement de l’intrigue

À ce stade, j’ai passé trois jours à essayer de rendre GCC plus rapide. Il est temps d’essayer quelque chose de différent.

IBM Open XL C/C++ 17.1.3 est le compilateur moderne d’IBM, basé sur LLVM/Clang. Il génère un code nettement meilleur pour POWER9 que GCC.

Pour construire MariaDB avec Open XL, il a fallu résoudre cinq problèmes différents :

En-tête HTM manquant: Open XL n’a pas le fichier htmxlintrin.h de GCC. J’ai créé un stub.
AR 32 bits par défaut: Les outils AIX sont par défaut en 32 bits. Définis OBJECT_MODE=64.
Incompatibilité LLVM AR: Open XL’s AR ne pouvait pas gérer XCOFF. Utilise le système /usr/bin/ar.
Conflits OpenSSL: Utilise -DWITH_SSL=system pour éviter les problèmes liés à WolfSSL.
Chemins d’accès aux bibliothèques manquants: Explicit -L/opt/freeware/lib pour l’éditeur de liens.

Ensuite, j’ai exécuté le test de référence :

Compilateur	30 requêtes	Par requête
GCC 13.3.0	0.190s	6.3ms
Open XL 17.1.3	0.063s	2.1ms

Trois fois plus rapide. Même code source. Mêmes drapeaux d’optimisation (-O3 -mcpu=power9).

Et voici le bonus : la variance du benchmark de GCC était de 10 à 40 % entre les exécutions. La variance d’Open XL était inférieure à 2 %. Il n’y a pratiquement pas de gigue.

Pourquoi une telle différence ?

Open XL (qui est basé sur LLVM) l’a fait :

Meilleure planification des instructions pour l’exécution hors ordre de POWER9
Attribution de registres supérieurs
Des passes d’optimisation plus agressives

Le backend POWER/XCOFF de GCC n’est tout simplement pas aussi mature. La boîte à outils AIX GCC est fonctionnelle, mais elle n’est pas optimisée pour les charges de travail critiques en termes de performances.

Chapitre 5 : Les impasses du LTO et du PGO

L’espoir est éternel. Peut-être que les LTO et PGO d’Open XL fonctionneraient ?

LTO : L’ironie

Open XL prend en charge -flto=full sur XCOFF. Il se construit vraiment ! Mais…

Résultat : 27 % plus lent que l’Open XL non LTO.

Pourquoi ? Les bibliothèques partagées AIX nécessitent une liste d’exportation explicite (exports.exp). Avec LTO, le script de CMake a vu ~27 000 symboles à exporter.

Le principal avantage de l’OLT est d’internaliser les fonctions, c’est-à-dire de les marquer comme étant locales afin qu’elles puissent être optimisées ou mises en ligne. Lorsque tu es obligé d’exporter 27 000 symboles, aucun d’entre eux ne peut être internalisé. Les frais généraux de l’OLT (fichiers intermédiaires plus volumineux, liaison plus lente) demeurent, mais l’avantage disparaît.

C’est comme si tu payais un abonnement à une salle de sport et qu’on te disait ensuite que tu ne peux utiliser aucun des équipements.

PGO : Les profils qui n’ont jamais existé

L’optimisation guidée par le profil semblait prometteuse :

Construis avec -fprofile-generate
Charge de travail pour l’entraînement à la course à pied
Reconstruis avec -fprofile-use
Profite d’un code plus rapide

L’étape 1 a fonctionné. Étape 2… les profils ne sont jamais apparus.

J’ai lié manuellement le runtime de profilage LLVM à la bibliothèque partagée. Toujours pas de profils.

La cause première : Le runtime de profilage de LLVM utilise atexit() ou __attribute__((destructor)) pour écrire des profils à la sortie. Sur AIX avec XCOFF, la sémantique des destructeurs de bibliothèques partagées est différente de celle d’ELF. Le gestionnaire n’est tout simplement pas appelé de manière fiable pour les configurations complexes à plusieurs bibliothèques comme MariaDB.

Les cas de test simples fonctionnent. Les applications réelles ne fonctionnent pas.

Chapitre 6 : La révélation LPAR

J’avais maintenant un compilateur rapide. Il est temps de tester les processeurs dédiés et d’éliminer le problème d’invalidation du cache de l’hyperviseur.

La matrice de test

Config LPAR	GCC	Open XL
12 vCPUs partagés	0.190s	0.063s
12 plafonds dédiés	0.205s	0.082s
21 dédiés plafonnés	0.320s	0.067s

Attends. Les services partagés sont plus rapides que les services dédiés ?

Le facteur WoF

POWER9 dispose d’une fonction appelée Workload Optimized Frequency (WoF). En mode partagé avec une faible utilisation, un seul cœur peut atteindre ~3,8 GHz. Les processeurs dédiés plafonnés sont bloqués à 2750 MHz.

Pour une requête à un seul fil, le mode partagé obtient 38 % de vitesse d’horloge en plus. Cela bat la pénalité d’invalidation du cache pour cette charge de travail.

Imagine que tu choisisses entre une voiture de sport sur une autoroute avec une circulation occasionnelle (partagée) et un camion avec une voie réservée mais une limite de vitesse (dédiée plafonnée).

Le désastre du mode donateur de PowerVM

Il existe une troisième option : les processeurs dédiés en mode “Donating”, qui redonnent les cycles inactifs au pool partagé.

Mode	GCC	Open XL
Plafonné	0.205s	0.082s
Faire un don	0.325s	0.085s

60% de régression avec GCC.

Chaque fois qu’une requête explose, il y a un temps de latence pour récupérer les cycles donnés. Pour les charges de travail en rafale et à un seul fil, comme les requêtes de base de données, c’est dévastateur.

Recommandation: N’utilise jamais le mode Don pour les charges de travail des bases de données.

Le 21-Core Sweet Spot

Avec 21 cœurs dédiés (contre 24 pour Linux), Open XL a atteint 0,067s – égalant presque les 0,063s du mode partagé. Le cache L3 supplémentaire apporté par plus de cœurs compense l’absence d’augmentation de la fréquence du WoF.

Chapitre 7 : Le tableau d’affichage final (rebondissement)

Nouveaux benchmarks sur du matériel POWER9 identique, janvier 2026 :

Plateforme	Cœurs	30 requêtes
Linux	24 dédié	0.057s
AIX + Open XL	12 partagés	0.063s
AIX + Open XL	21 dédié	0.067s
AIX + GCC	12 partagé	0.190s
AIX + GCC	21 dédié	0.320s

Attends. Le système AIX a 21 cœurs contre 24 pour Linux. Cela représente 12,5 % de cœurs en moins, ce qui signifie 12,5 % de cache L3 en moins.

L’écart mesuré ? 10-18%.

Ce n’est pas un écart de performance. C’est une différence de matériel.

Avec IBM Open XL, AIX offre des performances par cœur identiques à celles de Linux. L’écart de 23x que nous avons constaté au début ? Il n’a jamais été question de la lenteur d’AIX. C’était le cas :

Un cache mal configuré (16 Mo au lieu de 4 Go)
Taille des pages incorrecte (4KB au lieu de 64KB)
Le mauvais compilateur (GCC au lieu d’Open XL)

Le mythe “AIX est lent” est mort.

Le musée complet de l’échec

La science ne se limite pas à ce qui fonctionne – il s’agit aussi de documenter ce qui ne fonctionne pas. Voici notre mur de “bien essayé, mais non” :

Ce que nous avons essayé	Résultat	Notes
`mhnsw_max_cache_size = 4GB`	5 fois plus rapide	Élimine les tressautements de la mémoire cache
`LDR_CNTRL` 64K pages	~40% plus rapide	Réduit les erreurs de la TLB
`MAP_ANON_64K` patch mmap	~8% plus rapide	Amélioration mineure du TLB
IBM Open XL 17.1.3	3x plus rapide	Meilleur codegen POWER9
LPAR partagé (vs dédié)	~25% plus rapide	Augmentation de la fréquence du WoF
Open XL + LTO	27% plus lent	Conflit d’exportation AIX
Open XL + PGO	Ne fonctionne pas	Profils non écrits
GCC LTO	Impossible	XCOFF n’est pas pris en charge
GCC PGO	Échecs de construction	Erreurs de relocalisation du TOC
`-ffast-math`	Casse MHNSW	Corruption par flottaison
`-funroll-loops`	Pire	I-cache bloat
POWER VSX bloom filter	41% plus lent	Pas de multiplication vec 64 bits sur P9
Préfixe logiciel	Aucun effet	L’hyperviseur évince les données préfixées
Réglage du DSCR	Bloqué	L’hyperviseur contrôle le DSCR dans les LPAR partagés
Mode de don	60% de régression	Ne jamais utiliser pour les bases de données

Le résultat de VSX est particulièrement intéressant : nous avons implémenté un filtre Bloom SIMD en utilisant les extensions vectorielles de POWER. Il était 41 % plus lent que le scalaire. POWER9 n’a pas de multiplication vectorielle 64 bits – il faut vec_extract → multiplication scalaire → vec_insert pour chaque voie, ce qui est plus lent que de laisser le moteur Out-of-Order gérer une boucle scalaire.

Ce que j’ai appris

1. Les défauts de paiement sont plus importants que tu ne le penses

Un cache de 16 Mo par défaut a transformé des requêtes de moins d’une milliseconde en requêtes de 24 ms. C’est une pénalité de 24x pour un seul paramètre mal configuré.

Lorsque tu portes un logiciel, remets en question tous les paramètres par défaut. Ce qui fonctionne sous Linux peut ne pas fonctionner sur ta plateforme.

2. Le mythe de la lenteur d’AIX a toujours été un problème de chaîne d’outils

Avec GCC, nous étions 3 à 4 fois plus lents que Linux. Avec Open XL, nous sommes au même niveau que Linux par cœur.

La plateforme n’a jamais été lente. La chaîne d’outils par défaut n’était tout simplement pas optimisée pour les charges de travail critiques en termes de performances. Choisis le bon compilateur.

3. La virtualisation comporte des compromis cachés

Les LPAR partagés peuvent être plus rapides que les LPAR dédiés pour les charges de travail monothématiques (augmentation de la fréquence du WoF). Le mode dédié est plus efficace pour les charges de travail multithreads soutenues. Le mode don est un piège.

Connais ta charge de travail. Choisis ta configuration LPAR en conséquence.

4. Tous les ports d’optimisation n’ont pas la même valeur

LTO, PGO et la vectorisation SIMD ont tous échoué sur AIX pour diverses raisons. Les techniques qui rendent Linux rapide ne se traduisent pas toujours.

Parfois, l’optimisation “évidente” est le mauvais choix. Mesure tout.

5. Parfois, il n’y a pas d’écart du tout

Nous avons passé des jours à enquêter sur un “écart de performance” qui s’est avéré être :

Erreurs de configuration
Mauvais compilateur
Moins de cœurs sur le système de test

La leçon à retenir : vérifie tes données de base. Assure-toi de comparer des pommes avec des pommes avant de supposer qu’il y a un problème à résoudre.

Recommandations

Pour les utilisateurs d’AIX MariaDB

Utilise la version Open XL (version 3, bientôt disponible)
Règle mhnsw_max_cache_size sur au moins 4 Go pour la recherche vectorielle
Conserver le LPAR partagé pour une latence de requête unique
N’utilise jamais le mode don pour les bases de données
Utilise des pages de 64K via le wrapper LDR_CNTRL

Pour MariaDB en amont

Augmente la valeur par défaut de mhnsw_max_cache_size – 16MB est beaucoup trop petit
Mettre en œuvre l’éviction LRU – jeter tout le cache en cas de débordement est brutal.
N’ajoute pas le filtre bloom POWER VSX – le scalaire est plus rapide sur POWER9

Prochaines étapes

Les RPM sont publiés sur aix.librepower.org. Release 2 includes the configuration fixes. La version 3 avec Open XL est également disponible.

Priorités immédiates:

Licence commerciale Open XL : L’évaluation expire bientôt. Il faut vérifier auprès d’IBM si nous sommes d’accord pour utiliser xLC à cette fin.
Implémentation native de l’AIO: AIX a POSIX AIO et IOCP compatible avec Windows. Il est temps d’écrire le backend InnoDB.
Retour d’information sur le MHNSW en amont: La valeur par défaut de mhnsw_max_cache_size (16 Mo) est trop faible pour les charges de travail réelles ; nous suggérerons une valeur par défaut plus élevée.

Pour les organisations qui exécutent déjà des charges de travail critiques sur AIX – et il y en a beaucoup, des banques aux compagnies aériennes en passant par les systèmes de santé – la possibilité d’exécuter également MariaDB moderne et performant ouvre de nouvelles possibilités.

AIX correspond à Linux. Le mythe est mort. Et MariaDB sur AIX est prêt pour la production.

TL;DR

Au départ, l’écart de performance était de 23x (42 QPS contre 971 QPS).
Configuration du cache corrigée : Amélioration de 5x
Taille de page fixe : ~40% de plus
Passage à IBM Open XL: amélioration de 3x par rapport à GCC
LPAR partagé utilisé : ~25% plus rapide que le dédié (WoF boost)
Résultat final : NO GAP – 10% de différence = 12,5% de cœurs en moins (21 vs 24)
AIX atteint les mêmes performances par cœur que Linux grâce à Open XL
Open XL LTO : n’aide pas (27% plus lent)
Open XL PGO : ne fonctionne pas (problème AIX XCOFF)
POWER VSX SIMD : 41% plus lent que le scalaire (pas de multiplication vec 64 bits)
Mode donateur : 60% de régression – ne jamais utiliser pour les bases de données
“AIX est lent pour les bases de données open source” a toujours été un mythe de la chaîne d’outils.

Des questions ? Des idées ? Tu utilises MariaDB sur AIX et tu veux partager ton expérience ?

This work is part of LibrePower – Unlocking IBM Power Systems through open source. Unmatched RAS. Superior TCO. Minimal footprint ?

Dépôt du projet LibrePower AIX : gitlab.com/librepower/aix

MariaDB sur AIX | 3 Semaines de Développement Technique (Partie 1)

28 janvier 2026/dans Informations/par Hugo

MariaDB sur AIX, la plateforme qui alimente les systèmes les plus critiques au monde

Dans la vie, il y a des décisions que tu prends en sachant très bien qu’elles te feront souffrir. Se marier. Avoir des enfants. Courir un marathon. Porter MariaDB 11.8 sur IBM AIX.

Voici (partie 1) l’histoire de la dernière édition – et les raisons pour lesquelles je la referais sans hésiter.

Chapitre 1 : “C’est si dur que ça ?”

Tout a commencé par une question innocente lors d’une réunion d’équipe : “Pourquoi n’avons-nous pas MariaDB sur nos systèmes AIX ?”

Voici ce que les gens qui n’ont jamais travaillé avec AIX ne comprennent pas : AIX ne plaisante pas. Lorsque les banques ont besoin d’un temps de disponibilité de cinq neuf pour leurs systèmes bancaires de base, elles utilisent AIX. Lorsque les compagnies aériennes ont besoin de systèmes de réservation qui ne peuvent pas tomber en panne, elles utilisent AIX. Quand Oracle, Informix ou DB2 doivent fournir des performances absolument brutales pour des charges de travail OLTP critiques, ils utilisent AIX.

AIX n’est pas à la mode. AIX n’a pas de mascotte cool. AIX ne fera pas l’objet d’articles de blogs technologiques essoufflés sur la “perturbation”. Mais lorsque les choses ne peuvent absolument pas échouer, AIX est là, faisant tranquillement son travail pendant que tous les autres sont occupés à redémarrer leurs conteneurs.

Alors pourquoi MariaDB ne prend-elle pas officiellement en charge AIX ? L’économie est simple : la communauté open source s’est concentrée sur Linux, et le portage nécessite une expertise spécifique à la plateforme. MariaDB prend officiellement en charge Linux, Windows, FreeBSD, macOS et Solaris. AIX ne figure pas sur la liste – non pas parce que c’est une mauvaise plate-forme, mais parce que personne n’a encore fait le travail.

Chez LibrePower, c’est exactement ce que nous faisons.

Ma première erreur a été de dire tout haut : “Il suffit sans doute de le compiler et d’ajuster quelques éléments”.

Leçon n° 1: Lorsque quelqu’un dit ” compile-le simplement ” à propos d’un logiciel sur AIX, il est sur le point d’en apprendre beaucoup sur la programmation des systèmes.

Chapitre 2: Défis de CMake pour MariaDB sur AIX

Le premier jour de la compilation a été… éducatif. CMake sur AIX, c’est comme jouer aux cartes avec quelqu’un qui a une compréhension très différente des règles – et qui s’attend à ce que tu les découvres toi-même.

Le bogue de la fonction fantôme

AIX a une caractéristique intéressante : il déclare des fonctions dans les en-têtes pour des raisons de compatibilité, même si ces fonctions n’existent pas réellement au moment de l’exécution. C’est comme si ton GPS te disait “tourne à droite dans 200 mètres” mais que la rue était un mur de briques.

CMake fait un CHECK_C_SOURCE_COMPILES pour tester si pthread_threadid_np() existe. Le code se compile. CMake dit “super, on l’a !” Le binaire démarre et… BOOM. Symbole non trouvé.

Il s’avère que pthread_threadid_np() est réservé à macOS. AIX le déclare dans les en-têtes parce que… eh bien, je ne suis pas encore tout à fait sûr. Peut-être pour une raison de compatibilité POSIX qui avait un sens il y a des décennies ? Quelle que soit la raison, GCC le compile sans problème et l’éditeur de liens ne se plaint pas jusqu’à l’exécution.

Même chose avec getthrid(), qui est spécifique à OpenBSD.

La solution:

IF(NOT CMAKE_SYSTEM_NAME MATCHES "AIX")
  CHECK_C_SOURCE_COMPILES("..." HAVE_PTHREAD_THREADID_NP)
ELSE()
  SET(HAVE_PTHREAD_THREADID_NP 0)  # Trust but verify... okay, just verify
ENDIF()

poll.h : Cache-cache

AIX a <sys/poll.h>. C’est juste là. Tu peux cat. Mais CMake ne le détecte pas.

Après trois heures de débogage d’une erreur “POLLIN undeclared” dans viosocket.c, j’ai découvert que la solution consistait simplement à forcer la définition :

cmake ... -DHAVE_SYS_POLL_H=1

Trois heures. Pour un drapeau.

(Pour être honnête, il s’agit d’un problème de détection de plate-forme CMake, et non d’un problème AIX. Les vérifications de CMake supposent des dispositions d’en-tête de type Linux).

Les plugins maudits

À 98 % de la compilation – 98 % ! – le plugin wsrep_info a explosé avec des symboles non définis. Parce qu’il dépend de Galera. Que nous n’utilisons pas. Mais CMake le compile quand même.

Egalement S3 (nécessite les symboles Aria), Mroonga (nécessite Groonga), et RocksDB (profondément lié aux optimisations spécifiques à Linux).

Configuration finale de CMake :

-DPLUGIN_MROONGA=NO -DPLUGIN_ROCKSDB=NO -DPLUGIN_SPIDER=NO 
-DPLUGIN_TOKUDB=NO -DPLUGIN_OQGRAPH=NO -DPLUGIN_S3=NO -DPLUGIN_WSREP_INFO=NO

Cela ressemble à une amputation chirurgicale, mais il s’agit en fait de tailler dans le gras. Ces plugins sont des cas limites dont peu de déploiements ont besoin.

Chapitre 3: Implémentation du Thread Pool pour MariaDB sur AIX via Pollset

C’est là que les choses sont devenues intéressantes. Et par “intéressant”, je veux dire “j’ai failli me donner un tic permanent”.

MariaDB a deux modes de gestion des connexions :

une-filière-par-connexion: Un thread par client. Simple. S’adapte comme une voiture qui monte une côte.
pool de threads: Un pool fixe de threads gère toutes les connexions. Élégant. Efficace. Et non disponible sur AIX.

Pourquoi ? Parce que le pool de threads nécessite des API de multiplexage d’E/S spécifiques à la plateforme :

Plateforme	API	Statut
Linux	epoll	Pris en charge
FreeBSD/macOS	kqueue	Pris en charge
Solaris	ports d’événements	Pris en charge
Windows	IOCP	Pris en charge
AIX	pollset	Non pris en charge (jusqu’à présent)

Alors… à quel point la mise en œuvre de la prise en charge des jeux de vote peut-elle être difficile ?

(Note de la rédaction : à ce stade, l’auteur a besoin d’une pause de 20 minutes et d’une boisson).

Le problème ONESHOT

Linux epoll possède un merveilleux drapeau appelé EPOLLONESHOT. Il garantit qu’un descripteur de fichier ne déclenche des événements qu’une seule fois jusqu’à ce que tu le réarmes explicitement. Cela empêche deux threads de traiter la même connexion simultanément.

Le pollset AIX est déclenché par niveau. Uniquement déclenché par niveau. Pas d’options. Si des données sont disponibles, il les signale. Encore et encore et encore. Comme un collègue serviable qui te rappelle sans cesse ce courriel auquel tu n’as pas encore répondu.

Onze versions de la sagesse croissante

Il s’en est suivi onze itérations de code, toutes plus élaborées les unes que les autres, pour essayer de simuler le comportement de ONESHOT :

v1-v5 (L’âge de l’innocence)

J’ai essayé de modifier les drapeaux d’événements avec PS_MOD. “Si je mets l’événement à 0, il ne se déclenchera plus”, me suis-je dit. Spoiler : il n’a pas cessé de se déclencher.

v6-v7 (L’ère des machines à états)

“Je sais ! Je vais maintenir l’état interne et filtrer les événements en double.” Le problème : il y a une fenêtre de temps entre le moment où le noyau te donne l’événement et celui où tu mets à jour ton état. Dans cette fenêtre, un autre thread peut recevoir le même événement.

v8-v9 (La phase de déni)

“Je vais mettre l’état à PENDANT avant de traiter”. Ça a marché… en quelque sorte… jusqu’à ce que ça ne marche plus.

v10 (Espoir)

J’ai enfin trouvé la solution : PS_DELETE + PS_ADD. Lorsque tu reçois un événement, supprime immédiatement le fd du pollset. Lorsque tu es prêt à recevoir d’autres données, ajoute-le à nouveau.

// On receiving events: REMOVE
for (i = 0; i < ret; i++) {
    pctl.cmd = PS_DELETE;
    pctl.fd = native_events[i].fd;
    pollset_ctl(pollfd, &pctl, 1);
}

// When ready: ADD
pce.command = PS_ADD;
pollset_ctl_ext(pollfd, &pce, 1);

Ça a marché ! Avec -O2.

Avec -O3… segfault.

Porter MariaDB sur AIX = Bugs (Le bug -O3)

Imagine mon visage. J’ai un code qui fonctionne parfaitement avec -O2. J’active -O3 pour les benchmarks de production et le serveur se plante avec “Got packets out of order” ou un segfault dans CONNECT::create_thd().

J’ai passé deux jours à penser qu’il s’agissait d’un bug du compilateur. GCC 13.3.0 sur AIX. J’ai accusé le compilateur. J’ai blâmé l’éditeur de liens. J’ai tout blâmé sauf mon propre code.

Le problème était plus subtil : MariaDB a deux chemins de code concurrents qui appellent io_poll_wait sur le même pollset :

Les blocs d’écoute avec timeout=-1
Le travailleur fait appel à timeout=0 pour les vérifications non bloquantes.

Avec -O2, la synchronisation était telle que les collisions étaient rares. Avec -O3, le code était plus rapide, les collisions se produisaient plus souvent, et boom – race condition.

v11 (L’illumination)

La solution consistait à créer un mutex dédié protégeant à la fois pollset_poll et toutes les opérations de pollset_ctl:

static pthread_mutex_t pollset_mutex = PTHREAD_MUTEX_INITIALIZER;

int io_poll_wait(...) {
    pthread_mutex_lock(&pollset_mutex);
    ret = pollset_poll(pollfd, native_events, max_events, timeout);
    // ... process and delete events ...
    pthread_mutex_unlock(&pollset_mutex);
}

Oui, il sérialise l’accès au pollset. Oui, c’est théoriquement plus lent. Mais tu sais ce qui est encore plus lent ? Un serveur qui tombe en panne.

Le code final de la v11 a passé 72 heures de tests de résistance avec 1 000 connexions simultanées. Aucun plantage. Aucune fuite de mémoire. Aucun “paquet hors service”.

Chapitre 4 : La chose `-blibpath` (en fait une caractéristique)

Une véritable caractéristique d’AIX : tu dois spécifier explicitement le chemin de la bibliothèque au moment de la liaison avec -Wl,-blibpath:/your/path. Si tu ne le fais pas, le binaire ne trouvera pas libstdc++ même s’il se trouve dans le même répertoire.

Au début, cela te semble ennuyeux. Puis tu réalises : AIX préfère les chemins explicites et déterministes aux recherches implicites. Dans les environnements de production où “ça a marché sur ma machine” n’est pas acceptable, c’est une caractéristique, pas un bogue.

Chapitre 5 : Stabilité – Les chiffres qui comptent

Après tout ce travail, où en sommes-nous ?

Le RPM est publié sur aix.librepower.org et déployé sur un système IBM POWER9 (12 cœurs, SMT-8). MariaDB 11.8.5 fonctionne sur AIX 7.3 avec le pool de threads activé. Le serveur a passé avec succès une suite d’assurance qualité brutale :

Test	Résultat
100 connexions simultanées	✓
500 connexions simultanées	✓
1 000 connexions	✓
30 minutes de charge soutenue	✓
11+ millions de requêtes	✓
Fuites de mémoire	ZÉRO

1 648 482 400 octets de mémoire – constants pendant 30 minutes. Pas un seul octet de dérive. Le serveur a fonctionné pendant 39 minutes en charge continue et s’est éteint proprement.

Il fonctionne. Il est stable. Il est prêt à être mis en production.

Impact du pool de fils

Le travail sur le pool de threads a permis des gains massifs pour les charges de travail simultanées :

Configuration	Mélange de 100 clients	par rapport à la ligne de base
Original `-O2` one-thread-per-connection	11.34s	–
`-O3` + pool-of-threads v11	1.96s	83% plus rapide

Pour les charges de travail OLTP à forte concordance, c’est la différence entre “lutter” et “voler”.

Ce que j’ai appris (jusqu’à présent)

CMake suppose qu’il s’agit de Linux. Sur les systèmes non-Linux, vérifie manuellement que la détection des fonctionnalités est correcte. Les faux positifs te feront mal au moment de l’exécution.
Les entrées/sorties déclenchées par niveau nécessitent de la discipline. EPOLLONESHOT existe pour une raison. Si ton système ne l’a pas, prépare-toi à mettre en œuvre ta propre sérialisation.
-O3 expose les bogues latents. Si ton code “fonctionne avec -O2 mais pas avec -O3”, tu as une condition de course. Le compilateur fait son travail ; le bogue est le tien.
Les mutex sont tes amis. Oui, elles ont des frais généraux. Mais tu sais ce qui est le plus coûteux ? Déboguer les conditions de course à 3 heures du matin.
AIX récompense la compréhension profonde. C’est un système qui ne pardonne pas les raccourcis, mais une fois que tu as compris ses conventions, il est prévisible et robuste. Ce n’est pas pour rien que les banques l’utilisent encore – et qu’elles continueront à le faire dans un avenir prévisible.
L’écosystème est important. Des projets comme linux-compat de LibrePower rendent le développement moderne viable sur AIX. Contribuer à cet écosystème profite à tout le monde.

Qu’est-ce qu’on fait maintenant ? La question de la performance

Le serveur est stable. Le pool de discussion fonctionne. Mais il y a une question en suspens à laquelle je n’ai pas encore répondu :

Quelle est sa rapidité par rapport à Linux ?

J’ai effectué un test de recherche vectorielle – le type d’opération qui permet d’améliorer les fonctions de recherche de l’IA. Index MHNSW (Hierarchical Navigable Small World) de MariaDB, 100 000 vecteurs, 768 dimensions.

Linux sur du matériel POWER9 identique : 971 requêtes par seconde.

AIX avec notre nouvelle version : 42 requêtes par seconde.

Vingt-trois fois plus lent.

Mon cœur s’est effondré. Trois semaines de travail, et nous sommes 23x plus lents que Linux ? Sur un matériel identique?

Mais voici ce qu’il en est de l’ingénierie : lorsque les chiffres n’ont pas de sens, il y a toujours une raison. Et parfois, cette raison s’avère être une bonne nouvelle surprenante.

Dans la deuxième partie, je couvrirai :

Comment nous avons découvert que l’écart de 23x était surtout une erreur de configuration.
Le compilateur qui a tout changé
Pourquoi “AIX est lent” s’est avéré être un mythe
Le “musée des échecs” complet des optimisations qui n’ont pas fonctionné.

Les RPM sont publiés sur aix.librepower.org. La version GCC est stable et prête pour la production.

Mais l’histoire de la performance ? C’est là que les choses deviennent vraiment intéressantes.

La deuxième partie arrive bientôt.

TL;DR

MariaDB 11.8.5 fonctionne maintenant sur AIX 7.3 avec le pool de threads activé
Première mise en œuvre d’un pool de threads pour AIX à l’aide d’un pollset (11 itérations pour obtenir une simulation ONESHOT correcte).
Le serveur est stable: 1 000 connexions, plus de 11 millions de requêtes, aucune fuite de mémoire.
Le pool de threads offre une amélioration de 83 % pour les charges de travail simultanées
Le premier test de recherche vectorielle montre un écart de 23x par rapport à Linux – mais est-ce que c’est tout ?
RPMs publiés sur aix.librepower.org
La deuxième partie sera bientôt disponible: L’enquête sur les performances

Des questions ? Des idées ? Tu veux contribuer à l’écosystème open source AIX ?

Ce travail fait partie de LibrePower – Unlocking IBM Power Systems through open source. RAS inégalé. Coût total de possession supérieur. Empreinte minimale ?

Dépôt du projet LibrePower AIX : gitlab.com/librepower/aix

LLMs sur AIX : expérimentation technique au-delà de l’engouement pour les GPUs

12 janvier 2026/dans Informations/par Hugo

À LibrePower, nous avons publié Llama-AIX: une preuve de concept pour exécuter l’inférence de modèle LLM léger directement sur AIX 7.x, en utilisant seulement le CPU et la mémoire, sans GPU.

? GitLab

Il faut être clair dès le départ : il s’agit d’amusement technique et d’expérimentation, pas d’un produit, pas d’une promesse commerciale, pas d’une alternative aux grandes plateformes d’IA accélérées par le GPU.

Cela dit, l’expérience repose sur une base technique solide.

La théorie : tous les cas d’utilisation du LLM ne sont pas liés au GPU.

Dans de nombreux scénarios professionnels courants dans les environnements Power :

RAG (Retrieval Augmented Generation)
Questions sur la documentation interne
Assistants techniques sur place
Recherche sémantique sur ses propres connaissances
Analyse de texte fortement dépendante de la latence et de la proximité des données.

Le goulot d’étranglement n’est pas toujours le calcul de la masse, mais.. :

CPU
Largeur de la mémoire
Temps de latence de l’accès aux données
Localisation des données

Dans ces cas, les inférences petites et bien délimitées peuvent être raisonnablement exécutées sans GPU, surtout lorsque le modèle n’est pas le centre du système, mais juste une autre pièce du système.

⚙️ CPU, MMA et accélérateurs basse consommation

L’évolution naturelle ne concerne pas seulement les GPU :

Des processeurs de plus en plus vectorisés
Extensions en tant que MMA
Accélérateurs dédiés et économes en énergie (comme le futur Spyre).
Intégration plus étroite avec le système d’exploitation et la pile de données

Ce type d’accélération est particulièrement pertinent dans les architectures de puissance, où la conception donne la priorité au débit soutenu, à la cohérence et à la fiabilité, et pas seulement aux pics de FLOPS.

? Pourquoi AIX ?

L’exécuter sur AIX n’est pas une nécessité, c’est un choix conscient :

Comprendre les limites réelles
Explorer sa faisabilité technique
Démonter les hypothèses simplistes
Apprendre comment les LLM s’intègrent dans les systèmes d’alimentation existants

De nombreux clients Power exploitent des infrastructures stables, amorties et critiques, où le déplacement des données vers le cloud ou l’introduction de GPU n’est pas toujours souhaitable ou viable.

? Ce qui est (et ce qui n’est pas) Llama-AIX

✔ Un PoC technique
✔ Une exploration honnête
✔ Un exercice d’ingénierie
✔ Source ouverte
✖ Pas un benchmark
✖ Pas une plateforme d’IA complète
✖ Pas destinée à concurrencer les solutions GPU
✖ Pas de ” marketing de l’IA “.

L’idée est simple : voir au-delà du battage médiatique, comprendre les nuances et évaluer où les LLM apportent une réelle valeur dans les environnements Power et AIX.

Purement par curiosité technique.

Et parce que l’expérimentation reste un élément fondamental de l’ingénierie.

Dans quel cas d’utilisation spécifique un LLM in Power sur site aurait-il du sens pour toi ?

Lancement de LibrePower (et voici son Manifeste)

8 janvier 2026/dans Informations/par Hugo

Nous voulons libérer tout le potentiel d’IBM Power.

Nous construisons une communauté pour faire grandir l’écosystème Power – plus de solutions, plus d’utilisateurs, plus de valeur.

Le matériel le plus performant dont tu ne profites pas encore pleinement.

IBM Power est à la base de l’informatique critique dans le monde entier. Les transactions bancaires, les réservations de vols, les systèmes hospitaliers, les installations SAP – les charges de travail qui ne peuvent pas se permettre de tomber en panne fonctionnent sur Power.

Ce n’est pas une coïncidence.

Les systèmes d’alimentation offrent une fiabilité légendaire grâce à leur architecture RAS (fiabilité, disponibilité, facilité d’entretien) que x86 ne peut tout simplement pas égaler. Ils fonctionnent sans problème pendant 10, 15 ans ou plus. Leur conception – grandes caches, SMT8, bande passante mémoire extraordinaire – est conçue pour maintenir les performances à l’échelle de manière durable.

Mais il existe une opportunité que la plupart des organisations manquent :

Le pouvoir peut faire beaucoup plus que ce qu’on lui demande habituellement.

La capacité est là. Le potentiel est énorme. Ce qui a manqué, c’est une validation indépendante, un élan communautaire et des outils accessibles qui ouvrent la porte à de nouveaux cas d’utilisation.

Exactement ce que LibrePower est en train de construire.

Qu’est-ce que LibrePower ?

LibrePower est une initiative communautaire visant à étendre les possibilités d’IBM Power à l’ensemble de l’écosystème :

AIX – L’Unix vétéran qui gère les charges d’entreprise les plus exigeantes
IBM i – Le système intégré sur lequel fonctionnent des milliers d’entreprises dans le monde entier.
Linux on Power (ppc64le ) – Ubuntu, Rocky, RHEL, SUSE, Fedora sur l’architecture POWER

Nous ne sommes pas là pour remplacer quoi que ce soit. Nous sommes là pour ajouter:

Plus de solutions certifiées fonctionnant sur Power
Plus de développeurs et d’administrateurs qui s’appuient sur la plateforme.
Plus de raisons d’investir dans l’énergie – à la fois dans les nouveaux équipements et dans les équipements existants.

Ce que nous faisons

1. Certifié LibrePower – validation indépendante

Les éditeurs de logiciels indépendants et les projets open source ont besoin de savoir que leurs logiciels fonctionnent sur Power. Les acheteurs ont besoin d’être rassurés avant de déployer leurs produits. La certification IBM a sa valeur, mais il y a de la place pour une validation indépendante menée par la communauté.

La certification LibrePower offre trois niveaux :

Niveau	Signification
✅ Travaille sur le pouvoir	Compile et fonctionne correctement sur ppc64le. Validation de base.
⚡ Optimisé pour la puissance	Conçu pour SMT, VSX/MMA. Comprend des données sur les performances.
? Certifié LibrePower	Validation complète + étude de cas + soutien continu.

Gratuit pour les projets open source. Niveaux Premium pour les éditeurs de logiciels indépendants qui recherchent une collaboration plus approfondie.

2. les dépôts de logiciels libres

Nous compilons, emballons et distribuons les logiciels dont la communauté Power a besoin :

AIX(aix.librepower.org) : outils CLI modernes, utilitaires de sécurité, couches de compatibilité
ppc64le: outils de conteneurs (AWX, Podman), utilitaires de développement, surveillance
IBM i: intégration open source (en cours de développement)

Tout est gratuit. Tout est documenté. Tout est sur GitLab.

3. Test de performance et optimisation

Le matériel Power possède des caractéristiques uniques dont la plupart des logiciels ne profitent pas. Nous effectuons des analyses comparatives, identifions les opportunités et travaillons avec des projets en amont pour améliorer les performances sur Power.

Lorsque nous trouvons des optimisations, nous y contribuons en retour. Tout l’écosystème en bénéficie.

4. Construire une communauté

Le monde de Power est fragmenté. Les administrateurs AIX, les équipes Linux on Power, les environnements IBM i – tous résolvent des problèmes similaires de façon isolée.

LibrePower relie ces communautés :

Partage des connaissances entre plates-formes
Amplifier la voix collective auprès des fabricants et des projets.
Créer un réseau d’expertise dans le domaine de l’électricité

5. Élargir le marché

Chaque nouvelle solution validée sur Power est une raison de plus pour les organisations de choisir la plateforme. Chaque développeur qui apprend Power est un talent pour l’écosystème. Chaque histoire de réussite démontre la valeur de la plateforme.

Plus de solutions → plus d’adoption → un écosystème plus fort → plus d’investissements dans Power.

Ce cercle vertueux profite à tout le monde : IBM, partenaires, ISV et utilisateurs.

Pourquoi devrais-tu t’en préoccuper ?

Si tu administres des systèmes Power :

Accède aux outils et aux solutions qui te manquaient.
Rejoins une communauté qui comprend ton environnement
Maximise le retour sur ton investissement en matériel informatique.

Si tu es un développeur :

Apprends une plateforme avec des caractéristiques techniques uniques
Contribue à des projets ayant un impact réel sur le monde de l’entreprise.
Développe une expertise dans un créneau à forte valeur ajoutée.

Si tu es un éditeur de logiciels indépendants :

Fais valider ton logiciel dans Power
Connecte-toi avec les entreprises clientes
Découvre les opportunités de marché dans l’écosystème de l’électricité

Si tu es en train d’évaluer l’infrastructure :

Découvre ce qui est vraiment possible en matière d’alimentation, au-delà de la charge traditionnelle.
Trouver une validation indépendante des solutions
Connecte-toi avec la communauté pour découvrir de vraies expériences

Sur quoi nous travaillons

AIX(aix.librepower.org)

✅ Gestionnaire de paquets moderne (dnf/yum pour AIX).
✅ fzf – fuzzy browser (binaire Go compilé pour AIX)
✅ nano – éditeur moderne
Outils 2FA – Google Authenticator avec QR Codes
? Prochainement : ripgrep, yq, coreutils modernes.

Linux ppc64le

? AWX – automatisation Ansible (portage complet en cours).
? Outils de conteneurs – Podman, Buildah, Skopeo
? Outils de développement – lazygit, k9s, CLIs modernes.

IBM i

? Phase de planification – évaluer les priorités avec l’aide de la communauté.

La vision

Imagine :

Tous les grands projets open source considèrent que la puissance au moment de la publication est…
Les éditeurs de logiciels indépendants considèrent Power comme une plate-forme stratégique, et non comme une réflexion après coup.
Les organisations déploient de nouvelles charges utiles sur Power en toute confiance
Une communauté connectée et en pleine croissance qui alimente l’écosystème.

C’est la Renaissance du pouvoir.

Il ne s’agit pas de nostalgie du passé. Il ne s’agit pas seulement de prolonger la durée de vie des déploiements existants.

Expansion active de ce que Power peut faire et de qui l’utilise.

Rejoindre

LibrePower grandit avec la communauté. Voici comment tu peux t’impliquer :

? S’abonner aux dernières nouvelles – nouveautés, guides, actualités de la communauté
? Explore nos dépôts – utiliser, contribuer, demander
✅ Certifie ton logiciel – valide ton logiciel dans Power
? Deviens sponsor – soutiens l’initiative

Qui est à l’origine de ce projet ?

LibrePower est une initiative de SIXE, un partenaire commercial d’IBM et de Canonical avec plus de 20 ans d’expérience dans l’écosystème Power.

Nous avons vu ce que le pouvoir peut faire. Nous avons vu ce qui manque. Maintenant, nous construisons ce qui devrait exister.

LibrePower – Libérer le potentiel des systèmes électriques grâce aux logiciels libres ?. RAS inégalé. Coût total de possession supérieur. Empreinte au sol minimale. ?

Qu’est-ce qu’une usine IA et comment la construire avec l’open source dans votre datacenter

Qu’est-ce qu’une usine IA exactement ?

Pourquoi les organisations rapatrient leur inférence IA on-premise

Coûts prévisibles

Zéro vendor lock-in

Conformité réglementaire

Le stack open source : trois technologies, zéro dépendance propriétaire

Ceph : le stockage distribué conçu pour l’IA

OpenStack : votre cloud privé avec gestion native des GPU

Kubernetes + vLLM : la couche d’orchestration de l’inférence

Architecture de référence : de la donnée au modèle en production

Ceph S3

OpenStack

Kubernetes

vLLM / Triton

Qui a réellement besoin d’une usine IA on-premise

Santé et pharma

Banque et assurance

Secteur public et défense

Industrie et manufacture

Les questions à se poser avant de commencer

Quels modèles allez-vous servir et à quels volumes ?

Votre équipe a-t-elle la capacité d’opérer ce stack ?

Quel est le TCO réel sur 3 ans ?

Votre usine IA, avec le stack que nous utilisons nous-mêmes

10 erreurs d’architecture et de ROI que personne n’a évaluées dans l’exode post‑VMware

Confondre urgence et stratégie

Ignorer la gouvernance du projet open source

Ne pas lire le Contributor Licence Agreement

Supposer que les coûts d’abonnement resteront stables

Sous-estimer la complexité opérationnelle d’OpenStack

Croire que Ceph, c’est « juste cocher la case »

Ne pas inventorier les fonctionnalités entreprise qui disparaissent

Équilibrage automatique (DRS)

Tolérance aux pannes et DR

SDN et microsegmentation

Certifications éditeurs

Automatisation et API

Support 24/7

Calculer le ROI uniquement sur la ligne des licences

Concevoir pour le Jour 1 et oublier le Jour 2

Sécurité et conformité

Télémétrie et observabilité

Sauvegarde et restauration

Dette technique

Croire que la technologie est la décision

La meilleure migration est celle qui se fait avec discernement, pas dans la précipitation

Conformité NIS2 avec des logiciels libres.Sans licence, sans verrouillage.

NIS2 vous concerne-t-il ? Et quel cadre choisir en Belgique ?

Calculateur de catégorie NIS2

Quel outil couvre quelles mesures NIS2 ?

Installer les outils n'est pas être conforme à NIS2

Où en êtes-vous réellement ?

Linux est la base de votre stack NIS2. Maîtrisez-la.

L'essentiel, pour ceux qui manquent de temps

Questions fréquentes sur NIS2 et les logiciels libres

Réglementation et ressources citées

Nous déployons des stacks NIS2 open source en production

Le résultat

L’ingrédient secret : qu’est-ce que LFM2.5 ?

Le matériel : IBM Power System S924

Performance : trouver le point optimal

Test en conditions réelles : le défi de l’administrateur système

Round 1 : L’erreur cryptique (errpt)

Round 2 : L’audit de sécurité (last)

Round 3 : Le conseil dangereux (/etc/passwd)

Round 4 : Durcissement des services (lssrc -a)

Pourquoi c’est important pour les utilisateurs d’IBM Power

Essayez-le vous-même

Ce qu’apporte IBM et pourquoi c’est le plus grand lancement en six ans

Les trois modèles FlashSystem de 2026 : FlashSystem 5600, 7600 et 9600

FlashCore Module 5 : du QLC qui performe comme du TLC (et pourquoi c’est important)

FlashSystem.ai : l’IA agentique dans la baie, entre promesses et réalité

Détection de ransomware en 60 secondes : les données et les astérisques

L’argument qui n’apparaît pas dans les datasheets : la chaîne d’approvisionnement

Pure Storage, Dell, NetApp et les autres — et maintenant ?

Là où IBM prend clairement l’avantage :

Là où la concurrence résiste :

À qui s’adresse-t-il ?

Conclusions

Conformité NIS2 avec des logiciels libres.
Sans licence, sans verrouillage.

Chapitre 4 : La chose `-blibpath` (en fait une caractéristique)