IA
Réception de cellule robotisée avec IA : les 5 documents que votre client va vous demander
Votre client réceptionne une cellule robotisée intégrant un composant IA. Avant de signer le PV de réception, son équipe qualité et son responsable HSE vont passer la cellule au crible. Voici les cinq documents qu'ils exigeront et comment vous y préparer sans improviser en bout de projet.
La pression documentaire sur les livraisons de cellules robotisées avec IA s'est durcie depuis 2025. Deux raisons concrètes : la Directive Machines 2023/1230 renforce l'obligation de résultat sur l'intégrateur, et l'EU AI Act impose des exigences de traçabilité sur tout système IA classé à haut risque (Annexe III).
La date butoir pour les systèmes haut risque embarqués dans des machines : août 2026. Vos clients automotive, agroalimentaire et logistique intègrent ces exigences dans leurs cahiers de réception parfois avant même que leurs acheteurs n'aient mis à jour leurs templates.
Ce guide couvre les cinq dossiers concrets que vous devrez produire. Pas les principes généraux du droit. Les livrables que le chef de projet acheteur va poser sur la table lors du FAT ou du SAT.
1. Le rapport de qualification du modèle IA
Le client veut savoir si votre modèle a été testé dans des conditions proches de son environnement réel. Ce n'est pas une question d'accuracy globale sur le jeu d'entraînement. C'est une question de comportement dans les cas limites : pièces grasses, éclairage variable, références produits jamais vues en entraînement.
Un rapport de qualification du modèle IA couvre au minimum :
Les performances sur un jeu de données représentatif de la production cible, pas uniquement les données d'entraînement
Le domaine de validité explicite : quelles références, quelles conditions d'éclairage, quelle plage de cadence
Les résultats de tests hors distribution (OOD) : que fait le modèle face à une situation qu'il n'a jamais vue ?
Les métriques de fiabilité par prédiction, pas seulement les métriques globales
La limite du rapport classique
Un rapport basé sur une accuracy globale de 97 % ne dit rien sur le comportement du modèle sur les 3 % restants. Il ne dit pas non plus si le modèle "sait quand il ne sait pas". Un client avec des exigences qualité élevées, automotive ou pharmaceutique va systématiquement soulever ce point.
La fiabilité par prédiction change ça. Pour chaque inférence, un score de confiance individuel est produit, ce qui permet d'indiquer dans le rapport : "Sur 12 000 cycles de test, 98,7 % des prédictions ont un score de confiance au-dessus du seuil opérationnel. Les 1,3 % sous le seuil ont déclenché une escalade vers l'opérateur." C'est ce niveau de granularité que les clients exigeants attendent en 2026.
2. La documentation de gestion des risques IA (Article 9 EU AI Act)
L'Article 9 du Règlement UE 2024/1689 impose au fournisseur d'un système IA à haut risque d'établir et de maintenir un système de gestion des risques couvrant l'ensemble du cycle de vie. Pour un intégrateur qui livre une cellule robotisée, vous êtes en position de déployeur et parfois de fournisseur si vous avez entraîné le modèle.
Ce dossier doit documenter :
L'identification des scénarios de défaillance potentiels
Les mesures de mitigation associées : arrêt d'urgence, zone de sécurité, supervision humaine, seuil de confiance minimum
Les preuves que ces mesures ont été testées
Le protocole de surveillance en temps réel post-déploiement
La différence entre analyse de risques Directive Machines et gestion des risques IA
Votre client connaît l'analyse de risques EN ISO 10218 ou ISO 13849. Ce qu'il attend en plus, c'est que vous documentiez les risques propres au composant IA. Les deux référentiels ne couvrent pas le même terrain.
L'analyse Directive Machines couvre les risques mécaniques, électriques, ergonomiques. La gestion des risques IA couvre les défaillances silencieuses du modèle : détection erronée sans signal d'alarme, dérive des modèles en production, comportement inattendu hors distribution. Ce sont des risques que votre client ne peut pas voir à l'œil nu sur la cellule. Il vous demande de les avoir cartographiés.
Dimension | Analyse de risques Directive Machines | Gestion des risques IA (Article 9) |
|---|---|---|
Périmètre | Risques mécaniques, électriques, ergonomiques | Défaillances du modèle IA, comportements hors distribution |
Méthode | AMDEC machine, ISO 13849 | Cartographie scénarios de défaillance, tests OOD |
Preuve de conformité | Marquage CE, dossier technique | Documentation technique EU AI Act, logs de surveillance |
Responsabilité | Intégrateur (Directive Machines 2023/1230) | Intégrateur en tant que déployeur (EU AI Act Article 26) |
3. Les logs de traçabilité par inférence (Article 12 EU AI Act)
L'Article 12 du Règlement UE 2024/1689 impose que tout système IA à haut risque génère des journaux d'événements permettant de reconstituer le déroulement des opérations. Pour une cellule robotisée : pour chaque prédiction qui pilote une action physique en contexte de sécurité, un log horodaté doit être conservé.
Un log conforme Article 12 contient à minima :
L'horodatage de l'inférence (précision milliseconde)
L'identifiant de la prédiction
Le score de confiance de la prédiction
L'action déclenchée ou le refus d'action
Le contexte opérationnel : référence produit, identifiant cellule, mode de fonctionnement
Pourquoi les logs existants ne couvrent pas ce périmètre
Les historiques SCADA, les logs PLC, les journaux de supervision machine : aucun ne répond à cette exigence. Ils enregistrent les actions machines et les états capteurs. Ils n'enregistrent pas les métriques de fiabilité du composant IA au moment de la décision.
La différence compte lors d'un incident. Si un bras robotique cause un dommage et que votre client doit reconstituer la séquence devant une autorité de surveillance ou son assureur, la question sera : "À quel niveau de confiance le modèle IA a-t-il décidé d'agir ?" Sans log de fiabilité par inférence, la réponse est : "On ne sait pas." Avec, la réponse est traçable.
Les systèmes compatibles black-box comme TrustalAI génèrent ces logs au niveau de la couche de fiabilité, sans modifier le modèle sous-jacent ni le processus industriel. Chaque inférence produit un enregistrement structuré incluant le score de confiance, exploitable pour l'audit et la conformité Article 12. Latence : sous les 100ms en production normale, 20ms en edge.
4. Le dossier technique CE et Machinery Regulation (EU 2023/1230)
Ce document, votre client l'exige pour toute machine. Mais l'intégration d'un composant IA modifie ce que le dossier doit couvrir. La Directive Machines 2023/1230 intègre explicitement les systèmes IA dans le périmètre de l'évaluation de conformité.
Un dossier technique CE pour une cellule robotisée avec IA inclut :
L'évaluation des risques intégrant le comportement du composant IA et pas seulement la mécanique
La justification du niveau de confiance opérationnel retenu : pourquoi ce seuil, sur quelle base de test
Les preuves que le système de supervision humaine est fonctionnel (Article 14 EU AI Act)
La déclaration de conformité CE
Ce qui change avec l'IA dans le dossier
Jusqu'ici, un dossier CE pour une cellule de picking documentait un comportement déterministe : le bras fait X quand le capteur détecte Y. Avec un composant IA, ce n'est plus entièrement le cas. La documentation doit justifier comment l'incertitude du modèle est maîtrisée et comment la supervision humaine intervient quand la confiance est insuffisante.
Ce point est régulièrement sous-estimé en phase de conception. Les clients automotive et agroalimentaire avec des processus de qualification fournisseur formalisés,PPAP, IATF 16949 vont le soulever. Il est plus interessant de le documenter avant la réception que le négocier après.
5. Le plan de surveillance continue et de maintenance du modèle
Un modèle IA déployé en production n'est pas statique. Les conditions changent : nouvelles références produits, nouveaux fournisseurs de matière première, évolutions des conditions d'éclairage ou de cadence. La dérive des modèles finit toujours par arriver. Ce que votre client veut savoir : comment vous la détectez avant qu'elle cause un incident, et comment vous mettez à jour le modèle sans arrêter la production.
Le plan de surveillance continue documente :
Le protocole de détection de drift : quels indicateurs, quelle fréquence, qui est alerté
Les seuils d'alerte et les seuils d'arrêt
La procédure de mise à jour du modèle : tests de régression, validation avant déploiement, rollback possible
Les responsabilités post-réception : vous, le client, ou un tiers
La question contractuelle qui va venir
"Qui est responsable si le modèle dérive six mois après la livraison et cause un arrêt de ligne ?"
C'est une question de périmètre contractuel autant que technique. Les intégrateurs qui ne l'ont pas documenté en amont se retrouvent en position ambiguë. Ceux qui ont fourni un plan de surveillance avec des seuils explicites ont une réponse et une protection.
La surveillance post-déploiement ne demande pas de réentraîner en permanence. Une couche de fiabilité plug-and-play peut détecter en continu la dérive des distributions d'entrée sans accéder aux données d'entraînement ni modifier le modèle. Le signal d'alerte arrive avant que la performance ne se dégrade visiblement sur la production.
Fiabilité par prédiction vs monitoring post-mortem : la distinction que votre client va faire
Un point source de confusion en réception : les outils de monitoring agrégé tableaux de bord de performance hebdomadaires, rapports de dérive ne remplacent pas les logs de fiabilité par inférence. Et votre client le sait, ou va l'apprendre vite.
Monitoring post-mortem / agrégé | Fiabilité par prédiction | |
|---|---|---|
Quand ? | Après exécution, sur des fenêtres temporelles | Avant l'action, pour chaque prédiction individuelle |
Granularité | Métriques sur N inférences | Score par inférence |
Usage en réception | Rapport de qualification globale | Logs Article 12, preuve de supervision temps réel |
Usage post-déploiement | Détection de dérive sur la durée | Escalade immédiate sur prédiction non fiable |
Conformité EU AI Act | Insuffisant seul pour Article 12 | Conforme Article 12 |
Les deux sont nécessaires. Ce que votre client exige en réception, c'est la preuve que les deux couches sont en place et non l'une ou l'autre.
FAQ
Quels documents un intégrateur doit fournir lors de la réception d'une cellule robotisée avec IA ?
Cinq documents sont exigés : le rapport de qualification du modèle IA (performances sur données représentatives, tests hors distribution, métriques de fiabilité par prédiction), la documentation de gestion des risques IA (Article 9 EU AI Act), les logs de traçabilité par inférence (Article 12 EU AI Act), le dossier technique CE intégrant l'évaluation des risques IA (Directive Machines 2023/1230, EN ISO 10218, ISO 13849), et le plan de surveillance continue avec protocole de détection de dérive.
La Directive Machines 2023/1230 s'applique déjà à mes projets en cours ?
La Directive Machines 2023/1230 est en vigueur depuis 2023 avec une période de transition : les équipements neufs mis sur le marché après juillet 2027 devront s'y conformer. Mais les projets intégrant de l'IA à haut risque tombent aussi sous les obligations de l'EU AI Act, dont l'échéance pour les systèmes Annexe III est fixée à août 2026. Pour les cellules en cours de conception, il vaut mieux anticiper les deux référentiels maintenant.
Qu'est-ce qu'un log de traçabilité conforme Article 12 EU AI Act pour une cellule robotisée ?
Un log conforme Article 12 enregistre, pour chaque inférence du composant IA pilotant une action physique en contexte de sécurité : l'horodatage (précision milliseconde), le score de confiance de la prédiction, l'action déclenchée ou le refus d'action, et le contexte opérationnel. Les logs SCADA ou PLC classiques ne répondent pas à cette exigence, ils enregistrent les états machines, pas les métriques de fiabilité du modèle au moment de la décision.
Comment documenter la supervision humaine dans le dossier CE d'une cellule avec IA ?
La supervision humaine (Article 14 EU AI Act) doit être documentée techniquement : quand le système s'arrête pour solliciter un opérateur, à quel seuil de confiance, quelle interface alerte l'opérateur, comment il prend le relais ou valide la prédiction. Ces mécanismes doivent être testés, et les preuves de test doivent figurer dans le dossier CE. Écrire "un opérateur peut intervenir" ne suffit pas.
Un modèle IA black-box peut-il générer les logs de traçabilité requis par l'EU AI Act ?
Oui, à condition de brancher en parallèle une couche de fiabilité compatible black-box. Cette couche intercepte les prédictions du modèle, calcule les métriques de fiabilité par inférence et génère les logs structurés sans accéder aux poids du modèle ni le modifier. Cette architecture plug-and-play permet à des modèles de vision comme Cognex, Keyence, Basler, d'être mis en conformité avec l'Article 12 sans réentraînement.
Source:
Partager
Articles connexes
