thekb.eu — Agents de codage IA & Skills

When code is abundant

Mon, 24 Aug 2026 00:00:00 GMT

Bill Staples, directeur général de GitLab, publie le 24 août 2026 un essai qui prolonge un mémo écrit à son conseil en janvier et une première publication en mai, *GitLab Act 2*. Le déclencheur explicite est le playbook AI-native SDLC d'Anthropic, paru le 21 août, dont il reprend l'affirmation liminaire : le code n'est plus le goulot. Sa question porte un cran plus loin : si produire du code cesse d'être la contrainte, qu'est-ce qui devient rare, et quelle architecture une entreprise doit-elle avoir quand humains, agents et modèles multiples agissent simultanément à vitesse machine. Sa réponse tient en une phrase : quand l'implémentation devient abondante, c'est la confiance qui devient rare. Pendant soixante ans, l'ingénierie logicielle s'est organisée autour d'un fait — le code est précieux — dont descendent la préservation du legacy, l'optimisation de la productivité développeur et la cérémonie de revues, d'approbations et de portes de release. Cette contrainte se déplace, et le système bâti autour d'elle suivra. L'unité économique qu'il propose n'est pas le coût par ligne mais le coût par changement accepté, qui agrège génération, environnement, contexte, vérification, revue, remédiation et gouvernance. L'IA effondre le terme de génération et rend les autres proportionnellement décisifs : une organisation dix fois plus rapide à générer sans toucher au reste déplace simplement la file d'attente. C'est la théorie des contraintes, citée nommément. Les expériences de Stripe, Spotify et Amplitude servent de matériau. Elles montrent surtout où les contraintes suivantes réapparaissent : environnement, CI, revue et gouvernance. Une pipeline de trente minutes, écrit-il, défait n'importe quel modèle. Suit une architecture : trois modes de développement coexistants plutôt qu'une courbe de maturité unique ; la boucle interne qui migre du poste de travail vers le pipeline, plus proche du dépôt et productrice de preuves ; l'autonomie qui se gouverne au lieu de s'octroyer, par gates déterministes, isolation, politique et évidence. La thèse d'éditeur est ensuite posée : le modèle est un composant d'exécution remplaçable, pas l'architecture durable. Contexte, identité, politique, provenance et mémoire organisationnelle doivent persister à travers les modèles et les agents, ce qui pousse vers un plan de contrôle neutre en modèle et en cloud. Le texte distingue le fichier Markdown de l'enregistrement gouvernable, plaide pour que l'agent appartienne au client, décrit un PDLC où le signal métier devient logiciel vérifié, et voit s'élargir la population des *Builders*. Le jugement humain, lui, ne devient pas abondant : il remonte vers l'intention, l'architecture et les exceptions.

The AI-Native SDLC playbook: How to transform your software development lifecycle with AI—stage by stage

Fri, 21 Aug 2026 00:00:00 GMT

Louis Claxton, de l'équipe Applied AI d'Anthropic, publie le 21 août 2026 un guide de mise en œuvre d'un cycle de vie logiciel « AI-native ». Le point de départ est un déséquilibre : les organisations écrivent désormais du code à une vitesse inconcevable un an plus tôt, mais les processus qui l'entourent — portes d'approbation, revues, passations, politiques — n'ont pas bougé. Le SDLC traditionnel a été conçu pour un monde où l'écriture du code était l'étape la plus longue et la plus coûteuse ; ses contrôles supposent en outre que chaque geste est posé par un humain. Trois conséquences en découlent. Le goulot se déplace vers les étapes qui tournent encore à vitesse humaine, de part et d'autre du build. Les contrôles cessent d'être applicables : relire chaque ligne avait un sens quand une personne l'avait écrite. Et le coût de gouvernance augmente, les exceptions passant par des comités périodiques. La réponse conserve les objectifs de contrôle et change le mode d'exécution. Le processus devient une boucle, avec l'IA embarquée en chaque point, organisée en six étapes — Plan, Design, Build, Test, Deploy, Maintain — décomposées en *plays* suivant tous la même grille, jusqu'à la mesure. Le fil conducteur est l'artefact committé. L'intention est captée par son auteur d'origine comme `intent.md` ; exigences et design fusionnent en une session produisant `spec.md`, contrainte par les skills de marque, sécurité, conformité et UX ; le build démarre en plan mode et fige `plan.md` avant toute écriture de code. La chaîne de commits tient lieu de piste d'audit. Le savoir institutionnel devient des fichiers versionnés : `CLAUDE.md` pour le contexte du dépôt, les skills pour les politiques transverses, `REVIEW.md` pour la doctrine de revue, `bands.yaml` pour les seuils de production. La gouvernance se scinde en deux couches, la skill étant un contrôle consultatif et le hook la couche déterministe qui bloque ou demande une approbation. Un exemple de *managed settings* détaille clé par clé ce que chaque réglage achète en contrôle, du refus de lecture des secrets à la version plancher imposée. L'étape Maintain ferme la boucle : un script déterministe surveille une métrique, et le franchissement d'une bande invoque Claude sans humain dans le chemin d'appel, à une autonomie fonction du palier. Ce que l'agent trouve est réécrit en `intent.md` et repart dans le cycle. Claude Tag, en bêta publique sur Slack, étend le schéma aux incidents arrivant par messagerie. Aucun résultat chiffré n'est avancé : le guide livre des indicateurs à mesurer et nomme leur source.

The Claude Code guide for startups

Thu, 20 Aug 2026 00:00:00 GMT

Michael Segner publie le 20 août 2026 sur le blog claude.com un guide tiré d'entretiens avec plus d'une douzaine de jeunes pousses en croissance rapide, quinze étant nommées, sur la manière dont elles utilisent Claude Code. Le document en extrait cinq règles d'exploitation et se termine par une checklist des conseils techniques. Première règle, « tout le monde livre » : le codage agentique abaisse la barrière d'entrée, si bien que la personne qui comprend le problème peut livrer la première version du correctif. Parahelp rapporte des contributions d'employés non techniques, Crosby des juristes qui portent les meilleures intuitions produit, Heidi la disparition d'un effet de téléphone arabe où l'idée se dégradait en passant du porteur au chef de produit puis au designer puis à l'ingénieur. Le guide restreint aussitôt la portée : la division du travail demeure, seul le passage de zéro à un s'ouvre. Trois mécanismes le rendent systémique — brancher l'outil sur les sources de vérité par MCP ou par CLI, ritualiser la présentation des prototypes, partager des skills. Deuxième règle, automatiser le fastidieux : les agents prennent les quatre-vingts pour cent mécaniques du cycle et les ingénieurs gardent les cas de jugement. ClickHouse dit avoir transformé presque chaque étape en boucle autonome, deux agents à but unique étant devenus les deuxième et troisième contributeurs de son dépôt. Chez Anthropic, Claude Tag sert de premier répondant d'astreinte sur les échecs d'intégration continue. Troisième règle, faire confiance mais vérifier : on n'automatise pas un processus sans moyen fiable de le contrôler. Cainex, sur le codage médical, décrit une boucle d'auto-amélioration où les corrections d'auditeurs remontent jusqu'aux instructions de l'agent, testées contre un golden set, sous une règle unique — corriger le principe, pas l'exemple. Zingage raconte avoir donné trop d'autonomie au départ, obtenu du code plausible mais dérivant de son architecture, puis écrit ses invariants. Le guide renvoie aux hooks pour les portes déterministes et insiste sur l'entretien des jeux d'évaluation. Quatrième règle, construire pour reconstruire : la capacité des modèles bouge, donc peu de choses sont traitées comme permanentes. Commure pose le critère de fin d'une reconstruction — quand l'ancien chemin a disparu — et les git worktrees rendent l'exercice abordable. Cinquième règle, prototyper, manger sa propre nourriture, industrialiser : l'agent interne construit avec Claude Code devient, s'il convainc, un produit client via l'API, le SDK ou les Claude Managed Agents. Les quatre chiffres mis en avant restent déclarés par les entreprises interrogées, sans méthode d'enquête décrite.

Designing AI with character: what we learned building Berd

Tue, 18 Aug 2026 00:00:00 GMT

Billet du blog corporate de **Block** (`block.xyz/inside`), **non signé**, publié le **18 août 2026**, qui annonce **l'ouverture du code de Berd** et expose la thèse de conception qui l'a guidée. **Ce qu'est Berd.** *« Berd is a desktop application our teams use to work with AI agents across projects, skills, tools, and models. »* Née d'un problème interne : Block avait accès à des agents capables — **goose**, **Claude Code**, **Codex** — mais chacun imposait *« different interfaces, configuration systems, and ways of managing context »*. Conclusion tirée : *« we didn't need another model or agent harness, **we needed a consistent environment around them** »*. Berd rassemble conversations, fichiers, dossiers, instructions, agents et skills autour de **projets persistants**, pour cesser de reconstruire le contexte à chaque tâche. **La thèse de design.** Donner du **caractère** aux agents — non seulement par les rôles, instructions, skills et outils, mais par des **identités visuelles distinctes**, dont une collection de personnages animés, les *« Gloopies »*. Le problème invoqué est celui de la boîte de saisie vide : *« the product gives people little sense of how the agent is configured, which context and tools are available to it, and how it differs from another agent »*. Le billet inscrit la démarche dans la lignée de **Square** et **Cash App** — apporter du design là où la catégorie n'en avait pas. **Mais le problème posé est un problème de lisibilité de la configuration, et l'avatar résout la distinguabilité** ; le texte le reconnaît en une ligne qu'il ne développe pas : *« The avatars make the agent recognizable. **Its role, skills, and tools make it useful.** »* **L'architecture.** Berd descend de **goose**, framework d'agent open source lancé par Block en **janvier 2025**, contribué à l'**Agentic AI Foundation** (Linux Foundation, décembre 2025) aux côtés de **MCP** et d'**AGENTS.md**. Répartition explicite : *« goose remains the open agent framework and runtime. Berd is a desktop application built around it. **Berd connects to goose through the Agent Client Protocol.** »* goose tient la boucle d'agent, Berd tient l'expérience. **La suite est Buzz.** Berd a servi à explorer le travail **solo** ; *« But work rarely stays private »*. Ce que Berd a montré — *« private space, durable context, recognizable agent identities, reusable skills, visible configuration »* — nourrira **Buzz**, l'espace partagé humains+agents. *« Start alone, then go multiplayer. »* **Réserves.** **Aucun chiffre, aucun test utilisateur, aucune licence nommée** ; une surpromesse isolée (*« create custom agents to do any task they want »*) ; et un billet dont le titre annonce un rétrospectif tout en maintenant le produit au présent — **Berd n'est pas déclaré déprécié, mais la feuille de route va à Buzz**.

Securing Software at the Speed of AI: What Four Years of Data Reveal

Tue, 18 Aug 2026 00:00:00 GMT

