1017 | Agents IA, matériel improbable et réseaux d'antan

Claire Martin: Bonjour et bienvenue dans l'édition du jour, moi c'est Claire Martin.

Nicolas Moreau: Et moi Nicolas Moreau. Aujourd'hui on va parler d'agents IA qui écrivent du code et qui résolvent des mystères, de modèles qui tournent sur du matériel improbable comme des consoles de jeu, de vieux standards réseau qui refont surface, et de toute une série de brèves côté web et culture dev.

Claire Martin: Le fil rouge, c'est un peu la tension entre le très récent et le très ancien : des modèles de pointe d'un côté, et de l'autre des bugs vieux de 37 ans, des esolangs absurdes et du Token Ring des années 90.

Nicolas Moreau: Commençons par les agents. Il y a deux nouvelles qui sont revenues en force dans les discussions. La première : Claude a optimisé tout seul huit circuits quantiques simulés, et dans certains cas il a réduit le nombre d'opérations d'un facteur 17.

Claire Martin: Et la deuxième, c'est que Claude a résolu une énigme qui traînait depuis longtemps en cryptographie : l'origine des seeds des courbes NIST utilisées dans ECDSA.

Nicolas Moreau: Alors pour ceux qui ne connaissent pas le contexte, ECDSA c'est l'algorithme de signature utilisé partout, dans TLS, dans Bitcoin, dans les certificats. Et les courbes elliptiques recommandées par le NIST, on connaît leurs paramètres, mais les valeurs aléatoires qui ont servi à les générer, les fameux seeds, n'ont jamais été justifiées publiquement de manière convaincante.

Claire Martin: Et ça a alimenté pendant des années un débat assez vif : est-ce que ces seeds étaient vraiment aléatoires, ou est-ce qu'il y avait une porte dérobée ? Parce que si quelqu'un connaît un paramètre caché dans la génération de la courbe, théoriquement il peut casser les clés de tout le monde.

Nicolas Moreau: Et la réponse, c'est plutôt rassurante : les seeds proviennent de lrand48, le générateur de nombres pseudo-aléatoires historique d'Unix, initialisé avec des timestamps Unix. Donc pas de backdoor, juste une méthode de génération plutôt artisanale, datant d'une époque où personne n'imaginait que ces paramètres seraient scrutés à la loupe vingt ou trente ans plus tard.

Claire Martin: Ce qui est intéressant dans les discussions, c'est que ça clarifie sans pour autant clore tout le débat. Une partie des gens disent : voilà, le mystère est résolu, on peut arrêter de soupçonner. D'autres répondent que le problème de fond reste entier : le point n'est pas de savoir si ces seeds sont innocents, mais que le processus de génération n'était pas vérifiable.

Claire Martin: Même sans intention malveillante, une courbe générée à partir d'un générateur non cryptographique et d'un timestamp, c'est exactement le genre de choix qu'on ne se permettrait plus aujourd'hui.

Nicolas Moreau: Et il y a l'argument du précédent : Dual EC, le générateur aléatoire du NIST qui, lui, contenait une backdoor présumée, a renforcé la méfiance envers tout ce qui sort du NIST. Le fait que les courbes ECDSA soient innocentes ne répare pas complètement cette défiance, parce que la leçon retenue par beaucoup, c'est « ne jamais faire confiance à des constantes non expliquées », quelle que soit l'explication rétroactive.

Claire Martin: Et du côté des sceptiques les plus durs, certains notent qu'on ne peut pas non plus vérifier formellement que l'explication lrand48-plus-timestamp est la bonne, au sens où reproduire la génération donnerait exactement ces seeds. C'est plausible, c'est cohérent, mais c'est de la reconstruction, pas de la preuve documentaire.

Nicolas Moreau: Bon. Passons à l'autre gros morceau : Anthropic affirme que Claude Code écrit environ 90 pour cent de son propre code. Le sien, donc le code de l'outil lui-même. Et l'entreprise dit traiter plus de 30 000 changements par jour, avec un review automatisé.

