DH et Steampunk (2) : bonnes pratiques et standards

Suite du précédent article qui s’intéresse à quelques autres lignes du texte de Paul, où il attaque cette fois les bonnes pratiques :

Enfin, et là je vais jeter un gros pavé dans la mare, il faut parler des bonnes pratiques. Parce que les bonnes pratiques sont peut-être une excellente chose, mais elles sont aussi un frein. Tout d’abord il faudrait voir exactement ce qu’il y a derrière, car c’est aussi un terme dont on se gargarise, il faut bien l’avouer. Par exemple, on se focalise sur l’archivage – je ne dis pas que ce n’est pas important –, on se focalise sur la structuration et la possibilité de mise en opérabilité, et on oublie (ou en tous cas on ne se positionne pas) sur le reste. On ne se positionne pas sur l’innovation conceptuelle par exemple, sur l’enrichissement sémantique, sur la granularité des outils d’interrogation, ou simplement sur la décomposition de ces fameuses données. J’ai peur qu’on se contente de bonnes pratiques aujourd’hui dans les digital humanities et que l’on renonce à un certain devoir d’audace.

 

En quelques lignes, Paul me donne envie de beaucoup parler. Je vais être obligé de faire plusieurs billets sur les bonnes pratiques, celui-ci est le premier, il concerne les standards (j’utilise ici standard au sens anglo-saxon et ne parlerai pas de norme).

Dans la communauté des Digital Humanities, à peu près tout le monde semble convaincu par la nécessité de suivre les standards comme bonne pratique pour la réalisation d’un projet. Mozilla doit être pour beaucoup dans l’évangélisation sur le sujet, les membres de la fondation ont agité avec succès le drapeau des standards pendant des années. Pourtant en lisant Coders at Work, on tombe sur Brendan Eich (M. Mozilla) disant qu’agiter le drapeau des standards est « à double tranchant et à moitié de la connerie » (p. 156). L’homme qui a participé à l’éducation de milliers de personnes sur les standards du Web mitige leurs bienfaits profonds. Il ne développe pas plus loin, mais je vais partir de là pour donner quelques limites aux standards dont il faut avoir conscience et pour comprendre quand on peut et quand on doit faire preuve d’audace et ignorer les standards. Notez bien que si je ne dis rien pour défendre les standards ici, j’en suis malgré tout un fervent défenseur. Je parle de limites, pas de raisons de tout jeter par la fenêtre. En tenant compte de ces limites, je discuterai ensuite de la TEI, le standard de représentation des textes anciens sous forme numérique.

Quand je lis Paul sur les bonnes pratiques, je comprends que ces dernières peuvent ralentir un projet au point que l’on n’arrive plus à faire ce que l’on était censé faire avec ledit projet. Le problème avec un standard c’est qu’on perd un temps monumental à le suivre. Dans une présentation provocatrice sur la morosité de la recherche sur les systèmes d’exploitation, Rob Pike se plaint que 90 à 95 % du temps passé à écrire le système d’exploitation Plan 9 a servi à implémenter l’ensemble des standards nécessaires pour faire vivre ce système d’exploitation avec les autres. Pourtant Plan 9 semblait révolutionnaire à son époque et fut le premier système à implémenter UTF-8. L’audace c’est 5 à 10 % de temps pour 90 à 95 % d’absence de révolution. Les standards peuvent manger un temps monstrueux, quand vous devez courir derrière quelqu’un, vous devez faire tout ce qu’il fait et être compatible avec lui sinon vous n’existez pas. Avoir bien suivi les standards ne fut pas suffisant pour que Plan 9 aille au-delà du succès d’estime.

Cette position est doublement dangereuse. Outre que l’on perd du temps sans arriver à convaincre, le mec qui court devant peut trouver que vous êtes un boulet. Lui il implémente les standards pour vous faire plaisir, que vous puissiez trottiner derrière lui, mais à un moment ou à un autre il va vous planter là. Parce que les standards, il les a tous implémentés, il est devant vous et maintenant il a envie de passer à la vitesse supérieure. Un exemple ? En ce moment, la plupart des systèmes Linux sont en train de faire des bras d’honneur à l’ensemble des autres systèmes compatibles POSIX alors qu’ils avaient dû montrer patte blanche durant les années 1990-2000 pour respecter ce standard. Survivre pour UNIX ou les clones libres comme *BSD ne voudra plus dire suivre POSIX, mais suivre POSIX et les extensions non standards de Linux. Linux aussi fait des choix entre portabilité et innovation. Il est en concurrence avec d’autres et n’a pas le temps d’attendre tout le monde.

