Un traitement de texte peut-il remplacer un e diteur XML pour l e dition savante?

Un traitement de texte peut-il remplacer un e diteur XML pour l e dition savante? Analyse de cas : le Sanctoral du lectionnaire de l office dominicain Depuis 2002, l École nationale des chartes est engagée dans un programme de publication électronique de sources, prolongeant ainsi une longue tradition de l édition critique. Les principes éditoriaux de cette tradition sont consignés et explicités dans les fascicules publiés sous la direction de P. Bourgain, O. Guyotjeannin et F. Vieillard (Conseils pour l edition des textes medievaux, Paris, éd. CTHS, 3 tomes, 200-2002). Nous essayons désormais d exprimer ces conseils sous forme de schémas XML/TEI 2. Ce travail de mise en correspondance des règles typographiques et des règles d encodage a notamment pour objectif de faciliter l intégration de nos chaînes d édition papier et électronique. Mais cet effort, s il part toujours des recommandations éditoriales pour une édition sur papier (du traitement de texte), peut être limitant : le traitement de texte formate notre manière de penser le texte et induit des usages qui peuvent s avérer ultérieurement préjudiciables pour l exploitation informatique de ses contenus. Pour illustrer le propos, nous suivrons le cas concret de l exploitation hélas empêchée des très précieuses identifications de sources d'un texte médiéval, telles que proposées par Anne-Élisabeth Urfels-Capot dans son édition du sanctoral du lectionnaire de l'office dominicain, publiée par l'école des chartes 3. Anne-Élisabeth Urfels-Capot a réalisé son édition d après un manuscrit copié à Paris au temps de saint Louis, conservé aujourd hui au couvent Sainte-Sabine de Rome (sous la cote XV L) et considéré comme le témoin authentique de la liturgie dominicaine telle qu elle fut fixée par le maître de l ordre, Humbert de Romans, de 254 à 256. Ce lectionnaire témoigne de l effort naissant d harmonisation du rite dans la chrétienté. Il est aussi remarquable pour l attention portée par son éditeur aux sources utilisées. Non seulement Humbert de Romans référence toujours très précisément ses emprunts, mais il signale aussi au fil du texte le procédé de leur adaptation : réécriture, sélection par coupures ou citation à l identique. Ce soin, encore exceptionnel au XIII e siècle, témoigne du caractère savant de l ordre Prêcheur et intéresse l historien des http :// elec. enc. sorbonne. fr / sanctoral / 2 http://developpements.enc.sorbonne.fr/diple/schema/ 3 Le sanctoral de l'office dominicain (254-256), édité par Anne-Élisabeth Urfels-Capot, Mémoires et documents de l'école des chartes, 84, Paris, 2007. Communication du 2/0/20 à Caen, /

