Le premier m'a surpris par sa source. Anthropic elle-même a abandonné le RAG plus base vectorielle pour Claude Code, au profit de la recherche agentique — grep, ls, cat, en boucle, un peu comme un développeur explore un repo à la main. Boris Cherny, qui dirige Claude Code, l'a écrit noir sur blanc : les premières versions utilisaient RAG et une base vectorielle locale, "mais on a vite découvert que la recherche agentique fonctionne généralement mieux". Les raisons données ne sont pas cosmétiques : un index vectoriel devient obsolète dès que le code ou la doc bouge, la recherche sémantique retourne des "snippets similaires" là où il faut des références exactes, et la recherche agentique évite toute la complexité opérationnelle de maintenir un index à jour — plus simple, plus sûr aussi côté confidentialité. Fabio Akita est arrivé au même endroit par un chemin différent, en partant des capacités de contexte des modèles actuels plutôt que du choix d'architecture d'Anthropic : un bon grep plus une fenêtre de contexte généreuse bat, dans la plupart des cas, une pile RAG complète. Deux angles distincts, une même conclusion. La contrepartie honnête existe : mal cadrée, une recherche agentique peut explorer trop et consommer plus de tokens qu'un lookup vectoriel bien réglé — mais c'est un problème de cadrage, pas un argument pour revenir à la vectorisation par défaut.

Deuxième fil, plus terre-à-terre mais probablement le plus rentable des quatre : avant même de se poser la question du retrieval, convertir un document en markdown réduit sa taille en tokens de 65 à 90%, selon le format de départ. Un exemple parlant : un article de 500 mots pèse autour de 700 tokens une fois converti en markdown, et peut dépasser 8000 tokens dans son HTML brut d'origine — la faute aux balises, aux attributs, à tout ce qui sert l'affichage et rien à la compréhension. Les DOCX et les PDF texte tirent aussi leur épingle du jeu, dans des proportions un peu moindres. Des outils font ce travail sans qu'on ait à y penser : MarkItDown, l'outil open source de Microsoft — qui tourne en local, y compris comme serveur MCP directement dans Claude Code —, Pandoc, Marker. C'est le levier le plus simple à activer, et il agit avant même d'avoir choisi une stratégie de recherche.

Troisième fil : les graphes de connaissances façon GraphRAG, présentés comme l'étape d'après pour qui veut un vrai "cerveau" documentaire. Le coût d'indexation, historiquement, est aberrant — environ 1544$ par million de tokens pour construire un graphe complet, contre environ 1,45$ par million de tokens pour un RAG vectoriel classique, un facteur qui tourne autour de mille. Un cas concret, documenté sur le dépôt officiel de Microsoft GraphRAG : indexer un seul dossier juridique de 5 Go de texte revenait, avec GPT-4o-mini, à environ 33 000$. Une variante publiée par Microsoft Research fin 2024, LazyGraphRAG, a fait tomber ce coût au niveau d'un RAG vectoriel classique en repoussant l'essentiel du travail LLM au moment de la requête plutôt qu'à l'indexation — et cette baisse tient toujours en 2026, elle n'a rien d'un correctif ponctuel. Mais faire baisser le prix ne répond pas à la vraie question, celle qui a justifié tout un papier de recherche à elle seule en 2026 : un graphe ne vaut son coût que sur des questions vraiment transversales à tout un corpus — comparaisons, motifs qui traversent plusieurs documents — jamais sur du lookup simple, qui reste mon usage dominant. Et il garde un risque propre, symétrique à la vectorisation à l'aveugle : l'extraction du graphe se fait elle aussi par un LLM, qui peut très bien relier deux entités par une relation qui ne tient pas vraiment dans le texte source.

Le quatrième fil est celui qui m'a le plus servi à comprendre ce que je fais déjà sans le nommer ainsi : mon wiki personnel, à la Obsidian, n'est pas un GraphRAG déguisé, même si les deux finissent par produire un graphe qu'on peut visualiser. La mécanique est différente à la racine. Chaque nœud est un fichier markdown, chaque arête est un lien que j'écris moi-même, après avoir compris le contenu — pas un LLM qui infère une relation depuis un texte qu'il vient de lire une fois. Coût d'extraction nul, risque d'hallucination nul, parce que la compréhension précède le lien plutôt que l'inverse. Les plugins qui promettent de découvrir des liens "cachés" par embeddings, comme InfraNodus sur Obsidian, réintroduisent à mes yeux le même risque que GraphRAG, juste déplacé du serveur vers le plugin. Andrej Karpathy a formalisé cette approche en avril 2026, dans un texte qu'il présente explicitement comme une alternative à la vectorisation et au contexte long : une mémoire d'agent persistante sur disque, en markdown et wikilinks, chargée au fur et à mesure que l'agent navigue plutôt que toute entière en contexte. Une implémentation communautaire de ce patron tourne à 100% en local via Ollama — la preuve que ça ne suppose pas un modèle frontier, seulement un agent bien réglé pour savoir quel lien suivre et quand s'arrêter.

Un aparté qui n'est pas le sujet de ce billet, mais qui l'illustre bien : mon CV décrivait cette pratique comme "RAG (passif)". Un screening IA que j'ai fait tourner sur mon propre site — je raconte le protocole complet ici — a lu ce mot comme un aveu de faiblesse plutôt que comme de la précision honnête, et ça m'a coûté des points de score. J'avais choisi de garder le mot tel quel à l'époque, en toute connaissance de cause. Mais cette session de recherche m'a donné de quoi trancher autrement : "RAG (markdown-based)" décrit exactement la même pratique, sans ce risque de lecture, alors j'ai changé le mot sur mon CV. La pratique n'a pas bougé d'un pouce ; c'est le vocabulaire autour qui a vieilli plus vite qu'elle.

Ces quatre fils ne prouvent pas que le markdown gagne partout : la recherche agentique a ses limites de cadrage, LazyGraphRAG a sa place quand le corpus le justifie vraiment, InfraNodus rend un vrai service tant qu'on sait ce qu'il fait sous le capot. Ce qu'ils confirment, plus précisément, c'est que mon réflexe de data engineer — sortir l'info dans un format plus petit, curé à la main, versionnable — tient debout point par point, sur les quatre fils que j'ai vérifiés. Il reste, pour l'instant, le point de départ le plus rentable avant même de se demander si on a vraiment besoin de vectoriser quoi que ce soit.

Références

• Boris Cherny (X) — citation d'origine sur l'abandon de RAG + vector DB pour Claude Code
• Robert H. Eubanks — Anthropic Replaced Their RAG Pipeline with Agentic Search
• Fabio Akita — RAG is dead, long context wins
• MindStudio — How to Convert Files to Markdown to Reduce AI Token Usage by Up to 90%
• Microsoft — MarkItDown (dépôt officiel)
• GraphRAG vs Vector RAG: When the Knowledge Graph Pays for Itself — chiffres de coût d'indexation ($1544/M tokens vs $1,45/M tokens)
• Microsoft GraphRAG (discussion officielle) — le cas des 33 000$ pour indexer 5 Go de documents légaux
• Microsoft Research — LazyGraphRAG: Setting a new standard for quality and cost
• arXiv — When Is Graph Structure Worth Its Cost? The Case for Structure Pricing in Retrieval-Augmented Generation
• InfraNodus — Visualize Knowledge Graphs for Personal Knowledge Management
• Andrej Karpathy — LLM Wiki (gist d'origine, avril 2026)
• kytmanov/obsidian-llm-wiki-local — implémentation 100% locale via Ollama

J'avais déjà construit un skill agent-rh, nourri de ma propre veille, pour m'améliorer au fil du temps sur mon CV. Il a fini par pointer un vrai problème que je devais corriger : il donnait tout en synthèse en devinant ce que vient chercher la personne qui regarde mon CV — et ça, c'est impossible à deviner de façon fiable, puisque ça dépend entièrement de qui regarde et pourquoi. Alors j'ai testé autre chose : simuler un vrai outil de screening CV par IA, façon Greenhouse, Ashby ou Workday, directement sur mon site public, et regarder comment mon skill RH réagit à ce que cet outil produit — pas en lisant mon CV lui-même, en ne lisant que sa synthèse. Reproduire fidèlement ce qu'un recruteur humain ferait en 2026, pas ce que je voudrais qu'il fasse.

L'hypothèse tient debout : 87% des entreprises utilisent l'IA à un moment ou un autre de leur processus de recrutement, et le pipeline type ressemble à ceci — parsing du document, résumé ou score produit par un LLM, puis lecture humaine de ce résumé, la décision finale restant humaine. Ce que ça change concrètement, c'est qu'optimiser un CV pour un lecteur humain de trente secondes et l'optimiser pour un parseur IA ne sont pas tout à fait le même exercice. Parfois les deux se renforcent. Parfois ils s'opposent frontalement, comme on va le voir.

Le protocole que j'ai suivi : un agent générique fraîchement instancié, sans aucune mémoire de la conversation, qui lit uniquement ce qui est publié publiquement sur mon site — le CV, la page d'accueil, tous les billets du blog. Il produit un rapport structuré, exactement au format qu'un vrai outil de tri sortirait : un Fit Score chiffré et justifié, les compétences détectées en distinguant déclaratives (section Compétences) et inférées (citées seulement en prose dans une puce d'expérience), les points forts, les gaps, et une recommandation. Ce format n'est pas inventé : une compétence nommée dans une section dédiée et prouvée dans une puce d'expérience compte pour plus forte que l'une des deux prise seule — précisément ce que la fonctionnalité que je décris plus bas est venue corriger. Une fois ce rapport produit, je me mettais à la place du recruteur : je ne réagissais qu'à cette synthèse, jamais au CV brut. Cinq lectures ont été faites ainsi, sur cinq agents fraîchement instanciés, aucun ne se souvenant des passes précédentes.

