Modèle de structure de tiers ELAN : locuteurs, traduction, notes, codes (avec exemples)

Un bon modèle de structure de tiers ELAN (locuteurs, traduction, notes, codes) vous aide à annoter plus vite, à éviter les doublons et à partager un projet sans confusion.

La règle la plus utile : séparez clairement (1) la parole de chaque locuteur, (2) la traduction, (3) les notes d’annotation et (4) les codes d’analyse, avec des noms de tiers cohérents pour toute l’équipe.

Dans cet article, vous trouverez une structure recommandée, deux exemples complets (entretien à un locuteur et interaction à plusieurs), et des conventions de nommage faciles à appliquer.

Key takeaways

• Créez un groupe de tiers par locuteur : transcription/orthographe, traduction, commentaires/notes, puis codes.
• Utilisez des conventions de nommage stables (préfixes et langue) pour éviter les erreurs en équipe.
• Gardez les tiers « analyse » séparés des tiers « données » (transcription et traduction) pour protéger vos sources.
• Adaptez la structure à votre unité de travail : tour de parole, phrase, ou segment temporel.

Pourquoi une structure de tiers ELAN claire change tout

ELAN est très flexible, mais cette liberté crée vite du désordre si chacun nomme ses tiers à sa manière.

Une structure stable améliore trois choses : la lisibilité, la recherche (filtres, exports) et la collaboration (fusion, relecture, livraison).

Les 4 familles de tiers à séparer

• Données : ce qui est dit (transcription) et comment c’est dit (optionnel : phonétique, gestes).
• Traduction : rendu dans une autre langue (ou une normalisation dans la même langue).
• Notes : décisions, incertitudes, contexte, qualité audio, métadonnées locales.
• Analyse (codes) : catégories, thèmes, actes de langage, phénomènes interactionnels.

Modèle de base : tiers « locuteur » + traduction + notes + codes

Le modèle ci-dessous couvre la plupart des études (entretiens, classes, réunions, observations) sans devenir lourd.

Il fonctionne bien si vous voulez exporter vers un tableur, faire relire, ou garder une séparation nette entre données et analyse.

Structure recommandée par locuteur (gabarit)

• SPK_[ID]__tx_[LANG] : transcription principale (orthographe).
• SPK_[ID]__tr_[LANG2] : traduction (vers LANG2) alignée sur la transcription.
• SPK_[ID]__note : notes d’annotation (inaudible, rire, référence, décision).
• SPK_[ID]__code : codes analytiques (thèmes, actes, stratégies) alignés sur la transcription ou sur la traduction selon votre méthode.

Gardez une logique simple : un tiers « parent » pour la parole, et des tiers « enfants » pour traduction, notes et codes.

Dans ELAN, cela correspond souvent à un tiers parent en Alignable (lié au temps), et des tiers enfants en Referring (référencés sur le parent).

Variantes utiles (à activer seulement si nécessaire)

• SPK_[ID]__tx_norm_[LANG] : normalisation (si la transcription conserve des formes non standard).
• SPK_[ID]__tx_phon : transcription phonétique (si votre étude la demande).
• SPK_[ID]__morph / SPK_[ID]__gloss : morphologie/gloses (linguistique).
• SPK_[ID]__para : paralinguistique (rire, soupir) si vous ne voulez pas le mettre dans la transcription.
• ENV__note : notes globales (bruit, événement hors champ, coupure).

Conventions de nommage : la clé pour travailler en équipe

Si votre projet est collaboratif, imposez un standard de noms avant de commencer l’annotation.

Le but : qu’un tiers soit compréhensible sans ouvrir le guide de codage.

Règles simples et robustes

• Préfixe de type : SPK_ pour un locuteur, ENV_ pour l’environnement, CAM_ si vous avez plusieurs caméras, etc.
• ID stable : SPK_A, SPK_B, SPK_TCH (enseignant), SPK_INT (intervieweur) selon votre terrain.
• Double underscore __ comme séparateur principal, puis un suffixe clair : tx, tr, note, code.
• Langue en code court : fr, en, ar, etc. pour éviter les variantes (FR, Français, french).
• Pas d’espaces : évite des soucis à l’export et dans d’autres outils.

