# Développement d'une unité d'anonymisation visuelle automatisée par détection humaine via IA

Manon Gauthier

<figure><img src="image_1.png" /></figure>

## To cite this version:

Manon Gauthier. Développement d'une unité d'anonymisation visuelle automatisée par détection humaine via IA. Informatique [cs]. 2025. hal-05308809

HAL Id: hal-05308809

https://hal.inrae.fr/hal-05308809v1

Submitted on 10 Oct 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>
TÉLÉCOM PHYSIQUE STRASBOURG

DIPLÔME GÉNÉRALISTE
PROMO 2026

Rapport de stage de 2ième année

Département : Images, Signaux et Science des Données

Développement d'une unité
d'anonymisation visuelle automatisée par
détection humaine via IA

Auteur :
GAUTIER Manon

Entreprise :
GenPhySE — INRAE

Référent Filière ISSD :
DRIRA Hassen

Responsable du stage :
LAPERRUQUE François
Remerciements

Je tiens à exprimer toute ma reconnaissance à mon tuteur de stage, François Laperruque, pour la confiance qu'il m'a accordée dans la réalisation de ce projet ainsi que pour son écoute attentive et bienveillante face à mes questions.

Je remercie également Clément et Téo pour le temps qu'ils ont consacré à m'expliquer patiemment leurs réalisations ainsi que pour leur accompagnement tout au long du développement de ma part du projet.

Enfin, je voudrais remercier Kevin Wanaverbecq, ancien élève de l'école, sans la recommandation duquel je n'aurais sans doute pas eu connaissance de ce stage.
# Table des figures

<table><tr><td>2.1</td><td>Fonctionnement de SPIDER</td><td>6</td></tr><tr><td>5.1</td><td>Schéma général de l'unité d'anonymisation</td><td>18</td></tr><tr><td>5.2</td><td>Architecture fonctionnelle de l'unité d'anonymisation</td><td>20</td></tr><tr><td>5.3</td><td>Exemple d'anonymisation sur image fixe<sup>1</sup></td><td>22</td></tr><tr><td>6.1</td><td>Dispatcher</td><td>27</td></tr><tr><td>6.2</td><td>Traitement d'un dépôt</td><td>28</td></tr><tr><td>6.3</td><td>Exemple d'arborescence finale pour l'utilisateur userX, avant et après compression</td><td>30</td></tr><tr><td>6.4</td><td>Notification de fin de traitement</td><td>30</td></tr><tr><td>6.5</td><td>Notification de fin de traitement avec fichiers à problèmes</td><td></td></tr><tr><td>6.6</td><td>Notification de dépôt inactif, avertissement</td><td></td></tr><tr><td>6.7</td><td>Notification de dépôt inactif, suppression</td><td></td></tr></table>
# Introduction

Actuellement en deuxième année d'école d'ingénieurs à Télécom Physique Strasbourg, ce stage marque la fin de ma première année en filière Généraliste et spécialité ISSD (Images Signaux et Science des Données). Il s'est déroulé au sein de l'unité GenPhySE de l'INRAE, sur le site de Toulouse-Auzeville, dans l'équipe ALIEN.

L'objectif principal de ce stage était d'intervenir dans le cadre du projet SPIDER (Système Partagé d'Interopérabilité des Données d'Expérimentation et de Recherche), un projet porté par GenPhySE visant à centraliser et structurer les données scientifiques produites dans différentes unités de recherche. Une problématique clé du projet concerne la gestion des fichiers multimédias (images et vidéos) contenant des personnes identifiables : chercheurs, techniciens, agriculteurs, dont les données doivent être protégées conformément au Règlement Général sur la Protection des Données (RGPD).

Mon stage consistait plus précisément à concevoir et développer une infrastructure d'anonymisation automatique des fichiers multimédias, destinée à être intégrée à la plateforme SPIDER. Cette infrastructure, que l'on appelera "Unité d'anonymisation", a été pensée dans une logique modulaire de type ETL (Extract, Transform, Load), et s'appuie sur un pipeline combinant un dispatcher, un gestionnaire de pipeline, des workers spécialisés et un ordonnanceur de tâches. Un serveur Python léger complète cette unité en assurant l'exposition d'une API dédiée à la transmission automatisée des fichiers traités.

Ce sujet m'a offert une immersion concrète dans le quotidien d'un développeur intégré à une équipe projet. J'ai bénéficié d'une grande autonomie dans mon travail, rendue possible par la confiance de mon encadrant, François Laperruque. J'ai eu l'opportunité de contribuer pleinement au développement d'un outil très attendu, au même titre que les développeurs Clément Crouzet, responsable du projet SPIDER, et Téo Cochou, référent IA de l'équipe.

Des réunions hebdomadaires avec l'équipe ALIEN, ainsi que des échanges réguliers avec l'équipe SPIDER – dont Laurence Drouilhet est la cheffe de projet métier SPIDER, et Thierry Heirman, le chef de projet informatique – ont assuré un suivi de l'avancement du projet.
# Chapitre 1

# GenPhySE INRAE

## I INRAE

L'INRAE, Institut national de recherche pour l'agriculture, l'alimentation et l'environnement, a été créé le 1er janvier 2020 suite à la fusion de l'Inra (Institut national de la recherche agronomique) et de l'Irstea (Institut national de recherche en sciences et technologies pour l'environnement et l'agriculture). Il constitue aujourd'hui le premier organisme de recherche français dédié à ces trois grands domaines scientifiques. En réunissant des expertises complémentaires, à la fois technologiques et scientifiques, l'INRAE vise à devenir un acteur de référence au niveau mondial pour relever les grands défis sociétaux, notamment :

- la sécurité alimentaire et nutritionnelle;

