Sécurité de l'IA en industrie : AI Act, NIST CSF, et framework d'intégration en entreprise

Le problème en une ligne

Une ETI industrielle qui déploie de l’IA sans cadre de sécurité ne prend pas un risque technique — elle prend un risque juridique, financier et réputationnel. L’AI Act européen est entré en application progressive depuis février 2025, et les premières sanctions tombent dès août 2026.

Cet article n’est pas un résumé de texte réglementaire. C’est un guide d’intégration : comment une ETI de 150 à 2 000 salariés, avec un SI Microsoft 365, des capteurs en production et un bureau d’études, peut déployer l’IA en respectant le cadre légal sans paralyser l’innovation.

1. AI Act européen — ce que ça change concrètement

Le Règlement européen sur l’intelligence artificielle (Règlement UE 2024/1689) est le premier cadre juridique contraignant au monde dédié à l’IA. Il ne régule pas la technologie en tant que telle, mais les usages — et c’est une distinction fondamentale.

Les quatre classes de risque

L’AI Act classe chaque système d’IA selon son niveau de risque pour les droits fondamentaux et la sécurité. La classification dépend du cas d’usage, pas du modèle sous-jacent.

Classe	Définition	Exemples industriels	Obligations
Inacceptable	Pratiques interdites	Scoring social des employés, manipulation comportementale subliminale, surveillance biométrique temps réel en usine	Interdiction totale
Élevé	Systèmes touchant la sécurité ou les droits fondamentaux	Contrôle qualité sur des produits soumis à la Directive Machines (2006/42/CE), systèmes de recrutement automatisé, scoring crédit fournisseur	Évaluation de conformité, registre EU, surveillance humaine, documentation technique
Limité	Systèmes interagissant avec des personnes	Chatbot service client, assistant RH, générateur de rapports	Obligation de transparence (l’utilisateur doit savoir qu’il interagit avec une IA)
Minimal	Tout le reste	Maintenance prédictive, optimisation process, planification production, recommandation de paramètres machines	Aucune obligation spécifique (bonnes pratiques recommandées)

Impact concret pour une ETI industrielle

La majorité des cas d’usage IA en industrie tombent dans la catégorie minimal ou limité. La maintenance prédictive, l’optimisation de paramètres, le SPC augmenté, la planification — tout ça est catégorie minimale.

Mais attention aux cas limites :

Vision par ordinateur sur le poste de travail : si le système analyse les gestes des opérateurs pour évaluer leur performance, c’est potentiellement du risque élevé (évaluation de personnes dans un contexte professionnel). Si le système ne regarde que les pièces et ignore les humains, c’est du risque minimal.
Recrutement : tout système qui filtre, classe ou évalue des candidats est automatiquement risque élevé. Même un simple scoring de CV par IA.
Sécurité des travailleurs : un système IA qui détecte le port des EPI et génère des alertes est risque élevé dès lors qu’il identifie des individus.

Obligations par classe — le détail

Pour les systèmes à risque élevé (les seuls avec des obligations lourdes) :

Système de gestion des risques — Identification, évaluation et mitigation des risques tout au long du cycle de vie. Pas un document ponctuel, un processus continu.
Gouvernance des données — Les données d’entraînement doivent être pertinentes, représentatives, sans biais excessif. Documentation de la provenance, du nettoyage, de l’annotation.
Documentation technique — Spécification du système, performance mesurée, limites connues, jeux de test utilisés. Format : annexe IV du règlement.
Enregistrement des événements (logs) — Traçabilité automatique des décisions du système. Durée de conservation : au minimum la durée prévue par l’obligation sectorielle, sinon 6 mois.
Transparence — L’utilisateur doit comprendre les outputs du système. Pas une boîte noire.
Surveillance humaine — Un humain doit pouvoir superviser, interpréter et, si nécessaire, désactiver le système.
Robustesse et cybersécurité — Le système doit résister aux attaques adverses, aux données corrompues, aux conditions hors distribution.
Enregistrement dans la base de données EU — Déclaration obligatoire avant mise sur le marché.

Timeline d’application

Date	Étape
1er août 2024	Publication au JOUE
2 février 2025	Interdiction des pratiques inacceptables (Titre II)
2 août 2025	Obligations pour les modèles d’IA à usage général (GPAI), y compris les fondations models
2 août 2026	Obligations pour les systèmes à risque élevé définis à l’Annexe III
2 août 2027	Obligations pour les systèmes à risque élevé couverts par la législation d’harmonisation de l’UE (Annexe I)

