CONFORMITÉ · SECNUMCLOUD

MDR SecNumCloud : SOC managés sur cloud qualifié ANSSI 3.2

11 fournisseurs · 7 adéquations fortement documentées · 4 articles · 8 critères MDR

SecNumCloud est le référentiel ANSSI applicable à la qualification de services d'informatique en nuage. La qualification porte sur un service nommé, fourni par une entité juridique identifiée, pour des catégories précises — SaaS, PaaS, CaaS ou IaaS — et pendant une période donnée. Elle ne qualifie pas globalement un groupe, un fournisseur MDR, une pile logicielle ou tout service hébergé sur le cloud concerné.

Le catalogue ANSSI consulté le 1er septembre 2026 liste « Cloud de confiance S3NS », fourni par Thales Cloud Sécurisé, pour les catégories PaaS, CaaS et IaaS, du 17 décembre 2025 au 17 décembre 2028, décision n°2057. S3NS n'est donc plus « en cours d'aboutissement ». Cette qualification ne s'étend toutefois pas automatiquement au SOC/MDR de Thales Cyber Solutions ni aux logiciels et services additionnels déployés sur S3NS.

La même règle vaut pour les autres offres : utiliser ou savoir intégrer un service SecNumCloud qualifié peut contribuer à une architecture recevable, mais ne rend pas le MDR « qualifié SecNumCloud ». Il faut vérifier le service exact, les composants hors périmètre, les consoles SaaS, les télémétries, les sauvegardes, le support, les sous-traitants et tout transit de données.

Les niveaux présentés ci-dessous décrivent donc une adéquation documentaire à une architecture SecNumCloud. Ils ne constituent ni une qualification ANSSI du MDR ni une garantie que l'offre commerciale étudiée reste intégralement dans le périmètre qualifié.

01 — PÉRIMÈTRE

Qui est concerné ?

SecNumCloud peut être exigé ou recommandé selon la doctrine cloud applicable, la sensibilité du système, le marché public et l'analyse de risque. Il ne faut pas déduire une obligation générale pour tous les OIV, toutes les données sensibles ou tous les services MDR. L'acheteur doit identifier le texte ou la clause qui fonde son exigence puis vérifier la décision ANSSI du service retenu.

02 — TEXTE LÉGAL

Articles & exigences clés

Référentiel SecNumCloud v3.2

Exigences applicables au prestataire et au service d'informatique en nuage

Le référentiel couvre le prestataire, son personnel, la gouvernance, les opérations et le déroulement du service. La qualification n'est acquise qu'après évaluation et décision ANSSI pour le service concerné.

Catalogue ANSSI, édition du 01/09/2026

Entité, service, catégories et validité

La preuve à conserver est la ligne du catalogue et la décision : fournisseur légal, nom du service, SaaS/PaaS/CaaS/IaaS, dates de début et de fin, numéro de décision.

Décisions individuelles de qualification

Périmètre limité au service nommé

Une décision qualifie le service décrit et ses conditions d'utilisation. Les services managés, logiciels, options ou flux supplémentaires doivent être analysés séparément s'ils ne figurent pas dans ce périmètre.

Doctrine d'utilisation de l'informatique en nuage par l'État

Rattacher l'exigence au contexte de l'acheteur

La doctrine de l'État contient des recommandations et exigences propres aux administrations. Son application à un acteur privé ou à un périmètre OIV doit être justifiée par le texte, le marché ou l'analyse de risque applicable.

03 — IMPLICATIONS MDR

Critères MDR qui découlent du référentiel

01Nommer le service SecNumCloud exact, son fournisseur légal, sa décision, ses catégories et ses dates de validité
02Distinguer trois situations : MDR lui-même dans le périmètre qualifié, MDR opéré sur un service cloud qualifié, ou simple compatibilité technique avec ce service
03Cartographier tout composant hors périmètre : EDR/XDR, SIEM, SOAR, portail, ticketing, sauvegarde, threat intelligence, IA et support
04Vérifier où transitent les journaux et télémétries, y compris pour le support, la maintenance, l'analyse de menace et l'entraînement de modèles
05Identifier les personnels, sous-traitants et accès distants susceptibles d'agir sur le périmètre
06Faire figurer au contrat l'architecture qualifiée, les changements soumis à accord, les preuves de maintien de qualification et le plan de sortie
07Prévoir une solution si la qualification expire, est suspendue ou si un composant sort du périmètre
08Ne jamais transformer une filiation, un partenariat, un hébergement français ou une pile souveraine en qualification SecNumCloud implicite

