Post X d'**Andrew Ng** du **14 août 2026** (16:29 UTC), reprise de la lettre « Dear friends » de ***The Batch* n°366** (DeepLearning.AI, même date), ~900 mots. Ng présente **The AI Engineering Skills Map** et publie **quatre compétences** tenues pour les plus importantes. **(1) Construire et déployer des applications IA** — la spécificité est nommée : *« The key difference between AI and non-AI applications is that the former has unpredictable outputs »*, d'où l'accent mis sur les *evals* et les boucles d'analyse d'erreurs. **(2) Les fondamentaux du génie logiciel**, parce que *« Understanding software fundamentals allows you to recognize what tradeoffs even exist »* — le développeur inexpérimenté échoue *« because they don't know what context to give their coding agent »*, d'où l'objectif de *« steering coding agents using the precise language of software engineering »*. **(3) L'usage des agents de codage**, dans une formulation opérationnelle : *« help the agent autonomously close loops by providing verifiers or evals »*, et *« knowing how much to intervene and how much to leave them alone »*. **(4) *Shaping the build*** : *« Given a clear spec, coding agents are rapidly improving at delivering to it. Thus, our work as engineers is shifting toward deciding what should be in the spec »*, assorti de *« Engineers should no longer expect to be given a pixel-perfect design and asked only to implement it. »* Une **note de terminologie** porte l'essentiel du cadrage : Ng parle de **compétences** d'AI engineering et **non du rôle** « AI Engineer », avec une analogie explicite — *« All developers today should know how to work with the cloud, and only a smaller number have a "Cloud engineer" title. »* L'ensemble est adossé à *« une analyse de plus de 10 000 offres d'emploi, des dizaines d'entretiens structurés avec experts, hiring managers et recruteurs, des sondages et d'autres données en ligne »*, dont **aucun résultat chiffré n'est publié** : Ng qualifie son procédé de *« informally… akin to running clustering »* et annonce une carte détaillée dans de futurs billets. Il déclare l'intérêt en avant-dernière phrase : *« DeepLearning.AI's principal focus is to help developers gain these AI engineering skills. »*
#AI Engineering Skills Map#carte des compétences#Andrew Ng
**Andrew Ng** — fondateur de **DeepLearning.AI** · general partner d'**AI Fund** · cofondateur de **Coursera** et de **Google Brain** · ancien chief scientist de Baidu. Texte signé · à la première personne · écrit *« with my team »* sans qu'aucun collaborateur soit nommé. Publié le **14 août 2026** sur X et dans ***The Batch* n°366** — même texte aux deux endroits ; préférer *The Batch* pour toute citation durable. Quatrième fiche Ng du corpus · après les lettres n°350 (24 avril) · n°352 (8 mai) et n°359 (26 juin).
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)
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
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.)
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.)
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 ».
Interview vidéo enregistrée sur **VivaTech** (stand **Scaleway**), diffusée par le média **République**, réunissant **Damien Lucas** (CEO de Scaleway) et **Franck Le Moal** (Global Technical Officer du groupe **LVMH**). **Thèse centrale** : l'émergence d'une **« géopolitique de la tech »** force les multinationales à abandonner la solution mondiale unique au profit d'un **système d'information régionalisé en trois plaques** (États-Unis, Europe, Chine). LVMH (80 Md€ de CA, 75 maisons, 100+ pays) officialise un partenariat **cloud avec Scaleway** pour bâtir une **brique européenne autonome**, en complément de Google Cloud (data, depuis 2021), SAP, Salesforce côté occidental et Alibaba Cloud / Huawei / Tencent côté chinois. Le groupe se dit **« hybride »** et **autonome** plutôt que **« souverain »** (mot qu'il refuse, jugé ambigu). Scaleway se positionne en **cloud provider européen** immune aux lois extraterritoriales et protégé contre un **kill switch** (« pas de la science-fiction », au vu de l'actualité du week-end). Argument économique de Damien Lucas : **1 € dépensé chez Scaleway = 68 centimes qui restent dans l'économie européenne** (vs < 20 centimes chez un hyperscaler US, même hébergé en France). Calendrier : PoC terminés, démarrage chez **Sephora et Louis Vuitton**, empreinte significative visée à **12-18 mois**. Mission Scaleway assumée : se concentrer sur **IaaS / PaaS** (pas de verticalisation type bureautique), s'appuyer sur un écosystème de partenaires (applicatif souverain, chipsets et serveurs européens). Le recours aux **GPU Nvidia / IA** de Scaleway n'est **pas prévu à court terme** mais reste ouvert (modèles open source pour l'autonomie + performance économique).
**Bertrand** — journaliste / présentateur du média **République** (partenaire de VivaTech) · conduit l'entretien. **Damien Lucas** — CEO de **Scaleway**. **Franck Le Moal** — Global Technical Officer du groupe **LVMH**.
Retraite Thoughtworks sur l'avenir du développement logiciel avec les LLM — réflexions sur l'impact organisationnel, la dette cognitive et la programmation supervisée