5 minutes
Veille du 11 octobre 2026 — inférence locale entreprise · contrôle de version · sécurité génération mouvements
Les 3 articles les plus chauds de la veille du 11 octobre 2026. 🔥
🔥 Top 3
1. Building a 4x R9700 setup for a 10 person startup
Quatre GPU AMD dans une tour, pour dix personnes : la nouvelle cohérence du calcul local.
Un post Reddit a fait réagir la communauté des modèles locaux récemment : une startup de dix personnes a monté une machine avec quatre Radeon R9700, les cartes workstation d’AMD basées sur l’architecture RDNA 4, dotées de 32 Go de mémoire vidéo (VRAM) chacune.
Le calcul est simple. Quatre cartes, cela fait 128 Go de VRAM disponibles pour faire tourner des modèles de langage open-weight, c’est-à-dire des modèles dont les poids sont publiés et que l’on peut héberger soi-même. Un 70 milliards de paramètres en quantification 4 bits (une compression qui réduit la taille des poids en sacrifiant un peu de précision) tient alors confortablement en mémoire.
L’argument économique tient en une phrase : le coût d’achat de la machine se situe dans la même fourchette qu’un abonnement annuel à une API pour une équipe de cette taille, mais les requêtes suivantes ne coûtent rien. Et les données d’entreprise ne quittent pas le bureau.
Le revers, c’est tout ce qui tourne autour du hardware. ROCm, le pile logiciel d’AMD pour le calcul accélééré, reste moins mature que CUDA chez NVIDIA, son équivalent. Les frameworks d’inférence y fonctionnent aujourd’hui, mais avec moins de chemins optimisés et parfois quelques réglages manuels.
Ce genre de configuration se banalise à mesure que les modèles ouverts rattrapent les propriétaires sur des tâches précises. La question qui se pose désormais : à partir de quelle taille d’équipe bascule-t-on du cloud vers une machine sous le bureau ?
🔗 www.reddit.com
2. Dwarf Fortress uses version control now
Dwarf Fortress utilise un contrôle de version depuis 2023. Oui, vous avez bien lu. Ce jeu, développé par deux frères depuis plus de vingt ans et connu pour sa complexité absolue (une simulation d’un monde entier, avec de la météo, de la géologie, des syndromes mystérieux qui peuvent tuer toute une forteresse naine) a fonctionné pendant des années sans Git, sans SVN, sans aucun sauvegardage structuré du code.
L’histoire est racontée par Simon Willison, qui a retrouvé les propos de Tarn Adams, le créateur du jeu. En 2013, il expliquait : je n’utilise pas de contrôle de version, je n’aime pas l’idée de mon code enfermé dans une boîte noire sans bénéfice immédiat. En 2016, il insistait encore : si vous ne savez pas ce qu’est le contrôle de version, ne me faites pas la leçon. Si vous savez ce que c’est, vous allez hurler.
Un contrôle de version, pour rappel, c’est l’outil qui garde l’historique de toutes vos modifications de code (Git est le plus connu). On peut revenir en arrière, comparer deux versions, travailler à plusieurs sans tout casser. La quasi-totalité des développeurs professionnels l’utilisent quotidiennement. Tarn Adams s’en passait depuis le début du projet.
Ce qui le fait changer d’avis, c’est la sortie sur Steam, qui a transformé le développement en quelque chose de plus collectif, avec des chaînes Discord à suivre et des processus à structurer. Le milliardaire (ou plutôt millionaire) a fini par céder avant de toucher ce palier.
La leçon est un peu amusante : un projet peut survivre des décennies sans les outils qu’on considère comme obligatoires, à condition d’avoir un seul développeur et beaucoup de discipline. La question, c’est combien d’autres codebases tiennent encore grâce à la même méthode artisanale.
🔗 Simon Willison
3. CSF: Contextual Safety Filtering for Motion Generators
Un robot humanoïde génère du mouvement à partir d’une phrase. « Tape dans le ballon » ou « tape dans le mur », pour le modèle c’est du pareil au même. C’est le problème que des chercheurs ont décidé de traiter, avec une couche de sécurité qui ne dépend pas du générateur.
Les générateurs de mouvement conditionnés par le texte savent produire des mouvements fluides et réalistes pour un robot entier. Ce qu’ils ignorent totalement, c’est le contexte de la scène : le même geste peut viser un objet inoffensif ou un humain. Les garde-fous existants vérifient la phrase d’entrée, nécessitent des données de mouvement annotées, ou imposent des contraintes géométriques. Aucun ne capte la manière dont le décor change le sens d’un mouvement.
L’approche, baptisée CSF (Contextual Safety Filtering), est un filtre qui s’applique sans réentraîner le générateur. Concrètement, on donne au système des règles de sécurité en langage naturel, chacune illustrée par des trajectoires de référence classées en sûres et en dangereuses. À partir de ces exemples, il construit une valeur d’affinité de sécurité. Un contrôleur du type CBF-QP (Control Barrier Function, combiné à un programme quadratique) corrige alors la trajectoire générée pour qu’elle reste du côté sûr, en demandant la modification minimale possible.
Les chiffres tiennent la route : le filtre active les bonnes règles dans tous les scénarios dangereux testés, réduit le taux d’événements à risque jusqu’à 90 %, et laisse passer entre 88 et 100 % des mouvements anodins. Il a été éprouvé sur un robot Unitree G1 en conditions réelles, y compris lors d’interactions avec des humains.
Reste une question pratique : ce genre de filtre deviendra-t-il une couche standard embarquée sur chaque humanoïde, ou restera-t-il une option que chaque constructeur devra soigner lui-même ?
🔗 arXiv
📦 Le reste de la veille
- @Kenz_1604 @sleepagotchi A sleep agent proactive approach contrasts sharply with traditional AI tools — Tweet vague évoquant un « sleep agent » proactif sans aucun détail technique ni démonstration exploitable.