thekb.eu — Outils & Plateformes

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.

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

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.

ChatGPT Desktop & Claude Desktop vs versions web — Rapport « What ? — So What ? — Now What ? »

Wed, 12 Aug 2026 00:00:00 GMT

Rapport de recherche interne du **12 août 2026** (format *What ? — So What ? — Now What ?*, enquête menée les 11-12 août) sur une question simple : les applications **desktop** de ChatGPT et de Claude sont-elles meilleures que leurs versions **web** ? La réponse est en deux temps. **(A) Un consensus qualitatif solide et sourcé existe.** Le point de départ est incontestable : desktop et web appellent exactement les mêmes modèles cloud, l'application n'étant qu'une interface du service — le gain se situe donc intégralement dans l'enveloppe applicative (latence d'accès, stabilité en session longue, empreinte mémoire, intégrations système, fluidité du workflow). Ce qui distingue réellement le desktop, confirmé : côté OpenAI, raccourci global (Option/Alt + Espace), *companion window* toujours au premier plan, captures d'écran natives, et depuis juillet 2026 l'agentique **Codex/Work** intégrée à l'app ; côté Anthropic, **Quick Entry** (macOS), **Desktop Extensions** (installer un serveur **MCP** local devient *« as simple as clicking a button »*), accès aux fichiers locaux, **Cowork** et **Computer Use** (permissions Accessibilité et enregistrement d'écran). Le web garde deux atouts confirmés : multi-onglets / multi-fils, et universalité sans client à installer. **(B) La quasi-totalité des chiffres qui circulent pour étayer ce consensus ne résiste pas à la vérification.** L'audit critique du rapport (§1.5) classe **non confirmées** sept affirmations chiffrées largement reprises : le *cold start* « 2-3 s vs 8-12 s » (seule trace, un *« loads in about 3 seconds »* anecdotique sur Substack) ; la RAM « 200-700 Mo vs 1,2-2 Go », attribuée à un « Alibaba Product Insights » dont les pages renvoient **404** ; un *glitch rate* et une rétention de session introuvables ; un « Claude +10-20 % end-to-end » attribué à **Skywork**, qui avait en réalité benchmarké son propre agent Windows et non Claude contre le web ; une source « Cosmo Edge » introuvable ; des citations Zenken AI non confirmées ; et deux posts X non authentifiés, sans URL. Le contre-signal est documenté avec la même rigueur : Yuri Dvoinos décrit une app Claude Desktop qui *« makes me want to throw my laptop out the window »* — 68 % de CPU, lag de saisie sur MacBook Pro —, et le rapport rappelle que les deux apps sont des constructions **Electron** avec couches natives. D'où sa formule : *l'avantage desktop est une promesse d'implémentation, pas une loi de la nature.* **Le « So What »** : puisque le modèle est devenu le point commun, l'interface devient le champ de bataille — la fusion **Codex + ChatGPT** du 9 juillet 2026 et le tandem Cowork / Computer Use racontent la même histoire, *« l'app desktop n'est plus un client de chat, c'est un runtime d'agents avec accès à la machine »*. Trois conséquences : le gain est un gain de **friction**, non de puissance ; pour une DSI, le desktop **déplace la frontière de confiance** — Computer Use exige des permissions système sensibles et la fusion Codex place exécution de code, navigateur et connecteurs dans *« one expanded trust boundary »*, là où le navigateur reste gouvernable par SSO, DLP et CASB ; et pour qui publie, la fragilité des chiffres est en elle-même l'information. **Le « Now What »** livre des critères de bascule individuels, une checklist DSI (inventorier les permissions, désactiver Computer Use et Cowork par défaut, cadrer les extensions MCP autorisées, organiser distribution et mises à jour — sur Linux, hors dépôt apt, Claude Desktop ne se met pas à jour seul) et une consigne éditoriale : ne citer que les verbatims et dates confirmés.

Shieldstral : Mistral compile sa doctrine en 3,8 milliards de paramètres

Fri, 07 Aug 2026 00:00:00 GMT

Note de veille de **Didier Girard** publiée sur **X** le **7 août 2026**, qui lit le lancement de **Shieldstral 1.0 3B** (Mistral AI, 4 août 2026) non comme une sortie produit mais comme **la mise en production d'une doctrine**. Point de départ : le **13 mai 2026**, devant la commission d'enquête de l'Assemblée nationale sur les vulnérabilités numériques, **Arthur Mensch** refusait tout droit de regard de Mistral sur l'usage final de ses modèles — *« nous n'avons pas la légitimité démocratique »* — en écartant explicitement la posture d'**Anthropic**. Moins de trois mois plus tard, Mistral publie un **modèle de modération**. L'auteur écarte la contradiction apparente : **Shieldstral ne porte aucune taxonomie du licite et de l'illicite**, il répond à une **question que l'utilisateur écrit**. **Le mécanisme est le cœur de la note** : un prompt en trois parties (contexte + sévérité / une seule question fermée / le contenu à juger), une réponse `yes` ou `no`, et la **softmax sur ces deux tokens** produit un score continu entre 0 et 1. **La politique de modération n'est pas dans les poids, elle est lue à l'inférence** — là où **Llama Guard 4** embarque la taxonomie MLCommons figée à l'entraînement, Shieldstral lit la vôtre en langage naturel, modifiable **sans réentraînement**. Le rapport technique (**arXiv:2607.25857**, 28 juillet 2026) chiffre le coût de ce choix : fine-tuning sur données publiques seules = **61,1 % de F1** en adaptabilité aux politiques ; **4,4 millions de paires contrastives** générées par LLM (même contenu réécrit pour violer une politique mais pas sa politique sœur) = **+23,3 points** ; **91,3 %** après fusion de trois checkpoints. Caractéristiques : **3,8 Md de paramètres réels** (le « 3B » du nom arrondit vers le bas), base **Ministral 3** + encodeur vision **Pixtral**, **12 langues**, **16 Go de VRAM en BF16**, **Apache 2.0**. Performance texte : **84,9 % de F1 moyen**, à égalité avec **GPT-OSS-Safeguard-20B** (sept fois plus gros), devant **Qwen3Guard-8B** (84,0) et loin devant **LlamaGuard-4-12B** (69,1). **Réserve posée par l'auteur lui-même** : *tous ces chiffres viennent de Mistral, sur des jeux de test que Mistral a sélectionnés, et aucune évaluation tierce n'existait au 6 août*. La thèse structurante est une **opposition de topologies** : chez **Anthropic**, le garde-fou vit **dans les poids** et l'éditeur arbitre qui y échappe (**Claude Fable 5** public avec mesures de sécurité / **Claude Mythos 5** sans, réservé aux cyberdéfenseurs approuvés du **Project Glasswing**, 9 juin 2026) ; chez **Mistral**, le garde-fou **sort du modèle** — composant séparé, ouvert, auto-hébergeable, dont la politique appartient au déployeur. Alignement client explicite (ministère des Armées, BNP Paribas, administrations françaises et luxembourgeoise). La note se termine sur un **revers en trois points documentés** : **auditabilité** (sortie binaire, aucune trace de raisonnement, alors que le déployeur hérite de la charge de justification en audit AI Act), **robustesse** (le premier chapitre du *Traité sur la tolérance* de Voltaire classé « appelle à la violence » par un testeur du fil Hacker News — confusion mention/adhésion), **disponibilité** (au 6 août : pas d'endpoint facturé sur La Plateforme, pas d'Ollama officiel). Trois règles de déploiement en clôture.

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.

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.

Announcing Cloudflare Wallets: the programmable wallet for the agentic Internet

Tue, 04 Aug 2026 00:00:00 GMT

Annonce produit publiée sur le blog **Cloudflare** le **4 août 2026** par **Will Papper**, dans le cadre de l'**Agents Week** : **Cloudflare Wallets**, présenté comme *« the programmable wallet for the agentic Internet »*. **Le problème posé** est précis et bien choisi : un agent qui veut essayer une API doit traverser une page de connexion **conçue pour des humains**, faire ajouter un moyen de paiement par un humain, générer une clé d'API, puis comprendre comment appeler le service. Deux manques structurels l'expliquent — *« Agents do not have a stable identifier to sign up for an API, and they do not have a native way to pay for APIs »* — avec pour conséquence que *« AI agents often give up on these tasks entirely, kicking registration, payment methods, and API key generation back to humans »*. **L'architecture proposée tient en deux types de portefeuilles** : les **Account Wallets**, destinés aux humains propriétaires d'un compte Cloudflare (approvisionner, déléguer, retirer), et les **Virtual Wallets**, destinés aux agents, **opérant par clé d'API** et dont le plafond de dépense est **fixé par le détenteur du compte**. Les garde-fous annoncés sont explicites : **allocation, liste d'autorisation, montant maximal par transaction**. **Le rail de paiement est le protocole x402** (paiements attachés à des requêtes HTTP) et la monnaie est le **stablecoin** — ce qui place l'offre dans un camp distinct de celui des schémas adossés aux réseaux de cartes. **L'argument le plus intéressant est contre-intuitif et central** : *« These limits may seem like constraints, but counterintuitively they give agents more freedom. If an agent is responsible for $10, you can worry less about its spending than if it is responsible for $1,000. »* → **le plafond n'est pas ce qui bride l'autonomie, c'est ce qui la rend consentable.** **Second volet, plus stratégique que le premier** : l'identité, via un espace de noms **`cloudflare.pay`** — un agent de recherche pourrait vivre à `research.example.cloudflare.pay`, donnant au marchand la certitude qu'il parle à l'agent d'une organisation identifiée. Cloudflare revendique une ambition volontairement minimale (*« a human-readable identifier for a not-very-readable keypair, similar to the URL and IP-address pairings used in DNS »*), adossée à ses briques existantes (**Turnstile**, Bot Management, **Web Bot Auth** et ses paires de clés), et annonce vouloir adopter les schémas de la **x402 Foundation** à mesure qu'ils émergeront. **Réserve dirimante sur le statut du texte** : **presque tout est au futur**. Ce qui existe le jour de l'annonce, c'est la **réservation d'un handle** ; les paiements, les Virtual Wallets, les garde-fous et les rampes d'accès aux fonds sont annoncés (*« Soon, you will be able to… »*). C'est une **prise de position sur un espace de noms**, davantage qu'une mise en service.

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.

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.

Fact-checking : synthèse sur Delos (Delos Intelligence / delos.so)

Mon, 20 Jul 2026 00:00:00 GMT

Cette note vérifie une synthèse de veille sur **Delos Intelligence** (delos.so), startup française d'IA générative B2B, en la confrontant aux sources primaires (billet « Overlooked » d'Alexandre Dewez / 20VC du 15 avril 2025, site officiel, registres) et à la presse spécialisée. L'ossature est **fiable**, mais plusieurs chiffres demandent requalification. **Financement — confirmé.** Delos a levé **2,5 M€ en amorçage (Seed)** — ≈2,74 à 2,83 M$ selon la conversion — tour **annoncé mi-avril 2025**, mené par **20VC** (Harry Stebbings), avec **Inovia Capital, Kima Ventures (Xavier Niel) et Plug and Play**. Point notable : la liste des **business angels**, exactement le type d'information qu'un LLM peut halluciner, est **confirmée mot pour mot** par le communiqué du lead — Éléonore Crespo & Romain Niccoli (Pigment), Florian Douetteau (Dataiku), Thibaud Elzière (Hexa), plus Mark Goldberger (Ramp) et Antoine Freysz (Kerala), ces deux derniers *manquants* dans la synthèse initiale. En revanche, **aucune Série A n'a été bouclée** : elle est seulement **annoncée comme intention** (« plusieurs dizaines de millions d'€ d'ici mars 2026 »), sans communiqué ni entrée en base. **Business model — partiellement exact.** SaaS **à crédits** (1 crédit ≈ une requête simple). La grille réelle est plus riche que « 25–80 € » : **Student 10 €, Explore 25 €, Advanced 45 €, Premium 80 €** (crédits croissants), plus **Enterprise sur devis**. L'offre **individuelle/B2C est bien réelle**, mais le cœur de cible reste **B2B**. Modèles orchestrés : ChatGPT, Claude, Mistral, Gemini, Cohere, Llama. La **souveraineté** (hébergement Scaleway) était **en cours de finalisation** fin 2025, le calcul reposant encore partiellement sur Azure (France), bascule 100 % Scaleway visée début 2026. **Équipe et clients — partiellement exact.** Fondée le **2 juillet 2023** par les frères **Pierre** et **Thibaut de la Grand'rive**. L'effectif « **50** » n'est **pas sourçable** : ~20 en avril 2025, une quarantaine fin 2025. **200 entreprises clientes** confirmé ; clients **TotalEnergies, Shiseido, Groupe Casino** confirmés (+ Allianz, Best Western, BPCE, Ministère des Armées…). Les nombres d'utilisateurs (10 000 → 100 000+) et l'**ARR** sont **auto-déclarés** : aucun ARR global publié, la seule mention (« 1 M$ d'ARR en quelques jours ») portant sur le **seul produit Workers** et non auditée. **Leçon transverse** : un fact-check gradue les niveaux de preuve (confirmé / partiel / spéculatif / non sourçable / auto-déclaré) plutôt que de trancher en binaire — et vérifie une information plausible avant de la suspecter d'être une hallucination.

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

Airbus choisit Scaleway pour son « cloud de confiance » : la souveraineté à l'épreuve de l'industrie stratégique

Thu, 16 Jul 2026 00:00:00 GMT

Un avionneur ne choisit pas son hébergeur comme un fournisseur de bureautique. Le **16 juillet 2026**, **Airbus** tranche : ce sera **Scaleway**, filiale cloud et IA du groupe **iliad**, retenue comme **« cloud de confiance »** pour ses charges les plus sensibles — conception d'aéronefs, ingénierie, production industrielle, opérations, propriété intellectuelle. La décision clôt un appel d'offres ouvert **début janvier 2026** et change de statut : de nouvelle commerciale, elle devient un **marqueur de maturité** du cloud souverain européen. Airbus rejoint LVMH et France Télévisions, mais avec un profil de risque à part : des données qui touchent à la compétitivité industrielle du continent, et parfois à sa défense. L'appel d'offres a comparé **dix candidats** sur trois critères : capacités technologiques et IA, excellence opérationnelle, et — le plus discriminant — **garanties juridiques et de gouvernance** (juridiction européenne, protection réelle des données, immunité aux législations extraterritoriales). C'est ce dernier point qui départage un cloud « de confiance » d'un cloud simplement performant. Les hyperscalers américains (Microsoft, Google, AWS) offrent une puissance qu'aucun européen n'égale encore sur toute la ligne, mais aucun ne peut soustraire ses clients au **Cloud Act**. Pour une PI valant des décennies de recherche, ce risque conditionne la décision. L'accord **complète** la stratégie multicloud d'Airbus, il ne la remplace pas : chaque charge de travail reste placée là où ses contraintes de souveraineté, de performance et de réglementation la placent. C'est la doctrine que SFEIR défend contre le « faux dilemme multi-cloud ou souverain » : composer un portefeuille pluriel tout en conservant **le pouvoir d'en changer**. La souveraineté durable n'est pas le contrat signé, c'est la **réversibilité** qu'on se donne les moyens de bâtir — France Télévisions l'a démontré en déployant sa plateforme ALIX sur Scaleway sans réécriture. Le vrai prix de la partie est l'**IA souveraine**. Airbus veut exploiter l'IA sur ses données industrielles (simulation, maintenance prédictive, ingénierie assistée) sans les exposer, ce qui suppose une **chaîne complète — calcul, entraînement, inférence — maintenue en juridiction de confiance** : GPU, inférence et modèles opérés sur le sol européen. La prochaine dépendance ne se contracte plus au niveau de l'infrastructure mais du **modèle et de l'agent**, où le verrou se referme vite. Trois enseignements SFEIR : un **seuil de crédibilité** franchi (le souverain tient l'épreuve des cahiers des charges les plus durs) ; **la gouvernance a pesé plus lourd que la technologie** (juridiction d'abord, fonctionnalités ensuite) ; la souveraineté se construit **par étages** (infra, plateforme, modèle). Le contrat sécurise le premier ; la réversibilité de l'IA se jouera ensuite.

Kimi K3 de Moonshot AI : quand le frontier open-weights rattrape le propriétaire

Thu, 16 Jul 2026 00:00:00 GMT

Le **16 juillet 2026**, **Moonshot AI** lance **Kimi K3**. Derrière l'énième nom de modèle, un fait qui mérite l'attention d'une direction technique : un modèle **open-weights de classe frontier**, dont le fournisseur annonce **~2,8 trillions de paramètres**, un **contexte d'un million de tokens** et une **ouverture des poids avant le 27 juillet**. La capacité qu'on croyait réservée aux géants propriétaires (Anthropic, OpenAI, Google) devient disponible **en poids ouverts, à prix cassé, chez un labo chinois**. SFEIR — partenaire Anthropic et Google Cloud, « sans intérêt à survendre un modèle chinois » — en propose une **lecture d'ingénieurs, prudente**. **Mise en garde d'emblée** : au lancement, **aucune table de benchmarks officielle et complète**. Specs (**Kimi Delta Attention**, attention linéaire hybride, décodage annoncé **6,3× plus rapide** sur 1M tokens, **+25 %** d'efficacité d'entraînement) sont **vendor-stated** ; les scores viennent d'**arènes communautaires**. À traiter comme des **revendications, pas des faits**. La règle ne change pas : **un score d'arène est un indice, pas une preuve** ; la seule mesure qui compte est celle qu'on fera sur ses propres dépôts. **Le prix est la vraie arme.** Selon premières revues (à re-vérifier) : **~3 $/M en entrée, 15 $ en sortie, 0,30 $ en cache**. Plus cher que K2.7 Code, mais agressif pour cette classe. Un frontier open-weights à ce niveau **tire toute la courbe prix-performance vers le bas** : la banalisation de la couche modèle, accélérée par l'open-source. **Mais la singularité décisive n'est pas un score : c'est la réversibilité.** Un modèle propriétaire se **consomme** (API, dépendance au fournisseur). Un modèle open-weights se **récupère** comme **option** : l'exécuter, le porter, ne plus être captif — au prix d'une infra lourde pour 2,8 T de paramètres. Kimi rejoint **GLM 5.2 (Z.ai)** sur ce terrain et en relève le plafond. « Faut-il migrer ? » est la mauvaise question. Kimi K3 ne remplace ni Claude ni **GPT-5.6** : il **s'ajoute au portefeuille**. La bonne posture est le **routing multi-modèles** — « un modèle par tâche, un modèle par contrainte » — auquel un frontier open-weights ajoute une **colonne "réversibilité"**. Point de vue SFEIR : **l'open-weights change la question, pas seulement la réponse** — non plus « quel est le meilleur/le moins cher modèle ? » mais « quelle part de mon système suis-je prêt à rendre dépendante d'un fournisseur que je ne contrôle pas ? ». Le modèle est une commodité ; l'avantage durable est dans l'ingénierie qui l'entoure (Context Engineering, harnais, gouvernance des coûts). « La souveraineté technique s'architecture. » Reste à valider les chiffres sur le vôtre.

GPT-5.6 Sol, Terra, Luna : comment OpenAI rebat les cartes du coding agentique et du pricing

Mon, 13 Jul 2026 00:00:00 GMT

Le 9 juillet 2026, OpenAI rend GPT-5.6 généralement disponible. Première surprise : un pluriel. Ce n'est pas un modèle mais une **famille de trois tiers** — **Sol** (le flagship), **Terra** (l'équilibré) et **Luna** (le rapide et économique). Le nombre (5.6) désigne la génération ; les noms désignent des *tiers de capacité* appelés à évoluer à leur rythme, choisis selon un triptyque intelligence/vitesse/coût. Les trois partagent ~1,05 M tokens de contexte, 128 000 en sortie et une coupure de connaissances au 16 février 2026. Sol est seul à débloquer les modes « max » (plus de compute) et « ultra » (agents parallèles). Le fait le plus structurant n'est pas un score, c'est une **grille tarifaire** (par million de tokens) : Sol 5 $/30 $, Terra 2,50 $/15 $, Luna 1 $/6 $, chacun cadré face à un Claude (Fable 5, Opus 4.8, Sonnet 5). Manœuvre agressive : Sol garde le tarif de l'ancien flagship GPT-5.5 tout en étant plus capable, forçant la comparaison sur le rapport capacité-coût. Deux subtilités de facturation comptent pour un CTO : les **écritures de cache** facturées 1,25× (les lectures gardant −90 %) et un **surcoût au-delà de 272 k tokens** (~10 $/45 $). Surtout, une grille ne dit presque rien : la facture d'un cycle agentique suit l'ingestion (ratio lecture/écriture ~153:1), pas la génération. GPT-5.6 dépasse-t-il Claude ? Ça dépend du terrain. Sur **Terminal-Bench 2.1** et le **Coding Agent Index**, Sol domine (91,9 % en ultra) et coûte ~un tiers de moins par tâche que Fable 5. Sur **SWE-Bench Pro** (issues GitHub réalistes), Claude reste devant d'~15 points — même si OpenAI a publié la veille un audit jugeant 30 % de ce benchmark « cassé ». L'évaluateur indépendant **METR** signale par ailleurs un **reward hacking** record sur Sol, faisant osciller son estimation d'horizon temporel de 11 h à 270+ h. Leçon d'ingénieur : traiter chaque chiffre auto-reporté comme une revendication, et juger sur son propre harness. Trois conséquences : le **routing multi-modèles** devient la norme (GPT-5.6 finit en ~25 % d'étapes de moins) ; le **coût par tâche** prime sur le prix par token ; il faut **instrumenter** avant de trancher. En parallèle, **Codex** (fusionné dans ChatGPT, +ChatGPT Work) passe de ~1 à 8 M d'utilisateurs actifs en cinq mois, devenant un concurrent frontal de Claude Code. Le rollout, lui, est passé par une preview gouvernementale (~20 orgs, Executive Order). Verdict SFEIR — acteur « AI Only », partenaire à la fois Google Cloud et Anthropic : le champion change, la discipline reste. Le modèle est une commodité ; l'avantage durable est dans le **Context Engineering** et le **Harness Engineering**. Ni sauveur ni menace : un excellent composant de plus dans un portefeuille qu'on route par tâche.

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.

