IBM DataStage : qu’est-ce que c’est, comment ça marche et pourquoi c’est toujours la référence ETL en 2026

Intégration de données · Avril 2026

Qu'est-ce qu'IBM DataStage et pourquoi il reste la référence ETL en entreprise en 2026.

Pendant que le marché de l'intégration de données se fragmente entre outils cloud-native, notebooks et orchestrateurs à la mode, DataStage continue de déplacer les données qui comptent depuis trois décennies — banque, santé, télécoms et administrations publiques. Voici ce qu'il est, comment il fonctionne et quand il est pertinent en 2026.

Avril 20269 min de lecture

Si vous travaillez avec les données dans une grande organisation, vous avez probablement entendu parler de DataStage — même si vous ne savez pas exactement ce qu'il fait au-delà de « ce truc IBM pour déplacer des données ». C'est bien plus que ça.

IBM DataStage est l'outil ETL (Extract, Transform, Load) de la suite IBM InfoSphere. Il est en production depuis plus de 25 ans, a traversé plusieurs acquisitions et changements de marque, et en 2026 il reste l'une des pièces centrales de l'écosystème de données d'IBM — désormais disponible en tant que service au sein d'IBM Cloud Pak for Data.

Les fondamentaux

Qu'est-ce que DataStage et d'où vient-il

IBM DataStage est un outil d'intégration de données qui permet de concevoir, déployer et exécuter des pipelines qui extraient des informations de multiples sources, les transforment selon des règles métier et les chargent dans des systèmes cibles. Dans le monde de l'ingénierie de données, c'est ce qu'on appelle l'ETL — Extract, Transform, Load — et DataStage est l'une des implémentations les plus établies et robustes du marché.

L'histoire mérite d'être résumée car elle explique beaucoup de ce qu'est DataStage aujourd'hui. Né dans les années 90 comme produit d'Ardent Software, il a été acquis par Informix, elle-même rachetée par IBM en 2001. Depuis, il fait partie de la famille IBM InfoSphere — une suite d'outils pour l'intégration, la qualité et la gouvernance des données.

Ce qui distingue DataStage d'un script Python ou d'un flux Apache Airflow, ce n'est pas ce qu'il fait (déplacer des données de A à B), mais comment il le fait : avec une interface visuelle de conception de jobs, un moteur de traitement parallèle distribué, des connecteurs natifs pour pratiquement n'importe quelle base de données ou système, et un système de métadonnées intégré qui trace d'où vient chaque donnée et quelles transformations elle a subies.

En clair : DataStage, c'est ce qu'utilisent les organisations qui déplacent des millions d'enregistrements chaque nuit entre des dizaines de systèmes, et qui ont besoin que cela fonctionne toujours, soit auditable et ne nécessite pas une équipe de 15 personnes pour le maintenir.

L'architecture

Comment ça marche : le moteur de traitement parallèle

Le composant central de DataStage est son moteur parallèle (Parallel Framework). Contrairement aux outils ETL qui traitent les données de manière séquentielle — un enregistrement après l'autre — DataStage répartit le travail sur plusieurs partitions qui s'exécutent simultanément. C'est la même idée que MapReduce ou Spark, mais implémentée avant que ces technologies n'existent.

┌──────────────────────────────────────────────────────┐ Moteur Parallèle DataStage └───────┬──────────────┬────────────────┬───────────────┘ ┌────▼────┐ ┌─────▼──────┐ ┌──────▼──────┐ Extract │ │ Transform │ │ Load │ │ │ │ Db2 │ │ Règles │ │ DWH Oracle │ │ Nettoyage │ │ Data Lake SAP │ │ Enrichiss. │ │ Cloud APIs │ │ → parallèle│ │ → batch/TR CSV │ │ → N nœuds │ │ └─────────┘ └────────────┘ └─────────────┘

L'aspect ingénieux du moteur parallèle est que le développeur n'a pas à penser au parallélisme. On conçoit le job comme s'il était séquentiel — en glissant des stages dans le Designer — et le moteur décide comment partitionner les données, combien de nœuds utiliser et comment redistribuer la charge.

Les composants du stack

  • DataStage Designer. L'interface visuelle où l'on conçoit les jobs. On glisse des stages (sources, transformations, cibles), on les connecte par des liens, on définit les métadonnées de chaque colonne et on compile. Derrière, il génère du OSH (Orchestrate Shell), le langage exécuté par le moteur parallèle.
  • DataStage Director. La console de supervision. On y voit les jobs en cours, les échecs, les logs, les statistiques de performance, et on peut relancer ou annuler des exécutions.
  • Information Server. La couche enveloppante : sécurité, métadonnées partagées avec les autres outils InfoSphere (QualityStage, Information Analyzer, IGC), API REST pour l'automatisation, et le référentiel central des définitions de jobs.
  • Connecteurs. DataStage dispose de connecteurs natifs pour un catalogue impressionnant : Db2, Oracle, SQL Server, PostgreSQL, MySQL, SAP, Teradata, Snowflake, Amazon Redshift, S3, Azure Blob, Kafka, fichiers plats, XML, JSON, APIs REST — et bien d'autres. Ce ne sont pas des wrappers ODBC génériques — ce sont des connecteurs optimisés pour chaque moteur, avec support du bulk load, du pushdown optimization et du contrôle fin des sessions.
Cas d'usage

À quoi sert DataStage en pratique

La vraie question n'est pas « à quoi peut-il servir » (déplacer n'importe quelle donnée entre n'importe quels systèmes) mais « dans quels cas est-il pertinent face à des alternatives plus modernes ou moins chères ». Car DataStage n'est pas l'outil le plus simple du marché, et son coût de licence n'est pas anodin.

Alimentation d'entrepôts de données

C'est le cas classique et il reste le plus courant. Les organisations qui disposent d'un DWH — qu'il s'agisse d'IBM Db2 Warehouse, de Teradata, Snowflake ou Redshift — et qui doivent charger des données propres, transformées et enrichies chaque nuit (ou chaque heure) depuis des dizaines de systèmes sources.

Migration de données

Quand une organisation change d'ERP, de core bancaire ou de système hospitalier, il y a un projet de migration de données qui peut durer des mois. DataStage sert à mapper les anciens schémas vers les nouveaux, appliquer les règles de conversion, valider l'intégrité référentielle et exécuter des chargements massifs avec possibilité de rollback.

Intégration en temps réel avec CDC

Avec IBM CDC (Change Data Capture) intégré, DataStage peut répliquer les changements en base de données avec des latences de l'ordre de la milliseconde. Cela s'utilise dans les environnements où les données opérationnelles doivent être synchronisées entre systèmes en quasi-temps réel.

Qualité et gouvernance des données

DataStage s'intègre nativement avec le reste de la suite InfoSphere : QualityStage pour le nettoyage, Information Analyzer pour le profiling, et IBM Knowledge Catalog pour la gouvernance et le lignage. Les projets de gouvernance qui nécessitent une traçabilité de bout en bout ont tout sous le même toit.

Où DataStage est le plus pertinent

Banque, assurance, télécoms, santé, administrations publiques et utilities. Des secteurs avec des volumes massifs, une réglementation stricte (NIS2, PCI DSS, RGPD, DORA), et des environnements IBM Power où DataStage tourne nativement. Si votre infrastructure est déjà IBM — Power11, AIX, Db2 — DataStage s'intègre naturellement.

L'évolution

DataStage dans Cloud Pak for Data : l'évolution 2025-2026

L'histoire récente de DataStage a un protagoniste clair : IBM Cloud Pak for Data. C'est la plateforme de données unifiée d'IBM, construite sur Red Hat OpenShift, qui regroupe tous les services de données sous une interface commune.

Le changement le plus significatif est intervenu en juin 2025, avec la version 5.2 de Cloud Pak for Data : DataStage est disponible sur OpenShift sur IBM Power (ppc64le). Cela signifie que les organisations équipées de serveurs Power peuvent désormais containeriser DataStage et le gérer avec la même orchestration que le reste de leurs workloads cloud-native.

La version actuelle — Cloud Pak for Data 5.3 — apporte DataStage avec un support complet ETL et ELT, l'exécution à distance et le nouveau DataStage Flow Designer intégré à l'interface web.

Note sur la sécurité. En février et mars 2026, IBM a publié plusieurs correctifs de sécurité pour DataStage on Cloud Pak for Data 5.1.2 à 5.3.0, incluant des vulnérabilités d'injection de commandes et de fuite d'informations sensibles. Si vous utilisez DataStage sur Cloud Pak for Data, assurez-vous d'être en version 5.3.1 ou ultérieure.
Le paysage concurrentiel

DataStage face aux alternatives en 2026

Il serait malhonnête de parler de DataStage sans reconnaître que le marché de l'intégration de données en 2026 est très différent de celui de 2015. Il existe des alternatives sérieuses, et la décision dépend fortement du contexte.

OutilModèleFort enFaible en
IBM DataStageLicence IBMTraitement parallèle, environnements IBM, réglementationCoût, courbe d'apprentissage, écosystème fermé
Informatica IDMCSaaS / on-premPart de marché, catalogue de connecteursPrix encore plus élevé que DataStage
Apache Spark / dbtOpen sourceCloud-native, flexibilité, communautéPas un ETL clé en main, nécessite de l'ingénierie
Talend (Qlik)CommercialFacilité d'utilisation, cœur open sourceRacheté par Qlik en 2023, feuille de route incertaine
Azure Data FactorySaaS AzureIntégration native AzureDépendance cloud, limité hors Azure
AWS GlueSaaS AWSServerless, coût faible en petits volumesDépendance cloud, limité hors AWS

Quand DataStage a-t-il du sens ? Quand vous avez déjà investi dans l'écosystème IBM (Power, Db2, InfoSphere), quand vous avez besoin de traitement parallèle on-premise à des volumes que d'autres ne gèrent pas bien, quand la réglementation exige une traçabilité complète des métadonnées, ou quand votre équipe connaît déjà DataStage et que le coût de reconversion dépasse celui de la licence.

Quand ne l'est-il pas ? Quand votre stack est purement cloud-native (AWS/Azure/GCP sans IBM), les volumes sont faibles, vous préférez le code à l'interface visuelle, ou le budget ne permet pas la licence IBM et vous préférez investir en ingénierie avec des outils open source.

Se former

Formation officielle IBM DataStage en Europe

Si DataStage fait partie de votre stack actuel ou va le devenir, se former correctement fait la différence entre une équipe qui conçoit des jobs efficaces et une qui produit des pipelines qui mettent des heures à s'exécuter et que personne ne sait débugger.

SIXE est IBM Authorized Training Partner et propose les cours DataStage suivants, dispensés par des instructeurs accrédités IBM :

Les deux cours incluent les supports officiels IBM et des travaux pratiques. Disponibles en présentiel en Europe, à distance, ou en intra-entreprise adapté à votre équipe. Dispensés en français, espagnol et anglais.

Formation sur mesure

Si vous avez besoin d'un cours adapté — par exemple, centré sur la migration de jobs classiques vers Cloud Pak for Data, ou sur l'optimisation des performances dans un environnement spécifique — nous le concevons à partir des supports officiels, complétés par du contenu issu de nos propres déploiements. Consultez le catalogue complet de formation officielle IBM ou contactez-nous directement par WhatsApp.

Pour aller plus loin


Vous travaillez avec IBM DataStage ?

Formation officielle. En Europe. Par des gens qui le déploient.

Que vous débutiez avec DataStage ou que vous souhaitiez faire monter votre équipe en compétences, les cours officiels IBM dispensés par SIXE couvrent des fondamentaux à l'administration avancée du moteur parallèle.

OpenStack Gazpacho | Alternative VMware open source

Cloud privé · Avril 2026

OpenStack Gazpacho : l'alternative VMware open source qui passe enfin en production.

OpenStack 2026.1 Gazpacho est sorti le 1er avril. Plus de 9 000 modifications, 500 contributeurs, migrations en direct parallèles, automatisation intelligente du bare metal avec Ironic et la suppression progressive d'Eventlet. C'est la version SLURP de l'année — et la plus pertinente pour les entreprises qui réévaluent leur stack de virtualisation.

Avril 202614 min de lecture
Logo OpenStack 2026.1 Gazpacho — la 33e version du logiciel d'infrastructure cloud open source le plus déployé au monde, principale alternative VMware pour le cloud privé

OpenStack vient de publier sa 33e version. Il y a quelques années, la nouvelle serait passée inaperçue en dehors du cercle habituel des opérateurs de cloud privé. Mais 2026 n'est pas une année ordinaire pour l'infrastructure. Broadcom remodèle le paysage VMware depuis plus d'un an. Les entreprises européennes mesurent le coût réel de la dépendance technologique. Et le cloud privé open source est passé d'une posture idéologique à un choix économique.

Gazpacho arrive exactement au moment où plus d'organisations que jamais cherchent activement une alternative sérieuse à vSphere. Et cette version, pour la première fois depuis longtemps, apporte des réponses concrètes aux questions que se posent ces organisations.

Pour comprendre ce qui change vraiment, il faut commencer par quelque chose de peu glamour mais fondamental : savoir si vous pouvez mettre à jour sans perturber la production.

Le modèle de versions

Le modèle SLURP et pourquoi Gazpacho est la version qui compte