Sanctions

Les amendes sont calibrées pour être dissuasives, même pour les grandes entreprises :

Infraction	Amende maximale
Pratique interdite	35 M€ ou 7% du CA mondial
Non-conformité risque élevé	15 M€ ou 3% du CA mondial
Fausse déclaration	7,5 M€ ou 1,5% du CA mondial

Pour une ETI à 50 M€ de CA, une non-conformité sur un système à risque élevé représente jusqu’à 1,5 M€. C’est un risque existentiel.

La bonne nouvelle : si vos systèmes IA sont en catégorie minimale (maintenance prédictive, optimisation process), vous n’avez aucune obligation réglementaire spécifique au titre de l’AI Act. Mais documenter votre classification est une protection juridique en soi.

2. NIST Cybersecurity Framework 2.0 — la colonne vertébrale de la sécurité IA

Le NIST CSF 2.0 (février 2024) n’est pas européen, mais c’est le framework de référence mondial pour structurer une démarche de cybersécurité. L’ANSSI le recommande comme socle méthodologique. Sa force : il est applicable à n’importe quelle taille d’organisation et à n’importe quel domaine, y compris l’IA industrielle.

Les 6 fonctions

Le CSF 2.0 ajoute Govern aux 5 fonctions historiques. C’est la nouveauté majeure : la gouvernance n’est plus implicite, elle est au centre du framework.

GOVERN — La gouvernance de la cybersécurité

La fonction Govern encadre la stratégie, les rôles, les politiques et la supervision. C’est le “qui décide quoi” de la sécurité IA.

Application à un pipeline ML industriel :

Définir un responsable IA (même à temps partiel). Dans une ETI, c’est souvent le DSI ou le responsable qualité. L’important est qu’une personne nommée ait l’autorité de stopper un déploiement.
Rédiger une politique d’usage de l’IA : quels cas d’usage sont autorisés, quels fournisseurs cloud sont approuvés, quelles données peuvent être envoyées à l’extérieur. Deux pages suffisent.
Intégrer l’IA dans le registre des traitements RGPD existant. Pas de registre séparé.
Définir le budget sécurité IA : tests, audits, formation. Ordre de grandeur pour une ETI : 0,5 à 2 % du budget IT.

IDENTIFY — Cartographier les actifs et les risques

Savoir ce qu’on protège avant de protéger.

Application concrète :

Inventaire des systèmes IA : modèles déployés, modèles en développement, APIs tierces utilisées, données d’entraînement. Un tableur suffit. Colonnes : nom, fournisseur, données consommées, classification AI Act, criticité business, responsable.
Analyse des flux de données : d’où viennent les données (capteurs, ERP, MES), où vont-elles (cloud, edge, stockage local), qui y a accès.
Évaluation des risques : pour chaque système IA, identifier les scénarios de défaillance. Un modèle de vision qui classe un défaut comme conforme (faux négatif) a un impact direct sur la qualité produit.

PROTECT — Mettre en place les contrôles de sécurité

Les barrières techniques et organisationnelles.

Application concrète :

Chiffrement des données d’entraînement : au repos (AES-256) et en transit (TLS 1.3). C’est non négociable.
Contrôle d’accès au modèle : qui peut entraîner, qui peut déployer, qui peut interroger. Principe du moindre privilège.
Versioning des modèles : chaque version d’un modèle ML doit être traçable (code, données d’entraînement, hyperparamètres, métriques). MLflow, DVC, ou même un dossier versionné sous Git.
Validation avant déploiement : un modèle ne passe en production qu’après validation sur un jeu de test représentatif, avec des métriques documentées.
Formation des équipes : les opérateurs qui utilisent un système IA doivent comprendre ses limites. Un briefing de 30 minutes par système suffit.

DETECT — Surveiller les anomalies

La sécurité, ce n’est pas que de la prévention. C’est aussi de la détection.

Application concrète :

Model drift monitoring : surveiller la distribution des inputs et des outputs du modèle en production. Si les données d’entrée dérivent par rapport aux données d’entraînement, le modèle devient non fiable. Outils : Evidently AI, WhyLabs, ou un simple test de Kolmogorov-Smirnov sur les features clés.

$D_n = \sup_x |F_n(x) - F_0(x)|$

Où $F_n(x)$ est la distribution empirique des données en production et $F_0(x)$ la distribution des données d’entraînement. Si $D_n$ dépasse le seuil critique, alerte.

