Comment satisfaire au marquage machine-readable des contenus générés par IA ?

Aucune technologie unique de watermarking ne remplit les quatre exigences du règlement (imperceptibilité, robustesse, détectabilité et traçabilité). L'approche pratique combine trois couches : métadonnées C2PA (Coalition for Content Provenance and Authenticity) intégrées, watermark imperceptible (par exemple SynthID de Google DeepMind pour les images ou techniques similaires pour le texte) et logging audité côté générateur. Chaque couche couvre les modes de défaillance des autres.

Quelle version de QRadar couvrent les formations SIXE mises à jour ?

Les trois formations SIXE (Fondamentaux, Déploiement et administration, Opérations avancées) sont mises à jour à IBM QRadar SIEM 7.6, la dernière version supportée par IBM au moment de la mise à jour. Les laboratoires se déroulent sur des environnements 7.6 réels.

Qui peut répondre à l'enquête LibrePower 2026 ?

Toute personne ayant travaillé avec IBM Power, POWER, ppc64le, AIX, IBM i ou Linux on Power au cours des 24 derniers mois. Administrateurs, architectes, DevOps, avant-ventes, ISV, mainteneurs open source, IBM Champions, Business Partners, chercheurs et passionnés. L'enquête s'adapte à votre profil et n'affiche que les sections pertinentes.

Combien de temps faut-il pour y répondre ?

Entre 12 et 20 minutes selon votre niveau de détail. La plupart des questions sont facultatives — seules celles marquées d'un astérisque sont obligatoires. La progression est sauvegardée dans votre navigateur, vous pouvez reprendre plus tard.

Est-ce vraiment anonyme ?

Oui. LibrePower ne publie que des agrégats avec le nombre de réponses (N) et n'attribue jamais rien à une personne ou une entreprise. Votre email est facultatif et sert uniquement à vous envoyer le rapport. Toute citation directe issue des commentaires libres nécessite un consentement explicite.

Ceph est-il adapté à la production ?

Oui. Ceph fonctionne en production dans des organisations gérant des pétaoctets de données. Il bénéficie du support commercial d'IBM (IBM Storage Ceph) et de Red Hat (OpenShift Data Foundation).

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

28 juillet 2026/dans Informations/par Alba Martinez

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 ●28 juil. 2026

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 ?

24 juillet 2026/dans Informations/par Alba Martinez

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●Juillet 2026

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

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ème	Type	Point fort	Licence	Version (2026)
Ceph	Unifié	Plateformes hybrides IA + HPC, clouds privés, data lakes S3. Objet, bloc et fichier depuis un même cluster.	Open source LGPL	20.2.2 « Tentacle » (juin 2026)
IBM Storage Scale	POSIX parallèle	HPC d'entreprise avec support et SLA, IA sur NVIDIA DGX BasePOD/SuperPOD, haute performance clé en main.	Commercial IBM	5.2.x
Lustre	POSIX parallèle	Supercalcul classique à bande passante maximale. Le standard du TOP500 quand une équipe sait l'exploiter.	Open source GPLv2	2.17 (déc. 2025)
DAOS	Objet / KV	Performance extrême sur NVMe pur. Le plus rapide de l'IO500, pour les charges où la latence est primordiale.	Open source BSD	2.6
BeeGFS	POSIX parallèle	Clusters HPC moyens à grands et groupes de recherche voulant de bonnes performances sans équipe de stockage dédiée.	Community + Enterprise	8.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

16 juillet 2026/dans Informations/par Alba Martinez

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●Juillet 2026

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

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.

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.

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.

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

L’EDR au-delà de Windows : Linux, AIX et IBM i

25 juin 2026/dans Informations, Informations/par Alba Martinez

Sécurité · EDR / XDR · IBM Power

L'EDR au-delà de Windows : protéger Linux, AIX et IBM i.

Nous cartographions la couverture réelle des plateformes EDR du marché sur l'ensemble de votre parc — y compris les serveurs pour lesquels CrowdStrike et SentinelOne ne fournissent aucun agent. Là où le radar porte, là où se cachent les angles morts, et comment les combler avec l'open source.

11 min de lecture●Analyse technique●Juin 2026

Il y a une conversation qui revient à chaque fois que nous passons en revue la stratégie de détection d'un client. On nous présente la couverture : Windows protégé, Linux en partie, macOS selon les cas. Tout à fait raisonnable. Puis nous demandons : « Et les serveurs AIX ? Et les IBM i ? » Ce qui suit, le plus souvent, c'est un bref silence gêné.

