Les petites automatisations qui se cumulent sur un trimestre

En janvier, j’ai compté. Pas les gros projets, les petits scripts, les hooks, les raccourcis que j’avais écrits au fil des mois précédents. Il y en avait vingt-trois. Aucun ne m’avait pris plus d’une heure. Aucun n’était impressionnant. Et collectivement, ils m’avaient rendu une demi-journée par semaine.

Ce n’est pas un article sur l’automatisation spectaculaire, le pipeline CI qui sauve la mise, le bot qui remplace trois personnes. C’est sur l’autre genre : les scripts de deux minutes qui s’accumulent silencieusement jusqu’à ce qu’un jour vous réalisiez que votre semaine ne ressemble plus à celle d’il y a six mois.

Le calcul que personne ne fait

Il y a un xkcd célèbre qui montre combien de temps on peut investir dans l’automatisation d’une tâche en fonction de sa fréquence. Le tableau est utile, mais il rate un effet : l’automatisation ne fait pas que gagner du temps, elle supprime de la friction cognitive. Un script qui fait gagner trente secondes mais supprime une décision élimine un coût que le tableau ne mesure pas.

Mon exemple préféré : un hook post-commit qui lance le linter sur les fichiers modifiés et affiche les erreurs dans le terminal. Gain en temps pur ? Peut-être dix secondes. Mais le vrai gain, c’est que je ne pense plus jamais au linting. Il a disparu de ma charge mentale. Multiplié par vingt décisions similaires, c’est un cerveau moins encombré en fin de journée.

Mes catégories d’automatisation

Après un an à noter chaque petit script que j’écrivais, j’ai vu émerger quatre catégories :

1. Les garde-fous silencieux

Des vérifications qui tournent sans qu’on les invoque. Un pre-push hook qui vérifie que les secrets ne fuient pas. Un script de CI qui refuse un merge si la description de PR est vide. Un check qui alerte si un fichier .env.example ne correspond plus aux variables réellement utilisées.

Ces automatisations ne font rien de visible, jusqu’au jour où elles attrapent le truc qui aurait coûté cher.

2. Les raccourcis de contexte

Des alias et des scripts qui réduisent le coût de reprendre un contexte. Un make status qui affiche en une commande : la branche, les PRs ouvertes, les tests qui tournent, le dernier déploiement. Un script qui ouvre les cinq fichiers les plus touchés par la branche courante. Un raccourci qui génère le résumé de mes commits de la semaine pour le standup.

Le point commun : ils transforment une question de trente secondes (« où j’en étais ? ») en une réponse instantanée.

3. Les générateurs de squelette

Des templates exécutables. Un make new-post qui crée le fichier Markdown avec le bon frontmatter et ouvre l’éditeur. Un make new-tool qui scaffold un composant avec les bons imports. Un script qui génère un fichier de migration à partir du schéma actuel de la base.

Le gain n’est pas seulement le temps d’écriture, c’est la conformité garantie. Chaque fichier généré respecte les conventions sans effort.

4. Les rapports automatiques

Des scripts qui collectent et affichent de l’information qu’on aurait consultée manuellement. Un résumé hebdomadaire des métriques du projet (taille du bundle, nombre de tests, couverture). Un rapport mensuel des dépendances obsolètes. Un check quotidien des certificats qui expirent.

La règle des quinze minutes

Ma règle personnelle : si j’hésite à automatiser quelque chose, je me donne quinze minutes. Si en quinze minutes j’ai un script qui marche (même mal), je le garde et je l’améliore plus tard. Si après quinze minutes je n’ai rien, j’abandonne et je note le besoin pour plus tard.

La plupart de mes vingt-trois scripts sont nés de ces fenêtres de quinze minutes. Ils ne sont pas élégants. Certains sont des one-liners bash. D’autres sont dix lignes de Node. Aucun ne mérite un dépôt GitHub. Mais ils tournent.

Ce qui ne marche pas

Tout n’est pas automatisable, et certaines automatisations coûtent plus qu’elles ne rapportent :

Les tâches qui changent chaque fois. Si le processus n’est pas stable, le script sera périmé avant d’avoir été utile.
Les tâches qu’on fait une fois par mois. Le coût cognitif de se rappeler que le script existe dépasse le gain.
Les tâches qui nécessitent du jugement. Les automatiser produit une fausse confiance, on cesse de réfléchir à la chose qu’elles ne couvrent pas.

La meilleure heuristique que j’ai trouvée : n’automatise que ce qui t’irrite. L’irritation est un signal fiable que la tâche est fréquente, prévisible et sans valeur intellectuelle.

L’effet de cumul

Le vrai pouvoir de ces petites automatisations n’apparaît pas script par script. Il apparaît au bout de trois mois, quand vous réalisez que votre workflow a changé de forme. Les déploiements ne sont plus stressants parce que six vérifications tournent avant. Les revues de code sont plus rapides parce que le linting et les conventions sont déjà vérifiés. Les changements de contexte coûtent moins cher parce que le résumé est déjà là.

Comme l’écrivent Hunt et Thomas dans The Pragmatic Programmer, « Don’t Repeat Yourself » ne s’applique pas qu’au code, il s’applique à vos processus. Chaque tâche répétitive que vous continuez de faire à la main est une forme de duplication.

Commencez petit. Un script cette semaine. Un hook la semaine prochaine. Un alias vendredi. Dans trois mois, comptez.

Si cela vous a parlé, vous aimerez La boucle d’agent qui a remplacé mon samedi et Écrire des skills que votre agent de code utilisera vraiment. Abonnez-vous ci-dessous pour recevoir le billet de vendredi prochain.