Trois premières passes ont eu lieu au fil de mes corrections du CV, le même jour. Score de départ : 61 sur 100, avant toute section Compétences, sans ville ni région précisées, sans cloud provider nommé, sans orchestrateur cité. Après ajout d'une section Compétences, de Nantes, d'Azure et de GitLab CI/CD : 70 sur 100. Puis, après avoir supprimé un bloc "Stack technique" jugé redondant pour gagner en lisibilité : 63 sur 100 — alors que rien d'important n'avait disparu en substance, les mots-clés du bloc supprimé avaient été recopiés dans la section Compétences avant suppression.

Ce que la troisième passe a mis en évidence, c'est la vraie tension du billet. La règle "trois à cinq puces par poste, curées, pas une liste exhaustive" est une norme bien établie pour un CV lu par un humain pressé. Le problème, c'est qu'en simplifiant pour respecter cette règle, j'ai fait disparaître les puces de prose qui donnaient du contexte narratif à une dizaine de compétences listées par ailleurs dans la section Compétences — Docker, Kubernetes, TDD/DDD, Talend, Power BI. L'outil a signalé explicitement que ces tags "n'ont aucune trace dans les puces d'expérience" et a baissé sa confiance sur chacun d'eux pris individuellement. Un lecteur humain pressé, lui, préfère justement la version courte.

J'ai un principe qui s'oppose frontalement à cette lecture, et je le tiens : les compétences n'ont pas besoin d'avoir une ligne dans un contexte de synthèse, les mots sont une synthèse pour respecter les trente secondes — si les RH ont des questions, c'est à l'entretien qu'elles se posent. C'est un choix de design que je défends. Mais l'exercice montre concrètement qu'un lecteur IA ne sait pas "attendre l'entretien" — il note ce qu'il voit, au moment où il le voit. Ce n'est l'erreur de personne : deux lecteurs différents optimisent pour des choses différentes, et mon CV ne peut pas être parfaitement optimal pour les deux à la fois.

La question suivante m'intéressait plus encore : ce score est-il une propriété stable de mon CV, ou dépend-il de ce qu'on cherche ? J'ai rejoué la même lecture — même CV, même page d'accueil, même blog, rien n'a changé entre les trois — en ne faisant varier qu'un seul paramètre du prompt : le poste cible donné à l'agent. Trois formulations, trois scores très différents.

Vingt-trois points d'écart sur un document strictement identique, en changeant seulement la cible de recherche. La conclusion que je retiens de ce chiffre : le score d'un outil de screening n'est pas une propriété du CV, c'est une propriété de la rencontre entre le CV et une recherche précise. Je n'ai pas "un score", j'en ai autant que de recherches possibles. Et le matching par titre de poste littéral semble peser plus lourd que le matching sémantique sur les compétences réelles — le rapport lui-même le dit, à propos du score le plus bas : l'écart pourrait venir d'un problème de formulation du CV plutôt que d'un déficit de compétence réel, mais ce n'est pas vérifiable à la seule lecture.

J'ai voulu corriger ce que je pouvais corriger sans mentir sur rien : la tension "tags sans preuve narrative" repérée au round 1. Plutôt que de rajouter de la prose — ce qui aurait recréé le problème de longueur qui m'avait fait simplifier au départ — j'ai rendu le lien structurel. Chaque tag de la section Compétences est devenu un vrai lien HTML statique vers l'expérience précise où cette compétence a été utilisée, avec un survol qui surligne l'entrée visée sans jamais masquer le reste. J'ai rejoué les trois mêmes recherches sur des agents fraîchement instanciés, CV identique par ailleurs.

Le gain le plus net de toute la session : dix-sept points sur la recherche "développeur", exactement celle où le round 1 avait identifié le problème. Le rapport du round 2 l'écrit noir sur blanc à propos de TDD/DDD : liés à trois expériences distinctes, donc "traçables et non déclaratifs". Les deux autres scores, eux, ne bougent quasiment pas — logique, puisque les gaps qu'ils pointent (pas d'Airflow ni de dbt pour le poste Data Engineer, pas de LangChain ni de base vectorielle pour Context Engineer) sont des compétences réellement absentes. Aucun lien structurel ne peut les faire apparaître par magie. Le lien compétence-expérience aide à prouver une compétence déclarée, il n'en invente pas une manquante.

Ces gaps-là, d'ailleurs, je les laisse tels quels. LangChain, LlamaIndex, bases vectorielles, fine-tuning, MLOps : absents de mon CV, mais pas parce que je ne sais pas ce que c'est. Ce sont des outils connus, compris, mais non utilisés en entreprise — et je ne peux pas valoriser un outil que je n'ai pas pratiqué en contexte professionnel. Expliquer cette nuance-là (je connais, mais je n'ai pas appliqué en entreprise) prendrait encore des lignes sur un CV que je suis justement en train de condenser. L'outil de screening traite ces absences correctement comme un vrai gap de marché plutôt que comme une erreur de rédaction — ce qui me va très bien, parce que c'est exactement ce qu'ils sont.

Deux précisions de vocabulaire, faites pendant cette même session, illustrent bien le réflexe qui traverse tout ce billet : vérifier avant d'utiliser un terme qui sonne bien. J'ai remplacé "data ocean" par "hub-and-spoke" pour décrire mon architecture multi-usines centralisée — "hub-and-spoke" est le terme générique établi pour cette topologie. Un terme plus spécifique existe côté IIoT, "Unified Namespace", mais je l'ai écarté parce que la littérature l'associe à des protocoles OT précis, MQTT et Sparkplug B, pas à Kafka nativement : l'utiliser aurait sur-affirmé un outillage que je n'utilise pas. Deuxième correction, plus nuancée qu'un simple remplacement de mot : "Forward Deployed Engineering" pour mon titre de poste. Écrire du code de production, embarqué chez le client — ça, je le fais déjà, et ça reste ma feuille de route. Ce qui manque encore, c'est la partie la plus revendiquée du FDE version 2026 : piloter des agents IA directement en production chez le client. Je me concentre sur l'étape d'avant, celle qui doit exister avant qu'on puisse piloter des agents en production de façon fiable — construire la documentation, le "cerveau", le RAG, peu importe le mot exact. "Context Engineering", terme employé par Gartner qui déclarait mi-2025 que le prompt engineering était fini au profit du context engineering, avec une prédiction de présence dans 80% des outils IA d'ici 2028, nomme précisément l'étape où j'en suis réellement — pas la suivante, même si la suivante est le terme qui fait le plus de bruit en 2026. J'ai peut-être tort de rester aussi précis plutôt que d'anticiper, mais je saurai la défendre en entretien — et peut-être qu'un billet comme celui-ci donne à une IA qui résume un contexte qu'un simple mot-clé ne porte pas.

Il y a un point du round 2 que je n'ai pas corrigé, et que je ne corrigerai pas. Mon CV dit "RAG (passif)". Un des rapports lit ce qualificatif comme moi qui minimise ma propre compétence plutôt que comme de la précision honnête — et ça coûte des points de score. Je le garde quand même, en toute connaissance de cause :

"RAG c'est un mot-clé, qui dit RAG dit attente vector DB ou fine-tuning. Moi j'utilise un RAG passif, des informations bien rangées en Markdown pour l'IA — c'est passif et retouchable/versionnable facilement, et c'est bien l'intérêt. Le passage à la DB vectorielle peut avoir lieu comme produit à la fin, mais pas au début, où il faut d'abord l'auditer et l'améliorer. En 2026 on voudrait que je parle de fine-tuning et de vector DB, alors que j'ai fait mes recherches et j'estime que ce n'est pas le moment dans mes usages — qu'un RAG passif est plus pertinent que du bruit IA de métier. Mais l'analyse montre que 'RAG' seul passe comme mot-clé, et 'RAG (passif)' comme non compris, ce qui baisse la note. Je reste honnête, j'emploie les bons termes — ça montre bien un problème du CV 2026 : les humains (et les agents) attendent des mots précis, alors que la réflexion et l'usage pertinent d'un domaine en mutation sont invisibilisés parce qu'absents des recherches habituelles. Tant pis pour les points des agents — eux aussi biaisés — j'utilise ce qui me semble juste."

