AI Act : la première norme harmonisée est publiée, et le haut risque reporté

Deux nouvelles de l'AI Act sont tombées cet été et cet automne, et il faut les lire ensemble. D'abord, les obligations applicables aux systèmes d'IA à haut risque de l'annexe III ont été repoussées du 2 août 2026 au 2 décembre 2027. Ensuite, la première norme harmonisée du règlement a été publiée le 14 octobre 2026 : EN 18286, qui porte sur le système de management de la qualité.

Prises séparément, ces deux informations envoient des signaux opposés : seize mois de répit d'un côté, une exigence normative de l'autre. Prises ensemble, elles disent la même chose. Le calendrier a bougé, pas le niveau d'exigence, et vous savez désormais sur quel référentiel travailler pendant le délai. Voici ce que contient cette norme, ce que la présomption de conformité vous apporte réellement, et ce qu'il est utile de faire d'ici là.

Ce qui a été publié, et quand

La Commission a adopté la décision d'exécution (UE) 2026/2274 le 12 octobre 2026, publiée au Journal officiel de l'Union européenne le 14 octobre. Elle publie la référence de la norme EN 18286:2026, adoptée par le CEN et le CENELEC en juillet 2026, intitulée « Intelligence artificielle : système de management de la qualité pour le règlement européen sur l'IA ».

C'est la première norme harmonisée publiée au titre de l'AI Act. D'autres sont attendues : le mandat de normalisation confié aux organismes européens de normalisation couvre une dizaine de domaines clés du règlement, de la gestion des risques à la robustesse en passant par la qualité des données. Celle-ci est donc une première pierre, pas le dispositif complet.

Ce que couvre la norme, concrètement

EN 18286 vise à aider les fournisseurs de systèmes d'IA à haut risque à mettre en œuvre l'article 17 de l'AI Act, qui impose un système de management de la qualité documenté. Elle couvre le cycle de vie complet du système.

• La gouvernance : rôles, responsabilités, politique qualité, ressources.
• La conception et le développement : spécifications, choix techniques, traçabilité des décisions.
• La gestion des risques et des données : ce qui alimente le système, d'où ça vient, comment c'est contrôlé.
• La vérification et la validation : les tests, et la preuve que vous les avez faits.
• La maîtrise des modifications : ce qui se passe quand le modèle, les données ou le paramétrage changent.
• La surveillance après mise sur le marché et le signalement des incidents graves.

Un point rassurant pour les structures modestes : l'article 17, paragraphe 2, prévoit que la mise en œuvre reste proportionnée à la taille et aux caractéristiques de l'organisation. La norme n'impose donc pas à une PME le dispositif d'un grand groupe industriel, mais elle impose d'avoir pensé chaque sujet.

Si cette liste vous évoque un système de management de la qualité classique, c'est normal. La logique est celle de la qualité documentée appliquée à l'IA, et la norme peut s'intégrer aux dispositifs qualité existants plutôt que de vivre à côté.

La présomption de conformité, et sa limite

L'intérêt d'une norme harmonisée tient dans un mécanisme précis : le fournisseur qui l'applique est présumé conforme aux exigences qu'elle couvre. En cas de contrôle, la charge de la démonstration s'allège considérablement, puisqu'il suffit d'établir que la norme a été suivie.

Une nuance juridique mérite toutefois d'être signalée, et elle est rarement mentionnée. L'article 40, paragraphe 1, du règlement rattache la présomption aux exigences de la section 2 du chapitre III, alors que l'article 17, sur le système de management de la qualité, figure à la section 3. Des praticiens relèvent que le fondement de cette présomption au regard de l'article 17 reste à préciser. Autrement dit, l'effet protecteur est annoncé, son assise exacte sera clarifiée à l'usage.

Deux autres limites valent d'être posées. L'application de la norme reste volontaire : vous pouvez démontrer votre conformité autrement, simplement sans bénéficier de la présomption. Et la norme ne dispense pas des exigences de l'AI Act qu'elle ne couvre pas, ni des évaluations de conformité requises par ailleurs.

Le report de calendrier, et ce qu'il ne reporte pas

Le règlement (UE) 2026/1744, volet IA du paquet de simplification européen, a décalé l'entrée en application des obligations haut risque. Les systèmes autonomes listés à l'annexe III passent du 2 août 2026 au 2 décembre 2027. Les systèmes intégrés à des produits déjà réglementés, à l'annexe I, passent au 2 août 2028.

Attention au contresens, qui est répandu. Le report porte sur les exigences substantielles du chapitre III. Il ne touche pas les interdictions de l'article 5, qui restent applicables, ni l'obligation de littératie en IA, c'est-à-dire de formation des équipes qui conçoivent ou utilisent ces systèmes. Nous avions détaillé ce découpage dans notre article sur ce qui s'applique vraiment depuis le 2 août 2026.

Seize mois supplémentaires, c'est à la fois beaucoup et très peu. Beaucoup, si vous commencez maintenant. Très peu, si votre système est déjà en production et que la documentation n'existe pas : reconstituer après coup la traçabilité des données d'entraînement et des décisions de conception est l'exercice le plus coûteux de tout le dispositif.

Êtes-vous seulement concerné ?

C'est la question à trancher avant toute autre, et la réponse est non pour la majorité des projets que l'on nous soumet. Le régime haut risque vise des usages précis : biométrie, infrastructures critiques, éducation, emploi et gestion des travailleurs, accès aux services essentiels, répression, migration, justice et processus démocratiques. S'y ajoutent les systèmes d'IA intégrés comme composant de sécurité à des produits déjà soumis à une réglementation européenne.

