0913 | L'IA à toute vitesse : puces, code et vie privée

||Download

Show notes

Une demi-heure sur ce qui se joue autour de l'IA : la gouvernance et le rythme du développement, l'IA dans le code professionnel et les agents qui s'auto-financent, la surveillance à la maison (téléviseurs, presse-papiers), le matériel qui accélère ou freine les transformers, et un tour des outils, de la recherche et des maths. Du hardware 8087 au Navier-Stokes, en passant par Zoom et LG.

Chronologie

  • 00:00:04 Introduction
  • 00:00:26 Le rythme de l'IA : gouvernance, ironie et choix personnels
  • 00:03:20 L'IA dans le code et l'industrie : benchmarks privés, agents et la « banque centrale » Nvidia
  • 00:06:38 Surveillance au quotidien : TV LG, presse-papiers Zoom, archives Usenet
  • 00:10:27 Puces et architectures : du Neural Engine d'Apple au microcode du 8087
  • 00:12:56 Outillage du développeur : profiler les builds, idées de langages, contribuer à OSM
  • 00:15:27 Recherche et fondements : induction heads, un 7G improbable, et Navier-Stokes
  • 00:17:32 Conclusion

Liens connexes

Cet épisode est produit par Bri. Bri utilise une technologie d'IA avancée pour transformer les flux qui vous intéressent en podcasts conçus pour l'écoute. Contactez-nous à hi@bri.so.

Transcript

Claire Martin: Bonjour à tous, bienvenue dans ce nouvel épisode du podcast. Je suis Claire Martin.

Nicolas Moreau: Et moi Nicolas Moreau. Ce qu'on a retenu des dernières vingt-quatre heures, c'est un fil rouge assez net : l'intelligence artificielle change de régime. On en parle plus comme une promesse, on en parle comme quelque chose qu'il faut gouverner, ralentir, mesurer — et qui déjà, concrètement, transforme le travail, l'argent, et même notre vie privée.

Claire Martin: Et ce débat-là, il est porté par des gens qui sont au cœur de la machine. Alors on commence fort : Dario Amodei, le patron d'Anthropic, publie un texte intitulé « Pacing the Frontier », « rythmer la frontière ». Et l'idée centrale, c'est que les grands labos devraient peut-être accepter de se limiter eux-mêmes.

Nicolas Moreau: Concrètement, qu'est-ce qu'il propose ? Trois choses. D'abord des « évaluateurs embarqués » — des embedded evaluators, des mécanismes d'évaluation intégrés aux systèmes eux-mêmes pour mesurer en continu ce que les modèles savent faire. Ensuite, une coordination au niveau de l'industrie : pas qu'un labo ralentisse tout seul et se fasse dépasser, mais un accord sectoriel. Et enfin, un ralentissement global du rythme de développement.

Claire Martin: Et la raison qu'il met en avant, c'est très précise : les risques de RSI. Recursive Self-Improvement, l'auto-amélioration récursive. L'idée qu'un système capable d'améliorer les systèmes qui le conçoivent — y compris lui-même — déclenche une dynamique qu'on ne peut plus contrôler une fois lancée. Donc le raisonnement d'Amodei, c'est : avant d'atteindre ce point, il faut avoir mis en place les garde-fous, parce qu'après, ce sera trop tard.

Nicolas Moreau: Ce qui est remarquable, c'est que ça vient de quelqu'un dont l'entreprise a tout intérêt à aller vite. C'est le dirigeant d'un des principaux labos qui demande publiquement qu'on mette des freins. Ça crée une tension intéressante : est-ce que c'est de la prudence sincère, ou est-ce qu'il y a une dimension stratégique — l'idée que les règles qu'on propose soient celles qui avantagent celui qui les écrit ?

Claire Martin: Et c'est exactement la question à laquelle personne n'a encore de réponse. Ce qu'on ne sait pas, et il faut le dire clairement : est-ce que les grands labos vont réellement accepter de se limiter, et surtout comment ? Des embedded evaluators, ça suppose qu'on sache déjà mesurer les capacités dangereuses. Une coordination sectorielle, ça suppose une confiance entre concurrents.

