Article de fond (point de vue) publié sur **sfeir.com** le 23 juillet 2026, signé **SFEIR** (voix éditoriale du cabinet). C'est un **commentaire stratégique de la note Trésor-Éco n° 391** de la DG Trésor (juin 2026 — cf. [[dgtresor-ia-effets-emploi-2026-06-30]]), relu à travers la doctrine SFEIR « **amplifier l'IA plutôt que la subir** ». L'article salue le **ton prudent d'économiste** de Bercy (mécanismes + incertitude plutôt qu'une prédiction) et en extrait une **thèse en trois temps** : (1) **pas d'effet agrégé mesurable** à ce stade (deux forces qui se compensent — déplacement vs productivité — adoption UE ~20 %) ; (2) un **seul signal empirique solide, sur les juniors** (−16 % d'emploi des 22-25 ans exposés aux US) ; (3) un **danger de long terme qui déplace la question** — le **décrochage compétitif** (non-adoption), pas la destruction d'emplois. Le cœur analytique retenu par SFEIR : l'**élasticité-prix** décide de l'effet emploi (paradoxe de **Jevons** appliqué au code) → l'argument est **structurellement pro-emploi pour les développeurs**. L'article **démonte le narratif « licenciements IA »** (4,5-6,2 % des annonces US, « labellisation » à 59 %) et pointe les **angles morts** de la note (scénario agentique relégué en note de bas de page ; vitesse de diffusion non discutée ; OpenAI/Anthropic devenus sources de Bercy = biais de source non signalé). **Traduction opérationnelle SFEIR** (pour DSI/CTO) : la valeur migre vers intention/architecture/contrôle, former des **ingénieurs augmentés** (programmes **AI Champions**), et éviter l'adoption précipitée (**workslop**, dette technique) via **context engineering** et gouvernance.
#IA et emploi#décrochage compétitif#non-adoption
**SFEIR** — ESN française « AI Only » (~850 ingénieurs, 8 agences France & Benelux). Voix éditoriale du cabinet (byline « SFEIR »). Positionnement de la maison sur la transformation IA des DSI ; ce texte prolonge la ligne éditoriale portée notamment par Didier Girard (cf. [[girard-sfeir-ai4it-vs-ai4business-budgets-2027-2026-06-24]]).
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.)
Test de cohérence d'Ethan Mollick (Wharton) : on saura que les labos d'IA croient vraiment à l'ASI le jour où ils dissoudront leurs équipes *Forward Deployed Engineering* (FDE). Débat public avec roon (OpenAI) sur LinkedIn : roon objecte que c'est un **problème hayékien** (l'intelligence ne résout pas automatiquement le flux d'information organisationnel) et reprend le terme « **Gentle singularity** ». Consensus dans les commentaires : la technologie est la partie facile, la politique interne / les workflows legacy / la responsabilité contractuelle sont le vrai blocage. Formule-marqueur : *"Curing cancer might be easier than replacing Accenture"*. Opposition épistémique **East Coast vs West Coast** sur la trajectoire d'adoption de l'IA.
#ASI (Artificial Super Intelligence)#Forward Deployed Engineering (FDE)#consulting IA
Ethan Mollick (professeur Wharton, auteur *Co-Intelligence*) — auteur du post ; roon (employé OpenAI, identité publique anonyme, voix influente du cercle accel) — interlocuteur cité ; commentateurs anonymes (praticiens, consultants, chercheurs).
Blocage adoption IA en entreprise par IT/juridique, fossé entre entreprises innovantes et frileuses, leadership et gestion du risque - LinkedIn
#adoption IA#blocage entreprise#IT
Ethan Mollick
Adoption IA organisationnelle, transformation du travail, stratégie d'innovation, leadership, productivité, oneusefulthing.org
#Adoption IA#transformation organisationnelle#productivité
Ethan Mollick
Planification stratégique face aux futurs impossibles de l'IA et de l'AGI - One Useful Thing - Ethan Mollick
#AGI#Intelligence Artificielle Générale#planification stratégique
Ethan Mollick · Professeur à la Wharton School · University of Pennsylvania
Weave (workweave.dev) - Startup Y Combinator - Mesure du travail d'ingénierie par IA - Weave Hour - Attribution de code IA - Annuaire YC
#Weave#Workweave#Y Combinator
Y Combinator
Crise de sens au travail - Bouton "Help me write" - Setting time on fire - Signaux d'effort - Lettres de recommandation IA - Ethan Mollick - One Useful Thing
#The Button#Help me write#Google Docs
Ethan Mollick