Exemple de dictionnaire de noms (à copier dans votre protocole)

• tx = transcription verbatim (orthographe)
• tx_norm = transcription normalisée
• tr = traduction
• note = note d’annotation
• code = code analytique

Conseil pour éviter les doublons

Décidez si vous codez sur la transcription (tx) ou sur la traduction (tr), puis gardez ce choix partout.

Si vous changez en cours de projet, vous perdrez du temps à réconcilier les segments et les exports.

Exemple 1 : entretien à un locuteur (intervieweur + participant)

Dans un entretien, vous avez souvent deux rôles stables : intervieweur (INT) et participant (P01).

Le modèle ci-dessous reste simple, mais couvre traduction, notes et codes.

Arborescence de tiers (proposée)

• SPK_INT__tx_fr
  • SPK_INT__note
• SPK_P01__tx_fr
  • SPK_P01__tr_en
  • SPK_P01__note
  • SPK_P01__code
• ENV__note

Pourquoi c’est efficace

• Vous gardez l’intervieweur léger (souvent pas besoin de traduction/codes sur ses questions).
• Vous concentrez analyse et traduction sur le participant, ce qui simplifie l’export.
• Les notes restent séparées, donc vous pouvez livrer la transcription sans commentaires internes.

Mini-exemple de contenu (même segment, 4 niveaux)

• SPK_P01__tx_fr : « J’ai hésité parce que je ne savais pas si c’était autorisé. »
• SPK_P01__tr_en : “I hesitated because I didn’t know whether it was allowed.”
• SPK_P01__note : « Ton bas sur “autorisé”, mot confirmé au 2e visionnage. »
• SPK_P01__code : « incertitude; règle/autorisation »

Exemple 2 : interaction multi-parties (réunion, classe, focus group)

En interaction, le défi principal est le chevauchement, les tours de parole courts et les changements rapides de locuteur.

Votre structure doit rester lisible même avec 4 à 10 personnes.

Arborescence de tiers (proposée) pour 4 locuteurs

• SPK_A__tx_fr
  • SPK_A__tr_en
  • SPK_A__note
  • SPK_A__code
• SPK_B__tx_fr
  • SPK_B__tr_en
  • SPK_B__note
  • SPK_B__code
• SPK_C__tx_fr
  • SPK_C__tr_en
  • SPK_C__note
  • SPK_C__code
• SPK_D__tx_fr
  • SPK_D__tr_en
  • SPK_D__note
  • SPK_D__code
• ENV__note
• INT__code_global (optionnel)

Quand ajouter un code « global » d’interaction

• Quand vous codez des phénomènes qui dépassent un seul locuteur : interruption, accord collectif, éclats de rire, vote, décision.
• Quand votre unité d’analyse est un épisode (30–120 secondes) plutôt qu’un tour de parole.

Astuce sur les chevauchements

Évitez de forcer un seul tiers « tour de parole » commun à tout le monde, car les chevauchements deviennent difficiles à annoter proprement.

Préférez un tiers parent par locuteur, puis ajoutez un tiers global (INT__code_global) pour les phénomènes de groupe si besoin.

Mettre en place le template : étapes pratiques (et choix à trancher)

Un template utile n’est pas seulement une liste de tiers, c’est aussi un ensemble de décisions partagées.

Voici une méthode rapide en 6 étapes pour standardiser votre projet.

1) Définir l’unité de segmentation

• Tour de parole : bien pour interaction, interviews et analyse conversationnelle.
• Phrase : bien pour traduction et export, plus stable pour les relectures.
• Épisode : bien pour codes thématiques et observations (plus macro).

2) Choisir où se fait la traduction

• Traduction sous chaque locuteur : idéal si vous traduisez tout ce qui est dit.
• Traduction seulement pour certains locuteurs : utile si un seul locuteur est analysé.
• Un tiers de traduction global : à éviter sauf cas spécial, car on perd facilement l’alignement avec les tours.

