Inspections NIS2 en 2026 : ce que vérifient les auditeurs

Conformité · Cybersécurité · Directive UE

Inspections NIS2 en 2026 : ce que les auditeurs vérifient réellement.

Les autorités compétentes commencent à exercer leurs pouvoirs de supervision prévus par NIS2, à mesure que les États membres finalisent leur cadre national. La conversation est passée de « sommes-nous concernés ? » à « pouvons-nous montrer des preuves ? ». Ce guide opérationnel reprend ce que nous voyons sur le terrain : ce que l'autorité demande en premier, les documents à garder prêts et les pièges qui déclenchent un audit approfondi.

8 min de lectureGuide opérationnel

NIS2 n'est plus un exercice de planification — c'est un régime d'inspection. La Directive (UE) 2022/2555 est entrée en vigueur en janvier 2023 et la date limite de transposition était le 17 octobre 2024 ; le cadre de supervision décrit aux articles 31–33 est devenu applicable dans chaque État membre via les mesures nationales de transposition. Ce qui passait pour « nous préparons » en 2024 doit désormais devenir « voici les preuves » en 2026.

Ce n'est ni un article juridique (je ne suis pas juriste et ne joue pas à l'être) ni une pièce de marketing par la peur. C'est la check-list opérationnelle que nous parcourons avec nos clients lorsqu'ils ont reçu une notification de leur autorité — ou qu'ils veulent simplement être audit-ready avant qu'elle n'arrive. Si vous cherchez plutôt le panorama « qu'est-ce que NIS2 et comment Wazuh y répond », notre article Conformité NIS2 avec Wazuh couvre ce terrain. Celui-ci porte sur la visite elle-même.

En 30 secondes

Une inspection NIS2 se concentre sur les preuves, pas sur l'intention. Attendez-vous à ce que l'autorité compétente demande : (1) la politique de sécurité approuvée par l'organe de direction (art. 20), (2) l'analyse de risques, (3) l'inventaire des actifs et fournisseurs, (4) la télémétrie SIEM et la chronologie d'un incident réel montrant les étapes 24h / 72h / 1 mois (art. 23), et (5) les preuves de formation des dirigeants. Documents non datés, MFA absente sur les accès privilégiés ou notifications hors délais : voilà les signaux d'alarme qui déclenchent un audit approfondi.

10
Domaines de mesures
article 21(2)
24 / 72 h
Notification d'incident
article 23
Jusqu'à 10 M€ / 2 %
Amende admin. max.
entités essentielles
(art. 34 + transposition nat.)
01 · Le tournant 2026

De la préparation à la preuve

2024, c'était le cadrage. 2025, la construction. 2026, c'est la démonstration. Une fois les lois nationales de transposition entrées en vigueur, le régime de supervision décrit aux articles 31 à 33 de NIS2 est devenu opérationnel. Les autorités compétentes peuvent désormais demander des informations, effectuer des inspections sur site et appliquer les mesures administratives de l'article 32 — y compris, en cas grave pour les entités essentielles, l'interdiction temporaire pour une personne physique d'exercer des fonctions de direction (art. 32.5).

La bonne nouvelle : les critères n'ont pas changé. L'article 21 reste l'article 21. La moins bonne : on ne répond plus « nous mettons en œuvre » avec un sourire. Les inspecteurs veulent des artefacts documentés, datés et versionnés.

Pour la France

L'ANSSI a publié le 17 mars 2026 le Référentiel Cyber France (ReCyF), qui regroupe les mesures recommandées pour atteindre les objectifs de sécurité fixés par NIS2. Il n'est pas obligatoire au départ, mais les entités qui choisissent de l'appliquer pourront s'en prévaloir lors d'un contrôle de l'ANSSI. L'ANSSI met également à disposition MonEspaceNIS2, un simulateur pour déterminer si une entité est concernée.

L'article 21(2) en un coup d'œil

Pour mémoire, les dix domaines de mesures minimales exigés par la directive (formulation courte) : analyse des risques et politiques de sécurité · gestion des incidents · continuité d'activité (sauvegardes, reprise, gestion de crise) · sécurité de la chaîne d'approvisionnement · sécurité dans l'acquisition, le développement et la maintenance des SI (y compris gestion des vulnérabilités) · politiques d'évaluation de l'efficacité des mesures · pratiques de cyberhygiène et formation · cryptographie et, le cas échéant, chiffrement · sécurité des RH, contrôle d'accès et gestion des actifs · authentification multifactorielle ou continue et communications sécurisées.

02 · Qui vous supervise

Identifier votre autorité compétente

L'article 8 impose à chaque État membre de désigner une ou plusieurs autorités compétentes pour la supervision NIS2. En pratique, le modèle varie : certains pays disposent d'une agence unique pour tous les secteurs, d'autres répartissent la supervision entre l'agence nationale de cybersécurité, le régulateur financier, le régulateur de l'énergie, etc. En France, l'ANSSI est l'autorité nationale chargée de la cybersécurité et joue un rôle central dans le dispositif NIS2 ; en Belgique, le CCB (Centre pour la Cybersécurité Belgique) tient ce rôle. Les entités bancaires et de marchés financiers croisent aussi DORA (Règlement (UE) 2022/2554), qui prévaut en général comme lex specialis pour ce qu'il couvre.

Avant toute chose : confirmez qui vous supervise et par quel canal. La plupart des autorités ont publié un portail d'entrée — trouvez-le maintenant, pas le jour où l'e-mail arrive.

03 · Les cinq premières demandes

Les cinq vérifications prioritaires d'un inspecteur

Si les pratiques de supervision varient selon l'État membre et le secteur, voici les artefacts les plus fréquemment demandés lors des revues de readiness et des audits réglementaires — et ceux qui, d'expérience, allègent considérablement la conversation pour la suite lorsqu'ils sont en ordre.

#
Ce qui est demandé
Ce qui constitue une « bonne » preuve
01
Politique de sécurité approuvée par l'organe de direction
Document daté, signature au niveau du conseil, procès-verbal référençant l'approbation. Mention explicite des domaines de l'article 21(2).
02
Analyse de risques et plan de traitement
Méthodologie déclarée (ISO 27005, NIST 800-30, etc.), récente (12 derniers mois), risque résiduel accepté par écrit par la personne responsable.
03
Inventaire des actifs et des fournisseurs
Liste des actifs avec criticité ; liste des fournisseurs avec marquage des prestataires TIC critiques et clauses NIS2 (notification, droit d'audit, plan de sortie).
04
Procédure de réponse aux incidents + chronologie réelle
Procédure documentée et post-mortem anonymisé d'un incident récent montrant les étapes 24h / 72h / 1 mois avec horodatages du SIEM.
05
Preuves de formation des dirigeants (art. 20.2)
Feuilles de présence des formations cyber suivies par l'organe de direction dans les 12 derniers mois, avec contenu et prestataire.
04 · Le déroulé

Comment se déroule concrètement une inspection NIS2 ?

Les modalités précises varient selon l'État membre et l'autorité compétente, mais le schéma général d'une mission de supervision est assez stable. En six étapes — de la notification initiale au rapport final — voici ce à quoi vous attendre.

#
Étape
Ce qui se passe
01
Notification de l'autorité
Courrier officiel précisant la portée du contrôle, l'autorité responsable, l'agent désigné et le dossier documentaire initial demandé. Délais de réponse explicitement indiqués.
02
Demande documentaire
Envoi du dossier audit-ready (voir §06) via le canal sécurisé indiqué. Tout doit être daté, versionné et signé là où requis. Pas d'envoi par messagerie personnelle.
03
Analyse préliminaire
L'autorité examine le dossier et peut formuler des questions écrites complémentaires. Phase typiquement de deux à six semaines selon la charge et la complexité.
04
Entretien avec les responsables
Audition du RSSI / DSI et, selon les cas, d'un membre de l'organe de direction. Objectif : valider la cohérence entre les preuves documentaires et la pratique opérationnelle.
05
Contrôle sur site (le cas échéant)
Visite des installations, démonstrations techniques (SIEM, MFA, sauvegardes), revue des journaux d'audit, vérification d'échantillons d'incidents. Pas systématique mais fréquent pour les entités essentielles.
06
Rapport et actions correctives
Rapport écrit avec constats, écarts identifiés et plan d'actions correctives avec délais. Possibles mesures administratives de l'article 32 en cas de manquement grave.
À retenir

Le scénario complet n'est pas systématique. Pour les entités importantes, le contrôle peut se limiter aux étapes 1 à 3 si le dossier documentaire est solide. Pour les entités essentielles, les étapes 4 et 5 sont nettement plus probables. Dans tous les cas, l'autorité dispose du pouvoir d'effectuer des contrôles inopinés (art. 32).

05 · L'horloge

La chronologie 24 / 72 / 1 que vous devrez démontrer

L'article 23 fixe trois étapes de notification pour un incident significatif. Les inspecteurs ne demandent pas seulement si la procédure existe — ils demandent une chronologie réelle : quand l'incident a été détecté, quand l'alerte précoce a été déposée, quand la notification a été déposée, et comment vous y êtes arrivé. Sans télémétrie centralisée, cette chronologie est introuvable. Les délais exacts et le format de notification peuvent être précisés par la législation nationale de transposition ou par l'autorité compétente.

Notification d'incident significatif · article 23
24 h
Alerte précoce
Indication d'une éventuelle origine malveillante ou d'un impact transfrontalier.
72 h
Notification
Évaluation initiale, sévérité, IoC et mesures de mitigation déjà prises.
1 mois
Rapport final
Cause racine, actions correctives et impact transfrontalier le cas échéant.
La pièce qui tient NIS2 debout

La détection sans analystes, c'est du théâtre. Nous combinons typiquement le déploiement de Wazuh (SIEM/XDR open source avec tableaux de bord mappés NIS2, zéro coût de licence) et un support d'urgence 24/7 assuré en français, anglais et espagnol — c'est cette combinaison qui soutient matériellement les délais de l'article 23. Si vous avez besoin d'une plateforme SIEM commerciale avec intégrations avancées, nous déployons aussi IBM QRadar.

06 · Le dossier

Le dossier « audit-ready »

À ranger dans un dépôt unique et contrôlé — pas dans la messagerie personnelle d'un collaborateur. Daté, versionné, propriétaire assigné.

01

Politique de sécurité de l'information (approuvée par le conseil)

02

Analyse de risques et plan de traitement

03

Inventaire des actifs avec criticité

04

Registre des fournisseurs TIC critiques + clauses NIS2

05

Procédure de réponse aux incidents + runbooks

06

Plans de continuité et de reprise (PCA/PRA)

07

Stratégie de sauvegarde + dernier test de restauration

08

Politique de gestion des vulnérabilités et rapports

09

Preuves d'application de la MFA sur les accès privilégiés

10

Registres de formation des dirigeants (art. 20.2)

11

Notifications d'incidents récentes déposées

12

Dernier rapport d'audit interne ou externe

Mappé sur les domaines de mesures de l'article 21(2) de la Directive (UE) 2022/2555.

07 · Vérification rapide

Êtes-vous prêt pour une inspection ? Trois questions

Un auto-diagnostic rapide basé sur les trois points où nous voyons le plus souvent les organisations trébucher lors d'une revue pré-audit. C'est indicatif, pas une évaluation formelle.

Êtes-vous prêt pour une inspection ?

3 questions · résultat instantané · aucun tracking

1. Votre organe de direction a-t-il formellement approuvé la politique de sécurité de l'information dans les 12 derniers mois — avec un PV ou une attestation au dossier ?

2. Si un incident significatif survenait aujourd'hui, pourriez-vous produire une chronologie SIEM avec horodatages pour les étapes 24h / 72h / 1 mois ?

3. La MFA est-elle appliquée sur tous les accès privilégiés et distants, avec preuves dans vos journaux IAM ou SSO ?

Vous semblez audit-ready sur l'essentiel.

Les trois points que les inspecteurs vérifient en premier sont en ordre. Prochaine étape utile : exercices de simulation, revue des clauses fournisseurs et affinage des modèles de chronologie d'incident.

→ Échanger avec SIXE sur un exercice de simulation

Des écarts visibles à combler avant une inspection.

Les éléments sont là mais pas au niveau « audit-ready ». Un sprint focalisé de deux mois — formaliser l'approbation de la politique, répéter la chronologie d'incident et compléter la couverture MFA — suffit habituellement.

→ Voir comment Wazuh comble la lacune SIEM

Risque matériel en cas d'inspection aujourd'hui.

Approbation conseil manquante, pas de chronologie SIEM et MFA partielle : c'est exactement la combinaison qui déclenche un audit approfondi. À prioriser absolument avant tout le reste — les autres artefacts comptent peu si la base n'est pas là.

→ Demander une évaluation de préparation NIS2

08 · Comment nous aidons

Ce que SIXE met sur la table

Être audit-ready pour NIS2, c'est de l'instrumentation disciplinée et de l'opérationnel documenté. Chacun des sept piliers ci-dessous est associé à une brique concrète que nous déployons en mission :

  1. Évaluation des écarts contre l'article 21 — cartographie des contrôles existants (ISO 27001, NIST CSF, ReCyF en France) et production des artefacts audit-ready.
  2. Gouvernance et formation des dirigeants — formulation du PV d'approbation par le conseil, contenu de formation pour l'organe de direction (preuves art. 20.2).
  3. SIEM / XDR. Le déploiement de Wazuh avec tableaux de bord mappés NIS2 est notre choix par défaut — open source, zéro coût de licence. Pour une plateforme commerciale d'entreprise avec intégrations profondes, nous déployons aussi IBM QRadar.
  4. Réponse aux incidents 24/7. La détection sans analystes ne tient pas le délai de 24h. Support d'urgence 24/7 en français, anglais et espagnol — sans intermédiaires.
  5. Application de la MFA. Particulièrement délicate sur les environnements IBM Power — PowerSC pour AIX et IBM i couvre cette couche avec intégration de la conformité.
  6. Registre des fournisseurs et clauses contractuelles. Inventaire des prestataires TIC critiques et clauses alignées NIS2 — la mesure 4 (chaîne d'approvisionnement) est celle où la majorité des équipes décrochent.
  7. Exercices de simulation et répétition de chronologie d'incident. La première fois où vous reconstruisez une chronologie 24h / 72h ne devrait pas être pendant un incident réel.

Pour les secteurs industriels (énergie, eau, transport, fabrication, environnements OT), une couche supplémentaire qui n'apparaît pas dans les référentiels ISO génériques : la visibilité OT. Nous utilisons Claroty pour la supervision réseau OT et l'audit des dispositifs industriels avec Tenable.

FAQ

Questions rapides

Qui est mon autorité compétente sous NIS2 ?

Chaque État membre désigne une ou plusieurs autorités compétentes par secteur (article 8). En France, l'ANSSI est l'autorité nationale chargée de la cybersécurité et joue un rôle central dans le dispositif NIS2 ; elle a publié MonEspaceNIS2 pour aider à déterminer l'éligibilité. En Belgique, c'est le CCB (Centre pour la Cybersécurité Belgique). Vérifiez la loi nationale de transposition de votre pays ou le site du CSIRT national. ENISA publie également des informations consolidées sur les autorités et points de contact nationaux.

Comment commence une inspection NIS2 ?

Pour les entités essentielles, la supervision est proactive (art. 32) : l'autorité peut déclencher une inspection sans indice préalable de non-conformité. Pour les entités importantes, la supervision est réactive (art. 33), généralement déclenchée par un signalement d'incident ou une plainte. Dans les deux cas, l'autorité envoie une notification écrite, demande un dossier initial et peut planifier des visites sur site.

Quels documents préparer avant une inspection ?

Au minimum : politique de sécurité approuvée par l'organe de direction, analyse de risques, inventaire des actifs et des fournisseurs, procédures de gestion d'incident, plans PCA/PRA, preuves de formation des dirigeants, registres d'incidents récents et leurs notifications, dernier rapport d'audit. Tout daté, versionné et signé là où c'est requis.

L'inspecteur demande-t-il des preuves du SIEM ?

Oui. Attendez-vous à des demandes sur : liste des actifs supervisés, échantillons d'alertes et leur traitement, configuration de rétention des journaux, intégrité des pistes d'audit, tableaux de bord mappés aux contrôles NIS2, et la chronologie d'un incident réel montrant les étapes 24h/72h de l'article 23. Wazuh couvre cela avec des tableaux de bord alignés NIS2.

Quels sont les signaux d'alarme déclenchant un audit approfondi ?

Pas de cadre documenté de gestion des risques. Organe de direction qui n'a pas formellement approuvé la politique (violation directe de l'art. 20). Pas de MFA sur les accès privilégiés. Notifications d'incident hors délai 24h/72h. Aucun exercice d'incident dans les 12 derniers mois. Inventaire des fournisseurs sans les prestataires TIC critiques. Preuves d'audit dans une messagerie personnelle.

ISO 27001 suffit-il pour passer une inspection NIS2 ?

ISO 27001 est une base solide — la plupart des mesures de l'article 21 sont couvertes — mais ce n'est pas une équivalence automatique. Il faut mapper les contrôles existants à l'art. 21, documenter les écarts (typiquement notification 24h/72h, clauses chaîne d'approvisionnement, formation des dirigeants) et produire des preuves audit-ready pour chacun.


Préparation à l'inspection NIS2

Évaluez votre niveau de préparation avant un contrôle NIS2

De la revue de préparation contre l'article 21, aux preuves SIEM qui tiennent les délais 24/72h, à une équipe joignable 24/7 quand quelque chose lâche à trois heures du matin. Plus de 15 ans en cybersécurité d'infrastructures critiques, IBM Business Partner, suivi en français, anglais et espagnol — sans intermédiaires.

Open source sur IBM Power : cette enquête est pour vous

Communauté · Open Source · IBM Power

LibrePower 2026 : l'enquête annuelle sur l'open source dans IBM Power.

