est lié au contenu de l'information, notamment sa compréhensibilité et sa justesse [28]. Par exemple, là où la transparence exigerait de disposer des poids d'un réseau de newones, l'explicabilité permet d'interpréter ces chiffres et le résultat qui en découle.

Nous nous intéressons dans cette étude au cas d'usage des dispositifs de détection d'infractions routières. En effet, si les premiers systèmes de radar fonctionnaient par effet Doppler, les plus récents permettent de détecter si une voiture franchit la ligne d'un feu rouge<fnref n="5" /> ou de discriminier entre une voiture et un camion dans le cas de limites de vitesse différentes<fnref n="6" />. Aujourd'hui, une troisième génération de dispositif est en cours de développement par les entreprises françaises, qui permettraient de détecter si un conducteur porte bien sa ceinture de sécurité et ne téléphone pas au volant [21] à l'aide d'apprentissage profond. Toutefois, les performances et la chaîne de décision de ces nouveaux systèmes sont différents : ils sont moins précis et un opérateur humain est en charge de vérifier la sortie du système et de sanctionner ou non l'automobiliste. Le constat de l'infraction est effectué par l'humain, même si celui-ci s'appuie sur des images recommandées au préalable par le système. Les dispositifs de vidéos intelligentes adoptent généralement ce schéma : le système propose, et l'humain décide.

Dans cette étude, nous examinons les besoins en explicabilité de ces nouveaux dispositifs à base d'apprentissage profond. Nous étudions le cas des radars routiers classiques afin de soulever les différences avec le nouveau dispositif. Les différents types de radars actuels, ainsi que leurs exigences techniques et réglementaires sont exposés en Section 2. En Section 3, nous présentons les dispositifs de nouvelle génération à base d'IA et montrons que les anciennes méthodes d'évaluation, fondées sur des essais et calculs de performance, ne sont pas adaptées à ces nouveaux systèmes. Nous expliquons également comment le changement dans la chaîne de décision, avec l'introduction du contrôle humain, fait passer le besoin d'explicabilité de la machine à l'homme. En Section 4, nous analysons les textes réglementaires à la recherche d'exigences d'explicabilité pour les systèmes d'IA et montrons qu'aujourd'hui elles sont davantage semblables à des exigences de transparence. En Section 5, nous revenons au cas d'usage des dispositifs de détection d'infractions, et discutons du rôle que pourrait jouer l'explicabilité dans cette chaîne de commande. Enfin, nous discutons en Section 6 de ce qui peut être retenu de l'étude de ce cas d'usage et donnons quelques recommandations, utilisables pour ces dispositifs mais aussi pour d'autres systèmes tels que les dispositifs de vidéos intelligentes qui seront expérimentés lors des Jeux Olympiques de Paris en 2024.

# 2 Le fonctionnement et l'encadrement des radars routiers actuels

## 2.1 Une diversité de radars qui utilisent parfois des techniques d'apprentissage machine

### 2.1.1 Types de radars actuels

Nous connaissons bien aujourd'hui les radars routiers qui flashent l'automobiliste imprudent lorsque la vitesse de son véhicule dépasse un certain seuil. Mais cet appareil est loin d'être le seul type de radar existant. Nous allons ici nous intéresser au cas des radars fixes, bien que l'on notera tout de même l'existence de radars déplaçables, destinés à être disposés par exemple sur des chantiers, pour couvrir les zones de danger, ainsi que de radars mobiles, débarqués au bord de la route ou embarqués dans une voiture radar. Les radars fixes comprennent : les radars de contrôle de la vitesse fixes, aussi appelés cinémomètres, les radars de franchissement, et les radars pédagogiques <fnref n="7" />. Ces derniers, visent à inciter les usagers à ralentir sans les verbaliser, en affichant par exemple un symbole « danger » ou leur vitesse en rouge si elle est trop élevée. Nous les écartons pour notre discussion puisqu'ils ne mènent pas à un processus de contravention. Il reste alors deux types de radars : les radars vitesse et les radars de franchissement.

Les plus anciens radars routiers sont les radars de vitesse fixes qui calculent instantanément la vitesse d'un véhicule à son passage et sanctionnent lorsque la vitesse dépasse la limite autorisée. Plusieurs variantes de ces systèmes existent comme les radars qui permettent de différencier entre plusieurs catégories de véhicules, par exemple entre poids lourds et véhicules légers, pour contrôler des limites de vitesse différentes. Les radars de vitesse moyenne, communément appelés radars tronçon, permettent, quant à eux, de calculer la vitesse moyenne d'un véhicule sur une portion de route <fnref n="8" />. Le dernier type de radar, les radars de franchissement, comprennent les radars feux rouges, positionnés au niveau des carrefours routiers et prenant une photo si un véhicule franchit la ligne du feux ou s'il poursuit sa route au delà du feu, et les radars de passage à niveau <fnref n="9" />.

### 2.1.2 Certains radars intègrent des modèles d'apprentissage machine

S'il est impossible de connaître les détails du fonctionnement des systèmes de radars actuels pour des raisons de propriété intellectuelle des entreprises, nous savons néanmoins que les techniques de détection ont bien évoluées depuis les radars à effet Doppler.

<footnote n="5">5. Voir les radars feu rouge, sur le site de la sécurité routière : https://www.securite-routiere.gouv.fr/radars/different-types-de-radars/radars-fixes/radars-de-franchissement</footnote>

<footnote n="6">6. Voir les radars discriminants, sur le site de la sécurité routière : https://www.securite-routiere.gouv.fr/radars/differents-types-de-radars/radars-fixes/radars-de-contrôle-de-la-vitesse-fixes</footnote>

<footnote n="7">7. Voir la liste des différents types de radars sur le site de la sécurité routière : https://www.securite-routiere.gouv.fr/radars/differents-types-de-radars</footnote>

<footnote n="8">8. Voir la liste des différents radars de contrôle de la vitesse fixes sur le site de la sécurité routière : https://www.securite-routiere.gouv.fr/radars/differents-types-de-radars/radars-fixes/radars-de-controle-de-la-vitesse-fixes</footnote>

<footnote n="9">9. Voir la liste des différents radars de franchissement sur le site de la sécurité routière : https://www.securite-routiere.gouv.fr/radars/differents-types-de-radars/radars-fixes/radars-de-franchissement</footnote>
est lié au contenu de l'information, notamment sa compréhensibilité et sa justesse [28]. Par exemple, là où la transparence exigerait de disposer des poids d'un réseau de neuerones, l'explicabilité permet d'interpréter ces chiffres et le résultat qui en découle.

Nous nous intéressons dans cette étude au cas d'usage des dispositifs de détection d'infractions routières. En effet, si les premiers systèmes de radar fonctionnaient par effet Doppler, les plus récents permettent de détecter si une voiture franchit la ligne d'un feu rouge<fnref n="5" /> ou de discriminner entre une voiture et un camion dans le cas de limites de vitesse différentes<fnref n="6" />. Aujourd'hui, une troisième génération de dispositif est en cours de développement par les entreprises françaises, qui permettraient de détecter si un conducteur porte bien sa ceinture de sécurité et ne téléphone pas au volant [21] à l'aide d'apprentissage profond. Toutefois, les performances et la chaîne de décision de ces nouveaux systèmes sont différents : ils sont moins précis et un opérateur humain est en charge de vérifier la sortie du système et de sanctionner ou non l'automobiliste. Le constat de l'infraction est effectué par l'humain, même si celui-ci s'appuie sur des images recommandées au préalable par le système. Les dispositifs de vidéos intelligentes adoptent généralement ce schéma : le système propose, et l'humain décide.

Dans cette étude, nous examinons les besoins en explicabilité de ces nouveaux dispositifs à base d'apprentissage profond. Nous étudions le cas des radars routiers classiques afin de soulever les différences avec le nouveau dispositif. Les différents types de radars actuels, ainsi que leurs exigences techniques et réglementaires sont exposés en Section 2. En Section 3, nous présentons les dispositifs de nouvelle génération à base d'IA et montrons que les anciennes méthodes d'évaluation, fondées sur des essais et calculs de performance, ne sont pas adaptées à ces nouveaux systèmes. Nous expliquons également comment le changement dans la chaîne de décision, avec l'introduction du contrôle humain, fait passer le besoin d'explicabilité de la machine à l'homme. En Section 4, nous analysons les textes réglementaires à la recherche d'exigences d'explicabilité pour les systèmes d'IA et montrons qu'aujourd'hui elles sont davantage semblables à des exigences de transparence. En Section 5, nous revenons au cas d'usage des dispositifs de détection d'infractions, et discutons du rôle que pourrait jouer l'explicabilité dans cette chaîne de commande. Enfin, nous discutons en Section 6 de ce qui peut être retenu de l'étude de ce cas d'usage et donnons quelques recommandations, utilisables pour ces dispositifs mais aussi pour d'autres systèmes tels que les dispositifs de vidéos intelligentes qui seront expérimentés lors des Jeux Olympiques de Paris en 2024.

# 2 Le fonctionnement et l'encadrement des radars routiers actuels

## 2.1 Une diversité de radars qui utilisent parfois des techniques d'apprentissage machine

### 2.1.1 Types de radars actuels

Nous connaissons bien aujourd'hui les radars routiers qui flashent l'automobiliste imprudent lorsque la vitesse de son véhicule dépasse un certain seuil. Mais cet appareil est loin d'être le seul type de radar existant. Nous allons ici nous intéresser au cas des radars fixes, bien que l'on notera tout de même l'existence de radars déplaçables, destinés à être disposés par exemple sur des chantiers, pour couvrir les zones de danger, ainsi que de radars mobiles, débarqués au bord de la route ou embarqués dans une voiture radar. Les radars fixes comprennent : les radars de contrôle de la vitesse fixes, aussi appelés cinémomètres, les radars de franchissement, et les radars pédagogiques <fnref n="7" />. Ces derniers, visent à inciter les usagers à ralentir sans les verbaliser, en affichant par exemple un symbole « danger » ou leur vitesse en rouge si elle est trop élevée. Nous les écartons pour notre discussion puisqu'ils ne mènent pas à un processus de contravention. Il reste alors deux types de radars : les radars vitesse et les radars de franchissement.

Les plus anciens radars routiers sont les radars de vitesse fixes qui calculent instantanément la vitesse d'un véhicule à son passage et sanctionnent lorsque la vitesse dépasse la limite autorisée. Plusieurs variantes de ces systèmes existent comme les radars qui permettent de différencier entre plusieurs catégories de véhicules, par exemple entre poids lourds et véhicules légers, pour contrôler des limites de vitesse différentes. Les radars de vitesse moyenne, communément appelés radars tronçon, permettent, quant à eux, de calculer la vitesse moyenne d'un véhicule sur une portion de route <fnref n="8" />. Le dernier type de radar, les radars de franchissement, comprennent les radars feux rouges, positionnés au niveau des carrefours routiers et prenant une photo si un véhicule franchit la ligne du feux ou s'il poursuit sa route au delà du feu, et les radars de passage à niveau <fnref n="9" />.

### 2.1.2 Certains radars intègrent des modèles d'apprentissage machine

S'il est impossible de connaître les détails du fonctionnement des systèmes de radars actuels pour des raisons de propriété intellectuelle des entreprises, nous savons néanmoins que les techniques de détection ont bien évoluées depuis les radars à effet Doppler.

<footnote n="5">5. Voir les radars feu rouge, sur le site de la sécurité routière : https://www.securite-routiere.gouv.fr/radars/different-types-de-radars/radars-fixes/radars-de-franchissement</footnote>

<footnote n="6">6. Voir les radars discriminants, sur le site de la sécurité routière : https://www.securite-routiere.gouv.fr/radars/differents-types-de-radars/radars-fixes/radars-de-contrôle-de-la-vitesse-fixes</footnote>

<footnote n="7">7. Voir la liste des différents types de radars sur le site de la sécurité routière : https://www.securite-routiere.gouv.fr/radars/differents-types-de-radars</footnote>

<footnote n="8">8. Voir la liste des différents radars de contrôle de la vitesse fixes sur le site de la sécurité routière : https://www.securite-routiere.gouv.fr/radars/differents-types-de-radars/radars-fixes/radars-de-controle-de-la-vitesse-fixes</footnote>

<footnote n="9">9. Voir la liste des différents radars de franchissement sur le site de la sécurité routière : https://www.securite-routiere.gouv.fr/radars/differents-types-de-radars/radars-fixes/radars-de-franchissement</footnote>
Les techniques employées aujourd'hui relèvent de l'appren-
tissage machine « classique », notamment l'utilisation de
features extractor pour détecter des objets dans une image.
Une des méthodes les plus répandue se nomme Histogram
of Oriented Gradients (HOG). Elle consiste à créer un his-
togramme en utilisant les gradients et les orientations des
valeurs des pixels de l'image : l'amplitude est plus élevée
lorsqu'il y a un changement brusque d'intensité, comme sur
les bords, ce qui permet de détecter l'objet - ici la voiture.
Ces techniques permettent aux radars actuels d'atteindre
une très forte précision : leur taux d'erreur est d'environ
$10^{-6}$.

2.1.3 La décision des radars est automatique et est présumée juste

En France, ces radars sont encadrés par la loi n° 2003-495 du 12 juin 2003, renforçant la lutte contre la violence routière [6], qui autorise la mise en place de cinémomètres fixes et l'édition des procès-verbaux de façon automatique à partir de photographies numériques. La gestion du traitement automatisé des infractions routières est confié depuis 2011 à l'Agence Nationale de Traitement Automatisé des Infractions (ANTAI)<fnref n="10" />. Ainsi, les radars actuels détectent automatiquement, c'est-à-dire sans contrôle humain, que les véhicules dépassent la limite de vitesse et envoient l'infraction directement au poste de police [35]. Le message d'infraction contient notamment la vitesse estimée, l'heure, le numéro du radar, ainsi que la plaque d'immatriculation lue par le radar.

Le Code de la route précise dans son Article L.130-9 que « Lorsqu'elles sont effectuées par ou à partir des appareils de contrôle automatique ayant fait l'objet d'une homologation, les constatations relatives aux infractions dont la liste est fixée par décret en Conseil d'État font foi jusqu'à preuve du contraire ». Cela signifie qu'il y a présomption de justesse du résultat : en cas de contestation, il revient à l'utilisateur de prouver que le résultat est faux et que la sanction est infondée. Cela ne laisse place qu'à quelques possibles cas de contestation : par exemple si le conducteur peut démontrer que son véhicule ne pouvait pas atteindre la vitesse qui lui est reprochée, si le véhicule a été volé, cédé ou détruit, ou en cas d'usurpation de plaque d'immatriculation [35].

Le fonctionnement des radars actuels est résumé en Fi-
gure 1.

2.2 L'encadrement des radars actuels

2.2.1 Une homologation obligatoire par le LNE

Selon le décret n° 2001-387 du 3 mai 2001 relatif au contrôle des instruments de mesure [5], les radars routiers sont soumis à plusieurs examens, listés en article 4. La première vérification, appelée examen de type ou homologation, permet l'approbation du modèle du système qui sert ensuite de référence à la production des autres appareils. La seconde, la vérification primitive, consiste en un contrôle de chaque appareil avant la mise en service. Une vérification de l'installation sur site est ensuite effectuée. Enfin, le

contrôle en service, ou vérification périodique, est réalisé à
intervalles réguliers pendant toute la durée de vie de l'ap-
pareil<fnref n="11" />.

Ces examens sont principalement <fnref n="12" /> effectués par le Labo-
ratoire National de Métrologie et d'Essais (LNE) <fnref n="13" />, et, dans
le cas de l'homologation, aboutissent à la délivrance d'un
certificat. Ces certificats sont trouvable sur le site du LNE,
souvent accompagnés d'annexes décrivant brièvement le
fonctionnement du système.

Les radars routiers sont soumis à une série de vérifica-
tions pour garantir l'exactitude de leurs mesures. Les pro-
cessus de vérification varient selon les pays d'Europe. Par
exemple, l'Allemagne se base sur de l'audit logiciel. En
France, ces vérifications sont effectuées dans le cadre de
l'examen d'homologation et reposent sur des essais réali-
sés sur le système final. Le but général des essais est de
garantir le bon fonctionnement des systèmes et le respect
des exigences réglementaires. Nous nous concentrons dans
cette analyse sur le cas français.

2.2.2 Les marges d'erreur définies par arrêté

L'arrêté du 4 juin 2009 relatif aux cinémomètres de contrôle routier [3], précise les modalités des examens dans le cas des radars de vitesse. Il contient un descriptif de l'examen d'homologation, qui comporte : un examen de conformité du dossier, des essais en laboratoire, dans les conditions de fonctionnement, des essais en fonctionnement réel dans des conditions normales d'utilisation sur route, ainsi que « des analyses de simulation pour les situations dangereuses qui ne peuvent être reproduites lors des essais sur route » (art. 9). La liste des essais minimaux à réaliser en laboratoire est également fournie. Parmi eux se trouvent notamment : la courbe d'erreurs en fonction de la vitesse, l'exactitude de la valeur des vitesses, des exigences sur les affichages, sur les tolérances en termes de température, d'humidité ou de choc (annexe III).

L'arrêté fourni, en outre, les exigences essentielles de
construction des cinémomètres, comme les erreurs maxi-
males tolérées sur les mesures de vitesses : 5 km/h pour des
vitesses inférieures à 100 km/h et 5% de la vitesse pour des
vitesses supérieures (art. 6). Ce 5 (km/h et %) est remplacé
par un 3 pour les appareils neufs fixes, 7 pour les appareils
neufs dans un véhicule en mouvement et 10 pour les ap-
pareils en service dans un véhicule en mouvement (art.5 et
6).

Les radars de franchissement, détectant si un véhicule ne
respecte pas l'arrêt à un feux rouge, sont soumis à une
réglementation différente : celle de l'arrêté du 18 janvier
2012 relatif à l'homologation des systèmes de contrôle au-

<footnote n="11">11. Voir les différents examens des radars sur le site de la sécurité rou-
tière: https://www.securite-routiere.gouv.fr/radars/
/fonctionnement-des-radars/verification-des-rad-
ars-de-vitesse</footnote>

<footnote n="12">12. Pour les radars de franchissements, seule l'homologation est réa-
lisée par le LNE, les autres vérifications sont menées par des agents
habilités des Centres d'Etudes Techniques de l'Equipement : https :
//www.securite-routiere.gouv.fr/radars/fonctionn-
ement-des-radars/verification-des-radars-de-fra-
nchissement-de-feux</footnote>

<footnote n="13">13. https://www.lne.fr/fr</footnote>

<footnote n="10">10. https://www.antai.gouv.fr/</footnote>
Les techniques employées aujourd'hui relèvent de l'appren-
tissage machine « classique », notamment l'utilisation de
features extractor pour détecter des objets dans une image.
Une des méthodes les plus répandue se nomme Histogram
of Oriented Gradients (HOG). Elle consiste à créer un his-
togramme en utilisant les gradients et les orientations des
valeurs des pixels de l'image : l'amplitude est plus élevée
lorsqu'il y a un changement brusque d'intensité, comme sur
les bords, ce qui permet de détecter l'objet - ici la voiture.
Ces techniques permettent aux radars actuels d'atteindre
une très forte précision : leur taux d'erreur est d'environ
$10^{-6}$.

2.1.3 La décision des radars est automatique et est présumée juste

En France, ces radars sont encadrés par la loi n° 2003-495 du 12 juin 2003, renforçant la lutte contre la violence routière [6], qui autorise la mise en place de cinémomètres fixes et l'édition des procès-verbaux de façon automatique à partir de photographies numériques. La gestion du traitement automatisé des infractions routières est confié depuis 2011 à l'Agence Nationale de Traitement Automatisé des Infractions (ANTAI)<fnref n="10" />. Ainsi, les radars actuels détectent automatiquement, c'est-à-dire sans contrôle humain, que les véhicules dépassent la limite de vitesse et envoient l'infraction directement au poste de police [35]. Le message d'infraction contient notamment la vitesse estimée, l'heure, le numéro du radar, ainsi que la plaque d'immatriculation lue par le radar.

Le Code de la route précise dans son Article L.130-9 que « Lorsqu'elles sont effectuées par ou à partir des appareils de contrôle automatique ayant fait l'objet d'une homologation, les constatations relatives aux infractions dont la liste est fixée par décret en Conseil d'État font foi jusqu'à preuve du contraire ». Cela signifie qu'il y a présomption de justesse du résultat : en cas de contestation, il revient à l'utilisateur de prouver que le résultat est faux et que la sanction est infondée. Cela ne laisse place qu'à quelques possibles cas de contestation : par exemple si le conducteur peut démontrer que son véhicule ne pouvait pas atteindre la vitesse qui lui est reprochée, si le véhicule a été volé, cédé ou détruit, ou en cas d'usurpation de plaque d'immatriculation [35].

Le fonctionnement des radars actuels est résumé en Fi-
gure 1.

2.2 L'encadrement des radars actuels

2.2.1 Une homologation obligatoire par le LNE

Selon le décret n° 2001-387 du 3 mai 2001 relatif au contrôle des instruments de mesure [5], les radars routiers sont soumis à plusieurs examens, listés en article 4. La première vérification, appelée examen de type ou homologation, permet l'approbation du modèle du système qui sert ensuite de référence à la production des autres appareils. La seconde, la vérification primitive, consiste en un contrôle de chaque appareil avant la mise en service. Une vérification de l'installation sur site est ensuite effectuée. Enfin, le

contrôle en service, ou vérification périodique, est réalisé à
intervalles réguliers pendant toute la durée de vie de l'ap-
pareil<fnref n="11" />.

Ces examens sont principalement <fnref n="12" /> effectués par le Labo-
ratoire National de Métrologie et d'Essais (LNE) <fnref n="13" />, et, dans
le cas de l'homologation, aboutissent à la délivrance d'un
certificat. Ces certificats sont trouvable sur le site du LNE,
souvent accompagnés d'annexes décrivant brièvement le
fonctionnement du système.

Les radars routiers sont soumis à une série de vérifica-
tions pour garantir l'exactitude de leurs mesures. Les pro-
cessus de vérification varient selon les pays d'Europe. Par
exemple, l'Allemagne se base sur de l'audit logiciel. En
France, ces vérifications sont effectuées dans le cadre de
l'examen d'homologation et reposent sur des essais réali-
sés sur le système final. Le but général des essais est de
garantir le bon fonctionnement des systèmes et le respect
des exigences réglementaires. Nous nous concentrons dans
cette analyse sur le cas français.

2.2.2 Les marges d'erreur définies par arrêté

L'arrêté du 4 juin 2009 relatif aux cinémomètres de contrôle routier [3], précise les modalités des examens dans le cas des radars de vitesse. Il contient un descriptif de l'examen d'homologation, qui comporte : un examen de conformité du dossier, des essais en laboratoire, dans les conditions de fonctionnement, des essais en fonctionnement réel dans des conditions normales d'utilisation sur route, ainsi que « des analyses de simulation pour les situations dangereuses qui ne peuvent être reproduites lors des essais sur route » (art. 9). La liste des essais minimaux à réaliser en laboratoire est également fournie. Parmi eux se trouvent notamment : la courbe d'erreurs en fonction de la vitesse, l'exactitude de la valeur des vitesses, des exigences sur les affichages, sur les tolérances en termes de température, d'humidité ou de choc (annexe III).

L'arrêté fourni, en outre, les exigences essentielles de
construction des cinémomètres, comme les erreurs maxi-
males tolérées sur les mesures de vitesses : 5 km/h pour des
vitesses inférieures à 100 km/h et 5% de la vitesse pour des
vitesses supérieures (art. 6). Ce 5 (km/h et %) est remplacé
par un 3 pour les appareils neufs fixes, 7 pour les appareils
neufs dans un véhicule en mouvement et 10 pour les ap-
pareils en service dans un véhicule en mouvement (art.5 et
6).

Les radars de franchissement, détectant si un véhicule ne
respecte pas l'arrêt à un feux rouge, sont soumis à une
réglementation différente : celle de l'arrêté du 18 janvier
2012 relatif à l'homologation des systèmes de contrôle au-