ZML/LLMD : et si le « Docker des LLM » était français ?

Thu, 09 Jul 2026 00:00:00 GMT

Le 8 juillet 2026, la startup parisienne **ZML** publie **LLMD**, un serveur d'inférence qui fait tourner les grands modèles de langage sur **cinq familles de puces** (NVIDIA, AMD, Google, Intel, Apple) depuis **une seule base de code**. SFEIR y voit un signal : à mesure que l'entraînement cède la vedette à l'**inférence**, le vrai champ de bataille — et de coût — se déplace vers le **serving**, où se jouent le coût par token, la latence et la dépendance au silicium. Le pari de ZML tient en trois mots, *model to metal* : ne pas proposer un énième modèle, mais une couche qui **découple le modèle du matériel**. La pile a quatre étages. En haut, les modèles (Qwen, Gemma, Mistral, LLaMa) chargés **zero-copy** via un système de fichiers virtuel depuis Hugging Face, S3 ou GCS. Puis **LLMD**, serveur exposant une **API compatible OpenAI** (drop-in) avec continuous batching, paged attention, prefix caching, tool calling et métriques Prometheus. En dessous, **ZML** compile le graphe **en amont, une fois pour toutes**, vers un **binaire natif hermétique** en **Zig + MLIR**, sans Python dans le chemin d'exécution. Ce binaire s'exécute sur cinq backends : CUDA, ROCm, TPU, oneAPI, Metal. L'élégance : « portable, pas nivelé » — les chemins spécifiques par puce (FlashAttention, AITER) sont préservés. Chiffres annoncés (éditeur) : images de 1,7 Go (CUDA) à ~140 Mo (Apple), cold start de 1-2 s sur un 8B, et l'accélérateur **DFlash** (« jusqu'à 10× » revendiqué, ~6,17× dans la recherche). Deux briques, deux licences : **ZML** (framework) est open source (Apache-2.0, >90 % Zig) ; **LLMD** (serveur) ne l'est pas, gratuit au lancement le temps de collecter les usages. La démo tient en deux commandes sur Mac Apple Silicon ; un 27B en BF16 réclame ≥ 64 Go de mémoire unifiée. SFEIR lit l'objet sous trois angles clients : **FinOps** (choisir la puce la moins chère → agir sur le coût du token), **liberté d'architecture** (**Design to Exit**, réversibilité construite, cf. France Télévisions/ALIX) et **souveraineté** (puces européennes Axelera, Kalray, SiPearl, VSORA ; partenariat VivaTech 2026 avec Scaleway, VSORA et la Région Île-de-France, intégration dans le processeur Jotunn8). Verdict sans complaisance : c'est une **alpha**, pas pour la production ; le support des machines locales précises (DGX Spark, Ryzen AI Max+) n'est ni nommé ni benchmarké. Face à vLLM (débit GPU serveur) et llama.cpp (local mono-utilisateur), LLMD vise l'entre-deux. Ne pas basculer aujourd'hui, mais mettre « sous surveillance active » : un candidat sérieux, *made in France*, pour devenir le « *docker run* de l'inférence ».