Claire Martin: Là, les réactions sont très contrastées. Un premier camp dit : c'est cohérent avec ce qu'on voit ailleurs. Les outils de code agentique sont les meilleurs clients de leur propre catégorie, c'est le dogfooding ultime. Si un agent peut écrire du code pour les autres, le premier projet qu'il devrait pouvoir assumer, c'est lui-même.

Nicolas Moreau: Un deuxième camp s'accroche au chiffre brut. 30 000 changements par jour, ça dépasse la capacité humaine de revue, donc inévitablement une grosse partie du contrôle qualité est elle-même automatisée. Et la question qui revient tout le temps : est-ce que un review automatisé fait par le même type de modèle qui a généré le code peut vraiment attraper les problèmes ?

Nicolas Moreau: Il y a un risque de corrélation des erreurs : ce que le modèle ne comprend pas en écrivant, il ne le comprendra peut-être pas mieux en relisant.

Claire Martin: Et il y a le détail qui fait tiquer tout le monde, c'est qu'Anthropic a reçu en juin la note de crédit la plus basse, une note junk. En même temps qu'on évoque un IPO valorisé à plus de 2 000 milliards de dollars.

Nicolas Moreau: Ce qui donne une discussion assez vertigineuse. D'un côté une entreprise qui dit que son produit principal écrit son propre code à 90 pour cent, donc des coûts de développement marginaux potentiellement très bas. De l'autre, une note financière junk, ce qui signifie que les agences de rating jugent le profil de risque élevé.

Nicolas Moreau: Certains commentateurs y voient une incohérence, d'autres disent que c'est parfaitement logique : une note de crédit évalue la stabilité des revenus et le niveau d'endettement, pas la qualité d'un pipeline de développement. Une entreprise qui brûle du cash pour poursuivre une croissance énorme peut avoir une note junk et une valorisation rêvée en même temps.

Claire Martin: Et ça nourrit aussi le débat sur le fond : si les agents écrivent le code et que la valeur se déplace vers les modèles eux-mêmes, la santé financière de ces entreprises dépend moins du génie logiciel que de la capacité à couvrir les coûts d'inférence et d'entraînement. C'est une économie complètement différente de celle du logiciel classique.

Nicolas Moreau: Et justement, est-ce que ça marche vraiment ? Parce que la même journée, on a vu un benchmark qui remet les choses en perspective : Mercor a publié une étude selon laquelle 90 pour cent des heures de travail aux États-Unis tombent sur des tâches que les benchmarks IA existants couvrent à peine.

Claire Martin: C'est presque le même pourcentage que pour le code de Claude Code, il y a une ironie là-dedans. Mais le message est important : on évalue les modèles sur un échantillon très étroit de tâches, souvent bien définies, souvent techniques, et tout le reste du travail réel, la coordination, le jugement dans l'ambiguïté, les interactions humaines, reste largement hors champ.

Nicolas Moreau: Les deux camps de la discussion se rejoignent partiellement là-dessus. Ceux qui sont enthousiastes sur les agents disent : oui, 90 pour cent du code de Claude Code, mais c'est le cas d'usage le plus favorable qui existe, du code bien structuré, avec des tests, dans un environnement maîtrisé. Ceux qui sont sceptiques disent : regardez, les benchmarks eux-mêmes ne couvrent que le dixième émeraude du travail réel.

Nicolas Moreau: Les deux positions convergent vers la même conclusion : les chiffres impressionnants mesurent des niches favorables.

Claire Martin: Et il y a un troisième élément pour tester concrètement les capacités agentiques : StarSkirmish Bench, version 0.2. Le principe, c'est de faire écrire par des LLM des bots en C++ pour StarCraft, en une heure de temps de travail. Et le leader, c'est GPT-6 Astra, avec 57 pour cent de winrate.

