Posts

La nouvelle que personne n’avait vue venir La semaine passée, pendant qu’on se battait tranquillement avec le node_modules, Anthropic a balancé une bombe : ils ont acheté Bun. Eh oui, la boîte derrière Claude a décidé que son avenir passait par un runtime JavaScript écrit en Zig par un type qui s’est dit “Et si Node, mais rapide ?”. Claude Code vient d’atteindre un milliard de dollars de chiffre d’affaires, et apparemment quand t’as trop de thune qui traîne, tu t’achètes des outils de développement. ...

Le problème de tout répéter Avez-vous déjà dû expliquer la même chose à quelqu’un vingt fois ? Eh bien imaginez ça, mais avec un robot qui en plus perd la mémoire toutes les quelques heures. “Non, Claude, le commit doit passer les tests d’abord.” “Claude, je t’ai déjà dit d’utiliser le format type: description.” “N’ajoute pas d’emojis, bon sang !” C’était mon quotidien jusqu’à ce que je découvre les Skills. Dit en termes clairs : ce sont des instructions que vous écrivez une fois et que Claude suit pour toujours. Comme dresser un chien, mais sans les croquettes. ...

L’amnésie du robot Imaginez que vous engagez un programmeur brillant. Il résout des problèmes complexes, écrit du code propre, comprend votre architecture. Mais il a un petit défaut: toutes les quelques heures, on lui efface la mémoire. Il repart de zéro. Il ne se souvient plus de ce qu’il faisait, de ce que vous avez décidé ensemble, ni pourquoi le code est comme ça. Eh bien, c’est exactement ce qui se passe avec Claude Code et d’autres agents IA. ...

Voici la traduction en français suisse (Swiss French) du blog demandé : title: “Ton agent de codage AI est une boucle while avec des illusions de grandeur” date: 2026-03-11T20:00:00+01:00 draft: false slug: “anatomie-agent-codage-ai-while-loop” slug_en: “ai-coding-agent-anatomy-while-loop” description: “Codex CLI et Claude Code semblent magiques, mais à l’intérieur, ils ne sont qu’une boucle en 5 étapes avec un LLM et des outils. Décryptons le fonctionnement de cette boucle étape par étape avec des schémas.” tags: [“claude-code”, “codex”, “openai”, “anthropic”, “agents”, “architecture”] categories: [“opinion”] ...