Puisque l’on parle de portabilité (un des gros avantages des standards), voyons quelques instants comment se fait cette portabilité au quotidien. On écrit quelque chose, puis on le teste sous une implémentation de référence. Par exemple si l’on fait du web, on essaye sa page dans Firefox. Lorsque l’on est content du résultat, on teste son code sur les autres plateformes communes du marché. On se retrouve souvent dans l’obligation d’adapter son code afin qu’il se comporte bien sur toutes les plateformes (Chrome, Safari, IE, Opera…). On perd du temps à cause des autres ! Pourquoi ? Un standard peut être ambigu et compris différemment selon les participants. De plus il peut y avoir un historique à respecter qui ne respectait pas lui-même les standards. Spolski décrit admirablement l’incroyable complexité des standards du web dans son article sur les écouteurs pour martiens. Ce qu’il faut retenir ici c’est que l’on a besoin d’implémentations de référence.

Toujours sur le web, notez comment récemment les principaux acteurs de ce marché à nouveau très concurrentiel ont réussi à se mettre (presque) d’accord sur leurs innovations. Ils ont pris comme plateforme de référence leurs outils et sont sortis du W3C qui a fait un standard sans prendre en compte l’existant. Les éditeurs se sont rebiffés, ont créé leur propre environnement pour mettre à jour le standard, ont été réintégrés au W3C avant de se dire qu’ils allaient en ressortir en partie parce que le processus était trop lent. Les producteurs de standards ne sont pas sacrés, on peut décider de ne pas les suivre et de créer d’autres standards et cela peut être bénéfique pour tout le monde.

Notons enfin que l’on n’a pas forcément besoin de standard pour faire quelque chose de fantastique. Quand Ken Thompson s’est dit « tiens je vais écrire un système d’exploitation » il n’a pas pris le standard du jour pour l’implémenter. Il a pris un petit PDP-7 qui traînait là, il a bricolé un truc qu’il trouvait bien dessus. Dix-neuf ans après, ça avait tellement bien pris, c’était tellement utilisé que ça a été standardisé. Vous pouvez aussi travailler avec les autres sans standard. Json ou Markdown par exemple ne sont pas standardisés. Pourtant ils sont suffisamment documentés pour être incroyablement simple à scanner, parser et utiliser. Des centaines, des milliers d’applications les moulinent et n’importe quel hacker en tire ce qu’il veut en quelques lignes de {perl,python,ruby}.

Pour moi, battre le drapeau des standards est à double tranchant parce qu’en permettant de parler avec tout le monde, on ralentit l’innovation. Pour pouvoir innover dans un environnement standard et être suivi, il faut être suffisamment dominant et méprisant pour pouvoir se moquer de savoir si les autres suivent ou pas. Il existe aussi le cas où c’est un groupe de dominants qui se détachent du droit chemin pour travailler ensemble sur un nouveau chemin. Enfin, on trouve régulièrement dans l’histoire des choses n’ayant pas commencé sous la forme de standard ou n’étant pas standardisées et qui sont utilisées massivement tous les jours.

J’espère que je ne vous ai pas perdu, ça fait plusieurs paragraphes que je ne parle pas du tout de Digital Humanities. Justement quels standards suit-on dans les Digital Humanities ? Je ne vais prendre qu’un exemple : celui avec lequel j’ai le plus passé de temps : la TEI. Et en fait ce n’est pas vraiment un standard. Qui court derrière, qui court devant ? Où est l’implémentation de référence ? Parfois j’ai l’impression que tout le monde court derrière et que les seules personnes devant sont des évangélistes qui assurent qu’on est presque arrivé. Il n’y pas d’implémentation de référence et ce qui est sûr c’est que tous ceux qui sortent de l’orthodoxie sont fustigés. En fait, j’imagine presque Paul disant :