- la transition vers des agricultures plus durables (agroécologie, réduction de l'usage des produits chimiques);

- la gestion des ressources naturelles et des écosystèmes (eau, sols, forêts);

- la lutte contre l'érosion de la biodiversité;

- le développement de l'économie circulaire et la prévention des risques naturels.

À ces priorités s'ajoutent des enjeux locaux tels que les conditions de vie et de travail des agriculteurs, la compétitivité des entreprises, l'aménagement du territoire ou encore l'accès pour tous à une alimentation saine et variée. L'ambition d'INRAE est de produire une recherche d'excellence, porteuse d'innovation, au service de la connaissance, de l'enseignement et des politiques publiques, afin d'accompagner et d'accélérer les transitions nécessaires dans les domaines de l'agriculture, de l'alimentation et de l'environnement, en cohérence avec les objectifs du développement durable.

## II GenPhySE & l'équipe ALIEN

L'INRAE est divisé en 14 départements de recherche répartis sur 18 centres. Chaque centre est lui-même subdivisé en unités, une unité pouvant être rattachée à plusieurs départements de recherche.

GenPhySE (Génétique, Physiologie, et Systèmes d'Élevage) est une des unités du centre INRAE Occitanie-Toulouse. Elle est rattachée aux départements Génétique Animale (GA) et Physiologie Animale et Systèmes d'Élevage (PHASE). C'est également une UMR, affiliée à l'École Vétérinaire de Toulouse (ENVT) et à l'Institut Polytechnique de Toulouse (INP).
L'unité GenPhySE a vu le jour en 2014, à la suite de la fusion de trois unités du site INRAE de Toulouse-Auzeville, toutes engagées dans la recherche animale. Sa mission scientifique est centrée sur la compréhension des mécanismes complexes qui régissent la capacité des animaux à s'adapter à des environnements en constante évolution. L'objectif est de proposer des innovations en génétique, nutrition et conduite d'élevage, afin de contribuer à la diversification et à la durabilité des systèmes de production.

Les recherches menées à GenPhySE adoptent une approche multi-échelle, allant de l'ADN à l'animal, au troupeau, jusqu'au système d'élevage dans sa globalité. L'activité scientifique de l'unité est structurée autour de cinq pôles de recherche, regroupant dix équipes.

Durant mon stage, j'ai travaillé au sein de l'équipe A.. L.. I.. E.. N.. (ALIEN). Cette équipe fait partie du CATI Systèmes d'informations et calcul pour le phénotypage animal (SICPA). Les CATIs (Centre Automatisé de Traitement de l'Information) sont de façon générale des lieux de production informatique ou de services en soutien à une communauté scientifique ciblée.
# Chapitre 2

## Le projet SPIDER

Dans le domaine des sciences animales, la collecte et la gestion des données expérimentales sont essentielles. De nombreux systèmes d'information (SI) ont été développés au sein de l'INRAE afin de répondre aux besoins spécifiques liés aux différentes espèces (lapins, bovins, porcins, ovins-caprins, équins, poissons, volailles), mais aussi à des thématiques transversales comme la santé, l'alimentation ou encore l'environnement. Ces bases, conçues indépendamment les unes des autres, ont permis une structuration fine des données, mais leur hétérogénéité rend difficile leur exploitation conjointe et leur valorisation à grande échelle.

Le projet SPIDER (Système Partagé d'Interopérabilité des Données d'Expérimentation et de Recherche) a été conçu pour répondre à cette problématique. Il vise à centraliser, harmoniser et rendre interopérables les données issues de ces différents SI afin de constituer une plateforme unique d'accès et de partage.

### I Systèmes d'information

Aujourd'hui, 11 systèmes d'information sont utilisés dans les unités expérimentales de différents départements de recherche (Génétique Animale - GA, Physiologie Animale et Systèmes d'Élevage - PHASE, Santé Animale - SA, Systèmes Agraires et Développement - SAD, Écologie des Forêts, Prairies et milieux Aquatiques - EFPA). Chacun a été développé pour répondre aux besoins spécifiques d'une espèce ou d'une thématique :

- Sicpa Lapins (1992)

- Sicpa Porcins (2012)

- Sicpa Bovins (2003)

- Sicpa Équins (2019)

- Sicpa Ovins-Caprins (2003)

- Sicpa Poissons (2016)

- Sicpa Volailles (2008)

- Sicpa Ambiance (2019)

- Sicpa Sanitaire et Alimentation (2014)

- Sicpa Expérimentations (2005)

- TraceAppli (2005)

Cette diversité illustre la richesse des données collectées par l'INRAE, mais aussi la nécessité d'un projet comme SPIDER pour les fédérer et en faciliter l'exploitation.
# II Acteurs du projet

Le projet SPIDER est piloté par Laurence Drouilhet et Thierry Heirman, dans le cadre de l'initiative PATASEL. Il s'appuie sur les compétences de plusieurs unités de recherche, en particulier :

- l'UMR1388 **GenPhySE** (Génétique, Physiologie et Systèmes d'Élevage) basée à Castanet-Tolosan,

- l'UMR1348 **PEGASE** (Physiologie, Environnement et Génétique pour l'Animal et les Systèmes d'Élevage) située à Saint-Gilles.

Le projet mobilise également le groupe « Gestion des données » de GenPhySE, impliqué depuis 2018 dans l'inventaire, la localisation et la description des données existantes.

# III Fonctionnement

Le fonctionnement de SPIDER repose sur une architecture technique qui sépare la gestion des données brutes de celle des métadonnées :

Les fichiers déposés par les utilisateurs sont stockés dans l'infrastructure de stockage institutionnelle **CEPH**, conçue pour gérer de grands volumes de données en garantissant fiabilité et sécurité.

Les métadonnées associées à ces fichiers sont enregistrées dans une base **MongoDB**, permettant une indexation rapide, un accès structuré et une interopérabilité optimale.

Deux interfaces complémentaires sont mises à disposition des chercheurs :

- la page de dépôt : https://spider.cati.inrae.fr/DepotSpiderWeb
  Elle permet de charger des fichiers et de renseigner les métadonnées contextuelles;

- la page de consultation : https://spider.cati.inrae.fr/SpiderWeb
  Offre un accès aux données centralisées et facilite leur exploration.

Ce fonctionnement assure que chaque jeu de données est accompagné d'informations descriptives normalisées, permettant une recherche plus efficace, une meilleure réutilisation et une interopérabilité avec d'autres infrastructures comme les **CRB Anim (BReiF)** ou **CTIG**.

L'unité d'anonymisation s'intègre dans cette chaîne de traitement au moment de la réception des données. (voir schéma Figure 2.1)
<figure><img src="image_3.png" /><figcaption>FIGURE 2.1 – Fonctionnement de SPIDER</figcaption></figure>

# IV Objectifs

## IV.1 Principe F.A.I.R.

Le projet SPIDER s'inscrit pleinement dans la logique du principe F.A.I.R. (Findable, Accessible, Interoperable, Reusable), qui regroupe un ensemble de bonnes pratiques pour la gestion des données scientifiques :

- Findable, les données doivent être faciles à localiser grâce à des métadonnées claires et à un identifiant unique;

- Accessible, elles doivent être consultables via des protocoles ouverts, même si un accès complet peut nécessiter une autorisation;

- Interoperable, elles doivent utiliser des formats et standards communs pour faciliter leur combinaison avec d'autres sources;

- Reusable, elles doivent inclure des informations précises sur leur provenance et leurs conditions d'utilisation afin de pouvoir être réutilisées efficacement.

En adoptant ce cadre, SPIDER favorise la transparence scientifique, le partage et la valorisation des données de recherche.

## IV.2 Objectifs spécifiques de SPIDER

SPIDER poursuit cinq objectifs principaux :

- Centraliser et harmoniser les informations issues des différents systèmes.

- Faciliter l'accès aux données via une plateforme unique et interoperable.

- Enrichir les données grâce à des métadonnées normalisées (ontologies, thésaurus IN-RAE).

- Ouvrir les données vers des plateformes nationales d'open data comme Recherche Data Gouv.

- Assurer la pérennité et la robustesse du stockage face à la croissance des volumes.
IV.3 Objectifs spécifiques de l’unité d’anonymisation

L’unité d’anonymisation (UA) a pour mission de traiter les données multimédia visuelles (photos, vidéos) afin de supprimer ou masquer toute information permettant d’identifier directement des individus. Elle constitue un maillon essentiel pour garantir la conformité éthique et réglementaire des dépôts de données, en particulier lorsqu’ils contiennent des éléments visuels.

Les objectifs de l'UA sont les suivants :

— Assurer la confidentialité en anonymisant systématiquement les fichiers multimédia déposés.

— Proposer un service autonome, utilisable indépendamment de SPIDER, pour que des utilisateurs externes puissent également soumettre des données à anonymiser.

— S’intégrer dans la chaîne SPIDER en transmettant automatiquement, après traitement, les fichiers conformes au système de stockage.

— Notifier l'utilisateur une fois l'anonymisation terminée, afin qu'il puisse compléter son dépôt en renseignant les métadonnées scientifiques sur l'interface SPIDER.

— Garantir la transparence du processus en associant au dépôt des informations décrivant le traitement appliqué.

Concrètement, l'utilisateur effectue son dépôt initial sur l'UA. Après anonymisation des fichiers visuels, ceux-ci sont transférés vers SPIDER. L'utilisateur est ensuite prévenu de la fin du traitement et invité à compléter son dépôt en renseignant les métadonnées associées via l'interface web SPIDER.
# Chapitre 3

## État de l'art

### I Modèles IA pour l'anonymisation visuelle

Les cibles principales de l'anonymisation sont : visage, silhouette, mains/peau et signes distinctifs (tatouages, logos, plaques, vêtements rares). Les vecteurs de ré-identification incluent la reconnaissance faciale, le *person re-ID* (silhouette + vêtements), les corrélations spatiales/temporales et les métadonnées (EXIF, GPS). L'objectif est de réduire la probabilité de ré-identification sous un seuil mesurable, tout en préservant l'utilité des données pour les tâches aval.

#### I.1 Détection, segmentation et suivi vidéo

La première étape du processus d'anonymisation consiste à localiser précisément les objets d'intérêt (par exemple les silhouettes humaines ou certaines parties du corps) afin de générer les masques nécessaires à la protection des données visuelles. Cette étape combine deux tâches principales de vision par ordinateur : la détection d'objets et la segmentation d'instance.

##### I.1.1 Détection d'objets

La détection d'objets consiste à identifier la présence et la position de catégories spécifiques dans une image. Plusieurs familles d'architectures coexistent :

- **Faster R-CNN** : Introduit en 2015, Faster R-CNN (*Faster Region-based Convolutional Neural Network*) est une architecture de détection d'objets en deux étapes. Dans un premier temps, un module appelé *Region Proposal Network* (RPN) génère un ensemble de régions candidates susceptibles de contenir des objets. Dans un second temps, chaque région est affinée par un réseau convolutionnel qui prédit à la fois la classe de l'objet et ajuste les coordonnées de la boîte englobante. Ce découplage permet une excellente précision, notamment pour les petites cibles ou en présence d'occlusions. Cependant, la double passe sur les données entraîne un coût computationnel élevé, ce qui le rend moins adapté aux contraintes de latence stricte ou aux applications temps réel. Faster R-CNN reste toutefois une référence dans les contextes où la précision prime sur la vitesse, comme l'imagerie médicale ou l'analyse hors ligne.

- **YOLO (You Only Look Once)** : YOLO est une famille de modèles dits *single-shot*, où la détection se fait en une seule passe sur l'image. L'idée clé est de diviser l'image
en une grille et de prédire, pour chaque cellule, un ensemble de boîtes englobantes et de scores de confiance, ainsi que les probabilités d'appartenance à chaque classe. Cette conception élimine l'étape intermédiaire de génération de propositions, réduisant ainsi considérablement la latence. Les versions successives (v3 à v8) ont amélioré à la fois la précision et la vitesse grâce à des optimisations architecturales (réseaux plus profonds et plus légers, nouvelles fonctions d'ancrage, meilleurs algorithmes de non-max suppression). La variante YOLO-seg intègre un module de segmentation d'instance, produisant directement un masque pour chaque objet détecté. Cela permet d'obtenir un contour plus précis qu'une simple boîte, ce qui est particulièrement pertinent pour l'anonymisation, où il est souhaitable d'épouser au mieux la forme réelle d'un visage ou d'une silhouette. Bien que conçu pour le temps réel, YOLO-seg peut aussi être exploité dans un pipeline hors ligne, offrant un bon compromis entre rapidité et qualité de segmentation.

— DETR (DEtection TTransformer) : DETR, introduit par Facebook AI Research en 2020, repose sur l'architecture des Transformers, popularisée dans le traitement du langage naturel. Contrairement aux approches traditionnelles qui utilisent des ancrés (anchor boxes) et de multiples heuristiques, DETR formule la détection d'objets comme un problème d'appariement bipartite entre un ensemble fixe de prédicitions et les objets réels dans l'image. Un backbone convolutionnel (souvent ResNet) extrait des caractéristiques visuelles, puis un encodeur-décodeur Transformer modélise les relations spatiales globales entre pixels. Ce mécanisme d'attention globale permet au modèle de capturer des dépendances à longue portée, améliorant la robustesse dans les scènes complexes ou encombrées. DETR simplifie la pipeline de détection en supprimant des composants ad hoc, mais souffre d'un temps d'entraînement plus long et d'une convergence lente. Des variantes (Deformable DETR, DN-DETR) ont été proposées pour accélérer le processus tout en conservant les avantages de l'attention globale.

<table><caption>TABLE 3.1 – Comparaison des principales architectures de détection d'objets</caption><thead><tr><td>Modèle</td><td>Temps réel</td><td>Précision élevée</td><td>Segmentation intégrée</td><td>Simplicité d'intégration</td></tr></thead><tbody><tr><td>Faster R-CNN</td><td>✗</td><td>✓✓</td><td>✗</td><td>✗</td></tr><tr><td>YOLO</td><td>✓</td><td>✓</td><td>✓(YOLO-seg)</td><td>✓✓</td></tr><tr><td>DETR</td><td>✗</td><td>✓</td><td>Partiel</td><td>✓</td></tr></tbody></table>

### I.1.2 Pistes d'amélioration : pose et suivi multi-objets

Plusieurs évolutions pourraient renforcer la précision et la stabilité de l'anonymisation dans des scénarios complexes.

D'une part, l'utilisation de méthodes d'estimation de pose comme OpenPose, HRNet ou Keypoint R-CNN permettrait de localiser précisément des points clés du corps (yeux, coudes, genoux, mains, etc.). Cela ouvrirait la possibilité d'un masquage sélectif, ciblant uniquement les zones réellement sensibles (par exemple le visage et les mains) et préservant ainsi une plus grande partie du contenu visuel utile. Cette approche serait particulièrement pertinente dans les contextes où la conservation du maximum d'informations non sensibles est essentielle, par exemple pour des analyses comportementales ou biomécaniques.

D'autre part, pour les séquences vidéo, l'intégration d'un **suivi multi-objets** (Multi-Object Tracking – MOT) permettrait de maintenir la cohérence des masques d'une image à l'autre. Des méthodes comme DeepSORT (détection + descripteur visuel), ByteTrack (robuste aux détections de faible confiance) ou OC-SORT (optimisation des trajectoires) garantiraient qu'un
même objet conserve le même masque tout au long de sa trajectoire, réduisant les scintillements et les erreurs d'alignement.

Bien que le pipeline actuel fonctionne en offline image par image et ne nécessite pas encore ce type de suivi, ces deux améliorations seraient indispensables pour une évolution vers un traitement **temps réel** ou pour l'anonymisation de vidéos complexes, tout en optimisant le compromis entre confidentialité et utilité des données.

### I.1.3 Cas difficiles

Certaines situations restent problématiques pour les algorithmes de détection et de segmentation :

- *Foules denses* : occlusions partielles entre individus.

- *Occlusions* : objets partiellement cachés.

- *Angles extrêmes* : vues plongeantes ou rasantes.

- *Faible luminosité* : images bruitées, éclairage nocturne.

Ces cas nécessitent des modèles robustes et, éventuellement, un pré-traitement spécifique (amélioration de la luminosité, débruitage).

## I.2 Méthodes d'anonymisation

Lorsqu'un objet sensible est détecté par le modèle, plusieurs stratégies peuvent être envisagées pour assurer la protection des données personnelles visuelles :

- **Suppression du fichier** : solution radicale, garantissant l'absence totale de fuite d'informations mais entraînant la perte complète des données, y compris des zones non sensibles.

- **Masquage complet de l'image** : application d'un filtre sur l'intégralité du contenu, conservant le fichier mais supprimant toute information exploitable.

- **Blocage rectangulaire** : recouvrement par un rectangle uniforme englobant la zone détectée ; méthode simple mais impliquant une perte d'information sur une zone souvent plus large que nécessaire.

- **Masquage ajusté à la silhouette** : génération d'un masque précis épousant la forme de l'objet détecté, permettant de préserver un maximum de contexte visuel tout en protégeant les zones sensibles.

### I.2.1 Masques

Dans le cadre de l'anonymisation, un **masque** est une image binaire ou à niveaux de gris générée par un algorithme de détection ou de segmentation, qui délimite avec précision les zones contenant des informations personnelles — visages, silhouettes, mains, tatouages, ou tout autre élément distinctif. Les valeurs hautes du masque correspondent aux régions à protéger, sur lesquelles sont appliquées diverses **techniques de masquage** (ou **filtres d'anonymisation**) telles que le floutage, la pixelisation, le recouvrement opaque ou l'inpainting. Les valeurs basses désignent les zones à conserver inchangées. Ce procédé agit comme un « pochoir numérique » permettant de cibler sélectivement les zones sensibles tout en préservant l'intégrité visuelle et l'utilité des autres parties de l'image. Il constitue ainsi un outil essentiel pour garantir la confidentialité des données visuelles et se conformer aux exigences réglementaires telles que le RGPD.
**Masquage conditionnel** Le masquage conditionnel consiste à adapter dynamiquement la méthode et l'étendue du masquage en fonction du type d'objet détecté, du niveau de sensibilité de l'information et du contexte d'utilisation. Par exemple, on peut se limiter à un floutage du visage pour un risque faible, recourir à une pixelisation ou un recouvrement complet pour un risque moyen, ou encore masquer l'intégralité de la silhouette dans des contextes à haut risque de ré-identification.

### I.2.2 Filtres d'anonymisation

- *Floutage* : application d'un filtre de flou (gaussien, moyen ou de mouvement) pour rendre les détails indiscernables tout en conservant les formes générales. Temps de calcul : faible, traitement rapide adapté aux flux vidéo temps réel.

- *Pixelisation* : réduction de la résolution locale en agrandissant artificiellement les pixels, supprimant ainsi les détails fins. Temps de calcul : très faible, l'une des méthodes les plus rapides, idéale pour le traitement à grande échelle.

- *Recouvrement opaque* : remplacement de la zone masquée par une couleur unie ou un motif, garantissant l'absence totale d'information visuelle. Temps de calcul : très faible, opération quasi instantanée même sur de grands volumes d'images.

- *Inpainting* : remplissage intelligent de la zone masquée à partir du contexte environnant, afin de la rendre visuellement cohérente tout en supprimant l'information sensible. Temps de calcul : élevé, surtout pour les méthodes basées sur des réseaux neuronaux ou des algorithmes complexes, moins adapté aux besoins temps réel.

<table><caption>TABLE 3.2 – Comparaison des filtres d'anonymisation</caption><thead><tr><td>Filtre</td><td>Protection forte</td><td>Qualité visuelle</td><td>Temps de calcul</td></tr></thead><tbody><tr><td>Floutage</td><td>✓</td><td>✓</td><td>Faible</td></tr><tr><td>Pixelisation</td><td>✓</td><td>Partiel</td><td>Très faible</td></tr><tr><td>Recouvrement opaque</td><td>✓✓</td><td>✗</td><td>Très faible</td></tr><tr><td>Inpainting</td><td>✓✓</td><td>✓✓</td><td>Élevé</td></tr></tbody></table>

## II Infrastructures et chaîne de traitement des données

La mise en place d'un module d'anonymisation nécessite une infrastructure logicielle adaptée au volume et au type de données traitées, ainsi qu'aux contraintes de performance et de conformité. Dans la littérature et les solutions industrielles, plusieurs approches se distinguent, chacune présentant des avantages et des limites.

### II.1 Styles d'architecture

- **Monolithes intégrés**

L'anonymisation est directement incluse dans une plateforme globale de gestion de données (ex. système d'information hospitalier).

