md-vs-docx

git clone git://bebou.netlib.re/md-vs-docx

Log | Files | Refs |

readme.md (17674B)

 # Des notes au sujet de markdown vs office
 
 Côté thèse on a identifié la question de l'indexation des documents de travail
 et les recherches qui suivent comme un sujet potentiellement intéressant. Se
 pose la question de la pertinence d'une indexation centralisée au niveau du
 serveur vs une indexation en local, en particulier si plusieurs postes indexent
 les mêmes fichiers.
 
 Côté Commown il est préssenti qu'utiliser majoritairement du markdown pour les CR et
 les prises de notes augmenterait la productivité (ou plutôt ferait baisser la
 frustration ?). De plus certains ordinateurs dans les bureaux n'ont que 8Go de
 RAM et commencent à galérer. Le passage à plus de markdown pourrait être un moyen
 d'éviter un upgrade en RAM ?
 
 Côté Légicoop le besoin de faire de la recherche plein texte est importante.
 Un passage vers du markdown, même comme simple intermédiaire pour la recherche,
 pourrait être pratique.
 
 Il semblerait donc que la combinaison de ces trois sujets est pertinente à
 creuser.
 
 Les hypothèse que j'émets sur le sujet :
 
   * L'écriture, la lecture et le traitement de fichiers texte au format markdown
     nécessite moins de puissance de calcul, moins de stockage, des logiciels
     moins complexes
   * Si c'est effectivement le cas cela peut participer à concrètement faire
     baisser le besoin d'augmenter/renouveller le matériel dans les bureaux de
     Commown
   * `tracker` n'est peut-être pas une super solution : perf douteuses dans
     certains cas, très intégré à GNOME, possiblement "inutile" si on utilise
     surtout des fichiers textes etc).
   * La recherche en plein texte sur des fichiers texte pourrait possiblement
     être faite via une combinaison relativement simple d'outils relativement
     simples (voir les travaux de Paul).
   * L'utilisation de markdown pourrait faciliter la production de documents
     "finis" type pdf.
   * Il y a consensus à Commown sur la volonté de ne pas administrer d'instance
     Nextcloud + Onlyoffice dans le cadre de l'infogérance mais proposer un
     éditeur de markdown léger et le stockage associé serait gérable
 
 La comparaison de l'indexation centralisée et déportée vs en local n'est pas
 triviale, je n'ai pas d'hypothèse à ce sujet. J'anticipe cependant qu'elle
 mettrait à jour des critères n'étant pas techniques tel que le besoin d'avoir
 accès aux résultats de recherche en étant hors-ligne.
 
 Le sujet de la production de document est un souhait à long terme de Légicoop
 et porurait faire l'objet d'une collaboration avec Antoine Fauchié.
 
 La variable humaine sera probablement importante dans la conduite d'un éventuel
 changement. A ce titre là le sujet peut être l'occasion de se faire la main sur
 des méthodes de recherche qualitatives type entretiens. L'enjeux étant de savoir
 si tout cela serait pertinent à proposer aux clients du service d'infogérance,
 quelles en seraient les limites humaines, dans quelle mesure il faudra composer
 avec l'existant et négocier.
 
 ## La situation chez Commown
 
 Chez Commown les documents de travail sont principalement stockés dans un
 nextcloud hébergé par IndieHosters. On y trouve environ 50Go de données. Des
 fichiers texte, des tableurs, des gros zip pour flasher des téléphones, des
 photos et des vidéos pour l'équipe com, des pdfs. Il serait peut-être utile
 d'avoir des stats sur les extensions. Ces documents sont souvent lus et édité
 via la suite OnlyOffice adossée au Nextcloud, parfois en local dans libreoffice
 après synchronisation.
 
 Une partie de la documentation destinée à l'atelier est aujourd'hui sous format
 docx mais est destinée à être migrée en markdown dans un futur assez proche.
 
 Aujourd'hui les besoins identifiés à Commown sont :
 
   * La prise de notes collaboratives
   * La production collaborative de compte-rendu de réunion
 
 La production de pdf et la recherche plein texte n'ont pas été remontés en tant
 que besoin mais très peu de personnes ont été consultées.
 
 Il est anticipé que le plus difficile sera l'accompagnement au changement.
 L'éventuelle mise en évidence d'un bénéfice environnementale et d'une meilleure
 maitrise des données pourrait être mobilisé pour faciliter cet accompagnement.
 
 ## La situation chez Légicoop
 
 Légicoop ont plus de 80Go de documents, en grande partie des docx et des pdfs,
 stockés dans un Nextcloud hébergé par Worteks. La totalité des membres de
 Légicoop synchronisent en local la totalité des fichiers de Nextcloud. La
 culture du travail en local y est développée et les personnes ont une bonne
 maîtrise de leur arboresence de fichiers. Les documents sont lus et édités dans
 Microsoft Word, Libreoffice writer ou la suite Onlyoffice en ligne.
 
 Du fait de la gestion de très nombreux fichiers l'enjeux de la recherche est
 important. Il est habituel à Légicoop de faire de la recherche plein texte ou
 sur les méta-données des fichiers notamment la date de dernière modification.
 
 GNOME, et donc les PCs que Commown loue à Légicoop, embarque un logiciel
 anciennement nommé tracker et dorénavant nommé
 [tinySPARQL](https://tracker.gnome.org/). Il indexe les fichiers du système, y
 compris sur ces méta-données (type artiste d'un fichier de musique) puis les
 rend accessible aux applications de l'écosystème GNOME. Légicoop ont fait état
 d'instabilité dans Nautilus, l'explorateur de fichier de GNOME, et de
 l'incapacité de faire des recherches sur certains propriétés. L'outil ne semble
 pas être très populaire, une recherche sur "tracker" donne en second résultat
 une question stackoverflow "Comment désactiver tracker ?".  Florent a émit des
 doutes sur l'incapacité de Nautilus à faire des recherches avancés sur certains
 critères. Si effectivement le combo tinySPARQL + Nautilus fait l'affaire et ne
 nécessite "que" de la formation alors le passage à du markdown pourrait avoir
 une utilité marginale pour la recherche.
 
 À Légicoop la plupart des documents manipulés ont pour vocation de générer du
 pdf. Le souhait des co-fondateurs serait d'avoir un jour la possibilité de
 générer des documents "très beaux" via LaTeX. L'usage du markdown combiné à un
 traducteur markdown -> LaTeX et des templates LaTeX pourrait leur permettre
 de s'affranchir largement d'une suite Office.
 
 ## Quelques tests techniques
 
 Parce qu'amorcer des vrais tests avec de vraies personnes c'est long et
 difficile j'ai d'abord entrepris de faire quelques tests rapides dans mon coin.
 
 ### La migration d'un existant
 
 J'ai imaginé (keyword imaginé) que l'existence d'un gros corpus documentaire en
 docx ou odt pourrait être un frein conséquent à l'adoption du markdown. Il
 existe plusieurs outils pour convertir du docx en markdown. J'ai pour le moment
 testé [markitdown](https://github.com/microsoft/markitdown), logiciel
 open-source de Microsoft - merci à eux - en python. Ça a les désavantages du
 python - installation fastidieuse, assez lent au démarrage - mais l'avantage de
 bien fonctionner pour des docx, des pdf, dex pptx et même des xlsx. Le readme
 précise tout de même que la qualité du markdown de sortie n'est pas
 nécessairement au niveau pour une lecture tel quel par des humains.
 
 Dans les tests que j'ai fait sur des docx et pdfs aléatoirement piochés dans le
 Nextcloud de Commown j'obtiens tout de même de très bons résultats. Voir les
 résultats dans ce dépôt. Si le but est d'extraire le texte uniquement pour faire
 de la recherche et non pas pour ensuite travailler sur le fichier markdown alors
 la sémantique du markdown n'est peut-être pas nécessaire et `pdftotext` peut
 faire l'affaire. Il est par ailleurs considérablement plus rapide. Sur ma
 machine et un pdf de 7Mo et 1500 pages (la bible) :
 
     markitdown kjv.pdf > kvj.md   101.31s user 0.30s system 99% cpu 1:41.77 total
     pdftotext kjv.pdf - > kvj.txt 3.38s user 0.06s system 99% cpu 3.445 total
 
 Convertir les 86 docx des dossiers que j'ai synchros sur mon PC prend pas mal
 de temps
 
     find -name '*.docx'  0.01s user 0.01s system 95% cpu 0.021 total
     xargs -n1 sh -c  --  165.47s user 12.76s system 121% cpu 2:26.83 total
 
 Et parallelisé :
 
     xargs -P4 -n1 sh -c  -- 230.06s user 17.51s system 341% cpu 1:12.58 total
 
 On est donc pas sur quelque chose de trivial en puissance de calcul mais
 jouable si l'on migre un existant un bonne fois pour toute. Si l'on fait la
 conversion uniquement pour la recherche il faudrait le faire à chaque modif de
 fichier. En prenant le fichier `brainstorm.docx` comme fichier d'exemple[^1], en
 ayant en tête qu'il est assez long et complexe :
 
     markitdown brainstorm.docx > /dev/null  4.23s user 0.21s system 109% cpu 4.050 total
 
 La complexité du document semble avoir une incidence puisqu'avec un docx de 100
 pages mais très simple :
 
     markitdown exemple.docx > /dev/null  1.59s user 0.14s system 127% cpu 1.353 total
 
 Avec l'option `--keep-data-uris` la conversion des docx conserve les images et
 les encode en base64 dans une balise image. Si l'on voulait migrer proprement
 il faudrait extraire les base64 du markdown.
 
 ### Produire des PDF depuis du markdown
 
 Je crois que la plupart des personnes utilisent pandoc + LaTeX. Sans vraiment de template
 cela produit des documents propres mais au style très LaTeX. Voir `2025-06-03.(md|pdf)`.
 Je suppose qu'il y aurait peu d'entreprises satisfaites par un rendu comme
 celui-ci. Il alors de créer des templates LaTeX personnalisé ce qui n'est pas
 une mince affaire.
 
 Les perfs de `pandoc` et `LaTeX` sont pas folles mais à mettre en perspective
 en fonction du besoin :
 
     pandoc 2025-06-03.md -t pdf  0.99s user 0.14s system 99% cpu 1.141 total
 
 Avec le combo `lowdown` + `roff` :
 
     $ lowdown -tms 2025-06-03.md | preconv | groff -Tpdf -ms | zathura -
     lowdown -tms 2025-06-03.md  0.00s user 0.01s system 82% cpu 0.016 total
     preconv  0.00s user 0.01s system 81% cpu 0.018 total
     groff -Tpdf -ms  0.20s user 0.04s system 136% cpu 0.175 total
 
 mais le rendu est encore plus éloigné de ce qu'on s'imagine être un document
 d'entreprise. On dépend de la sortie roff ms de `lowdown` et l'on a donc accès
 uniquement aux éléments markdown implémentés par cet outil. Cela dit cette
 piste pourrait être creusée avec Antoine Fauchié.
 
 Se pose la question du lieu, du moment et de la fréquence de la génération de
 ces PDF. Est-ce que c'est une opération qui a lieu en local et à la demande sur
 la machine des personnes à l'aide d'un outil qui leur est mis à disposition ?
 Est-ce que c'est quelque chose qui a lieu à distance une fois tous les soirs -
 quid de "j'ai besoin de l'envoyer maintenant" ?
 
 ### Faire de la recherche plein texte
 
 Pour faciliter la lecture et la recherche dans l'existant du dossier
 infogérance du Nextcloud de Commown j'ai préalablement modifié tous les noms de
 fichiers pour en retirer les caractères qui pourraient poser des soucis dans
 les scripts :
 
     detox -r ./dossier-a-traier/*
 
 Puis j'ai créé une version markdown de tous les docx et pdf tout en conservant
 le mtime :
 
     find -name '*.docx' | xargs -P4 -n1 sh -c 'echo "$1";markitdown "$1" > "${1%.docx}.md";touch --date="@$(stat -c "%Y" "$1")" "${1%.docx}.md"' --
     find -name '*.pdf' | xargs -P4 -n1 sh -c 'echo "$1";markitdown "$1" > "${1%.pdf}.md";touch --date="@$(stat -c "%Y" "$1")" "${1%.pdf}.md"' --
 
 Ce qui permet ensuite de faire une recherche plein texte un peu brut de
 décoffrage comme ceci - avec `fzy` comme dépendance :
 
     find -name '*.md' |
         xargs grep -H '.' |
         fzy -l 100 |
         cut -d: -f1 |
         xargs ${EDITOR:-vim}
 
 Evidemment si l'on est dans une situation où les fichiers `markdown` ne servent
 qu'à la recherche alors il faut quelque chose d'un peu plus avancé dans le
 style de :
 
     file=$(find -name '*.md' |
         xargs grep -H '.' |
         fzy -l 100 |
         cut -d: -f1 |
         sed 's/\.md$//')
     for ext in docx odt pdf;do
         test -f $file.$ext && libreoffice $file.$ext
     done
 
 En terme de performance c'est parfait sur mon ordi avec 132 documents markdown
 et 89 227 lignes.
 
 Je trouve ça chouette mais je doute que cela convienne à grand monde. Plusieurs
 questions se posent :
 
   * Est-ce qu'il faut de la formation ?
   * Est-ce que c'est vraiment inenvisageable si c'est embarqué dans une TUI un
     peu plus jolie accessible en double cliquent sur un `.desktop` ?
   * Est-ce que c'est quelque chose avec lequel on peut intéragir via une page
     web assez simple ?
   * Est-ce que ça tient la charge sur de très gros corpus ?
   * Est-ce que c'est pas ce que Paul avait déjà fait @Florent ?
 
 ### La taille des documents
 
 L'impact que la conversion de docx et de pdf en markdown a sur la taille des
 documents n'est pas trivial.
 
 ls -larth | awk '{print $5,$9}' | sort -k2 | column -ts ' '
 
 Elle a grandement réduit la taille de ce pdf type formulaire :
 
     9.1K  affiliation.md
     3.2K  affiliation.md.gz
     563K  affiliation.pdf
     8.8K  affiliation.txt
 
 Et bien réduit la taille de ce document complexe avec du suivi de changement
 etc :
 
     93K   brainstorm.docx
     54K   brainstorm.md
     21K   brainstorm.md.gz
 
 Mais considérablement augmenter la taille de ce document ne contenant que du
 texte très redondant pour peu que l'on ne compresse pas la sortie :
 
     8.6K  exemple.docx
     286K  exemple.md
     3.1K  exemple.md.gz
 
 Même histoire pour un document avec une image non compressée mais moins
 dramatique :
 
     74K   exemple-image.docx
     109K  exemple-image.md
     70K   exemple-image.md.gz
 
 Si le docx contient une image elle est intégrée en base64 dans le markdown.
 
 Si le but est de continuer à travailler sur du docx et d'utiliser le markdon
 pour faire des recherches la conversion ne fera que faire grossir le stockage.
 Si l'on substitut un document par un autre il est difficile de dire si l'on
 économisera du stockage ou pas.
 
 ## Un éditeur
 
 On peut distinguer trois grands types d'éditeurs :
 
   1. Editeur de texte classique (vim, emacs, vscode...)
   2. Editeur de markdown, en local, avec rendu (obsidian, zettlr...)
   3. Editeur de markdown, en ligne, avec rendu et collaboration en temps réel
      (notion, codiMD, etherpad...)
 
 On peut noter des avantages et inconvénients à la va vite :
 
   1. Toujours disponible en local. Fonctionnalités d'édition de texte
      potentiellement les plus puissantes. Pléthore de choix, y compris qui
      fonctionne sur des machines très peu puissantes. Migration d'un éditeur à
      un autre techniquement immédiate.
   2. Intègre du rendu pour les personnes pas à l'aise et/ou travaillant sur des
      documents complexes. Intègrent parfois des exports PDF (via pandoc pour
      zettlr par ex). Obsidian a pleins de plugins, y compris un plugin git pour
      de l'éventuelle collaboration qui ne repose pas sur un service entièrement
      en ligne ou un nextcloud. Obsidian n'est pas libre, Zettlr l'est mais est
      plus orienté recherche. Migration d'un éditeur à un autre techniquement
      immédiate.
   3. A priori collaboration la plus "naturelle". Nécessite une connexion et un
      navigateur. Potentiellement un peu (beaucoup) gourmand en ressource.
      Nécessite d'héberger un service sur un serveur, à voir la complexité.
      Migration d'un éditeur à un autre nécessite l'installation d'un nouveau
      service, peut-être la migration de données.
 
 Les options 1. et 2. ne sont pas exclusives. La 3. peut l'être en fonction de
 la manière dont sont stockées les données. Par exemple codiMD utilise une base
 postgres et donc, par défaut, semble ne pas pouvoir simplement se synchro avec
 un système de fichier local pour éditer avec un éditeur local.
 
 ## Merci les LLM ?
 
 Il est suggéré dans le README de `markitdown` que la motiviation première de la
 conversion vers du markdown est de pouvoir entrainer des LLM dessus. Pour les
 PDF c'est également la motivation affichée par
 [pyMuPDF](https://pymupdf.readthedocs.io/en/latest/pymupdf4llm/index.html). Je
 trouve ça super ironique. Microsoft a fait plein d'argent en poussant du Word
 partout, y compris lorsque du texte suffisait, rendant une part significative
 des documents produits par l'humanité difficile à lire pour pleins d'humains. Ce
 n'est qu'une fois qu'il a fallu rendre les documents Word lisibles par des
 machines qu'ils ont développé un outil permettant de rendre tous les docx
 existants lisibles par tous les humains. Et en effet de bord on en profite.
 
 L'extraction du texte des docx et des pdf ne sert pas qu'à entrainer des modèles
 de LLM mais aussi à alimenter des RAG, une technique permettant à un LLM
 de modifier sa réponse en s'alimentant depuis un corpus documentaire existant.
 C'est ce qui permet à certaines entreprises de promettre qu'en mettant tous les
 documents de leurs clients dans une base de donnée leur LLM saura répondre à des
 questions qui leur sont spécifiques comme : "Retrouve moi le compte-rendu de la
 réunion du projet Machin et dit moi ce que l'on avait prévu comme date de fin".
 Ce que je trouve à nouveau assez ironique puisque le fait que l'information soit
 prisonnière dans des PDF ou des docx est l'une des raisons pour laquelle il est
 difficile de chercher dedans. Les technologies développées pour faire
 fonctionner des RAG qui permettent de faire des recherches plus facilement
 permettent aussi de revenir à une situation dans laquelle il n'est pas ou moins
 nécessaire d'avoir recours à des RAG pour faire des recherches plus facilement.
 C'est assez fascinant.
 
 [^1]: il n'est aps dans le dépôt parce qu'il contient des informations
     potentiellement confidentielles de Commown