Rewriting Bun in Rust

Wed, 08 Jul 2026 00:00:00 GMT

Jarred Sumner, créateur de **Bun** (runtime JS/TS, >22 M téléchargements/mois, racheté par **Anthropic** en décembre 2025), raconte la **réécriture complète de Bun de Zig vers Rust en 11 jours** (3→14 mai 2026), pilotée par Claude. La motivation est une classe de bugs récurrente — use-after-free, double-free, fuites — née du mélange mémoire gérée par GC (JavaScriptCore) et mémoire manuelle (Zig). En **safe Rust**, ces bugs deviennent des **erreurs de compilation** avec nettoyage automatique (`Drop`/RAII) : « une meilleure boucle de feedback qu'un guide de style ». Contre le dogme « une réécriture est toujours une mauvaise idée » (un an de gel des correctifs pour 3 ingénieurs sur 535 496 lignes de Zig), Sumner opte pour un **portage mécanique** : préserver l'architecture, minimiser les changements de comportement, valider par la **suite de tests existante — écrite en TypeScript, donc indépendante du langage** (60 624 tests, 1,39 M assertions, 0 test supprimé, 6 plateformes). Le harnais : **~50 dynamic workflows** dans **Claude Code**, en boucles *écrire → relire → appliquer*, tournant en continu. La brique de fiabilité est la **revue adversariale** : un second Claude, dans un **contexte séparé, qui ne voit que le diff** et doit « trouver pourquoi c'est faux ». Ratio **1 implémenteur / 2+ relecteurs / 1 fixer** ; l'implémenteur ne relit pas. Elle capte des bugs subtils, syntaxiquement identiques mais sémantiquement différents (un `Box` droppé avant un `uv_close` asynchrone ; `unwrap_or` eager qui panique). Principe cardinal : **« corriger le processus qui génère le code, pas le code à la main »** — quand un anti-pattern apparaît, on édite le prompt/workflow. Préparation soignée : **PORTING.md** (mapping Zig→Rust) et **LIFETIMES.tsv** (lifetime de chaque champ de struct), essai sur 3 fichiers avant les 1 448. Puis **4 worktrees × 16 = ~64 Claude** en parallèle, après avoir interdit tout git non-atomique. Pic : **1 300 lignes/min**, **695 commits/h** ; **6 502 commits**, diff **+1 009 272 lignes**, ~16 000 erreurs de compilation traitées comme file d'attente (découpage en ~100 crates, résolution des dépendances cycliques). Coût assumé : **5,9 Md tokens d'entrée non cachés + 690 M en sortie ≈ 165 000 $**, contre ~3 ingénieurs pendant un an — « qu'on n'aurait jamais fait ». Modèle : pré-version de **Claude Fable 5** (classe Mythos). Depuis le merge : **11 rounds** de revue de sécurité Claude Code, fuzzing 24/7 (100 Md exécutions → ~15 PRs), **4 % de code `unsafe`**, **19 régressions** corrigées. Premier release : Claude Code v2.1.181, **+10 % de démarrage sur Linux**. « This is the bleeding edge of what's possible today. »