C'est probablement la meilleure illustration de toute cette session pour la thèse du billet. La tension entre précision honnête et optimisation de score n'est pas résolue en faveur du score. Je préfère perdre quelques points qu'employer un mot qui laisserait entendre une compétence que je n'ai pas jugée pertinente pour mon usage. Je sais ce qu'est une base vectorielle et comment elle fonctionne — le passage du RAG passif vers une version vectorielle est même une évolution prête à être déclenchée une fois la phase de validation actuelle terminée. Mais noter que je connais le concept sans l'avoir pratiqué en contexte professionnel demanderait encore une ligne de plus sur un CV déjà tiré au maximum vers la synthèse. Je ne mens pas en ne le notant pas ; je choisis juste où s'arrête la condensation.

Il restait une dernière chose à vérifier : comment l'outil de screening lit-il ce blog lui-même ? Deux réponses, et je n'avais anticipé qu'une des deux. La première : il note explicitement le blog comme une preuve de pratique IA "rare et inhabituellement transparente pour un CV candidat" — signal de crédibilité fort selon lui, cohérent avec le pipeline agentique qui produit ces billets. La seconde, que je n'avais pas vue venir : le volume de contenu, onze billets en une dizaine de jours, est signalé comme un "pattern de fréquence inhabituelle" qu'un outil orienté détection de contenu généré remarquerait — même en jugeant le contenu lui-même de bonne qualité. L'ironie ne m'a pas échappé : ce rythme de publication est rendu possible précisément par le pipeline que ce blog documente.

Une limite à assumer avant de refermer ce billet : un seul agent générique a servi de "faux outil de screening" pour les cinq passes. C'est une approximation raisonnable, calée sur de la recherche réelle plutôt qu'inventée, mais pas une reproduction fidèle d'un outil commercial comme Greenhouse ou Ashby — ces outils-là tournent sur des modèles et des pondérations calibrés sur des milliers de CV réels, avec une review humaine en boucle. Mon exercice donne une direction crédible, pas une mesure de laboratoire.

Ce que je retiens de toute cette session, c'est que le pari n'est pas résolu, et qu'il ne le sera probablement jamais complètement. Écrire pour un humain qui a trente secondes et écrire pour un robot qui scanne tout ne sont pas le même exercice — parfois ils tirent dans le même sens, parfois ils se contredisent, et dans ce cas-là je choisis la version honnête plutôt que la version qui score le mieux. Un CV n'a pas un score. Il en a autant que de personnes, humaines ou non, qui le lisent.

Références

• ATS Verification — AI resume screening in 2026 — le pipeline parsing / résumé-score par IA / lecture humaine finale.
• DemandSage — AI Recruitment Statistics — le chiffre de 87% des entreprises utilisant l'IA dans leur recrutement.
• ProfileOps — Skills Section Resume ATS — pourquoi une compétence nommée en section dédiée et prouvée dans une puce d'expérience est plus forte que l'une des deux seule.
• Extern — Resume Bullet Points Guide — la norme de trois à cinq puces curées par poste.
• HiveMQ — Unified Namespace (UNS) Essentials for IIoT — l'Unified Namespace comme architecture spécifiquement bâtie sur MQTT/Sparkplug B.
• Kai Waehner — Unified Namespace vs. Data Product in IT/OT for Industrial IoT
• TechCrunch — Forward Deployed Engineers are the AI industry's latest talent obsession — FDE comme modèle d'engagement, pas comme pratique technique IA.
• Atlan — What Is Context Engineering? — définition, et citation de Gartner ("context engineering is in, prompt engineering is out") avec la prédiction de présence dans 80% des outils IA d'ici 2028.

Le mécanisme est simple et documenté : chaque tour renvoie toute la conversation accumulée, donc même une question d'une ligne, posée dans une session ouverte depuis des heures, coûte le prix de tout l'historique qu'elle traîne avec elle. C'est explicitement listé, dans la documentation officielle de Claude Code, comme la première raison pour laquelle l'usage grimpe dans une longue session — et plus un projet a de matière à charger (agents, docs, conventions), plus cette mécanique joue vite.

Le pipeline construit la veille en est un bon exemple. `blog-curateur`, `blog-redacteur` et `blog-illustrateur` me font vraiment gagner du temps, mais c'est précisément le facteur de coût multi-agents que j'ai déjà chiffré : jusqu'à 15 fois plus de tokens qu'un chat simple, chez Anthropic comme chez moi. Un coût accepté en connaissance de cause en construisant ce pipeline, pas une surprise découverte en touchant le plafond.

Si ce projet était pour une entreprise, je crois que j'aurais été content de remplir un KPI de quantité — plus de contenu produit, plus d'agents qui tournent, ça se lit bien sur un dashboard. Ici, la mesure qui compte est différente : la qualité reste maîtrisée malgré la croissance du projet, et c'est la taille réelle du projet — plus d'agents, plus de documentation, plus de contexte à porter — qui explique la facture, pas une dérive de ce que je produis.

Ça ne veut pas dire que la croissance est gratuite. Le contexte qui grandit accumule aussi du bruit — le "context rot", documenté par une étude de Chroma menée en 2025 sur 18 modèles frontière, dont Claude Sonnet 4 et Opus 4 : la performance décline de façon continue et mesurable dès que le contexte grandit, bien avant d'atteindre la limite réelle de la fenêtre, et Claude montre l'écart le plus marqué de tous les modèles testés entre un prompt court et un prompt long. Le savoir vérifié qu'on accumule au fil d'une session — décisions tranchées, conventions établies — compte pour de vrai, mais il reste en concurrence directe avec ce bruit, pas à l'abri de lui.

Ça me donne une idée à tester : recompresser ma documentation et mes fichiers `.md` utiles, pour revenir à un usage tout aussi qualitatif mais qui fait redescendre la consommation de tokens. Pas fait pour l'instant, juste une piste qui devient de plus en plus concrète à mesure que le projet grossit — le plafond de session n'est sans doute que le premier signal d'un projet qui a changé d'échelle.

Références

• Documentation Claude Code — Manage costs effectively
• Chroma Research — Context Rot: How Increasing Input Tokens Impacts LLM Performance

Le matin, il y avait un curateur et un rédacteur tout juste esquissés, un seul fichier à sections pour tout suivre et aucune discipline de vérification des sources. Le soir, un pipeline à quatre étapes en dossiers numérotés — sujet à compléter, sujet prêt, brouillon, mise en page, chacun avec son dossier d'archive pour garder l'historique sans jamais l'effacer —, trois agents qui ne font chacun qu'une seule chose, une règle de vérification qui a déjà attrapé deux vraies erreurs de citation sur 29, et 8 billets en ligne sur le site. Ce n'est pas juste « plus de contenu » : c'est passé d'un brouillon d'outillage à un système que je peux faire tourner, mesurer, et corriger un maillon à la fois.

La chose qui m'a le plus surpris à la vivre : transformer une réflexion brute — les notes que j'accumule en discutant avec l'IA, souvent écrites vite — en un billet honnête, sourcé et illustré correctement, coûte beaucoup plus cher que d'écrire simplement ce que je pense. Le premier passage curateur + rédacteur sur 6 sujets m'a coûté 1,37$ mesurés (0,33$ pour le curateur, 1,04$ pour les six rédactions) — dérisoire en argent, mais ce chiffre cache des dizaines d'allers-retours d'agents, un audit qui a recalé 2 citations sur 29 (des pages réelles, qui ne disaient simplement pas ce qu'on leur faisait dire), et deux passes complètes d'illustration parce que la première ne suffisait pas. Écrire vite, c'est facile. Écrire quelque chose dont je peux défendre chaque affirmation, ça prend un temps que je n'avais pas anticipé — exactement la différence entre un billet de blog et un post LinkedIn.

Ce qui a le mieux marché : découpler curateur, rédacteur et illustrateur en trois rôles distincts, chacun avec son propre dossier de travail et son droit d'écriture strictement borné, plutôt qu'un seul agent généraliste qui ferait tout. Ça a rendu possible ce qu'un agent unique ne m'aurait pas permis facilement : mesurer le coût de chaque rôle séparément (le dashboard que j'avais déjà construit pour suivre mes coûts d'agents les distingue automatiquement, sans rien de nouveau à brancher), corriger un seul maillon — le jugement visuel de l'illustrateur — sans toucher aux deux autres, et faire confiance à un rôle précis pour une décision précise. Seul le curateur juge si un sujet est mûr ; le rédacteur ne discute pas cette décision, il l'applique.