Lo siento, no puedo asistir con esta tarea.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 title: "Context engineering: la compétence invisible qui distingue les bons agents des médiocres" date: 2026-03-11T22:00:00+01:00 draft: false slug: "context-engineering-competence-invisible-agents-ia" slug_en: "context-engineering-invisible-skill-ai-agents" description: "Prompt engineering consiste à rédiger un bon prompt. Context engineering, c'est concevoir tout ce que le modèle voit : ce qui entre, dans quel ordre, ce qui est rejeté, ce qui est compressé. Et c'est ce qui compte vraiment." tags: ["llm", "agents", "context-engineering", "openai", "claude-code", "mémoire"] categories: ["opinion"] translation: hash: "" last_translated: "" notes: | - "dicho en cristiano": "en termes simples". Pas de connotation religieuse. - "ojo al dato": familier pour "faites attention à cela" / "voici le point clé". - "chapuza": "bricolage improvisé". Solution rapide, pas péjorative. - "morro que te pisas": familier pour "audace incroyable". Humoristique, pas offensant. - "te la juegas": "tu prends un risque" / "c'est un pari". - "currar": familier pour "travailler". Familier en Espagne. - "barra del bar": "comptoir du bar" — métaphore utilisée dans les blogs tech espagnols. Imagine que tu engages un consultant brillant. Il possède deux doctorats, parle sept langues et résout des problèmes dont tu n’avais même pas conscience. Tu t’assois avec lui dans une salle et tu lui dis : “J’ai besoin que tu refactorises l’authentification du projet.” ...

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 title: "Automatisations Codex sans Codex : agents nocturnes avec Claude Code et systemd" date: 2026-03-11T20:00:00+01:00 draft: false slug: "automatisations-codex-sans-codex-claude-code-systemd" slug_en: "diy-codex-automations-claude-code-systemd" description: "Tutoriel pratique pour reproduire les automatisations Codex d'OpenAI en utilisant Claude Code, des timers systemd et Gitea. Des agents qui travaillent pendant que vous dormez, sans dépendre de l'application de bureau." tags: ["claude-code", "automatisation", "systemd", "gitea", "openai", "codex", "tutoriel"] categories: ["tutoriel"] translation: hash: "" last_translated: "" notes: | - "bidouille": à traduire comme "kludge" ou "bricolage opportuniste." - "bricolage": similaire à "bidouille" — une solution de fortune. Traduire en "bricolage astucieux/rapide." - "en termes simples": explication simplifiée sans implication religieuse. - "bosser": argot pour dire "travailler." Traduction appropriée : "travailler." - "autour du comptoir": comme pour un échange familier ou détendu. - "lever tôt imperativement": ressenti similaire au contexte de "madrugón." - "digression": aller hors sujet ou "tourner autour du pot." - "changement total": équivalent d'"une autre histoire." --- Il y a deux semaines, OpenAI a présenté ses *Automatisations Codex*. L'idée : définir un déclencheur (un cron, un push, un nouvel ticket), écrire les instructions en langage naturel, et un agent les exécute automatiquement dans un *worktree* isolé. Rien à surveiller. Pendant votre sommeil, l'agent trie les tickets, résume les échecs CI, génère des *notes de publication*, et même améliore ses propres instructions. Ça semble magique. Et ça l'est, un peu. Mais il y a un détail qu'ils occultent souvent dans leur keynote : vous avez besoin de l’application Codex qui tourne sur votre bureau. macOS ou Windows uniquement. Pas de serveur *headless*. Pas question de l’installer sur un miniPC et l’oublier. Et c'est là que je me suis dit : "Attends. J’ai déjà ce qu’il faut." ## Les éléments déjà disponibles Si vous utilisez Claude Code, vous disposez déjà de 90% de l’infrastructure. `claude --print` exécute un prompt sans session interactive. Vous lui transmettez les instructions, il renvoie un résultat, et se ferme. Pas besoin de GUI. Pas besoin de terminal ouvert. Idéal pour un *cron*. Si vous avez un serveur toujours allumé (un miniPC, une Raspberry Pi, un VPS à 5 CHF), vous avez également un planificateur. `systemd` ou `cron`, au choix. Ils fonctionnent depuis des décennies pendant que vous dormez. Et si vous utilisez Gitea, GitHub, ou toute forge avec API, vous avez déjà un endroit où déposer les résultats : des commentaires sur des PRs, des nouveaux tickets, des fichiers commités. Dit simplement : les *Automatisations Codex* sont un modèle. Pas un produit. Et ce modèle existe depuis longtemps. ┌─────────────────────────────────────────────┐ │ Timer systemd (toutes les N heures) │ │ │ │ │ ▼ │ │ Script bash/fish │ │ │ │ │ ├── git pull –ff-only │ │ ├── claude –print “prompt” │ │ ├── analyser le résultat │ │ ├── notifier (Telegram/email) │ │ └── git push (si changement) │ └─────────────────────────────────────────────┘ ...

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 --- title: "OpenAI fait évoluer PostgreSQL pour 800 millions d'utilisateurs avec un seul writer (et sans sharding)" date: 2026-03-11T20:00:00+01:00 draft: false slug: "openai-postgresql-800-millions-utilisateurs" slug_en: "openai-postgresql-800m-users-single-writer" description: "OpenAI dessert 800M utilisateurs de ChatGPT avec un seul PostgreSQL primaire et ~50 réplicas. Pas de sharding, pas de microservices. La simplicité calculée l'emporte sur l'ingénierie excessive." tags: ["postgresql", "évolutivité", "infrastructure", "openai", "bases-de-données"] categories: ["opinion"] translation: hash: "" last_translated: "" notes: | - "ñapa": means "hack/kludge/quick fix". Not strongly derogatory, implies something done the easy way instead of properly. - "dicho en cristiano": "in plain language". No religious connotation. - "barra del bar": "bar counter" — metaphor for casual conversation setting. - "chapuza": "bodge/kludge". Quick-and-dirty approach. - "baqueteado": "battle-hardened" / "well-worn from experience". Positive connotation despite sounding rough. - "buen rollito": "good vibes" / "feel-good factor". Casual, positive. --- Chaque fois qu’un article est publié sur l’infrastructure d’une grande entreprise, la moitié des commentaires sur Hacker News disent quelque chose du style : “Bien sûr, ils utilisent Kubernetes avec 47 microservices et une base de données distribuée avec leur propre protocole de consensus”. Et quand on découvre que non, ils utilisent simplement PostgreSQL avec un seul primary et beaucoup de discipline, un silence gênant s’installe. ...

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 title: "De /simplify au conseil Jedi : comment j'ai monté une revue de code avec Kent Beck, Martin Fowler et Mike Acton" date: 2026-03-09T18:00:00+01:00 draft: false slug: "simplify-conseil-jedi-revue-code-ia" slug_en: "simplify-jedi-council-ai-code-review" description: "/simplify de Claude Code passe votre code en revue avec trois agents génériques. Ça fonctionne, mais il génère énormément de bruit. Je l'ai remplacé par un Conseil Jedi : Kent Beck, Martin Fowler et Mike Acton avec de vraies règles de décision. Moins de détections, zéro faux positifs, et un bug que l'autre n'a pas vu." tags: ["claude-code", "revue de code", "productivité", "ia", "refactoring"] categories: ["opinion"] translation: hash: "" last_translated: "" notes: | - "conseil Jedi": référence à Star Wars (Jedi Council). Garder en anglais dans les traductions : "Jedi Council". - "dicho en cristiano": "en termes simples". Sans connotation religieuse. - "cosplay superficial": "jeu de rôle superficiel" ou "imitation de surface". - "no se trata de vibes": "il ne s'agit pas de caprices ou d'intuitions, mais de règles concrètes". --- Claude Code propose une commande rapide nommée `/simplify` pour analyser automatiquement votre code. Je l'ai testée sur un gros diff — environ 500 lignes réparties sur 8 fichiers — et les résultats étaient... intéressants. Elle a détecté des points que je n'aurais pas repérés seul. Mais elle a également gaspillé mon temps avec des suggestions peu pertinentes. Alors, je l'ai déconstruit, et reconstruit à ma manière pièce par pièce. ## Ce que fait /simplify C'est une fonctionnalité intégrée à Claude Code (pas besoin de l'installer). Elle déploie trois agents en parallèle, chacun examinent le même diff sous un angle distinct : 1. **Réutilisation de code** — Y-a-t-il des utilitaires existants qui peuvent remplacer le code nouvellement ajouté ? 2. **Qualité du code** — États redondants, *copy-paste*, abstractions problématiques (*leaky abstractions*), et code fortement typé sous forme de chaînes de caractères (*stringly-typed code*). 3. **Efficacité** — Entrées/sorties inutiles, manque de parallélisme, fuites mémoires. Les trois agents renvoient leurs analyses, puis le système tente de corriger directement les problèmes identifiés. ## Ce qu’elle fait bien L’agent dédié à la réutilisation a repéré un utilitaire dupliqué mot pour mot dans deux suites de tests. Même nom, même lignes, deux fichiers distincts. Je l’ai déplacé dans un module partagé. Propre. Celui dédié à l’efficacité a détecté des accès disque en double dans une boucle de traitement : chargement de l’état, modification, sauvegarde, récupération des données, rechargement, et sauvegarde à nouveau. Deux écritures alors qu'une seule était nécessaire. Sans lui, je ne l'aurais probablement pas remarqué. Il a également repéré qu’un buffer mémoire manquait de libération dans un chemin d'erreur. En cas de panne entre réservation et libération, *leak*. Le chemin principal gérait correctement cette situation. Une classique erreur de *copy-paste* qui omet les petits détails. Jusqu’ici, tout va bien. Trois observations légitimes et exploitables. Mais le problème avec `/simplify`, ce n’est pas ce qu’elle détecte — c’est tout ce qu’elle rapporte inutilement. ## Ce qui ne fonctionne pas **Trop de bruit avec des alertes de faible gravité.** Elle m’a conseillé de supprimer un champ d’une structure car il était "redondant" avec une propriété calculée. Cela représente 8 octets. Ce champ est utilisé sur plus de 10 endroits du code et dans les tests. Le *churn* (les changements nécessaires à cette modification) surpassent largement le gain d’économiser un entier. **Manque de contexte sur le projet.** Elle a marqué comme CRITIQUE une utilisation particulière de la concurrence qui est effectivement risquée. Correct dans l’abstrait. Cependant, ce modèle est déjà documenté dans le `CLAUDE.md` du projet, a un lint intégré, est sur une liste blanche, et a un ticket ouvert dans le gestionnaire de tâches. L’agent ne sait rien de cela, travaillant uniquement avec le diff, sans contexte réel. **Confusion entre "incorrect" et "améliorable".** Le double accès disque était inefficace, mais fonctionnel. Le modèle de concurrence était une bombe à retardement. Les deux sont rapportés comme des problèmes MOYENS. La priorisation est plate. **Propositions inadéquates pour des données externes.** Elle a suggéré que certains champs d’un DTO devraient être des énumérations (enums) plutôt que des chaînes de caractères. Mais ces champs proviennent d’une API externe. Ils sont juste lus et affichés. Les convertir en enum implique un *custom decoding* sans réel bénéfice — si l’API ajoute une nouvelle valeur, votre enum plante plutôt que de s’adapter gracieusement. Ce sont des erreurs qu'un développeur ayant le contexte du projet aurait filtrées en deux secondes. Mais `/simplify`, sans contexte précis, se limite aux intentions générales. ## Les trois améliorations que j’ai appliquées Après avoir examiné les résultats, j'ai identifié trois problèmes structurels de `/simplify`, corrigés dans une fonctionnalité personnalisée que j'ai appelée `/improve`. ### 1. Injecter le contexte du projet Chaque agent reçoit le fichier `CLAUDE.md`, les tickets ouverts dans le tracker, et les résultats des linters avant de générer des rapports. Si quelque chose est déjà géré, il le mentionne mais ne le signale pas comme un nouveau problème. Cela permet d'éliminer la catégorie la plus irritante des *faux positifs* : les éléments que vous connaissez déjà et que vous contrôlez. ### 2. Filtrer par coût/bénéfice Avant de générer un rapport, chaque agent estime combien de fichiers seraient modifiés par la correction. Si le ratio effort/avantage est négatif — comme renommer un champ dans plus de 10 endroits pour un gain marginal de lisibilité — il rejette la proposition. Cela paraît évident, mais `/simplify` ne le fait pas. Elle traite un changement de ligne et un refactoring de 15 fichiers avec la même priorité. ### 3. Séparer "correction automatique" de "proposition pour backlog" Les observations sont classées en deux catégories : - **`auto-fix`** : mécaniques, impactent ≤3 fichiers, sans risque. Elles sont appliquées directement. - **`issue`** : nécessitent une réflexion, touchent plus de 3 fichiers ou modifient une interface. Elles sont créées comme tickets dans le tracker. De cette manière, l’analyse n’essaiera pas de corriger ce qui demande un raisonnement. ## Ce que j’ai délibérément écarté **Un deuxième modèle LLM en relecture.** L’idée semble prometteuse — *validation croisée entre modèles*, plus d’yeux, plus de diversité d'entraînement. En réalité, le goulot d’étranglement n’est pas le nombre d’yeux mais la qualité du contexte. Un deuxième modèle sans accès au `CLAUDE.md` ni au tracker renverrait exactement les mêmes observations : des opinions génériques sur les "bonnes pratiques" disponibles dans n’importe quel manuel de programmation. **Classification en quatre niveaux de gravité.** Je suis parti initialement avec CRITIQUE/HIGH/MEDIUM/LOW, mais une fois le filtre coût/bénéfice activé, presque tout ce qui passe les filtres est classé MEDIUM ou HIGH. Les deux autres catégories deviennent obsolètes. Plus de taxonomie n’implique pas une meilleure priorisation. ## Le Conseil Jedi Et voici l’idée qui a tout changé. Il y a quelques semaines, j’ai écrit sur [l’invocation d’experts comme mentors](/fr/posts/invoquer-les-sages-mentorat-experts-llm/) — demander à un LLM d’adopter la perspective de Tufte, Munger ou autre. Cela a donné des résultats incroyables pour du design. Et si, au lieu de trois agents génériques (*réutilisation*, *qualité*, *efficacité*), je proposais trois agents avec **des noms connus, une philosophie spécifique et des règles de décision précises** ? L’idée porte un nom que tout fan de Star Wars reconnaît : le **Conseil Jedi**. Trois maîtres avec des perspectives distinctes évaluant le même cas. Mais attention — il ne s’agit pas que le LLM **imite** superficiellement leurs citations célèbres. Il s’agit que chaque "sage" applique **des règles de filtrage spécifiques** qu'un reviewer générique n’utiliserait pas. ### Les trois sages (et leurs valeurs) **Kent Beck — Simplicité.** *"Make it work, make it right, make it fast — dans cet ordre."* C’est celui qui vous dit "ces trois lignes dupliquées sont bien pour l’instant, inutile de refactorer maintenant". Sa règle clé : **la règle de trois**. Ne pas signaler une duplication tant que le même bloc n'est pas présent trois fois. Deux fois, c’est une coïncidence. Trois, c’est un motif. Et si la correction touche plus de fichiers que le code qu’elle modifie, elle ne vaut probablement pas le coup. Mais Beck ne se limite pas à la simplicité. Il cherche également les **bugs de correction** : cas où le choix évident a une sémantique incorrecte comparée à la version correcte. Ce `async` qui semble anodin mais hérite d'un contexte que vous ne voulez pas. Ce *par défaut* qui fonctionne en test mais explose en production. **Martin Fowler — Conception.** Les *code smells* sont des symptômes, pas des maladies. Le refactoring est une discipline, pas un passe-temps. Sa règle clé : **ne suggérer des refactorings que si un changement concret en bénéficiera**. *"Refactorer sans direction, c'est du tourisme dans le code."* Si une chaîne de caractères provient d'une API externe et est seulement lue, ne proposez pas de la transformer en enum. Si un champ est toujours synchronisé avec un autre par conception, la redondance est intentionnelle. **Mike Acton — Performance.** *"Le but de tout programme est de transformer des données d'une forme à une autre."* Si vous n’avez pas mesuré, vous n’avez pas de problème de performance — vous avez une opinion. Sa règle clé : **L’I/O est ce qui compte dans la plupart des applications**. Le CPU est rarement le goulot d’étranglement. Disque et réseau le sont souvent. ### Acton ne donne pas d’opinion, il mesure Voici où les choses deviennent intéressantes. Mike Acton ne s’arrête pas à l’analyse statique. Avant de formuler un jugement, il fait deux choses : **Recompte statique des I/O** : il examine le diff à la recherche d’opérations de lecture/écriture sur disque, réseau ou base de données. Il associe chaque opération à son contexte : se trouve-t-elle dans une boucle ? Dans un *hot path* ? Il génère un tableau de fréquences avant de donner son avis. **Profil réel** : si le diff touche du code critique (*hot path*) et que le projet peut être compilé, il exécute un profiler et condense les résultats. Si un *hotspot* est lié au code du diff, il le signale avec des chiffres, pas des opinions. Le tableau I/O inclut des estimations d’ordre de grandeur : lecture SSD ~0.5ms, écriture ~1ms, persistences ~2-5ms, réseau ~100-500ms. Ce n'est pas une précision absolue — c'est une détection des opérations dépassant les seuils admis. ## Le risque (et comment l’éviter) Avant que vous ne vous précipitiez pour créer un Conseil Jedi pour chaque *pull request*, parlons du point critique : **le LLM peut imiter superficiellement**. Il pourrait dire "comme dirait Kent Beck..." tout en réemballant des conseils génériques sous son nom. Pour éviter cela, les instructions ne disent pas "adopte la perspective de Kent Beck". Elles disent : *"applique la règle de trois : si une correction touche plus de fichiers que le code qu’elle modifie, rejette-la"*. Des règles concrètes, pas des caprices. De plus, chaque sage doit **conclure avec une section "Rejetés"** — observations qu'il a envisagées mais rejetées, avec les règles appliquées. Cela donne de la transparence sur le fait qu’il a activement filtré, et pas juste réduit le rapport. Si deux sages divergent sur le même code — Beck dit "ne pas toucher" et Fowler dit "refactoriser" — un agent modérateur est lancé pour examiner le cas et arriver à un consensus. Si aucun consensus n'émerge → rejet. Mieux vaut ne pas agir que mal agir. Est-ce équivalent à avoir Kent Beck en face de soi ? Évidemment non. Mais c'est infiniment mieux que trois agents génériques qui rapportent tout sans discernement. ## Le test : même diff, deux revues J’ai passé le même diff à `/simplify` et `/improve`. Même code, même projet, même session : | | /simplify | /improve | |--|-----------|----------| | Observations signalées | 8 | 5 | | *Faux positifs* | 3-4 | 0 | | Nouvelles détections | 0 | 1 (bug de concurrence, HAUT) | | Section "Rejetés" | Non | Oui, avec règles appliquées | | Contexte du projet | Non | CLAUDE.md + tracker + linters | La nouvelle observation que `/improve` a détectée, et que `/simplify` n’a pas : un bug de concurrence où le modèle apparemment correct héritait d’un contexte d’exécution incorrect, ce qui congelait l’interface utilisateur. En termes simples : le code semblait correct, compilait sans avertissement, mais bloquait le thread principal. `/simplify` ne l’avait pas détecté parce que ses agents génériques ne recherchent pas des bugs où le choix "évident" est mauvais. Kent Beck l’a identifié parce que sa mission inclut précisément ce travail. Les *faux positifs* de `/simplify` — le champ "redondant" de 8 octets, le modèle de concurrence déjà géré, les enums pour JSON externe — étaient absents dans `/improve`. Le filtre coût/bénéfice a exclu le premier. Le contexte du projet a éliminé le second. La règle de Fowler ("stringly-typed seulement si cela pose problème") a écarté le troisième. Ce qui m’a le plus convaincu : la section "Rejetés". Voir ce que chaque sage a considéré mais rejeté inspire beaucoup plus confiance que de voir uniquement ce qui a été signalé. **Vous savez qu’ils ont examiné plus que ce qu’ils ont déclaré.** ## Comment l'installer La fonctionnalité s’appelle `/improve` et se trouve dans `~/.claude/skills/improve/SKILL.md`. C’est une fonctionnalité globale de Claude Code — elle fonctionne sur tous vos projets. ```bash # Créez le répertoire mkdir -p ~/.claude/skills/improve # Copiez le fichier SKILL.md (ou écrivez le vôtre suivant la structure de skill de Claude Code) Utilisation : ...