Claire Martin: Et un ralentissement global, ça suppose un mécanisme — réglementaire, contractuel, on ne sait pas — qui empêche les acteurs hors du club de filer à toute allure.

Nicolas Moreau: Et il y a un texte qui illustre parfaitement le problème de crédibilité de tout ça. Xe Iaso, ingénieure et blogueuse très connue, publie un billet au titre assumé et provocateur : « Tout le monde devrait ralentir le développement de l'IA, sauf moi ».

Claire Martin: Le titre dit tout, non ?

Nicolas Moreau: Presque tout, et la suite rend le propos encore plus croustillant : Xe Iaso a configuré une règle de pare-feu sur son site qui bloque les visiteurs venant des États américains. Donc concrètement, son contenu est inaccessible depuis les États-Unis.

Claire Martin: Et là, tu as toute l'ironie du débat réunie dans une seule personne. D'un côté, on demande un ralentissement collectif, une coordination, une gouvernance mondiale. De l'autre, la réponse concrète d'une développeuse, c'est un geste unilatéral, symbolique, presque une blague de système — « je bloque un pays entier avec une règle de firewall ». C'est exactement le contraire d'une coordination.

Nicolas Moreau: Et c'est peut-être le vrai signe de l'état du débat : chacun reconnaît que le rythme est un problème, mais la réponse individuelle prime encore sur la réponse collective. Est-ce que la prise de position d'Amodei déclenchera un vrai mouvement d'industrie, ou restera-t-elle une tribune de plus ? C'est la question laissée ouverte, et honnêtement, on n'a pas d'élément pour trancher.

Claire Martin: Ce qui est certain, c'est que même si tout le monde se mettait d'accord demain pour ralentir, l'IA a déjà transformé des pans entiers du métier. Et justement, passons à la partie la plus tangible : l'IA dans le code et dans l'industrie. Et là, un benchmark qui mérite qu'on s'y attarde, parce qu'il répond à un vrai problème : les benchmarks publics sont contaminés. Les modèles sont entraînés sur les données de test, donc les scores gonflent.

Nicolas Moreau: Et Real-SWE, c'est la réponse à ça : on évalue les modèles sur du code d'entreprise privé, du vrai code de production que les modèles n'ont jamais vu. Et le résultat du dernier passage, c'est Fable 5.1, via Claude Code, qui mène avec 38,8 % de résolution.

Claire Martin: Et il faut prendre la mesure de ce chiffre : 38,8 %, ça veut dire que sur des tâches réelles, dans des bases de code réelles, environ six tâches sur dix échouent. C'est à la fois un progrès — le modèle résout presque quatre problèmes sur dix qu'il n'a jamais rencontrés — et un rappel à la réalité par rapport aux annonces de type « l'IA remplace les développeurs ». Sur du code privé, la moitié du chemin reste à faire, et encore.

Nicolas Moreau: Ce que ce genre de benchmark permet, c'est de sortir du débat d'opinion. On ne discute plus de savoir si l'IA code bien : on mesure, sur des dépôts privés, ce qui passe et ce qui ne passe pas. Et le débat qui reste ouvert, c'est la sélection des tâches : est-ce que ces bases privées représentent bien la diversité du code d'entreprise ? Est-ce que les tâches sont équilibrées en difficulté ? C'est ça qui fera la valeur de Real-SWE sur la durée.

Claire Martin: Et pour rester dans l'économie de l'IA, un article du Economist propose une image frappante : Nvidia serait la « banque centrale de l'IA ». L'idée, si on déplie la métaphore, c'est que Nvidia contrôle l'accès à la ressource essentielle — les GPU — un peu comme une banque centrale contrôle la liquidité.

Claire Martin: Et les commentateurs ont prolongé la métaphore : TSMC, qui fabrique physiquement les puces, serait alors la monnaie elle-même, ou la « monnaie » — la référencement de la comparaison, c'était TSMC comme l'atelier de frappe, le mint.

Nicolas Moreau: Et la comparaison a fait débat. Parce qu'une banque centrale, d'habitude, ça régule, ça prête en dernier ressort, ça impose des règles. Nvidia, elle, est un acteur commercial qui gagne énormément à ce que la demande explose. Est-ce qu'une entreprise dont le modèle d'affaires dépend de la croissance de l'IA peut jouer le rôle d'une institution neutre ? C'est une vraie objection.