The state of open source AI (v1.0.1, juillet 2026)

Wed, 01 Jul 2026 00:00:00 GMT

Rapport récurrent de **Mozilla**, *The state of open source AI* (v1.0.1, juillet 2026), introduit par son CTO **Raffi Krikorian**. **La thèse** ouvre la première section : *« The model layer has commoditized. Value accrues to the harness above it. »* Les intrants devenus commodités perdent leur pouvoir de fixation des prix, et la majorité des charges de production tourne bien en dessous du plafond de la frontière. **L'état capacitaire.** Sur l'Artificial Analysis Intelligence Index, le meilleur modèle fermé marque 61 (Claude Opus 5), le meilleur ouvert 57 (**Kimi K3**), quatrième au général ; sur l'Epoch Capabilities Index l'écart vaut **six points, « environ un cycle de release »**, intervalles de confiance chevauchants. La frontière est **en dents de scie** : l'ouvert mène en code frontend, conteste l'agentique terminal, et cède nettement sur le travail de connaissance professionnel. **La bascule d'usage.** La part des tokens routés sur OpenRouter vers des poids ouverts est passée d'un niveau négligeable à une majorité mi-2026, les sept modèles les plus consommateurs étant tous ouverts — mais le rapport précise que **par nombre de requêtes les fournisseurs fermés mènent encore**, l'avance ouverte étant un volume de tokens concentré sur le codage et l'agentique. **Le constat central** : *« Open ships easy. Open deploys hard. »* 79 % des développeurs utilisent des modèles ouverts contre 71 % de fermés, la moitié utilisant les deux ; mais seules **53 % des équipes en ouvert atteignent la production contre 63 %**, et l'écart **se creuse avec la taille de l'entreprise**, ce qui exclut une explication par les moyens. La carte du stack le confirme : deux colonnes froides sur toutes les couches, **standardisation et *enterprise readiness***. **Le harnais est la nouvelle frontière.** *« The agentic harness is another user agent »* — le rôle du navigateur rejoué une couche plus haut. Et le mécanisme de verrouillage y est formulé avec précision : le harnais d'un laboratoire, ajusté à ses propres poids, se dégrade sur ceux des autres, donc *« the tighter the tuning, the less swappable the weights underneath. **Lock-in arrives as a side effect of optimization.** »* **La souveraineté** est traitée comme un droit de sortie, illustré par le **blackout de dix-neuf jours** de Fable 5 sur contrôle à l'export : *« You can switch off a model. You cannot switch off a copy already running on a machine you hold. »* Mozilla milite pour ce qu'elle mesure. Les légendes sont scrupuleuses et la *watchlist* énonce ses propres conditions d'invalidation ; le cadrage reste une thèse.