Ce n'est pas un oubli. C'est que la plupart des plateformes EDR du marché — CrowdStrike, SentinelOne, Microsoft Defender — ne fournissent aucun agent pour AIX ni pour IBM i. Et dans la banque, l'assurance ou la logistique, ce sont justement les systèmes qui traitent les transactions les plus critiques de l'organisation.

44 %

Des violations
impliquent un rançongiciel

Agent EDR
leader pour AIX

10M+

Téléchargements
annuels de Wazuh

24h

Délai d'alerte
imposé par NIS2

01 · Démêler les sigles

EDR, XDR, MDR : trois lettres qui ne disent pas la même chose

Le secteur empile les acronymes à toute vitesse, et la frontière entre les produits est rarement nette. Avant d'aller plus loin, il vaut la peine de poser ce qu'est chacun — parce que la distinction compte dès qu'il faut protéger un serveur qui n'est pas sous Windows.

EDR Endpoint Detection & Response Détecte les menaces sur les endpoints en analysant le comportement, pas les signatures. Il repère le malware qui ne laisse aucun fichier — exactement ce qu'un antivirus classique ne voit jamais.

XDR Extended Detection & Response Étend la visibilité au-delà du endpoint en corrélant la télémétrie réseau, identité, messagerie et cloud dans une seule plateforme — une vue plus large qu'un capteur isolé.

MDR Managed Detection & Response Pas une technologie — un service. Quelqu'un exploite votre EDR/XDR en continu. Pertinent sans SOC interne ; beaucoup moins si vous avez l'équipe mais pas l'outil.

La distinction qu'on oublie le plus

L'antivirus cherche des signatures connues : des fichiers qui correspondent à une base de malwares. Si l'attaque est inédite ou ne laisse aucun fichier (fileless, living-off-the-land), il ne la voit pas. L'EDR, lui, la repère — parce qu'il ne surveille pas les fichiers, mais les comportements.

02 · La carte de couverture

Jusqu'où porte le radar de votre EDR ?

Voici l'exercice qu'on fait rarement lors d'un audit de sécurité : cartographier la couverture EDR réelle des principales plateformes commerciales sur chaque type de système que vous exploitez en production. Pas la version de la fiche technique — la vraie.

Windows

x86_64

Couverture totale

Linux x86

RHEL · Ubuntu · Debian

Couverture totale

macOS

Apple Silicon · Intel

Couverture partielle

Linux on Power

ppc64le

Couverture partielle

Couvert par les EDR commerciaux leaders Limité ou variable selon l'éditeur Aucun agent disponible

Ce sont ces deux dernières cases, le problème. CrowdStrike ne fournit aucun agent pour AIX ni pour IBM i. SentinelOne non plus. Microsoft Defender non plus. C'est un angle mort du marché EDR commercial qui frappe de plein fouet les secteurs à la plus grande surface d'attaque réglementée — banque, assurance, santé, logistique — qui sont justement ceux qui concentrent le plus d'infrastructures IBM Power.

L'angle qu'on regarde rarement

Vous payez déjà CrowdStrike, SentinelOne ou Microsoft Defender. Le problème n'est pas seulement la sécurité — c'est qu'une partie de votre infrastructure la plus critique reste hors de cet investissement. Vous payez pour une couverture qui, par conception, n'atteint jamais les systèmes qui traitent vos transactions.

03 · Le marché

Consolidation, concentration et une alternative discrète

Le paysage EDR connaît depuis deux ans une recomposition. Et les mouvements les plus marquants ne viennent pas des produits — ils viennent des fusions.

Le leader entreprise CrowdStrike reste la référence du haut de gamme. L'incident de juillet 2024 a entraîné un niveau de vigilance qui n'existait pas avant, mais techniquement il demeure parmi les meilleurs.

L'intégration native Microsoft Defender for Endpoint continue de gagner des parts grâce à son intégration à Microsoft 365. Pour qui est déjà dans cet écosystème, le coût marginal est difficile à battre.

Les acquisitions Cisco a racheté Splunk (28 milliards de dollars). Palo Alto a absorbé la partie SaaS de QRadar. Le message : la détection et la réponse fusionnent avec le SIEM. Ce ne sont plus des produits distincts — ce sont les couches d'une même plateforme.

