Le fait majeur que tu dois connaître (octobre 2026)
Le 14 octobre 2026, la Commission européenne a publié au Journal officiel la référence à EN 18286:2026, via la décision d’exécution (UE) 2026/2274. C’est la première norme harmonisée citée pour l’AI Act.
Traduction business, sans bla-bla : si tu appliques une norme harmonisée citée au JO, tu bénéficies d’une présomption de conformité pour les exigences couvertes. Ici, ça cible le système de management de la qualité exigé par l’article 17 pour les systèmes d’IA à haut risque.
Le message implicite est clair : l’UE ne veut pas un “dossier conformité” fait une fois. Elle veut un système de management vivant : changements, tests, incidents, fournisseurs, preuves. Dans la durée.
EN 18286:2026 vs ISO/IEC 42001:2023 : qui sert à quoi
ISO/IEC 42001:2023 : le socle “gouvernance IA” pour toute entreprise
ISO 42001 décrit un AI Management System (AIMS) basé sur PDCA (Plan, Do, Check, Act). C’est fait pour être applicable à toutes tailles d’organisations et ça couvre autant ceux qui fournissent que ceux qui utilisent de l’IA.
Le point qui t’intéresse si tu détestes la paperasse : ISO 42001 pousse à intégrer l’IA dans tes processus existants et à documenter ce qui est spécifique à l’IA (opacité, dérives, apprentissage, dépendance modèle, etc.). Pas à réécrire ISO 9001 en version “IA”.
EN 18286:2026 : la traduction “audit” de l’article 17 pour le haut risque
EN 18286:2026 est un QMS conçu pour des finalités réglementaires AI Act. C’est orienté cycle de vie produit/système, mappé à l’article 17, et pensé pour se superposer à l’existant (ISO 42001, ISO 9001, QMS sectoriels). Pas pour tout remplacer.
Décision dirigeant : si tu es potentiellement provider (tu développes, tu mets sur le marché, tu “packaging” un système IA), tu as intérêt à penser “EN 18286” comme ton mode d’emploi pour rendre ton management auditable.
Question simple : est-ce que tu es concerné “haut risque” ou juste “bonne gouvernance” ?
Tu ne vas pas lancer un chantier lourd si tu fais juste un assistant interne qui résume des tickets support. Par contre tu dois te poser 3 questions très concrètes :
- Est-ce que l’IA influence une décision qui peut impacter les droits, l’accès à un service, l’emploi, la santé, la sécurité ? Là, le niveau d’exigence monte vite.
- Est-ce que tu fournis un système à des clients (même B2B) avec ton nom dessus ? Tu te rapproches du rôle “provider”.
- Est-ce que le système agit (déclenche une action) ou conseille ? Un agent qui clique et exécute, c’est plus risqué qu’un chatbot qui répond.
Si tu veux un plan “terrain” AI Act global (sans juridique inutile), tu peux t’appuyer sur ce protocole : https://jimmymanin.com/blog/ai-act-2-aout-2026-ton-plan-de-conformite-terrain-en-10-decisions-de-dirigeant.
Le piège classique : surdocumenter pour se “rassurer”
La surdoc arrive quand tu fais ça :
- tu écris 40 pages de procédures que personne ne suit
- tu copies-colles une politique IA générique
- tu fais des “revues” sans données (pas de logs, pas de tests, pas d’incidents tracés)
Résultat : zéro maîtrise. Et le jour où ça dérape, tu n’as ni preuve, ni réflexe, ni boucle d’amélioration.
La bonne cible pour une PME : peu de documents, mais des contrôles récurrents et des preuves faciles à sortir.
La matrice “effort vs risque” pour éviter l’usine à gaz
Avant d’écrire quoi que ce soit, tu classes ton système dans une matrice simple. Objectif : mettre l’effort au bon endroit.
1) Évalue le risque sur 4 axes (score 1 à 3)
- Impact business : erreur coûteuse, engagement contractuel, financier, juridique
- Impact personnes : RH, discrimination, santé, droits
- Exposition : interne, partenaires, clients, grand public
- Autonomie : informe, recommande, agit (exécute)
Total 4 à 12. C’est ton “thermomètre”.
2) Mappe effort minimum vs effort renforcé
- 4 à 6 (faible) : registre 1 page, tests de base, revue trimestrielle
- 7 à 9 (moyen) : versioning strict, tests non-régression, supervision humaine explicite, incidents formalisés
- 10 à 12 (élevé) : management proche QMS, contrôle fournisseurs, traçabilité forte, critères d’acceptation signés, revues mensuelles
Ce n’est pas “ISO ou rien”. C’est “contrôles proportionnés”.
La checklist dirigeant en 10 points : mini-système de management IA (chatbot/RAG/agent interne)
Le but : être “prêt” au sens EN 18286:2026 et cohérent avec ISO 42001, sans transformer ton entreprise en cabinet d’audit.
1) Décide le périmètre (et écris-le)
Tu définis : un système, une finalité, des utilisateurs, des données. Point.
- Chatbot support interne ?
- RAG sur base documentaire qualité ?
- Agent qui crée des commandes, envoie des emails, modifie un CRM ?
Si tu mélanges tout, tu ne contrôles rien.
2) Nomme un owner métier (accountability) + un référent risque
Décision d’orga. Tu veux deux rôles, même si c’est 10% du temps :
- AI Owner (métier) : porte l’usage, les KPI, valide le “bon pour prod”.
- Référent risque/conformité : challenge données, sécurité, privacy, incidents, fournisseurs.
Sans owner, tu vas avoir un outil “en liberté”.
3) Classe le risque (simple, mais écrit)
Tu poses ton score effort vs risque (vu plus haut) et tu actives le niveau de contrôle adapté. C’est une décision de dirigeant : quel risque tu acceptes contre quel gain.
4) Crée un registre IA “1 page par système”
Document minimal, mais non négociable. Une page, structurée :
- Finalité et périmètre
- Utilisateurs (qui a le droit)
- Données utilisées (sources RAG, connecteurs, exports)
- Modèles et fournisseurs (ChatGPT, Claude, Gemini, open source, etc.)
- Limites connues (hallucinations, zones interdites, incertitudes)
- Contrôles en place (tests, escalade, logs, filtrage)
Ce registre devient ta “table des matières” de conformité et de pilotage. Pas un PDF pour faire joli.
5) Verrouille la donnée (RAG et connecteurs) avant de verrouiller le prompt
90% des ennuis viennent de là : tu branches Drive, SharePoint, Gmail, Slack… et tu crois que “ça ira”. Non.
- liste des sources autorisées
- liste d’exclusion (RH sensible, juridique, secrets industriels, etc.)
- propriétaire de chaque source
- fréquence de mise à jour
- test de dérive contenu (document supprimé, version obsolète, doc contradictoire)
Pour cadrer le risque fuite quand tu connectes un agent : https://jimmymanin.com/blog/connecteurs-ia-drive-gmail-slack-eviter-la-fuite-de-donnees-quand-tu-branches-un-agent.
6) Versionne modèle, prompts et outils (et impose une règle de changement)
Si tu ne sais pas ce qui a changé, tu ne peux pas expliquer un incident.
- un dépôt ou un espace “source of truth” pour les prompts système
- une règle : pas de changement en prod sans test minimal
- un log des changements (date, auteur, raison, impact)
Oui, même pour “juste un prompt”. Parce que tes prompts peuvent devenir des preuves : https://jimmymanin.com/blog/vos-prompts-peuvent-devenir-des-preuves-ce-que-tout-dirigeant-doit-cadrer.
7) Mets en place des tests minimaux avant mise en prod (et des critères d’acceptation)
Tu veux deux jeux de tests. Petit, mais stable.
- Jeu métier : 20 à 50 cas réels (questions, demandes, situations client).
- Jeu risque : hallucinations, données sensibles, demandes interdites, prompt injection, consignes contradictoires.
Tu définis des critères : taux d’erreur acceptable, refus attendu, seuil d’escalade humaine.
Si tu veux un protocole rapide anti-hallucinations : https://jimmymanin.com/blog/hallucinations-ia-le-protocole-simple-en-5-tests-pour-eviter-l-erreur-qui-coute-cher.
8) Organise la supervision humaine (qui valide quoi, et quand l’IA doit s’abstenir)
Tu écris une règle simple :
- ce que l’IA peut faire seule
- ce qu’elle peut préparer mais qui doit être validé
- ce qu’elle n’a pas le droit de faire
Ça s’aligne très bien avec une logique “niveaux d’autonomie” : https://jimmymanin.com/blog/agents-ia-le-modele-3-niveaux-dautonomie-pour-automatiser-sans-provoquer-lincident.
9) Mets un vrai processus “incident IA” (simple, mais rapide)
Un incident IA, ce n’est pas que “ça plante”. C’est aussi : mauvaise réponse plausible, fuite, action agentique non voulue, dérive de comportement après changement modèle.
- un canal de remontée (Teams/Slack + email)
- une grille de gravité (faible, moyen, élevé)
- un délai de traitement
- un post-mortem court : cause, correction, prévention, décision de reprise
Pour une version express avant de laisser un agent cliquer : https://jimmymanin.com/blog/agents-ia-et-incidents-reels-le-plan-de-controle-en-30-minutes-avant-de-laisser-cliquer.
10) Cadence de revue (mensuelle ou trimestrielle) et décisions actées
Si tu veux “être prêt” au sens management system, il te faut une boucle. Pas un document figé.
- revue des incidents et quasi-incidents
- revue des changements (modèle, connecteurs, données, prompts)
- revue des métriques (qualité, temps gagné, taux d’escalade)
- revue fournisseurs (conditions, localisation, options privacy, réversibilité)
- décision : on continue, on corrige, on coupe, on limite
Trace la décision dans un compte rendu d’une page. C’est ça, la preuve.
Les documents minimaux à produire (PME) : 6 pièces, pas 26
Si tu veux une base “audit ready” sans surdocumenter, vise ces 6 livrables :
- Registre IA : 1 page par système
- Politique d’usage : ce qui est autorisé/interdit + règles données
- Procédure de changement : qui peut changer quoi, et comment on teste
- Jeux de tests : cas métier + cas risque + résultats (même en tableur)
- Procédure incident IA : canal, gravité, délais, post-mortem
- Compte rendu de revue : mensuel ou trimestriel
Le reste, tu le fais seulement si ton score risque l’impose ou si ton secteur te le demande.
Qui fait quoi : RACI minimal pour que ça tienne
Tu veux éviter le flou artistique. Voilà une répartition simple.
- Dirigeant : fixe le niveau de risque acceptable, arbitre les blocages, valide le périmètre.
- AI Owner (métier) : KPI, jeu de tests métier, validation “go/no-go”, animation des revues.
- IT / Sécurité : accès, logs, connecteurs, secrets/API keys, contrôle fournisseurs.
- Référent conformité / DPO (si tu en as un) : données perso, bases légales, minimisation, durées.
- Utilisateurs clés : remontée incidents, feedback qualité, respect des règles.
Tu n’as pas ces rôles en interne ? Tu les “portes” à temps partiel. Mais tu les nommes.
Contrôles récurrents : la routine qui te protège (et évite le contrôle panique)
Si tu ne dois retenir qu’un truc : la conformité AI Act côté management, c’est des routines.
- Hebdo (10 min) : check incidents, changements en attente, dérives grossières.
- Mensuel (30-60 min) : revue KPI, revue tests, revue accès/connecteurs, décisions actées.
- Trimestriel (60-90 min) : revue fournisseurs, revue risques, revue périmètre, exercice “et si le modèle change/saute ?”.
Pour le volet continuité (dépréciation modèle, arrêt API, panne) : https://jimmymanin.com/blog/depreciation-des-modeles-llm-plan-de-continuite-en-10-points-pour-eviter-la-panne.
Ce que tu gagnes vraiment avec cette approche (et les limites)
Gains :
- moins d’incidents coûteux (erreurs plausibles, fuites, actions non voulues)
- moins de “taxe de vérification” parce que tu testes mieux et tu cadres l’usage
- des preuves prêtes si un client, un auditeur, un assureur ou un régulateur te challenge
- une gouvernance IA PME réaliste, qui tient même si les modèles changent
Limites :
- un management system ne rend pas une IA “fiable”. Il rend ton organisation capable de détecter, corriger, décider.
- si tu es vraiment sur du “haut risque” AI Act, tu auras potentiellement des exigences au-delà du QMS (données, traçabilité, conformité, etc.). EN 18286 aide sur l’article 17, pas sur tout le reste.
Plan d’action 7 jours : être “prêt” sans y passer 3 mois
Jour 1 : liste tes systèmes IA (même ceux “bricolés”), score risque 4 axes.
Jour 2 : choisis 1 système prioritaire (celui qui a le plus d’exposition ou d’autonomie).
Jour 3 : crée la page registre IA + nomme AI Owner et référent risque.
Jour 4 : verrouille données (sources RAG, exclusions, droits, connecteurs).
Jour 5 : mets versioning prompts + règle de changement + log.
Jour 6 : écris 20 à 50 tests métier + 10 à 20 tests risque, et exécute-les.
Jour 7 : mets le canal incident + la première revue mensuelle (même si tu es seul).
Si tu veux cadrer le volet transparence (article 50) pour tes chatbots et contenus IA, tu peux t’appuyer sur cette checklist : https://jimmymanin.com/blog/ai-act-article-50-la-checklist-transparence-pour-chatbots-agents-et-contenus-ia.
Ce que tu dois décider maintenant
Tu n’as pas besoin de devenir expert d’EN 18286:2026 et d’ISO 42001. Tu dois prendre 5 décisions nettes :
- quel système IA est “prioritaire risque” chez toi
- qui en est responsable (owner métier)
- quel niveau de risque tu acceptes (et donc quel niveau de contrôle)
- quelles données tu autorises et lesquelles tu bloques
- quelle routine tu tiens (revues, tests, incidents)
Fais ça, et tu es déjà dans l’esprit “AI Act conformité entreprise” version 2026 : pas de surdoc, mais une gouvernance IA PME qui produit des preuves et tient dans le temps.
