Les normes que personne n'a terminées
Bertrand 7 avril 2026

Les normes que personne n'a terminées

19 min de lecture

Le Règlement européen sur l’IA exige des entreprises qu’elles se conforment à des normes harmonisées. Les normes harmonisées n’existent pas.

Ce n’est pas une simplification. C’est la situation. La Commission européenne a demandé au CEN-CENELEC de rédiger les normes. Le CEN-CENELEC a raté l’échéance. Puis il a raté l’échéance révisée. Les normes sont désormais attendues pour le quatrième trimestre 2026. La date de conformité pour les systèmes d’IA à haut risque est le 2 août 2026. Les normes sont censées arriver après l’examen.

Une PME ne peut pas construire un programme de conformité sur la base d’une norme qui n’a pas été écrite. Mais le règlement n’attend pas l’organisme de normalisation. L’article 9 exige toujours un système de gestion des risques. L’article 11 exige toujours une documentation technique. L’article 13 exige toujours la transparence. Ces articles sont précis. Ils disent ce qu’il faut construire. Les normes diraient comment le démontrer. Le « quoi » existe. Le « comment » manque.

C’est le fossé. Et il est plus large que la plupart des entreprises ne le réalisent.

La demande de normalisation

En mai 2023, la Commission européenne a adressé une demande de normalisation aux organisations européennes de normalisation CEN et CENELEC. La demande leur demandait de développer des normes harmonisées couvrant les exigences pour les fournisseurs de systèmes d’IA à haut risque — les spécifications techniques qui, une fois publiées au Journal officiel de l’Union européenne, donneraient aux entreprises une présomption de conformité aux exigences du Règlement sur l’IA.

Le mécanisme est une pratique réglementaire européenne établie. Le règlement définit les exigences. Les organismes de normalisation traduisent ces exigences en spécifications techniques. Les entreprises qui respectent les spécifications sont présumées conformes au règlement. C’est la même architecture qui sous-tend le Règlement Machines, le Règlement relatif aux dispositifs médicaux et des dizaines d’autres cadres de sécurité des produits de l’UE.

L’échéance initiale pour la livraison des normes était le 30 avril 2025. Le CEN-CENELEC ne l’a pas respectée. Le président du JTC 21 — le comité technique conjoint responsable des travaux — a indiqué début 2025 que les normes seraient probablement finalisées fin 2025. Le 23 juin 2025, la Commission a formellement révisé l’échéance au 31 août 2025. Le CEN-CENELEC n’a pas non plus respecté cette échéance.

La demande de normalisation a été modifiée en juin 2025 pour s’aligner sur le texte final du Règlement sur l’IA. Le programme de travail du JTC 21 couvre environ trente-cinq éléments de travail répartis en cinq groupes : aspects fondamentaux, aspects opérationnels, fiabilité, ingénierie et domaines d’application spécifiques. Trois cents experts de plus de vingt pays participent. L’ampleur est considérable. Le calendrier ne l’était pas.

Ce qui existe

En mars 2026, une norme est entrée en enquête publique. Une seule.

La prEN 18286 — Intelligence artificielle : Système de management de la qualité à des fins réglementaires du Règlement européen sur l’IA — est devenue la première norme harmonisée du Règlement sur l’IA à entrer en enquête publique le 30 octobre 2025. L’enquête a duré jusqu’au 27 décembre 2025. Les organismes nationaux de normalisation ont soumis leurs commentaires. Le CEN compile actuellement les réponses et résout les commentaires avant que la norme puisse être adoptée.

La prEN 18286 couvre l’article 17 du Règlement sur l’IA : l’exigence relative au système de management de la qualité. Elle traduit les obligations de l’article 17 en contrôles concrets de gouvernance, de documentation, de cycle de vie et de preuve. Elle indique à un fournisseur comment structurer le système de management de la qualité exigé par le règlement. Elle est spécifique, détaillée et opérationnellement utile.