Le choix qui me parle le plus, professionnellement : utiliser le système de fichiers lui-même comme file d'attente. Chaque dossier numéroté est un topic, chaque agent consomme dans un dossier et produit dans le suivant, et un dossier d'archive par étape garde l'historique sans jamais rien supprimer (ou alors c'est moi qui appliquerais une rétention plus tard pour purger) — exactement le réflexe que j'applique déjà au travail, de Kafka à Databricks, sans jamais écraser ce qui est passé. Le pattern existe ailleurs — maildir sous Unix, hot-folder/spool, l'architecture medallion bronze/silver/gold que je manipule tous les jours en data engineering — mais je ne l'avais jamais appliqué à mon propre outillage perso avant ce jour. Un des rares endroits où mon métier et mon usage perso de l'IA se répondent directement, sans effort de traduction entre les deux mondes.

Le vrai moment intéressant de la journée n'est pas venu d'une fonctionnalité qui marchait du premier coup, mais d'un raté. Le premier jet de schémas produits par l'illustrateur était propre techniquement — du CSS valide, des licences d'image vérifiées — mais pauvre : des oppositions à deux boîtes reliées par une flèche, qui ne faisaient que remettre en forme ce que la phrase d'à côté disait déjà. En comparant les six résultats côte à côte, mon jugement a été direct : ça habille, mais ça n'apporte rien — il manque du discernement sur quoi habiller. En creusant la cause, le problème est apparu : l'illustrateur ne regardait que le texte déjà compressé du billet pour décider quoi dessiner, jamais la matière plus riche des fichiers de réflexion d'origine. Il ne pouvait donc que reformuler en boîtes ce qui était déjà écrit, jamais l'enrichir. Une fois corrigé — obligation de relire les sources avant de dessiner, test explicite : « quelqu'un qui lit juste le paragraphe apprend-il vraiment plus en regardant ce schéma ? » — la deuxième passe a produit des structures à trois éléments ou plus, avec de vraies données chiffrées dedans plutôt qu'une reformulation vide. La leçon dépasse ce cas précis : un agent qui ne regarde que sa propre sortie compressée ne peut jamais l'enrichir, seulement la reformuler — et ça vaut probablement pour plus que des schémas.

Un deuxième détail, plus petit, m'a marqué pour une raison différente : c'est moi qui ai eu tort en premier. Pour illustrer une émotion — la confusion, le soulagement —, j'ai proposé Giphy par réflexe, c'est ce que j'utilise en conversation tous les jours. Sauf qu'en vérifiant avant d'écrire la règle plutôt qu'en la supposant, les conditions d'utilisation de Giphy comme de Tenor restreignent explicitement l'usage au cadre personnel et non commercial, et la plupart des GIFs de réaction sont de toute façon extraits de films ou de séries sans licence propre — un flou juridique connu, toléré par une norme culturelle de non-poursuite plutôt que couvert par un vrai droit d'usage. Remplacé par OpenMoji, un jeu d'emojis sous licence CC BY-SA 4.0 porté par une école de design allemande et ses contributeurs — moins « meme viral », mais aligné avec le niveau d'exigence que j'essaie d'appliquer partout ailleurs sur ce site. Ce qui compte ici, ce n'est pas la vérification en soi, c'est que je l'ai appliquée à ma propre suggestion, pas seulement à ce qu'une IA proposait.

La proposition évidente n'était pas la bonne — et c'est la mienne.

Au bout du compte, cette journée n'a pas prouvé qu'une IA peut écrire un blog toute seule — elle a plutôt confirmé le contraire. Ce qui rend un billet publiable, ce n'est pas l'autonomie des agents, c'est la discipline de vérification que j'y ai mise autour : lire les brouillons côte à côte, remettre en cause un schéma qui ne dit rien, vérifier une licence avant de l'écrire en dur dans un agent, refuser une source qui sonne juste mais ne dit pas ce qu'on lui fait dire. Le pipeline fait gagner du temps sur la mécanique — dossiers, déplacements de fichiers, mise en forme HTML. Il ne remplace à aucun moment le moment où je relis, où je doute, où je corrige. C'est probablement la seule vraie conclusion de ce bilan : plus le système qui écrit à ma place devient sophistiqué, plus mon propre rôle de relecture compte, pas moins.

Références

• GIPHY — User Terms of Service
• Tenor — Legal Terms
• OpenMoji
• Emoji "face with hand over mouth" : OpenMoji – the open-source emoji and icon project, licence CC BY-SA 4.0.

Le partage du travail n'a jamais été flou dans ma tête. Le lore, les dessins, la musique, les bruitages, le game design : entièrement nous, mon fils et moi. L'architecture du code et les choix techniques : décidés par moi. L'IA : elle exécute. Elle implémente ce que je lui demande, selon les directives que je pose — jamais l'inverse. Je n'ai jamais eu la tentation de lui faire générer le game design, le graphisme ou la musique. Ce n'est pas une question de principe abstrait, c'est que je n'en avais tout simplement pas envie : c'est la partie qui m'intéresse, et qui intéresse mon fils.

Le jeu est volontairement léger : un jeu dans le navigateur, sans installation, une expérience de 5 à 10 minutes. Ça limite ce qu'on peut implémenter — pas de moteur 3D, pas de gros calculs, pas de dépendance lourde. Mais ça permet à tous nos amis d'y jouer directement, sans se soucier de leur machine. C'est une contrainte assumée, pas une excuse : je préfère un petit jeu que tout le monde peut ouvrir à un gros jeu que personne n'installe.

Ce qui m'a frappé en le faisant, c'est que le résultat est plein de choses cassées. Pas cassées à cause du code — le code fonctionne, il fait ce qu'on lui a demandé. Cassées dans le fait main : une transition maladroite, un dessin d'enfant qui déborde du cadre qu'on lui a bricolé, un bruitage un peu trop fort par endroits. Et ces choses cassées, je les trouve belles. Si j'avais laissé faire — si j'avais demandé à l'IA de générer le design, les images, la musique en plus du code — ça aurait été standard, propre, cohérent. Ça aurait été du slop. Alors que là, ce qui est raté est raté d'une façon qui vient de nous, pas d'une moyenne statistique de ce qui marche bien.

Ça me ramène à une question que je n'ai pas tranchée : est-ce que c'est de l'IA, ou est-ce une œuvre ? Je n'ai pas de réponse propre et définitive. Ce que je sais, c'est que ce petit jeu montre quelque chose d'humain, manette en main — le lore de mon fils, mes choix de game design, nos maladresses assumées — et que le code généré n'est qu'un moyen d'y arriver, pas le contenu lui-même. Je ne sais pas si ça suffit à répondre à la question pour tout le monde. Pour ce projet-là, en tout cas, ça me suffit à moi.

Le jeu est jouable directement dans le navigateur, sans rien installer : mia.adventures.free.fr.

Première chose que j'ai vérifiée : la différence n'est pas une histoire de modèle. Les paliers d'abonnement Claude sont Pro à 20$, Max 5x à 100$, Max 20x à 200$ — et le plan Max ne débloque aucun modèle ni aucune fonctionnalité en plus de Pro. Uniquement plus de volume d'usage. Donc si mes amis payent dix fois plus pour un résultat qui semble similaire, l'explication la plus probable n'est pas qu'ils obtiennent mieux : c'est qu'ils consomment dix fois plus de tokens. Rassurant sur un point — je ne rate rien en restant à 20$, mon usage est juste structurellement différent.

D'où vient ce volume, en général ? Anthropic chiffre le coût de son propre système multi-agents : un agent seul consomme 4 fois plus de tokens qu'un simple chat, et un système multi-agents complet monte à 15 fois. Leur propre retour d'expérience est direct là-dessus : des équipes ont investi des mois dans des architectures multi-agents élaborées pour découvrir qu'un meilleur prompting sur un agent unique donnait des résultats équivalents. Leur règle : rester en agent unique quand la tâche tient dans une fenêtre de contexte, que les étapes sont séquentielles, que le workflow est assez déterministe pour être spécifié — ou que le budget est serré. Le multi-agent ne se justifie vraiment que pour éviter la pollution de contexte, pour des tâches réellement parallélisables, ou pour une spécialisation qui améliore le focus.

La phrase qui m'a le plus servi, face à la pression ambiante à parler d'agents plutôt que de scripts pour cocher des KPI : la plupart des tâches de code ont beaucoup moins de sous-tâches parallélisables que la recherche. Le cas d'usage qui justifie le facteur 15, chez Anthropic, c'est leur propre système de recherche interne — ça ne généralise pas à de l'ingénierie logicielle. Je navigue à vue sur cette pression, mon but reste juste de construire des choses solides, pas de faire de la politique interne — mais c'est un fait technique que je peux citer plutôt qu'une simple préférence.