Troisième espoir que nous avions, les historiens producteurs de TEI, et je sais que cela a fait l’objet de beaucoup de discussions ces derniers temps. Sur ce concept aussi, je suis très perplexe. Je jette ma pierre dans le marigot de la discussion dans laquelle tout le monde se dépêtrera demain. Je pense que ce concept d’historien producteur de TEI est dangereux et n’a pour l’instant pas donné de résultats.

La TEI est un ensemble de recommandations, pas un standard. Quelle est la différence ? Peut-on bien travailler avec les autres avec des recommandations plutôt qu’un standard ? Tout projet avec de la TEI un tant soit peu développé que j’ai pu voir (Telma, les publications de l’École des chartes) n’est compatible qu’avec lui même. Par exemple l’IRHT, l’École des chartes et le King’s College produisent des fichiers TEI de chartes médiévales. Peut-on utiliser les outils de l’un pour manipuler les chartes de l’autre ? Je ne crois pas. C’est comme si chacun avait un web privé de son côté que le navigateur de l’autre ne pouvait pas lire. Au sein de l’École des chartes, je compte au moins trois manières différentes de décrire une charte avec des outils différents pour les traiter. Le seul truc TEI un peu interopérable c’est la TEI Lite, et là vous pouvez faire la même chose que ce que vous faites avec du HTML, du DocBook ou du Markdown sauf qu’il n’y a pas des dizaines de moulinettes ou bibliothèques sympas existantes pour gérer votre document (avez vous essayé Pandoc ?). Trop de gens prêtent à la TEI les avantages des standards, alors qu’elle ne les a pas. La TEI se révèle plus lourde à mettre en place, à comprendre et à implémenter que bien des standards à base de XML. La TEI vous donne deux choix : être lourd sans en avoir l’avantage d’un standard (la portabilité), ou être léger sans les avantages d’un standard (plein d’outils existants pour les gérer). La TEI ne vous permet pas de tester votre code sur une plateforme de référence, elle attend que vous écriviez la plateforme de référence et vous n’avez que le temps d’écrire ce qui fera tourner votre code et seulement votre code.

Je peux me tromper, ça fait un bout de temps que je n’ai pas suivi les nouveautés de la TEI, il y a peut-être plein de plateformes utilisées par plusieurs institutions profitant d’un champ large de balises, mais en lisant Paul j’ai compris que la plupart des projets utilisaient toujours la TEI Lite. Il y a quelques années j’ai soumis à Mark Olsen (M. Philologic) l’idée que la TEI ne servait à rien et qu’il valait mieux s’en affranchir. Ce dernier m’a assuré que non, malgré tout ce que l’on pouvait reprocher à la TEI, c’est la TEI qui avait gagné et que comme c’est ce que tout le monde faisait, il fallait l’utiliser. Mark a beaucoup milité pour avoir des outils génériques de traitement de la TEI qui ont toujours été méprisés parce qu’il faudrait quelque chose qui fasse tout, même si on n’arrive pas à le faire, plutôt que quelque chose qui ne s’arrête qu’à quelques possibilités intéressantes de la TEI. Mark a sans doute raison. Ça ne sert à rien de réinventer la TEI, elle est relativement utilisée, a malgré tout des qualités et a résolu des problèmes qu’on a sans doute pas envie d’avoir à nouveau. Ce que je regrette, c’est qu’il soit très difficile, sous prétexte de « bonne pratique », de s’affranchir de son orthodoxie. Je ne trouve pas qu’elle ait fait des preuves d’utilité et de facilité d’utilisation justifiant un tel respect. Je ne peux souhaiter que de l’audace et de l’innovation à son propos.


Publié par

Nicolas Legrand

Maîtrise d'histoire, DESS de compétence complémentaire en informatique, six ans à l'École nationale des chartes, trois à l'Observatoire de Paris-Meudon, à la BULAC depuis décembre 2013. Développeur Web, administrateur système et réseau, administrateur de système de gestion de bibliothèque.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.