Elle n’est pas encore non plus une Norme européenne. C’est un projet. Il est susceptible de modification. Il ne peut être cité comme norme harmonisée tant qu’il n’est pas finalisé et que sa référence n’est pas publiée au Journal officiel. La présomption de conformité — le bénéfice juridique qui rend les normes harmonisées précieuses — ne s’attache qu’à cette publication. À ce jour, la prEN 18286 fournit des orientations. Elle ne fournit pas de certitude juridique.

Sa norme compagnon, la prEN 18228, couvre la gestion des risques au titre de l’article 9. Elle est entrée en scrutin interne du comité mi-2025. Elle n’a pas atteint l’enquête publique. La norme de gestion des risques — sans doute la norme opérationnellement la plus critique pour toute entreprise déployant un système d’IA à haut risque — accuse des mois de retard sur la norme de management de la qualité, elle-même à des mois de la finalisation.

Au-delà de ces deux normes, les éléments de travail restants couvrent la gouvernance des données, les biais, la cybersécurité, la robustesse, la journalisation, la transparence, la vision par ordinateur et le traitement du langage naturel. La plupart sont au stade de brouillon de travail ou à des stades antérieurs. Le pipeline est plein. Le résultat ne l’est pas.

Pourquoi les normes sont en retard

Les organismes de normalisation ne sont pas rapides. C’est par conception, pas par défaillance. La légitimité des normes harmonisées repose sur un processus de consensus qui inclut l’industrie, le monde académique, la société civile, les régulateurs et les experts en normalisation de toute l’Europe. Précipiter ce processus produit des normes qui manquent d’adhésion, qui ratent des cas particuliers, qui échouent les entreprises qu’elles sont censées servir. Le processus de consensus est lent parce qu’il est rigoureux.

Mais le Règlement sur l’IA a créé un problème de calendrier structurel qu’aucune optimisation de processus ne peut résoudre. Le règlement a été publié au Journal officiel le 12 juillet 2024. Les dispositions relatives au haut risque prennent effet le 2 août 2026. La demande de normalisation a été émise en mai 2023 — avant la finalisation du règlement. Quand le texte final a été publié, la demande a dû être modifiée pour s’aligner sur la loi effective. Le travail commencé sur la base d’un règlement en projet a dû être révisé au regard du texte final. L’horloge a continué à tourner. Le périmètre s’est élargi.

Le résultat est un fossé entre le calendrier réglementaire et le calendrier de normalisation, inscrit dans l’architecture dès le départ. Le règlement avance sur un calendrier politique. Les normes avancent sur un calendrier de consensus technique. Les deux calendriers sont structurellement incompatibles.

Le CEN-CENELEC a reconnu le problème. En octobre 2025, les Bureaux techniques conjoints du CEN et du CENELEC ont adopté un paquet exceptionnel de mesures d’accélération. La plus significative : permettre la publication directe des normes après un vote d’enquête positif, en sautant le vote formel séparé qui suit normalement. C’est extraordinaire. Le vote formel est une étape fondamentale du processus de normalisation européen. Le contourner est la reconnaissance que le processus normal ne peut pas livrer dans le calendrier réglementaire.

Même avec cette accélération, l’objectif pour la première vague de normes est le quatrième trimestre 2026 — après la date de conformité du 2 août 2026. Les mesures d’accélération sont conçues pour que les normes soient publiées avant la fin 2026. Pas avant août.

Le fossé de la présomption de conformité

Comprendre pourquoi cela compte exige de comprendre ce que font les normes harmonisées dans l’architecture réglementaire européenne.

L’article 40 du Règlement sur l’IA établit la présomption de conformité : les systèmes d’IA à haut risque conformes aux normes harmonisées — ou à des parties de celles-ci — dont les références ont été publiées au Journal officiel sont présumés conformes aux exigences couvertes par ces normes. Ce n’est pas une conformité par défaut. C’est un raccourci juridique. Si une norme harmonisée couvre les exigences de gestion des risques de l’article 9 et que votre système est conforme à cette norme, vous êtes présumé avoir satisfait à l’article 9. Un régulateur contestant votre conformité doit renverser cette présomption.