savoirs médiévaux. Une édition électronique devrait être l occasion de quantifier cette évolution des pratiques d écriture, de créer des index et d effectuer des comptages. Hélas le formatage initial de l édition en traitement de texte l'interdit. À partir de ce cas du Sanctoral, nous commencerons par détailler les nombreuses potentialités du traitement de texte pour la production de contenus structurés en XML, tout en pointant les limites liées à la conception du texte que cet outil induit. Nous expliquerons ensuite en quoi la définition de schémas XML est nécessaire et peut permettre un retour efficace au traitement de texte, avec un recours maîtrisé aux modèles de documents (dérivés des schémas). Ce recours suppose des compétences que les auteurs n'ont pas toujours ; le rapport auteur/éditeur conditionne bien souvent l'exploitation des outils de structuration du texte. Si l on veut faire du TEI sans voir de balises, pourquoi faire du TEI? Les éditeurs électroniques peuvent le déplorer, mais les auteurs apprécient rarement les balises, ils utilisent bien plus largement le traitement de texte. Or les logiciels bureautiques enregistrent désormais leurs fichiers dans un format XML. Mais de quel XML s agit-il? Que peut, et surtout que ne peut pas, le traitement de texte? Un traitement de texte peut enregistrer en XML, en HTML, en RTF, ou dans un format propriétaire binaire ; mais cela ne change pas la structure du document encodé. Le format de ces application s est stabilisé il y a maintenant 20 ans, avec la sortie de Microsoft Word.5. pour Macintosh, et la défaite des programmes alternatifs, notamment WordPerfect. Depuis lors, c est le modèle du Xerox Park et Steve Jobs qui gouverne les applications grand public : le WYSIWYG, «What you see is what you get», «ce que vous voyez, c est tout ce que vous aurez» (et rien de plus). La compatibilité entre les logiciels repose sur un modèle formel similaire du texte qui peut être brossé à grands traits. Les traitements de texte répondent à un besoin identifié dès les années 960, depuis les premières machines à écrire à mémoire ou les programmes de photocomposition : un texte s écrit en ligne et s imprime en surface. Alignements et justification occupaient un temps important qui pou- OpenDocument (.odt : OpenOffice, LibreOffice depuis 200 sous le nom.sxw), OfficeOpenXML (.docx : Microsoft Word, depuis 2007) Communication du 2/0/20 à Caen, 2/

vait s automatiser. Il en résulte un modèle du texte à deux niveaux : une suite de paragraphes contenant des caractères. Les mises en formes (gras, italique, tailles, polices ) peuvent être appliquées en cours de ligne, sur une suite de caractères, ou à tout un bloc, comme pour un paragraphe de titre. XML se prête spécialement bien à la conservation de telles structures, notamment pour le texte de mises en forme mêlées, mais bien des structures en XML ne peuvent pas trouver une forme en traitement de texte, notamment les hiérarchies complexes. Avec le temps, pour répondre à des besoins éditoriaux classiques, le modèle s est enrichi de quelques exceptions ajoutant ou simulant des niveaux hiérarchiques dans la structure du texte. Les styles de titres numérotés de à 0 permettent de générer automatiquement un sommaire hiérarchique, mais cet ordre linéaire n est pas inscrit dans une structure enveloppante et hiérarchique (arbre XML) ; cette structure est simulée, ce que prouve la possibilité de commencer l arbre avec un titre de niveau autre que. Les listes sont imbricables et permettent de structurer un bloc arborescent jusqu à 0 niveaux. Les tableaux aussi sont imbricables, sans limite formelle, sauf la patience et la lisibilité. Enfin, le flux de la ligne peut être interrompu par des points hors flux : les notes de bas de page, les notes de fin de document, les marques d index, ou l insertion d images. L informatisation d une partie de la tradition imprimée permet au traitement de texte de produire des structures un peu plus complexes que de simples séries de paragraphes, cependant cette complexité reposera surtout sur la discipline de l utilisateur, l application ne prévoit pas d assister la création de motifs de contenu et de les valider. Le traitement de texte permet donc de produire certaines structures XML, mais ne se substitue pas à un éditeur XML validant. Outre ces limites théoriques, la pratique révèle beaucoup d effets de bords lorsque les textes bureautiques sont exploités avec rigueur, par exemple pour alimenter une base de données. Ainsi, l encodage d informations structurées au niveau caractère est très limité. Soit par exemple une édition qui indique les noms de personnes en petites capitales. Il semble simple d en extraire automatiquement la liste. En réalité, le rendu du traitement de texte cache des situations variées : ainsi, dans FRANÇOIS I er, le F majuscule peut ne pas être en petites capitales, de même que l espace, le I ne doit pas l être, et le er en exposant non plus. L encodage d un tel segment par un logiciel est inter - rompu à chaque modification d apparence, ce qui n affecte pas l impression, mais qui empêche de conserver la continuité logique nécessaire à l exploitation de l information. Ces artefacts peuvent cependant être contournés en grande partie, ce que nous avons obtenus avec notre programme de conversion de fichiers ODT vers TEI 2. On déconseillera l usage des cadres, visuellement instables entre les logiciels. 2 http://developpements.enc.sorbonne.fr/diple/modules/odt_tei/memo#h_ Communication du 2/0/20 à Caen, 3/