<footnote n="11">11. Voir les différents examens des radars sur le site de la sécurité rou-
tière: https://www.securite-routiere.gouv.fr/radars/
/fonctionnement-des-radars/verification-des-rad-
ars-de-vitesse</footnote>

<footnote n="12">12. Pour les radars de franchissements, seule l'homologation est réa-
lisée par le LNE, les autres vérifications sont menées par des agents
habilités des Centres d'Etudes Techniques de l'Equipement : https :
//www.securite-routiere.gouv.fr/radars/fonctionn-
ement-des-radars/verification-des-radars-de-fra-
nchissement-de-feux</footnote>

<footnote n="13">13. https://www.lne.fr/fr</footnote>

<footnote n="10">10. https://www.antai.gouv.fr/</footnote>
tomatisé de franchissement d'une signalisation lumineuse fixe ou clignotante [1]. Les examens nécessaires sont semblables à ceux des cinémomètres et détaillés dans l'article 3.

L'arrêté fourni la liste des spécifications techniques nécessaires à l'homologation de ces systèmes. Notamment, l'article 30 stipule qu'« aucune fausse détection n'est autorisée, ce qui signifie qu'aucun véhicule doit être contrôlé alors qu'il n'aurait pas dû l'être », et l'article 31 de rajouter que « le pourcentage maximum de non détection doit être inférieur ou égal à 10% ». De plus, « le pourcentage de plaques lisibles [...] doit être supérieur ou égal à 95% hors cas de masquage » (art. 35).

Ces exigences reflètent le choix de ne tolérer aucun faux positif, à savoir une infraction signalée à tort, même si cela conduirait à baisser le nombre de « vraies » infractions détectées. Toutefois, ces taux « s'applique[ent] à toute série [...] consécutive d'au moins 100 véhicules contrôlés par le système » (art. 31 et 35), ce qui ne suffit pas à garantir qu'aucune fausse détection n'est envoyée sur un grand nombre d'essais.

### 2.2.3 Une documentation complète sur la conception et le fonctionnement du système

L'arrêté de 2009 détaille la liste des pièces justificatives nécessaires à la demande d'homologation des cinémomètres, qui s'apparentent à des exigences de transparence. Ainsi, il est exigé de fournir : un projet de manuel d'utilisation, un carnet métrologique, le logiciel et ses documents ainsi que « le détail de la détermination d'un résultat et le calcul d'incertitude associé, les facteurs d'incertitude pris en compte et les limites imposées à certains paramètres » (art. 8). La liste des informations minimales que doit contenir le carnet métrologique est donnée en annexe II.

D'autres exigences de transparence sont stipulées par l'arrêté du 31 décembre 2001 [2], complétant le décret n° 2001-387 relatif au contrôle des instruments de mesure, qui stipule que la demande d'examen de type doit être accompagnée d'un dossier contenant : une notice explicative sur le fonctionnement de l'appareil, ses caractéristiques métrologiques, des plans de conception et de fabrication avec descriptions, les résultats des calculs de conception et des contrôles, la plaque d'identification et de poinçonnage, le plan de scellement (art. 5).

Ainsi, les exigences définies dans le cadre de l'homologation portent principalement sur la transparence et l'acès à l'information, notamment vis-à-vis de la communication aux laboratoires d'essais. Il n'est en effet pas vrai-ment question d'explicabilité. Les performances de l'appareil sont simplement vérifiés en terme de précision sur la vitesse par le biais du calcul d'incertitude de mesure. Si l'incertitude est suffisamment basse, l'homologation est approuvée sans explication supplémentaire. Ces exigences de transparence, pour chacun des acteurs, sont illustrées par les flèches vertes de la Figure 1.

Les exigences de transparence pour les radars classiques se rapprochent de la documentation technique et la notice d'utilisation exigées par le projet de règlement européen AI

Act.

# 3 Nouveaux dispositifs ceinture/ téléphone

## 3.1 Fonctionnement des nouveaux dispositifs

Aujourd'hui de nouveaux systèmes sont en cours de développement en France, et déjà déployés en Australie. Ils permettent, une fois placés sur le bord de la route, de détecter si un conducteur ne porte pas de ceinture de sécurité ou s'il téléphone au volant [32], des obligations explicitées par les articles R.412-1 et R.412-6-1 du Code de la route [?]. En effet, un dixième des accidents de la route sont dû à l'utilisation d'un téléphone au volant [21].

Ces nouveaux dispositifs ceinture/ téléphone utilisent des techniques d'apprentissage profond sur des réseaux neuronaux entraînés à partir d'images récoltées par des dispositifs tests aux alentours de Paris. Le système, une fois déployé, analyse les images des véhicules à partir du flux vidéo pour détecter les infractions. Si le système détecte une infraction, l'image est alors envoyée au Centre National de Traitement des infractions routières (CNT) à Rennes, où des officiers de police du Centre Automatisé de Constatation des Infractions Routières (CACIR) vérifient l'image et constatent l'infraction le cas échéant. La vérification humaine sert donc à valider l'existence de l'infraction à partir de l'image. Pour les radars d'excès de vitesse, cette validation n'est pas possible, car l'humain ne peut pas indépendamment vérifier la mesure de la vitesse. Il doit se fier entièrement à l'appareil. C'est l'appareil, non l'humain, qui constate l'excès de vitesse. Dans le cas des dispositifs ceinture/ téléphone, le système propose des candidats, mais c'est bien l'agent de police qui décidera *in fine* si une infraction est effectivement constatée. Le paramétrage du dispositif permettra d'ajuster la qualité des candidats envoyés selon des seuils de confiance. Plus le seuil de confiance est élevé, plus l'examen du vérificateur humain deviendra une pure formalité, soulevant des risques de biais d'automatisation.

L'article R.130-11 du Code de la route stipule que : « *Font foi jusqu'à preuve du contraire les constatations, effectuées par ou à partir des appareils de contrôle automatique ayant fait l'objet d'une homologation, relatives aux infractions sur : 1° Le port d'une ceinture de sécurité homologuée dès lors que le siège qu'il occupe en est équipé prévu [...] ; 2° L'usage du téléphone tenu en main [...]* ». Par conséquent, la constatation de l'officier de police du non port de la ceinture ou de l'utilisation du téléphone au volant à partir des images délivrées par le système est présumée juste. Dès lors, les conducteurs sanctionnés devront être en mesure de prouver qu'ils respectaient bien la législation s'ils veulent contester la décision. Cette présomption de justesse est silmilaire à celle utilisée pour les radars automatiques actuels, à la différence que c'est la décision humaine qui est supposée être juste, et non la décision automatisée du radar.

Le fonctionnement des dispositifs ceinture/ téléphone est illustré en Figure 2.
tomatisé de franchissement d'une signalisation lumineuse fixe ou clignotante [1]. Les examens nécessaires sont semblables à ceux des cinémomètres et détaillés dans l'article 3.

L'arrêté fourni la liste des spécifications techniques nécessaires à l'homologation de ces systèmes. Notamment, l'article 30 stipule qu'« aucune fausse détection n'est autorisée, ce qui signifie qu'aucun véhicule doit être contrôlé alors qu'il n'aurait pas dû l'être », et l'article 31 de rajouter que « le pourcentage maximum de non détection doit être inférieur ou égal à 10% ». De plus, « le pourcentage de plaques lisibles [...] doit être supérieur ou égal à 95% hors cas de masquage » (art. 35).

Ces exigences reflètent le choix de ne tolérer aucun faux positif, à savoir une infraction signalée à tort, même si cela conduirait à baisser le nombre de « vraies » infractions détectées. Toutefois, ces taux « s'applique[ent] à toute série [...] consécutive d'au moins 100 véhicules contrôlés par le système » (art. 31 et 35), ce qui ne suffit pas à garantir qu'aucune fausse détection n'est envoyée sur un grand nombre d'essais.

### 2.2.3 Une documentation complète sur la conception et le fonctionnement du système

L'arrêté de 2009 détaille la liste des pièces justificatives nécessaires à la demande d'homologation des cinémomètres, qui s'apparentent à des exigences de transparence. Ainsi, il est exigé de fournir : un projet de manuel d'utilisation, un carnet métrologique, le logiciel et ses documents ainsi que « le détail de la détermination d'un résultat et le calcul d'incertitude associé, les facteurs d'incertitude pris en compte et les limites imposées à certains paramètres » (art. 8). La liste des informations minimales que doit contenir le carnet métrologique est donnée en annexe II.

D'autres exigences de transparence sont stipulées par l'arrêté du 31 décembre 2001 [2], complétant le décret n° 2001-387 relatif au contrôle des instruments de mesure, qui stipule que la demande d'examen de type doit être accompagnée d'un dossier contenant : une notice explicative sur le fonctionnement de l'appareil, ses caractéristiques métrologiques, des plans de conception et de fabrication avec descriptions, les résultats des calculs de conception et des contrôles, la plaque d'identification et de poinçonnage, le plan de scellement (art. 5).

Ainsi, les exigences définies dans le cadre de l'homologation portent principalement sur la transparence et l'acès à l'information, notamment vis-à-vis de la communication aux laboratoires d'essais. Il n'est en effet pas vrai-ment question d'explicabilité. Les performances de l'appareil sont simplement vérifiés en terme de précision sur la vitesse par le biais du calcul d'incertitude de mesure. Si l'incertitude est suffisamment basse, l'homologation est approuvée sans explication supplémentaire. Ces exigences de transparence, pour chacun des acteurs, sont illustrées par les flèches vertes de la Figure 1.

Les exigences de transparence pour les radars classiques se rapprochent de la documentation technique et la notice d'utilisation exigées par le projet de règlement européen AI

Act.

# 3 Nouveaux dispositifs ceinture/ téléphone

## 3.1 Fonctionnement des nouveaux dispositifs

Aujourd'hui de nouveaux systèmes sont en cours de développement en France, et déjà déployés en Australie. Ils permettent, une fois placés sur le bord de la route, de détecter si un conducteur ne porte pas de ceinture de sécurité ou s'il téléphone au volant [32], des obligations explicitées par les articles R.412-1 et R.412-6-1 du Code de la route [?]. En effet, un dixième des accidents de la route sont dû à l'utilisation d'un téléphone au volant [21].

Ces nouveaux dispositifs ceinture/ téléphone utilisent des techniques d'apprentissage profond sur des réseaux neuronaux entraînés à partir d'images récoltées par des dispositifs tests aux alentours de Paris. Le système, une fois déployé, analyse les images des véhicules à partir du flux vidéo pour détecter les infractions. Si le système détecte une infraction, l'image est alors envoyée au Centre National de Traitement des infractions routières (CNT) à Rennes, où des officiers de police du Centre Automatisé de Constatation des Infractions Routières (CACIR) vérifient l'image et constatent l'infraction le cas échéant. La vérification humaine sert donc à valider l'existence de l'infraction à partir de l'image. Pour les radars d'excès de vitesse, cette validation n'est pas possible, car l'humain ne peut pas indépendamment vérifier la mesure de la vitesse. Il doit se fier entièrement à l'appareil. C'est l'appareil, non l'humain, qui constate l'excès de vitesse. Dans le cas des dispositifs ceinture/ téléphone, le système propose des candidats, mais c'est bien l'agent de police qui décidera *in fine* si une infraction est effectivement constatée. Le paramétrage du dispositif permettra d'ajuster la qualité des candidats envoyés selon des seuils de confiance. Plus le seuil de confiance est élevé, plus l'examen du vérificateur humain deviendra une pure formalité, soulevant des risques de biais d'automatisation.

L'article R.130-11 du Code de la route stipule que : « *Font foi jusqu'à preuve du contraire les constatations, effectuées par ou à partir des appareils de contrôle automatique ayant fait l'objet d'une homologation, relatives aux infractions sur : 1° Le port d'une ceinture de sécurité homologuée dès lors que le siège qu'il occupe en est équipé prévu [...]; 2° L'usage du téléphone tenu en main [...]* ». Par conséquent, la constatation de l'officier de police du non port de la ceinture ou de l'utilisation du téléphone au volant à partir des images délivrées par le système est présumée juste. Dès lors, les conducteurs sanctionnés devront être en mesure de prouver qu'ils respectaient bien la législation s'ils veulent contester la décision. Cette présomption de justesse est similaire à celle utilisée pour les radars automatiques actuels, à la différence que c'est la décision humaine qui est supposée être juste, et non la décision automatisée du radar.

Le fonctionnement des dispositifs ceinture/ téléphone est illustré en Figure 2.
<figure><img src="image_23.png" /><figcaption>FIGURE 1 – Fonctionnement des radars actuels (en noir) et exigences de transparence (en vert)</figcaption></figure>

<figure><img src="image_24.png" /><figcaption>FIGURE 2 – Fonctionnement des dispositifs ceinture/ téléphone (en noir) et exigences de transparence (en vert) et d'explicabilité (en bleu)</figcaption></figure>

## 3.2 Les nouveaux dispositifs soulèvent des questions nouvelles, notamment par rapport à l'explicabilité

### 3.2.1 Des modèles opaques d'apprentissage profond

La première différence concerne la technologie utilisée. Ici l'apprentissage profond renforce le nombre de paramètres et donc l'opacité du système. Alors que l'homologation des radars actuels ne requiert qu'une simple transparence du processus<fnref n="14" />, l'homologation des futurs dispositifs devra évoluer vers l'explicabilité.

En effet, la transparence totale d'un réseaux de neurones est peu utile : qui aimerait recevoir une liste de millions ou milliards de paramètres ? Une transparence partielle est toutefois possible et utile, par exemple en documentant la planification du processus de conception, les données et annotations utilisées, le type d'algorithme choisi, le processus d'apprentissage, les domaines d'usages, le protocole d'évaluation du modèle, les méthodes de gestion des cas d'erreurs, le maintien en condition opérationnelles... Tous ces éléments se retrouve dans le « Référentiel de certification de processus pour l'IA » [15] développé récemment par le LNE. Des exigences similaires figurent dans le projet de règlement européen *AI Act*, dans son annexe IV. Toutefois, le référentiel du LNE discute de la certification d'un processus et non du système en lui même. Or connaître les don-

nées d'entraînement et de test ne donne pas nécessairement d'information sur la performance globale du système, par exemple. On pourrait notamment souhaiter savoir si le dispositif de détection d'infractions est sujet à des biais qui pourraient compromettre son équité, tels que la détection plus facile de certaines infractions sur des types spécifiques de véhicules ou de morphologies.

Le problème pour les nouveaux systèmes est également plus complexe, car le même système doit gérer à la fois la détection des ceintures et des téléphones. Or, le problème ceinture/ téléphone est asymétrique : dans un cas, l'infraction est envoyée si un objet est détecté (le téléphone), dans l'autre, s'il ne l'est pas (la ceinture). Il est légitime de se demander si ces deux problèmes opposés ne requièrent pas des règles adaptées à chacun. Nous avons vu avec l'exemple des radars de vitesse et de franchissement que les exigences de précision visent à éviter les erreurs conduisant à accuser à tort le conducteur de dépasser la limite de vitesse ou de brûler un feu rouge (des faux positifs). Dans le cas ceinture/ téléphone, deux types d'erreurs peuvent être envisagés : les faux positifs, où l'objet est détecté alors qu'il n'est en réalité pas présent, et les faux négatifs où l'objet n'est pas détecté alors qu'il est présent. Dans le cas de la ceinture, l'erreur problématique où le conducteur est faussement accusé correspond à un faux négatif. En revanche, pour le téléphone, cette erreur se traduit par un faux positif. Les autres types d'erreurs, à savoir les faux positifs pour la

<footnote n="14">14. Voir Section 2.2.3</footnote>
<figure><img src="image_23.png" /><figcaption>FIGURE 1 – Fonctionnement des radars actuels (en noir) et exigences de transparence (en vert)</figcaption></figure>

<figure><img src="image_24.png" /><figcaption>FIGURE 2 – Fonctionnement des dispositifs ceinture/ téléphone (en noir) et exigences de transparence (en vert) et d'explicabilité (en bleu)</figcaption></figure>

## 3.2 Les nouveaux dispositifs soulèvent des questions nouvelles, notamment par rapport à l'explicabilité

### 3.2.1 Des modèles opaques d'apprentissage profond

La première différence concerne la technologie utilisée. Ici l'apprentissage profond renforce le nombre de paramètres et donc l'opacité du système. Alors que l'homologation des radars actuels ne requiert qu'une simple transparence du processus<fnref n="14" />, l'homologation des futurs dispositifs devra évoluer vers l'explicabilité.

En effet, la transparence totale d'un réseaux de neurones est peu utile : qui aimerait recevoir une liste de millions ou milliards de paramètres ? Une transparence partielle est toutefois possible et utile, par exemple en documentant la planification du processus de conception, les données et annotations utilisées, le type d'algorithme choisi, le processus d'apprentissage, les domaines d'usages, le protocole d'évaluation du modèle, les méthodes de gestion des cas d'erreurs, le maintien en condition opérationnelles... Tous ces éléments se retrouve dans le « Référentiel de certification de processus pour l'IA » [15] développé récemment par le LNE. Des exigences similaires figurent dans le projet de règlement européen *AI Act*, dans son annexe IV. Toutefois, le référentiel du LNE discute de la certification d'un processus et non du système en lui même. Or connaître les don-

nées d'entraînement et de test ne donne pas nécessairement d'information sur la performance globale du système, par exemple. On pourrait notamment souhaiter savoir si le dispositif de détection d'infractions est sujet à des biais qui pourraient compromettre son équité, tels que la détection plus facile de certaines infractions sur des types spécifiques de véhicules ou de morphologies.

Le problème pour les nouveaux systèmes est également plus complexe, car le même système doit gérer à la fois la détection des ceintures et des téléphones. Or, le problème ceinture/ téléphone est asymétrique : dans un cas, l'infraction est envoyée si un objet est détecté (le téléphone), dans l'autre, s'il ne l'est pas (la ceinture). Il est légitime de se demander si ces deux problèmes opposés ne requièrent pas des règles adaptées à chacun. Nous avons vu avec l'exemple des radars de vitesse et de franchissement que les exigences de précision visent à éviter les erreurs conduisant à accuser à tort le conducteur de dépasser la limite de vitesse ou de brûler un feu rouge (des faux positifs). Dans le cas ceinture/ téléphone, deux types d'erreurs peuvent être envisagés : les faux positifs, où l'objet est détecté alors qu'il n'est en réalité pas présent, et les faux négatifs où l'objet n'est pas détecté alors qu'il est présent. Dans le cas de la ceinture, l'erreur problématique où le conducteur est faussement accusé correspond à un faux négatif. En revanche, pour le téléphone, cette erreur se traduit par un faux positif. Les autres types d'erreurs, à savoir les faux positifs pour la

<footnote n="14">14. Voir Section 2.2.3</footnote>
ceinture et les faux négatifs pour le téléphone, peuvent être considérés comme importants pour le policier qui manque une infraction, mais semblent moins problématiques vis-à-vis des droits de la personne accusée. Compte tenu de la présomption de l'existence de l'infraction créée par l'article R.130-11 du Code de la route, on peut imaginer que le système sera paramétré pour éviter tout risque de fausse accusation, et que les opérateurs humains ne constateront l'infraction que si l'image signalée par le système ne laisse aucun doute. Mais si le système n'envoie que des images d'infractions manifestes, la vigilance du contrôleur humain diminuera, celui-ci devenant complaisant devant la performance quasi-infaillible de l'algorithme<fnref n="15" />.

### 3.2.2 Performance du système

L'homologation est le processus soulevant le plus de questions pour les nouveaux systèmes de détection de ceinture/ téléphone. En effet, elle reposait jusqu'à présent sur des essais réalisables grâce à la précision élevée des systèmes radars. Or, en moyenne, la précision est bien moindre sur les nouveaux dispositifs à base d'IA que sur les anciens : le taux d'erreur peut atteindre l'ordre du pourcentage, voire de la dizaine de pourcent. Ces différences rendent ces nouveaux produits plus difficilement certifiables par essais qui requièrent de passer plusieurs centaines de tests sans échouer.

Un autre problème technique concerne le calcul d'incertitude. Pour les anciens radars, cette incertitude est une incertitude de mesure : elle est liée à l'instrument de mesure qu'est le radar. Dans le cas des dispositifs ceinture/ téléphone, l'incertitude est liée au réseau de neurones. Pour calculer l'incertitude du modèle d'apprentissage, des statistiques sur la distribution prédictive sont souvent utilisées. Dans le cas de la classification, cette distribution est composée de probabilités de classe qui représentent intuitivement le degré de confiance dans un résultat [12].

De plus, les résultats des tests sont considérablement influencés par les conditions d'essai, ce qui peut entraîner des variations importantes de performance en fonction de facteurs tels que la météo, l'éclairage et l'angle de vue, là où avant ces écarts étaient négligeables.

La possibilité de paramétrer les dispositifs pour qu'ils n'envoient des images qu'en cas de confiance élevée sera déterminante pour mesurer la qualité du système. Les opérateurs humains devraient recevoir des images seulement de cas manifestes, où l'infraction sautent aux yeux.

Aujourd'hui, le LNE se penche sur un nouveau processus d'homologation pour ces dispositifs. Si les exigences exactes ne sont pas encore publiques, elles risquent fort de s'inspirer de leur « Référentiel de certification de processus pour l'IA » [15]. L'approche envisagée relèverait alors plus de la certification d'un algorithme, que de celle d'un système complet en conditions de déploiement. Or, l'évaluation d'un système doit tenir compte non seulement des données et paramètres d'entraînement, mais également du bon fonctionnement du contrôle humain [29].

### 3.2.3 Assurer la qualité du contrôle humain

Alors que les radars actuels sont entièrement automatisés, le nouveau système ceinture/ téléphone ne fait qu'envoyer une photo lorsque le modèle détecte une infraction mais laisse à l'officier de police la responsabilité de décider si oui ou non l'image représente bien une infraction. Ce processus d'humain dans la boucle<fnref n="16" /> est fondamental d'un point de vue légal aujourd'hui puisqu'il entraîne la responsabilité de l'individu qui prend la décision.

Néanmoins, les systèmes d'aide à la décision peuvent engendrer des biais chez les utilisateurs humains, surtout lorsque les recommandations générées par le système sont de très grande qualité. Si le système n'envoie que des images d'infractions manifestes, les humains deviendront moins vigilants, réduisant ainsi les bienfaits du contrôle humain. Ce phénomène conduit à des décisions qui ne sont humaines qu'en apparence et dissimulent une décision entièrement algorithmique. Pour autant, ce contrôle reste une garantie nécessaire selon la grande majorité des textes sur l'éthique algorithmique [22]. La Cour de Justice de l'Union Européenne exige un contrôle humain de chaque résultat algorithmique notamment dans le cadre de systèmes qui détectent des risques de terrorisme [14]. De plus, l'article 47 de la loi Informatique et Liberté (LIL) du 6 janvier 1978 [7] exclut l'utilisation de l'apprentissage machine pour des décisions entièrement automatisées de l'administration, ce qui rend indispensable un contrôle humain effectif de chaque décision.

## 4 Exigences de transparence et d'explicabilité pour l'IA

Nous avons montré que les nouveaux dispositifs ceinture/ téléphone sont très différents des radars classiques, ce qui peut nécessiter des exigences différentes de transparence et d'explicabilité. Mais qu'est-il aujourd'hui prévu dans la loi pour les systèmes d'IA ?

### 4.1 Code des Relations entre le Public et l'Administration

Le Code des Relations entre le Public et l'Administration (CRPA) impose un certain nombre d'obligations en matière de transparence lorsque l'administration prend une décision individuelle sur le fondement d'un traitement algorithmique<fnref n="17" />. D'une part, l'administration doit publier en ligne les règles définissant les principaux traitements utilisés dans l'accomplissement de ses missions lorsqu'ils fondent des décisions individuelles. D'autre part, l'administration doit communiquer à l'intéressé, à sa demande, les informations suivantes « 1° Le degré et le mode de contribution du traitement algorithmique à la prise de décision ; 2° Les données traitées et leurs sources ; 3° Les paramètres de traitement et, le cas échéant, leur pondération, appliqués à la situation de l'intéressé ; 4° Les opérations effectuées par le

