Les txt, les dossiers et le terminal (TUI)
Dans cet article, je détaille pourquoi j'ai adopté le format TXT comme socle de mon organisation, comment il s'articule avec une structure de dossiers et des outils en ligne de commande (TUI), et ce que cette approche m'a permis de simplifier au quotidien.
Ôde au txt
Je vais démarrer en parlant d'un format de fichier : le format TXT. C'est sur ce format que repose en grande partie mon organisation et les évolutions dans mes pratiques.
Le format TXT (texte brut) est le type de fichier le plus simple qui existe : il ne contient que du texte non structuré, sans mise en forme (pas de gras, pas de couleurs, pas de polices spécifiques). Chaque caractère est encodé selon un standard comme ASCII ou UTF-8, et il peut être ouvert et lu par presque n'importe quel logiciel, sur n'importe quel système d'exploitation (Windows, macOS, Linux, BSD, etc.). Cette simplicité fait que le TXT est très léger, universel et durable dans le temps. Un document avec un seul mot (bonjour) pèsera 8 octets en TXT et presque 9 Ko en DOC (ou son équivalent ODF). Pour un seul mot, l'ODF est 1121 fois plus lourd.
Certes, il n'est pas possible d'ajouter d'images, de tableaux et du formatage, mais pour de nombreux cas d'usage, ce n'est pas nécessaire. Je pourrai très bien convertir ce document en markdown et ajouter des mises en forme, tout en gardant un poids nettement inférieur à un DOC. L'avantage de cette approche basique, outre son poids et sa portabilité, est la facilité de le convertir : en markdown pour un peu de mise en forme, en HTML si besoin, ou encore dans une structure plus riche pour de la publication avec un outil comme Pandoc, pour retrouver toutes les options disponibles dans un logiciel comme Word ou LibreOffice.
Ce faible poids change aussi la donne côté réseau, à commencer par l'email. C'est un format beaucoup plus ouvert, beaucoup moins punitif. Si on prend l'exemple de l'envoi de courriels, la majorité des emails envoyés utilisent le format HTML, plus lourd, qui permet certes une mise en forme, mais qui ouvre aussi la porte à beaucoup plus de piratage (liens cachés, code injecté). À l'inverse, il est possible d'envoyer des emails au format texte, ce qui réduit immédiatement cette surface de risque, diminue les chances d'être considéré comme spam, et apporte en plus l'avantage de la légèreté.
Écrire des comptes rendus, créer des todo-list, obtenir des formats enrichis, tout est possible depuis ce simple point de départ. Reste à structurer et organiser ces fichiers.
Les dossiers
J'ai longtemps cherché à utiliser des logiciels et méthodes de gestion de projet, cela fonctionnait parfois, mais toujours avec un ajout de surcouches qui semblaient démesurées. Mettre à jour ces méthodes et logiciels coupait mon organisation en silos, alors qu'un ordinateur est de base un outil d'organisation. Les dossiers offrent eux-mêmes une manière naturelle de prioriser des informations. Il est rapide d'ajouter des notes, des todos et des documents dans chaque dossier et il devient facile d'avoir une organisation qui suit le mouvement d'un projet. Aucune surcouche n'est nécessaire, juste une méthode d'organisation en fonction des dossiers.
Ma structure de dossiers correspond à mon organisation, de la façon suivante :
piksbox/
├── focusbox/ # projets qui doivent être terminés prochainement ou qui demandent un suivi important
├── workbox/ # projets en cours mais non urgents, en attente de retours
├── frigobox/ # projets pour plus tard, idées
├── studio/ # documents pour gérer ma structure, divisés en catégories (compta, com, modèles, ressources, etc.)
├── inbox/ # suivi courant hors projet
└── dev/ # dossiers de développementCe qui est important est que toutes mes « zones » de travail suivent le même schéma, que ce soit les favoris du navigateur ou les dossiers de mes mails.
Mes projets ne suivent pas nécessairement le même processus, mais je garde une structure similaire dans chaque dossier pour suivre un projet :
un_projet/
├── 01. org/ # gestion, suivi, administration
├── 02. contenu/ # les contenus
├── 03. design/ # éléments graphiques, photos, maquettes, etc.
└── 04. cycle/ # suivi sur le long terme (mesure écoconception, audit, référencement, maintenance)À l'inverse, les dossiers où je stocke le code sont regroupés par typologie de projet (statique, kirby, prototype, ecommerce, fin-de-cycle, basefiles, bin). Ce regroupement me permet de gérer les mises à jour par type de sites/projets, afin de les traiter plus facilement. Plutôt que charger la nouvelle version de Kirby dans chaque projet, je charge la mise à jour une seule fois et la propage localement, d'où le dossier basefiles, qui contient les mises à jour, les modèles en commun (htaccess, config, robots, etc.). Rsync est mon principal outil de déploiement et de gestion des mises à jour.
Le terminal et shell
C'est à ce niveau qu'intervient le terminal et des scripts pour automatiser aisément des étapes répétitives. Un script pour copier le dernier fichier de mise à jour pour les sites Kirby et un script pour déployer la mise à jour après un test et une sauvegarde sur une forge. Makefile est une grande aide pour gérer les commandes régulières plus rapidement. Je centralise mes scripts dans dev/bin avec quelques Alias. Je peux ainsi créer un nouveau projet avec le bon format de dossier, mettre à jour des todo, compression, etc. Mon environnement de construction de site (gestion CSS, police de caractères, photos et svg, déploiement) suit la même logique en reposant uniquement sur des scripts shell et un Makefile. Cela m'évite d'utiliser des outils trop complexes comme NPM ou le dernier builder à la mode. Évidemment beaucoup de tâches sont réalisées avec des commandes Linux qui permettent déjà de faire beaucoup (déplacer, renommer, etc.) sans avoir besoin de créer des scripts spécifiques.
Les outils TUI
En fait, ce format me permet surtout de garder un éditeur unique, Vim, avec lequel je gère une grande partie de l'édition et du traitement. D'autres programmes TUI viennent compléter mes besoins avec une logique proche de Vim dans l'édition et les contrôles : calendrier avec Calcurse, mocp comme lecteur, lynx comme navigateur.
La courbe d'apprentissage est un peu rude pour une transition, mais en définitive la complexité est moindre sur le long terme en évitant de passer d'un outil qui propose des logiques et interfaces différentes. Le résultat est un environnement beaucoup plus unifié qui fait que chaque ajout ou apprentissage sert pour tous les usages.
Par exemple, cet article, je l'ai écrit dans Vim en pensant au format Markdown parce que je savais qu'il allait être destiné à être publié en HTML. Je l'ai démarré dans un fichier texte.
Outre les alias pour des raccourcis, tout est géré tout simplement par bash, l'utilisation d'un multiplexeur comme Tmux pour facilement rouvrir des projets avec différents panneaux sur le terminal central. L'explorateur de fichiers devient très superflu, fzf ou ranger sont devenus bien plus pratiques.
La dernière interface graphique reste le navigateur pour le développement de site web et quelques services en ligne, principalement Penpot (maquette) et Excalidraw (tableau interactif pour les ateliers). Pour les notes et le suivi des lectures, j'utilise Obsidian (basé sur des fichiers txt) et Zotero, mpv pour la lecture vidéo. Le reste est devenu superflu.
Je cherche surtout la stabilité, d'où mon usage de Debian avec un environnement de bureau orienté clavier (Regolith pour le moment, prochainement je passerai à bspwm et sxhkd pour avoir un environnement plus simple).
La suite
Ma transition la plus compliquée est le passage à Neomutt depuis Thunderbird. C'est en cours pour vraiment limiter mon usage d'interface graphique et améliorer ma gestion des courriels avec une interface plus cohérente avec mes pratiques tout en favorisant le format txt.
Je dois encore formaliser des dépôts pour partager mes scripts. Je vais d'abord changer mon environnement de bureau et je pourrai prévoir un dépôt mieux structuré.
Conclusion
Au final, cette organisation ne propose rien de farfelu, rien de vraiment innovant. La plupart du temps il s'agit d'outils anciens qui gèrent bien une tâche précise, mais il est facile de les combiner (philosophie Unix). Ce n'est vraiment pas sexy comme on aime dans la tech, mais ça fonctionne dans le temps, c'est flexible et robuste. Après tant d'années de tests, c'est enfin la première fois que j'ai une configuration qui fonctionne sans avoir de problème à la maintenir. Je peux me concentrer sur les projets. Ce type de fonctionnement ouvre vraiment des portes pour gérer des projets avec peu de moyens et imaginer des hébergements ou des moyens de transmission beaucoup plus innovants et résilients. Ça change d'un Docker sur AWS avec le dernier framework à la mode. Qu'il est bon de pouvoir compter sur ces outils.
À venir
- Mieux détailler des cas concrets comme exemple.
- Dépôt de scripts.
- Configuration de mes machines.
Ressources
- https://plaintextaccounting.org/
- https://useplaintext.email/
- note : je cherche un article sur l'organisation des dossiers avec focusbox, frigobox, l'idée n'est pas de moi, mais je n'arrive plus à trouver l'article d'origine, si vous l'avez et que vous pouvez me l'envoyer je suis preneur pour pouvoir citer la source.