Claire Martin: Et il y a des limites mécaniques à l'analogie. Une banque centrale peut créer de la monnaie ; Nvidia ne crée pas de capacité de calcul, elle la fabrique — et sa capacité de production dépend de TSMC et de la chaîne d'approvisionnement. Donc la question reste posée : jusqu'où l'analogie tient, et où casse-t-elle ?

Nicolas Moreau: Et dans le même registre — l'économie de l'IA qui se crée elle-même — il y a un exemple qui sort complètement des schémas habituels. Le site Tedium rapporte du spam sur iLands : des agents IA qui proposent des missions freelance à environ 25 dollars. Et la logique est presque vertigineuse : ces agents, apparemment, prennent des missions pour financer leurs propres coûts de tokens.

Claire Martin: Donc l'agent travaille pour payer son propre calcul. C'est une boucle économique autonome, en miniature. Et ça pose la vraie question, celle qui n'a pas de réponse aujourd'hui : est-ce que cette économie d'agents est durable ? À 25 dollars la mission, après les frais de plate-forme et le coût réel en tokens, qu'est-ce qu'il reste ? Et surtout : qu'est-ce que ça fait au marché du freelance, quand une partie des offres est générée par des machines ?

Nicolas Moreau: Là aussi, c'est un phénomène naissant. On a le fait rapporté, on n'a pas encore de données sur l'ampleur, ni sur la qualité des livrables. Mais le symptôme est clair : dès qu'un canal économique existe, des agents s'y engouffrent. Et ça rejoint la discussion sur le rythme — c'est arrivé sans que personne ne décide quoi que ce soit.

Claire Martin: Ce qui nous amène naturellement au prochain sujet : quand l'IA et les agents sont omniprésents, la question de la confiance et de la vie privée devient centrale. Et on a trois histoires là-dessus qui se répondent entre elles.

Nicolas Moreau: La première, c'est l'affaire LG. Gamers Nexus avait publié des enquêtes sur la télémétrie des téléviseurs LG, et LG a réagi en contestant, avec des formulations qui vont jusqu'à suggérer que le média ne serait pas fiable — d'où le titre de la réponse de Gamers Nexus : « LG Says We're Fake News », « LG nous traite de fausses nouvelles ».

Claire Martin: Et le fond du désaccord, c'est un mot : « continuellement ». LG nie espionner ses clients « en continu ». Or le point contesté, c'est que les téléviseurs journalisent quand même les dialogues ambiants — ce qui se dit autour du téléviseur. LG avance que l'ACR, la reconnaissance automatique de contenu, serait optionnelle.

Nicolas Moreau: Donc on a un débat sémantique qui masque un fait matériel : oui, il y a une collecte de données d'ambiance, mais elle serait conditionnée à un réglage. Et la question que chacun doit se poser, c'est : est-ce que ce réglage est par défaut activé ou désactivé, et est-ce qu'un utilisateur moyen sait qu'il existe ? Ça, ça reste flou.

Claire Martin: Et il y a une couche médiatique intéressante : pendant cette polémique, YouTube a apparemment testé des variantes de titres de vidéos en A/B. C'est-à-dire que même la façon dont une enquête vous est présentée devient un objet d'optimisation algorithmique. La médiatisation devient elle-même un sujet de controverse.

Nicolas Moreau: Et ce qu'il faut retenir comme piste à suivre, c'est la réponse technique : comment désactive-t-on l'ACR réellement, complètement ? Est-ce qu'une désactivation dans les menus coupe tout, ou est-ce qu'il reste du trafic réseau ? C'est la question non résolue.

Claire Martin: Deuxième histoire, et elle est plus dérangeante parce qu'elle touche les développeurs, c'est-à-dire des gens qui pensent avoir de bonnes pratiques. Simon Tatham, le créateur de PuTTY, a analysé le client Zoom sous Linux. Et il a trouvé quelque chose de remarquable : le client lit proactivement tout le contenu du presse-papiers X11.