Sans la norme harmonisée, pas de présomption. Vous devez toujours respecter l’article 9. Mais vous devez démontrer la conformité selon vos propres termes, avec votre propre méthodologie, sans l’appui d’une norme qu’un régulateur a pré-approuvée. La charge de la preuve est plus lourde. La certitude juridique est moindre.

C’est la conséquence pratique du fossé de normalisation. La loi s’applique. Les exigences sont claires. Mais l’outil qui rend la conformité démontrable — la norme harmonisée — n’est pas disponible. Les entreprises doivent se conformer sans la feuille de route que l’architecture réglementaire était conçue pour fournir.

L’analogie est architecturale. Le règlement dit : construisez une maison qui respecte ces exigences structurelles. La norme harmonisée est le code de construction qui précise comment respecter ces exigences — les matériaux, les méthodes, les mesures. Sans le code de construction, vous devez toujours construire une maison structurellement solide. Mais vous devez prouver qu’elle est structurellement solide sans référence au code selon lequel l’inspecteur a été formé pour évaluer. Vous construisez selon des exigences, pas selon des spécifications. Les exigences sont les mêmes. La preuve est plus difficile.

Le recours aux spécifications communes

Le Règlement sur l’IA a anticipé ce problème. L’article 41 habilite la Commission à adopter des spécifications communes — des actes d’exécution qui servent de voie de conformité alternative lorsque les normes harmonisées ne sont pas disponibles.

Les conditions sont explicites. La Commission peut adopter des spécifications communes lorsque : elle a demandé des normes harmonisées et la demande n’a pas été acceptée, les normes ne sont pas livrées dans le délai, ou aucune référence à des normes harmonisées n’a été publiée au Journal officiel et aucune référence n’est attendue dans un délai raisonnable.

Les trois conditions sont remplies. La demande a été acceptée mais l’échéance a été manquée — deux fois. Aucune référence n’a été publiée au Journal officiel. Aucune n’est attendue avant le 2 août 2026.

La Commission a l’autorité juridique pour adopter des spécifications communes aujourd’hui. Elle ne l’a pas fait. La raison est politique, pas juridique. Les spécifications communes sont des actes d’exécution rédigés par la Commission — elles contournent le processus de normalisation fondé sur le consensus. La communauté de la normalisation les perçoit comme une intrusion dans son domaine. Les groupes industriels préfèrent des normes développées par consensus à des spécifications imposées par la réglementation. La Commission a historiquement été réticente à utiliser le mécanisme des spécifications communes, préférant attendre les normes harmonisées.

Le résultat : la voie principale de conformité (normes harmonisées) n’est pas disponible. La voie alternative (spécifications communes) n’a pas été activée. Les entreprises restent avec le texte du règlement et ce qu’elles arrivent à construire à partir de lui.

L’Omnibus numérique et l’échéance mouvante

Le fossé de normalisation est un moteur principal de l’Omnibus numérique — la proposition législative que la Commission a publiée le 19 novembre 2025 pour modifier le calendrier d’application du Règlement sur l’IA.

La logique politique est directe. Le règlement exige la conformité. La conformité est facilitée par les normes harmonisées. Les normes harmonisées ne sont pas prêtes. Donc, reporter l’échéance de conformité jusqu’à ce que les normes soient prêtes. L’Omnibus numérique propose de remplacer l’échéance du 2 août 2026 pour les dispositions relatives au haut risque par un mécanisme lié à la disponibilité des normes harmonisées — en pratique, repoussant la date effective au 2 décembre 2027 pour les systèmes d’IA à haut risque autonomes (Annexe III) et au 2 août 2028 pour les systèmes d’IA intégrés dans des produits (Annexe I).