<footnote n="15">15. Voir Section 3.2.3</footnote>

<footnote n="16">16. Ou *human-in-the-loop* en anglais.</footnote>

<footnote n="17">17. Pour le détail des exigences de transparence applicables aux algorithmes publics, voir le guide d'Etalab : https://etalab.github.io/algorithmes-publics/guide.html</footnote>
ceinture et les faux négatifs pour le téléphone, peuvent être considérés comme importants pour le policier qui manque une infraction, mais semblent moins problématiques vis-à-vis des droits de la personne accusée. Compte tenu de la présomption de l'existence de l'infraction créée par l'article R.130-11 du Code de la route, on peut imaginer que le système sera paramétré pour éviter tout risque de fausse accusation, et que les opérateurs humains ne constateront l'infraction que si l'image signalée par le système ne laisse aucun doute. Mais si le système n'envoie que des images d'infractions manifestes, la vigilance du contrôleur humain diminuera, celui-ci devenant complaisant devant la performance quasi-infaillible de l'algorithme<fnref n="15" />.

### 3.2.2 Performance du système

L'homologation est le processus soulevant le plus de questions pour les nouveaux systèmes de détection de ceinture/ téléphone. En effet, elle reposait jusqu'à présent sur des essais réalisables grâce à la précision élevée des systèmes radars. Or, en moyenne, la précision est bien moindre sur les nouveaux dispositifs à base d'IA que sur les anciens : le taux d'erreur peut atteindre l'ordre du pourcentage, voire de la dizaine de pourcent. Ces différences rendent ces nouveaux produits plus difficilement certifiables par essais qui requièrent de passer plusieurs centaines de tests sans échouer.

Un autre problème technique concerne le calcul d'incertitude. Pour les anciens radars, cette incertitude est une incertitude de mesure : elle est liée à l'instrument de mesure qu'est le radar. Dans le cas des dispositifs ceinture/ téléphone, l'incertitude est liée au réseau de neurones. Pour calculer l'incertitude du modèle d'apprentissage, des statistiques sur la distribution prédictive sont souvent utilisées. Dans le cas de la classification, cette distribution est composée de probabilités de classe qui représentent intuitivement le degré de confiance dans un résultat [12].

De plus, les résultats des tests sont considérablement influencés par les conditions d'essai, ce qui peut entraîner des variations importantes de performance en fonction de facteurs tels que la météo, l'éclairage et l'angle de vue, là où avant ces écarts étaient négligeables.

La possibilité de paramétrer les dispositifs pour qu'ils n'envoient des images qu'en cas de confiance élevée sera déterminante pour mesurer la qualité du système. Les opérateurs humains devraient recevoir des images seulement de cas manifestes, où l'infraction sautent aux yeux.

Aujourd'hui, le LNE se penche sur un nouveau processus d'homologation pour ces dispositifs. Si les exigences exactes ne sont pas encore publiques, elles risquent fort de s'inspirer de leur « Référentiel de certification de processus pour l'IA » [15]. L'approche envisagée relèverait alors plus de la certification d'un algorithme, que de celle d'un système complet en conditions de déploiement. Or, l'évaluation d'un système doit tenir compte non seulement des données et paramètres d'entraînement, mais également du bon fonctionnement du contrôle humain [29].

### 3.2.3 Assurer la qualité du contrôle humain

Alors que les radars actuels sont entièrement automatisés, le nouveau système ceinture/ téléphone ne fait qu'envoyer une photo lorsque le modèle détecte une infraction mais laisse à l'officier de police la responsabilité de décider si oui ou non l'image représente bien une infraction. Ce processus d'humain dans la boucle<fnref n="16" /> est fondamental d'un point de vue légal aujourd'hui puisqu'il entraîne la responsabilité de l'individu qui prend la décision.

Néanmoins, les systèmes d'aide à la décision peuvent engendrer des biais chez les utilisateurs humains, surtout lorsque les recommandations générées par le système sont de très grande qualité. Si le système n'envoie que des images d'infractions manifestes, les humains deviendront moins vigilants, réduisant ainsi les bienfaits du contrôle humain. Ce phénomène conduit à des décisions qui ne sont humaines qu'en apparence et dissimulent une décision entièrement algorithmique. Pour autant, ce contrôle reste une garantie nécessaire selon la grande majorité des textes sur l'éthique algorithmique [22]. La Cour de Justice de l'Union Européenne exige un contrôle humain de chaque résultat algorithmique notamment dans le cadre de systèmes qui détectent des risques de terrorisme [14]. De plus, l'article 47 de la loi Informatique et Liberté (LIL) du 6 janvier 1978 [7] exclut l'utilisation de l'apprentissage machine pour des décisions entièrement automatisées de l'administration, ce qui rend indispensable un contrôle humain effectif de chaque décision.

## 4 Exigences de transparence et d'explicabilité pour l'IA

Nous avons montré que les nouveaux dispositifs ceinture/ téléphone sont très différents des radars classiques, ce qui peut nécessiter des exigences différentes de transparence et d'explicabilité. Mais qu'est-il aujourd'hui prévu dans la loi pour les systèmes d'IA ?

### 4.1 Code des Relations entre le Public et l'Administration

Le Code des Relations entre le Public et l'Administration (CRPA) impose un certain nombre d'obligations en matière de transparence lorsque l'administration prend une décision individuelle sur le fondement d'un traitement algorithmique<fnref n="17" />. D'une part, l'administration doit publier en ligne les règles définissant les principaux traitements utilisés dans l'accomplissement de ses missions lorsqu'ils fondent des décisions individuelles. D'autre part, l'administration doit communiquer à l'intéressé, à sa demande, les informations suivantes « 1° Le degré et le mode de contribution du traitement algorithmique à la prise de décision ; 2° Les données traitées et leurs sources ; 3° Les paramètres de traitement et, le cas échéant, leur pondération, appliqués à la situation de l'intéressé ; 4° Les opérations effectuées par le

<footnote n="15">15. Voir Section 3.2.3</footnote>

<footnote n="16">16. Ou *human-in-the-loop* en anglais.</footnote>

<footnote n="17">17. Pour le détail des exigences de transparence applicables aux algorithmes publics, voir le guide d'Etalab : https://etalab.github.io/algorithmes-publics/guide.html</footnote>
traitement ». Ces informations doivent être communiquées
« sous une forme intelligible ».

Ces obligations soulèvent des questions particulières lors-
qu'il s'agit des systèmes de détection ceinture/ téléphone.
En premier lieu, la communication de l'image fondant l'in-
fraction est prévue par le CRPA qui permet un accès aux
documents administratifs. Mais l'exigence forte concerne
surtout la délivrance des « paramètres de traitements et,
le cas échéant, leur pondération, appliqués à la situation
de l'intéressé ». Dans le cadre de modèles d'apprentissage
profond ces paramètres peuvent correspondre par exemple
aux valeurs des poids du réseau de neurones ou encore aux
hyperparamètres d'apprentissage. Les paramètres de tra-
tement doivent correspondre à ceux appliqués à la situa-
tion de l'intéressé, donc les paramètres et les pondération
appliqués pour classifier l'image particulière de l'infrac-
tion. Cette exigence nécessiterait de préserver, pour chaque
image conduisant à une décision, une copie du modèle au
moment de la décision algorithmique, ainsi qu'une copie de
l'image, afin de permettre une réplicabilité de la décision.
La mention de « forme intelligible » suggère que les para-
mètres et leur pondération doivent être compréhensibles, ce
qui est loin d'être évident pour un modèle complexe.

## 4.2 Directive Police-Justice et la loi Informa-
tique et Liberté

Le dispositif ceinture/ téléphone constitue un traitement de données à caractère personnel à des fins de détection d'infractions pénales, ce qui relève des dispositions de la LIL qui transposent la Directive européenne « Police-Justice » 2016/680 du 27 avril 2016 [4]. S'agissant d'une nouvelle technologie, le dispositif ceinture/ téléphone nécessiterait probablement une analyse d'impact au titre de l'article 90 de la LIL, une analyse qui serait transmise à la CNIL. Dans le cadre de cette analyse, des obligations particulières de transparence et d'explicabilité du dispositif pourraient être identifiées comme étant nécessaires pour la protection des droits des personnes.

## 4.3 Projet de Règlement européen sur l'intel-
ligence artificielle AI Act

Le projet de règlement AI Act impose des obligations parti-
culières de transparence aux fournisseurs de systèmes d'IA
à haut risque. La liste des applications à haut risque (An-
nexe III du règlement) n'inclut pas explicitement des dispo-
sitifs de reconnaissance d'image non-biométriques, même
pour des applications répressives. Ainsi, en l'état actuel du
projet, le dispositif ceinture/ téléphone ne semble pas être
considéré comme étant une application à haut risque au re-
gard du futur règlement <fnref n="18" />. Ce dispositif ne tomberait pas

non plus dans la liste des applications interdites par le projet
de règlement, ou dans la liste des applications d'IA néces-
sitant des mesures de transparence particulières. Mais les
dispositions du projet sont susceptibles d'évoluer en fonc-
tion des négociations du texte.

5 Définir les besoins d'explicabilité
pour les dispositifs ceinture/ télé-
phone

Les dispositifs ceinture/ téléphone nécessitent des exigences d'explicabilité supplémentaires qui viennent s'ajouter aux exigences de transparence prévues pour les systèmes de radars actuels. Elles sont illustrées sur la Figure 2 par les flèches bleues. Dans cette section, nous détaillons ces besoins en explicabilité.

5.1 Les destinataires et les finalités des expli-
cations

Les mesures d'explicabilité doivent correspondre aux be-
soins de chaque public visé par l'explication. En effet, l'ex-
plicabilité doit être adaptée à la catégorie d'acteurs à la-
quelle elle s'adresse [26]. Il est possible de distinguer no-
tamment les experts des non-experts [36] car le niveau d'ex-
pertise de l'acteur peut influer sur sa capacité à comprendre
l'explication donnée [45]. Il faut alors trouver la juste me-
sure et adapter le niveau d'explicabilité à la situation don-
née et au niveau d'expertise de la personne concernée [10].
Un expert aura par exemple besoin d'une explication plus
en profondeur, avec un examen exhaustif du modèle qui
pourra être plus complexe. Au contraire, pour des non-
experts, l'explication pourra être plus brève, plus visuelle
et peu complexe, pour être facilement compréhensible.

Il est possible d'identifier plusieurs catégories d'acteurs,
telles que les créateurs, les opérateurs, les exécutants, les
personnes ciblées, et les examinateurs/ régulateurs [43]. De
même, il existe quatre raisons principales pour demander
une explication : pour justifier, pour contrôler, pour amélio-
rer, pour découvrir [8].

Nous souhaitons évaluer les besoins d'explicabilité pour
chacun des publics, pour les dispositifs ceinture/ téléphone.
Le premier public est constitué des personnes ciblées par la
décision. Celles-ci auront besoin d'informations pour éven-
tuellement contester la décision, et vérifier s'il ne s'agit pas
d'une erreur. Comme pour les radars classiques, la com-
munication de l'image pourrait suffire à démontrer que la
plaque d'immatriculation est fausse, ou à démontrer que
l'image est complètement floue et ne pourrait pas fonder
une constatation d'infraction. Au-delà de l'image, il est
difficile d'identifier l'utilité d'autres explications, et no-
tamment les paramètres et les pondérations prévues par le
CRPA. L'humain est capable de classifier une image issue
de la vie courante aussi bien qu'un ordinateur, indépendam-
ment de la compréhension des calculs de l'ordinateur. Pour
détecter une erreur de classification, l'image suffit donc.
Il ne s'agit alors plus d'une exigence d'explicabilité, mais
d'une simple vérification des données d'entrée.

<footnote n="18">18. L'Annexe III listant les systèmes à haut risque mentionne en 6.a « les systèmes d'IA destinés à être utilisés par les autorités répressives pour mener des évaluations individuelles des risques visant à déterminer la probabilité qu'une personne physique commette une infraction ou récidive, ou le risque encouru par les victimes potentielles d'infractions pénales ». Toutefois, nous considérons que notre cas d'usage ceinture/ téléphone ne rentre pas dans cette catégorie, car il ne constitue pas une évaluation des risques et ne calcule pas la probabilité d'un individu à commettre une infraction.</footnote>
traitement ». Ces informations doivent être communiquées
« sous une forme intelligible ».

Ces obligations soulèvent des questions particulières lors-
qu'il s'agit des systèmes de détection ceinture/ téléphone.
En premier lieu, la communication de l'image fondant l'in-
fraction est prévue par le CRPA qui permet un accès aux
documents administratifs. Mais l'exigence forte concerne
surtout la délivrance des « paramètres de traitements et,
le cas échéant, leur pondération, appliqués à la situation
de l'intéressé ». Dans le cadre de modèles d'apprentissage
profond ces paramètres peuvent correspondre par exemple
aux valeurs des poids du réseau de neurones ou encore aux
hyperparamètres d'apprentissage. Les paramètres de tra-
tement doivent correspondre à ceux appliqués à la situa-
tion de l'intéressé, donc les paramètres et les pondération
appliqués pour classifier l'image particulière de l'infrac-
tion. Cette exigence nécessiterait de préserver, pour chaque
image conduisant à une décision, une copie du modèle au
moment de la décision algorithmique, ainsi qu'une copie de
l'image, afin de permettre une réplicabilité de la décision.
La mention de « forme intelligible » suggère que les para-
mètres et leur pondération doivent être compréhensibles, ce
qui est loin d'être évident pour un modèle complexe.

## 4.2 Directive Police-Justice et la loi Informa-
tique et Liberté

Le dispositif ceinture/ téléphone constitue un traitement de données à caractère personnel à des fins de détection d'infractions pénales, ce qui relève des dispositions de la LIL qui transposent la Directive européenne « Police-Justice » 2016/680 du 27 avril 2016 [4]. S'agissant d'une nouvelle technologie, le dispositif ceinture/ téléphone nécessiterait probablement une analyse d'impact au titre de l'article 90 de la LIL, une analyse qui serait transmise à la CNIL. Dans le cadre de cette analyse, des obligations particulières de transparence et d'explicabilité du dispositif pourraient être identifiées comme étant nécessaires pour la protection des droits des personnes.

## 4.3 Projet de Règlement européen sur l'intel-
ligence artificielle AI Act

Le projet de règlement AI Act impose des obligations parti-
culières de transparence aux fournisseurs de systèmes d'IA
à haut risque. La liste des applications à haut risque (An-
nexe III du règlement) n'inclut pas explicitement des dispo-
sitifs de reconnaissance d'image non-biométriques, même
pour des applications répressives. Ainsi, en l'état actuel du
projet, le dispositif ceinture/ téléphone ne semble pas être
considéré comme étant une application à haut risque au re-
gard du futur règlement <fnref n="18" />. Ce dispositif ne tomberait pas

non plus dans la liste des applications interdites par le projet
de règlement, ou dans la liste des applications d'IA néces-
sitant des mesures de transparence particulières. Mais les
dispositions du projet sont susceptibles d'évoluer en fonc-
tion des négociations du texte.

5 Définir les besoins d'explicabilité
pour les dispositifs ceinture/ télé-
phone

Les dispositifs ceinture/ téléphone nécessitent des exigences d'explicabilité supplémentaires qui viennent s'ajouter aux exigences de transparence prévues pour les systèmes de radars actuels. Elles sont illustrées sur la Figure 2 par les flèches bleues. Dans cette section, nous détaillons ces besoins en explicabilité.

5.1 Les destinataires et les finalités des expli-
cations

Les mesures d'explicabilité doivent correspondre aux be-
soins de chaque public visé par l'explication. En effet, l'ex-
plicabilité doit être adaptée à la catégorie d'acteurs à la-
quelle elle s'adresse [26]. Il est possible de distinguer no-
tamment les experts des non-experts [36] car le niveau d'ex-
pertise de l'acteur peut influer sur sa capacité à comprendre
l'explication donnée [45]. Il faut alors trouver la juste me-
sure et adapter le niveau d'explicabilité à la situation don-
née et au niveau d'expertise de la personne concernée [10].
Un expert aura par exemple besoin d'une explication plus
en profondeur, avec un examen exhaustif du modèle qui
pourra être plus complexe. Au contraire, pour des non-
experts, l'explication pourra être plus brève, plus visuelle
et peu complexe, pour être facilement compréhensible.

Il est possible d'identifier plusieurs catégories d'acteurs,
telles que les créateurs, les opérateurs, les exécutants, les
personnes ciblées, et les examinateurs/ régulateurs [43]. De
même, il existe quatre raisons principales pour demander
une explication : pour justifier, pour contrôler, pour amélior-
rer, pour découvrir [8].

Nous souhaitons évaluer les besoins d'explicabilité pour
chacun des publics, pour les dispositifs ceinture/ téléphone.
Le premier public est constitué des personnes ciblées par la
décision. Celles-ci auront besoin d'informations pour éven-
tuellement contester la décision, et vérifier s'il ne s'agit pas
d'une erreur. Comme pour les radars classiques, la com-
munication de l'image pourrait suffire à démontrer que la
plaque d'immatriculation est fausse, ou à démontrer que
l'image est complètement floue et ne pourrait pas fonder
une constatation d'infraction. Au-delà de l'image, il est
difficile d'identifier l'utilité d'autres explications, et no-
tamment les paramètres et les pondérations prévues par le
CRPA. L'humain est capable de classifier une image issue
de la vie courante aussi bien qu'un ordinateur, indépendam-
ment de la compréhension des calculs de l'ordinateur. Pour
détecter une erreur de classification, l'image suffit donc.
Il ne s'agit alors plus d'une exigence d'explicabilité, mais
d'une simple vérification des données d'entrée.

<footnote n="18">18. L'Annexe III listant les systèmes à haut risque mentionne en 6.a « les systèmes d'IA destinés à être utilisés par les autorités répressives pour mener des évaluations individuelles des risques visant à déterminer la probabilité qu'une personne physique commette une infraction ou récidive, ou le risque encouru par les victimes potentielles d'infractions pénales ». Toutefois, nous considérons que notre cas d'usage ceinture/ téléphone ne rentre pas dans cette catégorie, car il ne constitue pas une évaluation des risques et ne calcule pas la probabilité d'un individu à commettre une infraction.</footnote>
Si la contestation concerne la légalité du système dans son
ensemble, la personne ciblée, ou bien une autorité de régul-
lation, pourrait souhaiter comprendre si le système souffre
de biais, par exemple un système qui privilégierait certains
types ou couleurs de voitures. Dans ce cas, le dispositif
pourrait violer le principe d'égalité devant la loi, conduis-
sant à son illégalité. De même, une explication pourrait per-
mettre de détecter certaines intentions malveillantes lors de
la conception de l'algorithme, par exemple des signes dis-
tinctifs qui permettraient d'éviter la détection de l'infrac-
tion.

Les agents de police qui constatent les infractions auront besoin également de l'image pour valider ou rejeter la re-commandation. L'image parlera d'elle-même la plupart du temps, l'agent n'ayant pas non plus besoin de comprendre les calculs du système pour savoir si l'image montre une infraction. Un explication visuelle pourrait consister à montrer la partie de l'image qui, selon l'ordinateur, caractériser l'infraction. Mais si l'image n'est pas claire quant à l'existence de l'infraction, l'agent ne pourra la constater.

Les images envoyées à tort à un agent humain seront en
principe détectées par l'agent. Il y aura donc une trace de
ces erreurs de classification, et leurs causes pourront être
étudiées. Le cas des infractions qui échappent à la détec-
tion sera plus difficile. Ces cas de non-détection ne se-
ront pas connus, et ne pourront pas être analysés avec des
outils d'explicabilité. Or, les systèmes de reconnaissance
d'images peuvent être trompés par l'ajout d'auto-collants
ou films destinés justement à changer la classification [18].
On peut donc s'attendre à l'émergence de stratagèmes pour
éviter des détections automatiques, à l'instar des dispositifs
anti-radars. Un modèle pourra évidemment apprendre à re-
connaître, et a éviter, ces stratagèmes anti-détection, s'ils
sont connus.

Les régulateurs, l'exploitant, les organismes de certification auront besoin d'informations sur la conception du système, les données d'entraînement, de test, et de validation. Les informations sur les seuils de confiance, le niveau toléré de faux positifs et de faux négatifs, les tests de biais, et les choix de mesures de réduction de biais, seront nécessaires pour apprécier la performance du système.

Même si les dispositions du futur règlement *AI Act* ne s'appliquaient pas au dispositif, les informations listées dans l'Annexe IV du projet de règlement seraient utiles voire nécessaires pour que les régulateurs, l'exploitant du système, et les organismes de certification puissent apprécier les forces et les faiblesses du dispositif.

## 5.2 Adapter la forme des explications au public visé

Il existe une multitude de solutions possibles pour expliquer
une image, mais ces dernières doivent être adaptées au pu-
blic visé. En effet il y a un « bon » niveau d'explication à
trouver pour chaque situation donnée [30]. De nombreuses
solutions techniques existent mais elles sont surtout adres-
sées à des spécialistes en IA, et pourraient détériorer la dé-
cision humaine au lieu d'aider si elles sont utilisées par des
non-experts [44].

Les cas d'erreurs peuvent être étudiés notamment par
l'utilisation d'outils d'explicabilité post-hoc, tels que
SHAP [27] ou LIME [38] qui permettent une vérification
rapide du point de focus de l'algorithme par la mise en
avant des pixels les plus importants pour la décision. Tou-
tefois, ces explications sont surtout destinées à des spécia-
listes en IA, elles seront plus difficiles à interpréter par des
non-experts comme l'exploitant ou l'agent de police. De la
même façon, pour aider à l'intelligibilité de la décision al-
gorithmique, une carte de chaleur <fnref n="19" /> peut montrer les parties
de l'image qui ont le plus contribué à la classification. Dif-
férentes techniques peuvent être utilisées pour générer de
telles explications : la descente de gradient comme la rétro-
propagation guidée [41] et la méthode Grad-CAM [40], ou
encore les études de sensibilité comme les méthodes d'oc-
clusion [46]. Les cartes de chaleur ont été critiquées car
elles échouent aux tests de randomisation <fnref n="20" /> et les explica-
tions sont donc indépendantes des données d'entraînement
et des paramètres du modèle [9]. Elles ont également ten-
dance à être similaires pour différentes prédictions [39]. Or,
ce que l'on recherche c'est une explication qui soit propre
à la fois à notre système et notre donnée d'entrée, pour re-
fléter la décision prise, plutôt qu'une explication générique.
En effet, on veut éviter d'avoir la même carte de chaleur
lorsqu'il y a une ceinture et lorsqu'il n'y en a pas. Les ex-
plications sous forme de carte de chaleur n'aident donc pas
forcément à prendre une décision. Elles peuvent toutefois
servir à détecter des erreurs évidentes, comme un focus de
l'algorithme ailleurs que sur la ceinture ou le téléphone.
Elles sont déjà couramment utilisées pour la détection de
biais dans les données, comme la présence de filigranes
(aussi appelés *watermarks*) sur les images [11].

Pour aider l'agent à détecter la présence de la ceinture ou
du téléphone, une simple boîte de délimitation (*bounding
box*) pourrait être utilisée. Mais ces méthodes, basées sur
la détection d'objets [37], seraient soit appliquées *a poste-
riori* et ne seraient alors pas représentatives de la décision
du modèle, soit nécessiteraient une refonte du modèle d'ap-
prentissage.

Pour comprendre une erreur sur un cas individuel, une
explication contre-factuelle <fnref n="21" /> pourrait également s'avérer
utile. Pour expliquer pourquoi une image appartient à une
certaine classe (par exemple, les classes « ceinture » ou
« sans ceinture », respectivement pour le téléphone), une
nouvelle image composite est générée à partir de l'image
de départ et de changements locaux [19]. Ces changements
sont les changements minimaux permettant de faire bascu-
ler l'image d'une classe à une autre. Cette catégorie d'ex-