Nicolas Moreau: Ce qui est amusant, c'est que 57 pour cent, c'est à la fois impressionnant et modeste. C'est un peu mieux qu'un pile ou face, en gros. Et les discussions autour de ce genre de bench posent la question de ce qu'on mesure réellement. Écrire un bot StarCraft compétent en une heure, ça demande de comprendre l'API du jeu, de gérer la macro, la micro, le pathfinding... Le fait qu'un modèle produise quelque chose qui gagne 57 pour cent de ses parties, c'est déjà notable.

Nicolas Moreau: Mais certains font remarquer que la winrate dépend énormément de contre qui on joue : contre d'autres bots générés par LLM, ou contre des bots humains établis depuis des années ?

Claire Martin: Et ça rejoint le fil de la fiabilité. La question qui revient partout dans ces trois histoires, le code auto-écrit, les benchmarks partiels, les bots StarCraft, c'est la même : est-ce qu'on a des agents fiables, ou des agents brillants sur des échantillons favorables ? Un bot qui gagne 57 pour cent du temps, c'est exactement le profil d'un système qui est bon en moyenne mais pas fiable, et pour du code de production ou de la sécurité, la fiabilité compte plus que la moyenne.

Nicolas Moreau: Pour comprendre pourquoi ces modèles marchent si bien dans ces niches, il y a eu un rappel théorique utile qui a ressurgi dans les discussions : un article qui explique le Transformer comme une mémoire associative, où chaque couche est un store mémoire. Autrement dit, le modèle apprend des associations entre concepts, et chaque couche enrichit le stock de correspondances.

Claire Martin: Ça éclaire pas mal de comportements qu'on observe. Si un modèle fonctionne par association, alors il est naturellement excellent sur des tâches qui ressemblent à ce qu'il a déjà vu, comme optimiser un circuit quantique qui ressemble à des problèmes d'optimisation connus, ou expliquer l'origine de constantes cryptographiques qui ressemblent à des patterns historiques documentés.

Claire Martin: Et il est naturellement fragile sur des tâches qui exigent de la planification véritablement nouvelle, comme un bot StarCraft contre des stratégies inédites.

Nicolas Moreau: Et ça donne un cadre à la question laissée ouverte : est-ce que l'association suffit à long terme, ou est-ce qu'il manque quelque chose, une forme de raisonnement séquentiel, de vérification formelle, pour passer du « bon en moyenne » au « fiable » ? Personne n'a de réponse fermée là-dessus.

Claire Martin: Bon, maintenant il faut bien faire tourner tout ça. Et là on a deux histoires qui partagent un détail technique fascinant : le RDMA.

Nicolas Moreau: Commençons par le côté plus classique : Black Forest Labs a sorti FLUX 3 Image Klein, un modèle open-weights de 5,6 milliards de paramètres pour la génération d'images, l'édition et le multi-référence. Le mot clé c'est « Klein », et les 5,6 milliards de paramètres le confirment : c'est une version compacte, pensée pour tourner sur du matériel raisonnable.

Claire Martin: Et le fait que ce soit open-weights compte beaucoup dans les discussions. Ça veut dire qu'on peut télécharger les poids et les faire tourner en local, ce qui ouvre la porte exactement au genre d'expérimentations dont on va parler maintenant. Le multi-référence, c'est-à-dire la possibilité de partir de plusieurs images de référence, intéresse particulièrement les gens qui font de la création en local, sans envoyer leurs images dans le cloud.

Nicolas Moreau: Et côté matériel improbable, premier exploit : PS5LM. Quelqu'un fait tourner llama.cpp, jailbreaké, sur la PlayStation 5. Le modèle tourne sur le GPU avec RDMA, et il y a 11,4 gigaoctets de mémoire partagée disponibles. Et le résultat, c'est que la PS5 sert de serveur de modèles.

Claire Martin: Ce qui est à la fois hilarant et techniquement sérieux. La PS5 a du matériel très compétent, surtout côté bande passante mémoire, mais elle n'est pas conçue pour ça. Le jailbreak permet d'exécuter du code arbitraire, et ensuite il s'agit d'adapter llama.cpp au GPU de la console. Le résultat n'est pas de la recherche fondamentale, c'est de l'ingénierie de contournement, et c'est exactement ce qui plaît à ce public.