L'alternative open source En parallèle, Wazuh a dépassé les 10 millions de téléchargements par an et ajouté le threat hunting assisté par un LLM exécuté en local — sans coût de licence.

04 · Wazuh comme EDR/XDR

Ce qui fonctionne, et ce qui ne fonctionne pas

Soyons précis, car c'est un produit avec lequel nous travaillons au quotidien et dont nous connaissons bien les forces et les limites. Wazuh est open source, léger et multiplateforme — et, point essentiel pour cet article, son agent fonctionne en environnement PASE sur IBM i et sur AIX.

Ses points forts

Surveillance d'intégrité des fichiers (FIM) et détection de rootkits
Analyse des logs système et inventaire logiciel et matériel
Détection de vulnérabilités CVE et réponse active automatisée
Agents pour Linux, Windows et macOS ; déployable en PASE (IBM i) et avec un agent pour AIX
Threat hunting assisté par LLM local depuis 2025, sans coût de licence

Là où sont ses limites

Pas de protection au niveau du noyau comme CrowdStrike ou SentinelOne
Pas de sandboxing des menaces
Console fonctionnelle, perfectible côté ergonomie
Les 3 000+ règles par défaut sont un point de départ, pas une solution clé en main
Nécessite une équipe qui sache le configurer et l'affiner

C'est cette dernière ligne qui compte. L'écart entre un Wazuh qui génère du bruit et un Wazuh qui produit du renseignement exploitable tient à la configuration, au tuning et à la connaissance de l'environnement. Pour la comparaison complète face aux alternatives commerciales, tout est sur notre page Wazuh.

05 · Combler l'angle mort

Existe-t-il un EDR pour IBM i et AIX ?

C'est la question directe, et la réponse honnête est : pas dans le catalogue des grands éditeurs, mais oui, via l'open source. Revenons aux deux cases rouges de la carte. Si les plateformes commerciales n'atteignent pas AIX et IBM i, trois pièces comblent le vide — et elles se complètent.

Wazuh sur PASE (IBM i) et AIX

Wazuh peut être déployé en environnement PASE sur IBM i pour collecter la télémétrie et les événements du système, ensuite corrélés dans la plateforme centrale. Pour AIX, il existe un agent natif. Aucun des deux n'égale la couverture de Wazuh sous Windows, mais ils collectent les logs système, surveillent l'intégrité des fichiers et détectent les changements de configuration. Sur IBM i, associer Wazuh à la collecte du QAUDJRN — le journal d'audit natif — apporte une couche de visibilité que la plupart de ces systèmes n'ont tout simplement pas aujourd'hui.

PowerSC pour le durcissement et la conformité

PowerSC est l'outil natif d'IBM pour AIX et IBM i. Il surveille les modifications de fichiers, vérifie les configurations face aux référentiels CIS/STIG et génère des rapports de conformité. Ce n'est pas un EDR au sens strict, mais il couvre la détection des changements et la gestion de configuration qui complètent Wazuh.

L'open source pour IBM Power

Au-delà des outils d'IBM, il existe des dépôts open source maintenus spécifiquement pour IBM Power qui simplifient le déploiement d'agents de surveillance et d'outils d'automatisation sur AIX et IBM i.

LibrePower : le catalogue open source pour IBM Power Il maintient des dépôts de paquets pour AIX et IBM i avec les dépendances nécessaires au déploiement d'agents de surveillance, de scripts d'audit et d'outils d'automatisation. Avec AWX et Ansible, vous déployez et configurez ces agents sur des parcs de serveurs Power exactement comme vous le feriez sous Linux. Catalogue AIX Catalogue IBM i AWX / Ansible

La pièce que l'auditeur veut voir

Wazuh + PowerSC + Ansible sur IBM Power n'est pas un EDR sur étagère. Mais cela offre une visibilité sur des systèmes que les plateformes EDR commerciales n'atteignent pas, et produit des preuves alignées sur les exigences de surveillance, de journalisation et de détection de NIS2 et d'ISO 27001.

06 · Par où commencer

Trois étapes si vous ne protégez que Windows

Auditer votre couverture réelle

Inventoriez chaque endpoint — pas seulement ceux que l'IT gère activement, mais ceux qui tournent tout seuls depuis des années. Chaque serveur AIX, chaque IBM i, chaque LPAR de production qui n'envoie aucune télémétrie à un système central est un angle mort. Tant que vous ignorez combien restent sans protection, vous ne pouvez pas dimensionner la solution.