Détection d’inputs adverses : en vision industrielle, un changement d’éclairage, un reflet, ou un artefact de caméra peut tromper le modèle. Surveiller le score de confiance des prédictions. Un score systématiquement bas est un signal.
Audit des logs d’accès : qui a interrogé le modèle, quand, avec quelles données. Les accès anormaux (volume inhabituel, horaires atypiques) déclenchent une alerte.

RESPOND — Réagir aux incidents

Que faire quand ça tourne mal.

Application concrète :

Procédure de rollback : pouvoir revenir à la version précédente du modèle en moins de 15 minutes. Cela suppose un pipeline CI/CD pour le ML, même minimal.
Isolation du système compromis : si un modèle produit des résultats aberrants, pouvoir le désactiver sans arrêter la production. Cela implique un mode dégradé (retour au contrôle manuel, par exemple).
Notification : qui prévenir en interne (responsable qualité, DSI), et le cas échéant en externe (CNIL si données personnelles compromises, autorité sectorielle si sécurité produit impactée).

RECOVER — Rétablir et apprendre

Revenir à la normale et empêcher la récurrence.

Application concrète :

Post-mortem structuré : chaque incident IA fait l’objet d’un REX (Retour d’Expérience). Causes racines, actions correctives, délai de mise en oeuvre. C’est la même logique que le 8D ou le A3 en qualité.
Réentraînement : si la cause est une dérive des données, réentraîner le modèle sur les données récentes et valider avant redéploiement.
Mise à jour de la politique : chaque incident enrichit la politique de sécurité IA. Le registre des risques est un document vivant.

3. Gestion des accès Microsoft 365 / SharePoint — le maillon faible

La plupart des ETI industrielles utilisent Microsoft 365. C’est le système nerveux de l’entreprise : mails, fichiers, Teams, SharePoint. Quand on déploie de l’IA, les modèles ont besoin d’accéder à des données qui sont dans cet écosystème. Et c’est là que l’héritage des privilèges SharePoint devient un problème de sécurité IA.

Le piège de l’héritage SharePoint

SharePoint fonctionne par défaut en héritage de permissions : un sous-dossier hérite des droits du dossier parent. C’est pratique pour l’administration, mais ça crée des situations dangereuses quand un pipeline IA a accès à un dossier de niveau supérieur.

Scénario concret : le bureau d’études partage un dossier “Plans” sur SharePoint. Le responsable qualité y a accès pour les contrôles. Un assistant IA est connecté à ce dossier pour répondre aux questions des techniciens. Par héritage, l’IA a aussi accès au sous-dossier “Plans_Confidentiels_Client_X” — des documents sous NDA que les techniciens ne devraient pas voir.

Architecture recommandée pour une ETI industrielle

Voici une structure SharePoint sécurisée pour une ETI avec trois populations : production, bureau d’études et direction.

Sites SharePoint (niveau 1) :

Site	Population	Accès IA autorisé	Justification
`site-production`	Opérateurs, chefs d’équipe, maintenance	Oui (assistant documentation)	Procédures, gammes, fiches sécurité
`site-be`	Bureau d’études, méthodes	Restreint (indexation partielle)	Plans, calculs, CFAO — données sensibles
`site-direction`	Direction, RH, finance	Non	Données stratégiques et personnelles
`site-qualite`	Qualité, HSE	Oui (SPC, rapports)	Données process, non nominatives
`site-commun`	Tous	Oui	Procédures générales, documentation fournisseur

Principe : casser l’héritage à la racine de chaque site, puis définir des groupes de sécurité Azure AD spécifiques.

Groupes de sécurité Azure AD

SG-Production-Lecteur      → Accès lecture site-production
SG-Production-Contributeur → Accès écriture site-production
SG-BE-Lecteur              → Accès lecture site-be
SG-BE-Confidentiel         → Accès sous-dossiers sous NDA
SG-Direction-Full           → Accès site-direction
SG-IA-DocumentAssistant    → Accès lecture site-production + site-qualite + site-commun
SG-IA-IndexBE              → Accès lecture site-be HORS dossiers confidentiels

Le groupe SG-IA-DocumentAssistant est celui qui est attribué au service principal (service account) de l’IA. Il a un périmètre explicite, restreint, auditable.

Conditional Access — Azure AD

Le Conditional Access est le mécanisme qui permet de conditionner l’accès à des ressources Microsoft 365 selon le contexte : appareil, localisation, niveau de risque, application.