OpenStack publie deux versions par an. Depuis 2022, les versions alternées sont marquées SLURP (Skip Level Upgrade Release Process) : elles permettent aux opérateurs de mettre à jour une fois par an, en sautant directement d'un SLURP au suivant sans toucher la version intermédiaire.

Voici l'état des versions à la date de cet article :

VersionDateStatut
2026.1 Gazpacho1er avril 2026Version actuelle. SLURP. Recommandée pour les nouveaux déploiements et les mises à jour.
2025.2 Flamingo1er octobre 2025Supportée. Non-SLURP (intermédiaire).
2025.1 EpoxyAvril 2025SLURP précédent. Mise à jour directe vers Gazpacho possible.
2026.2 HibiscusSeptembre 2026 (prévue)Prochaine version. Non-SLURP.

Le calendrier officiel du cycle Gazpacho détaille tous les jalons, les dates de gel des fonctionnalités et les équipes responsables. La page officielle de la version regroupe les points forts sélectionnés par la communauté.

La conséquence concrète : si votre environnement tourne sous Epoxy (2025.1), vous pouvez passer directement à Gazpacho sans toucher Flamingo. Cela divise par deux vos mises à jour obligatoires et simplifie la planification des fenêtres de maintenance en production.

Et si vous êtes sous Flamingo, c'est une mise à jour standard en une seule étape.

Contexte

Gazpacho est la 33e version d'OpenStack. Environ 500 contributeurs de 100 organisations — Ericsson, Rackspace, Red Hat, Samsung SDS, SAP, NVIDIA, Walmart, entre autres — ont apporté plus de 9 000 modifications en six mois. Le système CI/CD (OpenDev Zuul) a traité plus d'un million de jobs pour valider cette version. Et un chiffre clé pour l'Europe : 40 % des contributions proviennent de développeurs européens, portés par les initiatives de souveraineté numérique du continent. Les détails complets sont dans le blog officiel de l'OpenInfra Foundation.

Le calendrier des versions est clair. Voyons maintenant ce qui justifie réellement une mise à jour — au-delà de la simple fermeture d'une fenêtre de support.

La nouveauté phare

Migrations en direct parallèles dans Nova : le changement de donne

Si nous devions choisir une seule nouveauté de Gazpacho pour expliquer pourquoi cette version compte pour les entreprises, ce serait celle-ci : Nova prend désormais en charge les migrations en direct parallèles.

Jusqu'ici, la migration en direct des instances traitait les transferts mémoire de façon séquentielle : une connexion après l'autre. Gazpacho introduit plusieurs connexions simultanées, ce qui accélère significativement le transfert des workloads lourds entre hôtes ou zones de disponibilité.

Pourquoi est-ce si important ? Parce que la vitesse de migration détermine en pratique la durée d'une fenêtre de maintenance. Pour une organisation gérant des centaines de VMs — ou qui évalue une sortie de VMware — la différence entre migration série et migration parallèle, c'est la différence entre une nuit de maintenance et un week-end entier.

Migration en direct — fenêtre de maintenance ↕ survolez pour le détail
t=0 t=T t=2T t=3T t=4T

Et ce n'est pas tout ce qui change dans Nova

Les migrations parallèles sont la nouveauté la plus visible, mais Nova apporte trois autres changements qui reposent sur le même principe : moins de friction opérationnelle.

Migration en direct avec vTPM

Une autre nouveauté qui s'articule avec les migrations parallèles : Nova permet désormais de migrer des instances utilisant le vTPM (module de plateforme sécurisée virtuelle) sans les arrêter. Les workloads avec chiffrement de disque ou démarrage sécurisé — courants dans les environnements réglementés — peuvent désormais être déplacés entre nœuds sans interruption de service. Auparavant, migrer une VM avec vTPM nécessitait un cycle complet arrêt-déplacement-redémarrage. C'est terminé.

IOThread par défaut par instance QEMU

Un changement plus subtil mais avec un impact réel : Nova active par défaut un IOThread par instance QEMU, déchargeant le traitement des E/S disque des vCPU. Dans les environnements haute densité — nombreuses VMs par hôte — cela se traduit par des performances de stockage plus constantes sous charge, sans toucher à la configuration.

Couverture OpenAPI complète dans Nova

Nova atteint une couverture totale de son schéma OpenAPI : chaque endpoint de l'API dispose désormais d'une spécification lisible par machine. Pour les équipes qui automatisent avec Terraform, Ansible ou des outils maison, cela permet de valider les requêtes avant de les envoyer et de réduire les erreurs dans les déploiements d'infrastructure en tant que code.

Nova gère les VMs. Mais les VMs doivent bien vivre quelque part. Et si ce quelque part est du matériel physique qui n'est pas encore passé par OpenStack — ce qui est exactement la situation lors de la plupart des migrations depuis VMware — Ironic entre en jeu.

Bare metal intelligent

Ironic : automatisation intelligente qui réduit le travail manuel

Ironic est le service OpenStack pour provisionner des serveurs physiques — bare metal — comme s'il s'agissait de machines virtuelles. Dans Gazpacho, Ironic reçoit un ensemble d'améliorations qui représentent collectivement un vrai saut dans les opérations quotidiennes :

  • Détection automatique de l'interface de déploiement. Ironic détermine automatiquement la bonne méthode de déploiement pour chaque serveur, éliminant la sélection manuelle. Cela peut sembler banal, mais dans un datacenter avec du matériel hétérogène (générations et fabricants différents), c'est des heures de configuration économisées par nœud.
  • Détection automatique du protocole (NFS/CIFS) pour Redfish. La configuration du boot par virtual media est simplifiée : Ironic détermine le protocole correct sans intervention de l'opérateur.
  • Planification des ports par traits. L'attribution du réseau est automatisée en fonction des attributs réels de l'infrastructure — type de NIC, vitesse, capacités — au lieu de dépendre de mappages manuels.
  • Interface de déploiement noop. Probablement la plus intéressante pour les projets de migration : elle permet d'enregistrer et de surveiller des serveurs déjà déployés et en production, sans nécessité de les reprovisionner. Le cas d'usage typique : intégrer du matériel existant dans l'inventaire OpenStack lors d'une migration graduelle depuis VMware.
En pratique

L'interface noop est particulièrement utile dans les projets de migration VMware vers OpenStack que nous menons chez SIXE. Elle permet d'enregistrer les hôtes ESXi existants dans OpenStack, de les surveiller, et de planifier la migration des workloads sans avoir à réinstaller l'OS hôte avant le moment venu. C'est la différence entre "tout migrer en un week-end" et "migrer par phases, avec le contrôle".

Guide des drivers Cyborg

Cyborg, le service d'accélérateurs d'OpenStack, publie pour la première fois un guide unifié de configuration des drivers couvrant tous les types supportés : FPGA, GPU, NIC, QAT, SSD et PCI passthrough. Pour les organisations qui intègrent des accélérateurs IA ou des workloads HPC dans leur cloud privé, disposer d'une documentation testée et unifiée réduit significativement la barrière à l'entrée.

Les VMs sont migrées avec Nova et le matériel existant est intégré avec Ironic. Place maintenant à la partie qui finit toujours par être plus complexe que prévu : le réseau.

Réseau, stockage, sécurité

Ce qui change en profondeur : OVN, Manila, OpenBao

Réseau : BGP natif et améliorations OVN dans Neutron

Le contrôleur OVN de Neutron intègre des fonctionnalités très demandées en environnement enterprise :

  • Support BGP natif pour annoncer les routes directement depuis le contrôleur réseau, sans outillage externe.
  • Routage Nord-Sud pour les ports externes, simplifiant la connectivité avec les réseaux physiques.
  • Paires d'adresses autorisées avec MACs virtuels, permettant les scénarios multi-tenant et les architectures hybrides.

Historiquement, ce sont des scénarios où OpenStack nécessitait des contournements ou des outils tiers. Gazpacho les résout nativement.

Stockage : QoS dans Manila et attachements asynchrones

Manila introduit des types et spécifications QoS qui permettent d'appliquer des politiques de performance par workload au stockage partagé. Si vous avez un pool de stockage pour les bases de données et un autre pour les fichiers froids, vous pouvez désormais définir des limites et des priorités au niveau de la plateforme, pas seulement au niveau matériel. Cinder progresse sur les attachements de volumes asynchrones, améliorant la réactivité en environnement haute densité.

Sécurité : PKI avec OpenBao

L'intégration avec OpenBao — fork open source de HashiCorp Vault — pour la gestion des certificats PKI dans OpenStack-Ansible permet d'aligner l'infrastructure de certificats d'OpenStack avec les outils de sécurité enterprise existants. Particulièrement pertinent dans les environnements réglementés où la gestion du cycle de vie des certificats est auditée.

Watcher : stratégies de migration inter-zones

Watcher, le service d'optimisation des ressources, améliore ses stratégies de redistribution des workloads entre zones avec des tests renforcés. Pour les opérateurs gérant des clouds multi-sites ou avec des zones de disponibilité différenciées, cela améliore la fiabilité des redistributions automatiques lors des maintenances ou des pannes.

Tout ce qui précède — migrations, automatisation, réseau — ce sont des fonctionnalités visibles que vous pouvez justifier dans une conversation budgétaire. Mais Gazpacho effectue aussi un travail silencieux, plus important à long terme que n'importe quelle nouvelle fonctionnalité : faire le ménage.

Dette technique

Eventlet : le début de la fin d'une dépendance héritée

L'une des histoires de fond les plus importantes d'OpenStack ces trois dernières années, c'est la suppression progressive d'Eventlet, une bibliothèque de concurrence coopérative adoptée aux débuts du projet, quand Python 2 n'avait pas d'alternative native. Python 3 en a une : asyncio. Mais migrer un projet de la taille d'OpenStack d'un modèle de concurrence à un autre est un travail monumental.

Dans Flamingo (2025.2), quatre services ont terminé la migration : Ironic, Mistral, Barbican et Heat. Dans Gazpacho, Nova progresse significativement vers le threading natif, avec des améliorations de performance et de stabilité mesurables. Neutron avance aussi. Et neuf autres projets sont en migration active.

Pourquoi une organisation qui ne contribue pas au code d'OpenStack devrait-elle s'en préoccuper ? Parce qu'Eventlet est une source connue de bugs subtils, de difficultés de débogage et d'incompatibilités avec les bibliothèques Python modernes. Sa suppression rend OpenStack plus stable, plus maintenable et plus prévisible en production sur le long terme. C'est le type d'amélioration invisible qui n'apparaît pas dans les démonstrations mais qui fait la différence à 3h du matin quand quelque chose tombe en panne.

Progression de la migration Eventlet
● Terminé ◐ En cours ○ En attente
0
Terminés
0
En cours
0
En attente
0%
Complété
Progression globale du projet Objectif : asyncio natif sur tous les services
Le contexte du marché

Gazpacho comme alternative VMware : pourquoi le moment compte

On revient au point de départ de cet article. Nous avons dit que 2026 n'est pas une année ordinaire pour l'infrastructure — que Broadcom a forcé les organisations à repenser leur stack de virtualisation. La question que ces organisations se posent n'est plus « OpenStack est-il techniquement capable ? ». Cela a été tranché depuis longtemps. La question est : « a-t-il des réponses à mes problèmes concrets ? ». Avec Gazpacho, cette réponse s'est considérablement améliorée.

Depuis que Broadcom a restructuré le modèle de licences VMware — hausses de prix significatives, fin des licences perpétuelles, passage aux bundles — les préoccupations que nous entendons le plus souvent sont toujours les mêmes. Gazpacho apporte une réponse directe à chacune, et chaque réponse renvoie directement à ce que nous venons de voir :

Préoccupation fréquenteLa réponse de Gazpacho
Vitesse de migrationMigrations en direct parallèles qui rivalisent avec vMotion. vTPM sans interruption.
Matériel existantIronic noop permet d'enregistrer les hôtes sans reprovisionnement. Migration graduelle.
Réseau complexeBGP natif dans OVN, routage N-S, MACs virtuels. Sans outils tiers.
Accélérateurs (GPU, FPGA)Guide unifié des drivers Cyborg. PCI passthrough amélioré.
Mises à jour prévisiblesModèle SLURP : une mise à jour majeure par an, chemin de migration testé.
Souveraineté / vendor lock-inProjet ouvert, 100 organisations contributrices, 40 % européen.

À cela s'ajoute qu'OpenStack dépasse les 55 millions de cœurs en production dans le monde. Ce n'est pas un projet de niche ni une promesse future : c'est de l'infrastructure qui tourne en production chez Walmart, le CERN, NTT, Deutsche Telekom, et des milliers d'organisations plus petites qui ne publient pas leurs chiffres. Le projet fonctionne depuis 15 ans et la base de contributeurs croît, elle ne rétrécit pas. La version précédente, Flamingo (2025.2), avait déjà réalisé des avancées importantes en matière de sécurité et de suppression d'Eventlet.

L'angle européen

40 % des contributions à Gazpacho proviennent de développeurs européens. Ce n'est pas un hasard : les initiatives de souveraineté numérique de l'UE poussent l'adoption d'infrastructures ouvertes dans les administrations publiques et les entreprises réglementées. Pour les organisations qui doivent démontrer leur indépendance technologique dans leurs appels d'offres ou leurs audits, OpenStack est l'une des rares options qui combine maturité technique et gouvernance véritablement ouverte.

Prochaines étapes

Comment intégrer tout cela dans votre infrastructure