Déployer Wazuh comme couche de base

Un serveur Wazuh avec des agents partout — Windows, Linux, AIX, IBM i — donne une visibilité centralisée. Ce n'est pas l'étape finale, mais c'est celle qui produit le plus d'information par euro investi. Notre guide sur Wazuh et NIS2 détaille la marche à suivre pour les environnements soumis à la réglementation.

Définir votre stratégie de réponse

Détecter sans pouvoir répondre, c'est une alarme que personne n'éteint. Les réponses actives de Wazuh (isolement d'un hôte, blocage d'IP, arrêt de processus) demandent une configuration soignée pour éviter les faux positifs qui touchent la production. C'est là que l'expérience compte plus que la technologie.

Là où SIXE intervient

Dimensionner un déploiement Wazuh, intégrer vos systèmes Power à la stratégie EDR ou préparer la détection pour un audit NIS2 — chez SIXE, nous évoluons depuis plus de 15 ans à cette intersection entre infrastructure IBM Power et sécurité.

Résumé

L'essentiel en cinq points

À retenir

→ L'antivirus classique ne suffit plus : il détecte des signatures, pas des comportements. L'EDR, lui, repère le malware fileless.

→ Les principales plateformes EDR ne fournissent aucun agent pour AIX ni IBM i — un angle mort dans la banque, l'assurance et la logistique.

→ Wazuh est une vraie alternative open source, avec un agent AIX et un déploiement PASE (IBM i), et plus de 10 M de téléchargements par an.

→ Wazuh + PowerSC + Ansible réduit nettement cet angle mort et produit des preuves alignées sur NIS2 et ISO 27001.

→ L'écosystème open source LibrePower simplifie nettement le déploiement d'agents et l'automatisation sur IBM Power.

FAQ

Questions fréquentes

Quelle est la différence entre EDR, XDR et antivirus ?

L'antivirus compare les fichiers à une base de signatures de malwares connus. L'EDR analyse le comportement du système — processus, connexions, modifications de fichiers — pour repérer les menaces qui ne laissent aucun fichier, comme les malwares fileless. Le XDR étend cette visibilité au-delà du endpoint en corrélant la télémétrie réseau, identité, messagerie et cloud au sein d'une seule plateforme.

CrowdStrike ou SentinelOne disposent-ils d'un agent pour AIX ou IBM i ?

Non. Les principales plateformes EDR commerciales ne proposent pas d'agent pour AIX ni pour IBM i. C'est un angle mort qui touche en priorité les secteurs à la plus grande surface d'attaque réglementée : banque, assurance, santé et logistique — précisément ceux qui exploitent le plus d'infrastructures IBM Power.

Quelles alternatives à CrowdStrike ou SentinelOne sur AIX ?