Nicolas Moreau: Deuxième exploit, plus gros calibre : Muse Spark Open d'Apple, via MLX, un modèle d'environ 816 milliards de paramètres, qui tourne sur quatre Mac Studios, à plus de 36 tokens par seconde, grâce au RDMA sur Thunderbolt.

Claire Martin: Et là il faut donner l'échelle. 816 milliards de paramètres, c'est un très gros modèle, typiquement dans la catégorie des modèles frontière. Le faire tourner à 36 tokens par seconde sur du matériel bureautique, pas sur un cluster datacenter, c'est ce qui rend l'exploit remarquable. La technique, c'est le RDMA : Remote Direct Memory Access, qui permet à une machine d'accéder directement à la mémoire d'une autre sans passer par le processeur.

Nicolas Moreau: Et c'est ça le fil commun des deux histoires : dans les deux cas, la clé n'est pas le nombre de machines, c'est la bande passante entre elles. Le GPU de la PS5 accède à la mémoire partagée via RDMA, les quatre Mac Studios se partagent le modèle via RDMA sur Thunderbolt. Le modèle trop gros pour une seule machine devient possible dès qu'on peut faire circuler les données assez vite entre les machines.

Claire Martin: Et dans les discussions, il y a deux lectures. La première : c'est une démonstration que l'inférence locale de gros modèles se démocratise. FLUX 3 Klein en petit, Muse Spark Open en grand, la frontière du « faisable chez soi » recule. La deuxième lecture, plus prudente : ce sont des exploits, pas des solutions de production. Une PS5 jailbreakée comme serveur de modèles, c'est amusant, mais personne ne va construire une flotte de serveurs d'inférence sur des consoles détournées.

Claire Martin: Et les quatre Mac Studios, ça reste un investissement conséquent, avec une solution artisanale d'interconnexion.

Nicolas Moreau: La vraie question qui reste ouverte, c'est la viabilité : est-ce que ces architectures bricolées à base de RDMA sur Thunderbolt deviennent une alternative crédible, ou est-ce qu'elles restent des démonstrations ? La direction semble claire, vu que même des fabricants comme Apple s'appuient sur RDMA dans leurs outils MLX officiels, mais le détail de ce qui est durable versus ce qui est un hack d'un week-end, ça reste à voir.

Claire Martin: Et d'ailleurs le RDMA, c'est aussi une histoire de réseau, tout simplement. Ce qui nous amène au thème suivant, et c'est un thème où le très vieux et le très neuf se côtoient.

Nicolas Moreau: Commençons par le neuf : RFC8950. Cette norme permet de transporter des routes IPv4 sur des sessions BGP où le next-hop est une adresse IPv6. Traduction concrète : on peut construire des backbones purement IPv6, sans IPv4 nulle part dans le cœur du réseau, tout en acheminant quand même du trafic IPv4.

Claire Martin: Et c'est important parce que l'Internet est dans une situation de coexistence forcée depuis des années. L'IPv4 est épuisé, les adresses sont chères et rares, mais le cœur de beaucoup de réseaux traîne encore de l'IPv4 pour des raisons d'inertie. RFC8950 permet de nettoyer le cœur : le backbone parle uniquement IPv6, et l'IPv4 devient juste un service en périphérie, encapsulé dans un plan de transport IPv6.

Nicolas Moreau: La discussion autour, c'est en partie de l'enthousiasme et en partie du pragmatisme. Ceux qui gèrent des grands réseaux voient ça comme un simplificateur : un seul protocole dans le cœur, moins d'états à maintenir, moins de dual-stack partout. Ceux qui sont plus prudents rappellent que le déploiement réel dépend des opérateurs, et que les migrations BGP ont historiquement pris des années. Le fait que la norme existe ne veut pas dire que les backbones se convertissent du jour au lendemain.