Politiques recommandées pour l’IA :

Politique	Condition	Action
Bloquer l’accès IA depuis l’extérieur	IP source hors plage réseau entreprise	Bloquer
MFA obligatoire pour les admins IA	Rôle = admin du service IA	Exiger MFA
Bloquer les appareils non conformes	Appareil non géré par Intune	Bloquer l’accès aux sites SharePoint sensibles
Session limitée pour le service account IA	Application = service IA	Session max 8h, re-auth obligatoire
Alerte sur accès massif	Volume de requêtes > 10 000/h	Alerte + throttle

Automatiser avec Microsoft Graph API

La gestion manuelle des permissions ne tient pas à l’échelle. Microsoft Graph API permet d’automatiser l’attribution, la révocation et l’audit des droits.

Exemple : lister les permissions effectives d’un service account IA sur un site SharePoint

import requests

GRAPH_URL = "https://graph.microsoft.com/v1.0"
TOKEN = "..."  # OAuth2 token avec scope Sites.Read.All

# Obtenir les permissions du site
site_id = "contoso.sharepoint.com,site-guid,web-guid"
response = requests.get(
    f"{GRAPH_URL}/sites/{site_id}/permissions",
    headers={"Authorization": f"Bearer {TOKEN}"}
)

for perm in response.json().get("value", []):
    roles = perm.get("roles", [])
    identity = perm.get("grantedToV2", {})
    app = identity.get("application", {})
    user = identity.get("user", {})
    print(f"  {app.get('displayName', user.get('displayName', '?'))} → {roles}")

Exemple : révoquer un accès IA à un dossier spécifique

# Casser l'héritage sur un dossier et retirer le service account IA
drive_item_id = "folder-guid"
perm_id = "permission-id-to-revoke"

requests.delete(
    f"{GRAPH_URL}/drives/{drive_id}/items/{drive_item_id}/permissions/{perm_id}",
    headers={"Authorization": f"Bearer {TOKEN}"}
)

Automatisation recommandée : un script hebdomadaire qui audite les permissions effectives du service account IA et génère un rapport de conformité. Si une permission non autorisée est détectée (ajoutée par un admin local SharePoint, par exemple), elle est automatiquement révoquée.

4. Architecture zero trust pour les données industrielles

Le principe : never trust, always verify

Le modèle de sécurité traditionnel est périmétrique : on protège le réseau de l’entreprise avec un firewall, et tout ce qui est à l’intérieur est considéré comme de confiance. Ce modèle est mort. Il suppose que la menace vient de l’extérieur, alors que la majorité des incidents de sécurité impliquent des accès internes légitimes mal contrôlés.

Le zero trust inverse la logique : aucun utilisateur, aucun appareil, aucun service n’est considéré comme fiable a priori. Chaque accès est vérifié, chaque session est limitée dans le temps, chaque flux de données est authentifié.

Segmentation IT/OT — le point critique en industrie

Dans une usine, deux mondes coexistent :

IT (Information Technology) : les serveurs, le réseau bureautique, Microsoft 365, l’ERP. Protocoles : TCP/IP, HTTPS, SMB.
OT (Operational Technology) : les automates (PLC), les capteurs, les SCADA, les IHM. Protocoles : Modbus, Profinet, OPC-UA, EtherNet/IP.

Historiquement, ces deux réseaux étaient séparés physiquement (air gap). Avec l’industrie 4.0 et l’IA, ils se connectent — et c’est là que le risque explose.

Architecture de référence — modèle Purdue adapté zero trust :

Niveau	Nom	Exemples	Zone réseau
5	Cloud / SaaS	Azure ML, APIs LLM, Microsoft 365	Internet (contrôlé)
4	Enterprise	ERP, PLM, BI, data lake	DMZ entreprise
3.5	DMZ industrielle	Historian, gateway OPC-UA, broker MQTT	Zone tampon (CRITIQUE)
3	Site operations	MES, supervision, SCADA serveur	Réseau industriel
2	Area control	Automates, contrôleurs, HMI	Réseau automate
1	Basic control	I/O, variateurs, capteurs intelligents	Réseau terrain
0	Process	Capteurs passifs, actionneurs	Câblage physique

La DMZ industrielle (niveau 3.5) est le point névralgique. C’est par là que transitent les données de production vers le cloud ou le data lake. Aucun flux direct du niveau 2 vers le niveau 5 ne doit exister.