AIX, IBM i, Linux on Power, ppc64le. 12 à 20 minutes de votre expérience deviennent un rapport public annuel qui aide à comprendre, avec des chiffres réels, l'état de l'écosystème. Chez SIXE, nous relayons l'enquête pour qu'elle touche davantage de professionnels.

5 min de lectureEnquête ouverte
Affiche de l'enquête annuelle LibrePower 2026 sur l'open source dans IBM Power
Enquête ouverte sur librepower.org/annual-survey

LibrePower vient d'ouvrir son enquête annuelle sur l'état de l'open source dans IBM Power, et elle est ouverte à toute personne qui travaille avec la plateforme — administrateurs AIX ou IBM i, équipes Linux on Power, développeurs ppc64le, architectes, avant-ventes, ISV, IBM Champions et Business Partners. Le résultat est un rapport public annuel qui dresse une photographie utile et agrégée de ce qui fonctionne, de ce qui coince, et des priorités vues par la communauté.

« Si IBM Power apparaît quelque part dans votre travail, cette enquête est pour vous. »
— LibrePower 2026

Qu'est-ce que LibrePower et pourquoi participer ?

LibrePower est un projet indépendant centré sur l'écosystème open source d'IBM Power. Sa production principale est un rapport public publié une fois par an, qui montre l'état de la plateforme vu par celles et ceux qui l'opèrent et la construisent au quotidien : l'admin AIX qui maintient les paquets du Toolbox, l'équipe IBM i qui intègre les outils modernes, l'ingénieur qui prépare des wheels Python pour ppc64le, l'architecte qui évalue une nouvelle charge sur Power.

Entre les enquêtes, LibrePower publie une newsletter technique sur Substack — benchmarks, notes de portage ppc64le, entretiens avec des IBM Champions. Elle vient compléter les canaux officiels et les blogs des éditeurs, en apportant un regard supplémentaire issu de la communauté technique.

Pourquoi c'est utile

Un rapport basé sur les réponses réelles de la communauté apporte du contexte utile à tout le monde : aux personnes qui utilisent la plateforme, à celles qui la construisent et à celles qui décident des priorités. Plus l'échantillon est varié, plus le résultat est représentatif.

Vous êtes du public visé ? Très probablement

L'enquête s'adapte à votre profil : vous ne voyez que les questions qui ont du sens pour votre plateforme. Si vous travaillez avec IBM i, les questions AIX n'apparaissent jamais. Si vous faites du Linux on Power, on ne vous interroge pas sur VIOS. Et si votre seul contact avec la plateforme est de suivre l'écosystème de loin, un parcours est prévu pour vous aussi.

Elle est conçue pour couvrir tout le spectre :

  • Exploitation — administrateurs L1, L2, L3 sur AIX, IBM i, VIOS et Linux on Power. Celles et ceux qui sont en première ligne quand la production bouge.
  • Développement et plateforme — développeurs ppc64le, équipes DevOps/SRE, mainteneurs open source, ingénieurs qui portent des stacks vers Power.
  • Architecture et avant-ventes — qui décide entre Power et les autres plateformes, conçoit des migrations, accompagne les clients dans leurs choix techniques.
  • ISV, IBM Business Partners et collaborateurs IBM — la voix de ceux qui construisent et vendent sur la plateforme compte autant que celle des consommateurs.
Ce qu'on va vous demander

Les domaines couverts par LibrePower 2026

L'enquête se divise en blocs thématiques. Vous ne verrez que ceux qui correspondent à votre profil, donc votre parcours réel est plus court que la liste complète :

Structure de l'enquête
01
Vous et votre plateformeRôle, environnements que vous gérez, charges (Oracle, Db2, SAP, HANA, Java, conteneurs, IA, HA/DR, modernisation…). Définit le reste du parcours.
02
Votre vision depuis le terrainMaturité de l'open source sur Power, recommandation (NPS 0–10), communauté, recrutement des compétences, usages réels en production.
03
Ouverture par coucheDe l'ISA au firmware, en passant par la documentation, les distributions, les conteneurs et l'intégration continue. Une matrice qui mesure le degré d'ouverture réel de chaque couche que vous touchez.
04
Réalité d'AIX, IBM i et Linux on PowerTrois blocs spécifiques — vous ne voyez que le vôtre. AIX Toolbox et dnf, RPM sur IBM i via ACS, écosystème ppc64le sur Linux, conteneurs et CI.
05
Confiance dans chaque acteurIBM, Red Hat, SUSE, Canonical, mainteneurs indépendants, ISV, Business Partners. Vous évaluez uniquement ceux pour lesquels vous avez une base de jugement.
06
Priorités et participationCe sur quoi LibrePower devrait travailler en priorité dans les 12 prochains mois, le paquet ou runtime n°1 à débloquer, et comment rejoindre le projet si vous le souhaitez.

Pourquoi nous relayons l'initiative depuis SIXE

En tant qu'IBM Business Partner spécialisé en open source, Linux on Power, AIX, IBM i et plus largement la plateforme Power, nous avons vu ces dernières années la part open source grandir dans tout l'écosystème — des dépôts officiels jusqu'aux outils modernes qui arrivent sur IBM i, en passant par l'évolution de ppc64le sur Linux. Ce que nous constatons en conseil et en formation vient compléter ce qui est publié dans les canaux officiels : cas concrets, décisions réelles, questions qui apparaissent dans les projets.

Nous relayons donc cette enquête : plus l'échantillon est varié, plus le rapport est utile — et puisqu'on y est, nous tenons aussi à ce que les voix francophones et européennes y soient bien représentées.

Pour voir le type de travail que nous publions sur ces sujets : nous avons installé et testé AIX 7.3, présenté les nouveautés d'IBM i 7.6, et comparé les alternatives à ESXi (PowerVM, Proxmox, OCP). Nous proposons aussi des formations officielles AIX et un support et conseil sur Power, AIX, IBM i et Linux on Power.

Trois questions rapides avant de commencer

Est-ce que l'enquête est en français ?

Pour l'instant, elle est uniquement en anglais. Si c'est un frein pour vous, il y a un champ libre à la fin (« y a-t-il quelque chose que nous aurions dû demander ? ») où vous pouvez le signaler — c'est exactement le genre de retour qui fait évoluer la prochaine édition.

Et si je n'ai pas d'expérience sur un point précis ?

Presque toutes les questions proposent une option « N/A » ou « je ne sais pas ». L'enquête est conçue pour que vous ne donniez un avis que lorsque vous avez de quoi en émettre un — c'est précisément ce qui donne sa crédibilité au rapport.

Puis-je partager le lien avec mon équipe ?

Oui, avec plaisir. L'adresse est librepower.org/annual-survey. Plus les profils qui répondent sont variés, plus le rapport est utile.


15 minutes · Rapport directement dans votre boîte

Répondez à l'enquête annuelle LibrePower

AIX, IBM i, Linux on Power, ppc64le. Si vous travaillez avec la plateforme à n'importe quelle couche, votre expérience rend le rapport meilleur. Indépendante, anonyme par défaut, accessible à toute la communauté.

Ceph en 2026 : Nouveautés, Versions et Feuille de Route

Stockage · Ceph · Open Source

Ceph 2026 : versions, roadmap et déploiement en production.

Squid est la version stable. Tentacle arrive. Et les décisions que vous prendrez cette année sur votre architecture de stockage distribué définiront votre infrastructure pour les cinq prochaines années. Voici tout ce qu'il faut savoir — sans discours commercial, que de l'ingénierie.

10 min de lectureGuide technique

Ceph est la plateforme de stockage distribué open source la plus mature et la plus déployée, fournissant du stockage bloc, objet et fichiers depuis un seul cluster, sans aucun point unique de défaillance. Il est utilisé en production par des organisations gérant des pétaoctets de données — des laboratoires de recherche aux fournisseurs cloud. Avec Tentacle (v20) désormais publiée et Squid (v19) largement déployée, 2026 est le bon moment pour comprendre où en est Ceph et où il va.

Chez SIXE, nous déployons et assurons le support d'infrastructures Ceph en production depuis des années. Cette page est la référence que nous aurions aimé avoir quand nous avons commencé : releases actuelles, fonctionnalités réelles, bonnes pratiques honnêtes et zéro baratin.

v20
Dernière release
(Tentacle)
3 en 1
Bloc + Objet + Fichiers
dans un seul cluster
0
Point unique
de défaillance
01 · Contexte

Qu'est-ce que Ceph ?

Ceph est une plateforme de stockage distribué open source qui unifie le stockage objet, bloc et fichiers dans un seul cluster. Créé par Sage Weil dans le cadre de son doctorat à UC Santa Cruz, il est aujourd'hui maintenu par une communauté mondiale et commercialement supporté par IBM (IBM Storage Ceph) et Red Hat (OpenShift Data Foundation).

Ce qui distingue Ceph du stockage traditionnel, c'est son algorithme CRUSH : les données sont distribuées sur du matériel standard sans serveur central de métadonnées, de sorte que le cluster peut s'auto-réparer lorsqu'un disque ou un nœud tombe en panne. Pas d'appliance propriétaire, pas de verrouillage fournisseur, pas de point de défaillance caché attendant de gâcher votre trimestre.

Si vous évaluez des alternatives, notre comparaison Ceph vs Storage Scale (GPFS), NFS et GFS2 couvre les compromis. Pour le stockage objet, consultez Ceph vs MinIO.

En clair

Ceph se fiche du nombre de disques que vous avez et de leur emplacement. Vous ajoutez du matériel, Ceph redistribue les données. Vous perdez du matériel, Ceph reconstruit automatiquement. C'est toute la proposition de valeur, et elle est solide.

02 · Versions

Historique des versions de Ceph

Ceph suit un cycle prévisible avec des versions majeures tous les 12 à 18 mois, nommées alphabétiquement d'après des créatures marines :

ReleaseTentacle (20.x)Squid (19.x)Reef (18.x)
Publiée
Nov 2025
Mars 2024
Août 2023
Statut
Active / Recommandée
Active
Fin de vie
Moteur
Crimson en maturation
Crimson adoption précoce
OSD classique
Nouveauté clé
EC Crimson, tiering, MDS
Perf RGW + CephFS NFS
Mirroring RBD
Chemin de mise à jour
Cible actuelle
→ Tentacle
→ Squid → Tentacle

Quincy (17.x) a atteint sa fin de vie en 2025. Si vous y êtes encore, le chemin est Quincy → Reef → Squid → Tentacle. La documentation officielle d'upgrade détaille le processus étape par étape.

Recommandation

Ne sautez pas de version. Ceph ne supporte que les mises à jour séquentielles (Quincy → Reef → Squid). Planifier la migration avant la fin de vie de votre version coûte considérablement moins cher que de le faire dans l'urgence.

CHRONOLOGIE DES VERSIONS CEPH Reef18.x · 2023EOL Squid19.x · 2024Active Tentacle20.x · Nov 2025Recommandée U21.x · ~2027 → upgrade →→ upgrade →
Chronologie des releases Ceph — mises à jour séquentielles uniquement. Chaque version majeure est supportée pendant environ 2 ans.
ARCHITECTURE UNIFIÉE DE STOCKAGE CEPH RADOS Reliable Autonomic Distributed Object Store RBD Stockage bloc RGW Stockage objet S3 CephFS Système de fichiers OSD · OSD · OSD · OSD · OSD · OSD · OSD · OSD · OSD · OSD Distribué sur matériel standard — aucun point de défaillance VMs · Kubernetes · BDD Sauvegardes · IA · Médias HPC · CI/CD · Partages
Ceph fournit du stockage bloc, objet et fichiers à travers un seul cluster RADOS. Chaque interface sert différentes charges de travail, toutes partageant la même infrastructure auto-réparable.
03 · Nouveautés

Ceph Squid (v19) : la release qui a consolidé Ceph

Squid représente une avancée significative en termes de performance et de maturité opérationnelle :

Crimson OSD : adoption précoce

Le Crimson OSD est une réécriture complète du daemon OSD classique utilisant le framework Seastar. Il remplace l'architecture multi-thread par un modèle shared-nothing, run-to-completion. Concrètement : latence significativement réduite sur les clusters NVMe, surtout pour les patterns d'I/O aléatoires petits typiques des bases de données et de la virtualisation. Crimson continue de mûrir au fil des releases — il est disponible pour adoption précoce dans certains scénarios, mais l'OSD classique reste le choix par défaut pour la plupart des déploiements en production.

Performance du RADOS Gateway

La couche de stockage objet S3 bénéficie d'uploads multipart plus rapides, d'un garbage collection amélioré et d'une consommation mémoire réduite sous charges PUT intensives.

CephFS + NFS-Ganesha

CephFS a amélioré le support des exports NFS via NFS-Ganesha, de meilleures performances de snapshots et des quotas plus granulaires. Consultez notre guide sur la haute disponibilité NFS avec Ceph et Ganesha.

Tableau de bord renouvelé

L'interface web de gestion a été rafraîchie, avec une meilleure intégration d'alertes Prometheus et de nouvelles pages pour le mirroring RBD et les sous-volumes CephFS.

04 · Dernière release

Ceph Tentacle (v20) : la nouvelle génération

Tentacle a été publiée le 18 novembre 2025 et constitue désormais la version recommandée pour les nouveaux déploiements. Ses améliorations principales par rapport à Squid :

  • Crimson pour les pools erasure-coded — étendant les gains de performance de Crimson au-delà des pools répliqués.
  • Tiering RADOS plus intelligent — meilleures politiques de placement pour les clusters hybrides NVMe + SSD + HDD.
  • Chiffrement RGW amélioré — gestion des clés plus granulaire au niveau bucket avec intégration KMS externe.
  • MDS à l'échelle — meilleures performances du serveur de métadonnées pour les clusters avec des milliards de fichiers.

Les notes de release complètes sont sur la page des releases Ceph. Suivez le développement sur le tracker du projet et la liste ceph-devel.

À retenir

Si Squid fonctionne bien en production, pas d'urgence à migrer vers Tentacle. Mais pour les nouveaux déploiements, Tentacle est le point de départ recommandé — vous bénéficiez de toutes les améliorations de Squid plus les nouveautés de Tentacle dès le premier jour.

05 · Kubernetes

Rook-Ceph : stockage pour clusters Kubernetes

Rook est l'opérateur diplômé de la CNCF qui déploie et gère Ceph nativement dans Kubernetes. Les releases récentes se concentrent sur la stabilité, un scaling plus fluide des OSD, de meilleurs défauts Helm pour la production et une intégration renforcée avec OpenShift Data Foundation.

SIXE propose des formations Ceph couvrant l'administration standalone et les déploiements Rook dans Kubernetes.

06 · Cas d'usage

Fonctionnalités et cas d'usage de Ceph

Un cluster, trois interfaces. C'est l'atout de Ceph — et il est réellement utile :

Trois interfaces, un cluster
RBD — Stockage blocDisques virtuels pour VMs (Proxmox, KVM, OpenStack) et PV Kubernetes. Thin provisioning, snapshots, clones et mirroring inter-sites pour le DR.
RGW — Stockage objet S3API REST compatible S3. Cibles de sauvegarde, datasets IA/ML, archives multimédia, lacs de données. Voir notre comparaison Ceph vs MinIO.
CephFS — Système de fichiers POSIXAccès fichiers partagé pour le HPC, les pipelines CI/CD et les plateformes de contenu. Multi-filesystem, quotas, sauvegardes par snapshots.
Cas émergent : infrastructure IAS3 pour la distribution de modèles/datasets + RBD pour les volumes GPU. Consultez notre analyse Storage Scale vs Ceph pour l'inférence IA.
Pourquoi c'est important

La plupart des solutions de stockage vous forcent à choisir : bloc OU objet OU fichiers. Ceph fait les trois depuis un seul pool de matériel. Moins de systèmes à opérer, moins de fournisseurs à gérer, et moins d'appels à 3h du matin pour la baie de stockage que vous aviez oubliée.

07 · Adoption

Qui utilise Ceph en production ?

Ceph n'est pas une expérience de laboratoire — il exécute des charges critiques à grande échelle. Les fournisseurs cloud l'utilisent pour l'infrastructure multi-tenant, les institutions de recherche pour des lacs de données à l'échelle du pétaoctet, et les entreprises pour du stockage unifié derrière Kubernetes et OpenStack. Le CERN, Bloomberg, Deutsche Telekom, DigitalOcean et OVHcloud comptent parmi les grands adoptants publiquement connus.

Les scénarios de déploiement les plus courants que nous observons chez SIXE :

  • Infrastructure cloud — stockage backend pour OpenStack ou Kubernetes, remplaçant les SAN propriétaires.
  • Pipelines IA/HPC — stockage objet S3 pour les datasets d'entraînement, bloc pour les nœuds de calcul GPU.
  • Sauvegarde et archivage — stockage objet avec erasure coding remplaçant les bandes ou appliances de déduplication propriétaires.
  • Partages d'entreprise — CephFS + NFS-Ganesha remplaçant le NAS traditionnel pour les partages départementaux.

Compatibilité des plateformes

PlateformeCompatibleIntégrationNotes
Kubernetes
Oui
Rook (CNCF)
CSI natif, PV dynamique
OpenShift
Oui
ODF / Rook
Support Red Hat
Proxmox
Oui
Intégré
RBD + CephFS natif
OpenStack
Oui
Cinder / Glance / Manila
Standard de facto
VMware
Oui
Gateway iSCSI
Non natif, via gateway
Nutanix
Partiel
iSCSI
Nutanix a son propre stockage
08 · Bonnes pratiques

Bonnes pratiques Ceph en 2026

Déployer Ceph n'est pas difficile. Le déployer correctement est ce qui fait la différence :