*Avantages* : intégration forte, déploiement centralisé.
*Limites*: couplage fort, évolutivité réduite, dépendance aux cycles de mise à jour du système principal.

*Cas d'usage*: petites équipes, périmètre stable, environnement unique.

## Micro-services API

Service indépendant accessible via REST ou GraphQL, souvent conteneurisé.

*Avantages*: réutilisable dans plusieurs systèmes, scalable horizontalement.

*Limites*: nécessite une orchestration et un suivi des appels.

*Cas d'usage*: intégration dans un SI complexe, échanges entre plusieurs applications.

## Batch offline

Traitement planifié à intervalles réguliers via un ordonnanceur (cron, Airflow, Luigi, Prefect).

*Avantages*: robustesse, simplicité, adapté aux gros volumes.

*Limites*: latence entre l'arrivée des données et leur traitement.

*Cas d'usage*: traitement nocturne, forte volumétrie, absence de contrainte temps réel.

## Architectures hybrides

Combinaison d'une API pour le traitement ponctuel et d'un batch pour les volumes massifs, éventuellement orchestrés par un bus de messages (Kafka, RabbitMQ).

*Avantages*: polyvalence, flexibilité.

*Limites*: complexité accrue de déploiement et de supervision.

*Cas d'usage*: besoins mixtes (temps réel + batch), intégrations multiples.

<table><caption>TABLE 3.3 – Comparaison des styles d'architecture pour l'anonymisation</caption><thead><tr><th>Style</th><th>Scalabilité</th><th>Simplicité</th><th>Latence faible</th><th>Adapté gros volumes</th></tr></thead><tbody><tr><td>Monolithique</td><td>✗</td><td>✓</td><td>✓</td><td>✗</td></tr><tr><td>Micro-service API</td><td>✓</td><td>Partiel</td><td>✓</td><td>Partiel</td></tr><tr><td>Batch offline</td><td>Partiel</td><td>✓✓</td><td>✗</td><td>✓✓</td></tr><tr><td>Hybride</td><td>✓✓</td><td>Partiel</td><td>✓</td><td>✓</td></tr></tbody></table>

## II.2 Technologies de couche API

Parmi les frameworks API en Python, trois approches dominent :

- **Flask**: léger, simple à mettre en œuvre, adapté aux besoins personnalisés.

- **FastAPI**: performances élevées, support natif d'OpenAPI, validation de données intégrée.

- **Django REST Framework**: robuste, complet, adapté aux gros projets web.

<table><caption>TABLE 3.4 – Comparaison des frameworks API</caption><thead><tr><th>Framework</th><th>Performance</th><th>Simplicité</th><th>Fonctionnalités avancées</th></tr></thead><tbody><tr><td>Flask</td><td>Partiel</td><td>✓✓</td><td>Partiel</td></tr><tr><td>FastAPI</td><td>✓✓</td><td>✓</td><td>✓✓</td></tr><tr><td>Djang REST Framework</td><td>Partiel</td><td>Partiel</td><td>✓✓</td></tr></tbody></table>
## II.3 Technologies de planification

Pour l'orchestration et la planification des traitements, on distingue :

- cron : ordonnanceur Unix minimaliste, simple et fiable.

- Airflow / Prefect : orchestrateurs avancés pour pipelines complexes.

- Systèmes événementiels (Kafka, RabbitMQ) : déclenchement à l'arrivée d'un fichier ou d'un message.

<table><caption>TABLE 3.5 – Comparaison des solutions de planification</caption><thead><tr><th>Solution</th><th>Simplicité</th><th>Adaptée gros volumes</th><th>Réactivité temps réel</th></tr></thead><tbody><tr><td>cron</td><td>✓✓</td><td>Partiel</td><td>✗</td></tr><tr><td>Airflow / Prefect</td><td>Partiel</td><td>✓✓</td><td>Partiel</td></tr><tr><td>Kafka / RabbitMQ</td><td>✗</td><td>✓✓</td><td>✓✓</td></tr></tbody></table>