<footnote n="19">19. Une carte de chaleur, ou saliency maps en anglais, se superpose aux pixels d'une image et la teinte selon leur importance dans la décision.</footnote>

<footnote n="20">20. Un test de randomisation consiste à réinitialiser aléatoirement les paramètres d'un modèle ou ses données d'entrée et d'observer l'effet sur la sortie de l'algorithme.</footnote>

<footnote n="21">21. Une explication contre-factuelle pose la question : « pourquoi pas ? » Elle permet de créer un cas imaginaire où la décision aurait été l'inverse et de voir quels éléments ont fait basculer cette décision. Par exemple dans le cas de la ceinture, on imagine qu'un contraste plus élevé entre les habits et la ceinture aurait permis de mieux distinguer : si le conducteur avait porté un t-shirt blanc, alors le système aurait détecté la ceinture.</footnote>
Si la contestation concerne la légalité du système dans son ensemble, la personne ciblée, ou bien une autorité de régulation, pourrait souhaiter comprendre si le système souffre de biais, par exemple un système qui privilégierait certains types ou couleurs de voitures. Dans ce cas, le dispositif pourrait violer le principe d'égalité devant la loi, conduisant à son illégalité. De même, une explication pourrait permettre de détecter certaines intentions malveillantes lors de la conception de l'algorithme, par exemple des signes distinctifs qui permettraient d'éviter la détection de l'infraction.

Les agents de police qui constatent les infractions auront besoin également de l'image pour valider ou rejeter la recommandation. L'image parlera d'elle-même la plupart du temps, l'agent n'ayant pas non plus besoin de comprendre les calculs du système pour savoir si l'image montre une infraction. Un explication visuelle pourrait consister à montrer la partie de l'image qui, selon l'ordinateur, caractériser l'infraction. Mais si l'image n'est pas claire quant à l'existence de l'infraction, l'agent ne pourra la constater.

Les images envoyées à tort à un agent humain seront en principe détectées par l'agent. Il y aura donc une trace de ces erreurs de classification, et leurs causes pourront être étudiées. Le cas des infractions qui échappent à la détection sera plus difficile. Ces cas de non-détection ne seront pas connus, et ne pourront pas être analysés avec des outils d'explicabilité. Or, les systèmes de reconnaissance d'images peuvent être trompés par l'ajout d'auto-collants ou films destinés justement à changer la classification [18]. On peut donc s'attendre à l'émergence de stratagèmes pour éviter des détections automatiques, à l'instar des dispositifs anti-radars. Un modèle pourra évidemment apprendre à reconnaître, et a éviter, ces stratagèmes anti-détection, s'ils sont connus.

Les régulateurs, l'exploitant, les organismes de certification auront besoin d'informations sur la conception du système, les données d'entraînement, de test, et de validation. Les informations sur les seuils de confiance, le niveau toléré de faux positifs et de faux négatifs, les tests de biais, et les choix de mesures de réduction de biais, seront nécessaires pour apprécier la performance du système.

Même si les dispositions du futur règlement *AI Act* ne s'appliquaient pas au dispositif, les informations listées dans l'Annexe IV du projet de règlement seraient utiles voire nécessaires pour que les régulateurs, l'exploitant du système, et les organismes de certification puissent apprécier les forces et les faiblesses du dispositif.

## 5.2 Adapter la forme des explications au public visé

Il existe une multitude de solutions possibles pour expliquer une image, mais ces dernières doivent être adaptées au public visé. En effet il y a un « bon » niveau d'explication à trouver pour chaque situation donnée [30]. De nombreuses solutions techniques existent mais elles sont surtout addressées à des spécialistes en IA, et pourraient détériorer la décision humaine au lieu d'aider si elles sont utilisées par des non-experts [44].

Les cas d'erreurs peuvent être étudiés notamment par l'utilisation d'outils d'explicabilité post-hoc, tels que SHAP [27] ou LIME [38] qui permettent une vérification rapide du point de focus de l'algorithme par la mise en avant des pixels les plus importants pour la décision. Toutefois, ces explications sont surtout destinées à des spécialistes en IA, elles seront plus difficiles à interpréter par des non-experts comme l'exploitant ou l'agent de police. De la même façon, pour aider à l'intelligibilité de la décision algorithmique, une carte de chaleur<fnref n="19" /> peut montrer les parties de l'image qui ont le plus contribué à la classification. Différentes techniques peuvent être utilisées pour générer de telles explications : la descente de gradient comme la rétropropagation guidée [41] et la méthode Grad-CAM [40], ou encore les études de sensibilité comme les méthodes d'occlusion [46]. Les cartes de chaleur ont été critiquées car elles échouent aux tests de randomisation<fnref n="20" /> et les explications sont donc indépendantes des données d'entraînement et des paramètres du modèle [9]. Elles ont également tendance à être similaires pour différentes prédictions [39]. Or, ce que l'on recherche c'est une explication qui soit propre à la fois à notre système et notre donnée d'entrée, pour refléter la décision prise, plutôt qu'une explication générique. En effet, on veut éviter d'avoir la même carte de chaleur lorsqu'il y a une ceinture et lorsqu'il n'y en a pas. Les explications sous forme de carte de chaleur n'aident donc pas forcément à prendre une décision. Elles peuvent toutefois servir à détecter des erreurs évidentes, comme un focus de l'algorithme ailleurs que sur la ceinture ou le téléphone. Elles sont déjà couramment utilisées pour la détection de biais dans les données, comme la présence de filigranes (aussi appelés *watermarks*) sur les images [11].

Pour aider l'agent à détecter la présence de la ceinture ou du téléphone, une simple boîte de délimitation (*bounding box*) pourrait être utilisée. Mais ces méthodes, basées sur la détection d'objets [37], seraient soit appliquées à *a posteriori* et ne seraient alors pas représentatives de la décision du modèle, soit nécessiteraient une refonte du modèle d'ap-prentissage.

Pour comprendre une erreur sur un cas individuel, une explication contre-factuelle<fnref n="21" /> pourrait également s'avérer utile. Pour expliquer pourquoi une image appartient à une certaine classe (par exemple, les classes « ceinture » ou « sans ceinture », respectivement pour le téléphone), une nouvelle image composite est générée à partir de l'image de départ et de changements locaux [19]. Ces changements sont les changements minimaux permettant de faire basculer l'image d'une classe à une autre. Cette catégorie d'ex-

<footnote n="19">19. Une carte de chaleur, ou saliency maps en anglais, se superpose aux pixels d'une image et la teinte selon leur importance dans la décision.</footnote>

<footnote n="20">20. Un test de randomisation consiste à réinitialiser aléatoirement les paramètres d'un modèle ou ses données d'entrée et d'observer l'effet sur la sortie de l'algorithme.</footnote>

<footnote n="21">21. Une explication contre-factuelle pose la question : « pourquoi pas ? » Elle permet de créer un cas imaginaire où la décision aurait été l'inverse et de voir quels éléments ont fait basculer cette décision. Par exemple dans le cas de la ceinture, on imagine qu'un contraste plus élevé entre les habits et la ceinture aurait permis de mieux distinguer : si le conducteur avait porté un t-shirt blanc, alors le système aurait détecté la ceinture.</footnote>
plication pourrait être utilisée par les agents de police pour
comprendre une décision sur un cas particulier.

Une explication à base de concepts 22 [34, 24, 23] permet-
trait peut-être de capturer des éléments comme la position
du corps ou de l'objet ceinture/ téléphone. Ce type d'expli-
cation sera plus évidente à interpréter pour un expert tentant
de comprendre le fonctionnement, et les erreurs, de l'al-
gorithme. Néanmoins, il est possible que ces méthodes ne
servent qu'à souligner la présence de l'objet, limitant ainsi
l'explication. Il en va de même pour les explications à base
de texte générées par des méthodes de captioning [20], qui
servent peu dans le cas d'une détection binaire.

Enfin, des méthodes utilisant des prototypes 23 [25] pour-
raient également servir à des experts pour comprendre le
comportement général d'un système mais sont peu convain-
cantes pour une décision individuelle.

# 6 Discussion et recommandations

Les nouveaux dispositifs ceinture/ téléphone utilisent des
algorithmes à base d'apprentissage profond, ce qui pose
la question de leur explicabilité. Ces dispositifs envoient
des images d'infractions à des agents de police, qui exa-
minent les images pour constater, ou non, une infraction.
Ces dispositifs de reconnaissance d'image n'ont pas les
mêmes performances techniques que les radars classiques,
et peuvent commettre des erreurs. Cependant, seules les
images ayant un taux de confiance élevé seront envoyées
aux agents. Ce type de dispositif est similaire dans son
fonctionnement à d'autres dispositifs de vidéo dits « intel-
ligents », tels que ceux qui seront expérimentés lors des
Jeux Olympiques de Paris en 2024. Ces dispositifs ont de
nombreux usages, comme la détection automatique d'in-
fractions, d'évènements « suspects » ou de colis abandon-
nés [13]. Ils peuvent également être utilisés dans le secteur
privé pour la sécurité des bâtiments, des banques, des ma-
gasins, etc. Le flux vidéo est alors pré-analysé par le sys-
tème d'IA et une alerte est levée lorsqu'un élément que le
système a été programmé à détecter est repéré. Ce fonc-
tionnement correspond, selon le projet de loi relatif aux
jeux Olympiques et Paralympiques de 2024, à un « signa-
lement d'attention » : « [les traitements algorithmiques] ne
produisent aucun autre résultat et ne peuvent fonder, par
eux-mêmes, aucune décision individuelle ni aucun acte de
poursuite. Ils demeurent en permanence sous le contrôle
des personnes chargées de leur mise en œuvre » (art. 7§6-
7) [31]. En cela, la situation relative au contrôle humain est
similaire pour ces systèmes de vidéo « intelligentes » que
pour les dispositifs de détection ceinture/ téléphone. Nos
conclusions seraient donc valables plus généralement pour
tout système s'appuyant sur la vérification humaine pour la
classification d'images.

Notre analyse des textes légaux, de la certification pour l'IA
de confiance et du processus envisagé pour les dispositifs de

détection ceinture/ téléphone nous amène à la conclusion
que les exigences détaillées d'explicabilité contenues dans
le CRPA ont peu d'intérêt pour la personne ciblée par une
décision dans la mesure où l'image parle pour elle-même,
et permet de détecter une erreur de classification.

Pour ces nouveaux dispositifs, il est nécessaire de réfléchir
en amont aux besoins en explicabilité pour adapter le niveau
de l'explication à la personne concernée et à l'objectif de
l'explication. Dans le cadre des nouveaux dispositifs cein-
ture/téléphone, nous avons identifié plusieurs publics ayant
des besoins différents d'explication. Pour les personnes ci-
blées, comme pour les agents en charge de constater les in-
fractions, une communication de l'image suffira en général
pour comprendre la classification. Contrairement à un score
de risque, par exemple, une image parle pour elle-même.

Pour les concepteurs, les exploitants, les régulateurs, et les
organismes de certification, les besoins en transparence et
en explicabilité seront plus élaborés. Ces acteurs souhai-
teront comprendre les classifications pour améliorer l'ef-
ficacité, l'équité, et la sécurité du système, et notamment
contrôler et corriger les biais dans le modèle, et les er-
reurs individuelles. Pour ce faire, la documentation tech-
nique prévue par l'Annexe IV du projet de règlement euro-
péen AI Act sera utile et, dans la plupart des cas, nécessaire.

Une approche qui se contenterait de communiquer les para-
mètres et leur pondération, et/ou les caractéristiques de don-
nées d'entraînement, serait peu utile. Différentes techniques
d'explicabilité individuelle - carte de chaleur, explications
contre-factuelles, explication à base de concepts - aideront
alors à comprendre les sources d'erreurs de classification.
Une image suffira à constater l'erreur; une explication in-
dividuelle sera nécessaire pour comprendre sa source.

Le concepteur et l'exploitant du système devront faire
des choix de performance - prioriser la réduction de faux
positifs par rapport aux faux négatifs; définir des seuils
de confiance. Ces choix devront faire l'objet de justifica-
tions particulières. Par exemple, si le système envoient des
images avec un taux de confiance d'au moins 98%, pour-
quoi ce niveau de pourcentage et pas un autre ? Si le concep-
teur a fait des choix pour concilier biais et performance,
comment justifier ces choix ? Si le système minimise les
faux positifs mais en échange laisse passer beaucoup de
faux négatifs, comment justifier cet équilibre ? Si le sys-
tème n'envoie que des images avec un taux de confiance
très élevé, comment lutter contre les biais humains liés à
l'automatisation ?

La CNCDH recommande « aux administrations de commu-
niquer sous une forme intelligible les informations sur le
fonctionnement de l'algorithme, ainsi que sur la part éven-
tuellement prise par une intervention humaine dans le pro-
cessus de décision. » (Recommandation 19) [16]. L'expli-
cation du processus n'est alors pas seulement l'explication
de la recommandation du système d'apprentissage mais de
l'entièreté de la chaîne de décision.

<footnote n="22">22. Une explication à base de concepts cherche les attributs de l'image qui pourraient faire basculer la décision. Par exemple, un zèbre est classifié ainsi par ces rayures. On pourrait imaginer ici rechercher un concept de ceinture ou de bras levé à l'oreille dans le cas du téléphone.</footnote>

<footnote n="23">23. Un prototype est une image "type" générée pour une classe donnée.</footnote>
plication pourrait être utilisée par les agents de police pour
comprendre une décision sur un cas particulier.

Une explication à base de concepts <fnref n="22" /> [34, 24, 23] permet-
trait peut-être de capturer des éléments comme la position
du corps ou de l'objet ceinture/ téléphone. Ce type d'expli-
cation sera plus évidente à interpréter pour un expert tentant
de comprendre le fonctionnement, et les erreurs, de l'al-
gorithme. Néanmoins, il est possible que ces méthodes ne
servent qu'à souligner la présence de l'objet, limitant ainsi
l'explication. Il en va de même pour les explications à base
de texte générées par des méthodes de captioning [20], qui
servent peu dans le cas d'une détection binaire.

Enfin, des méthodes utilisant des prototypes <fnref n="23" /> [25] pour-
raient également servir à des experts pour comprendre le
comportement général d'un système mais sont peu convain-
cantes pour une décision individuelle.

# 6 Discussion et recommandations

Les nouveaux dispositifs ceinture/ téléphone utilisent des
algorithmes à base d'apprentissage profond, ce qui pose
la question de leur explicabilité. Ces dispositifs envoient
des images d'infractions à des agents de police, qui exa-
minent les images pour constater, ou non, une infraction.
Ces dispositifs de reconnaissance d'image n'ont pas les
mêmes performances techniques que les radars classiques,
et peuvent commettre des erreurs. Cependant, seules les
images ayant un taux de confiance élevé seront envoyées
aux agents. Ce type de dispositif est similaire dans son
fonctionnement à d'autres dispositifs de vidéo dits « intel-
ligents », tels que ceux qui seront expérimentés lors des
Jeux Olympiques de Paris en 2024. Ces dispositifs ont de
nombreux usages, comme la détection automatique d'in-
fractions, d'évènements « suspects » ou de colis abandon-
nés [13]. Ils peuvent également être utilisés dans le secteur
privé pour la sécurité des bâtiments, des banques, des ma-
gasins, etc. Le flux vidéo est alors pré-analysé par le sys-
tème d'IA et une alerte est levée lorsqu'un élément que le
système a été programmé à détecter est repéré. Ce fonc-
tionnement correspond, selon le projet de loi relatif aux
jeux Olympiques et Paralympiques de 2024, à un « signa-
lement d'attention » : « [les traitements algorithmiques] ne
produisent aucun autre résultat et ne peuvent fonder, par
eux-mêmes, aucune décision individuelle ni aucun acte de
poursuite. Ils demeurent en permanence sous le contrôle
des personnes chargées de leur mise en œuvre » (art. 7§6-
7) [31]. En cela, la situation relative au contrôle humain est
similaire pour ces systèmes de vidéo « intelligentes » que
pour les dispositifs de détection ceinture/ téléphone. Nos
conclusions seraient donc valables plus généralement pour
tout système s'appuyant sur la vérification humaine pour la
classification d'images.

Notre analyse des textes légaux, de la certification pour l'IA
de confiance et du processus envisagé pour les dispositifs de

détection ceinture/ téléphone nous amène à la conclusion
que les exigences détaillées d'explicabilité contenues dans
le CRPA ont peu d'intérêt pour la personne ciblée par une
décision dans la mesure où l'image parle pour elle-même,
et permet de détecter une erreur de classification.

Pour ces nouveaux dispositifs, il est nécessaire de réfléchir
en amont aux besoins en explicabilité pour adapter le niveau
de l'explication à la personne concernée et à l'objectif de
l'explication. Dans le cadre des nouveaux dispositifs cein-
ture/téléphone, nous avons identifié plusieurs publics ayant
des besoins différents d'explication. Pour les personnes ci-
blées, comme pour les agents en charge de constater les in-
fractions, une communication de l'image suffira en général
pour comprendre la classification. Contrairement à un score
de risque, par exemple, une image parle pour elle-même.

Pour les concepteurs, les exploitants, les régulateurs, et les
organismes de certification, les besoins en transparence et
en explicabilité seront plus élaborés. Ces acteurs souhai-
teront comprendre les classifications pour améliorer l'ef-
ficacité, l'équité, et la sécurité du système, et notamment
contrôler et corriger les biais dans le modèle, et les er-
reurs individuelles. Pour ce faire, la documentation tech-
nique prévue par l'Annexe IV du projet de règlement euro-
péen AI Act sera utile et, dans la plupart des cas, nécessaire.

Une approche qui se contenterait de communiquer les para-
mètres et leur pondération, et/ou les caractéristiques de don-
nées d'entraînement, serait peu utile. Différentes techniques
d'explicabilité individuelle - carte de chaleur, explications
contre-factuelles, explication à base de concepts - aideront
alors à comprendre les sources d'erreurs de classification.
Une image suffira à constater l'erreur ; une explication in-
dividuelle sera nécessaire pour comprendre sa source.

Le concepteur et l'exploitant du système devront faire
des choix de performance - prioriser la réduction de faux
positifs par rapport aux faux négatifs; définir des seuils
de confiance. Ces choix devront faire l'objet de justifica-
tions particulières. Par exemple, si le système envoient des
images avec un taux de confiance d'au moins 98%, pour-
quoi ce niveau de pourcentage et pas un autre ? Si le concep-
teur a fait des choix pour concilier biais et performance,
comment justifier ces choix ? Si le système minimise les
faux positifs mais en échange laisse passer beaucoup de
faux négatifs, comment justifier cet équilibre ? Si le sys-
tème n'envoie que des images avec un taux de confiance
très élevé, comment lutter contre les biais humains liés à
l'automatisation ?

La CNCDH recommande « aux administrations de commu-
niquer sous une forme intelligible les informations sur le
fonctionnement de l'algorithme, ainsi que sur la part éven-
tuellement prise par une intervention humaine dans le pro-
cessus de décision. » (Recommandation 19) [16]. L'expli-
cation du processus n'est alors pas seulement l'explication
de la recommandation du système d'apprentissage mais de
l'entièreté de la chaîne de décision.

<footnote n="22">22. Une explication à base de concepts cherche les attributs de l'image qui pourraient faire basculer la décision. Par exemple, un zèbre est classifié ainsi par ces rayures. On pourrait imaginer ici rechercher un concept de ceinture ou de bras levé à l'oreille dans le cas du téléphone.</footnote>

<footnote n="23">23. Un prototype est une image "type" générée pour une classe donnée.</footnote>
# Remerciements

Cette recherche a été financée dans le cadre du projet LIM-PID 24 (Projet ANR 20-CE23-0028).

# Références

[1] Arrêté du 18 janvier 2012 relatif à l'homologation des systèmes de contrôle automatisé de franchissement d'une signalisation lumineuse fixe ou clignotante. NOR : DEVS1107065A.

[2] Arrêté du 31 décembre 2001 fixant les modalités d'application de certaines dispositions du décret n° 2001-387 du 3 mai 2001 relatif au contrôle des instruments de mesure. NOR : ECOI0200007A.

[3] Arrêté du 4 juin 2009 relatif aux cinémomètres de contrôle routier. NOR : ECEI0912713A.

[4] Directive (UE) 2016/680 du Parlement européen et du Conseil du 27 avril 2016 relative à la protection des personnes physiques à l'égard du traitement des données à caractère personnel par les autorités compétentes à des fins de prévention et de détection des infractions pénales, d'enquêtes et de poursuites en la matière ou d'exécution de sanctions pénales, et à la libre circulation de ces données, et abrogeant la décision-cadre 2008/977/JAI du Conseil. OJL 119.

[5] Décret n°2001-387 du 3 mai 2001 relatif au contrôle des instruments de mesure. NOR : ECOI0100116D.

[6] Loi n° 2003-495 du 12 juin 2003 renforçant la lutte contre la violence routière. NOR : EQUX0200012L.

[7] Loi n° 78-17 du 6 janvier 1978 relative à l'information, aux fichiers et aux libertés.

[8] Amina Adadi and Mohammed Berrada. Peeking Inside the Black-Box : A Survey on Explainable Artificial Intelligence (XAI). *IEEE Access*, 6 :52138–52160, 2018.

[9] Julius Adebayo, Justin Gilmer, Michael Muelly, Ian Goodfellow, Moritz Hardt, and Been Kim. Sanity Checks for Saliency Maps. *arXiv :1810.03292*, 2020.

[10] Valérie Beaudouin, Isabelle Bloch, David Bounie, Stéphan Clémençon, Florence d'Alché Buc, James Eagan, Winston Maxwell, Pavlo Mozharovskyi, and Jayneel Parekh. Flexible and Context-Specific AI Explainability : A Multidisciplinary Approach. *SSRN Electronic Journal*, 2020.

[11] Astrid Bertrand, Adam Pearce, and Nithum Thain. Searching for unintended biases with saliency. *PAIR Explorables*, 2022.

[12] Umang Bhatt, Javier Antorán, Yunfeng Zhang, Q. Vera Liao, Prasanna Sattigeri, Riccardo Fogliato, Gabrielle Melançon, Ranganath Krishnan, Jason Stanley, Omesh Tickoo, Lama Nachman, Rumi Chunara, Madhulika Srikumar, Adrian Weller, and Alice Xiang. Uncertainty as a Form of Transparency : Measuring, Communicating, and Using Uncertainty. In *Proceedings of the 2021 AAAI/ACM Conference on AI, Ethics, and Society*, pages 401–413, New York, NY, USA, 2021. Association for Computing Machinery.

[13] CNIL. Caméras dites « intelligentes » ou « augmentées » dans les espaces publics. Position sur les conditions de déploiement. Technical report, 2022.

[14] Cours de Justice de l'Union Européenne. Arrêt de la Cour (grande chambre) du 21 juin 2022, Ligue des droits humains contre Conseil des ministres, Affaire C-817/19.

[15] Laboratoire National de Métrologie et d'Essais (LNE). Référentiel de certification de processus pour l'IA - Conception, développement, évaluation et maintien en conditions opérationnelles, 2021.

[16] Commission Nationale Consultative des Droits de l'Homme(CNCDH). Avis relatif à l'impact de l'intelligence artificielle sur les droits fondamentaux. Technical report, 2022.

[17] Commission Européenne. Proposition de règlement du Parlement Européenn et du Conseil établissant des règles harmonisées concernant l'Intelligence Artificielle (législation sur l'Intelligence Artificielle) et modifiant certains actes législatifs de l'Union. COM/2021/206 final, April 2021.

[18] Kevin Eykholt, Ivan Evtimov, Earlence Fernandes, Bo Li, Amir Rahmati, Chaowei Xiao, Atul Prakash, Tadayoshi Kohno, and Dawn Song. Robust Physical-World Attacks on Deep Learning Visual Classification. In *2018 IEEE/CVF Conference on Computer Vision and Pattern Recognition*, pages 1625–1634, 2018.