Dimensionnement matériel

  • OSD : NVMe dédiés pour la partition WAL/DB, même si les disques principaux sont des HDD. Ce seul changement peut doubler les performances d'écriture aléatoire.
  • Réseau : Minimum 10 Gbps pour le réseau public, 10 Gbps séparé pour le réseau cluster/réplication. Le réseau est presque toujours le goulot d'étranglement — pas le CPU, pas la mémoire.
  • Mémoire : Comptez 4 à 5 Go de RAM par daemon OSD. BlueStore sur NVMe peut nécessiter davantage.

Configuration

  • Réplication vs erasure coding : Réplication (3x) pour les charges sensibles à la latence (RBD, CephFS). Erasure coding pour le stockage massif (sauvegardes RGW, archives).
  • Carte CRUSH : Concevez-la pour refléter vos domaines de défaillance physiques (baie, rangée, datacenter). La config par défaut suppose que tous les OSD sont dans un même domaine de défaillance. Ce n'est jamais le cas.
  • Supervision : Ceph Dashboard + Prometheus + Grafana. Alertes pour les pannes OSD, seuils nearfull et slow ops.

Erreurs courantes

L'erreur Ceph la plus fréquente en production — could not connect to ceph cluster despite configured monitors — a une solution étonnamment simple la plupart du temps. Notre guide de dépannage Ceph la couvre pas à pas.

La règle d'or

Ne laissez jamais un cluster Ceph dépasser 85 % de capacité. Le rééquilibrage CRUSH devient de plus en plus pénible à mesure que vous approchez du plein. Vous ne remarquerez pas le problème progressivement — vous le remarquerez d'un coup. Planifiez l'extension avant d'en avoir besoin.

09 · Alternatives

Ceph vs le reste : comparaison rapide

Chaque solution de stockage a ses compromis. Voici un aperçu honnête — pas de critique, juste des outils différents pour des besoins différents :

CephMinIOIBM Storage Scale
Types de stockage
Bloc + Objet + Fichier
Objet seul
Fichier + Objet
Protocole
S3, NFS, iSCSI, RBD
S3
POSIX, NFS, S3
Complexité
Moyenne–Élevée
Faible
Élevée
Kubernetes natif
Rook (CNCF)
Operator
Driver CSI
Coût licence
Open source
Open source
Commercial
Idéal pour
Infrastructure unifiée
Charges S3 pures
HPC / IA à l'échelle

Besoin du détail complet ? Nos analyses approfondies : Ceph vs MinIO et Ceph vs Storage Scale (GPFS).

10 · Support expert

Besoin d'aide avec Ceph en production ?

Lire la documentation est une chose. Opérer un cluster Ceph sous SLA avec des données critiques est une autre affaire. SIXE est partenaire IBM avec une expérience directe de la conception, du déploiement et de l'exploitation d'infrastructures Ceph à travers l'Europe.

  • Conseil et déploiement — Conception d'architecture, dimensionnement matériel, optimisation CRUSH et durcissement pour la production.
  • Formation officielle Ceph — Administration standalone et déploiements Rook dans Kubernetes, avec travaux pratiques.
  • Support continu — Supervision, mises à jour, résolution d'incidents. Ingénieurs senior, sans helpdesks.
De l'ingénierie, pas du support

Nous sommes l'équipe que vous appelez quand le cluster est en feu — et l'équipe que vous auriez dû appeler avant qu'il ne s'enflamme. Parlez-nous de votre projet et nous vous dirons ce qu'il faut réellement.

Résumé

L'essentiel en 5 points

Pour ceux qui sont pressés

Ceph Tentacle (v20) est la dernière release (nov 2025), avec Crimson pour l'erasure coding, un tiering plus intelligent et de meilleures performances MDS.

Squid (v19) reste une branche active solide — largement déployée, avec Crimson OSD en adoption précoce, RGW plus rapide et meilleur support CephFS/NFS.

Reef (v18) a atteint sa fin de vie — dernière release 18.2.8 en mars 2026. Planifiez votre mise à jour vers Squid ou Tentacle.

Rook-Ceph reste le standard pour les déploiements Kubernetes natifs, avec un scaling plus fluide.

Trois interfaces depuis un seul cluster : bloc (RBD), objet (RGW) et fichiers (CephFS) — la plateforme de stockage unifié open source la plus mature disponible.

FAQ

Questions fréquentes

Quelle est la dernière version stable de Ceph ?

Ceph Tentacle (v20.x), publiée en novembre 2025. Squid (v19.x) reste une branche stable active largement déployée. Reef (v18.x) a atteint sa fin de vie avec sa release finale (18.2.8) en mars 2026 — les nouveaux déploiements devraient viser Squid ou Tentacle.

Ceph peut-il remplacer NFS en production ?

CephFS peut servir des exports NFS via NFS-Ganesha, et cela fonctionne bien en production. Mais Ceph n'est pas un remplacement direct de NFS — il nécessite une planification de cluster, une conception réseau et une expertise opérationnelle. C'est un autre animal.

Ceph est-il adapté aux charges de production ?

Oui. Ceph fonctionne en production dans des organisations gérant des pétaoctets, des institutions de recherche aux fournisseurs cloud. Il bénéficie du support commercial d'IBM et de Red Hat.

Quelle différence entre Ceph et MinIO ?

Ceph fournit bloc, objet et fichiers depuis un seul cluster. MinIO se concentre exclusivement sur le stockage objet S3. Ceph est plus polyvalent mais plus complexe à opérer ; MinIO est plus simple pour les charges objet pures. Les deux sont excellents — des outils différents, des compromis différents.

Comment fonctionne Rook-Ceph avec Kubernetes ?

Rook est un opérateur diplômé de la CNCF qui automatise le déploiement, la mise à l'échelle et les mises à jour de Ceph dans Kubernetes. Il fournit un provisionnement dynamique CSI pour les volumes RBD et CephFS — vous créez un PVC, Rook s'occupe du reste.

Sources

Références

Ceph. Documentation officielle et notes de release. docs.ceph.com/releases

Ceph. Page du projet et téléchargements. ceph.io

Rook. Cloud-Native Storage for Kubernetes. rook.io

IBM. IBM Storage Ceph. ibm.com/products/storage-ceph

Red Hat. Red Hat Ceph Storage. redhat.com/technologies/storage/ceph

Dernière mise à jour : .


Support Ceph professionnel

Besoin de Ceph en production ? Parlons architecture.

Conception de cluster, déploiement, formation et support continu. Ingénieurs stockage senior à travers l'Europe — pas de helpdesks, pas de file d'attente. Juste des experts Ceph.

VMware en 2026 : quatre voies après le changement Broadcom

Virtualisation · Infrastructure · 2026

VMware en 2026 : quatre voies après le changement de modèle Broadcom.

Si votre vSphere 7 ou 8 tourne comme une horloge, vous n'avez aucune raison d'y toucher. Point. Ce qui a changé c'est le modèle de licences, pas la plateforme — et il existe quatre voies raisonnables : rester avec Broadcom, garder ce que vous avez avec support tiers, migrer vers Proxmox VE, ou passer à OpenShift Virtualization. La décision sur le quand — ou le si — revient de votre côté. Nous menons les quatre.

10 min de lectureGuide

En 30 secondes : quatre voies raisonnables pour votre VMware en 2026 — rester avec Broadcom (VCF/VVF), garder votre vSphere avec support tiers, migrer vers Proxmox VE, ou passer à OpenShift Virtualization. Les quatre fonctionnent ; l'adéquation dépend de votre pile, de votre calendrier et du budget que vous avez envie de lier au fabricant.

Nous maintenons VMware depuis avant l'existence de Broadcom, et depuis que Broadcom existe. Nous faisons aussi du support tiers pour votre pile d'entreprise, des migrations vers Proxmox et OpenShift, et de la formation officielle sur ce dont vous avez besoin. Pas de cheval favori — juste des clients très différents, et cet article est ce qu'on leur raconte quand ils demandent « bon, et moi je fais quoi ? ».

4
Voies raisonnables
en 2026
2023
Broadcom termine
l'acquisition de VMware
15+
Années SIXE
en virtualisation d'entreprise
01 · Contexte

Qu'est-ce qui a changé chez VMware depuis l'acquisition par Broadcom ?

Broadcom a clôturé l'acquisition de VMware le 22 novembre 2023. À partir de là, plusieurs choses ont changé du côté commercial — détaillées dans l'article officiel de Broadcom sur les changements de portfolio. La plateforme technique reste la même. Ce qui change c'est comment on l'achète, pas comment elle fonctionne.

  • Fin des nouvelles licences perpétuelles. Le catalogue est passé aux abonnements, principalement via deux bundles : VMware Cloud Foundation (VCF) et VMware vSphere Foundation (VVF).
  • Réorganisation du catalogue. Des produits autrefois vendus séparément (vSAN, NSX, Aria) sont désormais intégrés aux bundles, ce qui change le calcul des licences par serveur.
  • Programme partenaires renouvelé. Les accords de canal ont été renégociés, et beaucoup de clients traitent désormais directement avec Broadcom ou avec un partenaire de premier niveau.
  • Les licences perpétuelles existantes restent valides : les clients qui les ont déjà achetées peuvent continuer à les exécuter, sans nouvelles mises à jour s'ils ne souscrivent pas de support.
En contexte

C'est un changement de modèle commercial, pas une défaillance technique de VMware. Pour certaines organisations la transition est gérable ; pour d'autres — surtout celles qui n'utilisent pas tous les composants du bundle — la facture se multiplie. Faites les calculs avant de renouveler, pas après.

02 · Décision

Pourquoi tant d'entreprises repensent-elles leur VMware en 2026 ?

On l'entend dans presque toutes les conversations — trois motifs qui apparaissent presque toujours ensemble :

  1. La facture grimpe. Passer à un bundle avec des composants que vous n'utilisez pas (vSAN, NSX, Aria) multiplie le coût par core.
  2. L'horloge tourne. Contrats pluriannuels qui arrivent à terme, et le classique e-mail « votre renouvellement est dans 90 jours, vous confirmez ? ».
  3. La plateforme vieillit. vSphere 7 a clôturé son support général le 2 octobre 2025 ; vSphere 8 est annoncé pour 2027.

Tout le monde ne vit pas ça de la même manière. Si vous avez 3 hôtes et un cluster modeste, l'ajustement est gérable. Si vous avez 300 hôtes avec vSAN étendu, ouvrir l'éventail des options a un retour clair et rapide. La question n'est plus « quelle version j'achète ? » — elle est maintenant « qu'est-ce que je fais avec tout ce que j'ai déjà déployé et qui tourne ? ».

03 · Les quatre voies

Quelles sont vos quatre vraies options en 2026 ?

Il y a aujourd'hui quatre voies raisonnables. Pas de réponse universelle : l'adéquation dépend de combien de VMware vous avez, de ce qui tourne dessus, de qui l'opère et du calendrier que vous gérez.

Option À qui ça convient Ce que vous gagnez Ce que ça coûte
1. Rester avec Broadcom (VCF / VVF)
Vous utilisez réellement le bundle complet (vSAN, NSX, Aria) et vous avez le budget pour le nouveau modèle d'abonnement.
Plateforme complète, feuille de route officielle, support direct du fabricant, accès aux nouvelles versions.
Abonnement annuel, facture liée au nombre de cores.
2. Garder votre VMware avec support tiers
Vous êtes stable sur vSphere 7 ou 8 et vous voulez le rester plusieurs années de plus — avec économies sur les licences et autonomie sur le quand (ou si) migrer.
Version actuelle sécurisée et opérationnelle ; SLA contractuel ; budget libéré pour l'investissement ou les ressources humaines ; temps pour évaluer Proxmox ou OpenShift sans pression.
Renoncer aux nouvelles versions du fabricant et au support direct de Broadcom pendant la durée du contrat.
3. Migrer vers Proxmox VE
Équipes qui cherchent un hyperviseur open source à usage général équivalent à vSphere pour des VMs et des conteneurs LXC.
Plateforme ouverte, sans licences par hôte, avec abonnements de support entreprise disponibles, écosystème mature.
Projet de migration (P2V/V2V), montée en compétences de l'équipe, réécriture de certaines automatisations.
4. Migrer vers OpenShift Virtualization
Vous allez déjà vers conteneurs et Kubernetes et vous voulez consolider VMs et pods sur une seule plateforme.
Une seule plateforme pour VMs et conteneurs, intégration native CI/CD et réseau Kubernetes, support entreprise Red Hat / IBM.
Courbe d'adoption Kubernetes, refonte réseau et stockage, plan de migration par vagues.

Les quatre fonctionnent. Ce que nous NE recommandons pas : décider à contre-la-montre avec le renouvellement qui pèse. Dans ce scénario on finit presque toujours par renouveler par inertie, sans avoir comparé — et c'est la pire option de toutes, parce que vous ne l'avez même pas choisie.

Interactif

Quelle voie vous correspond ?

Trois questions rapides et on vous dit laquelle des quatre voies a le plus de sens dans votre cas. Aucune donnée collectée, pas d'e-mail demandé — tout se calcule dans votre navigateur.

01Quand expire votre contrat VMware actuel ?
02Où va votre plateforme dans les 3 prochaines années ?
03À quel point votre pile actuelle est-elle « VMware-lourde » ?
Répondez aux 3 pour voir le résultat
Votre recommandation initiale

04 · Voie 2 en détail

Qu'est-ce que le support tiers pour VMware ?

Ce n'est pas du « support technique » au sens habituel. C'est ce qui se passe quand le fabricant cesse d'être votre fournisseur de maintenance et qu'un autre entre faire ce travail — nous, en l'occurrence. Nous maintenons votre vSphere 7 ou 8 stable, patché et sous SLA contractuel pendant que vous décidez de la suite à long terme. Cela ne remplace pas les mises à niveau de version du fabricant. Cela remplace le contrat de maintenance — c'est là que part l'argent.

Les clients nous contractent pour quatre raisons, dans des ordres variables :

  • Rester sur vSphere 7 ou 8 cinq à dix ans de plus sans que personne ne vous pousse à mettre à niveau. Si votre plateforme est stable, vous n'avez pas besoin d'une nouvelle version — vous avez besoin que la vôtre reste sécurisée.
  • Récupérer le levier : c'est vous qui fixez le calendrier, pas la date de fin de support général imposée par Broadcom.
  • Sortir l'argent du contrat de maintenance logicielle pour le placer où il apporte — nouveau matériel, un projet repoussé depuis un an, une personne de plus dans l'équipe.
  • Un seul contrat pour toute la pile (hyperviseur, matériel, OS invité). Vous arrêtez d'accumuler des contrats verticaux avec chaque fabricant.

Cela convient particulièrement bien quand votre vSphere est solide et que vous voulez le prolonger pendant que vous évaluez tranquillement Proxmox ou OpenShift — ou aucun des deux, si vous changez d'avis en chemin. Nous couvrons vSphere 7 et 8 depuis l'Europe, en français (et anglais, et espagnol), avec un ingénieur attitré qui ne tourne pas. Périmètre, SLA et processus dans support tiers VMware 7 et 8 ; la même logique pour SAP vit dans le hub de support tiers.

05 · Voies 3 et 4 en détail

Et si je veux migrer ? Proxmox ou OpenShift ?

Cela dépend d'où va votre plateforme dans les cinq prochaines années.

Proxmox VE — la migration latérale

Proxmox VE est la réponse naturelle si ce que vous avez est un VMware shop classique — VMs Windows et Linux, stockage partagé, sauvegardes — et que vous voulez un hyperviseur open source qui ressemble à ce que vous opérez déjà. Il supporte l'import de VMs depuis VMware, tourne sur KVM et LXC, et propose des abonnements de support entreprise. C'est une migration latérale, pas un changement de paradigme. C'est aussi la voie pour laquelle nos données GSC montrent le plus d'intérêt côté francophone : la requête « migration vmware vers proxmox » est devenue une vraie conversation en 2026.

OpenShift Virtualization — la consolidation Kubernetes

OpenShift Virtualization (basé sur KubeVirt) est la réponse si votre organisation va déjà vers les conteneurs et que vous voulez une seule plateforme pour VMs et pods. Il permet d'exécuter des machines virtuelles comme ressources Kubernetes, à côté de vos applications conteneurisées, avec le même réseau et le même stockage. Plus de courbe d'apprentissage, mais aussi plus de marge si votre feuille de route est cloud-native.

Une troisième voie : OpenStack

Il existe une quatrième destination à garder en tête : OpenStack avec Ceph reste une option solide pour les grands environnements qui veulent opérer un cloud privé complet. Le choix entre les trois n'est pas idéologique ; c'est une question d'adéquation technique et d'équipe.

06 · Coût et délais

Combien coûte une migration depuis VMware ? Et combien de temps ?

Pas de tarif catalogue. Quiconque vous donne un chiffre sans regarder votre infrastructure l'invente. Le temps et le coût dépendent de trois choses :

  • Taille du parc : nombre d'hôtes, nombre de VMs, taille en TB, présence de vSAN/NSX.
  • Complexité du réseau et du stockage : switches distribués, microsegmentation, réplication, DR.
  • Dépendances de la pile supérieure : backup, supervision, automatisation, CI/CD.

Pour planifier :

  • Une migration de dizaines de VMs depuis vSphere vers Proxmox ou OpenShift s'exécute typiquement en semaines, avec des fenêtres maîtrisées par service.
  • Un projet sur centaines de VMs s'exécute en mois, par vagues, avec un strangler pattern : nouvelles charges sur la plateforme destination, charges existantes migrées par blocs.
Insight clé

Ce qui rallonge (et renchérit) les projets, ce n'est généralement pas l'hyperviseur — ce sont les dépendances qui pendent dessus : backup, PRA, automatismes anciens, intégrations CMDB. C'est pourquoi le premier livrable de toute migration sérieuse est un inventaire et une carte des dépendances, pas un PoC du nouvel hyperviseur.

07 · Méthode

Quel est l'ordre recommandé pour décider ?

Voici la procédure que nous appliquons chez SIXE quand un client nous demande « qu'est-ce que je fais avec VMware ? ». Cochez les étapes au fur et à mesure — la barre vous indique ce qu'il vous reste et le plan vous appartient.

