EU AI Act et Directive Machines : peut-on satisfaire les deux avec une couche de fiabilité ?

Un intégrateur industriel livre une cellule robotisée équipée d'un système de vision basé sur du deep learning. Il signe un contrat au forfait avec obligation de résultat. Quelques mois plus tard, son client lui demande de justifier la fiabilité de la brique IA, pas la performance globale mais bien la fiabilité de chaque décision prise en temps réel.

Il ne peut pas répondre.

Ce n'est pas une situation hypothétique. C'est le quotidien de plusieurs centaines d'intégrateurs système en Europe depuis que l'EU AI Act a enclenché son calendrier de conformité et que le Règlement Machines 2023/1230 a clarifié les obligations sur les machines intégrant de l'intelligence artificielle.

La question posée ici est simple : peut-on satisfaire ces deux textes réglementaires avec un seul dispositif technique ? Et si oui, lequel ?

Ce que les deux textes exigent réellement

L'EU AI Act et les systèmes à haut risque (Annex III)

L'EU AI Act place les systèmes IA utilisés dans des contextes industriels critiques, contrôle qualité automatisé, robotique, systèmes de détection, sous la catégorie "à haut risque" dès lors qu'ils influencent des décisions conséquentes sur des personnes ou des processus de sécurité.

Pour ces systèmes, le texte impose plusieurs obligations précises : documenter la robustesse et la fiabilité avant déploiement, mettre en place une surveillance post-marché continue, garantir la traçabilité des données et des décisions, et démontrer que le système reste fiable dans ses conditions opérationnelles réelles.

La date de référence légale reste le 2 août 2026. Un accord politique a été conclu le 7 mai 2026 entre les co-législateurs (Parlement européen + Conseil) sur le paquet Digital Omnibus on AI, qui décalerait les obligations Annex III au 2 décembre 2027 mais cet accord n'est pas encore formellement adopté (vote final + publication au JO à venir). Tant que l'adoption formelle n'est pas intervenue, le calendrier de l'AI Act de base (Art. 113) constitue le droit positif applicable. Kennedys Law, "The EU AI Act Implementation Timeline"

Ce qui frappe dans l'EU AI Act, c'est l'exigence de traçabilité granulaire. Selon le cabinet Datenschutz-Notizen, "l'infrastructure de conformité pour les systèmes à haut risque repose sur la capacité à journaliser et reconstruire chaque décision IA". Autrement dit : il ne suffit pas de prouver que le modèle est bon en moyenne. Il faut prouver que chaque prédiction est traçable et que sa fiabilité est mesurable.

Selon une enquête Bureau Veritas / AWS publiée en 2026, 68 % des entreprises peinent à interpréter l'EU AI Act. Et 60 % n'ont pas la gouvernance nécessaire pour y répondre. Les coûts de mise en conformité estimés par la Commission européenne atteignent jusqu'à 319 000 € pour une PME. DQ India, "45 Industry Associations Sign Joint Statement"

Le Règlement Machines 2023/1230 et la responsabilité de l'intégrateur

Le Règlement Machines 2023/1230, qui succède à la Directive 2006/42/CE, change un point fondamental : il met explicitement en lumière le problème posé par l'intégration de systèmes IA (notamment du deep learning) dans des cellules robotisées.

Ce texte impose à l'intégrateur système le marquage CE et l'analyse de risques de la machine complète.
C'est lui qui porte l'obligation de résultat vis-à-vis du client final. Et c'est lui qui, si le système de vision provoque un incident, doit prouver qu'il avait correctement évalué et encadré la fiabilité du composant IA.

Comme le résume Robotics & Automation News, le passage du "freeze" (qualification sur version figée) au "continuous assurance" (surveillance continue) est désormais ce que la réglementation exige pour les logiciels intégrés dans des systèmes robotiques. Robotics & Automation News, "From Freeze to Flow: New EU Regulation Redefines Robotics Software Qualification"

