Introduction

Les guides d’annotation constituent la base de tout projet d’annotation de données. Ils définissent ce qui doit être annoté, comment cela doit être annoté et la manière dont les annotateurs doivent gérer les nombreuses situations rencontrées sur des données réelles.

Pourtant, après avoir travaillé sur des dizaines de projets d’annotation, nous avons constaté que la qualité des guides d’annotation varie considérablement.

Certains clients fournissent une documentation extrêmement claire, structurée et complète. D’autres proposent des guides laissant une large place à l’interprétation. Nous avons vu des guides sans aucun exemple, des guides où les exceptions sont dispersées dans tout le document, ou encore des consignes formulées de manière inutilement complexe.

Dans ces situations, une part importante du démarrage du projet est consacrée à clarifier les exigences plutôt qu’à annoter les données.

Dans de nombreux cas, nous finissons par créer nos propres guides internes à partir des échanges avec le client, des questions des annotateurs et des décisions prises durant les premières phases du projet.

Alors, qu’est-ce qui fait un bon guide d’annotation ?

Pourquoi les guides d’annotation sont-ils importants ?

Lorsque des problèmes de qualité apparaissent, la première hypothèse est souvent que les annotateurs ont besoin de davantage de formation ou qu’un niveau de revue supplémentaire est nécessaire.

Pourtant, les incohérences d’annotation proviennent fréquemment d’instructions ambiguës plutôt que des annotateurs eux-mêmes.

Si deux annotateurs expérimentés peuvent raisonnablement interpréter une règle de manière différente, les incohérences deviennent presque inévitables.

Un bon guide d’annotation permet de s’assurer que chaque annotateur prend la même décision face à une même situation. Il réduit les incertitudes, accélère l’intégration des nouveaux annotateurs, simplifie les revues qualité et favorise la cohérence de l’ensemble du jeu de données.

1. Commencer par l’objectif du projet

Au début d’un projet, nous aimons fournir suffisamment de contexte pour que les annotateurs comprennent le rôle de leurs annotations dans l’ensemble du processus.

Ils n’ont pas besoin de connaître tous les détails techniques du système final (souvent confidentiels), mais ils doivent comprendre :

• L’objectif du projet
• Comment les données annotées seront utilisées
• Quelles informations sont importantes à capturer

Cette section ne sert pas uniquement à expliquer la tâche. Elle aide également les annotateurs à comprendre leur rôle dans le projet global et l’importance des décisions qu’ils prennent tout au long du processus d’annotation.

D’après notre expérience, les annotateurs sont généralement plus impliqués lorsqu’ils comprennent la finalité et l’impact de leur travail.

Cette partie comprend généralement un ou deux exemples représentatifs permettant d’illustrer les objectifs du projet et de donner une vision concrète de la tâche à réaliser.

2. Décrire la technique d’annotation

L’étape suivante consiste à expliquer la méthode d’annotation qui sera utilisée.

Selon le projet, cela peut inclure :

• Les boîtes englobantes (bounding boxes)
• Les polygones
• La segmentation sémantique
• La segmentation d’instances
• Les points clés (keypoints)
• La classification

Cette section doit décrire ce que l’annotation représente et comment elle doit être réalisée, à l’aide d’exemples illustrant les situations les plus courantes du jeu de données.

C’est également l’occasion de familiariser les annotateurs avec les données du client et de montrer concrètement le résultat attendu avant le démarrage de la production.

3. Définir clairement les classes

Chaque classe doit disposer d’une définition précise et sans ambiguïté.

Pour chaque classe, le guide doit expliquer :

• Ce qui doit être annoté
• Ce qui ne doit pas être annoté
• Ce qui distingue cette classe de classes similaires
• Des exemples typiques

Une terminologie cohérente est essentielle. Un même objet ou concept ne doit pas être désigné par des termes différents selon les sections du document.

Lorsque c’est possible, il est recommandé d’inclure des exemples visuels. Une seule image permet souvent de transmettre une règle plus efficacement que plusieurs paragraphes de texte.

4. Définir des règles d’annotation claires, précises et complètes

Cette section constitue le cœur du guide d’annotation.

D’après notre expérience, de bonnes règles d’annotation partagent trois caractéristiques essentielles.

Clarté

Les règles doivent être rédigées dans un langage simple et direct.