[19] Yash Goyal, Ziyan Wu, Jan Ernst, Dhruv Batra, Devi Parikh, and Stefan Lee. Counterfactual Visual Explanations. 2019.

[20] Lisa Anne Hendricks, Zeynep Akata, Marcus Rohrbach, Jeff Donahue, Bernt Schiele, and Trevor Darrell. Generating Visual Explanations. *arXiv :1603.08507*, 2016.

[21] TF1 INFO. Excès de vitesse, pas de ceinture, téléphone au volant : gare aux nouveaux radars. JT 20h du 30 juillet 2021. URL : https://www.tflinf.o.fr/societe/autoroute-exces-de-vitesse-pas-de-ceinture-telephone-au-volant-rien-n-echappe-aux-nouveaux-radars-urbains-2192686.html.

[22] Anna Jobin, Marcello Ienca, and Effy Vayena. The global landscape of AI ethics guidelines. *Nature Machine Intelligence*, 1(9) :389–399, 2019.

[23] Dmitry Kazhdan, Botty Dimanov, Mateja Jamnik, Pietro Liò, and Adrian Weller. Now You See Me (CME) : Concept-based Model Extraction. *arXiv :2010.13233*, 2020.

[24] Been Kim, Martin Wattenberg, Justin Gilmer, Carrie Cai, James Wexler, Fernanda Viegas, and Rory

<footnote n="24">24. https://limpid.telecom-paris.fr/</footnote>
# Remerciements

Cette recherche a été financée dans le cadre du projet LIM-PID 24 (Projet ANR 20-CE23-0028).

# Références

[1] Arrêté du 18 janvier 2012 relatif à l'homologation des systèmes de contrôle automatisé de franchissement d'une signalisation lumineuse fixe ou clignotante. NOR : DEVS1107065A.

[2] Arrêté du 31 décembre 2001 fixant les modalités d'application de certaines dispositions du décret n° 2001-387 du 3 mai 2001 relatif au contrôle des instruments de mesure. NOR : ECOI0200007A.

[3] Arrêté du 4 juin 2009 relatif aux cinémomètres de contrôle routier. NOR : ECEI0912713A.

[4] Directive (UE) 2016/680 du Parlement européen et du Conseil du 27 avril 2016 relative à la protection des personnes physiques à l'égard du traitement des données à caractère personnel par les autorités compétentes à des fins de prévention et de détection des infractions pénales, d'enquêtes et de poursuites en la matière ou d'exécution de sanctions pénales, et à la libre circulation de ces données, et abrogeant la décision-cadre 2008/977/JAI du Conseil. OJL 119.

[5] Décret n°2001-387 du 3 mai 2001 relatif au contrôle des instruments de mesure. NOR : ECOI0100116D.

[6] Loi n° 2003-495 du 12 juin 2003 renforçant la lutte contre la violence routière. NOR : EQUX0200012L.

[7] Loi n° 78-17 du 6 janvier 1978 relative à l'information, aux fichiers et aux libertés.

[8] Amina Adadi and Mohammed Berrada. Peeking Inside the Black-Box : A Survey on Explainable Artificial Intelligence (XAI). *IEEE Access*, 6 :52138–52160, 2018.

[9] Julius Adebayo, Justin Gilmer, Michael Muelly, Ian Goodfellow, Moritz Hardt, and Been Kim. Sanity Checks for Saliency Maps. *arXiv :1810.03292*, 2020.

[10] Valérie Beaudouin, Isabelle Bloch, David Bounie, Stéphan Clémençon, Florence d'Alché Buc, James Eagan, Winston Maxwell, Pavlo Mozharovskyi, and Jayneel Parekh. Flexible and Context-Specific AI Explainability : A Multidisciplinary Approach. *SSRN Electronic Journal*, 2020.

[11] Astrid Bertrand, Adam Pearce, and Nithum Thain. Searching for unintended biases with saliency. *PAIR Explorables*, 2022.

[12] Umang Bhatt, Javier Antorán, Yunfeng Zhang, Q. Vera Liao, Prasanna Sattigeri, Riccardo Fogliato, Gabrielle Melançon, Ranganath Krishnan, Jason Stanley, Omesh Tickoo, Lama Nachman, Rumi Chunara, Madhulika Srikumar, Adrian Weller, and Alice Xiang. Uncertainty as a Form of Transparency : Measuring, Communicating, and Using Uncertainty. In *Proceedings of the 2021 AAAI/ACM Conference on AI, Ethics, and Society*, pages 401–413, New York, NY, USA, 2021. Association for Computing Machinery.

[13] CNIL. Caméras dites « intelligentes » ou « augmentées » dans les espaces publics. Position sur les conditions de déploiement. Technical report, 2022.

[14] Cours de Justice de l'Union Européenne. Arrêt de la Cour (grande chambre) du 21 juin 2022, Ligue des droits humains contre Conseil des ministres, Affaire C-817/19.

[15] Laboratoire National de Métrologie et d'Essais (LNE). Référentiel de certification de processus pour l'IA - Conception, développement, évaluation et maintien en conditions opérationnelles, 2021.

[16] Commission Nationale Consultative des Droits de l'Homme(CNCDH). Avis relatif à l'impact de l'intelligence artificielle sur les droits fondamentaux. Technical report, 2022.

[17] Commission Européenne. Proposition de règlement du Parlement Européenn et du Conseil établissant des règles harmonisées concernant l'Intelligence Artificielle (législation sur l'Intelligence Artificielle) et modifiant certains actes législatifs de l'Union. COM/2021/206 final, April 2021.

[18] Kevin Eykholt, Ivan Evtimov, Earlence Fernandes, Bo Li, Amir Rahmati, Chaowei Xiao, Atul Prakash, Tadayoshi Kohno, and Dawn Song. Robust Physical-World Attacks on Deep Learning Visual Classification. In *2018 IEEE/CVF Conference on Computer Vision and Pattern Recognition*, pages 1625–1634, 2018.

[19] Yash Goyal, Ziyan Wu, Jan Ernst, Dhruv Batra, Devi Parikh, and Stefan Lee. Counterfactual Visual Explanations. 2019.

[20] Lisa Anne Hendricks, Zeynep Akata, Marcus Rohrbach, Jeff Donahue, Bernt Schiele, and Trevor Darrell. Generating Visual Explanations. *arXiv :1603.08507*, 2016.

[21] TF1 INFO. Excès de vitesse, pas de ceinture, téléphone au volant : gare aux nouveaux radars. JT 20h du 30 juillet 2021. URL : https://www.tflinf.o.fr/societe/autoroute-exces-de-vitesse-pas-de-ceinture-telephone-au-volant-rien-n-echappe-aux-nouveaux-rads-urbains-2192686.html.

[22] Anna Jobin, Marcello Ienca, and Effy Vayena. The global landscape of AI ethics guidelines. *Nature Machine Intelligence*, 1(9) :389–399, 2019.

[23] Dmitry Kazhdan, Botty Dimanov, Mateja Jamnik, Pietro Liò, and Adrian Weller. Now You See Me (CME) : Concept-based Model Extraction. *arXiv :2010.13233*, 2020.

[24] Been Kim, Martin Wattenberg, Justin Gilmer, Carrie Cai, James Wexler, Fernanda Viegas, and Rory

<footnote n="24">24. https://limpid.telecom-paris.fr/</footnote>
Sayres. Interpretability Beyond Feature Attribution: Quantitative Testing with Concept Activation Vectors (TCAV). In *Proceedings of the 35th International Conference on Machine Learning*, pages 2668–2677. PMLR, 2018.

[25] Sunnie S. Y. Kim, Nicole Meister, Vikram V. Ramaswamy, Ruth Fong, and Olga Russakovsky. HIVE: Evaluating the Human Interpretability of Visual Explanations. arXiv:2112.03184, 2021.

[26] Alexandra Kirsch. Explain to whom? Putting the User in the Center of Explainable AI. In *Proceedings of the First International Workshop on Comprehensibility and Explanation in AI and ML 2017 co-located with 16th International Conference of the Italian Association for Artificial Intelligence (AI*IA 2017)*, Bari, Italy, 2017.

[27] Scott Lundberg and Su-In Lee. A Unified Approach to Interpreting Model Predictions. arXiv:1705.07874, 2017.

[28] Aymeric Poulain Maubant. Pour y voir plus clair sur les notions de transparence et d'explicabilité en IA, 2020. URL: https://medium.com/@AymericPM/pour-y-voir-plus-clair-sur-les-notions-de-transparence-et-dexplicability%3A9-en-ia-c0db2e96ae62.

[29] Winston Maxwell. *Le contrôle humain des systèmes algorithmiques - un regard critique sur l'exigence d'un "Humain dans la boucle"*. HDR, Université Paris 1 Panthéon-Sorbonne, 2022.

[30] Winston Maxwell, Valérie Beaudouin, Isabelle Bloch, David Bounie, Stéphan Clémençon, Florence d'Alché Buc, James Eagan, Pavlo Mozharovskyi, and Jayneel Parekh. Identifying the 'Right' Level of Explanation in a Given Situation. SSRN Electronic Journal, 2020.

[31] Assemblée Nationale. Projet de loi relatif aux jeux Olympiques et Paralympiques de 2024 et portant diverses autres dispositions, April 2023.

[32] Angélique Négroni. De redoutables radars urbains expérimentés, LE FIGARO, July 2021. URL: https://www.lefigaro.fr/actualite-france/de-redoutables-radars-urbains-experimentes-20210728.

[33] Independent Hight-Level Expert Group on Artificial Intelligence set up by the European Commission (HLEG). Ethics guidelines for trustworthy AI. Technical report, European Commission, 2019.

[34] Jayneel Parekh, Pavlo Mozharovskyi, and Florence d'Alché Buc. A Framework to Learn with Interpretation. arXiv:2010.09345, 2021.

[35] Xavier Pin. V° Circulation routière - Fasc. 102 : Circulation routière - Constatation des infractions routières. In *JurisClasseur Lois pénales spéciales*. 2019.

[36] Gabrielle Ras, Marcel van Gerven, and Pim Haselaer. Explanation Methods in Deep Learning : Users, Values, Concerns and Challenges. arXiv:1803.07517, 2018.

[37] Joseph Redmon, Santosh Divvala, Ross Girshick, and Ali Farhadi. You Only Look Once : Unified, Real-Time Object Detection, 2016. arXiv:1506.02640.

[38] Marco Tulio Ribeiro, Sameer Singh, and Carlos Gues-trin. "Why Should I Trust You?" : Explaining the Predictions of Any Classifier. arXiv:1602.04938, 2016.

[39] Cynthia Rudin. Stop Explaining Black Box Machine Learning Models for High Stakes Decisions and Use Interpretable Models Instead. arXiv:1811.10154, 2019.

[40] Ramprasaath R. Selvaraju, Michael Cogswell, Abhishek Das, Ramakrishna Vedantam, Devi Parikh, and Dhruv Batra. Grad-CAM : Visual Explanations from Deep Networks via Gradient-Based Localization. In *2017 IEEE International Conference on Computer Vision (ICCV)*, pages 618–626, 2017.

[41] Jost Tobias Springenberg, Alexey Dosovitskiy, Thomas Brox, and Martin Riedmiller. Striving for simplicity : The all convolutional net. arXiv:1412.6806, 2015.

[42] Catherine Tessier. Ethique et IA : analyse et discussion. In *Conférence Nationale en Intelligence Artificielle (CNIA)*, 2021.

[43] Richard Tomsett, Dave Braines, Dan Harborne, Alun Preece, and Supriyo Chakraborty. Interpretable to Whom? A Role-based Model for Analyzing Interpretable Machine Learning Systems. arXiv:1806.07552, 2018.

[44] Danding Wang, Qian Yang, Ashraf Abdul, and Brian Y. Lim. Designing Theory-Driven User-Centric Explainable AI. In *Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems*, CHI '19, pages 1–15, New York, NY, USA, 2019. Association for Computing Machinery.

[45] Xinru Wang and Ming Yin. Are Explanations Helpful? A Comparative Study of the Effects of Explanations in AI-Assisted Decision-Making. In *26th International Conference on Intelligent User Interfaces*, pages 318–328, New York, NY, USA, 2021. Association for Computing Machinery.

[46] Matthew D. Zeiler and Rob Fergus. Visualizing and Understanding Convolutional Networks. In David Fleet, Tomas Pajdla, Bernt Schiele, and Tinne Tuytelaars, editors, *Computer Vision – ECCV 2014*, Lecture Notes in Computer Science, pages 818–833. Springer International Publishing, 2014.
Sayres. Interpretability Beyond Feature Attribution: Quantitative Testing with Concept Activation Vectors (TCAV). In *Proceedings of the 35th International Conference on Machine Learning*, pages 2668–2677. PMLR, 2018.

[25] Sunnie S. Y. Kim, Nicole Meister, Vikram V. Ramaswamy, Ruth Fong, and Olga Russakovsky. HIVE: Evaluating the Human Interpretability of Visual Explanations. arXiv:2112.03184, 2021.

[26] Alexandra Kirsch. Explain to whom? Putting the User in the Center of Explainable AI. In *Proceedings of the First International Workshop on Comprehensibility and Explanation in AI and ML 2017 co-located with 16th International Conference of the Italian Association for Artificial Intelligence (AI*IA 2017)*, Bari, Italy, 2017.

[27] Scott Lundberg and Su-In Lee. A Unified Approach to Interpreting Model Predictions. arXiv:1705.07874, 2017.

[28] Aymeric Poulain Maubant. Pour y voir plus clair sur les notions de transparence et d'explicabilité en IA, 2020. URL: https://medium.com/@AymericPM/pour-y-voir-plus-clair-sur-les-notions-de-transparence-et-dexplicability%3A9-en-ia-c0db2e96ae62.

[29] Winston Maxwell. *Le contrôle humain des systèmes algorithmiques - un regard critique sur l'exigence d'un "Humain dans la boucle"*. HDR, Université Paris 1 Panthéon-Sorbonne, 2022.

[30] Winston Maxwell, Valérie Beaudouin, Isabelle Bloch, David Bounie, Stéphan Clémençon, Florence d'Alché Buc, James Eagan, Pavlo Mozharovskyi, and Jayneel Parekh. Identifying the 'Right' Level of Explanation in a Given Situation. SSRN Electronic Journal, 2020.

[31] Assemblée Nationale. Projet de loi relatif aux jeux Olympiques et Paralympiques de 2024 et portant diverses autres dispositions, April 2023.

[32] Angélique Négroni. De redoutables radars urbains expérimentés, LE FIGARO, July 2021. URL: https://www.lefigaro.fr/actualite-france/de-redoutables-radars-urbains-experimentes-20210728.

[33] Independent Hight-Level Expert Group on Artificial Intelligence set up by the European Commission (HLEG). Ethics guidelines for trustworthy AI. Technical report, European Commission, 2019.

[34] Jayneel Parekh, Pavlo Mozharovskyi, and Florence d'Alché Buc. A Framework to Learn with Interpretation. arXiv:2010.09345, 2021.

[35] Xavier Pin. V° Circulation routière - Fasc. 102 : Circulation routière - Constatation des infractions routières. In *JurisClasseur Lois pénales spéciales*. 2019.

[36] Gabrielle Ras, Marcel van Gerven, and Pim Haselaer. Explanation Methods in Deep Learning : Users, Values, Concerns and Challenges. arXiv:1803.07517, 2018.

[37] Joseph Redmon, Santosh Divvala, Ross Girshick, and Ali Farhadi. You Only Look Once : Unified, Real-Time Object Detection, 2016. arXiv:1506.02640.

[38] Marco Tulio Ribeiro, Sameer Singh, and Carlos Gues-trin. "Why Should I Trust You?" : Explaining the Predictions of Any Classifier. arXiv:1602.04938, 2016.

[39] Cynthia Rudin. Stop Explaining Black Box Machine Learning Models for High Stakes Decisions and Use Interpretable Models Instead. arXiv:1811.10154, 2019.

[40] Ramprasaath R. Selvaraju, Michael Cogswell, Abhishek Das, Ramakrishna Vedantam, Devi Parikh, and Dhruv Batra. Grad-CAM : Visual Explanations from Deep Networks via Gradient-Based Localization. In *2017 IEEE International Conference on Computer Vision (ICCV)*, pages 618–626, 2017.

[41] Jost Tobias Springenberg, Alexey Dosovitskiy, Thomas Brox, and Martin Riedmiller. Striving for simplicity : The all convolutional net. arXiv:1412.6806, 2015.

[42] Catherine Tessier. Ethique et IA : analyse et discussion. In *Conférence Nationale en Intelligence Artificielle (CNIA)*, 2021.

[43] Richard Tomsett, Dave Braines, Dan Harborne, Alun Preece, and Supriyo Chakraborty. Interpretable to Whom? A Role-based Model for Analyzing Interpretable Machine Learning Systems. arXiv:1806.07552, 2018.

[44] Danding Wang, Qian Yang, Ashraf Abdul, and Brian Y. Lim. Designing Theory-Driven User-Centric Explainable AI. In *Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems*, CHI '19, pages 1–15, New York, NY, USA, 2019. Association for Computing Machinery.

[45] Xinru Wang and Ming Yin. Are Explanations Helpful? A Comparative Study of the Effects of Explanations in AI-Assisted Decision-Making. In *26th International Conference on Intelligent User Interfaces*, pages 318–328, New York, NY, USA, 2021. Association for Computing Machinery.

[46] Matthew D. Zeiler and Rob Fergus. Visualizing and Understanding Convolutional Networks. In David Fleet, Tomas Pajdla, Bernt Schiele, and Tinne Tuytelaars, editors, *Computer Vision – ECCV 2014*, Lecture Notes in Computer Science, pages 818–833. Springer International Publishing, 2014.
# Automatisation de l'inspection de conteneurs maritimes : une preuve de concept

S. Tabti¹, F. Vallée¹, D. Poon Shu Han¹, M. Elion¹*, Y. Alouini¹

¹ Fieldbox, Quai Armand Lalande, Bordeaux, 33300

stabti@fieldbox.ai

## Résumé

Cet article présente une preuve de concept d'automatisation de l'inspection de conteneurs maritimes développée pour un client en Asie. Un modèle de détection de défauts (Yolov5) est entraîné sur des vidéos d'intérieur de conteneurs collectées grâce à un rover. Ce projet couvre toutes les étapes de développement d'un modèle d'IA, de l'exploitation d'un gros volume de données historiques, la définition d'un système d'acquisition de données adapté à une automatisation de l'inspection, à l'annotation des images et l'entraînement du modèle sur un jeu de données frugal.

## Mots-clés

Automatisation, inspection de conteneurs, détection de défauts, Yolov5, transfer learning.

## Abstract

This article presents a proof of concept developed for a client in Asia. It deals with automated visual inspection of shipping containers thanks to a deep learning model (Yolov5) trained to detect defects inside containers using videos collected by a rover. This project covered all the steps to build an AI model, from historic data exploration on a big set of pictures taken by container surveyors, defining a new data collection process adapted to future inspection automation, to image labeling and model training on a small dataset.

## Keywords

Automation, container inspection, defect detection, Yolov5, transfer learning.

## 1 Introduction

L'inspection de conteneurs maritimes est un défi logistique majeur [5]. En particulier, inspecter d'éventuels défauts sur les conteneurs est important pour leur maintenance et la prévention de dommages plus graves. A titre d'exemple, à Singapour, 500 conteneurs sont inspectés chaque jour, dont 30% comportent des défauts. L'inspection d'un conteneur peut prendre entre 5min (défauts mineurs) à 40min (défauts majeurs). Automatiser ce procédé grâce à des modèles de vision par ordinateur serait bénéfique, néanmoins cela est

complexe à plusieurs niveaux. Nous abordons dans cet article deux principaux verrous.

Le premier verrou consiste en l'absence d'un système de collecte de données adapté à cette automatisation. En effet, chez notre client, le procédé actuel implique qu'un camion porte-conteneur se gare dans une zone dédiée, qu'un inspecteur analyse l'extérieur, l'intérieur vide et les informations inscrites sur le conteneur. Puis, des photos des dommages observés sont prises à l'aide d'une tablette avec un point de vue très proche du défaut. Ce procédé est inadapté si on vise l'automatisation de la prise de vue et de la détection des défauts car les points de vues des photos sont trop hétérogènes et dépendent de l'inspecteur. Par la suite, l'inspecteur renseigne la localisation des défauts, leurs catégories, et émet si nécessaire des recommandations de nettoyage et de réparation sur une application.

Un second verrou concerne la variabilité des types de défauts à identifier qui sont plus d'une centaine et soumis à la norme ISO 9897 General Container Standard. Ceci implique plusieurs points. Premièrement, la constitution d'une base de données intégrant cette variété va demander un temps considérable. Ensuite, le niveau d'expertise requis pour l'annotation des images est tel qu'il sera nécessaire que des inspecteurs la prennent en charge, ce qui entraîne un investissement humain, en temps et financier. Enfin, plusieurs modèles d'Intelligence Artificielle (IA) seront nécessaires pour localiser et classifier les différents types de défauts. En effet, pour certains défauts un modèle de détection d'objets est pertinent mais pour d'autres, comme l'évaluation de la lisibilité d'informations inscrites sur les conteneurs, il faudrait faire de la reconnaissance de caractères puis des post-traitements.

Le développement d'une solution d'automatisation d'une telle envergure pour un client commence traditionnellement par un premier projet avec un périmètre réduit dit "preuve de concept" (ou POC pour Proof Of Concept). L'objet de cet article est de présenter ce POC mené entre fin 2021 et mi-2022. Nous commençons par un bref état de l'art en inspection de conteneurs en section 2. Puis, grâce à une exploration de données historiques, nous définissons une liste de défauts prioritaires pour ce POC en section 3. La section

<footnote>*Ce travail a été réalisé sur une période où M. Elion faisait partie de Fieldbox avant de rejoindre une autre entreprise.</footnote>
# Automatisation de l'inspection de conteneurs maritimes : une preuve de concept

S. Tabti¹, F. Vallée¹, D. Poon Shu Han¹, M. Elion¹*, Y. Alouini¹

¹ Fieldbox, Quai Armand Lalande, Bordeaux, 33300

stabti@fieldbox.ai

## Résumé

Cet article présente une preuve de concept d'automatisation de l'inspection de conteneurs maritimes développée pour un client en Asie. Un modèle de détection de défauts (Yolov5) est entraîné sur des vidéos d'intérieur de conteneurs collectées grâce à un rover. Ce projet couvre toutes les étapes de développement d'un modèle d'IA, de l'exploitation d'un gros volume de données historiques, la définition d'un système d'acquisition de données adapté à une automatisation de l'inspection, à l'annotation des images et l'entraînement du modèle sur un jeu de données frugal.

## Mots-clés

Automatisation, inspection de conteneurs, détection de défauts, Yolov5, transfer learning.

## Abstract

This article presents a proof of concept developed for a client in Asia. It deals with automated visual inspection of shipping containers thanks to a deep learning model (Yolov5) trained to detect defects inside containers using videos collected by a rover. This project covered all the steps to build an AI model, from historic data exploration on a big set of pictures taken by container surveyors, defining a new data collection process adapted to future inspection automation, to image labeling and model training on a small dataset.

## Keywords

Automation, container inspection, defect detection, Yolov5, transfer learning.

## 1 Introduction

L'inspection de conteneurs maritimes est un défi logistique majeur [5]. En particulier, inspecter d'éventuels défauts sur les conteneurs est important pour leur maintenance et la prévention de dommages plus graves. A titre d'exemple, à Singapour, 500 conteneurs sont inspectés chaque jour, dont 30% comportent des défauts. L'inspection d'un conteneur peut prendre entre 5min (défauts mineurs) à 40min (défauts majeurs). Automatiser ce procédé grâce à des modèles de vision par ordinateur serait bénéfique, néanmoins cela est

complexe à plusieurs niveaux. Nous abordons dans cet article deux principaux verrous.