Modèle de versions, migrations en direct parallèles, bare metal intelligent, réseau sans contournements, dette technique en voie de résorption, contexte de marché favorable. Tout converge vers la même question pratique : que faites-vous maintenant ? La réponse dépend de là où vous en êtes.

Il y a trois situations courantes, et le bon diagnostic diffère pour chacune :

  • Vous avez OpenStack en production et devez planifier la mise à jour vers Gazpacho. Si vous êtes sous Epoxy, la mise à jour directe SLURP vers SLURP est votre chemin. Si vous êtes sous Flamingo, c'est une étape standard. Dans les deux cas, la recommandation est de valider dans un environnement de test, surtout si vous utilisez des fonctionnalités qui ont changé entre les versions (migrations, OVN, Ironic).
  • Vous avez VMware et le coût de renouvellement vous pousse à explorer des alternatives. La question ici est d'architecture : quels workloads migrer en premier, quelle architecture OpenStack convient (sur quel matériel, avec quel stockage — Ceph est le choix naturel), et comment migrer les données sans interrompre le service.
  • Vous démarrez un nouveau projet — cloud privé, plateforme de données, infrastructure IA — et OpenStack est sur la table. Gazpacho est la bonne version pour commencer, avec Ceph pour le stockage et, si vous avez besoin de conteneurs, Kubernetes intégré via Magnum.

Dans les trois cas, l'ordre sensé est le même : une courte conversation technique pour comprendre la situation, une proposition d'architecture avec des options et des compromis clairs, et un laboratoire de validation avant de toucher à la production. Ce que Gazpacho change, ce n'est pas le processus — c'est qu'il y a désormais plus de briques matures avec lesquelles travailler.

Pour aller plus loin


Vous évaluez OpenStack ou planifiez une mise à jour ?

Parlons de votre infrastructure.

Dites-nous où vous en êtes — mise à jour en attente, sortie de VMware, nouveau projet — et nous ressortirons de l'appel avec une vision claire de l'architecture, de l'effort et des prochaines étapes. Sans devis génériques. Directement avec des ingénieurs qui ont les mains dans des projets comme le vôtre depuis des années.

Wazuh : le SIEM open source qui répond à NIS2 sans le prix de Splunk

SIEM & XDR · Avril 2026

Wazuh : le SIEM open source qui répond à NIS2 sans le prix de Splunk.

En deux ans, Cisco a racheté Splunk pour 28 milliards de dollars et Palo Alto Networks a racheté les actifs SaaS de QRadar. Pendant ce temps, Wazuh est resté indépendant, a dépassé les 10 millions de téléchargements annuels et a lancé en juin 2025 une fonctionnalité de threat hunting basée sur un LLM exécuté en local. Voici pourquoi cela change la conversation SIEM en 2026.

Avril 202612 min de lecture

Voici une conversation que nous avons plusieurs fois par mois chez SIXE depuis fin 2024. Un directeur des systèmes ou un RSSI nous appelle, en général avec un peu de fatigue dans la voix, et dit une variante de la même chose : « notre contrat Splunk arrive à échéance et le budget de l'année prochaine ne suivra pas », ou bien « nous sommes sur QRadar SaaS et IBM nous a annoncé qu'il faut migrer vers Cortex XSIAM, mais nous ne sommes pas sûrs que ce soit ce que nous voulons ». Et de plus en plus souvent, depuis que la transposition de NIS2 est devenue une obligation concrète : « nous devons démontrer une supervision de sécurité réelle d'ici la fin de l'année et nous n'avons aucune solution en place ».

Ce n'est pas une coïncidence. Le marché du SIEM commercial a plus changé en 24 mois que durant la décennie précédente. Et au milieu de tout ce mouvement, il y a une brique qui est restée exactement où elle était. Elle n'est cotée à aucune bourse, personne ne l'a rachetée, et entre-temps elle n'a cessé de croître. Elle s'appelle Wazuh.

Le contexte 2024-2026

La carte du SIEM qui a changé en 24 mois

Si vous travaillez en sécurité défensive depuis quelques années, vous savez que le marché du SIEM commercial a toujours été conservateur. Les grands acteurs bougeaient peu. Les clients supportaient des contrats douloureux parce que migrer un SIEM est un projet sérieux, et personne ne le fait par plaisir. Et puis, entre le printemps 2024 et l'été 2025, trois choses se sont produites qui ont brisé cet équilibre.

Mars 2024 — Cisco rachète Splunk pour 28 milliards de dollars

L'opération la plus chère de l'histoire du SIEM. Cisco a payé 157 dollars par action, bien au-dessus du cours de Splunk plus tôt dans l'année. Avant la clôture de l'opération, Splunk a licencié 7 % de ses effectifs — environ 560 personnes — dans une restructuration mondiale. Les enquêtes d'analystes juste avant le rachat indiquaient déjà que 22 % des clients envisageaient de changer de fournisseur en cas de hausse de prix après l'acquisition. Ceux d'entre nous qui ont vu ce type d'opération se dérouler savent ce qui suit en général : pression interne pour rentabiliser un prix d'achat élevé, changements de roadmap, et renouvellements de contrat de plus en plus tendus.

Mai-septembre 2024 — Palo Alto Networks rachète les actifs SaaS de QRadar

Celle-ci, personne ne l'avait vue venir. En mai 2024, IBM et Palo Alto Networks ont annoncé que Palo Alto rachetait les actifs SaaS de QRadar pour environ 500 millions de dollars, avec une clôture confirmée en septembre. Forrester l'a résumé en une phrase que les clients sont encore en train de digérer : à l'expiration des contrats, les clients QRadar SaaS doivent migrer vers Cortex XSIAM ou partir vers un autre fournisseur. Ce n'est pas une opinion, c'est le plan officiel de transition.

IBM continue de maintenir QRadar on-premise — correctifs, mises à jour critiques, nouveaux connecteurs — donc les clients qui ont leurs propres installations ne sont pas abandonnés du jour au lendemain. Mais le message de fond que les comités de sécurité lisent est clair : l'investissement lourd ne va plus vers QRadar, il va vers XSIAM et Precision AI. Beaucoup utilisent ce signal pour repenser leur stratégie SOC à moyen terme.

Pendant ce temps — Wazuh dépasse les 10 millions de téléchargements annuels

Cela n'a pas fait la une des journaux, parce que Wazuh n'a pas une machine de communication comparable à celle de Cisco ou Palo Alto. Mais les chiffres sont là. Selon les données que le projet publie lui-même, Wazuh dépasse les 10 millions de téléchargements annuels, possède l'une des plus grandes communautés de sécurité open source au monde, et a déployé en juin 2025 une fonctionnalité qu'aucun de ses concurrents commerciaux ne propose encore sans licence supplémentaire : le threat hunting assisté par un grand modèle de langage exécuté en local. Nous y revenons plus loin.

Une note importante sur QRadar. Chez SIXE, nous continuons à fournir le support et la formation officielle IBM QRadar, et nous allons continuer tant qu'il y aura des clients avec des déploiements actifs. QRadar on-prem reste un outil solide pour les équipes qui l'ont déjà en production et veulent en tirer le meilleur. Mais si vous lancez un nouveau projet SIEM en 2026, ou si vous avez QRadar SaaS et que le contrat arrive à échéance, la conversation qui a du sens aujourd'hui est différente. Et elle passe par Wazuh bien plus souvent qu'il y a deux ans.
Le produit

Qu'est-ce que Wazuh (au-delà du « c'est gratuit »)

Si Wazuh n'était qu'un collecteur de logs bon marché, cette conversation serait différente. Ce n'est pas le cas. Wazuh est une plateforme qui unifie, dans un même agent et une même pile logicielle, un ensemble de fonctions que le reste du marché vend dans des boîtes séparées : SIEM, XDR, détection sur endpoint, intégrité des fichiers, scan de vulnérabilités CVE, audit de configuration contre CIS, conformité réglementaire et réponse active. Le tout avec le même agent qui tourne sur Linux, Windows, macOS, conteneurs Docker ou machines virtuelles.

Voici ce qui se passe concrètement quand un agent Wazuh est déployé sur l'un de vos serveurs :

  • Collecte et corrèle les logs en temps réel. Syslog, auditd, Windows Event Log, applicatif — tout cela avec des decoders natifs. L'agent envoie les données chiffrées au manager central, qui évalue les règles, corrèle entre hôtes et déclenche des alertes le cas échéant.
  • Surveille l'intégrité des fichiers et de la configuration. Toute modification dans /etc, dans le registre Windows, dans les binaires système ou dans les fichiers que vous marquez comme sensibles déclenche immédiatement une alerte. C'est de la détection de manipulation, et c'est l'une des fonctions qu'on payait à part jusqu'ici.
  • Scanne les vulnérabilités contre des bases CVE actualisées. Wazuh croise l'inventaire des paquets installés avec les flux officiels des éditeurs et les bases CVE publiques, et vous indique quelles machines doivent être patchées et avec quelle priorité. Sans payer Tenable ou Qualys en supplément.
  • Audite la configuration contre les CIS Benchmarks. Chaque agent exécute des évaluations périodiques de durcissement contre les politiques CIS ou vos politiques internes, et produit le rapport de conformité prêt à présenter à un auditeur.
  • Réagit activement. Blocage automatique d'IP, kill de processus suspects, isolation d'un hôte, exécution de scripts personnalisés. Sans que personne ne touche au clavier à trois heures du matin.
  • Cartographie tout sur MITRE ATT&CK. Chaque règle déclenchée est étiquetée avec la technique et la tactique ATT&CK correspondantes, ce qui rend les tableaux de bord pour l'analyste SOC bien plus utiles que les écrans génériques de la plupart des outils.
┌──────────────────────────────────────────────┐ Wazuh Manager (analysis engine · rules · response) └──────┬──────────────┬──────────────┬─────────┘ ┌────▼─────┐ ┌─────▼─────┐ ┌────▼──────┐ Agents │ │ Indexer │ │ Dashboard linux │ │ cluster │ │ windows │ │ OpenSearch│ │ MITRE macos │ │ │ │ compliance docker │ │ → shards │ │ SOC view k8s │ │ → HA │ │ └──────────┘ └───────────┘ └───────────┘

La pile est solide et éprouvée en production. Un article académique publié par Springer en avril 2026 évalue des architectures Wazuh distribuées en haute disponibilité, avec une gestion de pics d'ingestion bien au-dessus de la moyenne EPS, et conclut — avec les mots prudents habituels du monde académique — que les solutions SIEM open source bien conçues peuvent égaler, et sur certains aspects dépasser, les plateformes commerciales. Dit plus simplement : quand quelqu'un qui ne vend pas Wazuh évalue Wazuh avec méthode, les résultats tiennent la route.

La nouveauté de l'année

L'atout caché : threat hunting avec un LLM local

En juin 2025, presque sans bruit, Wazuh a intégré une capacité qui change la façon de travailler d'un analyste SOC : le threat hunting assisté par un grand modèle de langage exécuté en local. Pas dans le cloud d'OpenAI. En local. Dans votre propre infrastructure.

Pourquoi est-ce important ? Parce que tous les « SIEM avec IA » que le marché commercial a lancés — Cortex XSIAM avec Precision AI, Splunk et sa propre suite, les nouveautés de QRadar avant la vente — fonctionnent en envoyant vos logs vers les modèles de l'éditeur. Et dans beaucoup de cas, c'est précisément ce que le client n'a pas le droit de faire pour des raisons réglementaires. Si vos logs contiennent des données de patients, des informations de clients bancaires, ou des données classifiées d'une administration publique, les envoyer vers un LLM dans le cloud d'un fournisseur tiers n'est pas négociable — vous ne pouvez tout simplement pas.

L'approche de Wazuh contourne ce problème. Vous choisissez le modèle. Vous le déployez où vous voulez. Vos données ne sortent pas. Et les requêtes ressemblent exactement à ce qu'un analyste formulerait en langage naturel : « montre-moi toutes les tentatives d'élévation de privilèges du dernier mois corrélées avec des comptes de service », « résume les événements de cet hôte sur les 24 dernières heures et priorise ce qui est anormal », « est-ce qu'il y a quelque chose dans ces logs qui ressemble à la TTP T1078 de MITRE ? ».

Notre point de vue chez SIXE

C'est exactement la ligne sur laquelle nous travaillons depuis quelque temps du côté infrastructure — des LLM qui tournent on-premise, sans rien envoyer dans aucun cloud, pour des environnements qui manipulent des données sensibles. Nous l'avons appliqué sur IBM Power, sur AIX, et sur des clusters Ceph et Kubernetes pour de l'inférence privée. Quand nous avons vu Wazuh prendre la même direction côté SOC, c'est devenu l'une des raisons pour lesquelles nous misons encore plus fort sur la plateforme. Si le côté « infrastructure » de cette histoire vous intéresse, nous le détaillons sur notre page inférence d'IA souveraine on-premise.

Le comparatif

Wazuh face à Splunk, QRadar et XSIAM en 2026

Sans discours marketing, voici l'état actuel des quatre acteurs qui reviennent dans la majorité des conversations que nous avons. Les chiffres et les statuts sont vérifiables à la date de publication de cet article.