04 — SÉLECTION (11)

Niveaux d’adéquation documentés

Ces niveaux éditoriaux comparent les preuves publiques disponibles. Ils ne valent ni certification, ni éligibilité juridique, ni garantie que l’entité, le service et les dates correspondront au contrat proposé.

Adéquation fortement documentée· 7

Thales

Souverain FR· Meudon

Le catalogue ANSSI liste le service « Cloud de confiance S3NS » de Thales Cloud Sécurisé en PaaS, CaaS et IaaS du 17/12/2025 au 17/12/2028 (décision 2057). Le MDR de Thales Cyber Solutions doit démontrer que l'architecture proposée reste dans ce périmètre ; la relation de groupe ne suffit pas.

Force spécifique → Preuve officielle disponible pour le service cloud S3NS ; rattachement du MDR à vérifier dans l'architecture et le contrat.

Linkt

Souverain FR· Mont-Saint-Aignan

Aucune qualification SecNumCloud du MDR n'est déduite. Le rapprochement repose sur opérations et pile technologique françaises revendiquées. Le fournisseur doit nommer le service cloud qualifié, produire la décision et démontrer les flux qui restent dans son périmètre.

Force spécifique → Hébergement et opérations FR + stack 100 % FR — cas rare de bout-en-bout sans dépendance hors UE.

OWN.security

Souverain FR· Paris

Aucune qualification SecNumCloud du MDR n'est déduite. Le rapprochement repose sur pile HarfangLab/Sekoia et opérations françaises documentées. Le fournisseur doit nommer le service cloud qualifié, produire la décision et démontrer les flux qui restent dans son périmètre.

Force spécifique → Aucun éditeur hors UE dans la chaîne de détection — alignement strict avec la doctrine SecNumCloud sur les OIV.

Axians Cybersecurity

Souverain FR

Aucune qualification SecNumCloud du MDR n'est déduite. Le rapprochement repose sur variante souveraine de Solar SOC et intégration HarfangLab documentées. Le fournisseur doit nommer le service cloud qualifié, produire la décision et démontrer les flux qui restent dans son périmètre.

Force spécifique → Premier déploiement HarfangLab à grande échelle dans une offre MDR souveraine — preuve d'industrialisation.

Formind

Souverain FR· Issy-les-Moulineaux

Aucune qualification SecNumCloud du MDR n'est déduite. Le rapprochement repose sur modèle d'intégration multi-outils et PASSI actif documentés. Le fournisseur doit nommer le service cloud qualifié, produire la décision et démontrer les flux qui restent dans son périmètre.

Force spécifique → Capacité d'opérer sur un cloud SecNumCloud du client (OVH/S3NS) en BYO — souplesse rare.

Docaposte Cyber

Souverain FR· Ivry-sur-Seine

Aucune qualification SecNumCloud du MDR n'est déduite. Le rapprochement repose sur écosystème de partenaires français/européens documenté. Le fournisseur doit nommer le service cloud qualifié, produire la décision et démontrer les flux qui restent dans son périmètre.

Force spécifique → Cumul opérateur Pack Cyber + co-fondatrice Numspot — capable d'aligner l'ensemble de la chaîne sur le référentiel SecNumCloud.

SYNETIS

Souverain FR· Paris

Aucune qualification SecNumCloud du MDR n'est déduite. Le rapprochement repose sur opérations françaises et capacité d'intégration documentées. Le fournisseur doit nommer le service cloud qualifié, produire la décision et démontrer les flux qui restent dans son périmètre.

Force spécifique → Combinaison rare : capital 100 % FR + PASSI LPM + opérations 100 % FR sans astreinte hors zone — profil compatible OIV strict.

Adéquation documentée· 4

Advens

Souverain FR· Lille