L édition critique rencontre une autre limite importante, le traitement de texte ne gère pas plus de deux couches de notes, en bas de page et en fin de volume. Or l édition critique de manuscrits littéraires ou d imprimés anciens avec de nombreux témoins demande des distinctions supplémentaires. Ce critère est décisif et justifie l abandon du traitement de texte pour certaines éditions, souvent au profit de LaTeX. Pour le Sanctoral, Anne-Élisabeth Urfels-Capot a édité un manuscrit unique, elle n étudie pas les variantes de nombreux exemplaires. Trois niveaux de notes ont cependant été jugés nécessaires : le premier pour les interventions éditoriales (les corrections signalées) ; un second pour les gloses ; enfin, à la fin de chacune des leçons, sont énumérées les sources hagiographiques mobilisées (identifiées d'après leur édition moderne, par exemple dans la Bibliotheca hagiographica latina, abrégée BHL). Un traitement de texte a suffi à l auteur pour mener son livre à bien, le fichier a été repris en PAO, puis envoyé à l imprimeur. La reprise du texte pour l édition électronique en XML/TEI a montré d autres limites. L auteur n avait pas utilisé les styles de titres hiérarchiques, il n a donc pas pu vérifier l arbre de sa table des matières. Les erreurs de mises en forme auraient produit des incohérences peu acceptables dans la division automatique des chapitres. Le travail d édition électronique a surtout concerné la reprise des citations bibliques dans le corps des leçons, ainsi que la structuration des identifications de sources (plus de mille). L auteur étant malheureusement décédé depuis, il n a pas été possible de normaliser ces enregistrements relatifs aux sources de manière à en établir l index automatique. Ils sont normalisés pour l affichage, pas pour les traitements. Une telle liste aurait pourtant offert une forme de navigation, mais aussi un outil quantitatif pour mesurer plus efficacement la part des sources mobilisées. Un livre écrit avec un traitement de texte peut être repris pour l écran en TEI, mais le projet éditorial conservera les limites induites par le logiciel. Les utilisateurs se sont habitués à jouer avec ces limites, à chercher des solutions de présentations qui s en accommodent, n osant par exemple pas demander des notes marginales, ou un deuxième flux synchronisé de texte pour une traduction. Un traitement de texte peut en effet produire du XML affichable, mais cela ne suffit pas en faire un outil d édition électronique. Nous avons pu établir un tel index pour notre édition électronique des Chroniques latines de Saint-Denis dirigée par Pascale Bourgain (http://elec.enc.sorbonne.fr/chroniqueslatines/refs). Communication du 2/0/20 à Caen, 4/

Propositions pour la convergence de schémas XML/TEI dédiés à l'édition critique Le traitement de texte résulte d une certaine culture du texte une manière de le penser et entretient cette culture. TEI ne change certes pas radicalement notre rapport au texte mais ouvre de nouvelles perspectives pour son exploitation. Anne-Élisabeth Urfels-Capot, lorsqu elle s est lancée dans l édition du Sanctoral, avait bien mesuré toute l importance philologique et historique du réseau des citations déployé par Humbert de Romans. Les principes de son édition en témoigne : elle explicite systématiquement les sources mentionnées par l auteur et signale les procédés d adaptation employés. Pourtant, le signalement de ces sources, aussi précis et lisible (sur le papier) soit-il, ne permet pas de dresser un index ou d établir automatiquement des comptages. Aussi Pascale Bourgain, pour établir dans sa présentation de l édition que le sanctoral du lectionnaire se fonde sur 24 textes différents, a-t-elle dû établir ce compte manuellement. Avec TEI, naît le réflexe d appareiller le texte pour automatiser de telles opérations : dans un élément <listbibl>, il est aisé de dresser la liste de référence des ouvrages (<bibl>) cités, chacun caractérisé par un attribut xml:id pour assurer la correspondance avec leur repérage au fil de l édition (<bibl corresp="#monid">). TEI permet même d établir de telles correspondances de différentes façons. Un tel balisage ouvre des perspectives scientifiques, permettant par exemple de quantifier précisément l influence de différents auteurs médiévaux dans l élaboration du lectionnaire ou la part des types textuels cités (homélies, sermons, récits hagiographiques). Un tel repérage des citations sur un corpus plus vaste permettrait de mesurer par exemple l influence du lectionnaire cistercien : quelle base de textes communs partage-t-il avec le lectionnaire dominicain? TEI avec sa très vaste librairie d éléments autorise toutes sortes d exploitations du texte édité. La seule limite est sans doute l imagination du chercheur. Dans le cas du Sanctoral on pourrait par exemple entreprendre un travail très utile sur la versiculation exprimée explicitement dans le manuscrit. Le repérage systématique des signes de versiculation aiderait à mettre en évidence leur potentialité sémantique. Avec TEI, à l inverse d ODT, le problème n est plus celui des limites du format, mais du nombre des possibilités offertes qui peuvent épuiser le temps de l éditeur, nuire à la cohérence d un même projet, et surtout, empêcher l interopérabilité des éditions pour la constitution de corpus de recherche plus larges : comment établir des comparaisons entre les lectionnaires domi- Lire la présentation de P. Bourgain, http://elec.enc.sorbonne.fr/sanctoral/presentation Communication du 2/0/20 à Caen, 5/

nicain et cistercien si leurs sources sont encodées différemment? Choisir TEI nous condamne-t-il donc à programmer continuellement une tuyauterie de filtres de conversion? Martin Mueller pose la question avec malice dans sa lettre datée du 4 août 20, adressée aux membres des TEI-C Board and Council : «The TEI is about encoding. (...) What about the decoding of TEI encoded documents?» TEI permet une sophistication extrême de l encodage, mais sa sophistication précisément (plus de 500 éléments) complique la conception d outils parfaitement génériques. Considérons par exemple le cas de l apparat critique. Si l on se réfère au chapitre qui lui est consacré dans les Guidelines de la TEI, on se perd vite dans le nombre des possibilités d encodage. Le seul élément <app> peut contenir jusqu à 43 éléments. Cette richesse est bien sûr un des atouts de TEI : elle favorise les expérimentations concurrentes, toujours riches d enseignements. Mais la combinatoire qui en résulte laisse de trop nombreuses possibilités pour permettre de concevoir un traitement générique, même avec un objectif aussi trivial que la transformation du fichier source en HTML pour une lecture à l écran. Pour l éditeur d un corpus, ce n est plus de la liberté, mais une confusion qui nuit souvent à la rigueur de l édition. Dans de nombreux projets, pour bénéficier d un service, on adopte de fait les spécifications propriétaires de l application qui le garantit le mieux : les équipes n ayant pas les moyens d acquérir toutes les compétences sont parfois obligées de modifier leur balisage pour obtenir un affichage satisfaisant, par exemple avec PhiloLogic ou XTF. Pourtant, les applications ne doivent pas influencer l encodage, et c est au chercheur ou à l éditeur de faire les choix les plus appropriés. À l'école des chartes, nous avons donc commencé par resserrer nos schémas sur les besoins spécifiques de l édition critique, à savoir l expression de variantes, en limitant donc le contenu de <app> à deux éléments : <lem> et <rdg>. La simplicité apparente de ce schéma résulte d un véritable effort de modélisation à partir des différents cas rencontrés. Cet effort permet de maîtriser très précisément le contenu des sources XML et d écrire du code sur-mesure, robuste et qui sera générique pour l ensemble des nouveaux fichiers produits. Pour éditer un nouveau corpus, inutile d'écrire de nouvelles XSL 2 dédiées ; l affichage, fidèle aux usages de l'édition critique, est garanti pour tous les corpus encodés conformément aux schémas. De la même manière, il devient possible de composer des feuilles d'export génériques vers des outils de fouille statistique. L'effort de normalisation le lent repérage des motifs d'encodage les plus génériques et robustes et la rédaction de schémas très finement définis et documentés permet l'exploitation efficace des fichiers sources XML produits. En amont, cette maîtrise du schéma, par la définition précise de la structure du docu- http://developpements.enc.sorbonne.fr/diple/schema/ 2 http://developpements.enc.sorbonne.fr/diple/transform/ Communication du 2/0/20 à Caen, 6/

ment à encoder, permet de configurer finement les outils pour produire le fichier source XML. Pour l'édition des Chroniques latines, nous avons été confrontés au même problème d'identification des sources et avons pu (contrairement au cas du Sanctoral) formaliser un schéma avant de produire le fichier source. À partir d'une telle spécification, nous pouvons définir un modèle de document OTT pour utiliser efficacement le traitement de texte et prévoir, lors de la transformation TEI, la récupération des références aux sources soigneusement signalées au fil du texte. Pour la personnalisation des schémas, le consortium TEI propose un outil très perfectionné, la syntaxe ODD couplée avec les formulaires Roma. ODD répond d abord au besoin de générer la documentation de tout TEI ; cette finalité initiale affecte son usage pour la définition de projets éditoriaux spécifiques. L utilisateur est invité à choisir les chapitres de la documentation qui l intéresse et à retirer les éléments qu il n utilise pas. Or l expérience montre qu un projet finit par emprunter à tous les chapitres, si bien que la plupart des utilisateurs finissent par tout prendre pour être sûr de ne manquer de rien. A l'usage, et très paradoxalement, Roma/ODD mène à renoncer à la validation, et donc en un sens, à XML. En effet, un projet éditorial ne se pose pas nécessairement selon l ontologie TEI. Le core TEI seul est déjà trop important et trop permissif. La démarche qui consiste à concevoir un schéma en retranchant des éléments d'un tronc commun est dangereuse ; elle conduit souvent à maintenir dans un schéma spécifique des éléments superflus qui parasiteront la validation. Il est possible d établir un bon schéma avec ODD, mais essentiellement par ceux qui sauraient le faire sans ODD. L'expérience montre qu'une bonne modélisation n est pas soustractive, mais constructive, l éditeur connait mieux son corpus que TEI, il est plus efficace de partir du besoin spécifique et de ce seul besoin. Pour le Sanctoral, l aspect spécifique du schéma à valider concerne au final uniquement la hiérarchie des chapitres et la structure d une leçon, avec le cas particulier des références aux sources que l on voudrait pouvoir réunir dans un index. Le travail de normalisation nos éditions (environ 00 Mo de fichiers TEI) nous permet d aboutir à cette conclusion : l édition sous schéma validant exige et soutient une compréhension plus profonde du document et permet d'optimiser les développements d exploitation des corpus. Un projet éditorial plus strictement défini permet un usage du traitement de texte détaché de l apparence imprimée, conçu comme un apport initial dans la chaîne de production du texte, avant d autres étapes de validation et d enrichissement. Ainsi Anne-Élisabeth Urfels-Capot aurait pu continuer à écrire avec son logiciel bureautique habituel, tout en produisant une structure permettant l indexation de ses identifications de sources. Une équipe éditoriale multi-support aurait donné la consigne d utiliser des marques d index afin d encoder une clé de regroupement des références. Communication du 2/0/20 à Caen, 7/

L interface du traitement de texte permet à l auteur de surveiller la progression et la cohérence de son index qui est ensuite repris pour l édition électronique. Cette chaîne est techniquement possible, mais est-elle humainement concrétisable avec les compétences actuelles des auteurs? L éditeur, l auteur et la structure Pour publier, que ce soit sous forme imprimée ou électronique, l éditeur a besoin d un texte structuré. La question est de savoir d où vient la structure, et surtout, quel degré de structuration du texte on peut attendre d'un auteur? Pour ce dernier, il existe deux manières de le structurer : par mise en forme typographique ; par stylage dans un logiciel de traitement de texte. Avant l informatique, l auteur, pour structurer son texte, jouait uniquement sur les différentes mises en forme typographiques possibles : gras, soulignement, italique, petites ou grandes capitales, taille et nature des polices, types de justification. Un titre était par exemple distingué du texte courant par un corps plus élevé, une mise en forme en capitales et une justification centrée ; les paragraphes étaient repérés et distingués entre eux par des retraits positifs de première ligne. La structure était donc figurée mais non écrite. L informatisation des pratiques de rédaction et d édition a modifié la donne. Dans un premier temps, par atavisme, les auteurs utilisèrent les traitements de texte comme des stylos ou des machines à écrire, se contentant de mettre en gras, en italique, etc. Puis ils s initièrent au maniement des outils informatiques. Depuis une petite dizaine d années, ils commencent à découvrir les possibilités des logiciels et les gains qu ils peuvent en tirer. De plus en plus d auteurs s essaient au stylage, pour gagner du temps dans la mise en forme, pour générer des tables des matières automatiques, ou tout simplement pour s y retrouver dans le texte quand les niveaux de titre sont nombreux. C est une rupture conceptuelle remarquable : avec ces styles, l auteur met de la structure dans le texte même. La structure sémantique sort du sommeil métaphysique où elle planait et vient s écrire, plus précisément s encoder. Elle enrichit désormais le texte d une dimension invisible, mais concrète : les balises. À la zone d application d un style correspond une unité sémantique décidée par l auteur et matérialisée par l encodage (en général, son nom vient désigner le type d unité, par exemple «prénom auteur» ; «titre I»). Dans un second temps, des caractéristiques typographiques lui sont attribuées. En maniant les styles, les auteurs structurent donc leur texte, souvent sans le savoir. Communication du 2/0/20 à Caen, 8/

Revenons à notre question : que peut attendre un éditeur d un auteur en termes de structuration? Il peut obtenir une structuration purement typographique. Dans ce cas, s'il veut une structure en bonne et due forme, il doit repartir de zéro. Mais s il n en veut pas, il peut s en accommoder. Les éditions de l École des chartes ont ainsi traité, encore récemment, des projets d'ouvrages reçus sous la forme de fichiers Word, entièrement mis en page et typographiquement prêts, tout cela sans stylage. L'un d'eux résulte d'un travail de vingt ans, d une grande complexité graphique, retapé à partir de fiches cartonnées. L éditeur n a apporté aucune modification, le fichier a été imprimé, le livre était réussi ; en revanche, il n'a pas pu être exploité autrement, en base de données par exemple. La zone opérable serait donc celle du stylage sous traitement de texte. Mais peut-on obtenir des auteurs un usage rigoureux du stylage? La réponse vient immédiatement à l esprit : cela dépend des auteurs. Certes, mais cela dépend tout autant de la volonté éditoriale. Quel est le projet? Veut-on un fichier XML valide pour une édition multisupport, un stockage pérenne des données ou la possibilité d exploiter les ressources textuelles par des moteurs de recherche? Ou se satisfait-on d un simple import de texte stylé, dans un logiciel de PAO, pour une édition papier? Si l éditeur décide de faire styler l auteur (parce que le projet le nécessite et que l auteur le peut), l éditeur joue une partie du rôle d un éditeur XML : définition de la structure, contrôle et validation. C'est là remplacer un feu tricolore par un agent de la circulation : le traitement s'avère plus souple, mais aussi plus laborieux. Même avec un auteur soigneux, il restera des problèmes invisibles à l œil mais qui gênent la structuration : un style pour les noms propre en petites capitales, qui n est pas appliqué à la majuscule initiale ; un style de titre en capitales où lettres minuscules et majuscules sont mélangées ; un repentir qui laisse un espace avec un style servant par exemple à l extraction d un index des concepts ; des espaces non stylés qui interrompent un terme en plusieurs mots ; La production d'un fichier parfaitement valide ne sera possible qu au terme de longs et coûteux efforts. La récompense c est qu un bon stylage se récupère dans un logiciel de PAO et peut être ensuite enrichi. InDesign permet par exemple de rassembler des styles dans des groupes de styles (ce qui permet une profondeur de structure par le haut) et d imbriquer des styles de caractères dans des styles de paragraphes (ce qui apporte une profondeur de structure par le bas). Cet outil apporte un plus qui le rapproche d un éditeur XML. L évolution va de toutes façons dans le sens d un rapprochement entre les logiciels de PAO et les éditeurs XML : on peut déjà charger des DTD dans In- Communication du 2/0/20 à Caen, 9/

Design, importer du XML, tester la validité de la structure, etc. A la fin du processus, on peut exporter les fichiers dans un XML de bonne tenue. Pour conclure, on peut certes demander à un auteur de structurer son texte par stylage sous traitement de texte, après avoir défini en amont un schéma. Mais la pratique enseigne qu'il est souvent difficile d obtenir des auteurs un travail aussi rigoureux, en particulier pour des stylages qui ne modifient pas l'aspect visuel du texte. Les logiques de rédaction et celles d édition convergent laborieusement. Bien souvent, l éditeur préfère styler lui-même le texte dans un logiciel de PAO. Ce qu il perd à tout faire, il le gagne en temps d explications pédagogiques, de contrôles, et d attente des retours auteurs. En définitive et en l'état des pratiques, la seule voie si l éditeur veut rigoureusement structurer un texte, c est qu il s en charge lui même. L auteur joue un rôle au moment normatif de définition du schéma ; l éditeur doit assurer l exécutif. Reste à déterminer s il est plus pertinent pour l éditeur de styler en PAO puis d exporter en XML ou d encoder directement en XML. La seconde voie est celle d avenir, mais elle suppose une formation des éditeurs qui peut prendre encore du temps. Conclusion Le traitement de texte a révolutionné l édition. Cependant l édition critique n est pas seulement un flux, c est aussi une forme, et le traitement de texte tend à simplifier et limiter cette forme. Il est possible d extraire toute la structure d un document conçu avec un logiciel bureautique vers par exemple XML, mais utilisée seule, l application limite le projet éditorial en deçà même de la tradition imprimée. Le document électronique ouvre d autres perspectives éditoriales. Depuis les années 990, l initiative TEI réfléchit et structure ces nouvelles possibilités. La lecture de sa documentation est non seulement un manuel d édition traditionnelle, mais aussi un réservoir d innovations, ouvrant même des pistes pour l exploitation scientifique des corpus. Cependant, toutes ces potentialités risquent d égarer le projet éditorial si un schéma n est pas explicitement défini. Cette définition intellectuelle évite de limiter le document à ce que peuvent les formats et les logiciels, cette distance théorique permet même de les utiliser autrement, non pour leurs résultats apparents, mais pour les structures d information qu ils produisent. Dans ce cadres, un usage raisonné et productif du traitement de texte est alors possible. Communication du 2/0/20 à Caen, 0/

Cependant, ce modèle suppose un chercheur idéal qui serait complètement autonome avec ses logiciels. Un bon usage des styles ou de TEI revient plutôt à renforcer le rôle de l éditeur, dans une organisation plus collective du travail. Cette mutation est en cours à l École des chartes. Communication du 2/0/20 à Caen, /