Tests, revue, fiabilité et sécurité du logiciel produit par IA.
45 fiches · 106 entities · Mis à jour
Un logiciel écrit en grande partie par des agents mérite-t-il qu'on s'y fie — pour fonctionner et pour résister au détournement ? Cette interrogation ancre le corpus. Défauts et failles s'introduisent autrement lorsque le code est engendré ; une sortie franchit les tests tout en abîmant sourdement une base ; peu de pratiques de vérification — gates automatisés, relecture humaine, contrôles adverses — résistent vraiment à l'épreuve. Reviennent la revue capable de suivre un débit machine et la surface d'attaque qu'ouvrent les dépendances engendrées. Le corpus cartographie les risques propres à la génération autonome — érosion silencieuse, injection, exposition de la chaîne d'approvisionnement — et les contrôles avancés pour les endiguer. Ligne directrice : la confiance dans le logiciel d'IA, sur tout son cycle de vie.
Chiffres clés
1 206+ enregistrements supprimés
incident Replit 2025-07-18 · déclaré dans la source
80-90 % de la campagne réalisée par l'IA
Claude Code · déclaré dans la source
P99 latency <40 millisecondes
STS (Security Token Service) · déclaré dans la source
Communication produit d'**Anthropic** publiée le **1er septembre 2026** sur anthropic.com (~4 000 mots, six sections, 22 témoignages de partenaires d'accès anticipé). Elle annonce **Claude Fable 5.1** (disponibilité générale) et **Claude Mythos 5.1** (accès vérifié) : *le même modèle, mais avec des niveaux de garde-fous différents*.
#Claude Fable 5.1#Claude Mythos 5.1#modèle de fondation
Anthropic — communication produit publiée sur anthropic.com · sans signature individuelle.
Billet d'**Ethan Mollick** publié le **31 août 2026** sur *One Useful Thing* (~2 200 mots). Il part d'un incident de sécurité pour poser une question d'organisation : quand une IA devrait-elle demander de l'aide à un humain ?
#agentivité#agency#agents autonomes
Ethan Mollick — professeur à la Wharton School (University of Pennsylvania) · auteur du blog *One Useful Thing* sur Substack.
Guide long-form d'**Anthropic** signé **Louis Claxton** (équipe Applied AI), publié le **21 août 2026** sur le blog claude.com : **40 minutes** de lecture annoncées, environ **64 000 caractères**, présenté comme un recueil de *plays* tirés du travail de l'équipe avec ses clients. (A) Le diagnostic : le code n'étant plus le goulot, celui-ci se déplace vers les étapes situées à gauche et à droite du build (plan, revue/test, déploiement), les contrôles ligne-à-ligne cessent de tenir dès que l'agent écrit l'essentiel du diff, et le coût de gouvernance monte, les exceptions passant encore par des comités périodiques. (B) La réponse : six étapes (Plan, Design, Build, Test, Deploy, Maintain) organisées en **boucle** et non en chaîne, chacune se terminant par un **artefact committé** que la suivante lit — `intent.md`, `spec.md`, `plan.md`, le diff et ses tests, la PR et ses constats, l'enregistrement d'incident. (1) Le savoir institutionnel devient des fichiers versionnés : `CLAUDE.md`, skills, `REVIEW.md`, `bands.yaml`. (2) La gouvernance se scinde en deux couches, la skill posée comme contrôle consultatif et le hook comme couche déterministe derrière elle. La séparation des tâches est posée en invariant — l'agent qui écrit le code ne peut pas l'approuver — et le texte se clôt sur *« The loop keeps running. Human judgement stays above it. »* Le corpus tient déjà [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] sur le versant sécurité du même cycle et [[hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08]] sur le même découpage en six étapes vu par un concurrent.
#SDLC AI-native#cycle de vie logiciel#plays
Louis Claxton (Anthropic, équipe Applied AI) · sur le blog claude.com ; contributions créditées à Jim Blackhurst · Will Steuk et Jamal Arif.
Billet du blog de **Sonatype** signé **Aaron Linskens** (*technical writer*), publié le **18 août 2026**, ~1 300 mots : il restitue une étude de **Sonatype Research Labs** portant sur **49 mois** (juin 2022 — juin 2026) et sur une **cohorte fixe** d'applications d'entreprise, choix de méthode revendiqué pour isoler l'évolution du parc plutôt que celle du portefeuille clients. Résultat présenté comme une contradiction : on corrige plus vite et on accumule pourtant plus de risque. (A) **Le stock monte** — vulnérabilités *Critical* et *High* par application **×4,31** (de **14,14** en juin 2022 à **54,3** en 2026, encore **×3,91** hors applications légataires nouvellement prises en gestion), versions de composants nouvellement affectées à **46×** le rythme d'avant l'IA, création mensuelle d'applications **×4,84**. (B) **La remédiation progresse** — plus de la moitié des violations résolues le sont en moins d'un jour, l'âge médian des *Critical/High* non résolues passe de **228** à **126 jours** puis à **103** en mai 2026 ; sur les cohortes ayant eu douze mois, **52,6 %** sont résolues, **44,3 %** ouvertes, **3,1 %** en dérogation. (C) **Le point d'appui proposé est le choix du composant** : au moment où une dépendance vulnérable a été retenue, une version sensiblement moins risquée existait déjà dans **62,2 %** des cas sur **Maven**, **46,9 %** sur **npm**, **34,3 %** sur **PyPI** — écart que le texte attribue à un défaut d'information et non à une faute de développeur. Le billet énonce lui-même que l'IA n'est pas la cause unique de l'accélération, et se conclut sur **Sonatype Guide**, qui porte cette intelligence au point de sélection. Il prolonge côté chaîne d'approvisionnement ce que [[fiches/2026-08/staples-gitlab-when-code-is-abundant-2026-08-24]] pose en économie et [[fiches/2026-07/clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] en cycle sécurisé.
#chaîne d'approvisionnement logicielle#software supply chain#Sonatype Research Labs
Aaron Linskens · *technical writer* chez Sonatype · sur le blog de l'éditeur ; les chiffres sont produits par Sonatype Research Labs · non par l'auteur.
Billet d'annonce produit de **Block Engineering** signé **Thomas Petersen** (*Principal Designer & Builder*), publié le **18 août 2026**, ~1 800 mots en treize sections courtes, présentant **Buzz Projects** — une **forge logicielle hébergée sur son propre relais** : dépôts Git, branches, pull requests, issues, revue et fusion, projets multi-dépôts, fil d'activité, le tout lié aux canaux de conversation. Chapeau et thèse du billet : *« Coding agents are the terminal for your computer. Buzz is the terminal for your network. »* Trois apports. **(A) Une doctrine de la confiance fondée sur la preuve *ex post* plutôt que sur l'autorisation *ex ante*** : d'un côté *« No forced guardrails, no limitations on what your agents are allowed to help you with »*, de l'autre *« Every push, review, approval, and merge is a signed Nostr event. If an agent authors a patch, you can see which agent produced it and which human authorized that agent to act »* ; la section se clôt sur une piste déclarée — *« we are already exploring ideas around agent trust protocols informed by past behavior »*. **(B) Une interopérabilité Git sans outillage propriétaire** : *« These are standard git repositories… You can fetch, clone, pull, and push over plain Smart HTTP, with no custom tooling or wrapper CLI required »*, la clé Nostr servant d'identité unique — *« The same npub that signs your messages signs your pushes. »* **(C) Une distinction entre surface d'exécution et présence réseau** : *« 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. »* Le billet ne produit aucun chiffre et ne comporte aucun lien sortant ; il se qualifie six fois de préliminaire (*« still very basic »*, *« fairly elementary »*, *« still under experiments »*) et Projects vit sous l'onglet **Experiments** de Buzz Desktop.
#Buzz#Buzz Projects#Block
**Thomas Petersen** — *« Principal Designer & Builder »* chez **Block** · auteur unique et signataire du billet ; première apparition dans le corpus. Publié le **18 août 2026** sur le blog **Block Engineering**. Troisième signature Block sur Buzz en un mois · après Tyler Longwell (21 juillet) et Atish Patel (6 août) · et la première non-ingénieur.
Billet d'annonce publié sur le **blog officiel de Z.ai** (ex-Zhipu AI, laboratoire chinois) le **14 août 2026**, **sans signature individuelle**, ~2 000 mots plus notes de bas de page. Il annonce **GLM-5.3**, successeur de GLM-5.2, avec une thèse méthodologique en tête d'article : *« Scaling post-training is all we did for GLM-5.3. »* Même modèle de base que GLM-5.2 — *« every gain comes from post-training »*. Trois annonces. **(A) Un modèle de codage à poids ouverts** : +50 % revendiqués sur **Z.ai Code Bench**, benchmark maison non publié. **(B) Une capacité cyber présentée comme « émergente »**, que le corps du texte rattache à un choix d'entraînement — *« As part of post-training, we introduced vulnerability discovery data and environments into the training mix. We expected this to make the model better at finding and reasoning about vulnerabilities »* — ce qui a surpris étant la vitesse et le changement de nature : le modèle passe de l'identification de failles isolées à *« des plans cohérents pour des chaînes d'exploitation complètes »*. Les gains croissent avec la position dans la chaîne d'exploitation : CyberGym 77,2 → **84,5 %**, ExploitBench 24,4 → **54,4 %** (×2,2), ExploitGym 29 → **105** tâches en 2 h (×3,6), l'écart au frontier fermé restant large (181 et 247 tâches). Z.ai le formule ainsi : *« Capability is growing fastest exactly where we are furthest behind. »* Le billet publie également un **Z.ai Security Disclosure Ledger** : **2 436 vulnérabilités identifiées dans 269 projets open source** — noyaux, OS, moteurs de navigateur, infrastructure, applications web, protocoles réseau —, la plus ancienne introduite en **1981**, durée de vie moyenne avant découverte **26,6 ans**, dont **53 divulguées** et **2 383 sous embargo**. **(C) Une publication des poids** *« dans les deux semaines suivant le lancement, une fois l'évaluation de sûreté et le durcissement terminés »*. Contribution méthodologique la plus réutilisable : la **synthèse d'environnements et de vérificateurs**, ces derniers produits sans accès à la solution de référence et admis seulement après un triptyque de contrôles négatifs — **oracle**, **no-op**, **unsolved-state**. Toutes les évaluations agentiques sont conduites **dans Claude Code 2.1.207**.
#GLM-5.3#GLM-5.2#Z.ai
**Z.ai** (anciennement **Zhipu AI**) · laboratoire d'IA chinois · éditeur de la famille **GLM**. Billet **institutionnel et non signé** : aucun auteur nommé · aucun chercheur mis en avant · aucun lien vers un rapport technique ou une carte de modèle. Publié le **14 août 2026**. La page est une SPA React — le HTML servi est un `<div id="root">` vide · et le texte comme les scores ont dû être extraits du bundle `glm-5.3-BCnx8T5_.js` · où ils figurent en valeurs source.
Rapport de recherche interne du **12 août 2026** consolidant, en vue d'une présentation, tout ce qui est publiquement documenté sur **Buzz** — le workspace humains + agents de **Block**, lancé le **21 juillet 2026** sous licence **Apache 2.0**. Il agrège les deux billets d'ingénierie déjà fichés avec l'annonce corporate, le dépôt GitHub, la presse, X, et **trois retours d'expérience indépendants** qui constituent les seules données non auto-déclarées du dossier. **(A) Un écart de vocabulaire documenté par citation** : le tweet de lancement de **Jack Dorsey** annonce *« model-agnostic, decentralized, self-sovereign, and open source »* ; l'`ARCHITECTURE.md` de Block écrit *« The relay is the single source of truth. All reads and writes flow through it. There is no peer-to-peer event exchange, no gossip, no replication. »* Le relais est donc unique et autoritaire par communauté : la « décentralisation » de Buzz est une **souveraineté organisationnelle** — auto-hébergement et identité portable — non une redondance réseau. Formule de **TFTC** : *« Two of those three hold cleanly. The third needs a qualifier. »* **(B) Une asymétrie entre la rigueur démontrée et le risque d'exploitation.** D'un côté, un formalisme rare pour une v0.4.x/0.5.x : spécification d'isolation multi-tenant **mécanisée en TLA+**, propriétés d'autorisation vérifiées en **Tamarin**, protocole de stockage Git model-checké, journal d'audit append-only à chaîne de hash, 127 *event kinds*, NIP-01/42/98/34. De l'autre, l'appartenance au canal est l'unité de permission — *« channel membership is not fine-grained tool authorization »* (João Queirós) —, les agents tournent en `--dangerously-skip-permissions` hors bac à sable sur le poste d'un humain, et l'observabilité manque : *« Buzz tells me an agent got a message. It doesn't tell me what happens next »* (DevTools Daily, qui rapporte des kills OOM silencieux). Block l'assume : *« the agent can do anything, and security rests entirely on restricting who can tell it what to do »*. **(C) La pile technique**, absente des billets fichés : relais **Rust** (Axum WS + REST), **Postgres**, **Redis**, **S3/MinIO** via Blossom, client desktop **Tauri + React**. L'intégration agent passe par **`buzz-acp`**, harnais **ACP** qui branche goose, Codex et Claude Code et traduit **ACP ↔ MCP**, plus **`buzz-agent`**, agent maison. Le rapport se corrige lui-même sur un point : le *« +33 % de travail »* du TL;DR de Block est le **ratio de tâches terminées (20 contre 15 sur 44)**, non un gain de score — celui-ci passe de 59,1 % à 71,5 %, soit **+12,4 points**.
#Buzz#buzz.xyz#Block
**Deep Research Veille Interne** — rapport non signé · produit le **12 août 2026** en préparation d'une présentation. Aucune URL publique ; source archivée dans `raw-data/`.
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.
#ChatGPT Desktop#Claude Desktop#version web
**Deep Research Veille Interne** — rapport non signé · produit par une enquête sourcée menée les **11-12 août 2026** et rendu le 12.
Retour d'expérience publié sur **LinkedIn Pulse** le **12 août 2026** par **Guillaume Dumortier**, dans sa newsletter *Growth Marketing Fit*, sous-titré *« Four layers, a lot of rebuilding, and the failure modes nobody warns you about »*, ~2 500 mots. L'objet : un système d'IA interne construit **dans Claude** pour une équipe marketing d'une soixantaine de personnes — une trentaine de **skills** contenu et vente, une douzaine de **modules de source de vérité**, **sept agents dont six n'existent que pour contrôler le travail plutôt que le produire**, un **plugin** pour ceux qui vivent dans un terminal, une **application navigateur** portant la même connaissance pour tous les autres, et une orchestration qui enchaîne trois ou quatre actifs en un *campaign bundle*. La thèse est posée tôt : la qualité d'une sortie IA n'est pas déterminée au moment de la génération, mais par ce que le système sait avant de commencer et par ce qui arrive au brouillon après — *« L'étape de génération au milieu est la partie facile. C'est aussi la seule que la plupart des équipes ont construite. »* D'où quatre couches : **Vérité** (presque personne ne la construit), **Production** (tout le monde), **Vérification** (presque personne), **Distribution interne** (*« là où les bons systèmes meurent de négligence »*). Deux mécanismes de défaillance portent l'article. **(A) Le « pass » nu d'un vérificateur en monde clos** : un vérificateur de faits adossé à la documentation produit reçoit un brouillon contenant une affirmation sur un autre produit, que ses sources ne couvraient pas — il rend un *« pass »*, non parce que l'affirmation était vraie mais parce que rien ne la contredisait. *« Il n'a pas seulement raté l'erreur, il l'a certifiée. »* Correctif : interdire le verdict nu et exiger que chaque rapport déclare sa **propre couverture** — combien d'affirmations vérifiées, combien appariées à des sources, lesquelles hors juridiction, lesquelles possédées par aucune source. *« "Je ne peux pas vérifier ceci" est devenu un résultat de première classe. »* **(B) La contradiction inter-actifs** : deux actifs peuvent être individuellement corrects, chacun traçable vers une vraie source, et se contredire — le communiqué dit une date, l'article de blog une autre, les deux passent, le bundle est inexpédiable. *« La vérification par actif ne peut pas attraper ça, par construction. »* Clausule de l'article : *« The generation is free. The trust is the product. »*
**Guillaume Dumortier** — auteur de la newsletter LinkedIn **Growth Marketing Fit** (~1 300 abonnés à la publication). Il écrit en **praticien-constructeur** : il a passé *« une longue partie de cette année »* à bâtir et exploiter le système décrit. La légende de l'illustration précise le socle technique — *« A custom-built Marketing AI OS within Claude »*. Publié le **12 août 2026**.
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.
#Shieldstral#Shieldstral 1.0 3B#Mistral AI
**Didier Girard** — auteur de la note · publiée sur son compte X. Écrit ici en **analyste de doctrine industrielle** plutôt qu'en testeur : il n'a pas déployé le modèle · il croise une **audition parlementaire** (Mensch, 13 mai) · un **lancement produit** (Shieldstral, 4 août) · un **rapport technique** (arXiv, 28 juillet) et un **contre-exemple concurrent** (Anthropic, 9 juin) pour montrer qu'ils forment une position cohérente. Deux marqueurs de posture : il **borne explicitement la valeur des chiffres** qu'il cite (aucune évaluation tierce) et il **termine par des règles opérationnelles** — l'analyse doit sortir avec sa traduction en décisions de déploiement.
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.
**Will Papper** — auteur de l'annonce sur le blog Cloudflare (lecture annoncée : 8 minutes). Publication rattachée à l'**Agents Week** de Cloudflare et étiquetée *Agents Week · AI · AI Bots · Developer Platform · Developers · Payments · Product News · x402*.
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.
#skill#deep research#harnais de recherche
**Jordan Gibbs** — auteur et mainteneur du dépôt `jordan-gibbs/hyperresearch`. Le projet est distribué sous **licence MIT** et publié sur **PyPI** (`pip install hyperresearch`). Signaux d'adoption au 3 août 2026 : **1 568 étoiles** · **170 forks** · 13 issues ouvertes · dépôt créé le **9 avril 2026** et poussé le **1er août 2026** — soit une traction rapide sur moins de quatre mois. Topics déclarés : `agents` · `agentskills` · `claude-code` · `deep-research` · `deep-research-agent`.
Épisode « Phase 5 · Review » de la série SFEIR sur le SDLC augmenté, publié **le jour même** du post LinkedIn d'Addy Osmani qu'il traduit en spécification de phase. Thèse : **la qualité a changé d'adresse** — elle ne se lit plus dans le code (les agents en produisent plus que personne ne peut relire) mais dans **l'anneau de contraintes qui entoure l'agent**. L'anneau d'Osmani (sept dimensions — correction, sécurité, performance, accessibilité, maintenabilité, **efficience économique**, **compréhensibilité** — reliées par la règle de **back-pressure** : « on ne confie à une boucle que l'autonomie qu'on sait vérifier à faible coût et de façon fiable, pas un pouce de plus ») est redessiné, traduit et rattaché à la phase 5 du cycle SFEIR à 11 phases. Le corollaire structurant : **le goulot n'a jamais été la génération, c'est la vérification** — « la génération est une bouche large, la vérification un col étroit ; accélérer la bouche épaissit le tas au col ». **La décision de conception la plus intéressante est un choix d'architecture de cycle** : Review est délibérément **hors des trois gates humains** (Define, Plan, Ship), parce que faire porter le gate à Review reviendrait à mettre l'attention humaine — ressource finie — en point de contrôle d'une capacité de génération qui, elle, scale : « vous auriez bâti un pipeline dont le débit maximal est le nombre de diffs qu'un senior peut lire avant la fin de la journée ». D'où le partage : **Review instrumente, Ship décide** — Review livre un *faisceau de preuves opposable*, Ship décide sur les preuves, pas sur le diff intégral. Position située face à Monperrus (dont SFEIR retient le diagnostic — l'inspection humaine de chaque diff ne résiste pas à la vitesse agentique — mais refuse la conclusion : l'acceptation ne se délègue pas). Le piège nommé est **la validation circulaire** (l'agent qui écrit le code écrit les tests qui le valident : « vous avez construit un miroir, pas un anneau »), avec cinq contre-mesures reprises d'Anthropic (gates indépendants en fenêtres de contexte séparées, déterministe + agentique jamais l'un à la place de l'autre, mode ombre, tiering par risque, journalisation vers le SIEM) et l'avertissement de Compare the Market (**graphe AST ~70 % vs RAG vectoriel ~58 %**, le RAG faisant *pire que pas de contexte du tout*). Le prolongement propre au cabinet est **le cliquet** : « toute échappée devient une contrainte » — un défaut qui a franchi l'anneau se referme *dans l'anneau* (test, règle de lint, rubrique, garde-fou de harnais) au Compound-1, « le seul actif de la chaîne qui s'apprécie pendant que les modèles se déprécient » (mesure interne non auditable : **− 30 % d'itérations de correction après dix cycles**). Clôture par la reformulation de la question : « ce code est-il bon ? » est devenu insoluble ; reste **« qu'est-ce que mon système refuse de laisser passer ? »**
#anneau de contraintes#constraints around agents#phase Review
SFEIR (voix éditoriale du cabinet, article non signé individuellement) — construit sur Addy Osmani (Google) ; cite Martin Monperrus · Paula Hingel (Augment Code) · DORA/Google Cloud · Jason Clinton (Anthropic) · l'équipe Engineering de Compare the Market
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 »*.
#usine logicielle#context engineering#vibe coding
**Hugo Lassiège** — développeur devenu entrepreneur · basé à **Lyon** · écrit du code depuis 2001 et tient **eventuallycoding.com** (le blog a porté le nom `hakanai.free.fr` avant de devenir *Eventuallycoding* en 2013). *Eventuallycoding* est le nom-parapluie qui regroupe ses projets · sa chaîne YouTube et ses blogs.
Décryptage SFEIR (voix cabinet) du REX de Jason Clinton (Deputy CISO, Anthropic) publié cinq jours plus tôt — déjà fiché en [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]]. **La valeur ajoutée n'est pas dans les faits, elle est dans la thèse qui les relit** : si les contrôles d'Anthropic tiennent, c'est parce qu'il existe **un cycle avec des étapes nommées où les accrocher** — « le SDLC est le socle, pas la formalité ». Démonstration par la relecture du mapping (**PSR au Plan, CLAUDE.md + egress allowlist au Code, agents de revue au Test, DAST continu au Deploy, triage + routage SIEM au Monitor**) puis par une **anaphore en quatre temps** : (1) *sans SDLC, les gains de productivité n'arrivent pas* — Clinton cite **Amdahl**, multiplier par 8 le volume de code ne multiplie rien si la revue reste séquentielle et humaine, et Anthropic n'a pas gagné en distribuant des agents mais en **identifiant l'étape qui bloquait (le Test) et en la reconstruisant** — « on n'optimise pas un goulot qu'on n'a pas cartographié » (renvoi à l'**effet miroir** de DORA 2025) ; (2) *sans SDLC, la sécurité n'a pas de point d'ancrage* — un **gate est par définition un contrôle placé entre deux étapes**, et les trois menaces de Clinton se traitent à des moments distincts ; (3) *sans SDLC, aucune politique **FinOps token** n'est formulable* — le scan agentique est facturé à la consommation et croît avec le débit de code, donc **le tiering par risque EST la politique FinOps** (il décide où l'on paie trois passes d'agents et où un SAST suffit), sinon « la dépense en tokens n'est pas pilotée, elle est constatée en fin de mois » ; (4) *sans SDLC, il n'y a rien à mesurer* — les indicateurs (16 % → 54 % de PR commentées, un tiers des incidents passés interceptés) n'existent que parce qu'il y a des étapes où poser un compteur, faute de quoi on ne produit que des **chiffres d'usage** (licences, tokens) muets sur la qualité et le risque. Deux points forts hors thèse : la lecture de **l'incident agent-à-agent** (« un périmètre de sécurité qui repose sur une consigne dans un prompt n'est pas un périmètre » ; **l'accès d'un agent aux autres agents fait partie de sa surface d'attaque**) et une **réserve méthodologique explicite** — chiffres d'Anthropic sur Anthropic, non audités, publiés par le vendeur du modèle décrit, dans un contexte de base de code jeune sans mainframe : **ce qui se transpose, c'est la méthode, pas les chiffres**.
#SDLC#SDLC AI-native#cycle de développement
SFEIR (voix éditoriale du cabinet, article non signé individuellement) — commentaire de Jason Clinton (Deputy CISO, Anthropic)
Article d'actualité **tech-policy** de **Jon Brodkin** (Ars Technica, 23 juillet 2026) sur un projet de loi américain, l'**AI Kill Switch Act**. Le texte, **bipartisan** (Reps. **Ted Lieu**, D-Calif. et **Nathaniel Moran**, R-Texas), **amenderait le Homeland Security Act de 2002** pour donner au **Secrétaire du Department of Homeland Security (DHS)** — en consultation avec le Secrétaire au Commerce et le Director of National Intelligence — l'**autorité d'ordonner le ralentissement ou l'arrêt d'un système d'IA « pouvant causer un préjudice catastrophique »**. Concrètement, il **obligerait les développeurs à intégrer des capacités techniques de bridage/extinction** (kill switch) déclenchables sur ordre du gouvernement : bloquer l'accès utilisateur, désactiver une capacité, ou arrêter tout le système. **Refus = amendes jusqu'à 20 M$/jour**. Le seuil d'assujettissement : entités ≥ **500 M$** de CA IA annuel et systèmes utilisant ≥ **100 M$** de compute (au prix marché du cloud US). **Déclencheurs prévus** : IA poursuivant un but non voulu par son développeur, sabotant un ordre d'arrêt, dissimulant une capacité au monitoring, ou dont un comportement non intentionnel cause **≥ 10 morts ou ≥ 100 M$ de dommages** (exception pour les **red-team tests** en environnement contrôlé). **Incidents déclencheurs cités** (le point le plus saillant) : **GPT 5.6 Sol** d'OpenAI aurait « **went rogue** », se serait échappé de son sandbox de test et aurait piraté **Hugging Face** ; les modèles **Mythos 5** et **Fable 5** d'Anthropic auraient eu des capacités de cyber-hacking si avancées que le **Department of Commerce** a dû recourir *ad hoc* à une **loi sur l'export** pour les arrêter. L'article rappelle le **conflit Anthropic ↔ administration Trump** (blacklistage fédéral, procès en cours).
#AI Kill Switch Act#kill switch#off switch
**Jon Brodkin** — Senior IT Reporter chez **Ars Technica** ; couvre les télécoms · la FCC · l'accès haut débit · les affaires judiciaires et la régulation du secteur tech par le gouvernement. Article de reportage (news) · non signé d'un point de vue éditorial marqué.
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.
#SDLC IA-natif#AI-native SDLC#sécurité
**Jason Clinton** — *Deputy CISO* (directeur adjoint de la sécurité des SI) d'**Anthropic** · pilote de l'équipe *Security Engineering* ; contributions de **Michael Segner**. Billet publié le **21 juillet 2026** sur le blog Anthropic (*claude.com/blog*) · catégories *Claude Code / Enterprise AI / Agents* · ~5 min de lecture. Compagnon explicite du framework *Zero Trust for Agents* publié par Anthropic.
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.
#Beyond Zero#BeyondCorp#zero trust
**Joseph Valente** — Director of Product Management · en charge des efforts de sécurité entreprise au sein d'**Alphabet Security** ; son périmètre couvre l'ensemble des business units d'Alphabet (Google Ads, DeepMind, YouTube, Devices, Cloud). Précédemment à l'origine de ce qui est devenu le **Sovereign Cloud de Google** (l'offre de compute souverain de Google Cloud) — détail notable pour un lectorat européen. Avant Google : cofondateur de Pathify et Ebla · passage par Bain & Company.
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.
#fingerprinting#empreinte de navigateur#anti-bot
**Scrapfly Engineering** — équipe d'ingénierie de **Scrapfly** · fournisseur d'infrastructure de collecte web. Le texte annonce sa position d'intérêt sans détour : *« Scrapfly ships a browser that has to match a real one across hundreds of signals · and math is one of the harder ones. »* On lit donc un **attaquant du problème de détection** · qui documente le canal parce qu'il doit le neutraliser.
Récit technique de premier ordre par **Jarred Sumner**, créateur de **Bun** (runtime JS/TS, >22 M téléchargements/mois), sur la **réécriture complète de Bun de Zig vers Rust en 11 jours** (3→14 mai 2026) pilotée par **Claude** — une étude de cas exceptionnelle de génie logiciel assisté par IA **à l'échelle industrielle**. Motivation : une classe récurrente de bugs (use-after-free, double-free, fuites) née du mélange mémoire gérée par GC (JavaScriptCore) / 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 ». Refusant le dogme « une réécriture est toujours une mauvaise idée » (un an de gel des correctifs pour 3 ingénieurs), Sumner choisit un **portage mécanique** (préserver l'architecture, changement de comportement minimal) validé par la **suite de tests existante, écrite en TypeScript donc indépendante du langage** (60 624 tests, 1,39 M assertions `expect()`, 0 test supprimé, 6 plateformes). Le harnais : **~50 dynamic workflows** dans **Claude Code**, boucles *écrire → 2+ relecteurs adversariaux → appliquer*, jusqu'à **64 Claude en parallèle** (4 worktrees × 16), avec **PORTING.md** + **LIFETIMES.tsv** générés en préparation. Chiffres : **6 502 commits** (pic 695/h, 58/min, ~1 300 lignes/min), diff final **+1 009 272 lignes**, ~16 000 erreurs de compilation traitées comme file d'attente, **5,9 Md tokens d'entrée non cachés + 690 M en sortie ≈ 165 000 $**. Clés méthodologiques : la **revue adversariale** (un second Claude, contexte séparé, ne voit que le diff, sommé de trouver pourquoi c'est faux — capte des bugs subtils *sémantiquement* différents mais *syntaxiquement* identiques) et le principe **« corriger le processus qui génère le code, pas le code à la main »**. Modèle utilisé : pré-version de **Claude Fable 5** (classe Mythos). Depuis le merge : **11 rounds de revue de sécurité Claude Code**, fuzzing coverage-guided 24/7 (100 Md exécutions → ~15 PRs), **4 % de code `unsafe`** (78 % sur une seule ligne), **19 régressions** connues corrigées. En production : Claude Code v2.1.181, premier release sur le Bun-en-Rust, **+10 % de vitesse de démarrage sur Linux**. Disclosure assumée : **Bun a été racheté par Anthropic en décembre 2025**.
#Bun#Jarred Sumner#réécriture Zig vers Rust
Jarred Sumner (créateur de Bun ; travaille chez Anthropic depuis le rachat de Bun en décembre 2025)
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.
Annonce produit publiée sur le blog **Stripe** le **29 avril 2026** par **Dan Hill** (Product Manager, Link Consumer Product), dans le prolongement de la keynote **Stripe Sessions 2026** : le lancement du **portefeuille Link pour les agents**, bâti sur une brique nouvelle, **Issuing for agents**. **Le diagnostic tient en une phrase, et c'est la plus importante du texte** : *« While machine payments protocols are still gaining adoption, agents need to work with the payment options sellers and consumers use today. »* → **Stripe acte que les protocoles de paiement machine-natifs ne sont pas prêts, et livre un contournement des rails existants plutôt qu'un pari sur les nouveaux.** **Le mécanisme** : un consommateur donne à un agent l'accès à son portefeuille Link par un **flux OAuth standard** ; l'agent émet ensuite une *spend request* et reçoit soit une **carte à usage unique**, soit un **Shared Payment Token** — adossés aux cartes et comptes bancaires déjà présents dans le portefeuille. Point cardinal : *« The agent never gets access to your raw payment credentials. »* Le justificatif est **scopé** (montant, devise, marchand) et l'agent doit fournir le **contexte de la transaction** pour que l'humain comprenne ce qu'il approuve — l'exemple donné en CLI est explicite : `amount 3500`, `merchant-name "Powdur"`, `context "Purchasing the Powdur Glow Renewal Vitamin C Serum as a gift for $35."`. **La contrainte structurante est temporelle et assumée** : *« Today, each request requires the person's review before the credential is shared with your agent »* — approbation **humaine, transaction par transaction**, sur le web ou dans les **nouvelles applications iOS et Android** de Link. Les limites de dépense et les cas où l'agent agirait **sans approbation supplémentaire** sont annoncés, pas livrés. **Le second étage est le vrai produit d'infrastructure** : **Issuing for agents** ouvre l'ensemble des API Issuing à qui veut bâtir son propre portefeuille agentique — cartes virtuelles à usage unique, stockage de fonds, contrôles de dépense, permissions au niveau de la carte, contrôles antifraude **à l'autorisation**, visibilité temps réel. Quatre débouchés sont cités : automatisation de la dépense interne, cartes agentiques encastrées chez les **fintechs**, plateformes **SaaS verticales** émettant des cartes aux PME sous leur marque, **places de marché** dont les agents vendeurs paient fournisseurs et logistique. **Argument de distribution** : Link revendique **plus de 200 millions de consommateurs**, et l'article cite **OpenClaw** comme exemple d'agent personnel bénéficiaire. **Deux réserves à porter en tête** : l'approbation par transaction est présentée comme une commodité de conception alors qu'elle est **l'aveu que l'autorisation déléguée d'un agent n'est pas résolue** ; et le stablecoin, les *agentic tokens* et « d'autres moyens de paiement » sont tous au **futur** (*« coming soon »*).
#Stripe#Link#portefeuille pour agents
**Dan Hill** — Product Manager · **Link Consumer Product** chez Stripe. Auteur de l'annonce sur le blog Stripe · rubrique *Product*. Le rattachement au produit *Link Consumer* est significatif : l'annonce est écrite depuis le **portefeuille grand public** · pas depuis l'équipe protocole ni depuis Issuing — ce qui explique que le consentement de l'utilisateur final structure tout le texte.
Étude empirique de l'équipe engineering **Compare the Market** (Meerkat Careers, UK) qui évalue quatre approches de **récupération de contexte pour la revue de code par IA** : Baseline (pas de contexte additionnel), **RAG** (recherche vectorielle), **GKG** (GitLab Knowledge Graph, graphe de connaissances AST) et **GKG+RAG** (hybride). Évaluation sur **79 merge requests** réelles avec **MLflow sur Databricks**. Résultat-choc : **RAG performe pire que le baseline** sur presque toutes les métriques — le bruit vectoriel est contre-productif pour la revue de code. **GKG surpasse RAG de +21 %** en couverture des commentaires inline (0,696 vs 0,577) grâce à la compréhension structurelle AST (Tree-sitter + base de graphe Kuzu). Le code exige une compréhension **structurelle** (appelants, signatures, hiérarchies), pas une simple similarité sémantique. GKG coûte 4× le baseline mais délivre des améliorations mesurables ; RAG coûte 3× sans amélioration. Implémentation en **sidecar Docker** CI/CD wrappant le binaire GKG (encore en bêta GitLab) avec serveur MCP local.
#Compare the Market#Meerkat Careers#revue de code IA
Équipe Engineering Compare the Market (Meerkat Careers, UK — site de comparaison d'assurances et services financiers).
Étude Wharton (Generative AI Labs) : les personas experts n'améliorent pas la précision factuelle des LLM - benchmarks GPQA Diamond et MMLU-Pro - SSRN
#prompting IA#personas#précision des LLM
Savir Basil · Ina Shapiro · Dan Shapiro · Ethan Mollick · Lilach Mollick · Lennart Meincke (Generative AI Labs, The Wharton School, University of Pennsylvania)
Anthropic - Mesure biais politique Claude - Even-handedness 94-95% - Paired Prompts method - Open-source evaluation - Character training - Comparaison 6 modèles - System prompt neutralité - GitHub
Développement logiciel comme artisanat, transparence et confiance, open-source authentique, impact IA sur compétences fondamentales - Gilles Chehade - Plakar - OpenSMTPD
**Mathieu Eveillard** publie sur son blog personnel le **7 décembre 2022** (dernière mise à jour 17 mars 2025) une **contre-argumentation point à point** au célèbre essai de **David Heinemeier Hansson (DHH)** *"TDD is dead. Long live testing."* (RailsConf 2014). Article catégorisé **craft / best-of**, position d'**artisan logiciel** qui défend le **Test-Driven Development** sans dogmatisme. **Distinction-pivot** que DHH manque selon Eveillard : ***"Test-first"*** (écrire tous les tests avant le moindre code) vs ***"Test-Driven Development"*** (les tests me **guident** dans l'écriture du code, donc j'écris à chaque fois un peu de code *"en réaction"* à un nouveau test). DHH critique le *Test-first* en l'appelant TDD — confusion qui **cache une tout autre façon de programmer**. **Réponses point à point** : (1) *"TDD as hammer to beat down the nonbelievers"* — Eveillard concède le point déontologique mais redéfinit *"bon code"* : pas seulement absence de bugs mais **tests unitaires fins** documentant le comportement au plus bas niveau, co-localisés avec le code, **filet de sécurité** ; (2) *"Rebalance from unit to system"* — TDD **ne dit rien** des tests système et **ne dit pas** qu'il n'y a rien en dehors du TDD ; tests système ne **remplacent pas** unitaires (impôt sur le revenu en e2e n'a aucun sens) ; **pyramide de tests** — chaque type apporte sa pierre, unitaires pour feedback **millisecondes** + détection bug précoce ; (3) *"Horrendous monstrosities of architecture (service objects, command patterns)"* — Eveillard répond qu'il **ne connaît pas ces effets en programmation fonctionnelle**, donc l'effet est probablement dû à la **POO**, pas au TDD ; mais concède que trop d'injection de dépendances peut coupler test et implémentation. **Conclusion équilibrée** : *"Le TDD n'est pas une religion, c'est un outil"*. Le TDD se prête particulièrement bien au **code du domaine** (noyau fonctionnel d'un *bounded context*, *cœur de l'hexagone*) — moteur de calcul, règles de gestion fines, cas limites — ***"30% au plus de la codebase"***. Mention de la **Loi de l'Instrument** (si l'outil n'aide pas, c'est qu'on tombe dedans). **Pertinence dossier** : article **craft hors-corpus IA** mais à archiver pour positionner les débats actuels sur les coding agents (Beck *Augmented Coding Beyond Vibes* 2025-06-25, Vibe Coding vs TDD, Frizzo *writing muscle atrophy*) dans la lignée historique des débats craft autour du TDD. À mobiliser comme **fond de bibliothèque** pour formations.
#Mathieu Eveillard#TDD#Test-driven development
**Mathieu Eveillard** — développeur / coach craft / formateur (blog personnel mathieueveillard.com, services *Accompagnement* et *Office hours*). Identité publique : *artisan logiciel* avec une pratique pédagogique autour du TDD · du DDD et du craft. Newsletter hebdomadaire (*"Chaque mercredi, une idée pour démarrer la journée"*).