Un long article de Deyan GINEV repris par Yihui XIE (le créateur entre autres de knitr) explique avec force arguments que LaTeX est mort. Vraiment ?

Tout d’abord précisons que ces deux auteurs ne sont pas n’importe qui. En plus de leur compétence technique ils ont déjà une longue réflexion sur les langages & en particulier la manière d’écrire un texte. Pour résumer (en déformant un peu leur réflexion), [**LaTeX*] est complexe & très orienté vers le papier. Hors actuellement un document doit d’abord être pensé pour le web ou autre support immatériel. De plus pour les textes scientifiques [**Markdown*] ou dérivé est beaucoup plus simple d’emploi avec de très bons résultats, sauf pour les math. Et je ne résiste pas à vous rappeler la syntaxe [**LaTeX*] pour augmenter la hauteur des lignes d’un tableau : \renewcommand{\arraystretch}{2} Instinctif n’est-ce pas ? Quand on a pas sucé [**TeX*] dés le berceau l’apprentissage est quand même abrupt. Sans parler des multiples packages écrits au fil du temps pour faire la même chose, lequel je prends ? (exemple : graphic, graphics ou graphicx ?) Il est vrai que [**TeX*] puis [**LaTeX*] ont été conçus pour écrire du texte ou des formules mathématiques dans de gros livres imprimés en noir & blanc. Pour tout le reste (couleurs, images etc.) il a fallu écrire des extensions sous forme de packages. Et je reste là sur de l’imprimé. Si on va vers du format informatique que ce soit des documents proches du papier mais avec des liens hypertexte (un pdf par exemple) c’est faisable sans grande difficulté, mieux qu’avec un traitement de texte mais c’est encore un package en plus. Qui doit être placé en dernier etc. Rien de complexe mais mettez-vous à la place du débutant qui a bien noté tous ses [**\usepackage*] & obtient des messages d’erreur parce que un package est appelé après [**hyperref*] ! Donc un langage déjà complexe au départ, compliqué encore par l’appel de nombreuses extensions ayant chacune sa logique. Mais par quoi le remplacer ? Les deux auteurs cités au dessus parlent de [**Markdown*] mais mettent surtout en avant [**html/css*].

Et oui le machin qui peine à garantir qu’une page va s’afficher correctement, à la mise en page incertaine & à la typographie simpliste (pou être gentil). Mais qui gère les liens comme personne (heureusement !), permet toutes les animations, images, vidéos, sons etc. Donc, certes pas demain matin, mais rapidement [**html/css*] pourra, avec quelques progrès, permettre de générer des documents tels qu’on les imagine aujourd’hui, capables de s’adapter à tout support. Par exemple pour créer une présentation Xaringan ou autres permet de le faire avec toute la puissance du couple [**html/css*] avec un soupçon de [**Javascript*]. Peut-être. En Attendant il reste [**Markdown*] avec un convertisseur [**LaTeX*] comme Pandoc pour sortir des documents corrects. Ce qui entraîne deux réflexions :

• [**LaTeX*] sera probablement de plus en plus utilisé en arrière plan pour la qualité du rendu final mais sans qu’on voit le code.
• Quid des documents complexes ? Mélanger une biblio par chapitre, un index, des notes à plusieurs niveaux, [**Markdown*] est incapable de le gérer. Même une simple fusion de cellules dans un tableau est impossible. Donc aujourd’hui, pas encore de solution globale.

Pour ma part j’écris tous mes rapports statistiques avec [**RMarkdown*] soit du [**Markdown*] qui permet d’incorporer du code [**R*]. Et comme je ne maîtrise pas encore très bien les subtilité des entêtes de [**RMarkdown*], je refignole à la main la sortie finale en LaTeX. Je rends un document en html, clair, lisible & un document en pdf ou en .doc plus facile à retravailler pour le client. Donc plus de [**LaTeX*] en routine sauf pour les diapo de cours. Autre avantage, les calculs restent là & peuvent être relancés à tout moment : un travail doit être reproductible. Avec knitr et org-mode aussi me direz-vous ? Et vous avez raison mais le code est moins clair, plus difficile à maintenir. Question de goût.

Et je surveille tout ça, ça bouge, ça évolue !