Flux de données capteur vers cloud — points de contrôle

Voici le chemin typique d’une donnée capteur dans une architecture zero trust :

Capteur (niveau 0-1) → Signal analogique ou numérique, pas d’authentification possible à ce niveau.

Automate / Gateway edge (niveau 2-3) → Premier point de contrôle. Le gateway edge (un Raspberry Pi industriel, un Siemens IOT2050, un dispositif Moxa) authentifie le flux via certificat TLS mutuel (mTLS) avant de le transmettre au niveau supérieur. Les données sont bufferisées localement en cas de perte réseau.

DMZ industrielle (niveau 3.5) → Deuxième point de contrôle. Un broker MQTT ou un serveur OPC-UA reçoit les données, les valide (format, plage de valeurs, fréquence), et les transmet au data lake. Pare-feu applicatif (WAF) entre la DMZ et le réseau IT.

Data lake / Historian (niveau 4) → Troisième point de contrôle. Les données sont stockées chiffrées (AES-256). L’accès est contrôlé par identité (service account avec token à durée limitée). Les requêtes sont loggées.

Cloud / API IA (niveau 5) → Quatrième point de contrôle. Les données envoyées au cloud sont anonymisées ou pseudonymisées. L’API est authentifiée par clé + certificat. La connexion est chiffrée (TLS 1.3). Les données restent dans la région EU (conformité RGPD).

Règles de flux zero trust

Source	Destination	Protocole	Authentification
Capteur → Gateway	OPC-UA / Modbus TCP	Certificat X.509 (mTLS)	TLS 1.3
Gateway → DMZ	MQTT / AMQP	Token JWT signé	TLS 1.3
DMZ → Data lake	HTTPS / gRPC	Service account Azure AD	TLS 1.3 + AES-256 at rest
Data lake → Cloud ML	HTTPS	API key + certificat	TLS 1.3
Cloud ML → Application	HTTPS	OAuth2 + RBAC	TLS 1.3

Aucun flux descendant (du cloud vers l’OT) ne doit être autorisé sans validation humaine explicite. Un modèle IA ne doit jamais pouvoir écrire directement sur un automate en production.

5. Framework d’intégration IA sécurisée — checklist en 8 étapes

Cette checklist est conçue pour un DSI ou un RSSI qui doit intégrer un premier cas d’usage IA dans un SI industriel existant. Chaque étape produit un livrable concret.

Étape 1 — Classifier le cas d’usage (AI Act)

Livrable : fiche de classification (1 page)

Répondre à trois questions :

Le système IA prend-il ou influence-t-il des décisions concernant des personnes ? (oui = risque élevé potentiel)
Le système est-il couvert par une directive sectorielle (Machines, Dispositifs médicaux, Produits de construction) ? (oui = vérifier l’Annexe I)
Le système interagit-il directement avec des utilisateurs humains ? (oui = au minimum risque limité, obligation de transparence)

Si aucune de ces conditions n’est remplie → risque minimal. Documenter la classification et passer à l’étape 2.

Étape 2 — Cartographier les données

Livrable : data flow diagram

Identifier :

Sources de données (capteurs, ERP, MES, SharePoint, saisie manuelle)
Nature des données (process, qualité, maintenance, RH, financier)
Données personnelles (présence détectée ? → RGPD applicable)
Flux : où les données sont-elles stockées, transformées, envoyées ?

Étape 3 — Évaluer les risques

Livrable : matrice de risque (probabilité x impact)

Pour chaque risque identifié, évaluer :

$\text{Score de risque} = P(\text{occurrence}) \times I(\text{impact}) \times (1 - E(\text{contrôle existant}))$

Où $P$ est la probabilité (1 à 5), $I$ l’impact (1 à 5), et $E$ l’efficacité du contrôle existant (0 à 1). Un score supérieur à 12 nécessite une action corrective avant déploiement.

Risques types :

Fuite de données de production vers un fournisseur cloud
Faux négatif du modèle (défaut non détecté)
Dérive du modèle non détectée
Accès non autorisé au modèle ou à ses données d’entraînement
Indisponibilité du service IA (impact sur la production si dépendance critique)

Étape 4 — Définir l’architecture technique

Livrable : schéma d’architecture avec zones de confiance

Décider :

Où tourne le modèle (cloud, edge, on-premise) — voir section 6
Quels flux réseau sont nécessaires
Où se situent les points de contrôle zero trust
Quel niveau de redondance est requis

Étape 5 — Configurer les accès