Nicolas Moreau: Et pourquoi c'est grave sous X11 spécifiquement ? Parce que le presse-papiers sous X11 n'est pas privé par conception : n'importe quelle application connectée au serveur X peut lire le presse-papiers des autres. Et les gestionnaires de mots de passe y déposent vos mots de passe quand vous les copiez. Donc si Zoom lit le presse-papiers de façon proactive, potentiellement à intervalles réguliers, il peut capturer des données sensibles sans que vous ayez collé quoi que ce soit dans Zoom.

Claire Martin: Exactement, et c'est ça qui rend l'affaire intéressante techniquement. Le presse-papiers, dans un modèle X11, repose sur la confiance : tu ne lis le presse-papiers que quand l'utilisateur te le demande. Lire de façon proactive, c'est casser ce contrat implicite. Même si Zoom n'en fait rien de malveillant, la donnée transite, elle est traitée, et personne n'a consenti à ce périmètre précis.

Nicolas Moreau: Et la question ouverte, là aussi, c'est la réponse : est-ce que ça va pousser vers un vrai sandboxing du presse-papiers sous Linux, comme ce qui existe sur les plateformes plus modernes avec des contrôles d'accès granulaires ? Ou est-ce que chacun va simplement arrêter d'utiliser Zoom sous X11 ? L'histoire des réponses techniques reste à écrire.

Claire Martin: Et troisième histoire, qui est le miroir temporel des deux premières : Usenet-Rewind. C'est un nouveau projet qui propose un archivage intégral et interrogeable d'Usenet, de 1981 à aujourd'hui — plus d'un milliard de messages.

Nicolas Moreau: Un milliard de messages, datant de l'époque où personne n'imaginait que « poster sur un forum » laisserait une trace consultable quarante ans plus tard. Et donc, mécaniquement, ce projet fait ressortir d'anciens posts — des messages que leurs auteurs ont écrits il a très longtemps, souvent sous des identités d'alors, avec des opinions d'alors.

Claire Martin: Et le problème de vie privée est rétroactif : ce n'est pas une collecte nouvelle, c'est une redécouverte. Des gens ont écrit des choses il y a trente ans sous pseudonyme, et se retrouvent aujourd'hui reliés à ces messages par des archives interrogeables. Le pseudonyme de l'époque ne protège plus grand-chose face à un corpus complet et recherche plein-texte.

Nicolas Moreau: Le fil rouge des trois histoires, c'est le même : des systèmes conçus à une époque où la collecte de données n'était pas pensée comme un risque — le presse-papiers X11, Usenet, la télé connectée — se retrouvent confrontés à un contexte où tout est archivable, analysable, correlable. Et les réponses, qu'elles soient techniques ou juridiques, sont toujours en retard.

Claire Martin: Changement de Registre, mais dans la même logique de fond : si on veut comprendre ce que les puces doivent faire, il faut comprendre les architectures. Et on a deux magnifiques plongées techniques, une très récente et une très ancienne, qui se répondent étonnamment bien.

Nicolas Moreau: La récente, c'est Eileen Yoon qui a rétro-conçu le Neural Engine d'Apple, l'ANE, dans le M1. Et sa conclusion est nette : le Neural Engine a été conçu pour le flux de données des CNN, des réseaux de convolution. Et pour les transformers — donc pour tout ce qui est LLM et modèles d'attention — il est inadapté.

Claire Martin: Et il faut expliquer pourquoi, parce que c'est instructif. Les CNN et les transformers n'ont pas du tout le même profil d'accès mémoire ni le même motif de calcul. Les CNN ont des opérations très régulières, des fenêtres glissantes, un flux de données prévisible. Les transformers, c'est de l'attention, des matrices énormes, des accès mémoire beaucoup plus chaotiques. Un circuit optimisé pour le premier est structurellement mauvais pour le second.

Nicolas Moreau: Et le signe qu'Apple a tiré les conséquences, c'est le M5 : le Neural Engine y est intégré au GPU. Autrement dit, au lieu d'un accélérateur séparé spécialisé CNN, on fusionne l'accélération dans le GPU, qui est un moteur beaucoup plus généraliste. C'est un virage architectural : on abandonne la spécialisation étroite au profit de la flexibilité.

Claire Martin: Et le contrepoint historique, c'est Ken Shirriff, qui a reconstitué le microcode du 8087 — le coprocesseur mathématique d'Intel des années 80. Et une instruction en particulier, FSCALE, est un cas d'école : elle utilise plus de 140 micro-instructions et passe par trois niveaux de sous-routines.