## III Conclusion

L'étude comparative des approches de détection et de segmentation a conduit au choix d'un modèle YOLO avec module de segmentation YOLO-seg, reconnu pour son excellent compromis entre précision, vitesse et simplicité d'intégration. Ce modèle permet d'identifier efficacement les silhouettes humaines dans des contextes variés et de générer des masques précis épousant leur forme réelle, limitant ainsi le masquage aux seules zones pertinentes. Les masques sont appliqués sous forme unicolore, méthode garantissant l'effacement complet des informations personnelles tout en préservant un maximum de contexte visuel afin de maintenir la valeur analytique des images. Ce parti pris répond à un double objectif : respect strict du RGPD et préservation de l'utilité des données.

Sur le plan logiciel, l'unité d'anonymisation a été pensée pour évoluer vers un micro-service indépendant, évitant toute adhérence forte avec le projet SPIDER auquel elle est actuellement rattachée. Cette approche facilite le déploiement dans d'autres environnements ou projets futurs. L'architecture repose sur Flask, choisi pour sa légèreté et sa flexibilité dans la mise en place rapide d'API sur mesure, ainsi que sur cron, solution simple et fiable pour orchestrer les traitements par lots à intervalles réguliers.

Enfin, cette conception laisse une marge d'évolution importante. L'architecture retenue permet d'intégrer ultérieurement des orchestrateurs plus avancés (Airflow, Prefect) ou des architectures événementielles (Kafka, RabbitMQ) pour un traitement quasi temps réel. De même, l'utilisation d'un modèle YOLO rapide ouvre la voie à une anonymisation live et à l'ajout de fonctionnalités telles que le suivi multi-objets ou l'estimation de pose pour un masquage encore plus sélectif.
# Chapitre 4

## Mise en place d'un environnement de travail

### I Configuration de l'environnement de développement

La mise en place d'un environnement de développement cohérent et reproductible a été une étape clé pour assurer la fiabilité du code et faciliter sa maintenabilité. L'objectif était de garantir que le projet puisse être exécuté dans des conditions identiques sur différentes machines, tout en restant simple à déployer et à faire évoluer.

#### I.1 Environnements virtuels et gestion des dépendances

Afin d'éviter les conflits de versions et d'isoler les dépendances nécessaires au projet, l'utilisation d'environnements virtuels est incontournable. En Python, le module `venv` permet de créer un environnement isolé qui contient ses propres interpréteur et bibliothèques, ce qui évite les interférences entre les dépendances des différents projets.

**pyproject.toml :**

Pour la gestion des dépendances et la configuration des outils de build, le fichier `pyproject.toml` a été utilisé conformément aux recommandations de la Python Packaging Authority (PyPA). Ce fichier centralise les métadonnées du projet, les dépendances, ainsi que les configurations des outils de formatage et de linting. Voici un exemple simplifié de structure :

```toml
[project]
name = "mon_projet"
version = "1.0.0-beta"

requires-python = ">=3.8"

dependencies = [...]
```

L'utilisation de `pyproject.toml` permet de simplifier le partage et la réinstallation des dépendances sur d'autres machines avec la commande `pip install`.
## I.2 Versionnage et dépôt GitHub

Le projet a été hébergé sur un dépôt GitHub afin de centraliser le code source et d'assurer son suivi dans le temps. Le développement a été effectué en autonomie, avec des revues de principe régulières mais sans revue de code externe, et en travaillant directement sur la branche main. Bien que cette configuration soit suffisante pour un projet individuel, l'utilisation de branches dédiées et de revues de code pourrait être envisagée pour un développement collaboratif futur.

## I.3 Structure du code

Le code a été structuré de manière modulaire afin de séparer clairement les différentes responsabilités : logique d'anonymisation, API, scripts de traitement par lots et outils utilitaires. L'arborescence générale du projet est la suivante :

<figure><img src="image_4.png" /></figure>

## I.4 Conventions de documentation

Chaque fonction définie dans le code est accompagnée d'une docstring décrivant son objectif, ses paramètres, ses valeurs de retour et, le cas échéant, les exceptions levées. Cette documentation interne facilite la lecture et la maintenance du code, et constitue une base pour une génération automatisée de documentation si nécessaire.

# II Développement et déploiement

## II.1 Développement

Le développement s'est effectué dans mon espace personnel $HOME (répertoire du projet et environnement virtuel). Pour valider les flux de bout en bout, deux comptes de test `usertest1` et `usertest2` ont été créés. Un petit script génère des *batches* de test zippés avec une répartition aléatoire d'images et de vidéos, puis les dépose automatiquement dans les répertoiries des utilisateurs de test afin d'alimenter la chaîne (priorisation, anonymisation, fichiers d'état, notifications).

Les essais du serveur se font en local, en lançant deux terminaux via `screen`: le premier exécute l'API Flask, le second envoie des requêtes HTTP brutes. Exemple minimal :

```
$ screen -S au-dev
# Fenêtre 0 (serveur) :
(venv)$ python -m flask --app src/anonymization_server:app run --port 5000
```
```
# Fenêtre 1 (requêtes) :
$ telnet 127.0.0.1 5000
GET /etat/usertest1/<batch_id> HTTP/1.1
Host: 127.0.0.1:5000
```

En parallèle, des appels `curl` (`GET /etat/<user_id>/<batch_id>`) permettent d'inspecter rapidement les réponses 202/200/404. Le fonctionnement continu de l'unité repose sur le duo **API Flask** (requêtes ponctuelles) + **tâches cron** (vidage de file, notifications, nettoyage).

## II.2 Déploiement

Le déploiement s'effectue dans `/opt/AnonymizationUnit`, distinct de l'espace de développement en `$HOME`. Cette séparation facilite les mises à jour (atomiques) et la disponibilité continue de l'API.

### Procédure d'installation (extraits de README.md) :

```
sudo mkdir -p /opt/AnonymizationUnit
sudo chown -R <admin>:<admin> /opt/AnonymizationUnit
cd /opt/AnonymizationUnit
git clone https://github.com/m-gautier03/anonymization-unit.git .
python3 -m venv .venv
source .venv/bin/activate
pip install .
# Placer le poids YOLO (ex. yolo11m-seg.pt) à la racine du projet
```

### Ouverture du serveur (réseau).

```
cd /opt/AnonymizationUnit
source .venv/bin/activate
/opt/AnonymizationUnit/.venv/bin/python -m flask \
--app src/anonymization_server:app run \
--host 0.0.0.0 \
--port 5000
```

(En production interne, un WSGI type `gunicorn` et/ou un reverse proxy restent optionnels.)

### Automatisation (cron) :

Un traitement quasi temps réel est implémenté par une exécution toutes les minutes des scripts, et un nettoyage nocturne est effectué quotidiennement.

### Lancement manuel (débogage).

Les tests d'API peuvent être effectués depuis une seconde fenêtre (ex. `screen`) pour observer les réponses 202/200/404 et les journaux en direct.
# Chapitre 5

## Unité d'anonymisation

L'unité d'anonymisation constitue le cœur de mon stage, et l'essentiel de mon travail s'est concentré sur sa conception et son développement. Elle représente l'infrastructure dans laquelle est exécuté l'ensemble du processus d'anonymisation des fichiers multimédias, depuis la réception des données jusqu'à leur restitution, une fois traitées et validées. Cette unité intègre notamment le modèle anonymiseur, chargé de détecter et d'anonymiser les présences humaines.

Chaque dépôt effectué sur l'unité d'anonymisation correspond à un dépôt parallèle sur l'interface web de SPIDER. Un dépôt est appelé "batch", puisque qu'un seul jeu de données peut être divisé en plusieurs dépôts.

Pour chaque fichier du batch, les métadonnées EXIF sont extraites puis sauvegardées, avant que le modèle anonymiseur ne traite le contenu et génère une sortie temporaire. Un fichier d'état, mis à jour en continu, décrit l'avancée du traitement et associe à chaque fichier l'un des statuts suivants :

- *done* : traitement correct;

- *processing* : fichier en cours de traitement;

- *warning* : fichier traité avec une confiance inférieure au seuil défini;

- *error* : aucun autre état applicable.

Les fichiers en état *warning* ou *error* nécessitent une validation manuelle. L'utilisateur reçoit une notification par e-mail listant les fichiers concernés. Chaque fichier peut alors être validé (et conservé) ou rejeté (et supprimé du répertoire de sortie). Les fichiers rejetés devront être anonymisés manuellement par l'utilisateur, puis redéposés.

Une fois les données validées, l'utilisateur procède au renseignement des métadonnées contextuelles de son jeu de données sur le site internet de SPIDER en référençant le répertoire de sortie de l'unité. SPIDER récupère alors les fichiers et les stocke de manière pérenne dans ses bases (MongoDB pour les métadonnées, Ceph pour les fichiers).

Le fonctionnement général de l'unité d'anonymisation est présenté schématiquement dans la figure suivante :
<figure><img src="image_5.png" /><figcaption>FIGURE 5.1 – Schéma général de l’unité d’anonymisation</figcaption></figure>

# I Architecture fonctionnelle

L’unité d’anonymisation est intégralement développée en **Python** et repose sur une structure de type ETL (*Extract, Transform, Load*). Elle est composée de plusieurs modules coopérant selon une logique de pipeline.

## I.1 Procédure de traitement

Le traitement d’anonymisation suit les étapes suivantes (voir figure 5.2) :

1. L’utilisateur dépose ses données dans le sous-répertoire **INPUT** de son espace utilisateur. Chaque dépôt est appelé *batch*.

2. Le **Dispatcher** calcule la priorité de chaque batch en fonction du rapport entre son âge et sa taille.

3. Le **Pipeline Manager** sélectionne le batch prioritaire et déclenche son traitement via le **Worker 1**.

4. Le **Worker 1** parcourt les fichiers du batch et effectue :

- extraction des métadonnées EXIF;

- appel au modèle de deep learning anonymiseur;

- mise à jour du fichier d’état;

- sauvegarde du fichier anonymisé dans le répertoire **OUTPUT** de l’utilisateur.