Livrable : matrice RBAC (Role-Based Access Control)

Rôle	Peut entraîner	Peut déployer	Peut interroger	Peut auditer	Peut désactiver
Data scientist	Oui	Non	Oui	Oui	Non
DevOps / MLOps	Non	Oui	Oui	Oui	Oui
Opérateur	Non	Non	Oui	Non	Non
Responsable qualité	Non	Non	Oui	Oui	Oui
DSI / RSSI	Non	Oui (validation)	Oui	Oui	Oui

Implémenter via Azure AD + Conditional Access (voir section 3).

Étape 6 — Mettre en place le monitoring

Livrable : tableau de bord de surveillance

Métriques à suivre :

Performance modèle : accuracy, precision, recall, F1 — mesurés sur données réelles, pas sur le jeu de test
Data drift : distance statistique entre distribution d’entraînement et distribution de production (KS test, PSI)

$PSI = \sum_{i=1}^{k} (P_i - Q_i) \cdot \ln\left(\frac{P_i}{Q_i}\right)$

Où $P_i$ est la proportion dans le bin $i$ pour les données de production et $Q_i$ pour les données d’entraînement. $PSI > 0.2$ = dérive significative, investigation requise.

Latence : temps de réponse du modèle (P50, P95, P99)
Volume : nombre de prédictions/jour, tendance
Accès : tentatives d’accès refusées, accès depuis des IPs inhabituelles

Étape 7 — Documenter et former

Livrable : dossier de conformité + supports de formation

Le dossier comprend :

Classification AI Act (étape 1)
Data flow diagram (étape 2)
Matrice de risque (étape 3)
Architecture technique (étape 4)
Matrice RBAC (étape 5)
Procédures d’exploitation : déploiement, rollback, incident, réentraînement
Registre de traitement RGPD mis à jour

La formation couvre :

Opérateurs : utilisation du système, limites, procédure de signalement d’anomalie (30 min)
Managers : interprétation des résultats, procédure de désactivation (1h)
IT : administration, monitoring, procédure d’incident (2h)

Étape 8 — Auditer et itérer

Livrable : rapport d’audit périodique

Fréquence recommandée : trimestriel la première année, semestriel ensuite.

Contenu de l’audit :

Revue des métriques de monitoring (étape 6)
Vérification de la conformité des accès (permissions effectives vs permissions autorisées)
Test de robustesse (inputs adverses, données hors distribution)
Revue des incidents depuis le dernier audit
Mise à jour de la matrice de risque si nécessaire

6. Données sensibles et modèles — où, comment, et sous quel régime juridique

Où tournent les modèles

Le choix entre cloud et on-premise n’est pas binaire. C’est un spectre, et la décision dépend de la sensibilité des données, du volume, de la latence requise et du budget.

Architecture	Données restent sur site	Latence	Coût initial	Coût récurrent	Cas d’usage typique
Full cloud (API)	Non	200-500 ms	Nul	Proportionnel au volume	Assistant documentaire, génération de rapports
Cloud privé (Azure ML, AWS SageMaker)	Dans le tenant	100-300 ms	Moyen	Moyen	Modèles custom, données modérément sensibles
Edge (gateway industriel)	Oui	10-50 ms	Moyen	Faible	Vision temps réel, alertes process
On-premise (serveur local)	Oui	5-100 ms	Élevé	Faible	Données très sensibles, conformité stricte
Hybride	Partiellement	Variable	Moyen	Moyen	Entraînement cloud, inférence locale

Règle pragmatique : si les données sont soumises à un NDA client ou contiennent des cotes de fabrication, le modèle doit tourner on-premise ou en edge. Pas de compromis.

Chiffrement

At rest (données stockées) :

AES-256 pour les fichiers et bases de données
Chiffrement de la partition disque (BitLocker, LUKS) sur les serveurs hébergeant les modèles
Les clés de chiffrement sont stockées dans un HSM (Hardware Security Module) ou un Azure Key Vault, jamais en clair sur le serveur

In transit (données en mouvement) :

TLS 1.3 obligatoire sur tous les flux
mTLS (mutual TLS) entre les composants du pipeline ML
Pas de flux en clair, même sur le réseau interne

Anonymisation et pseudonymisation

La distinction est juridiquement fondamentale :

