DEV Community: Dev du Sud

127 vues et 0 clic — le tableau de bord le plus utile que j'aie construit

Dev du Sud — Sat, 14 Nov 2026 13:40:04 +0000

J'ai écrit mon propre tracker de clics pour une raison simple : je voulais savoir si les
visiteurs d'une page cliquaient sur le lien qu'elle contenait. Pas combien de temps ils
restaient, pas d'où ils venaient, pas leur empreinte de navigateur. Une question, deux
chiffres.

Le premier rapport a répondu : 127 vues, 0 clic.

Ma première réaction a été de chercher le bug. Ma seconde, plus utile, a été de vérifier la
mesure avant d'accuser les visiteurs.

Le tracker, en quarante lignes

Un fichier PHP, une table SQLite, deux types d'événements.

<?php
// tracker.php — appelez-le en GET avec ?p=slug&e=vue ou ?p=slug&e=clic
$db = new PDO('sqlite:' . __DIR__ . '/stats.db');
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$db->exec("CREATE TABLE IF NOT EXISTS evenements (
  id       INTEGER PRIMARY KEY AUTOINCREMENT,
  ts       TEXT NOT NULL,
  page     TEXT NOT NULL,
  type     TEXT NOT NULL CHECK (type IN ('vue','clic')),
  cible    TEXT,
  ref      TEXT,
  ua_hash  TEXT
)");

$page  = substr(preg_replace('/[^a-z0-9-]/', '', $_GET['p'] ?? ''), 0, 64);
$type  = $_GET['e'] ?? '';
$cible = substr($_GET['c'] ?? '', 0, 200);

if ($page === '' || !in_array($type, ['vue', 'clic'], true)) {
    http_response_code(204);
    exit;
}

$ua = $_SERVER['HTTP_USER_AGENT'] ?? '';
// on garde une empreinte tronquée, pas l'adresse IP en clair
$empreinte = substr(hash('sha256', $ua), 0, 16);

$stmt = $db->prepare(
    "INSERT INTO evenements (ts, page, type, cible, ref, ua_hash)
     VALUES (datetime('now'), ?, ?, ?, ?, ?)"
);
$stmt->execute([
    $page, $type, $cible,
    substr($_SERVER['HTTP_REFERER'] ?? '', 0, 200),
    $empreinte,
]);

http_response_code(204);   // pas de corps : rien à afficher, rien à charger

Côté page, deux appels : un fetch au chargement, un sur le clic.

<a href="/destination" data-track="lien-principal">Voir la fiche</a>

<script>
fetch("tracker.php?p=ma-page&e=vue", {keepalive: true});

document.querySelectorAll("a[data-track]").forEach(a => {
  a.addEventListener("click", () => {
    fetch(`tracker.php?p=ma-page&e=clic&c=${a.dataset.track}`,
          {keepalive: true});
  });
});
</script>

keepalive: true est le seul détail technique qui compte : sans lui, le navigateur annule la
requête au moment où la page de destination commence à se charger, et le clic n'est jamais
enregistré. C'est le bug classique de tous les trackers maison, et il produit exactement le
symptôme que j'avais — sauf que ce n'était pas lui cette fois, ce qui m'a fait perdre une heure
de plus.

127 et 0 : vérifier avant de conclure

Trois vérifications, dans l'ordre.

1. La base reçoit-elle quelque chose ? Oui, 127 lignes de type vue. Le tracker écrivait.

2. Le type clic arrive-t-il quand on le provoque ? Test manuel :

curl -s -o /dev/null -w "%{http_code}\n" \
  "https://exemple.fr/tracker.php?p=ma-page&e=clic&c=test"
sqlite3 stats.db "SELECT type, COUNT(*) FROM evenements GROUP BY type;"

La ligne apparaît. Le code d'écriture est correct.

3. La page envoie-t-elle vraiment un clic ? C'est là qu'était la réponse : le bouton
« Voir la fiche » n'était pas un lien. C'était une image avec un onclick qui appelait
window.location, dans une balise sans href. Le script de tracking écoutait les a, et il
n'y avait aucun a à écouter.

Le tracker mesurait correctement une page qui n'avait rien à cliquer.

Pourquoi le zéro vaut mieux que la moyenne

Un outil d'analytics classique m'aurait affiché autre chose. Il aurait compté une visite, une
page vue, un taux de rebond, une durée de session, et j'en aurais déduit que la page
« intéressait ». Aucun de ces chiffres ne répond à la question que je m'étais posée.

Le zéro, lui, répond. Il dit : personne n'a cliqué. Et comme il est inconfortable, il oblige à
descendre dans le détail — jusqu'à la balise <a> manquante.

C'est la différence entre une métrique de vanité et une mesure honnête :

une métrique de vanité monte quand on travaille plus, et ne descend jamais toute seule ;
une mesure honnête peut valoir zéro, et c'est précisément pour ça qu'on la croit quand elle vaut autre chose.

Une page vue n'est pas un intérêt. Un temps de lecture estimé n'est pas une lecture. Un taux de
clic de 0 % est un fait : il y a un lien à réparer, ou une audience qui n'est pas là.

Ce que j'ai changé : la page, pas le tracker

La tentation, quand un chiffre déplaît, c'est de changer le thermomètre. Ajouter une mesure de
défilement, compter les « intentions de clic », élargir la définition d'un clic jusqu'à ce
qu'elle inclue les survols.

J'ai fait l'inverse. J'ai corrigé le HTML, remis un vrai <a href>, et laissé le tracker
identique. La question « est-ce que les gens cliquent » n'a de valeur que si la réponse peut
être non.

Et j'ai gardé le zéro dans l'historique au lieu de le masquer. Un rapport qui commence par
« 127 vues, 0 clic » raconte une histoire vraie : une page a été vue, et elle n'offrait rien à
cliquer. Effacer cette ligne aurait rendu les chiffres suivants illisibles.

Les limites d'un tracker maison

Elles existent, et il faut les connaître avant de prendre une décision sur ses propres
chiffres.

Les robots. Une partie des 127 vues n'est peut-être pas humaine. Un filtre sur le User-Agent en élimine une partie, jamais la totalité.
Les bloqueurs. Un visiteur avec un bloqueur de publicité peut bloquer tracker.php s'il est sur une liste. La mesure est donc un plancher, pas un total.
Pas de déduplication. Un rechargement compte une vue de plus. C'est acceptable pour comparer deux périodes, faux pour compter des personnes.
L'attribution est approximative. Le Referer est absent dans beaucoup de cas, et falsifiable dans tous.
Le stockage. Une empreinte de User-Agent n'identifie personne, mais ce n'est pas anonyme pour autant. Je la tronque, je ne stocke pas l'IP, et je purge la table au bout de 90 jours.

Ces limites ne rendent pas la mesure inutile. Elles rendent le chiffre interprétable : 127
vues est un ordre de grandeur, pas une audience. 0 clic est un fait, pas une estimation.

Ce qu'un tableau de bord honnête doit accepter

Un tableau de bord n'est pas un miroir de son travail. C'est un miroir de ce qu'on a décidé de
mesurer — et cette décision est plus importante que l'outil.

J'ai construit celui-ci pour répondre à une question précise, avec deux colonnes et une
requête :

SELECT page,
       SUM(type = 'vue')  AS vues,
       SUM(type = 'clic') AS clics
  FROM evenements
 WHERE ts >= datetime('now', '-30 day')
 GROUP BY page
 ORDER BY vues DESC;

Deux colonnes, une période, pas de score composite. C'est tout ce que j'ai besoin de savoir, et
c'est suffisant pour constater qu'une page est vue et que son lien ne fonctionne pas.

Le reste — le temps passé, la profondeur de défilement, le parcours de conversion — ne
répondrait pas mieux. Il donnerait juste plus de chiffres à interpréter, et une pente plus
facile à trouver flatteuse.

17 modèles LLM en local sur un iGPU et 14 Go de RAM — ce que ça vaut vraiment

Dev du Sud — Fri, 13 Nov 2026 08:46:17 +0000

Dix-sept modèles téléchargés, un processeur graphique intégré, 14 Go de mémoire partagée avec
le système. Pas de GPU dédié, pas de serveur, pas de facture à la requête.

Beaucoup la décriraient comme insuffisante, et elle l'est en effet pour certaines choses. Mais
elle tourne tous les jours, et sur une partie de mes tâches elle est plus utile qu'une API.

La question n'est pas « est-ce que ça marche », mais « à quoi ça sert, et jusqu'à quand ».

Ce que 14 Go veulent dire pour un modèle

Un modèle occupe de la mémoire pour trois raisons, et il faut les trois.

Les poids. Sept milliards de paramètres en 4 bits, environ 4,5 Go. En 8 bits, le double. En 16 bits, quatre fois plus.
Le cache de contexte. Chaque token occupe de la mémoire, pour chaque couche. Il croît avec la longueur du contexte, et c'est souvent lui qui fait déborder, pas les poids.
Le runtime. Quelques centaines de mégaoctets, plus ce que le système utilise déjà.

Sur un iGPU, il n'y a pas de VRAM séparée : le graphique intégré prend sa mémoire dans les
14 Go systèmes. Un modèle de 7B en 4 bits laisse de quoi respirer. Un 14B en 4 bits frôle la
limite et ne supporte pas un contexte long. Au-delà de 30B, ce n'est pas une question de
patience : ça ne rentre pas.

La taille du modèle est une contrainte dure, pas un réglage : aucun paramètre d'Ollama ne fera
tenir 40 Go dans 14.

Dix-sept modèles sur le disque, un seul en mémoire

Avoir dix-sept modèles ne veut pas dire en faire tourner dix-sept. Ollama charge un modèle quand
une requête arrive, le garde quelques minutes, puis le décharge quand un autre arrive.

ollama list      # ce qui est sur le disque
ollama ps        # ce qui est réellement chargé, et pour combien de temps

ollama ps est la commande que je regarde le plus : elle explique pourquoi une requête
« rapide » prend parfois quinze secondes. Le modèle était froid.

Deux conséquences. Un modèle à la fois : deux 7B chargés ensemble, et la machine échange sur le
disque, avec un ralentissement d'un facteur dix, pas deux. Et le premier token coûte cher : sur
un usage interactif, la latence de chargement se sent ; sur un lot de deux cents documents, elle
est amortie.

Là où le local gagne, sans discussion

Les données qui ne sortent pas. Un document client, un export de base, un journal
d'incident : tout ça part chez un fournisseur dès qu'on appelle une API. En local, ça reste sur
le disque. Ce n'est pas une opinion sur la confidentialité, c'est une différence de nature.

Le volume régulier. Classer deux mille lignes, extraire des champs de trois cents factures,
reformater du texte : le coût par appel, multiplié par le volume, devient un budget. En local,
le coût marginal est de l'électricité.

L'absence de limite de débit. Pas de quota, pas de 429, pas de fenêtre de tokens à
surveiller. Un script qui traite toute la nuit ne s'arrête pas au bout de cent requêtes.

La reproductibilité. Le même modèle, la même version, le même fichier de poids dans six
mois. Une API change de modèle derrière son nom sans prévenir, et une sortie qui marchait cesse
de marcher sans qu'une ligne de code ait bougé.