Nicolas Moreau: Cent quarante micro-instructions pour une seule instruction machine. Ça donne la mesure de ce qu'était l'ingénierie à l'époque : chaque instruction du coprocesseur était en fait un petit programme, déroulé par le microcode, avec des appels imbriqués. Et ça met en perspective le débat actuel : la question « quelle architecture pour quel workload » se pose depuis toujours, on vient juste de changer d'échelle.

Claire Martin: Et il y a un lien entre les deux histoires qui mérite d'être dit, c'est l'efficience énergétique. Un article d'OilPrice — et il faut le préciser, il est vraisemblablement assisté par IA, donc à lire avec recul — calcule que l'Union européenne utilise 44 % d'énergie en moins par euro de PIB qu'en 1995. Et les lecteurs ont recalculé l'équivalent américain, arrivant à environ 48 %.

Nicolas Moreau: Donc sur trente ans, l'intensité énergétique de l'économie a été divisée par deux, à peu près. Et ça, c'est exactement le problème auquel l'IA se confronte : ces gains d'efficience sont réels, mais la demande de calcul croît plus vite que les gains. D'où l'enjeu des architectures qu'on vient de discuter — le Neural Engine mal adapté aux transformers, c'est de l'énergie gaspillée, littéralement.

Claire Martin: Mais bon, l'efficience, ce n'est pas que dans le silicium, c'est aussi dans le code. Et ça nous amène aux outils du développeur, avec trois sujets très concrets.

Nicolas Moreau: Le premier, c'est Lalit Maganti qui publie buildprof, un outil open source de traçage de builds. Le principe : visualiser un build comme un arbre de processus chronologique. Tu vois quels processus se sont lancés, quand, en parallèle ou en série, où le temps passe vraiment.

Claire Martin: Et ce qui rend l'outil crédible tout de suite, c'est qu'il l'a utilisé sur un cas réel : comparer les temps de build du projet Bun en Zig contre en Rust. Une question que la communauté se pose depuis des années, et là on a des données de traçage plutôt que des opinions.

Nicolas Moreau: Et le bénéfice d'un tel outil au-delà du cas Bun, c'est de rendre visible ce qui est opaque. Un build, c'est des centaines de processus, et la plupart des développeurs n'ont aucune idée de ce qui prend le temps. Si on voit les vraies causes, on peut paralléliser, cacher, supprimer. La question à suivre, c'est de savoir si buildprof va s'imposer dans les chaînes CI, où les temps de build coûtent directement de l'argent.

Claire Martin: Deuxième sujet, côté langages de programmation : un billet de blog passe en revue plusieurs idées qui reviennent dans le design des langages — le flow typing, le borrow checking, et la programmation par contrats.

Nicolas Moreau: Rappel rapide pour ceux qui ne connaissent pas. Le flow typing, c'est le fait que le compilateur affine le type d'une variable en fonction du flux de contrôle : si tu as testé que la variable n'est pas nulle, le compilateur le sait après le test. Le borrow checking, c'est le modèle de Rust, qui garantit à la compilation qu'il n'y a pas d'accès mémoire conflictuel.

Nicolas Moreau: Et la programmation par contrats, c'est des préconditions et postconditions qu'on attache aux fonctions pour spécifier ce qu'elles exigent et garantissent.

Claire Martin: Et le clin d'œil délicieux, c'est que l'exemple en langage D du billet — justement sur la programmation par contrats — contenait une coquille dans une postcondition. Le code qui illustre les contrats avait un bug dans son contrat.

Nicolas Moreau: Ce qui est presque une démonstration involontaire du point du billet : les contrats sont du code, donc ils peuvent être faux. Et ça pose une vraie question, celle de la vérification des contrats eux-mêmes — est-ce qu'on vérifie les vérificateurs, et jusqu'à quel niveau ? C'est une régression qu'on peut pousser à l'infini.

Claire Martin: Et troisième sujet, plus altruiste : un tutoriel pour faire son premier edit OpenStreetMap en quinze minutes. L'outil, c'est le plugin « Website Wizard » pour JOSM, l'éditeur de référence. Et le cas d'usage proposé, c'est d'ajouter des tags website à des boutiques.

