Retour d’expérience : l’assistant installé le 2 août 2026 sur mon homelab ne fait plus ce pour quoi je l’avais monté. Ce qui a produit le changement n’est pas la puissance du modèle, c’est la mémoire et les procédures écrites — et la seule règle qui rende la chose supportable : tout livrable doit être vérifiable.
Le carnet et la machine : ce qui reste quand la conversation est finie.
Ce que je lui demandais au départ
Quand j’ai installé Mercure dans un conteneur sur mon serveur, en août, j’avais trois consignes et elles étaient modestes : surveiller une boîte mail, tenir mon coffre de notes Obsidian, et pouvoir regarder ce qui se passe sur mon réseau local.
Autrement dit, un assistant de la première génération : je lui parle, il répond, il va chercher sur le web, il me dit ce qu’il sait. C’est déjà utile — c’est même ce qui m’a convaincu — mais c’est un usage où l’humain reste le déclencheur de tout. Rien ne se passe quand je ne suis pas là.
Trois mois plus tard, je viens de compter ce qui tourne réellement sur la machine. Cinquante-six tâches sont planifiées et se déclenchent sans intervention de ma part. Ce n’est plus le même objet, et je crois savoir pourquoi.
Ce qui tourne aujourd’hui
Le plus simple est de ranger le travail par familles, avec ce que chacune produit concrètement.
La veille. Chaque matin, l’agent lit environ deux cents fils d’actualité, filtre, et garde une quarantaine d’articles. Ceux-là ne restent pas dans un dossier de liens : ils deviennent des notes datées dans le coffre, rangées par thème, avec leur source et une phrase qui dit de quoi il s’agit. Le 27 octobre, par exemple, quarante et une notes sont entrées, dont sept ont été reclassées au moment de la création — un article que la source rangeait en sciences et qui parlait en réalité d’histoire des idées. Puis une synthèse quotidienne est publiée, et elle en est à sa soixante-huitième.
Les boîtes mail. Les newsletters dont je me suis désinscrit sont traitées en corbeille, sans repasser par moi. Une tâche plus large examine la boîte de réception et n’écrit que s’il y a quelque chose à dire. Un chien de garde vérifie que le serveur de mail répond toujours.
L’infrastructure. Une sauvegarde hebdomadaire pousse l’ensemble vers le NAS, avec vérification d’arrivée. Quatorze machines sont sondées toutes les cinq minutes ; l’agent ne parle que si un état change, ce qui est la seule façon de rendre une surveillance supportable. Quand le courant saute, il rédige le compte rendu — la coupure du 13 octobre a duré quinze minutes et vingt-cinq secondes, à 218 watts de charge, et cette mesure existe parce qu’un onduleur la lui a donnée.
La production. Le lundi matin, il prépare des pistes d’édito à partir de mes lectures de la semaine. Les articles du blog partent vers Mastodon toutes les deux heures, avec un filtre qui exclut les veilles quotidiennes et une liste de soixante-cinq adresses déjà publiées pour ne jamais doubler.
Aucune de ces tâches ne demande une intelligence remarquable. Toutes demandent de la régularité, ce qui est exactement ce qu’un humain ne fournit pas.
La différence n’est pas le modèle
On croit volontiers que la bascule vient de la qualité du modèle. J’ai un peu changé de modèle, et ça n’a rien bouleversé. Ce qui a changé quelque chose est plus prosaïque : l’agent a un carnet.
Un assistant sans mémoire, c’est un collègue brillant mais amnésique. On lui réexplique le dossier chaque matin : où sont les fichiers, quelle machine porte quoi, quel mot de passe vit dans quel fichier, pourquoi la sauvegarde de mardi a échoué. Il travaille bien, puis il oublie, et le coût de l’oubli, c’est moi qui le paie.
Le carnet a deux parties. La première est un ensemble de faits datés — près de douze mille à ce jour : quel disque est dans quelle machine, quelle adresse IP a changé en octobre, quel service tourne sur quel port, quelle sauvegarde est chiffrée et avec quelle clé. La seconde est un ensemble de procédures écrites, trois cent quarante, une par type de tâche. Elles ne décrivent pas le travail : elles décrivent les pièges.
C’est là que se joue la différence, et c’est très concret. Trois exemples vécus.
Un travail planifié avait été créé en désignant le fournisseur de modèle par un nom incomplet. Le système est retombé en silence sur un modèle local trop petit, et l’erreur qui remontait parlait de longueur de contexte, pas de fournisseur. Deux heures de diagnostic la première fois. La procédure dit maintenant, en une ligne, quoi regarder en premier.
Autre cas : sur une erreur d’infrastructure, l’API Mastodon crée parfois le message puis renvoie l’échec. Un script naïf compte un échec, republie au tour suivant, et l’on découvre deux fois le même message en ligne. La parade consiste à relire le fil après une erreur avant de renvoyer quoi que ce soit. Sans la note, on la refait.
Troisième : après un formatage, l’identifiant d’un disque peut apparaître vide alors que le disque est bon. Un rafraîchissement des tables de partitions et on continue. Sans ce rappel, on croit avoir cassé le disque.
Rien de tout cela n’est de l’intelligence. C’est de la mémoire d’atelier — les gabarits que l’artisan garde cloués au mur. Un modèle qui raisonne mieux ne remplace pas un gabarit : il le réinvente à chaque fois, et pas toujours bien.
Le revers : ce qui rate sans qu’on le sache
Il faut le dire, parce que c’est la partie que les démonstrations oublient. Un système qui agit seul se trompe seul, et il se trompe discrètement.
Cette semaine, un rapport hebdomadaire n’est jamais parti. Le processus a été tué au démarrage, l’erreur est enregistrée, la sortie est vide. Personne ne s’en est aperçu — pas moi, pas l’agent — avant que je regarde le tableau des tâches pour une tout autre raison. Le rapport de la semaine n’existe pas, et il n’existera pas, sauf si je le relance.
Le même jour, une autre tâche a signalé qu’un contrôle de documentation était en écart : quatre scripts d’infrastructure modifiés trois jours plus tôt ne sont cités dans aucun journal d’intervention. Là, le détecteur a fonctionné, mais il a fallu quelqu’un pour l’écrire — un contrôle qui vérifie les contrôles.
J’en ai tiré deux règles, que je crois valables pour toute automatisation de ce genre.
La première : tout travail doit laisser un objet vérifiable. Pas « c’est fait », mais une note datée dans le coffre, un fichier arrivé sur le NAS, un message réellement en ligne. Un agent qui répond « terminé » ne prouve rien ; un artefact, si.
La seconde : rien d’irréversible ne se fait sans accord. Il écrit des brouillons, il propose, il prépare ; il ne publie pas un article, il ne supprime pas une archive, il ne change pas une configuration réseau sans que je l’aie dit. Le coût de cette règle est un clic ; le coût de son absence est une journée de reconstruction.
Ce que ça change pour moi
Le temps que je passe à faire de la basse besogne a disparu : je ne classe plus d’articles, je ne trie plus de newsletters, je ne vérifie plus si la sauvegarde est passée. En revanche, j’ai gagné une charge nouvelle, et je préfère la nommer : lire les rapports. Un agent autonome ne supprime pas le travail de supervision, il le déplace — du faire vers le relire.
C’est un bon échange, à une condition : que les rapports soient courts, et qu’ils signalent les écarts plutôt que les succès. Un message qui dit « tout va bien » chaque matin ne m’apprend rien et finit par ne plus être lu, ce qui est la pire des situations : un système surveillé par un humain qui ne lit plus.
Un agent utile n’est pas celui qui répond le mieux. C’est celui dont le travail laisse une trace vérifiable, dont les erreurs se voient, et qui ne décide pas seul de ce qui ne se rattrape pas.
Chiffres relevés sur la machine le 27 octobre 2026 : 56 tâches planifiées, 340 procédures écrites, 8 167 notes dans le coffre, 68 synthèses de veille publiées, 14 hôtes surveillés. L’agent tourne dans un conteneur LXC sur un serveur Proxmox, avec un NAS TrueNAS pour les données. Sur la mémoire de l’assistant : Donner une mémoire à son assistant IA.