Le premier verrou consiste en l'absence d'un système de collecte de données adapté à cette automatisation. En effet, chez notre client, le procédé actuel implique qu'un camion porte-conteneur se gare dans une zone dédiée, qu'un inspecteur analyse l'extérieur, l'intérieur vide et les informations inscrites sur le conteneur. Puis, des photos des dommages observés sont prises à l'aide d'une tablette avec un point de vue très proche du défaut. Ce procédé est inadapté si on vise l'automatisation de la prise de vue et de la détection des défauts car les points de vues des photos sont trop hétérogènes et dépendent de l'inspecteur. Par la suite, l'inspecteur renseigne la localisation des défauts, leurs catégories, et émet si nécessaire des recommandations de nettoyage et de réparation sur une application.

Un second verrou concerne la variabilité des types de défauts à identifier qui sont plus d'une centaine et soumis à la norme ISO 9897 General Container Standard. Ceci implique plusieurs points. Premièrement, la constitution d'une base de données intégrant cette variété va demander un temps considérable. Ensuite, le niveau d'expertise requis pour l'annotation des images est tel qu'il sera nécessaire que des inspecteurs la prennent en charge, ce qui entraîne un investissement humain, en temps et financier. Enfin, plusieurs modèles d'Intelligence Artificielle (IA) seront nécessaires pour localiser et classifier les différents types de défauts. En effet, pour certains défauts un modèle de détection d'objets est pertinent mais pour d'autres, comme l'évaluation de la lisibilité d'informations inscrites sur les conteneurs, il faudrait faire de la reconnaissance de caractères puis des post-traitements.

Le développement d'une solution d'automatisation d'une telle envergure pour un client commence traditionnellement par un premier projet avec un périmètre réduit dit "preuve de concept" (ou POC pour Proof Of Concept). L'objet de cet article est de présenter ce POC mené entre fin 2021 et mi-2022. Nous commençons par un bref état de l'art en inspection de conteneurs en section 2. Puis, grâce à une exploration de données historiques, nous définissons une liste de défauts prioritaires pour ce POC en section 3. La section

<footnote>*Ce travail a été réalisé sur une période où M. Elion faisait partie de Fieldbox avant de rejoindre une autre entreprise.</footnote>
4 décrit le système d'acquisition de données qui permettra à l'avenir l'automatisation de l'inspection de l'intérieur et de l'extérieur des conteneurs. En particulier, nous évoquons le choix des équipements, la campagne de collecte de données d'entraînement et leur annotation. Les images de défauts collectées étant trop peu nombreuses, le périmètre du projet a été réduit. En conséquence, le modèle de détection de défauts (localisation et classification) entraîné est dédié uniquement à l'intérieur des conteneurs et décrit en section 5. Pour conclure, nos retours d'expériences et perspectives sont partagés en section 6.

## 2 Bref état de l'art en inspection de conteneurs

Plusieurs solutions commerciales et travaux de recherche existent afin d'automatiser une partie du procédé d'inspection de conteneurs et ceci sur différents types de données. Par exemple, l'entreprise MEP propose un système où un camion chargé d'un conteneur passe dans un scanner à rayons X. Aucun modèle d'IA n'apparaît dans leur documentation. En revanche, plusieurs articles de recherche développent des modèles de classification pour déterminer si les conteneurs contiennent des armes ou des objets de contre-bande, ex : [1]. L'entreprise LASE, quant à elle, a proposé un système basé sur 3 capteurs lasers permettant d'obtenir un profil 3D d'un conteneur qui est analysé afin de détecter des défauts de surface.

En ce qui concerne l'analyse d'images, plusieurs solutions commerciales existent, ex : VISY et ProjAIX. À notre connaissance, ces dernières se focalisent sur la reconnaissance des caractères pour récupérer les informations inscrites sur les conteneurs et sur la détection de quelques défauts extérieurs. Cependant, elles ne permettent pas de classifier les défauts détectés. Plusieurs travaux de recherche, ex : [2], sont développés pour la détection de corrosion sur les conteneurs. D'autres proposent des modèles de classification d'un nombre limité de défauts. Par exemple, le modèle proposé dans [6] est entraîné sur une base de données de photographies de conteneurs avec des prises de vues très hétérogènes.

Le jeu de données mentionné dans [6] risque d'être peu adapté pour l'entraînement d'un modèle d'IA qui, une fois déployé, serait appliqué à des flux vidéos avec des points de vues très différents et potentiellement loin des défauts. Or c'est l'objectif que nous nous sommes fixé pour automatiser la prise de vue des images aussi bien que la détection de défauts. De plus, après la campagne de collecte de données, le périmètre de ce POC va se concentrer sur l'intérieur des conteneurs, peu traité dans la littérature. La localisation des défauts dans l'image sera garantie par un modèle de détection d'objets traçant des rectangles (bounding boxes) autour des défauts plutôt qu'un modèle de classification qui ne prédit qu'un label sans localisation.

<table><caption>TABLE 1 – Résumé des données historiques transmises par le client. Plus de cent types de défauts ont été recensés et plus de 180K images partagées. On rappelle que ces données sont inadaptées à l'automatisation proposée et donc inutilisées pour l'entraînement des futurs modèles.</caption><thead><tr><th>Catégorie</th><th>Porte</th><th>Extérieur</th><th>Intérieur</th><th>Inscriptions</th><th>Nettoyage</th></tr></thead><tbody><tr><td>#types de défauts</td><td>49</td><td>27</td><td>20</td><td>18</td><td>2</td></tr><tr><td>#images</td><td>52164</td><td>49045</td><td>66680</td><td>7176</td><td>11412</td></tr></tbody></table>

## 3 Exploration et analyse des données historiques

Plus d'une centaine de types de défauts de conteneurs existent et sont répartis entre les catégories suivantes : extérieur, intérieur, inscriptions et nettoyage. Afin de définir une liste de défauts sur lesquels se concentrer pour construire un premier modèle d'IA pour ce POC, une phase d'exploration et d'analyse de données historiques est menée. L'extrait d'archives de données de 2019 et 2020 transmis par le client comporte : 1/ des fichiers JSON avec pour chaque type de défaut les noms de fichiers des photos prises par les inspecteurs, 2/ les photos associées (plus de 90 Gigaoctets d'images). Analyser les fichiers JSON a permis d'avoir une vision globale de ces données résumée en tableau 1 et de calculer pour chaque catégorie le nombre de photos collectées en 2019 et en 2020 pour chaque type de défaut.

Il est important de séparer l'exploration des données datant de 2019 et de 2020 pour éviter un biais d'analyse dû au COVID qui a eu un fort impact sur les activités commerciales en Asie, et ceci même jusqu'à la fin du POC en 2022. L'analyse de ces graphes montre également que d'une année à une autre, ce ne sont pas nécessairement les mêmes types de défauts qui sont les plus récurrents. De plus, il y a un fort déséquilibre dans la répartition des défauts, ce qui doit être un point d'attention pour la modélisation afin d'éviter de favoriser uniquement les types de défauts majoritaires. La figure 1 illustre nos observations dans le cas de la distribution des principaux types de défauts d'intérieur de conteneurs et leur nettoyage.

L'analyse de ces graphes pour chaque catégorie (extérieur, intérieur, ... etc.) permet de se concentrer sur l'exploration d'images comportant les types de défauts au nombre d'occurrences les plus élevés en 2019, pour éviter le biais du COVID, et de ne conserver qu'une vingtaine de types de défauts importants aux yeux du client et dont on attend que la visibilité soit suffisante sur les données qui seront collectées avec le système d'acquisition décrit en section 4.

## 4 Système d'acquisition des données, collecte et labellisation

Pour la campagne de collecte de données menée entre Février et Mars 2022 et un potentiel déploiement futur de nos modèles d'IA sur des flux de données acquis automatiquement.
4 décrit le système d'acquisition de données qui permettra à l'avenir l'automatisation de l'inspection de l'intérieur et de l'extérieur des conteneurs. En particulier, nous évoquons le choix des équipements, la campagne de collecte de données d'entraînement et leur annotation. Les images de défauts collectées étant trop peu nombreuses, le périmètre du projet a été réduit. En conséquence, le modèle de détection de défauts (localisation et classification) entraîné est dédié uniquement à l'intérieur des conteneurs et décrit en section 5. Pour conclure, nos retours d'expériences et perspectives sont partagés en section 6.

## 2 Bref état de l'art en inspection de conteneurs

Plusieurs solutions commerciales et travaux de recherche existent afin d'automatiser une partie du procédé d'inspection de conteneurs et ceci sur différents types de données. Par exemple, l'entreprise MEP propose un système où un camion chargé d'un conteneur passe dans un scanner à rayons X. Aucun modèle d'IA n'apparaît dans leur documentation. En revanche, plusieurs articles de recherche développent des modèles de classification pour déterminer si les conteneurs contiennent des armes ou des objets de contre-bande, ex : [1]. L'entreprise LASE, quant à elle, a proposé un système basé sur 3 capteurs lasers permettant d'obtenir un profil 3D d'un conteneur qui est analysé afin de détecter des défauts de surface.

En ce qui concerne l'analyse d'images, plusieurs solutions commerciales existent, ex : VISY et ProjAIX. À notre connaissance, ces dernières se focalisent sur la reconnaissance des caractères pour récupérer les informations inscrites sur les conteneurs et sur la détection de quelques défauts extérieurs. Cependant, elles ne permettent pas de classifier les défauts détectés. Plusieurs travaux de recherche, ex : [2], sont développés pour la détection de corrosion sur les conteneurs. D'autres proposent des modèles de classification d'un nombre limité de défauts. Par exemple, le modèle proposé dans [6] est entraîné sur une base de données de photographies de conteneurs avec des prises de vues très hétérogènes.

Le jeu de données mentionné dans [6] risque d'être peu adapté pour l'entraînement d'un modèle d'IA qui, une fois déployé, serait appliqué à des flux vidéos avec des points de vues très différents et potentiellement loin des défauts. Or c'est l'objectif que nous nous sommes fixé pour automatiser la prise de vue des images aussi bien que la détection de défauts. De plus, après la campagne de collecte de données, le périmètre de ce POC va se concentrer sur l'intérieur des conteneurs, peu traité dans la littérature. La localisation des défauts dans l'image sera garantie par un modèle de détection d'objets traçant des rectangles (bounding boxes) autour des défauts plutôt qu'un modèle de classification qui ne prédit qu'un label sans localisation.

<table><caption>TABLE 1 – Résumé des données historiques transmises par le client. Plus de cent types de défauts ont été recensés et plus de 180K images partagées. On rappelle que ces données sont inadaptées à l'automatisation proposée et donc inutilisées pour l'entraînement des futurs modèles.</caption><thead><tr><th>Catégorie</th><th>Porte</th><th>Extérieur</th><th>Intérieur</th><th>Inscriptions</th><th>Nettoyage</th></tr></thead><tbody><tr><td>#types de défauts</td><td>49</td><td>27</td><td>20</td><td>18</td><td>2</td></tr><tr><td>#images</td><td>52164</td><td>49045</td><td>66680</td><td>7176</td><td>11412</td></tr></tbody></table>

## 3 Exploration et analyse des données historiques

Plus d'une centaine de types de défauts de conteneurs existent et sont répartis entre les catégories suivantes : extérieur, intérieur, inscriptions et nettoyage. Afin de définir une liste de défauts sur lesquels se concentrer pour construire un premier modèle d'IA pour ce POC, une phase d'exploration et d'analyse de données historiques est menée. L'extrait d'archives de données de 2019 et 2020 transmis par le client comporte : 1/ des fichiers JSON avec pour chaque type de défaut les noms de fichiers des photos prises par les inspecteurs, 2/ les photos associées (plus de 90 Gigaoctets d'images). Analyser les fichiers JSON a permis d'avoir une vision globale de ces données résumée en tableau 1 et de calculer pour chaque catégorie le nombre de photos collectées en 2019 et en 2020 pour chaque type de défaut.

Il est important de séparer l'exploration des données datant de 2019 et de 2020 pour éviter un biais d'analyse dû au COVID qui a eu un fort impact sur les activités commerciales en Asie, et ceci même jusqu'à la fin du POC en 2022. L'analyse de ces graphes montre également que d'une année à une autre, ce ne sont pas nécessairement les mêmes types de défauts qui sont les plus récurrents. De plus, il y a un fort déséquilibre dans la répartition des défauts, ce qui doit être un point d'attention pour la modélisation afin d'éviter de favoriser uniquement les types de défauts majoritaires. La figure 1 illustre nos observations dans le cas de la distribution des principaux types de défauts d'intérieur de conteneurs et leur nettoyage.

L'analyse de ces graphes pour chaque catégorie (extérieur, intérieur, ... etc.) permet de se concentrer sur l'exploration d'images comportant les types de défauts au nombre d'occurrences les plus élevés en 2019, pour éviter le biais du COVID, et de ne conserver qu'une vingtaine de types de défauts importants aux yeux du client et dont on attend que la visibilité soit suffisante sur les données qui seront collectées avec le système d'acquisition décrit en section 4.

## 4 Système d'acquisition des données, collecte et labellisation

Pour la campagne de collecte de données menée entre Février et Mars 2022 et un potentiel déploiement futur de nos modèles d'IA sur des flux de données acquis automatiquement.
<figure><img src="image_25.png" /><figcaption>FIGURE 1 – Distribution des types de défauts intérieurs de conteneurs. Les années 2019 et 2020 représentent les données historiques avec des photos prises par des inspecteurs. L'année 2022 représente la campagne de collecte de données sur le mois de Février servant à l'entraînement du modèle. On note un déséquilibre dans la répartition des types de défauts, des défauts majoritaires différents d'une année à l'autre, un fort impact du COVID en 2020 et un faible volume de données collectée en 2022.</figcaption></figure>

ment, nous avons mis en place un système d'acquisition de vidéos grâce à un ensemble de caméras de surveillance pour l'inspection de l'extérieur des conteneurs. Le modèle de caméra a été sélectionné avec soin en fonction de ses propriétés (résolution de 2K, Field Of View, auto-focus, ...etc.). Nous avons opté pour la marque Hikvision. La marque Axis est une très bonne option également. La configuration d'installation des caméras proposée en figure 2 garantit la visibilité des défauts avec peu de distorsions, tout en s'adaptant à la structure du site industriel. Les vidéos sont stockées sur un équipement de type NAS (Network Attached Storage), puis synchronisées à intervalles réguliers vers un espace de stockage cloud (type bucket) accessible à distance pour effectuer des tâches d'analyse et de modélisation.

<figure><img src="image_26.png" /><figcaption>FIGURE 2 – Schéma d'installation des caméras pour l'inspection de l'extérieur des conteneurs (vue du dessus d'un camion remorque porte-conteneur).</figcaption></figure>

Concernant l'équipement permettant d'acquérir semi-automatiquement des vidéos à l'intérieur des conteneurs, nous avons sélectionné pour ce POC le rover (drone rou-

<figure><img src="image_27.png" /><figcaption>FIGURE 3 – Recommandations de pilotage du rover pour maximiser la qualité et la visibilité des défauts collectés lors d'inspections de l'intérieur des conteneurs. À gauche : préconisations lorsque le rover est placé dans le conteneur et qu'il se déplace vers le fond de celui-ci. À droite : préconisations pour que le rover sorte sans être ébloui par la lumière extérieure.</figcaption></figure>

lant) DJI RoboMaster S1 d'une résolution de 2K. Le mode opératoire que nous avons mis en place est le suivant : un inspecteur ouvre la porte du conteneur, installe le rover à l'intérieur, puis le pilote en suivant le chemin que nous avons préconisé afin de maximiser la visibilité de tous les types de défauts. Pour cela, le rover avance tout droit en orientant la caméra vers le bas pour observer les défauts sur le plancher et en bas du conteneur. Arrivé au bout, il ne fait pas un tour sur lui même afin d'éviter un contre-jour provoqué par la lumière de l'extérieur. Il fait plutôt une marche arrière en pointant la caméra vers le haut pour observer les défauts sur le plafond et en haut du conteneur. Ce procédé est schématisé en figure 3. La carte SD du rover est régulièrement extraite par l'inspecteur pour télécharger les données sur un espace de stockage dans le cloud.

Au fur et à mesure de la phase de collecte de vidéos, les images les plus pertinentes pour la modélisation sont extraites et labellisées par des inspecteurs de conteneurs, vu le niveau d'expertise élevé requis pour cette tâche. Pour cela, l'outil open-source Label Studio leur a été mis à disposition et nous les avons formés à son utilisation. L'histogramme vert en fig.1 montre la distribution des défauts les plus récurrents collectés. Les activités commerciales en Asie étant toujours impactées par le COVID en 2022, un nombre insuffisant d'images pour la majorité des types de défauts furent effectivement collectées. Les défauts majoritaires concernant l'intérieur des conteneurs et leur nettoyage, nous avons réduit le périmètre du POC à l'entraînement d'un modèle de détection de 5 types de défauts sur les images du rover décrits en tableau 2.
<figure><img src="image_25.png" /><figcaption>FIGURE 1 – Distribution des types de défauts intérieurs de conteneurs. Les années 2019 et 2020 représentent les données historiques avec des photos prises par des inspecteurs. L'année 2022 représente la campagne de collecte de données sur le mois de Février servant à l'entraînement du modèle. On note un déséquilibre dans la répartition des types de défauts, des défauts majoritaires différents d'une année à l'autre, un fort impact du COVID en 2020 et un faible volume de données collectée en 2022.</figcaption></figure>

ment, nous avons mis en place un système d'acquisition de vidéos grâce à un ensemble de caméras de surveillance pour l'inspection de l'extérieur des conteneurs. Le modèle de caméra a été sélectionné avec soin en fonction de ses propriétés (résolution de 2K, Field Of View, auto-focus, ...etc.). Nous avons opté pour la marque Hikvision. La marque Axis est une très bonne option également. La configuration d'installation des caméras proposée en figure 2 garantit la visibilité des défauts avec peu de distorsions, tout en s'adaptant à la structure du site industriel. Les vidéos sont stockées sur un équipement de type NAS (Network Attached Storage), puis synchronisées à intervalles réguliers vers un espace de stockage cloud (type bucket) accessible à distance pour effectuer des tâches d'analyse et de modélisation.

<figure><img src="image_26.png" /><figcaption>FIGURE 2 – Schéma d'installation des caméras pour l'inspection de l'extérieur des conteneurs (vue du dessus d'un camion remorque porte-conteneur).</figcaption></figure>

Concernant l'équipement permettant d'acquérir semi-automatiquement des vidéos à l'intérieur des conteneurs, nous avons sélectionné pour ce POC le rover (drone rou-

<figure><img src="image_27.png" /><figcaption>FIGURE 3 – Recommandations de pilotage du rover pour maximiser la qualité et la visibilité des défauts collectés lors d'inspections de l'intérieur des conteneurs. À gauche : préconisations lorsque le rover est placé dans le conteneur et qu'il se déplace vers le fond de celui-ci. À droite : préconisations pour que le rover sorte sans être ébloui par la lumière extérieure.</figcaption></figure>

lant) DJI RoboMaster S1 d'une résolution de 2K. Le mode opératoire que nous avons mis en place est le suivant : un inspecteur ouvre la porte du conteneur, installe le rover à l'intérieur, puis le pilote en suivant le chemin que nous avons préconisé afin de maximiser la visibilité de tous les types de défauts. Pour cela, le rover avance tout droit en orientant la caméra vers le bas pour observer les défauts sur le plancher et en bas du conteneur. Arrivé au bout, il ne fait pas un tour sur lui même afin d'éviter un contre-jour provoqué par la lumière de l'extérieur. Il fait plutôt une marche arrière en pointant la caméra vers le haut pour observer les défauts sur le plafond et en haut du conteneur. Ce procédé est schématisé en figure 3. La carte SD du rover est régulièrement extraite par l'inspecteur pour télécharger les données sur un espace de stockage dans le cloud.

Au fur et à mesure de la phase de collecte de vidéos, les images les plus pertinentes pour la modélisation sont extraites et labellisées par des inspecteurs de conteneurs, vu le niveau d'expertise élevé requis pour cette tâche. Pour cela, l'outil open-source Label Studio leur a été mis à disposition et nous les avons formés à son utilisation. L'histogramme vert en fig.1 montre la distribution des défauts les plus récurrents collectés. Les activités commerciales en Asie étant toujours impactées par le COVID en 2022, un nombre insuffisant d'images pour la majorité des types de défauts furent effectivement collectées. Les défauts majoritaires concernant l'intérieur des conteneurs et leur nettoyage, nous avons réduit le périmètre du POC à l'entraînement d'un modèle de détection de 5 types de défauts sur les images du rover décrits en tableau 2.
<table><caption>TABLE 2 – Description des défauts d'intérieur de conteneurs sur lesquels Yolov5 a été entraîné et performances sur des images de test (TP : True Positives).</caption><thead><tr><td>Défaut</td><td>Description</td><td>TP</td></tr></thead><tbody><tr><td>FWA-DY</td><td>Plancher sale</td><td>0.72</td></tr><tr><td>LSR-DB</td><td>Débris sur anneau d'arrimage</td><td>0.18</td></tr><tr><td>PSC-DT</td><td>Tôle froissée</td><td>0.11</td></tr><tr><td>FPP-BR</td><td>Plancher abîmé</td><td>-</td></tr><tr><td>FWA-OS</td><td>Tâche d'huile sur le plancher</td><td>0.25</td></tr></tbody></table>

## 5 Détection de défauts avec Yolov5

Pour la détection de défauts à l'intérieur de conteneurs, le modèle Yolov5 (medium) développé par Ultralytics et préentraîné sur le dataset COCO a été utilisé. Alors que peu de travaux dédiés à la détection de défauts à l'intérieur de conteneurs sont proposés dans la littérature et que la majorité proposent des modèles de classification, notre choix s'est porté sur ce modèle de détection d'objets car la localisation des défauts dans les images et leur catégorisation est importante pour nos clients. De plus, l'inférence des modèles de type Yolo (ex : Yolov4 [3]) est très rapide, en particulier si on dispose d'une puissance de calcul adaptée. Un transfer learning a été appliqué pour spécialiser le modèle préentraîné aux données du client. Pour cela, les images acquises en Février 2022 ont été utilisées. On rappelle que le nombre total d'images pour chaque type de défauts est représenté en fig.1, en vert. Des images sans défauts (ou : background images) sont ajoutées à ce dataset à hauteur de 10% du nombre total d'images tel qu'il est recommandé par Ultralytics afin de réduire les faux positifs.

Le data splitting entre entraînement/validation (~ 80% des images) et test (~ 20% des images) a été réalisé de façon à éviter toute fuite de données menant à du sur-apprentissage (ex : ne pas intégrer des images extraites de la même vidéo dans le même split) et à maintenir la même distribution des types de défauts dans chaque split. De plus, pour pallier la frugalité et le déséquilibre du jeu de données (cf. fig. 1), nous avons généré 500 images par des opérations de base d'augmentation de données d'entraînement (flip horizontal, flip vertical, translations, changements de contraste). Au final, après nettoyage et augmentation, le jeu d'entraînement et de validation est composé d'un peu plus de 1600 images, ce qui est très faible. Le jeu de test est composé d'approximativement 300 images. L'optimiseur sélectionné est une descente de gradient stochastique, la taille des batchs est de 8 et le paramètre de label smoothing est fixé à 0.15 afin de limiter l'impact d'erreurs d'annotation par les inspecteurs. Le nombre d'epochs maximal est limité à 100.

Des métriques de performances du modèle sur des images de test sont présentées en dernière colonne du tableau 2. Il s'agit de TP (True Positives) par type de défaut normalisé par le nombre d'instances (nombre de boxes) correspondantes à ce type de défaut. Ces résultats sont pour

<figure><img src="image_28.png" /><figcaption>FIGURE 4 – Détections réussies sur des vidéos de test.</figcaption></figure>