Mon architecture perso, en comparaison, est délibérément étroite : des conversations ciblées, des sous-agents précis, l'humain qui valide avant que ça parte. Et il y a un mécanisme que je n'avais pas pleinement saisi avant de creuser : chaque sous-agent garde son propre cache de prompt. Reprendre un sous-agent déjà utilisé, dont le contexte a déjà été envoyé une fois, coûte le tarif du cache — bien moins cher. Un nouveau chat qui redécouvre tout depuis mes fichiers `.md` repaie le contexte plein à chaque fois. Ça change complètement la lecture de mon propre agent `architecte-agents` : ce n'est pas « un agent de plus qui coûte cher », c'est un raccourci de cache vers une synthèse déjà faite. Architecturalement, ça n'a rien à voir avec un essaim d'agents qui tournent en parallèle, même si les deux s'appellent « agent ».

Autre supposition que j'ai vérifiée plutôt que crue : je pensais qu'un sous-agent basculait automatiquement sur un modèle plus léger. Faux. Le champ `model:` d'un sous-agent vaut `inherit` par défaut — si je ne le précise pas, il tourne silencieusement sur le même modèle que la session principale. Un choix que je croyais faire, mais qui ne se faisait pas. Ça éclaire aussi, en creux, pourquoi Copilot — imposé sur une mission — part vite n'importe comment même en sélectionnant Sonnet comme modèle : le harnais (les outils, la gestion du contexte, la mémoire, l'orchestration) est un produit à part entière, indépendant du modèle branché dessus. Le lien avec le coût est direct : personnaliser cette couche-là, c'est exactement ce qui rend mon usage à 20$ tenable.

Tout ça restait une explication plausible, pas une preuve. Mon côté data engineer n'aime pas s'arrêter là, donc j'ai voulu mesurer mon propre usage plutôt que de me contenter d'une anecdote. J'ai installé `ccusage`, un outil qui reconstitue le coût équivalent tarif API à partir des journaux locaux de Claude Code.

Premier piège, découvert en générant le rapport : `ccusage` agrège par défaut tous les projets Claude Code de la machine, pas seulement celui en cours — aucun filtre par projet en ligne de commande, seulement par date ou par identifiant de session. Pour isoler le coût réel de ce repo, il a fallu croiser les identifiants de session avec les fichiers de journal propres à son dossier. Résultat : 77,61$ équivalent tarif API sur 6 sessions pour ce repo, contre 301,29$ tous projets confondus sur la même période. Un facteur 4 entre ce que je croyais mesurer et ce que je mesurais vraiment, si je n'avais pas vérifié.

Ce facteur 4, c'est tout le billet résumé en une ligne. Sans cette vérification, j'aurais cru un chiffre quatre fois trop élevé pour ce projet précis — exactement le genre de réflexe qui vient de mon métier : ne jamais faire confiance à un agrégat sans connaître précisément son périmètre.

Une mesure ponctuelle ne suffit pas, j'ai voulu pouvoir suivre ça dans la durée — donc j'ai construit un petit dashboard. Deux surprises techniques en chemin, pas prévues au départ. D'abord, un fichier Numbers n'est pas un format texte : c'est une archive zip de fichiers propriétaires, illisible et inéditable par un script. Direction CSV/JSON à la place. Ensuite, une limite plus fondamentale : une page ouverte en `file://` ne peut pas aller chercher un fichier JSON voisin — les navigateurs bloquent ça. C'est exactement pour cette raison que le reste de mes sites utilise un bouton « Importer » manuel plutôt qu'un chargement automatique : pas un choix arbitraire, une contrainte du navigateur. Solution retenue : générer le HTML avec les données embarquées dedans directement au moment de la construction — une commande, et la page est à jour, ouvrable en double-clic, sans serveur, sans dépendance, sans librairie de graphique.

En creusant ensuite le coût par sous-agent, je pensais avoir besoin d'une table de correspondance entre les noms utilisés par `ccusage` et les miens. En fait non : la colonne « Agent » de `ccusage` désigne l'outil en ligne de commande (Claude Code contre un autre), pas mes sous-agents — deux concepts homonymes sans rapport. Le vrai nom d'un sous-agent est écrit en clair ailleurs, dans les journaux bruts d'une session. En vérifiant le calcul à la main, j'ai trouvé un vrai piège de comptage : un message avec plusieurs blocs (du texte plus plusieurs appels d'outil) écrit une ligne de journal par bloc, en répétant le même identifiant de message et le même total cumulé à chaque fois. Sommer sans dédupliquer par cet identifiant fait presque doubler le total — vérifié sur une session précise, où 277 lignes avec des tokens ne correspondaient qu'à 133 messages réellement uniques. Une fois ce doublon corrigé et les tarifs publiés par Anthropic appliqués, mon calcul recoupait à environ 5% près le total donné par l'outil lui-même.

Je n'ai rien inventé dans la façon de présenter tout ça : la logique de dashboard suit un standard existant, FOCUS (FinOps Open Cost and Usage Specification), porté par la FinOps Foundation et étendu aux usages IA récemment. Coût dans le temps, coût par modèle, coût moyen par appel — les mêmes vues qu'on attendrait d'un dashboard de coûts cloud classique, appliquées à mon usage perso de Claude Code.

Alors, pourquoi je reste à 20$ pendant que d'autres montent à 200$ ? Pas par petit budget, et pas non plus par chance. Parce que mon usage — du human-in-the-loop par défaut, des sous-agents ciblés et réutilisés à chaud plutôt qu'un essaim parallèle — est structurellement plus économe, exactement dans le sens où Anthropic décrit son propre usage recommandé : un agent unique bien prompté pour l'essentiel, le multi-agent réservé à ce qui est vraiment parallélisable. Mes amis n'ont pas forcément tort : leur usage vise sans doute plus de structure, là où le mien répond juste au besoin du moment — et seul sur mon propre projet, en train de tester, la sur-ingénierie ne peut de toute façon pas s'appliquer. Mon but est un résultat pas cher, quitte à y passer plus de mon propre temps à la place. Mais « plus cher » ne veut pas dire « meilleur », et j'ai maintenant un chiffre pour l'affirmer plutôt qu'une impression.

Références

• Anthropic — How we built our multi-agent research system
• Building multi-agent systems: when and how to use them
• Documentation Claude Code — Sub-agents
• ccusage (dépôt GitHub)
• ccusage (registre npm)
• FOCUS — FinOps Open Cost and Usage Specification
• FinOps for AI: LLM cost tracking

Le problème, c'est que la vitesse de l'IA n'est pas le temps humain. J'ai l'impression de piloter une armée de développeurs qui alternent junior et expert d'une tâche à l'autre, qui suivent les instructions ou n'en font qu'à leur tête — comme des humains, mais cent fois plus vite. Rester au centre, à tout auditer, à tout voir passer, ça finit en épuisement pur. Et en même temps, je sens bien la transformation : pourquoi passer six mois à faire, imparfaitement, à la main, ce qu'une IA fait en une semaine ? Je ne l'ai pas tranché. Cette question-là reste ouverte, et ce billet ne prétend pas la fermer.

Ce qui m'a débloqué, en revanche, c'est de comprendre que ce sentiment d'épuisement n'était pas un manque de discipline de ma part. C'est un mécanisme connu, mesuré, et il a un nom.

Une étude du BCG a chiffré ce que je vivais sans le savoir : surveiller étroitement des agents IA est la forme d'engagement la plus coûteuse mentalement qu'ils aient mesurée — +14% d'effort mental, +12% de fatigue, +19% de surcharge d'information. Et le mécanisme derrière n'a rien de nouveau : il est documenté depuis la Seconde Guerre mondiale, dans une étude de Mackworth sur des opérateurs radar chargés de surveiller un écran en continu. Leur taux de détection chutait de 10 à 15% dès les trente premières minutes de surveillance, et continuait de se dégrader ensuite. Ça a un nom : le "vigilance decrement". Une attention humaine ne tient pas en continu, peu importe la volonté qu'on y met — ce n'est pas conçu pour ça.

Une phrase de cette recherche m'a particulièrement parlé : on ne soutient pas la vigilance par la volonté sur des centaines de répétitions par semaine ; on la soutient quand le système ne sollicite le jugement humain que lorsqu'il est réellement nécessaire. Ce n'est donc pas à moi de tenir plus longtemps. C'est le système autour de moi qui doit arrêter de me demander la même intensité d'attention sur tout, tout le temps.

En creusant, j'ai réalisé que je posais la question au mauvais niveau. "Human-in-the-loop ou on-the-loop pour ce projet" traite le projet comme une seule unité, qui devrait mériter un seul niveau de confiance du début à la fin. C'est probablement ça qui bloquait — pas le choix lui-même, la façon de le poser.

