{"word_count": 2146, "character_count": 13728}
La linguistique de corpus, pour l'oral, est confrontée à un problème technique : une multiplicité d'outils développés isolément au fil des ans a donné lieu à une multiplicité de formats pour représenter nos données (transcriptions, annotations, ...). Le problème nous est si familier qu'il nous semble normal. À l'échelle individuelle ou d'un petit groupe, il peut paraître bénin.L'atelier DoReCo de septembre 2019 à Berlin a été l'occasion de revenir sur le problème des formats à l'échelle d'une communauté, échelle à laquelle les solutions ad hoc deviennent inopérantes. J'aimerais ici brièvement détailler le problème et les trois solutions générales adoptées pour le résoudre, à savoir : (1) le "tout-en-un", (2) la conversion de formats et (3) le format commun. Un avertissement avant de commencer : je confondrai ici le nom des  formats (généralement désignés par l'extension de fichier  correspondante) et le nom de leur outil dédié quand il y en a un. Par  exemple je parlerai de format Praat pour  parler du format de fichier d'extension ".TextGrid". Malgré la confusion possible, cela suit les usages et facilite l'identification des formats. Je vais aussi répéter ici quelques lieux communs, et je m'en excuse par avance.1.    Le problème des formatsÀ l'échelle individuelle, le problème se pose ainsi : un chercheur transcrit un enregistrement ou récupère des transcription réalisées dans un outil A, par exemple Transcriber. Il décide ensuite de réaliser des annotations dans un outil B, disons Analec. Puis il veut mener ses analyses dans un autre outil C, tel R. Chacun de ces outils utilise des fichiers différents : il faut passer par les formats A-B-C.C'est la conversion de formats. Soit les outils réalisent déjà cette conversion pour le chercheur (import/export ou logiciel tiers), soit le chercheur (plus souvent l'équipe de recherche) code cette conversion de façon ad hoc pour ses besoins spécifiques, y compris quand les conversions existantes se révèlent peu fiables ou difficiles d'accès.À l'échelle individuelle, ce n'est guère qu'un désagrément qui, au pire, dicte les outils que l'équipe va utiliser.À l'échelle d'une communauté, ces questions de fiabilité et d'accès deviennent particulièrement problématiques. Pour les corpus (bases de données), l'objectif est de voir ses données exploitées par la communauté de chercheurs. Or les chercheurs n'utilisent pas tous le même format et ne sont pas tous disposés ou en position de réaliser les conversions nécessaires. L'exemple le plus simple est la phonologie qui tend à travailler avec Praat et s'attend généralement à ce que les données soient déjà disponibles dans ce format ; à l'inverse, les utilisateurs d'ANNIS sont habitués à convertir et n'attendent qu'un format pour lequel un outil de conversion existe. Quant à la fiabilité, elle repose sur les pratiques. L'information peut être stockée de manière différente : on peut décider par exemple de stocker les métadonnées dans un fichier Elan ou les placer à part dans un fichier tableur (Excel, Calc...). Même alors, comment sont nommées ces métadonnées ? La conversion automatique est rendue difficile, sinon impossible, par ces divergences de pratiques. Un cas typique est celui de Praat où le nom des locuteurs est généralement placé dans celui des tires (je ne définirai pas ici ce qu'est une tire) là où le format Exmaralda leur réserve un espace dédié. Tout cela signifie que, même si un outil de conversion existe, aussi bien fait soit-il, il peut se révéler inadapté.À cela s'ajoutent des questions concernant la pérennité des données : tel format peut dans 20 ans devenir obsolète, et rendre un corpus difficile d'accès. C'est ce qui semble être arrivé au Switchboard Corpus. Cela peut du reste arriver aussi aux outils de conversion eux-mêmes s'ils ne sont pas mis à jour à mesures des changements dans les formats qu'ils convertissent.Les solutions ad hoc qui fonctionnent au niveau individuel ne s'appliquent plus au niveau de la communauté. La raison fondamentale est qu'au niveau individuel les données sont spécifiques, connues et maîtrisées ; au niveau de la communauté les données sont universelles, imprévisibles. En peu de mots, à cette échelle le problème posé par les formats n'a pas encore trouvé de solution.Et cela bien qu'il en existe essentiellement trois.2.    Le "tout-en-un"Je ne suis pas sûr de ce que j'avance ici, mais il semble qu'une première solution adoptée, face au besoin de changer de format à chaque fois que l'on change d'outil, est simplement de ne plus avoir à changer d'outil.À mes yeux, des logiciels comme Elan, Exmaralda ou encore Winpitch suivent, accidentellement ou non, cette philosophie du "tout-en-un". Le principe est simple : tout ce dont le chercheur aurait besoin peut être exploité à l'intérieur de l'outil, depuis la transcription jusqu'à l'analyse. Cette philosophie m'avait été présentée plus particulièrement avec Analec : les outils statistiques intégrés devaient suffire pour ne pas avoir à exporter les données vers R (ou SPSS). Au niveau individuel, cette solution est idéale. Le chercheur n'a besoin de disposer que d'un seul programme pour l'ensemble de sa recherche. Cela résout le problème technique des formats, mais facilite aussi le travail.Pour le logiciel lui-même, c'est aussi un avantage : le nombre de fonctionnalités encourage son utilisation et, de facto, Elan est devenu l'outil de référence des linguistes de terrain. Au niveau de la communauté, cela dit, cette approche est plus discutable. Ces critiques seront assez subjectives, mais elles sont aussi assez communes. De tels logiciels tendent à avoir une interface lourde et complexe, difficile d'accès pour le nouvel utilisateur. Ces logiciels demeurent incomplets : ils sont parfaits pour une tâche donnée (tel le travail de terrain pour Elan) et inadaptés pour d'autres (tel l'alignement des frontières où Praat est bien plus pratique). Le "tout-en-un" souffre également des questions de fiabilité : les outils ajoutés le sont souvent dans le cadre de cas spécifiques. L'import du format Flex par Elan par exemple semble différer de l'export du même format par Flex. Le "tout-en-un" est pratique et adapté pour une série de tâches données, dans un domaine précis, mais trouve ses limites au-delà, à l'échelle de la communauté. 3.    La conversion de formatsSi un seul logiciel ne peut pas s'imposer, alors pourquoi ne pas faciliter le changement de format ? Comme dit, la pratique actuelle consiste, pour les équipes de recherche, à convertir leurs données de façon ad hoc. Les outils de conversion sont ensuite généralement abandonnés : ils se révèlent peu fiables pour convertir d'autres données, ils ne sont pas "universels".Le principe derrière la conversion des formats serait de fournir au chercheur un convertisseur universel, capable de convertir n'importe quel format en n'importe quel autre format avec fiabilité. En termes de conversion, je distingue les outils intégrés, c'est-à-dire les outils d'import/export au sein d'un logiciel tel Exmaralda ou Elan, et les outils indépendants, c'est-à-dire des outils à part ayant pour seule fonction la conversion. Je ne connais que deux exemples de tels outils indépendants : TEI-Corpo et Pepper. Ces outils fournissent une liste de formats pour lesquels ils permettent la conversion, avec la volonté que cette dernière soit effectivement universelle, qu'elle puisse être appliquée à n'importe quel jeu de données.Pepper est à mes yeux exemplaire. Sa philosophie "couteau suisse" consiste à utiliser un modèle universel (Salt) reposant sur le graphe et pouvant stocker absolument n'importe quelle information. La conversion consiste alors à importer un format A dans ce modèle puis à exporter le modèle dans un format B (avec perte d'information si le format B ne peut pas contenir toute l'information du format A). Outre de réduire le nombre de conversions nécessaires, il s'agit du moyen le plus sûr d'assurer l'universalité des conversions ; et en bonus, le modèle Salt permet des opérations intermédiaires sur les données, comme par exemple de fusionner des transcriptions.La principale difficulté de la conversion demeure, toujours, le manque de fiabilité.Un outil de conversion ne peut pas prédire tous les formats qu'il faudra convertir. Il y a le système de notation du format Pangloss, la co-référence de MMAX 2, les balises à l'intérieur de la transcription de Transcriber, ... Pepper y a répondu par un modèle universel, Salt, mais le problème devient alors que personne, au moment d'exporter depuis Salt, ne sait où vraiment et sous quelle forme quelle information a été stockée. Je n'aurais pas ici raisonnablement assez de place pour lister tous les problèmes que je rencontre de mon côté pour définir une classe (un modèle) universelle pour la conversion. Pangloss n'utilise pas un système de partition (tires). Qu'est-ce qui constitue une colonne au  moment de convertir en format tabulaire ? Les segments vides de Praat n'ont pas la même signification dans Elan.La conversion de formats est la piste la moins coûteuse en l'état actuel, mais nous sommes encore loin de pouvoir assurer l'universalité de ces conversions, pas à ma connaissance de façon pratique et fiable.4.   Le format communEnfin, s'il n'est pas possible de rester sur un seul outil et si convertir entre les formats n'est pas universel, la solution serait que tous les outils utilisent le même format.L'idée derrière cette approche est d'utiliser le format standard TEI (Text Encoding Initiative) et son standard ISO 24624 (Schmidt 2011) comme unique format pour tous les outils en linguistique de l'oral. Le même fichier pourrait être ouvert avec Praat, avec Elan, Transcriber ou encore Clan, sans avoir à se soucier de conversions. Au niveau individuel comme au niveau de la communauté, la question des formats disparaîtrait entièrement, sans avoir à se confiner à un seul outil. Si de nouveaux outils sont créés, ceux-ci sauraient quel format utiliser et seraient aussitôt compatibles pour l'ensemble de la communauté.Le format TEI lui-même est idéal pour cette tâche. Actuellement, on le considère comme un format de stockage et de partage, inutilisable autrement. Mais il s'agit surtout de la référence dans les humanités numériques depuis 1994, capable de contenir n'importe quelle information (le TEI est en cela universel), mise à jour en fonction des nouveaux besoins avec l'assurance de la rétro-compatibilité : un fichier TEI ne deviendra théoriquement jamais obsolète.En théorie, un format commun est la meilleure option, et celle privilégiée par les informaticiens. En pratique, deux obstacles majeurs empêchent son implémentation. Le premier est d'adapter les outils existants à ce format ; le second est d'établir les pratiques pour ce format.Tant que les outils les plus populaires ignorent le TEI, personne n'utilisera le TEI, et donc les outils n'auront aucun intérêt à s'adapter pour l'utiliser. Je ne parle pas de fonctions d'import et d'export mais bien d'une simple ouverture de fichier. Il est possible d'adapter Praat ou Elan pour qu'ils ouvrent naturellement les fichiers TEI, mais cela demande beaucoup de temps et d'efforts dont personne ne dispose vraiment. Même en réunissant les bonnes volontés, cela dit, d'autres problèmes se posent encore. Certains programmes ne peuvent simplement pas adopter le TEI, du fait de leur fonctionnement : ce sont typiquement les bases de données qui séparent l'information en tables distinctes. Pour les programmes qui peuvent adopter le TEI, ils n'exploitent pas toute l'information et il faut s'assurer que celle-ci n'est pas perdue : typiquement Praat ignore toute métadonnée, qu'il faut bien stocker quelque part pour qu'à la sauvegarde celle-ci soit toujours présente et intacte. Enfin, il y a l'information effectivement exploitée. Quand je parle de métadonnée, je pense aux informations sur les locuteurs, sur l'enregistrement, la transcription, mais aussi les dictionnaires, etc. Je ne connais personne qui ait réussi à dresser un inventaire exhaustif des informations attendues à l'intérieur du TEI et, en conséquence, la structure effective du fichier qui serait exploitée. À mon sens, la question est ici purement technique. Chaque programme récupère l'information qu'il va exploiter et stocke le reste à part, puis le récupère à la sauvegarde.Mais à terme, il faut que quelqu'un adapte le code des programmes existants et populaires pour donner sa chance au TEI.5. En conclusionPour les corpus, la question est de savoir quels formats fournir à la communauté. La réponse est généralement : le plus de formats possible, les plus populaires, et si possible les outils de conversion également.Quelques remarques, à ce sujet, issues de l'atelier DoReCo :Le format de transcription dans lequel le corpus a été réalisé constitue un prérequis. Il est, pour les corpus, le plus facile à délivrer, mais il assure aussi la vérifiabilité des données : par exemple si une conversion s'est mal passée. Certains formats sont inutiles, et il est préférable de fournir les outils de conversion plutôt que les fichiers convertis eux-mêmes : c'est le cas pour Annis, Analec ou MMAX2. Les utilisateurs de ces outils sont habitués à convertir eux-mêmes. Pour l'analyse, il peut même être souhaitable que l'analyste contrôle le fichier qu'il obtient, par exemple les tables pour l'analyse statistique. Cela laisse les formats les plus communs, autrement dit les outils les plus utilisés. Lors de l'atelier, les formats retenus ont été ceux d'Elan et de Praat. Le format TEI, quant à lui, sert en pratique uniquement à la pérennité des données, une forme d'archivage. Il ne deviendra un format d'exploitation que si nous arrivons à adapter les outils existants.