la plupart faibles et paraissent corrélés au nombre d'images collectées par type de défaut. En effet, le nombre d'images est trop limité pour espérer des performances élevées (Ultralytics recommande au moins 1500 images par classe, ce dont nous sommes loin). Il faudrait que la campagne de collecte de données soit reconduite pour plus longtemps. Cependant, on rappelle que ce score dépend du seuil sur le degré de confiance pour la sélection de boxes candidates à la Non-Max Suppression et du seuil sur l'IoU (Intersection over Union). Le seuil par défaut de l'IoU à 0.45 n'est pas assez permissif, ce qui a pour conséquence d'observer aucun TP de FPP-BR. Un travail futur pour pousser plus loin l'analyse des résultats consisterait à développer un post-traitement permettant d'optimiser ces seuils. Ceci est encouragé par des détections prometteuses obtenues sur des vidéos de test, cf. quelques exemples en figure 4. On précise que lorsque le modèle doute, la classe background est prédite plutôt que d'autres classes.

En fin de projet, des tests en conditions réelles réalisés sur site sur des vidéos inédites ont satisfait le client. En revanche, ces tests nous ont permis d'observer un sur-apprentissage sur la classe la plus récurrente : FWA-DY. En effet, le modèle prédit trop souvent cette classe. Après investigation auprès des inspecteurs, nous avons réalisé que les critères de décision sur ce défaut n'étaient pas assez bien formalisés et variaient d'un inspecteur à un autre, ce qui a biaisé le modèle pour prédire plus souvent qu'il ne faut que le plancher est sale. Encourager les annotateurs à avoir des critères de décisions clairs et avoir un processus de révision des labels par un deuxième annotateur est une bonne pratique pour limiter ce type de biais.

## 6 Conclusion et perspectives

Cet article décrit un projet concret d'intelligence artificielle mené pour un client en Asie dans un temps limité. L'objectif est de développer une preuve de concept d'automatisation d'inspection de conteneurs maritimes. Pour cela, un système de prise de vue quasi-automatique de conteneurs chargés sur des camions a été mis en place. Un réseau de caméra permet l'inspection de l'extérieur, tandis qu'un rover permet l'inspection de l'intérieur. La
<table><caption>TABLE 2 – Description des défauts d'intérieur de conteneurs sur lesquels Yolov5 a été entraîné et performances sur des images de test (TP : True Positives).</caption><thead><tr><td>Défaut</td><td>Description</td><td>TP</td></tr></thead><tbody><tr><td>FWA-DY</td><td>Plancher sale</td><td>0.72</td></tr><tr><td>LSR-DB</td><td>Débris sur anneau d'arrimage</td><td>0.18</td></tr><tr><td>PSC-DT</td><td>Tôle froissée</td><td>0.11</td></tr><tr><td>FPP-BR</td><td>Plancher abîmé</td><td>-</td></tr><tr><td>FWA-OS</td><td>Tâche d'huile sur le plancher</td><td>0.25</td></tr></tbody></table>

# 5 Détection de défauts avec Yolov5

Pour la détection de défauts à l'intérieur de conteneurs, le modèle Yolov5 (medium) développé par Ultralytics et préentraîné sur le dataset COCO a été utilisé. Alors que peu de travaux dédiés à la détection de défauts à l'intérieur de conteneurs sont proposés dans la littérature et que la majorité proposent des modèles de classification, notre choix s'est porté sur ce modèle de détection d'objets car la localisation des défauts dans les images et leur catégorisation est importante pour nos clients. De plus, l'inférence des modèles de type Yolo (ex : Yolov4 [3]) est très rapide, en particulier si on dispose d'une puissance de calcul adaptée. Un transfer learning a été appliqué pour spécialiser le modèle préentraîné aux données du client. Pour cela, les images acquises en Février 2022 ont été utilisées. On rappelle que le nombre total d'images pour chaque type de défauts est représenté en fig.1, en vert. Des images sans défauts (ou : background images) sont ajoutées à ce dataset à hauteur de 10% du nombre total d'images tel qu'il est recommandé par Ultralytics afin de réduire les faux positifs.

Le data splitting entre entraînement/validation (~ 80% des images) et test (~ 20% des images) a été réalisé de façon à éviter toute fuite de données menant à du sur-apprentissage (ex : ne pas intégrer des images extraites de la même vidéo dans le même split) et à maintenir la même distribution des types de défauts dans chaque split. De plus, pour pallier la frugalité et le déséquilibre du jeu de données (cf. fig. 1), nous avons généré 500 images par des opérations de base d'augmentation de données d'entraînement (flip horizontal, flip vertical, translations, changements de contraste). Au final, après nettoyage et augmentation, le jeu d'entraînement et de validation est composé d'un peu plus de 1600 images, ce qui est très faible. Le jeu de test est composé d'approximativement 300 images. L'optimiseur sélectionné est une descente de gradient stochastique, la taille des batchs est de 8 et le paramètre de label smoothing est fixé à 0.15 afin de limiter l'impact d'erreurs d'annotation par les inspecteurs. Le nombre d'epochs maximal est limité à 100.

Des métriques de performances du modèle sur des images de test sont présentées en dernière colonne du tableau 2. Il s'agit de TP (True Positives) par type de défaut normalisé par le nombre d'instances (nombre de boxes) correspondantes à ce type de défaut. Ces résultats sont pour

<figure><img src="image_28.png" /><figcaption>FIGURE 4 – Détections réussies sur des vidéos de test.</figcaption></figure>

la plupart faibles et paraissent corrélés au nombre d'images collectées par type de défaut. En effet, le nombre d'images est trop limité pour espérer des performances élevées (Ultralytics recommande au moins 1500 images par classe, ce dont nous sommes loin). Il faudrait que la campagne de collecte de données soit reconduite pour plus longtemps. Cependant, on rappelle que ce score dépend du seuil sur le degré de confiance pour la sélection de boxes candidates à la Non-Max Suppression et du seuil sur l'IoU (Intersection over Union). Le seuil par défaut de l'IoU à 0.45 n'est pas assez permissif, ce qui a pour conséquence d'observer aucun TP de FPP-BR. Un travail futur pour pousser plus loin l'analyse des résultats consisterait à développer un post-traitement permettant d'optimiser ces seuils. Ceci est encouragé par des détections prometteuses obtenues sur des vidéos de test, cf. quelques exemples en figure 4. On précise que lorsque le modèle doute, la classe background est prédite plutôt que d'autres classes.

En fin de projet, des tests en conditions réelles réalisés sur site sur des vidéos inédites ont satisfait le client. En revanche, ces tests nous ont permis d'observer un sur-apprentissage sur la classe la plus récurrente : FWA-DY. En effet, le modèle prédit trop souvent cette classe. Après investigation auprès des inspecteurs, nous avons réalisé que les critères de décision sur ce défaut n'étaient pas assez bien formalisés et variaient d'un inspecteur à un autre, ce qui a biaisé le modèle pour prédire plus souvent qu'il ne faut que le plancher est sale. Encourager les annotateurs à avoir des critères de décisions clairs et avoir un processus de révision des labels par un deuxième annotateur est une bonne pratique pour limiter ce type de biais.

# 6 Conclusion et perspectives

Cet article décrit un projet concret d'intelligence artificielle mené pour un client en Asie dans un temps limité. L'objectif est de développer une preuve de concept d'automatisation d'inspection de conteneurs maritimes. Pour cela, un système de prise de vue quasi-automatique de conteneurs chargés sur des camions a été mis en place. Un réseau de caméra permet l'inspection de l'extérieur, tandis qu'un rover permet l'inspection de l'intérieur. La
campagne de collecte et d'annotation d'images nous a permis de constituer un jeu d'entraînement. Cependant, ce dernier étant d'un volume trop faible, le périmètre du projet à été réduit à la detection de 5 types de défauts à l'intérieur des conteneurs. Les performances du modèle Yolov5 sont améliorables mais encourageantes vu les résultats obtenus sur des vidéos de test.

Pour une prochaine phase commerciale, une campagne de collecte de données plus longue et une labellisation de meilleure qualité auront un impact positif sur les résultats. Cependant, le chemin est long pour l'automatisation de l'inspection de conteneurs. Plusieurs travaux sont envisagés, ex : d'autres types de défauts (intérieurs et extérieurs) doivent être intégrés, des post-traitements doivent être mis en place, les modèles développés doivent être déployés sur site et une application métier doit être développée pour faciliter le travail quotidien des inspecteurs. De plus, en fonction des temps d'inférence requis pour la détection de défauts, d'autres modèles peuvent être expérimentés. L'implémentation de Yolov5 par Ultralytics est satisfaisante pour ce POC mais d'autres implémentations avec des licences permettant une meilleure protection du code produit existent, ex : des transformers pour une détection d'objets interprétable [4] sont une bonne option.

## Remerciements

C. Collignon, R. Yang, K. Vaibhav, J. Budynek, A. Coutant, A. Cherifi, P. Oreistein, P. Chin, J. Sauer.

## Références

[1] M. Abdolshah, M. Teimouri, and R. Rahmani. Classification of X-ray images of shipping containers. *Expert Systems with Applications*, 77:57–65, 2017.

[2] Z. Bahrami, R. Zhang, T. Wang, and Z. Liu. An end-to-end framework for shipping container corrosion defect inspection. *IEEE Transactions on Instrumentation and Measurement*, 71:1–14, 2022.

[3] A. Bochkovskiy, C-Y. Wang, and H-Y. M. Liao. Yolov4: Optimal speed and accuracy of object detection. *arXiv preprint arXiv:2004.10934*, 2020.

[4] H. Chefer, S. Gur, and L. Wolf. Generic attention-model explainability for interpreting bi-modal and encoder-decoder transformers. In *Proceedings of the IEEE/CVF International Conference on Computer Vision (ICCV)*, pages 397–406, October 2021.

[5] N. Hoffmann, R. Stahlbock, and S. Voß. A decision model on the repair and maintenance of shipping containers. *Journal of Shipping and trade*, 5:1–21, 2020.

[6] Z. Wang, J. Gao, Q. Zeng, and Y. Sun. Multitype damage detection of container using CNN based on transfer learning. *Mathematical Problems in Engineering*, 2021:1–12, 2021.
campagne de collecte et d'annotation d'images nous a
permis de constituer un jeu d'entraînement. Cependant, ce
dernier étant d'un volume trop faible, le périmètre du projet
à été réduit à la detection de 5 types de défauts à l'intérieur
des conteneurs. Les performances du modèle Yolov5 sont
améliorables mais encourageantes vu les résultats obtenus
sur des vidéos de test.

Pour une prochaine phase commerciale, une campagne de
collecte de données plus longue et une labellisation de
meilleure qualité auront un impact positif sur les résul-
tats. Cependant, le chemin est long pour l'automatisation
de l'inspection de conteneurs. Plusieurs travaux sont envi-
sagés, ex : d'autres types de défauts (intérieurs et extérieurs)
doivent être intégrés, des post-traitements doivent être mis
en place, les modèles développés doivent être déployés sur
site et une application métier doit être développée pour fa-
ciliter le travail quotidien des inspecteurs. De plus, en fonc-
tion des temps d'inférence requis pour la détection de dé-
fauts, d'autres modèles peuvent être expérimentés. L'implé-
mentation de Yolov5 par Ultralytics est satisfaisante pour ce
POC mais d'autres implémentations avec des licences per-
mettant une meilleure protection du code produit existent,
ex : des transformers pour une détection d'objets interpré-
table [4] sont une bonne option.

Remerciements

C. Collignon, R. Yang, K. Vaibhav, J. Budynek, A. Coutant, A. Cherifi, P. Oreistein, P. Chin, J. Sauer.

Références

[1] M. Abdolshah, M. Teimouri, and R. Rahmani. Classification of X-ray images of shipping containers. *Expert Systems with Applications*, 77:57-65, 2017.

[2] Z. Bahrami, R. Zhang, T. Wang, and Z. Liu. An end-to-end framework for shipping container corrosion defect inspection. *IEEE Transactions on Instrumentation and Measurement*, 71:1-14, 2022.

[3] A. Bochkovskiy, C-Y. Wang, and H-Y. M. Liao. Yolov4: Optimal speed and accuracy of object detection. *arXiv preprint arXiv:2004.10934*, 2020.

[4] H. Chefer, S. Gur, and L. Wolf. Generic attention-model explainability for interpreting bi-modal and encoder-decoder transformers. In *Proceedings of the IEEE/CVF International Conference on Computer Vision (ICCV)*, pages 397–406, October 2021.

[5] N. Hoffmann, R. Stahlbock, and S. Voß. A decision model on the repair and maintenance of shipping containers. *Journal of Shipping and trade*, 5:1-21, 2020.

[6] Z. Wang, J. Gao, Q. Zeng, and Y. Sun. Multitype damage detection of container using CNN based on transfer learning. *Mathematical Problems in Engineering*, 2021:1-12, 2021.
Session 4 : Modélisation
Session 4 : Modélisation
# Les registres de la Comédie-Française sur le Web de données liées :
de l'hétérogénéité de données vers des données quantitatives en RDF

Charline Granger<fnref n="1" />, Fabien Amarger²

¹Université Paris Nanterre, 200 avenue de la République, Nanterre, France
charline.granger@yahoo.com

²Logilab, 104 avenue Auguste Blanqui, Paris, France
fabien.amarger@logilab.fr

## Résumé

La Comédie-Française est une troupe de théâtre née de la volonté centralisatrice de Louis XIV en 1680 : troupe au statut ambigu, elle est pensionnée par le roi, mais fonctionne aussi comme une entreprise privée, dont les sociétaires se partagent les parts. Pour administrer ce partage et permettre le contrôle du pouvoir royal, les comédiens de la compagnie produisent dès sa fondation des registres journaliers, partiellement manuscrits, où ils consignent les recettes et les dépenses. Ces archives comptables sont uniques en leur genre par leur densité et leur continuité, puisque les registres ont été tenus à jour quotidiennement par les membres de la compagnie. Ces données sont particulièrement importantes pour comprendre la vie théâtrale de l'époque. Il n'y a actuellement pas d'autre moyen pour étudier ces registres que de les analyser manuellement, c'est pourquoi le programme de recherche des Registres de la Comédie-Française (RCF) a initié leur transcription et la constitution de bases de données, pour en faciliter l'étude. Ici, nous nous intéressons à la transcription des données des dépenses, qui sont particulièrement hétérogènes. La seconde partie de notre proposition porte sur l'alignement de ces données des dépenses sur les données transcrites antérieurement, qui proviennent des registres des recettes et des feux. L'objectif est de publier toutes ces données dans un même entrepôt SPARQL, afin de permettre des analyses quantitatives transversales.

## Mots-clés

archives, history of theatre, ontology, Linked Open Data, Digital Humanities

## 1 Introduction

La Comédie-Française est une troupe de théâtre née de la volonté centralisatrice de Louis XIV en 1680 : troupe au statut ambigu, elle est pensionnée par le roi, mais fonctionne aussi comme une entreprise privée, dont les sociétaires se partagent les parts. Pour administrer ce partage et permettre le contrôle du pouvoir royal, les comédiens de la compagnie produisent dès sa fondation des registres journaliers, partiellement manuscrits, où ils consignent les recettes et les dépenses. Ces archives comptables sont uniques en leur genre par leur densité et leur continuité, puisque ces

registres ont été tenus à jour quotidiennement jusqu'aujourd'hui par les membres de la troupe.

Afin de donner accès à cette archive précieuse, un programme de recherche international bilingue, le programme des Registres de la Comédie-Française<fnref n="1" /> [4] a été fondé il y a une dizaine d'années[1]. Il regroupe la Comédie-Française et plusieurs Universités : Paris Nanterre, Sorbonne Université, l'Université de Rouen Normandie, l'Université de Victoria (Canada), New York University et le Massachusetts Institute of Technology. Ce programme a d'abord été consacré à la création d'une base de données concernant les recettes journalières de la troupe entre 1680 et 1793, ce qui représente 113 saisons et plus de 30 000 soi-rées programmées : les registres de recettes donnent accès à la programmation (habituellement deux pièces par soi-rée) et au nombre de billets vendus par catégorie de place. Deux bases de données relationnelles ont ainsi été créées : d'une part, la base de données des recettes, qui associe à une date de représentation les titres des pièces jouées ce soir-là, les noms de leurs auteurs et le genre dramatique auquel elles ressortissent; d'autre part, la base des "feux" (distribution par représentation), qui associe, sur la période 1765-1793, une date de représentation à des noms d'acteurs et d'actrices, eux-mêmes associés aux rôles qu'ils ont tenus ce soir-là, rôles auxquels est rattachée une pièce, un auteur et un genre.

L'enjeu pour nous, aujourd'hui, est de créer une troisième base de données, la base de données des dépenses de la troupe de 1680 à 1776, complémentaire de celle des recettes et des feux. Parallèlement à ce travail, nous créons un dépôt RDF de l'ensemble de nos jeux de données, pour les rendre ouvertes et permettre une liberté de représentation que n'autorisent pas les bases de données relationnelles. [La société Logilab, en tant que prestataire informatique, a en charge la réalisation technique de ces deux chantiers.] Car là est le défi pour nous : rendre compte de manière la plus fidèle possible de données partiellement irrégulières. Pour cela, nous présenterons, dans cet article, les registres eux-mêmes, pour que l'on puisse se rendre compte de ces irrégularités. Nous rendrons compte ensuite de l'application de transcription des dépenses, avant d'aborder, dans un

<footnote n="1">1. RCF https://cfregisters.org</footnote>
# Les registres de la Comédie-Française sur le Web de données liées :
de l'hétérogénéité de données vers des données quantitatives en RDF

Charline Granger<fnref n="1" />, Fabien Amarger²

¹Université Paris Nanterre, 200 avenue de la République, Nanterre, France
charline.granger@yahoo.com

²Logilab, 104 avenue Auguste Blanqui, Paris, France
fabien.amarger@logilab.fr

## Résumé

La Comédie-Française est une troupe de théâtre née de la volonté centralisatrice de Louis XIV en 1680 : troupe au statut ambigu, elle est pensionnée par le roi, mais fonctionne aussi comme une entreprise privée, dont les sociétaires se partagent les parts. Pour administrer ce partage et permettre le contrôle du pouvoir royal, les comédiens de la compagnie produisent dès sa fondation des registres journaliers, partiellement manuscrits, où ils consignent les recettes et les dépenses. Ces archives comptables sont uniques en leur genre par leur densité et leur continuité, puisque les registres ont été tenus à jour quotidiennement par les membres de la compagnie. Ces données sont particulièrement importantes pour comprendre la vie théâtrale de l'époque. Il n'y a actuellement pas d'autre moyen pour étudier ces registres que de les analyser manuellement, c'est pourquoi le programme de recherche des Registres de la Comédie-Française (RCF) a initié leur transcription et la constitution de bases de données, pour en faciliter l'étude. Ici, nous nous intéressons à la transcription des données des dépenses, qui sont particulièrement hétérogènes. La seconde partie de notre proposition porte sur l'alignement de ces données des dépenses sur les données transcrites antérieurement, qui proviennent des registres des recettes et des feux. L'objectif est de publier toutes ces données dans un même entrepôt SPARQL, afin de permettre des analyses quantitatives transversales.

## Mots-clés

archives, history of theatre, ontology, Linked Open Data, Digital Humanities

## 1 Introduction

La Comédie-Française est une troupe de théâtre née de la volonté centralisatrice de Louis XIV en 1680 : troupe au statut ambigu, elle est pensionnée par le roi, mais fonctionne aussi comme une entreprise privée, dont les sociétaires se partagent les parts. Pour administrer ce partage et permettre le contrôle du pouvoir royal, les comédiens de la compagnie produisent dès sa fondation des registres journaliers, partiellement manuscrits, où ils consignent les recettes et les dépenses. Ces archives comptables sont uniques en leur genre par leur densité et leur continuité, puisque ces

registres ont été tenus à jour quotidiennement jusqu'aujourd'hui par les membres de la troupe.

Afin de donner accès à cette archive précieuse, un programme de recherche international bilingue, le programme des Registres de la Comédie-Française<fnref n="1" /> [4] a été fondé il y a une dizaine d'années[1]. Il regroupe la Comédie-Française et plusieurs Universités : Paris Nanterre, Sorbonne Université, l'Université de Rouen Normandie, l'Université de Victoria (Canada), New York University et le Massachusetts Institute of Technology. Ce programme a d'abord été consacré à la création d'une base de données concernant les recettes journalières de la troupe entre 1680 et 1793, ce qui représente 113 saisons et plus de 30 000 soi-rées programmées : les registres de recettes donnent accès à la programmation (habituellement deux pièces par soi-rée) et au nombre de billets vendus par catégorie de place. Deux bases de données relationnelles ont ainsi été créées : d'une part, la base de données des recettes, qui associe à une date de représentation les titres des pièces jouées ce soir-là, les noms de leurs auteurs et le genre dramatique auquel elles ressortissent ; d'autre part, la base des "feux" (distribution par représentation), qui associe, sur la période 1765-1793, une date de représentation à des noms d'acteurs et d'actrices, eux-mêmes associés aux rôles qu'ils ont tenus ce soir-là, rôles auxquels est rattachée une pièce, un auteur et un genre.

L'enjeu pour nous, aujourd'hui, est de créer une troisième base de données, la base de données des dépenses de la troupe de 1680 à 1776, complémentaire de celle des recettes et des feux. Parallèlement à ce travail, nous créons un dépôt RDF de l'ensemble de nos jeux de données, pour les rendre ouvertes et permettre une liberté de représentation que n'autorisent pas les bases de données relationnelles. [La société Logilab, en tant que prestataire informatique, a en charge la réalisation technique de ces deux chantiers.] Car là est le défi pour nous : rendre compte de manière la plus fidèle possible de données partiellement irrégulières. Pour cela, nous présenterons, dans cet article, les registres eux-mêmes, pour que l'on puisse se rendre compte de ces irrégularités. Nous rendrons compte ensuite de l'application de transcription des dépenses, avant d'aborder, dans un

<footnote n="1">1. RCF https://cfregisters.org</footnote>
dernier temps, la création de l'entrepôt SPARQL contenant les données fusionnées des trois bases.

## 2 Les registres de la "Comédie-Française"