Claire Martin: Et là, un contrepoint historique s'est invité naturellement dans la conversation : Token Ring. Le standard réseau d'IBM des années 80 et 90, qui a perdu contre Ethernet.

Nicolas Moreau: Et l'explication de sa défaite est très pédagogique : Ethernet était moins cher, et il montait mieux en puissance. Quand Ethernet a atteint 100 mégabits par seconde, la partie était jouée. Token Ring était techniquement séduisant, le token-passing donnait un accès ordonné au média, pas de collisions, un comportement déterministe. Mais face à un concurrent moins cher et mieux scalable, ces qualités n'ont pas suffi.

Claire Martin: Et c'est là que les trois histoires de ce bloc se répondent : RFC8950, c'est une norme qui gère la transition d'une génération de protocole à une autre, en préservant les services existants. Token Ring, c'est le récit d'une transition ratée, où la meilleure technologie a perdu contre la plus économique. Et le bug OpenBSD qu'on va évoquer maintenant, c'est l'héritage qui persiste bien au-delà de ce qu'on imaginait.

Nicolas Moreau: Le bug « Big Fish » d'OpenBSD, donc. Un débordement d'entier 16 bits dans le compteur d'attachement de la mémoire partagée SysV. Vieux de 37 ans. Et il permet une escalade de privilèges locale vers root.

Claire Martin: Ce qui est presque incompréhensible à première vue : OpenBSD est réputé être le système le plus audité au monde, avec une culture quasi obsessionnelle de la sécurité. Et pourtant, un compteur de 37 ans a survécu à tout ce temps.

Nicolas Moreau: L'explication tient dans la mécanique du bug. La mémoire partagée System V, c'est une API Unix très ancienne, héritée des années 80, qui permet à des processus de partager des segments de mémoire. Le compteur d'attachement, qui suit combien de processus sont rattachés à un segment, était codé sur 16 bits. Un programme local peut attaché et détaché de manière répétée pour faire déborder le compteur, et à partir de là, manipuler l'état interne du noyau pour obtenir les privilèges root.

Claire Martin: Le point qui a le plus nourri la discussion, c'est la leçon sur le code hérité. Ce compteur a probablement été écrit à une époque où 16 bits semblaient largement suffisants : qui allait attacher 65 000 processus à un seul segment de mémoire partagée ? Et la réponse, c'est qu'un attaquant, si. Le monde change, les contraintes qui semblaient académiques deviennent exploitables, et le code, lui, ne bouge pas.

Nicolas Moreau: Et ça crée un parallèle direct avec tout ce dont on a parlé avant : les seeds NIST vieux de plusieurs décennies qu'on vient tout juste d'expliquer, le Token Ring qu'on exhume comme leçon, le compteur SysV qui explose après 37 ans. Les vieilles architectures, ça compte encore, et pas toujours dans le bon sens. Le même internet qui déploie RFC8950 pour préparer le futur fait tourner des API des années 80 dans son noyau.

Claire Martin: Et il reste des questions ouvertes là-dessus : combien de systèmes embarqués, de vieux serveurs, d'équipements industriels tournent encore sur des noyaux avec ce bug ? L'escalade est locale, donc il faut déjà un accès à la machine, ce qui limite la gravité, mais pour un environnement multi-utilisateurs, c'est un vrai problème.

Nicolas Moreau: Bon. Passons aux brèves, et il y en a de bonnes. Commençons par une polémique qui a chauffé GitHub : Home Assistant.

Claire Martin: Donc Home Assistant, la plateforme domotique open source très populaire, a intégré une fonctionnalité qui scanne les données ressemblant à des secrets dans la configuration des utilisateurs, des mots de passe, des tokens, ce genre de choses, et envoie les empreintes, les hashes, à HaveIBeenPwned, le service qui recense les fuites de données. Et le problème, c'est que ça se fait sans opt-in. Pas de consentement explicite.