5. Une fois le batch traité, le **Worker 2** inspecte le fichier d’état. En cas de présence de fichiers en *warning* ou *error*, une notification est envoyée à l’utilisateur.

6. Le serveur surveille le fichier d’état et, lorsque tous les fichiers sont en état *done*, il compresse le répertoire **OUTPUT** et le transmet à SPIDER via une API.

7. Le **Scheduler** orchestre la fréquence d’exécution du Pipeline Manager pour maintenir un fonctionnement quasi temps-réel.

8. Enfin, le **Stale Batch Manager** libère automatiquement l’espace de stockage en supprimant les batchs inactifs ou abandonnés.
<figure><img src="image_6.png" /><figcaption>FIGURE 5.2 – Architecture fonctionnelle de l’unité d’anonymisation</figcaption></figure>
## II Serveur et API

L'unité d'anonymisation repose sur un serveur central chargé de la coordination des proces-
sus et de la communication avec SPIDER. Un web-service expose une API permettant :

- la surveillance de l'état des traitements;

- la compression et le transfert des sorties vers SPIDER;

- la suppression des données locales après confirmation de stockage.

Ce mécanisme assure l'intégrité du flux de données et une intégration fluide avec l'infra-
structure SPIDER.

## III Modèle anonymiseur

Le modèle anonymiseur repose sur une variante segmentation d'Ultralytics YOLO (poids par défaut yolo11m-seg.pt). Il est configuré pour détecter les personnes (classes=[0]) puis appliquer un masquage polygonal noir sur chaque instance détectée (Figure 5.3). Le seuil de confiance τ est fourni par la configuration de lot (confThr dans config.csv) et pilote la qualification warning des fichiers.

**Gestion de la confiance — image :**

Pour une image donnée, le modèle renvoie des boîtes (boxes) et des masques (masks). Les polygones des masques sont remplis en noir (anonymisation) et le fichier est classé selon :

- *done* si toutes les détections ont une confiance $\ge \tau$ (sauvegarde en OUTPUT/<batch>);

- *warning* s'il existe au moins une détection avec confiance $< \tau$ (copie dans le répertoire <batch>_defects pour revue manuelle).

Dans les deux cas, l'image anonymisée est produite, et pour les images en *done*, les métadonnées EXIF extraites sont conservées dans *metadata.json*.

**Gestion de la confiance — vidéos :**

Le flux vidéo est traité image par image. Pour chaque frame :

- si toutes les détections ont une confiance $\ge \tau$, les masques de segmentation sont remplis (anonymisation fine par polygones);

- si *au moins une* détection a une confiance $< \tau$, la frame entière est noircée (blackout) afin d'éliminer tout risque de ré-identification.

Les périodes consécutives de frames en blackout sont agrégées en *intervalles* et exportées dans un CSV (*start*, *end*, format HH:MM:SS). En aval, le worker applique une règle métier : si un intervalle dépasse un seuil vidéo (paramètre *warn_sec*), le fichier est marqué *warning* ; sinon *done* . La vidéo anonymisée est sauvegardée dans *OUTPUT/<batch>*.

**Sorties et structure.** Les résultats sont organisés ainsi :

- *OUTPUT/<batch>* : fichiers anonymisés *validés* (images et vidéos), *status.json*, *metadata.json*;

- *INPUT/<batch>/<batch>_defects* : images en *warning* et CSV des intervalles de blackout vidéo.
**Robustesse et limites.** Le choix de noircir entièrement une frame vidéo dès qu'une détection est sous τ maximise la protection de la vie privée en cas d'incertitude du modèle. À l'inverse, pour les images, la décision *warning* déclenche une revue humaine tout en conservant une anonymisation polygonale. Des améliorations possibles incluent le *warm-up* du modèle au niveau du lot (éviter un rechargement par fichier) et l'exposition de *warn_sec* dans la configuration utilisateur.

<figure><img src="image_7.png" /><figcaption>Image avant traitement</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Image après traitement (masques noirs)</figcaption></figure>

FIGURE 5.3 – Exemple d’anonymisation sur image fixe<fnref n="1" />

<footnote n="1">1. Image libre de droit. Crédit : *Jeune femme souriante en robe de travail bleue, fermière professionnelle engagée dans l'élevage de vaches, jouant avec un petit veau dans une stalle ouverte le jour d'automne* — 11 février 2025, via Shutterstock (image 2584458725).</footnote>
# Chapitre 6

## Description Technique

### I Dépôt d'un jeu de données

#### I.1 Contenu d'un dépôt (batch)

Un dépôt s'effectue sous forme d'un fichier **.ZIP** contenant :

- Les fichiers multimédia à anonymiser;

- Un fichier nommé exactement *config.csv*;

- D'autres fichiers ou sous-dossiers éventuels non relatifs à l'anonymisation qui participent à l'ensemble du jeu de données.

**Fichier config.csv**

Le fichier *config.csv* est essentiel au bon fonctionnement du processus d'anonymisation.

Il joue deux rôles principaux :

- Permettre l'envoi d'e-mails à l'utilisateur afin de l'informer de l'avancement du traitement ou des problèmes rencontrés;

- Contrôler certains paramètres d'anonymisation afin d'adapter le fonctionnement du modèle aux besoins de l'utilisateur.

- **name** | prénom :

*Chaîne de caractères sans espace, optionnel*

Champ facultatif. Sert uniquement à titre informatif dans les journaux de traitement ou pour faciliter le suivi de l'utilisateur.

- **lastname** | nom :

*Chaîne de caractères sans espace, optionnel*

Champ facultatif. Comme le prénom, il est uniquement utilisé à des fins de traçabilité dans les journaux de traitement ou pour faciliter le suivi de l'utilisateur.

- **email** :

*Chaîne de caractères sans espace, obligatoire*

Adresse e-mail permettant à l'unité d'anonymisation de notifier l'utilisateur à chaque étape clé du processus : fin de traitement, succès, avertissement ou erreur. Ce champ est indispensable au bon déroulement du processus : en son absence, le dépôt est interrompu.
— confThr (Confidence Threshold) | seuil de confiance :

Nombre compris entre 0 et 1, 0.25 par défaut

La confiance est une valeur calculée par le modèle d'IA représentant la probabilité qu'un objet détecté soit une silhouette humaine. Ce seuil détermine à partir de quelle certitude une image peux être considérée comme "correctement anonymisée".

— 0.25 : détection large, risque de masquer des objets non humains.

— 0.80 et plus : détection stricte, risque de laisser passer certaines silhouettes humaines.

— owPrevBatch (overwrite previous batch) | écraser dépôt précédent :

Booléen : true / false, optionnel, false par défaut

Lorsque cette option est activée (true), le dépôt remplace un précédent portant exactement le même nom. Cela peut être utile en cas de nouveau dépôt après correction. Si la valeur est false, les dépôts précédents sont conservés et chaque soumission est identifiée par sa date et son heure d'extraction depuis le .ZIP initial.

— ProcessingMode | mode de traitement :

Entier : 1 pour l'anonymisation

Indique le type de traitement appliqué au jeu de données. La valeur 1 correspond au mode d'anonymisation standard. Les autres valeurs sont réservées à un usage interne pour effectuer des tests ou accéder de potentielles futures fonctionnalités lors de leur développement non accessibles aux utilisateurs.

Config.csv

name, lastname, email, confThr, owPrevBatch, ProcessingMode

xxxx,xxxx,xxx@inrae.fr,0.25假,1

## I.2 Exportation sur l'unité d'anonymisation

Un compte utilisateur permettant d'accéder à la machine virtuelle hébergeant l'unité d'anonymisation est créé pour chaque scientifique souhaitant effectuer un dépôt. L'automatisation de la création de ces comptes a été envisagée, mais ne fait pas partie du périmètre du stage et sera développée ultérieurement.

Chaque compte utilisateur est initialisé avec deux sous-répertoires par défaut : INPUT et OUTPUT.

— INPUT : répertoire dans lequel l'utilisateur dépose ses fichiers à traiter ;

— OUTPUT : répertoire à accès restreint, uniquement modifiable par un administrateur du serveur. C'est dans ce répertoire que sont placés les résultats après anonymisation.

<figure><img src="image_9.png" /></figure>

L'unité d'anonymisation ne disposant pas d'interface graphique, les utilisateurs déposent leurs données via le protocole Secure Copy Protocol (SCP) directement depuis un terminal de
leur machine locale :

```
scp <chemin_du_fichier_zip> <user>@147.100.202.199:~/INPUT/
```

Le protocole *Secure Copy Protocol (SCP)* est un protocole de transfert de fichiers sécurisé reposant sur SSH (*Secure Shell*). Il permet de copier des fichiers entre une machine locale et une machine distante (ou entre deux machines distantes) en garantissant à la fois la confidentialité et l'intégrité des données transférées, grâce au chiffrement fourni par SSH.

Dans le cadre de l'unité d'anonymisation, SCP est utilisé pour assurer :

- un transfert sécurisé des données;

- une authentification forte des utilisateurs grâce à leurs identifiants de connexion;

- la simplicité d'utilisation (commande unique directement depuis un terminal).

# II Processus d'anonymisation

Le processus d'anonymisation est régi par les scripts du sous-répertoire core/ :

<figure><img src="image_10.png" /></figure>

## II.1 Pipeline Manager

Le *Pipeline Manager* est l'agent qui orchestre l'ensemble de la chaîne de traitement des dépôts à anonymiser. Il est implémenté dans le script `src/core/pipeline_manager.py` et se charge de détecter les nouveaux lots, de les extraire, de préparer les répertoires et fichiers d'état, de séquencer le traitement par un processus *worker*, puis de notifier l'utilisateur en fin d'exécution. Les journaux d'activité sont centralisés dans un fichier de log dédié.

**Déclenchement (cron).** Le script est déclenché toutes les minutes par le planificateur cron, et ses sorties sont redirigées vers un fichier de log :

