📰 L'actu
OpenAI autorisera les conversations érotiques pour les adultes vérifiés dès décembre: Sam Altman a confirmé que ChatGPT lèvera ses restrictions de contenu adulte (x.com) après avoir développé de nouveaux outils de sécurité mentale. Cette évolution répond à la concurrence des compagnons IA de xAI et transforme ChatGPT en plateforme plus permissive pour les utilisateurs majeurs.
La Californie devient le premier État à réguler les chatbots compagnons IA: La loi SB 243 impose aux entreprises comme OpenAI et Character AI des vérifications d'âge et des alertes (techcrunch.com) pour protéger les utilisateurs vulnérables. Cette réglementation prend effet en janvier 2026 et pourrait servir de modèle à d'autres juridictions.
Le petit modèle (7 millions de paramètres) de Samsung surpasse GPT-5 et Gemini sur des tâches de logique: Le Tiny Recursive Model atteint 44,6% de réussite sur ARC-AGI (arxiv.org) grâce à une approche récursive qui compense la petite taille par des passes multiples de raisonnement. Cette méthode démontre que l'architecture peut rivaliser avec la force brute des modèles géants.
OpenAI signe un partenariat de plusieurs milliards avec Broadcom pour développer ses propres puces IA: Les deux entreprises collaborent depuis 18 mois (openai.com) pour concevoir 10 gigawatts de processeurs personnalisés qui seront déployés entre 2026 et 2029. Cette alliance permettra à OpenAI de réduire sa dépendance à Nvidia et d'optimiser ses coûts d'infrastructure, avec l'IA elle-même participant à la conception des puces.
💡 Le travail comme traduction
Aparna Chennapragada, Chief Product Officer chez Microsoft AI for Work (ancienne fondatrice de Google Lens), observe que la plupart du travail en entreprise n'est ni de la création ni de l'exécution.
C'est de la traduction.
Un développeur transforme des spécifications en code. Un chef de projet transforme des activités en comptes-rendus. Un avocat transforme des risques en clauses. Un analyste transforme des journaux système en analyses. Un commercial transforme des problèmes clients en propositions.
Les chiffres : les développeurs écrivent du nouveau code seulement 10 à 16% de leur temps. Le reste ? Débugger, planifier, chercher du contexte. Les travailleurs du savoir passent 57 à 60% de leur temps à coordonner et communiquer. Les organigrammes en pyramide existent précisément pour gérer ce coût : une épaisse couche d'intermédiaires qui transportent l'information.
Sa thèse : les LLMs sont les premiers traducteurs universels pour le travail. Un rapport de 20 pages devient instantanément un mémo d'une page. Une réunion de 60 minutes devient une synthèse de 4 minutes. Des exigences deviennent du code avec tests. Pour la première fois, le coût unitaire de la traduction est proche de zéro.
L'impact : les couches intermédiaires se compriment. Les pyramides deviennent des "backbones" (épines dorsales). Les individus passent moins de temps à produire des artefacts et plus de temps à les juger. Les petites organisations peuvent coordonner à l'échelle des grandes.
La création et l'exécution justifient l'existence d'une entreprise. La traduction a toujours été le coût de faire des affaires. Ce coût est en train de s'effondrer.
📚 La documentation de Thomas
Le documentaliste
Il y a quelques mois, j'ai dû ajouter une fonctionnalité sur un vieux projet. Vraiment vieux. Le genre de code que je ne comprends plus, même si c'est moi qui l'ai écrit.
Je l'avais plus trop en tête. Vague souvenir qu'il y avait un truc particulier sur cette partie. Période pré-Claude Code, plonger là-dedans m'aurait coûté cher.
J'ai utilisé ma technique habituelle : les questions bêtes - poser des questions dont je connais déjà la réponse pour guider le modèle dans la bonne direction. Sauf que cette fois, différence notable : je ne savais pas la réponse. Ou plus. Je l'avais oubliée.
Ça a marché quand même. Ça m'a permis de me rafraîchir progressivement la mémoire. Et de cibler de mieux en mieux les questions.
Mais je suis amené à bosser de temps en temps sur ce code. Dans 6 mois, j'aurai encore oublié. Vous connaissez ça ?
Du coup, au lieu de juste coder la fonctionnalité avec l'aide de Claude Code, je me suis fixé un autre objectif : générer la documentation nécessaire pour que Claude Code puisse coder la fonctionnalité tout seul. Sans mon aide.
La doc que je cherche à créer, c'est pas une doc de la fonctionnalité elle-même. C'est une doc qui décrit le fonctionnement, l'architecture, l'environnement du code existant. Le contexte nécessaire pour comprendre comment ce code fonctionne.
L'idée : investir du temps maintenant pour en gagner dans 6 mois.
J'ai procédé par itérations.
v0 : J'ai posé plusieurs questions successives pour créer une première doc.
Test : Nouvelle session Claude Code. Je lui demande de coder la fonctionnalité en lisant la doc au préalable.
Échec. Mais l'échec est informatif. J'observe où il bloque. Quelles questions il pose. Quelles hypothèses erronées il fait.
v1 : À partir de ce que j'ai observé, je repose des questions. Je l'oriente. Le force à découvrir les zones qu'il a manquées. La doc se construit par ce dialogue, pas en solitaire.
Retest. Nouvelle session, même demande.
Échec. Mais différent. Il bloque ailleurs. Je recommence.
v2, v3... jusqu'à obtenir une doc qui lui permet de coder sans mon aide.
Pour que vous visualisiez, voici le début de la doc finale (écrite en pyramide inversée) :
Système Slideout - Pattern d'interface modulaire
Vue d'ensemble : Le système slideout est une architecture AJAX modulaire qui permet d'afficher dynamiquement des interfaces de gestion dans un panneau latéral, sans recharger la page.
Architecture de communication :
CLIC → Helper → JavaScript → Rails → Template → DOM
L'exemple est très concret, très technique. Mais le principe s'applique à tout usage de LLM : documenter le contexte d'une analyse de marché, décrire le ton et l'audience d'un article, préciser les contraintes d'un rapport financier.
Verdict : Quand il n'arrive pas à coder ce que je lui demande, c'est pas parce qu'il est nul. C'est que ma doc est incomplète. Ou ambiguë. Ou mal structurée.
Vous faites peut-être déjà ça sans le nommer ?
Amanda Askell disait (de mémoire, je retrouve pas la vidéo) que pour elle le prompt engineering c'était la capacité à faire faire au modèle ce que 99% des utilisateurs ne savaient pas lui faire faire.
Avec le bon contexte, la bonne doc, le modèle est capable de faire ce qu'on pensait impossible au départ.
y dépend de x. Bon x. Bon y. Bonne documentation. Bon y ?
En tant qu'utilisateur de LLM, on peut se voir comme un documentaliste.
Si le LLM n'arrive pas à faire la tâche qu'on lui a confiée, peut-être qu'on a mal fait notre job de documentaliste.
Shift de responsabilité. Ne pas blâmer le modèle. Interroger la qualité de sa doc.
D'ailleurs, on parle souvent de l'amélioration des modèles. Plateau ? Pas plateau ? Mais il y a aussi le fait qu'on est, nous aussi, les utilisateurs, en phase d'apprentissage sur comment utiliser ces modèles efficacement.
Je crois qu'on n'a pas atteint le plateau de ce côté-là non plus.
Mais ça, c'est pour une prochaine fois.
Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.
Samuel Beckett
🍷 Un dernier pour la route
