Essai publié sur **Gates Notes** le **26 août 2026** par **Bill Gates**, cofondateur de **Microsoft** et président du conseil de la **Gates Foundation**, ~4 500 mots, annoncé comme le premier d'une série. Le texte pose une alternative — l'IA sera le plus grand égalisateur jamais inventé, ou la pire source d'injustice — et un constat : il n'existe aucun plan pour entrer dans cette période. **(A) Trois risques** : la disparition durable des emplois d'entrée et de milieu de carrière, cols blancs comme cols bleus, en une décennie plutôt qu'en plusieurs générations, parce que la substitution porte cette fois sur la **cognition** ; l'armement des acteurs malveillants (cyberattaques, bioterrorisme, fraude, deepfakes), doublé d'une concentration du pouvoir chez ceux qui en détiennent déjà ; l'effet des compagnons IA sur le développement des enfants et sur l'esprit critique. **(B) Les bénéfices**, situés dans cinq domaines — recherche, santé, agriculture des pays à faible revenu (l'impact que l'auteur dit le plus rapide), services publics, éducation — avec une réserve portée sur le verbe : *« the operative word is "can" »*. **(C) Trois propositions** ouvrent la série : bâtir un cadre institutionnel national et international inédit, empruntant au régime d'inspection nucléaire, à la régulation aérienne et aux accords sur l'ozone ; réserver certains métiers aux humains, domaine nommé **Human Reserved** ; **taxer les tokens d'IA et les robots** pour rééquilibrer la fiscalité du travail et du capital. Gates déclare ses liens financiers avec l'industrie et le reversement de ses profits à la fondation. Le texte prolonge les tribunes de dirigeants sur la répartition de la valeur de l'IA — [[nadella-frontier-ecosystem-human-token-capital-2026-06-12]], [[zuckerberg-meta-future-is-for-everyone-superintelligence-2026-08-10]] — en portant sur la puissance publique plutôt que sur la firme.
#équité et IA#transition vers l'ère IA#substitution de la cognition#disparition d'emplois#emplois d'entrée de gamme
Bill Gates — cofondateur de Microsoft · président du conseil de la Gates Foundation. Blog personnel Gates Notes. Page non capturable par `curl | lynx` (403 Akamai) : extraction navigateur.
Billet invité d'**Andy Warfield**, ingénieur du service **S3** chez **AWS**, publié le **26 août 2026** sur *All Things Distributed*, le blog de **Werner Vogels**, qui le présente en quelques lignes signées *« --W »* : **3 554 mots** annoncés par la page. Le texte sert de véhicule à l'annonce que **DuckLabs**, l'équipe derrière **DuckDB**, rejoint **AWS**. (A) La thèse : l'informatique système consiste à chercher le compromis élégant face à une « physique » mobile — les rapports entre vitesse mémoire, réseau et calcul — et cette physique a changé. Warfield chiffre l'écart : une **m1.xlarge** de 2007 offrait **15 Go de RAM**, **4 cœurs virtuels** et **~1 Gb/s** de réseau ; une **m8g.48xlarge** d'aujourd'hui environ **50×** plus de chacun des trois. La croissance des jeux de données, elle, suit une distribution dont les très grands volumes sont la queue. (B) La conséquence : le traitement distribué — **MapReduce**, les **RDD** de **Spark** — a été conçu sous la contrainte d'I/O du début des années 2000, et une grande part du travail qui lui était confié n'a plus besoin de quitter l'application. D'où le moteur embarqué en bibliothèque, dans l'espace d'adressage de l'application, dont **DuckDB** est l'exemple. Warfield y adosse l'article *Scalability! But at what COST?* (2015) et l'épigraphe de **Paul Barham** : *« You can have a second computer once you've shown you know how to use the first one. »* Il pose une réserve explicite : *« When a job genuinely needs a thousand machines, it needs a thousand machines. »* Le corpus tient déjà [[vogels-tech-predictions-2026-allthingsdistributed-2025-11-25]] du même blog et [[anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03]] sur l'analytique en libre-service.
#DuckDB#DuckLabs#acquisition AWS
Andy Warfield · ingénieur du service S3 chez AWS · en billet invité sur *All Things Distributed* ; introduction de Werner Vogels · CTO d'Amazon.
Essai de **Bill Staples**, directeur général de **GitLab**, publié le **24 août 2026** sur le blog about.gitlab.com : **31 minutes** de lecture annoncées, environ **39 000 caractères**, présenté comme la suite d'un mémo écrit au conseil d'administration en janvier 2026 et partiellement publié en mai sous le titre *GitLab Act 2*. Le texte se donne comme une réponse au playbook AI-native SDLC d'**Anthropic** paru trois jours plus tôt, dont il reprend la phrase d'ouverture — *« Code is no longer the bottleneck »* — pour poser la question qui l'occupe : qu'est-ce qui devient rare quand le code devient abondant. (A) Le diagnostic économique : l'unité utile n'est pas le coût par ligne mais le **coût par changement accepté**, qui agrège génération, environnement, contexte, vérification, revue, remédiation et gouvernance ; l'IA effondre le seul terme de génération, ce qui rend les autres proportionnellement plus lourds — une organisation dix fois plus rapide à générer *« will simply move the queue »*. (B) La réponse architecturale : quatre capacités — plateforme d'agents, exécution à l'échelle machine, contexte durable, gouvernance — formant une couche d'entreprise qui survit au modèle, *« The model should be replaceable. The agent should belong to the customer. »* (1) Trois modes coexistent durablement, du légataire piloté par l'humain au développement autonome, contre l'idée d'une courbe de maturité unique. (2) Le pipeline CI/CD devient le lieu où tourne la boucle interne, au lieu d'être une porte en fin de course. Les chiffres avancés sont ceux de **Stripe**, **Spotify** et **Amplitude** ; GitLab n'en produit qu'un, sur son propre contrôle de source. Le corpus tient déjà [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], la source à laquelle ce texte répond, et [[sfeir-sdlc-pdlc-articulation-2026-07-22]] sur l'articulation SDLC/PDLC que Staples reprend à son compte.
#abondance du code#coût par changement accepté#théorie des contraintes
Bill Staples · directeur général de GitLab (fonction non affichée par la page) · sur le blog about.gitlab.com.
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.
Guide signé **Michael Segner**, publié le **20 août 2026** sur le blog claude.com dans la catégorie *Claude Code* : **5 minutes** de lecture annoncées pour environ **31 500 caractères** de corps, également proposé en PDF. Matériau déclaré : des entretiens avec **plus d'une douzaine** de jeunes pousses, quinze nommées — **Artemis Security**, **Cainex**, **Clay**, **ClickHouse**, **Cognition**, **Commure**, **Crosby**, **Emergent**, **Harvey**, **Heidi**, **Higgsfield**, **Omni**, **Parahelp**, **Translucent**, **Zingage**. (A) Cinq règles d'exploitation : *everyone ships*, *automate the tedium*, *trust, but verify*, *build for rebuilding*, *prototype, dogfood, productionize*, chacune close par des astuces produit et reprise dans une checklist finale. (B) Un corps fait de citations attribuées, chaque règle étant illustrée par des dirigeants nommés plutôt que par une mesure agrégée. Les quatre chiffres mis en exergue sont ceux des entreprises interrogées : **+30 %** de fonctionnalités livrées (ClickHouse), **2 à 3×** de productivité d'ingénierie (Omni), **100 %** du tri de bugs automatisé (Clay), **plus de 6 000 PR par semaine** (Artemis Security). Deux passages sortent du registre du témoignage : la boucle d'auto-correction de **Cainex** sur le codage médical, décrite étape par étape, et l'usage interne de **Claude Tag** chez **Anthropic** comme premier répondant d'astreinte CI/CD. La question posée en ouverture — *« what would it look like if an organization built their product development lifecycle with Claude Code from the ground up? »* — rejoint [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], paru le lendemain chez le même éditeur, et prolonge [[cherny-wu-reflecting-year-claude-code-2026-07-17]].
#Claude Code#jeunes pousses#everyone ships
Michael Segner · auteur du guide sur le blog claude.com (fonction non affichée par la page) ; entretiens avec les dirigeants de quinze entreprises nommées.
Billet du blog corporate de **Block** (`block.xyz/inside`), non signé — l'auteur affiché est **« Block »** —, publié le **18 août 2026**, ~930 mots, qui annonce **l'ouverture du code de Berd**, l'application de bureau interne de Block pour travailler avec des agents, et expose la thèse de conception qui l'a guidée : donner du caractère aux agents *« not only through roles, instructions, skills, and tools, but through distinctive visual identities »* — d'où les personnages animés maison, les *« Gloopies »*. Le billet part d'un constat de fragmentation (*« The technology was powerful, but the experience around it was fragmented »*) et d'un problème d'interface nommé avec précision : *« 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 »*. Deux apports structurants. **(A) Une articulation en trois étages** : **goose** reste le framework et le *runtime* qui tient la boucle d'agent ; **Berd** est le client de bureau (projets, contexte, sessions, agents, configuration) ; les deux communiquent par l'**Agent Client Protocol**. **Buzz** est désigné comme la suite, quand le travail solo devient collaboratif (*« Start alone, then go multiplayer »*). **(B) Six exigences léguées à Buzz**, énoncées comme bilan : *« private space, durable context, recognizable agent identities, reusable skills, visible configuration, and clearer visibility into an agent's configured context, tools, and capabilities »* — grille directement réutilisable pour évaluer un client d'agents. Le texte distingue lui-même identité et capacité : *« The avatars make the agent recognizable. Its role, skills, and tools make it useful. »* Aucun chiffre d'usage n'est produit et aucune licence n'est nommée pour l'ouverture de code.
#Berd#Block#open source
**Aucun auteur nommé** : le billet est signé **« Block »** — le champ *Author* de la page porte le nom de l'entreprise. Publié le **18 août 2026** sur `block.xyz/inside` · le blog **corporate** · et non sur `engineering.block.xyz`.
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.