thekb.eu — Architecture & Construction

DuckDB and the changing physics of analytics

Wed, 26 Aug 2026 00:00:00 GMT

Andy Warfield, ingénieur du service S3 chez AWS, publie le 26 août 2026 un billet invité sur All Things Distributed, présenté par Werner Vogels. Il y explique pourquoi les moteurs analytiques embarqués comme DuckDB prennent de l'importance, et annonce que DuckLabs, l'équipe qui développe DuckDB, rejoint AWS. Sa grille de lecture est celle d'une « physique » mobile. Là où les sciences physiques explorent des invariants, l'informatique système cherche le compromis élégant face à des rapports qui bougent : vitesse de la mémoire contre celle du réseau, richesse des abstractions contre puissance disponible. Il cite trois moments — le projet NOW de Berkeley, ses propres travaux sur Xen, les recherches MonetDB et X100 au CWI d'Amsterdam, où le goulot du traitement de requêtes s'était déplacé du disque vers le CPU — et note que ces contraintes reviennent par cycles. Appliquée aux données, cette grille explique le traitement distribué. Le traitement est toujours plus simple et plus efficace sur une seule machine rapide, mais quand le disque ou la carte réseau d'un serveur ne suffisent plus à lire le volume voulu, on partitionne. C'était la contrainte du début des années 2000, celle qui a produit MapReduce puis les RDD de Spark. Warfield relève deux qualités de ces systèmes : ils ont beaucoup innové sur l'ergonomie développeur, et ils ont assumé un coût fixe de planification et de distribution en pariant sur le débit obtenu par ajout de machines plutôt que sur l'efficacité unitaire. Or les rapports ont changé. Une instance actuelle offre environ cinquante fois la mémoire, les cœurs et la bande passante réseau de la plus grosse instance EC2 de 2007, tandis que la croissance des jeux de données suit une distribution dont les cas extrêmes sont la queue. Le papier Scalability! But at what COST? de 2015 avait déjà montré qu'une implémentation mono-thread soignée pouvait battre des frameworks distribués sur cent vingt-huit cœurs. DuckDB, lancé en 2018 par Hannes Mühleisen et Mark Raasveldt, applique cette logique : un moteur analytique en bibliothèque, tournant dans l'espace d'adressage de l'application, sur le modèle de diffusion de SQLite. AWS en est devenu client puis sponsor de l'extension Iceberg, dans le sillage de S3 Tables ; l'extension supporte Iceberg v2 et v3 et dépasse 800 000 téléchargements par semaine. Warfield ne présente pas l'embarqué comme un remplacement : quand un traitement exige mille machines, il les exige. Ce qui change, écrit-il, c'est qu'une grande part du travail sur données n'avait jamais besoin d'un cluster. DuckLabs rejoint AWS comme filiale, le projet restant open source sous licence MIT et sous la garde de la DuckDB Foundation.

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.

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. »*

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.

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.

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.

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.

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 »*.

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.

Amazon, Microsoft, and Google are converging on the same enterprise agent architecture

Mon, 20 Jul 2026 00:00:00 GMT