Là où l'API gagne, et il faut le dire

Le contexte long. Un document de cent pages, une base de code entière : sur 14 Go, le cache
de contexte devient le facteur limitant bien avant la qualité du modèle.

Le raisonnement difficile. Un petit modèle produit des réponses plausibles et fausses sur
les problèmes à plusieurs étapes. Il n'échoue pas bruyamment : il échoue avec assurance.

La vision et l'audio. Ceux qui tiennent dans 14 Go existent, mais leur qualité n'est pas
comparable : pour lire un graphique ou transcrire une réunion, l'API reste devant.

La latence sur les gros modèles. Un 70B sur une API répond en quelques secondes ; le même en
local ne rentre pas.

La maintenance. Un modèle local, c'est plusieurs gigaoctets à télécharger et une version à
figer. Une API, c'est une clé.

Router selon la tâche

Le code ne fait pas de magie : il choisit un modèle selon la tâche et appelle Ollama en HTTP
local.

import json, urllib.request

def local(prompt: str, modele: str, contexte: int = 4096) -> str:
    req = urllib.request.Request(
        "http://127.0.0.1:11434/api/generate",
        data=json.dumps({
            "model": modele,
            "prompt": prompt,
            "stream": False,
            "keep_alive": "10m",        # le modèle chaud reste 10 min en mémoire
            "options": {"num_ctx": contexte, "temperature": 0.2},
        }).encode(),
        headers={"Content-Type": "application/json"},
    )
    with urllib.request.urlopen(req, timeout=300) as r:
        return json.loads(r.read())["response"]

TACHES = {
    "classer":  ("petit-modele-3b", 2048),
    "extraire": ("petit-modele-3b", 4096),
    "resumer":  ("moyen-modele-7b", 8192),
}

Deux réglages comptent plus que le choix du modèle. num_ctx explicite : la valeur par défaut
peut être plus grande que nécessaire, et le cache de contexte est ce qui fait planter une
machine à 14 Go. keep_alive à dix minutes : sur un lot de deux cents documents, ça évite de
recharger le modèle entre chaque appel ; sur un usage sporadique, ça libère la mémoire.

Ce que la mesure tranche

Je ne publie pas de tokens par seconde, parce que le chiffre ne veut rien dire sans le modèle,
la quantification, la longueur de contexte et la machine. Je mesure trois choses.

Est-ce que ça tient dans une conversation interactive ? Une réponse après vingt secondes sur une question courte fait du local un outil batch, pas un assistant.
Est-ce que la mémoire reste sous le plafond ? Une machine qui échange sur le disque ment sur ses performances.
Est-ce que la qualité passe sur vingt cas réels ? Mes documents, mes erreurs, comparés à la main. Pas un benchmark public.

Sur ces trois critères, la répartition est simple : le local prend le volume et la
confidentialité, l'API prend le raisonnement et le multimédia. Le choix se fait par une ligne
dans un dictionnaire.

Dix-sept modèles sur un disque et 14 Go de RAM, ce n'est pas une performance : c'est un poste de
travail qui fait ce qu'il peut faire. Le local ne remplace pas une API, il la complète là où
payer n'a pas de sens et où envoyer les données n'en a pas non plus. La seule erreur serait de
trancher par principe — ça se tranche par tâche, avec une mesure.

317 tâches et 36 projets dans SQLite — le statut « abandonné » m'a plus servi que les autres

Dev du Sud — Thu, 12 Nov 2026 07:40:16 +0000

Trois cent douze tâches, trente-six projets, un fichier. Pas de serveur, pas d'abonnement, pas
d'application mobile.

Le chiffre qui m'intéresse n'est pas 317. C'est 33 : le nombre de tâches que j'ai
abandonnées — ni faites, ni supprimées, marquées comme telles. C'est le statut qui a le
plus changé ma façon de travailler, et celui qu'aucun outil de gestion de tâches ne met en
avant.

La répartition, brute

SELECT statut, COUNT(*) AS n
  FROM missions
 GROUP BY statut
 ORDER BY n DESC;

done        231
todo         38
abandonne    33
encours      10

Trois cent douze lignes dans ces quatre statuts. La table en contient 317 : les cinq autres sont
des tâches bloquées — quatre qui attendent une décision de ma part, une qui attend un client.
À l'échelle d'un projet, c'est un écart qu'on ne voit pas ; à l'échelle de trois cents lignes,
c'est le genre de trou qu'un tableau de bord propre vous cache.

Ce qui manque encore, c'est la contrainte. Le schéma réel ne l'a pas :

CREATE TABLE missions (
  id       TEXT PRIMARY KEY,
  projet   TEXT NOT NULL,
  titre    TEXT NOT NULL,
  statut   TEXT NOT NULL DEFAULT 'todo'
             CHECK (statut IN ('todo','encours','done','abandonne','bloque_ludo','bloque_externe')),
  type     TEXT NOT NULL DEFAULT 'agent' CHECK (type IN ('agent','humain')),
  preuve   TEXT,
  cree_le  TEXT NOT NULL DEFAULT (datetime('now')),
  maj_le   TEXT NOT NULL DEFAULT (datetime('now'))
);

Une contrainte CHECK ne répare pas les lignes existantes, mais elle empêche la suivante. Sur
SQLite, c'est trois lignes de SQL qui remplacent une convention documentée que personne ne lit.

Dix tâches en cours, et pas une de plus

Dix, sur 317. Ce n'est pas une politique, c'est un constat, et il est plutôt sain : au-delà
d'une douzaine de chantiers ouverts en parallèle, je passe mon temps à changer de contexte au
lieu d'avancer.

La requête qui surveille ça est banale, mais je la regarde chaque semaine :

SELECT projet, COUNT(*) AS en_cours
  FROM missions
 WHERE statut = 'encours'
 GROUP BY projet
 ORDER BY en_cours DESC;

Trente-huit tâches à faire, pour trente-six projets : la plupart des projets ont une tâche
ouverte, quelques-uns en ont trois. Cette forme de distribution est une information en soi —
elle dit que je travaille en largeur, pas en profondeur.

Pourquoi « abandonné » est un statut

Pendant des années, j'ai eu deux façons de traiter une tâche que je ne ferais pas : la
supprimer, ou la laisser en todo pour toujours.

Les deux sont mauvaises.

Supprimer efface la décision. Six mois plus tard, je retrouve la même idée, je la recrée, et je repasse une heure à me demander si je l'ai déjà tentée. La réponse était dans une ligne que j'avais effacée.
Laisser en todo pollue la liste. Une liste de tâches qui contient vingt lignes qu'on ne fera jamais cesse d'être une liste de tâches : elle devient un cimetière qu'on évite d'ouvrir.

abandonne tranche : la ligne reste, avec sa raison dans le champ note, et elle sort de
toutes les vues de travail. Trente-trois fois, j'ai écrit pourquoi. Trente-trois fois, ça m'a
évité de recommencer.

UPDATE missions
   SET statut = 'abandonne',
       note = note || ' | abandonné: ' || :raison,
       maj_le = datetime('now')
 WHERE id = :id;

Une tâche abandonnée peut revenir : elle repasse en todo, avec son historique. C'est une
décision réversible, ce qui est précisément la raison pour laquelle je la prends plus
facilement.

La colonne qui décide : `preuve`

Une ligne ne passe pas en done sans un artefact vérifiable. Trois formes acceptées, pas
quatre :

un chemin de fichier qui existe, produit après la création de la tâche ;
une URL qui répond 200 au moment de la clôture ;
un hash de commit.

Le contrôle est mécanique, et il tient en une requête.

-- tâches marquées faites dont la preuve ne pointe plus sur rien
SELECT id, projet, titre, preuve
  FROM missions
 WHERE statut = 'done'
   AND (preuve IS NULL OR preuve = '');

Sur 231 tâches terminées, cette requête doit renvoyer zéro ligne. Elle en renvoie zéro, mais
seulement parce que j'ai passé une soirée à remplir les preuves manquantes quand je l'ai
écrite pour la première fois. Avant ça, il y en avait une trentaine — dont un « site livré »
dont personne ne retrouvait l'URL.

Le contrôle côté fichier, pour les preuves de type chemin :

sqlite3 missions.db "SELECT preuve FROM missions WHERE statut='done' AND preuve LIKE '/%';" \
| while read -r p; do
    [ -f "$p" ] || echo "preuve absente: $p"
  done

Et la partie que je n'automatise pas : vérifier que le fichier a été produit après la
création de la tâche. Un rapport de septembre ne prouve pas un travail de novembre. C'est un
stat comparé à cree_le, et ça se fait à la main quand un doute existe.

Ce que SQLite encaisse, et ce qu'il n'encaisse pas

À 317 lignes et 36 projets, la question de la base ne se pose même pas : le fichier fait moins
d'un mégaoctet, les requêtes sont instantanées, et la sauvegarde est un .backup dans un
cron.

Les limites réelles sont ailleurs, et elles n'ont rien à voir avec le volume :

un seul écrivain. Si deux scripts écrivent en même temps, le second attend. Avec PRAGMA busy_timeout = 5000, il attend cinq secondes au lieu de planter. Sur un poste de travail, c'est suffisant ; sur un serveur partagé, ce ne l'est pas.
pas de vue partagée. Dès que quelqu'un d'autre doit voir l'état, il faut exporter. Donner accès au fichier, c'est donner accès à tout, y compris aux notes internes.
les suppressions de colonnes sont pénibles. Ajouter une colonne est trivial, en retirer une demande de recréer la table. Je garde donc les migrations numérotées dans un dossier, avec PRAGMA user_version comme compteur.

Ce que 317 lignes m'ont appris

Trois choses, et aucune n'est technique.

Un total ne dit rien. 317 tâches, c'est un chiffre de vanité ; 10 en cours, c'est une charge de
travail. La répartition raconte l'état réel du système, pas le total.

Un statut « abandonné » est un outil de clarté, pas un échec. Trente-trois décisions explicites
valent mieux que trente-trois lignes fantômes.

Et une tâche sans preuve est une opinion. La colonne preuve est la seule partie du schéma qui
m'a obligé à changer ma façon de travailler : quand on sait qu'on devra citer un fichier, on
produit le fichier. Pas parce qu'on est discipliné — parce que la case ne se coche pas sinon.

26 automatisations surveillées par un tableau de bord qui ne consomme aucun token

Dev du Sud — Wed, 11 Nov 2026 11:44:35 +0000

À un moment, j'ai eu vingt-six automatisations en fonctionnement : des publications, des
sauvegardes, des synchronisations, des vérifications de certificats, des collectes.

Vingt-six choses qui peuvent tomber en silence, et aucune raison de croire qu'elles vont bien.
Ma première idée a été de demander à un modèle de langage de résumer l'état de chaque job.
C'était une très mauvaise idée : vingt-six résumés toutes les deux minutes, c'est de l'argent
brûlé pour reformuler des codes de sortie.

Aujourd'hui, le tableau de bord tourne en local, ne fait aucun appel payant, et rafraîchit les
vingt-six jobs en 9 à 11 secondes. Voici comment il est fait, et surtout ce qu'il ne sait pas
faire.