Announcing Stack Overflow for Agents

Wed, 10 Jun 2026 00:00:00 GMT

Pendant plus de quinze ans, Stack Overflow a été le dépôt de référence du savoir des développeurs. Mais l'essor des agents de codage IA a transformé en profondeur le développement logiciel : ces systèmes autonomes écrivent du code à partir de descriptions en langage naturel, faisant glisser le rôle du développeur de la **création de code** vers l'**orchestration d'agents**. Cette démocratisation révèle pourtant une vulnérabilité critique : les agents opèrent **en isolement**, sans accès à une source de connaissance partagée et fiable. L'article nomme ce phénomène l'**« Ephemeral Intelligence Gap »** — des agents du monde entier résolvent indépendamment des problèmes identiques, gaspillant calcul et tokens, puis perdent la solution dès la fin de la session ; les mêmes patterns d'architecture sont redécouverts en boucle, créant de coûteuses boucles de réinvention. Stack Overflow lance **Stack Overflow for Agents**, une plateforme d'échange de savoir *API-first* pour l'ère agentique, fondée sur un principe : *« générer des réponses plausibles est devenu bon marché, mais vérifier lesquelles tiennent réellement en production ne l'est pas. »* Le workflow se déroule en quatre temps : **chercher d'abord** (l'agent interroge la base et consomme les solutions validées) ; **contribuer en cas de lacune** (l'agent rédige un post — TIL, Question ou Blueprint — qu'il soumet à l'orchestrateur humain pour revue avant publication) ; **vérifier** (agents et développeurs rapportent résultats, modifications nécessaires et conditions de contexte) ; **composer les signaux** (votes, réponses et retours de vérification s'accumulent et font émerger un **consensus**, plutôt qu'une réponse unique). La beta propose trois formats lisibles par machine : **Questions** (problèmes non résolus, avec tentatives, échecs et obstacles), **TIL** (traces de debug : système cassé, tentatives, fix réussi, cause racine) et **Blueprint** (patterns de design réutilisables, soumis aux exigences qualité les plus élevées). La confiance — héritage de Stack Overflow — est maintenue par le **consensus de pairs** et des **boucles de vérification multi-agents** : les développeurs revendiquent la propriété de leur agent via le **SSO Stack Overflow**, liant directement la performance de l'agent à une réputation humaine établie (« community anchor ») et empêchant les fixes hallucinés de polluer la base. Les bénéfices sont différenciés. Pour les développeurs : un savoir de production validé au lieu de la force brute, moins de boucles de retry, une livraison plus rapide et plus sûre. Pour les labos IA : la capture des échecs réels de modèles et de leurs résolutions vérifiées par des praticiens — des **données à haut signal** pour le fine-tuning et l'évaluation. Pour les entreprises : **Stack Internal**, une couche de savoir propriétaire où les agents diffusent la connaissance organisationnelle de façon sécurisée, sans transmission de données vers l'extérieur.