EN 18286 (norme harmonisée AI Act) : plan 30 jours pour une PME lyonnaise à risque

Octobre 2026 : ce qui a vraiment changé, là, tout de suite

Tu déploies un système d’IA « à haut risque » dans ta PME à Lyon. Jusque-là, tu pouvais lire l’AI Act et te dire : « OK, mais concrètement, on documente quoi, et dans quel ordre ? »

Depuis le 14 octobre 2026, il y a un changement très concret : EN 18286:2026 est désormais une norme harmonisée au titre de l’AI Act. Sa référence a été publiée au Journal officiel de l’UE (décision d’exécution de la Commission du 12 octobre 2026, publiée le 14 octobre 2026, applicable le jour de la publication). Source : DOUE-L-2026-81573.

Effet immédiat : si tu appliques EN 18286 dans le périmètre qu’elle couvre, tu bénéficies d’une présomption de conformité pour les exigences de l’AI Act couvertes par cette norme. La Commission rappelle ce mécanisme côté normes harmonisées : FAQ Commission sur la standardisation AI Act.

Point clé : EN 18286 vise surtout le système de management de la qualité attendu pour les IA à haut risque, en lien direct avec l’article 17 (Quality Management System). Source : AI Act Service Desk, Article 17.

EN 18286, « norme harmonisée », « présomption de conformité » : traduction en français simple

Norme harmonisée AI Act : ce que ça veut dire (utilement)

Une norme harmonisée, ce n’est pas « une norme ISO de plus ». C’est une norme :

• élaborée dans le cadre d’une demande de normalisation de la Commission,
• et surtout citée au Journal officiel de l’UE.

Quand elle est citée au JO, elle peut déclencher la logique de présomption. Source : Commission, standardisation AI Act.

Présomption de conformité : ce que ça change dans ta vie

La présomption de conformité veut dire : si tu prouves que tu respectes une norme harmonisée, alors les exigences légales couvertes par la norme sont présumées respectées. Tu peux toujours démontrer la conformité autrement, mais tu vas payer en temps, en preuves, en discussions, et parfois en audit.

Deux pièges à éviter :

• Présomption partielle : elle vaut uniquement pour les exigences réellement couvertes par EN 18286.
• Présomption conditionnelle : il faut appliquer la norme sérieusement, pas juste « s’en inspirer ».

Le caractère « dans la mesure où la norme couvre les exigences » est rappelé dans le texte cadre. Source : Conseil de l’UE, ST 7536/2024 (PDF).

EN 18286 = système qualité IA : ce que ça recouvre

EN 18286 s’aligne sur l’idée centrale de l’article 17 : un système qualité IA n’est pas un PDF. C’est un ensemble de :

• processus (comment tu travailles),
• rôles (qui décide, qui valide, qui alerte),
• preuves (ce que tu peux montrer),
• contrôles (ce qui t’empêche de faire n’importe quoi),
• le tout relié aux versions du système (traçabilité, gestion du changement).

L’AI Act attend explicitement des procédures de conformité et de gestion des modifications. Source : Article 17, AI Act Service Desk.

Avant de courir : es-tu « deployer »… ou aussi « provider » sans le savoir ?

Tu dis : « je déploie un système IA à risque ». Dans l’AI Act, les obligations changent selon ton rôle.

• Deployer : tu utilises un système à haut risque fourni par un éditeur, dans ton activité.
• Provider : tu mets sur le marché ou tu mets en service un système à haut risque sous ton nom, ou tu le reconditionnes (marque blanche), ou tu le modifies substantiellement.

Pourquoi c’est critique : EN 18286 est centrée sur le provider, car elle vise le système qualité (article 17) typiquement attendu côté « mise sur le marché / mise en service ».

Donc, pour une PME lyonnaise, la première preuve à produire n’est pas technique. C’est une preuve de rôle : qui est responsable de quoi, contractuellement et opérationnellement. Source de cadrage juridique : ST 7536/2024 (PDF).

Ce que EN 18286 te donne vraiment : un squelette auditable

Une PME n’a pas envie de « faire du compliance théâtre ». L’intérêt d’une norme harmonisée AI Act, c’est pragmatique :

• réduire l’ambiguïté : tu sais quoi écrire et quoi garder comme preuve,
• industrialiser : la conformité devient un process réutilisable (pas un one shot),
• parler audit : une logique de contrôle compréhensible par un tiers.