Ce qu'un job laisse derrière lui

Un job ne se surveille pas en l'interrogeant : on ne demande pas à une tâche « est-ce que tu
vas bien ? ». On lit ce qu'elle a laissé.

Quatre traces suffisent, et elles existent presque toujours déjà :

l'âge d'un heartbeat — un fichier écrit à la fin d'une exécution réussie ;
le code de sortie de la dernière exécution, quand le scheduler le conserve ;
le nombre d'objets traités — trois lignes ajoutées en base, deux fichiers déplacés ;
le journal, pour la dernière ligne d'erreur.

Le tableau de bord n'invente rien. Il lit ces traces, les compare à une règle, et affiche une
couleur. Un job vert n'est pas un job qui fonctionne : c'est un job dont les traces ressemblent
à celles d'un job qui fonctionne. La nuance compte, j'y reviens plus bas.

Le registre : une ligne par job

Tout tient dans un dictionnaire. Pas de table, pas de configuration YAML à parser, pas de
fichier par job.

JOBS = {
    "publication-devto": {
        "heartbeat": "~/.local/state/devto-last-success",
        "seuil_h": 30,
    },
    "sauvegarde-quotidienne": {
        "heartbeat": "~/.local/state/backup-last-success",
        "seuil_h": 26,
    },
    "veille-certificats": {
        "tache": "veille-ssl.timer",
        "seuil_h": 25,
    },
    "compteur-missions": {
        "sqlite": ("~/pilotage/missions.db",
                   "SELECT COUNT(*) FROM missions WHERE date(maj_le) = date('now')"),
        "seuil": 1,
    },
}

Trois types de sonde, et c'est tout : un fichier horodaté, un timer systemd, une requête SQL.
Chaque job déclare son type et son seuil. Le collecteur ne connaît aucun job en particulier —
ajouter une automatisation, c'est ajouter une entrée.

Cette propriété est la plus importante du système : le tableau de bord ne grossit pas quand le
nombre de jobs grossit. Il reste le même code, avec un dictionnaire plus long.

Le cycle, en 9 à 11 secondes

Chaque sonde est une fonction courte qui renvoie un état et un message.

import os, sqlite3, subprocess, time
from pathlib import Path

def sonde_heartbeat(spec, maintenant):
    p = Path(os.path.expanduser(spec["heartbeat"]))
    if not p.exists():
        return "rouge", "aucun heartbeat"
    age_h = (maintenant - p.stat().st_mtime) / 3600
    if age_h > spec["seuil_h"]:
        return "rouge", f"muet depuis {age_h:.0f} h"
    return "vert", f"il y a {age_h:.1f} h"

def sonde_timer(spec, maintenant):
    r = subprocess.run(
        ["systemctl", "--user", "is-active", spec["tache"]],
        capture_output=True, text=True, timeout=3,
    )
    etat = r.stdout.strip()
    return ("vert" if etat == "active" else "rouge"), etat

def sonde_sqlite(spec, maintenant):
    chemin, requete = spec["sqlite"]
    with sqlite3.connect(os.path.expanduser(chemin), timeout=2) as con:
        (n,) = con.execute(requete).fetchone()
    return ("vert" if n >= spec["seuil"] else "rouge"), f"{n} lignes"

Le collecteur les enchaîne, mesure le temps, et écrit un JSON.

debut = time.monotonic()
resultats = {}
for nom, spec in JOBS.items():
    try:
        if "heartbeat" in spec:
            etat, msg = sonde_heartbeat(spec, time.time())
        elif "tache" in spec:
            etat, msg = sonde_timer(spec, time.time())
        else:
            etat, msg = sonde_sqlite(spec, time.time())
    except Exception as e:                     # une sonde cassée ne casse pas l'affichage
        etat, msg = "gris", f"sonde en erreur: {type(e).__name__}"
    resultats[nom] = {"etat": etat, "message": msg}

resultats["_cycle"] = {"secondes": round(time.monotonic() - debut, 1)}

Deux détails qui font la différence entre 10 secondes et 10 minutes :

un timeout sur chaque appel externe (3 secondes pour systemctl, 2 pour SQLite). Sans lui, un job bloqué bloque tout le cycle, et le tableau de bord affiche l'état d'il y a une heure en croyant afficher le présent ;
des sondes séquentielles, pas parallèles. Vingt-six processus simultanés coûtent plus en mémoire et en contexte que les dix secondes qu'on gagne. Sur un poste de travail, la séquentialité est le choix paresseux et correct.

Le JSON est écrit de façon atomique, sinon le navigateur lit un fichier à moitié rempli une
fois sur cent :

tmp = "/tmp/etat-jobs.json.tmp"
Path(tmp).write_text(json.dumps(resultats, ensure_ascii=False))
os.replace(tmp, "/home/moi/etat-jobs.json")

Le rendu : du HTML, du `fetch`, et rien d'autre

Pas de framework, pas d'étape de build, pas de serveur. Une page HTML de cent lignes avec une
boucle de rafraîchissement.

<table id="t">
  <thead><tr><th>Job</th><th>État</th><th>Détail</th></tr></thead>
  <tbody></tbody>
</table>

<script>
async function rafraichir() {
  const r = await fetch("etat-jobs.json?_=" + Date.now());
  const data = await r.json();
  const tbody = document.querySelector("#t tbody");
  tbody.innerHTML = "";
  for (const [nom, v] of Object.entries(data)) {
    if (nom.startsWith("_")) continue;
    const tr = document.createElement("tr");
    tr.className = v.etat;
    tr.innerHTML = `<td>${nom}</td><td>${v.etat}</td><td>${v.message}</td>`;
    tbody.appendChild(tr);
  }
  document.querySelector("#cycle").textContent =
    data._cycle.secondes + " s";
}
rafraichir();
setInterval(rafraichir, 120000);   // toutes les 2 minutes
</script>

Le collecteur tourne lui aussi toutes les deux minutes, dans un timer systemd. La page ne
calcule rien : elle affiche un fichier. C'est ce qui rend le coût nul — ni requête à une API
distante, ni modèle, ni quota.

0 token, et ce que ça implique

Le compte est simple : vingt-six jobs, un cycle toutes les deux minutes, donc 720 cycles par
jour. Aucun de ces cycles n'appelle un service payant. Le coût marginal est une lecture de
fichier et un stat.

Mais l'absence de modèle a un prix, et il faut le dire clairement :

pas de détection d'anomalie. Le tableau de bord compare à un seuil que j'ai écrit. Il ne remarque pas qu'un job tourne deux fois plus longtemps que d'habitude, ni que son volume de sortie a chuté de moitié. Pour ça, il faudrait un historique, pas un instantané ;
pas de diagnostic. Il dit « muet depuis 31 h ». Il ne dit pas pourquoi. La cause est dans le journal, et c'est moi qui vais la lire ;
pas de priorisation. Vingt-six lignes rouges se valent à l'écran. Un modèle pourrait trier ; un humain qui connaît ses jobs le fait aussi bien en trois secondes.

Un tableau de bord à 0 token n'est pas un tableau de bord intelligent. C'est un miroir. Et un
miroir honnête vaut mieux qu'un analyste qui se trompe.

La leçon que m'a donnée le premier job vert

Un job est resté vert pendant onze jours alors qu'il ne publiait plus rien. Son heartbeat était
écrit au bon endroit, à la bonne heure, par un script qui sortait en 0… après avoir trouvé
zéro fichier à traiter.

« Code de sortie 0 » et « travail effectué » ne sont pas la même chose. Depuis, la sonde de ce
job ne regarde plus son heartbeat mais le nombre de lignes ajoutées dans son journal de
publication. Un job qui tourne pour rien est rouge, même s'il est content de lui.

C'est la seule sonde que j'ai réécrite, et c'est celle qui a le plus servi. Le reste du
système n'a pas changé : un dictionnaire, trois types de sondes, un JSON, une page qui
rafraîchit toutes les deux minutes.

Mon cron de 3 h ne tournait que les nuits où j'avais laissé le PC allumé

Dev du Sud — Sun, 08 Nov 2026 07:40:11 +0000

La ligne était propre. Trois heures du matin, tous les jours, un script de maintenance qui
compacte une base, archive des journaux et pousse une sauvegarde.

0 3 * * * /home/moi/bin/maintenance.sh >> /home/moi/logs/maintenance.log 2>&1

Elle a tourné quatre fois en trois semaines.

Pas parce qu'elle était mal écrite. Parce qu'à 3 h du matin, mon poste de travail est éteint.
Et cron, dans ce cas, ne fait rien du tout : ni exécution, ni erreur, ni ligne de log, ni trace
nulle part. L'exécution n'a simplement jamais existé.

Ce que cron ne promet pas

cron est un déclencheur, pas un ordonnanceur. La différence est minuscule dans la
documentation et énorme en pratique.

Un déclencheur dit : « à cette minute précise, si la machine est allumée et que le démon tourne, lance cette commande ».
Un ordonnanceur dit : « cette tâche doit s'être exécutée une fois par jour ; si elle a été manquée, rattrape-la ».

cron appartient à la première catégorie. Il n'a aucune mémoire des exécutions passées, aucun
état « en retard », aucun mécanisme de rattrapage. C'est un choix de conception assumé depuis
les années 1970, pas un bug.

Le corollaire est ce qui m'a eu : l'absence d'exécution ne produit aucun signal. Un job qui
échoue écrit au moins une trace. Un job qui n'a pas été déclenché n'écrit rien, et rien, dans
un fichier de log, ressemble exactement à « tout va bien ».

Pourquoi je ne l'ai vu que trois semaines plus tard

Mon garde-fou habituel est un fichier d'horodatage écrit après chaque succès. Je regarde son
âge, et s'il dépasse le seuil, je crie.

Sauf que ce garde-fou tournait dans le même cron, sur la même machine, à une heure où elle est
allumée. Il mesurait donc l'âge d'un heartbeat écrit par un job qui, lui, ne tournait jamais.
Le compteur montait, mais rien ne l'interrogeait : le contrôle était dans le même fichier que
le problème, et le cron ne l'a jamais exécuté non plus.

C'est le piège classique du chien de garde hébergé sur la machine gardée. Quand le poste est
éteint, les deux dorment ensemble.

La réponse historique : anacron

anacron existe précisément pour ça. Il ne raisonne pas en minutes mais en jours : chaque
tâche déclare un intervalle (« tous les jours »), et anacron vérifie au démarrage et une fois
par heure si l'intervalle est écoulé. Si oui, il lance, quelle que soit l'heure.

# /etc/anacrontab
1  10  maintenance  /home/moi/bin/maintenance.sh

Le 1 est la périodicité en jours, le 10 le délai en minutes après le démarrage, et le
troisième champ sert au nom du fichier d'état qui empêche de relancer deux fois.

C'est solide, ça existe partout, et ça règle le cas « PC éteint ». Trois limites m'ont fait
choisir autre chose :

la granularité est la journée ; une tâche qui doit tourner toutes les six heures n'est pas son fort ;
anacron n'est pas toujours un service supervisé par systemd, et son journal ne se lit pas avec journalctl comme le reste du système ;
sur plusieurs distributions, il n'est même pas installé par défaut. Sur un poste de bureau avec une session utilisateur systemd, le timer est déjà là.