Évitez les formulations ambiguës, les tournures inutilement complexes, les doubles négations ou les longs paragraphes contenant plusieurs conditions et exceptions.

L’objectif n’est pas seulement que la règle soit correcte. Elle doit être facile à comprendre et à appliquer de manière cohérente.

Lorsqu’une règle nécessite plusieurs décisions successives, un arbre de décision est souvent plus efficace qu’une longue explication textuelle.

Les arbres de décision peuvent être très utiles

Ils sont particulièrement pertinents lorsque :

• Plusieurs conditions doivent être vérifiées dans un ordre précis
• Les règles comportent de nombreuses exceptions
• Des décisions similaires reviennent régulièrement
• Une mauvaise interprétation d’une condition peut entraîner une annotation incorrecte

Ils constituent également un bon moyen d’évaluer la qualité des consignes elles-mêmes. Si une règle ne peut pas être facilement transformée en arbre de décision, cela peut indiquer qu’elle reste ambiguë ou incomplète.

Précision

L’un des sujets les plus fréquemment discutés pendant la phase de calibration concerne le niveau de précision géométrique attendu. Il s’agit souvent d’une décision importante, car elle peut avoir un impact significatif sur la durée du projet et la charge de travail.

Les annotateurs doivent savoir précisément quel niveau de détail est attendu. En pratique, une légère augmentation des exigences de précision peut parfois entraîner une hausse disproportionnée du temps d’annotation.

L’objectif n’est donc pas de maximiser la précision à tout prix, mais de définir le niveau réellement nécessaire au regard des objectifs du projet (voir notre article sur le sujet « Précision vs performance« )

Les questions suivantes doivent notamment trouver une réponse :

• À quel point un polygone doit-il suivre les contours de l’objet ?
• Les petites protubérances doivent-elles être incluses ?
• Les petits trous ou espaces doivent-ils être représentés ?
• Quel niveau d’écart est acceptable ?
• À partir de quand une annotation est-elle considérée comme suffisamment précise / insuffisamment précise ?

Tous les projets n’exigent pas le niveau de précision maximal. Dans certains cas d’usage, quelques pixels d’écart n’auront aucun impact réel. Dans d’autres, des contours très précis seront indispensables.

Un bon guide définit clairement le niveau de précision attendu plutôt que de demander aux annotateurs d’être simplement « aussi précis que possible ».

Exhaustivité

L’un des aspects les plus souvent négligés dans les guides d’annotation est leur exhaustivité.

De nombreux guides décrivent les situations les plus courantes mais omettent les cas qui génèrent réellement des questions pendant la production.

Les annotateurs ne devraient pas avoir à deviner quoi faire lorsqu’ils rencontrent :

• Des objets partiellement visibles
• Des occultations
• Des objets qui se chevauchent
• Des objets tronqués
• Du flou de mouvement
• Des images de faible qualité
• Des cas ambigus

Un bon guide doit anticiper les situations susceptibles d’être rencontrées et expliquer comment les traiter.

Dans la mesure du possible, ces situations doivent être illustrées par des exemples concrets issus du jeu de données.

Une structure souvent efficace est :

Règle générale → Exception → Cas limite

Commencez par la règle qui s’applique dans la majorité des cas, puis documentez clairement les situations où elle ne s’applique plus. Les cas plus spécifiques ou inhabituels peuvent ensuite être décrits séparément comme des cas limites, avec une explication claire et, si possible, un exemple visuel.

5. Documenter les cas limites et les exceptions

Les cas limites méritent leur propre section car ils sont souvent à l’origine d’une grande partie des questions posées par les annotateurs.

Aussi soigneusement qu’un guide soit rédigé, les annotateurs finiront toujours par rencontrer des situations qui ne correspondent pas parfaitement aux règles générales.

Pour chaque cas limite important, nous recommandons de documenter :

• La situation
• L’annotation attendue
• Un exemple visuel
• Une courte explication du raisonnement

Les exemples réels issus du jeu de données sont généralement plus utiles que des exemples artificiels, car ils reflètent les situations réellement rencontrées en production.

6. Définir la gestion des pré-annotations

Lorsque des pré-annotations sont fournies, le guide doit clairement expliquer comment elles doivent être utilisées.

Cette section décrit généralement leur niveau de qualité global et précise ce qui doit être vérifié ou corrigé.

Par exemple, le guide peut indiquer :