Nicolas Moreau: Et la colère des utilisateurs sur GitHub porte sur plusieurs choses en même temps. D'abord le principe : même si envoyer un hash et pas le secret en clair est une pratique raisonnable sur le plan technique, un hash de mot de passe reste une donnée sensible, et l'envoyer à un service tiers sans demander, c'est une violation de la confiance. Ensuite le contexte : Home Assistant tourne sur des installations domestiques, souvent dans un esprit « mes données restent chez moi ».

Nicolas Moreau: Beaucoup de gens ont choisi ce logiciel précisément pour éviter d'envoyer quoi que ce soit à des tiers.

Claire Martin: Et il y a le débat de fond récurrent : le opt-in versus le opt-out. Les défenseurs de l'équipe Home Assistant pourraient dire que la fonctionnalité sert la sécurité de l'utilisateur, détecter ses secrets compromis est un service. Mais la position majoritaire dans la protestation, c'est que le consentement passe avant le service, et surtout dans un projet open source où la confiance communautaire est le capital principal.

Claire Martin: C'est le genre de décision qui aurait dû passer par une discussion publique avant d'être implémentée.

Nicolas Moreau: La question qui reste ouverte, c'est quelle leçon ça donne pour l'écosystème open source en général : à partir de quand un projet a-t-il le droit de faire des appels réseau au nom de ses utilisateurs ? Et la réponse, visiblement, c'est qu'il faut demander, même quand l'intention est bonne.

Claire Martin: Dans le même registre communautaire mais beaucoup plus léger : /dev/null, un réseau social pour développeurs. Le login se fait via GitHub, et le profil est importé automatiquement.

Nicolas Moreau: Le nom est évidemment un clin d'œil, /dev/null c'est la poubelle universelle d'Unix, celle où on envoie tout ce qu'on veut faire disparaître. Appeler un réseau social comme ça, c'est assumé. Et le concept lui-même est une réaction assez lisible à l'état des réseaux sociaux actuels : un espace où votre identité, c'est votre historique de contribution GitHub, importé automatiquement, pas un profil à remplir à la main.

Claire Martin: Le débat dans la communauté, c'est de savoir si les développeurs ont vraiment besoin d'un réseau social qui leur soit propre, ou si c'est un énième réseau de niche qui finira desertique. D'un côté, l'argument de la pertinence : un profil basé sur des contributions réelles, pas sur de la mise en scène. De l'autre, le scepticisme classique face à tout nouveau réseau : la valeur d'un réseau social, c'est ses utilisateurs, et il en faut beaucoup pour que la boucle tourne.

Nicolas Moreau: Continuons les brèves avec une actualité qui touche une communauté assez spécifique : les radioamateurs. eBay limite les annonces de postes radio à cause de nouvelles règles de la FCC, l'autorité américaine des télécoms. Avec une exception pour les matériels qui fonctionnent uniquement sur des fréquences amateur.

Claire Martin: Et ça illustre un problème classique de régulation : la FCC impose des règles, probablement liées au fait que des émetteurs non conformes ou non autorisés circulent sur des plateformes de vente, et eBay applique des restrictions larges. Le problème, c'est que la restriction brute attrape tout le monde, y compris les radioamateurs qui utilisent du matériel parfaitement légal. D'où l'exception pour les appareils purement amateurs, qui essaie de préserver l'usage légitime.

Nicolas Moreau: La discussion chez les radioamateurs tourne autour de la question de la praticabilité : est-ce qu'un vendeur particulier sait clairement si son appareil tombe dans l'exception ou pas ? Les frontières réglementaires entre ce qui est autorisé et ce qui ne l'est pas sont rarement évidentes pour un particulier, et quand une plateforme doit trancher, elle a tendance à la sureté, c'est-à-dire à restreindre. Le coût de la conformité retombe sur les usagers de bonne foi.

Claire Martin: Petit détour côté web, avec un débat technique qui revient cycliquement : les formats d'image. Jake Archibald a publié une comparaison qui donne une grille de décision simple : pour les photos et les captures d'écran sur le web, AVIF est généralement plus petit. Pour les images sans perte, JPEG XL gagne.