PlateformeÉtat en 2026Modèle commercial
WazuhIndépendant. Aucune acquisition, aucune levée de fonds, croissance des téléchargements et de la communauté.Open source AGPLv3. Aucun coût de licence. Wazuh Cloud en option.
SplunkPropriété de Cisco depuis mars 2024. Réduction des effectifs de 7 % avant clôture. Intégration en cours.Au volume de données ingérées (Go/jour). Coût élevé, pression sur les renouvellements.
QRadar SaaSVendu à Palo Alto Networks en 2024. Migration obligatoire vers Cortex XSIAM à l'expiration des contrats.Destination Cortex XSIAM. Migration gratuite pour les « clients éligibles ».
QRadar on-premMaintenu par IBM. Correctifs, connecteurs, sans grandes nouveautés fonctionnelles.Licence IBM par EPS. Support officiel actif.
Cortex XSIAMProduit stratégique de Palo Alto Networks. IA intégrée (Precision AI).Selon capacité et fonctionnalités. Positionné en haut de gamme tarifaire.
ELK / OpenSearch purGratuit, mais vous le construisez vous-même : règles, decoders, FIM, conformité.Pile gratuite. Le vrai coût est dans le temps d'ingénierie interne.

Ce qui est intéressant dans ce tableau ne se trouve dans aucune colonne — c'est dans ce qu'implique sa lecture complète. Quatre des six acteurs commerciaux sont en transition, en mode maintenance, ou en migration obligatoire. Wazuh et ELK sont les seuls qui se trouvent exactement là où ils étaient il y a trois ans, avec leurs communautés intactes et leurs feuilles de route publiques. Et de ces deux-là, un seul propose nativement SIEM, XDR, FIM, scan de vulnérabilités, réponse active et conformité : Wazuh.

Une note sur le coût. Quand nous comparons Wazuh à Splunk lors de sessions techniques avec des clients, la discussion ne tourne presque jamais autour du coût de la licence — qui, oui, est largement inférieur. Elle tourne le plus souvent autour de la prévisibilité. Splunk monte avec vous : plus vous ingérez de données, plus vous payez. Wazuh non. Et dans un environnement où les volumes de logs croissent de 30 à 40 % par an — parce que vous ajoutez de nouveaux services, parce que NIS2 vous oblige à conserver davantage, parce que vous déployez plus de conteneurs — cette différence se traduit en une facture que les DAF savent très bien lire.
L'angle réglementaire

NIS2, RGPD, ISO 27001 : la conformité sans souffrance

Il y a une raison très concrète à la croissance accélérée de Wazuh en Europe francophone, et c'est la pression réglementaire. La directive NIS2 a été transposée en droit français et belge au cours de 2024-2025, et son périmètre est large : opérateurs de services essentiels, opérateurs d'importance vitale, mais aussi des milliers d'« entités importantes » qui n'avaient jamais été soumises à ce type d'obligations auparavant. Pour beaucoup d'organisations de taille moyenne — hôpitaux, universités, collectivités territoriales, entreprises industrielles, services financiers — la question n'est plus de savoir si elles ont besoin d'un SIEM. C'est lequel elles peuvent se permettre sans que le comité de direction lève un sourcil.

Wazuh fournit nativement des tableaux de bord et des rapports cartographiés sur les principaux référentiels :

  • NIS2. Contrôles de détection, traçabilité des incidents, capacité de notification à l'autorité compétente (l'ANSSI en France, le CCB en Belgique) dans les délais imposés, preuves des mesures de gestion des risques pour les entités essentielles et importantes.
  • RGPD. Contrôles de logging des accès, traçabilité, détection et réponse à incident, preuves utiles pour l'horloge de notification d'une violation de données personnelles à la CNIL ou à l'APD.
  • ISO/IEC 27001. Preuves pour les contrôles de l'Annexe A liés à l'exploitation, aux communications, à la conformité et à la gestion des incidents de sécurité.
  • PCI DSS. Contrôles de logging, intégrité des fichiers, gestion des vulnérabilités, rétention — la check-list exigée par la norme, cartographiée exigence par exigence.
  • CIS Benchmarks. Audit continu du durcissement du système d'exploitation et des services, avec rapport historique des dérives.

Cela dit — et nous le disons avec affection parce que nous venons de ce monde — les tableaux de bord ne suffisent pas à passer un audit. Ce qui le permet, c'est que quelqu'un ait conçu correctement l'architecture, que les règles soient ajustées au contexte du client, que les exceptions soient documentées, et que le flux de preuves arrive de manière ordonnée à la personne qui doit le signer. Cette partie n'est pas faite par le produit, elle est faite par l'équipe qui le déploie. Et c'est, probablement, 70 % de la valeur d'un projet Wazuh bien mené.

Ce que nous faisons chez SIXE

Nous déployons Wazuh depuis des années dans des organisations soumises à NIS2, au RGPD, à PCI DSS et à des cadres sectoriels spécifiques, en France, en Belgique et au-delà. La page complète du service, avec l'architecture, le cycle de déploiement et les cas d'usage, est ici : Implémentation et support de Wazuh. Si la conformité NIS2 est ce qui vous met le plus de pression en ce moment, c'est par là qu'il faut commencer.

La migration

Migrer depuis Splunk, QRadar ou ELK sans aveugler le SOC

Migrer un SIEM est un projet qui fait peur, et à juste titre. Un SIEM mal migré laisse vos contrôles de détection aveugles précisément au pire moment. C'est pourquoi notre façon de procéder doit être ennuyeuse et prévisible, avec trois principes que nous ne négocions pas :

  1. Ne jamais éteindre l'ancien SIEM avant que le nouveau ne fonctionne. L'ancien continue d'absorber les logs et de générer ses alertes pendant que Wazuh commence à tourner en parallèle. Pendant quelques semaines, vous avez une couverture double et un risque nul. Cette période coûte cher en ressources, certes, mais bien moins qu'un mois de SOC aveugle.
  2. Convertir d'abord les règles critiques, pas tout le catalogue. Les grands SIEM ont souvent des milliers de règles accumulées, et une part importante sont des règles que personne ne regarde ou qui déclenchent des faux positifs. La première passe identifie les 50 à 150 règles critiques qui produisent réellement des détections utiles, les réécrit au format Wazuh et les valide avec des événements réels. Le reste suit plus tard — ou ne suit pas, parce que souvent cela n'en vaut pas la peine.
  3. Valider avec des événements qui font mal, pas avec des tests synthétiques. Avant de considérer Wazuh comme opérationnel, nous reproduisons un ensemble de scénarios réels — tentative d'élévation de privilèges, exfiltration, comportement précoce de rançongiciel, compromission de compte — et nous vérifions que les alertes se déclenchent, se corrèlent et arrivent au SOC avec le bon contexte. Si elles ne se déclenchent pas, le système n'est pas considéré comme opérationnel. C'est aussi simple que ça.

La partie qui change selon votre point de départ, c'est le travail de conversion :

  • Depuis Splunk. Le travail le plus intéressant. Le SPL (Search Processing Language) ne se traduit pas automatiquement vers les règles Wazuh, mais le motif de détection est en général reproductible avec des decoders custom et des règles sur OpenSearch. Nous avons mené plusieurs migrations de ce type et l'essentiel du travail se trouve dans les tableaux de bord et les règles, pas dans l'ingestion.
  • Depuis QRadar. La bonne nouvelle est que QRadar et Wazuh partagent une grande partie de la philosophie autour des événements et des offenses. La mauvaise est que les DSM de QRadar sont propriétaires et qu'il faut reconstruire les parsers. Si vous êtes sur QRadar SaaS avec la migration vers XSIAM qui s'approche, c'est une fenêtre raisonnable pour évaluer sérieusement la troisième option.
  • Depuis ELK pur. La plus simple des trois — Wazuh utilise déjà OpenSearch comme indexer, donc une bonne partie de la pile de données vous est familière. Le saut consiste à ajouter les règles, la conformité et la réponse active, qu'en ELK pur vous auriez dû construire à la main.
Prochaines étapes

Par où commencer

Si vous lisez ceci et que vous vous dites « cela me concerne plus que je ne le voudrais », vous avez probablement raison. Pas besoin d'un projet immense pour faire le premier pas. La meilleure façon de démarrer, c'est en général une conversation courte autour de trois questions :

  • Où vous trouvez-vous exactement aujourd'hui ? Sur Splunk avec un renouvellement qui approche ? Sur QRadar SaaS avec la migration vers XSIAM à l'horizon ? Rien encore, et NIS2 commence à vous mettre la pression ?
  • Quelle réglementation vous oblige réellement ? NIS2, RGPD, PCI DSS, ISO 27001 — couvrir une seule n'est pas la même chose que couvrir les quatre, et l'architecture de Wazuh se dimensionne différemment selon ce qui s'applique vraiment.
  • Combien d'endpoints, quels systèmes d'exploitation, quels logs avez-vous déjà, quelles intégrations vous faut-il ? Avec ces données, on peut déjà esquisser une conception concrète et une estimation d'effort réaliste.

Quand vous saurez ce que vous voulez regarder, la page complète avec l'architecture, les modules, le comparatif détaillé avec les alternatives commerciales et le cycle de déploiement est ici : Wazuh — Implémentation et support SIXE. Et si vous préférez parler à quelqu'un qui a passé des années les mains dans des projets comme le vôtre, la session technique de 30 minutes est gratuite et sans engagement. Vous repartez de l'appel avec une esquisse d'architecture, une estimation d'effort réaliste et les prochaines étapes. Si Wazuh est adapté, nous vous le dirons. Si ce n'est pas le cas, nous vous le dirons aussi.

Pour aller plus loin


Vous repensez votre SIEM ?

Session technique de 30 minutes. Sans engagement.

Vous nous dites où vous en êtes, quelle réglementation vous concerne et ce qui vous préoccupe. Vous repartez de l'appel avec une esquisse d'architecture, une estimation d'effort et les prochaines étapes. Pas de devis générique, pas de discours commercial — directement avec quelqu'un de l'équipe technique.

Bacula : sauvegarde immuable anti-ransomware sans facturation

Sauvegarde & Résilience · Avril 2026

Bacula : la sauvegarde qui tient face aux rançongiciels. Sans facturer au To.

Les groupes de ransomware modernes ne s'attaquent plus d'abord à vos serveurs. Ils s'attaquent d'abord à vos sauvegardes. Voici ce que cela signifie concrètement, ce qu'est réellement une sauvegarde immuable, et pourquoi de plus en plus de nos clients tournent le dos à Veeam et Veritas pour basculer vers Bacula.

Avril 202610 min de lecture

Pendant des années, la sauvegarde a été la tâche ingrate du datacenter. Celle qu'on configurait un vendredi après-midi, qu'on validait avec quelques coches vertes, et qu'on ne regardait plus jusqu'à ce qu'un pépin arrive. On est tous passés par là.

Cette négligence confortable n'est plus tenable. Le serveur de sauvegarde est désormais la première chose que les groupes de ransomware modernes cherchent à neutraliser, et la raison est brutalement simple : s'ils le font tomber avant de chiffrer quoi que ce soit, votre entreprise n'a plus d'issue. Vous payez, ou vous perdez les données. Et pendant ce temps, Veeam, Veritas et Commvault continuent de facturer au téraoctet. Veeam en particulier a annoncé des hausses de 4 à 8 % chaque année, et certains clients rapportent des augmentations cumulées de 25 % ou plus sur quatre ans. Il existe une alternative que la plupart des équipes IT n'ont pas encore prise au sérieux.

Le contexte 2026

Votre sauvegarde n'est plus la dernière ligne de défense. Elle est la première victime.

Fin mars, Bacula Systems a publié deux articles qui résument bien où en est la discussion aujourd'hui. Le premier explique pourquoi l'infrastructure de sauvegarde est une cible plus précieuse pour un attaquant qu'un compte d'administrateur de domaine, et le second pourquoi le Zero Trust s'effondre au niveau de la couche de sauvegarde. Rien de tout cela n'est une nouveauté pour les équipes de réponse aux incidents — elles le répètent depuis deux ans. Mais le fait de le voir noir sur blanc change des conversations de comité de direction qui étaient auparavant impossibles à tenir.

Quand un client nous appelle pour gérer un incident, le schéma qu'il nous décrit est presque toujours le même, à quelques variations près :

Jour 1-3 Accès initial (phishing, VPN, 0-day) Jour 4-10 Reconnaissance + élévation de privilèges Jour 11-14 Localisation et compromission du serveur de sauvegarde Jour 15 Effacement des catalogues et des dépôts Jour 16 Lancement du chiffrement massif Jour 17 Note de rançon sur l'intranet

Regardez cette frise un instant. L'attaquant passe plus de jours à neutraliser la sauvegarde qu'à lancer le chiffrement lui-même. Ce n'est pas une erreur de sa part. Il sait très bien que si la sauvegarde survit, la victime ne paie pas, et toute l'opération perd son intérêt économique. C'est de la comptabilité criminelle froide.

C'est pour cela que la question "est-ce qu'on a des sauvegardes ?" ne vaut plus comme réponse à quoi que ce soit. La question vraiment utile est inconfortable : ces sauvegardes seraient-elles impossibles à détruire, même pour quelqu'un qui aurait déjà des identifiants d'administrateur sur votre réseau ? Si vous devez y réfléchir, la réponse honnête est sans doute non.

Le chiffre qui dérange. Les rapports de résilience publiés au long de 2025 indiquent que plus d'un tiers des organisations victimes de ransomware découvrent, en pleine crise, que leurs sauvegardes ont aussi été touchées. Et voici la partie qui nous hante : dans la grande majorité de ces cas, le système de sauvegarde "fonctionnait parfaitement" la veille. Tableau de bord vert, e-mails quotidiens de succès, dernière copie à trois heures du matin. Tout allait bien. Jusqu'au moment où ce n'était plus le cas.
Le contexte réglementaire