Nicolas Moreau: C'est un très bon choix pédagogique, parce que c'est une contribution faible en risque et à valeur immédiate. Tu vérifies le site web d'un commerce, tu l'ajoutes dans les tags OSM, et la donnée profite à tout l'écosystème — les applications de navigation, les moteurs de recherche locaux. Quinze minutes pour passer de consommateur de la carte à contributeur.

Claire Martin: Et on termine avec un bloc recherche et fondements, trois sujets qui ont un point commun : la prudence scientifique, la manière d'annoncer — ou de ne pas annoncer — des révolutions.

Nicolas Moreau: Le premier, et c'est l'affaire à suivre : le Clay Mathematics Institute a publié une prise de position sur le problème de Navier-Stokes, l'un des sept problèmes du millénaire, dont la résolution vaudrait un million de dollars. Un prétendu solutionneur s'est manifesté. Et la position du Clay est d'un professionnalisme remarquable : neutre, sans mention d'OpenAI — même si les rumeurs en ligne pointaient par là — et avec la promesse d'une évaluation qui viendra plus tard.

Claire Martin: Et c'est exactement la bonne méthode. Un problème du millénaire, ça se vérifie par les pairs, sur des mois, parfois des années. Annoncer « c'est résolu » avant la vérification, ce serait répéter l'erreur classique. Le Clay ne valide rien, ne nie rien, dit seulement « nous évaluerons ». Et ce qu'on ne sait pas, c'est ce que contient la prétendue solution, ni qui l'a produite, ni sous quelle forme. Affaire à suivre, clairement.

Nicolas Moreau: Deuxième sujet, un classique qu'on revoit : « A Mathematical Framework for Transformer Circuits », publié en 2021. C'est un papier fondateur de l'interprétabilité des transformers, et deux concepts en sont sortis et sont devenus du vocabulaire standard.

Claire Martin: Le premier, ce sont les induction heads, les têtes d'induction : des mécanismes internes au modèle qui détectent des motifs répétés dans le contexte et prédisent la suite du motif. Et l'hypothèse forte du papier, c'est que ce sont ces têtes d'induction qui expliquent l'in-context learning — le fait qu'un modèle apprenne, en quelques exemples donnés dans le prompt, sans réentraînement.

Nicolas Moreau: Et le deuxième concept, c'est le residual stream, conçu comme un bus. L'image est puissante : toutes les couches du transformer lisent et écrivent dans un espace de communication partagé, comme des périphériques sur un bus informatique. Ça a structuré toute la recherche d'interprétabilité qui a suivi.

Claire Martin: Et le troisième sujet est une bouffée d'air frais : un papier arXiv qui pose une question apparemment simple — est-ce qu'il y aura un 7G ? Et sa réponse est une critique de la numérotation automatique des générations mobiles. Il propose plutôt un « Readiness-Framework », un cadre de préparation : au lieu de décréter qu'une génération existe parce que le marketing a besoin d'un nouveau chiffre, on évalue si les technologies sont réellement prêtes.

Nicolas Moreau: Et ça, ça nous ramène pile au début de l'épisode. Que ce soit sur les maths — ne pas valider une solution avant l'évaluation —, sur les réseaux — ne pas numéroter une génération avant qu'elle existe techniquement —, ou sur l'IA — ne pas promettre des capacités avant de les mesurer sur du code réel privé —, le même principe revient : la prudence scientifique avant l'annonce de la révolution.

Claire Martin: Et dans l'autre sens, le même principe pour les risques : Dario Amodei nous dit de ralentir avant le point de non-retour, pas après. Xe Iaso nous le dit avec l'ironie en plus. Et Real-SWE nous rappelle qu'avant de parler de révolution du code, il faut des chiffres honnêtes — 38,8 %, c'est un chiffre honnête.

Nicolas Moreau: Voilà, c'est tout ce qu'on avait pour aujourd'hui. On vous dit à la prochaine, et d'ici là, regardez bien vos presse-papiers.

Claire Martin: Et votre téléviseur. Merci de nous avoir écoutés, au revoir !

Nicolas Moreau: Au revoir !