Le Conseil a adopté sa position le 13 mars 2026. Les commissions IMCO et LIBE du Parlement européen ont adopté leur rapport conjoint le 18 mars 2026 — 101 voix pour, 9 contre, 8 abstentions. Les deux institutions soutiennent le report. Le vote en plénière du Parlement était prévu le 26 mars. Des négociations en trilogue entre le Parlement, le Conseil et la Commission suivront.

L’élan politique est clair. Les deux colégislateurs soutiennent le report. Le trilogue négociera les détails, pas le principe.

Mais — et j’ai déjà fait ce point et je le referai — l’Omnibus numérique n’a pas été adopté. Il n’a pas été publié au Journal officiel. Il n’est pas entré en vigueur. Au 7 avril 2026, le 2 août 2026 est la loi. Planifier pour décembre 2027 est rationnel. Compter sur décembre 2027 est imprudent. La différence entre planifier et compter, c’est si vous avez commencé à vous préparer pour août.

Une entreprise qui n’a pas commencé le travail de conformité parce qu’elle s’attend à ce que l’échéance bouge fait un pari. Les probabilités favorisent le report. L’inconvénient d’avoir tort n’est pas abstrait — il est opérationnel. C’est la course pour construire un système de gestion des risques, une documentation technique, une infrastructure de journalisation et des mécanismes de supervision humaine dans les semaines entre un trilogue échoué et le 2 août. La probabilité est faible. L’impact est catastrophique.

Ce qu’une entreprise peut faire aujourd’hui

L’absence de normes harmonisées ne signifie pas l’absence d’exigences. Les dispositions de fond du Règlement sur l’IA sont autonomes. Elles disent ce qu’il faut construire. Les normes auraient fourni une méthodologie consensuelle pour le construire. Sans les normes, vous devez construire la méthodologie vous-même — mais la destination est la même.

Voici ce qui existe et ce que vous pouvez en faire.

Article 9 — Gestion des risques. Le règlement spécifie en détail les exigences pour un système de gestion des risques. Il doit s’agir d’un processus itératif continu. Il doit identifier et analyser les risques connus et raisonnablement prévisibles. Il doit évaluer les risques qui émergent lorsque le système est utilisé conformément à sa destination et dans des conditions d’utilisation abusive raisonnablement prévisible. Il doit adopter des mesures de gestion des risques appropriées. L’article est prescriptif. Vous n’avez pas besoin de la prEN 18228 pour construire un système de gestion des risques. Vous avez besoin de l’article 9, de la documentation technique de votre système et de quelqu’un compétent dans le domaine d’application de votre système d’IA. La norme, quand elle arrivera, fournira une méthodologie structurée. L’article fournit les exigences que cette méthodologie doit satisfaire.

Article 10 — Gouvernance des données. Les jeux de données d’entraînement, de validation et de test doivent respecter des critères de qualité : pertinents, suffisamment représentatifs, exempts d’erreurs dans la mesure du possible et complets au regard de la destination prévue. L’article précise les pratiques de gouvernance des données — y compris l’examen des biais, l’identification des lacunes et les mesures appropriées pour y remédier. Documentez vos données. Documentez leurs sources. Documentez vos contrôles de qualité. Documentez comment vous avez traité les biais. La norme fournira un cadre pour faire cela. L’article vous dit ce que le cadre doit couvrir.

Article 11 — Documentation technique. L’Annexe IV liste le contenu de la documentation technique en détail. Description générale, processus de développement, surveillance et contrôle, système de gestion des risques, modifications au cours du cycle de vie, normes harmonisées appliquées et mesures de conformité. Le dernier point — normes harmonisées appliquées — sera vide pour l’instant. L’Annexe IV prévoit explicitement cette situation : lorsqu’aucune norme harmonisée n’a été appliquée, la documentation doit inclure « une liste des autres normes et spécifications techniques pertinentes appliquées ». ISO/IEC 42001, ISO/IEC 23894, ISO/IEC 38507 — ce ne sont pas des normes harmonisées au titre du Règlement sur l’IA, mais ce sont des spécifications techniques pertinentes qui démontrent une méthodologie de conformité. Utilisez-les. Documentez leur application. La documentation technique n’exige pas des normes harmonisées. Elle exige la documentation de toutes les normes que vous avez effectivement appliquées.