Ce que j'utilise maintenant : un timer systemd persistant

Un .service et un .timer, tous les deux dans ~/.config/systemd/user/.

# maintenance.service
[Unit]
Description=Maintenance nocturne

[Service]
Type=oneshot
ExecStart=/home/moi/bin/maintenance.sh
Nice=10
IOSchedulingClass=idle

# maintenance.timer
[Unit]
Description=Maintenance quotidienne à 3 h, rattrapage inclus

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
RandomizedDelaySec=600

[Install]
WantedBy=timers.target

La ligne qui compte tient en un mot : Persistent=true.

Avec elle, systemd enregistre la dernière exécution dans
~/.local/share/systemd/timers/. Au démarrage, il compare l'horodatage à la planification : si
une échéance a été manquée, il lance le service immédiatement, une fois. Pas cinq fois pour
cinq jours manqués — une fois. C'est le comportement qu'on veut : un état à rattraper, pas une
file de travail à vider.

RandomizedDelaySec=600 étale le déclenchement sur dix minutes. Sur un parc de machines, ça
évite que tout le monde frappe la même API à 3 h 00 pile. Sur un seul poste, ça évite aussi de
tomber pile sur une fenêtre de mise à jour.

systemctl --user daemon-reload
systemctl --user enable --now maintenance.timer

Vérifier que ça a réellement rattrapé

Activer un timer ne prouve rien. Trois commandes, et deux d'entre elles doivent être lues
régulièrement.

systemctl --user list-timers maintenance.timer
systemctl --user status maintenance.service
journalctl --user -u maintenance.service -n 20 --no-pager

list-timers affiche la prochaine échéance et la dernière exécution. C'est la colonne
« LAST » qui m'intéresse : si elle date de trois jours, le rattrapage n'a pas eu lieu.

Pour tester le rattrapage sans attendre 3 h du matin : un timer de test avec un OnCalendar
dans deux minutes, on éteint la machine avant l'échéance, on la rallume après, et on regarde si
le service a tourné. C'est fastidieux une fois, et ça évite de découvrir le problème en
production.

Ce que le rattrapage ne répare pas

Il faut être honnête sur les limites, parce que « persistant » fait croire à une garantie plus
large qu'elle ne l'est.

Un seul rattrapage, pas un historique. Cinq jours d'absence produisent une exécution, pas cinq. Si le script traite « les données du jour », celles des jours manqués ne seront jamais traitées : il lui faut une plage de dates, pas « hier ».
Le timer ne vérifie pas le résultat. Un service qui sort en 0 sans rien faire reste un succès. Le timer garantit le déclenchement, pas le travail.

Et aucun outil local ne peut rattraper quoi que ce soit si la machine ne redémarre jamais : la
surveillance des tâches critiques doit vivre ailleurs, dans un service qui attend un ping et qui
crie quand il manque.

La différence tient en une phrase. cron répond à « est-ce qu'il est 3 h ? ». Un timer persistant
répond à « est-ce que le travail d'aujourd'hui a été fait ? ». La première question est facile à
poser et n'apporte aucune garantie ; la seconde est la seule qui m'intéresse.

Ma maintenance tourne maintenant tous les jours, y compris les nuits où le PC dort. Et comme
elle est enfin visible dans journalctl, elle a arrêté d'être un rituel silencieux pour
devenir une tâche comme les autres.

Gmail refuse une sauvegarde de 329 Mo — et relever la limite n'est pas la réparation

Dev du Sud — Thu, 05 Nov 2026 10:18:49 +0000

La sauvegarde faisait 329 Mo. Le message d'erreur faisait une ligne :

552 5.3.4 Message size exceeds fixed maximum message size

Rien sur la taille autorisée, rien sur la taille réellement envoyée, rien sur ce qu'il faut
faire. J'ai passé une heure à vérifier mon mot de passe, mon serveur SMTP et mon port avant de
comprendre que le problème était arithmétique.

Les 25 Mo ne sont pas 25 Mo

Gmail refuse un message au-delà de 25 Mo. Ce chiffre est celui du message encodé, pas celui
du fichier sur le disque. Et c'est là que tout se joue.

Un fichier joint est transporté en base64. Cet encodage transforme 3 octets en 4 caractères :
le volume augmente d'environ un tiers. Ajoutez les en-têtes MIME, les séparateurs de parties,
l'encodage du nom de fichier, et un fichier de 20 Mo produit un message de 27 à 28 Mo.

Autrement dit, la vraie limite utile est autour de 18 Mo de fichier, pas 25.

def taille_message(taille_fichier: int) -> int:
    """Estimation du message encodé : base64 (4/3) + en-têtes MIME."""
    return int(taille_fichier * 4 / 3) + 4096

Une sauvegarde de 329 Mo, c'est donc l'équivalent de 440 Mo de message. Dix-sept fois la
limite. Il n'y avait pas de réglage à trouver : il y avait un découpage à écrire.

Découper, mais pas n'importe comment

Premier réflexe : split -b 10M. C'est ce que j'ai fait la première fois, et c'est une
mauvaise idée pour trois raisons.

split produit des fichiers sans aucune information sur leur ordre, leur nombre, ni leur
contenu. Si un bloc arrive corrompu — et sur trente-trois pièces jointes, ça finit par arriver —
vous ne le savez qu'au moment de reconstituer, sans savoir lequel. Et si un envoi échoue, vous
ne savez pas ce qui manque.

Le découpage doit produire, en plus des blocs, un manifeste. Trente lignes de Python :

import hashlib, json, pathlib

SRC = pathlib.Path("/home/moi/backups/sauvegarde-2026-10.enc")
OUT = pathlib.Path("/home/moi/backups/blocs")
BLOC = 10 * 1024 * 1024

OUT.mkdir(parents=True, exist_ok=True)
manifeste = {"source": SRC.name, "taille": SRC.stat().st_size, "blocs": []}

with SRC.open("rb") as f:
    i = 0
    while True:
        data = f.read(BLOC)
        if not data:
            break
        nom = f"{SRC.stem}.part{i:03d}"
        (OUT / nom).write_bytes(data)
        manifeste["blocs"].append({
            "fichier": nom,
            "octets": len(data),
            "sha256": hashlib.sha256(data).hexdigest(),
        })
        i += 1

(OUT / "manifeste.json").write_text(json.dumps(manifeste, indent=2))
print(f"{len(manifeste['blocs'])} blocs, {manifeste['taille']} octets")

Résultat : 33 blocs, dont 32 de 10 Mo et un dernier plus petit, plus un manifeste.json de
quelques kilo-octets. Chaque bloc encodé fait environ 13,3 Mo de message — largement sous les
25 Mo, avec de la marge pour les en-têtes et pour un client mail qui décide d'ajouter sa
signature.

Le sha256 par bloc n'est pas du zèle. C'est ce qui permet de répondre à la seule question qui
compte quand on restaure : « ce bloc est-il celui que j'ai envoyé ? »

Le manifeste part en premier

L'ordre d'envoi a son importance. Le manifeste est le plus petit fichier et le plus important :
il décrit tout le reste. Je l'envoie en premier, avec un objet explicite.

[backup 2026-10] 00/33 manifeste — 329 Mo, 33 blocs
[backup 2026-10] 01/33 part000
...
[backup 2026-10] 33/33 part032

Trois choses dans cette convention :

le numéro dans l'objet permet de retrouver un message égaré par une simple recherche ;
le total (/33) permet de savoir s'il manque quelque chose sans ouvrir le manifeste ;
le nom du fichier reste dans l'objet, donc un bloc renommé par un client mail reste identifiable.

Un détail qui n'en est pas un : je n'envoie jamais deux blocs dans le même message. Deux
pièces jointes de 10 Mo, c'est 26,6 Mo encodés, donc un refus. La limite se calcule par
message, pas par envoi.

Reconstituer et vérifier

La restauration ne doit pas dépendre de ma mémoire. Elle lit le manifeste et refuse de
continuer si un bloc manque.

import hashlib, json, pathlib

D = pathlib.Path("/home/moi/backups/blocs")
m = json.loads((D / "manifeste.json").read_text())

sortie = pathlib.Path("/home/moi/restaure.enc")
with sortie.open("wb") as out:
    for b in m["blocs"]:
        p = D / b["fichier"]
        if not p.exists():
            raise SystemExit(f"bloc manquant: {b['fichier']}")
        data = p.read_bytes()
        if hashlib.sha256(data).hexdigest() != b["sha256"]:
            raise SystemExit(f"bloc corrompu: {b['fichier']}")
        out.write(data)

print("taille:", sortie.stat().st_size, "attendu:", m["taille"])

Le contrôle final est une comparaison de taille, puis un déchiffrement qui échouera de
lui-même si un octet manque — un fichier chiffré est son propre checksum. Sur trente-trois
blocs envoyés en trois soirs, c'est ce contrôle qui m'a évité de découvrir le problème six mois
plus tard, au pire moment.

Pourquoi relever la limite est toujours la mauvaise réparation

J'ai cherché la solution évidente : un autre fournisseur, un compte payant, un envoi par lien
de partage. Chacune de ces réponses repousse le problème sans le traiter, et en crée un autre.

La limite n'est pas une brimade. Un serveur mail doit stocker, scanner et parfois répliquer chaque message. Un plafond par message est ce qui empêche un envoi unique de saturer une boîte partagée.
Le destinataire a sa propre limite. Relever la mienne ne change rien à la sienne. Un message de 300 Mo sera refusé à l'arrivée, ou silencieusement tronqué par un relais intermédiaire — et c'est bien pire qu'un refus.
Un gros message n'est pas reprenable. Un envoi de 329 Mo qui casse à 90 % doit recommencer à zéro. Trente-trois blocs de 10 Mo : on renvoie le bloc qui a échoué, en deux minutes.
La boîte du destinataire a un quota. Une sauvegarde de 329 Mo dans une boîte de 15 Go, c'est deux pour cent de l'espace, tous les mois, sans jamais rien supprimer. Au bout de deux ans, la boîte est pleine et personne ne sait pourquoi.

Le découpage, lui, est une contrainte qui s'applique partout : n'importe quel hébergeur, un
disque amovible, un dépôt d'objets, une clé USB. C'est la seule version du système qui
fonctionnera encore quand le fournisseur aura changé ses règles.

Ce que je garde

Une fonction de découpage de trente lignes, un manifeste avec un hash par bloc, une convention
de nommage dans l'objet du message, et un script de restauration qui refuse de mentir.

La taille de 10 Mo n'est pas magique : elle laisse de la marge sous les 25 Mo encodés, elle
tient dans une pièce jointe raisonnable, et elle permet de renvoyer un bloc sans y passer la
soirée. Le chiffre à retenir est ailleurs : base64 coûte un tiers. Tant qu'on l'oublie, on
cherche un réglage là où il n'y a qu'une division.

Un dossier, c'est une file d'attente : 21 articles publiés sans base de données

Dev du Sud — Wed, 04 Nov 2026 07:41:04 +0000

Je n'ai pas de back-office. J'ai un dossier.