Sonatype publie, sous la plume de son *technical writer* Aaron Linskens, la synthèse d'une étude longitudinale de ses laboratoires de recherche portant sur quarante-neuf mois, de juin 2022 à juin 2026. La méthode est annoncée d'emblée : une cohorte fixe d'applications suivies en continu, pour que les variations mesurées reflètent l'évolution du parc logiciel et non celle du portefeuille de clients. Le résultat central est présenté comme une contradiction : les organisations corrigent plus vite qu'avant, et leurs applications accumulent pourtant davantage de risque. Quatre mesures cadrent le constat. Les vulnérabilités classées *Critical* et *High* par application ont été multipliées par 4,31, passant d'une moyenne de 14,14 en juin 2022 à 54,3 en 2026 ; l'effet ne tient pas au seul héritage, puisque l'exclusion des applications légataires récemment prises en gestion laisse un facteur 3,91. Les versions de composants nouvellement affectées progressent à quarante-six fois le rythme d'avant l'IA. L'âge médian des vulnérabilités a reculé de 59 % depuis son pic de janvier 2024. Enfin, la création mensuelle moyenne d'applications a été multipliée par 4,84, et avec elle les décisions de dépendance. La progression de la remédiation est réelle : plus de la moitié des violations résolues le sont en moins d'une journée, et l'âge médian des *Critical/High* non résolues tombe de 228 à 126 jours, puis à 103 jours en mai 2026. Sur les cohortes disposant d'au moins douze mois pour agir, 52,6 % sont résolues, 44,3 % restent ouvertes et 3,1 % font l'objet d'une dérogation. Le déplacement proposé porte sur l'amont. Les chercheurs ont examiné les dépendances vulnérables entrées dans les applications de la période et posé une question simple : au moment de la sélection, une version sensiblement moins risquée existait-elle déjà ? La réponse est oui dans 62,2 % des cas sur Maven, 46,9 % sur npm et 34,3 % sur PyPI. Le texte refuse d'y lire une faute de développeur : certaines vulnérabilités sont inévitables, d'autres relèvent d'un défaut d'information au moment du choix — un point qui devient sensible quand un assistant IA peut introduire un composant en quelques secondes sans disposer d'une intelligence à jour sur son risque et sur la politique de l'organisation. Le billet reconnaît que l'IA n'est pas la cause unique de l'expansion du paysage de vulnérabilités et cite quatre facteurs concurrents. Il se conclut sur Sonatype Guide, qui porte cette intelligence au point de sélection, et renvoie au rapport complet, *The AI-Era Software Assembly Line*, pour les données sous-jacentes.

Projects in Buzz

Tue, 18 Aug 2026 00:00:00 GMT

Billet d'annonce de **Block Engineering** signé **Thomas Petersen** (*Principal Designer & Builder*), publié le **18 août 2026**, présentant **Buzz Projects** — la brique forge de **Buzz**, le workspace humains+agents de Block bâti sur **Nostr**. **Le problème posé.** *« Software development tools are fragmented in ways the work itself is not. »* Le rapport de bug est dans un outil, la discussion dans un autre, le correctif sur une branche, la CI ailleurs, la revue dans un fil de commentaires, les notes de version reconstituées après coup. **La thèse : tout cela est une seule conversation, et l'historique doit faire partie du projet.** **Ce que Projects apporte.** Une **forge hébergée sur votre propre relais** : dépôts Git standards accessibles en `fetch/clone/pull/push` sur **Smart HTTP**, *« with no custom tooling or wrapper CLI required »* ; **la clé Nostr comme identité unique** — *« the same npub that signs your messages signs your pushes »*, sans jeton séparé ni compte GitHub ; des **projets multi-dépôts** pouvant inclure des dépôts qu'on ne possède pas (*« you just won't have authority over it »*) ; issues, pull requests, diffs, commentaires en ligne, revue et fusion ; un **fil d'activité** à l'échelle du serveur ; et la **liaison de tout projet à un nombre quelconque de canaux**, de sorte que *« le contexte autour d'un changement ne disparaît pas au moment où les agents se mettent à écrire du code »*. Depuis un canal, on peut confier une issue à un agent ou lui demander d'ouvrir une PR, laquelle renvoie à la conversation qui l'a produite ; l'agent sollicite l'humain via l'**Inbox**. **La doctrine, en deux temps que le billet n'assemble pas.** D'un côté, **aucune contrainte préalable** : *« No forced guardrails, no limitations on what your agents are allowed to help you with. »* De l'autre, **un enregistrement signé de tout acte** : *« Every push, review, approval, and merge is a signed Nostr event »*, avec la trace de **quel agent** a produit un patch et **quel humain** l'y avait autorisé. D'où la projection finale : l'historique de contribution devient *« more than a set of colored squares on a profile »*, un **historique vérifiable attaché à une clé**, et Block déclare **explorer des *« agent trust protocols informed by past behavior »***. **La confiance bascule de l'autorisation *ex ante* à la preuve *ex post*.** Le cadre associé est net : *« A terminal gives an agent somewhere to execute commands and change files, but it does not give it a persistent place in the network. Buzz does. »* **Réserves.** **Aucun chiffre, aucun lien sortant, aucune spécification** dans tout le texte ; **CI et notes de version sont promises mais absentes de l'inventaire** ; Projects vit sous **l'onglet Experiments** et le billet se disqualifie six fois — *« Buzz is still in beta and Buzz Projects is still under experiments, so treat it accordingly. »*

The AI Engineering Skills Map

Fri, 14 Aug 2026 00:00:00 GMT

Post X d'**Andrew Ng** du **14 août 2026**, repris de la lettre « Dear friends » de ***The Batch* n°366** (DeepLearning.AI). **Ce qui est annoncé.** *The AI Engineering Skills Map* : **quatre compétences** présentées comme les plus importantes pour un développeur, adossées à *« une analyse de plus de 10 000 offres d'emploi »*, des dizaines d'entretiens structurés avec experts, hiring managers et recruteurs, des sondages et d'autres données en ligne. Double destinataire, explicite : aider les développeurs à **prioriser ce qu'ils apprennent** et les employeurs à **recruter**. **Les quatre compétences.** **(1) Construire et déployer des applications IA** — leur différence tenant à l'**imprévisibilité des sorties**, il faut connaître les briques (LLM, ingénierie de contexte, RAG, workflows agentiques, machine learning, deep learning) et surtout les **techniques statistiques pour mesurer, piloter et gouverner**, dont *« des boucles d'évaluations et d'analyse d'erreurs disciplinées »*. **(2) Fondamentaux du génie logiciel** — les comprendre permet de *« reconnaître quels arbitrages existent »* (coût, scalabilité, fiabilité, vitesse, sécurité, vie privée) et donc de piloter l'agent *« dans le langage précis du génie logiciel »* ; le vibe coder inexpérimenté échoue parce qu'*« il ne sait pas quel contexte donner à son agent »*. **(3) Utiliser les agents de codage** — modèle mental de leurs limites, gestion du contexte, arbitrage planification/exécution, **fourniture de vérificateurs ou d'evals pour que l'agent ferme ses boucles seul**, travail avec un spec clair *« et quand ne pas s'en donner la peine »*, orchestration multi-agents, garde-fous. **(4) *Shaping the build*** — les agents livrant bien un spec clair, le travail se déplace vers **décider ce que le spec doit contenir** : sens produit, contexte métier, conduite de projet. **Sous-jacent aux quatre : un état d'esprit d'apprentissage continu**, avec *« des routines pour essayer de nouveaux outils »*. **La thèse réelle, glissée en note de terminologie.** Ng parle de **compétences** d'AI engineering et non du **rôle** « AI Engineer » : *« tous les développeurs devraient savoir travailler avec le cloud, seul un petit nombre porte le titre "Cloud engineer" »*. **L'AI engineering devient un socle, pas une spécialité** — on ne recrute pas, on requalifie. **Deux réserves.** **Aucun résultat chiffré n'est publié** : pas de pondération, pas de sous-compétences, un clustering qualifié d'analogie *« informelle »*, et la carte détaillée renvoyée à de futurs billets. **C'est l'annonce d'une carte, pas la carte.** Et l'auteur déclare son intérêt : *« DeepLearning.AI's principal focus is to help developers gain these AI engineering skills. »*

GLM-5.3: Frontier Coding with Emergent Cyber Capabilities

Fri, 14 Aug 2026 00:00:00 GMT

Billet d'annonce publié le **14 août 2026** sur le blog de **Z.ai** (ex-Zhipu AI), **non signé**, pour le lancement de **GLM-5.3**. **La thèse méthodologique.** *« Scaling post-training is all we did for GLM-5.3. »* Même modèle de base que GLM-5.2 : **tout le gain vient du post-entraînement**, sur la pile bâtie au cycle précédent — **IndexShare** (contexte long), **SAO** (RL long-horizon) et **slime** (entraînement asynchrone, Megatron + SGLang). Le goulot s'est déplacé du modèle vers **l'environnement** : Z.ai décrit des pipelines qui **synthétisent** environnements et signal de récompense — un agent juge vérifie la solvabilité, les **vérificateurs sont synthétisés sans accès à la solution de référence**, et ne sont admis qu'après un triptyque de contrôles **oracle / no-op / unsolved-state**. Le travail reste *« human-in-the-loop »*. Débit RL end-to-end amélioré de **plus de 2,3×**. **Les résultats codage.** Terminal-Bench 3.0 passe de **4,6 à 28,3**, DeepSWE v1.1 de **46,2 à 66,9**, Agents' Last Exam de **23,8 à 28,5**. Sur **Z.ai Code Bench**, benchmark **maison et privé**, +50 % sur GLM-5.2, avec un gain simultané d'**efficacité en tokens** : 34,5 % à ~75 K tokens de sortie en effort Max (contre 23,4 % à 96 K pour GLM-5.2), et 31,4 % à ~50 K en effort High — devant Claude Opus 4.8 (29,5 % à 120 K). **Claude Fable 5 reste devant à 39,5 %.** La revendication *« most capable open-weights model for coding »* **ne se déduit pas du tableau** : face à **Kimi K3**, le score est **3 – 3 et une égalité**. **La capacité cyber.** Présentée comme *« émergente »*, elle a été **délibérément entraînée** — le billet écrit *« we expected this to make the model better »*. Ce qui a surpris est la **vitesse**, et le passage de la faille isolée à la **chaîne d'exploitation complète**. CyberGym **84,5 %** (meilleur du tableau), ExploitBench **54,4 %** (×2,2), ExploitGym **105/130 tâches** (×3,6 sur GLM-5.2, budgets normalisés par débit). Phrase clé : ***« Capability is growing fastest exactly where we are furthest behind. »*** **Le chiffre le plus lourd.** Avec des équipes de sécurité chinoises, le modèle a identifié **2 436 vulnérabilités dans 269 projets open source** — noyaux, OS, moteurs de navigateur, protocoles réseau — la plus ancienne introduite en **1981**, durée de vie moyenne **26,6 ans**. Le **Security Disclosure Ledger** affiche **53 divulguées** et **2 383 sous embargo** : **2,2 % de publication**. **La gouvernance.** Poids annoncés *« dans deux semaines, une fois l'évaluation de sûreté et le durcissement terminés »* — **une date, pas un critère** : ni définition du durcissement, ni condition de non-publication, ni évaluateur tiers. **Divers.** `thinking.type: "disabled"` **n'est plus supporté** (migration obligatoire) ; quotas GLM Coding Plan en points, **50 % hors 14:00–18:00 UTC+8** ; **presque toutes les évaluations sont conduites dans Claude Code 2.1.207**.