Méthode SIXE · 5 étapes avant de renouveler ou migrer 0 / 5 complétées
1
Inventaire réel du parc

Hôtes, cores, VMs, vSAN, NSX, Aria, contrats en cours et dates d'échéance. Sans ça, tout calcul est de la fiction.

2
Carte des dépendances de la pile supérieure

Backup, PRA, supervision, automatisation, intégrations CMDB. Les vrais délais — et les risques cachés — vivent ici.

3
Trois chiffres comparables

Coût de renouvellement avec Broadcom dans le nouveau modèle · Coût de support tiers sur 12-24 mois · Coût estimé de migration (main d'œuvre + outils + formation).

4
Décision éclairée — ou combinaison

Les quatre voies sont combinables. Pattern fréquent : support tiers pendant 18 mois + migration progressive vers Proxmox pour les charges standard et vers OpenShift pour celles qui vont aux conteneurs.

5
Plan d'exécution par vagues

Revue trimestrielle. L'important est de séparer la décision technique du calendrier commercial — le levier est dans votre main, pas dans la date de renouvellement.

08 · Équipe

Et la formation de l'équipe ?

N'importe laquelle des quatre voies demande de la formation, mais dans des proportions différentes :

  • Rester sur VMware sous Broadcom : peu de formation nouvelle, surtout sur le modèle de licences et les bundles.
  • Support tiers : aucune formation additionnelle ; l'équipe continue d'opérer ce qu'elle connaît déjà.
  • Proxmox VE : formation modérée ; le modèle mental ressemble à vSphere mais les outils et le réseau sont différents.
  • OpenShift Virtualization : formation Kubernetes significative ; à commencer avant la migration, pas pendant.

Nous sommes partenaire formation sur plusieurs de ces plateformes : VMware, Red Hat (y compris OpenShift), et les solutions basées KVM. Si vous voulez garder votre équipe certifiée sur ce qu'elle opère déjà, nous proposons la formation officielle VMware vSphere. Quand la migration s'accompagne d'une formation précoce, les vagues vont plus vite et avec moins d'incidents.

Quatre voies pour VMware en 2026 : continuer, support tiers, Proxmox et OpenShift
Quatre voies pour votre infrastructure VMware en 2026 — toutes valables ; ça dépend de votre pile, de votre calendrier et de votre budget.
10 · Notre position

VMware est-il une mauvaise plateforme après Broadcom ?

Non. Et il vaut mieux le clarifier. Voici des choses qu'on pourrait dire pour des clics faciles, et qu'on ne dira pas :

  • Que VMware est un mauvais produit. Il ne l'est pas — nous le maintenons depuis plus de quinze ans.
  • Que Broadcom est le méchant de l'histoire. C'est une décision commerciale légitime d'un fabricant. Aux clients de décider ce qu'ils en font, pas d'insulter celui qui l'a prise.
  • Que Proxmox ou OpenShift sont « la réponse ». Ce sont des réponses quand ils conviennent. Dans d'autres cas, ce qui convient c'est de rester sur VMware — avec ou sans Broadcom.
Ce qu'on vous dit

Ne décidez pas dans la précipitation. Faites les calculs sur les quatre, et s'il vous faut du temps pour bien faire, le support tiers existe justement pour ça. Nous maintenons VMware depuis avant l'existence de Broadcom. Nous maintenons aussi Proxmox, OpenShift et OpenStack. Ce que vous décidez, on l'exécute — c'est la différence.

Résumé

L'essentiel en 5 points

Si vous avez sauté à la fin

→ C'est le modèle qui a changé, pas la plateforme. Abonnement (VCF/VVF) au lieu de nouvelles perpétuelles. Les perpétuelles que vous possédez déjà restent à vous.

Quatre voies raisonnables : rester avec Broadcom, support tiers, migrer vers Proxmox ou passer à OpenShift. Les quatre fonctionnent.

Support tiers = acheter du temps sans renoncer à la sécurité. Votre vSphere 7 ou 8 reste patché et sous SLA, mais le contrat n'est plus avec Broadcom.

Ne commencez pas par le PoC du nouvel hyperviseur. Commencez par l'inventaire et la carte des dépendances. L'hyperviseur est rarement la partie difficile.

Les quatre voies se combinent. Pattern le plus fréquent : 12-18 mois de support tiers + migration par vagues en parallèle.

FAQ

Questions fréquentes

Le support tiers pour VMware est-il légal ?

Oui — et ce n'est pas une zone grise. Il couvre la maintenance opérationnelle des versions déjà déployées, sans redistribuer de logiciel ni modifier de licences. Il ne remplace pas les mises à niveau du fabricant — il remplace le contrat de maintenance, c'est autre chose.

Puis-je continuer à utiliser VMware sans renouveler avec Broadcom ?

Si vous avez des licences perpétuelles antérieures, oui : vous pouvez continuer à les exécuter. Ce que vous perdez c'est l'accès aux nouvelles mises à jour et au support direct du fabricant. Pour combler ce manque, il y a le support tiers VMware 7 et 8 avec SLA contractuel.

Quand prend fin le support de vSphere 7 et vSphere 8 ?

VMware vSphere 7 a atteint la fin du support général le 2 octobre 2025, selon la communication officielle de Broadcom. vSphere 8 est actuellement prévu pour 2027. Les dates sont mises à jour périodiquement sur le portail officiel de cycle de vie.

Proxmox VE est-il une alternative entreprise sérieuse ?

Oui, et ceux qui continuent de dire le contraire n'y ont pas regardé depuis des années. Proxmox tourne en production dans des organisations sérieuses, propose des abonnements de support entreprise et un écosystème mature de backup, haute disponibilité et clustering. La différence avec VMware n'est pas une question de maturité technique — c'est une question de modèle (open source vs. propriétaire) et d'outils.

OpenShift Virtualization remplace-t-il vSphere ?

Pour beaucoup de charges, oui. Il exécute les VMs comme objets Kubernetes et permet de consolider VMs et conteneurs sur une seule plateforme. Si votre organisation ne se dirige pas vers Kubernetes dans les prochaines années, ce n'est pas pour vous. Si elle s'y dirige déjà, c'est l'une des meilleures cartes sur la table.

Combien on économise exactement en migrant ou en passant au support tiers ?

Cela dépend du parc et du modèle actuel. Il est habituel de trouver des économies importantes dans les grandes infrastructures avec des bundles non utilisés à 100 % — mais on ne peut donner un chiffre qu'après calcul avec vos chiffres. Tout pourcentage sans votre inventaire est du marketing.

Même approche pour SAP ?

Oui. Nous appliquons la même logique « vous décidez, on exécute » à l'infrastructure SAP — IBM Power, AIX, Linux pour SAP HANA. Ça vit dans support tiers SAP.

Deuxième avis, sans baratin

Vous voulez voir les quatre voies avec vos chiffres, pas les nôtres ?

On vous monte un rapport court avec le coût réel de chaque option appliqué à votre inventaire : rester avec Broadcom, support tiers, Proxmox ou OpenShift. Première conversation gratuite — si on ne colle pas, on ne colle pas. Si on colle, vous nous le direz.

Mettre à niveau Debian 12 vers Debian 13 Trixie (guide 2026)

Linux · Debian · Systèmes

Comment mettre à niveau Debian 12 vers Debian 13 Trixie sans casser la production.

Debian 13 « Trixie » est désormais la version stable. Voici la méthode pas à pas que nous appliquons chez SIXE pour mettre à niveau des serveurs de production : préparation, dépôts, full-upgrade et un plan de rollback testé. Sans mauvaise surprise.

8 min de lectureGuide technique

Pour mettre à niveau Debian 12 Bookworm vers Debian 13 Trixie : faites une sauvegarde, mettez Bookworm entièrement à jour, faites pointer les dépôts de bookworm vers trixie, lancez d'abord apt upgrade --without-new-pkgs puis apt full-upgrade, nettoyez et redémarrez.

Simple sur une machine de labo. Tout autre chose sur un parc de production avec bases de données, services critiques et SLA. Chez SIXE, nous maintenons des infrastructures Linux en production depuis plus de 15 ans, et voici la méthode exacte que nous appliquons pour un dist-upgrade sans interruption imprévue. Seul le saut 12 → 13 est pris en charge : si vous êtes sur Debian 11, passez d'abord à Debian 12.

2030
Support de Trixie
(3 ans + 2 LTS)
~59 000
Paquets dans
les dépôts
20-60'
Durée typique
de la mise à niveau
01 · Nouveautés

Qu'est-ce que Debian 13 Trixie et qu'est-ce qui change par rapport à Bookworm ?

Debian 13 « Trixie » est la version stable de Debian depuis le 9 août 2025. Elle embarque le noyau Linux 6.12 LTS, la finalisation de la fusion de /usr (désormais obligatoire), le passage à time_t sur 64 bits (qui prépare le problème de l'an 2038 sur les architectures 32 bits) et APT 3.0, avec une sortie plus lisible et une meilleure résolution des dépendances.

Pour un serveur de production, ce n'est pas une révolution mais exactement ce qu'on attend de Debian : une base plus propre, un noyau moderne et cinq ans de support de sécurité devant soi. Le point opérationnel clé : le compteur de support repart à zéro — et celui de Bookworm commence à s'épuiser.

En contexte

Trixie n'oblige à rien réapprendre : même APT, même philosophie. L'effort porte sur la planification du saut, pas sur l'adaptation à un nouveau système.

02 · Cycle de vie

Jusqu'à quand Debian 12 Bookworm est-il pris en charge ?

Depuis la sortie de Trixie en août 2025, Debian 12 est passé en oldstable. Il conserve un support de sécurité LTS jusqu'à environ juin 2028, mais ne reçoit plus le support complet de l'équipe de sécurité. Ce n'est pas une urgence critique, mais chaque mois d'attente ajoute de la dette technique et réduit la fenêtre pour migrer sereinement.

CYCLE DE VIE DU SUPPORT — DEBIAN 12 vs DEBIAN 13 20232025202620282030 AUJOURD'HUI Debian 12 « Bookworm » LTS → juin 2028 Debian 13 « Trixie » → juin 2030 Support complet LTS
Fenêtres de support de Debian 12 et Debian 13 — dates approximatives selon le cycle de vie de Debian
Recommandation

N'attendez pas la fin du cycle de Bookworm. Planifiez la mise à niveau dans une fenêtre tranquille, pas dans l'urgence quand les correctifs de sécurité cessent d'arriver.

03 · Préparation

Que faut-il préparer avant la mise à niveau ?

Un dist-upgrade est sûr si on le prépare. La plupart des incidents que nous avons vus ne viennent pas de la mise à niveau elle-même, mais du fait d'avoir sauté cette étape. Cochez chaque point avant de commencer :

Check-list pré-vol0 / 6 fait
Sauvegarde complète ou snapshot. Sur une VM, un snapshot complet : c'est votre bouton de rollback.
Lire les notes de publication de Debian 13 pour votre cas (problèmes connus).
Espace disque suffisant dans / et /var pour télécharger les nouveaux paquets.
Accès hors bande (console / IPMI / KVM) au cas où SSH tomberait pendant le processus.
Nettoyer /boot des anciens noyaux pour que le noyau 6.12 tienne.
Fenêtre de maintenance convenue et utilisateurs prévenus.

Les six cochés ? Alors oui, lancez la mise à niveau.

04 · Pas à pas

Comment mettre à niveau Debian 12 vers Debian 13, étape par étape

Le processus comporte six phases : mettre Bookworm à jour, faire pointer les dépôts vers trixie, désactiver les dépôts tiers, lancer d'abord la mise à niveau minimale puis la complète, nettoyer et redémarrer avec vérification. Voici le flux et les commandes exactes.

La mise à niveau en 6 phases
1
Mettre Bookworm à jourPartir d'un système 100 % à jour
2
Dépôts vers Trixiebookworm → trixie (dont trixie-security)
3
Désactiver les dépôts tiersLes réactiver un par un ensuite
4
Mise à niveau minimale + complète--without-new-pkgs puis full-upgrade
5
Nettoyageautoremove + autoclean
6
Redémarrage et vérificationcat /etc/debian_version → 13.x

1. Mettez Debian 12 entièrement à jour

Tout correctif en attente devient un conflit pendant le saut. Partez d'un Bookworm impeccable :

root@debian12 — bash
$ sudo apt update
$ sudo apt upgrade
$ sudo apt full-upgrade
$ sudo apt --purge autoremove

2. Faites pointer les dépôts vers Trixie

Remplacez bookworm par trixie dans vos sources APT. Cela couvre aussi bookworm-securitytrixie-security. Vérifiez le résultat avec cat avant de continuer.

éditer les sources APT
# Format classique
$ sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list

# Format DEB822 (installations récentes de Debian 12)
$ sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/debian.sources

3. Désactivez temporairement les dépôts tiers

Tout dépôt externe dans /etc/apt/sources.list.d/ (Docker, PostgreSQL, etc.) peut bloquer la mise à niveau s'il ne prend pas encore en charge Trixie. Désactivez-les maintenant et réactivez-les un par un ensuite, en vérifiant que chacun publie déjà pour Debian 13.

4. Lancez la mise à niveau : minimale d'abord, complète ensuite

La mise à niveau minimale réduit le risque de conflits de dépendances. Supervisez le processus : vous répondrez à quelques invites concernant les fichiers de configuration modifiés.

root@debian12 — dist-upgrade
$ sudo apt update
$ sudo apt upgrade --without-new-pkgs   # mise à niveau minimale
$ sudo apt full-upgrade                 # mise à niveau complète

5. Nettoyez les paquets obsolètes

nettoyage
$ sudo apt --purge autoremove -y
$ sudo apt autoclean

6. Redémarrez et vérifiez

root@debian13 — vérification
$ sudo reboot
# après le redémarrage :
$ cat /etc/debian_version   # -> 13.x
$ uname -r                  # -> 6.12.x
$ systemctl --failed        # aucun service en échec
05 · Rollback

Combien de temps cela prend-il et peut-on revenir en arrière ?

Sur un serveur classique, la mise à niveau prend 20 à 60 minutes selon le nombre de paquets et la vitesse du disque et du réseau. Revenir en arrière après un dist-upgrade n'est pas trivial une fois les paquets installés : c'est pourquoi le snapshot préalable est non négociable. Sur les VM, revenir au snapshot prend quelques minutes ; sur du matériel physique, le plan de rollback consiste à restaurer depuis la sauvegarde.

Règle d'or

Ne faites jamais un saut de version majeure en production sans un retour arrière testé. Une sauvegarde que vous n'avez jamais restaurée n'est pas une sauvegarde : c'est un espoir.

06 · Erreurs courantes

Quelles sont les erreurs les plus fréquentes lors du passage à Trixie ?

Ce que nous voyons le plus en production, et comment l'éviter :

  • Dépôts tiers sans version pour Trixie qui bloquent apt : désactivez-les avant (étape 3).
  • /boot plein qui empêche l'installation du nouveau noyau : nettoyez les anciens noyaux avant de commencer.
  • Fichiers de configuration écrasés en acceptant aveuglément la version du paquet : en cas de doute, conservez la vôtre et révisez ensuite.
  • Oublier --without-new-pkgs dans la phase minimale, ce qui déclenche des conflits de dépendances.
  • Services maison supposant des chemins /usr non fusionnés : la fusion de /usr est désormais obligatoire dans Trixie.
07 · En contexte

Debian ou Ubuntu pour votre serveur ?

La question qu'on nous pose le plus. Il n'y a pas de réponse universelle : tout dépend si vous privilégiez le contrôle et l'indépendance (Debian) ou le support commercial intégré et des outils comme Ubuntu Pro et Landscape (Ubuntu). Voici la comparaison rapide :

Debian 13Ubuntu ProRHEL
Gouvernance
Communautaire
Canonical
IBM / Red Hat
Support / version
5 ans + ELTS
10 ans
10 ans
Paquets
~59 000
~30 000
~5 000
Coût de licence
0 €
Par nœud
Par nœud
Support en français
SIXE
SIXE UP
SIXE

Vous travaillez avec Ubuntu ? En tant que partenaire Canonical, nous vous accompagnons aussi avec SIXE UP. Et si votre cas est de migrer entre distributions, nous gérons les migrations sans interruption.

Ingénieur SIXE mettant à niveau un serveur de Debian 12 Bookworm vers Debian 13 Trixie dans un datacenter
Mise à niveau de Debian 12 Bookworm vers Debian 13 Trixie sur une infrastructure de production
08 · Support professionnel

Et si vous préférez ne pas toucher à la production vous-même ?

Mettre à niveau une machine de labo, c'est une après-midi. Mettre à niveau un parc de production avec SLA, bases de données et services critiques, c'est une autre histoire : il faut inventorier les dépendances, valider en staging, coordonner les fenêtres et disposer d'un rollback testé.

C'est exactement ce que nous faisons chez SIXE. Nous proposons un support professionnel pour Debian — mises à niveau de version planifiées, durcissement avec supervision Wazuh et résolution d'incidents avec SLA — et nous gérons la maintenance de systèmes critiques. Vous voulez former votre équipe ? Nous proposons une formation officielle Linux.

Plus de 15 ans à maintenir Linux en production

Des ingénieurs seniors qui parlent votre langue, sans helpdesks ni escalades. Vous devez mettre à niveau plusieurs serveurs vers Debian 13 ? Parlez-nous de votre cas et nous vous proposons un plan avec fenêtre de maintenance et rollback.

Résumé

L'essentiel en 5 points

Pour les pressés

Debian 13 Trixie est la version stable depuis août 2025 ; Debian 12 est désormais oldstable (LTS jusqu'à ~2028).

Sauvegarde / snapshot avant tout. C'est votre seul vrai rollback.

→ Partez d'un Bookworm 100 % à jour, basculez les dépôts vers trixie et lancez upgrade --without-new-pkgs avant le full-upgrade.

Désactivez les dépôts tiers pendant le processus.

→ Seul 12 → 13 est pris en charge : depuis Debian 11, passez d'abord par Debian 12.

FAQ

Questions fréquentes

Peut-on passer de Debian 11 directement à Debian 13 ?

Non. Debian ne prend en charge que les mises à niveau entre versions consécutives. Depuis Debian 11 « Bullseye », il faut d'abord passer à Debian 12 « Bookworm » puis, une fois là, à Debian 13 « Trixie ».

Vais-je perdre mes données et ma configuration ?

Non, un dist-upgrade conserve les données et la configuration. Une sauvegarde ou un snapshot complet reste néanmoins obligatoire : c'est votre plan de rollback en cas d'échec.

Vaut-il mieux mettre à niveau ou réinstaller de zéro ?

Pour un serveur bien entretenu, le dist-upgrade est sûr et bien plus rapide. La réinstallation ne se justifie que si le système accumule beaucoup de dette technique ou des configurations incohérentes.

Sources

Références

Debian. Informations sur la version Debian 13 « trixie ». debian.org/releases/trixie

Debian. Notes de publication de Debian 13. debian.org/releases/trixie/releasenotes

Debian. Debian 13 « trixie » released (2025-08-09). debian.org/News/2025

Équipe de sécurité de Debian. debian.org/security

Rédigé par l'équipe d'ingénierie systèmes de SIXE. Dernière mise à jour : .


Support Debian professionnel

Vous devez mettre à niveau vos serveurs vers Debian 13 ?

Nous proposons un plan de mise à niveau avec audit préalable, validation en staging, fenêtre de maintenance et rollback testé. Ingénierie senior, avec SLA.

Conformité NIS2 avec Wazuh

Cybersécurité · NIS2 · Wazuh

Conformité NIS2 avec Wazuh.

La Belgique a été le premier pays de l'UE à transposer NIS2 en droit national. L'auto-évaluation est due avant le 18 avril 2026. Wazuh est un outil gratuit qui couvre une grande partie des mesures de surveillance et de détection exigées — mais pas toutes. Ce guide vous explique ce qu'il couvre, ce qu'il ne couvre pas, et comment préparer votre conformité.

12 min de lectureCybersécurité · Conformité

La loi du 26 avril 2024 transpose la directive européenne NIS2 en droit belge. Si votre organisation fournit des services essentiels — ou des technologies à une entité qui en fournit — vous êtes concerné. Les amendes peuvent atteindre 10 millions d'euros ou 2 % du chiffre d'affaires mondial. L'auto-évaluation doit être soumise au CCB avant le 18 avril 2026.

Wazuh est une plateforme de sécurité open source qui centralise les journaux d'activité de vos serveurs, détecte les comportements suspects et génère les preuves qu'un auditeur ou le CCB s'attend à trouver. Elle est gratuite, largement adoptée par des administrations publiques et des centres de recherche européens — dont le CERN — et chez SIXE nous la déployons dans des environnements de production configurés spécifiquement pour la conformité réglementaire.

0 €
Coût de licence Wazuh
10
Mesures NIS2 supportées
24h
Alerte précoce incident
4 000+
Entités NIS2 en Belgique
01 · Champ d'application

La loi NIS2 belge vous concerne-t-elle ?

La loi NIS2 belge s'applique aux entités essentielles (énergie, transports, santé, eau, infrastructures numériques, administration publique) et aux entités importantes (services postaux, gestion des déchets, alimentation, fabrication, chimie, fournisseurs numériques). Si vous fournissez des technologies ou des services à l'un de ces secteurs, vous pouvez également être concerné via les exigences relatives à la chaîne d'approvisionnement.

En Belgique, plus de 4 000 entités se sont déjà enregistrées auprès du CCB via Safeonweb@Work.

Touchez chaque carte pour savoir si NIS2 vous concerne
« Nous sommes un prestataire IT qui héberge les systèmes d'un hôpital belge. »
Touchez pour révéler
Oui, vous êtes concerné La santé est un secteur essentiel sous NIS2. En tant que fournisseur technologique de ce secteur, vous entrez dans le champ d'application via les exigences de la chaîne d'approvisionnement (article 21.2.d).
« Nous sommes une PME industrielle de 250 employés en Wallonie. »
Touchez pour révéler
Oui, entité importante La fabrication est classée « secteur important » sous NIS2. Les moyennes et grandes entreprises de ce secteur sont concernées. La supervision est réactive (après incident), mais les obligations sont réelles.
« Nous sommes un bureau de comptabilité de 10 personnes sans clients publics. »
Touchez pour révéler
Probablement pas Les petites entreprises hors des secteurs listés ne sont généralement pas concernées. Mais vérifiez vos contrats : si vous traitez des données pour des clients dans des secteurs essentiels, des exigences pourraient s'appliquer.
« Nous opérons un data centre en Belgique utilisé par des administrations publiques. »
Touchez pour révéler
Oui, entité essentielle Les fournisseurs d'infrastructures numériques (cloud, DNS, data centres) sont classés comme entités essentielles. Supervision proactive du CCB et obligations les plus strictes.
« Nous sommes un fournisseur d'énergie distribuant de l'électricité en Flandre et à Bruxelles. »
Touchez pour révéler
Oui, entité essentielle L'énergie est un secteur essentiel. Supervision proactive, signalement obligatoire d'incidents (24h/72h/1 mois), amendes jusqu'à 10 M€ ou 2 % du chiffre d'affaires mondial.

CyberFundamentals : le cadre belge de conformité NIS2

La Belgique a créé son propre cadre pour faciliter la mise en conformité : CyberFundamentals (CyFun®), développé par le CCB. Il comporte 4 niveaux de maturité — Small (7 contrôles), Basic (34), Important (132) et Essential (217). C'est une alternative pratique à ISO 27001, et 75 % des entités enregistrées l'ont choisi. L'auto-évaluation CyFun ou la documentation ISO 27001 doit être soumise au CCB avant le 18 avril 2026.

02 · Les exigences

NIS2 décrit des capacités de SIEM — sans utiliser le mot

Un SIEM (Security Information and Event Management) est un système qui centralise les journaux d'activité de tous vos serveurs et équipements, les analyse automatiquement pour détecter des comportements suspects, et génère des alertes lorsque quelque chose ne va pas. Imaginez une caméra de surveillance pour toute votre infrastructure informatique — mais qui comprend ce qu'elle voit.

NIS2 ne dit pas « installez un SIEM ». Mais l'article 21 exige des mesures qui, en pratique, nécessitent des capacités de type SIEM :

  • Gestion des incidents (art. 21.2.b) — détecter, traiter et signaler les incidents. NIS2 impose un signalement en trois étapes : alerte précoce sous 24 heures, notification sous 72 heures, rapport final sous un mois.
  • Gestion des risques (art. 21.2.a) — analyse des risques continue et politiques de sécurité des systèmes d'information.
  • Continuité des activités (art. 21.2.c) — gestion des sauvegardes, reprise après sinistre, gestion de crise.
  • Sécurité de la chaîne d'approvisionnement (art. 21.2.d) — sécurité des relations avec les fournisseurs directs.
  • Traitement des vulnérabilités (art. 21.2.e) — divulgation et gestion des vulnérabilités.
  • Surveillance et journalisation (art. 21.2.g/h) — politiques d'évaluation de l'efficacité des mesures, y compris la journalisation et la surveillance des systèmes.
L'essentiel

NIS2 ne prescrit pas d'outil spécifique. La directive prescrit des résultats — détection d'incidents, réponse, journalisation, gestion des risques. Utiliser Wazuh pour y parvenir est une décision technique et économique, pas une obligation réglementaire.

03 · Ce que Wazuh apporte

Quelles mesures NIS2 Wazuh supporte-t-il ?

Wazuh est une plateforme open source (gratuite) qui combine plusieurs fonctions de sécurité en un seul produit : centralisation des journaux, surveillance de l'intégrité des fichiers, détection de vulnérabilités, vérification de la configuration de vos serveurs, et réponse automatique aux menaces.

Exigence NIS2 / ISO 27001 Fonction Wazuh Ce que ça fait, concrètement
Détection d'incidents (art. 21.2.b)
Analyse des journaux
Collecte et corrèle les événements de tous les postes pour repérer les menaces
Réponse aux incidents (art. 21.2.b)
Réponse active
Bloque des IP, isole des machines ou arrête des processus automatiquement
Vulnérabilités (art. 21.2.e)
Détection de vulnérabilités
Identifie les logiciels avec des failles connues nécessitant une mise à jour
Journalisation (A.8.15)
Gestion centralisée des logs
Collecte, normalise et archive les journaux de tous les systèmes surveillés
Surveillance (A.8.16)
Surveillance continue
Surveillance 24h/24 de tous les agents avec tableaux de bord et alertes
Protection contre les logiciels malveillants (A.8.7)
FIM + YARA + VirusTotal
Surveillance de l'intégrité des fichiers, détection par signature
Configuration sécurisée (A.8.9)
Audit de configuration
Vérifie la conformité aux bonnes pratiques CIS Benchmarks
Contrôle d'accès
Détection d'accès
Détecte les tentatives de connexion par force brute et les accès suspects
Détection d'intrusion (art. 21.2.a)
Suricata + MITRE ATT&CK
IDS réseau avec règles personnalisées basées sur les techniques d'attaque connues
Évaluation de l'efficacité (art. 21.2.g)
Tableaux de bord
Métriques de conformité et opérationnelles en temps réel
Déplacez le curseur — quelle supervision selon votre catégorie ?
Entité importante Entité essentielle
Art. 21Toutes les mesures de sécurité (identiques)
Art. 23Signalement d'incidents (24h / 72h / 1 mois)
Art. 32Supervision proactive par le CCB
Art. 34Amendes jusqu'à 10 M€ ou 2 % du CA
Art. 32.5Responsabilité personnelle de la direction
CCBAudits aléatoires, inspections sur site
Entité importante — Mêmes obligations de sécurité que les entités essentielles, mais supervision réactive (le CCB enquête après un incident). Amendes jusqu'à 7 M€ ou 1,4 % du CA.

Un point essentiel : ce tableau montre les capacités techniques de Wazuh. Mais un outil ne « se conforme » pas à NIS2 — c'est votre organisation qui le fait. Wazuh est l'instrument ; les politiques, les procédures, la gouvernance et le plan de réponse aux incidents constituent le cadre qui lui donne une validité auprès du CCB ou d'un auditeur CyFun.

04 · Les limites

Ce que Wazuh ne fait PAS tout seul

C'est la section que la plupart des fournisseurs évitent. Et c'est celle qui renforce le plus la crédibilité.

Wazuh ne remplace pas

Un cadre de gestion des risques. NIS2 exige une analyse des risques formelle et continue. Wazuh détecte les menaces, mais n'évalue pas les risques métier.

La gouvernance et les politiques. Vous avez besoin de politiques de sécurité documentées et approuvées par la direction. L'article 20 de NIS2 rend la direction personnellement responsable.

Le signalement d'incidents. Wazuh détecte les incidents et conserve les preuves. Mais déposer l'alerte précoce sous 24h auprès du CCB est un processus organisationnel.

La sécurité de la chaîne d'approvisionnement. L'article 21.2.d exige de gérer les risques liés à vos fournisseurs. Wazuh surveille votre infrastructure, pas celle de vos sous-traitants.

La continuité des activités. Stratégie de sauvegarde, reprise après sinistre, gestion de crise — ce sont des capacités organisationnelles.

Une équipe qui analyse les alertes. Un SIEM que personne ne consulte est une caméra de surveillance avec l'écran éteint.

05 · Pas de certification produit

NIS2 ne certifie pas les produits — elle exige des résultats

Contrairement à certains cadres nationaux qui maintiennent des catalogues de produits « approuvés », NIS2 ne prescrit pas d'outils spécifiques. Il n'existe pas de label « SIEM certifié NIS2 ». La directive exige des organisations qu'elles mettent en place des mesures techniques et organisationnelles proportionnées aux risques.

En Belgique, le CCB propose le cadre CyberFundamentals comme voie structurée vers la conformité. Vous pouvez démontrer votre conformité soit via une évaluation CyFun (avec ses 4 niveaux), soit via une documentation ISO 27001. Wazuh s'intègre dans les deux approches comme composant technique de surveillance et de détection.

Clé pour l'audit

Tout déploiement de Wazuh pour NIS2 nécessite des procédures documentées reliant les données produites par l'outil à votre cadre de gestion des risques. La détection sans documentation est invisible pour un auditeur.

06 · Migration depuis un SIEM commercial

Migrer depuis Splunk ou QRadar sans perdre la conformité

Si votre organisation utilise un SIEM commercial dont le renouvellement approche, Wazuh est une alternative viable. La question n'est pas de savoir s'il fonctionne — mais comment migrer sans créer un trou dans vos preuves de conformité.

Du SIEM commercial à Wazuh — sans rupture de conformité
1
Inventaire des règles activesCelles que quelqu'un consulte réellement, pas celles livrées par défaut.
2
Traduction des règles vers WazuhRéécriture des règles personnalisées + création de décodeurs pour vos applications.
3
Export de l'historiqueArchivage des événements passés. Sans cela, l'auditeur voit un trou dans vos journaux.
4
Fonctionnement en parallèle (4 à 6 semaines)Les deux SIEM fonctionnent simultanément. Vérification que Wazuh capture tout.
5
Validation avec l'auditeurFacultatif mais recommandé. Obtenir le feu vert avant d'éteindre l'ancien système.
6
Arrêt + documentationTransition documentée dans vos registres de gestion des risques.

Chez SIXE, nous disposons d'une expertise forte en IBM QRadar avec de la formation officielle. Nous connaissons QRadar et Wazuh, et savons exactement quelles pièces doivent être reconstruites lors d'une migration.

07 · L'erreur que tout le monde fait

Installer Wazuh « tel quel » n'est pas être conforme à NIS2

Wazuh est livré avec plus de 3 000 règles de détection préconfigurées. La plupart ne s'appliquent pas à votre environnement. Si vous n'avez que des serveurs Linux mais laissez actives les règles Solaris et Windows Server 2012, vous obtenez du bruit : des alertes que personne ne comprend et que personne ne consulte.

Ce qui manque dans l'installation par défaut

Pas de tableau de bord NIS2 ni CyFun. Les tableaux livrés couvrent PCI DSS, HIPAA, GDPR et NIST. Pour NIS2/CyFun, il faut les construire : des panneaux regroupés par mesures de l'article 21.

Pas de décodeurs pour vos applications internes. Vos portails, processus batch, logiciels métier — sans décodeurs adaptés, ces journaux arrivent en texte brut et la corrélation perd tout son sens.

L'installation prend 1 à 2 jours. L'ajustement prend 4 à 6 semaines. L'installation est ce qui ressemble au projet. L'ajustement est le projet.

Si vous avez déjà Wazuh installé mais pas ajusté, dites-nous ce que vous avez — le diagnostic initial est sans engagement.

08 · Préparation

Ce que vous devez avoir prêt pour l'auto-évaluation CyFun

L'échéance du 18 avril 2026 approche. Que vous choisissiez CyberFundamentals ou ISO 27001 comme cadre, voici les documents et preuves que le CCB ou un organisme d'évaluation s'attend à trouver :

  • Documentation de gestion des risques — analyse formelle des risques liée aux mesures de l'article 21 que vous avez mises en œuvre.
  • Politique de rétention des journaux — durée de conservation, lieu de stockage et garantie d'intégrité. NIS2 ne fixe pas de durée minimale, mais la pratique courante est de 12 à 24 mois.
  • Procédures de réponse aux incidents — qui reçoit les alertes, comment les incidents sont triés, contenus et signalés dans les délais 24h/72h/1 mois.
  • Procédures de gestion des vulnérabilités — fréquence d'analyse, délai de correction, SLA par gravité.
  • Tableaux de bord NIS2/CyFun — vues de conformité regroupées par mesures, séparées des panneaux génériques.
  • Preuves archivées — exports périodiques d'événements critiques, configuration des règles, registre de modifications.
09 · Formation

Former votre équipe à opérer Wazuh pour NIS2

Un système de surveillance que personne ne consulte ne détecte pas les incidents — il les enregistre, c'est tout. Les compétences nécessaires pour opérer Wazuh dans un contexte de conformité sont spécifiques : lire les événements, créer des règles adaptées à votre environnement, préparer les preuves pour le CCB, et répondre aux incidents dans les délais réglementaires.

Formation Wazuh →

Résumé

L'essentiel, pour ceux qui manquent de temps

En 6 points

NIS2 décrit des capacités de SIEM dans son article 21 — gestion d'incidents, surveillance, journalisation, gestion des vulnérabilités.

Wazuh supporte 10 mesures NIS2 et ISO 27001 liées à la surveillance, la détection et la traçabilité.

Il n'existe pas de certification produit NIS2. Vous démontrez votre conformité via CyberFundamentals ou ISO 27001.

Wazuh ne remplace pas la gestion des risques, la gouvernance, le signalement d'incidents ni l'équipe qui analyse les alertes.

Installer n'est pas se conformer. L'écart entre « nous avons Wazuh » et « nous sommes prêts pour l'auto-évaluation » représente 4 à 6 semaines de travail sérieux.

Wazuh est gratuit. L'implémenter correctement ne l'est pas.

FAQ

Questions fréquentes

La loi NIS2 oblige-t-elle à avoir un SIEM ?

Pas nommément. Mais l'article 21 exige des capacités de gestion d'incidents, de surveillance continue et de journalisation qui, en pratique, ne peuvent être raisonnablement assurées qu'avec un SIEM ou une plateforme équivalente.

Wazuh est-il conforme à NIS2 ?

Wazuh apporte les capacités techniques pour soutenir la majorité des mesures de surveillance et de détection de l'article 21. Mais la conformité est démontrée par l'organisation — pas par un outil. Ce que le CCB valide, ce sont les politiques, procédures et preuves documentées.

Qu'est-ce que CyberFundamentals ?

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

Wazuh est-il certifié NIS2 ?

Il n'existe pas de certification produit NIS2. La directive prescrit des résultats, pas des outils. Vous choisissez vos outils et démontrez votre conformité via CyFun ou ISO 27001.

Quelle est l'échéance en Belgique ?

Les entités doivent soumettre leur auto-évaluation au CCB avant le 18 avril 2026. Cette évaluation peut prendre la forme d'une auto-évaluation CyberFundamentals ou d'une documentation ISO 27001.

En combien de temps faut-il signaler un incident ?

Trois étapes : alerte précoce sous 24 heures, notification sous 72 heures, rapport final sous un mois. Wazuh fournit les capacités de détection et de journalisation, mais le signalement au CCB est un processus organisationnel.

Sources

Références et réglementation citées

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

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

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

Wazuh — Ensuring NIS2 compliance. wazuh.com

ISO/IEC 27001:2022. iso.org

Wazuh — documentation officielle. documentation.wazuh.com

Catalogue complet de formation · SIXE.

Dernière mise à jour :


Wazuh + NIS2

Parlons de votre projet

Session technique de 30 minutes, sans engagement. Dites-nous quelle catégorie NIS2 vous concerne, ce que vous avez en place et quand votre auto-évaluation est prévue. Nous ressortons avec une esquisse d'architecture et les prochaines étapes.

Chain of Thought : pourquoi votre IA ne raisonne pas

IA · Raisonnement · LLM

Chain of Thought : pourquoi votre modèle d'IA ne raisonne pas.

Le Chain of Thought n'est pas de la pensée. C'est la forme statistique de la pensée. Apple, Arizona State et UC Berkeley le prouvent avec des données. Voici ce que cela signifie pour qui déploie de l'IA en production.

9 min de lectureIA · Production · Infrastructure

Le Chain of Thought (CoT) est une technique qui fait générer aux modèles de langage des étapes intermédiaires avant de répondre. Bien qu'elle améliore les benchmarks, des recherches récentes démontrent qu'il ne s'agit pas d'un raisonnement authentique : c'est une contrainte statistique qui imite la forme de la pensée humaine.

Pour les entreprises qui déploient de l'IA en environnement de production, comprendre cette différence n'est pas un débat philosophique. C'est une décision d'architecture qui affecte la fiabilité, le coût et le risque opérationnel. Chez SIXE, nous concevons des infrastructures critiques depuis plus de 15 ans, avec zéro tolérance à la panne. Cette expérience nous a appris une règle qui s'applique aussi bien à un cluster IBM Power qu'à un agent IA : ne jamais faire confiance à un seul composant pour ce qui ne doit pas tomber.

01 · Définition

Qu'est-ce que le Chain of Thought et pourquoi ressemble-t-il à du raisonnement ?

Lorsque vous activez le mode « raisonnement » ou « thinking » dans des modèles comme GPT-5, Claude ou DeepSeek, le modèle génère un monologue intermédiaire avant de répondre : « bien, d'abord j'analyse X... maintenant je considère Y... attendez, laissez-moi vérifier Z... ». Dans la littérature technique, cela s'appelle Chain of Thought (CoT), littéralement « chaîne de pensée ».

Le problème est que ce n'est pas penser. C'est générer du texte avec la forme statistique du raisonnement humain. Le modèle a vu des millions d'exemples de raisonnement étape par étape pendant son entraînement et a appris à reproduire ce schéma. Quand vous lui demandez de « réfléchir », ce qu'il fait réellement est reconnaître la catégorie du problème et remplir le patron statistique le plus adapté.

Un exemple concret : si vous posez à un modèle « raisonneur » un problème de dimensionnement de stockage Ceph avec 12 OSD, réplication 3 et tolérance à la panne de 2 nœuds, il vous renverra quatre paragraphes impeccables avec des formules, des considérations sur les domaines de panne et un chiffre final. Cela ressemble à de la pensée structurée. Ce qu'il a fait, c'est détecter « problème de dimensionnement Ceph » et appliquer le patron statistique vu dans des centaines de documents techniques similaires.

Pourquoi ça marche ? Parce que la plupart du temps, la réponse est correcte. La question est ce qui se passe quand le problème sort du manuel.

02 · Les preuves

Les LLM raisonnent-ils vraiment ? Ce que disent les études

Le CoT fonctionne. Il améliore les benchmarks de manière mesurable. La question pertinente n'est pas s'il fonctionne, mais pourquoi il fonctionne. Et la réponse des études les plus rigoureuses est inconfortable.

Le CoT comme béquille statistique

Une équipe d'Arizona State University a démontré que le CoT excelle lorsque les données du problème se trouvent dans la distribution d'entraînement. Dès que le problème sort de la zone connue, les performances s'effondrent. C'est la différence entre un système qui a mémorisé des solutions et un autre qui comprend véritablement les principes sous-jacents.

Le CoT comme contrainte architecturale

Le CoT n'est pas du raisonnement abstrait : c'est une contrainte qui oblige le modèle à imiter la forme du raisonnement. Forcer le modèle à écrire « premièrement... deuxièmement... par conséquent... » fait que chaque token généré influence le suivant avec plus de cohérence. C'est une astuce architecturale qui améliore la cohérence interne du texte, pas un acte cognitif. L'article Chain-of-Thought Reasoning In The Wild Is Not Always Faithful documente comment le CoT peut donner une image incorrecte du processus réel que suit le modèle pour arriver à ses conclusions.

Conclusion technique

Le CoT est utile pour de nombreuses tâches. Mais ce n'est pas du raisonnement. C'est de la cohérence formelle avec l'apparence de la logique.

03 · Le décoratif

Que sont les « étapes décoratives » du raisonnement IA ?

Un article d'octobre 2025 publié par des chercheurs d'UC Berkeley et UC Davis a introduit le concept de decorative thinking steps (étapes de pensée décoratives), et leur découverte est particulièrement pertinente pour quiconque évalue des modèles d'IA pour la production.

Les chercheurs ont découvert que de nombreuses étapes intermédiaires du CoT sont littéralement décoratives. Le modèle écrit des choses comme « attendez, laissez-moi vérifier... je crois que j'ai fait une erreur... je vais recalculer », puis ignore complètement cette autocorrection et livre la réponse qu'il avait déjà décidée en interne.

La démonstration a été élégante : ils ont délibérément perturbé les étapes intermédiaires (changé des chiffres, altéré la logique) et vérifié si la réponse finale changeait. Dans de nombreux cas, elle ne changeait pas. La conclusion était déjà prise. La chaîne de pensée était générée après coup, comme rationalisation a posteriori.

Touchez chaque étape pour découvrir si elle est réelle ou décorative
"Hmm, attendez. Je crois que je me suis trompé sur le facteur de réplication. Laissez-moi recalculer depuis le début..."
Touchez pour révéler
Décoratif Le modèle avait déjà la réponse. L'« autocorrection » n'a pas changé le résultat final. C'est du théâtre narratif.
"Capacité brute = 12 × 8 To = 96 To. Avec réplication 3 : 96 / 3 = 32 To utiles."
Touchez pour révéler
Real Cette étape contient le calcul qui détermine la réponse finale. TTS élevé : le résultat en dépend.
"Je vais vérifier ma réponse étape par étape pour m'assurer que je n'ai commis aucune erreur de calcul dans l'estimation précédente..."
Touchez pour révéler
Décoratif Pure formule rhétorique. Le modèle ne réexécute aucun calcul : il a déjà émis les tokens de la réponse. Il ajoute simplement des mots qui ressemblent à de la rigueur.
"Question intéressante. Avant de répondre, je vais considérer plusieurs angles : le domaine de panne, l'équilibrage des OSD et le surcoût des métadonnées..."
Touchez pour révéler
Décoratif Énumérer des facteurs sans les traiter n'est pas de l'analyse. C'est la forme statistique de ce que ferait un expert. Le modèle a déjà choisi sa réponse.
"Avec tolérance à la panne de 2 nœuds et 4 OSD par nœud, le pire cas perd 8 OSD. Capacité minimale garantie : (12−8) × 8 / 3 ≈ 10,7 To."
Touchez pour révéler
Real Introduit de nouvelles variables (nœuds, OSD par nœud) qui changent effectivement le résultat. Sans cette étape, la réponse serait différente.

Un résultat concret de l'étude : sur le dataset AIME, seuls 2,3 % des étapes de raisonnement du CoT avaient une influence causale réelle sur la prédiction finale du modèle. Le reste était de la décoration. (Source : Can Aha Moments Be Fake?, UC Berkeley)

Implication directe

Qu'un modèle explique bien pourquoi il est arrivé à une conclusion ne signifie pas que cette conclusion soit correcte. L'explication est générée en même temps que (ou après) le résultat, et dans de nombreux cas c'est une justification construite sur une réponse prédéterminée.

04 · Apple

« The Illusion of Thinking » : l'étude d'Apple qui change tout

Si les étapes décoratives démontrent que le CoT ne garantit pas le raisonnement même quand il donne la bonne réponse, l'étude d'Apple va plus loin : elle montre que lorsque le problème se complique vraiment, les modèles abandonnent.

En juin 2025, Apple a publié The Illusion of Thinking, une étude qui a soumis des modèles de raisonnement de dernière génération à des puzzles classiques d'informatique : la Tour de Hanoï, des problèmes de traversée de rivière et d'autres exercices que tout étudiant de première année résout avec un crayon et du papier.

PERFORMANCE PAR COMPLEXITÉ — DONNÉES APPLE « ILLUSION OF THINKING » (2025) 100% 75% 50% 25% 0% 88% 72% Facile 55% 82% Moyenne 8% 10% Difficile Sans CoT Avec CoT
Performance des modèles avec et sans CoT par complexité — Basé sur les données d'Apple ML Research, « The Illusion of Thinking », juin 2025
Faites glisser le curseur — comment le CoT performe-t-il selon la complexité ?
Facile Moyenne Difficile
Sans CoT
88%
Avec CoT
72%
El modelo sin CoT gana. El "pensamiento" extra solo añade coste y latencia.

La découverte la plus significative est la troisième. Les modèles « raisonneurs » ne se contentent pas d'échouer sur les problèmes complexes — ils réduisent l'effort computationnel précisément quand ils devraient l'augmenter. C'est l'équivalent d'un système de monitoring qui cesse de générer des alertes quand l'infrastructure en a le plus besoin.

Il convient de noter que l'article a suscité un débat : une équipe du CSIC à Madrid a répliqué une partie des expériences et a nuancé que certains échecs étaient dus aux limites de tokens de sortie, pas à des limitations cognitives pures. Mais les conclusions de fond — que la performance s'effondre avec la complexité et que le CoT ne passe pas à l'échelle de manière prévisible — ont tenu.

05 · Coûts

Vaut-il la peine de payer pour des modèles de raisonnement ?

Cela dépend. Et c'est précisément la réponse que la plupart des fournisseurs ne veulent pas vous donner.

Un cas illustrant le risque : une entreprise européenne a monté un agent « raisonneur » pour classifier des tickets de support. La chaîne de pensée générée par le modèle était narrativement impeccable. Le problème est que 30 % des tickets finissaient dans la mauvaise file, et le modèle expliquait avec une éloquence impeccable pourquoi cette classification erronée était la bonne. Narration parfaite, résultat erroné.

Cela se produit parce que nous confondons qualité de l'explication avec qualité de la décision. Ce sont deux choses différentes. Un modèle peut produire un raisonnement formellement impeccable et arriver à une conclusion incorrecte, exactement comme une présentation aux graphiques spectaculaires peut défendre une mauvaise stratégie.

Règle pratique

Avant de payer pour des modèles de raisonnement, benchmarkez avec votre cas réel. Les supports marketing des fournisseurs montrent les résultats de leurs meilleurs jours. Vos données, votre casuistique et vos cas limites déterminent si le surcoût est justifié.

06 · Perspective

L'IA est-elle inutile alors ?

Non. Et il est important de bien le comprendre, car le pendule peut basculer dans l'autre sens tout aussi facilement.

Qu'un LLM ne raisonne pas comme un humain ne signifie pas qu'il soit inutile. Cela signifie qu'il faut comprendre exactement ce qu'il fait pour l'utiliser correctement.

Un système IBM Power10 sous AIX ne « pense » pas aux charges de travail. Il n'a pas d'intuition. Ce qu'il a, c'est une architecture RISC haute performance, une bande passante mémoire qu'un x86 équivalent ne peut égaler, et une fiabilité (RAS) de niveau mainframe. Si vous comprenez ce qu'il fait, vous l'utilisez pour ce qu'il vaut : bases de données critiques, HPC, inférence IA à l'échelle. Sinon, vous l'utilisez comme un serveur x86 coûteux en vous demandant pourquoi il ne performe pas.

C'est exactement la même chose pour les LLM. Ce sont des processeurs de langage extraordinaires. Ils synthétisent, traduisent, rédigent, classifient et extraient des motifs textuels à une vitesse qu'aucune équipe humaine ne peut égaler. C'est réel, cela a une valeur mesurable et cela transforme les opérations dans tous les secteurs.

Ce qu'ils ne sont pas, ce sont des agents pensants dotés d'une compréhension authentique du monde. Et vendre le second quand on a le premier, c'est ce qui crée une bulle d'attentes qui, tôt ou tard, se corrigera.

07 · En production

Comment utiliser l'IA en production sans tomber dans le piège ?

Dans le monde de l'infrastructure critique — IBM Power, AIX, clusters haute disponibilité — il y a un principe qui ne faillit jamais : concevez avec de la redondance. On ne fait jamais confiance à un seul composant pour ce qui ne doit pas tomber.

1. N'utilisez pas l'explication comme garantie de la réponse

L'explication du modèle est générée en même temps que (ou après) le résultat. Souvent c'est une rationalisation a posteriori. Si le système prend des décisions critiques, vous avez besoin d'une vérification indépendante. Peu importe la qualité de l'explication.

2. Benchmarkez avec votre cas réel avant de choisir un modèle

Pour les tâches simples, le modèle bon marché peut surpasser le modèle coûteux. Pour les tâches moyennes, le CoT compense. Pour les tâches très complexes, les deux échouent. Le seul moyen de le savoir est de tester avec vos données réelles, pas celles du fournisseur.

3. Concevez des architectures avec vérification externe

Si votre architecture IA se résume à « je demande au modèle et je fais confiance à sa réponse », vous n'avez pas d'architecture. Un déploiement sérieux d'IA inclut la validation croisée, des règles métier comme couche de contrôle, des alertes quand la confiance du modèle baisse, et des humains dans la boucle pour les décisions critiques.

4. Exigez des preuves, pas des promesses

Le marché de l'IA est rempli d'affirmations extraordinaires sans preuves proportionnelles. Un fournisseur sérieux vous montre des benchmarks sur votre type de données. Un fournisseur moins sérieux vous montre une démo spectaculaire avec des données préparées.

08 · Notre méthodologie

Comment évaluons-nous les modèles d'IA pour les environnements de production ?

Chez SIXE, nous appliquons à l'IA les mêmes critères que nous appliquons depuis plus de 15 ans à tout composant d'infrastructure critique :

  • Tests avec les données réelles du client, pas avec des datasets génériques ni des démos préparées.
  • Mesure de performance sur les cas limites, pas uniquement sur le cas nominal. Les erreurs n'apparaissent pas dans la médiane, elles apparaissent aux extrêmes.
  • Architecture redondante toujours. L'IA est une couche supplémentaire du système, pas le système entier. Elle se complète par des règles métier, de la validation croisée et une supervision humaine là où la décision est critique.
  • Sélection du modèle par cas d'usage, pas par le marketing. Un modèle avec CoT peut être parfait pour l'analyse de texte complexe et totalement inutile (et plus cher) pour de la classification simple.
  • Infrastructure dimensionnée pour l'inférence. Un modèle d'IA est aussi bon que l'infrastructure qui le soutient. Nous l'avons vérifié de première main avec vLLM sur IBM Power et avec Ceph comme backend de stockage pour l'IA.
Résumé

Pour les dirigeants pressés

L'essentiel en 6 points

→ Le Chain of Thought n'est pas de la pensée : c'est la forme statistique de la pensée, une contrainte qui améliore la cohérence du texte généré.

Apple a démontré que les modèles de raisonnement s'effondrent face aux problèmes complexes et réduisent leur effort précisément quand ils devraient l'augmenter.

Seuls 2,3 % des étapes de raisonnement ont une influence causale sur la réponse du modèle. Le reste est de la décoration.

Ne payez pas pour du « raisonnement » sans le mesurer sur votre cas d'usage concret avec vos données réelles.

N'utilisez jamais l'explication du modèle comme garantie que la réponse est correcte.

Concevez avec vérification externe. L'IA est un outil extraordinaire, pas un oracle.

Sources

Références et articles cités

Apple Machine Learning Research. The Illusion of Thinking: Understanding the Strengths and Limitations of Reasoning Models via the Lens of Problem Complexity. Juin 2025. machinelearning.apple.com

Zhao, C. et al. (Arizona State University). Is Chain-of-Thought Reasoning of LLMs a Mirage? A Data Distribution Lens. Août 2025. arxiv.org/abs/2508.01191

Zhao, J. et al. (UC Berkeley, UC Davis). Can Aha Moments Be Fake? Identifying True and Decorative Thinking Steps in Chain-of-Thought. Octobre 2025. arxiv.org/abs/2510.24941

Arcuschin, I. et al. Chain-of-Thought Reasoning In The Wild Is Not Always Faithful. Mars 2025. arxiv.org/abs/2503.08679

Dellibarda Varela, I. et al. (CSIC, Madrid). Rethinking the Illusion of Thinking. Juillet 2025. arxiv.org/abs/2507.01231

Dernière mise à jour :


IA en production

Besoin d'évaluer comment intégrer l'IA dans votre infrastructure ?

Chez SIXE, nous concevons des architectures IA avec la même philosophie que nous appliquons à tout système critique : redondance, vérification externe et benchmarks réels. Parlez-nous de votre cas.

Serveurs et stockage en stock | Livraison < 30 jours

Disponibilité · Mai 2026

Serveurs et stockage en stock. Livrés en moins de 30 jours.

La crise d'approvisionnement en SSD et la demande croissante d'infrastructure pour l'IA portent les délais de livraison du secteur à 3–6 mois. Chez SIXE, nous avons du matériel disponible, nous le configurons en interne et nous le livrons en moins de 30 jours.

8 min de lectureStockage · Serveurs · Infrastructure

Si vous cherchez à acheter un serveur rack ou une baie de stockage entreprise et que votre fournisseur habituel vous annonce des semaines ou des mois de délai, ce n'est pas un cas isolé. C'est la nouvelle normalité.

La bonne nouvelle : nous avons du stock. Serveurs IBM Power10 et Power11, Dell PowerEdge, Lenovo ThinkSystem. Baies IBM FlashSystem sur toutes les gammes. Configurés par nos propres ingénieurs et prêts pour la production.

<30
Jours de livraison
garantie
3–6
Mois de délai moyen
du secteur
100%
Configuration
interne — sans intermédiaires
01 · Contexte

Pourquoi obtenir du matériel est un vrai problème en 2026

La crise d'approvisionnement en matériel ne s'est pas terminée avec la pandémie. Elle s'est transformée. En 2026, les puces ne manquent plus, mais la demande mondiale en capacité de calcul et de stockage pour l'IA absorbe la production de SSD, de mémoire et de composants serveur à un rythme que la chaîne d'approvisionnement ne peut pas suivre.

Les conséquences pour toute entreprise devant renouveler ou étendre son infrastructure on premise sont concrètes :

  • Projets de migration bloqués faute de matériel disponible.
  • Contrats de maintenance expirés sans équipement de remplacement en vue.
  • Extensions de capacité arrivant trop tard pour les engagements métier.
  • Prix en hausse sur le marché dû à la pénurie de SSD flash et NVMe.
Délais de livraison réels — secteur vs SIXE (mai 2026)
Stockage
all-flash
SIXE
FlashSystem
Serveur GPU
(IA)
SIXE
Serveurs
Serveur rack
x86
SIXE
Dell / Lenovo
Secteur — délai élevé
Secteur — variable
SIXE — stock propre
Fait essentiel

IBM conçoit et fabrique ses propres modules flash (FlashCore Modules). Contrairement à Dell, HPE ou NetApp — qui dépendent de fournisseurs tiers de SSD — IBM contrôle sa propre chaîne d'approvisionnement en stockage flash. Cela se traduit directement par des délais de livraison plus courts et prévisibles pour les Business Partners IBM comme SIXE.

02 · Stockage

Baies de stockage IBM FlashSystem en stock

S'il y a un produit où l'urgence est maximale et où l'avantage de livraison de SIXE fait la plus grande différence, c'est le stockage entreprise. La pénurie de SSD NVMe allonge les délais de toutes les baies all-flash du marché. Mais IBM fabrique ses propres unités flash — et cela nous permet d'avoir du stock quand les autres n'en ont pas.

Baies de stockage IBM FlashSystem — stockage flash all-flash NVMe avec FlashCore Modules de cinquième génération
IBM FlashSystem — génération 2026 avec FlashCore Module 5 (FCM5)

Entrée de gamme : FlashSystem 5015 et 5045

La porte d'entrée du stockage flash entreprise. Une baie 2U à double contrôleur avec compression, déduplication et analytique prédictive par IA incluse. Idéale pour le stockage PME, la sauvegarde ou la consolidation de charges de travail mixtes. Vérifier la disponibilité et les conditions.

Milieu de gamme : FlashSystem 5200 et nouveau 5600

Pour les entreprises qui ont besoin de performances réelles. Le nouveau FlashSystem 5600 intègre les FlashCore Modules de cinquième génération (FCM5) au format NVMe EDSFF avec des capacités allant jusqu'à 105 To par module. Détection de ransomware au niveau matériel en moins d'une minute, snapshots immuables (safe-guarded copies) et chiffrement au repos en standard.

Entreprise : FlashSystem 7200/7600 et 9600

Pour les environnements critiques : SAP HANA, bases de données Oracle, usines d'IA, HPC. La 9600 évolue jusqu'à des centaines de PB avec des latences inférieures à 100μs.

Protection anti-ransomware matérielle

Toutes les baies FlashSystem intègrent la détection de menaces au niveau des I/O, sous le système d'exploitation et le système de fichiers. Les safe-guarded copies créent des snapshots immuables qui ne peuvent être ni supprimés ni modifiés, même avec un accès root.

Au-delà des baies

Nous proposons également IBM Storage Scale (GPFS) pour le HPC et l'inférence IA, Storage Protect et Storage Defender pour la sauvegarde entreprise, et Storage Fusion pour les architectures Red Hat OpenShift et Kubernetes.

Conditions compétitives

En tant que Business Partner IBM direct, nous avons accès à des conditions que d'autres distributeurs ne peuvent pas offrir. Si vous avez déjà un devis d'un autre fournisseur, contactez-nous avant de décider — nous pouvons vous surprendre.

03 · Serveurs

Serveurs entreprise : IBM Power, Dell PowerEdge, Lenovo

IBM Power10
S1012, S1022, S1024, E1050, E1080. AIX, IBM i et Linux. PowerVM. Consolidation extrême.
En stock
IBM Power11
S1122, S1124, E1150, E1180. Nouvelle génération. IA intégrée et efficacité énergétique.
Nouveau 2026
Dell PowerEdge
T360 (serveur tour), R660, R760 (rack), XE9680 (8× GPU NVIDIA H100 pour l'IA).
En stock
Lenovo ThinkSystem
Serveurs x86 pour virtualisation, bases de données et applications entreprise.
En stock

IBM Power : fait tourner Linux exactement comme un serveur x86

C'est le point où beaucoup de clients hésitent. « Mais c'est du Power… ». Les serveurs IBM Power exécutent Red Hat, SUSE et Ubuntu nativement. Vous installez votre distribution Linux, lancez vos conteneurs, déployez OpenShift ou Kubernetes. L'expérience administrateur est identique.

La différence est en dessous. Un seul serveur Power10 ou Power11 consolide ce qui nécessitait auparavant quatre ou cinq racks de serveurs commodity. PowerVM virtualise avec une fiabilité que VMware ne peut plus promettre — ni facturer, depuis que Broadcom a changé le modèle de licences. Pour quiconque cherche une alternative à VMware sans repartir de zéro avec KVM, Power est l'option la moins risquée.

Dell et Lenovo : x86 quand x86 est la bonne réponse

Tout ne nécessite pas un Power. Pour un serveur tour de PME faisant tourner un ERP local, un Dell T360 résout le problème. Pour le centre de données, les serveurs rack R660 et R760 sont le standard du marché. Et si vous avez besoin d'un serveur GPU pour l'inférence IA on premise, le Dell XE9680 avec 8 GPU NVIDIA H100 est le serveur IA le plus polyvalent disponible aujourd'hui. Vérifier la disponibilité et les conditions.

04 · Catalogue

Ce que nous avons et à quoi ça sert

ProduitCas d'usageDisponibilité
FlashSystem 5015/5045
PME, sauvegarde, consolidation
En stock
FlashSystem 5200/5600
ERP, SAP, virtualisation, IA
En stock
FlashSystem 7600/9600
Mission critique, HPC, Oracle
En stock
Dell T360
Tour, PME, ERP, serveur de fichiers
En stock
Dell R660 / R760
Rack, virtualisation, SGBD
En stock
Dell XE9680
IA on premise, 8× NVIDIA H100
Sur demande
Power10 S1022/S1024
Linux, AIX, IBM i, consolidation
En stock
Power11 S1122/S1124
Nouvelle génération, IA intégrée
En stock
Lenovo ThinkSystem
x86 standard, gestion simplifiée
En stock

Vérifier la disponibilité et les conditions →

05 · Service

Nous ne livrons pas une boîte — nous livrons un système en production

Chaque projet matériel inclut la conception de la solution, la configuration et la validation dans nos locaux, l'installation sur site ou à distance, et le support après-vente. Nous n'expédions pas de matériel non configuré.

Nos ingénieurs — les mêmes qui dispensent la formation officielle IBM et assurent le support L2/L3 — connaissent chaque produit parce qu'ils travaillent avec au quotidien. Si vous devez migrer depuis VMware, depuis une baie d'un autre fabricant ou depuis un serveur en fin de support, nous nous en chargeons.

En option : contrats de maintenance annuels 8×5 ou 24×7 avec SLA garanti.

Sans intermédiaires

Nous sommes un Business Partner IBM direct. Pas de distributeurs, revendeurs ou couches intermédiaires entre votre projet et le fabricant. Cela signifie un accès direct au stock IBM, aux conditions partenaire, et la capacité d'escalader au support fabricant si nécessaire.


Vérifier la disponibilité

N'attendez pas que la chaîne d'approvisionnement empire.

Dites-nous ce dont vous avez besoin — serveur, stockage ou les deux — et nous confirmons la disponibilité et un délai réel sous 24 heures ouvrables.

Storage Scale vs Ceph pour l’inférence IA : comment choisir

Storage Scale vs Ceph · Inférence IA

Storage Scale vs Ceph pour l'inférence IA : comment choisir.

Nous déployons les deux. Nous les exploitons tous les deux en production depuis des années. Et non, la réponse n'est pas « utilisez les deux » : c'est comprendre ce que chacun fait bien, où chacun pèche, et lequel correspond à votre charge de travail.

12 min de lectureStockage · IA · Architecture

La même question revient sous différents déguisements : « Storage Scale ou Ceph pour l'inférence IA ? »

Nous sommes IBM Business Partner. Nous vendons Storage Scale. Nous dispensons aussi des formations Ceph et du conseil Ceph en production. Nous travaillons avec les deux au quotidien, donc ce qui suit vient de la construction d'architectures réelles — pas de la lecture de datasheets.

Voici ce que nous dirions à un client assis en face de nous pour concevoir son architecture de stockage pour l'inférence IA.

01 · En premier

Avant de choisir : ce que l'inférence IA attend du stockage

La plupart des gens commencent par le produit. Nous, on commence par le pattern d'accès, parce que c'est ça qui détermine si le choix fonctionne ou vous donne des migraines pendant des années.

Un environnement d'inférence réel — pas une démo Llama sur un laptop — ressemble à ça :

Ce qui vit sur votre stockage d'inférence
# Le plus lourd — lecture parallèle, beaucoup de nœuds models/llama-70b/ ← 40-140 Go en shards safetensors models/embedding/ ← petits mais accédés en permanence# RAG — des millions de petits fichiers, accès mixte rag/raw/ ← PDFs, emails, images, audio rag/parsed/ ← sortie Docling/OCR rag/chunks/ ← fragments, JSONL, parquet rag/embeddings/ ← vecteurs# Opérations — batch, logs, adapters batch-jobs/ ← entrée/sortie batch inference checkpoints/ ← adaptateurs LoRA, fine-tuning logs/ ← traçabilité, évaluation

Et tout ça est consommé par un zoo de processus : des nœuds GPU avec vLLM ou TGI, des nœuds CPU, Spark ou Ray en prétraitement, des pipelines Docling et OCR, la base vectorielle, des applications legacy qui entrent par NFS, et quelqu'un de la conformité qui veut voir un PDF depuis Windows en SMB.

Si votre setup ressemble à ça — beaucoup de consommateurs, beaucoup de protocoles, des données partagées — c'est ce pattern qui doit guider la décision. Pas le prix par To ni le logo du fournisseur.

02 · Storage Scale

Où Storage Scale gagne pour l'inférence IA

POSIX natif : vos frameworks attendent un répertoire, pas un bucket

Ça paraît évident jusqu'à ce que vous deviez le mettre en place. Regardez comment les outils que vous allez utiliser chargent les modèles :

Comment les frameworks réels chargent les modèles
# HuggingFace Transformers model = AutoModel.from_pretrained("/models/mistral-7b")# vLLM vllm serve /models/Meta-Llama-3-8B-Instruct# Triton Inference Server model_repository: /models/triton-repo/

Ils demandent un chemin. Un répertoire. Pas un endpoint S3. Storage Scale (anciennement GPFS) est un système de fichiers parallèle POSIX natif. Ce /models est un répertoire partagé que tous les nœuds lisent simultanément, avec un accès concurrent réel, sans copies intermédiaires. Rien à inventer.

IBM Storage Scale — documentation officielle

Zéro copie entre couches : l'argument le plus convaincant

Avec Ceph S3, le schéma typique pour servir un modèle : télécharger depuis le bucket → écrire sur disque local ou PVC → démarrer le moteur d'inférence → servir. Trois étapes avant la première requête. Et si vous avez 16 nœuds, les 16 téléchargent leur copie.

Avec Storage Scale, le moteur d'inférence pointe vers /gpfs/models/llama-70b/ et démarre. C'est tout. Pas de téléchargement, pas de cache, pas de « ce nœud a-t-il la dernière version ? ». Quand vous mettez le modèle à jour, vous le faites une fois et tous les nœuds le voient.

C'est particulièrement visible quand vous itérez — changement de modèles, test d'adaptateurs LoRA, rotation entre configurations. Avec le cache local, vous finissez par maintenir des scripts de synchronisation, de l'invalidation et du nettoyage de disque. Avec un système de fichiers parallèle, il n'y a rien à maintenir.

Multi-protocole sur le même fichier

C'est ce qui résout le casse-tête enterprise. Un même fichier dans Storage Scale peut être consommé par POSIX (nœud GPU), par S3 (app moderne), par NFS (équipe data), par SMB (quelqu'un sous Windows) et par CSI (pod Kubernetes). Le même fichier. Pas une copie par protocole. Pas un namespace différent par interface.

IBM implémente cela via Cluster Export Services (CES), qui expose l'accès S3, NFS et SMB sur les mêmes données du système de fichiers parallèle.

Métadonnées : quand vous avez des millions de petits fichiers

Le RAG enterprise, ce n'est pas « trois PDFs dans un bucket ». Ce sont des millions de documents, millions de chunks, millions d'embeddings, fichiers de configuration, index auxiliaires, shards, logs. Des opérations intensives sur de grands répertoires avec beaucoup de petits fichiers. Storage Scale résout ce problème dans les environnements HPC depuis des décennies — Summit, Sierra et d'autres supercalculateurs tournaient sur GPFS. CephFS peut gérer ça, mais d'après notre expérience, il faut beaucoup plus de travail de conception pour éviter les problèmes de performance.

03 · Ceph

Où Ceph gagne pour le stockage IA

Stockage objet massif : du vrai S3, pas du S3 en option

Ceph est né comme stockage distribué pour objets, blocs et fichiers. Son RGW (RADOS Gateway) fournit une API S3 complète, avec lifecycle policies, versioning, multi-tenancy, IAM — tout ce qu'il faut pour un object store sérieux. Ce n'est pas un accessoire. C'est le cœur du produit.

Si votre pipeline d'inférence est S3-natif — les modèles téléchargés depuis un bucket, les datasets lus par API, les résultats écrits comme objets — Ceph fait très bien le travail. Un cluster Ceph bien conçu scale horizontalement à des centaines de Po en ajoutant des nœuds commodity.

Coût par To : Ceph l'emporte nettement

Soyons directs : Storage Scale coûte plus cher. Il faut des licences IBM, du matériel avec des exigences spécifiques, et des gens qui savent l'opérer (il n'y en a pas beaucoup). Ceph tourne sur du matériel commodity, n'a pas de coût de licence logicielle, et une équipe avec une solide expérience Linux peut l'opérer.

Pour un client avec des pétaoctets de données dont la majorité sont « froides » — datasets d'entraînement, archives historiques, sauvegardes de modèles — ça n'a pas de sens de payer Storage Scale pour des To lus une fois par mois. Ceph avec un erasure coding bien configuré est la bonne réponse.

Kubernetes : Rook rend tout trivial

Pour les équipes qui vivent dans Kubernetes ou OpenShift, Ceph avec Rook est difficile à battre. Un opérateur qui donne RBD (ReadWriteOnce), CephFS (ReadWriteMany) et RGW (S3) depuis un seul cluster. OpenShift Data Foundation (ODF) est littéralement Ceph packagé par Red Hat.

Storage Scale a aussi CSI, mais Rook/Ceph est dans l'écosystème Kubernetes depuis plus longtemps et la communauté est bien plus large. Si votre équipe pense en opérateurs, en Helm charts et en GitOps, Ceph parle leur langue.

Stockage bloc pour VMs et bases de données

Si en plus de l'inférence vous faites tourner OpenStack, de la virtualisation ou avez besoin de volumes bloc pour des bases de données, le RBD de Ceph est ce qu'il y a de mieux. Storage Scale ne joue pas ici — ce n'est pas son terrain.

Échelle

Le CERN exploite plus de 60 Po sur Ceph en production, comme socle de son infrastructure OpenStack. Ils sont passés de quelques Po à l'échelle exabyte en une décennie, en ajoutant des nœuds sans rupture architecturale.

04 · Les limites

Ce que chacun fait mal — et que personne ne veut dire

C'est là que la plupart des articles restent vagues. Pas nous. Nous déployons les deux, et les deux ont des choses qui ne nous plaisent pas.

Ce qui ne nous plaît pas dans Storage Scale

  • C'est cher. Licences IBM, matériel avec des exigences spécifiques, et un rack avec Storage Scale ECE + GPUs représente un investissement conséquent. Pour un pilote IA ou une startup, ça n'a pas de sens.
  • L'exploitation demande un profil HPC. Ce n'est pas que ce soit difficile — c'est un monde différent du cloud-native. Si votre équipe vit dans Kubernetes et n'a jamais touché un système de fichiers parallèle, la courbe d'apprentissage est réelle.
  • S3 n'est pas son point fort. Storage Scale propose l'accès S3 via CES, et ça marche. Mais comparé au RGW de Ceph sur les fonctionnalités S3 pures — lifecycle, multi-tenancy, versioning avancé — Ceph a l'avantage.
  • Stockage bloc : quasi inexistant. Si vous avez besoin de RBD ou de volumes bloc pour des VMs, Storage Scale n'est pas votre outil.

Ce qui ne nous plaît pas dans Ceph

  • CephFS n'est pas GPFS. CephFS fonctionne, mais pour de nombreux clients concurrents faisant de l'I/O parallèle sur des millions de fichiers (le pattern classique IA/HPC), Storage Scale a considérablement plus d'expérience.
  • Le cache local ajoute de la complexité. Si vos modèles vivent dans S3, chaque nœud d'inférence télécharge sa copie. Avec 4 nœuds, c'est trivial. Avec 32, vous entretenez des scripts de synchronisation, contrôlez les versions du cache, et espérez que les disques locaux ne se remplissent pas.
  • Le multi-protocole n'est pas propre. Ceph parle RGW (S3), RBD (bloc), CephFS (fichier) et NFS (via Ganesha). Mais chaque protocole opère sur son propre pool ou namespace. Vous ne pouvez pas lire le même fichier en S3 et en NFS de façon transparente comme avec Storage Scale.
  • Métadonnées sous pression. Des opérations intensives sur des répertoires avec des millions de petits fichiers (le cas RAG) peuvent devenir un goulot d'étranglement dans CephFS si la conception n'est pas bonne.
Piège classique

Monter s3fs ou goofys pour donner une sémantique POSIX à Ceph S3 et pouvoir utiliser from_pretrained() directement. Techniquement ça marche. En production, la sémantique POSIX est partielle, les performances sont imprévisibles et les erreurs sont créatives. Nous ne le recommandons pas comme solution permanente.

05 · Le comparatif

Storage Scale vs Ceph pour le stockage IA : résumé

Critère Storage Scale Ceph
POSIX pour l'IA
Natif
CephFS
Object store S3
Via CES
Natif
Stockage bloc
Non
RBD
Chargement modèles partagé
Direct
Via cache
RAG / beaucoup de fichiers
Fort
Si S3
Multi-protocole / même fichier
Oui
Pas propre
Kubernetes
CSI
Rook
Coût par To
Élevé
Faible
Exploitation
HPC
SRE
Héritage IA/HPC
Décennies
Croissant

En résumé : Storage Scale gagne quand les données sont « vivantes » — beaucoup de processus lisant des modèles partagés, des pipelines POSIX, des environnements mixtes où Kubernetes coexiste avec des applications legacy. Ceph gagne quand les données sont des objets — S3 comme interface principale, modèles mis en cache localement, équipes cloud-native, budget serré.

Utiliser Storage Scale comme un object store bon marché, c'est jeter de l'argent. Essayer de faire de CephFS un système de fichiers parallèle HPC, c'est chercher les ennuis. Chacun est très bon dans ce qu'il fait.

06 · Notre avis

Ce que nous dirions à un client qui nous pose la question aujourd'hui

Si on nous pousse dans nos retranchements : pour l'inférence IA en environnement enterprise avec des données partagées et du RAG, Storage Scale pose moins de problèmes. Les modèles sont vivants, partagés, accessibles par le protocole dont chaque consommateur a besoin. Pas de scripts de synchronisation, pas de prières sur le cache.

Mais si votre pattern est vraiment cloud-native — pods stateless, S3 comme source de vérité, une équipe SRE qui sait exploiter Ceph — alors Ceph est la bonne réponse et vous coûtera considérablement moins cher. On ne le dit pas pour être polis : on l'a vu fonctionner comme ça en production de nombreuses fois.

Et si votre environnement traite des données sensibles sur IBM Power, s'intègre avec DB2 ou Oracle, et que l'inférence va cohabiter avec des charges HPC ou analytics — Storage Scale n'a pas de rival réel. C'est son terrain naturel. Storage Scale combiné avec Content-Aware Storage dans IBM Fusion commence à transformer le stockage en moteur actif de préparation de données pour le RAG.


Storage Scale ou Ceph ?

Ça dépend. Parlez-nous de votre cas et on vous dit lequel.

Nous exploitons les deux en production. Décrivez votre charge de travail et nous vous orienterons.

IBM Fusion et NVIDIA Blackwell : infrastructure IA et vector database

IBM Storage · NVIDIA · IA

IBM Fusion & NVIDIA Blackwell : le stockage devient un moteur de vector database pour l'IA.

GTC 2026 a révélé une alliance IBM-NVIDIA bien plus profonde qu'il n'y paraît. Fusion n'est plus du simple stockage pour conteneurs : avec Content-Aware Storage et les GPU Blackwell, le stockage devient un moteur actif de préparation de données pour l'IA — et notamment un moteur de vector database embarqué dans votre infrastructure.

8 min de lectureStockage · IA · Infrastructure

Le 16 mars, IBM montait sur scène à GTC 2026 à San José avec une annonce passée relativement inaperçue hors des cercles de stockage : une collaboration élargie avec NVIDIA couvrant les GPU Blackwell Ultra sur IBM Cloud, l'analytique de données native GPU, le traitement intelligent de documents et les déploiements on-premises pour les secteurs réglementés.

Trois semaines plus tard, IBM publiait un Redbook technique détaillant l'intégration de Storage Scale, Fusion et Content-Aware Storage (CAS) avec la NVIDIA AI Data Platform. Et récemment, IBM, NVIDIA et Samsung ont démontré un système CAS capable de gérer 100 milliards de vecteurs sur un seul serveur — ce qui positionne Fusion comme une infrastructure de vector database on-premises à l'échelle enterprise.

Qu'est-ce que cela signifie concrètement ? S'agit-il d'un vrai changement architectural ou de marketing de keynote ? Voici notre analyse.

L'annonce

GTC 2026 : IBM et NVIDIA passent à la vitesse supérieure sur l'IA enterprise

Ce qu'IBM a annoncé à GTC n'est pas un partenariat générique. Ce sont cinq axes de travail concrets qui affectent directement la façon dont les entreprises déploient une infrastructure IA on-premises :

  • GPU NVIDIA Blackwell Ultra sur IBM Cloud — disponibles depuis Q2 2026 pour l'entraînement à grande échelle, l'inférence haute performance et le raisonnement IA.
  • Content-Aware Storage (CAS) intégré dans la prochaine version de Fusion — le stockage cesse d'être passif et commence à traiter les données pour l'IA, y compris la vectorisation.
  • Red Hat AI Factory avec NVIDIA — OpenShift + GPU NVIDIA comme plateforme standardisée pour déployer l'IA en production.
  • IBM Consulting + NVIDIA Blueprints — services d'intégration pour passer de l'IA en pilote à l'IA en production.
  • Support de la NVIDIA AI Data Platform (AIDP) — un design de référence intégrant compute, réseau et stockage dans un système unifié pour l'IA.
Fuente: IBM Newsroom, 16 marzo 2026

Le point le plus impactant pour l'infrastructure on-premises : Fusion HCI intègre désormais des serveurs GPU avec NVIDIA H200 et RTX Pro 6000 Blackwell Edition. Ce n'est pas une feuille de route — le matériel est disponible. Chaque système supporte jusqu'à 4 serveurs GPU avec 8 cartes chacun.

Pour comprendre comment toutes les pièces s'assemblent, voici la stack complète qu'IBM a définie comme architecture de référence AIDP sur Fusion :

Rob Davis, VP Storage Networking Technology chez NVIDIA, a été direct : les agents IA ont besoin d'accéder, de rechercher et de traiter des données à grande échelle, et aujourd'hui ces étapes se déroulent dans des silos séparés. L'intégration de CAS avec NVIDIA orchestre données et compute via un réseau optimisé pour surmonter ces silos.

La technologie

Content-Aware Storage : quand le stockage comprend ce qu'il contient

C'est la partie la plus intéressante de l'annonce et la moins couverte. Jusqu'ici, le stockage enterprise était un dépôt passif : il conservait des fichiers et les servait sur demande. Pour faire du RAG (Retrieval-Augmented Generation) ou alimenter des modèles d'IA avec des données d'entreprise, vous aviez besoin d'un pipeline séparé qui extrayait les documents, les découpait en chunks, les vectorisait et les injectait dans une vector database externe.

CAS élimine ce pipeline externe. Il opère en deux phases — visualisé ci-dessous :

Phase 1 : Ingestion et préparation continues

CAS surveille des dossiers sur Storage Scale (ou sur stockage externe via AFM) et détecte les modifications en temps réel. Lorsqu'un document est modifié ou ajouté, CAS le traite automatiquement : extraction de contenu texte, tableaux, graphiques et images via NVIDIA NeMo Retriever, chunking sémantique, et conversion en embeddings haute dimension. Les vecteurs sont indexés dans une vector database gérée par CAS sur Storage Scale ECE.

Phase 2 : Requête et récupération

Lorsqu'un utilisateur ou un agent IA pose une question, CAS effectue une recherche sémantique, par mots-clés (BM25) ou hybride. Les résultats passent par un reranker NVIDIA optimisé pour la pertinence maximale. Le point critique : les vecteurs héritent des contrôles d'accès (ACL) des documents originaux. Si un utilisateur ne peut pas lire un fichier, il ne voit pas non plus ses vecteurs dans les résultats RAG.

Fuente: IBM Redbook MD248598 — Enabling AI Inference at Scale, abril 2026
Pourquoi c'est important

La plupart des déploiements RAG enterprise échouent sur deux points : les données deviennent obsolètes parce que personne ne met à jour la vector database, et il n'y a pas de contrôle d'accès sur les vecteurs. CAS résout les deux problèmes au niveau de l'infrastructure, pas de l'application. C'est un vrai changement de paradigme.

Démo IBM + NVIDIA + Samsung
100mil millones
de vecteurs sur un seul serveur avec compute et stockage découplés, indexation hiérarchique accélérée par GPU. À cette échelle, les indices RAG traditionnels deviennent ingérables.
Fuente: SDxCentral, abril 2026
Le matériel

H200, RTX Pro 6000 et Blackwell Ultra : quelle GPU va où

Il y a trois lignes de GPU NVIDIA dans l'écosystème IBM à ne pas confondre. Chacune a un rôle distinct — cliquez sur chaque onglet pour voir où elle se déploie et à quoi elle sert :

NVIDIA Blackwell Ultra
GTC 2026 · Cloud-first
IBM Cloud
DisponibilitéIBM Cloud · Q2 2026
Cas d'usageEntraînement à grande échelle, inférence haute performance, raisonnement IA
DéploiementCloud uniquement · pas d'option on-prem dans Fusion
IntégrationRed Hat AI Factory + serveurs VPC avec conformité réglementaire
Si votre charge de travail peut aller dans le cloud et que vous n'avez pas de contraintes de résidence de données, Blackwell Ultra sur IBM Cloud est l'option la plus puissante du catalogue. Mais si vos données ne peuvent pas quitter le périmètre, consultez les deux autres onglets.
NVIDIA H200
Hopper · Mémoire HBM3e étendue
Fusion HCI on-prem
DisponibilitéFusion HCI · Mai 2026
Cas d'usageEntraînement, fine-tuning et inférence lourde de LLM
Mémoire141 Go HBM3e · 4,8 To/s de bande passante
Configuration2 GPU par serveur · Jusqu'à 4 serveurs par rack
Maximum total32 GPU par système Fusion
La H200 est l'option pour l'entraînement sérieux on-premises. Sa mémoire HBM3e étendue par rapport à la H100 la rend idéale pour les grands modèles qui nécessitaient auparavant un sharding agressif. Dans Fusion HCI, elle accède directement à Storage Scale ECE via un réseau 200 GbE.
NVIDIA RTX Pro 6000
Blackwell Edition · Inférence + visualisation
Fusion + AIDP
DisponibilitéFusion HCI · Mai 2026
Cas d'usageInférence, RAG, vectorisation CAS, vector database, visualisation professionnelle
ArchitectureBlackwell Server Edition · 96 Go GDDR7
Configuration2 GPU par serveur · Jusqu'à 4 serveurs par rack
Stack AIDP+ BlueField-3 DPU · SuperNICs ConnectX-7/8
La RTX Pro 6000 Blackwell est la GPU de la stack AIDP de référence. Elle accélère le chunking sémantique et la vectorisation CAS — en clair, elle alimente votre vector database on-premises. Combinée au BlueField-3 DPU, elle décharge le traitement réseau et stockage du CPU principal. C'est la pièce clé pour le RAG enterprise en production.
Fuente: IBM Redbook MD248598 — Reference Stack AIDP
Ce qu'on ne voit pas dans les keynotes

Le BlueField-3 n'est pas qu'un NIC rapide. C'est un DPU (Data Processing Unit) qui décharge les opérations réseau, stockage et sécurité du CPU principal. Dans un système AIDP, les BlueField-3 accélèrent la communication entre Storage Scale et les GPU, réduisant la latence d'accès aux données pour l'inférence temps réel. C'est une pièce critique qui n'apparaît pas dans les keynotes mais qui fait la différence en performance réelle.

L'analyse

Ce que ça signifie pour l'IA on-premises

En assemblant toutes les pièces, le message d'IBM est clair : Fusion n'est plus un produit de stockage pour conteneurs. Si vous connaissez déjà IBM FlashSystem, C'est une plateforme IA on-premises intégrant compute (OpenShift), accélération (GPU NVIDIA), stockage intelligent (Storage Scale + CAS avec vector database intégrée) et réseau optimisé (Spectrum-X + BlueField-3) dans un appliance unifié.

Pour les organisations qui ne peuvent — ou ne veulent — pas envoyer leurs données dans le cloud, c'est significatif. En particulier dans trois scénarios :

Secteur réglementé

Banque, santé, administration publique. Les données ne peuvent pas quitter le périmètre. Avec Fusion HCI + CAS + GPU NVIDIA, vous pouvez faire du RAG d'entreprise sur des documents internes sans que rien ne sorte du rack. Et les ACL sont appliquées au niveau du vecteur — conformité intégrée, pas rapportée.

IA sur données propriétaires à grande échelle

IBM estime que 80 à 90 % des données d'entreprise sont non structurées. CAS convertit ce volume en données consommables par l'IA de façon continue et automatique, en alimentant une vector database toujours à jour. Ce n'est pas un projet ETL ponctuel — c'est une capacité permanente de l'infrastructure.

Alternative au cloud quand le TCO ne s'additionne pas

IBM répète le chiffre de performances équivalentes à Databricks à 60% du coût. C'est un benchmark interne sur des opérations sélectionnées, donc à prendre avec recul. Mais la logique économique de l'on-premises pour des charges prévisibles et à haut volume reste solide. Si vous savez que vous aurez 30 GPU tournant 24h/24, le TCO on-premises gagne généralement.

Notre lecture

Réel ou marketing ?

Un peu des deux, comme toujours. Ce qui est indiscutablement réel :

  • Le matériel existe y se puede comprar. Las H200 y RTX Pro 6000 están disponibles como servidores GPU para Fusion HCI. No es un roadmap.
  • CAS fonctionne. La démo à 100 milliards de vecteurs est vérifiable. Le Redbook détaille l'architecture étape par étape.
  • NVIDIA AIDP est un design de référence réel avec une adoption précoce en santé (UT Southwestern Medical Center) et en finance.
  • Red Hat AI Factory standardise le déploiement OpenShift + GPU comme plateforme IA — exactement ce que Fusion HCI livre comme appliance.

Ce qui mérite d'être nuancé :

  • CAS n'est pas encore en GA dans Fusion. IBM a dit Q2 2025, puis Q2 2026. Il est intégré dans Storage Scale depuis mars 2025, mais la version embarquée dans Fusion arrive encore.
  • Le chiffre des 60% de coût vs Databricks est un benchmark interne en conditions contrôlées. En production réelle, le bénéfice dépendra de votre charge de travail.
  • Fusion HCI n'est pas bon marché. Un rack avec GPU H200, 16 nœuds de stockage et licences OpenShift représente un investissement considérable. Cela a du sens pour les organisations avec des données sensibles et des charges prévisibles — pas pour un pilote IA.
Notre avis

Ce qui est le plus significatif dans cette vague, ce ne sont pas les GPU — tout le monde en a. C'est CAS. Que le stockage comprenne sémantiquement ce qu'il contient et maintienne une vector database à jour en temps réel avec des ACL héritées — c'est un vrai changement architectural. Si ça fonctionne comme promis (et les démos le suggèrent), ça résout les deux principaux problèmes du RAG enterprise : la fraîcheur des données et la sécurité des accès.

Cela dit, tout le monde n'a pas besoin de Fusion HCI pour en bénéficier. CAS vit dans Storage Scale, qui peut aussi être déployé en mode software-defined sur votre propre matériel. Et si votre volume de données ne justifie pas Storage Scale, Ceph avec un pipeline RAG conventionnel reste une alternative viable et plus économique. D'ailleurs, notre guide sur les agents IA avec n8n montre comment assembler un workflow RAG sans infrastructure lourde — comparez avec ce que Fusion propose pour voir ce qui correspond à votre contexte. Nous couvrons aussi le choix du stockage dans notre comparatif Ceph vs Storage Scale.

Comme toujours, la réponse dépend du volume, de la sensibilité des données et du budget. Nous vous aidons à l'évaluer.


Vous évaluez une infrastructure IA on-premises ?

Décrivez-nous votre cas d'usage. Nous vous aidons à dimensionner.

Fusion HCI, Fusion Software, Storage Scale standalone ou Ceph — selon ce dont vous avez besoin. Nous ne vendons pas une solution unique ; nous vous aidons à choisir la bonne.

SIXE