Transport et infrastructures critiques — Conformité au règlement IA de l'UE

Obligations du règlement IA de l'UE pour les systèmes d'IA dans les véhicules autonomes, la gestion du trafic, l'aviation, le ferroviaire et les infrastructures critiques. Couvre l'Annex I (NLF) et la catégorie 2 de l'Annex III.

Pourquoi le transport est un secteur prioritaire au titre du règlement IA de l'UE

Le règlement IA de l'UE (règlement (UE) 2024/1689) assigne ses obligations les plus exigeantes aux domaines où les défaillances de l'IA ont des conséquences directes sur la sécurité physique, la continuité des services critiques et la sécurité publique. Le transport et les infrastructures critiques occupent une position centrale dans cette architecture pour deux raisons juridiques indépendantes : le déploiement omniprésent de l'IA en tant que composants de sécurité dans des produits de transport réglementés (déclenchant l'Art. 6(1) via l'Annex I), et l'inscription explicite des systèmes d'IA de gestion des infrastructures critiques comme systèmes à haut risque à l'Annex III, point 2.

Le secteur du transport se distingue également par la densité et la maturité de ses cadres réglementaires existants. La réception par type des véhicules au titre du règlement sur la sécurité générale (UE) 2019/2144, la certification aéronautique au titre du règlement de base EASA (UE) 2018/1139, l'interopérabilité ferroviaire et la sécurité au titre du règlement ERA (UE) 2016/796 et de la directive sécurité 2016/798, ainsi que la cybersécurité des infrastructures critiques au titre de la directive NIS2 (UE) 2022/2555 créent des obligations légales préexistantes qui se cumulent avec — et dans certains cas interagissent structurellement avec — le règlement IA de l'UE.

Pour les organisations du secteur du transport, la conséquence pratique est que la conformité à la réglementation sur l'IA ne peut pas être gérée comme un chantier réglementaire isolé. Elle doit être intégrée dans les programmes existants de réception par type, de certification, de gestion de la sécurité et de cybersécurité. Ne pas réaliser cette intégration expose non seulement à un risque de non-conformité au règlement IA, mais également à une non-conformité vis-à-vis des réglementations sectorielles qui disposent de leurs propres autorités de contrôle et d'accès au marché.

Composants de sécurité IA (Annex I) et IA de gestion des infrastructures critiques (Annex III, point 2)

Le règlement IA de l'UE crée deux voies distinctes de classification à haut risque pertinentes pour le transport. Déterminer quelle voie s'applique — et si les deux s'appliquent simultanément — est la première étape analytique de tout programme de conformité IA dans le secteur du transport.

Annex I — Composants de sécurité de produits réglementés par le NCL

L'Art. 6(1) du règlement IA de l'UE classe comme à haut risque tout système d'IA qui est un composant de sécurité d'un produit réglementé par la législation du Nouveau cadre législatif (NCL) listée à l'Annex I. Pour le transport, les principaux instruments NCL sont :

• Règlement sur la sécurité générale (UE) 2019/2144 — véhicules routiers (voitures, camions, motocycles, autocars)
• Règlement de base EASA (UE) 2018/1139 — aéronefs, moteurs et équipements associés
• Législation ferroviaire de l'ERA — comprenant le règlement (UE) 2016/796 (Agence ERA), la directive 2016/797 (interopérabilité) et la directive 2016/798 (sécurité ferroviaire)
• Règlement Machines (UE) 2023/1230 — applicable aux systèmes d'IA dans les équipements portuaires automatisés, les véhicules industriels et les engins de construction opérant dans des contextes d'infrastructures de transport

Un système d'IA est un composant de sécurité d'un produit de transport si sa défaillance ou son dysfonctionnement pourrait mettre en danger la santé ou la sécurité des personnes. Pour les véhicules routiers, cela englobe les systèmes de freinage d'urgence autonome, les systèmes d'IA de maintien de voie, le régulateur de vitesse adaptatif de niveau SAE L2 et supérieur, ainsi que tous les systèmes de conduite automatisée L3–L5. Pour l'aviation, cela englobe les systèmes d'IA dans les systèmes de gestion de vol, les composants de pilotage automatique et les systèmes d'avertissement de proximité du sol. Pour le ferroviaire, cela englobe les systèmes d'IA dans la protection automatique des trains, la signalisation assistée par IA et la manœuvre autonome.

