Le 24 juillet 2026, l’ENISA a ouvert la consultation sur le futur schéma européen de certification des services de sécurité gérés, appelé EUMSS. Pour une PME belge qui externalise sa surveillance ou sa réponse à incident, le mot « certification » semble apporter une réponse simple : choisir un prestataire certifié et considérer le risque comme traité.
Le projet dit quelque chose de plus étroit. Sa première version certifierait un service de réponse à incident selon un périmètre et un niveau d’assurance définis. Elle ne certifierait ni toute l’entreprise qui fournit ce service, ni tous ses autres services, ni la configuration particulière du client. Elle ne rendrait pas non plus une PME conforme à NIS2.
Cette limite est utile. Elle oblige à distinguer le badge du travail attendu le jour où un compte administrateur est détourné, un connecteur IA extrait trop de données ou un agent exécute une action qu’il ne fallait pas autoriser.
Projet publié
24 juillet
Version 1.1 soumise à consultation.
Fin des avis
13 septembre
Les réponses restent ouvertes jusque-là.
Premier profil
1 service
La réponse à incident uniquement.
ENISA, consultation EUMSS, vérifiée le 25 juillet 2026.
Le service sera certifié, pas le prestataire entier
Le règlement européen de 2025 définit largement les services de sécurité gérés : gestion d’incidents, tests d’intrusion, audits, conseil technique, renseignement sur les menaces ou évaluation des risques. Le projet publié cet été ne couvre pas encore toute cette liste.
Il combine deux couches. Une couche horizontale rassemble les exigences communes : conception sécurisée, intégration chez le client, continuité, exploitation, maintenance, gestion des accès, sous-traitance et amélioration continue. Une couche verticale décrit ensuite le service précis qui fait l’objet du certificat.
La seule verticale aboutie dans la version 1.1 concerne la réponse à incident. La détection, la qualification, la restauration, l’analyse après incident, les tests d’intrusion et le conseil pourront rejoindre de futures versions. Ils ne doivent pas être supposés couverts aujourd’hui.
Le projet prévoit trois niveaux d’assurance — élémentaire, substantiel et élevé — mais le niveau ne transforme pas le périmètre. Il augmente la profondeur de l’évaluation appliquée au même service. Un certificat « élevé » de réponse à incident ne devient donc pas un certificat général du centre opérationnel de sécurité, de l’outil de surveillance ou de toutes les prestations du fournisseur.
Le badge ne se lit jamais seul
Il faudra vérifier le service certifié, son niveau d’assurance, sa version, ses dépendances et sa date de validité. Le nom du prestataire ne suffira pas.
Le texte distingue aussi le service standard de son déploiement. Le certificat attesterait la capacité du fournisseur à livrer ce service à ses clients. Il ne serait pas réémis pour chaque instance. Le raccordement à votre réseau, vos journaux disponibles, vos comptes cloud, vos délais d’autorisation et vos sauvegardes resteront donc à vérifier dans votre propre dossier.
ENISA, projet EUMSS v1.1, sections 0.2 et 1.4, vérifié le 25 juillet 2026.
Un incident IA traverse plusieurs contrats
Un pilote IA ajoute rarement un seul logiciel. Il relie une application, un modèle hébergé, une base documentaire, des identités, des connecteurs et parfois un outil capable d’agir dans le CRM, la messagerie ou l’ERP.
Quand un incident survient, le prestataire cyber doit comprendre cette chaîne avant de la contenir. Couper le compte de service peut arrêter la fuite, mais aussi interrompre une facturation ou un traitement client. Isoler la base vectorielle peut conserver les preuves, mais laisser le connecteur actif. Révoquer une clé API ne dit pas si les données déjà envoyées au fournisseur du modèle seront conservées.
Le périmètre contractuel doit donc nommer les objets réellement observés :
- les applications, modèles, connecteurs, comptes techniques et environnements couverts ;
- les journaux disponibles, leur horodatage, leur durée de conservation et leur export ;
- les données sensibles et les sous-traitants qui peuvent les recevoir ;
- les actions que le prestataire peut exécuter seul et celles qui exigent une autorisation ;
- la personne qui peut arrêter le service IA, révoquer un accès ou basculer en mode manuel ;
- la chaîne de conservation des preuves et la destination des copies d’enquête ;
- la restauration, la validation métier et les critères de remise en production.
Cette liste ne demande pas une architecture parfaite. Elle demande que l’équipe puisse répondre à une question ordinaire : « qui fait quoi dans les trente premières minutes ? »
L’ENISA observe que les modèles de pointe raccourcissent déjà le cycle entre découverte et exploitation d’une vulnérabilité. Sa recommandation n’est pas de confier toutes les décisions à une autre IA. Elle insiste sur les fondamentaux, la priorisation rapide et des flux automatisés gardés par des décisions humaines. Pour une PME, cette garde humaine doit apparaître dans le contrat, pas seulement dans une présentation commerciale.
ENISA, Cybersecurity in the Frontier AI Era, vérifié le 25 juillet 2026.
Le projet européen peut déjà servir de questionnaire
Attendre le certificat serait une mauvaise raison de reporter le cadrage. Le document EUMSS détaille déjà les trois moments d’un service : sa mise en place, son exécution et sa clôture. Une PME peut reprendre cette structure dans un appel d’offres ou un avenant.
Avant l’incident
Le contrat doit fixer les catégories d’incidents, les contacts, les horaires, les délais, les outils autorisés, les accès préparés et les dépendances du prestataire. Une promesse de disponibilité « 24/7 » ne répond pas à la question du temps nécessaire pour affecter un analyste capable d’agir sur votre environnement.
Demandez aussi une matrice d’autorisation. Elle doit distinguer l’observation, la collecte de preuves, le blocage d’un compte, l’isolement d’un système, l’arrêt d’un agent et la suppression d’une donnée. Plus l’action est difficile à inverser, plus la décision et son propriétaire doivent être explicites.
Pendant l’incident
Le projet EUMSS sépare l’ouverture du dossier, le triage, la collecte, l’analyse, le confinement, l’éradication et le passage à la reprise. Cette séquence évite qu’un prestataire confonde vitesse et précipitation.
Pour chaque étape, exigez une trace : heure, hypothèse, preuve, action, auteur, autorisation et résultat. Le fournisseur doit pouvoir travailler vite sans rendre l’enquête impossible. Le guide du Centre pour la Cybersécurité Belgique rappelle notamment de préparer le plan, les rôles, les experts externes, la surveillance, les accès et les sauvegardes avant l’incident.
Centre pour la Cybersécurité Belgique, Premiers secours en cas de cyberincident, vérifié le 25 juillet 2026.
Après l’incident
La clôture ne se limite pas à « service rétabli ». Le dossier doit contenir les causes, les systèmes et données touchés, les décisions prises, les preuves conservées, les corrections restant à mener et le responsable de chacune.
Pour l’IA, ajoutez la version du modèle ou du service, les prompts système concernés, les droits du connecteur et le jeu de tests utilisé avant la remise en production. Sans cette photographie, une mise à jour silencieuse peut réintroduire le même risque sous une autre forme.
Le test d’achat tient en un exercice
L’analyse de marché de l’ENISA relève trois obstacles récurrents à l’externalisation : le coût, le manque d’expertise interne et la difficulté d’adapter le niveau de service puis de l’intégrer aux processus du client. Un certificat commun peut réduire une partie du contrôle fournisseur. Il ne résout pas l’intégration.
Le test le plus court consiste à jouer un incident de quarante-cinq minutes avant la mise en production. Par exemple : un compte de service utilisé par l’assistant documentaire télécharge soudainement un volume anormal de fichiers. L’équipe doit décider qui reçoit l’alerte, qui peut bloquer le compte, comment préserver les journaux, comment prévenir le métier et comment continuer sans l’assistant.
Si le prestataire, l’intégrateur et la PME ne savent pas exécuter ce scénario avec les accès disponibles, le futur certificat ne réparera pas le contrat. S’ils y arrivent et produisent une trace exploitable, le label pourra plus tard ajouter une assurance utile à un dispositif déjà réel.
À faire avant lundi
Choisissez un seul usage IA, dessinez ses dépendances sur une page et demandez au prestataire cyber de jouer la perte ou le détournement de son compte technique.
Le bon achat n’est donc pas « un prestataire certifié ». C’est un service au périmètre lisible, raccordé à un plan que les personnes concernées ont déjà essayé.
Repères
Questions fréquentes.
Un prestataire peut-il déjà présenter un certificat EUMSS ?
Non. L’ENISA consulte sur un projet de schéma jusqu’au 13 septembre 2026. Il faudra encore finaliser et adopter le dispositif avant l’émission de certificats.
Le futur certificat prouvera-t-il la conformité NIS2 du client ?
Non. Le projet précise qu’un certificat pourra fournir certaines preuves utiles, sans remplacer la conformité NIS2 ni le contrôle de l’autorité compétente.
Que demander aujourd’hui pour protéger un pilote IA ?
Un périmètre technique, les rôles, les délais, les droits d’action, la conservation des preuves, les dépendances, le plan de reprise et un exercice réalisé avant la mise en production.
Sources.
Tout est vérifiable. Si vous trouvez une donnée qui ne colle pas, dites-le, on corrige et on date l'erratum.
- Presse 2026-07-25
- Primaire 2026-07-25
- Primaire 2026-07-25
- Loi 2026-07-25
- Donnée 2026-07-25
- Primaire 2026-07-25
Premiers secours en cas de cyberincident
Centre pour la Cybersécurité Belgique
- Primaire 2026-07-25