3) Décider où placer les phénomènes non verbaux

• Dans la transcription (tx) avec des balises simples : [rire], [pause].
• Dans un tiers dédié (para) si votre étude code finement le non verbal.

4) Séparer notes et codes

• Notes = incertitudes, décisions, qualité audio, contexte local.
• Codes = catégories analysables, destinées à l’export et au calcul qualitatif.

5) Écrire une « charte de nommage » d’une page

• Liste des IDs locuteurs autorisés (A, B, INT, P01, etc.).
• Liste des suffixes autorisés (tx, tr, note, code, …).
• Liste des langues autorisées (fr, en, …).

6) Prévoir la relecture et la livraison

Si vous livrez à un client ou à un autre service, vous aurez souvent besoin d’exporter en texte, CSV ou sous-titres.

Une structure propre réduit les nettoyages de dernière minute et limite les erreurs d’attribution de locuteur.

Pièges courants (et comment les éviter)

La plupart des problèmes viennent d’un manque de cohérence ou d’une séparation floue entre données et analyse.

Corriger après coup coûte cher en temps, surtout avec plusieurs annotateurs.

• Noms de tiers incohérents : imposez un format unique, sinon vous aurez tx_fr / Transcription / verbatim pour la même chose.
• Langues mélangées dans un même tiers : gardez une langue par tiers (tx_fr, tr_en).
• Codes écrits dans les notes : vous perdez la capacité d’exporter et de compter facilement.
• Trop de tiers dès le départ : commencez minimal, ajoutez seulement ce qui sert à votre question de recherche.
• Décisions non documentées : une note ENV__note au début du fichier peut résumer les choix (segmentation, conventions).

Common questions

• Dois-je créer un tiers de traduction par locuteur ou un seul tiers global ?
  Un tiers par locuteur reste le plus clair, car la traduction suit le même découpage que la parole et garde l’alignement.
• Où mettre les hésitations, répétitions et “euh” ?
  Si votre analyse en a besoin, gardez-les dans tx (verbatim) et créez un tx_norm si vous devez aussi fournir une version plus lisible.
• Comment nommer les locuteurs quand je ne connais pas leurs noms ?
  Utilisez des IDs neutres et stables (SPK_A, SPK_B) ou des rôles (SPK_TCH, SPK_STU1), puis gardez la même logique dans tout le corpus.
• Mes codes doivent-ils être sur la transcription ou sur la traduction ?
  Choisissez une base unique : transcription si vous analysez le langage original, traduction si l’équipe code dans la langue cible.
• Dois-je séparer “notes” et “commentaires” ?
  Pas forcément : un seul tiers note suffit, sauf si vous voulez distinguer les notes de qualité (audio) des notes méthodo (décisions).
• Comment gérer les chevauchements en réunion ?
  Gardez un tiers parent par locuteur et annotez chaque segment sur sa propre ligne temporelle, puis ajoutez un code global si vous analysez des épisodes de groupe.
• Quel format facilite la relecture externe ?
  Une transcription propre par locuteur (tx) avec des notes séparées, puis une traduction alignée (tr) si elle est nécessaire.

Ressources utiles (sans compliquer votre setup)

Pour revoir la logique des types de tiers (alignés au temps vs référencés), la documentation officielle d’ELAN reste la source la plus fiable.

Vous pouvez consulter le site du développeur via la page ELAN du Max Planck Institute pour les notions et manuels.

Quand faire appel à une transcription professionnelle

Si vous passez beaucoup de temps à nettoyer l’audio, à attribuer les locuteurs, ou à préparer une base fiable avant le codage, externaliser la transcription peut simplifier votre flux.

Vous pouvez aussi combiner une première passe automatique et une relecture, selon votre exigence de qualité, par exemple via la transcription automatique ou via la relecture de transcription.

Si vous voulez une base propre à importer et annoter dans ELAN (avec des repères clairs pour locuteurs, notes ou traduction), GoTranscript peut vous orienter vers les bonnes options, dont ses professional transcription services.