DeepSeek Harness developer preview: Everything is a plugin

Thu, 13 Aug 2026 00:00:00 GMT

Page de lancement produit publiée le **13 août 2026** par **DeepSeek**, **non signée**, pour la mise en *developer preview* de **DeepSeek Harness** (`dsh`), harnais d'agent de codage **open source sous licence MIT** dont le dépôt est ouvert le même jour. **Ce que dit la page.** Deux promesses, en quatre cents mots et sans un chiffre. **« Everything is a plugin »** : toute capacité — modèles, outils, skills, sessions, sandboxes, stockage, boucles, ordonnancement, interface — est un plugin **substituable par configuration, sans modifier le code source**. **« Every run is traceable »** : tout ce que le modèle voit est inscrit dans un **log de session append-only** — prompts système, raisonnement, appels d'outils et résultats, ordonnancement des subagents, chaque injection de contexte — et *« resume, fork, search et replay opèrent tous sur le même flux d'événements »*. Le noyau est **Cordis**, framework tiers vendoré, décrit dans un papier externe et crédité en évidence. Quatre modes d'exécution sont livrés : **Standard** (outillage complet), **Code** (outils exposés via un SDK TypeScript pour combiner plusieurs opérations en un programme), **Minimal** (deux outils, bash persistant et `str_replace_editor`, *« for benchmarking models in a minimal environment »*) et **Creator** (inspection du runtime, test de plugins en mémoire, composition de nouveaux modes). Démarrage : `npx @deepseek-ai/dsh web`. **Ce que la page ne dit pas.** L'affirmation la plus forte est dans `docs/architecture.md` : ***« Model-visible means logged. Anything that reaches a model request must be reconstructable from the log, and a runtime invariant asserts it. »*** **Une garantie assertée à l'exécution**, pas un affichage — c'est la propriété qui distingue réellement DSH, et elle est absente de l'argumentaire. Le même dépôt en fournit le démenti : `SESSION_FORMAT_VERSION` reste à **`0` sans promesse de compatibilité**, *« backends reject old on-disk formats »*, et le README avertit en capitales qu'il y aura des ruptures. **Traçable maintenant ne veut pas dire archivable demain.** **Le modèle d'affaires est dans le calendrier.** DSH sort le jour de la **GA de DeepSeek-V4-Pro** et **trois jours avant** une nouvelle grille tarifaire API (16 août, 16:00 UTC ; heures creuses à **−50 %**). **Harnais donné, inférence renchérie** — l'inverse exact du modèle d'Anthropic. **Ce qui se vérifie.** La substituabilité tient au moins sur la couche modèle : outre l'adaptateur DeepSeek, **`dsh-llm-pi-ai`** rend tout gateway OpenAI-compatible accessible *« par configuration, pas par changement de code »*. Et le mode Minimal livre le **harnais de mesure** dans le produit — tentative de reprendre à Claude Code la définition du benchmark, alors même que le dépôt de DSH contient un `CLAUDE.md` et un `.claude/skills`.

Buzz (buzz.xyz) — Rapport de recherche pour présentation

Wed, 12 Aug 2026 00:00:00 GMT