Un assistant interne qui résume des documents, un outil de rédaction, un moteur de recherche sémantique sur votre base documentaire n'entrent pas dans ce régime. En revanche, un outil qui trie des candidatures, qui note des salariés, qui conditionne l'accès à un service essentiel ou qui pilote un équipement de sécurité y entre, même si la partie IA vous paraît modeste.

La qualification se fait sur l'usage, pas sur la sophistication technique. C'est précisément le travail que nous faisons en phase de cadrage IA : déterminer le régime applicable avant d'écrire la première ligne de code, parce qu'il détermine l'architecture, la documentation et le budget.

Fournisseur ou déployeur, la distinction qui change tout

Le règlement ne traite pas de la même façon celui qui met un système sur le marché et celui qui s'en sert. Le fournisseur développe le système ou le fait développer et le commercialise sous son nom ou sa marque. Le déployeur l'utilise sous sa propre autorité dans le cadre de son activité professionnelle.

La norme EN 18286 s'adresse aux fournisseurs : c'est à eux qu'incombe le système de management de la qualité de l'article 17. Un déployeur a des obligations réelles mais nettement plus légères, principalement utiliser le système conformément à sa notice, assurer une supervision humaine compétente, surveiller son fonctionnement et conserver les journaux.

Beaucoup d'entreprises se croient fournisseurs alors qu'elles sont déployeurs, et s'alarment pour rien. D'autres font l'inverse, et c'est plus ennuyeux, parce que trois situations font basculer un déployeur dans le rôle de fournisseur : apposer son nom ou sa marque sur un système à haut risque, le modifier substantiellement, ou changer sa finalité au point de le rendre à haut risque alors qu'il ne l'était pas.

Et si vous appelez simplement une API ?

C'est le cas le plus fréquent dans nos projets : l'intelligence vient d'un modèle tiers, appelé par une API, et le produit est celui que vous construisez autour. Cette configuration ne vous rend pas automatiquement fournisseur d'un système à haut risque, et elle ne vous en protège pas non plus.

Ce qui compte est l'usage que sert votre produit et le nom sous lequel il est commercialisé. Si vous publiez sous votre marque un outil de présélection de candidatures, peu importe que le raisonnement soit délégué à un modèle externe : c'est votre système, pour un usage listé à l'annexe III. À l'inverse, un assistant de rédaction interne appelant le même modèle reste hors du régime haut risque.

Deux conséquences pratiques. La première, contractuelle : vos fournisseurs de modèles doivent vous transmettre ce dont vous avez besoin pour documenter votre système, et la réversibilité compte, puisque changer de modèle ne doit pas vous obliger à refaire toute votre documentation. Nous abordions cette question d'indépendance dans notre article sur OpenRouter. La seconde, architecturale : journaliser les entrées, les sorties et la version de modèle utilisée coûte peu si c'est prévu dès le départ, et devient très cher à rattraper.

Ce qu'il est utile de faire pendant le délai

Si vous êtes concerné, quatre chantiers tiennent dans les seize mois sans mobiliser une équipe entière.

Commencez par qualifier vos systèmes un par un, et par écrire cette qualification. Un tableau de bord qui liste vos usages d'IA, leur régime et le responsable de chacun vaut mieux qu'une conviction partagée oralement. C'est aussi ce document que réclamera le premier auditeur venu.

Mettez ensuite en place la traçabilité au fil de l'eau, pas rétrospectivement. D'où viennent les données, qui a validé quel jeu, quelle version du modèle tourne en production, qui a décidé de quoi. Un dépôt Git, des tickets et un registre de décisions suffisent à démarrer ; ce qui coûte cher, c'est de reconstituer tout cela deux ans plus tard.

Traitez la surveillance après mise en service comme une fonctionnalité du produit, pas comme une tâche de conformité. Journalisation exploitable, détection des dérives, procédure de signalement des incidents graves. Les mêmes briques servent à la qualité du produit et à la conformité, c'est ce qui rend l'investissement rentable. Nous faisions le même constat sur la sécurité des agents IA.

Enfin, formez les équipes. L'obligation de littératie en IA n'a pas été reportée, et c'est la plus simple à satisfaire : qui utilise quoi, pour quoi faire, avec quelles limites connues.

Ce que ça change pour un budget

La conformité n'est pas une ligne qui s'ajoute à la fin d'un projet, c'est une contrainte d'architecture. Un système conçu dès le départ avec sa traçabilité, ses tests et sa journalisation coûte modérément plus cher. Le même système mis en conformité après coup se paie en reprise, parfois en refonte.

C'est la même logique que celle décrite dans notre article sur le coût d'un projet IA du POC à la production : le modèle pèse peu dans la facture, l'industrialisation pèse lourd, et la conformité fait partie de l'industrialisation. La publication d'EN 18286 a au moins ce mérite : elle donne une liste de sujets à chiffrer, au lieu d'un risque flou.

Ce que nous en retenons

La première norme harmonisée de l'AI Act existe depuis le 14 octobre 2026. Elle porte sur le système de management de la qualité de l'article 17, couvre tout le cycle de vie, et ouvre une présomption de conformité dont l'assise juridique exacte reste à préciser. Son application est volontaire, et elle ne couvre pas tout le règlement.

En parallèle, les obligations haut risque de l'annexe III ont été repoussées au 2 décembre 2027, celles de l'annexe I au 2 août 2028. Les interdictions et la littératie en IA, elles, s'appliquent déjà.

La bonne lecture n'est donc pas « on a le temps », c'est « on sait enfin quoi construire, et on a seize mois pour le faire proprement ». Nous accompagnons cette qualification et cette mise en place dans nos projets de transformation IA. Si vous ne savez pas si vos systèmes relèvent du haut risque, parlons-en.