Et surtout : si tu es (ou deviens) provider, tu te rapproches d’un chemin « standard » pour soutenir une évaluation de conformité, au lieu d’un dossier artisanal.

Plan d’alignement en 30 jours (PME à Lyon) : gouvernance, docs, responsabilités, preuves

Objectif : en 30 jours, tu n’as pas « tout réglé ». Mais tu as un système qualité IA minimal qui tient debout, et des preuves qui résistent à une revue sérieuse. Tu peux ensuite élargir.

Jours 1 à 5 : cadrage, rôle, périmètre (les fondations)

• Décide et documente ton rôle : deployer uniquement, ou aussi provider. Écris le raisonnement. Ajoute les extraits contractuels utiles (éditeur, intégrateur, infogérant).
• Fige le périmètre : nom du système, version, cas d’usage exact, population utilisatrice, sites concernés (Lyon, agences AURA), interfaces (ERP, CRM, SIRH), flux de données.
• Ouvre un registre « conformité AI Act » : une page qui relie le système à son cycle de vie (changements, incidents, actions correctives, validations).

Tu veux un support simple pour ton registre et ta logique de preuve ? Tu peux t’appuyer sur : AI Act : documenter vos usages d’IA en entreprise (registre prêt à copier).

Jours 6 à 12 : gouvernance et responsabilités (qui décide quoi, et quand)

• Nomme un responsable « système qualité IA / AI Act » (même à 20 %). Ce n’est pas un titre. C’est un point de décision.
• Écris une matrice RACI : métier, IT, data, RSSI, juridique, achats. Qui propose ? Qui valide ? Qui exécute ? Qui est consulté ?
• Mets en place un processus de gestion des changements : toute modification qui touche données, modèle, règles, prompts, seuils, interfaces, doit passer par une validation et laisser une trace.
• Crée un processus de dérogation : quand tu ne peux pas respecter un contrôle, tu documentes le pourquoi, la mesure compensatoire, et qui approuve.

Si ton vrai problème, c’est « on ne sait pas qui décide » dans une boîte de 30 à 200 personnes, tu as une base ici : Gouvernance de l'IA : qui décide quoi dans une entreprise de cinquante personnes.

Jours 13 à 20 : documentation opérationnelle (les livrables qui tiennent)

Tu vises une documentation courte, mais exploitable. Si ce n’est pas relu et utilisé, ça ne sert à rien.

• Dossier « intended purpose » : finalité prévue, contexte, utilisateurs, décisions impactées, et limites d’usage (ce que le système ne doit pas faire).
• Dossier données : sources, droits d’usage, description des champs, qualité, biais identifiés, mesures de réduction. Si tu entraînes ou affines : versionnage des datasets.
• Dossier tests et validation : plan de tests, critères d’acceptation, résultats, et suivi des régressions à chaque changement.
• Dossier supervision humaine : où l’humain intervient, comment il peut contredire, arrêter, escalader. Qui est formé, et comment.
• Dossier incidents : définition d’un incident (erreur grave, dérive, fuite, décision anormale), procédure de traitement, délais internes, preuves conservées.

Pour la partie « traçabilité des décisions » (souvent oubliée et pourtant simple), garde un format de log lisible : Tracer les décisions prises avec l'aide d'une IA.

Jours 21 à 30 : preuves, contrôle, et routine (le système qualité IA devient réel)

• Construis ton pack de preuves : registre AI Act, versions, validations, résultats de tests, fiches de changement, liste des accès, preuves de formation, preuves de revue fournisseur.
• Fais une revue interne type « audit à blanc » : une personne externe au projet (DSI, RSSI, qualité, ou même DG) pose 15 questions et cherche les pièces. Si tu ne retrouves pas une preuve en 2 minutes, c’est trop fragile.
• Installe une routine mensuelle : revue des changements, revue des incidents, revue des métriques (qualité, dérive, faux positifs, taux de contestation humaine), revue des accès.
• Verrouille la gestion de version : un changement = un identifiant = une date = une justification = des tests = un responsable.

Pour rester pragmatique sur le passage « POC vers run », tu peux croiser avec : Industrialiser l’IA en DSI à Lyon : checklist POC vers run.

Ce que EN 18286 ne couvre pas totalement (et comment tu gères quand même)

Le piège classique : croire que « norme harmonisée = tout est réglé ». Non. EN 18286 aide surtout sur le système qualité IA. Or un système à haut risque touche aussi :