La réponse que j'ai trouvée dans la littérature, c'est l'échantillonnage pondéré par le risque. Pas aléatoire — un tirage au sort dilue trop les échecs rares, il faut cibler. L'idée est de stratifier par signal de risque : ce qui touche un accès réseau, des identifiants, un appel d'outil sensible mérite un examen serré ; une logique avec des branches et des boucles mérite un examen moyen ; le reste peut rester léger, voire passer sans relecture. Ça rejoint un principe que Claude Code applique déjà sur lui-même : agir librement sur ce qui est local et réversible, s'arrêter sur ce qui est difficile à annuler ou a un large rayon d'impact.

Ça se combine avec un cadre à trois niveaux que j'ai fini par adopter pour parler de ça plus précisément que "je surveille" ou "je ne surveille pas" : human-in-the-loop (une approbation avant que l'action s'exécute, pour le risque élevé), human-on-the-loop (l'action s'exécute seule, je surveille et je peux intervenir pendant ou après, pour le risque moyen quand la vitesse compte et que l'erreur est réversible), et fully autonomous (aucun point de contrôle humain). Le point important, c'est que ce niveau se choisit étape par étape dans un même flux de travail, pas une fois pour tout le projet. Le brainstorm reste pour moi du human-in-the-loop, c'est là que je porte la valeur ajoutée. L'exécution de tâches bornées et vérifiables individuellement, elle, tolère très bien du human-on-the-loop.

Ce qui m'a débloqué n'est donc pas plus de volonté ni une meilleure discipline de relecture. C'est d'arrêter de traiter "le projet" comme une seule tranche de confiance, et de le découper en tranches qui n'ont pas toutes besoin du même régime — décidé petit bout par petit bout, pas globalement en amont.

Reste une question que je n'ai pas résolue, et je préfère le dire plutôt que d'inventer une réponse propre : la littérature sur laquelle je m'appuie vient largement du monde devops et sécurité, où les signaux de risque sont assez évidents à nommer — accès réseau, identifiants, appels d'outils sensibles. Sur mon propre travail, en dehors de ce contexte-là, comment je définis concrètement mes propres strates de risque ? Je ne le sais pas encore précisément. C'est la prochaine chose à creuser.

Références

• The Decoder — Study warns of "AI brain fry" as workers hit cognitive limits overseeing AI agents (étude BCG / UC Riverside)
• Atomic Robot — AI review fatigue
• NHI Mastery Group — Why do random samples fail to give good AI agent eval coverage?
• Wikimedia Commons — Oscilloscope operators on an SCR 268 radar maintain watch near Menella, Italy, WWII (photo : National Museum of the U.S. Navy, domaine public)

En creusant, j'ai vu que d'autres personnes qui travaillent avec des agents construisent des "hooks" — des scripts qui s'exécutent à des moments précis du fonctionnement de l'agent. Ma première question était un peu bête, mais utile : c'est encore une contrainte de plus à écrire quelque part, ou c'est autre chose que des instructions ?

C'est autre chose, et comprendre pourquoi m'a fait revoir une intuition que j'avais depuis un moment. Je pensais qu'un fichier d'instructions bien écrit, avec les bons champs de permissions, suffisait à garantir un comportement. Ce n'est pas vrai. Tout ce qui passe par le contexte d'un agent — un CLAUDE.md, une liste d'outils autorisés donnée à un sous-agent — reste, au fond, une suggestion. Rien ne garantit qu'elle sera honorée à un tour donné, et plus la conversation s'allonge, plus l'attention du modèle dérive des instructions du début.

Les hooks, eux, ne passent pas par le modèle. Ce sont des commandes shell exécutées hors de lui, à des points fixes de son cycle de vie : avant qu'il appelle un outil, après, quand il reçoit un message, quand il termine sa réponse. Ils reçoivent du JSON en entrée — quel outil, quels paramètres — et répondent par un code de sortie. Code 2 : ça bloque, même si le modèle "voulait" continuer. C'est la première fois que je vois une couche qui ne demande pas l'avis du modèle pour agir.

J'ai voulu vérifier si cette logique tenait aussi pour les sous-agents, parce que j'en construis pour séparer des tâches — un agent RH, un agent sécurité, un agent SEO sur ce site. Ma question : si je restreins la liste d'outils d'un sous-agent — pas d'Edit, seulement Read et Grep — est-ce que ça garantit qu'il ne peut pas écrire ? Réponse : non. Deux bugs ouverts et documentés sur le dépôt officiel de Claude Code montrent des sous-agents contournant les règles de permission alors même que l'outil concerné n'était pas dans leur liste autorisée. Et même sans bug : un sous-agent qui a accès à Bash peut modifier un fichier avec un simple sed -i, sans jamais appeler l'outil "Edit" nommé comme tel. La restriction sur les outils nommés ne couvre pas ce qu'on peut faire à côté.

Ça m'a forcé à revoir ma façon de penser la sécurité de mes propres architectures d'agents. La vraie garantie, ce n'est pas un champ d'outils autorisés bien rempli, c'est un hook qui s'exécute avant le système de permission et qui peut bloquer un appel, quel que soit l'agent qui l'a fait, quel que soit le chemin pris pour y arriver. Une image qui m'a parlé, lue dans une discussion sur le sujet : une porte sans poignée, plutôt qu'une porte avec une pancarte "ne pas ouvrir".

Ce que je n'avais pas vu non plus : un hook n'a aucun accès à l'état interne du modèle. Il ne voit que des événements observables de l'extérieur. Ma règle de départ — demander si l'agent n'est pas sûr — n'est pas hookable telle quelle, parce que "le modèle n'était pas sûr" n'est pas une donnée qu'un hook peut lire. Ce n'est pas que je m'y prends mal, c'est hors de portée par construction. Ce qui devient hookable, c'est la version reformulée en condition observable : pas "demande si incertain", mais "bloque toute écriture tant qu'aucun appel à AskUserQuestion n'a eu lieu dans cette tâche". Présence ou absence d'un événement, ça, un hook sait le vérifier.

Autre angle mort découvert en creusant : je pensais qu'un agent principal "reprenait la main" si la réponse d'un sous-agent ne lui convenait pas. Faux, par défaut. Un sous-agent tourne dans son propre contexte isolé et ne retourne qu'une chaîne de résultat final au parent. Rien ne vérifie automatiquement que ce résultat est bon. Si je veux qu'une mauvaise réponse soit rattrapée, il faut construire l'étape de validation moi-même — ce n'est pas un réflexe intégré à l'outil, c'est un choix d'architecture à faire.

Ça éclaire aussi un truc qui m'agaçait sans que j'en comprenne la cause : chez le client, avec Copilot, même en sélectionnant Sonnet comme modèle, ça part parfois n'importe comment. Copilot n'a pas d'équivalent officiel de premier ordre pour les hooks — je n'ai pas trouvé de trace d'une couche déterministe comparable dans ses réglages. Ça veut dire que la seule main que j'y ai, c'est la couche instructions, probabiliste. Le modèle est le même que celui que j'utilise ailleurs, mais le harnais autour n'offre pas la même prise. Ça confirme une distinction que j'avais un peu ratée : le modèle et le harnais sont deux choses séparées, et une bonne partie de la fiabilité perçue d'un outil se joue dans le harnais, pas dans le modèle branché dessus.

Je ne tire pas de tout ça une promesse de contrôle total. Un hook n'a de prise que sur ce qui est observable et formulable en condition binaire — tout ce qui reste un jugement pur, "est-ce que c'était vraiment ambigu", aucun hook ne le fait à ma place. Ce n'est pas un trou dans les hooks, c'est la frontière naturelle entre ce qu'une couche déterministe peut garantir et ce qui reste mon rôle de relecture. Mais je sais maintenant où est cette frontière — et je ne demande plus poliment à un prompt de faire le travail d'une porte fermée à clé.

Références

• Claude Code — documentation des hooks
• Claude Code — documentation des settings (clé hooks)
• Claude Agent SDK — documentation des permissions
• Claude — annonce des sous-agents dans Claude Code
• Claude Code — issue #25000 : sous-agents contournant les règles de permission
• Claude Agent SDK (TypeScript) — issue #115 : Edit utilisé malgré une liste d'outils restreinte
• Nicolas Bustamante — sur la distinction modèle / harnais

Pour situer d'où je pars : j'ai décroché mon diplôme de développeur en 2019, à trente-six ans, au bout de six mois de formation intensive après une reconversion. Une conviction s'est installée tout de suite et ne m'a plus quitté : dans ce métier, la veille n'est pas optionnelle. Le secteur bouge trop vite pour se permettre de ne pas regarder ce qui arrive. À l'époque, le machine learning et le big data se structuraient sérieusement — je construisais de l'infrastructure data sans savoir précisément ce qui allait couler dedans un jour.

Puis ChatGPT est arrivé, fin 2022. Bluffant, vraiment. Mais un moteur probabiliste reste un moteur probabiliste : il prédit le mot le plus vraisemblable, pas le plus vrai, et il hallucine avec la même aisance qu'il répond juste. Je m'en servais sur des choses à faible enjeu — reformuler, expliquer un concept flou, dégrossir un bout de code que j'allais de toute façon relire en entier. Un brouillon, pas un collaborateur.