La classification au titre de l'Art. 6(1) est catégorielle. Elle ne nécessite pas que le système d'IA démontre indépendamment une probabilité significative de préjudice — la désignation de composant de sécurité est suffisante. Cela signifie que les fournisseurs de tels systèmes doivent se conformer aux exigences du Chapitre III, Section 2 (Art. 9–15) couvrant la gestion des risques, la gouvernance des données, la documentation technique, la journalisation automatique, la transparence, la surveillance humaine, et la précision et la robustesse.

Annex III, point 2 — Gestion des infrastructures critiques

Indépendamment de la voie relative aux composants de sécurité, l'Annex III, point 2 liste expressément comme à haut risque les systèmes d'IA destinés à être utilisés comme composants de sécurité dans la gestion et l'exploitation d'infrastructures critiques, notamment :

• Les infrastructures critiques de trafic routier
• Les infrastructures critiques de transport par voie d'eau
• Les composants critiques du réseau électrique (en tant qu'infrastructures critiques présentant des profils de risque équivalents à ceux du transport)

Les systèmes d'IA entrant dans cette catégorie comprennent : les plateformes de gestion du trafic autoroutier utilisant l'IA pour le contrôle dynamique de la vitesse et la détection des incidents, les systèmes basés sur l'IA pour la stabilité du réseau électrique intelligent et l'équilibrage des charges lorsqu'une défaillance du réseau affecterait les opérations de transport, et les systèmes d'IA gérant les infrastructures portuaires au niveau de l'exploitation de service essentiel.

La distinction entre le point 2 et la voie Annex I est que l'Annex III, point 2 s'applique aux opérateurs d'infrastructures et non seulement aux fabricants de produits. Une autorité publique ou un concessionnaire privé exploitant un centre de gestion du trafic piloté par l'IA est soumis aux obligations du point 2 en tant que déployeur ou, s'il a lui-même développé le système d'IA, en tant que fournisseur.

Double classification

Lorsqu'un système d'IA est à la fois un composant de sécurité d'un produit réglementé par le NCL et est déployé dans la gestion d'infrastructures critiques (par exemple, un système d'IA intégré dans une plateforme d'autoroute intelligente qui interface également avec des systèmes de véhicules), les deux voies s'appliquent. Les obligations les plus exigeantes prévalent.

Fournisseur et déployeur dans le contexte du transport — OEM et opérateur

La répartition des obligations entre fournisseurs (Art. 16) et déployeurs (Art. 26) est particulièrement complexe dans le transport, où la chaîne d'approvisionnement entre le développeur d'IA, l'intégrateur système, l'OEM, l'opérateur d'infrastructure et la flotte d'utilisateurs finaux peut impliquer plusieurs entités juridiques supportant chacune des responsabilités distinctes au titre du règlement IA.

Les OEM de véhicules en tant que fournisseurs

Un OEM qui intègre un système d'IA de conduite — développé en interne ou provenant d'un fournisseur de rang 1 ou de rang 2 — et met le véhicule sur le marché de l'UE sous sa propre marque est le fournisseur du système d'IA au sens de l'Art. 16. C'est le cas même si la technologie d'IA a été initialement développée par un tiers, à condition que l'OEM n'ait pas simplement revendu un système inchangé sous la marque du tiers. Les obligations du fournisseur comprennent :

• La mise en place d'un système de gestion de la qualité au titre de l'Art. 17
• L'élaboration et la tenue à jour de la documentation technique au titre de l'Art. 11 et de l'Annex IV, couvrant la finalité prévue, la conception, les données d'entraînement, les résultats de validation et le plan de surveillance post-commercialisation du système d'IA
• La réalisation ou la commandite d'une évaluation de conformité — qui, pour les composants de sécurité de véhicules, doit être coordonnée avec la procédure de réception par type au titre du règlement GSR 2019/2144
• L'enregistrement du système d'IA dans la base de données de l'UE pour les systèmes d'IA à haut risque au titre de l'Art. 49 avant la mise sur le marché
• La fourniture aux instructions d'utilisation aux déployeurs en aval (opérateurs de flottes, sociétés de location) suffisantes pour permettre un déploiement conforme

Les opérateurs de flottes et les concessionnaires en tant que déployeurs

Une société exploitant une flotte de véhicules autonomes, une collectivité locale déployant un système d'IA de gestion du trafic, ou un gestionnaire d'infrastructure ferroviaire utilisant des outils de maintenance assistée par IA est un déployeur au sens de l'Art. 26. Les obligations du déployeur comprennent :

• L'utilisation du système d'IA dans le cadre des instructions d'utilisation du fournisseur — toute utilisation opérationnelle en dehors de ce cadre peut reclasser le déployeur en fournisseur, déclenchant l'ensemble des obligations du fournisseur
• La mise en œuvre de mesures de surveillance humaine telles que précisées par le fournisseur et adaptées au contexte opérationnel
• La conservation des journaux opérationnels générés par le système d'IA pendant au moins six mois, ou plus longtemps lorsque la législation sectorielle applicable (NIS2, législation nationale sur la sécurité des transports) impose une durée de conservation prolongée
• La notification au fournisseur dans les meilleurs délais des dysfonctionnements ou incidents graves, et aux autorités nationales compétentes au titre de l'Art. 73 lorsque la sécurité ou les droits fondamentaux sont en jeu
• La réalisation d'évaluations d'impact sur les droits fondamentaux (EADF) au titre de l'Art. 27 lorsque le système d'IA est déployé par une autorité publique ou dans des contextes affectant des personnes à grande échelle

Interaction avec les réglementations sectorielles — EASA, ERA et réception par type

Véhicules routiers — GSR 2019/2144 et réception par type

Le règlement sur la sécurité générale (UE) 2019/2144 impose l'inclusion de fonctionnalités spécifiques d'ADAS et de conduite autonome dans les nouveaux types de véhicules et établit les exigences techniques relatives à leurs performances. La réception par type des véhicules — conduite par les autorités nationales de réception (par exemple, le KBA en Allemagne, la DREAL en France, le Rijksdienst voor het Wegverkeer aux Pays-Bas) — est le principal mécanisme d'accès au marché pour les véhicules routiers.

Le règlement IA de l'UE ne se substitue pas à la réception par type. L'Art. 8(1) du règlement IA précise que lorsque la législation sectorielle impose des exigences d'une rigueur équivalente ou supérieure, un alignement procédural est possible, mais les obligations du règlement IA demeurent. En pratique, l'évaluation de conformité d'un système d'IA de conduite doit couvrir à la fois les exigences techniques du règlement GSR (évaluées dans le cadre de la réception par type) et les exigences du règlement IA (documentation technique, gouvernance des données, journalisation, surveillance humaine, surveillance post-commercialisation). Les OEM doivent planifier une évaluation intégrée couvrant les deux cadres afin d'éviter les efforts redondants et les lacunes potentielles.

Aviation — EASA et la feuille de route IA

L'EASA exerce une autorité de certification sur les aéronefs, les moteurs et les pièces au titre du règlement (UE) 2018/1139. La feuille de route IA de l'EASA (publiée en éditions successives depuis 2020) aborde la fiabilité de l'IA pour les systèmes d'IA embarqués et constitue la référence de certification principale pour les applications d'IA critiques pour le vol.

Le règlement IA de l'UE s'applique aux systèmes d'IA aéronautiques au sol (gestion du trafic, diagnostic de maintenance, systèmes de gestion de cabine) qui se situent en dehors du périmètre de navigabilité de l'EASA. Pour les systèmes d'IA embarqués certifiés par l'EASA, un alignement au titre de l'Art. 8(1) est envisageable, mais le chevauchement entre les exigences de navigabilité EASA et les obligations du règlement IA (notamment en matière de journalisation et de surveillance humaine) doit être analysé système par système. Le concept d'« niveau d'assurance IA » de l'EASA ne correspond pas directement à la classification à haut risque du règlement IA de l'UE ou aux exigences d'évaluation de conformité.

Ferroviaire — ERA et systèmes de gestion de la sécurité

L'ERA (Agence de l'Union européenne pour les chemins de fer) supervise l'interopérabilité ferroviaire et le cadre de sécurité commun au titre des directives 2016/797 et 2016/798. Les entreprises ferroviaires et les gestionnaires d'infrastructure sont tenus de maintenir un système de gestion de la sécurité (SGS) couvrant l'évaluation des risques, l'enquête sur les accidents et l'amélioration continue.