Quand j'ai un article à écrire, j'ouvre un fichier, je le nomme 12-mon-sujet.md, je le pose
dans devto-articles/. Le lendemain matin, un job prend le premier fichier par ordre
alphabétique, le publie sur Dev.to, puis le déplace dans publies/. Vingt et un articles sont
passés par là. Aucun n'a été publié deux fois, aucun n'a été perdu, et je n'ai jamais eu à
ouvrir un tableau de bord pour savoir où j'en étais.

C'est l'architecture la plus banale qui existe — et celle que je conseille avant d'installer
n'importe quel outil de gestion de contenu.

Le nom du fichier est l'ordre de publication

Le job ne trie pas par date de modification, il ne lit pas un champ publish_at, il prend
sorted(os.listdir(...))[0]. Un seul critère, et il tient parce que le nom porte un numéro à
deux chiffres.

11-dossier-file-attente-devto.md
12-gmail-25-mo-sauvegarde.md
13-cron-3h-pc-eteint.md

Le zéro de tête n'est pas décoratif. Sans lui, 10-... passe avant 9-..., et l'ordre de
publication devient le genre de bug qu'on ne voit qu'au bout d'un mois. Trois caractères, et le
problème n'existe pas.

Deuxième conséquence, plus intéressante : le nom est une promesse de calendrier. Un article
par jour, donc un numéro par jour. Si je pars trois jours, je pose trois fichiers et je sais
exactement ce qui sortira lundi, mardi, mercredi. Rien à planifier ailleurs.

Le filtre compte autant que le tri. Le dossier contient aussi des notes et des brouillons : la
sélection ne retient que les fichiers dont le nom commence par un chiffre.

CANDIDATS = sorted(
    p for p in RACINE.glob("*.md")
    if p.name[0].isdigit()           # ignore notes, brouillons, sauvegardes
)
fname = CANDIDATS[0] if CANDIDATS else None

Un fichier = un article, et un seul

Un dossier, c'est une file d'attente ouverte : n'importe quoi peut y tomber. Chez moi, un
fichier de brouillons pour les réseaux sociaux s'y est retrouvé, et il a été publié avant que
je comprenne pourquoi. C'était un fichier markdown valide, avec un contenu, sans champ title.
L'API a créé l'article. Son titre était devenu « Sans titre ».

Depuis, la validation se fait avant le premier appel réseau, sur trois champs :

def valide(fm: dict) -> str | None:
    if not fm.get("title", "").strip():
        return "titre manquant"
    if not fm.get("description", "").strip():
        return "description manquante"
    if fm.get("published") != "false":
        return "published doit valoir false à la pose"
    return None

Un fichier refusé reste dans le dossier, avec son nom intact. Il ne bloque pas la file : le job
le saute et prend le suivant. Un fichier invalide qui bloque toute la production, c'est une
panne ; un fichier invalide qui est sauté, c'est un avertissement.

Le published: false dans le front matter n'est pas une politesse. C'est la marque « cet
article attend son tour ». Le jour où je veux publier tout de suite, je passe par un PUT
manuel et je déplace le fichier à la main — mais le job, lui, ne publie jamais un fichier qui
s'est déjà déclaré publié ailleurs.

Le déplacement est la transaction

C'est le point sur lequel j'ai le plus réfléchi, parce que c'est le seul endroit où le système
peut perdre quelque chose.

L'ordre est strict, et il n'est pas négociable :

l'API répond 2xx avec un id d'article ;
le fichier est déplacé dans publies/ ;
une ligne est ajoutée au journal.

draft = poster(article)                 # lève une exception si l'API refuse
shutil.move(src, DEST / src.name)       # rename atomique, même disque

with JOURNAL.open("a", encoding="utf-8") as f:
    f.write(f"{date}\t{src.name}\t{draft['id']}\t{draft['url']}\n")

Si l'étape 1 échoue, rien n'a bougé. Si l'étape 2 échoue alors que l'article est en ligne, le
fichier repart le lendemain — et l'API répond 422 sur un titre déjà utilisé. C'est bruyant,
c'est réparable, et ça se voit. L'inverse — déplacer avant de publier — produit un article
perdu en silence. Entre les deux erreurs, j'ai choisi celle qui gueule.

Le shutil.move est sur le même disque, donc c'est un rename : atomique. Pas de fichier à
moitié copié, pas de doublon.

Ce qui se passe quand le dossier est vide

C'est le cas qui m'a coûté le plus cher, et il ne ressemble pas à une panne.

Zéro fichier candidat, zéro erreur. Le script sort en 0, le scheduler est content, et le
lendemain matin rien n'est en ligne. Aucun message, aucun log d'erreur, parce qu'il n'y a pas
d'erreur : il n'y a rien à faire.

Un job de publication qui n'a plus rien à publier est une alerte, pas un succès. Le script sort
maintenant en code 3, avec un message explicite :

if not todo:
    print("ALERTE: aucun fichier en attente")
    sys.exit(3)

Et je garde une marge de sept fichiers d'avance. Vingt et un articles plus tard, la file n'est
jamais descendue en dessous de trois. Quand elle approche de zéro, c'est que j'ai arrêté
d'écrire — c'est l'information la plus utile que ce système me donne.

Le journal, trois colonnes

Chaque publication laisse une ligne, et cette ligne suffit :

2026-10-14  11-dossier-file-attente-devto.md  1874521  https://dev.to/...

Je ne construis pas de statistiques dessus : tail -5 pour savoir ce qui est sorti cette
semaine, grep pour retrouver un article. Vingt et un articles, six cents octets de journal.

Pourquoi je n'ai pas ajouté de base de données

Parce que je n'en ai pas besoin, et parce que le système de fichiers fait déjà le travail :
lister, compter, trier, déplacer, horodater. Une table articles avec une colonne statut
aurait ajouté une deuxième source de vérité à synchroniser avec les fichiers. Deux sources de
vérité, c'est une divergence garantie et un script de réconciliation à écrire.

Ici, l'état est le dossier. Un article en attente est un fichier à la racine. Un article publié
est un fichier dans publies/. Rien à interroger, rien à réparer, et une sauvegarde qui tient
dans un tar.

La seule chose que j'ai ajoutée, c'est un verrou : flock autour du job, pour qu'un
déclenchement manuel et le cron ne prennent pas le même fichier à la même seconde.

Deux cent cinquante lignes de Python, un dossier, un fichier de journal. Vingt et un articles
sortis sans intervention, et un système que je peux encore lire dans trois ans sans relire de
documentation.

La leçon n'est pas « faites tout en bash ». C'est que la bonne file d'attente est souvent celle
qu'on a déjà sous la main, à condition d'accepter deux contraintes : un ordre explicite dans le
nom, et un déplacement qui sert de transaction. Le reste, c'est de la décoration.

Mes 200 tâches tiennent dans un fichier SQLite de 192 Ko

Dev du Sud — Tue, 03 Nov 2026 18:06:48 +0000

J'ai une centaine de tâches vivantes : un site à réparer, un client à relancer, un article à
finir, une facture à vérifier. Pendant des années j'ai utilisé un outil en ligne, avec des
colonnes, des étiquettes, des glisser-déposer et une application mobile.

Le problème n'était pas l'outil. Le problème, c'est que je passais plus de temps à organiser
mes tâches qu'à les faire, et qu'aucune de ces tâches ne laissait de trace vérifiable une fois
« archivée ».

Aujourd'hui, tout tient dans un fichier de 192 Ko et une commande en ligne.

Ce que j'ai réellement besoin de stocker

Quatre choses, pas plus :

quoi (un titre),
pour quel projet,
pour quand (une échéance, souvent absente),
et où j'en suis (un statut).

Plus deux champs qui ne viennent pas des outils classiques : le type (est-ce moi qui dois
le faire, ou un agent/une machine ?) et la preuve.

CREATE TABLE missions (
  id          TEXT PRIMARY KEY,
  projet      TEXT,
  titre       TEXT NOT NULL,
  statut      TEXT NOT NULL DEFAULT 'todo',
  type        TEXT NOT NULL DEFAULT 'agent',
  due_date    TEXT,
  owner       TEXT,
  preuve      TEXT,
  note        TEXT,
  cree_le     TEXT,
  maj_le      TEXT
);

CREATE INDEX idx_due ON missions(due_date, statut);

statut vaut todo, doing, done ou blocked. Pas de table de statuts, pas de
métadonnées imbriquées : quatre chaînes et une contrainte applicative.

Total : 190 lignes et 192 Ko pour une centaine de tâches et leur historique. La base entière
tient dans une pièce jointe.

La colonne qui a tout changé : `preuve`

J'ai eu un problème répété : des tâches marquées « faites » qui ne l'étaient pas. Un serveur
« installé » qui n'existait pas. Un site « livré » dont personne ne retrouvait l'URL. Dans les
deux cas, la case était cochée par quelqu'un de bonne foi, pressé, qui avait fait presque
le travail.

J'ai ajouté une règle, puis une colonne pour la rendre mécanique : une tâche n'est terminée
que si elle peut citer un artefact vérifiable.

-- la contrainte, côté applicatif : pas de preuve, pas de clôture
UPDATE missions
   SET statut = 'done',
       preuve = :chemin,          -- /home/moi/livrables/rapport.pdf
       maj_le = datetime('now')
 WHERE id = :id AND :preuve IS NOT NULL AND :preuve <> '';

Trois formes de preuve acceptées, et trois seulement :

un chemin de fichier qui existe et qui a été produit après la création de la tâche ;
une URL qui répond HTTP 200 testée au moment de la clôture ;
un hash de commit.

python3 pilotage.py done m-42 --preuve "/home/moi/livrables/rapport.pdf"

Et le contrôle qui va avec, parce qu'une règle qu'on ne vérifie pas n'est pas une règle :

test -f "$(sqlite3 missions.db "SELECT preuve FROM missions WHERE id='m-42';")" \
  && echo "preuve OK"

Depuis, la question « où en est ce chantier ? » a une réponse en une requête, et non plus en
une conversation.

Les quatre requêtes qui servent tous les jours

Ce qui est en retard — la seule requête que je regarde le matin :

SELECT id, titre, due_date, projet
  FROM missions
 WHERE statut <> 'done'
   AND due_date IS NOT NULL
   AND date(due_date) <= date('now', '+14 day')
 ORDER BY date(due_date) ASC;

Ce que je dois faire moi (par opposition à ce que les scripts font) :

SELECT id, titre, projet FROM missions WHERE type = 'ludo' AND statut = 'todo';

Cette séparation est plus utile qu'elle n'en a l'air : elle évite de demander à une machine
un geste qu'elle n'a pas le droit de faire (payer, signer, téléphoner), et elle évite de
s'étonner qu'un chantier n'avance pas alors qu'il attend un humain.

La charge par projet :

SELECT projet,
       SUM(statut = 'todo')    AS a_faire,
       SUM(statut = 'doing')   AS en_cours,
       SUM(statut = 'blocked') AS bloque
  FROM missions
 GROUP BY projet
 ORDER BY a_faire DESC;

Ce qui est bloqué depuis trop longtemps :

SELECT id, titre, ROUND(julianday('now') - julianday(maj_le)) AS jours
  FROM missions
 WHERE statut = 'blocked'
   AND julianday('now') - julianday(maj_le) > 14
 ORDER BY jours DESC;