• Quels types d’erreurs sont fréquemment présents dans les pré-annotations
• Quels éléments doivent normalement être corrigés
• Quels éléments peuvent être laissés tels quels
• Quand une pré-annotation doit être supprimée ou remplacée
• Que faire lorsqu’une pré-annotation attendue est absente
• Si les classes, les géométries ou les attributs doivent être systématiquement vérifiés

Il est également important de préciser si les pré-annotations doivent être considérées comme un simple point de départ ou comme des annotations devant être systématiquement revues.

Le niveau de correction attendu doit être adapté à la qualité des pré-annotations et aux objectifs du projet. Cela peut avoir un impact important sur le temps d’annotation et doit donc être clairement défini dès le départ.

7. Expliquer le workflow d’annotation dans l’outil

Une fois les règles d’annotation définies, le guide peut expliquer comment elles doivent être appliquées dans l’outil d’annotation.

En pratique, cette section reste souvent relativement courte. Les équipes d’annotation connaissent généralement déjà les outils qu’elles utilisent au quotidien ; il y a donc peu d’intérêt à reproduire une documentation complète pour chaque projet.

Nous privilégions plutôt les informations spécifiques au projet, telles que :

• Les fonctionnalités particulières à utiliser
• Les workflows spécifiques au projet
• L’utilisation éventuelle d’outils d’assistance à l’annotation (comme SAM – voir notre article sur « SAM en annotation de données : quand et comment l’utiliser ?« )
• Les raccourcis clavier permettant de gagner en efficacité
• Les erreurs fréquentes à éviter
• Les exigences spécifiques du client liées à l’outil

L’objectif est de mettre en avant les informations propres au projet plutôt que de reproduire le manuel utilisateur de l’outil.

Les guides d’annotation sont des documents vivants

Une idée reçue consiste à penser qu’un guide d’annotation doit être entièrement finalisé avant le début de la production. En réalité, même le guide le mieux préparé ne couvrira pas toutes les situations dès le premier jour.

Lorsque les annotateurs commencent à travailler sur les données réelles, ils rencontrent inévitablement des cas qui n’avaient pas été anticipés. Ces questions sont précieuses. Lorsqu’une même question revient régulièrement, cela indique souvent que le guide doit être amélioré.

Ces questions récurrentes peuvent révéler :

• Une règle manquante
• Une définition peu claire
• Un cas limite non documenté
• Un besoin d’exemples supplémentaires

C’est pourquoi nous considérons les guides d’annotation comme des documents vivants qui évoluent tout au long de la phase de calibration et, lorsque nécessaire, pendant la production.

Avec le temps, le guide devient une représentation de plus en plus complète des décisions nécessaires pour annoter correctement le jeu de données.

Une structure pratique pour un guide d’annotation

D’après notre expérience, un guide d’annotation efficace suit souvent la structure suivante :

1. Objectifs du projet
2. Technique d’annotation
3. Classes et définitions
4. Règles d’annotation
5. Cas limites et exceptions
6. Pré-annotations (si applicable)
7. Workflow d’annotation dans l’outil

La structure exacte varie selon les projets, mais le principe reste le même : définir ce qui doit être annoté, expliquer comment les décisions doivent être prises, anticiper les situations difficiles, puis seulement expliquer comment réaliser la tâche dans l’outil.

Conclusion

Rédiger un guide d’annotation efficace consiste avant tout à réduire l’ambiguïté.

Les meilleurs guides d’annotation sont :

• Suffisamment clairs pour être compris rapidement
• Suffisamment précis pour définir le niveau de détail attendu
• Suffisamment complets pour couvrir les situations réelles
• Riches en exemples visuels
• Améliorés en continu grâce aux retours des annotateurs

Plus important encore, un bon guide ne doit pas seulement expliquer quoi faire dans les situations les plus courantes. Il doit permettre à différents annotateurs de prendre la même décision, y compris lorsque la réponse n’est pas immédiatement évidente.

Moins il reste de place à l’interprétation, plus il devient facile de produire des annotations cohérentes entre les personnes, les lots de données et dans le temps.

Vous démarrez un nouveau projet d’annotation et ne savez pas par où commencer pour rédiger vos consignes ? Notre équipe accompagne chaque année des dizaines de projets d’annotation. Échangeons sur les besoins spécifiques de votre projet. Contactez nous.