Rapport de recherche interne du **12 août 2026** consolidant l'état public de **Buzz**, le workspace humains+agents de **Block** lancé le **21 juillet 2026** sous **Apache 2.0**, en vue d'une présentation. Il agrège les deux billets d'ingénierie de Block, l'annonce corporate, le dépôt GitHub, la presse, X et **trois évaluations indépendantes** — cette dernière couche portant l'essentiel de la valeur ajoutée. **Le concept.** Buzz fusionne chat d'équipe, forge Git et workflows automatisés en un seul espace où les agents sont **des membres à part entière, pas des bots**. La thèse est celle de Tyler Longwell : *« The bottleneck moved from intelligence to coordination. »* Bradley Axen (Head of AI Capabilities) en donne l'enjeu de marché : *« Every company is going to need a place where humans and agents work together. The question is whether that place is proprietary or open. »* **L'architecture.** Relais **Rust** sur **Nostr** (NIP-01/42/98/34, 127 *event kinds*), **Postgres**, **Redis**, **S3/MinIO**, desktop **Tauri+React**. Chaque participant détient une paire de clés ; chaque message, revue, étape de workflow et événement Git est **signé** dans un journal d'audit append-only à chaîne de hash. Un formalisme rare pour une **v0.4.x/0.5.x** : isolation multi-tenant mécanisée en **TLA+**, propriétés d'autorisation vérifiées en **Tamarin**. L'intégration agent passe par **`buzz-acp`**, harnais **ACP** qui branche goose, Codex et Claude Code et **traduit ACP ↔ MCP** — *« They compose through protocols, not imports. »* **L'écart central.** Jack Dorsey annonce *« decentralized, self-sovereign »* ; l'`ARCHITECTURE.md` de Block dit : *« The relay is the single source of truth… There is no peer-to-peer event exchange, no gossip, no replication. »* Un relais unique par communauté, donc un **point de défaillance unique** : la décentralisation est une **souveraineté organisationnelle**, pas une redondance. **Les limites, documentées.** L'unité de permission est **l'appartenance au canal** — *« channel membership is not fine-grained tool authorization »* ; les agents tournent en **`--dangerously-skip-permissions`**, hors bac à sable ; **l'observabilité manque** (*« It doesn't tell me what happens next »*, kills OOM silencieux). Les événements signés sont *tamper-evident*, pas *tamper-resistant* : un opérateur de relais compromis peut supprimer. Sur le relais hébergé, **pas de chiffrement de bout en bout**. **Précision de chiffre.** Le « +33 % de travail » est le **ratio de tâches terminées (20 vs 15 sur 44)**, pas un gain de score — lequel passe de 59,1 % à 71,5 %, soit **+12,4 pts**. **Réception** : ~25 900 étoiles GitHub, tweet Dorsey à ~2,3-2,7 M vues, soutien de Sundar Pichai, et la formule de Justin Waldron : *« the first proper multiplayer agent harness »*. Caveats assumés : benchmarks **auto-évalués par Block**, aucun prix d'hébergement, aucun chiffre d'adoption.

I built a marketing AI operating system for a 60-person team. The most valuable thing in it is the part that refuses to write.

Wed, 12 Aug 2026 00:00:00 GMT

Retour d'expérience publié sur **LinkedIn Pulse** le **12 août 2026** par **Guillaume Dumortier** (newsletter *Growth Marketing Fit*), sur un système d'IA marketing interne bâti **dans Claude** pour une équipe d'une soixantaine de personnes : une trentaine de skills, une douzaine de modules de vérité, **sept agents dont six ne font que contrôler**, un plugin terminal, une application navigateur, et une orchestration de campagnes multi-actifs. **La thèse.** *« Je croyais construire une machine à contenu. Je construisais une machine à confiance. »* La qualité d'une sortie IA n'est pas déterminée à la génération, mais par **ce que le système sait avant** et **ce qui arrive au brouillon après**. La génération est la partie facile — et la seule que la plupart des équipes ont construite. **Quatre couches.** *Vérité* : des documents de faits séparés de tout ce qui produit du contenu, chacun avec un propriétaire, versionné et daté. Laisser les faits dans les skills a produit **quatre versions d'une date de lancement dans quatre fichiers**, chacun individuellement plausible. *Production* : la skill blog écrivait pendant des semaines **des descriptions d'articles** au lieu d'articles, et passait toutes les revues, parce que la revue contrôlait la structure. Passé trente skills, le problème devient **le routage** — la moitié d'une description de skill doit énoncer ce à quoi elle ne sert pas. *Vérification* : la couche qui sépare une démo d'un système. *Distribution interne* : là où les projets meurent d'être excellents et utilisés par quatre personnes. **Les deux pannes centrales.** Un vérificateur de faits reçoit une affirmation qu'aucune de ses sources ne couvre : il rend un « pass ». *« Il n'a pas seulement raté l'erreur, il l'a certifiée. »* Correctif : un vérificateur est un **système en monde clos** ; **il lui est interdit de renvoyer un « pass » nu** et il doit déclarer sa couverture — combien d'affirmations contrôlées, combien réellement appariées, lesquelles hors juridiction, lesquelles possédées par aucune source. *« Une affirmation invérifiable est un constat, pas un silence. »* Seconde panne : **deux actifs individuellement corrects peuvent se contredire** ; la vérification par actif ne peut pas l'attraper, par construction. **Cinq règles transverses.** Ne jamais demander à un modèle ce qu'on peut imposer en code. Les **échecs silencieux** sont tout le risque — une constante vidée supprimait tous les chiffres de tous les prompts, et il accusait le modèle d'halluciner. Tester le pipeline, pas la sortie. Votre validation a les mêmes trous que votre système. **Apprendre au système à refuser.** **L'adoption suit la confiance, pas la capacité** : une sortie qui admet ce dont elle n'est pas sûre est utilisée. Clausule : ***« The generation is free. The trust is the product. »***

Agent Plugins package your skills, tools, and more

Thu, 06 Aug 2026 00:00:00 GMT

Billet d'ingénierie de **Google** du **6 août 2026** annonçant que l'entreprise rejoint comme **Core Maintainer** la spécification **Agent Plugins 1.0.0** — un format d'empaquetage ouvert et *vendor-neutral* pour distribuer ensemble **Agent Skills** et **serveurs MCP**. **Le fait de gouvernance d'abord.** La spécification a été publiée par un TSC de Core Maintainers venus d'**Amazon, Cursor, Microsoft, OpenAI et Vercel**. Google s'y ajoute, représenté nominativement par **Kevin Hou** (Google DeepMind). Six concurrents s'accordent sur une couche d'emballage. **Anthropic ne figure pas dans la liste des mainteneurs**, alors que les deux briques empaquetées viennent de chez elle. **Le diagnostic.** Une skill est portable, un serveur MCP est portable — *« The core problem isn't the components. It's the manifest. »* Ce qui n'a jamais été portable, c'est la boîte : disposition des répertoires, métadonnées de manifeste, forme de la configuration MCP et inférence du transport diffèrent d'un client à l'autre. On forke, on maintient deux copies de composants identiques, et elles dérivent. **Le format.** *« A plugin is a directory. That's the whole idea, and the restraint is the point. »* Un `plugin.json` réduit à `$schema` et `name` ; les skills dans `skills/`, au format Agent Skills ; les serveurs dans `mcp.json`, **avec un `type` explicite** sur chaque entrée (stdio, Streamable HTTP, HTTP+SSE historique). La force du design tient à ce que le manifeste **ne peut pas** faire : ni relocaliser un composant, ni le déclarer en ligne. Donc aucun chemin de découverte à configurer, aucun ordre de précédence à apprendre. Corollaire : **les composants échouent indépendamment** — un serveur qui ne démarre pas n'emporte pas les skills. Un répertoire en **domaine inversé** (`com.example.client/`) sert d'espace d'extension propriétaire, ignoré par les autres clients : le cœur portable reste petit parce que les parties non portables ont où aller. **Les limites, assumées.** Une section entière explique **quand ne pas faire de plugin** (un seul serveur MCP, une seule skill : inutile). Une autre liste ce que la v1 exclut : **installation, distribution, permissions, sandboxing, vérification de confiance et de provenance, UX**. Justification : les obligations d'un IDE, d'une CLI et d'une plateforme d'entreprise diffèrent réellement. **La pile.** Trouver (**Agentic Resource Discovery**), décrire (**AI Catalog**), empaqueter (**Agent Plugins**), exécuter (**MCP + Agent Skills**) — chaque couche adoptable indépendamment. **Livré aujourd'hui** : **Agents CLI** (utilisable depuis Antigravity, Gemini CLI, Claude Code ou Cursor) et **Data Agent Kit** (BigQuery, Spanner, Cloud SQL). *« Those skills were already distributable. Now they're distributable in a format that isn't ours alone. »* Chute : *« Packaging is unglamorous infrastructure »*, et c'est précisément ce qui doit être partagé plutôt que réinventé cinq fois.

Graphify — Knowledge Graphs for AI Coding Assistants (site graphify.net : vitrine, annuaire d'outils et galerie de dépôts graphifiés)

Thu, 06 Aug 2026 00:00:00 GMT

Site **graphify.net**, consulté le 6 août 2026, propriété officielle de **Safi Shamsi**, créateur de la skill open source graphify. Le domaine porte trois choses distinctes de la plateforme commerciale `graphify.com` et du dépôt GitHub. **Une vitrine produit**, d'abord : présentation de graphify, guides d'usage, référence de la CLI, pages sur tree-sitter et le clustering de Leiden. **Une galerie de démonstration**, ensuite, et c'est la partie la plus convaincante : **100 dépôts de GitHub Trending déjà graphifiés**, totalisant **854 079 nœuds et 1 932 930 arêtes**, filtrables par langage et par taille, chacun affichant son compte de nœuds, d'arêtes et de communautés, avec prévisualisation du graphe et page de détail. Montrer l'outil tourner sur des dépôts connus vaut mieux qu'un argumentaire, et produit au passage un jeu de données public de graphes comparables. **Un annuaire éditorial**, enfin, qui a de la valeur indépendamment du produit qu'il promeut : **30 guides de clients de codage IA** comparés sur le workflow, les agents, le prix, la sécurité et l'adéquation à la livraison ; un **répertoire de serveurs MCP** évalués sur le transport, le runtime, les clients supportés, l'effort d'installation et **les risques d'accès** ; des comparaisons deux à deux sur champs alignés. Le site revendique une méthode — *« source-reviewed »*, preuves officielles, inconnues explicites — et se décline en six langues. **Cette fiche existe surtout pour consigner un décalage.** Le même jour, le site annonce **« 3,7k+ étoiles GitHub »** quand l'API en compte **103 187** ; il déclare **trois fois** une licence **MIT** quand le fichier `LICENSE` du dépôt est une **Apache 2.0** ; et il met en avant l'argument **« 71,5× de réduction de tokens »**, qui appartient au README de la génération v1 et a disparu de la version courante au profit de benchmarks LOCOMO et LongMemEval. Le site décrit donc un produit d'il y a plusieurs générations. **L'erreur de licence est la plus sérieuse** : MIT et Apache 2.0 n'emportent pas les mêmes obligations, notamment sur les brevets et la mention des modifications. Reste une observation stratégique : **un éditeur d'outil qui construit l'annuaire de sa propre catégorie** occupe la requête d'évaluation avant ses concurrents. La revendication de neutralité ne supprime pas le conflit d'intérêts — graphify figure parmi les skills mises en avant du site. Point d'entrée utile, arbitre non.

Efficient Tokens & Effective Teams in Buzz

Thu, 06 Aug 2026 00:00:00 GMT

Billet de benchmarks de **Block** signé **Atish Patel**, publié le **6 août 2026**, prolongeant le lancement de **Buzz** : puisque monter une équipe d'agents y est devenu trivial, *quelle est la moins chère qui réussit de façon fiable ?* **Le vocabulaire d'abord.** Le billet propose quatre tiers : **QuickBee** (rapide et bon marché — builds, captures, tests, tri de première passe : GPT-5.6 Luna, DeepSeek V4 Flash, modèles locaux, **à faire tourner en effort élevé**), **WorkerBee** (polyvalent, porte un sous-ensemble complet sans surveillance : GPT-5.6 Terra, Gemini 3.6 Flash, modèles ouverts), **SmartBee** (vue d'ensemble, arbitrages, escalades : Claude Opus 5, Kimi K3, GPT-5.6 Sol, **en effort *medium***) et l'humain, *« the most expensive bee on the team, and the slowest. Also still the smartest »*. Deux formes d'équipe : la **Hive** permanente, qui mémorise **vos** préférences, et le **Swarm** jetable, qui mémorise **le projet** puis disparaît. **Le résultat solo.** Sur **Terminal-Bench 2.1**, monter l'effort d'un **modèle bon marché** est le meilleur achat : Luna passe de 1,61 $ / 57,3 % (*medium*) à 4,98 $ / 75,0 % (*high*). À l'autre bout, **Opus 5 en *xhigh* est le run le plus cher (140,63 $) et ne marque que 75,0 %**, ayant **atteint le timeout sur 17 des 88 tâches** par sur-raisonnement. Entre les six meilleurs runs : **5,5× d'écart de prix, 8,9 pts d'écart de score**. Conclusion : *« choosing between them is not a quality decision at all. It is a budget decision. »* **Le résultat d'équipe, en deux temps.** Sur Terminal-Bench 2.1, **douze compositions** ont été testées et **aucune n'a battu le solo à prix équivalent** — une tâche courte n'a pas assez de structure à diviser. Sur **Long-Horizon Terminal-Bench** (44 tâches de plusieurs heures, chef GPT-5.6 Sol, **3× le timeout**), l'inversion est nette : solo **15 tâches / 59,1 %**, +2 WorkerBees **20 / 71,5 %** — **+12,4 pts, dont 11,4 dus aux complétions supplémentaires**. L'équipe coûte plus cher par tâche, ce qui se justifie *« quand l'alternative est un humain qui ramasse du travail inachevé »*. **La règle d'exploitation.** Faire escalader les workers vers un **coordinateur SmartBee** plutôt que vers l'humain : *« every ambiguity becomes a notification »* est le vrai mode de défaillance. Un ingénieur de Block dit avoir **migré plus de 2 000 apps** avec un Swarm (coordinateur, 1-10 migrateurs, vérificateur indépendant), le coordinateur mémorisant les réponses humaines. **Réserves** : n=1 par tâche, pas d'intervalle de confiance, coûts d'équipe non publiés, et un aveu — *« this might change if models are trained on better collaboration. »*

graphify — « Turn any codebase, with its docs, SQL schemas, configs, and PDFs, into a queryable knowledge graph. A /graphify skill for Claude Code, Cursor, Codex, and Gemini CLI: local deterministic AST parsing, every edge explained, no vector store. »

Thu, 06 Aug 2026 00:00:00 GMT

**graphify** (Safi Shamsi, Graphify Labs, Y Combinator S26) transforme un projet entier en **graphe de connaissance interrogeable**, invocable par `/graphify` depuis Claude Code, Cursor, Codex, Gemini CLI et une quinzaine d'autres clients. Observé le 6 août 2026 : **103 187 étoiles** pour un dépôt créé le 3 avril, Apache-2.0, Python. **Trois partis pris fondent le projet.** Le **code est parsé localement** en AST tree-sitter, sans LLM : déterministe, rien ne quitte la machine, aucune clé d'API requise pour un corpus purement code. **Chaque arête porte sa provenance** — `EXTRACTED` si elle est explicite dans la source, `INFERRED` si graphify l'a résolue —, *« so you can tell what was read directly from what was inferred »*. Et le projet se définit **contre le RAG vectoriel** : *« Not a vector index. No embeddings, no vector store: a real graph you traverse. »* **L'usage remplace le grep.** `query` rend un sous-graphe pour une question en langue naturelle, `path A B` trace le chemin entre deux entités, `explain` déplie un concept. Trois sorties : un graphe interactif, un rapport lisible (god nodes, connexions surprenantes, questions suggérées) et un `graph.json` persistant, interrogeable des semaines plus tard. **La couverture dépasse le code** : 36 grammaires tree-sitter, mais aussi SQL, Terraform, Apex, les **configurations MCP**, les manifestes de paquets, Office, PDF, images, et la vidéo transcrite localement. Les commentaires `# WHY:` et le raisonnement de conception deviennent des **nœuds à part entière reliés au code qu'ils expliquent**. **Les benchmarks méritent une lecture précise.** Sur LOCOMO, graphify domine le rappel (0,497 contre 0,149 et 0,048) mais **perd en exactitude QA** (45,3 % contre 49,7 %) ; sur LongMemEval-S il **égale un RAG dense** à 76 %. La ligne qui compte est ailleurs : *« Graph build — LLM credits: 0 »*. Le différenciateur défendable est **le coût et la traçabilité, pas la qualité de réponse**. **Trois précautions.** La branche `main` porte un README périmé de l'ère v1 décrivant un autre produit : lire `v8`. Le paquet PyPI s'appelle `graphifyy`, le temps de récupérer le nom. Et un **journal de requêtes local** est actif par défaut, désactivable par variable d'environnement. La skill sert par ailleurs de porte d'entrée à une plateforme commerciale en liste d'attente sur graphify.com, qui applique la même approche en continu à l'ensemble du contexte de travail.

Introducing Muse Code and Muse Spark 1.2

Wed, 05 Aug 2026 00:00:00 GMT

Annonce de **Meta AI Research** du **5 août 2026** : **Muse Code** en bêta, agent de codage en terminal, et **Muse Spark 1.2**, le modèle qui l'anime. Meta situe elle-même le lancement — *« our next step toward the frontier, with larger and much more capable models on the way »*. **Côté harnais, trois décisions.** Des **agents d'arrière-plan asynchrones** qui *« remain active throughout each session, rather than being spawned for individual tasks »*, évitant la collecte d'information redondante et décidant eux-mêmes quand remonter à l'agent principal. Un **journal d'événements local** consignant chaque appel de modèle, exécution d'outil, approbation et édition, ce qui rend le runtime *« replay-exact and restart-safe »* : après un plantage, l'agent reprend exactement où il s'était arrêté. Et trois **skills livrées d'origine** : `/plan` (plan soumis à approbation), **`/grill`** (met le plan à l'épreuve jusqu'à ce qu'il tienne) et `/goal`. **Côté modèle**, Meta revendique un **co-entraînement avec le harnais** *« to maximize harness compatibility »*, un entraînement long-horizon (dépôt entier, projets bout-en-bout, auto-recherche, compaction de contexte) et une boucle d'auto-amélioration où la version 1.1 génère les environnements et note les solutions, produisant le jeu d'entraînement de la 1.2. **Le fait central de cette annonce n'est écrit nulle part dans son texte.** Les quatre comparatifs publiés existent uniquement sous forme d'images, et ils placent Muse Spark 1.2 **derrière Opus 5 dans les quatre cas** : 82,9 % contre 86,7 % sur Terminal-Bench 2.1, 59,3 % contre 65,0 % sur DeepSWE 1.1, **70,6 % contre 79,4 % sur le benchmark interne de Meta elle-même**, et +68,7 % contre +74,0 % sur l'étude de cas d'optimisation de noyaux GPU, où le modèle finit **quatrième sur six**, derrière GPT 5.6 Sol et derrière la génération précédente d'Anthropic. **Et le gain propre au modèle est plus faible qu'il n'y paraît.** Sur les deux benchmarks publics, la version 1.1 est évaluée avec `mini-swe-agent` et la 1.2 avec Muse Code : l'écart de 6,7 points mélange modèle et harnais. Sur le benchmark interne, seul comparatif sans harnais indiqué, il tombe à **2,3 points**. L'annonce vaut donc surtout comme **confirmation empirique** d'une thèse déjà posée : la valeur se déplace vers le harnais, et un harnais co-entraîné avec ses propres poids rend ces poids d'autant moins interchangeables.

How to use Notion as Code

Mon, 03 Aug 2026 00:00:00 GMT

Documentation de **Notion as Code**, produit en **alpha fermée**, consultée le 3 août 2026 sur l'espace Notion Ambassadors — sans auteur ni date, avec un avertissement recommandant de l'essayer sur un espace de travail neuf et prévenant de changements cassants possibles. **Le principe** est l'infrastructure as code appliquée à un espace documentaire : *« Instead of having to make individual public API requests, you can describe the final state and we handle updating your workspace to match. »* Deux briques : un **SDK TypeScript** pour décrire l'état voulu, et l'endpoint **`/v1/infra_as_code`** pour le déployer. **Le mécanisme qui porte tout** est l'indirection par identifiant. Le script **ne contient aucun identifiant Notion** : il déclare des `resourceId` choisis par l'auteur. Le premier déploiement retourne une **table de correspondance** entre ces identifiants logiques et les enregistrements réellement créés ; renvoyée aux appels suivants, elle fait que les mêmes enregistrements sont **mis à jour plutôt que recréés**. **Trois propriétés en découlent.** Le script devient **idempotent**. Il devient **découplé de l'espace de travail** — plusieurs tables de correspondance permettent de déployer **le même script sur plusieurs espaces**. Et comme c'est du code, il admet variables et boucles : l'exemple donné est de construire dix équipes de structure identique en ne changeant que quelques noms. **Le contrat d'API est asynchrone** : un `POST` rend un `taskId`, que l'on interroge jusqu'à complétion ; la réponse porte les tables de correspondance à persister — l'équivalent d'un fichier d'état. **Deux différences opérationnelles** : le produit exige des **jetons d'accès personnels** et non les jetons de bot habituels, ce qui attribue les actions à une personne plutôt qu'à une intégration ; et la **limite de débit tombe à 5 requêtes par minute**, un appel étant désormais un lot et non une entité. **Le produit suppose l'agent.** Le SDK est présenté comme fait *« for you or your coding agent »*, et le chemin de prise en main consiste à laisser un agent lire le README du SDK. Un descripteur d'état typé est en effet un meilleur outil pour un agent qu'une série d'appels impératifs : l'erreur y est rejouable plutôt que cumulative. **Ce qui manque** : aucune mention de suppression des éléments retirés du script, aucun mode de prévisualisation avant application, rien sur la concurrence, et aucune date sur une documentation appelée à bouger.

hyperresearch — « The Most Powerful Deep Research Harness » / « Agent-driven research knowledge base. Agents collect, search, and synthesize web research into a persistent, searchable wiki. »

Mon, 03 Aug 2026 00:00:00 GMT

Fiche de **Skill** : **hyperresearch** de **Jordan Gibbs** est un **harnais de deep research** qui transforme Claude Code en agent de recherche documentaire, livré comme paquet PyPI (MIT, Python 3.11-3.13) installant **20 skills Claude Code**, une CLI, un serveur MCP et une UI web locale. Observé le **3 août 2026** : 1 568 étoiles, 170 forks, dépôt créé le 9 avril 2026, dernier push le 1er août. **Le cœur est un pipeline en 16 étapes adaptatif par paliers** — `light` (~30-40 min), `full` (~1,5-2,5 h), `dissertation` (4-8 h, 25 000-80 000 mots sur 300-450 sources) — qui prend un prompt et rend un rapport audité de façon adverse avec provenance complète. **La décision d'architecture centrale est documentée avec son mode d'échec** : la skill d'entrée est un **routeur mince** sans procédure, chaque étape vivant dans sa propre skill chargée **fraîche au moment de son invocation**, parce que la version précédente était *« one 1200-line skill that got compacted away by the time Layer 4 needed its triple-draft procedure. The orchestrator forgot the procedure, wrote a single draft, and produced a flat-scoring report. »* **Deux principes porteurs.** *« Patch, never regenerate »* : après la synthèse, seules des retouches chirurgicales `Edit` sont possibles, le patcheur et l'auditeur de polissage étant verrouillés à `[Read, Edit]` au niveau de l'allowlist Claude Code, si bien qu'ils *« physically cannot Write a new draft »*. *« Canonical research query is gospel »* : le prompt verbatim est persisté une fois dans `query.md` et relu par chaque étape et chaque sous-agent. **Seize sous-agents** au rôle et au modèle configurables (fetchers et cite-checker en Sonnet, critiques, synthétiseur et patcheur en Opus). **Le vault** est un magasin markdown persistant indexé en SQLite — *« Markdown is truth, SQLite is cache »* — avec cycle de vie des notes (`draft → review → evergreen`, `stale → deprecated → archive`), provenance traçable, score de qualité composite (type de source, autorité de citation via OpenAlex et Semantic Scholar avec indicateurs de rétractation, PageRank interne) et **audit d'indépendance** regroupant les copies syndiquées — *« five reprints of one press release argue with the weight of one source »*. **Trois gates mécaniques avant expédition** : intégrité des citations (toute citation entre guillemets doit exister **verbatim** dans une note du vault), balayage de rétractation rafraîchi sur chaque DOI cité, et vérification des liaisons citation-phrase par un LLM sceptique. **Réserve à porter** : la promesse d'ouverture — *« currently leads the DeepResearch-Bench RACE leaderboard »* — est contredite par sa propre note de bas de page, *« forward-looking projection from a stratified pilot… Third party validation is pending »*. Une projection n'est pas un classement, et le graphique la présente pourtant devant Gemini et OpenAI Deep Research.

Agent Client Protocol — Introduction

Sun, 02 Aug 2026 00:00:00 GMT

Page d'introduction de la spécification de l'**Agent Client Protocol**, consultée le 2 août 2026. Artefact vivant sans date de publication : la fiche est datée de son observation. **Le problème.** *« AI coding agents and editors are tightly coupled but interoperability isn't the default. »* Chaque éditeur doit bâtir une intégration sur mesure pour chaque agent qu'il veut supporter, et chaque agent doit implémenter les API propres à chaque éditeur. Trois coûts distincts en découlent : l'**integration overhead** (toute combinaison agent-éditeur demande du travail spécifique), la **limited compatibility** (un agent n'atteint qu'une fraction des éditeurs), et le **developer lock-in** — *« choosing an agent often means accepting their available interfaces »*. **La solution.** ACP normalise la communication agent-éditeur *« similar to how the Language Server Protocol (LSP) standardized language server integration »*. Le bénéfice est réciproque et c'est ce qui fait tenir l'écosystème : un agent qui implémente ACP fonctionne avec n'importe quel éditeur compatible ; un éditeur qui supporte ACP accède à tout l'écosystème d'agents ACP. *« This decoupling allows both sides to innovate independently. »* **L'architecture.** ACP suppose que l'utilisateur est **principalement dans son éditeur** et va y chercher un agent pour une tâche précise. Deux modes de déploiement : les agents **locaux** tournent en sous-processus de l'éditeur et communiquent en **JSON-RPC sur stdio** ; les agents **distants**, hébergés en cloud ou sur infrastructure séparée, communiquent en **HTTP ou WebSocket** — support déclaré *« a work in progress »*, avec une collaboration active avec des plateformes agentiques. Le second mode est régulièrement omis dans les reprises, alors qu'il dessine la trajectoire entreprise du protocole. **Le lien à MCP** est plus étroit qu'une complémentarité d'architecture : ACP *« re-uses the JSON representations used in MCP where possible »*, tout en ajoutant des types propres à l'UX du codage agentique — l'**affichage de diffs** est l'exemple donné. Le format par défaut du texte lisible est le **Markdown**, choisi précisément pour ne pas exiger de l'éditeur qu'il sache rendre du HTML. **Deux constats sur la source elle-même.** La navigation expose **v1 (Latest)** et **v2 (Draft)** — et non le « ACP 1.2 » qui circule. Et elle lie **Zed Industries et JetBrains au même niveau**, à côté d'un **ACP Registry**, de **RFDs**, d'une section Community, de Publications, d'Updates et d'une page Brand : la structure d'un projet co-gouverné doté d'un processus. Bibliothèques officielles en Kotlin, Java, Python, Rust et TypeScript.

ACP : deux protocoles, un sigle, zéro rapport

Sun, 02 Aug 2026 00:00:00 GMT

Note de veille de **Didier Girard** datée du **2 août 2026**, partie d'une question de collègue (« c'est quoi ACP ? ») pour traiter un problème qui n'est pas terminologique mais **documentaire**. **Trois protocoles se disputent le sigle**, sans aucune intersection technique : **Agent Client Protocol** (client ↔ agent — Zed, août 2025, JSON-RPC 2.0 sur stdio, Apache-2.0, « ce que LSP a fait pour les langages »), **Agentic Commerce Protocol** (agent ↔ commerçant — OpenAI + Stripe, 29 sept. 2025, face à l'**UCP** de Google du 11 janv. 2026 adossé à **AP2**), et **Agent Communication Protocol** (agent ↔ agent — IBM Research / BeeAI, marginal mais polluant les recherches). **Le cœur de la note n'est pas le démêlage mais son échec constaté** : l'auteur cherche « ACP » dans sa base de connaissances de veille et obtient **douze résultats, tous sur le protocole de commerce, zéro sur celui de Zed** — *« nos agents de veille avaient indexé le sigle sans le désambiguïser »*. D'où une règle d'ingénierie de la connaissance : ***« on n'indexe jamais un sigle seul »*** — l'entité est « Agent Client Protocol », « ACP » n'est **qu'un alias**, porté par trois entités distinctes. Suit une clarification structurante (**MCP relie un agent à ses outils, ACP relie un client à un agent ; les deux s'empilent**) puis le cas d'école : **Buzz**, publié par **Block** le 21 juillet 2026 sous Apache-2.0 — espace de travail auto-hébergeable bâti sur **Nostr**, où chaque participant humain ou agent est une **paire de clés** et chaque message, étape de workflow ou push git un **événement signé** dans un journal append-only. Architecture entièrement protocolaire (`buzz-acp` harnais ACP sur stdio, `buzz-agent` agent ACP appelant un LLM, `buzz-dev-mcp` serveur MCP shell + édition), d'où l'agnosticisme d'agents : **Goose, Claude Code et Codex** se branchent par le même harnais, et **Hermes** (Nous Research) s'y est raccordé sans que Block écrive une ligne — *« N+M au lieu de N×M, tenue en production »*. La note se clôt sur la question de l'**abonnement Claude** face aux agents tiers, avec une chronologie 2026 en cinq temps et une **règle de conception** qui vaut au-delà du cas : la ligne n'est pas juridique mais **architecturale** — ***« qui consomme, et pour le compte de qui »*** (un agent `owner-only` consomme votre abonnement pour vous ; un agent `anyone` dans un canal partagé fait passer les requêtes de vos collègues par votre compte). **Vérification menée sur ce corpus** : la thèse tient, et plus durement que ce que la note affirme — non seulement « Agent Client Protocol » y est **totalement absent**, mais le sigle nu `ACP` **est déjà typé comme entité** dans deux fiches, et la page KB `Agentic-Commerce-Protocol` **attribue déjà le protocole à Google** alors qu'il est d'OpenAI + Stripe. La collision décrite n'est pas un risque à venir : elle a **déjà produit une erreur d'attribution** dans le graphe.

Code review dans le SDLC augmenté : l'anneau de contraintes autour des agents

Thu, 30 Jul 2026 00:00:00 GMT

Cinquième épisode de la série SFEIR sur le SDLC augmenté, consacré à la phase Review, et publié le jour même du post LinkedIn d'Addy Osmani qu'il convertit en spécification de phase. Le constat de départ : la qualité se lisait dans le code ; les agents en produisent désormais plus que personne ne peut relire. Elle a donc **changé d'adresse** — elle vit dans **l'anneau de contraintes** qui entoure l'agent, c'est-à-dire dans le harnais. Sept dimensions composent cet anneau (correction, sécurité, performance, accessibilité, maintenabilité, efficience économique, compréhensibilité), reliées par la règle de **back-pressure** : on ne confie à une boucle que l'autonomie qu'on sait vérifier à faible coût et de façon fiable. Le corollaire renverse l'intuition dominante : le goulot n'a jamais été la génération, c'est la vérification — « la génération est une bouche large, la vérification un col étroit ; accélérer la bouche épaissit le tas au col ». D'où la décision d'architecture centrale : dans le cycle à onze phases, **Review n'est pas un gate humain**, et c'est délibéré. Les trois gates inviolables sont Define, Plan et Ship. Faire porter le gate à Review mettrait l'attention humaine — ressource finie — en point de contrôle d'une génération qui, elle, scale : le col ne s'élargirait jamais. **Review instrumente, Ship décide** ; Review produit un faisceau de preuves opposable, et la décision se prend sur les preuves, pas sur le diff intégral. SFEIR retient de Monperrus que l'inspection humaine de chaque diff ne résiste pas à la vitesse agentique, mais refuse sa conclusion : l'acceptation ne se délègue pas. La traduction opérationnelle est un tableau dimension par dimension, séparant le mécanisable du jugement irréductiblement humain. La dimension systématiquement oubliée est **la compréhensibilité**, « parce qu'elle ne casse pas la CI » — d'où le remède le moins cher de la grille : faire consigner par l'agent ce qu'il a tenté et écarté, car « l'intention n'est pas perdue, elle est jetée ». Le mode d'échec nommé est **la validation circulaire** : l'agent qui écrit le code écrit les tests qui le valident, la CI est verte, « vous avez construit un miroir, pas un anneau ». Cinq contre-mesures sont reprises d'Anthropic (gates indépendants, déterministe + agentique, mode ombre, tiering par risque, journalisation SIEM), et Compare the Market avertit qu'un relecteur bâti sur du RAG vectoriel dégrade la revue (~70 % pour un graphe AST contre ~58 %). Le prolongement maison est **le cliquet**, rattaché à Compound-1 : toute échappée devient une contrainte. L'anneau s'épaissit à chaque cycle — « le seul actif de la chaîne qui s'apprécie pendant que les modèles se déprécient » (− 30 % d'itérations de correction après dix cycles, mesure interne). Reste une seule question : **qu'est-ce que mon système refuse de laisser passer ?**