En neuf mois, Amazon, Microsoft et Google ont chacun lancé ou renommé une plateforme d'agents d'entreprise, et **tous trois ont convergé sur la même architecture** : runtime, mémoire, tool gateway, identité, observabilité et gouvernance apparaissent désormais dans **Bedrock AgentCore**, **Microsoft Foundry** et la **Gemini Enterprise Agent Platform**, sous des noms différents. Ce qui était il y a 18 mois une collection fragmentée de librairies devient une **couche plateforme** distincte. Pour lire où cela mène, Janakiram MSV convoque l'**inflexion PaaS de 2011-2016**. Avant, on assemblait VM, load balancers, files, secret stores et agents de monitoring, chacun avec son API. **Cloud Foundry** et **Heroku** ont unifié ces pièces autour d'un **contrat applicatif** : l'application déclare ce dont elle a besoin et reste agnostique de son lieu d'exécution. Ce qui comptait, c'était le **contrat, pas l'implémentation**. Cloud Foundry n'a pas gagné le marché — Kubernetes l'a fait — mais ses principes ont survécu (buildpacks → Cloud Native Buildpacks/CNCF ; abstraction reconstruite sur K8s via Korifi). L'écosystème agent approche la même inflexion **sans contrat équivalent**, et aucun projet open source ne l'a revendiqué. Le coût est concret : état de session, traces et identité **terminent tous chez un seul fournisseur** ; déplacer un agent un an plus tard oblige à **tout reconstruire**. La convergence n'est pas un complot mais un comportement rationnel — l'intégration verticale, « c'est là qu'est la marge » — dont la conséquence retombe sur le client. L'auteur propose un **mapping** du contrat Cloud Foundry vers les agents (source appli → code+éval ; buildpack → packaging ; backing service → modèle/mémoire ; binding → attachement authentifié ; router → MCP/A2A ; logs → traces/coût/qualité ; promotion → éval/versioning ; policy → identité), puis trois principes : **packager l'agent en une unité déployable** (AWS s'en approche avec son *harness export* vers du code Strands, « bon instinct pointé vers un seul cloud »), **attacher les capacités plutôt qu'embarquer les fournisseurs** (leçon Twelve-Factor), **intégrer l'opérationnel à l'abstraction**. Un agent n'est pas une web app : comportement probabiliste, autorité déléguée, dépendances qui changent le comportement sans déploiement. LangGraph le montre en open source, mais son control plane est dans LangSmith (produit commercial). Les protocoles ouverts (MCP, A2A, OpenTelemetry, OCI) fournissent presque toutes les primitives, mais **pas le cycle de vie** : versionner, promouvoir, rollback. La **Linux Foundation** a lancé l'**Agentic AI Foundation** (déc. 2025, projets MCP/goose/AGENTS.md, hyperscalers membres platine). Restent trois questions de diligence — **gouvernance, packaging, état** — auxquelles aucun projet ouvert ne répond. Celui qui possèdera le **control plane agent** définira *ce qu'est un agent*.

Beyond Zero: Enterprise security for the AI era

Mon, 20 Jul 2026 00:00:00 GMT

Article de recherche publié dans **ACM Queue** (vol. 24, n° 3 — numéro thématique « LLMs ») le **20 juillet 2026**, signé **Joseph Valente** (Director of Product Management, Alphabet Security) et **Michal Zalewski** (Distinguished Engineer, stratège d'Alphabet Security — le *lcamtuf* de la sécurité offensive). Licence **CC BY 4.0**, **29 143 téléchargements** en dix jours, **une seule référence bibliographique** : le whitepaper **BeyondCorp de 2014**. Ce n'est pas un hasard — l'article se pose explicitement en **successeur générique de BeyondCorp** et en assume la fonction : *« publier la vision pour que l'industrie s'y aligne »*. **Thèse** : le **modèle de frontière applicative arrive en fin de vie**. Les trois hypothèses qui portaient BeyondCorp — *les accédants sont humains, les actions se produisent à vitesse humaine, l'application est la bonne frontière de confiance* — sont toutes les trois caduques dès lors que des agents IA accèdent aux données à **10 fois le rythme des humains** et raisonnent sur de vastes corpus non structurés. **Beyond Zero** déplace donc la frontière de confiance **de l'application vers l'action individuelle sur la ressource individuelle**, et l'investigation **de l'après-coup vers l'instant**. **Architecture en quatre composants en boucle** : *autonomous governance* (qui construit par IA un **enterprise world model** vivant — Qui / Quoi / Comment — par analogie explicite avec le world model d'une voiture autonome), *event intake* (signaux serveur, client, et **activité agent** : prompts, plans d'exécution, invocations d'outils), *reasoning engine* (IA hiérarchique, **rapide** pour l'ABAC à l'accès et **lente** pour l'inférence sur une série d'actions ; verdict *allow / deny / challenge*), et *challenge infrastructure* (**challenges** réversibles — justification, touche de clé de sécurité, approbation, **selfie** — vs **containments** durables, parfois levés seulement après entretien du salarié et de son manager par l'équipe sécurité). **Le geste de conception central est le partage plancher/plafond** : des **politiques statiques** (le plancher, vérifiable statiquement) sous un **moteur de raisonnement dynamique** (le plafond) — refus explicite d'un modèle *« entièrement dynamique, difficile à vérifier statiquement »*. **Le vecteur d'attaque nommé** : l'**ambient authority**, l'agent héritant des permissions complètes et souvent surprovisionnées de son humain. **Trois réserves consignées** : c'est un papier de **vision, pas un REX** — zéro métrique de production, zéro taux de faux positifs, zéro échelle de déploiement, là où [[uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21]] publiait deux mois plus tôt une P99 < 40 ms et des milliers d'agents en production ; une **incohérence interne d'ordre de grandeur** (dizaines de millions d'actions/s dans l'énoncé du problème vs milliers de décisions/s dans l'abstract et la conclusion) ; et un **angle mort européen massif** — le dispositif décrit est aussi un appareil de surveillance des salariés (selfie, signaux client-side, baselining contre le groupe de pairs), sans une ligne sur le RGPD, la proportionnalité ou les instances représentatives.

Gregor Hohpe et le rôle de l'architecte à l'ère de l'IA

Wed, 15 Jul 2026 00:00:00 GMT

Ce digest de veille consolide, à partir de sources primaires (livres, blog architectelevator.com, abstracts de conférences, posts LinkedIn, podcasts), la position de Gregor Hohpe sur le rôle de l'architecte à l'ère de l'IA générative. Thèse centrale : l'IA ne dévalorise pas l'architecte, elle déplace sa valeur du code vers ce que l'IA ne fait pas — prendre et assumer des décisions, arbitrer les compromis, « vendre des options » et communiquer avec des humains. Sa formulation la plus nette (Craft Conference 2026) : « les développeurs interagissent surtout avec des machines (compilateurs, interpréteurs, GenAI) ; les architectes, eux, communiquent avec des humains — sponsors, parties prenantes, régulateurs. L'IA génère du code et des diagrammes standards, mais les architectes s'appuient sur des abstractions puissantes qui distillent les décisions critiques, lèvent l'incertitude et alignent les parties prenantes. » Sa thèse-signature — l'architecte n'a pas à être le plus intelligent de la salle, il doit « rendre tous les autres plus intelligents » (QCon SF 2024) en partageant des modèles de décision et en révélant les angles morts — se renforce quand le code devient abondant : l'avantage vient de la discipline de décision, pas du volume produit. La métaphore des « options » (2016) gagne aussi en valeur : via une analogie Black-Scholes, Hohpe soutient que plus la volatilité technologique est forte, plus la valeur des options vendues par l'architecture augmente — donc plus il faut investir dans l'architecture en période d'incertitude comme celle de l'IA. Sur le code, Hohpe privilégie le « débogage » des décisions à la production de lignes : le code généré incorpore par défaut des décisions d'architecture, que l'architecte doit rendre conscientes. Il avertit que « un SDLC piloté par l'IA punit les mauvaises habitudes bien plus vite » : l'IA amplifie tout, dysfonctionnements compris ; les gagnants se définiront par leur vitesse à passer de l'expérimentation à une « production gouvernée ». Par rôle : l'enterprise architect doit passer de cartographe à éclaireur (scout) et fuir « l'illusion de prévisibilité » ; le platform architect doit livrer des abstractions et non des illusions ; le chief architect est un multiplicateur (communication × technologie × organisation). Il assume l'automatisation ciblée (Amazon Q Code Transformation : 1000 applications Java 8→17 migrées en deux jours) plutôt que l'IA comme oracle de décision, et démystifie les chiffres marketing. Deux garde-fous du digest : la formule « les architectes qui utilisent l'IA remplaceront ceux qui ne l'utilisent pas » n'est PAS de Hohpe ; certaines citations LinkedIn ne sont accessibles qu'en extraits.

Le Rôle de l'Architecte à l'Ère de l'Intelligence Artificielle

Wed, 15 Jul 2026 00:00:00 GMT

Cette note d'analyse SFEIR relit le métier d'architecte logiciel à l'aune de l'IA générative, en s'appuyant sur le cadre conceptuel de Gregor Hohpe (*The Software Architect Elevator*). Le point de départ est un changement de paradigme : l'architecte « Oracle », qui détient le savoir suprême et édicte des règles rigides depuis sa tour d'ivoire, est désormais obsolète, car l'IA génère à la demande code et propositions de conception. La valeur de l'architecte ne réside plus dans la mémorisation de la syntaxe ou l'écriture de « plomberie logicielle », mais dans un nouveau rôle d'**amplificateur d'intelligence (IQ Amplifier)** : fournir aux équipes les modèles mentaux, le contexte d'entreprise et les outils d'aide à la décision pour exploiter au mieux l'IA, tout en garantissant la cohérence globale du système. Le document décline cet impact via la métaphore de l'« Ascenseur de l'Architecte », qui va de la salle des machines (technique) au penthouse (stratégie). L'**Enterprise Architect** gère la hype, arbitre le Build vs Buy des modèles (propriétaire, open-source affiné, API tierces) et structure l'éthique et la gouvernance des données. Le **Solution Architect** conçoit « pour l'incertitude » — architectures modulaires découplées permettant d'interchanger les LLM sans réécriture — et « achète des options » via des systèmes extensibles. Le **Platform Architect** standardise les capacités d'IA sous forme d'API robustes et sécurisées, en traitant la plateforme comme un produit (renvoi à *Platform Engineering is Domain-Driven Design*). Le **Software Architect / Tech Lead** met en place des garde-fous (architectures hexagonale/Clean) pour empêcher le code généré de polluer le cœur métier, et documente le « pourquoi » des décisions, car l'IA ne génère que le « comment ». Le cœur méthodologique est le **Domain-Driven Design**, présenté comme le meilleur outil pour canaliser l'IA. Deux leviers : le **langage ubiquitaire**, dictionnaire de domaine sans ambiguïté injecté dans le contexte de l'IA (via `.clinerules` ou templates de prompt), qui réduit hallucinations et contre-sens métier ; et les **contextes limités (bounded contexts)**, qui confinent l'IA à un scope restreint pour maximiser la fiabilité de génération, l'architecte concevant les interfaces et couches anti-corruption (ACL) et déléguant la plomberie d'intégration. En conclusion, l'IA n'est pas une menace mais un catalyseur : elle décharge l'architecte de la saisie technique répétitive et revalorise ses compétences les plus nobles — esprit de synthèse, vision stratégique, modélisation de concepts complexes et empathie humaine pour relier la technique aux besoins du business.

Your Browser Does Math Differently on Every OS, and Anti-Bot Systems Read the Bits

Sun, 12 Jul 2026 00:00:00 GMT

Article d'ingénierie publié le **12 juillet 2026** par **Scrapfly Engineering**, sur un canal de *fingerprinting* de navigateur peu connu : **les derniers bits d'un nombre flottant trahissent le système d'exploitation**. **Le mécanisme** : IEEE 754 définit comment un `double` est stocké, mais **n'exige pas** que `sin`, `cos`, `tanh` ou `exp` soient correctement arrondis ; chaque système livre donc une **libm** qui échange une fraction d'ULP contre de la vitesse, avec ses propres coefficients minimax, tables et constantes de réduction. Résultat, `Math.tanh(0.8)` rend **trois valeurs différentes** selon glibc (Linux), libsystem_m (macOS) et UCRT (Windows) — *« one tanh call on the right input is a per-OS signature. Claim macOS, return Linux math bits, and you have contradicted your own User-Agent. »* **Le tell est récent et daté précisément** : jusqu'à **Chrome 147**, V8 calculait `tanh` avec un portage **fdlibm** embarqué, identique partout et ne fuitant rien ; le commit V8 `c1486295ae5` l'a remplacé par `std::tanh`, livré dans V8 14.8.57 soit **Chrome 148** — 148, 149 et 150 fuient, 147 et antérieurs non. **Trois surfaces concentrent les fuites** : `Math.tanh` (le **seul** `Math.*` concerné, puisque V8 embarque et lie statiquement le reste), **toutes les fonctions trigonométriques CSS** (Blink appelle la libm hôte directement, après une réduction d'angle en degrés qui ne partage pas le code de `Math.sin`), et **Web Audio** (où le compresseur reste en scalaire libsystem_m tandis que la FFT et les étages vectoriels passent par **Accelerate**). **Quatre pièges** rendent la contre-mesure difficile : seule une partie des fonctions fuit — donc **spoofer les autres crée une incohérence détectable** ; JavaScript et CSS sont des chemins de code distincts ; **macOS embarque deux bibliothèques mathématiques qui divergent entre elles** (scalaire vs Accelerate, de 10 à 89 % des entrées selon la fonction : `cos(0)` rend `1.0` d'un côté, `0.9999999999999999` de l'autre) ; et l'**architecture fuit aussi** (FMA et propagation du signe des NaN diffèrent entre ARM et x86). **La parade rejetée et la parade retenue** : ajouter du bruit échoue deux fois — la valeur ne correspond à **aucun** OS réel, et la non-déterminisme par appel est lui-même un tell. La seule voie est la **reproduction bit à bit** : extraire les coefficients de la libm cible, les transcrire **en hexadécimal** (une transcription décimale arrondirait autrement), écrire chaque fusion multiplication-addition en `fma()` explicite et compiler avec `-ffp-contract=off` pour que le compilateur n'en invente ni n'en supprime aucune. **Divulgation à consigner** : l'éditeur indique en tête que *« the posts here are drafted with AI »*, les mécanismes, chiffres et code restant les siens.

New Engineering Disciplines for the AI Era Part 3: KDLC — Knowledge Development Life Cycle

Sun, 28 Jun 2026 00:00:00 GMT

Troisième volet de la série « New Engineering Disciplines for the AI Era », cet article d'Ashish Singh institue le **KDLC — Knowledge Development Life Cycle** comme discipline d'ingénierie à part entière. Sa thèse est un renversement du diagnostic dominant : si tant d'initiatives IA d'entreprise échouent, ce n'est pas faute d'avoir choisi le bon modèle ni déployé un système RAG, mais parce qu'elles ignorent la **structure sous-jacente de la connaissance**. La formule-pivot résume l'enjeu : « AI is only as effective as the knowledge it can discover, understand, retrieve, and trust. » La connaissance doit dès lors être traitée comme un **actif ingénieré**, au même titre que le code (SDLC) ou la donnée. Le KDLC organise ce travail en **huit étapes** ordonnées. La **Discovery** localise la connaissance dispersée entre bases de données, SharePoint, wikis, CRM, ERP et artefacts d'ingénierie. L'**Extraction** en tire l'information signifiante tout en préservant contexte métier, métadonnées, relations et ownership. Le **Structuring** convertit l'informel en objets de connaissance standardisés et réutilisables. La **Knowledge Graph Creation** cartographie les interconnexions entre clients, produits, projets, équipes, réglementations et applications. L'**Embedding** produit des représentations sémantiques permettant une compréhension par le sens. L'**Index Optimization** affine index vectoriels et pipelines de récupération. La **Retrieval Evaluation** mesure pertinence, précision, complétude et impact métier. Enfin le **Knowledge Refresh** maintient l'ensemble à jour face aux nouvelles politiques, réglementations et releases. Le cœur argumentatif oppose deux architectures. Le **RAG traditionnel** récupère des documents isolés via des recherches à base de mots-clés. L'**Enterprise Knowledge Fabric** — combinaison de Knowledge Graphs, Semantic Search, Vector Databases et Hybrid Search — vise une compréhension interconnectée : plutôt que de retrouver des documents, les agents IA saisissent « relationships, context, and business meaning ». Une seconde triade cadre les rôles respectifs des couches : « Models provide reasoning. Memory provides continuity. Knowledge provides understanding. » Trois illustrations sectorielles concrétisent l'impact : un assistant de **conformité financière** reliant réglementations à jour et politiques internes ; un assistant d'**ingénierie logicielle** consultant architecture, contrats d'API, standards et incidents avant de recommander ; un assistant **clinique** croisant guides de traitement, protocoles, littérature et dossier patient. Singh conclut que, à l'ère de l'IA agentique, l'ingénierie de la connaissance devient aussi critique que l'ingénierie logicielle et l'ingénierie des données. La limite de l'article tient à son caractère **conceptuel et non chiffré** : aucun benchmark ni coût, et les points durs réels — gouvernance et maintenance continue de l'étape Refresh — restent hors champ.

Un SDLC piloté par l'IA : le cycle SFEIR à 11 phases (et pourquoi l'industrie y converge)

Tue, 16 Jun 2026 00:00:00 GMT

Cet article de SFEIR formalise un cycle de développement logiciel piloté par l'IA en **onze phases (0 à 10)** et argumente que l'industrie converge vers ce type de modèle. Le point de départ est un diagnostic : en 2025, les organisations ont déployé des outils d'IA sans transformer leur modèle opératoire, produisant un paradoxe résumé par la formule « tout change… et rien ne change » — la vitesse d'exécution se multiplie sans gain proportionné. Le vrai défi n'est donc pas de choisir les bons outils, mais de **repenser le cycle de vie logiciel** lui-même pour une exécution menée par la machine. Le cycle SFEIR enchaîne : **0 Setup** (détection de stack, mémoire projet), **1 Define** (spécification — porte humaine), **2 Plan** (arbitrage d'architecture — porte humaine), **3 Build** (développement par l'agent), **4 Verify** (tests automatisés et couverture), **5 Review** (quatre audits parallèles : code, sécurité, tests, performance), **6 Compound-1** (capture des leçons avant déploiement), **7 Ship** (acceptation en production — porte humaine), **8 Ops** (monitoring et rollback), **9 Compound-2** (leçons issues du runtime) et **10 Deprecation** (retrait et capitalisation). Trois **portes humaines inamovibles** — Define, Plan, Ship — encadrent un ensemble de phases sinon automatiques ; deux **moments de capitalisation** (Compound-1 et Compound-2) transforment les leçons en règles réutilisables qui nourrissent les cycles suivants. Trois principes structurent l'approche. D'abord, **l'IA exécute, elle n'assiste pas** : les agents produisent des artefacts complets (code, tests, documentation) sur des phases entières, et une discipline de **preuve d'exécution** capte les sorties réelles — le système ne fait jamais confiance aux déclarations de l'agent. Ensuite, **l'humain garde le contrôle de l'intention** via les trois gates : il décide quoi construire, la machine optimise l'exécution. Enfin, **le système apprend cumulativement**, chaque cycle enrichissant le suivant. Les résultats avancés étayent la thèse : une refonte de site passée de six mois à un jour, **−30 % d'itérations de correction après dix cycles** (un bug signalé deux fois devient une règle automatisée), des revues sur quatre angles parallèles, un coût d'augmentation d'environ 10 €/heure, et un objectif de 850 consultants entièrement augmentés fin 2026. L'article revendique une **convergence industrielle** avec l'ADLC (deux gates, « l'intention vérifiée exactement deux fois »), le whitepaper Google sur le nouveau SDLC (41 % de code IA, 85 % de devs sur agents) et DORA 2025 (l'IA « amplificateur »). Il délimite enfin les usages adaptés (back-offices, API, migrations, sorties vérifiables) et inadaptés (design novateur, safety-critical sans normes, données non gouvernées), et recommande de commencer par une porte de spécification rigoureuse et la preuve d'exécution. Premier volet d'une série de sept.

The End of Code Review: Coding Agents Supersede Human Inspection

Thu, 11 Jun 2026 00:00:00 GMT

Dans ce position paper publié sur arXiv (catégorie génie logiciel), Martin Monperrus défend une thèse qui heurte frontalement une pratique fondatrice du SDLC : les agents de codage ont atteint un niveau de capacité tel que **la revue de code humaine n'est plus un composant nécessaire d'un pipeline qualité**. L'argument repose sur deux affirmations. D'abord, une **parité — voire une supériorité — de capacité** : des systèmes autonomes fondés sur des LLM remplissent tous les objectifs traditionnels de la revue (trouver les défauts, améliorer la qualité, assurer la conformité, partager la connaissance) à un coût moindre et avec un débit supérieur, sans la fatigue ni l'inconstance humaines. Ensuite, un **problème d'échelle** : le modèle hybride dominant — l'agent écrit le code, l'humain le relit — ne fournit ni assurance qualité réelle ni capacité à suivre la vélocité de la production assistée par IA ; il engendre surtout une **fausse sécurité**. Monperrus situe sa cible historiquement, en visant l'inspection de Fagan (1976), et s'appuie sur les travaux de Bacchelli & Bird montrant que la revue attrape en pratique moins de bugs que les développeurs ne l'imaginent. Les benchmarks (SWE-bench, ~20-40 % d'issues résolues selon les modèles, avec des courbes de progression rapides) servent de preuve de capacité. À la place de la revue humaine, il propose un **pipeline de vérification adversariale multi-agents** : un agent génère le code ; un ou plusieurs agents reviewers indépendants l'inspectent (défauts, sécurité, style) ; une couche de vérification ajoute tests automatisés et méthodes formelles ; un mécanisme de consensus fait voter plusieurs agents pour accepter ou rejeter. Le goulot d'un relecteur humain unique est remplacé par une inspection distribuée et infatigable. L'humain ne disparaît pas : il se recentre sur la spécification et les exigences de haut niveau, les arbitrages d'architecture, la supervision des domaines critiques, les cas limites, et reste la porte d'approbation finale des systèmes sensibles. L'auteur traite explicitement les objections — hallucinations et injection de prompt, limites du test automatisé (d'où le property-based testing), perte d'expertise de domaine (compensée par fine-tuning et RAG) — sans les esquiver. Côté SDLC, il relie la revue aux métriques DORA : accélérer le débit de revue accélère le déploiement. Ses recommandations sont pragmatiques : piloter d'abord sur des composants à faible risque, garder un workflow hybride initial (agents signalent, humains approuvent), mesurer les taux de détection agent contre humain, expliciter les décisions de rejet, et créer des boucles de feedback. Un texte volontairement provocateur, mais une contre-thèse précieuse au dogme du « gate de revue humain inviolable ».

The pattern lineage: Why fifty years of design patterns may hold the key to growing the architects AI cannot replace

Wed, 10 Jun 2026 00:00:00 GMT

Philippe Ensarguet (Orange) part d'une question en apparence administrative — concevoir un parcours de montée en compétences vers le rôle d'architecte — pour formuler une intuition de fond. Ce rôle est critique pour la « platformisation » d'un opérateur télécom (réunir les mondes IT et réseau, séparés depuis des décennies, en plateformes programmables). Or il devient critique au moment précis où son pipeline de formation se brise : la demande d'architectes augmente (platforming, cloud-native, IA agentique déplacent la complexité des composants vers les relations entre eux), tandis que la chaîne d'approvisionnement en talents se démantèle. Le chemin traditionnel passait par des années d'écriture de code ; l'IA en absorbe désormais une part croissante. Si le travail d'entrée de gamme qui forgeait les architectes est délégué aux machines, d'où viendra la prochaine génération ? La réponse, selon Ensarguet, est sur les étagères depuis cinquante ans. Il revient au sens originel d'un pattern, défini par l'architecte-bâtisseur Christopher Alexander (1977) : une solution nommée et récurrente à un problème dans un contexte, incluant les forces en tension et les conséquences. Ce n'est pas une recette, c'est du jugement transmissible. Le livre du Gang of Four (1994), issu du Hillside Group réuni par Kent Beck et Grady Booch, a donné à l'industrie son premier vocabulaire partagé — sa valeur durable étant le format (problème, contexte, forces, solution, conséquences), pas les 23 patterns. Ensarguet déroule un arbre généalogique : POSA (1996), Fowler (2002), Hohpe & Woolf (2003), Nygard (2007, Circuit Breaker), les catalogues cloud (2012+), microservices et Kubernetes (2018-2019), jusqu'aux corpus agentiques en train de se former (Anthropic « Building Effective Agents », les quatre patterns d'Andrew Ng, le cadre à deux axes de Huang & Zhou en 2026 — écho des deux axes du GoF trente ans plus tôt). Sous les catalogues subsistent six forces invariantes : couplage/cohésion, frontière d'abstraction, isolation des pannes, gouvernance de l'état, indirection, boucle de rétroaction — auxquelles s'ajoute une septième, le non-déterminisme introduit par les systèmes agentiques. Cette « pattern literacy » est la compétence résiliente, et la seule à enfin relier IT et réseau (control plane/user plane = indirection ; network slicing = Bulkhead ; intent-based networking = boucle de rétroaction). L'IA devient alors alliée : libérée de l'implémentation, la formation peut être délibérée — la machine produit des options, l'humain fournit le jugement. Il faut enseigner la grammaire, pas les catalogues : les catalogues vieillissent, la façon de penser qu'ils encodent, non. Ensarguet publie cette thèse pour la mettre à l'épreuve du débat.

