AI Act : ce qui s’applique le 2 août 2026

/dans /par
AI Act · Juillet 2026

AI Act 2 août : ce qui s'applique vraiment (et ce qui a glissé à 2027).

Pendant des mois, le 2 août 2026 était « le jour du haut risque ». Ce n'est plus le cas : le Digital Omnibus l'a repoussé à décembre 2027. Mais il a laissé intact l'Article 50 — celui qui oblige vos chatbots à s'identifier, vos contenus générés par IA à porter une marque machine-readable et vos deepfakes à être étiquetés. Si votre produit parle, écrit ou dessine, il est temps d'atterrir sur la partie technique avec le conseil de conformité à l'AI Act.

8 min de lecture ●Conformité IA ●

Le calendrier du Règlement (UE) 2024/1689 — l'AI Act — a été modifié il y a un mois et une grande partie du marché ne s'en est pas encore rendu compte. Le Digital Omnibus, approuvé par le Conseil de l'Union européenne le 29 juin 2026, a reporté les obligations de haut risque de l'Annexe III du 2 août 2026 au 2 décembre 2027. Mais l'Article 50 — transparence — a conservé sa date d'origine. Dans notre conseil de conformité AI Act, nous préparons cette partie technique depuis le printemps avec les clients qui ont anticipé.

Les trois dates qui comptent
2 août 2026S'applique dès maintenant
Article 50 · Transparence. Chatbots qui s'identifient, contenus générés par IA marqués machine-readable, deepfakes étiquetés. Amendes jusqu'à 15 M€ ou 3 % du chiffre d'affaires mondial.
2 déc. 2026Cet automne
Article 5 · Nouvelle interdiction. Les systèmes d'IA qui génèrent des images intimes non consenties sont interdits. S'applique à tous les opérateurs, quel que soit le niveau de risque.
2 déc. 2027+16 mois
Annexe III · Haut risque. RH, crédit, biométrie, éducation, services essentiels. Reporté depuis le 2 août 2026 par le Digital Omnibus.
01 · Contexte

Ce qui devait se passer le 2 août

Jusqu'au 29 juin, le calendrier de l'AI Act était connu et ennuyeux : le 2 août 2026 devaient entrer en vigueur les obligations pour les systèmes de l'Annexe III — biométrie, RH, décisions de crédit, éducation réglementée, infrastructures critiques, maintien de l'ordre et services essentiels.

Cela impliquait, pour tout opérateur avec un système classé haut risque, de mettre en production toute une série de dispositifs loin d'être triviaux : gestion des risques, qualité et biais des données, documentation technique, logging automatique des événements, transparence côté utilisateur, supervision humaine effective, précision et cybersécurité, et monitoring post-marché. Le tout avec preuve technique sur le code et l'infrastructure eux-mêmes.

Rien de tout cela ne s'applique en août. Mais une partie de ce qui était attendu — l'Article 50 — reste exactement à sa date.

02 · Digital Omnibus

Ce qui a changé le 29 juin

Le Digital Omnibus est le paquet de simplification numérique approuvé par le Conseil de l'Union européenne le 29 juin 2026. C'est une modification de l'AI Act lui-même. Motif déclaré : désengorger le calendrier face à l'évidence que ni les entreprises ni les autorités nationales compétentes n'allaient être prêtes en août avec les structures techniques et de supervision requises.

La mesure la plus visible : les obligations de haut risque de l'Annexe III, qui devaient entrer en vigueur le 2 août 2026, sont reportées au 2 décembre 2027. Seize mois de plus.

Ne pas confondre avec amnistie

C'est un report, pas une exemption. Le fond du règlement et les obligations ne changent pas. Ce qui change, c'est quand elles sont exigibles. Si votre système est classé haut risque de l'Annexe III, le travail technique reste le même — vous avez juste seize mois de plus pour le rendre présentable. Cette marge disparaît vite quand on ouvre le code base.

Ce qui n'a pas changé avec le Digital Omnibus est tout aussi important : l'Article 50 de transparence conserve sa date d'origine. Et la nouvelle interdiction de l'Article 5 sur les images intimes non consenties reste également au calendrier, pour le 2 décembre 2026.

03 · Article 50

Les trois choses qui entrent bien en vigueur

L'Article 50 du Règlement (UE) 2024/1689 impose des obligations de transparence aux fournisseurs et opérateurs (deployers) de systèmes d'IA — indépendamment du fait que le système soit à haut risque ou non. Trois blocs, et ils sont concrets.

50 · 1

Chatbot qui s'identifie

Les systèmes d'IA conçus pour interagir avec des personnes doivent informer l'utilisateur qu'il parle à une IA, sauf si c'est évident par le contexte. S'applique aux chatbots de support, assistants conversationnels, SVI à voix synthétique et agents dans les applications. Traduction UI : un message d'ouverture clair, pas une mention en pied de page.

50 · 2

Marquage du contenu généré

Les fournisseurs d'IA générative (texte, image, audio, vidéo) doivent marquer leurs sorties dans un format machine-readable permettant de détecter qu'elles ont été générées ou manipulées artificiellement. L'obligation porte sur le fournisseur du modèle, pas sur l'utilisateur final qui demande une image.

50 · 4

Deepfakes étiquetés

Les deployers qui utilisent l'IA pour créer des deepfakes (image, audio ou vidéo qui ressemble faussement à une personne réelle, à un objet ou à un événement) doivent étiqueter le contenu comme généré ou manipulé. Il existe des exceptions étroites pour usage artistique, satirique ou d'application de la loi — ce n'est pas un chèque en blanc.

Portée extraterritoriale

L'Article 50 s'applique à tout système d'IA mis sur le marché ou mis en service dans l'UE, indépendamment de la date de mise sur le marché et du lieu d'établissement du fournisseur. Un modèle entraîné en Californie et proposé en SaaS à des clients européens entre dans le champ d'application. Vivre hors UE ne dispense pas de l'amende si vos sorties arrivent ici.

04 · Sanctions

Combien coûte l'ignorer

L'AI Act ordonne les sanctions en trois paliers (Article 99). Important de ne pas les confondre car le gros chiffre du haut circule beaucoup.

35 M€ · 7 %
Pratiques interdites
(Article 5)
15 M€ · 3 %
Article 50 et autres
infractions
7,5 M€ · 1 %
Information incorrecte
à l'autorité

Les infractions à l'Article 50 relèvent du deuxième palier : jusqu'à 15 millions d'euros ou 3 % du chiffre d'affaires annuel mondial de l'exercice précédent — le montant le plus élevé étant retenu. La supervision et les sanctions relèvent de l'autorité nationale compétente de chaque État membre ; l'organisme précis (et son niveau de préparation) varie d'un pays à l'autre.

05 · Vérification rapide

L'Article 50 vous concerne-t-il ?

Trois questions courtes et vous saurez si vous avez du travail devant vous ou si vous pouvez respirer jusqu'au haut risque de 2027.

Vérification en 3 clics

Aucune télémétrie, aucun cookie, rien n'est envoyé. Tout se résout dans le navigateur.

1. Votre produit dispose-t-il d'un chatbot, assistant conversationnel ou SVI à voix synthétique qui parle avec des personnes réelles ?

2. Votre produit génère-t-il du texte, des images, de l'audio ou de la vidéo avec IA que les utilisateurs finaux voient ou téléchargent ?

3. Votre produit crée-t-il ou distribue-t-il des deepfakes — image, audio ou vidéo qui ressemble à une personne réelle, un objet ou un lieu ?

L'Article 50 s'applique — et sur plusieurs fronts.

Avec deux ou trois blocs cochés, vous avez des obligations de chatbot disclosure, watermarking du contenu et/ou étiquetage des deepfakes. C'est le scénario le plus dense : il faut toucher à l'UI, au pipeline de génération et laisser des logs auditables. Avec priorité et focus, en une semaine on met en place le minimum en commençant par ce qui est le plus visible à l'utilisateur.

→ Diagnostic AI Act avec SIXE

L'Article 50 s'applique sur un bloc précis.

Vous avez une obligation claire. Si le oui portait sur le chatbot, la partie lourde est UX : un message d'ouverture clair plus un log. Si c'était la génération de contenu, la partie lourde est technique : C2PA + watermark + logging. Si c'était les deepfakes, la partie lourde est de processus : étiquetage systématique dans le pipeline de publication.

→ Diagnostic AI Act avec SIXE

Sur l'Article 50, vous pouvez respirer.

Sans chatbot, sans contenu généré par IA côté utilisateur et sans deepfakes, ce bloc ne s'applique pas. Mais attention : si votre IA relève de l'Annexe III (biométrie, RH, crédit, éducation, infrastructures critiques, services essentiels), vous avez rendez-vous le 2 décembre 2027 avec les obligations de haut risque. Et ça, quand on s'y met, c'est bien plus de travail qu'un simple avis de chatbot.

→ Revoir la classification Annexe III

06 · Watermarking

Le vrai problème : aucune technologie ne suffit seule