La directive NIS2, transposée dans les droits nationaux européens en 2024 et appliquée activement depuis 2025, rend la résilience du système d'information un sujet obligatoire pour un périmètre beaucoup plus large qu'auparavant. La sauvegarde immuable et la capacité à démontrer une reprise d'activité effective ne sont plus seulement de bonnes pratiques — elles deviennent progressivement une exigence de conformité. Si votre organisation tombe dans le périmètre NIS2, l'architecture de sauvegarde est un sujet qui va remonter au comité de direction, que vous le vouliez ou non.

La bonne définition

Ce que "sauvegarde immuable" veut vraiment dire

Avertissement : "sauvegarde immuable" est devenu un slogan marketing. À peu près tous les éditeurs prétendent en proposer une, et la plupart désignent des choses radicalement différentes. Soyons donc précis sur ce dont on parle ici.

Une sauvegarde est véritablement immuable quand, une fois qu'elle a été écrite, personne ne peut la modifier ni la supprimer avant l'expiration de sa rétention. Personne. Ni l'utilisateur qui l'a créée, ni votre DBA avec des identifiants valides, ni vous-même avec le compte root, ni un attaquant qui aurait déjà compromis le serveur de sauvegarde. Si l'une de ces personnes peut détruire la copie, la copie n'est pas immuable. C'est juste une sauvegarde ordinaire avec une belle étiquette dessus.

Pour obtenir cette garantie en pratique, il existe trois approches sérieuses, et Bacula les supporte toutes les trois :

MécanismeDe quoi il s'agitÀ quoi ça sert
WORM sur bande LTOCartouches LTO en mode Write-Once-Read-Many. Le firmware du lecteur refuse physiquement toute réécriture.Air-gap réel. On sort la bande de la bibliothèque, on la met en coffre, et on l'oublie. Aucun réseau ne l'atteint.
Object Lock sur S3 / CephObjets verrouillés via l'API avec une rétention liée à l'objet. Même le root du bucket ne peut pas y toucher.Immuabilité pour le stockage objet. Compatible avec MinIO, Ceph RGW, AWS S3, Azure Blob.
Systèmes de fichiers append-onlyZFS ou Btrfs avec des snapshots que le processus de sauvegarde lui-même ne peut ni modifier ni supprimer.Première ligne de défense sur disque local. Utile pour les petits environnements, mais pas un substitut à l'air-gap réel.

La règle que de nombreux RSSI adoptent discrètement en ce moment s'appelle 3-2-1-1-0. Vous l'avez peut-être déjà croisée : trois copies, sur deux supports différents, une hors-site, une immuable, et zéro erreur lors de la vérification. Ce "1-0" est exactement ce qui a changé par rapport au classique 3-2-1 que nous avons tous connu. Avoir des copies ne suffit plus — elles doivent être inaltérables, et elles doivent être vérifiées automatiquement sans que personne n'ait à y penser. Et voici le point important : Bacula fait ces deux choses dans son cycle de fonctionnement normal. Ce n'est pas un module premium vendu à part.

Pourquoi la bande redevient sérieuse