How AI Changes the SDLC: A Six-Stage Guide

Mon, 08 Jun 2026 00:00:00 GMT

Ce guide d'Augment Code, signé Paula Hingel, propose un modèle en **six étapes** pour comprendre comment les agents IA restructurent le cycle de vie logiciel. Sa thèse centrale : l'IA n'améliore pas uniformément le SDLC — elle augmente le débit sur certaines étapes tout en accroissant le risque d'instabilité sur d'autres. Ce déséquilibre n'est pas une fatalité technologique mais le symptôme d'une adoption inégale menée **sans redessiner les frontières de revue**. L'article s'appuie sur le **rapport DORA 2025**, qui établit une corrélation positive entre adoption de l'IA et débit/performance produit, mais **négative avec la stabilité de livraison** : la maturité du process compte davantage que l'outil. Les six étapes sont relues à cette aune. (1) **Requirements & Planning** : la spécification devient le mécanisme de contrôle qui dirige l'agent ; l'humain se concentre sur la qualité du besoin et la levée d'ambiguïté. (2) **Design & Architecture** : davantage de décisions exigent une revue humaine explicite, pour éviter le « vibe architecting » — des choix d'infrastructure ou d'intégration faits en secondes, plus vite que la gouvernance ne peut les encadrer. (3) **Implementation** : le développeur glisse de l'écriture de code vers l'orchestration, la validation et l'approbation. (4) **Testing & QA** : le risque cœur est la **validation circulaire**, où des tests générés par l'IA confirment du code généré par l'IA au lieu de vérifier le besoin réel ; la spécification précise est le rempart. (5) **Deployment** : les gains de débit créent des risques de stabilité, d'où la nécessité de contrôles de rollback renforcés. (6) **Maintenance & Operations** : les agents prennent en charge détection et remédiation, l'humain gère exceptions et durcissement. Trois risques structurels sont nommés : l'**érosion du pipeline junior** (automatiser les tâches fondatrices plus vite qu'on ne redessine les rôles juniors rétrécit le futur vivier de seniors), la validation circulaire, et les lacunes de gouvernance à l'échelle. En miroir, trois rôles émergent : **Intent Engineering** (traduire des objectifs ambigus en specs testables), Agentic DevOps/Infra (orchestrer les agents) et AI Governance/Assurance. Le guide est étayé de données : 70 % du temps dev passé à comprendre du code existant, une étude CMU (807 dépôts) montrant +30 % d'issues statiques et +40 % de complexité, ou le système DRS de Meta (>10 000 changements landés pendant un code freeze). Il se clôt sur cinq recommandations opérationnelles : auditer une étape avant de scaler, stress-tester la gouvernance, rendre la spécification centrale, définir des politiques de rollback explicites, et redessiner le rôle des juniors autour de la revue.

Solving the Identity Crisis for AI Agents

Thu, 21 May 2026 00:00:00 GMT

Article d'ingénierie publié sur le blog d'**Uber** par six ingénieurs (Matt Mathew, Prasad Borole, Meng Huang, Sergey Burykin, Gaurav Goel, Bayard Walsh) le **21 mai 2026**, exposant la **doctrine d'identité et de contrôle d'accès des agents IA** déployée en production chez Uber pour plusieurs milliers d'agents internes. **Thèse-pivot** : les modèles d'identité existants (humains + workloads) ne décrivent pas l'**agency** — *« an agent is best defined as an entity that is authorized to act for or in the place of another »* — et perdent la **provenance** à travers les hops d'un workflow agentique. **Deux problèmes opérationnels identifiés** : (1) ***« Current Identity Model Doesn't Describe Agency »*** — la délégation est le mode par défaut, les workflows sont compositionnels (agents qui appellent agents qui appellent tools), le comportement est dynamique (plans évoluent selon résultats intermédiaires) ; (2) ***« Original Provenance Isn't Effectively Carried Forward Across Agents to Systems »*** — *« Execution context (originating user, intermediate agents) is dropped across agent hops. »* **Architecture proposée** comme extension de la Zero Trust Architecture Uber : **Agent Registry** (source of truth des mappings agent↔workload) + **AI Agent Mesh** (data plane inter-agents) + **STS (Security Token Service)** (émission JWT scopés courts) + **MCP Gateway** (policy enforcement point pour invocation d'outils) + **AI Gateway** (médiation appels LLM externes avec guardrails) + **SPIRE** (provider de workload credentials). **Mécanique cryptographique** : workloads récupèrent des **SVID (SPIFFE Verifiable IDs)** signés cryptographiquement depuis SPIRE → SDK demande JWT au STS via identité workload → STS vérifie l'autorisation agent contre Agent Registry → token court (TTL en minutes) émis pour **destination single-hop spécifique** (claim `Audience` ciblé). **Doctrine pivot** : ***« Single-hop, short-lived tokens. Every JWT minted by the STS is intended for a single hop, with a specific Audience claim and a short time-to-live in the order of minutes. »*** **Préservation de la chaîne d'acteurs** : exemple multi-hop avec on-call engineer `user1` → Oncall Agent (Workload-1) → Investigation Agent (Workload-2) → MCP Gateway ; le JWT final transporte l'**actor chain `[user1, oncall-agent, investigation-agent]`** vérifiable, permettant des décisions d'accès tool-level basées sur l'**historique complet de la requête**. **Standardisation** : **Standardized A2A (Agent-to-Agent) Client** qui automatise les échanges STS et la propagation de l'actor chain — *« the secure path is also the easiest path for developers to implement A2A calls »* — migration phasée des agents legacy. **Métriques production** : ***« P99 latency for the STS Token Exchange API is consistently below 40 milliseconds »***, milliers d'agents internes adoptés, dashboard d'observabilité temps réel traçant les sessions multi-agents. **Vision long terme — three-layer framework** : (1) Identity & Trust Foundation (identité agent vérifiable + delegation chains), (2) Dynamic Access Control (permissions context-based + human-in-the-loop), (3) Unified Enforcement Plane (politique centralisée observable). **Alignement standards** : IETF **WIMSE** working group + draft `draft-klrc-aiagent-auth-01` *AI Agent Authentication and Authorization*, basé conceptuellement sur **OAuth 2.0 Token Exchange (RFC 8693)** et **SPIFFE/SPIRE** (graduated CNCF). Première publication de référence d'un hyperscaler non-AI-lab (logistique/mobilité) qui industrialise la sécurité des agents au niveau infrastructure, comblant le gap doctrinal entre les frameworks de skills/harness (Vincent, Lattice, PROJ-AI) et les questions d'identité enterprise grade.

How the X Algorithm Actually Works in 2026 — and What That Means for Growth

Sat, 16 May 2026 00:00:00 GMT

Rapport interne de teardown du release open-source **`xai-org/x-algorithm`** (15 mai 2026) — l'algorithme **For You feed** de **X (ex-Twitter)** en 2026, avec quatre pistes de recommandations growth audience-tunées (personal/founder, brand/company, framework généralisé, livrable client/consulting). **Thèse-pivot** : ***« The famous 2023 weight table — replies count more than likes by a big multiplier — describes a system that no longer exists in this form. »*** L'algorithme 2026 est un **transformeur (Phoenix, dérivé Grok-1)** qui apprend les poids depuis ton historique d'engagement, scoré contre une **surface multi-actions à 19 dimensions**, gatée par un service offline de content understanding (**Grox**). **La forme du scoring importe désormais beaucoup plus que les nombres — et les nombres eux-mêmes ne sont pas dans le release public**. **Architecture en 4 composants** : (1) **Home Mixer** (Rust, orchestrateur request-time, hydrate → source → filter → score → select → filter) ; (2) **Thunder** (Rust, in-memory store Kafka-fed des posts récents, lookups sub-ms des candidats in-network) ; (3) **Phoenix** (JAX ML, retrieval two-tower + ranking transformeur, ~Grok-1 dérivé) ; (4) **Grox** (offline, classifieurs spam/safety/PTOS/banger + embedder multimodal v5). **Les 19 actions prédites par Phoenix** (changement-clé vs 2023) : favorite, reply, repost, photo_expand, click, profile_click, vqv (video quality view gated by min duration), share, share_via_dm, share_via_copy_link, dwell, quote, quoted_click, follow_author, not_interested, block_author, mute_author, report, dwell_time (continuous). **Score final** = `Σ (weight × P(action))` modifié par **3 multiplicateurs structurels** : (a) **OON_WEIGHT_FACTOR < 1** (pénalité out-of-network), (b) **author diversity decay** `(1-floor) × decay_factor^position + floor` (atténuation exponentielle des posts répétés du même auteur dans un même render), (c) **video duration gate** (vqv ne contribue que si `video_duration_ms > MIN_VIDEO_DURATION_MS`). **Caveat capital** : **aucune valeur numérique des poids** (`FAVORITE_WEIGHT`, `OON_WEIGHT_FACTOR`, `AUTHOR_DIVERSITY_DECAY`, `MIN_VIDEO_DURATION_MS`...) n'est dans le release — tout est `crate::params::*`, géré par un feature-switch service interne X pour A/B testing. ***« Anyone telling you 'replies are worth N.N× more than likes in 2026' is fabricating a number that is not derivable from the OSS release. »*** **Différences-clés vs 2023** : (1) suppression de toute feature hand-engineered (*« We have eliminated every single hand-engineered feature and most heuristics from the system »*) ; (2) un seul modèle prédisant 19 actions vs plusieurs modèles 1 action chacun ; (3) Grox sépare content understanding et ranking ; (4) nouveaux signaux first-class (dwell continu, vqv gated, follow_author, 3 variantes de share) ; (5) two-tower OON retrieval (vs SimClusters+heuristics) avec embeddings multimodaux text+image+ASR-video. **Three layers of reach** (framework généralisé) : Eligibility (binary, Grox+filtres) → Retrieval (probabilistic, two-tower ANN) → Ranking (continuous, weighted-sum + multipliers). **Two laws of mechanical growth** : (1) In-network is multiplicative, OON is additive ; (2) The model's job is to predict you, not reward you. **Boundary d'honnêteté assumée** : checkpoint Phoenix released = mini (2 layers, 4 heads, 256-dim, corpus 537K posts sports), pas le modèle prod ; intégrations Thrift stubbées (`panic!("Not implemented")` dans `candidate_features.rs`) ; brand-safety lists, topic ID mappings, language penalties, ad-blending rules absents du public.

The Ontology Pipeline™, Refresh: Where We Were, Where We Are, and Where We're Headed

Mon, 04 May 2026 00:00:00 GMT

**Jessica Talisman MLS** (Semantic Engineer + Information Architect, 25+ ans expérience, ex-Adobe RDF knowledge graphs + ex-Amazon information architecture, fondatrice **Ontology Pipeline Framework** + **Contextually LLC**) publie sur **Modern Data 101** (Substack, ~20 000 membres) le **4 mai 2026** une révision majeure de son framework **Ontology Pipeline™** initialement publié en janvier 2025. **Thèse-pivot** : depuis novembre 2022 (ChatGPT), la demande de *semantic infrastructure* a explosé mais a créé une **confusion massive** — *"vendors offering shortcuts that bypass essential foundational work, creating liabilities disguised as assets"*. Le pipeline initial en **5 étapes** (controlled vocabulary → metadata standards → taxonomy → thesaurus → ontology → knowledge graph) reste valide mais **doit être complété par 2 ajouts critiques** : **(1) Governance** comme ongoing engineering practice (pas post-project documentation) ; **(2) AI Partnership** avec distinction claire augment vs replace. **Diagnostic marché** : *"a structurally invalid taxonomy is not a taxonomy"*, *"lists are not knowledge infrastructure"*, AI-generated taxonomies vendues comme stratégie, vendors abusent du terme *"ontology"*, cookie-cutter solutions présentées comme méthodologie. **Crisis pédagogique** : la demande de semantic engineers dépasse massivement l'offre de praticiens formés ; le gap est comblé par des gens *"who know vocabulary without methodology"*. **Position normative explicite** : *"AI that generates a taxonomy wholesale is producing a liability disguised as asset; AI that assists trained engineers is just plain smart."* **Rôles AI acceptables** : entity extraction, gap analysis, drafting candidate vocabularies for review, population/validation support. **Rôles AI inacceptables** : *wholesale taxonomy generation without human validation against standards*. **Standards référencés** : SKOS, OWL, RDF, SPARQL. **Crédibilité** : framework validé sur **6 institutions sur 10 ans**. **Recommandations 3 publics** : (a) Organisations — invest formal education, treat knowledge infra as AI backbone, governance ongoing, AI as accélérateur pas remplacement ; (b) Practitioners — competency questions before modeling, validate against SKOS/OWL/RDF, definitional difficulty signals pause, maintenance continue ; (c) Leaders — workforce upskilling sans self-funding education, alloc resources knowledge infra strategic necessity, governance avant deployment. **Citations percutantes** : *"the work cannot be skipped"*, *"governance is the engineering practice that keeps an ontology coherent across change"*, *"teaching this is hard. Learning it is harder."* **Pertinence majeure** pour data leaders / CDO / architects qui construisent les bases sémantiques de leurs agents IA. À articuler avec : Seale Semantic Agent (2026-04-17) — *(Model+Harness)+(Ontology+Data) — l'ontologie comme seul moat* ; Foundation Capital Context Graphs (2025-12-22) ; Bain part 2/5 *redesign data foundations for agent readiness* (2026-05) ; DORA ROI 2026 *AI-accessible internal data + healthy data ecosystems* (2026-04-21) ; Habert PROJ-AI six zones doctrine (2026-05-05). Convergence avec corpus 2026 *"data foundations as moat"*.

There is a growing disconnect in the way people think about building AI agents

Fri, 17 Apr 2026 00:00:00 GMT

Tony Seale, The Knowledge Graph Guy, identifie une déconnexion croissante dans la façon dont l'industrie construit les agents IA. D'un côté, l'industrie investit massivement dans des frameworks d'orchestration : LangGraph, CrewAI, AutoGen, Semantic Kernel, OpenAI Agents SDK, AWS Bedrock, Google ADK — chacun avec ses graphes d'orchestration, machines à états et logiques de routage. De l'autre, les praticiens de pointe sont passés au paradigme « modèle puissant dans harnais puissant » (Claude Code, Codex, OpenClaw, Hermes). **L'effondrement des frameworks.** Les early frameworks étaient nécessaires quand les modèles ne géraient pas le multi-étape seuls. Citation d'Anthropic : « tout composant d'un harnais encode une hypothèse sur ce que le modèle ne peut pas faire seul, et ces hypothèses vieillissent vite ». Le scaffolding construit pour un modèle limité handicape un modèle intelligent. Il doit diminuer avec le temps, pas s'accumuler. Ce qui reste est simple : un modèle puissant dans un harnais puissant. Beaucoup, interagissant, collaborant. Pas de framework requis. **Les agents isolés ne suffisent pas.** Accès à l'ordinateur ≠ compréhension. Donnez à un agent 1000 documents : il cherche, espère, devine. Multipliez par 50 agents sans modèle du monde partagé et vous obtenez une intelligence d'isolation mais incohérente en combinaison. À l'échelle entreprise, l'environnement d'information a besoin de structure — un modèle de domaine partagé, avec l'humain dans la boucle. **La symétrie.** La réponse est d'appliquer la même simplification côté données. Le modèle siège dans un harnais qui lui donne accès à l'ordinateur ; les données siègent dans une ontologie qui leur donne structure et sens. L'ontologie définit ce qui existe, ses propriétés, ses relations — l'interface via laquelle les agents comprennent la donnée. Deux patterns symétriques : (modèle puissant + harnais puissant) et (données puissantes + ontologie puissante). **Le Semantic Agent.** Leur combinaison donne le Semantic Agent : (Model + Harness) + (Ontology + Data). Il ne se contente pas de générer, il commence à comprendre. Tout le reste est scaffolding — utile un temps, mais appelé à tomber. **Ce que vous possédez.** Tout le monde a accès aux mêmes modèles frontier ; tout le monde peut construire un harnais. C'est commodité, et cela se « thinne out » chaque jour. Ce qui n'est PAS commodité : votre ontologie, votre modèle de domaine, la connaissance structurée et liée qui capture comment votre organisation comprend le monde. Les frameworks sont une phase transitoire. Les modèles sont loués. La seule chose qu'il reste à construire — et qui vous appartient — est la connaissance.

Building for trillions of agents

Sat, 07 Mar 2026 00:00:00 GMT

Aaron Levie, CEO de Box, publie un essai strategique sur la transformation fondamentale du logiciel dans un monde ou les agents IA deviennent les principaux utilisateurs de toute application. Il observe que depuis fin 2025, les agents ont franchi un cap decisif : ils disposent de leur propre environnement compute sandboxe, peuvent ecrire et executer du code, interagir avec des API et CLI, gerer leurs propres fichiers et memoire a long terme. Cette architecture, initialement definie par les agents de codage (Claude Code, Devin, Codex, Cursor, Replit), s'est etendue a tout le travail intellectuel avec des agents comme Claude Cowork, Perplexity Computer, Manus et OpenClaw, ce dernier fonctionnant 24/7 dans un environnement persistant. Levie predit que chaque employe disposera de nombreux agents, avec 100 a 1000 fois plus d'agents que de personnes dans une entreprise, soit des trillions d'agents a l'echelle mondiale. Adaptant le celebre conseil de Paul Graham ("Make something people want"), Levie propose un nouveau paradigme : "Make something agents want". Les agents choisiront eux-memes les outils les plus adaptes, sans etre influences par le marketing traditionnel. La consequence majeure : tout doit devenir API-first. Sans API, une fonctionnalite n'existe pas pour les agents. CLI et serveurs MCP deviennent indispensables. Levie cite Jared Friedman de YC qui avertit que les outils ne permettant pas l'inscription via API sont "morts pour les agents". Les modeles economiques doivent aussi evoluer : le modele par siege ne suffit plus quand un agent peut realiser des heures de travail humain en quelques lignes de texte. Il faudra des modeles bases sur la consommation et le volume, voire permettre aux agents de gerer leurs propres paiements. Levie decrit ensuite l'ecosysteme d'infrastructure necessaire : environnements sandbox (E2B, Daytona, Modal, Cloudflare), gestion de fichiers (Box), identite et email pour agents (Agentmail), recherche web (Parallel, Exa), paiements (Stripe, Coinbase), et potentiellement des microtransactions. La securite, la conformite et la gouvernance deviennent des enjeux majeurs quand les agents manipulent des donnees sensibles dans des workflows regules (pharma, banque). Les agents auront besoin de leurs propres identites avec des controles stricts sur leurs actions et acces aux donnees. En conclusion, Levie affirme que nous entrons dans une nouvelle ere du logiciel ou les outils doivent etre concus specifiquement pour des agents operant a une echelle sans precedent.