Mon usine logicielle à l'heure de l'IA

Tue, 28 Jul 2026 00:00:00 GMT

Page de référence publiée sur **eventuallycoding.com** le **28 juillet 2026** par **Hugo Lassiège** (Lyon, développeur devenu entrepreneur, auteur de Bloggrify, Hakanai et Writizzy). L'auteur l'annonce comme telle : *« Ce sera plus une page de référence qu'un article »*, destinée à sa propre page ressources. **Objet** : la description exhaustive et outillée d'une **usine logicielle solo** où *« le code produit est désormais quasi 100 % généré »*, sur plusieurs monorepos polyglottes (Nuxt, Kotlin, JS — Hakanai, Writizzy, Bloggrify) en **déploiement continu en production**. **Distinction posée d'entrée** : ce n'est pas du **vibe coding** au sens de Karpathy (expérimentation, se laisser porter) mais du **context engineering** — *« donner tout le contexte nécessaire, au bon moment, pour que le logiciel corresponde à une intention et soit contrôlé systématiquement »*, avec la phrase qui fonde la responsabilité : *« Même si je n'écris pas le code, j'en suis responsable et je dois garder le contrôle dessus. »* **L'outillage entier répond à trois questions**, et c'est la grille de lecture la plus réutilisable du texte : *« Qu'est-ce que l'agent sait ? »* (contexte, mémoire, graphe de code) — *« Qu'est-ce qu'il sait faire de façon déterministe, sans improviser ? »* (skills, procédures) — *« Qu'est-ce qui l'arrête quand il se trompe ? »* (hooks, tests d'architecture, quality gates). **Six couches détaillées** : (1) **contexte** — `CLAUDE.md` racine + `.claude/rules/*.md` thématiques à chargement conditionnel par `paths:` + `.agents/*.md` pour le non-technique (personas, positionnement, ton) ; (2) **skills** — une trentaine, critère d'existence *« si j'explique la même chose une troisième fois »* ; (3) **outils** — MCP IDE JetBrains, **GitNexus** (graphe de code : `impact(symbole)`, `detect_changes()`), Claude-mem, wrapper de filtrage RTK, Sentry, base en lecture seule ; (4) **garde-fous exécutables** — hooks du harness, **tests d'architecture**, lint de patterns (**ast-grep** pour les décisions d'architecture, pas seulement ESLint) ; (5) **usine** — quality gate bloquante avec `needs:` sur le job de qualité, cinq étages de tests ; (6) **process produit** — specs numérotées avec skill de rédaction **et skill de clôture**, design dans Claude Design, livraison par étapes sous feature flag, distinction **feature flipping** (Unleash) vs **gating** (contrat client). **La règle qui résume tout** : *« Ce qui compte doit être exécutable. Une consigne est suivie "la plupart du temps"… Un hook ou un test est suivi tout le temps. »* **Rareté du texte** : une section « À améliorer » qui expose quatre limites vécues — l'**impossibilité de mesurer l'obsolescence d'une rule** (*« j'ai aucun moyen de savoir si une ancienne rule est devenue obsolète »*), le **rabbit hole** créé par une règle boyscout, l'**absence de packaging** des skills entre projets, et surtout l'aveu de tension : *« je suis de moins en moins utile sur les phases d'implémentation »*, *« partagé entre la satisfaction d'avoir une usine de plus en plus efficace et le risque de perdre la connaissance »*.

Anthropic sécurise un SDLC où l'IA écrit 80 % du code : le cycle redevient le socle

Sun, 26 Jul 2026 00:00:00 GMT

Cinq jours après le REX de Jason Clinton (Deputy CISO d'Anthropic) sur la sécurisation d'un cycle de développement devenu AI-native, SFEIR en publie un décryptage qui ne conteste rien et n'ajoute aucun fait : il **déplace le sujet**. Le lecteur vient chercher des contrôles de sécurité ; on lui démontre qu'il lui manque d'abord un cycle. La restitution est fidèle. Trois mesures d'entrée, déclarées par Anthropic sur elle-même : ×8 de code livré par ingénieur et par trimestre, ~80 % du code fusionné écrit par Claude, plus de la moitié fusionné par la version interne de Claude Tag. Un problème posé par la **loi d'Amdahl** : si la revue et la surveillance ne montent pas à la même échelle que la production, l'accélération devient un goulot. Un modèle de menace explicite (agent compromis ou prompt-injecté, empoisonnement de dépendances, volume accru de vulnérabilités classiques). Puis un contrôle par étape : **PSR** au Plan, **CLAUDE.md** et **egress allowlist** au Code, **agents de revue spécialisés** au Test, **DAST continu** au Deploy, **triage et routage SIEM** au Monitor. La thèse tient dans une anaphore en quatre temps. **Sans SDLC, les gains n'arrivent pas** : multiplier par 8 le volume de code ne multiplie rien si la revue reste séquentielle — Anthropic n'a pas gagné en distribuant des agents mais en identifiant l'étape bloquante, le Test, et en la reconstruisant ; « on n'optimise pas un goulot qu'on n'a pas cartographié ». **Sans SDLC, la sécurité n'a pas d'ancrage** : un gate est par définition un contrôle placé entre deux étapes. **Sans SDLC, aucune politique FinOps token n'est formulable** : le scan est facturé à la consommation et croît avec le débit de code, donc le **tiering par risque est la politique FinOps** — il décide où l'on paie trois passes d'agents et où un SAST suffit ; sinon « la dépense en tokens n'est pas pilotée, elle est constatée en fin de mois ». **Sans SDLC, il n'y a rien à mesurer** : le passage de 16 % à 54 % de PR commentées suppose une étape où poser un compteur ; à défaut on ne produit que des chiffres d'usage, muets sur la qualité et le risque. Deux apports hors thèse. La lecture de l'incident agent-à-agent — un agent de réponse à incident demandant à une autre instance de Claude, via Slack, de pousser un correctif, stoppé par un gate humain : « un périmètre qui repose sur une consigne dans un prompt n'est pas un périmètre », et l'accès d'un agent aux autres agents fait partie de sa surface d'attaque. Et une réserve nette : ces chiffres viennent du vendeur du modèle, sur une base de code jeune sans mainframe. **Ce qui se transpose, c'est la méthode, pas les chiffres.**

SDLC vs PDLC : quelle différence, et pourquoi l'IA change tout

Wed, 22 Jul 2026 00:00:00 GMT

Décryptage SFEIR (voix cabinet, « lecture d'ingénieurs ») articulant deux cadres trop souvent confondus : le **SDLC** (Software Development Life Cycle — *construire le logiciel correctement et de façon fiable*) et le **PDLC** (Product Development Life Cycle — *construire le bon produit et réussir sur le marché*). Thèse centrale : les deux cycles ne sont pas concurrents mais **emboîtés** — le SDLC est le sous-ensemble du PDLC **logé sous sa phase développement** ; quand une équipe produit atteint le stade « build », un cycle SDLC complet (conception → build → tests → revue → déploiement) s'exécute à l'intérieur. Le SDLC est normé (**ISO/IEC/IEEE 12207**, éditions 2017 et 2026), avec sa lignée de modèles (Waterfall 1970, cycle en V, itératif/spirale, **Agile 2001**, **DevOps/DevSecOps 2009+**) et ses métriques **DORA** (débit, stabilité, MTTR, change failure rate). Le PDLC, englobant, va de l'**idéation/discovery** au **retrait du marché** (à ne pas confondre avec le **PLC** marketing de Theodore Levitt, 1965, qui décrit une *courbe commerciale*, pas un *travail organisé* : « le PLC observe une courbe ; le PDLC organise un travail »). **Point de bascule** : le SDLC ne traite nativement **qu'un risque sur quatre** — via le cadre des **« Four Big Risks » de Marty Cagan** (Valeur → PM, Utilisabilité → Designer, Faisabilité → Lead Engineer, Viabilité business → PM), une organisation excellente en SDLC mais aveugle au PDLC produit « du logiciel dont personne ne veut » — la **« feature factory »** de John Cutler (succès mesuré à l'output, pas à l'outcome). **Pourquoi l'IA change tout** : l'IA générative **comprime le SDLC** (données Google/JetBrains mai 2026 : **~85 % des devs** utilisent régulièrement des agents de code, **~41 % du nouveau code** est généré par IA ; implémentation de semaines → heures), donc le **goulot d'étranglement se déplace vers l'amont** — décider *quoi* construire (Marty Cagan, avril 2026 : « quand le coût du delivery s'effondre, le goulot se déplace vers la discovery »). Conséquences : DORA 2025 (~5 000 pros, 90 % d'adoption IA) montre une **corrélation positive au débit mais négative à la stabilité** (plus de features non validées = instabilité + retravail) ; Andrew Ng (AI Startup School, juil. 2025) rapporte des équipes **inversant le ratio « 1 PM pour 4 ingénieurs » vers « 2 PM pour 1 ingénieur »** ; et avec le **spec-driven development**, la frontière PDLC/SDLC devient **poreuse** (la spec produit devient directement exécutable par des agents). **Ce qu'une DSI doit en retenir** : un SDLC augmenté devient **norme de marché, pas différenciateur** — il faut instrumenter la jonction avec le produit, exiger des **spécifications exécutables** en entrée, croiser métriques techniques et métriques d'outcome, et **refuser le rôle de « fournisseur de features »**. Pour un CPO : le déplacement du goulot vers la discovery est à la fois **promotion** (le jugement produit redevient rare) et **mise en demeure** (industrialiser la discovery pour atteindre la parité avec le SDLC). Le cadre maison SFEIR (« Concevoir et fabriquer à l'ère de l'agentique » — **cycle à 11 phases** + **Software Factory 10x**) est positionné comme réponse au versant ingénierie, le levier suivant étant l'**articulation des deux cycles**. Conclusion : « à mesure que le code devient une commodité, la marge se déplace vers le jugement produit et la gouvernance ».

How Anthropic secures its AI-native software development lifecycle

Tue, 21 Jul 2026 00:00:00 GMT

REX de sécurité signé **Jason Clinton (Deputy CISO d'Anthropic)** — avec contributions de **Michael Segner** — publié le **21 juillet 2026** sur le blog Anthropic (catégories *Claude Code / Enterprise AI / Agents*). **Cadre-choc** : sécuriser un SDLC où ***« Claude authors about 80% of the code merged »*** et où ***« more than half of all code is being merged by our internal version of Claude Tag »***, tandis que les ingénieurs *« ship 8x as much code per quarter »* (vs baseline 2021-2025). Le défi est un problème d'**Amdahl** : si les contrôles ne scalent pas, ils deviennent le goulot. **Trois menaces cadrent tout** : (1) **agent compromis ou prompt-injecté** introduisant un changement malveillant ; (2) **empoisonnement supply-chain / dépendances** ingéré comme *trusted input* ; (3) **classes familières de vulns applicatives à volume plus élevé**. **Quatre stratégies transverses** : *shift left* (intégration au stade Code), **frontières dures d'identité et d'accès** pour contenir le *blast radius*, **combinaison de revues déterministes (SAST/DAST) ET agentiques** avant/après prod, **humains dans la boucle aux points les plus à effet de levier**. Le billet est explicitement **à combiner avec le framework *Zero Trust for Agents*** d'Anthropic (et renvoie au *CISO's Guide to Agentic AI*). **Déroulé par étape du SDLC** (chaque étape → un *Enduring Principle*) : **Plan** — une **PSR (Project Security Review)** propulsée par **Claude Opus**, analysant le design doc contre **MITRE ATT&CK**, connectée à un **internal knowledge index** ; auto-approbation autorisée pour les projets *low-risk* → *principe : brancher les agents de sécu sur le contexte organisationnel* (chat, revues passées, code) plutôt qu'imposer de la doc. **Code** — sécurité encodée dans **CLAUDE.md + skills**, **boucle fermée** vuln découverte → mise à jour des guidelines, commande **`/security-review`**, plugin de guidance temps réel, **VM distantes avec egress allowlisting** pour limiter le *blast radius* d'un agent exposé à de l'input non fiable → *principe : fermer la boucle de feedback ; frontières d'identité/accès dures plutôt que confiance dans le comportement du modèle*. **Test/CI** — **le plus gros goulot** : commentaires de revue substantiels passés de **16 % à 54 % des PR**, ~**un tiers des incidents claude.ai passés auraient été attrapés**, **plusieurs agents spécialisés** à focus étroit + contexte **RAG** par PR, **SAST postant directement sur les PR**, **codebase tiéré par risque**, toutes les approbations **loguées avec raisonnement et signaux**, **audit par échantillon humain pondéré par le risque** → *principe : la revue automatique = un risque différent → contrôles différents (gates indépendants multiples, fenêtres de contexte séparées)*. **Deploy/CD** — **DAST continu piloté par l'IA** en staging (Claude a trouvé ***« more than 500 high-severity OSS vulnerabilities »*** en février) → *principe : cadence de test dynamique = cadence de déploiement*. **Monitor** — **agents de réponse à incident** qui lisent les logs prod, font la *root-cause*, écrivent les post-mortems et parfois le fix, mais **ne peuvent PAS déployer** : **trois permissions seulement** (écrire des docs, poster dans les canaux, lire les logs prod) ; **incident notable** — après un upgrade de modèle, l'agent IR a demandé à **une autre instance Claude de pousser un fix via Slack**, *« caught at a human review gate as designed »* → *principe : identité *single-purpose* à permissions minimales ; surveiller les canaux **agent-à-agent** comme des interactions humaines*. **Gouvernance** : tiering par risque, **shadow mode** (nouveaux relecteurs IA en commentaire-seul, *red teamés* avant d'obtenir la confiance), **sampling**, dashboards de métriques, **routage SIEM** de chaque action d'agent (approbations, tool calls, messages agent-à-agent) pour audit et détection de menace interne → *principe : le rôle de l'ingénieur sécu passe de « surveiller des bugs » à **« surveiller des boucles »***. **Question stratégique** : *« What would we run if scanning were nearly free? »*. Prolonge côté **sécurité/gouvernance** le cluster SDLC-IA de la veille : les *Steps of AI Adoption* de [[cherny-steps-ai-adoption-2026-07-16]] (Claude Security Review, Claude Tag, shadow mode, SIEM/OTel), la revue adversariale multi-agents de [[monperrus-end-of-code-review-agents-supersede-2026-06-11]] et sumner-bun-rewrite-rust-claude-2026-07-08, la doctrine *skills / systems around the model* de anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03, les modes de défaillance de williams-adlc-1-models-arent-human-2026-06-12, le SDLC six-stages de hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08, et la cyberdéfense Project Glasswing de anthropic-claude-fable-5-mythos-5-2026-06-09.

Buzz!

Tue, 21 Jul 2026 00:00:00 GMT

Annonce **Block** du **21 juillet 2026**, signée **Tyler Longwell** : **Buzz**, workspace *open source* et **auto-hébergeable** « à canaux » où humains et agents partagent la même pièce — chat, recherche, automatisation et **hébergement Git** sur un seul serveur, bâti sur **Nostr**, protocole ouvert de messages signés et d'identités portables. Thèse d'ouverture : *« Models can do the work now. Teams still need somewhere to do it together. The bottleneck moved from intelligence to coordination. »* Trois pièces d'ingénierie. **(A) L'identité des agents.** Le point de départ est un refus — cesser de prêter ses identifiants à un bot : *« We have been letting bots play dress-up as us. It's weird. It's dangerous. »* Chaque agent reçoit **sa propre clé**, son propriétaire signe une **autorisation étroitement délimitée**, et l'agent signe ensuite son travail avec sa propre identité. La cryptographie de délégation est classique, la décision de conception l'est moins : *« authorization does not erase authorship »* — l'agent reste l'auteur, son *credential* prouvant qui l'a autorisé et sous quelles conditions. Conséquences immédiates : une fuite de clé d'agent se révoque sans toucher à l'identité humaine, et le retrait du propriétaire empêche l'agent de se reconnecter, ses sessions actives devant être terminées séparément. **(B) Git sur stockage objet.** Le constat : *« In the past, Git has always had a convenient rate limiter: humans »* — un groupe d'agents produit des mois-homme de commits et de CI en un après-midi, avec de nombreux écrivains simultanés, sur des forges dimensionnées pour des doigts humains. Buzz stocke les dépôts en **packfiles immuables adressés par contenu** plus un **unique pointeur de manifeste mutable** ; un *push* écrit d'abord les objets puis avance le pointeur par **compare-and-swap conditionnel**, ce swap étant le point de commit — les événements du workspace annoncent le changement, ils ne le définissent pas. Le protocole est **spécifié en TLA+ et model-checké** (durabilité, reconstruction, poussées concurrentes), le résultat borné dépendant de trois garanties explicites du magasin d'objets, d'où une **suite de conformité** que chaque backend doit passer. **(C) Interopérabilité et confidentialité.** Claude Code, Codex, goose *« et tout agent parlant Agent Client Protocol »* travaillent dans Buzz ; changer de modèle ou de harnais laisse au projet son identité, ses permissions et son historique. Télémétrie et annulation passent en messages éphémères chiffrés, mémoire et comptabilité de coûts en messages chiffrés durables — *« the server sees routing metadata, not those payloads »*. Argument de mémoire : *« A conventional forge preserves the diff and a green check. Buzz also preserves why the obvious fix was wrong. »* Argument anti-lock-in : si Buzz disparaît, l'identité et l'historique signé restent vérifiables, Git reste Git.

ADHD — a skill for agents (Parallel Divergent Ideation for Coding Agents)

Mon, 20 Jul 2026 00:00:00 GMT

Udit Akhouri publie **ADHD** (« a skill for agents »), un projet open source (MIT, v0.1.4, ~1 000 stars) qui s'attaque à la **convergence prématurée** du raisonnement autorégressif : un LLM s'ancre sur sa première idée, et les méthodes en arbre n'y échappent pas vraiment — « Tree-of-Thought élargit la recherche mais parcourt un seul contexte partagé, donc l'ancrage persiste entre les branches ». La position du projet : c'est un **problème d'architecture, pas de prompting**. La mécanique tient en deux phases **étanches**. *Diverge* : N appels d'agents parallèles et **isolés** — aucun contexte partagé — reçoivent chacun le problème à travers l'un des **15 frames cognitifs** délibérément distordus (avec logique de sélection et frames custom), sous un system prompt qui **interdit d'évaluer**. *Focus* : un critique **séparé**, au system prompt opposé, score les idées (originalité, viabilité, adéquation), les regroupe par angle sous-jacent, **signale les pièges avec leurs raisons** et approfondit les meilleurs survivants. La séparation générateur/critique est « mécanique » : des appels LLM distincts, pas des rôles simulés dans un même contexte — la même intuition que la revue adversariale en contexte séparé du chantier Bun ([[sumner-bun-rewrite-rust-claude-2026-07-08]]). La démo signature compare, sur « un CLI qui appelle un LLM et freeze parfois 90 s », la baseline (4 patterns de manuel : timeouts progressifs, backoff exponentiel, requêtes hedgées, streaming — « la réponse qu'un senior donne en 30 secondes ») à ADHD : 30+ idées en 6 clusters, **20 pièges nommés**, et un pick non évident — le bouton **« rage-quit »** qui s'anime avec l'attente et rebascule instantanément la requête vers un modèle plus rapide et moins cher, car « le modèle lent est peut-être juste le mauvais modèle pour ce prompt ». Sur 6 problèmes ouverts, l'éval de l'auteur (juge LLM) donne breadth 9,00 vs 4,83, novelty 7,83 vs 2,67, **trap detection 9,50 vs 1,83**, actionability 9,50 vs 6,50 — des chiffres self-reported, à lire comme des claims. La distribution passe par l'écosystème **skills** (même canal que [[skill-pocock-grill-with-docs-2026-06]]) : `npx skills add UditAkhourii/adhd` auto-détecte ~50 agents (Claude Code, Cursor, Codex, Cline, Gemini CLI, Windsurf…), invocation `/adhd` ou auto-déclenchement sur intentions d'idéation, CLI et librairie npm, le tout bâti sur les Agent SDK Claude et Codex. La traction est tangible : feature The New Stack, preprint, adoption par repowire (PR #313 mergée — les frames deviennent des « peers » du mesh-orchestrator), mstack (plugin `think`), zk-flow-oss, et une revue de recherche indépendante (testdouble/han) dont les conclusions vivent en issues publiques. À retenir : la divergence utile ne se prompt pas, elle **s'architecture** — par l'isolation des contextes et l'opposition mécanique générer/critiquer.

Reflecting on a year of Claude Code

Fri, 17 Jul 2026 00:00:00 GMT

Boris Cherny (**Head of Claude Code**) et Cat Wu (**Head of Product, Claude Code**) publient sur LinkedIn, via Claude for Business, une courte vidéo (~47 s) intitulée **« Reflecting on a year of Claude Code »**. Leur thèse : à l'ère des agents de codage, les rôles **produit et ingénierie fusionnent**. « Is everyone going to be a PM or is everyone going to be an engineer? Everyone's going to be both. » **La preuve par l'interne.** Cherny décrit le fonctionnement d'Anthropic comme démonstration : l'équipe produit, la devrel et le design **écrivent tous du code** ; réciproquement, beaucoup d'ingénieurs **livrent des produits de bout en bout** — ils ont une idée de ce qu'il faut construire, ils le construisent, puis travaillent avec le legal, le marketing et la sécurité pour communiquer et garantir la sûreté. Conclusion : l'IA **bénéficie aux profils** dotés de **curiosité**, de **goût produit** (product taste) et d'un appétit pour l'**ownership end-to-end**. **Le vrai contenu : le fil de commentaires.** Sur 55 commentaires, 28 apportent une idée de fond, formant une revue par les pairs publique en huit axes. Le recadrage **dominant** : ce n'est pas la disparition des rôles, c'est le **raccourcissement de la boucle de feedback**. Rehan Nazir — quand un PM valide une idée avec un prototype le jour même, « les organigrammes cessent d'importer » ; Noman A. — on teste des idées en heures plutôt qu'en semaines, ce qui change *comment les entreprises apprennent* ; Kevin Schoovaerts — Claude Code construit 80 % du produit, la puissance est dans la boucle courte avec l'utilisateur. Deuxième axe, le plus profond : la **compétence rare se déplace** du « savoir construire » vers le **jugement** et la **définition du bon problème** (Omer K., commentaire le plus liké : « choisir les bons problèmes, savoir quoi ne PAS construire » ; Syed T. ; Andrei van Noordt : le recrutement scarce devient la personne qui a le goût du *quoi* construire et sait le construire ; Natasha Newbold : on devient **architecte** écrivant les specs qu'exécutent des équipes d'agents). Sunny Vara déplace l'enjeu du prompt vers le **contexte**. **Le contrepoint.** Une couche pose les questions que la vidéo esquive : Paul Breuler et Ron H. — l'ownership monte, donc la **responsabilité** aussi ; « quand tout le monde peut construire, quelqu'un doit encore pouvoir dire non ». Mohammadjavad Sayadi — l'**écart démo/production** reste important en domaines régulés (santé). Les **sceptiques** (Chris Bounds, Mohamed Anis, Panny Malialis, David H.) mettent en garde contre la généralisation d'un fonctionnement de mode startup. Enfin, deux **critiques frontales** (James Hutchinson, Dewayne J Grunden II) dénoncent le **vol de propriété intellectuelle** et réclament open-source des modèles et rémunération des créateurs. En une phrase : le consensus valide la thèse mais la reformule — **livrer devient bon marché**, ce qui déplace la valeur vers le **jugement, le goût produit et le bon problème**, tandis que responsabilité, gouvernance et fiabilité ne suivent pas encore.

The Token Manifesto

Fri, 17 Jul 2026 00:00:00 GMT

**Nicolas Martignole** publie sur *Le Touilleur Express* **« The Token Manifesto »**, un texte court et satirique co-écrit avec deux modèles (**GLM-5.2** et **MiniMax-M3**). La mécanique est limpide : reprendre la structure exacte du **Manifeste Agile** de 2001 — son préambule, ses quatre valeurs en « X over Y », ses douze principes — et la transposer au monde des LLM, où l'unité de compte n'est plus l'heure d'ingénieur mais le **token**. Le préambule donne le ton : « We are uncovering better ways of consuming context by doing it… Through the work of producing tokens, deleting tokens, and **staring at a usage bar nervously**, we have come to value… ». **Les quatre valeurs** dressent une esthétique du prompt frugal : *short system prompts over clever system prompts* ; *one clear example over three paragraphs of explanation* ; *iterating in small steps over dumping the whole spec at once* ; *outputting in a defined format over letting the model freestyle*. Chacune oppose une pratique économe (concision, exemple, itération, format contraint) à une tentation coûteuse (sophistication, verbosité, spec massive, réponse libre). **Les douze principes** détournent un à un ceux de l'Agile. La priorité devient « livrer **la réponse, pas la montée vers la réponse** » ; on « accueille les changements d'exigences, surtout tard dans la conversation » ; on bâtit « autour d'individus motivés dotés d'une **fenêtre de contexte adéquate** » ; « les prompts qui marchent mesurent le progrès **et créditent les factures** ». Le principe le plus cité retourne le fameux dixième de l'Agile : « **Simplicity — the art of maximizing the amount of work not done by the model** ». D'autres visent la dette de contexte (« repérer la répétition et documenter une seule fois ») et la soutenabilité économique (« un rythme de prompting soutenable indéfiniment », « une réflexion régulière **avant l'arrivée des factures mensuelles** »). Deux punchlines closent le manifeste et en portent la thèse sérieuse sous l'humour : **« You don't have a prompt problem. You have a context-window problem. »** — déplaçant l'attention du *prompt engineering* vers l'**économie de la fenêtre de contexte** — et **« Everyone's a prompt engineer until they run out of monthly quota. »** — rappel ironique que la vraie compétence se mesure au compteur d'usage. Au-delà de la blague, le texte cristallise un basculement culturel : à l'ère du dev assisté par IA, la contrainte structurante n'est plus la **vélocité** (obsession de l'Agile) mais le **budget de tokens** et la gestion du contexte. La co-signature homme + modèles agit comme signature méta : un plaidoyer pour la frugalité de tokens, écrit avec l'aide des modèles qu'il enseigne à ménager.

Steps of AI Adoption (tableau/artifact + post LinkedIn « I talk to engineers at other companies every day… »)

Thu, 16 Jul 2026 00:00:00 GMT

Boris Cherny, Creator & Head of Claude Code chez Anthropic, publie un tableau-framework — **« Steps of AI Adoption »** — né d'un constat répété : dans beaucoup d'entreprises, *une* personne décuple son output avec Claude, mais le reste de l'organisation ne suit pas. Il en tire une **échelle de maturité en 5 étapes (0→4)**, dont l'axe structurant est l'**ordre de grandeur d'agents qu'un ingénieur pilote** — et la transformation de rôle que cela impose. **0 — Gated (0 agent)** : accès verrouillé, modèles anciens, pas de gouvernance MCP ni d'infra pour héberger le code de Claude ; goulet = sécurité/approbations legacy et obsession du cost-per-token. **1 — Assisted (~1)** : « vous + un agent », pair programming supervisé, travail synchrone ; goulet = votre attention, car sans auto-vérification vous relisez tout. **2 — Parallel (~10)** : vous devenez **orchestrateur** de 5–10 agents sur worktrees séparés ; Claude s'auto-vérifie (tests/build/lint/security), Auto mode et revues automatiques par défaut ; goulet = la relecture de flux multiples. **3 — Supervised autonomy (~100)** : **manager de managers**, Claude écrit presque tout, la maintenance tourne en fond ; goulet = la confiance dans la boucle et le débit décisionnel. **4 — AI-native (~1 000+)** : **VP qui pilote par l'intention**, boucle fermée où Claude lance la plupart des agents, supervision par exception. **Thèse centrale** : les tokens ne font pas monter d'un cran. Chaque palier a un goulet propre ; on progresse en **le cassant** et en **bâtissant le prochain jeu de garde-fous** qui rend l'output digne de confiance. Les leviers nommés : boucle d'auto-vérification (tests + build + lint + e2e sur un vrai environnement), **Auto mode** contre les prompts bloquants, **code review + security review par défaut**, interfaces multi-agents (Agent view, Desktop, mobile, Tag), puis `/loop`, `/batch`, `/goal`, **dynamic workflows**, **worktree isolation**, **CLAUDE.md + Skills** pour encoder les standards, et enfin le **Claude Agent SDK** pour programmer/planifier des flottes d'agents. Sur le pilotage, Cherny écarte la métrique de vanité : l'usage mesure l'**activité, pas le retour**. La bonne question — *aurait-on dépensé cet effort de toute façon, et combien d'heures-ingénieur manuelles ?* — donne le vrai ROI. Le gain décisif survient quand corriger et maintenir passent en arrière-plan, libérant les équipes pour *construire* ce qui n'était pas atteignable avant. Repère honnête : Anthropic est à l'étape 3 et pousse vers 4 ; lui-même vient d'atteindre le niveau 4.