La combinaison des deux textes crée ce que l'on peut appeler une double pression réglementaire sur l'intégrateur système : prouver la fiabilité du composant IA au sens de l'EU AI Act, et garantir la sécurité de la machine livrée au sens du Règlement Machines. Ce sont deux exigences distinctes. Mais elles partagent un dénominateur commun : la fiabilité de chaque décision IA doit être mesurable et documentable.

Ce que le monitoring post-mortem ne peut pas fournir

C'est ici que la plupart des approches actuelles échouent.

Les solutions de monitoring IA dominantes sur le marché, les plateformes MLOps, outils d'observabilité, dashboards de performance fonctionnent sur un principe : analyser le comportement du modèle après exécution, sur un ensemble de prédictions agrégées. Elles calculent des métriques moyennes (accuracy, AP, taux de dérive global) sur des fenêtres temporelles.

Ce modèle est utile pour détecter une dégradation lente. Il ne répond pas aux exigences réglementaires pour une raison simple : au moment où la métrique agrégée signale un problème, des centaines de décisions ont déjà été prises, les actions ont déjà été exécutées, et le risque existe déjà dans le système.

L'EU AI Act demande la traçabilité de chaque décision. Le Règlement Machines demande la preuve de fiabilité sur la machine livrée, pas sur sa performance statistique moyenne. Le monitoring agrégé et post-mortem ne satisfait ni l'un ni l'autre.

La différence n'est pas anecdotique. C'est une question de granularité : les textes réglementaires raisonnent au niveau de la décision individuelle. La plupart des outils disponibles raisonnent au niveau de la cohorte.

Comment une couche de fiabilité répond aux deux obligations simultanément

Pour l'EU AI Act : traçabilité et détection de la dérive des modèles

Une brique de fiabilité per-prediction reliability génère, pour chaque sortie du modèle IA, un ensemble de métriques de confiance en temps réel. Dans le cas de la vision 2D industrielle, cela correspond aux incertitudes σx, σy, σw, σh sur chaque bounding box produite.

Ce que cela apporte concrètement pour la conformité EU AI Act :

Chaque prédiction est accompagnée d'une mesure de fiabilité exploitable, journalisée et traçable. Si un auditeur demande à reconstruire une décision passée, ce que The Recursive décrit comme "the replayability test", les données sont disponibles au niveau de chaque inférence, pas seulement au niveau agrégé.

La dérive des modèles (model drift) est détectable en continu : lorsque les métriques de confiance se dégradent sur une distribution d'entrée inhabituelle, le signal apparaît avant que la performance globale se dégrade. C'est ce que le système d'alerte précoce sur les situations hors domaine de validité (OOD Out-Of-Distribution) permet.

En pratique, cela signifie que le dossier technique requis par l'EU AI Act peut être alimenté automatiquement, sans processus manuel supplémentaire.

Pour la Directive Machines : documenter la fiabilité avant livraison

L'intégrateur système qui livre une cellule robotisée IA doit produire une analyse de risques démontrant que la fiabilité du composant IA a été évaluée dans les conditions d'exploitation réelles.

Le problème classique c'est que le modèle de vision est une boîte noire fournie par un OEM ou développée en interne. L'intégrateur n'a pas accès aux poids du modèle, ne peut pas modifier son architecture, et ne souhaite pas pour des raisons légitimes de propriété intellectuelle que le fournisseur de la brique de fiabilité ait accès à ses données ou à son IP.

Une couche de fiabilité plug-and-play répond précisément à cette contrainte : elle se branche en parallèle du modèle existant, sans modification du modèle IA original, sans accès aux données client, avec une activation possible sans changement de processus sur la ligne.

Ce positionnement change la nature de la preuve disponible pour l'analyse de risques : l'intégrateur peut désormais quantifier la fiabilité de la brique IA dans ses conditions opérationnelles réelles, avec des données de production, avant la livraison de la machine au client final.

C'est une réponse directe à l'obligation de résultat imposée par le Règlement Machines 2023/1230.

Ce que ça donne concrètement : le PoC VEDECOM

Les résultats disponibles sur un cas réel, le PoC mené avec l'Institut VEDECOM sur la perception coopérative pour véhicules autonomes donnent un ordre de grandeur utile.

