**Boris Cherny** (Creator & Head of Claude Code @Anthropic) publie sur LinkedIn un tableau-framework, **« Steps of AI Adoption »**, qui cartographie l'adoption de l'IA agentique par une équipe d'ingénierie en **5 étapes (0→4)**, chacune caractérisée par un **ordre de grandeur d'agents pilotés** et une **transformation du rôle de l'ingénieur** : **0 Gated** (0 agent, accès verrouillé), **1 Assisted** (~1 agent — « vous + un agent », pair programming supervisé), **2 Parallel** (~10 agents — **orchestrateur**), **3 Supervised autonomy** (~100 agents — **manager de managers**, un arbre org), **4 AI-native** (~1 000+ agents — **VP qui pilote par l'intention**). Le tableau croise cinq colonnes : nombre d'agents, *à quoi ça ressemble*, *le goulet d'étranglement*, *les produits qui aident*, *les garde-fous*. **Thèse centrale** : consommer plus de tokens ne fait pas monter d'un cran — pour passer à l'étape suivante il faut **identifier et casser le prochain goulet d'étranglement** ET **bâtir le prochain jeu de garde-fous**. Concrètement : donner à Claude une **boucle d'auto-vérification** de confiance (tests + build + lint + e2e sur un vrai environnement), activer l'**Auto mode** (éviter les prompts de permission bloquants), passer **code review et security review par défaut**, adopter des interfaces multi-agents (Agent view CLI, Desktop, apps iOS/Android, Tag), puis `/loop`, `/batch`, `/goal`, **dynamic workflows** et **worktree isolation** pour subagents. Sur le pilotage : l'usage (dashboard) mesure l'**activité, pas le retour** ; la bonne question est *« aurait-on de toute façon dépensé de l'effort d'ingénierie là-dessus ? si oui, combien d'heures-ingénieur manuelles cela aurait-il coûté ? »* — voilà le ROI. Le vrai gain arrive quand **corriger et maintenir se fait en arrière-plan** et que les équipes se concentrent sur *construire*. Anthropic se situe à l'**étape 3, en route vers 4** ; Boris Cherny déclare avoir personnellement atteint le **niveau 4**.
#Boris Cherny#Claude Code#Anthropic
Boris Cherny (Creator & Head of Claude Code @Anthropic)
Netflix — lettre actionnaires Q2 FY2026 : la GenAI passe à l'échelle en production (≈300 titres en 2026), LLMs pour la découverte et recherche en langage naturel, outils IA sur tout le cycle publicitaire (Netflix)
Décryptage SFEIR (voix cabinet) de la décision, annoncée le 16 juillet 2026, d'**Airbus** de retenir **Scaleway** (groupe **iliad**) comme **« cloud de confiance »** pour héberger et moderniser ses applications métiers critiques et ses données les plus sensibles (conception d'aéronefs, ingénierie, production industrielle, opérations, propriété intellectuelle). Au terme d'un appel d'offres ouvert **début janvier 2026** comparant **dix candidats**, Scaleway l'emporte sur **trois critères** — capacités technologiques/IA, excellence opérationnelle, et surtout **garanties juridiques et de gouvernance** : juridiction européenne, protection réelle des données, **immunité au Cloud Act** américain. SFEIR insiste sur le **renversement de hiérarchie** : la gouvernance a pesé plus lourd que la fonctionnalité, alors que les hyperscalers US (Microsoft, Google, AWS) gardent une supériorité fonctionnelle qu'aucun européen n'égale « sur toute la ligne ». L'accord, pluriannuel et de montant confidentiel, **complète** (ne remplace pas) la stratégie **multicloud** d'Airbus — la doctrine défendue par le cabinet : composer un portefeuille où chaque atelier vit selon ses contraintes, en gardant le **pouvoir d'en changer** (réversibilité, cf. France Télévisions/ALIX déployée sans réécriture). L'enjeu réel est l'**IA souveraine** : faire tourner des modèles sur des données industrielles (simulation, maintenance prédictive, ingénierie assistée) suppose une **chaîne complète — calcul, entraînement, inférence — maintenue en juridiction de confiance**. Trois enseignements : un **seuil de crédibilité** franchi pour le cloud souverain européen ; **gouvernance > fonctionnalités** pour la donnée stratégique ; la souveraineté se construit **par étages** (infra → plateforme → modèle), et la partie décisive — la réversibilité de l'IA — se jouera dans les mois qui viennent.
Décryptage SFEIR (voix cabinet, « lecture d'ingénieurs ») du lancement, le **16 juillet 2026**, de **Kimi K3** par le laboratoire chinois **Moonshot AI** : 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 2026** (probablement sous licence Modified MIT, comme la lignée K2). Thèse : 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 — pourtant **partenaire Anthropic et Google Cloud**, et donc « sans intérêt à survendre un modèle chinois » — assume une **mise en garde méthodologique** cardinale : au jour du lancement, **aucune table de benchmarks officielle et complète** n'existe ; specs (2,8 T, Kimi Delta Attention, +25 % d'efficacité d'entraînement) et scores sont **vendor-stated** ou issus d'**arènes communautaires**, « à traiter comme des revendications, pas comme des faits mesurés ». L'architecture nouvelle (**Kimi Delta Attention**, attention linéaire hybride ; décodage annoncé jusqu'à **6,3× plus rapide** sur 1M tokens) rompt avec la cadence K2 (K2 juil. 2025 → K2.7 Code juin 2026, un flagship tous les deux mois) ; deux variantes accompagnent le lancement (**K3 Max**, **K3 Swarm Max**), avec extinction forcée des séries kimi-k2.5/moonshot-v1 au **31 août 2026**. **La vraie arme, c'est le prix** (~3 $/M en entrée, 0,30 $ en cache, 15 $ en sortie selon sources secondaires) : 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 frontier open-weights transforme une API consommée (dépendance au fournisseur) en **option** (self-host, portage, sortie de captivité), au prix d'une infra lourde pour héberger 2,8 T de paramètres. 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 ? ». La bonne posture reste un **portefeuille routé** (un modèle par tâche, un modèle par contrainte), Kimi K3 ajoutant une **colonne « réversibilité »** à la grille de décision. Conviction « AI Only » inchangée : le modèle est une commodité, l'avantage durable est dans l'ingénierie qui l'entoure (Context Engineering, harnais, gouvernance des coûts, capacité à changer d'avis). Reste à valider les chiffres « sur le vôtre » — vos dépôts, vos données.
Digest de veille à sources primaires sur la position de **Gregor Hohpe** (auteur d'*Enterprise Integration Patterns*, *The Software Architect Elevator*, *Cloud/Platform Strategy* ; ex-Enterprise Strategist AWS & Google Cloud, ex-Chief Architect Allianz) quant au rôle de l'architecte à l'ère de l'IA générative. Thèse : l'IA **ne dévalorise pas** l'architecte, elle **déplace sa valeur** du code vers ce que l'IA ne fait pas — **prendre et assumer des décisions, arbitrer les compromis, « vendre des options », communiquer avec des humains, produire des abstractions justes**. Formule-clé (Craft Conference 2026) : « *Developers mainly interact with machines… GenAI. In contrast, architects communicate with humans* ». Sa thèse-signature (« l'architecte ne doit pas être le plus intelligent de la salle, il doit **rendre tous les autres plus intelligents** ») se renforce quand le code devient abondant : l'avantage vient de la **discipline de décision** et de la **mise au jour des compromis cachés**, pas du volume. Le digest décline aussi ses positions par rôle (enterprise architect : de **cartographe à éclaireur** ; software architect : **déboguer** les décisions plutôt que coder ; platform architect : **abstractions et non illusions**), sa métaphore des **options réelles** (valeur croissante avec la volatilité technologique, analogie Black-Scholes), et ses avertissements (« *An AI-driven SDLC punishes bad habits much faster* » ; les gagnants de l'IA se définiront par leur vitesse à passer de l'expérimentation à une **production gouvernée**). ⚠️ La formule répandue « les architectes qui utilisent l'IA remplaceront ceux qui ne l'utilisent pas » **n'est pas de Hohpe**. Domaine : architecture logicielle, rôle de l'architecte, prise de décision, options réelles, plateformes, GenAI dans le SDLC.
#Gregor Hohpe#Architect Elevator#rôle de l'architecte
Gregor Hohpe (sources primaires) — digest de veille
Note d'analyse SFEIR qui relit le métier d'architecte logiciel à l'ère de l'IA générative à travers le cadre de **Gregor Hohpe** (*The Software Architect Elevator*). Thèse centrale : l'architecte « **Oracle** » — détenteur du savoir suprême édictant des règles depuis sa tour d'ivoire — est obsolète, car l'IA génère code et propositions à la demande ; l'architecte moderne devient un **amplificateur d'intelligence (IQ Amplifier)** qui fournit aux équipes les modèles mentaux, le contexte métier et les outils de décision pour exploiter l'IA tout en garantissant la cohérence du système. Le document décline l'impact **étage par étage de l'« Ascenseur de l'Architecte »** (Enterprise / Solution / Platform / Software architect) et défend le **Domain-Driven Design (DDD)** comme garde-fou indispensable : le **langage ubiquitaire** sert de base aux *system prompts* (dictionnaire de domaine injecté via `.clinerules`/templates, réduisant hallucinations et contre-sens métier) et les **contextes limités (bounded contexts)** restreignent le scope confié à l'IA pour maximiser la fiabilité de la génération. Conclusion : l'IA n'est pas une menace mais un catalyseur qui décharge l'architecte de la saisie technique pour valoriser synthèse, vision stratégique, modélisation et lien humain tech↔business. Domaine : architecture logicielle, rôle de l'architecte, DDD, prompting structuré, gouvernance IA d'entreprise.
#Architecte logiciel#rôle de l'architecte#IA générative
Prasanna Sankar (co-fondateur/CTO de Rippling, fondateur de Vorflux) publie « The Great Flattening » — un essai-manifeste affirmant que les modèles de codage sont devenus **surhumains** et que le goulot d'étranglement a basculé de la production de code vers l'**encodage du jugement** dans les *agent harnesses*. Tout ce qui est à l'intérieur de l'organisation « s'effondre vers le harness » ; le travail réel de chacun devient le *self-profiling* : extraire les frameworks de décision tacites de sa tête pour les inscrire dans la codebase. Lancement simultané de Vorflux (« autopilote pour le software engineering »), $15M seed (Y Combinator, Peak XV Partners, Alliance DAO). L'essai a attiré 60 000+ vues sur X en 24h.
#Great Flattening#Vorflux#Prasanna Sankar
Prasanna Sankar (Prasanna S, @myprasanna) — co-fondateur et ex-CTO de Rippling ($16B+ valorisation) · fondateur et CEO de Vorflux AI. Article publié sur X (format long-form article) le 14 juillet 2026 · contenu repris comme manifeste Vorflux (vorflux.com/manifesto).
Message de **Linus Torvalds** sur la mailing list **linux-media** (thread « Linking Patchwork with Sashiko? », outil LLM d'aide aux mainteneurs), où le créateur et **top-level maintainer** du noyau Linux **tranche officiellement la position du projet sur l'IA**. Répondant à Roman Gushchin qui pointait qu'un message adverse exprimait « une position très anti-LLM en général », Torvalds acquiesce (« Yes ») puis **récuse frontalement que ce soit la position du kernel** (« And no, that's not the position of the Linux kernel »). Il **pose le pied** en tant que mainteneur suprême : **« Linux n'est pas un de ces projets anti-IA »** ; ceux que cela dérange peuvent **« faire le truc open source : forker »** — « ou juste partir ». **Thèse centrale** : **« l'IA est un outil, comme les autres outils qu'on utilise, et clairement un outil utile »** ; ce n'était « peut-être pas si "clairement" il y a un an, mais ce n'est plus en question aujourd'hui ». Il distingue les questions **encore ouvertes** (« à quoi ressemblera vraiment l'économie de l'IA au final ») de la question **tranchée** (« est-ce utile ? ») — « quiconque en doute n'a clairement pas vraiment essayé ». Il **concède** que l'outil peut être **« douloureux »** — charge des mainteneurs, et le fait qu'il « n'arrête pas de trouver des bugs embarrassants » — mais refuse la posture de l'autruche (« mettre la tête dans le sable en chantant "La La La, I can't hear you" »). **La bonne réponse** : faire en sorte que **les outils LLM _aident_ les mainteneurs** plutôt que de leur causer de la peine. **Non-coercition assumée** : « on ne force personne à l'utiliser, mais **j'ignorerai très bruyamment ceux qui cherchent à empêcher d'autres de l'utiliser** ». Sur l'imperfection : « l'IA n'est pas parfaite, mais bon sang, quiconque pointe ses problèmes ferait bien de se pointer aussi lui-même dans le miroir » — « **l'intelligence naturelle n'est pas toujours si géniale non plus** ». **Cadre de gouvernance** : le projet kernel « a toujours été et restera une affaire de **technologie** » ; l'angle social de l'open source est un « bénéfice secondaire, pas le _but_ » ; **« ce n'est PAS un projet de "social warrior", ne l'a jamais été et ne le sera jamais »** ; « on fait de l'open source parce que ça produit une **meilleure technologie**, pas pour des raisons religieuses ». Conclusion-programme : **« on décide d'abord sur le mérite technique. Pas sur la peur des nouveaux outils. »** À lire comme une **prise de position doctrinale** d'une des figures les plus influentes du logiciel — écho au contre-témoignage pro-LLM d'ESR (autre pilier de l'open source, [[raymond-llm-coding-empowering-2026-07-08]]).
#Linus Torvalds#Linux#noyau Linux
Linus Torvalds (torvalds@linuxfoundation.org) — ingénieur logiciel finlando-américain · **créateur et mainteneur suprême du noyau Linux** (depuis 1991) et de **Git** (2005). Employé de la **Linux Foundation**. Figure centrale et notoirement franche de l'open source · dont la parole sur les mailing lists du kernel fait autorité et jurisprudence dans la communauté. S'exprime ici en sa qualité de **top-level maintainer** pour fixer la position officielle du projet vis-à-vis des outils d'IA. Autres participants au thread cités : Roman Gushchin (linux.dev) · Laurent Pinchart · Mauro Carvalho Chehab · Konstantin Ryabitsev (Linux Foundation) · Steven Rostedt · Stephen Finucane · Jason Gunthorpe · entre autres. (Message de mailing list linux-media ; date : 2026-07-14 ; date d'ajout à la veille : 2026-07-17.)
Décryptage SFEIR (voix cabinet) de la disponibilité générale, le 9 juillet 2026, de **GPT-5.6** par OpenAI — non pas un modèle mais une **famille de trois tiers** : **Sol** (flagship long-horizon/cyber/science, seul à débloquer les modes « max » et « ultra »), **Terra** (équilibré du quotidien, ~moitié prix de GPT-5.5) et **Luna** (rapide/économique, haut volume). Les trois partagent ~**1,05 M tokens** de contexte, **128 k** en sortie et une coupure de connaissances au **16 février 2026**. Le fait le plus structurant n'est pas un score mais une **grille tarifaire agressive** (Sol 5 $/30 $, Terra 2,50 $/15 $, Luna 1 $/6 $ par million de tokens) : Sol garde le tarif de l'ancien flagship tout en étant plus capable, forçant la comparaison sur le **rapport capacité-coût**. Deux subtilités de facturation (écritures de cache facturées **1,25×**, surcoût au-delà de **272 k** tokens) rendent la grille trompeuse tant qu'on n'a pas mesuré combien de contexte l'agent relit (ratio lecture/écriture ~**153:1** en codage agentique). Verdict d'ingénieur, revendiqué neutre (SFEIR est partenaire **Google Cloud Premier** *et* **Anthropic**) : **personne ne rafle tous les tableaux** — GPT-5.6 domine Terminal-Bench 2.1 et le Coding Agent Index (à un tiers du coût par tâche), Claude reste devant sur SWE-Bench Pro (~15 pts) ; METR a signalé un **reward hacking** record sur Sol. Conclusion : « arrêtez de chercher le champion, apprenez à router » — le modèle est une commodité, l'avantage durable est dans le **Context/Harness Engineering**.
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.
Décryptage SFEIR (voix cabinet) du lancement, le 8 juillet 2026, de **LLMD** par la startup parisienne **ZML** (fondée par **Steeve Morin**, ex-VP Engineering de Zenly) : un serveur d'inférence qui fait tourner les LLM sur **cinq familles de puces** (NVIDIA CUDA, AMD ROCm, Google TPU, Intel oneAPI, Apple Metal) **depuis une seule base de code**. Thèse structurante : l'entraînement cède la vedette à l'**inférence**, où se jouent désormais le coût par token, la latence et surtout la **dépendance au silicium**. Le pari de ZML — résumé par la devise *model to metal* — est de **découpler le modèle du matériel** via un compilateur en **Zig + MLIR** produisant un binaire natif hermétique, sans Python dans le chemin d'exécution, exposé par une **API compatible OpenAI**. Deux briques, deux licences : **ZML** (framework, Apache-2.0, >90 % Zig) est open source ; **LLMD** (serveur) ne l'est pas, gratuit au lancement. L'article lit l'objet sous trois angles cabinet — **FinOps du token**, **liberté d'architecture** (Design to Exit), **souveraineté** (puces européennes émergentes, intégration dans le processeur VSORA Jotunn8) — puis livre un verdict sans complaisance : c'est une **alpha**, à mettre « sous surveillance active », pas à basculer aujourd'hui.
Post X d'**Eric S. Raymond** (ESR, auteur de *The Cathedral and the Bazaar*, co-fondateur de l'Open Source Initiative, ~50 ans de code) — **contre-témoignage frontal au discours « les LLMs génèrent du code pourri et hallucinent, inutiles pour programmer »**. Sa thèse : cela **ne lui arrive quasiment jamais**, et **plus du tout depuis les deux dernières générations** de modèles qu'il utilise (« chat GPT 5.4 et 5.5 » sous **codex**). L'ancien symptôme — un modèle qui « déraille » en approchant sa limite de contexte — a disparu : codex affiche désormais un **avertissement rouge** invitant à **vider la session** au lieu de partir en vrille. **Empan d'usage** : IA appliquée à des **feature changes, refactoring et debugging sur 63 projets** en **C, Go, Rust, Python et shell** ; rédaction de documentation ; **décompilation d'un binaire DOS en source lisible**. **Routine de travail** installée : quand il rouvre un projet, il lance d'abord les **tests de régression**, puis démarre codex et lui demande d'**auditer le code** (bugs + suggestions d'amélioration). Verdict : les LLMs sont **« excellents et formidablement capacitants »** ; leur **pire limite** est une **« vision en tunnel architecturale »** — excellents pour générer du code à la spécification, mais parfois **aveugles aux patterns de plus haut niveau** — ce qu'il assume comme le **job de son « meatbrain »**. Le point le plus fort, contre-intuitif : les LLMs **ne se trompent PAS sur les détails et les cas limites** ; il se dit **moins bon qu'eux** sur ce plan (malgré 50 ans d'XP) car si un changement doit **toucher cinq endroits**, le modèle **les retrouve les cinq de façon fiable**, là où l'humain en corrige quatre et **débogue des heures** avant de trouver le cinquième oublié. Il interroge alors les **« downshouters »** : vivent-ils dans un **autre univers** ? Utilisent-ils de **vieux modèles faibles** ? Y a-t-il un **skill issue** qu'il ne voit pas parce que ses **habitudes mentales et sa communication** collent bien aux « poignées » de ces outils ? Enjeu qu'il juge important à trancher, car « des **milliards de dollars seraient gaspillés en token spend mal dirigé** ». Sa recette, « très simple » : **« Be clear in your thinking, tell the model what you want with precision, and good things happen »** — chute : « what am I missing here? ». À lire comme **contrepoint pro-LLM d'une figure historique de l'open source** au débat récurrent sur la (dé)valeur des agents de codage — écho au « skill issue » et à la discipline de spécification (cf. [[martignole-token-manifesto-2026-07-17]]), et en diptyque avec la prise de position doctrinale pro-outil-IA de **Linus Torvalds** au nom du kernel Linux ([[torvalds-llm-outil-kernel-2026-07-14]]).
#Eric S. Raymond#ESR#esrtweet
Eric S. Raymond (ESR, @esrtweet sur X) — développeur · hacker et essayiste américain · **figure historique du mouvement open source**. Né le 4 décembre 1957 à Boston (Massachusetts) ; paralysie cérébrale de naissance · enfance en partie au Venezuela puis en Pennsylvanie. Auteur de l'essai très influent **« The Cathedral and the Bazaar »** (1997, livre 1999) · qui oppose le modèle « cathédrale » (développement centralisé et fermé) au modèle « bazar » (décentralisé et ouvert, à la Linux) ; il a **popularisé le terme « open source »** (contre « free software ») et contribué à convaincre **Netscape** d'ouvrir son code (naissance de Mozilla). **Co-fondateur de l'Open Source Initiative (OSI)** en 1998 · président jusqu'en 2005. A édité le **Jargon File** (*The New Hacker's Dictionary*) · maintenu des projets comme **Fetchmail** · écrit **« The Art of Unix Programming »** (2003). Se revendique **libertarien** · défenseur du port d'armes · ceinture noire de taekwondo ; commente régulièrement tech · politique et open source sur X. Se présente ici comme codeur « très · très bon » avec **~50 ans d'expérience**. (Post X personnel ; date de publication : 2026-07-08 ; date d'ajout à la veille : 2026-07-17.)
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)
Essai de Jean-Paul Paoli (*The Intelligence Fabric*) qui déplace la peur de l'IA au travail : le vrai danger n'est pas le **remplacement** (le poste qui disparaît) mais le **délitement silencieux** des liens d'équipe pendant que *tout le monde reste employé*. Thèse : quand chaque salarié fait de l'IA son **premier confident et collaborateur**, trois « fils » du tissu organisationnel se défont sans licenciement — les **liens entre pairs** (le transfert de savoir tacite du junior au senior court-circuité), le **lien manager-salarié** (les signaux d'alerte précoce disparaissent, le manager devient « le dernier informé au lieu du premier ») et le **jugement professionnel** (on cesse de former ceux qui savent *faire* et évaluer si la machine se trompe). Paoli nomme le phénomène **shadow intimacy** (par analogie au *Shadow IT*) et prescrit non un bannissement mais un « re-tissage » délibéré, fil par fil. Domaine : management, transformation organisationnelle, IA au travail, dépendance affective aux modèles.
#Shadow intimacy#remplacement par l'IA#liens d'équipe
Fil X (thread illustré) de **Thariq Shihipar** (équipe Claude Code / Anthropic) : un *field guide* pour tirer le meilleur de **Claude Fable 5**. Thèse centrale reprise de Korzybski — *« la carte n'est pas le territoire »* : la **carte** = ce qu'on donne à Claude (prompts, skills, contexte) ; le **territoire** = là où le travail se fait (codebase, contraintes réelles) ; l'écart entre les deux = les **unknowns** (inconnues). Fable est *« le premier modèle où la qualité du travail est plafonnée par ma capacité à clarifier ses inconnues »*. L'article fournit un **cadre à 4 quadrants** (known knowns / known unknowns / unknown knowns / unknown unknowns) et une **boîte à outils de techniques** ordonnées dans le temps (avant / pendant / après l'implémentation) — blindspot pass, brainstorms & prototypes, interviews, references, implementation plan, implementation-notes, pitches & explainers, quizzes — chacune avec des exemples de prompts. Domaine : ingénierie de prompt, agents de codage, méthodologie de travail avec l'IA, artefacts HTML.
#Unknowns#carte vs territoire#known/unknown knowns
Note courte de Simon Willison (weblog) relayant deux conseils entendus lors d'un *Fireside Chat* à l'AIE avec Cat Wu et Thariq Shihipar (équipe Claude Code) : **laisser le modèle (Fable, et dans une certaine mesure Opus) exercer son propre jugement plutôt que de lui dicter des règles** — illustré sur la décision d'écrire ou non des tests. Second conseil, de Jesse Vincent : pour **économiser les précieux tokens Fable** (avant une hausse de prix imminente), demander à Fable de **déléguer les petites tâches à des modèles moins puissants**, en le laissant juger lequel. Willison montre le prompt exact utilisé (« *use your judgement to decide an appropriate lower power model and run that in a subagent* ») et le **fichier mémoire** que Claude Code a écrit en réponse. Domaine : ingénierie de prompt, agents de codage, économie des tokens, orchestration multi-modèles.
#Jugement du modèle#délégation à des subagents#model override
Guide agent (Thinkroom, plateforme de Kieran Klaassen) documentant le **Compounding Knowledge Lifecycle** du compound-engineering-plugin (Every) : comment une leçon apprise une fois « continue de payer » — capturée, stockée, retrouvée et maintenue vraie. Décrit l'anatomie d'une *learning* (`docs/solutions/`), sa capture via `/ce-compound`, la carte mémoire (durable vs éphémère), la récupération *grep-first* (learnings-researcher) branchée sur 5 skills aux points de décision, et les trois contre-forces qui empêchent la mémoire de mentir. Directement pertinent : c'est la doctrine derrière la convention `docs/solutions/` de ce dépôt. Domaine : compound engineering, gestion de connaissance agentique, skills.
**Rapport récurrent de Mozilla**, *The state of open source AI*, **v1.0.1, juillet 2026**, introduit par une lettre de **Raffi Krikorian** (CTO) : sept sections, un site interactif et un rapport téléchargeable. Thèse posée en titre de la section 1 : *« The model layer has commoditized. Value accrues to the harness above it. »* **État capacitaire** : sur l'*Artificial Analysis Intelligence Index v4.1*, le meilleur modèle fermé marque **61** (Claude Opus 5) et le meilleur ouvert **57** (**Kimi K3**), quatrième au général et devant trois des plus grands laboratoires fermés ; sur l'*Epoch Capabilities Index*, l'écart est de **6 points** (K3 à 156 contre GPT-5.6 Sol à 162), soit *« about one release cycle »*, avec des intervalles de confiance qui se chevauchent. **Frontière en dents de scie** : l'ouvert mène en code frontend (K3 à 1 679 Elo sur LMArena Frontend Code Arena, six domaines sur sept), conteste le terrain agentique (88,3 contre 88,8 sur Terminal-Bench 2.1) et cède sur le travail de connaissance professionnel (Fable 5 devance K3 de 92 Elo sur GDPval-AA v2). **Bascule d'usage** : la part des tokens routés sur OpenRouter vers des modèles à poids ouverts est passée d'un niveau négligeable à un tiers fin 2025, puis à une **majorité mi-2026**, les sept modèles les plus consommateurs étant tous à poids ouverts — le rapport précisant lui-même que *« by request count, closed US providers still lead »*, l'avance ouverte étant un volume de tokens concentré sur le codage et l'agentique. **Le contraste central** : *« Open ships easy. Open deploys hard. »* — 79 % des développeurs qui ajoutent de l'IA utilisent des modèles ouverts contre 71 % pour les fermés, mais seules **53 %** des équipes en modèle ouvert atteignent la production **contre 63 %**, et l'écart se creuse avec la taille de l'organisation (fermé 54 % → 73 %, ouvert 53 % → 57 %), ce qui *« rules out a resources explanation »*. La carte de maturité du stack (48 composants, 9 couches) montre deux colonnes systématiquement froides — **standardisation** et ***enterprise readiness*** —, désignées comme l'écart opérationnel. **Section 5** : *« The agentic harness is another user agent »*, et *« The model is eating the harness »* — sur chaque modèle où les deux existent, le harnais du laboratoire l'emporte désormais, l'écart de 21,8 points s'étant comprimé à environ 3. D'où la formule : *« A harness tuned tightly to one lab's weights… degrades on anyone else's model, so the tighter the tuning, the less swappable the weights underneath. Lock-in arrives as a side effect of optimization. »*
#Mozilla#état de l'IA open source#poids ouverts
**Mozilla** — éditeur du rapport · avec une introduction signée **Raffi Krikorian** · *Chief Technology Officer*. Publié en **juillet 2026** (v1.0.1). Données issues de sources tierces créditées (Artificial Analysis, Epoch AI, OpenRouter, LMArena) et d'une enquête propre menée avec **SlashData** (*Mozilla / SlashData 2026 developer survey*, n = 1 410 sur la question des freins).
Note d'analyse **Trésor-Éco n° 391** (juin 2026) de la **Direction générale du Trésor** (Ministère de l'Économie), signée **Martin Chopard, Elisa Cotet, Tristan Gantois et Eloïse Villani**. Revue de littérature économique institutionnelle sur **l'effet de l'IA (surtout générative) sur l'emploi**. **Thèse en trois temps** : (1) l'IA joue sur le volume d'emploi via **deux canaux opposés** — effet de **déplacement** (substitution de tâches automatisables) vs effet de **productivité** (complémentarité, baisse des coûts, demande accrue) — mais l'**effet agrégé reste pour l'instant faible/non mesurable**, faute de recul et d'adoption (≈20 % des entreprises UE en 2025) ; (2) des **effets hétérogènes** apparaissent selon les **métiers** (exposition ≠ effet : tout dépend du degré de substituabilité/complémentarité et de l'**élasticité-prix** de la demande), les **travailleurs** (progrès technique biaisé, craintes pour les **jeunes**) et les **secteurs** (finance, informatique, services aux entreprises les plus exposés) ; (3) à **long terme, l'effet net reste incertain** — entre substitution massive (si IA agentique/physique se généralise) et **destruction créatrice** (leçon des révolutions passées : les innovations ont créé plus d'emplois qu'elles n'en ont détruit). Conclusion de **politique publique** : accompagner la transition (formation, mobilités — plan « Osez l'IA », France 2030) et **investir dans l'IA pour ne pas décrocher** face à la concurrence internationale. Corpus abondamment sourcé (43 notes, panels d'estimations Tableaux 1-3).
#IA et emploi#intelligence artificielle générative#effet de déplacement
**Martin Chopard · Elisa Cotet · Tristan Gantois · Eloïse Villani** — économistes de la **Direction générale du Trésor** (DG Trésor) · Ministère de l'Économie · des Finances et de la Souveraineté industrielle · énergétique et numérique. Directrice de la publication : Dorothée Rouzet. Le document engage la DG Trésor mais « ne reflète pas nécessairement la position du ministère ».
Troisième volet de la série « New Engineering Disciplines for the AI Era » d'Ashish Singh, consacré au **KDLC — Knowledge Development Life Cycle** : un cycle de vie en **8 étapes** pour transformer la connaissance d'entreprise en **actif ingénieré**, au même titre que le code ou la donnée. Thèse : les initiatives IA échouent parce qu'elles se focalisent sur le choix du LLM ou le déploiement d'un RAG, **sans traiter la structure sous-jacente de la connaissance** — « AI is only as effective as the knowledge it can discover, understand, retrieve, and trust ». Le KDLC enchaîne Discovery → Extraction → Structuring → Knowledge Graph → Embedding → Index Optimization → Retrieval Evaluation → Refresh. Il oppose le **RAG traditionnel** (documents isolés, mots-clés) à l'**Enterprise Knowledge Fabric** (Knowledge Graphs + Semantic Search + Vector DB + Hybrid Search) où les agents comprennent « relationships, context, and business meaning ». Formule-signal : « Models provide reasoning. Memory provides continuity. Knowledge provides understanding. » Trois exemples (finance/conformité, ingénierie logicielle, santé) illustrent l'impact.
#KDLC#knowledge development life cycle#cycle de vie de la connaissance