Anonymisation : suppression irréversible de tout lien avec une personne identifiable. Les données anonymisées ne sont plus des données personnelles au sens du RGPD. Mais l’anonymisation véritable est difficile à atteindre — les attaques par re-identification sont efficaces même sur des jeux de données agrégés.
Pseudonymisation : remplacement des identifiants directs par des pseudonymes, avec conservation de la table de correspondance. Les données restent des données personnelles au sens du RGPD, mais la pseudonymisation est considérée comme une mesure de sécurité appropriée (article 32).

En pratique pour les données industrielles :

Les données de capteurs (température, pression, vibration) ne sont pas des données personnelles en elles-mêmes. Elles le deviennent si elles sont associées à un opérateur identifié (ex : “production de l’opérateur Dupont le 15/03 de 6h à 14h”). Dans ce cas :

Dissocier les données process des données d’identification de l’opérateur
Si l’IA n’a pas besoin de savoir quel opérateur a produit, supprimer l’association
Si l’IA a besoin de différencier les opérateurs (pour un modèle de productivité par exemple), pseudonymiser : opérateur A, B, C

RGPD et données de production

Les obligations RGPD s’appliquent dès lors que des données personnelles sont traitées. En industrie, les cas les plus fréquents :

Type de données	Personnel ?	Obligation RGPD
Données capteurs process (T°, P, débit)	Non	Aucune
Données qualité produit (cotes, défauts)	Non	Aucune
Données machine (heures de marche, taux de panne)	Non	Aucune
Données badgeage / pointage	Oui	Base légale requise, durée limitée
Données de productivité par opérateur	Oui	Intérêt légitime, information des salariés, DPIA si profilage
Vidéosurveillance du poste de travail	Oui	Information, proportionnalité, DPIA obligatoire
Données RH dans un outil de recrutement IA	Oui	Consentement ou intérêt légitime, DPIA, AI Act risque élevé

DPIA (Data Protection Impact Assessment) : obligatoire pour les traitements à risque élevé. C’est l’analyse d’impact relative à la protection des données (article 35 RGPD). Le modèle de la CNIL est disponible en ligne et compte environ 10 pages pour un traitement standard.

7. Arbre de décision — quel framework appliquer ?

Cet arbre guide le choix du niveau de conformité requis pour un projet IA en contexte industriel.

graph TD
    A["Nouveau projet IA en industrie"] --> B{"Le système prend des décisions<br/>concernant des personnes ?"}

    B -->|Oui| C{"Recrutement, scoring,<br/>évaluation de performance ?"}
    B -->|Non| D{"Le système est couvert par<br/>une directive sectorielle ?<br/>(Machines, Dispositifs médicaux...)"}

    C -->|Oui| E["AI Act — Risque ÉLEVÉ<br/>Conformité complète obligatoire<br/>DPIA + Registre EU + Audit"]
    C -->|Non| F{"Le système identifie<br/>des individus ?<br/>(biométrie, vidéo...)"}

    F -->|Oui| G["AI Act — Risque ÉLEVÉ<br/>+ RGPD renforcé<br/>+ DPIA obligatoire"]
    F -->|Non| H["AI Act — Risque LIMITÉ<br/>Transparence obligatoire<br/>+ RGPD standard"]

    D -->|Oui| I{"Le système IA est un<br/>composant de sécurité<br/>du produit ?"}
    D -->|Non| J{"Le système interagit<br/>directement avec<br/>des utilisateurs ?"}

    I -->|Oui| K["AI Act — Risque ÉLEVÉ<br/>Évaluation de conformité<br/>par organisme notifié"]
    I -->|Non| L["AI Act — Risque MINIMAL<br/>Bonnes pratiques NIST CSF<br/>Documentation recommandée"]

    J -->|Oui| M["AI Act — Risque LIMITÉ<br/>Obligation de transparence<br/>NIST CSF recommandé"]
    J -->|Non| N["AI Act — Risque MINIMAL<br/>Aucune obligation spécifique<br/>NIST CSF recommandé"]

    N --> O{"Données envoyées<br/>hors site ?<br/>(cloud, API tierce)"}
    L --> O
    M --> O

    O -->|Oui| P["Zero trust obligatoire<br/>Chiffrement E2E<br/>Anonymisation si données sensibles"]
    O -->|Non| Q["Sécurité réseau standard<br/>Segmentation IT/OT<br/>Contrôle d'accès RBAC"]

    style A fill:#2C3E42,color:#FDFBF8,stroke:#7DB5A5
    style B fill:#566569,color:#FDFBF8,stroke:#2C3E42
    style C fill:#566569,color:#FDFBF8,stroke:#2C3E42
    style D fill:#566569,color:#FDFBF8,stroke:#2C3E42
    style E fill:#E99971,color:#FDFBF8,stroke:#2C3E42
    style F fill:#566569,color:#FDFBF8,stroke:#2C3E42
    style G fill:#E99971,color:#FDFBF8,stroke:#2C3E42
    style H fill:#7DB5A5,color:#FDFBF8,stroke:#2C3E42
    style I fill:#566569,color:#FDFBF8,stroke:#2C3E42
    style J fill:#566569,color:#FDFBF8,stroke:#2C3E42
    style K fill:#E99971,color:#FDFBF8,stroke:#2C3E42
    style L fill:#7DB5A5,color:#FDFBF8,stroke:#2C3E42
    style M fill:#7DB5A5,color:#FDFBF8,stroke:#2C3E42
    style N fill:#7DB5A5,color:#FDFBF8,stroke:#2C3E42
    style O fill:#566569,color:#FDFBF8,stroke:#2C3E42
    style P fill:#E99971,color:#FDFBF8,stroke:#2C3E42
    style Q fill:#FDFBF8,stroke:#7DB5A5,color:#2C3E42