Nicolas Moreau: Ce qui est intéressant, c'est que ça met fin à un peu de la guerre de religion autour de ces formats. Pendant longtemps, les discussions ont opposé les camps AVIF et les camps JPEG XL presque sur des bases idéologiques. La grille d'Archibald, c'est du pragmatisme : les deux formats ont des domaines où ils sont supérieurs, et le bon choix dépend du type d'image. AVIF compresse bien les photos et les screenshots, JPEG XL est meilleur en lossless.

Claire Martin: Et la question qui reste ouverte, c'est celle du support navigateur et de l'écosystème, parce qu'une compression 10 pour cent meilleure ne sert à rien si l'outil de build ne le gère pas ou si un navigateur ne l'affiche pas. Mais le fond du débat technique, en tout cas, a bien avancé.

Nicolas Moreau: On termine avec deux pépites de culture dev. La première : un langage de programmation ésotérique qui s'appelle « Folders », créé par Daniel Temkin. Le principe : le code, ce sont uniquement des dossiers imbriqués. Les noms sont ignorés. Tout le programme, c'est une structure d'arborescence.

Claire Martin: C'est complètement absurde et complètement cohérent à la fois, ce qui est la marque des bons esolangs. Un programme Folders, c'est un ensemble de dossiers dans des dossiers dans des dossiers, et c'est la profondeur et la structure de l'imbrication qui portent le sens. Vous pouvez nommer vos dossiers « nouveau dossier 47 », ça ne changera rien. C'est de l'art conceptuel qui se compile, en quelque sorte.

Nicolas Moreau: Et ce qui rend l'exercice plus profond qu'il n'y paraît, c'est qu'il pose une vraie question : qu'est-ce qui fait qu'une structure est un programme ? On a l'habitude de penser que le code, c'est du texte, des noms, des symboles. Folders démontre que seule la structure suffit, que le nommage est une commodité, pas une nécessité. C'est le même type de question que posent les minimalistes du calcul, les langages sans variables, sans noms.

Claire Martin: Et la deuxième pépite, c'est un retour très concret vers la nostalgie du rendu logiciel. Un développeur a raconté qu'il préfère le rendu par logiciel sous DOS plutôt que l'accélération matérielle, parce qu'il obtient des pixels nets, sans filtrage bilinéaire. Le filtrage bilinéaire, c'est ce flou que les GPU appliquent pour lisser les textures, et pour une certaine esthétique rétro, c'est un sacrilège.

Nicolas Moreau: Mais il y a un détail savoureux dans son histoire : faire tourner Quake en 800 par 600 à 60 images par seconde en rendu logiciel, ça exige aujourd'hui une machine moderne rapide. Autrement dit, un jeu de 1996, conçu pour des PC de l'époque, demande maintenant une machine puissante pour être rendu de la manière « authentique », en logiciel, à haute résolution.

Claire Martin: Et c'est une boucle parfaite pour conclure, parce que ça résume tout ce dont on a parlé aujourd'hui. On a des modèles de 816 milliards de paramètres répartis sur quatre machines, des agents qui écrivent leur propre code, et en même temps, pour afficher des pixels carrés d'un jeu de 1996 dans des conditions historiquement fidèles, il faut de la puissance de calcul moderne. Le matériel improbable, le code hérité, les standards qui traversent les décennies, tout ça coexiste dans le même écosystème.

Nicolas Moreau: Et la leçon commune, si on veut en tirer une, c'est que la technologie ne remplace jamais tout à fait ce qui précède, elle empile. Les seeds NIST de l'époque d'lrand48 coexistent avec des modèles frontière, la mémoire partagée SysV des années 80 tourne encore dans des noyaux modernes, le RDMA se réinvente sur Thunderbolt, et les pixels nets de DOS ont toujours des fans.

Claire Martin: On en reste là pour aujourd'hui. Merci de nous avoir écoutés, on se retrouve très bientôt pour une nouvelle édition.

Nicolas Moreau: Salut à tous, et à la prochaine.