Aucune qualification SecNumCloud du MDR n'est déduite. Le rapprochement repose sur capacité d'orchestration de plusieurs piles documentée. Le fournisseur doit nommer le service cloud qualifié, produire la décision et démontrer les flux qui restent dans son périmètre.

Force spécifique → Capacité d'opérer 100 % souverain en option — le client choisit la stack au démarrage.

Intrinsec

Souverain FR· Courbevoie

Aucune qualification SecNumCloud du MDR n'est déduite. Le rapprochement repose sur relation de groupe avec Cloud Temple évoquée, sans preuve publique que le MDR utilise un service qualifié précis. Le fournisseur doit nommer le service cloud qualifié, produire la décision et démontrer les flux qui restent dans son périmètre.

Force spécifique → Adossement Neurones coté + lien structurel Cloud Temple SecNumCloud — chaîne souveraine activable contractuellement.

ITrust

Souverain FR· Labège

Aucune qualification SecNumCloud du MDR n'est déduite. Le rapprochement repose sur SIEM/XDR Reveelium et plusieurs modèles de déploiement documentés. Le fournisseur doit nommer le service cloud qualifié, produire la décision et démontrer les flux qui restent dans son périmètre.

Force spécifique → Éditeur indépendant FR avec SOC en propre + 3 modes de déploiement — adapté à un OIV qui veut on-premise sous SecNumCloud.

Hexanet

Souverain FR· Reims

Aucune qualification SecNumCloud du MDR n'est déduite. Le rapprochement repose sur hébergement et pile française revendiqués. Le fournisseur doit nommer le service cloud qualifié, produire la décision et démontrer les flux qui restent dans son périmètre.

Force spécifique → Souveraineté assumée bout-en-bout sur stack 100 % FR — alignement de fait avec la doctrine SecNumCloud, même sans la qualif formelle.

05 — POINTS DE VIGILANCE

Limites et vérifications nécessaires

Aucune technologie ou société n'est « exclue SecNumCloud » par simple origine. En revanche, un composant SaaS, un accès de support, une sauvegarde ou une télémétrie hors du service qualifié peut faire sortir l'architecture du périmètre attendu. L'analyse doit porter sur le service et les flux réels, pas sur les slogans de souveraineté ou la nationalité supposée du fournisseur.

06 — RFP

Questions à poser au fournisseur

☐Opérez-vous depuis un cloud SecNumCloud qualifié ? Lequel (OVHcloud, S3NS, Numspot, Cloud Temple, Outscale) ? Numéro de qualif ?
☐Si non, êtes-vous compatible avec un cloud SecNumCloud du client ? Quel cloud ? Quel niveau d'intégration (API, déploiement, supervision) ?
☐Quels sont les éditeurs tiers que vous utilisez pour la détection (SIEM, EDR, XDR, SOAR) ? Capital, juridiction, hébergement de leur SaaS ?
☐Vos télémétries (logs EDR, événements SIEM) sont-elles traitées exclusivement en UE ? Y a-t-il transmission hors UE pour réentraînement IA, threat intel, support ?
☐Vos sous-traitants (support, analystes, rotation mondiale, threat intel) sont-ils tous UE ? Avez-vous une liste auditable ?
☐Quelles clauses contractuelles spécifiques acceptez-vous (localisation stricte, refus injonction extra-UE, audit ANSSI conjoint) ?
☐Quel est votre plan de réversibilité ? Format d'export, durée, capacité à transférer vers un autre prestataire SecNumCloud ?
☐Êtes-vous référencé UGAP / centrale d'achat publique avec mention SecNumCloud ? Avez-vous des références OIV publiques ?

07 — À RETENIR

Conclusion

Au 1er septembre 2026, S3NS est bien qualifié, mais cette preuve concerne « Cloud de confiance S3NS » et Thales Cloud Sécurisé, pas tout service du groupe Thales. Pour chaque candidat MDR, exigez un schéma d'architecture annoté avec les décisions ANSSI, les éléments hors périmètre et les accès de support. Une compatibilité SecNumCloud peut être utile ; elle ne doit jamais être présentée comme une qualification du MDR.

08 — SOURCES

Sources officielles et dates de contrôle

ANSSI