Aller au contenu
Sébastien Vidotto

Le labo · Mes outils

Mes outils : garder la main

1 236 mots · environ 5 min de lecture

Chaque labo se termine par une étincelle, partagée en l’état et sans garantie : lire l’avertissement. Tous les labos.

Mes outils

Pour garder la main, il faut pouvoir comprendre ce qu’on utilise, le ranger, et revenir en arrière quand on se trompe. Neuf pourquoi, un même souci.

Pourquoi un bureau par activité ?

En usage

Mes activités s’étalaient dans des dossiers, des outils et des onglets, et je perdais du temps à chercher où était quoi, à commencer par les données de chaque projet.

Chaque activité a reçu son bureau : une page dans le navigateur qui ressemble à l’écran d’un ordinateur, avec ses dossiers, ses applications et sa messagerie, et rien qui appartienne à une autre activité, pour qu’on puisse la déplacer d’un bloc. Pour les noms, j’ai fait comme à la bibliothèque : une petite étiquette sur chaque dossier dit à quelle activité il appartient, et on devine où il va rien qu’en lisant son nom, mes agents aussi, qui comprennent tout de suite un document bien nommé. Ce système, je le fais évoluer, sous d’autres formes, depuis mes débuts.

Depuis octobre 2026, le bureau me sert. En route, avec trop d’icônes, je m’y suis perdu : je suis reparti en arrière, volontairement, pour refaire les applications une à une en gardant ce qui marchait. J’en retiens qu’un petit plan de rangement mené au bout vaut mieux qu’un grand plan toujours en chantier.

Mon étincelle : « Fais-moi un bureau, dans le navigateur, par activité, avec au plus six applications chacun, et un nom de dossier qui dit où ranger chaque chose. » Un bureau qui ouvre tous mes outils ouvre aussi tous mes accès : je le protège comme une clé.

Pourquoi garder ses outils sous sa maîtrise ?

Prototype

La plupart des outils d’IA tournent chez quelqu’un d’autre : on leur confie ses textes et ses données, et on dépend de leurs conditions. Je veux garder la main sur mon propre code, pour continuer à tout comprendre, et pouvoir un jour faire tourner mes outils chez moi.

J’écris des fiches d’outils libres, dont le code est ouvert à tous, une par outil, avec sa licence et sa source, à relire avant d’installer : par défaut, l’outil répond seulement à la machine qui l’héberge, et la façon de l’arrêter est écrite dès le départ.

Les fiches existent, et je les tiens à jour au fil des versions des outils et des erreurs qu’on me signale.

Mon étincelle : « Pour cet outil libre, écris-moi une fiche : à quoi il sert, ce qu’il lui faut, comment l’installer pour qu’il réponde seulement à ma machine, et comment l’arrêter. »

Pourquoi mon propre CMS ?

En usage

Un site ordinaire repose sur toute une mécanique, une base de données, des extensions, des mises à jour : il devient fragile, et difficile à maîtriser. Pour moi, la liberté commence par la maîtrise : en 2022 déjà, j’écrivais que mon langage de programmation était « le langage de la liberté », celle de maîtriser chacune des lignes de son projet.

Après un premier essai en 2022, j’ai construit mon propre CMS, le logiciel qui fabrique les pages d’un site et les tient à jour : une page y devient un dossier, et chaque section un fichier. Mes blogs m’ont décidé à m’en servir partout : en mars 2026, j’ai compris que, sur l’ancien logiciel, il faudrait les surveiller chacun à part. Le blog d’Heteractis y est passé le premier, au début de l’été, après un tri de ses articles, chacun gardé, réécrit ou laissé en route avec un renvoi vers la bonne page. Puis j’y ai migré mes autres sites un par un, en relisant chacun, et l’ancien gardé en service jusqu’à ce que le nouveau soit vérifié.

Le CMS est en usage, et chaque site qui le rejoint suit le même chemin. Comme tout déménagement, celui-ci a demandé quelques retouches ; je le raconte en entier dans ce que je fais. J’en retiens qu’on complexifie toujours trop, et que rester simple demande un effort constant. L’ordre, lui, ne change pas : modifier sur ma machine, tester, sauvegarder, puis mettre en ligne.

Vous vous demandez peut-être ce que devient un site fait avec mon CMS le jour où je retourne dans ma tanière : son contenu tient dans de simples fichiers, rangés page par page, sans base de données cachée, qu’on peut lire et copier sans moi.

Mon étincelle : « Construis-moi un site où chaque page est un dossier et chaque section un fichier, sans base de données, que je peux modifier sur ma machine avant de le publier. »

Pourquoi pouvoir toujours revenir en arrière ?

En usage

Avancer vite, c’est aussi se tromper plus souvent. Le réflexe est ancien, puisqu’en 2008 déjà, le logiciel de sites que je faisais évoluer chez Xiizeos sauvegardait chaque page avant de la modifier ; en 2026, je l’ai étendu à tout ce que je fais.

Depuis, j’ai une corbeille plutôt que la suppression, une copie complète avant d’écrire, avec son empreinte, une signature qui prouve que la copie est intacte, et des changements qu’on peut défaire d’un geste.

J’en retiens qu’à force de tout sauvegarder, on encombre le disque : un bon historique vaut mieux qu’une pile de sauvegardes. Ma règle tient en une phrase : je veux bien que ce soit mieux, mais pas moins bien.

Mon étincelle : « Avant toute modification, mets une copie de côté, vérifie qu’elle est intacte, et seulement alors, modifie. » Une sauvegarde devient une vraie sauvegarde le jour où on l’a restaurée : j’essaie le retour en arrière avant d’en avoir besoin.

Pourquoi indexer sans rien recopier ?

En usage

Chaque fois que je voulais voir l’ensemble de mes projets d’un coup d’œil, je refaisais une carte. Et chaque carte, écrite à la main, était périmée quelques semaines plus tard ; alors j’en refaisais une autre, ailleurs, qui vieillissait à son tour.

En février 2026, j’ai changé d’approche. Au lieu de recopier les informations dans un catalogue, mon index se contente de pointer : chaque projet garde sa propre fiche, à sa place, et l’index dit seulement où la trouver, puis la relit quand on le lui demande. J’appelle cela le « zéro-copie » : une information n’existe qu’à un seul endroit, et partout ailleurs, on pointe vers elle. L’idée a gagné mes carnets de mémoire, puis un observatoire qui relit mes propres règles pour repérer celles qui se contredisent, et, en août 2026, une carte complète de mon disque, mesurée par un programme plutôt qu’écrite à la main, et qu’on refait d’une commande.

J’en retiens qu’une carte écrite à la main meurt vite, alors qu’une carte qui se refait seule tient. Mais un index ne voit que ce qu’on lui montre : ma carte d’août a découvert que mon observatoire n’en suivait qu’une petite partie. Et pointer demande une discipline, celle de bien nommer chaque fiche et de la tenir à jour là où elle vit.

C’est en usage : mes carnets, mon observatoire et ma carte du disque fonctionnent ainsi. Le pas suivant est tracé : que la carte nourrisse l’observatoire au lieu de vivre à côté.

Mon étincelle : « Fais-moi l’index de mes dossiers : pour chacun, une ligne qui dit ce que c’est, sa date et où lire sa fiche, sans rien déplacer ni recopier, et que je puisse refaire d’une seule commande. » Mon index reste en lecture seule : il regarde, il ne range pas.