1) Gestion des risques produit et usages réels

Ton QMS doit être relié à une logique de risques, mais la norme ne remplace pas ton analyse : risques pour les personnes, erreurs, dérives, contournements, mauvais usage interne.

• Action immédiate : fais une cartographie des risques par cas d’usage (pas « l’IA en général »).
• Preuve : un tableau simple risques, gravité, probabilité, contrôle, propriétaire, statut.

Si tu veux cadrer tes usages avant de te faire surprendre par l’AI Act, garde une méthode simple : AI Act à Lyon : ce qui s’applique déjà, et ton plan 30 jours.

2) Données et RGPD (base légale, minimisation, conservation)

EN 18286 ne va pas « faire le RGPD » à ta place. Si tu traites des données personnelles, tu dois gérer : base légale, information, durées de conservation, sous-traitants, transferts, sécurité, et parfois DPIA.

• Action immédiate : mets noir sur blanc quelles données partent vers quel fournisseur et pour quel usage.
• Preuve : registre de traitement + politique de conservation adaptée aux outils IA.

Deux briques utiles à garder sous la main :

• RGPD et IA en entreprise : ce que vous pouvez faire, ce que vous ne pouvez pas
• Écrire une politique de conservation des données pour ses outils IA

3) Cybersécurité (attaques, logs, accès, prompt injection)

EN 18286 structure le management, mais la cybersécurité doit être traitée comme un chantier à part entière, surtout si ton IA est connectée à des outils (agents, automatisations, actions sur SI).

• Action immédiate : « least privilege » sur les accès, et journalisation exploitable (qui a fait quoi, quand, via quel agent).
• Action immédiate : traite la prompt injection comme un risque normal, pas comme un bug exotique.
• Preuve : revue d’accès mensuelle, plan de logs, procédure incident sécurité liée IA.

Pour tes garde-fous agents et outils connectés :

• Agents IA en production : les cinq garde-fous à poser
• Injection de prompt : la faille que les entreprises sous-estiment
• Sécuriser un agent IA qui a accès à vos outils

4) Fournisseurs : ce que tu peux exiger, et ce que tu dois vérifier

Si tu es deployer, tu dépends d’un provider. Et même si tu es provider, tu dépends de briques (API, modèles, hébergement, outils MLOps). EN 18286 te pousse à structurer, mais tu dois récupérer les preuves chez tes fournisseurs.

• Action immédiate : liste tes fournisseurs « IA » (éditeur, cloud, API, intégrateur) et associe un niveau de criticité.
• Action immédiate : formalise un « minimum contractuel » : logs, incidents, changements, localisation, sous-traitants, suppression, audit, réversibilité.

Base de lecture utile : Contrat avec un fournisseur d'IA : les clauses à lire deux fois.

Checklist « système qualité IA » minimale à avoir au bout de 30 jours

Si tu veux une cible claire, voilà ce que tu dois pouvoir sortir en rendez-vous interne, client, audit, ou contrôle. Pas parfait, mais solide.

• Décision de rôle : deployer/provider, + justification.
• Périmètre figé : version, cas d’usage, flux, utilisateurs.
• RACI + responsable conformité QMS IA.
• Process changement + journal des changements.
• Intended purpose + limites d’usage + supervision humaine.
• Dossier données (sources, qualité, droits, biais, conservation).
• Plan de tests + résultats + tests de non-régression.
• Plan incidents (y compris sécurité) + preuves de simulation simple.
• Pack preuves : tout est retrouvable vite, versionné, daté, signé.

Ce que tu fais lundi matin (sans te raconter d’histoires)

Tu veux utiliser EN 18286 comme levier. Très bien. Voilà le move :

• 1) Tu identifies si tu es juste deployer ou si tu glisses vers provider.
• 2) Tu mets en place un système qualité IA minimal aligné article 17, piloté par une personne, avec une routine.
• 3) Tu construis un pack de preuves simple, et tu le testes en « audit à blanc ».
• 4) Tu traites à part, sans attendre, les trous non couverts totalement : données et RGPD, risques d’usage réel, cybersécurité, dépendance fournisseurs.

Si tu veux rester dans l’esprit Lyon IA, direct et opérationnel : vise « preuve avant slide ». À la fin des 30 jours, ton objectif n’est pas d’avoir lu l’AI Act. C’est d’être capable de montrer, pièces à l’appui, comment tu maîtrises ton système et ses changements.