L'obligation 50(2) — marquer le contenu généré par IA en format machine-readable — semble se résoudre avec une étiquette. Ce n'est pas le cas. Le règlement demande simultanément quatre propriétés qu'aucune technologie connue ne satisfait à la fois : imperceptibilité (ne pas dégrader le contenu), robustesse (survivre à la compression, à l'édition, aux captures d'écran), détectabilité (vérifiable en aval) et traçabilité (permettre d'identifier le générateur et la version).

L'approche pratique que les fournisseurs sérieux adoptent est en couches. Trois, chacune couvrant les modes de défaillance de la précédente.

Couche 1

Métadonnées C2PA

Standard de content provenance porté par Adobe, Microsoft, Sony et d'autres. Signe cryptographiquement les métadonnées qui voyagent avec le fichier : qui l'a généré, avec quel modèle, quand. Survit à la compression. Disparaît avec une capture d'écran ou un ré-encodage sans signature — c'est-à-dire avec presque n'importe quel post social.

Couche 2

Watermark imperceptible

SynthID (Google DeepMind) pour images et audio, techniques similaires pour texte et vidéo. Modifie de façon imperceptible la sortie pour qu'un détecteur la reconnaisse. Survit à la capture d'écran, mais se dégrade avec des manipulations agressives, un recadrage fort ou un mélange de sources.

Couche 3

Logging côté générateur

Enregistrement audité côté fournisseur : quoi a été généré, quand, avec quel prompt, quel modèle, quelle version. La plus ennuyeuse, la plus importante, et celle qui permet de répondre à une réquisition même si les couches 1 et 2 se sont évaporées en route.

Angle SIXE

La couche 3 — logging côté générateur — est là où avoir l'IA on-premise devient un vrai avantage et pas un simple slogan. Sur votre propre stack d'inférence, vous pouvez enregistrer chaque prompt, chaque sortie, chaque modèle et chaque version sans dépendre de l'audit trail d'un fournisseur SaaS qui vous montre ses logs quand il le décide. Et dans RAG avec Docling, la traçabilité du document qui a nourri quelle réponse fait partie de l'architecture dès la conception.

07 · Checklist

Le minimum à avoir en place

Si le quiz vous a dit que l'Article 50 s'applique, voici la checklist avec l'essentiel. Cochez ce que vous avez déjà. Ce qui reste non coché, c'est votre backlog — et ce que nous mettons en place avec les clients dès une mission de démarrage.

Checklist Article 50 · 7 points

0/7 complétés
  • Avis « vous parlez à une IA » sur vos chatbotsMessage d'ouverture clair, pas un astérisque caché. S'applique aussi aux assistants vocaux et SVI synthétiques.
  • Log de session du chatbotDate, système, version du modèle, ID de session. Si l'autorité demande, vous devez pouvoir démontrer que l'avis a bien été affiché.
  • C2PA sur les sorties généréesMétadonnées signées cryptographiquement sur images, audio et vidéo. C'est la couche 1 du watermarking en couches.
  • Watermark imperceptibleSynthID ou équivalent pour ce que C2PA perd quand quelqu'un fait une capture d'écran et la partage sur les réseaux.
  • Logging côté générateurEnregistrement auditable des prompts, sorties, modèle et version chez vous. Ennuyeux à implémenter, indispensable au moment de démontrer. Sur inférence on-premise avec Ceph, OpenStack ou K8s, ça reste dans votre périmètre.
  • Étiquetage des deepfakes dans le pipelineSi vous générez ou distribuez du contenu qui ressemble à des personnes réelles, étiquetez-le dans le flux de publication lui-même. Ne le laissez pas au libre choix de l'éditeur du jour. Avec des agents IA sécurisés, l'étiquetage s'applique comme une politique, pas comme un rappel.
  • Document interne de conformitéUne demi-page expliquant quelles obligations s'appliquent à quels systèmes, qui est responsable et où se trouvent les logs. C'est le point où ISO 42001 s'enchaîne naturellement avec l'AI Act.
Les sept cochés. Si c'est réel et pas de la théorie, votre semaine s'annonce bien. S'il en manquait, notre conseil AI Act démarre justement par là.
08 · Décembre 2026

L'autre date que presque personne ne regarde

Quatre mois après l'échéance de l'Article 50, le 2 décembre 2026, s'active une nouvelle interdiction ajoutée par le Digital Omnibus à l'Article 5 : les systèmes d'IA qui génèrent des images intimes non consenties entrent au catalogue des pratiques interdites du règlement.

Étant une interdiction, elle n'admet pas de nuances par taille ni par niveau de risque préalable du système. Elle s'applique à tous les opérateurs du marché européen — fournisseurs, deployers, importateurs, distributeurs — sans exception. Pas d'Annexe intermédiaire, pas de période de grâce supplémentaire. Interdit.

Elle touche directement des produits et services comme les générateurs d'images de personnes réelles sans consentement, les applications de face-swap sur contenu intime et les outils nudify qui ont proliféré de façon incontrôlée ces deux dernières années. Les fournisseurs de modèles à usage général sont concernés par la voie indirecte des usages prévisibles : si votre modèle peut raisonnablement être utilisé pour cela, les garde-fous techniques ne sont plus optionnels.

09 · Architecture

Pourquoi l'on-premise facilite la paperasse

Aucune des obligations de l'Article 50 ne dépend de l'endroit où se trouve l'IA — elles s'appliquent aux fournisseurs et aux deployers indépendamment de la topologie. Mais le démontrer en dépend. Et c'est là que déployer sur votre propre infrastructure joue en votre faveur pour des raisons très pratiques :

  • Le logging côté générateur (couche 3) vit dans votre système, avec vos politiques de rétention, sans accords d'accès avec des tiers ni limites d'exportation d'un tableau de bord SaaS.
  • La documentation technique du modèle — qui, si le niveau de risque monte, est demandée en détail — est sous votre contrôle : poids, provenance de l'entraînement, évaluations, version. Rien ne dépend de la bonne volonté de votre fournisseur cloud.
  • La gouvernance des données se démontre sur des données qui ne sont pas sorties du périmètre. Pour la santé, la banque et le secteur public, c'est une exigence de facto — l'AI Act ne fait que la mettre par écrit.
  • Les agents auditables avec OPA, LangChain ou CrewAI s'insèrent naturellement dans la supervision humaine effective que le haut risque exigera en 2027.
FAQ

Questions fréquentes

Qu'est-ce qui entre en vigueur dans l'AI Act le 2 août 2026 ?

Les obligations de transparence de l'Article 50. Les chatbots doivent informer l'utilisateur qu'il parle à une IA ; les contenus générés par IA (texte, image, audio, vidéo) doivent être marqués dans un format machine-readable ; les deepfakes doivent être étiquetés comme générés ou manipulés. Le non-respect est sanctionné par des amendes pouvant atteindre 15 millions d'euros ou 3 % du chiffre d'affaires annuel mondial (Article 99.4).

L'application aux systèmes à haut risque a-t-elle été reportée ?