Les exigences de gestion des risques du règlement IA au titre de l'Art. 9 correspondent étroitement aux exigences du SGS de l'ERA. Les organisations disposant d'un SGS mature sont bien positionnées pour intégrer la documentation de gestion des risques du règlement IA dans le cadre existant. L'ERA et la Commission européenne ont indiqué leur préférence pour des approches de conformité intégrées évitant la duplication entre le SGS et les obligations du règlement IA. Les systèmes d'IA utilisés dans l'exploitation automatisée des trains, les composants IA de l'ETCS (système européen de contrôle des trains) ou la maintenance prédictive alimentant des décisions critiques pour la sécurité sont à haut risque au titre de l'Annex I (composant de sécurité de véhicules ou d'infrastructures ferroviaires).

Autorités de contrôle et de certification

La conformité des systèmes d'IA dans le transport implique plusieurs organismes de contrôle aux compétences partiellement chevauchantes, selon la fonction du système d'IA et le produit dans lequel il est intégré.

L'EASA est l'autorité de certification pour les systèmes d'IA dans les aéronefs et les produits aéronautiques. Elle peut mener des enquêtes sur les défaillances de systèmes d'IA qui mettent en cause la navigabilité, et ses décisions affectent l'accès au marché dans l'ensemble de l'UE et dans les juridictions partenaires liées par des accords bilatéraux.

L'ERA supervise le cadre de sécurité commun pour le ferroviaire. Les certificats de sécurité ferroviaire et les autorisations d'exploitation sont conditionnés à la conformité du SGS, qui croise de plus en plus les obligations du règlement IA pour les systèmes ferroviaires à IA.

Les autorités nationales de réception par type des véhicules — notamment le KBA (Allemagne), les organismes délégués par l'ANFIA (Italie) et le Rijksdienst voor het Wegverkeer (Pays-Bas) — délivrent et peuvent retirer les réceptions par type pour les véhicules routiers. La non-conformité aux exigences du règlement IA pour les composants de sécurité IA peut constituer un motif de suspension de la réception par type ou de rappel.

Les autorités nationales compétentes NIS2 — désignées par chaque État membre, souvent une agence nationale de cybersécurité telle que le BSI (Allemagne), l'ANSSI (France) ou le NCSC-NL (Pays-Bas) — font appliquer les obligations NIS2 aux opérateurs de transport fournissant des services essentiels. L'application de NIS2 peut entraîner des injonctions contraignantes, des amendes et, dans les cas graves, la suspension des opérations.

Les autorités nationales de surveillance de l'IA désignées au titre de l'Art. 70 du règlement IA de l'UE disposeront de pouvoirs généraux de surveillance du marché, avec des mécanismes de coordination avec les autorités sectorielles spécifiques pour éviter les conflits de compétence.

Priorités de conformité pour les opérateurs et fournisseurs du secteur du transport

Étape 1 : Inventaire et classification des systèmes d'IA

Réaliser un inventaire structuré de tous les systèmes d'IA en développement ou en déploiement dans le portefeuille de produits de transport ou d'exploitation. Pour chaque système, déterminer s'il est un composant de sécurité d'un produit réglementé par le NCL (voie Art. 6(1)), un système d'IA de gestion d'infrastructure critique (Annex III, point 2), ou les deux. Documenter par écrit le raisonnement sous-tendant la classification. Les systèmes qui ne peuvent pas être définitivement exclus de la classification à haut risque doivent être traités comme tels dans l'attente d'une analyse juridique définitive.

Étape 2 : Planification de la voie d'évaluation de conformité

Pour les systèmes d'IA qui sont des composants de sécurité de véhicules, d'aéronefs ou de produits ferroviaires, identifier la procédure de certification sectorielle applicable et la mettre en correspondance avec les exigences d'évaluation de conformité au titre du règlement IA. Déterminer si un organisme notifié est requis (Art. 43(3)) ou si une auto-évaluation assortie d'un audit technique par un tiers est suffisante. Coordonner le calendrier d'évaluation de conformité au titre du règlement IA avec le programme de réception par type ou de certification afin d'éviter des retards d'accès au marché.

Étape 3 : Documentation technique et gouvernance des données

Préparer la documentation technique au titre de l'Annex IV pour chaque système d'IA à haut risque. Pour les systèmes d'IA de transport, celle-ci doit inclure : la finalité prévue avec une précision suffisante pour étayer à la fois la classification au titre du règlement IA et de la réglementation sectorielle ; la provenance des données d'entraînement, y compris toute donnée de conduite réelle, opérationnelle ou de capteur utilisée ; la description des environnements de simulation pour les systèmes d'IA validés par des tests virtuels ; et les plans de surveillance post-commercialisation alignés sur les obligations de reporting sectorielles.

Étape 4 : Intégration de NIS2 pour les opérateurs d'infrastructures critiques

Les opérateurs de transport fournissant des services essentiels doivent intégrer les exigences de cybersécurité du règlement IA au titre de l'Art. 15 avec les obligations de gestion des risques de cybersécurité de NIS2. Mettre en place un processus unique d'évaluation des risques de sécurité couvrant les deux cadres. Veiller à ce que les fournisseurs de logiciels d'IA — y compris les développeurs de modèles d'IA et les fournisseurs de données — soient soumis à des exigences de sécurité de la chaîne d'approvisionnement conformes à l'Art. 21(2)(d) de NIS2 et à l'Art. 25 du règlement IA (obligations relatives aux outils tiers).

Étape 5 : Surveillance humaine dans les contextes opérationnels

Concevoir des mécanismes de surveillance humaine au titre de l'Art. 14 qui soient opérationnellement viables dans les environnements de transport. Pour les systèmes de conduite autonome, définir les conditions dans lesquelles un conducteur doit être en mesure de reprendre le contrôle (L3) ou un opérateur à distance doit être en mesure d'intervenir (L4). Pour les systèmes d'IA de gestion du trafic aérien, préciser les points du flux de travail auxquels un contrôleur doit examiner et approuver les instructions générées par l'IA. Pour les systèmes d'IA de maintenance ferroviaire, définir les protocoles d'escalade lorsque le système signale des anomalies critiques pour la sécurité. Les mécanismes de surveillance doivent être documentés dans la documentation technique et reflétés dans les instructions d'utilisation fournies aux déployeurs.

Étape 6 : Surveillance post-commercialisation et notification des incidents

Mettre en place des systèmes de surveillance post-commercialisation satisfaisant à la fois aux exigences de l'Art. 72 du règlement IA et aux obligations sectorielles de reporting en matière de sécurité (notification des accidents ERA, déclaration d'événements EASA au titre du règlement (UE) 376/2014, notification d'incidents NIS2). Les incidents graves impliquant des systèmes d'IA à haut risque doivent être notifiés à l'autorité nationale de surveillance de l'IA au titre de l'Art. 73 dans un délai de 15 jours ouvrables à compter de la prise de connaissance. Ce délai doit être concilié avec l'exigence de notification initiale dans les 24 heures de NIS2 pour les incidents de cybersécurité significatifs, qui peut couvrir le même événement si le dysfonctionnement du système d'IA est imputable à une violation de cybersécurité.