Article 12 — Journalisation. Le système doit automatiquement enregistrer les événements. L’article précise lesquels : période d’utilisation, bases de données de référence, données d’entrée ayant produit des correspondances, identification des personnes impliquées dans la vérification. C’est une exigence d’ingénierie. Elle ne dépend pas d’une norme harmonisée. Construisez l’infrastructure de journalisation. La norme ne changera pas ce que vous enregistrez. Elle peut changer comment vous le structurez et le stockez. Construisez maintenant, affinez ensuite.

Article 13 — Transparence. Le système doit être conçu pour être suffisamment transparent pour permettre aux déployeurs d’interpréter le résultat et de l’utiliser de manière appropriée. Les instructions d’utilisation doivent inclure : l’identité du fournisseur, les caractéristiques du système, ses capacités et limites, la destination prévue, le niveau de précision et les métriques de précision pertinentes. Rédigez les instructions d’utilisation. Le contenu est spécifié dans l’article. Une norme harmonisée pourrait spécifier le format. Le contenu est déjà défini.

Article 14 — Supervision humaine. J’ai écrit à ce sujet en détail dans « L’erreur à 500 000 euros ». L’exigence est claire : les personnes physiques doivent être en mesure de comprendre pleinement les capacités et limites du système, de surveiller son fonctionnement, de pouvoir décider de ne pas utiliser le système ou d’ignorer son résultat, et de pouvoir intervenir ou interrompre le système. Construisez l’interface de supervision. Formez les superviseurs. La norme ne changera pas l’exigence. Elle fournira une méthodologie pour la démontrer.

prEN 18286 — Système de management de la qualité. Le projet de norme est publiquement disponible via les organismes nationaux de normalisation. Il n’est pas finalisé. Il peut changer. Mais c’est l’orientation la plus détaillée disponible pour la conformité à l’article 17. Lisez-le. Utilisez-le comme référence pour structurer votre système de management de la qualité. Quand la norme finale sera publiée, alignez-vous dessus. Le coût d’aligner un système construit sur le projet à la norme finale est un ajustement. Le coût de ne rien construire en attendant la norme finale est de repartir de zéro.

Le pont ISO

L’absence de normes harmonisées spécifiques au Règlement sur l’IA ne signifie pas l’absence de normes. Le paysage de normalisation internationale offre des cadres pertinents qui, s’ils ne confèrent pas la présomption de conformité au titre de l’article 40, fournissent des méthodologies structurées pour répondre aux exigences du Règlement sur l’IA.

L’ISO/IEC 42001 — Système de management de l’intelligence artificielle — fournit une norme de système de management pour les organisations utilisant ou fournissant de l’IA. Elle couvre l’évaluation des risques, la gouvernance et la gestion du cycle de vie. Elle ne correspond pas directement aux exigences du Règlement sur l’IA, mais elle aborde les mêmes préoccupations structurelles. Une entreprise dotée d’un système de management certifié ISO 42001 dispose d’un cadre qui se traduit en conformité au Règlement sur l’IA par adaptation, pas par réinvention.

L’ISO/IEC 23894 — Intelligence artificielle : Lignes directrices sur le management du risque — fournit un cadre de gestion des risques spécifique aux systèmes d’IA. Elle s’aligne conceptuellement sur l’article 9 mais a été développée indépendamment du Règlement sur l’IA. Une entreprise qui met en œuvre l’ISO 23894 dispose d’un système de gestion des risques qui couvre l’essentiel de ce que l’article 9 exige — avec des lacunes qui peuvent être comblées en lisant l’article 9 lui-même.