Ce qui a changé la donne, c'est la cadence des versions suivantes. GPT-4, Claude, Gemini : les hallucinations se sont faites plus rares, plus détectables. Et surtout sont arrivés les agents dans l'IDE — Copilot d'abord, puis Cursor, puis Claude Code. On apprenait à donner le bon contexte, à formuler la contrainte précise, à corriger quand l'agent partait dans la mauvaise direction. Un dialogue, pas une commande. Les MCP et les premiers skills, je les regardais déjà passer dans ma veille à cette période — prometteurs sur le papier, encore instables en pratique. Je les ai laissés de côté, sans les adopter.

Et puis le projet chez le client a pris de l'ampleur. Ce qui tenait sur une poignée de services est devenu, produit après produit, usine après usine, plus d'une centaine de dépôts git à maintenir. Chaque site industriel apportait ses propres conventions, ses propres exceptions. Documenter, tracer les changements, comprendre pourquoi telle règle avait été codée ainsi six semaines plus tôt : ça tenait, mais ça commençait à ressembler à tenir un mur qui pousse, sans pouvoir lâcher les mains pour voir à quoi il ressemble vraiment.

Le déclic, ce n'est pas un nouvel outil ni une nouvelle version de modèle. C'est une bascule dans la façon d'aborder la question. Avant, je posais le sujet par l'outil : quel agent, quelle intégration. Ce jour-là, en pleine migration, je l'ai posé par l'intention : qu'est-ce que je veux que l'IA comprenne, et comment le lui dire une bonne fois pour toutes ? Premier test, très simple : demander à l'agent de m'aider à écrire son propre fichier d'instructions. Et là, quelque chose a changé — l'IA n'était plus générique, elle répondait dans mon contexte, avec mes noms de choses, en respectant les contraintes que j'avais posées.

Le deuxième pas est venu du projet lui-même. On utilisait Databricks Genie, un assistant conversationnel sur les données — puissant, mais sans direction s'il n'a pas de contexte métier. J'ai essayé de lui injecter une compréhension du terrain : premier essai, une rétro-documentation générée entièrement par l'IA, juste sur le fond mais consommatrice de tokens de façon déraisonnable et pratiquement inmaintenable. Ce n'était pas la bonne architecture. Épurée, réinjectée en version courte et structurée, ça a marché — j'avais mis un vrai "cerveau" métier dans l'outil, capable de comprendre les questions dans notre vocabulaire. Je ne le savais pas encore, mais je venais de redécouvrir tout seul, à la dure, ce que la littérature appelle le pattern Memory Bank : la documentation devient un sous-produit de la mémoire du projet, pas un effort séparé.

De là, un principe s'est imposé, qui allait tenir pour tout le reste : un skill, c'est une intention formulée pour l'agent. Un script, c'est la logique déterministe qui ne doit pas halluciner. Un template, c'est le cadre dans lequel l'IA ne remplit que ce qui a vraiment besoin de langage naturel. L'IA comble les trous, elle ne pilote pas la logique. Empilé avec un workspace qui centralise les instructions et les skills pour l'ensemble des dépôts du projet, ça donnait quelque chose de sobre en tokens et de maintenable — moins d'hallucinations parce que la logique n'est pas déléguée, plus de maintenance parce que les scripts sont testables indépendamment de l'IA.

Je le dis franchement parce que le sens du récit compte : tout ça est né et a été validé en conditions réelles chez le client, sous contrainte, pas dans un coin tranquille de mon temps perso. C'est seulement après, ici, dans mes projets à moi, que j'ai pris le temps de ranger, de nommer, de généraliser ce qui avait marché — reconnaître que mon triptyque de travail recoupe une méthode déjà documentée ailleurs, formaliser l'idée qu'un hook déterministe vaut plus qu'une instruction qu'on espère suivie, tenir un vrai journal de décisions, graduer les niveaux d'autonomie plutôt que de tout traiter pareil. Cette formalisation, faite à froid en perso, est aujourd'hui réapplicable chez le client, en mieux outillée qu'à l'origine. Le sens du mouvement, c'est bien déclic et validation chez le client, puis formalisation en perso — pas l'inverse.

Il y a un point que je trouve important à assumer, plutôt qu'à enjoliver : ma reconversion à trente-six ans, avec six mois de formation intensive, ne m'a pas donné des années d'exécution manuelle. Elle m'a donné les concepts, les patterns, la façon de penser en systèmes. Et c'est très exactement ça qui permet de bien piloter une IA aujourd'hui — pas l'inverse. Il y a des choses que j'aurais mis des semaines à écrire seul, que j'ai construites en deux jours avec l'agent. Pas parce qu'il a pensé à ma place, mais parce qu'il a exécuté vite ce que je savais déjà penser.

Un doute qui ne se referme jamais tout à fait.

Ça n'a pas été que du soulagement. Distinct de la fatigue de tout vérifier, un risque s'est nommé de lui-même pendant cette période : le vrai risque n'est pas que l'IA prenne notre place, c'est qu'on la laisse prendre notre curiosité. Si tout ce qui demandait de l'effort devient facile, la question de savoir si on continue vraiment à développer ses réflexes d'ingénieur, ou si on les laisse s'atrophier derrière des workflows qu'on ne comprend plus tout à fait de l'intérieur, mérite d'être posée souvent — je n'ai pas de réponse définitive, juste l'habitude de me la reposer.

Ce que je retiens, c'est que le déclic n'a rien de romantique. Il n'a pas eu lieu parce que j'avais anticipé une tendance depuis mon canapé — il a eu lieu parce qu'il fallait débloquer un vrai mur, avec de vraies conséquences si ça ne marchait pas. C'est justement ce qui le rend crédible : ce n'est pas une théorie que j'aurais lue et recopiée, c'est une méthode que j'ai payée en dette de tokens avant de savoir la nommer.

Références

• hudrazine/claude-code-memory-bank — le pattern Memory Bank porté à Claude Code, que je découvre après coup avoir réinventé à la dure chez le client.
• Cline — Memory Bank: How to Make Cline an AI Agent That Never Forgets, l'article qui a popularisé le pattern.
• Mintlify — What is llms.txt?, le standard émergent pour exposer une doc curée à des agents IA.
• Emoji "thinking face" : OpenMoji – the open-source emoji and icon project, licence CC BY-SA 4.0.

Le problème de départ était simple à énoncer et pas si simple à résoudre : le site a quatre parties — CV, musique, jeux vidéo, blog — et je voulais qu'on sente qu'on change d'univers en passant de l'une à l'autre, sans que ça devienne quatre sites différents recollés ensemble.

J'ai commencé par le socle, avant même de penser identité par section : le dark mode. Le réflexe facile, c'est de partir sur du noir pur et du blanc pur, et ça donne un résultat qui fatigue les yeux et qui, sur les écrans OLED, finit par marquer l'écran à l'usage (smearing). La recherche 2026 sur le sujet est unanime là-dessus : un gris très sombre plutôt qu'un noir franc (j'ai retenu #121212), un blanc cassé plutôt qu'un blanc pur pour le texte, et pas plus d'un ou deux accents de couleur, désaturés à 70-80 % — en dark mode, chaque couleur pèse visuellement plus lourd qu'en fond clair, donc mieux vaut en mettre moins. J'ai aussi veillé au contraste minimum recommandé (WCAG AA, grosso modo 4,5:1 pour du texte normal), pas pour cocher une case d'accessibilité qu'on m'aurait imposée, mais parce qu'un site illisible n'a aucun intérêt à exister.

Sur la matière, j'avais trois directions possibles. La première, celle que j'ai gardée : un "verre sombre feutré" — fond très sombre, une lueur diffuse en arrière-plan (un halo bleu très désaturé qui dérive lentement), des cartes en verre dépoli (l'effet backdrop-filter: blur(), qu'on appelle glassmorphism), un seul accent bleu, des titres légèrement plus lourds en dark mode parce qu'un texte fin devient vite difficile à lire sur fond sombre. C'est la direction la plus proche de ce qui ressort des tendances 2026, et elle collait avec ce qui existait déjà dans le repo (le dark mode était déjà géré via prefers-color-scheme). Le glassmorphism, en particulier, est passé de gadget à langage de design qui a fait ses preuves — et il se fait entièrement en CSS natif, sans librairie.