```
* * * * * /opt/AnonymizationUnit/src/core/pipeline_manager.py >>
/opt/AnonymizationUnit/pipeline_log.txt 2>&1
```
**Entrées / sorties.** Le pipeline n'a ni entrées ni sorties à proprement parler, mais il produit les résultats anonymisés de l'ensemble des batchs présents sur la machine virtuelle de l'unité d'anonymisation au moment de son exécution. Ainsi, de manière générale, on peut considérer qu'au travers des diverses fonctions qu'il appelle et des scripts qu'il exécute, il a pour entrées et sorties :

- **Entrées** : l'ensemble des batchs .zip présents dans les répertoires INPUT de chaque utilisateur de l'unité d'anonymisation;

- **Sorties** : l'ensemble des batchs anonymisés générés dans les répertoires OUTPUT de chaque utilisateur de l'unité d'anonymisation, contenant les fichiers anonymisés, un fichier d'état, un fichier de métadonnées EXIF, ainsi que les autres fichiers éventuels figurant dans le batch d'entrée.

**Fonctionnement (vue d'ensemble).** Le point d'entrée `pipeline()` suit les étapes suivantes :

1. **Anti-concurrence globale** : création d'un verrou global `<pid>_global.lock`. Si un autre verrou global est présent (`another_instance_running`), le script se termine.

2. **Boucle de vidage de file** : interrogation du dispatcher via `get_next_batch()` (qui renvoie un couple composé du batch prioritaire et de son score de priorité) jusqu'à ce qu'il n'y ait plus de lots (`(None, None)`).

3. **Extraction** : chaque archive .zip est extraite dans un répertoire horodaté (via la fonction `extract_batch`). Si l'archive possède une racine commune, elle est retirée pour préserver une arborescence propre. L'archive source est supprimée après extraction.

4. **Nettoyage optionnel** : si la configuration (`config.csv`) contient `owPrevBatch=true`, les anciens lots au même base name sont supprimés (`delete_previous_batchs`).

5. **Fichier d'état initial** : création d'un status.json minimal contenant le hash du lot et la structure `files_status`.

6. **Anti-concurrence par lot** : création d'un verrou `<pid>_batch.lock` au niveau du répertoire de sortie du lot. S'il existe déjà un verrou de lot, le lot est ignoré pour éviter un double traitement.

7. **Délégation au worker** : lancement d'un sous-processus Python (`subprocess.run`) sur `worker_process_batch.py`, responsable du traitement fichier par fichier pour un batch.

8. **Notification** : en fin de traitement, envoi d'une notification utilisateur (`send notification`) indiquant le succès ou l'échec.

9. **Nettoyage** : suppression systématique des verrous (global et lot) dans les clauses `finally`, journalisation de fin.

**Mécanismes transverses.**

Toutes les étapes du pipeline s'appuient sur une journalisation centralisée (`log(...)`), produisant des messages formatés et explicites (démarrage/fin, extraction, suppression d'anciens lots, exécution du worker, erreurs, etc.), ce qui facilite le diagnostic en cas d'incident. Les erreurs du worker (`subprocess.CalledProcessError`) sont interceptées, notées en `ERROR`, puis le pipeline reprend avec le lot suivant. Les verrous (fichiers `.lock`) sont toujours retirés, même en cas d'échec, afin d'éviter tout blocage futur. La prévention des collisions repose sur un base name commun dérivé du répertoire (via `get_batch_base`); l'option `owPrevBatch` permet d'écraser automatiquement les versions antérieures. L'ensemble de ces comportements est piloté par le fichier de configuration `config.csv`, notamment pour la suppression des anciens lots et les paramètres de notification.
**Organisation et limites.** Le code est structuré en modules spécialisés (`initialize_paths`, `get_next_batch`, `worker_process_batch`, `sendNotification`), ce qui assure une séparation claire entre orchestration et traitement métier. Les hypothèses principales sont que les archives sont valides et accessibles en écriture, que le *worker* est idempotent (un redémarrage ne cor-rompt pas l'état), et que la découverte des lots se fait uniquement via `get_next_batch`. Dans ces conditions, le gestionnaire fournit une orchestration robuste (verrous anti-concurrence), une traçabilité complète (journaux et fichier d'état JSON), et une intégration simple dans un environnement cron.

## II.2 Dispatcher

<figure><img src="image_11.png" /><figcaption>FIGURE 6.1 - Dispatcher</figcaption></figure>

Le Dispatcher (Figure 6.1) sélectionne le prochain lot à traiter en évitant les doublons et les collisions. Il est implémenté dans `src/core/dispatcher.py` et s'appuie sur des uti-litaires de découverte de lots et de journalisation (`tools.batch_utils.find_all_batches`, `tools.file_utils.log`). Trois fonctions principales structurent le module : `hash_generator`, `get_batch_priority` et `get_next_batch`.

**Entrées / sorties.** Le Dispatcher n'exécute pas le traitement métier ; il fournit uniquement le prochain lot éligible.

- **Entrées** : les archives d'entrée (`.zip`) trouvées par `find_all_batches` (`place` = "input", `type` = "zip"), ainsi que les répertoires de sortie existants (`find_all_batches` (`place` = "output", `type` = "dir")).

- **Sorties** : un couple (`batch_path`, `batch_hash`) correspondant à l'archive prioritaire et au hash SHA-256 du lot; ou (`None`, `None`) s'il n'existe aucun lot éligible.