La commande, en 120 lignes d'argparse

SQLite sans interface, c'est vite pénible. Un petit CLI suffit :

import argparse, sqlite3, subprocess, datetime

def db():
    con = sqlite3.connect("missions.db")
    con.row_factory = sqlite3.Row
    return con

p = argparse.ArgumentParser()
sub = p.add_subparsers(dest="cmd", required=True)

d = sub.add_parser("due");    d.add_argument("--jours", type=int, default=14)
l = sub.add_parser("list");   l.add_argument("--statut", default="todo")
c = sub.add_parser("done");   c.add_argument("id"); c.add_argument("--preuve", required=True)

a = p.parse_args()

if a.cmd == "due":
    for r in db().execute(
        "SELECT id, titre, due_date FROM missions WHERE statut<>'done' "
        "AND due_date IS NOT NULL AND date(due_date)<=date('now',?) ORDER BY due_date",
        (f"+{a.jours} day",)):
        print(f"{r['due_date']}  {r['id']:<12} {r['titre'][:60]}")

En pratique je n'utilise que trois commandes : due, list, done. Tout le reste, c'est du
SQL tapé une fois par mois.

Sauvegarde : `cp` ne suffit pas

Le premier réflexe — cp missions.db backup/ — est faux si un job écrit pendant la copie :
on récupère un fichier dont la moitié des pages est incohérente. Trois réglages et une
commande règlent le problème.

PRAGMA journal_mode = WAL;      -- lectures concurrentes sans blocage
PRAGMA busy_timeout = 5000;     -- attendre 5 s plutôt que planter
PRAGMA synchronous = NORMAL;    -- bon compromis sur un poste de travail

sqlite3 missions.db ".backup '/home/moi/backups/missions-$(date +%F).db'"

.backup utilise l'API de sauvegarde en ligne : cohérent, même si une écriture est en cours.
Une ligne dans le cron, et le sujet est clos.

Ce que SQLite ne fait pas

Je préfère le dire clairement, parce que la mode du « tout dans un fichier » produit aussi des
désillusions :

Pas de multi-utilisateur concurrent. Un écrivain à la fois. Pour une équipe de trois qui écrit toute la journée, ça devient un sujet. Pour un poste de travail et quelques scripts, c'est un non-problème.
Pas de synchronisation mobile. Un fichier sur un disque local ne suit pas en déplacement. Si vous avez besoin de cocher des tâches dans le train, SQLite n'est pas la réponse.
Pas de vue partagée. Dès qu'un tiers doit voir l'état, il faut exporter (un fichier markdown, un JSON, un petit serveur) — pas donner accès au fichier.
Pas de sauvegarde automatique. Le fichier est unique : sa perte est totale. Une sauvegarde quotidienne n'est pas optionnelle.

Et une limite plus discrète : les schémas évoluent. Ajouter une colonne est trivial
(ALTER TABLE ... ADD COLUMN), la renommer ou la supprimer ne l'est pas. Je garde donc les
migrations dans un dossier migrations/ numéroté, avec la version courante dans
PRAGMA user_version. Dix lignes de code, et plus de mauvaise surprise.

Pourquoi je ne reviens pas en arrière

Parce que ma base de tâches est maintenant une donnée, pas une interface. Je peux la lire
avec sqlite3, l'exporter en CSV, la versionner, l'interroger depuis un script Python, la
sauvegarder par un simple .backup. Aucune de ces quatre choses n'était possible avec mon
outil en ligne, qui me laissait au mieux un export JSON à la mise en forme douteuse.

Et puis il y a le silence. Pas de notification, pas de rappel, pas d'e-mail « vous n'avez pas
ouvert votre tableau de bord cette semaine ». Une commande, une réponse, rien d'autre.

Deux cents tâches, cent quatre-vingt-douze kilo-octets, zéro euro par mois. Ce n'est pas une
prouesse technique. C'est juste un outil qui fait le travail et se tait.

Publier sur Dev.to depuis un serveur, avec 130 lignes de Python et zéro dépendance

Dev du Sud — Mon, 02 Nov 2026 07:40:55 +0000

Écrire dans un éditeur web, coller son markdown, choisir ses tags, cliquer sur publier :
quand on écrit une fois par mois, c'est très bien. Quand on écrit deux fois par semaine, ça
devient une corvée — et les corvées finissent par ne plus être faites.

Mon besoin était simple : j'écris un fichier .md dans un dossier, un job planifié le publie
le lendemain matin à 8 h 40. Pas d'interface, pas de SDK, pas de dépendance à installer sur un
serveur qui doit rester debout pendant des années.

Voici le pipeline complet, avec les erreurs que j'ai réellement rencontrées.

Ce dont l'API a besoin

Trois choses, et la troisième est celle qu'on oublie.

La clé API, dans l'en-tête api-key. Elle se génère dans les paramètres du compte Dev.to.
L'URL : https://dev.to/api/articles pour créer, https://dev.to/api/articles/<id> pour modifier.
Un en-tête User-Agent. Sans lui, vous prenez un 403 et vous cherchez pendant vingt minutes pourquoi votre clé « ne marche pas ».

La clé doit vivre dans un fichier d'environnement, jamais dans le script :

DEVTO_API_KEY=xxxxxxxxxxxxxxxxxxxxxxxx

def load_env(path):
    """Lit un .env minimaliste : KEY=VALUE, commentaires en #."""
    env = {}
    with open(path) as f:
        for line in f:
            line = line.strip()
            if not line or line.startswith("#") or "=" not in line:
                continue
            k, v = line.split("=", 1)
            env[k.strip()] = v.strip().strip('"').strip("'")
    return env

Étape 1 — lire le front-matter sans PyYAML

Un article, c'est un fichier markdown avec un en-tête entre deux ---. Pas besoin d'un
analyseur YAML complet : trois champs suffisent.

lines = open(fname).read().split("\n")
fm = {}
i = 1
while i < len(lines) and lines[i].strip() != "---":
    if ":" in lines[i]:
        k, v = lines[i].split(":", 1)
        fm[k.strip()] = v.strip()
    i += 1
body = "\n".join(lines[i + 1:]).strip()

Le fichier ressemble à ça :

---
title: Un titre qui donne envie de cliquer
description: "La phrase que Dev.to affichera dans les résultats."
tags: python,automation,tutorial
cover_image: https://exemple.fr/couverture.jpg
canonical_url: https://mon-site.fr/mon-article
---

Le corps, en markdown normal.

Étape 2 — le piège du titre vide

C'est l'erreur que j'ai réellement commise, et elle est publique : un fichier sans champ
title a été publié sous le titre « Sans titre ». Un fichier de brouillons de posts pour les
réseaux sociaux s'était retrouvé dans le dossier de la file, et le script l'a pris pour un
article.

Depuis, la validation se fait avant tout appel réseau :

if "title" not in fm or not fm["title"].strip().strip('"'):
    print(f"SAUTÉ (pas de titre): {fname}")
    return           # on ne publie pas, on passe au suivant

Deux lignes. Elles valent leur pesant de réputation.

Étape 3 — les tags valides, sinon 422

Dev.to n'accepte que des tags de sa liste. Un tag inconnu renvoie
422 — tag not found, et l'article n'est pas créé. Le plus simple est de filtrer contre une
liste blanche :

VALID_TAGS = {
    "python", "javascript", "productivity", "automation", "programming",
    "tutorial", "beginners", "webdev", "linux", "tools", "ai", "career",
    "opensource", "devops", "performance", "testing", "security", "data",
    "startup", "discuss", "showdev", "watercooler", "architecture",
    "codequality", "comparison",
}

tags = [t for t in tags if t in VALID_TAGS][:4]
if not tags:
    tags = ["discuss"]

Quatre tags maximum, c'est la limite de l'API. Les filtrer en silence vaut mieux qu'un échec
de publication pour une virgule de trop.

Étape 4 — créer en brouillon, puis publier

Publier directement, c'est un seul appel : POST avec "published": true. Ça marche… quand
l'API va bien. Aux heures de pointe, j'ai vu passer des 503 sur cet appel, et un 503 sur un
POST non idempotent laisse un doute désagréable : l'article a-t-il été créé, ou pas ?

Le pattern qui tient : créer le brouillon, récupérer son id, puis publier.

def api(method, url, payload=None, key=""):
    data = json.dumps(payload).encode() if payload is not None else None
    req = urllib.request.Request(url, data=data, method=method, headers={
        "Content-Type": "application/json",
        "api-key": key,
        "User-Agent": "Mozilla/5.0 (X11; Linux x86_64) MonBot/1.0",
    })
    with urllib.request.urlopen(req, timeout=40) as resp:
        return json.loads(resp.read())

# 1) brouillon
draft = api("POST", API, {"article": {
    "title": title, "body_markdown": body, "published": False, "tags": tags,
}}, key)
art_id = draft["id"]

# 2) publication, avec deux reprises sur 5xx
for attempt in range(3):
    try:
        api("PUT", f"{API}/{art_id}", {"article": {"published": True}}, key)
        break
    except urllib.error.HTTPError as e:
        if e.code in (502, 503, 504) and attempt < 2:
            time.sleep(8 * (attempt + 1))
            continue
        raise

Un PUT est idempotent : le rejouer ne crée rien en double. C'est toute la raison de cette
danse en deux temps.

Étape 5 — un fichier d'état, sinon vous publiez deux fois

Le job tourne une fois par jour, mais il peut tourner deux fois : un redémarrage, un
déclenchement manuel, une reprise après panne. Un petit JSON suffit à rendre le script
idempotent.

STATE = os.path.expanduser("~/.hermes/scripts/devto-publish-state.json")
state = json.load(open(STATE)) if os.path.exists(STATE) else {}

today = time.strftime("%Y-%m-%d")
if state.get("last") == today:
    print(f"déjà publié aujourd'hui ({today})")
    return

done = set(state.get("done", []))
todo = [f for f in files if f not in done]
fname = todo[0]                      # un article par jour, dans l'ordre alphabétique
# … publication …
done.add(fname)
state.update({"done": sorted(done), "last": today})
tmp = STATE + ".tmp"
json.dump(state, open(tmp, "w"))
os.replace(tmp, STATE)               # écriture atomique

os.replace plutôt qu'une écriture directe : si la machine s'éteint au mauvais moment, on
garde l'ancien état au lieu d'un fichier tronqué.

Le cron, et la seule ligne qui compte

40 8 * * * flock -n /tmp/devto.lock /usr/bin/python3 \
  /home/moi/.hermes/scripts/publish-devto.py >> /home/moi/logs/devto.log 2>&1

Une fois par jour, à heure fixe, avec un verrou. Et lisez ce log de temps en temps : c'est
tout l'objet de mon article précédent sur les crons qui meurent en silence.

Les quatre erreurs que j'ai vues en vrai

Code	Message	Cause réelle	Réaction
`403`	—	En-tête `User-Agent` absent	L'ajouter, toujours
`401`	`unauthorized`	Clé absente, expirée ou révoquée	Régénérer la clé
`422`	`tag not found`	Tag hors liste blanche	Filtrer les tags
`422`	`Title has already been used in the last five minutes`	Doublon de titre	Attendre, ou varier le titre
`503`	—	API surchargée	Réessayer avec un backoff