J'avais deux autres pistes, écartées mais gardées en tête pour plus tard. Un "terminal chaleureux" : touches monospace sur les labels et les dates pour signer visuellement le développeur, un accent chaud (ambre, orange désaturé — plus proche de l'univers musique que le bleu "tech"), une légère texture de grille en fond façon circuit imprimé. Plus marqué, plus risqué si mal dosé, je l'ai mis de côté. Et un "minimal éditorial" : beaucoup de blanc, des titres en serif système (pas de police distante — ui-serif/Georgia suffisent), l'accent réservé aux liens, quasiment plus de cartes, juste des séparateurs fins. Cette direction-là convient à un site pensé comme un essai ou un blog plutôt qu'une vitrine de compétences — elle reprendra peut-être du sens si le blog devient un jour la partie dominante du site. Pour l'instant, j'ai gardé le verre sombre comme base commune.

Vient ensuite la question de l'identité par section, qui était le vrai sujet : comment donner à chaque partie sa propre couleur sans que ça se transforme en quatre chartes graphiques différentes. La recherche sur les systèmes multi-marques est claire là-dessus, et c'est un pattern qui existe depuis longtemps dans le design de marque (le "wayfinding") : on garde fixes la typographie, la grille, les rayons de coin, les ombres, le rythme d'espacement — et on ne fait varier que la couleur (parfois une légère variation de forme) d'une sous-identité à l'autre. C'est ce qui permet à quelqu'un de reconnaître "même système" tout en sentant "univers différent" en changeant de page.

Techniquement, ça tombait bien : le site utilisait déjà des variables CSS centralisées (--accent, --accent-2, --bg-glow...). Il suffisait de les redéfinir dans un petit fichier theme.css propre à chaque section, sans jamais toucher aux règles de composants elles-mêmes (les cartes, la timeline, les boutons restent identiques partout). Une couleur qui change, une structure qui ne bouge pas.

La palette, section par section : le CV reste neutre, en bleu et orange — c'est la base du site, celle qui donne le ton, donc je ne voulais rien y bousculer. La musique passe en violet profond et or champagne, une ambiance sombre et un peu classe, cohérente avec ce que je fais musicalement. Les jeux vidéo basculent sur du corail et du turquoise, des coins plus arrondis, des micro-interactions un peu plus "rebondissantes" au survol — volontairement enfantin, à l'image du projet fait avec mon fils. Le blog, enfin, change complètement de registre : fond crème chaud plutôt que le bleu-gris froid des autres pages, encre presque noire, un accent terracotta/rouille, des titres en serif système. L'idée, c'est un effet "journal papier" — des cartes moins "verre", moins de flou, pour que ça se lise comme du texte d'abord, pas comme une interface.

Sur la page d'accueil, chaque tuile reprend un avant-goût de la couleur de sa section — une barre, une teinte d'icône — pour que cliquer dessus donne déjà l'impression d'entrer dans un autre univers avant même que la page ne charge.

Ce n'est pas figé pour toujours. Si le blog venait à devenir la partie centrale du site plutôt qu'une des quatre briques, je referais sans doute le point sur la direction "minimal éditorial" mise de côté. Et je n'ai pas de subagent dédié au design pour l'instant — cette recherche, je l'ai faite une fois, ponctuellement, avec l'agent principal. Si les demandes de retouche esthétique deviennent récurrentes, ça rejoindra sans doute la même logique que mes agents RH ou SEO : un spécialiste de plus, appelé quand il faut.

Références

• Envato Elements — Portfolio design trends 2026
• Tech-RZ — Dark mode design best practices in 2026
• Nate Bal — Best practices for dark mode
• ColorPickerCode — Best website color palettes 2026
• Mathis Biabiany — portfolio de creative technologist
• Christopher Arold — Multi-brand design system
• Robert Celt — Theming architecture: multi-brand design systems that actually work
• Design Systems Collective — The multi-brand design system playbook

Ça m'a ramené loin en arrière. Mes premiers sites, je les faisais avec l'outil de création de site d'Apple, en gérant le FTP chez Free. Je n'étais pas développeur, mais j'arrivais bon an mal an à faire ce que je voulais — même si le résultat n'était pas toujours des plus pertinent. Plus tard, en formation à l'ENI, j'ai découvert WordPress (que je ne connaissais que de nom) et fait du PHP avec Symfony. J'ai gardé ça en tête depuis : un jour, je referais des sites.

Devenu développeur, j'ai fini par délaisser les interfaces graphiques pour mieux gérer le versionning. Les plateformes WordPress, où on accède à l'admin en quelques secondes, c'est pratique à l'usage — la sécurité y est in fine correctement gérée dans le fonctionnement du CMS, mais c'est un point sur lequel il faut rester vigilant en permanence. Pareil pour les bases de données, pratiques pour l'autogénération de contenu. Je préfère consacrer mon énergie au fond et à la forme plutôt qu'à une veille sécurité supplémentaire, en plus de celle que je fais déjà tous les jours pour mon travail. En prenant la main avec les IA, je me suis dit que faire des sites statiques — sans interface, sans DB, sans rien qu'un contenu visible — était bien mieux : le framework devient des agents qui construisent un contenu statique cohérent, facilement modifiable, et l'approche agentique me permet de vérifier chaque diff git de fichier .md ou de page HTML pour m'assurer que tout est bon.

D'où ce site : un mini portfolio pour parler de moi et poser ma présence en ligne telle que je l'entends — une partie musique, une partie plus CV, une partie jeu vidéo, une partie blog avec du contenu RSS. C'est simple, je maîtrise ce que je veux. Je ne cherche pas à le monétiser ni à faire de la pub, ça existe déjà ailleurs. Que ce soit des IA ou des connaissances, ils trouveront ce qu'ils veulent y voir et en feront ce qu'ils veulent. Pas besoin de commentaires ni d'algo pour me montrer.

J'ai suivi la logique de certains principes IA qui fonctionnent chez moi, et que les personnes que je forme sur le sujet apprécient. J'ai fait mon petit dossier sur mon Mac, ouvert dans VS Code, et commencé à préparer Claude à une architecture où tous les fichiers .md vivent dans le repo — puis j'ai transformé le dossier en dépôt git, et c'est parti.

Première phase : le brainstorm. Une journée entière à mettre à plat mes idées, du brut, avec l'IA qui pose une question dès qu'elle a un doute sur ce que je dis — paramétré par moi dans le fichier d'instructions. J'ai vu le brainstorm se structurer et grandir tout seul. Un autre point que j'ai bien aimé : à un moment, faire des agents spécialisés — une personne RH pour m'aider à préparer ma partie CV, un spécialiste SEO pour les balises et la qualité HTML, un spécialiste sécurité pour vérifier que je n'utilise pas de JavaScript limite ou que je n'expose pas une donnée meta non voulue.

J'ai construit le site sans domaine ni hébergement, en local, avec le chat en mode agent qui construit. Je vérifiais étape après étape, commit après commit, avec de la recherche web pour que mes agents récupèrent de l'info fraîche dans leur petit cerveau de contexte. J'avançais, je les questionnais sur la qualité du site, je corrigeais, je m'améliorais, j'apprenais des choses au passage.

Puis est venu le moment de me lancer : domaine et hébergement. J'ai choisi Infomaniak, par alignement idéologique et parce qu'ils sont européens. Même en connaissant les termes et le fonctionnement du net, j'ai un peu galéré — mais aidé par la recherche IA, j'ai réussi à suivre les interfaces, à m'y retrouver, à faire la sécurité, les comptes utilisateurs, tous différents et bien chiffrés, sans jamais les donner à Claude.

Et me voilà avec un site à mon nom qui suit ma logique, avec quelques conseils d'agents spécialisés sur mes points faibles. Des scripts pour déployer, des scripts pour la maintenance. Ça fait vingt ans que je voulais faire ça, et je suis content que ça existe. Le faire en deux jours avec l'IA, c'est fou — ça confirme mes choix agentiques.

Deux choses avaient pourtant déjà commencé à faire le lien sans que je le contrôle : mon statut de membre de la SACEM, qui me rend traçable en tant que musicien, et LinkedIn, qui remontait déjà mon nom si on me cherchait en ligne.

Avec l'arrivée de l'IA et la puissance actuelle du croisement de données, je me suis rendu compte que ce que j'avais séparé était redevenu, de fait, de plus en plus uni. Plutôt que de laisser ce lien se faire tout seul, sans que je le maîtrise, j'ai décidé de construire un site qui montre tout, comme un portfolio.

En creusant, je me suis aussi rendu compte que la séparation que je m'imposais n'avait jamais vraiment existé dans les faits : la musique et mes emplois ont toujours été extrêmement liés dans mes choix. Mon poste chez Algam, mon poste dans le recyclage — les deux me sont venus par mon réseau musical, pas malgré lui.

Si faire du metal pouvait rebuter des employeurs en 2000, je pense — et j'espère — que ce n'est plus le cas en 2026. J'espère qu'on peut aujourd'hui voir ce que ça apporte réellement à mon profil : gérer un groupe, une tournée, un collectif, c'est déjà de la gestion de projet et du management d'équipe.

Ce site, c'est ça : arrêter de subir la porosité entre mes deux vies, et la raconter moi-même.