NIS2 et IA : la sécurité devient un critère de projet

La cybersécurité entre dans le cahier des charges IA

Une PME belge peut encore penser que NIS2 est une affaire de grandes organisations, d’hôpitaux, d’énergie, de télécoms ou d’infrastructures critiques. C’est parfois vrai juridiquement. C’est de moins en moins vrai commercialement.

Le Centre for Cybersecurity Belgium indique qu’un an après l’entrée de NIS2 en droit belge, 1 500 entités essentielles et 2 500 entités importantes sont déjà enregistrées. Ces organisations ne vont pas sécuriser uniquement leurs propres serveurs. Elles vont aussi regarder leurs fournisseurs, intégrateurs, agences, éditeurs, prestataires IT et sous-traitants métier.

Un projet IA arrive exactement dans cette zone sensible. Il lit des documents, se connecte parfois au CRM ou à l’ERP, résume des échanges clients, prépare des réponses, classe des demandes, appelle des API, ou donne accès à un fournisseur externe. Ce n’est plus seulement un outil de productivité. C’est un nouveau chemin dans le système d’information.

CCB, bilan NIS2 et Cyber Threat Landscape and Actions Taken in Belgium, vérifiés le 13 juin 2026.

Le risque n’est pas le modèle, c’est le branchement

Dans beaucoup de PME, le premier réflexe consiste à demander si l’outil IA est “conforme”. La question est trop courte. Un assistant générique utilisé pour reformuler un texte n’expose pas le même risque qu’un agent connecté à la boîte mail commerciale, au dossier partagé, au CRM ou à un espace client.

Le vrai changement se produit au moment du branchement. Qui a créé le compte ? Avec quelle adresse ? Le fournisseur garde-t-il les données ? Quels documents sont envoyés au modèle ? Les accès sont-ils partagés ? L’outil peut-il modifier une fiche client ou seulement proposer une réponse ? Que se passe-t-il si le prestataire arrête le service ? Qui reçoit l’alerte si un compte est compromis ?

Ces questions ne bloquent pas l’IA. Elles évitent que le pilote devienne une exception permanente.

Ce que NIS2 change pour une PME hors champ

Une PME qui n’entre pas directement dans le périmètre NIS2 peut tout de même être touchée de trois manières.

Par ses clients. Un client essentiel ou important peut demander des preuves : mesures de sécurité, gestion des accès, notification d’incident, continuité, clauses fournisseur, localisation ou sous-traitance. Si l’IA touche le service fourni, elle entre dans la discussion.

Par ses fournisseurs. Un prestataire IA, cloud, MSP, intégrateur ou éditeur peut devenir une dépendance critique. La PME doit comprendre ce qu’il fait, ce qu’il garde, ce qu’il journalise, et comment sortir proprement.

Par ses incidents. Le CCB rappelle que les interventions d’urgence ont concerné des intrusions réseau, fuites d’identifiants, compromissions d’e-mail professionnel, menaces internes, ransomware, malware et phishing. Un assistant IA mal intégré peut aggraver plusieurs de ces scénarios : plus de données exposées, plus d’automatisations, plus de comptes oubliés.

ENISA ajoute un point utile pour les PME : les petites organisations sont de plus en plus ciblées dans les attaques de chaîne d’approvisionnement, parce que leurs pratiques sont souvent moins matures et leurs moyens plus limités. Pour une PME fournisseur d’une grande organisation, la question n’est donc pas “suis-je trop petite pour NIS2 ?” mais “suis-je un maillon faible visible ?”

ENISA NIS360 2026, vérifié le 13 juin 2026.

La fiche minimale d’un projet IA

Avant de passer un pilote en production, une PME devrait écrire une fiche d’usage d’une page. Pas un dossier de conformité de cinquante pages. Une fiche lisible par le dirigeant, le responsable métier, l’IT et le fournisseur.

Question	Réponse attendue
Usage	Quel problème métier l’IA traite-t-elle, et quelle décision reste humaine ?
Données	Quels documents, champs CRM, emails, fichiers ou tickets sont utilisés ?
Accès	Quels comptes, clés API, droits et rôles sont nécessaires ?
Fournisseur	Qui traite les données, où, avec quelles sous-traitances et quelles clauses ?
Traces	Quels logs, validations, versions de prompts ou sorties sont conservés ?
Incident	Qui prévient-on si l’outil fuit, hallucine, envoie, modifie ou bloque ?
Sortie	Comment arrêter l’outil sans perdre les données, le savoir et le service ?

CCB, page NIS2 et Commission européenne, AI Act, vérifiés le 13 juin 2026.

Cette fiche a un avantage : elle force le projet à sortir de la démonstration. Tant que personne ne sait nommer les données, les accès et le scénario d’incident, le projet n’est pas prêt pour la production.

Le point de contrôle fournisseur

Le fournisseur IA n’est pas seulement celui qui vend le modèle. C’est parfois l’agence qui configure l’automatisation, l’intégrateur qui branche le CRM, l’éditeur métier qui ajoute une fonction IA, le consultant qui garde les prompts, ou le MSP qui administre les comptes.

Pour une PME, cinq vérifications suffisent souvent à révéler la maturité du montage.

• Le fournisseur distingue clairement données de test, données client et données sensibles.
• Les accès techniques utilisent des comptes dédiés, pas des comptes personnels partagés.
• Les sorties importantes sont validées par une personne identifiée avant envoi ou action.
• Les journaux permettent de comprendre qui a demandé quoi, quand et avec quelle version.
• Le contrat prévoit incident, suppression, réversibilité et sous-traitants.

Si le fournisseur répond uniquement par “nos modèles sont sécurisés”, il manque le sujet. La sécurité d’un projet IA dépend de l’assemblage : données, droits, interfaces, humains, procédures et preuves.

AI Act et NIS2 vont dans la même direction

L’AI Act et NIS2 ne poursuivent pas le même objectif. L’un encadre les systèmes d’IA et certains usages. L’autre renforce la cybersécurité des réseaux et systèmes d’information dans des secteurs critiques. Mais pour une PME qui lance un projet, les deux textes poussent vers la même discipline : documenter l’usage réel, former les personnes concernées, garder des traces et prévoir les incidents.

Le CCB a rappelé en avril 2026 que les entités essentielles devaient pouvoir démontrer la mise en oeuvre effective de mesures de gestion du risque cybersécurité et suivre une voie de conformité reconnue. Même si votre PME n’est pas dans cette catégorie, un client soumis à ce niveau d’exigence ne voudra pas d’un fournisseur incapable d’expliquer son propre usage de l’IA.

La bonne décision n’est donc pas d’attendre d’être obligé. Elle consiste à rendre chaque nouveau projet IA présentable : pourquoi il existe, ce qu’il touche, qui le contrôle, et comment il s’arrête.

La décision rapide

Pour une PME belge, la cybersécurité ne doit pas devenir un prétexte pour refuser l’IA. Elle doit devenir un critère de sélection.

Un bon projet IA accepte d’être décrit : usage, données, fournisseur, accès, traces, validation, incident, sortie. Un mauvais projet reste dans les slogans : gain de temps, automatisation, copilote, agent, innovation. Les clients soumis à NIS2 feront de moins en moins confiance à ce vocabulaire flou.

Le bon premier chantier est sobre. Choisissez un seul usage. Interdisez les comptes personnels. Limitez les données. Gardez une trace des validations. Demandez au fournisseur comment il supprime, journalise et notifie. Écrivez le scénario d’arrêt. Si tout cela paraît trop lourd pour le pilote, c’est souvent que le pilote touche déjà un processus plus sensible qu’annoncé.