Le 422 sur le titre m'a coûté une soirée : mes deux tentatives de reprise ré-envoyaient le
même titre, donc échouaient de la même façon. Une reprise ne doit se déclencher que sur une
erreur transitoire — jamais sur une erreur de contrat.

Ce que ça donne à l'usage

J'écris un fichier markdown, je le nomme 11-mon-sujet.md, je le pose dans le dossier. Le
lendemain à 8 h 40 il est en ligne, avec ses tags et sa couverture. Le fichier est marqué
comme publié, et il ne repartira pas.

Cent trente lignes, zéro dépendance installée, et un pipeline que je peux encore lire dans
deux ans. C'est exactement ce que je demande à un outil interne.

Votre cron est mort depuis trois semaines et personne ne vous a rien dit

Dev du Sud — Sun, 01 Nov 2026 19:55:11 +0000

Un job planifié ne tombe pas en panne comme un site web. Un site web qui tombe, on le voit :
les visiteurs écrivent, les statistiques s'effondrent. Un cron qui tombe, lui, produit exactement
la même chose qu'un cron qui n'avait rien à faire : du silence.

Je l'ai découvert en ouvrant le fichier des tâches planifiées de ma machine. Une publication
automatique d'articles était en état « pause » depuis le 16 octobre à 14 h 26. Treize exécutions
consécutives en échec avant ça, du 4 au 16 octobre. Personne n'avait été prévenu — et surtout,
rien ne s'était arrêté : les autres jobs continuaient, la machine était en bonne santé, tout
avait l'air normal.

Pourquoi un job meurt sans bruit

Trois causes, et dans mon cas les trois en même temps.

1. La panne réseau. Les journaux montrent une résolution DNS impossible au moment du
déclenchement : URLError, puis Name or service not known. Le job a échoué treize fois
de suite, à la même heure, chaque matin.

2. L'ordonnanceur qui se protège. Après un certain nombre d'échecs consécutifs, un
scheduler correct met le job en pause. C'est la bonne décision : ça évite de marteler une API
morte. Mais la mise en pause n'est pas forcément visible pour un humain, et rien ne garantit
qu'on la remarque un jour.

3. La sortie que personne ne lit. Un script qui écrit dans un fichier de log ne prévient
personne. Un script qui sort en code 0 alors qu'il n'a rien fait prévient encore moins.

Il existe un quatrième cas, plus vicieux : le script tourne, sort en 0, et ne fait rien. Le
cas classique, c'est le dossier vide.

if not todo:
    print("file vide")
    sys.exit(0)          # ← le drame est ici

Tout va bien. Surtout pour le monitoring.

Garde-fou 1 — un battement de cœur horodaté

Un fichier, écrit uniquement en cas de succès réel, avec l'horodatage à l'intérieur.

from datetime import datetime, timezone
import pathlib

HEARTBEAT = pathlib.Path.home() / ".local/state/mon-job-last-success"

def marquer_succes(note: str = "") -> None:
    HEARTBEAT.parent.mkdir(parents=True, exist_ok=True)
    HEARTBEAT.write_text(f"{datetime.now(timezone.utc).isoformat()} {note}\n")

Règle : on écrit le heartbeat à la fin, après l'action réussie. Pas au début, pas « à peu
près », pas « si tout s'est bien passé jusqu'ici ». Si le script plante au milieu, aucun
heartbeat — et c'est précisément l'information qu'on veut.

Garde-fou 2 — le chien de garde qui surveille le chien de garde

Un second job, indépendant, qui ne fait qu'une chose : mesurer l'âge du heartbeat et crier
si l'âge dépasse le seuil.

#!/usr/bin/env bash
set -euo pipefail

HB="$HOME/.local/state/mon-job-last-success"
SEUIL_H=$(( 3 * 24 ))   # 3 jours pour une publication quotidienne

if [ ! -f "$HB" ]; then
  notify-send "Job: aucun heartbeat n'a jamais été écrit" || true
  exit 1
fi

AGE_H=$(( ( $(date +%s) - $(stat -c %Y "$HB") ) / 3600 ))

if [ "$AGE_H" -gt "$SEUIL_H" ]; then
  notify-send "Job muet depuis ${AGE_H} h (seuil ${SEUIL_H} h)"
  exit 1
fi

echo "ok — dernier succès il y a ${AGE_H} h"

Ce garde-fou ne répare rien : il révèle. Dans mon cas, il aurait parlé le 16 octobre au
soir au lieu du 24.

Le seuil est la seule décision qui compte. Trop court, on crie pour un job hebdomadaire
parfaitement normal ; trop long, on découvre la panne quand le stock est déjà épuisé. Pour une
publication quotidienne, trois jours laissent une marge honnête : un week-end de panne réseau
ne déclenche rien, trois jours de silence déclenchent tout.

Si vous ne voulez pas écrire ce garde-fou, les services de dead man's switch existent
(healthchecks.io, ou Uptime Kuma en auto-hébergé) : le job envoie un ping en cas de succès, le
service crie quand le ping manque. C'est la même idée, hébergée ailleurs — et c'est plus
robuste, puisque la surveillance ne meurt pas avec la machine surveillée.

Garde-fou 3 — distinguer « rien à faire » de « je n'ai pas pu faire »

C'est tout le piège du file vide. Un job qui n'avait rien à faire et un job cassé doivent
produire deux signaux différents.

if not todo:
    print("ALERTE file vide")
    sys.exit(3)          # ni succès, ni panne : problème de stock

Avec un code de sortie non nul, le scheduler marque l'exécution en échec et la remonte. Trois
codes suffisent pour se comprendre entre humains :

Code	Sens	Réaction attendue
`0`	Succès, quelque chose a été fait	Rien
`1`	Erreur technique (réseau, API, disque)	Regarder les logs, réessayer
`3`	Rien à faire, et c'est anormal	Recharger la file, réapprovisionner

La différence entre 1 et 3 est la plus utile du lot : elle dit si on doit réparer la
plomberie ou remplir le réservoir.

Garde-fou 4 — tester le contrat, pas seulement le script

Un script testé une fois en septembre ne dit rien de son comportement en novembre. Deux
vérifications automatiques, une fois par semaine :

# 1) le script est-il encore démarrable ?
python3 -m py_compile "$HOME/.hermes/scripts/mon-job.py"