En janvier, le consortium LTO a présenté LTO-10 : 30 ou 40 To natifs par cartouche (jusqu'à 100 compressés), 400 Mo/s, et le même air-gap physique que LTO-1 il y a 25 ans. La bande reste la seule technologie de sauvegarde où un attaquant avec root sur votre serveur Bacula ne peut littéralement pas atteindre la donnée, parce que la donnée n'est reliée à rien. Chez SIXE, nous voyons depuis deux ans des clients qui avaient mis leurs bibliothèques LTO à la casse revenir acheter du matériel neuf. Ce n'est pas de la nostalgie — c'est un calcul de risque.

Bibliothèque de bandes LTO dans un rack de datacenter utilisée comme stockage immuable air-gap pour des sauvegardes Bacula
Une bibliothèque LTO moderne — le seul endroit où le ransomware n'atteint pas vraiment la donnée.
Pourquoi Bacula

Pourquoi Bacula colle si bien à ce scénario

Bacula protège des données depuis plus de vingt ans dans des banques, administrations publiques, hôpitaux, opérateurs télécom et centres de données scientifiques à l'échelle du pétaoctet. C'est probablement le logiciel de sauvegarde d'entreprise open source le plus mature qui existe, et ce n'est pas nous qui le disons — ce sont les installations qui tournent depuis les années deux mille, et ce sont les clients de l'éditeur qui lui confient leur donnée critique depuis vingt ans. La version commerciale actuelle est Bacula Enterprise 18.0.8, qui apporte des choses qui auraient semblé de la science-fiction il y a cinq ans : BGuardian pour détecter l'empoisonnement du catalogue, un tableau de bord de sécurité dans BWeb, le support natif de Microsoft 365 et Azure, un plugin Nutanix AHV, les snapshots CSI de Kubernetes.

Mais la vraie raison pour laquelle Bacula tient aussi bien face aux ransomwares modernes, ce ne sont pas les nouveaux plugins. Ce sont des choix de conception que le projet a faits il y a vingt ans et qui, avec le recul, ont très bien vieilli :

  • Architecture distribuée par conception. Director, catalogue, storage daemons et clients sont tous des processus distincts. Ils peuvent vivre sur des hôtes différents, avec des identifiants différents, sur des segments réseau différents. Compromettre l'un ne donne pas accès aux autres — loin de là.
  • Catalogue dans une vraie base de données. PostgreSQL ou MySQL avec leurs propres sauvegardes, leurs propres contrôles d'accès, leurs propres journaux d'audit. Vous pouvez le répliquer, le mettre derrière son propre pare-feu, le traiter comme l'actif critique qu'il est réellement. Ce n'est pas un fichier binaire perdu dans /var.
  • Vérification automatique du contenu. Bacula relit périodiquement les volumes et compare les checksums. Si quelque chose a été altéré — par une main humaine, par un secteur disque défectueux, par un bug matériel bizarre — vous le savez bien avant d'avoir besoin du restore d'urgence. Ça paraît ennuyeux sur le papier, mais c'est la différence entre une frayeur et une catastrophe.
  • Open source authentique, sans petits caractères. Le format des volumes est documenté. Si SIXE disparaît demain, ou si Bacula Systems disparaît, vos sauvegardes restent récupérables avec les outils open source de la communauté. Ce n'est pas quelque chose qu'on peut dire de beaucoup d'autres éditeurs.
  • LTO, Object Lock et air-gap, intégrés depuis toujours. Ces mécanismes ne sont pas un ajout récent parce que les ransomwares sont devenus à la mode. Ils sont la façon naturelle d'exploiter Bacula depuis des décennies. Quand le reste du marché a redécouvert que la bande comptait à nouveau, Bacula en était déjà là depuis longtemps.
┌────────────────────────────────────────────────┐ Bacula Director (orchestration + catalogue) └───────┬────────────┬────────────┬──────────────┘ ┌────▼────┐ ┌─────▼─────┐ ┌────▼─────┐ Clients │ │ Storage │ │ Catalog Linux │ │ Daemons │ │ Postgres VMware │ │ │ │ Proxmox │ │ → LTO WORM│ │ IBM i │ │ → Ceph S3 │ │ DB2 │ │ → Disk ZFS│ │ └─────────┘ └───────────┘ └──────────┘
Le volet financier

Pourquoi Bacula devient moins cher chaque année (et pas les autres)

L'écart de prix entre Bacula et les gros éditeurs propriétaires n'est pas une histoire de remise de couloir. Il tient au modèle de licensing lui-même. Veeam, Veritas NetBackup et Commvault facturent tous en fonction de la quantité de données protégées, du nombre d'hôtes, ou d'une combinaison créative des deux. Le résultat est toujours le même : quand votre entreprise grandit, votre facture de sauvegarde grandit au même rythme. Et les entreprises grandissent chaque année.

Bacula Systems, de son côté, licencie par nombre de clients et par plugins activés. Le prix reste stable même si le volume de données double. La première fois qu'un DAF prend conscience de ça dans une réunion avec nous, le silence autour de la table est assez parlant.

Et la situation se durcit de l'autre côté. Veeam a annoncé des hausses de prix de 4 à 8 % pour janvier 2025 et janvier 2026, et ce n'est que le chiffre officiel — sur les forums Veeam, certains clients rapportent des augmentations cumulées de 25 % ou plus entre 2021 et 2024, avec des renouvellements individuels à +49 %. On commence à voir dans la presse tech des comparaisons avec ce que Broadcom a fait à VMware après l'acquisition. Elles ne sont pas infondées.

ModèleCe que vous payezCe qui se passe quand vous grandissez
VeeamPar workload protégé, par socket, ou par instanceAugmente avec le nombre d'hôtes — plus 4-8 % chaque année
Veritas NetBackupPar capacité front-end (To protégés)Augmente avec le volume de données
CommvaultMélange de capacité et de modules activésAugmente avec les deux simultanément
Bacula EnterprisePar nombre de clients et pluginsStable. Les données doublent, le coût ne bouge pas.
Bacula Community + SIXELogiciel gratuit + heures de nos ingénieursVous ne payez que ce que vous utilisez de notre équipe.

Dans les migrations que nous avons menées depuis Veeam ou Veritas, l'économie annuelle de la première année se situe typiquement entre 60 % et 85 %. Le point idéal se trouve dans les environnements de taille moyenne, entre 20 et 200 To protégés — c'est là que la tarification à la capacité fait le plus mal et que Bacula brille le plus clairement. Et l'écart se creuse d'année en année, parce que votre donnée continue de grandir et que Bacula ne vous pénalise pas pour ça.

Une précision sur les chiffres. L'économie réelle dépend de votre contrat actuel, de votre nombre d'hôtes, des modules que vous utilisez, de votre empreinte de stockage. Il n'y a pas de chiffre magique. Ce que nous faisons chez SIXE, c'est prendre votre facture annuelle actuelle et la mettre en parallèle avec une estimation réaliste de Bacula plus notre support, avec vos vrais chiffres, avant que vous ne vous engagiez sur quoi que ce soit. Et si l'économie ne justifie pas le mouvement, nous vous le disons. Ça nous a valu pas mal d'amis.
L'implémentation

Comment concevoir un Bacula qui résiste à une attaque

Installer Bacula n'est pas la partie difficile. Concevoir un Bacula qui survit à quelqu'un qui a déjà root à l'intérieur de votre réseau — c'est là que commence la vraie ingénierie. Voici les cinq décisions d'architecture qui font la différence entre une sauvegarde qui sauve l'entreprise et une qui tombe avec elle :

1. Séparer le plan de contrôle du plan de données

Le director Bacula et son catalogue PostgreSQL ne devraient pas vivre sur le même réseau que les clients qu'ils protègent. Il faut un réseau d'administration séparé, avec ses propres règles, son propre MFA, et idéalement une architecture zero-trust appliquée aux serveurs de sauvegarde eux-mêmes. Ça paraît évident — et pourtant nous le voyons mal fait la plupart des fois que nous auditons une installation existante.

2. Au moins deux dépôts vraiment indépendants

Un dépôt rapide sur disque, ou sur Ceph avec Object Lock, pour les restores du quotidien. Et un second dépôt air-gap pour la rétention longue : bande LTO, ou un cluster Ceph physiquement isolé dans un autre site, ou les deux. La règle 3-2-1-1-0 n'est pas une suggestion optionnelle, c'est le minimum vers lequel il faut raisonnablement viser. Si votre plan de sauvegarde actuel tient dans un seul dépôt, vous avez un problème.

3. Vérification automatique. Activez-la vraiment.

Bacula permet de planifier des jobs qui relisent les volumes et comparent les checksums. Activez-les. Sérieusement. C'est la seule façon de détecter une altération, une dégradation du support, ou une erreur matérielle bizarre avant de la découvrir le pire jour possible — le jour où vous avez besoin d'un restore d'urgence. Notre recommandation habituelle est au minimum hebdomadaire, plus fréquent quand l'infrastructure le supporte.

4. Des rétentions qu'on ne peut pas raccourcir à la main

Les durées de rétention sont définies dans le director et "scellées" au moment de l'écriture sur un volume immuable. Une fois qu'un volume a été écrit sur une bande WORM ou dans un bucket Object Lock actif, il n'existe aucune console Bacula ni aucun client de base de données qui puisse réduire cette rétention. Ce volume va exister jusqu'à son expiration, point final. C'est exactement ce qui protège votre sauvegarde contre un insider malveillant ou un attaquant avec des identifiants valides.

5. Un plan de reprise écrit et réellement testé

Une sauvegarde qu'on ne restaure jamais n'existe pas. Bacula rend la partie restore plutôt agréable à opérer, mais répéter l'exercice sérieusement — avec des minutages, des responsables, des points de décision — c'est le travail de l'équipe. Chez SIXE, nous l'intégrons au Plan de Rétablissement en cas de Catastrophe du client, avec des exercices programmés au moins deux fois par an. Il n'y a pas de raccourci sur ce point.

Là où la plupart des projets s'arrêtent

Ces cinq points sont exactement l'endroit où quasiment tous les projets Bacula qu'on nous demande d'auditer se sont arrêtés à mi-chemin. Rien de tout ça n'est activé par défaut — ce sont des décisions d'ingénierie qui dépendent de votre infrastructure concrète, de votre cadre réglementaire, du nombre de personnes qui touchent à la sauvegarde, de votre budget. Quand SIXE entre dans un projet Bacula, c'est littéralement ce que nous faisons. Et c'est généralement la partie qui apporte le plus de valeur, bien plus que l'installation du paquet en elle-même.

La migration

Migrer depuis Veeam ou Veritas sans perdre un seul octet

L'objection qu'on nous fait lors du premier appel est presque toujours mot pour mot la même : "on a sept ans d'historique dans Veeam, on ne peut pas se permettre de le perdre". Et ils ont entièrement raison. Dans la banque, la santé, l'administration publique, ou tout environnement régi par le RGPD, ISO 27001, NIS2 ou des référentiels sectoriels, la rétention longue n'est pas une préférence — c'est une obligation légale. La bonne nouvelle, c'est qu'il n'y a aucune raison technique de perdre quoi que ce soit. Il suffit de concevoir la migration calmement.

Chez SIXE, nous procédons en trois phases :

  1. Fenêtre de coexistence. On laisse l'ancien système tourner à pleine puissance, faisant ses sauvegardes quotidiennes comme avant. Bacula commence à protéger en parallèle. Pendant quelques semaines, vous avez une couverture double et un risque nul. Ça rassure aussi pas mal les équipes sécurité qui fronçaient les sourcils au départ.
  2. Des restores réels avant d'éteindre quoi que ce soit. C'est ici qu'on gagne ou qu'on perd une migration. On ne fait pas le classique test de restore sur une VM témoin — on restaure des charges qui feraient vraiment mal si elles échouaient. Une base de données critique. Un serveur de fichiers sous contrainte réglementaire. Quand ces restores valident que la conception de Bacula couvre bien le scénario, on passe à la phase suivante. Pas avant.
  3. Archive historique en lecture seule. L'historique de l'ancien système n'est pas touché. Il reste accessible aussi longtemps que votre politique de rétention l'exige, en lecture seule, comme une archive vivante. Si on vous demande un fichier de 2023 l'année prochaine, il est toujours là. Et Bacula s'occupe de tout ce qui est nouveau en parallèle.

C'est honnêtement l'un des services qu'on nous demande le plus en ce moment. Le cocktail est parfait : les hausses de prix propriétaires qui s'enchaînent chaque année, la pression nouvelle autour de la sauvegarde immuable, et la prise de conscience progressive que la sauvegarde était dans la pile "risque non traité" depuis bien trop longtemps. Si vous voulez voir le détail complet du service — SLAs, cas d'usage, exemples sectoriels — tout est là : Support technique et migration vers Bacula.

Prochaines étapes

Par où commencer dès aujourd'hui

Si vous êtes arrivé jusqu'ici et que vous vous dites "il faudrait vraiment qu'on regarde notre sauvegarde de plus près", vous avez sans doute raison. Pas besoin de lancer un gros projet pour faire le premier pas. Honnêtement, ce qui est le plus utile, c'est généralement un audit court qui répond honnêtement à trois questions :

  • Est-ce que mes sauvegardes sont vraiment immuables ? Si un attaquant avait des identifiants d'admin sur mon réseau maintenant, pourrait-il les détruire ?
  • Sont-elles vérifiées automatiquement ? Ou est-ce que je ne saurai qu'elles sont corrompues que le jour où j'en aurai vraiment besoin ?
  • Combien est-ce que je paie par To protégé par an, et à quoi ressemblera cette facture dans trois ans ?

Vous pouvez répondre aux trois avec votre équipe actuelle, sans appeler personne. Et si l'une des réponses vous met mal à l'aise, parlons-en. Sans commercial, sans slides, directement avec quelqu'un de l'équipe technique qui a déjà mis les mains dans des projets comme le vôtre.

Pour aller plus loin


Votre sauvegarde tiendrait-elle aujourd'hui ?

Regardons votre architecture de sauvegarde ensemble

Sans commerciaux, sans présentations génériques, sans engagement. Un appel technique avec quelqu'un de l'équipe SIXE pour voir où vous en êtes et ce qui vaut vraiment la peine d'être touché. Si Bacula colle, nous vous le dirons. Sinon aussi.

LLM sur IBM i via PASE — Sans Linux ni GPU

IBM i · Mars 2026

On a exécuté un LLM sur IBM i. Sans Linux. Sans cloud. Sans GPU.

llama.cpp compilé pour AIX tourne nativement sur IBM i via PASE. Vos programmes RPG peuvent appeler un LLM local sans infrastructure supplémentaire et sans envoyer vos données à l'extérieur.

Mars 20268 min de lecture

Si vous administrez un IBM i, vous connaissez bien la réponse habituelle quand quelqu'un pose la question de l'IA : « montez un LPAR Linux », « utilisez OpenAI », « regardez Wallaroo ». Toutes ces options impliquent de sortir de la plateforme, d'ajouter des couches, et à un moment ou un autre d'envoyer des données métier sur un serveur que vous ne contrôlez pas.

Il y a 150 000 systèmes IBM i qui traitent des transactions bancaires, d'assurance et de santé dans le monde. La réponse ne peut pas toujours être « ajoutez de l'infrastructure ». On a donc essayé autre chose.

L'expérience

Ce qu'on a fait exactement

On a pris llama.cpp — le moteur d'inférence LLM open source le plus utilisé — on l'a compilé pour AIX et copié le binaire sur une partition IBM i V7R5. On l'a exécuté via PASE. Ça a fonctionné du premier coup.

$ uname -a
OS400 WWW 5 7 007800001B91

$ /QOpenSys/pkgs/bin/python3 -c "import platform; print(platform.platform())"
OS400-5-007800001B91-powerpc-64bit

$ /QOpenSys/pkgs/bin/python3 -c "import sys; print('Byte order:', sys.byteorder)"
Byte order: big

IBM i V7R5 sur pub400.com — un système IBM i public. Big-endian, powerpc-64bit, OS400. Pas Linux, pas AIX. IBM i.

Le type de binaire

$ file llama/llama-simple
llama/llama-simple: 64-bit XCOFF executable or object module

Un binaire XCOFF 64 bits — le format exécutable natif d'AIX. Compilé sur AIX 7.3 POWER avec GCC 13.3 et les extensions vectorielles VSX. C'est le même binaire de notre projet llama-aix, qui distribue déjà 10 modèles GGUF big-endian sur HuggingFace.

Première exécution

$ LIBPATH=/home/HBSIXE/llama /home/HBSIXE/llama/llama-simple --help

example usage:

    /home/HBSIXE/llama/llama-simple -m model.gguf [-n n_predict] [prompt]

Le binaire charge, lie libggml et libllama, analyse les arguments et répond. Tout à l'intérieur de PASE. Pour lancer une vraie inférence, on lui passe un modèle GGUF big-endian :

$ LIBPATH=/home/HBSIXE/llama /home/HBSIXE/llama/llama-simple \
    -m models/tinyllama-1.1b-q4_k_m-be.gguf \
    -p "What is IBM i?" -n 100 -t 4
Terminal IBM i PASE exécutant llama.cpp : le binaire XCOFF charge, lie les bibliothèques et répond à un prompt en temps réel
Le contexte

Pourquoi ça a du sens pour un environnement IBM i

En 2026, la conversation sur l'IA dans la communauté IBM i est plus active que jamais. IBM vient de lancer Bob (le successeur de WCA for i), un assistant de codage pour les développeurs RPG. 70 % des clients IBM i prévoient des mises à jour matérielles cette année. Et pourtant, une question reste sans réponse claire :

Comment intégrer un modèle de langage dans mes applications IBM i sans dépendre d'un service externe ?

Les options habituelles aujourd'hui :

OptionCe que ça impliqueLe problème
LPAR LinuxMonter une partition séparée, y faire tourner le LLM, l'appeler depuis RPG via APIInfrastructure supplémentaire, coût additionnel, les données transitent entre partitions
API cloudAppeler OpenAI, Azure ou AWS depuis RPGLes données métier quittent la machine. Problème sérieux en banque, assurance, santé — et potentiellement incompatible avec le RGPD
WallarooL'option 1 packagée comme service500 $/mois. C'est toujours un LPAR Linux avec une étiquette
PASE + llama.cppLe LLM tourne directement dans IBM i via PASEPas de matériel supplémentaire. Les données ne quittent pas la partition.
Et IBM Bob ?
Bob est fait pour le développeur : il aide à comprendre, documenter et générer du code RPG depuis l'IDE. Ce qu'on décrit ici concerne l'application en production : un LLM qui tourne dans la même partition et que n'importe quel programme RPG peut appeler comme une simple API locale. Ce sont des outils complémentaires, pas concurrents.
RGPD et résidence des données

Pour les organisations belges et françaises soumises au RGPD, la question de la résidence des données est non négociable. Une inférence LLM qui s'exécute en local sur IBM i, sans aucun transfert vers un service cloud tiers, est par construction conforme sur ce point. Aucune donnée ne sort de votre infrastructure.

La base technique

PASE : le pont que vous aviez déjà

PASE (Portable Application Solutions Environment) est un environnement d'exécution intégré à IBM i qui exécute des binaires AIX de façon native. Ce n'est pas de l'émulation — c'est une couche qui expose les appels système AIX directement sur le noyau IBM i. Si quelque chose tourne sur AIX, ça peut tourner sur IBM i via PASE.

┌──────────────────────────────────────────┐ IBM i (OS400) │ ┌──────────────┐ ┌────────────────┐ │ │ │ RPG / CL │ │ PASE │ │ │ │ COBOL / Db2 │───→│ (AIX runtime) │ │ │ │ │ │ │ │ │ │ localhost │ │ llama-server │ │ │ │ :8080 │ │ + modèle GGUF │ │ │ └──────────────┘ └────────────────┘ │ IBM POWER Hardware └──────────────────────────────────────────┘

On compile et distribue des paquets AIX via le dépôt AIX de LibrePower depuis plusieurs années — plus de 30 paquets open source installables via DNF. Quand llama.cpp a rejoint le catalogue, tester le passage à IBM i était l'étape naturelle. PASE s'occupe du reste.

Pour les administrateurs IBM i

Vous n'avez rien de spécial à installer sur le système d'exploitation. PASE est déjà actif. Il vous faut seulement le binaire XCOFF de llama.cpp et un modèle GGUF big-endian. Le LLM tourne comme n'importe quel processus PASE, sans toucher à l'environnement natif IBM i.

L'obstacle technique

Le problème du big-endian (et comment on l'a résolu)

Il y a une raison pour laquelle personne n'avait fait ça proprement avant : l'ordre des octets. IBM i et AIX sont big-endian. La quasi-totalité des logiciels d'IA — x86, ARM, Linux ppc64le — suppose un ordre little-endian. Un fichier GGUF téléchargé directement depuis HuggingFace ne fonctionne pas sur IBM i : les octets sont dans le mauvais sens.

On avait déjà résolu ce problème dans notre travail sur AIX. La solution : convertir les modèles avant de les distribuer. On les publie sur huggingface.co/librepowerai, validés sur du vrai matériel AIX et prêts à être chargés directement dans IBM i PASE.

ModèleTailleQuantisation
TinyLlama 1.1B Chat668 MoQ4_K_M
LFM 1.2B Instruct695 MoQ4_K_M
LFM 1.2B Thinking731 MoQ4_K_M
7 autres modèles disponibles

Ce sont les mêmes modèles qui atteignent 10–12 tok/s sur AIX POWER. Sur IBM i POWER10 — avec l'accélération matérielle MMA active via OpenBLAS — les performances devraient être comparables ou meilleures. Les benchmarks concrets sur IBM i sont en cours de préparation.

De la PoC à la production

De la preuve de concept à la production

Exécuter --help prouve que le binaire charge. Le chemin réel vers quelque chose d'utile pour vos applications comporte trois étapes — et la première est déjà disponible.

Étape 1 : Inférence directe (disponible maintenant)

Depuis n'importe quelle session SSH ou QSH sur l'IBM i :

# Inférence en ligne de commande
LIBPATH=/chemin/vers/llama /chemin/vers/llama/llama-simple \
    -m /chemin/vers/modele.gguf \
    -p "Résume ce bon de commande" -n 200 -t 8

Utile pour les scripts CL, les jobs en batch, ou simplement pour vérifier que le modèle charge et répond correctement sur votre matériel avant d'aller plus loin.

Étape 2 : Serveur API compatible OpenAI (prochainement)

llama.cpp inclut llama-server, qui expose un endpoint HTTP compatible avec l'API OpenAI. Une fois actif dans PASE, n'importe quel programme RPG peut l'appeler via QSYS2.HTTP_POST — comme n'importe quelle autre API :

# Démarrer le serveur d'inférence sur IBM i via PASE
LIBPATH=/chemin/vers/llama /chemin/vers/llama/llama-server \
    -m /chemin/vers/modele.gguf \
    --host 0.0.0.0 --port 8080 -t 8
// Appel depuis RPG — le LLM est sur localhost
dcl-s url varchar(256) inz('http://localhost:8080/v1/chat/completions');
dcl-s corps varchar(65535);
dcl-s reponse varchar(65535);
// QSYS2.HTTP_POST — aucune donnée ne quitte IBM i

L'essentiel : localhost. Le modèle est sur la même machine. Les données ne quittent pas la partition.

Étape 3 : Intégration applicative métier (en développement)

  • Analyse de documents : passer des rapports Db2 au LLM pour générer des résumés automatiques
  • Requêtes en langage naturel : l'utilisateur écrit en français, le LLM renvoie du SQL
  • Modernisation du code RPG : le LLM analyse et documente les programmes existants sans quitter IBM i
  • Supervision intelligente : analyser les messages QSYSOPR et les journaux de travaux avec un contexte sémantique
Une note sur les performances : les petits modèles (1–2 milliards de paramètres) dans PASE sont largement suffisants pour la classification, le résumé, l'extraction de données structurées et les réponses à format fixe. Pour la génération de texte plus longue ou le raisonnement complexe, les modèles 7B+ scalent bien avec davantage de threads. Les benchmarks IBM i POWER10 sont en cours de préparation.
Hands-on

Comment l'essayer vous-même

Si vous avez accès à un IBM i avec PASE actif, c'est trois étapes.

1. Récupérer le binaire llama.cpp pour AIX

Disponible sur le GitLab de LibrePower. Si vous avez DNF/yum configuré :

# Depuis AIX (ou via PASE si vous avez dnf)
dnf install llama-cpp

2. Télécharger un modèle big-endian

curl -L -o tinyllama-be.gguf \
  "https://huggingface.co/librepowerai/TinyLlama-1.1B-Chat-v1.0-GGUF-big-endian/resolve/main/tinyllama-1.1b-q4_k_m-be.gguf"

TinyLlama est un bon point de départ : 668 Mo, chargement rapide, suffisant pour vérifier que tout fonctionne avant de passer à des modèles plus grands.

3. Lancer l'inférence

LIBPATH=/chemin/vers/llama ./llama-simple \
    -m tinyllama-be.gguf \
    -p "Qu'est-ce qu'IBM i ?" \
    -n 150 -t 4
Des systèmes IBM i en production ?

SIXE accompagne des organisations belges et françaises dans la gestion de leurs environnements IBM i depuis des années. Si vous voulez évaluer si cette approche correspond à votre architecture — ou comprendre ce qu'elle implique pour vos applications RPG — contactez-nous, sans engagement.

Feuille de route

La suite

C'est une preuve de concept solide, pas un produit fini. Voici ce qu'on prévoit de faire ensuite :

  • llama-server sur IBM i — le serveur API HTTP dans PASE, documenté et packagé pour que vous puissiez le lancer en quelques minutes
  • Exemples d'intégration RPG — du vrai code d'appel au LLM depuis des programmes RPG via QSYS2.HTTP_POST
  • Benchmarks IBM i POWER10/POWER11 — des mesures réelles de tok/s avec PASE sur du matériel de production
  • Modèles plus grands — tests avec des modèles 7B+ sur des partitions avec suffisamment de mémoire
  • vLLM pour IBM i — notre paquet vLLM pour ppc64le, adapté pour tourner dans PASE

Autres projets LibrePower

ProjetCe qu'il fait
llama-aixllama.cpp pour AIX avec 10 modèles GGUF big-endian prêts à télécharger
linux.librepower.orgDépôt APT avec vLLM pour Linux ppc64le (Ubuntu/Debian)
aix.librepower.orgPlus de 30 paquets open source pour AIX, installables via DNF

IBM i avec PASE ?

Testez le LLM sur votre propre partition

Le binaire est sur GitLab. Les modèles sont sur HuggingFace. Si vous avez accès à PASE et quelques minutes, vous pouvez reproduire exactement ce qu'on décrit ici :)

vLLM sur IBM POWER : inférence LLM sans GPU



LibrePower · Linux on Power · Mars 2026

vLLM sur IBM POWER : inférence LLM sans GPU

Le premier paquet vLLM précompilé pour Linux ppc64le. Construit par la communauté — et il tourne sur le matériel que vous avez déjà.

Mars 202618 min de lecture


Si vous administrez des serveurs IBM POWER, vous connaissez la dynamique. Le matériel est exceptionnel — POWER9, POWER10 et POWER11 offrent une fiabilité incomparable, une bande passante mémoire sans égal et un débit par cœur que peu d’architectures peuvent égaler. Mais dans l’écosystème IA, vous aviez jusqu’ici deux options : apporter vos propres GPU (généralement x86) ou passer par Red Hat OpenShift AI. Il existe désormais une troisième option pour exécuter l’inférence de LLMs sur IBM POWER. Elle prend 30 secondes, fonctionne sur du matériel existant et utilise l’accélération matérielle MMA de façon automatique.

Le paquet

Ce que nous avons construit : vLLM sur IBM POWER en paquet .deb

vLLM est le moteur d’inférence LLM open source le plus utilisé. Il alimente l’inférence à l’échelle de millions de requêtes quotidiennes en production. Il prend en charge l’API OpenAI complète : /v1/chat/completions, /v1/completions, /v1/models — streaming, appels de fonctions, usage d’outils.

Le problème : il n’existait aucun paquet précompilé pour ppc64le. Ni sur PyPI. Ni dans les dépôts Ubuntu. Si vous vouliez vLLM sur IBM POWER, vous étiez livré à vous-même. La communauté IBM elle-même a documenté la complexité de l’installation manuelle.


Nous l’avons donc compilé. Sur du vrai matériel IBM POWER. Optimisé pour l’architecture. Et packagé sous forme de .deb qu’APT peut installer avec résolution complète des dépendances.

$ apt-cache show python3-vllm

Package: python3-vllm
Version: 0.9.2-1
Architecture: ppc64el
Maintainer: LibrePower <packages@librepower.org>
Depends: python3 (>= 3.10), python3-numpy, python3-requests
Homepage: https://librepower.org/stack/databases-operating-systems/linux/
Description: Serveur d'inférence LLM compatible OpenAI pour ppc64le
Ubuntu sur IBM POWER
Faire tourner Ubuntu sur IBM POWER est la base de ce flux de travail. SIXE déploie et supporte les environnements Ubuntu ppc64le en tant que Canonical Partner — la même infrastructure qui rend possible cette installation par APT. Pour aller plus loin sur l’administration Linux en Power, nous proposons des formations officielles IBM en français, disponibles à Paris, Bruxelles, Luxembourg et en ligne.

Sous le capot

Le processus : du code source au paquet .deb sur ppc64le

Compiler vLLM pour POWER n’est pas un simple pip install. Voici ce que cela a impliqué.

PyTorch sur POWER

vLLM dépend de PyTorch, qui n’est pas distribué pour ppc64le sur PyPI. IBM publie des wheels sur wheels.developerfirst.ibm.com — nous les utilisons comme base. Consultez le catalogue complet des outils de développement IBM supportés pour POWER.

L’extension C++

La voie haute performance de vLLM est une extension C++ (_C.abi3.so) qui gère l’attention, le cache, les fonctions d’activation et la quantification. Elle doit être compilée depuis le code source avec CMake, en liant l’API C++ de PyTorch et oneDNN pour des opérations GEMM optimisées.

-- PowerPC détecté
-- Flags de compilation : -fopenmp -DVLLM_CPU_EXTENSION
   -mvsx -mcpu=power9 -mtune=power9
-- Fichiers source : csrc/cpu/quant.cpp csrc/cpu/activation.cpp
   csrc/cpu/attention.cpp csrc/cpu/cache.cpp csrc/cpu/utils.cpp
   csrc/cpu/layernorm.cpp csrc/cpu/pos_encoding.cpp
[100%] Liaison du module partagé CXX _C.abi3.so
[100%] Cible _C construite

Le binaire résultant inclut oneDNN avec des noyaux GEMM PPC64 — la même bibliothèque mathématique qu’Intel utilise pour x86, mais ciblant les unités vectorielles de POWER.

Résolution des dépendances

L’écosystème Python sur ppc64le présente des lacunes. Certains paquets ont des wheels précompilées, d’autres nécessitent une compilation depuis le source, et quelques-uns ont des conflits de version. Nous avons tout résolu pour que vous n’ayez pas à le faire.

En pratique

Inférence LLM sur IBM POWER : code et résultat

Voici ce que cela donne en pratique. D’abord, installez le paquet :

# Ajouter le dépôt APT LibrePower
curl -fsSL https://linux.librepower.org/install.sh | sudo sh

# Installer vLLM pour ppc64le
sudo apt update
sudo apt install python3-vllm

# Installer les wheels PyTorch d'IBM
pip3 install torch --extra-index-url \
  https://wheels.developerfirst.ibm.com/ppc64le/linux

Puis exécutez l’inférence depuis Python :

# Python
from vllm import LLM, SamplingParams

llm = LLM(
    model="Qwen/Qwen2.5-0.5B-Instruct",
    dtype="bfloat16",
    device="cpu",
    enforce_eager=True
)

output = llm.generate(
    ["Explique l'informatique quantique en termes simples."],
    SamplingParams(temperature=0, max_tokens=100)
)

print(output[0].outputs[0].text)

Mais la vraie valeur de vLLM est le mode serveur, compatible avec l’API OpenAI :

# Démarrer le serveur d'inférence compatible OpenAI
python3 -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2.5-0.5B-Instruct \
    --device cpu --dtype bfloat16 --port 8000
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen2.5-0.5B-Instruct",
    "messages": [{"role": "user", "content": "Qu'\''est-ce qu'\''IBM POWER ?"}],
    "max_tokens": 100
  }'

LangChain, LlamaIndex, Open WebUI, Continue.dev — toute application pouvant pointer vers un endpoint OpenAI fonctionne sans modification. Changez base_url vers votre serveur POWER et c’est tout. C’est ce qui fait de l’inférence CPU sur IBM POWER une voie réaliste vers le déploiement d’IA générative sur infrastructure propre, sans dépendance GPU ni cloud public.

Les chiffres

Performances réelles sur POWER9, POWER10 et POWER11 : benchmarks d’inférence

Nous avons effectué des benchmarks sur les deux générations POWER avec Qwen2.5-0.5B-Instruct (494M paramètres, BF16). Ce ne sont pas des chiffres théoriques — ils proviennent de l’exécution de l’outil de benchmark sur du vrai matériel.

POWER9

$ OMP_NUM_THREADS=12 python3 bench_vllm.py
Exécution 1 : 17,8 tok/s (100 tokens en 5,6 s)
Exécution 2 : 16,7 tok/s (100 tokens en 6,0 s)
Exécution 3 : 18,5 tok/s (100 tokens en 5,4 s)
Benchmark POWER9 : fils=12 moyenne=17,6 tok/s

12 fils est le point optimal — davantage de fils ajoutent de la contention de cache sur cette charge de travail limitée par la bande passante mémoire.

POWER10

$ OMP_NUM_THREADS=1 python3 bench_vllm.py
Exécution 1 : 13,9 tok/s (100 tokens en 7,2 s)
Benchmark POWER10 : fils=1 moyenne=13,9 tok/s
13,9 tok/s depuis un seul cœur POWER10. Pour contexte : le résultat POWER9 utilise 12 fils sur plusieurs cœurs pour atteindre 17,6 tok/s. L’amélioration d’efficacité par cœur de POWER9 à POWER10 est spectaculaire, portée par l’accélération matérielle MMA. POWER11 partage la même architecture MMA avec des améliorations supplémentaires.
SystèmeFilstok/sEfficacité par cœur
POWER10/11113,913,9 tok/s/cœur
POWER91217,61,5 tok/s/cœur

Ce n’est pas une concurrence avec une A100 — cela comble un fossé entièrement différent : exécuter l’inférence de LLMs sur l’infrastructure IBM POWER que vous possédez déjà. Sans budget GPU, sans slot PCIe, sans maux de tête liés aux drivers. Pour les organisations avec des serveurs POWER9, POWER10 ou POWER11 existants, c’est la voie vers l’IA privée sans investissement en capital supplémentaire.

Nous avons également testé Qwen2.5-7B-Instruct (7 milliards de paramètres) sur un seul cœur POWER10 — il a chargé et tourné à 1,0 tok/s. Insuffisant pour une utilisation interactive sur un cœur, mais preuve que les modèles plus grands fonctionnent. Avec davantage de cœurs, cela évolue linéairement. Nos clients disposant de systèmes IBM POWER en production nous posent régulièrement la question : puis-je utiliser ce matériel pour de l’IA ? La réponse est désormais oui.

À noter que les nouveaux serveurs IBM Power11 introduisent la carte accélératrice Spyre — un matériel dédié à l’IA qui viendra compléter cette approche CPU dans les prochains mois.

Dans la machine

Ce qui se passe vraiment quand POWER10/11 exécute un modèle de langage

Si vous avez vu les présentations IBM sur l’IA en POWER, vous avez probablement rencontré les termes MMA, Spyre, oneDNN et OpenShift AI. Ils apparaissent souvent sur la même diapositive. Que signifient-ils réellement ? Et lesquels sont actifs quand vous exécutez python3 -m vllm ?

Nous avons plongé dans la pile logicielle pour répondre à cette question. Les résultats nous ont surpris.

Lexique rapide sans jargon superflu

  • LLM (grand modèle de langage) — Logiciel qui génère du texte : ChatGPT, Llama, Qwen. Un modèle mathématique avec des milliards de nombres qui prédit le mot suivant.
  • Inférence — Exécuter un modèle déjà entraîné pour obtenir des réponses. L’entraînement apprend au modèle ; l’inférence l’utilise. Cet article parle uniquement d’inférence.
  • Token — Un mot ou un fragment de mot. « 17,6 tokens par seconde » correspond à environ 17-18 mots par seconde.
  • BF16 (bfloat16) — Une façon de stocker des nombres sur 16 bits au lieu de 32. Moitié moins de mémoire, précision quasi identique. En résumé : « qualité suffisante à la moitié du coût de stockage ».
  • GEMM (multiplication générale de matrices) — L’opération mathématique centrale des réseaux de neurones. La majeure partie du temps de calcul en inférence LLM est consacrée à la multiplication de grandes matrices.
  • MMA (Matrix-Multiply Accumulate) — Circuits dédiés à l’intérieur de POWER10 et POWER11 conçus pour accélérer les calculs matriciels. Comme une calculatrice spécialisée pour l’opération précise qui domine l’inférence LLM.
  • OpenBLAS — Une bibliothèque mathématique open source avec des routines GEMM optimisées. Le moteur qui effectue la vraie multiplication de matrices sur POWER.
  • oneDNN — La bibliothèque mathématique d’Intel, également compilée dans vLLM. Un autre moteur pour le même usage.
  • PyTorch — Le framework qui exécute le réseau de neurones. Il appelle OpenBLAS ou oneDNN pour les calculs intensifs.

Comment les pièces s’assemblent

Quand vLLM génère un token, voici le chemin exact à travers la machine :

Vous tapez une question

vLLM la reçoit et la découpe en tokens

PyTorch exécute les calculs du réseau de neurones

Pour chaque couche : multiplication de grandes matrices (GEMM)

PyTorch demande à OpenBLAS : « multiplie ces deux matrices BF16 »

OpenBLAS exécute sbgemm_kernel_power10 ← ICI MMA EST UTILISÉ

Le matériel POWER10/11 exécute les instructions MMA

Le résultat remonte, le token suivant est choisi

Vous voyez le mot suivant apparaître
L’accélération MMA est déjà active dans nos benchmarks. Ce n’est pas une fonctionnalité future ni un flag de configuration — elle fonctionne dès maintenant, via le chemin PyTorch → OpenBLAS → matériel MMA. Aucune configuration spéciale requise.

La preuve : BF16 vs FP32 sur POWER10/11

Sur POWER10 et POWER11, MMA accélère les calculs BF16. Sur POWER9 (sans MMA), BF16 est en réalité plus lent que FP32 à cause de l’émulation logicielle. Si MMA fonctionne, BF16 devrait être plus rapide :

# Benchmark de multiplication de matrices (1024×1024) sur POWER10
BF16 : 384,4 GFLOPS  (5,6 ms)
FP32 : 249,6 GFLOPS  (8,6 ms)
Ratio BF16/FP32 : 1,54×

BF16 est 1,54× plus rapide que FP32. MMA est actif et fournit une accélération mesurable. Nos 13,9 tok/s sur un seul cœur POWER10 incluent déjà MMA. C’est le chiffre réel, accéléré par le matériel. Les capacités d’accélération IA de POWER10 et POWER11 sont au cœur de nos formations Linux sur IBM POWER Systems disponibles en français.

L’investigation oneDNN (et ce que nous avons appris)

Nous pensions initialement qu’il restait des performances inexploitées.

La build vLLM intègre oneDNN (initialement d’Intel). À l’intérieur, il existe deux chemins mathématiques spécifiques à POWER :

  • GEMM int8 : Un noyau écrit à la main par des ingénieurs IBM utilisant les instructions MMA pour les modèles quantifiés.
  • GEMM BF16 : Un passage direct à OpenBLAS — mais seulement quand compilé avec des flags spécifiques.

Notre build initiale n’avait pas ces flags. Nous avons recompilé avec -DDNNL_BLAS_VENDOR=OPENBLAS, confirmé que les flags étaient actifs, re-benchmarké — mêmes performances.

Pourquoi ? PyTorch allait déjà directement à OpenBLAS, contournant oneDNN pour les opérations matriciales principales. L’optimisation était déjà là ; nous ne le savions simplement pas.

Conclusion pratique : Vous n’avez rien de spécial à configurer. PyTorch sur POWER10 et POWER11 avec OpenBLAS utilise automatiquement MMA pour l’inférence BF16. Installez le paquet et exécutez.

Et IBM Spyre ?

IBM Spyre est une carte accélératrice IA dédiée pour POWER — un matériel entièrement séparé avec son propre silicium pour les calculs IA. La distinction clé :

  • MMA = accélération intégrée dans chaque cœur POWER10 et POWER11 (active dès maintenant dans nos benchmarks)
  • Spyre = carte accélératrice IA séparée ajoutée au système (prometteuse, mais nécessite des piles logicielles IBM spécifiques)

Notre travail se concentre sur ce qui est disponible aujourd’hui en utilisant le CPU déjà dans votre machine, sans investissement matériel supplémentaire.

Le tableau complet

TechnologieCe que c’estActive dans notre build ?
POWER10/11 MMA (BF16)Accélérateur matriciel intégré dans le CPUOui — PyTorch → OpenBLAS
POWER10/11 MMA (int8)Même matériel, pour les modèles 8 bitsCompilé, pas encore bout en bout
IBM SpyreCarte accélératrice IA séparéeNon — matériel différent
OpenShift AIPlateforme ML complète sur KubernetesNon — nous sommes l’alternative légère
oneDNNBibliothèque mathématique intégrée à vLLMCompilée, contournée par PyTorch
OpenBLASBibliothèque mathématique avec noyaux POWER10/11 écrits à la mainOui — le vrai moteur

Contexte

Vue d’ensemble : inférence LLM sur IBM POWER sans OpenShift

Red Hat OpenShift AI

Jusqu’ici, la proposition officielle d’IBM/Red Hat pour l’inférence LLM sur IBM POWER était OpenShift AI. Il supporte les notebooks, pipelines, entraînement de modèles, serving et monitoring. Depuis la version 3.0, il tourne sur ppc64le avec des charges de travail CPU uniquement.

OpenShift AI est le bon choix pour les organisations qui ont déjà des clusters OpenShift. Il vient avec RBAC, InstructLab pour le fine-tuning de modèles et un support enterprise.

Mais il requiert OpenShift. Un cluster Kubernetes, un abonnement Red Hat, la gestion des opérateurs. Pour beaucoup d’environnements POWER — notamment ceux qui tournent sous Linux standalone ou des environnements mixtes AIX/Linux — c’est un engagement significatif juste pour servir un modèle. Ces organisations font justement appel au service de maintenance et support IBM POWER de SIXE pour maintenir leur infrastructure opérationnelle.

Ce qu’apporte LibrePower

Nous ne remplaçons pas OpenShift AI. Nous le complétons avec un chemin plus léger pour les nombreux environnements POWER qui n’ont pas besoin de la plateforme complète.

OpenShift AILibrePower vLLM
InstallationCluster OpenShift + opérateursapt install python3-vllm
InfrastructureKubernetes obligatoireN’importe quel Ubuntu/Debian ppc64le
PérimètreCycle ML completInférence uniquement
SupportAbonnement Red HatCommunauté (open source)
GPUSupporté (x86)CPU uniquement (POWER natif)
Temps jusqu’à la première inférenceHeures ou joursMinutes
CoûtLicences OpenShiftGratuit

IBM construit l’autoroute — matériel de premier plan, wheels PyTorch, OpenShift AI, InstructLab. LibrePower ajoute une bretelle d’accès pour ceux qui n’ont pas besoin de la plateforme complète. La feuille de route IA d’IBM POWER avance rapidement, et les outils communautaires comme celui-ci comblent des lacunes réelles dans l’écosystème actuel. Pour une vue d’ensemble de l’évolution de POWER avec Power10 et Power11, consultez notre article sur les nouveaux serveurs IBM Power10.

L’infrastructure

Fonctionnement du dépôt de paquets LibrePower

Nous avons construit librepower.org en suivant le même modèle que notre dépôt de paquets AIX — une infrastructure qui distribue déjà plus de 30 paquets open source à des systèmes AIX dans le monde entier.

linux.librepower.org/
  dists/jammy/
    InRelease          (signé avec GPG)
    Release
    main/binary-ppc64el/
      Packages
  pool/main/
    python3-vllm_0.9.2-1_ppc64el.deb
  install.sh

Le CI/CD tourne sur GitLab : chaque push régénère les métadonnées APT et déploie automatiquement. Tous les paquets compilés sur du vrai matériel IBM POWER — pas de compilation croisée, pas d’émulation. Le code source complet est sur GitLab sous licence Apache 2.0.

Feuille de route

La suite pour vLLM sur IBM POWER

  • Plus de modèles testés — Llama, Mistral, Phi, Granite. Benchmarks systématiques par famille de modèles.
  • llama.cpp pour ppc64le — Modèles GGUF quantifiés pour une empreinte mémoire encore plus faible. Déjà disponible pour AIX.
  • Support Ubuntu 24.04 et Debian 12 — Extension du paquet aux dernières versions LTS.
  • Variantes optimisées pour POWER10/11 — Approfondissement du tuning MMA. Nos 13,9 tok/s par cœur actuels sont un point de départ, pas un plafond.
  • GEMM int8 bout en bout — Finalisation de la voie MMA pour les modèles quantifiés, ce qui devrait améliorer le débit.
Vous avez un IBM POWER et souhaitez déployer de l’IA ?
SIXE accompagne les organisations dans le déploiement et l’exploitation de Linux sur IBM POWER — de la formation officielle IBM en français au support d’infrastructure complet, en passant par Paris, Bruxelles et Luxembourg. Si vous évaluez l’inférence LLM sur du matériel POWER existant, parlez-nous de votre projet.

Vous avez un système ppc64le ?

Essayez vLLM sur IBM POWER dès maintenant

Si vous avez un système sous Ubuntu, c’est trois commandes. Le code source est sur GitLab si vous souhaitez approfondir ou contribuer. Formation et support infrastructure IBM POWER par SIXE.

# Ajouter le dépôt LibrePower
curl -fsSL https://linux.librepower.org/install.sh | sudo sh

# Installer vLLM pour ppc64le
sudo apt update && sudo apt install python3-vllm

# Installer PyTorch (wheels IBM)
pip3 install torch --extra-index-url \
  https://wheels.developerfirst.ibm.com/ppc64le/linux

# Lancer le serveur d'inférence compatible OpenAI
python3 -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2.5-0.5B-Instruct \
    --device cpu --dtype bfloat16 --port 8000

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


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 202620 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.

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

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 202625 min de lecturePour 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 ».

ProjetAnnéeChangementConséquenceGouvernance
MongoDB2018AGPL → SSPLRetiré de Debian/Red HatSingle vendor
Elasticsearch2021Apache 2.0 → SSPLFork : OpenSearch (Linux Foundation)Single vendor
HashiCorp2023MPL 2.0 → BSLFork : OpenTofu · IBM : 6,4 Mds $Single vendor
Redis2024BSD → SSPLFork : Valkey (Linux Foundation)Single vendor
MinIO2021–26Apache → AGPL → AbandonnéDépôt : « NO LONGER MAINTAINED »Single vendor
KubernetesApache 2.0 stableFondation (CNCF)
PostgreSQLLicence PostgreSQL stableCommunauté
LinuxGPLv2 stableFondation (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.

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

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écificationValeur
ServeurIBM Power System S924
ProcesseurIBM POWER9 @ 2.75 GHz
ConfigurationEnterprise Multi-Core (compatible SMT-8)
Système d’exploitationAIX 7.3 TL4
ArchitectureBig-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

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 5600FlashSystem 7600FlashSystem 9600
Format1U · 12 disques2U · 32 disques2U · 32 disques (avant 4U)
CPU2×12 cœurs Intel Xeon · PCIe Gen 42×16 cœurs AMD EPYC · PCIe Gen 52×48 cœurs AMD EPYC · PCIe Gen 5
Capacité brute633 To1,68 Po3,37 Po (vs 1,8 Po du 9500)
Capacité utilisable400 Tou1,2 Pou2,4 Pou
Capacité effectiveJusqu’à 2,4 PoeJusqu’à 7,2 PoeJusqu’à 11,8 Poe
IOPS2,6 millions4,3 millions6,3 millions
Débit lecture30 Go/s55 Go/s86 Go/s (vs 100 Go/s du 9500)
Ports16× FC ou 20× Ethernet32× FC ou Ethernet32× FC ou Ethernet (vs 48 du 9500)
Cas d’usageEdge, sites distants, petits DCVirtualisation, analytiqueBanque, 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 :

AspectIBM FlashSystem (nouveau)Pure Storage FlashArrayDell PowerStoreNetApp AFF
Unités propriétaires✅ FlashCore Module (QLC→TLC)✅ DirectFlash (150 To)❌ SSD standard❌ SSD standard
IA de gestionFlashSystem.ai (agentique)Pure1 MetaCloudIQBlueXP / AIOps
Détection ransomware HW✅ Sur l’unité flash❌ Logiciel❌ Logiciel❌ Logiciel (ONTAP)
Support baies tierces✅ +500 fabricants❌ Écosystème ferméPartielPartiel (FabricPool)
Chiffrement quantum-safe HW
Modèle de licenceTraditionnel IBMEvergreen (très transparent)APEX / traditionnelKeystone / 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 unité flash propriétaire pour nouveau IBM FlashSystem avec détection ransomware matérielle

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.

SIXE