Le Blog d'Arhuman

C’est la deuxième fois ce matin. Encore une fois, sans rien dire, Claude Code a co-signé mon commit.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Quand je lui fais remarquer, il s’excuse platement et recommence.

J’avais pourtant écrit, en majuscules, dans mon CLAUDE.md global :

NEVER append a Co-Authored by Claude in commit description

C’est le fichier que Claude Code charge à chaque session.

Je dis publiquement que j’utilise l’IA, mais je réponds de mon code. Avec cet ajout un client peut se demander qui répond du code, un mainteneur ce que “co-author” implique alors que ces questions n’ont pas lieu d’être. Co-signer ce n’est pas assister, c’est revendiquer la paternité.

Tous les développeurs ont déjà vécu cette scène : le pic d’adrénaline à l’annonce de l’incident en production. Ce mélange d’angoisse de ce que l’on va découvrir et de frénésie à collecter toute information qui nous permettra de comprendre puis corriger le problème. Cela m’est à nouveau arrivé il y a quelques jours, je me revois me précipiter sur les logs et je me souviens encore de la frustration de n’y trouver que des infos basiques et un message d’erreur peu explicatif “Impossible de charger le cache”.

On ne va pas parler ici d’altruisme, je n’ai aucune intention d’offrir à mon modèle un datacenter ou l’accès à toutes les connaissances humaines (ça d’autres s’en chargent déjà).

Quand je dis “réaliser”, je le pense au sens littéral: comment implémenter la fonction de rêver pour un modèle ?

Mais pour comprendre pourquoi et comment je suis arrivé à cette hypothèse de conception, il faut revenir en arrière.

La mémoire n’est pas du stockage

Tout part d’un travail sur la mémoire à long terme des agents que j’essaie d’implémenter via l’outil Open Source Mnemos¹.

À chaque problème complexe correspond une solution claire, simple… et fausse.
— H. L. Mencken

J’ai passé des années à chercher des solutions élégantes à des problèmes complexes.

Aujourd’hui, l’un d’eux me résiste particulièrement :

Comment évaluer la qualité réelle d’un dépôt de code source ?

Avec l’IA, le défi a changé. Ce n’est plus seulement “est-ce que ça fonctionne ?”, mais :
Ce code sera-t-il encore maintenable, sûr et fiable dans six mois ?

Ce matin, je me suis amusé à compresser le temps.

Mais avant que vous m’imaginiez en génie de la physique théorique ou en hurluberlu ayant besoin d’une camisole de force, laissez-moi vous expliquer.

Je travaille actuellement sur Metarc, un outil de metacompression (comprendre : appliquer des transformations intelligentes à certaines structures avant de passer le relais à un compresseur classique comme zstd). Si vous n’avez jamais entendu ce terme, vous allez comprendre en 5 minutes. Si vous êtes expert en compression, accrochez-vous, vous trouverez peut-être matière à débat.

…et comment l’IA l’a fait maçon

Mon profil psychologique est INTJ¹ aussi appelé Architecte, et j’ai passé une bonne partie de ma vie à prouver que cette étiquette était adaptée…de la pire des manières.

Des années à avoir une multitude d’idées

• sur des systèmes d’analyse (Blockchain, Productivité)
• sur des méthodes de développement personnel (Mémoire, Discipline, Apprentissage)
• des algorithmes (routage, metacompression, chiffrement)
• des outils (conversion de formats, gestion de projet, administration système)

Des années à produire des centaines d’idées à la chaîne pour rien ou pire pour en voir certaines réalisées par d’autres des années plus tard.

Et si le vrai gain n’était pas au niveau des octets ?

J’ai toujours été fasciné par les algorithmes de compression, j’avais 15 ans quand j’ai “inventé” le Run Length Encoding (avant d’apprendre qu’il avait été découvert plus de 20 ans avant ma naissance).
Je me suis extasié sur la simplicité “visuelle” du codage de Huffman, et sur l’astuce de Lempel-Ziv qui construit dynamiquement son dictionnaire.

Ces algorithmes sont puissants, et ce n’est pas un hasard s’ils sont sans cesse améliorés et encore combinés pour produire de nouveaux algorithmes encore plus puissants : Brotli, zstd.

Vos plannings dérapent, vos deadlines explosent et le périmètre se réduit.

Est-ce la faute de votre méthode de gestion de projet ?

Non, bien sûr. Chaque méthode a ses forces et son utilité et offre un cadre plus efficace que le développement au fil de l’eau et au doigt mouillé.

Mais toute méthode a deux effets pervers :

La méthode donne souvent un faux sentiment de sécurité

La méthode rassure parce qu’elle rend visible ce qui est facile à mesurer, mais des KPI au vert peuvent masquer un projet qui va dans le mur :

Introduction

En informatique, l’aphorisme “Less is More” revient souvent. Avec Jujutsu (jj), il prend une forme très concrète : un modèle mental plus simple peut réduire la friction quotidienne dans la gestion de versions.

Dans cet article¹, je ne vais pas chercher à “prouver” que jj est supérieur à git. Je vais montrer, sur un cas concret, pourquoi certaines opérations courantes : interrompre un travail, réorganiser ses modifications, corriger un commit non atomique ou résoudre un conflit, deviennent plus naturelles avec jj.

Pourquoi écrire encore sur le layout et les pratiques Go en 2026 ?

En 2018, Mat Ryer écrivait un article de référence How I write HTTP services after 8 years qu’il a mis à jour quelques années plus tard : “How I write HTTP services in Go after 13 years”.

En 2019, je présentais déjà ma manière de coder en Go dans plusieurs présentations d’introduction au langage.

Ce texte est une version révisée de cette présentation, nourrie par mon expérience et mes contraintes en 2026.