Oui. Le Digital Omnibus, approuvé par le Conseil de l'Union européenne le 29 juin 2026, a reporté les obligations de l'Annexe III (biométrie, RH, crédit, éducation, infrastructures critiques, maintien de l'ordre, services essentiels) du 2 août 2026 au 2 décembre 2027.

L'Article 50 n'a pas été reporté et s'applique toujours le 2 août 2026.

Qu'est-ce que le Digital Omnibus ?

Le paquet de simplification numérique approuvé par le Conseil de l'Union européenne le 29 juin 2026, qui reporte l'applicabilité de plusieurs obligations de l'AI Act et clarifie des aspects opérationnels du règlement. Sa mesure la plus significative est le report des obligations de haut risque de l'Annexe III au 2 décembre 2027.

Combien coûte le non-respect de l'Article 50 ?

Jusqu'à 15 millions d'euros ou 3 % du chiffre d'affaires annuel mondial de l'exercice précédent, le montant le plus élevé étant retenu (Article 99.4). C'est le deuxième palier de sanctions. Le premier palier (35 M€ ou 7 %) est réservé aux pratiques interdites de l'Article 5 — une autre affaire.

Comment satisfaire au marquage machine-readable ?

Avec une approche en trois couches : métadonnées C2PA signées cryptographiquement dans le fichier ; watermark imperceptible type SynthID pour ce que C2PA perd sur les captures d'écran ; et logging audité dans le générateur lui-même. Aucune couche seule ne couvre les quatre exigences du règlement — imperceptibilité, robustesse, détectabilité et traçabilité.

Quelle nouvelle interdiction entre en vigueur le 2 décembre 2026 ?

L'Article 5 ajoute une nouvelle interdiction : les systèmes d'IA qui génèrent des images intimes non consenties. S'applique à tous les opérateurs quel que soit le niveau de risque du système.

L'AI Act s'applique-t-il si mon IA est on-premise ?

Oui. L'AI Act s'applique à tout système mis sur le marché ou mis en service dans l'UE, indépendamment du lieu de déploiement et du lieu d'établissement du fournisseur. Que l'IA soit on-premise n'exempte pas — mais facilite la partie démontrer : logging, traçabilité et audit sont chez vous, pas chez un tiers.

AI Act, NIS2 et ISO 42001, est-ce la même chose ?

Non, mais ils se complètent. NIS2 est la directive européenne de cybersécurité — elle oblige à gérer les risques et à notifier les incidents. ISO/IEC 42001 est la norme internationale de gestion des systèmes d'IA — un cadre de gouvernance. L'AI Act est la loi européenne avec des obligations concrètes par niveau de risque. Les trois se recoupent sur la gouvernance des données, la traçabilité et le logging : bien faire l'un couvre une partie du suivant.

Conformité technique

Votre produit parle, écrit ou dessine avec l'IA ?

Nous cadrons quelles obligations de l'Article 50 s'appliquent à vos systèmes, révisons chatbots et générateurs, mettons en place le pipeline d'inférence avec logging auditable et déployons le watermarking en couches. Nous prenons la partie technique ; l'interprétation juridique reste avec votre conseil.

Conseil AI Act → Voir solutions IA

Quel stockage pour l’IA et le HPC : Ceph, Lustre ou DAOS ?

/dans /par
Infrastructure · Stockage IA / HPC · Open Source

Stockage pour l'IA et le HPC en 2026 : Ceph, Storage Scale, Lustre, DAOS et BeeGFS.

Vous montez un cluster de GPU qui coûte le prix d'un immeuble, puis vous décidez où vivent les données. Cette décision — le système de fichiers — détermine si vos GPU calculent ou attendent. Nous cartographions les cinq grands, à quoi sert chacun et comment ne pas vous tromper.

12 min de lecture●Comparatif technique●

Il y a une scène qui se répète chaque fois que nous auditons une plateforme d'IA ou de HPC. Le client nous montre, non sans fierté, son cluster de GPU flambant neuf. Des chiffres de TFLOPS impressionnants. Et là, nous posons la question ennuyeuse : « et d'où lisent-ils les données ? ». Trop souvent, la réponse est un partage NFS branché sur une machine dans un coin.

Acheter huit GPU qui coûtent le prix d'un appartement et les alimenter en NFS, c'est l'équivalent numérique de mettre le réservoir d'un scooter sur une Formule 1 : toute la puissance est là, mais elle passe la journée au stand. C'est le stockage qui décide si ces GPU travaillent ou attendent — et bien le choisir commence par savoir quelles options existent et à quoi sert chacune.

1 et 2
Places de DAOS sur la liste
de production IO500 (SC25)
×4
Leur score cumulé face
aux 30 systèmes suivants
#1
Lustre, le FS le plus répandu
en supercalcul
50+ Po
Ceph déployé
au CERN
01 · Le vocabulaire qui façonne l'architecture

Quatre notions avant de comparer quoi que ce soit

Le stockage distribué accumule vite le jargon, et les étiquettes marketing n'aident pas toujours. Avant d'entrer dans le vif, il vaut la peine de fixer quatre idées — ce sont elles qui séparent réellement un système d'un autre au moment de choisir.

POSIX parallèle vs. objet Un système de fichiers parallèle (chemins, permissions, open()/read()) répartit chaque fichier sur des centaines de serveurs qui le servent en même temps : c'est ce qu'attend le logiciel HPC classique. Le stockage objet n'a pas de répertoires, mais des clés et des objets via une API S3 : c'est le langage des data lakes et de l'IA moderne.
Bande passante vs. IOPS Le HPC classique veut des Go/s séquentiels pour écrire d'énormes checkpoints. L'entraînement d'IA veut souvent l'inverse : des millions de petits fichiers lus au hasard, où priment les IOPS et la performance des métadonnées. Presque aucun système n'est roi des deux.
Les métadonnées commandent Le serveur de métadonnées (MDS) est celui qui sait où se trouve chaque chose. Dans les charges d'IA avec des millions de petits fichiers, c'est souvent le premier goulot d'étranglement, avant le disque. Beaucoup de migrations échouent en dimensionnant bien le disque et en oubliant les métadonnées.
GPUDirect Storage Un chemin direct entre le stockage et la mémoire du GPU, sans passer par le CPU ni par un tampon intermédiaire en RAM. Moins de latence, moins de CPU consumé à déplacer des octets, et des GPU qui cessent d'attendre. C'est la pièce que l'IA moderne exige du stockage.
La distinction qui compte

Le meilleur stockage est celui qui correspond à votre charge de travail dominante. Si votre quotidien, ce sont des simulations qui écrivent des fichiers géants, vous cherchez de la bande passante séquentielle. Si c'est entraîner des modèles sur des millions d'images, vous cherchez des métadonnées rapides et des IOPS. Confondre les deux est l'erreur de conception la plus coûteuse que nous voyons.

02 · Les cinq prétendants

Qui joue dans quelle catégorie ?

Voici les cinq systèmes qui dominent le stockage sérieux pour l'IA et le HPC. Il n'y a pas de vainqueur unique : chacun a son point fort. Les barres comparent, à titre indicatif, deux axes presque toujours en tension : la performance de pointe qu'un système peut atteindre et la facilité d'exploitation au quotidien.

Ceph
Unifié · objet + bloc + fichier Performance de pointe Polyvalence / exploitation
Le couteau suisse
Storage Scale
POSIX parallèle · GPFS · IBM Performance de pointe Support / exploitation
Le cheval de trait entreprise
Lustre
POSIX parallèle · celui du TOP500 Performance de pointe Facilité d'exploitation
Le standard HPC
DAOS
Objet / KV sur NVMe Performance de pointe Facilité d'exploitation
La fusée de l'IO500
BeeGFS
POSIX parallèle · facile à déployer Performance de pointe Facilité d'exploitation
Le déploiement express
Barres indicatives · le meilleur système est celui qui correspond à votre charge, pas celui à la barre la plus longue
03 · Le tableau à montrer en réunion

Cinq systèmes en un coup d'œil

L'essentiel de chacun : quel type de stockage il est, où il brille, sous quelle licence il est distribué et quelle version est en production à la mi-2026.

SystèmeTypePoint fortLicenceVersion (2026)
CephUnifiéPlateformes hybrides IA + HPC, clouds privés, data lakes S3. Objet, bloc et fichier depuis un même cluster.Open source LGPL20.2.2 « Tentacle » (juin 2026)
IBM Storage ScalePOSIX parallèleHPC d'entreprise avec support et SLA, IA sur NVIDIA DGX BasePOD/SuperPOD, haute performance clé en main.Commercial IBM5.2.x
LustrePOSIX parallèleSupercalcul classique à bande passante maximale. Le standard du TOP500 quand une équipe sait l'exploiter.Open source GPLv22.17 (déc. 2025)
DAOSObjet / KVPerformance extrême sur NVMe pur. Le plus rapide de l'IO500, pour les charges où la latence est primordiale.Open source BSD2.6
BeeGFSPOSIX parallèleClusters HPC moyens à grands et groupes de recherche voulant de bonnes performances sans équipe de stockage dédiée.Community + Enterprise8.3.x
04 · Un par un

Ce que chacun fait bien (et ce qu'il ne fait pas)

Ceph — celui qui fait presque tout

Ceph est le couteau suisse du stockage distribué open source : il fournit de l'objet (S3 via RGW), du bloc (RBD) et du fichier (CephFS) depuis le même cluster, s'auto-répare et évolue en ajoutant des nœuds. Pour l'IA, cela donne RBD pour les machines d'entraînement, S3 pour le data lake et CephFS pour l'accès parallèle — avec une intégration native à OpenStack et Kubernetes. Ce n'est pas le roi de la performance de pointe en HPC extrême, mais sa polyvalence est sans rivale, et des déploiements comme les 50+ Po du CERN prouvent qu'il tient à grande échelle. La version 20.2.2 « Tentacle » (juin 2026) apporte Crimson pour les pools en erasure coding et des améliorations de chiffrement RGW. C'est aussi le gagnant naturel du vide laissé par MinIO, passé en « maintenance mode » fin 2025 — nous le détaillons dans notre guide Ceph vs MinIO 2026. Chez SIXE, nous le pratiquons au quotidien : Ceph pour l'IA & le HPC et formation officielle Ceph.

IBM Storage Scale (GPFS) — la performance avec un SLA

Jadis GPFS, puis Spectrum Scale, et aujourd'hui IBM Storage Scale : le même cheval de trait sous trois noms. C'est un système de fichiers parallèle POSIX mature, avec support entreprise, qui dans sa version 5.2.x intègre GPUDirect Storage de NVIDIA et la certification pour les plateformes DGX BasePOD/SuperPOD et Grace Blackwell. C'est le choix quand vous voulez la performance d'un FS parallèle sans dépendre de la capacité de votre équipe à reconstruire un Lustre à trois heures du matin : vous payez la licence, vous gagnez le SLA. Nous montons des infrastructures HPC avec Storage Scale + Spectrum LSF/SLURM et donnons la formation d'administration Storage Scale.

Lustre — le standard du TOP500

Lustre reste, et de loin, le système de fichiers le plus répandu en supercalcul : il fait tourner une part énorme des grands centres de calcul du monde. Il offre une bande passante séquentielle très élevée et évolue jusqu'à l'exaoctet. Le prix, c'est l'exploitation : ce n'est pas « installer et oublier », et il faut une vraie expertise pour le régler et le rétablir. La version 2.17 (décembre 2025) poursuit cette voie, avec la 2.18 qui prépare l'erasure coding au niveau du fichier (FLR-EC) et la compression côté client. Si vous venez de Lustre et cherchez du support commercial, nous avons écrit sur la migration de Lustre vers IBM Storage Scale.

DAOS — la fusée ressuscitée

DAOS est la réponse à « et si on jetait POSIX à la poubelle pour concevoir pour le NVMe à partir de zéro ? ». Résultat : il occupe les positions 1 et 2 de la liste de production IO500 (Argonne et LRZ, SC25), et 16 des 30 premiers du classement complet tournent sous DAOS. Il est né lié à la mémoire Optane d'Intel ; quand Intel a tué Optane, beaucoup l'ont enterré aussi. Mais depuis la version 2.6 (juillet 2024), il fonctionne uniquement avec des SSD NVMe et se porte très bien. Il est désormais gouverné par la DAOS Foundation sous l'égide de la Linux Foundation (Argonne, HPE, Google Cloud, Intel), après le transfert de l'équipe d'Intel à HPE en 2024. C'est l'option de performance maximale pour qui dispose de NVMe pur et d'une charge qui le justifie — pas un remplacement général.

BeeGFS — le facile à vivre

BeeGFS est le FS parallèle qui privilégie le fait de pouvoir le déployer un mardi après-midi sans doctorat en stockage. Il offre de très bonnes performances pour des clusters moyens et reste le favori de nombreux groupes de recherche pour sa simplicité. Attention à un changement important : depuis BeeGFS 8, l'édition Community reste gratuite mais exige de générer une licence communautaire (beegfs license), et les fonctions entreprise passent derrière une licence payante. La version stable en 2026 est la 8.3.x.

Le schéma qui revient

Remarquez la tension : Lustre et DAOS offrent la performance maximale mais exigent une équipe experte. Storage Scale achète cette performance avec une licence et du support. Ceph et BeeGFS renoncent à un peu de pointe en échange d'une vie plus simple. Aucune option n'est gratuite : chacune échange de la performance contre de la simplicité, ou du coût de licence contre du support.

05 · L'axe qui décide vraiment

Votre charge, c'est du HPC classique ou de l'IA ?

Avant de regarder les marques, regardez votre charge. La question qui ordonne la décision n'est pas « lequel est le meilleur ? » — c'est ce que vous allez demander au stockage. Voici les deux profils et ce dont chacun a besoin.

HPC classique
  • Simulation, CFD, dynamique moléculaire, météo
  • Écrit d'énormes checkpoints de façon séquentielle
  • Ce qu'il veut : des Go/s de bande passante soutenus
  • Gros fichiers, accès plus prévisible
  • Convient à : Lustre, Storage Scale, BeeGFS
Charge IA / ML
  • Entraînement et inférence sur des jeux de données massifs
  • Lit des millions de petits fichiers au hasard
  • Ce qu'il veut : IOPS, métadonnées rapides et GPUDirect
  • Doit alimenter les GPU sans les laisser inactifs
  • Convient à : DAOS, Storage Scale, Ceph (S3)

La plupart des plateformes modernes mêlent les deux, et c'est pourquoi le stockage open source pour l'IA et le HPC tend vers des architectures hybrides : un FS parallèle pour le calcul et du stockage objet S3 pour le data lake, cohabitant souvent sur Ceph + OpenStack + Kubernetes.

06 · Comment choisir sans regret

Quatre étapes avant de signer quoi que ce soit

Définissez votre charge dominante

Avant de regarder les produits, mesurez. Écrivez-vous quelques fichiers géants ou lisez-vous des millions de petits ? Est-ce la bande passante ou les métadonnées qui limitent ? Cette seule réponse élimine déjà la moitié des options. Et ne vous fiez pas qu'à l'aujourd'hui : dimensionnez pour la charge que vous aurez quand le projet d'IA grandira.

Décidez : open source avec équipe, ou support avec SLA

Lustre et DAOS sont gratuits en licence mais coûteux à exploiter : il faut des gens qui les connaissent. Storage Scale inverse l'équation : vous payez la licence et achetez la tranquillité. Ceph et BeeGFS se situent entre les deux. La vraie question est : avez-vous — ou voulez-vous — une équipe de stockage ?

Regardez l'écosystème que vous avez déjà

Vous faites déjà tourner OpenStack ou Kubernetes ? Ceph s'y intègre comme un gant. Vous avez des NVIDIA DGX / BasePOD ? Storage Scale est certifié. Du NVMe pur et soif de latence ? DAOS. Le meilleur stockage est souvent celui qui crée le moins de friction avec ce qui est déjà en production.

Testez à l'échelle avant de vous engager

Un benchmark sur quatre nœuds ne prédit pas le comportement à quarante. Testez avec votre charge réelle, pas celle, synthétique, de la fiche technique, et surveillez les métadonnées sous concurrence. Ici, l'expérience fait gagner des mois — et évite un achat à six chiffres mal orienté.

Là où SIXE intervient

Concevoir la couche de stockage d'une plateforme d'IA ou de HPC, comparer Ceph, Storage Scale, Lustre, DAOS ou BeeGFS pour votre cas, ou migrer de l'un à l'autre sans perdre de données ni de sommeil — chez SIXE, nous cumulons plus de 15 ans au croisement du stockage distribué, d'IBM Power et de l'open source. Voir support Ceph et IBM Storage.

Résumé

L'essentiel en 5 points

À retenir de cet article

→ Le stockage décide si vos GPU travaillent ou attendent. Il est aussi stratégique que le cluster de calcul lui-même.

→ Il n'y a pas de « meilleur » : il y a le meilleur pour votre charge. Le HPC classique veut de la bande passante ; l'IA veut des métadonnées, des IOPS et GPUDirect.

→ DAOS mène en performance (1er et 2e de l'IO500), Lustre en prévalence, Storage Scale en support entreprise.

→ Ceph est le choix polyvalent pour les architectures hybrides IA + HPC ; BeeGFS, le plus facile à déployer.

→ Avant de choisir : définissez la charge, tranchez open source vs. SLA, regardez votre écosystème et testez à l'échelle réelle.

FAQ

Questions fréquentes

Ceph ou Lustre : lequel est meilleur pour l'IA ?

Cela dépend de la charge. Lustre offre plus de bande passante séquentielle et reste la référence du supercalcul classique, mais il demande une vraie expertise pour être exploité. Ceph est plus polyvalent : il fournit de l'objet (S3), du bloc et du fichier à la fois, s'intègre à OpenStack et Kubernetes, et son stockage objet convient aux data lakes d'IA. Pour l'entraînement à grande échelle avec d'énormes checkpoints, Lustre ou Storage Scale ; pour les plateformes hybrides et les data lakes, Ceph.

DAOS est-il prêt pour la production ?

Oui, dans son créneau. Il occupe les positions 1 et 2 de la liste de production IO500 (SC25) et est gouverné par la DAOS Foundation sous l'égide de la Linux Foundation. Depuis la version 2.6 (juillet 2024), il fonctionne uniquement avec des SSD NVMe, sans Optane. C'est l'option de performance maximale, mais elle exige du matériel NVMe et une équipe spécialisée ; ce n'est pas un remplacement général de Lustre ou Ceph.

Storage Scale, c'est la même chose que GPFS ou Spectrum Scale ?

Oui. C'est le même produit IBM sous différents noms : GPFS, puis IBM Spectrum Scale, et aujourd'hui IBM Storage Scale. En 2026, il en est à la 5.2.x et prend en charge GPUDirect Storage de NVIDIA et la certification DGX BasePOD/SuperPOD.

BeeGFS est-il toujours gratuit ?

L'édition Community reste gratuite, mais depuis BeeGFS 8 il faut générer une licence communautaire avec beegfs license. Les fonctions entreprise passent derrière une licence payante. La version stable en 2026 est la 8.3.x.

Peut-on utiliser Ceph pour du HPC exigeant ?

Ceph figure sur la liste de production IO500 et il existe des déploiements massifs (le CERN dépasse 50 Po), mais pour du HPC à performance extrême il ne remplace généralement pas Lustre, Storage Scale ou DAOS. Sa force réside dans les architectures hybrides HPC + IA : objet, bloc et fichier depuis un même cluster, intégrés à OpenStack et Kubernetes.

Stockage IA / HPC · Open Source

Vos GPU calculent-ils ou attendent-ils ?

Dites-nous quelle charge vous allez déplacer, combien de GPU et ce que vous avez aujourd'hui en infrastructure. Nous vous répondons en moins de 24 heures avec une ébauche d'architecture de stockage et une idée réaliste de l'effort. Si Ceph convient, nous vous le disons. Si c'est plutôt Lustre, Storage Scale ou DAOS, aussi.

Voir le stockage IA/HPC Contact

IBM QRadar, leader G2 en SIEM, UEBA, NTA et IR 2026

/dans /par
Cybersécurité · IBM QRadar · SOC

IBM QRadar rafle quatre distinctions Leader du G2 d'un coup.

SIEM, UEBA, analyse de trafic réseau et réponse aux incidents. On reprend chaque catégorie une par une : ce qu'elle mesure vraiment, ce que ça change pour un vrai SOC et quelles formations QRadar 7.6 on a sous la main — pour éviter que la distinction finisse sur un slide de PowerPoint.

8 min de lecture●Analyse technique●

Le 10 juillet, IBM a annoncé que QRadar SIEM figure à nouveau comme leader du G2 Grid dans quatre catégories : SIEM, User and Entity Behavior Analytics (UEBA), Network Traffic Analysis (NTA) et Incident Response. Le billet officiel est court — il annonce les médailles et passe à autre chose.

Ici, on les reprend en détail. Ce que G2 mesure dans chacune des quatre, ce que ça change pour un SOC qui doit les faire tourner au quotidien et quelle version de QRadar couvrent nos formations (les trois sont alignées sur la 7.6, la dernière en date).

01

Les quatre médailles G2, une par une

G2 note les logiciels à partir d'avis vérifiés laissés par les personnes qui les font tourner en production. Être leader dans les quatre catégories à la fois est un signal intéressant : il s'agit de quatre capacités qui, il y a peu, se vendaient dans des produits distincts, et qui vivent aujourd'hui dans la même plateforme.

Catégorie 01 SIEM

Security Information and Event Management. Collecte les journaux des systèmes, du réseau, des applications et du cloud, les normalise, les corrèle et détecte les motifs qui pointent vers des incidents.

C'est le terrain historique de QRadar. Banques, opérateurs télécoms et administration publique l'y utilisent depuis plus d'une décennie. La surprise n'est pas ici — elle est dans le fait qu'il arrive aussi leader sur les trois autres.

Catégorie 02 UEBA

User and Entity Behavior Analytics. Analyse le comportement des utilisateurs et des actifs, établit une base de « ce qui est normal » et alerte quand quelque chose s'en écarte.

C'est la capacité de repérer qu'à trois heures du matin, un utilisateur qui n'a jamais téléchargé plus de 200 Mo se met à en télécharger 300 Go. Il fallait autrefois un produit UEBA à part ; dans QRadar, ça arrive comme une app intégrée.

Catégorie 03 NTA · Analyse de trafic réseau

Analyse du trafic réseau. Observe les flux (NetFlow, IPFIX et équivalents) pour détecter les mouvements latéraux, l'exfiltration ou les communications avec un C2 qui n'apparaissent pas dans les logs.

Le module QRadar Network Insights. Les logs racontent ce qui s'est passé sur les machines ; le NetFlow raconte ce qui est passé par les câbles. Sans la seconde moitié, on regarde la moitié du film. Utile surtout pour les équipes qui géraient le NetFlow dans une console à part.

Catégorie 04 Incident Response

Réponse aux incidents. Détecter, c'est la moitié du travail. L'autre moitié, c'est orchestrer la réponse : playbooks, tickets, confinement et coordination entre équipes.

Il s'agit de QRadar SOAR (ex-Resilient), qui figure comme leader G2 à part entière, séparément du SIEM. C'est la brique qui gagne le plus de poids en Europe depuis que NIS2 exige la notification des incidents en 24 heures — un délai qui devient vite serré si le playbook tient sur un Post-it.

02

Ce que certifie exactement un statut de leader G2

G2, c'est un peu le TripAdvisor du logiciel d'entreprise. Et comme TripAdvisor : si quatre cents utilisateurs s'accordent à dire que la paella est bonne, quelque chose se passe bien. Ça n'en fait pas pour autant un guide Michelin.

Traduit en QRadar : les avis confirment que les personnes qui l'exploitent en production le notent haut sur la satisfaction, l'écosystème d'intégrations et la capacité à monter en charge. Ce qu'ils ne confirment pas, c'est qu'il vaille un Gartner Magic Quadrant ou une Forrester Wave, qui sont des évaluations d'analystes. Deux signaux différents, tous les deux utiles.

Ces mêmes avis relèvent aussi ce que le communiqué officiel passe sous silence : QRadar a une courbe d'apprentissage, le tuning initial est exigeant et la facturation à l'EPS/FPI peut grimper plus vite que prévu si le dimensionnement n'est pas fait avec soin. Rien de tout cela n'est une faiblesse du produit — c'est une liste connue de points que nous avons vus en clientèle, et qui se règlent avec de la formation et de la planification.

03

Pourquoi la vague G2 tombe au bon moment

Le calendrier européen est chargé. NIS2 est en vigueur depuis 2024 et 2026 est l'année des contrôles et sanctions envers les entités essentielles et importantes. DORA oblige les entités financières à démontrer une résilience opérationnelle TIC, y compris la capacité à détecter, notifier et répondre aux incidents dans des délais mesurables. Dans les deux cas, avoir un SIEM installé ne suffit pas : il faut un SIEM bien affiné et un SOC qui sait le faire tourner.

C'est là que les distinctions G2 servent concrètement : elles donnent une indication de ce qui mérite d'être appris. Si ces quatre catégories sont celles où les utilisateurs notent le plus haut la satisfaction — SIEM, UEBA, trafic réseau et réponse —, alors former l'équipe à QRadar couvre ces quatre couches d'un seul coup. Une seule formation, quatre capacités : le genre de ratio qui passe bien devant un budget de formation.

04

Trois formations alignées sur la dernière version de QRadar (7.6)

Les trois formations SIXE IBM QRadar sont alignées sur la dernière version du produit, la 7.6. On peut les suivre séparément ou comme un parcours. En présentiel ou à distance, en français, anglais ou espagnol, avec supports propres et laboratoires sur QRadar 7.6 — le vrai produit, avec ses petites manies.

Fondamentaux · BQ205G IBM QRadar SIEM 7.6 · Formation Fondamentaux Architecture, offenses, règles, recherches AQL et tableaux de bord. La formation socle pour les analystes L1 et L2 qui vont exploiter QRadar au quotidien dans le SOC. Voir la formation Administration IBM QRadar SIEM 7.6 · Déploiement et administration Installation, tuning, gestion des utilisateurs et domaines, intégration des log sources, haute disponibilité et mises à jour. Pour qui doit maintenir le moteur en production. Voir la formation Opérations avancées IBM QRadar SIEM 7.6 · Opérations avancées UEBA, Network Insights, threat hunting avec AQL avancée, playbooks SOAR et intégration MITRE ATT&CK. Pour le SOC mûr qui veut tirer un rendement réel du moteur. Voir la formation
FAQ

Questions fréquentes

Dans quelles catégories G2 IBM QRadar est-il leader en 2026 ?

Dans quatre catégories critiques de sécurité : SIEM, User and Entity Behavior Analytics (UEBA), Network Traffic Analysis (NTA) et Incident Response. La reconnaissance repose sur des avis clients vérifiés et la présence sur le marché, pas sur une évaluation d'analyste indépendant.

Un statut de leader G2 équivaut-il à un Gartner Magic Quadrant ?

Non. G2 recueille des avis vérifiés d'utilisateurs réels ; Gartner et Forrester s'appuient sur leurs propres analystes. Ce sont des signaux différents et complémentaires : un produit qui obtient de bons scores dans les deux est généralement un pari plus tranquille qu'un produit qui ne se distingue que dans un seul.

Quelle version de QRadar couvrent les formations SIXE ?

Les trois formations (Fondamentaux, Déploiement et administration, Opérations avancées) sont alignées sur IBM QRadar SIEM 7.6, la version actuelle du produit. Les laboratoires se déroulent sur des environnements 7.6 réels.

Les formations QRadar sont-elles en présentiel ou à distance ?

Les trois formations peuvent être dispensées en présentiel dans les locaux du client ou à distance en classe virtuelle, en français, anglais ou espagnol. Elles s'adaptent au calendrier du client et au niveau de l'équipe, de l'analyste L1 à l'administrateur senior.

Formation IBM QRadar 7.6 · Présentiel ou distanciel

Et maintenant, comment on passe du titre à la production ?

Dites-nous combien de personnes doivent être formées, quels rôles elles occupent (analyste, administrateur, architecte) et sur quelle version vous êtes. On revient avec une proposition sur mesure — programme, format, dates et langue — en moins de temps qu'un vrai tuning.

Demander un devis WhatsApp Voir le hub formations QRadar

OWASP API Security Top 10 vs IBM API Connect

/dans /par
Sécurité des APIs · OWASP · IBM API Connect

OWASP API Security Top 10 vs IBM API Connect.

Les 10 risques critiques de sécurité des APIs selon OWASP, un par un, mappés sur les capacités réelles d'IBM API Connect et DataPower. Là où la passerelle résout, là où elle aide, et là où le travail reste celui de votre backend.

10 min de lecture●Analyse technique●

Les APIs sont le principal vecteur d'attaque contre les applications d'entreprise, et avec l'adoption croissante des agents d'IA et de protocoles comme MCP, l'inventaire des consommateurs autonomes continue de croître. Les risques du OWASP API Security Top 10 (édition 2023, en vigueur) ne changent pas — ils deviennent simplement plus critiques.

Cet article va droit au but : un mapping risque par risque de ce que couvrent IBM API Connect + DataPower et de ce qu'ils ne couvrent pas. Sur les 10, la passerelle a une couverture native sur 4, une aide partielle sur 4 autres, un impact indirect sur 1 et en laisse 1 au backend. Savoir lequel est lequel est ce qui distingue une équipe formée d'une équipe qui découvre les choses en production.

10
Risques critiques
dans la liste OWASP
2023
Édition OWASP
en vigueur
4 / 10
Couverture native
passerelle IBM
3
Nouvelles catégories
vs 2019
01 · Contexte

OWASP quoi, et pourquoi ça compte plus en 2026 ?

L'OWASP API Security Top 10 est la liste de référence du secteur avec les 10 risques les plus critiques en sécurité des APIs. La dernière édition date de 2023 — et en 2026 elle reste le standard, sans réédition en attente. Ce qui a changé, ce n'est pas la liste, c'est le contexte dans lequel elle s'applique :

  • Les APIs restent l'un des principaux vecteurs d'attaque contre les applications d'entreprise.
  • L'adoption croissante d'agents d'IA et de protocoles comme MCP ajoute des consommateurs autonomes à la carte — distincts des apps et partenaires habituels.
  • L'API sprawl — APIs non documentées ni gouvernées — reste un défi récurrent dans les organisations avec des années d'intégrations accumulées.

Dans ce contexte la passerelle cesse d'être un simple proxy et devient la pièce où les contrôles du OWASP API Top 10 sont appliqués — ou non.

Comment lire cet article

Chaque risque porte un badge de couverture avec quatre niveaux : Native (la passerelle le couvre par elle-même), Partielle (elle aide mais nécessite un bon design), Indirecte (contribution limitée) ou Non directe (le problème vit dans le backend). L'objectif n'est pas de vendre — c'est de savoir où mettre l'effort.

02 · Les 10 risques

OWASP API Top 10 (2023) · mapping sur IBM API Connect + DataPower

API1:2023 Broken Object Level Authorization (BOLA) Couverture partielle

Le client change un ID dans l'URL (/orders/42 → /orders/43) et accède à un objet qui ne lui appartient pas. Toujours le risque n°1 — parce que la logique de propriété vit dans le backend.

Ce que la passerelle FAIT Valide le JWT, extrait les claims utilisateur et les passe au backend dans des en-têtes signés. Peut appliquer des politiques par scope OAuth.
Ce que votre backend doit faire Vérifier que le user_id du token correspond au propriétaire de l'objet demandé sur chaque endpoint. La passerelle ne connaît pas votre modèle de données.
API2:2023 Broken Authentication Native

Tokens mal validés, mécanismes d'authentification non sécurisés, JWT signés avec none, identifiants par défaut. L'authentification est le plan où la passerelle apporte le plus, sans discussion.

Ce que la passerelle FAIT OAuth 2.0 complet (authorization server, scopes, refresh), validation JWT (signature, exp, aud, iss), OIDC, mTLS, clés API avec rotation, intégration avec LDAP/AD/IAM externe. C'est WD509G et WE752G à l'état pur.
Ce que votre backend doit faire Faire confiance au résultat de validation de la passerelle. Si vous re-validez côté backend, assurez-vous de ne pas introduire d'incohérences.
API3:2023 Broken Object Property Level Authorization Couverture partielle

Le backend renvoie plus de champs que l'utilisateur ne devrait voir (excessive data exposure) ou accepte plus de champs en écriture (mass assignment). Combine les anciens API3:2019 et API6:2019.

Ce que la passerelle FAIT Transformations de réponse (masquage de champs sensibles, filtrage par scope). DataPower peut appliquer du XSLT ou du GatewayScript pour assainir les payloads.
Ce que votre backend doit faire Ne pas renvoyer de champs que le rôle ne devrait pas voir. Ne pas accepter de champs non attendus en écriture. La passerelle peut aider a posteriori, mais la responsabilité reste sur le design de l'API.
API4:2023 Unrestricted Resource Consumption Native

Absence de rate limiting, pas de quotas, payloads sans taille maximale. S'appelait auparavant « Lack of Resources & Rate Limiting ». Là où la passerelle brille.

Ce que la passerelle FAIT Rate limit par consommateur, par plan, par endpoint. Quotas journaliers/mensuels. Throttling configurable. Limite de taille de payload. Burst control. Tout configuré dans le manager et appliqué dans DataPower ou Nano Gateway.
Ce que votre backend doit faire Définir les SLAs de chaque plan/consommateur. La passerelle applique ce que vous décidez — elle ne décide pas pour vous ce qui est raisonnable.
API5:2023 Broken Function Level Authorization Couverture partielle

Un utilisateur normal accède à des endpoints admin parce que l'API ne vérifie pas le rôle au-delà de l'authentification.

Ce que la passerelle FAIT Applique des politiques différentes par endpoint en fonction des scopes OAuth. Bloque l'accès aux routes admin depuis des tokens sans le scope correspondant. Routage conditionnel.
Ce que votre backend doit faire Concevoir correctement les scopes OAuth dès le départ. Un scope admin est inutile si tous les flows l'accordent. La passerelle applique des règles — elle ne les invente pas.
API6:2023 Unrestricted Access to Sensitive Business Flows Couverture partielle

Une API expose un flow métier sensible (achats, virements, votes) et un attaquant automatise des milliers d'appels légaux mais abusifs. Le dommage ne vient pas d'un exploit technique — il vient du volume.

Ce que la passerelle FAIT Throttling par consommateur, détection de patterns, geo-blocking, intégration CAPTCHA, intégration WAF (DataPower) pour des règles avancées.
Ce que votre backend doit faire Identifier quels flows sont sensibles (tous ne le sont pas) et concevoir des compteurs métier que la passerelle peut consommer via analytics.
API7:2023 Server Side Request Forgery (SSRF) Non directe

Une API accepte une URL de l'utilisateur et l'utilise pour faire des requêtes internes — l'attaquant l'utilise pour attaquer votre réseau interne. Vecteur en hausse en cloud à cause des services de metadata (AWS IMDS, Azure IMDS).

Ce que la passerelle FAIT Peu directement. Si le backend transmet via la passerelle vers l'outbound, on peut restreindre les destinations. Pas le pattern habituel.
Ce que votre backend doit faire Valider les URLs entrantes contre une liste blanche. Bloquer les plages internes (RFC 1918, link-local). Ne pas utiliser les entrées utilisateur directement dans des requêtes HTTP server-side. C'est 95 % backend.
API8:2023 Security Misconfiguration Native

Défauts non sécurisés, TLS mal configuré, CORS trop ouvert, en-têtes de sécurité absents, stack traces exposées. Le classique qui continue à causer des incidents.

Ce que la passerelle FAIT DataPower arrive avec des défauts sécurisés et permet des politiques centralisées de TLS, CORS, en-têtes de sécurité (HSTS, CSP, X-Frame-Options), suppression de stack traces. Audit de configuration unifié depuis API Connect V12.
Ce que votre backend doit faire Ne pas annuler côté backend ce que la passerelle fait déjà correctement (erreurs de double configuration). Maintenir des défauts sécurisés également à l'intérieur du réseau interne.
API9:2023 Improper Inventory Management Native

APIs zombies en production, anciennes versions jamais retirées, environnements de staging accessibles depuis internet, pas de documentation. La base de l'API sprawl.

Ce que la passerelle FAIT Le cœur d'API Connect est exactement cela : catalogue d'APIs, versioning, cycle de vie (création, publication, dépréciation, retrait), gouvernance fédérée en V12 (passerelles hétérogènes visibles depuis un seul plan de contrôle), Developer Portal avec documentation auto-générée.
Ce que votre backend doit faire Respecter le processus de gouvernance : chaque API publiée passe par le manager. Les APIs absentes du catalogue sont shadow — et ce sont elles qui génèrent les brèches.
API10:2023 Unsafe Consumption of APIs Couverture indirecte

Votre app consomme des APIs tierces sans valider ce qu'elles renvoient — et un fournisseur compromis vous emporte avec lui. Nouveau en 2023, particulièrement pertinent dans les architectures avec de nombreuses intégrations SaaS.

Ce que la passerelle FAIT Si la consommation d'APIs externes passe par la passerelle en outbound, on peut appliquer une validation de schéma, une sanitization des réponses et un rate limit du fournisseur. Pas toujours le pattern.
Ce que votre backend doit faire Valider les contrats d'API consommés. Ne pas faire confiance aux payloads reçus. Isoler les dépendances. C'est de la discipline de développement, plus que de la configuration de plateforme.
03 · Résumé visuel

Les 10 risques, en un coup d'œil

Tableau de couverture de la passerelle IBM (API Connect + DataPower) par risque OWASP :

Risque Nom court Couverture passerelle Capacité clé
API1
BOLA
Partielle
JWT claims propagés
API2
Broken Authentication
Native
OAuth, JWT, OIDC, mTLS
API3
Object Property Level Authz
Partielle
Masquage de champs
API4
Unrestricted Resource Consumption
Native
Rate limit, quotas, throttling
API5
Function Level Authorization
Partielle
Scopes OAuth + politiques
API6
Sensitive Business Flows
Partielle
Détection patterns, WAF
API7
SSRF
Non directe
Backend principalement
API8
Security Misconfiguration
Native
TLS, CORS, en-têtes, audit
API9
Improper Inventory Management
Native
Catalogue, versioning, V12
API10
Unsafe Consumption of APIs
Indirecte
Validation des contrats

Bilan : 4 couverture native (API2, API4, API8, API9) · 4 couverture partielle (API1, API3, API5, API6) · 1 indirecte (API10) · 1 non directe (API7).

04 · Le facteur humain

La passerelle applique des règles — quelqu'un doit les concevoir

La conclusion honnête après ce mapping est celle qui sort rarement dans le matériel marketing : la passerelle est un outil puissant, mais sans jugement propre. Elle applique à la lettre ce que votre équipe configure. Si les scopes OAuth sont mal pensés, la passerelle ne les répare pas pour vous. Si vous mettez un rate limit de 10 000 req/s sur un endpoint de virements, la passerelle vous aide à échouer plus vite.

Les capacités d'API Connect et DataPower sont celles que vous avez vues ci-dessus. La différence entre « nous avons API Connect » et « nous avons API Connect qui atténue correctement 8 des 10 risques OWASP » est faite par l'équipe qui l'opère.

Les 5 cours officiels qui couvrent tout cela WD509G et WD514G pour le noyau d'API Connect ; WE761G, WE752G et WE754G pour DataPower. En français, en intra-entreprise dès 2 personnes.
Catalogue de cours
Ce qu'il y a dans les cours

Pas seulement « ce que fait chaque nœud DataPower ». C'est quand appliquer quelle politique, comment concevoir des scopes OAuth qui passent à l'échelle, quand le rate limit par consumer ne suffit plus et il faut passer au business flow throttling — le type de décision opérationnelle qui se voit en projet, pas dans le manuel.

Résumé

L'essentiel en 5 points

À retenir

→ OWASP API Top 10 2023 reste le standard en vigueur en 2026 — pas de réédition en attente, mais plus pertinent avec l'adoption de l'IA agentique.

→ La passerelle IBM (API Connect + DataPower) a une couverture native sur 4 risques — authentification, rate limiting, configuration sécurisée et inventaire d'APIs.

→ Aide partielle sur 4 autres (BOLA, property authz, function authz, business flows) — la logique métier reste backend.

→ SSRF et unsafe consumption sont principalement le territoire des développeurs — n'attendez pas que la passerelle les résolve pour vous.

→ La différence entre avoir l'outil et atténuer les risques est l'équipe qui le configure.

FAQ

Questions fréquentes

La version 2023 d'OWASP API Top 10 est-elle toujours d'actualité en 2026 ?

Oui. La Fondation OWASP a publié la dernière mise à jour de l'API Security Top 10 en 2023 et aucune nouvelle édition n'a paru en 2026. La liste reste le standard de référence du secteur — d'autant plus pertinente avec la consommation croissante d'APIs par les agents d'IA.

API Connect / DataPower couvre-t-il les 10 risques OWASP ?

Non, et ce n'est pas un défaut de la passerelle. Sur les 10 risques, la passerelle a une couverture native sur 4 (API2, API4, API8, API9), une couverture partielle sur 4 (API1, API3, API5, API6), un impact indirect sur 1 (API10) et laisse 1 au backend (API7 SSRF). Le reste exige un design backend correct et une revue humaine.

Quel risque est le plus simple à atténuer avec la passerelle ?

API4 (Unrestricted Resource Consumption) et API9 (Improper Inventory Management). Rate limiting, quota plans et throttling sont le territoire natif d'API Connect. Catalogue, versioning et gouvernance fédérée en V12 couvrent directement la gestion d'inventaire.

Où apprendre à configurer tout cela dans API Connect ?

Les cours officiels WD509G (admins) et WD514G (devs), plus ceux de DataPower (WE761G, WE752G, WE754G). Chez SIXE on les anime en intra-entreprise dès 2 personnes avec des ingénieurs qui déploient ces produits en environnement client réel. Catalogue complet sur le hub de formation API Connect.

Sources

Références

OWASP Foundation. OWASP API Security Project. owasp.org/www-project-api-security

OWASP Foundation. API Security Top 10 (édition 2023). owasp.org/API-Security · édition 2023

IBM. IBM API Connect — Cloud Pak for Integration. ibm.com/products/api-connect

IBM. IBM DataPower Gateway. ibm.com/products/datapower-gateway

SIXE. Hub de formation officielle IBM API Connect. sixe.be/formation/ibm-api-connect

Dernière mise à jour : .

Formation API Connect & DataPower

Parlons formation pour votre équipe.

Dites-nous quels risques OWASP vous préoccupent le plus, combien vous êtes et où vous êtes basés. On revient vers vous en moins de 24 heures avec itinéraire, modalité et devis fermé. Sans formulaire à rallonge.

Voir le hub complet Contact

Informix 2026 : v15, watsonx et fin de support 12.10

/dans /par
Bases de données · IBM Informix · 2026

Informix en 2026 : version 15, watsonx et fin de support de 12.10.

Trois mouvements concrets — dont une fin de support qui a déjà pris effet — et un mouvement stratégique d'IBM vers l'analytique et l'IA. Si vous avez Informix en production ou si vous l'évaluez, mieux vaut avoir la carte à jour.

8 min de lecture●Guide technique●

Informix est l'une de ces bases de données dont on publie l'éloge funèbre de temps en temps — et quelques années plus tard elle est toujours en production dans des milliers d'organisations gérant OLTP intensif, séries temporelles et IoT. Depuis le début de 2026, trois choses concrètes se sont passées qu'il convient d'avoir à l'œil.

Chez SIXE nous délivrons les trois cours officiels de l'itinéraire Informix alignés sur la version 15, et nous accompagnons des clients dont les instances Informix tournent en production depuis des années. Voici le récapitulatif utile : ce qu'il y a sur la table, les dates qui comptent et où ça s'intègre.

Nov 2024
Informix 15
Disponibilité générale
Jan 2026
Informix 14.10xC13
Dernier fixpack
30-Avr-2026
EOS Informix 12.10
Déjà en vigueur
01 · Ce qui s'est passé cette année

Trois mouvements depuis le début de 2026

Si vous n'avez que 30 secondes, voici le résumé — le reste du post détaille chaque point :

Plateforme

Informix 15 consolide la ligne

Suppression des limites internes, stockage jusqu'à un demi-yottaoctet, smartblobs externes et InformixHQ renouvelé. La mise à jour moteur la plus marquante depuis plus d'une décennie.

Maintenance

14.10xC13 (janvier 2026)

archecker restaure désormais les tables avec colonnes SmartLOB (BLOB/CLOB) depuis backup. Direct I/O avec blocs 2K et 4K. Lot habituel de corrections cumulées.

Calendrier

EOS de 12.10 — déjà en vigueur

Informix 12.10 est hors support standard depuis le 30 avril 2026. IBM propose Extended Support contractable jusqu'en 2030 pour les organisations qui ont besoin d'un pont.

VERSIONS INFORMIX · ÉTAT EN 2026 12.10 EOS · 30-Avr-2026 Extended Support uniquement (jusqu'en 2030) 14.10 xC13 · Jan 2026 Version supportée 15 Ligne active · Nov 2024 Sans limites internes → migration recommandée → → chemin d'upgrade →
État des versions Informix en vigueur en 2026 · Sources : IBM Support Lifecycle, IIUG.
02 · Plateforme

Ce qu'apporte Informix 15

La version 15 — annoncée par IBM le 19 novembre 2024 — est la mise à jour du moteur la plus marquante depuis plus d'une décennie. Les changements principaux :

  • Stockage sans limites pratiques. Une instance Informix 15 peut gérer jusqu'à un demi-yottaoctet de données. La suppression des plafonds internes (lignes par page, pages par partition, tailles de page) libère de l'obligation de partitionner pour des raisons techniques — vous partitionnez uniquement quand cela a du sens fonctionnel.
  • Smartblobs externes. Les BLOBs et CLOBs (vidéos, documents, multimédia) peuvent vivre sur un système de fichiers externe. Sauvegardes plus rapides et stockage moins cher.
  • InformixHQ renouvelé. L'outil graphique de monitoring et d'administration propose une configuration plus simple de l'Enterprise Replication.
  • Plus de capacités de diagnostic. Améliorations du debugging SQL pour accélérer le travail des développeurs.
En clair

Sur de nombreux déploiements Informix, le partitionnement des tables était dicté par les limites du moteur plutôt que par le besoin fonctionnel. Cela change avec la 15 : vous partitionnez parce que ça a du sens au niveau du modèle de données, pas parce que le moteur l'impose.

03 · Maintenance

Nouveautés de 14.10xC13 (janvier 2026)

Si votre organisation est encore sur la ligne 14.10 — et c'est parfaitement valable, elle reste une version supportée — le dernier fixpack publié en janvier apporte :

  • archecker restaure les tables avec colonnes SmartLOB (BLOB / CLOB) depuis backup. Jusqu'ici ce scénario était plus manuel.
  • Direct I/O avec tailles de blocs 2K et 4K, en plus des tailles précédentes. Davantage de contrôle sur la performance des E/S.
  • Lot habituel de corrections cumulées et améliorations de stabilité.

14.10xC13 est un fixpack pensé pour maintenir la ligne saine pendant que vous planifiez le saut vers la 15.

04 · Intégration IA

Informix dans l'écosystème watsonx.data

IBM a publié un connecteur Informix officiel dans watsonx, également documenté dans le portail de docs de watsonx SaaS. La proposition de valeur :

  • Zero-ETL. Le connecteur interroge les données d'Informix sans les répliquer dans un data lake séparé. Une seule copie. IBM le dit littéralement : "access and query multi-modal data types in IBM Informix [...] with zero-ETL".
  • Formats ouverts dans watsonx.data. watsonx.data utilise Apache Iceberg comme format de table ouvert pour unifier et partager les données entre intégrations (Db2, Netezza, Informix et d'autres) sans avoir à re-cataloguer. Vos données dans Informix restent dans Informix.
  • Requêtes en langage naturel. Les capacités d'IA générative de watsonx.data permettent — selon IBM — aux clients d'Informix d'analyser leurs données "using natural language with no SQL required".

Pour une organisation avec Informix déjà installé, cette intégration transforme la base opérationnelle en également un actif analytique, sans migration ni réplication.

Comment le positionner

Si votre organisation utilise déjà watsonx.data ou l'évalue, l'intégration avec Informix élimine une des objections classiques : "comment connecter mes données opérationnelles à la couche IA sans monter un pipeline à part".

05 · Calendrier

Informix 12.10 — hors support standard depuis le 30 avril

Déjà en vigueur

Depuis le 30 avril 2026, Informix 12.10 (éditions Enterprise, Workgroup et Express) est hors support standard d'IBM. Les organisations qui font tourner encore 12.10 peuvent contracter IBM Extended Support avec couverture jusqu'en 2030 comme pont. Sans l'un ni l'autre, pas de correctifs de sécurité ni de résolution d'incidents par IBM.

Implications pratiques :

  • La ligne 12.10 n'accepte plus de nouvelles acquisitions de licences.
  • Les instances 12.10 sans extension sont sans correctifs ni support officiel depuis le 30 avril.
  • Extended Support est la voie contractable pour prolonger la couverture jusqu'en 2030 — utile comme pont pendant la planification de migration.
  • Le chemin d'upgrade habituel mène à la dernière version supportée (Informix 15). 14.10 est une étape intermédiaire valable si la compatibilité applicative l'exige.

Compatibilité et mouvements suggérés

Version Informix 12.10 Informix 14.10 Informix 15
Support IBM
EOS 30-Avr-2026
Supportée
Ligne active
Dernier fixpack
xC16
xC13 · Jan 2026
Dernière GA Nov-2024
Limites de stockage
Héritées
Héritées
Supprimées
Smartblobs externes
Non
Non
Oui
Intégration watsonx.data
Limitée
Limitée
Oui
Action suggérée
Plan de sortie
Plan d'upgrade
Ligne cible
06 · Intégration

Où Informix s'intègre bien en 2026

Scénarios où Informix reste une option compétitive :

  • OLTP intensif à faible latence. Retail, point de vente, banque, télécoms — l'empreinte mémoire et la performance par cœur restent parmi les meilleures du marché.
  • IoT et séries temporelles. Le moteur supporte les types temporels et la gestion de time series de façon native, sans dépendre de solutions externes.
  • Edge computing. Informix Embedded est pensé pour les appareils à matériel contraint et connectivité intermittente — kiosques, magasins distants, équipements industriels.
  • Bases de données de longue durée. Quand vous avez déjà 12.10 ou 14.10 en production, le chemin naturel est de monter à 15 — vous gardez les connaissances de l'équipe, les applications et les intégrations existantes.

À cela s'ajoute l'avantage opérationnel d'avoir un seul fournisseur (IBM) pour le support, la formation officielle et des partenaires avec une expérience réelle en production.

07 · Formation officielle

Les trois cours que nous animons

Dans l'itinéraire de formation Informix de SIXE nous animons les trois cours officiels IBM alignés sur la version 15 :

Code Cours Niveau Durée
IFMX819G
Informix 15 & 14.10 System Administration
Intermédiaire
3-4 jours · 24h
IX223G
Informix 14.10 pour DBAs
Fondamentaux
3 jours · 24h
SXIFX15A
Informix 15 — Administration Avancée, Migration et Cloud
Avancé
3-4 jours · 24h

En ligne ou en présentiel, en français, avec des laboratoires sur infrastructure réelle. Animés par les ingénieurs de SIXE qui exploitent Informix chez les clients. Intra-entreprise dès 2 personnes, avec remise volume.

Résumé

L'essentiel en 4 points

Pour les pressés

→ Informix 15 (nov 2024) supprime les limites internes, ajoute les smartblobs externes et renouvelle InformixHQ. Ligne cible pour la migration.

→ 14.10xC13 (jan 2026) apporte la restauration des SmartLOBs avec archecker et direct I/O en blocs 2K/4K. 14.10 reste une version supportée.

→ 12.10 est hors support standard depuis le 30-avr-2026. IBM Extended Support contractable jusqu'en 2030 comme pont.

→ Intégration watsonx.data avec connecteur zero-ETL et format ouvert Iceberg — les données opérationnelles deviennent un actif analytique sans réplication.

FAQ

Questions fréquentes

Y a-t-il toujours un support officiel d'IBM pour Informix en 2026 ?

Oui. Informix 15 est la ligne active. Informix 14.10 reste une version supportée avec ses fixpacks (le dernier, xC13, est sorti en janvier 2026). Informix 12.10 est hors support standard depuis le 30 avril 2026 ; IBM propose Extended Support contractable jusqu'en 2030 pour les organisations qui ont besoin d'étendre la couverture.

L'intégration avec watsonx.data nécessite-t-elle de déplacer les données ?

Non. Le connecteur zero-ETL accède à Informix là où il se trouve (on-premise, cloud, hybride) sans répliquer les données. Une seule copie, deux plans de consommation : opérationnel et analytique.

Quelle est la relation entre HCL et Informix ?

HCL et IBM co-licencient Informix depuis 2017. Il existe IBM Informix et HCL Informix avec la même base technique et une numérotation de versions équivalente (15.0). Les cours officiels de SIXE sont IBM.

Vaut-il la peine de migrer vers Informix 15 si je suis en 14.10 ?

Cela vaut la peine de le planifier. Les changements structurels (suppression des limites internes, smartblobs externes) sont significatifs et le connecteur watsonx.data est aligné sur la ligne active. 14.10 reste une version supportée, donc le saut peut être planifié sans précipitation.

Je suis en Informix 12.10. Que faire ?

Le support standard a pris fin le 30 avril 2026. Les options sont de contracter IBM Extended Support (couverture jusqu'en 2030) comme pont, ou de planifier la migration. La mise à niveau vers la dernière version supportée (15) est le chemin habituel ; 14.10 fonctionne comme étape intermédiaire si la compatibilité applicative l'exige.

Sources

Références

IBM. Informix 15: Unparalleled Scalability for the Modern Data-Driven World. ibm.com — annonce Informix 15

IBM. IBM Informix Enterprise Edition 12.10.x — Fin de support. ibm.com/support — EOS 12.10

IBM. Fix list for Informix Server 12.10.xC16 (dernier fixpack). ibm.com/support — 12.10.xC16

IBM. IBM Informix connection — documentation watsonx. dataplatform.cloud.ibm.com — connecteur Informix

IBM. watsonx.data SaaS — docs connecteur Informix. ibm.com/docs — watsonx Informix

IBM. Page officielle du produit. ibm.com/products/informix

IIUG. International Informix Users Group — End of support dates. iiug.org — dates EOS

Dernière mise à jour : .

Support et formation Informix

Migration, formation d'équipe ou simple évaluation ? Parlons-en.

Migration 12.10 → 15, healthcheck d'instances en production, support continu et formation officielle. Ingénieurs SIXE avec Informix réel en environnement client — sans helpdesks, sans files de tickets.

Contacter SIXE Voir la formation

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

/dans , /par
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 lecture●Guide 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.

Évaluer ma préparation NIS2 → Déploiement de Wazuh Support d'urgence 24/7

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

/dans /par
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 lecture●Enquê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é.

Répondre à l'enquête → S'abonner à la newsletter Contacter SIXE

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

/dans /par
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 lecture●Guide 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.

Contacter SIXE +34 91 198 02 43

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

/dans /par
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 lecture●Guide●

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.

Demander une évaluation +34 91 198 02 43

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

/dans /par
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 lecture●Guide 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-security → trixie-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.

Contacter SIXE +34 91 198 02 43
SIXE