**Fonctionnement (vue d'ensemble).** La fonction `get_next_batch` (`place` = "input") applique la logique suivante :

1. **Découverte** : récupération des candidats d'entrée (archives `.zip`) et des lots déjà produits (répertoires de output).

2. **Sauts des lots verrouillés** : tout lot d'entrée contenant un fichier `*_batch.lock` est ignoré pour éviter un double traitement.
3. **Identification par hash** : calcul du hash SHA-256 de l'archive via `hash_generator`. En cas d'échec, le lot est journalisé en `ERROR` et sauté.

4. **Détection de doublons** : pour chaque répertoire de sortie, lecture éventuelle du fichier d'état `<nom_sortie>_status.json` et comparaison de la clé `"hash"` avec `batch_hash`. Si égalité, le lot d'entrée est marqué déjà traité et ignoré.

5. **Retour** : le premier lot éligible (non verrouillé, non dupliqué) est retourné avec son hash ; sinon (`None`, `None`).

**Heuristique de priorité.** La priorité d'un lot est calculée par `get_batch_priority(batch_path)` à partir de l'âge et de la taille cumulée :

$$ score = \frac{\text{age en secondes}}{\text{taille en MB} + 1} $$

L'âge correspond au plus ancien `mtime` des fichiers du lot ; la taille est la somme des tailles des fichiers. Les métadonnées inaccessibles sont ignorées.

**Mécanismes transverses et robustesse.** Les erreurs sont journalisées via `log(..., level = "ERROR")` (par exemple lecture impossible d'un `status.json` ou échec de hachage), sans interrompre la sélection des lots suivants. Les fichiers `*_batch.lock` servent de garde-fou contre la concurrence au niveau lot ; les doublons sont évités par comparaison du SHA-256 stocké dans le `status.json` de sortie.

**Limites et hypothèses.** On suppose que les archives sont lisibles et suffisamment petites pour permettre un hachage en mémoire, que les fichiers `status.json` sont valides lorsqu'ils existent, et que la découverte repose exclusivement sur `find_all_batches`.

## II.3 Worker 1 : Traitement d'un dépôt (batch)

<figure><img src="image_12.png" /><figcaption>FIGURE 6.2 – Traitement d'un dépôt</figcaption></figure>

Le Worker 1 (Figure 6.2) exécute le traitement unitaire des fichiers d'un lot (anonymisation, métadonnées, statut). Il est implémenté dans `src/core/worker_process_batch.py` et s'appuie sur des utilitaires de configuration, d'E/S et de journalisation (`read_csv_value`, `load_json`,
`save_json`, `log`), ainsi que sur ultralytics.YOLO pour la détection/segmentation. Les fonctions principales sont `process_batch`, `process_file`, `init_files_status`, `is_valid_image`, `is_valid.video`, `_parse_hms_to_seconds` et `isVideo_warning`. Le traitement métier est choisi via `REGISTERED_FUNCTION5`.

## Entrées / sorties.

- **Entrées** : Un batch d'entrée sous forme de répertoire, avec le fichier de configuration `config.csv` (utilisation des clés `confThr`, `ProcessingMode`).

- **Sorties** : Le batch de sortie correspondant contenant les fichiers anonymisés dans `OUTPUT/<batch>`, `status.json` mis à jour (`files_status`), et `metadata.json` (EXIF des images traitées). Eventuellement, un répertoire `<batch>_defects` pour les images et vidéos anonymisées avec une faible confiance.

## Fonctionnement (vue d'ensemble).
La fonction `process_batch(batch_path)` suit les étapes suivantes :

1. **Chargement de la config** : lecture de `confThr` (seuil [0, 1]) et de `ProcessingMode` pour sélectionner la fonction de traitement dans `REGISTERED_FUNCTION5`.

2. **Chargement/initialisation des JSON** : `status.json` (au moins `"files_status": {})` et `metadata.json`.

3. **Préparation du statut** : `init_files_status` marque tous les médias éligibles en "processing" s'ils ne sont pas déjà présents.

4. **Déplacement des non-médias** : les fichiers non image/vidéo sont envoyés vers `OUTPUT` (copie pour les `.csv` de config).

5. **Boucle de traitement** : pour chaque image/vidéo, appel à `process_file` qui :

(a) charge le modèle YOLO (par défaut `yolo11m-seg.pt`);

(b) exécute la fonction `process_fn` (anonymisation pour `ProcessingMode = 1`) et supprime l'original après succès;

(c) met à jour `files_status`: `"done"`, `"warning"` (confiance basse ou coupure vidéo longue), ou `"ERROR"` en cas d'échec;

(d) pour les images : ajoute l'EXIF extrait (`extract_exif`) à `metadata.json`;

(e) pour les vidéos : vérifie les coupures (`isVideo_warning`) à partir des `.csv` de `<batch>_defects`.

6. **Nettoyage d'entrée** : suppression des `.csv` résiduels côté `INPUT`.

7. **Persistences** : sauvegarde de `status.json` et `metadata.json`.

8. **Compression** : archivage sous forme de zip des répertoires defects et du dépôt de sortie.

## Règles de statut et contrôles.

- **Images** : `"done"` si confiance `>= confThr`, `"warning"` sinon.

- **Vidéos** : recherche d'un fichier `csv <file_name>.csv` éventuel dans `<batch>_defects`; si il existe et si il renseigne une coupure (`end-start`) dépassant un certain seuil (par défaut 60s), alors le fichier est labellisé `"warning"`.

- **Erreurs** : toute exception dans `process_file` entraîne `"ERROR"` pour le fichier concerné et une sauvegarde immédiate du `status.json`.
**Mécanismes transverses.** La journalisation (`log`) trace chaque étape (démarrage/fin de lot, fichiers traités, avertissements, erreurs). Les fonctions utilitaires `_parse_hms_to_seconds` et `is.video_warning` assurent une interprétation robuste des intervalles HH:MM:SS des `.csv` vidéo (lignes invalides journalisées en WARN puis ignorées). Le worker évite de retraiter un fichier déjà présent en sortie en comparant les noms.

**Organisation et limites.** Le worker est conçu pour être relançable sans corrompre l'état (`files_status` persistant et filtrage par fichiers déjà présents en `OUTPUT`). Les verrous intervals sont gérés par le Pipeline Manager. Hypothèses : modèle YOLO disponible localement, droits d'écriture/lecture suffisants, `REGISTERED_FUNCTION`S correctement renseigné.

<figure><img src="image_13.png" /><figcaption>FIGURE 6.3 – Exemple d’arborescence finale pour l’utilisateur `userX`, avant et après compression</figcaption></figure>

## II.4 Worker 2 : Notification de fin de traitement

<figure><img src="image_14.png" /><figcaption>FIGURE 6.4 – Notification de fin de traitement</figcaption></figure>
Le *Worker 2* (Figure 6.4) gère les notifications de validation du traitement d'anonymisation. Il alerte l'utilisateur des erreurs de traitement et des fichiers signalés comme anonymisés avec une faible confiance. Un exemple de e-mail complet est consultable en Annexes, Figure 6.5. Il est implémenté dans `src/core/worker_notify_end_of_process.py` et s'appuie sur des utilitaires de configuration, d'E/S et de journalisation (`read_csv_value`, `load_json`, `save_json`, `log`).

## Entrées / sorties.

- **Entrées** : le `status.json` du lot (clé `files_status`), le fichier `config.csv` de configuration (clé `email` du destinataire), les identifiants d'envoi (`load_credentials`), et les chemins d'output (`initialize_paths`).

- **Sorties** : un courriel récapitulatif envoyé au destinataire, contenant la liste des fichiers en `warning/ERROR` et les instructions de récupération/transfert vers SPIDER ; traces de journalisation.

## Fonctionnement (vue d'ensemble).
La fonction `sendNotification(batch_path)` applique la séquence suivante :

1. **Lecture du destinataire** : extraction de l'adresse depuis `csv_file` (`read_csv_value(..., "email")`); si absente, un avertissement est journalisé et la notification est abandonnée.

2. **Analyse d'état** : `analyze_status(status_file)` renvoie `finished`, `warnings`, `errors`. Si `finished` est faux, aucun mail n'est envoyé.

3. **Construction et envoi** : chargement des identifiants (`load_credentials`), construction du message avec `build_message` (récapitulatif, fichiers en anomalie, consignes SPIDER et commande `scp`), puis envoi via `send_email` (SMTP TLS).

4. **Journalisation** du succès ou de l'échec de l'envoi.

## Contenu du message.
Le courriel inclut :

- la confirmation de fin d'anonymisation,

- la liste des fichiers en **warning** (confiance faible) et en **ERROR** (échec de traitement) avec leur chemin,

- des consignes pour corriger/réexpédier les fichiers défectueux,

- une commande `scp` d'exemple pour récupérer `<batch>_defects`, et

- les étapes pour transférer les données vers SPIDER (adresse du serveur, dossier distant, authentification unité).

Contenu complet en annexe (Fig. ??)

## Mécanismes transverses.
La journalisation (`log`) trace l'ensemble du flux (démarrage, cas non terminé, succès/échec d'envoi). Les erreurs SMTP sont capturées dans `send_email` (connexion TLS, authentification, `send_message`) et rejouées après log en `ERROR`. L'analyse d'état repose sur la clé `files_status` du `status.json` (`"processing"`, `"warning"`, `"ERROR"`).

## Organisation et limites.

- **Hypothèses** : `status.json` valide et lisible, présence d'une adresse `email` dans la configuration, accès réseau sortant au SMTP INRAE, et identifiants d'envoi disponibles (`load_credentials`). Par conception, aucun courriel n'est expédié tant que le lot n'est pas entièrement terminé (aucun fichier en `"processing"`).
— *Limites* : pas de drapeau persistant de notification déjà envoyée côté lot (la prévention de doublons repose sur l'orchestration), et le gabarit du message est figé en français (personnalisation possible en évolution).

## III Gestion des dépôts inactifs

Le processus d'anonymisation est régi par le Pipeline Manager du sous-répertoire cleanup/ :

<figure><img src="image_15.png" /></figure>

Déclenchement (cron). Le script est déclenché tous les matins à 4h00 par le planificateur cron, et ses sorties sont redirigées vers un fichier de log :

* * * * * /opt/AnonymizationUnit/src/cleanup/stale_batch_manager.py >>
/opt/AnonymizationUnit/stale_log.txt 2>&1

Le module de gestion des dépôts inactifs détecte les lots anciens, notifie leurs propriétaires et supprime ceux qui dépassent un âge configuré. Il est implémenté dans `src/core/stale_batch_manager.py` et s'appuie sur `find_all_batches`, `read_csv_value`, `load_json`/`save_json`, `load_credentials`, et `log`.
Les fonctions principales sont `get_batch_age_by_last_modif`, `select_old_batches`, `build_message`, `send_emailNotification` et `send_stale_batch_warning`. Des exemples des e-mails envoyés sont consultables en Annexes, Figure 6.6 et 6.7.

### Entrées / sorties.

— **Entrées** : répertoires INPUT/OUTPUT (découverte via `find_all_batches`), fichiers `config.csv` des lots (clé `email`), historique des notifications `notifications.json`, configuration d'intervalle `$HOME/.config/anonymization_unit/warning_interval$.json` (`warn_time_days`, `supp_time_days`), identifiants SMTP (`load_credentials`).

— **Sorties** : courriels envoyés (avertissement ou suppression), mise à jour de `notifications.json` (anti-doublon), suppression effective des lots arrivés à échéance, traces de journalisation.

### Fonctionnement (vue d'ensemble).

1. **Chargement des paramètres** : lecture de `warning_interval`.json pour obtenir les seuils d'âge (*avertissement* puis *suppression*), calcul du délai de grâce restant.
2. **Sélection des candidats** : évaluation de l'âge de chaque lot via `get_batch_age_by_last_modif` (à partir des `mtime`); classification en deux listes par `select_old_batches`: warn (entre les deux seuils) et supp (au-delà du seuil de suppression).

3. **Récupération du destinataire** : recherche d'un `config.csv` pour le lot (dans le lot lui-même ou dans `INPUT/<batch>`) et lecture de la clé `email`.

4. **Anti-doublon** : consultation de `notifications.json` (`<batch_path>_<tag>`) pour éviter les renvois.

5. **Notification** : construction du message via `build_message` (`warn`: avertissement avec délai restant; `supp`: notification de suppression immédiate) puis envoi via `send_emailNotification` (SMTP TLS `smtp.inrae.fr:587`).

6. **Suppression** : pour les lots marqués `supp`, suppression du répertoire du lot après notification.

## Paramétrage et règles.

- **Âge du lot** : calculé à partir des dates de modification des fichiers du lot (`mtime`).

- **Seuils** : `warn_time_days` et `supp_time_days` (jours) définis dans `warning_intervals.json` puis convertis en secondes ; le *grace period* est la différence entre les deux.

- **Canaux** : l'adresse du destinataire provient de `config.csv` (clé `email`); l'émetteur est construit à partir des identifiants chargés (`load Credentials`).

**Mécanismes transverses.** La journalisation (`log`) couvre le chargement des paramètres, les comptages (candidats à avertir/supprimer), les envois et les erreurs (SMTP, lecture d'intervalle, accès fichiers). Un historique `notifications.json` prévient les notifications multiples pour un même lot et un même tag (`warn/supp`).

## Organisation et limites.

- **Hypothèses** : présence d'un `config.csv` avec une clé `email`, accès au SMTP sortant, droits suffisants pour supprimer les répertoires de lots.

- **Limites** : pas de mode `dryrun` ni de corbeille (la suppression est définitive), dépendance à la configuration d'intervalle utilisateur, et absence de mécanisme de regroupement par propriétaire en cas de multiples lots.

# IV Communcation avec SPIDER

La communication avec le projet SPIDER est gérée par le serveur Flask codé dans `anonymization_server.py` :

```
anonymization_unit/
    README.md
    pyproject.toml
    src/
        anonymization_server.py
        core/
        cleanup/
        tools/
        tests/
```
model.pt

Ce WEB-service REST expose une route permettant de suivre l'état d'un lot d'anonymisation et de récupérer son fichier de statut. Il est basé sur Flask et opère sur la hiérarchie /home/<user>/INPUT et /home/<user>/OUTPUT.

Endpoint. GET /status/<user_id>/<batch_id> :

— 404 si <batch>_status.json est absent (process non démarré).

— 202 + JSON si au moins un fichier est encore en "processing" (files_status renvoyé pour diagnostic).

— 200 sinon : renvoie <batch>_status.json en téléchargement (send_file).

Fonctionnement (vue d'ensemble).

1. get_paths : construit les chemins du lot (OUTPUT, INPUT, <batch>_status.json, <batch>_metadata.json, tmp_dir, archive .zip).

2. is_processing : charge le status.json et teste si une valeur de files_status vaut "processing".

3. /status/... : vérifie la présence du status.json, retourne soit un JSON (202) soit le fichier (200).

4. create_zip : préparation d'une archive du lot dans tmp_dir .

Mécanismes et limites. Service minimaliste (pas d'authentification ni de validation d'entrées dans cet extrait) ; une stratégie de nettoyage après récupération pourrait être développée pour un nettoyage plus rapide que la simple attente du délai géré par le Stale Batch Manager.

V Fonctions utilitaires

anonymization_unit/
README.md
pyproject.toml
src/
anonymization_server.py
core/
cleanup/
tools/
batch_utils.py
extract_exif.py
file_utils.py
tests/
model.pt

Les fonctions utilitaires regroupées dans src/tools/ constituent un socle transversal qui factorise les opérations récurrentes (E/S fichiers, chemins, lecture/écriture CSV/JSON, journalisation, extraction EXIF via exiftool, découverte et qualification des lots). Elles fournissent une API stable et typée, avec une gestion homogène des erreurs et des messages de log, de sorte
que les modules métiers (*Dispatcher*, *Pipeline Manager*, *Workers*, notification, API) puissent se concentrer sur leur logique sans dupliquer du code bas niveau.

Concrètement, ces utilitaires imposent des conventions (arborescence *INPUT/*OUTPUT, noms de fichiers d'état), encapsulent les dépendances système (appel *exiftool*, accès disque, SMTP) et appliquent des invariants (formats JSON cohérents, encodage UTF-8, horodatage des logs). Centraliser ces aspects améliore la robustesse, la testabilité, la sécurité opérationnelle et la maintenabilité (principe *DRY*, séparation des responsabilités). Cette couche d'abstraction rend l'unité plus prévisible et facilite les évolutions futures sans effet de bord dans le pipeline.
Conclusion

Ce stage avait pour ambition de concevoir une unité d'anonymisation opérationnelle, ca-
pable de traiter des lots hétérogènes d'images et de vidéos avant leur intégration dans SPIDER.
Le travail mené a abouti à une architecture simple et robuste, organisée en pipeline de type
ETL : un Dispatcher qui priorise les lots selon un critère âge/taille et évite les doublons, un Pi-
peline Manager qui orchestre les étapes et garantit l'anticoncurrence, des Workers qui assurent
l'anonymisation et la traçabilité, un service web léger pour l'accès à l'état des traitements, et
un module de purge des dépôts inactifs pour préserver les ressources.

Au cœur du dispositif, le modèle d'anonymisation s'appuie sur une variante YOLOseg fo-
calisée sur la détection des personnes et le masquage polygonal. La gestion de la confiance
différencie images et vidéos : sur image, un seuil paramétrable classe le résultat et déclenche si
nécessaire une revue humaine, tandis que sur vidéo, toute incertitude conduit à noircir la frame
et à consigner les intervalles sensibles, choix assumé en faveur de la protection de la vie privée.
L'ensemble du flux est journalisé, idempotent au niveau du lot, et sécurisé pour les opérations
sensibles (chargement des identifiants d'envoi sous root/.config).

L'unité est pensée pour s'intégrer naturellement avec SPIDER : une fois les traitements
terminés et validés, les sorties sont prêtes au transfert, et l'utilisateur est guidé par des no-
tifications claires. Ce socle fournit dès à présent une chaîne fiable, traçable et extensible, sur
laquelle il sera aisé d'ajouter des raffinements (optimisations de performance, durcissement de
l'API, réglages plus fins des seuils, amélioration de l'ergonomie côté utilisateur).

En définitive, le projet atteint son objectif initial : offrir une base solide et évolutive pour
l'anonymisation visuelle dans SPIDER, conciliant exigences de protection des données et valo-
risation scientifique des jeux de données, tout en ouvrant des perspectives concrètes d'indus-
trialisation et d'amélioration continue.
# Résumé

Ce rapport décrit la conception et la mise en œuvre d'une unité d'anonymisation opérationnelle pour la plateforme SPIDER (INRAE). Le système traite des *batches* d'images et de vidéos au sein d'une chaîne ETL modulaire : un *Dispatcher* priorise les lots (rapport âge/taille et déduplication par hachage), un *Pipeline Manager* orchestre l'exécution avec verrous et journalisation, et des *Workers* réalisent l'extraction EXIF et l'anonymisation visuelle à l'aide d'une variante *YOLO-seg*. Sur image, les personnes détectées sont masquées par des polygones noirs ; le fichier est classé *done* ou *warning* selon un seuil de confiance paramétrable. Sur vidéo, toute détection sous le seuil entraîne le noircissement de la frame, et les intervalles consécutifs sont consignés en CSV pour revue. Un service Flask expose l'état des traitements et facilite le transfert vers SPIDER ; des e-mails de notification récapitulent avertissements et erreurs. L'ensemble vise la robustesse (idempotence par lot, *status.json*, logs centralisés), la protection des données dès la conception et une intégration fluide avec SPIDER. Les évolutions envisagées portent sur le préchauffage/partage du modèle, le durcissement de l'API, l'affinage des seuils—dont la politique vidéo—and la conteneurisation.

**Mots-clés** : anonymisation, vision par ordinateur, YOLO-seg, RGPD, pipeline ETL, SPIDER, images, vidéos.
Abstract

This work presents the design and implementation of a production-ready anonymization unit for the SPIDER platform (INRAE). The system ingests user “batches” of images and videos and processes them through a modular ETL pipeline : a *Dispatcher* prioritizes batches (age/size ratio and hash-based deduplication), a *Pipeline Manager* orchestrates execution with locking and logging, and *Workers* perform EXIF extraction and visual anonymization using a segmentation variant of Ultralytics *YOLO-seg*. For images, detected person instances are masked with black polygons; files are classified as *done* or *warning* based on a configurable confidence threshold. For videos, any low-confidence detection triggers frame blackout, and consecutive intervals are exported to CSV for review. A lightweight Flask service exposes processing status and supports handoff to SPIDER; notification emails summarize warnings and errors. The unit emphasizes robustness (idempotent per batch, explicit *status.json*, centralized logs), privacy by design, and smooth integration with SPIDER. Future work includes model warm-up/caching, hardened API (authn/authz), finer thresholding—including video interval policies—and containerized deployment.

**Keywords** : anonymization, computer vision, YOLO-seg, GDPR, ETL pipeline, SPIDER, images, videos.
# Annexes

<figure><img src="image_16.png" /><figcaption>FIGURE 6.5 – Notification de fin de traitement avec fichiers à problèmes</figcaption></figure>
<figure><img src="image_17.png" /><figcaption>FIGURE 6.6 – Notification de dépôt inactif, avertissement</figcaption></figure>

Bonjour,

Un dépôt associé à votre compte utilisateur a été détecté comme inactif sur l'unité d'anonymisation SPIDER.

Nom du dépôt : /home/usertest2/OUTPUT/batchB_20250825_125825

Délai avant suppression automatique : 30 jours

Si vous souhaitez conserver ce dépôt, veuillez le déclarer sur SPIDER avant la fin de ce délai.

Dans le cas contraire, il sera supprimé automatiquement.

Cordialement,

L'équipe SPIDER

<figure><img src="image_18.png" /><figcaption>FIGURE 6.7 – Notification de dépôt inactif, suppression</figcaption></figure>

Bonjour,

Le dépôt suivant, resté inactif, a été supprimé :

Nom du dépôt : /home/usertest2/OUTPUT/batchB_20250825_125825

Aucune action corrective n'ayant été entreprise dans les délais impartis, sa suppression a été effectuée automatiquement.

Cordialement,

L'équipe SPIDER
Bibliographie

[1] Redmon, J., Divvala, S., Girshick, R., and Farhadi, A., "You Only Look Once: Unified, Real-Time Object Detection," *Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR)*, pp. 779-788, 2016.

[2] Torvekar, N., and Game, P., "Microservices and Its Applications: An Overview," *International Journal of Computer Sciences and Engineering*, vol. 7, pp. 803-809, 2019. doi: 10.26438/ijcse/v7i4.803809.

[3] Cheng, B., Misra, I., Schwing, A.G., Kirillov, A., and Girdhar, R., "Masked-attention mask transformer for universal image segmentation," *Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR)*, 2022.

[4] Böhmer, W., Springenberg, J.T., and Riedmiller, M., "Privacy-preserving computer vision: A survey," *arXiv preprint arXiv:2205.09704*, 2022.

[5] Ahmed, H.A., Ahmed, M.H., Majidpour, J., et al., "Enhanced child face anonymization using YOLO framework for real-time privacy protection in videos," *Neural Computing and Applications*, vol. 37, pp. 19793-19816, 2025. doi: https://doi.org/10.1007/s00521-025-11424-x.

[6] Geitgey, A., "The world's simplest facial recognition API for Python and the command line," 2016. [En ligne]. Disponible: https://github.com/ageitgey/face_recognition.

[7] Jocher, G., Chaurasia, A., and Qiu, J., "Ultralytics YOLOv8," 2023. [En ligne]. Disponible: https://github.com/ultralytics/ultralytics.

[8] Ultralytics, "YOLO11-seg documentation," [En ligne]. Disponible : https://docs.ultralytics.com/models/yolo11.

[9] Ultralytics, "Object blurring using Ultralytics YOLO 11," [En ligne]. Disponible : https://docs.ultralytics.com/guides/object-blurring.

[10] Flask, "Flask Documentation," [En ligne]. Disponible : https://flask.palletsprojects.com/.

[11] Flask, "Flask API Documentation," [En ligne]. Disponible : https://flask.palletsprojects.com/en/latest/api/.

[12] Pallets, "Werkzeug Documentation," [En ligne]. Disponible : https://werkzeug.palletsprojects.com/.

[13] Crontab Guru, "The quick and simple editor for cron schedule expressions," [En ligne]. Disponible : https://crontab.guru.

[14] CNIL, "Règlement européen sur la protection des données (RGPD)," [En ligne]. Disponible : https://www.cnil.fr/fr/reglement-europeen-protection-donnees.

[15] Ministère de l'Économie, des Finances et de la Souveraineté industrielle et numérique, "Assurer sa cybersécurité et la protection de ses données," [En ligne]. Disponible : https://www.economie.gouv.fr/entreprises/gerer-son-entreprise-au-quotidien/assurer-sa-cybersecurite-et-la-protection-de-ses/le.