En ajoutant une couche de fiabilité per-prediction reliability sur un modèle de vision existant, sans réentraînement du modèle client, les résultats mesurés sur les données de production sont les suivants :

• -83 % de faux positifs éliminés

• -65 % d'erreurs de position (de 1,44 m à 0,51 m)

• -63 % d'erreurs d'orientation (de 6,28° à 2,35°)

• Exécution en temps réel en 20ms en Edge.

Ces résultats ont été benchmarkés contre 7 méthodes de fusion alternatives [Fadili et al., IRCE 2025] et publiés. Ils ne sont pas des projections : ils viennent d'une validation sur données réelles.

Pour un intégrateur système, -83 % de faux positifs se traduit directement en arrêts de ligne évités, en réduction du taux de rebut injustifié, et en documentation de fiabilité exploitable pour l'analyse de risques. Ce sont des arguments mesurables dans le dossier technique soumis à marquage CE.

FAQ :

L'EU AI Act s'applique-t-il aux intégrateurs système ou seulement aux développeurs de modèles IA ?

L'EU AI Act s'applique à tous les acteurs qui mettent en service des systèmes IA à haut risque sur le marché européen, y compris les intégrateurs. Si vous intégrez un composant de vision ou de détection IA dans une cellule robotisée livrée à un client industriel, vous êtes concerné par les obligations de documentation et de surveillance. L'éditeur du modèle n'est pas seul responsable : l'intégrateur qui déploie porte une part des obligations réglementaires, notamment sur la traçabilité et la gestion des risques.

Quelle est la différence entre le monitoring IA standard et la fiabilité par prédiction au sens de la conformité réglementaire ?

Le monitoring standard mesure des métriques agrégées sur des cohortes de prédictions, utile pour détecter une dégradation lente, mais insuffisant pour la traçabilité individuelle.
La fiabilité par prédiction (per-prediction reliability) génère des métriques de confiance pour chaque inférence, en temps réel. C'est ce niveau de granularité que l'EU AI Act exige pour la journalisation des systèmes à haut risque. Sans lui, vous ne pouvez pas reconstruire une décision individuelle en cas de contrôle ou d'incident.

La Directive Machines 2023/1230 est-elle compatible avec l'EU AI Act, ou créent-elles des obligations contradictoires ?

Les deux textes ne sont pas contradictoires : ils se complètent. La Directive Machines impose à l'intégrateur l'obligation de résultat sur la sécurité de la machine livrée et la documentation de l'analyse de risques. L'EU AI Act impose la traçabilité et la surveillance continue des composants IA. Une brique de fiabilité per-prediction reliability satisfait les deux : elle fournit la documentation technique pour le marquage CE et génère le log de fiabilité nécessaire à la conformité EU AI Act. Un seul dispositif, deux obligations adressées.

Combien coûte la non-conformité à l'EU AI Act pour un intégrateur industriel ?

Les sanctions prévues par l'EU AI Act atteignent jusqu'à 3 % du chiffre d'affaires mondial pour non-conformité sur les systèmes à haut risque. Mais le coût opérationnel le plus immédiat est ailleurs : un incident sur une machine livrée, sans documentation de fiabilité IA, peut engager la responsabilité contractuelle et civile de l'intégrateur au titre du Règlement Machines. La Commission européenne estime les coûts de mise en conformité à jusqu'à 319 000 € pour une PME, ce qui rend les approches plug-and-play, déployables sans modifier l'architecture existante, particulièrement pertinentes.

À quelle vitesse peut-on déployer une couche de fiabilité IA sur un système existant ?

Une couche de fiabilité plug-and-play compatible black-box ne nécessite pas de modification du modèle IA existant ni d'accès à la propriété intellectuelle du client. Elle se branche en parallèle de l'architecture existante. En pratique, le cycle type de déploiement comprend une phase de spécifications (2 semaines), une phase de validation (1 semaine) et un PoC de 2 semaines, soit environ 5 semaines pour une première validation sur données réelles.