# 2) a-t-il encore de quoi travailler ?
ls -1 "$HOME/devto-articles"/*.md 2>/dev/null | wc -l

Si le second nombre vaut zéro, le job va tourner pour rien. C'est exactement ce qui s'est
passé chez moi : les fichiers déjà publiés avaient été déplacés dans un sous-dossier
publies/, et le script ne regarde que la racine du dossier. Zéro candidat, tous les jours,
sans la moindre erreur.

Ajoutez flock pour éviter deux exécutions simultanées, et set -euo pipefail pour que
l'échec d'une commande intermédiaire ne soit pas avalée :

flock -n /tmp/mon-job.lock /usr/bin/python3 "$HOME/.hermes/scripts/mon-job.py"

Le détail qui m'a coûté le plus de temps

Deux runs sur treize ont échoué pour une raison différente du réseau :
422 — Title has already been used in the last five minutes. L'API refuse un titre identique
dans une fenêtre de cinq minutes, et mon script réessayait avec le même titre. Un type d'échec
sur deux est invisible dans un compteur global, et il suffit à casser un job.

Leçon : un échec n'est pas un échec. 503 (serveur fatigué), 422 (contrat violé), 401
(clé expirée) demandent trois réactions opposées — réessayer, corriger, réveiller un humain.
Les traiter pareil, c'est garantir qu'aucun des trois ne sera bien traité.

La checklist que j'applique maintenant

[ ] Un heartbeat écrit après le succès, jamais avant.
[ ] Un garde-fou indépendant qui mesure l'âge du heartbeat.
[ ] Trois codes de sortie : 0 succès, 1 panne, 3 stock vide.
[ ] Un test hebdomadaire du contrat : le script compile, la file n'est pas vide.
[ ] flock sur chaque job qui touche à un état partagé.
[ ] La sortie du job lue par quelque chose, jamais seulement écrite sur disque.
[ ] Un job mis en pause par le scheduler déclenche une alerte, pas un silence.

Ce que ça change

Rien de spectaculaire : un heartbeat, un chien de garde, trois codes de sortie, un test
hebdomadaire. Une quarantaine de lignes en tout. Mais depuis, le silence est devenu une
information.

Un job planifié n'est pas un service qui tourne. C'est une promesse renouvelée chaque nuit —
et une promesse non tenue ne fait aucun bruit. C'est à vous d'installer le bruit.

Sauvegarder ses fichiers importants automatiquement avec Python

Dev du Sud — Fri, 23 Oct 2026 09:00:00 +0000

Le jour où on regrette

On pense souvent aux sauvegardes trop tard. Le disque dur tombe en panne, l'ordinateur refuse de démarrer, un fichier est supprimé par erreur, ou un dossier client disparaît. À ce moment-là, on se dit : « j'aurais dû faire une copie ».

La bonne nouvelle, c'est qu'une sauvegarde simple n'a pas besoin d'être compliquée. Avec Python, on peut copier automatiquement un dossier important vers un autre emplacement : un disque externe, un dossier synchronisé, ou un NAS à la maison.

Ce tuto montre une sauvegarde basique, lisible, et adaptée aux débutants. Ce n'est pas une solution professionnelle complète, mais c'est déjà beaucoup mieux que rien.

La règle 3-2-1 en version simple

On entend souvent parler de la règle 3-2-1 : trois copies, sur deux supports différents, dont une hors de la maison ou de l'entreprise. Pour commencer, retenez surtout ceci : une seule copie sur le même ordinateur ne suffit pas.

Si votre dossier original et votre sauvegarde sont sur le même disque, une panne peut emporter les deux. L'idéal est de copier vers un support différent.

Le script Python

from pathlib import Path
import shutil
from datetime import datetime

SOURCE = Path("documents-importants")
DESTINATION = Path("sauvegardes")

horodatage = datetime.now().strftime("%Y-%m-%d_%H-%M")
dossier_backup = DESTINATION / f"backup_{horodatage}"

if not SOURCE.exists():
    raise SystemExit(f"Le dossier source n'existe pas : {SOURCE}")

shutil.copytree(SOURCE, dossier_backup)
print(f"Sauvegarde créée dans : {dossier_backup}")

Ce que fait ce script

Le dossier documents-importants est le dossier à protéger. Le dossier sauvegardes est l'endroit où Python va créer une copie. À chaque lancement, le script ajoute la date et l'heure dans le nom du dossier, par exemple backup_2026-10-11_18-30.

C'est très pratique, car on garde plusieurs versions. Si vous avez modifié un fichier hier et que vous regrettez aujourd'hui, vous pouvez retrouver une ancienne copie.

La fonction copytree copie tout le dossier. Elle est simple et efficace. Pour de très gros volumes, il existe des méthodes plus avancées qui ne copient que les fichiers modifiés. Mais pour apprendre et protéger un petit dossier, cette version est parfaite.

Comment l'adapter

Remplacez documents-importants par le chemin de votre vrai dossier. Par exemple, cela peut être un dossier Clients, Factures, Photos famille, ou Administratif. Remplacez aussi sauvegardes par votre disque externe si vous en avez un.

Sur Windows, un chemin peut ressembler à D:/Sauvegardes. Sur Linux ou Mac, il peut ressembler à /media/ludo/DisqueUSB/Sauvegardes. Le plus important est de tester avec un petit dossier avant de viser vos vrais fichiers.

Automatiser vraiment

Un script qu'on oublie de lancer ne sert pas à grand-chose. L'étape suivante consiste donc à le lancer automatiquement. Sur Windows, on peut utiliser le Planificateur de tâches. Sur Linux ou Mac, on peut utiliser cron ou un service équivalent.

Choisissez un rythme réaliste. Pour des fichiers très importants, une sauvegarde quotidienne peut être utile. Pour des documents moins actifs, une fois par semaine suffit peut-être.

Les erreurs fréquentes

Première erreur : ne jamais vérifier les sauvegardes. Une sauvegarde doit être testée. Ouvrez quelques fichiers copiés pour confirmer qu'ils sont lisibles.

Deuxième erreur : laisser le disque externe toujours branché. Si un ransomware chiffre vos fichiers, il peut aussi toucher le disque branché. Pour une vraie protection, branchez le disque, lancez ou laissez faire la sauvegarde, puis débranchez-le.

Troisième erreur : confondre synchronisation et sauvegarde. Un service cloud qui synchronise supprime parfois aussi le fichier partout si vous le supprimez par erreur. C'est pratique, mais ce n'est pas toujours une sauvegarde historique.

À retenir

Une sauvegarde simple aujourd'hui vaut mieux qu'un plan parfait jamais mis en place. Commencez avec un dossier important, une copie datée, et une vérification manuelle. Ensuite, vous pourrez automatiser le lancement.

Python ne rend pas vos données invincibles, mais il peut vous éviter le grand moment de solitude du fichier perdu.

Générer un PDF de rapport ou de facture sans acheter de logiciel

Dev du Sud — Wed, 21 Oct 2026 22:14:54 +0000

Pourquoi générer un PDF soi-même

Beaucoup de petites activités ont besoin de documents simples : une facture, un compte rendu d'intervention, un rapport de visite, un devis rapide, une fiche client. On peut le faire dans Word ou LibreOffice, bien sûr. Mais quand le même document revient souvent, remplir les mêmes lignes à la main devient vite pénible.

Python peut générer un PDF automatiquement à partir de quelques informations : nom du client, date, lignes de prestation, total. Pas besoin d'acheter un logiciel compliqué pour comprendre le principe.

Dans ce tuto, on va créer une mini facture très simple. Elle ne remplace pas un logiciel de comptabilité complet, surtout si vous avez des obligations légales précises. Mais elle montre comment produire un PDF propre, répétable, et facile à adapter.

L'outil utilisé

On va utiliser reportlab, une bibliothèque Python gratuite très connue pour créer des PDF. Si elle n'est pas installée, il faudra l'ajouter une fois sur votre ordinateur. Ensuite, le script pourra générer autant de PDF que vous voulez.

Le principe est très simple : on crée une page, on écrit du texte à des positions précises, puis on sauvegarde le fichier.

Le script Python

from reportlab.lib.pagesizes import A4
from reportlab.pdfgen import canvas
from reportlab.lib.units import cm

client = "Boulangerie du Port"
numero = "FAC-2026-001"
lignes = [
    ("Diagnostic ordinateur caisse", 1, 49.00),
    ("Sauvegarde des fichiers", 1, 39.00),
    ("Nettoyage logiciel", 1, 29.00),
]

fichier_pdf = "facture-exemple.pdf"
pdf = canvas.Canvas(fichier_pdf, pagesize=A4)
largeur, hauteur = A4

pdf.setFont("Helvetica-Bold", 18)
pdf.drawString(2 * cm, hauteur - 2 * cm, "Facture")

pdf.setFont("Helvetica", 11)
pdf.drawString(2 * cm, hauteur - 3 * cm, f"Numéro : {numero}")
pdf.drawString(2 * cm, hauteur - 3.7 * cm, f"Client : {client}")

pdf.line(2 * cm, hauteur - 4.5 * cm, largeur - 2 * cm, hauteur - 4.5 * cm)

y = hauteur - 5.5 * cm
total = 0
for description, quantite, prix in lignes:
    montant = quantite * prix
    total += montant
    pdf.drawString(2 * cm, y, description)
    pdf.drawRightString(15 * cm, y, f"{quantite} x {prix:.2f} €")
    pdf.drawRightString(19 * cm, y, f"{montant:.2f} €")
    y -= 0.8 * cm

pdf.line(12 * cm, y, largeur - 2 * cm, y)
y -= 0.8 * cm
pdf.setFont("Helvetica-Bold", 12)
pdf.drawRightString(19 * cm, y, f"Total : {total:.2f} €")

pdf.setFont("Helvetica", 9)
pdf.drawString(2 * cm, 2 * cm, "Document généré automatiquement avec Python.")
pdf.save()
print(f"PDF créé : {fichier_pdf}")

Ce que fait le script

La liste lignes contient les prestations. Chaque ligne a trois informations : le texte, la quantité, et le prix unitaire. Python calcule le total tout seul. Si vous ajoutez une prestation, le montant final change automatiquement.

Les coordonnées peuvent sembler étranges au début. Dans un PDF, on place les éléments sur une page, un peu comme sur une feuille avec une règle. 2 * cm signifie simplement « deux centimètres depuis le bord ». On n'a pas besoin de tout comprendre d'un coup : commencez par modifier les textes et les prix.

Comment l'utiliser au quotidien

Vous pouvez transformer ce script en modèle. Par exemple, un réparateur peut changer le nom du client et les prestations après chaque intervention. Une association peut générer un rapport mensuel. Un freelance peut produire un devis simple.

Le vrai intérêt arrive quand les données viennent d'un fichier. Imaginez un tableau avec tous les clients du mois. Python pourrait lire chaque ligne et générer un PDF par client. Là, le gain de temps devient énorme.

Attention aux obligations légales

Une facture réelle doit respecter des règles : identité de l'entreprise, numéro unique, dates, mentions, TVA selon votre situation, conditions de paiement, et parfois d'autres informations. Ce tuto ne donne pas un modèle légal complet. Il donne une base technique.

Si vous voulez l'utiliser pour une vraie activité, vérifiez les mentions obligatoires avec une source officielle ou votre comptable. L'automatisation ne dispense pas d'être carré.

À retenir

Créer un PDF avec Python, ce n'est pas réservé aux grosses entreprises. Pour des documents répétitifs, c'est même une excellente porte d'entrée dans l'automatisation. Vous commencez avec une facture simple, puis vous ajoutez petit à petit votre logo, vos couleurs, vos conditions, ou vos données clients.

Le but n'est pas de faire joli dès le premier jour. Le but est d'arrêter de recopier les mêmes informations à la main.

DEV Community: Dev du Sud

127 vues et 0 clic — le tableau de bord le plus utile que j'aie construit

Le tracker, en quarante lignes

127 et 0 : vérifier avant de conclure

Pourquoi le zéro vaut mieux que la moyenne

Ce que j'ai changé : la page, pas le tracker

Les limites d'un tracker maison

Ce qu'un tableau de bord honnête doit accepter

17 modèles LLM en local sur un iGPU et 14 Go de RAM — ce que ça vaut vraiment

Ce que 14 Go veulent dire pour un modèle

Dix-sept modèles sur le disque, un seul en mémoire

Là où le local gagne, sans discussion

Là où l'API gagne, et il faut le dire

Router selon la tâche

Ce que la mesure tranche

317 tâches et 36 projets dans SQLite — le statut « abandonné » m'a plus servi que les autres

La répartition, brute

Dix tâches en cours, et pas une de plus

Pourquoi « abandonné » est un statut

La colonne qui décide : preuve

Ce que SQLite encaisse, et ce qu'il n'encaisse pas

Ce que 317 lignes m'ont appris

26 automatisations surveillées par un tableau de bord qui ne consomme aucun token

Ce qu'un job laisse derrière lui

Le registre : une ligne par job

Le cycle, en 9 à 11 secondes

Le rendu : du HTML, du fetch, et rien d'autre

0 token, et ce que ça implique

La leçon que m'a donnée le premier job vert

Mon cron de 3 h ne tournait que les nuits où j'avais laissé le PC allumé

Ce que cron ne promet pas

Pourquoi je ne l'ai vu que trois semaines plus tard

La réponse historique : anacron

Ce que j'utilise maintenant : un timer systemd persistant

Vérifier que ça a réellement rattrapé

Ce que le rattrapage ne répare pas

Gmail refuse une sauvegarde de 329 Mo — et relever la limite n'est pas la réparation

Les 25 Mo ne sont pas 25 Mo

Découper, mais pas n'importe comment

Le manifeste part en premier

Reconstituer et vérifier

Pourquoi relever la limite est toujours la mauvaise réparation

Ce que je garde

Un dossier, c'est une file d'attente : 21 articles publiés sans base de données

Le nom du fichier est l'ordre de publication

Un fichier = un article, et un seul

Le déplacement est la transaction

Ce qui se passe quand le dossier est vide

Le journal, trois colonnes

Pourquoi je n'ai pas ajouté de base de données

Mes 200 tâches tiennent dans un fichier SQLite de 192 Ko

Ce que j'ai réellement besoin de stocker

La colonne qui a tout changé : preuve

Les quatre requêtes qui servent tous les jours

La commande, en 120 lignes d'argparse

Sauvegarde : cp ne suffit pas

Ce que SQLite ne fait pas

Pourquoi je ne reviens pas en arrière

Publier sur Dev.to depuis un serveur, avec 130 lignes de Python et zéro dépendance

Ce dont l'API a besoin

Étape 1 — lire le front-matter sans PyYAML

Étape 2 — le piège du titre vide

Étape 3 — les tags valides, sinon 422

Étape 4 — créer en brouillon, puis publier

Étape 5 — un fichier d'état, sinon vous publiez deux fois

Le cron, et la seule ligne qui compte

Les quatre erreurs que j'ai vues en vrai

Ce que ça donne à l'usage

Votre cron est mort depuis trois semaines et personne ne vous a rien dit

Pourquoi un job meurt sans bruit

Garde-fou 1 — un battement de cœur horodaté

Garde-fou 2 — le chien de garde qui surveille le chien de garde

Garde-fou 3 — distinguer « rien à faire » de « je n'ai pas pu faire »

Garde-fou 4 — tester le contrat, pas seulement le script

Le détail qui m'a coûté le plus de temps

La checklist que j'applique maintenant

Ce que ça change

Sauvegarder ses fichiers importants automatiquement avec Python

Le jour où on regrette

La règle 3-2-1 en version simple

La colonne qui décide : `preuve`

Le rendu : du HTML, du `fetch`, et rien d'autre

La colonne qui a tout changé : `preuve`

Sauvegarde : `cp` ne suffit pas