Ces normes ne sont pas des substituts des normes harmonisées. Elles ne confèrent pas la présomption de conformité. Mais elles fournissent quelque chose que les normes harmonisées manquantes ne peuvent pas fournir : de la structure. Un système de gestion des risques construit sur l’ISO 23894 et adapté à l’article 9 est démontrablement plus robuste qu’un système de gestion des risques construit à partir de rien sans aucun cadre méthodologique. Quand un régulateur évalue la conformité en l’absence de normes harmonisées, l’entreprise qui a appliqué une norme internationale reconnue — et documenté son application — est dans une position plus forte que l’entreprise qui n’a rien appliqué.

La réalité de l’application

La question pratique est ce qui se passe quand l’application commence sans normes harmonisées. La réponse dépend de l’autorité d’application.

Les autorités nationales compétentes opérationnelles depuis des mois — Traficom en Finlande, AESIA en Espagne, Bundesnetzagentur en Allemagne — ont eu le temps de développer des méthodologies d’application. Ces autorités comprennent le fossé de normalisation. Elles savent qu’aucune entreprise ne peut démontrer sa conformité à une norme qui n’existe pas. Leur approche d’application tiendra nécessairement compte de l’absence de normes harmonisées — en évaluant la conformité au regard des exigences du règlement plutôt que de spécifications techniques.

Ce n’est pas une licence pour la complaisance. L’absence de normes harmonisées ne réduit pas les exigences. Elle change le cadre probatoire. Une entreprise doit toujours se conformer aux articles 9 à 15. Elle doit toujours disposer d’un système de gestion des risques, d’une documentation technique, d’une journalisation, d’une transparence et d’une supervision humaine. Ce qu’elle ne peut pas avoir, c’est une norme harmonisée à laquelle se référer comme preuve. La preuve doit venir de la substance de ce que l’entreprise a construit, documenté et mis en œuvre.

Les entreprises qui s’en sortiront le mieux dans un environnement d’application sans normes harmonisées sont celles qui ont fait le travail. Pas celles qui ont attendu la norme. Pas celles qui ont engagé un cabinet de conseil pour produire une analyse des écarts. Celles qui ont lu l’article 9, construit un système de gestion des risques, l’ont documenté et l’ont maintenu. Celles qui ont lu l’article 11 et l’Annexe IV, produit la documentation technique et l’ont maintenue à jour. Celles qui ont traité le texte du règlement comme la spécification — parce qu’en l’absence de normes harmonisées, c’en est une.

La position

Le fossé de normalisation est réel, structurel, et ne se comblera pas avant le 2 août 2026. L’Omnibus numérique peut repousser la date de conformité à décembre 2027. Les normes harmonisées peuvent arriver au quatrième trimestre 2026. Les deux peuvent se produire. Aucun des deux ne s’est produit.

Le fossé ne justifie pas l’inaction. Il justifie un type d’action différent. Construisez sur la base du texte du règlement, pas sur la base d’une norme qui n’existe pas. Utilisez les projets de normes comme orientation, pas comme voie de conformité. Appliquez les normes internationales là où elles couvrent les mêmes préoccupations. Documentez tout — la méthodologie, les normes appliquées, les lacunes identifiées, les décisions prises.

Les entreprises qui navigueront avec succès dans le fossé de normalisation seront celles qui ont traité l’absence de normes comme une contrainte de construction, pas comme une excuse de construction. Léonard de Vinci travaillait sans logiciel de CAO. Les contraintes n’ont pas arrêté le travail. Elles l’ont façonné.

Les normes arriveront. Elles arrivent toujours. La question est si vous avez construit quelque chose qui vaut la peine d’être aligné avec elles — ou si vous êtes resté à la table à dessin à attendre des plans qui ne sont jamais venus.

Les plans sont en retard. La construction n’est pas optionnelle.

Écrit par
Bertrand
Technologue Créatif

Entrepreneur en série titulaire d'un doctorat en IA, avec vingt-cinq ans à construire des systèmes à travers l'Europe. Il crée du code comme il surfe : en lisant les patterns, en trouvant le flux, en rendant le difficile facile.

← Toutes les notes