Comme CrowdStrike et SentinelOne n'ont pas d'agent AIX, l'alternative concrète associe Wazuh (détection et collecte d'événements), PowerSC (l'outil natif IBM de durcissement et de conformité) et Ansible pour le déploiement automatisé. Ce n'est pas un remplacement strict, mais cela apporte la couche de détection que ces plateformes n'offrent pas sur AIX.

Wazuh peut-il servir d'EDR pour les serveurs IBM Power ?

Oui, avec des nuances. Wazuh dispose d'un agent pour AIX et peut être déployé en environnement PASE sur IBM i pour collecter la télémétrie et les événements du système. Il assure la surveillance d'intégrité des fichiers, détecte les changements de configuration et corrèle les événements dans la plateforme centrale. Il n'égale pas la protection au niveau du noyau des outils commerciaux sous Windows, mais il offre une visibilité sur des systèmes que ces plateformes n'atteignent tout simplement pas.

Est-ce utile pour la conformité NIS2 ou ISO 27001 ?

Associer Wazuh, PowerSC et l'automatisation Ansible sur IBM Power apporte une couche de détection et de traçabilité sur des systèmes que les plateformes EDR commerciales ne couvrent pas. Collecter le QAUDJRN d'IBM i et le syslog d'AIX dans un SIEM central produit des preuves alignées sur les exigences de surveillance, de journalisation et de détection de NIS2 et d'ISO 27001.

Sécurité des endpoints · IBM Power

Des angles morts dans votre couverture EDR ?

Dites-nous quels systèmes restent sans protection, combien d'endpoints vous exploitez et quelle réglementation s'applique. Vous aurez une réponse sous 24 heures, avec une ébauche d'architecture et une idée réaliste de l'effort. Si Wazuh convient, on vous le dit. Sinon, on vous le dit aussi.

Voir la solution Wazuh Contact

Votre équipe fait à la main ce que Db2 12 fait tout seul

25 juin 2026/dans Informations, Informations, Informations/par Alba Martinez

Bases de données · IBM Db2 · Exploitation

Votre équipe fait à la main ce que Db2 12 fait tout seul. Et elle ne le sait pas.

Des sauvegardes plus longues que nécessaire, des failovers montés sur un produit qu'IBM ne fait plus évoluer sous Linux, de la maintenance avec arrêt pour des opérations que le moteur gère désormais en ligne. Si votre équipe n'est pas passée à Db2 12, elle travaille plus que nécessaire — et prend peut-être des risques évitables.

9 min de lecture●Analyse technique●Juin 2026

IBM a publié Db2 12.1.5 le 9 juin 2026 — le sixième mod pack depuis la sortie de la version 12 en novembre 2024. À chaque publication, l'écart entre la façon dont un DBA exploite son Db2 et ce que le moteur fait déjà tout seul n'a cessé de se creuser. Sans que personne ne prévienne l'équipe.

Ce n'est pas un problème de compétence. Le produit a changé en profondeur et personne n'a mis l'équipe à jour. La 11.5 n'a plus évolué depuis des années, et entre elle et la 12.1 le moteur gère autrement la haute disponibilité, les sauvegardes, la maintenance et même le type de données qu'il peut stocker. Mais personne ne l'a dit à l'équipe.

Cinq situations concrètes où cela se voit. Ce ne sont pas des cas particuliers : c'est le quotidien d'un DBA qui ignore que son Db2 fait déjà ce qu'il continue de faire à la main depuis des années.

Le failover que votre équipe monte sur un produit qu'IBM n'enrichit plus

C'est le cas le plus parlant. Votre équipe configure HADR pour la haute disponibilité. Sous Linux, elle met en place TSAMP (Tivoli System Automation) parce que c'est ce qu'elle connaît. Ça fonctionne. Mais IBM concentre ses nouvelles capacités d'automatisation HADR sur Pacemaker et le positionne comme l'option stratégique pour les nouveaux déploiements Linux. Le gestionnaire de cluster de référence est désormais Pacemaker, open source, standard, plus simple à exploiter.

Ce que votre équipe faitConfigure TSAMP comme gestionnaire de cluster pour HADR. Suit la documentation qu'elle connaît. Gère le basculement avec les outils Tivoli.

Ce que Db2 12 attendPacemaker intégré. Automatisation native du basculement, VIP et Overlay IP découplés. En 12.1.5 (juin 2026) : quorum disk tiebreaker et quorum node fencing.

⚠Le coût : une couche HA montée sur un produit qu'IBM ne fait plus évoluer pour Db2 sous Linux. Ça fonctionne aujourd'hui, mais chaque mod pack ajoute de l'automatisation Pacemaker que votre équipe n'exploite pas.

Sous AIX, l'histoire va dans le même sens avec un autre acteur : l'option pour les charges exigeantes et critiques est PowerHA SystemMirror, pas TSAMP. PowerHA est le produit qu'IBM maintient et fait évoluer pour la haute disponibilité de Db2 sur Power — plus robuste, mieux intégré et mieux adapté aux environnements de production critiques. TSAMP est la couche à éviter, quelle que soit la plateforme. La conclusion n'est pas que Linux est l'option moderne et AIX l'ancienne — c'est que sur les deux plateformes il existe une bonne option, et TSAMP n'en est aucune.

La fenêtre de sauvegarde qui n'a plus besoin d'être aussi large

Avant la version 12, la sauvegarde traitait chaque tablespace avec un seul thread. Sur les bases volumineuses, les fenêtres s'étiraient et le DBA les acceptait comme inévitables. Dans Db2 12, le comportement a changé sur deux fronts concrets :

Ce que votre équipe faitAccepte qu'un seul thread traite chaque tablespace. Programme des fenêtres larges. Suppose que le history file est maintenu pendant la sauvegarde et bloque.

Ce que Db2 12 fait tout seulSauvegardes multi-thread — plusieurs threads traitant un même tablespace, sans configuration supplémentaire. En 12.1.4 (mars 2026) : la maintenance du history file s'effectue de façon asynchrone, sans bloquer. En 12.1.5 (juin 2026) : purge automatique des archive logs.

⚠Le coût : des fenêtres de maintenance plus larges que nécessaire. Chaque heure supplémentaire est du risque opérationnel et de la coordination métier évitables.

La maintenance qui arrête le service pour modifier une colonne

Modifier l'échelle d'un DECIMAL ou élargir un SMALLINT en INT sur une table columnaire (BLU) impliquait de recréer la table, migrer les données et vérifier. En pratique, un arrêt programmé. Dans Db2 12.1.4 (mars 2026) et 12.1.5 (juin 2026), plusieurs de ces opérations ne nécessitent plus d'interruption.

Ce que votre équipe faitCrée une nouvelle table, migre les données, renomme, vérifie. Programme un arrêt de service. Idem pour la réorganisation d'index.

Ce que Db2 12 fait tout seulALTER en ligne sur tables columnaires : modifier DECIMAL, élargir SMALLINT en INT, DROP et RENAME sans arrêt. Réorganisation d'index en ligne en 12.1.5 (juin 2026). Déplacement de tables sans interruption de service.

⚠Le coût : des arrêts de service pour des opérations que Db2 12 gère en ligne. Chaque arrêt évitable, c'est de la disponibilité récupérée.

L'architecture que votre équipe a écartée avec les critères de 2022

Ce cas rompt un peu le schéma des précédents, mais il est tout aussi pertinent : ce n'est pas quelque chose que Db2 12 fait tout seul, c'est une architecture désormais viable qui ne l'était pas avant. Si quelqu'un dans votre équipe a évalué Db2 pureScale — la haute disponibilité actif-actif d'IBM pour Db2, conceptuellement comparable à Oracle RAC — il l'a probablement écarté à cause des exigences matérielles. C'était un critère valable en 2022. Ça ne l'est plus.

Ce que votre équipe supposepureScale exige du matériel spécifique on-premises, une interconnexion InfiniBand et un projet d'infrastructure complexe.

Ce que Db2 12 proposepureScale self-managed sur Azure et AWS. Sur AWS, EFA réduit la latence de 40 % et multiplie le débit par 2,5×. Topologie HADR mixte pour la reprise avec un nombre de nœuds différent.

⚠Le coût : évaluer pureScale avec des informations antérieures à Db2 12 et l'écarter pour des exigences qui n'existent plus. Une décision d'architecture prise sur des données obsolètes.

Ce que votre équipe suppose nécessiter une autre base de données

Un besoin de recherche sémantique ou de RAG apparaît. Le réflexe est de supposer qu'il faut une autre base de données : un autre moteur vectoriel, une autre sauvegarde, un autre système de supervision, un autre cycle de vie à maintenir. C'est peut-être le bon choix. Mais il vaut la peine de savoir que Db2 12 stocke et interroge déjà des vecteurs au sein du même moteur :

Ce que votre équipe supposeQue faire du RAG nécessite une autre base de données, une autre sauvegarde, un autre système de supervision et un autre cycle de vie à gérer.

Ce que Db2 12 proposeType de données VECTOR natif (12.1.2). Indexation DiskANN (12.1.5). Fonctions SQL TO_EMBEDDING y TEXT_GENERATION qui invoquent des modèles watsonx.ai ou OpenAI directement depuis une requête SQL.

⚠L'option native ne sera pas toujours la meilleure. Mais un système de moins à maintenir, sauvegarder et superviser est une décision d'architecture qui mérite d'être évaluée — surtout si l'équipe ignorait qu'elle était sur la table.

Le schéma

Ce n'est pas un problème de compétence. C'est un problème d'information.

Les cinq cas ont un point commun : l'équipe ne fait pas les choses mal. Elle les fait comme on le lui a appris. Le problème, c'est que le produit a changé et que personne ne le lui a dit. IBM a publié six mod packs depuis novembre 2024. Les procédures apprises — que ce soit avec la version 10 ou la 11.5 — ne reflètent plus le fonctionnement actuel du moteur.

Et voici l'essentiel : la plupart de ces problèmes ne se résolvent pas en achetant du matériel ni en recrutant. Ils se résolvent en mettant à jour les procédures. Le risque n'est pas de mal exploiter Db2 — c'est de continuer à administrer Db2 12 comme s'il s'agissait de Db2 11.5.

Nous avons construit deux formations propres qui couvrent précisément cette lacune. Ce ne sont pas des cours génériques : ils sont mis à jour pour Db2 12.1.5, dispensés sur AIX et Linux et adaptés au niveau de l'équipe. En présentiel ou à distance, en français, anglais et espagnol.

Administration · Db2 12 LUW Administration IBM Db2 12 pour AIX et Linux Déploiement, stockage, sauvegarde, sécurité, performances et la nouvelle haute disponibilité avec HADR et Pacemaker. Huit modules orientés pratique DBA. Voir la formation Avancé · Db2 pureScale Déploiement et administration de Db2 pureScale Plusieurs instances Db2 partageant un système de fichiers avec Storage Scale (GPFS) en actif-actif. Neuf modules, de la conception du cluster à l'exploitation en production. Voir la formation

FAQ

Questions fréquentes

Pacemaker a-t-il remplacé TSAMP dans Db2 12 ?

Oui, sous Linux. Pacemaker remplace Tivoli System Automation comme gestionnaire de cluster pour HADR. Les procédures de configuration, validation et basculement changent entièrement. Sous AIX, l'option adaptée aux charges critiques est PowerHA SystemMirror — le produit qu'IBM maintient activement pour la HA de Db2 sur Power. TSAMP est la couche à éviter sur les deux plateformes.

Qu'est-ce que Db2 12 automatise par rapport aux versions précédentes ?

Sauvegardes multi-thread sans configuration supplémentaire, maintenance du history file découplée de la sauvegarde, évolution de schéma en ligne sur tables columnaires, purge automatique des archive logs et réorganisation d'index en ligne sans blocage.

Existe-t-il une formation Db2 12 à jour pour AIX et Linux ?

Oui. Chez SIXE, nous proposons deux formations : administration Db2 LUW et déploiement et administration de pureScale. En présentiel ou à distance, en FR/EN/ES.

Db2 pureScale peut-il être déployé dans le cloud ?

Oui, depuis Db2 12. En self-managed sur Azure (RoCE et TCP/IP, BYOL) et sur AWS (Elastic Fabric Adapter). Le matériel dédié on-premises n'est plus requis.

Formation Db2 12 · AIX et Linux

Votre équipe exploite Db2 sans s'être mise à jour sur la v12 ?

Dites-nous quelle version vous utilisez, combien de DBA ont besoin de se former et sur quelle plateforme. Nous vous préparons une proposition sur mesure — programme, format, dates et langue.

Demander un devis WhatsApp Voir formation LUW

OWASP API Security Top 10 vs IBM API Connect

9 juin 2026/dans Informations/par Alba Martinez

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●Juin 2026

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.

Risques critiques
dans la liste OWASP

2023

Édition OWASP
en vigueur

4 / 10

Couverture native
passerelle IBM

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 : juin 2026.

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

9 juin 2026/dans Informations/par Alba Martinez

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●Juin 2026

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.

É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

Supprimées

Smartblobs externes

Non

Oui

Intégration watsonx.data

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 : juin 2026.

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

8 juin 2026/dans cyber-sécurité, Informations/par Alba Martinez

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●Juin 2026

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.

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

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

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.

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

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.

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

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.

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.

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

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.

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.

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

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

Analyse de risques et plan de traitement

Inventaire des actifs avec criticité

Registre des fournisseurs TIC critiques + clauses NIS2

Procédure de réponse aux incidents + runbooks

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

Stratégie de sauvegarde + dernier test de restauration

Politique de gestion des vulnérabilités et rapports

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

Registres de formation des dirigeants (art. 20.2)

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

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 :

É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.
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).
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.
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.
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é.
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.
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

8 juin 2026/dans Informations/par Alba Martinez

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●Juin 2026

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

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.

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.

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.

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.

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.

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

3 juin 2026/dans Informations/par Alba Martinez

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●Juin 2026

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

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 releases Ceph — mises à jour séquentielles uniquement. Chaque version majeure est supportée pendant environ 2 ans.

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

POSIX, NFS, S3

Complexité

Moyenne–Élevée

Faible

Élevée

Kubernetes natif

Rook (CNCF)

Operator

Driver CSI

Coût licence

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 : juin 2026.

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