L'enjeu de l'établissement de ces bases de données est multiple, pour la communauté des chercheurs. D'abord, il s'agit de donner accès à un large public (étudiants, amauteurs, simples curieux et, bien sûr, universitaires et spécialistes) à des données qui ne sont pas aisément consultables par tous, parce qu'elles sont consignées dans les fonds de la Bibliothèque-Musée de la Comédie-Française. Les similés des registres numérisés, auxquels notre site donne accès, est le premier maillon de cette entreprise de diffusion. Mais surtout, les bases de données donnent accès à un surcroît d'information, auquel on ne peut pas avoir accès, ou très difficilement, en se contentant de consulter les registres ou leur version numérisée : grâce à la reconstruction des données permise par les bases de données, une lecture transversale est possible, qui permet de dégager des constantes et de faire des sondages sur la longue durée. On peut ainsi établir des statistiques sur les pièces qui rapportent le plus en fonction des périodes, sur la variation du nombre de spectateurs en fonction des catégories de places, sur la spécialisation des acteurs par types de rôles, etc. Dans le cas particulier de la base de données des dépenses que nous sommes en train de construire, nous espérons ainsi pouvoir savoir, à terme, quelles sont les pièces dont la représentation a coûté le plus cher en termes de décors, de costumes et de personnel supplémentaire, comme les musiciens et les figurants (les "assistants", comme on disait à l'époque). Grâce à cette base, nous pourrons mieux comprendre l'économie du théâtre, le statut des artistes sous l'Ancien Régime et obtenir de précieuses informations sur les prémisses de l'histoire de la mise en scène.

## 3 L'application de transcription des registres des dépenses

La politique de RCF en matière de traitement de l'information est de restituer la source de manière la plus précise possible, d'être au plus près de l'information d'origine telle qu'elle apparaît dans les registres. Cette exigence scientifique repose sur la volonté de livrer à l'utilisateur ou l'utilisatrice une information qui ait fait le moins possible l'objet de choix et d'interprétations en amont, ce qui biaiserait la lecture qu'il fait des registres. Une telle exigence est a priori aisément conciliable avec un traitement systématique de l'information, car, de manière générale, les registres journaliers présentent des informations qui sont elles-mêmes systématiques, parce qu'elles sont toujours subordonnées à une date : la "soirée", où a lieu telle représentation, qui a généré telles recettes et telles dépenses. Dans le cadre des registres des dépenses, en plus de cette régularité calendaire, on remarque qu'un certain nombre de catégories restent stables pendant plusieurs années, voire plusieurs décennies, ce qui nous permet de les envisager comme "données

massives". Pourtant, l'information est à plusieurs égards hétérogène et non continue. Un premier aspect de cette disparité réside dans le fait que beaucoup de types de frais ne sont pas stables à l'échelle des 96 saisons de la période 1680-1776, mais le sont sur des plus courtes périodes (décennies, années, voire mois). C'est pourquoi les registres peuvent être regroupés par périodes durant lesquelles les catégories pré-imprimées sont globalement stables. La tâche principale, lors du développement de l'application de transcription pour les registres des dépenses, a été de définir les différents formulaires pour chaque période. Chaque dépense est associée à une valeur monétaire représentée en L (livres), S (sols) and D (deniers).

Nous avons défini trois types de champs de dépenses :

- **Champ simple** qui associe une dépense à une seule valeur monétaire : par exemple dans la figure 1 "frais ordinaires".

- **Champ multiple** qui associe une dépense à plusieurs valeurs monétaires, chacune définie par un intitulé manuscrit : par exemple dans la figure 1 "Frais extraordinaires".

- **Champ partitionné** qui associe une dépense à une seule valeur monétaire, qui est la valeur de la part, mais qui l'associe en plus à un nombre de parts et à un total. Ce type de champ est utilisé, par exemple, pour définir le paiement des acteurs, qu'il est possible de retrouver sur la figure 1 avec le libellé "PART".

Un second aspect de la disparité de l'information contenue dans les registres des dépenses tient au fait qu'ils regroupent plusieurs types de données. Nous distinguons quatre catégories différentes de dépenses :

- Les **catégories pré-imprimées** : par exemple, sur la figure 1 "frais ordinaires".

- Les **mentions manuscrites sur les catégories pré-imprimées** (qui permettent de les clarifier ou même de les remplacer) : par exemple sur la figure 1 "et chandelle des religieux".

- Les **informations marginales** (toujours manuscrites, qui ne concernent pas les dépenses, mais donnent des précisions à propos d'une "relâche"<fnref n="2" /> ou indiquent la présence d'une personnalité importante dans la salle). Par exemple, sur la figure 1, nous pouvons lire "L'on ne joua point hier à cause du départ de Messieurs Poisson et Raisin pour Fontainebleau".

- Les **dépenses manuscrites** qui sont ajoutées aux catégories pré-imprimées. Par exemple sur la figure 1, "pour l'affiche noire".

L'interface de l'application de transcription a été adaptée pour pouvoir absorber toute cette diversité. Le transcripteur (ou la transcriptrice), peut enregistrer ces différentes annotations : le formulaire contient les dépenses pré-imprimées et certains champs sont laissés libres pour permettre de spécifier la mention manuscrite. Ces champs libres sont sys-

<footnote n="2">². "Relâche" désigne les jours de fermeture du théâtre.</footnote>
dernier temps, la création de l'entrepôt SPARQL contenant les données fusionnées des trois bases.

## 2 Les registres de la "Comédie-Française"

L'enjeu de l'établissement de ces bases de données est multiple, pour la communauté des chercheurs. D'abord, il s'agit de donner accès à un large public (étudiants, amauteurs, simples curieux et, bien sûr, universitaires et spécialistes) à des données qui ne sont pas aisément consultables par tous, parce qu'elles sont consignées dans les fonds de la Bibliothèque-Musée de la Comédie-Française. Les similés des registres numérisés, auxquels notre site donne accès, est le premier maillon de cette entreprise de diffusion. Mais surtout, les bases de données donnent accès à un surcroît d'information, auquel on ne peut pas avoir accès, ou très difficilement, en se contentant de consulter les registres ou leur version numérisée : grâce à la reconstruction des données permise par les bases de données, une lecture transversale est possible, qui permet de dégager des constantes et de faire des sondages sur la longue durée. On peut ainsi établir des statistiques sur les pièces qui rapportent le plus en fonction des périodes, sur la variation du nombre de spectateurs en fonction des catégories de places, sur la spécialisation des acteurs par types de rôles, etc. Dans le cas particulier de la base de données des dépenses que nous sommes en train de construire, nous espérons ainsi pouvoir savoir, à terme, quelles sont les pièces dont la représentation a coûté le plus cher en termes de décors, de costumes et de personnel supplémentaire, comme les musiciens et les figurants (les "assistants", comme on disait à l'époque). Grâce à cette base, nous pourrons mieux comprendre l'économie du théâtre, le statut des artistes sous l'Ancien Régime et obtenir de précieuses informations sur les prémisses de l'histoire de la mise en scène.

## 3 L'application de transcription des registres des dépenses

La politique de RCF en matière de traitement de l'information est de restituer la source de manière la plus précise possible, d'être au plus près de l'information d'origine telle qu'elle apparaît dans les registres. Cette exigence scientifique repose sur la volonté de livrer à l'utilisateur ou l'utilisatrice une information qui ait fait le moins possible l'objet de choix et d'interprétations en amont, ce qui biaiserait la lecture qu'il fait des registres. Une telle exigence est a priori aisément conciliable avec un traitement systématique de l'information, car, de manière générale, les registres journaliers présentent des informations qui sont elles-mêmes systématiques, parce qu'elles sont toujours subordonnées à une date : la "soirée", où a lieu telle représentation, qui a généré telles recettes et telles dépenses. Dans le cadre des registres des dépenses, en plus de cette régularité calendaire, on remarque qu'un certain nombre de catégories restent stables pendant plusieurs années, voire plusieurs décennies, ce qui nous permet de les envisager comme "données

massives". Pourtant, l'information est à plusieurs égards hétérogène et non continue. Un premier aspect de cette disparité réside dans le fait que beaucoup de types de frais ne sont pas stables à l'échelle des 96 saisons de la période 1680-1776, mais le sont sur des plus courtes périodes (décennies, années, voire mois). C'est pourquoi les registres peuvent être regroupés par périodes durant lesquelles les catégories pré-imprimées sont globalement stables. La tâche principale, lors du développement de l'application de transcription pour les registres des dépenses, a été de définir les différents formulaires pour chaque période. Chaque dépense est associée à une valeur monétaire représentée en L (livres), S (sols) and D (deniers).

Nous avons défini trois types de champs de dépenses :

- **Champ simple** qui associe une dépense à une seule valeur monétaire : par exemple dans la figure 1 "frais ordinaires".

- **Champ multiple** qui associe une dépense à plusieurs valeurs monétaires, chacune définie par un intitulé manuscrit : par exemple dans la figure 1 "Frais extraordinaires".

- **Champ partitionné** qui associe une dépense à une seule valeur monétaire, qui est la valeur de la part, mais qui l'associe en plus à un nombre de parts et à un total. Ce type de champ est utilisé, par exemple, pour définir le paiement des acteurs, qu'il est possible de retrouver sur la figure 1 avec le libellé "PART".

Un second aspect de la disparité de l'information contenue dans les registres des dépenses tient au fait qu'ils regroupent plusieurs types de données. Nous distinguons quatre catégories différentes de dépenses :

- Les **catégories pré-imprimées** : par exemple, sur la figure 1 "frais ordinaires".

- Les **mentions manuscrites sur les catégories pré-imprimées** (qui permettent de les clarifier ou même de les remplacer) : par exemple sur la figure 1 "et chandelle des religieux".

- Les **informations marginales** (toujours manuscrites, qui ne concernent pas les dépenses, mais donnent des précisions à propos d'une "relâche"<fnref n="2" /> ou indiquent la présence d'une personnalité importante dans la salle). Par exemple, sur la figure 1, nous pouvons lire "L'on ne joua point hier à cause du départ de Messieurs Poisson et Raisin pour Fontainebleau".

- Les **dépenses manuscrites** qui sont ajoutées aux catégories pré-imprimées. Par exemple sur la figure 1, "pour l'affiche noire".

L'interface de l'application de transcription a été adaptée pour pouvoir absorber toute cette diversité. Le transcripteur (ou la transcriptrice), peut enregistrer ces différentes annotations : le formulaire contient les dépenses pré-imprimées et certains champs sont laissés libres pour permettre de spécifier la mention manuscrite. Ces champs libres sont sys-

<footnote n="2">2. "Relâche" désigne les jours de fermeture du théâtre.</footnote>
<figure><img src="image_29.png" /><figcaption>FIGURE 1 – Exemple d’une page d’un registre des dépenses</figcaption></figure>
<figure><img src="image_29.png" /><figcaption>FIGURE 1 – Exemple d’une page d’un registre des dépenses</figcaption></figure>
tématiquement rassemblés en "super-catégories" pour regrouper des frais analogues quand cela est possible. Par exemple, la catégorie "Frais extraordinaires" est utilisée pour réunir les dépenses exceptionnelles qui concernent ce jour spécifiquement. Par exemple dans la figure 1, "pour l'affiche noire" ou dans d'autres pages "vin" ou encore "une robe de chambre".

Néanmoins, ces frais extraordinaires posent problème car cette catégorie de dépenses définit des dépenses irrégu- lières, contrairement aux dépenses ordinaires : aussi n'ont- ils pas de représentation fixe durant toute la période. Pour certaine saison, il existe la catégorie pré-imprimée "Frais extraordinaires", comme nous pouvons le voir sur la fi- gure 1. Mais dans d'autres registres, on note la présence de plusieurs mentions manuscrites qui ne sont pas catégori- sées. Dans cette situation, il est périlleux de définir une ca- tégorie pour ces dépenses : sont-elles réellement des "frais extraordinaires" ou sont-elles des dépenses non catégori- sables ? Le problème ici est double : comment transcrire ces mentions manuscrites non catégorisées et peut-on trouver un moyen efficace et pertinent, durant un traitement post- transcription, de catégoriser quand même ces dépenses ? Cette étape de catégorisation post-transcription est impor- tante puisqu'elle oriente les possibilités d'analyses quanti- tatives des données et leur interprétation. En fonction des catégories que nous définirons dans cette étape, les résul- tats peuvent varier significativement, ce qui n'est pas sans poser un problème scientifique majeur : en ajoutant une in- formation qui ne figure pas dans l'archive, nous risquons d'introduire un biais interprétatif dans les données trans- crites, qui ne rendent pas compte fidèlement du document source. Pour l'instant, nous ajoutons les mentions manus- crites non catégorisées comme des "Frais extraordinaires", sans catégorisation supplémentaire. C'est une des limites de notre approche : nous y reviendrons dans les perspec- tives présentées à la fin de cet article.

Un problème supplémentaire se pose pour certaines caté- gories de dépenses qui sont assimilées les unes aux autres sur une même ligne de frais. Dans la figure 1, les "frais ex- traordinaires" et les "chandelles des religieux" sont repré- sentées comme une même dépense, puisqu'il y a un seul nombre pour ces deux postes. Il n'y a donc aucun moyen de déterminer si la dépense "2 livres et 11 sols" correspond aux "frais extraordinaires" dans leur intégralité ou juste aux "chandelles des religieux".

La figure 2 présente l'exemple d'un formulaire de transcrip- tion d'une page d'un registre. La partie gauche de l'appli- cation est dédiée au fac-similé de la page de registre qui doit être transcrite. La partie droite contient les champs des dépenses à renseigner, en fonction de la période à laquelle la page fait référence. En bas de l'application, apparaissent en commentaires des méta-données concernant le processus de transcription. Est renseigné aussi dans ces méta-données l'état de la transcription pour cette page.

Le processus de transcription d'une page d'un registre suit différentes étapes. Tout d'abord, la page se trouve dans l'état *to do* (à faire). Puis, lorsque le transcripteur ou la transcriptrice a fini de transcrire la page, elle passe dans

l'état *to review* (à relire) pour informer un expert qu'il faut vérifier la page, pour la valider ou la corriger. Une fois que les données de transcription sont validées, la page passe dans l'état *validated* (validée). À ce moment, les données peuvent être analysées puisqu'elles ont été transcrites et va- lidées. Une page peut être validée même si des erreurs appa- raissent. Par exemple, l'erreur la plus courante réside dans une différence entre le total transcrit des dépenses sur la page d'archive et le total calculé par la machine, à partir des données rentrées dans le formulaire de saisie. La plu- part du temps, cette erreur est présente dans la page elle- même et n'est pas liée à une mauvaise transcription. Nous avons décidé de ne pas corriger l'erreur dans les données, en notifiant que la page contient une erreur. Cela permet de laisser aux chercheurs la possibilité d'étudier ces erreurs et de les interpréter, par exemple pour déterminer à partir des récurrences si elles sont délibérées ou non, et pour analyser s'il y a une forme de détournement d'argent de la part du comédien chargé de remplir quotidiennement le registre.

## 4 Des données RDF pour fusionner les trois bases de données

Une fois que les trois bases de données (*dépenses*, *recette* et *feux* (rôles et acteurs/actrices)) sont transcrites et validées, il faut ensuite pouvoir les fusionner, afin de pouvoir inter- roger l'intégralité des données. Le processus d'alignement a été relativement simple puisque chaque page transcrite, dans les trois bases, est associée à une date de représen- tation, qui constitue l'élément pivot de notre alignement. L'utilisation des formalismes RDF et des technologies du Web Sémantique nous a semblé le plus appropriée, dans la mesure où l'objectif principal est de donner accès à ces don- nées au plus grand nombre de personnes : les technologies du Web Sémantique et plus spécifiquement le Web de don- nées liées sont destinés précisément à cet usage [5]. Mais le formalisme RDF permet aussi de résoudre un des pro- blèmes présentés dans le chapitre 2. La diversité des don- nées est complexe à manipuler dans une base de données relationnelle, alors que le RDF permet de créer facilement des liens lorsque cela est nécessaire. Nous n'avons pas be- soin de connaitre au préalable l'intégralité des attributs et des champs.

Afin d'exporter ces données au format RDF, il nous faut définir une ontologie. Nous pouvons observer une partie de cette ontologie, unifiant les concepts des trois bases, dans la figure 3 : pour faciliter la lisibilité, nous n'en affichons qu'une partie (par exemple, la notion de "période" n'appa- raît pas).

Nous l'avons dit : le concept pivot pour créer les liens entre les différentes données des trois bases est la **Journée**. Toute la partie supérieure sur la figure 3 regroupe les concepts de la base des *Feux* (acteurs/actrices et rôles), en bas à gauche pour les *Dépenses* (Expenses) et en bas à droite pour les *Recettes* (Receipts). Tous les détails (catégories de dépenses, catégories de sièges, etc.) ne sont pas présents dans l'onto- logie initiale puisque ces détails sont générés dynamique- ment lors de l'export des données. L'ontologie évolue donc
tématiquement rassemblés en "super-catégories" pour regrouper des frais analogues quand cela est possible. Par exemple, la catégorie "Frais extraordinaires" est utilisée pour réunir les dépenses exceptionnelles qui concernent ce jour spécifiquement. Par exemple dans la figure 1, "pour l'affiche noire" ou dans d'autres pages "vin" ou encore "une robe de chambre".

Néanmoins, ces frais extraordinaires posent problème car cette catégorie de dépenses définit des dépenses irrégu- lières, contrairement aux dépenses ordinaires : aussi n'ont- ils pas de représentation fixe durant toute la période. Pour certaine saison, il existe la catégorie pré-imprimée "Frais extraordinaires", comme nous pouvons le voir sur la fi- gure 1. Mais dans d'autres registres, on note la présence de plusieurs mentions manuscrites qui ne sont pas catégori- sées. Dans cette situation, il est périlleux de définir une ca- tégorie pour ces dépenses : sont-elles réellement des "frais extraordinaires" ou sont-elles des dépenses non catégori- sables ? Le problème ici est double : comment transcrire ces mentions manuscrites non catégorisées et peut-on trouver un moyen efficace et pertinent, durant un traitement post- transcription, de catégoriser quand même ces dépenses ? Cette étape de catégorisation post-transcription est impor- tante puisqu'elle oriente les possibilités d'analyses quanti- tatives des données et leur interprétation. En fonction des catégories que nous définirons dans cette étape, les résul- tats peuvent varier significativement, ce qui n'est pas sans poser un problème scientifique majeur : en ajoutant une in- formation qui ne figure pas dans l'archive, nous risquons d'introduire un biais interprétatif dans les données trans- crites, qui ne rendent pas compte fidèlement du document source. Pour l'instant, nous ajoutons les mentions manus- crites non catégorisées comme des "Frais extraordinaires", sans catégorisation supplémentaire. C'est une des limites de notre approche : nous y reviendrons dans les perspec- tives présentées à la fin de cet article.

Un problème supplémentaire se pose pour certaines caté- gories de dépenses qui sont assimilées les unes aux autres sur une même ligne de frais. Dans la figure 1, les "frais ex- traordinaires" et les "chandelles des religieux" sont repré- sentées comme une même dépense, puisqu'il y a un seul nombre pour ces deux postes. Il n'y a donc aucun moyen de déterminer si la dépense "2 livres et 11 sols" correspond aux "frais extraordinaires" dans leur intégralité ou juste aux "chandelles des religieux".

La figure 2 présente l'exemple d'un formulaire de transcrip- tion d'une page d'un registre. La partie gauche de l'appli- cation est dédiée au fac-similé de la page de registre qui doit être transcrite. La partie droite contient les champs des dépenses à renseigner, en fonction de la période à laquelle la page fait référence. En bas de l'application, apparaissent en commentaires des méta-données concernant le processus de transcription. Est renseigné aussi dans ces méta-données l'état de la transcription pour cette page.

Le processus de transcription d'une page d'un registre suit différentes étapes. Tout d'abord, la page se trouve dans l'état *to do* (à faire). Puis, lorsque le transcripteur ou la transcriptrice a fini de transcrire la page, elle passe dans

l'état *to review* (à relire) pour informer un expert qu'il faut vérifier la page, pour la valider ou la corriger. Une fois que les données de transcription sont validées, la page passe dans l'état *validated* (validée). À ce moment, les données peuvent être analysées puisqu'elles ont été transcrites et val- lidées. Une page peut être validée même si des erreurs appa- raissent. Par exemple, l'erreur la plus courante réside dans une différence entre le total transcrit des dépenses sur la page d'archive et le total calculé par la machine, à partir des données rentrées dans le formulaire de saisie. La plu- part du temps, cette erreur est présente dans la page elle- même et n'est pas liée à une mauvaise transcription. Nous avons décidé de ne pas corriger l'erreur dans les données, en notifiant que la page contient une erreur. Cela permet de laisser aux chercheurs la possibilité d'étudier ces erreurs et de les interpréter, par exemple pour déterminer à partir des récurrences si elles sont délibérées ou non, et pour analyser s'il y a une forme de détournement d'argent de la part du comédien chargé de remplir quotidiennement le registre.

## 4 Des données RDF pour fusionner les trois bases de données

Une fois que les trois bases de données (*dépenses*, *recette* et *feux* (rôles et acteurs/actrices)) sont transcrites et validées, il faut ensuite pouvoir les fusionner, afin de pouvoir inter- roger l'intégralité des données. Le processus d'alignement a été relativement simple puisque chaque page transcrite, dans les trois bases, est associée à une date de représen- tation, qui constitue l'élément pivot de notre alignement. L'utilisation des formalismes RDF et des technologies du Web Sémantique nous a semblé le plus appropriée, dans la mesure où l'objectif principal est de donner accès à ces don- nées au plus grand nombre de personnes : les technologies du Web Sémantique et plus spécifiquement le Web de don- nées liées sont destinés précisément à cet usage [5]. Mais le formalisme RDF permet aussi de résoudre un des pro- blèmes présentés dans le chapitre 2. La diversité des don- nées est complexe à manipuler dans une base de données relationnelle, alors que le RDF permet de créer facilement des liens lorsque cela est nécessaire. Nous n'avons pas be- soin de connaitre au préalable l'intégralité des attributs et des champs.

Afin d'exporter ces données au format RDF, il nous faut définir une ontologie. Nous pouvons observer une partie de cette ontologie, unifiant les concepts des trois bases, dans la figure 3 : pour faciliter la lisibilité, nous n'en affichons qu'une partie (par exemple, la notion de "période" n'appa- raît pas).

Nous l'avons dit : le concept pivot pour créer les liens entre les différentes données des trois bases est la **Journée**. Toute la partie supérieure sur la figure 3 regroupe les concepts de la base des *Feux* (acteurs/actrices et rôles), en bas à gauche pour les *Dépenses* (Expenses) et en bas à droite pour les *Recettes* (Receipts). Tous les détails (catégories de dépenses, catégories de sièges, etc.) ne sont pas présents dans l'onto- logie initiale puisque ces détails sont générés dynamique- ment lors de l'export des données. L'ontologie évolue donc
<figure><img src="image_30.png" /><figcaption>FIGURE 2 – Application de transcription des dépenses</figcaption></figure>

en fonction des éléments découverts lors de l'export.

Une fois l'ontologie définie, nous alignons les concepts clés de cette ontologie avec des ontologies de références. Cet alignement est crucial, notamment parce que notre ontologie utilise, par fidélité à la source archivistique, des termes français. Mais il n'y a aucune raison de ne pas permettre à des personnes non francophones d'accéder à ces données : favoriser la réutilisation et l'appropriation des données par le plus grand nombre est un des objectifs du programme RCF, et cela est facilité lorsque les ontologies sont alignées sur une même ontologie de référence. Ces alignements peuvent ensuite être utilisés pour enrichir les données, par exemple en y adjoignant la date de naissance d'un acteur ou d'une actrice.

La table 1 présente les alignements entre l'ontologie RCF et FRBRoo, schema.org, DubinCore et FoaF. Nous n'avons toutefois pas aligné l'intégralité de FRBRoo, bien que cette dernière constitue une des ontologies les plus reconnues dans ce domaine. Parce qu'elle hérite de Cidoc CRM, la notion d'évènement est centrale dans sa modélisation. Or, dans nos données, il y a bien des évènements, mais tout n'est pas évènement : par exemple, nous n'avons pas "l'évènement" de la naissance d'une personne, ce qui est nécessaire dans l'ontologie FRBRoo. De plus, nous voulons éviter des alignements complexes qui ne rendraient pas la réutilisation du modèle aisée. Une fois que nous avons défini l'ontologie, exporté toutes les données à partir des trois bases de données en RDF, nous déployons l'intégration

des triplets RDF (ontologie et données) dans un entrepôt SPARQL public<fnref n="3" />. Nous utilisons Virtuoso Open-Source Edition<fnref n="4" />. Il est alors possible d'interroger cet entrepôt pour obtenir des réponses aux questions telles que "quel est le prix des représentations dans lesquelles un acteur donné a joué et quels sont les frais extraordinaires pour ces représentations ?" Une autre requête possible consiste à comparer les recettes de ces représentations et à les mettre en lien avec la distribution des rôles : ce peut être un moyen d'interroger le processus de vedettarisation des acteurs et actrices.

Pour aider les utilisateurs et utilisatrices ne maitrisant pas le SPARQL à accéder à ces données, nous avons développé une application web https://upnd.pages.logilab.fr/rcf-ui-expense/ qui utilise les données de l'entrepôt SPARQL. Cette application est pour l'instant dédiée aux dépenses, mais il serait intéressant de l'étendre pour prendre en compte les données des deux autres bases.

La figure 4 présente une capture d'écran de l'application. Nous pouvons observer qu'il est possible de comparer plusieurs types de dépenses dans une période donnée. C'est particulièrement utile pour déterminer quelle dépense présente une grande part des dépenses totales en fonction des autres types de dépenses et d'une période donnée. Cette application permet aux utilisateurs ou utilisatrices de com-

<footnote n="3">3. https://rcf-sparql.demo.logilab.fr/</footnote>

<footnote n="4">4. https://vos.openlinksw.com</footnote>