Récapitulatif — les 5 erreurs les plus fréquentes

Ignorer la classification AI Act. “Notre IA ne fait que de la maintenance prédictive, on n’est pas concerné.” Peut-être. Mais sans documentation de la classification, c’est indémontrable devant un régulateur.
Faire confiance à l’héritage SharePoint. Un assistant IA connecté à SharePoint avec les droits d’un admin voit tout — y compris les données RH, les contrats clients sous NDA, et les documents financiers. Cassez l’héritage. Appliquez le moindre privilège.
Envoyer des données de production en clair à un LLM cloud. Chaque appel API à ChatGPT ou Claude envoie les données au fournisseur. Les conditions d’utilisation varient, mais aucun fournisseur ne garantit que les données ne seront jamais utilisées pour améliorer ses modèles (sauf contrat entreprise explicite). Pour des données sensibles, le on-premise est le seul choix défendable.
Pas de monitoring post-déploiement. Un modèle ML n’est pas un logiciel classique. Il se dégrade naturellement à mesure que les données de production s’éloignent des données d’entraînement. Sans monitoring du drift, la performance se dégrade silencieusement pendant des mois avant qu’un incident ne la révèle.
Pas de procédure de rollback. Si le modèle produit des résultats aberrants en production un vendredi à 17h, pouvez-vous revenir à la version précédente en 15 minutes ? Si la réponse est non, vous n’êtes pas prêt pour la production.

Le problème en une ligne

1. AI Act européen — ce que ça change concrètement

Les quatre classes de risque

Impact concret pour une ETI industrielle

Obligations par classe — le détail

Timeline d’application

Sanctions

2. NIST Cybersecurity Framework 2.0 — la colonne vertébrale de la sécurité IA

Les 6 fonctions

GOVERN — La gouvernance de la cybersécurité

IDENTIFY — Cartographier les actifs et les risques

PROTECT — Mettre en place les contrôles de sécurité

DETECT — Surveiller les anomalies

RESPOND — Réagir aux incidents

RECOVER — Rétablir et apprendre

3. Gestion des accès Microsoft 365 / SharePoint — le maillon faible

Le piège de l’héritage SharePoint

Architecture recommandée pour une ETI industrielle

Groupes de sécurité Azure AD

Conditional Access — Azure AD

Automatiser avec Microsoft Graph API

4. Architecture zero trust pour les données industrielles

Le principe : never trust, always verify

Segmentation IT/OT — le point critique en industrie

Flux de données capteur vers cloud — points de contrôle

Règles de flux zero trust

5. Framework d’intégration IA sécurisée — checklist en 8 étapes

Étape 1 — Classifier le cas d’usage (AI Act)

Étape 2 — Cartographier les données

Étape 3 — Évaluer les risques

Étape 4 — Définir l’architecture technique

Étape 5 — Configurer les accès

Étape 6 — Mettre en place le monitoring

Étape 7 — Documenter et former

Étape 8 — Auditer et itérer

6. Données sensibles et modèles — où, comment, et sous quel régime juridique

Où tournent les modèles

Chiffrement

Anonymisation et pseudonymisation

RGPD et données de production

7. Arbre de décision — quel framework appliquer ?

Récapitulatif — les 5 erreurs les plus fréquentes

Pour aller plus loin