Vous bossez sur un projet et vous vous dites "Tiens, le site de [insérez ici une grosse boîte] a un design plutôt bien foutu, j'aimerais bien voir comment ils ont structuré leurs css".

Hé bien y'a un outil pour ça, et il s'appelle Dembrandt .

Dembrandt en action

En gros, c'est un petit outil en ligne de commande qui va analyser n'importe quelle URL et en extraire tout le design system : les couleurs (primaires, secondaires, variables CSS), la typographie (familles, tailles, graisses), les espacements, les bordures, les ombres et même les patterns de composants UI.

Le truc s'installe en une ligne avec npm (npm install -g dembrandt) et après vous avez juste à taper dembrandt stripe.com par exemple. En moins d'une seconde, l'outil va alors faire un rendu de la page avec Playwright, analyser le DOM, détecter les styles et vous ressort tout ça bien structuré avec des scores de confiance pour chaque couleur.

Ce que j'aime bien, c'est que ça exporte directement en JSON ou au format W3C Design Tokens si vous voulez l'utiliser avec Style Dictionary. Pratique pour alimenter votre propre design system ou pour documenter celui d'un client qui n'a jamais pris le temps de le faire... (il en faut)

Y'a aussi quelques options sympas comme --dark-mode pour extraire la palette sombre, --mobile pour simuler un viewport iPhone, ou --browser=firefox si le site que vous voulez analyser a des protections Cloudflare qui bloquent Chromium.

Bon, ça marche pas sur les sites qui utilisent Canvas ou WebGL pour le rendu, et faut pas s'attendre à des miracles sur les SPA qui chargent tout en async. Mais pour la majorité des sites, c'est vraiment efficace.

Le projet est open source sous licence MIT, donc vous pouvez l'auditer, le forker, le modifier comme bon vous semble. Et niveau légalité, analyser du HTML/CSS public pour de la veille concurrentielle ou de la documentation, c'est considéré comme du fair use dans la plupart des juridictions, donc vous êtes good !

Bref, si vous faites du design system, de l'audit UX ou juste de la veille sur ce que font les autres, c'est un outil à garder sous le coude.

Merci à Lorenper pour le partage !

Vous vous souvenez de mes explications sur comment Boston Dynamics comptait construire un cerveau pour Atlas ? Hé bien, ils viennent de trouver le partenaire parfait pour y arriver. Et pas n'importe lequel !

Annoncé au CES 2026 à Las Vegas lors de la présentation Hyundai, le fabricant de robots s'allie avec Google DeepMind pour intégrer les modèles fondationnels Gemini Robotics directement dans leurs humanoïdes. Du coup, Atlas va pouvoir percevoir son environnement, raisonner, utiliser des outils et même interagir avec des humains. Bref, passer du robot acrobate impressionnant au robot vraiment utile.

Atlas en pied, prêt à conquérir les usines ( Source )

L'idée, c'est de combiner le meilleur des deux mondes. D'un côté, vous avez l'intelligence athlétique de chez Boston Dynamics, ces années d'expertise à créer des machines capables de faire des saltos et de se relever après une gamelle. De l'autre, les modèles multimodaux de DeepMind qui comprennent le langage, la vision et peuvent générer des actions. Le mariage parfait entre le corps et l'esprit, en quelque sorte.

Alberto Rodriguez, le directeur du comportement robot chez Boston Dynamics (un ancien prof du MIT qui a lâché sa chaire pour rejoindre l'aventure), explique qu'ils avaient besoin d'un partenaire capable de développer des modèles fiables et scalables. Et Carolina Parada de DeepMind confirme que leurs modèles Gemini Robotics ont justement été conçus pour apporter l'IA dans le monde physique. Hop, le puzzle s'assemble.

Le regard d'Atlas, bientôt alimenté par Gemini

Mais ne vous attendez pas à voir un Atlas débarquer chez vous pour faire le ménage demain matin. Sniiiif... La cible, c'est l'industrie manufacturière, et plus précisément les usines du groupe Hyundai (qui possède Boston Dynamics, rappelons-le). Parce que même dans les chaînes de production les plus automatisées, il reste des dizaines de milliers de tâches manuelles impossibles à robotiser avec les méthodes traditionnelles. Le coût et le temps de développement sont juste délirants.

Avec un humanoïde doté d'un cerveau généraliste, on peut théoriquement lui apprendre une nouvelle tâche en une journée au lieu d'un an. C'est le même principe que ChatGPT, mais appliqué au monde physique et ça, c'est un vrai changement de paradigme.

La recherche conjointe démarre dans les prochains mois. Alors est-ce que ça va révolutionner les usines ? Peut-être. Est-ce que c'est le début d'une nouvelle ère pour la robotique humanoïde ? Moi j'y crois.

En tout cas, dans tout ce bordel ambiant autour des robots et de l'IA, cette alliance entre le hardware le plus avancé et le software le plus puissant a du sens. Et si vous voulez en savoir plus sur l'évolution d'Atlas ces dernières années , je vous avais déjà fait un petit récap.

Source

Est-ce que vous avez déjà rêvé de composer de la musique comme on code un programme ? Genre, écrire une boucle for et qu'elle génère un beat au lieu d'afficher des nombres dans la console ?

Hé bien, c'est exactement ce que propose Dittytoy . Et le truc de fou, c'est que ça tourne directement dans votre navigateur. Une simple URL et hop, vous voilà compositeur.

Vous allez sur le site, vous tapez du code JavaScript dans un éditeur, vous cliquez sur "Compile", et votre navigateur se transformera alors en synthétiseur. La plateforme utilise la Web Audio API pour générer le son en temps réel, ce qui donne des possibilités assez dingues côté créativité sonore.

Dittytoy repose sur 4 briques de base. D'abord les synthés qui génèrent le son brut via des fonctions mathématiques (sinus, carrée, triangle...). Ensuite les boucles qui répètent des patterns avec des commandes play() et sleep(). Puis les enveloppes pour contrôler l'attaque et le decay des notes. Et enfin les filtres pour sculpter le son avec des passe-bas, passe-haut et compagnie.

La syntaxe est inspirée de Sonic Pi , le fameux outil de programmation musicale utilisé dans les écoles pour apprendre le code aux gamins. Si vous avez déjà joué avec, vous serez en terrain connu. Sinon, la documentation est plutôt bien foutue avec des exemples qui fonctionnent direct.

Niveau fonctionnalités, y'a également de quoi faire. Plus de 70 gammes intégrées (majeure, mineure, pentatonique...), 50 types d'accords, et même un système d'entrées qui permet de créer des sliders pour tweaker les paramètres en temps réel. Vous pouvez aussi exporter vos créations en MP3, ce qui est quand même pratique pour les partager.

Perso, ce qui me plaît dans ce genre d'outils, c'est qu'ils démocratisent la création musicale pour les gens qui ont le cerveau câblé "code" plutôt que "solfège". Vous savez, ceux qui comprennent mieux un Math.sin(phase * 2 * Math.PI) qu'une portée avec des croches dessus.

Et puis y'a un côté hypnotique à voir son code se transformer en musique surtout avec leur visualiseur.

C'est un peu comme le Chipophone , mais version navigateur et sans avoir à recycler un vieil orgue.

Le créateur, Reinder Nijhoff, a même sorti un package npm pour les développeurs qui voudraient intégrer le moteur dans leurs propres projets.

C'est gratuit, le package npm est sous licence MIT, et les créations partagées sur la plateforme sont sous CC BY-NC-SA par défaut. De quoi vous la jouer compositeur de chiptune entre deux commits.

Bon, évidemment ça ne remplacera pas Ableton pour produire un album. Mais pour s'amuser, apprendre les bases de la synthèse sonore, ou juste épater vos collègues à la pause café en générant un beat avec 10 lignes de code, ça fait largement le taf.

Source

Bon, si vous êtes dev ou admin sys, vous connaissez forcément ce moment de solitude. Celui où VS Code se fige pendant 3 minutes parce que vous avez eu l'audace d'ouvrir un fichier de logs de 2 Go. Ou pire, Notepad qui vous affiche un joli message d'erreur en guise de bienvenue.

Bref, la galère classique du lundi matin.

Heureusement, je viens de tomber sur Log Voyager , un outil open source qui analyse des fichiers de logs massifs... directement dans votre navigateur Chrome ou Firefox sans faire exploser votre RAM.

Log Voyager en action - navigation fluide dans un fichier de logs massif ( Source )

Son secret ?

Toniglandil bien sûr ! Non, je plaisante ! En fait ce truc utilise la File Slicing API pour lire vos fichiers par petits bouts de 50 Ko. C'est comme du streaming, sauf que c'est pour vos logs. Du coup, que votre fichier fasse 500 Mo ou 10 Go, seul le chunk visible est chargé en RAM. C'est chouette non ?

D'ailleurs, par conception ("by design" comme disent les titi consultants), toute l'analyse se fait côté client dans votre navigateur. Vous pouvez vérifier dans le code source sur GitHub : aucune requête réseau pour vos fichiers. Du coup, ça fonctionne même hors connexion et pour ceux qui bossent avec des logs contenant des données sensibles (genre des infos clients ou des tokens), c'est plutôt rassurant.

Côté fonctionnalités, y'a aussi de quoi faire. Le scroll infini permet de naviguer dans des fichiers énormes sans que le navigateur ne bronche. Il y a un système de filtrage par regex pour trouver exactement ce que vous cherchez, un prettifier JSON intégré qui formate automatiquement les lignes JSON dans vos logs (super pratique quand vous avez du JSON imbriqué partout), et un système de bookmarks avec position en octets pour retrouver facilement un endroit précis dans le fichier.

Pour l'installer, soit vous passez par Docker. Notez que j'ai du nettoyer un peu le Dockerfile car y'a des choses mal comitée dedans... Breeeef...

git clone https://github.com/hsr88/log-voyager.git
cd log-voyager
docker build -t log-voyager .
docker run -d -p 8080:80 log-voyager

git clone https://github.com/hsr88/log-voyager.git
cd log-voyager
npm install && npm run dev

La guerre des consoles des années 90, c'est terminé depuis longtemps... Enfin, c'est ce qu'on croyait ! Car un moddeur du nom de Malucard vient de raviver les braises en portant Super Mario 64 sur... PlayStation 1. Oui, le jeu phare de la N64 qui tourne nativement sur la console de Sony... À l'époque de ma jeunesse aux temps jadis, ça aurait fait scandale ^^

Le projet s'appelle SM64-PSX et c'est basé sur le fameux travail de décompilation de Super Mario 64 qui circule depuis quelques temps. Sauf que là, au lieu de simplement recompiler le code pour PC, Malucard l'a adapté pour qu'il tourne sur le hardware de la PS1. Et c'était pas gagné d'avance.

Car les deux consoles sont très différentes niveau architecture. Du coup, il a fallu réécrire tout un tas de trucs : conversion en mathématiques à virgule fixe au lieu de flottants, compilation just-in-time des listes d'affichage dans un format custom, compression des animations (de 580 Ko à 190 Ko stockés directement en VRAM), quantification des textures en 4 bits... Bref, du bricolage de haut niveau pour faire rentrer un jeu N64 dans une PS1.

Mais c'est jouable, même si faut pas s'attendre à du miracle non plus. Y'a des arbres qui flottent dans le vide à cause des conversions mathématiques, certaines animations font crasher le jeu, la caméra est aux fraises dans pas mal de niveaux, et le menu pause ne fonctionne pas. Mais bon, voir Mario sauter dans le château de Peach sur une PlayStation, ça a quand même de la gueule !

Et le plus marrant dans l'histoire, c'est que cette initiative a provoqué une riposte de l'autre camp. Des fans de Spyro the Dragon ont lancé un projet miroir pour porter le jeu d'Insomniac... sur N64 ! La guerre des consoles continue donc, mais cette fois-ci ce sont les fans qui s'en chargent.

Voilà, si vous voulez tester, le code source est dispo sur GitHub . Il vous faudra une ROM originale de Super Mario 64 version US et quelques outils de compilation. Le build génère un fichier ISO et CUE prêt à être gravé ou émulé. Le projet supporte même les manettes DualShock avec les vibrations !

Merci à Lorenper pour l'info !

Et si l'OS lui-même ÉTAIT le jeu ?

C'est exactement le concept derrière Aurora OS.js , un projet open source complètement barré qui simule un système d'exploitation complet dans votre navigateur... avec des mécaniques de jeu de hacking intégrées.

Le truc, c'est que ce n'est pas juste une démo technique. Aurora OS.js embarque un vrai système de fichiers virtuel avec stockage persistant, un terminal avec des commandes type Linux (ls, cd, cat, mkdir...), un gestionnaire de fenêtres, un bloc-notes avec coloration syntaxique, et toute une architecture modulaire pour les applications. Bref, ça ressemble à un vrai OS, ça se comporte comme un vrai OS, mais ça tourne dans un onglet de votre navigateur.

Côté technique, les développeurs n'ont pas fait dans la demi-mesure. C'est à base de React 19, Electron 39, TypeScript 5, Tailwind CSS v4, et des animations fluides grâce à Framer Motion. Et le tout nécessite Node.js 24 minimum, ce qui montre qu'on est clairement sur des technos de pointe.

Le projet suit une roadmap en trois étapes. La version actuelle (v0.7.7) se concentre sur les fondations et l'utilisabilité. La v1.x apportera le gameplay solo de hacking. Et la v2.x ? Du multijoueur persistant où vous pourrez hacker d'autres joueurs. Ça va être trop incrrrr !

Si vous aimez les expériences dans le navigateur ou les projets qui repoussent les limites du web , Aurora OS.js mérite clairement un coup d'œil. Y'a une démo live sur GitHub Pages pour tester directement (user: guest / mdp: guest). Et comme c'est sous licence AGPL-3.0, vous pouvez fouiller le code et même contribuer si le cœur vous en dit.

Source

Si vous utilisez Docker Desktop sur Mac et que vous en avez marre de voir votre ventilateur s'emballer dès que vous lancez trois conteneurs, j'ai peut-être la solution à vos problèmes.

OrbStack , c'est une app native Swift qui remplace Docker Desktop et qui fait tourner vos conteneurs sans transformer votre MacBook en mineur de Bitcoin. Le truc démarre en 2 secondes 12 et consomme très peu de ressources en arrière-plan. Autant dire que par rapport à l'usine à gaz qu'est devenu Docker Desktop, ça fait du bien.

Concrètement, vous avez accès à tout ce que vous connaissez : la CLI Docker est compatible, vos docker-compose tournent généralement sans modification, et même Kubernetes est intégré nativement. Pas besoin donc de tout réapprendre. Vous installez, et vous pouvez migrer vos conteneurs existants depuis Docker Desktop.

Un conseil quand même : faites une sauvegarde de vos volumes avant, parce que la migration peut parfois cafouiller.

Mais OrbStack ne se limite pas aux conteneurs puisque le logiciel embarque aussi un gestionnaire de machines virtuelles Linux. Plusieurs distributions sont disponibles, d'Ubuntu à Fedora en passant par Arch, et elles se configurent en une minute chrono. Pratique quand vous avez besoin d'un shell Linux fonctionnel sous macOS sans vous farcir la lourdeur de VirtualBox.

Côté technique, OrbStack utilise VirtioFS pour le partage de fichiers entre l'hôte et les conteneurs, ce qui explique en partie les performances. Sur Apple Silicon, l'émulation x86 passe par Rosetta, donc la plupart de vos images Intel devraient tourner. Le réseau est également soigné avec support IPv6 et ICMP. Par contre, certains utilisateurs ont signalé des soucis avec des VPN d'entreprise, donc testez avant de tout basculer.

Dans l'interface, vous avez vos conteneurs, vos machines Linux, vos volumes, le tout accessible depuis la barre de menu ou via la CLI. Y'a même l'intégration VS Code pour ceux qui bossent sur des projets dans les VM Linux.

Pour le prix, c'est gratuit pour un usage personnel et si vous l'utilisez dans un contexte professionnel, comptez 8 dollars par mois ou 96 dollars à l'année.

Le seul inconvénient, c'est que ça ne tourne que sur macOS donc tant pis pour vous si vous êtes sur Linux ou Windows. En tout cas, pour les développeurs Mac qui en ont ras-le-bol de voir Docker Desktop bouffer leurs ressources et leur batterie, c'est franchement une alternative qui mérite le détour. Un peu comme VirtualBuddy a révolutionné la virtualisation macOS, OrbStack fait pareil mais pour les conteneurs.

Quand je suis tombé sur Wario.style , j'ai d'abord cru à une blague. Sauf que non.

Ce petit site web vous transforme vos morceaux préférés en version Game Boy, à condition qu'un fichier MIDI existe pour la chanson en question. Vous cherchez une chanson, vous sélectionnez la source MIDI qui vous plaît, vous cliquez sur "Generate"... et là, c'est la magie des bips et des blops qui opère.

Ce qui se cache derrière porte le doux nom de Wario Synthesis Engine. Concrètement, ça analyse le fichier MIDI pour identifier les pistes de mélodie, de basse et d'accords, puis ça resynthétise le tout avec des oscillateurs Web Audio calibrés pour imiter la puce sonore 4 canaux de la Game Boy. Deux canaux pulse wave pour la mélodie, un canal wave pour les graves, et un canal noise pour les percussions. C'est à dire le même setup que la vraie console de 1989, les amis !

Et le plus beau dans tout ça, c'est que la synthèse audio se fait entièrement côté client. La recherche de fichiers MIDI passe par un serveur, mais la génération du son, elle, tourne direct dans votre navigateur. Du coup, niveau réactivité, on est bien.

Le site est signé @b1rdmania, un dev qui a construit ce projet "for lols" avec Claude Code (hé oui, c'est mentionné fièrement sur la page). D'ailleurs si vous voulez fouiller le code source , tout est public sur GitHub. C'est du TypeScript propre avec Vite derrière pour le build.

Les dev ont un peu peur des avocats de Nintendo... lol ( Source )

Côté fonctionnalités, la version 1.3 apporte le partage direct sur X, une palette Game Boy claire pour les nostalgiques du vert olive, et des correctifs pour l'audio sur iPhone. Parce que oui, Apple bloque le son tant que vous n'avez pas tapé sur un truc, mais une fois le bouton "Enable Audio" cliqué, c'est parti mon kiki.

Le projet a d'ailleurs une page d'embed si vous voulez intégrer vos créations chiptune sur vos sites web. Perso, je trouve ça super cool pour donner une ambiance rétro à n'importe quel projet.

Voilà, si vous avez grandi avec les bips caractéristiques de la Game Boy et que vous avez toujours rêvé de transformer vos morceaux préférés en 8-bit, foncez tester Wario.style . C'est gratuit, c'est fun, et n'oubliez pas, si vous cherchez d'autres outils pour composer du chiptune plus sérieusement, j'ai parlé de Furnace et DefleMask il y a pas longtemps.

RyuU12358 n'est pas un personnage de manga cyberpunk... Non, c'est un développeur japonais qui a eu une idée toute bête. Il s'est demandé si on pouvait VOIR la structure des formules Excel au lieu de les lire comme on lirait un roman écrit en russe ?

Parce que bon, les formules de tableur imbriquées, c'est le cauchemar de pas mal de monde. Vous savez, ce genre de truc : =IF(AND(SUMIF(A:A,B2,C:C)>100,VLOOKUP(D2,E:F,2,FALSE)="OK"),CONCATENATE(G2," - ",H2),"Erreur").

Et encore, j'ai pris un exemple gentil.

Demo Frockly : une formule Excel décomposée en blocs ( Source )

Le problème, comme le souligne très justement le créateur, c'est pas que ces formules sont complexes. C'est que leur structure est planquée à l'intérieur d'une seule ligne de texte, du coup, à chaque fois qu'on doit les modifier, on repart de zéro pour comprendre comment tout s'imbrique.

Rien que d'y penser, ça me donne la flemme...

Mais c'est là qu'intervient Frockly , un éditeur web qui transforme vos formules en blocs visuels façon Scratch qu'on peut manipuler comme des Lego. Vous collez votre formule monstrueuse, et hop, elle se décompose en morceaux logiques reliés entre eux. Ça ressemble un peu à Flyde pour la programmation visuelle , mais adapté au monde des tableurs.

L'outil propose plusieurs modes de visualisation comme replier certaines parties pour avoir une vue d'ensemble, zoomer sur un noeud précis, ou remonter à la racine pour comprendre la hiérarchie.

Et le truc cool, c'est qu'on peut aussi construire ses formules de A à Z en assemblant des blocs. Plus besoin de compter les parenthèses comme un comptable sous pression. On connecte les fonctions entre elles, et Frockly génère la formule textuelle qu'on peut ensuite copier-coller dans Excel ou un autre tableur.

Y'a même un système de formules nommées (internes à Frockly) pour réutiliser des morceaux de logique, et un import expérimental de fichiers xlsx qui fonctionne côté client. Bon, on est sur une version 0.5, donc faut pas s'attendre à un truc parfaitement stable non plus...

Notez quand même que Frockly ne remplace pas Excel. C'est un outil qui tourne entièrement dans votre navigateur (pas d'upload serveur), ne calcule rien, ne modifie pas vos fichiers, et ne prétend surtout pas être un tableur. C'est en réalité un espace de travail intermédiaire pour comprendre et refactorer, point barre. L'idée c'est d'organiser vos formules ici, puis de retourner dans votre tableur avec une version plus claire.

Le tout est développé en TypeScript, tourne dans le navigateur, et le code est disponible sur GitHub. Bref, si vous avez déjà pesté devant une formule Excel incompréhensible héritée d'un collègue qui a quitté la boite il y a 3 ans, ce petit outil pourrait bien vous sauver quelques heures de migraine.

Source

Soyez honnêtes, c'est quoi votre dernier message de commit ? "fix", "update", "refactor" ou les grands classiques "Ça marche, on ne touche plus" ou "azertyuiop^$" ?

Si vous vous reconnaissez, alors Lumen va peut-être vous sauver la mise.

Lumen c'est un outil en ligne de commande écrit en Rust qui utilise l'IA pour vous aider à gérer votre workflow Git. En gros, vous stagez vos fichiers, vous lancez lumen draft et hop, l'IA analyse vos modifications pour générer un message de commit propre au format conventionnel. Fini les "fixed stuff" à 3h du mat.

Mais le truc va plus loin que ça puisque vous pouvez aussi lui demander d'expliquer un commit avec lumen explain HEAD (ou un hash, une plage de commits...). Pratique quand vous tombez sur du code écrit par vous-même il y a 6 mois et que vous n'y comprenez plus rien. D'ailleurs, y'a même une fonctionnalité de recherche interactive dans l'historique avec lumen list si vous avez fzf d'installé.

Et le plus cool, c'est la commande lumen operate. Vous lui décrivez en langage naturel ce que vous voulez faire genre "squash mes 3 derniers commits" et il vous génère la commande Git correspondante. Avec un warning si la commande est potentiellement destructrice et une demande de confirmation avant exécution, histoire de pas faire de bêtises.

Côté providers, c'est flexible... OpenAI, Anthropic Claude, Gemini, Groq, DeepSeek, Ollama pour du local, et d'autres encore... Vous configurez ça une fois avec lumen configure pour les commandes IA et c'est parti. Le diff viewer intégré est pas mal non plus (et lui fonctionne sans config), avec une vue côte à côte dans le terminal et la possibilité de naviguer entre les hunks.

L'installation se fait via Homebrew sur Mac/Linux avec brew install jnsahaj/lumen/lumen ou via Cargo si vous avez Rust. C'est open source sous licence MIT.

Perso, je trouve que c'est le genre d'outil bien pratique pour ceux qui galèrent avec leurs messages de commit ou qui passent leur temps à chercher des commandes Git obscures. Et le fait que ça tourne avec différents providers IA, y compris en local avec Ollama, c'est également un vrai plus pour ceux qui veulent pas envoyer leur code sur des serveurs externes.

A tester donc !

Source

Ah, Atom... Si vous avez connu l'éditeur de code de GitHub à l'époque, vous savez de quoi je parle. C'était le premier éditeur vraiment moderne, hackable à souhait, avec une communauté de dingues qui créait des extensions pour tout et n'importe quoi. Et puis Microsoft a racheté GitHub, et Atom a fini au cimetière des projets open source en 2022. RIP.

Sauf que les créateurs d'Atom n'ont pas dit leur dernier mot. Nathan Sobo et son équipe ont décidé de repartir de zéro pour créer Zed , un éditeur de code qui corrige toutes les erreurs du passé. Et quand je dis « de zéro », c'est vraiment from scratch, en Rust cette fois, et pas en Electron \o/.

Zed en action

Et ce qu'on obtient, c'est un éditeur qui démarre en quelques millisecondes et qui reste fluide même quand vous ouvrez des projets monstrueux. Là où VS Code commence à ramer sur un gros monorepo, Zed reste stable. C'est pas de la magie, c'est juste du code natif bien optimisé avec un moteur de rendu GPU custom (GPUI pour les intimes).

Mais le truc qui m'a vraiment intrigué, c'est leur concept de « Zed is our office ». En gros, l'équipe de développement de Zed n'a pas de bureau physique. Leur bureau, c'est Zed lui-même. Ils bossent en permanence dans des « channels » partagés où ils peuvent coder ensemble en temps réel, se parler en audio, et voir les curseurs des autres se balader dans le code. C'est du pair programming poussé à l'extrême, et apparemment ça marche plutôt bien pour eux.

Bon, faut qu'on parle un peu du moteur de recherche de mon site. Ceux qui l'ont déjà utilisé savent de quoi je parle : c'était pas terrible. Enfin, « pas terrible » j'suis gentil. C'est un espèce d'overlay avec des résultats certes fiables mais c'était vraiment pas pratique.

Et en plus de ça, comme j'ai un site statique généré avec Hugo, je passais par Algolia pour la recherche. Si vous ne connaissez pas, Algolia c'est un service cloud qui indexe votre contenu et vous fournit une API de recherche ultra-rapide. Sur le papier c'est génial et dans la pratique aussi d'ailleurs sauf que voilà, ça coûte des sous. Et mon site rencontre un franc succès ces derniers temps (merci à vous !), donc j'ai de plus en plus de visiteurs, donc de plus en plus de recherches, donc une facture Algolia qui grimpe gentiment chaque mois.

Du coup je me suis dit : « Et si je trouvais une solution de recherche pour sites statiques ? » Parce que oui, ça existe et c'est comme ça que j'ai découvert Pagefind.

Pagefind c'est donc un moteur de recherche statique open source développé par CloudCannon qui fonctionne comme ceci : Au moment du build de votre site, Pagefind parcourt tout votre HTML généré et crée un index de recherche qu'on peut interroger avec un peu de JS. Y'a donc plus d'API, et tout se fait localement sur le navigateur des internautes.

Bref, ça avait l'air très cool alors évidemment, je me suis lancé dans l'aventure et comme j'aime bien me compliquer la vie, j'ai décidé de pas juste intégrer Pagefind tel quel. Non non. J'ai voulu recréer l'interface du Google de 1998 parce que à quoi bon avoir son propre site web si on peut pas s'amuser un peu ^^.

Laissez-moi donc vous raconter cette aventure.

Le problème avec Algolia

Leur service est excellent, je dis pas le contraire, la recherche est rapide, les résultats sont pertinents, l'API est bien foutue mais voilà, y'a le modèle de pricing puisque Algolia facture au nombre de requêtes de recherche.

Plus les gens cherchent sur votre site, plus vous payez et quand vous avez un site qui fait plusieurs millions de pages vues par mois, bah... ça chiffre vite. En gros je dépasse très vite les 10 000 recherches offertes chaque semaine et ensuite ça chiffre. C'est pas la mort, mais c'est un coût récurrent débile pour un truc qui pourrait être gratuit.

En plus de ça, y'a la dépendance à un service externe. Si Algolia tombe, ma recherche tombe. Et si Algolia change ses prix, je vais devoir subir. Même chose si Algolia décide de modifier son API... il faudra que j'adapte mon code. Bref, c'est le cloud dans toute sa splendeur... C'est pratique mais on n'est jamais vraiment chez nous.

Pagefind à la rescousse

Pagefind résout donc tous ces problèmes d'un coup. C'est un outil en ligne de commande qui s'exécute après votre générateur de site statique (Hugo dans mon cas, mais ça marche avec Jekyll, Eleventy, Astro, ou n'importe quoi d'autre).

Concrètement, vous lancez :

npx pagefind --site public

Et Pagefind va :

• 1. Scanner tous vos fichiers HTML dans le dossier public/
• 2. Extraire le contenu textuel (en ignorant la nav, le footer, les pubs si vous lui dites)
• 3. Créer un index de recherche optimisé
• 4. Générer des fichiers JavaScript pour interroger cet index côté client

Et le résultat c'est un dossier pagefind/ qui contient tout ce qu'il faut. Ensuite; à vous de servir ces fichiers statiquement avec le reste de votre site, et la magie pourra opérer !

L'index pour mes 18 000 articles fait environ 1,5 Go. Ça peut paraître beaucoup, mais Pagefind est malin car il découpe l'index en fragments et ne charge que ce qui est nécessaire pour la recherche en cours. Du coup en pratique, une recherche typique télécharge quelques centaines de Ko, et pas plus.

L'intégration technique

Pour intégrer Pagefind dans mon workflow Hugo, j'ai donc été cherché le binaire, je l'ai mis sur mon serveur et je l'ai appelé dans un cron comme ça, je rafraichi l'index de recherche 1 fois par jour (et pas à chaque génération du site).

0 4 * * * /home/manu/pagefind/pagefind --site /home/manu/public_html --output-path /home/manu/public_html/pagefind >> /var/log/pagefind.log 2>&1

J'ai aussi créé un fichier de configuration pagefind.yml pour affiner le comportement :

root_selector: "[data-pagefind-body]"
exclude_selectors:
 - "header"
 - ".site-header"
 - "footer"
 - ".sidebar"

L'astuce ici c'est d'indexer uniquement les div ayant la class data-pagefind-body='true' et d'exclure les éléments qui ne font pas partie du contenu éditorial afin de ne pas indexer ce qui se trouve dans le header, les natives, le footer...etc.

Côté JavaScript, Pagefind utilise les imports ES6 dynamiques. Ça veut dire que le moteur de recherche n'est chargé que quand l'utilisateur lance effectivement une recherche :

async function initPagefind() {
pagefind = await import('/pagefind/pagefind.js');
await pagefind.init();
}

Et pour faire une recherche :

const search = await pagefind.search("linux");
// search.results contient les IDs des résultats
// On charge le contenu de chaque résultat à la demande
for (const result of search.results) {
 const data = await result.data();
 console.log(data.url, data.meta.title, data.excerpt);
}

C'est bien fichu parce que search.results retourne immédiatement les références des résultats, mais le contenu réel (titre, extrait, URL) n'est chargé que quand vous appelez result.data(). Du coup vous pouvez implémenter une pagination propre sans télécharger les données de milliers de résultats d'un coup.

Le délire rétro - Recréer Google 1998

Maintenant que j'avais un moteur de recherche fonctionnel, fallait l'habiller. Et c'est là que j'ai eu cette idée un peu débile : Pourquoi pas recréer l'interface du Google de 1998 ?

Pour les plus jeunes qui lisent ça, Google en 1998 c'était une page blanche avec un logo, un champ de recherche, et deux boutons : « Google Search » et « I'm Feeling Lucky« . Pas de suggestions, pas de carrousels, pas de pubs... Juste un champs de recherche. C'était la belle époque !

J'ai donc créé une page de recherche avec deux vues distinctes. La page d'accueil avec le logo centré et le champ de recherche au milieu, exactement comme le Google originel.

Et la page de résultats avec le logo en petit en haut à gauche et les résultats en dessous.

Pour le code CSS, j'ai voulu être fidèle à l'époque. Times New Roman comme police par défaut, les liens en bleu souligné qui deviennent violet une fois visités. Et surtout, les boutons avec l'effet 3D des interfaces Windows 95 :

.search-button:active { border-style: inset; }

Ce border: outset et border-style: inset au clic, c'est exactement ce qui donnait cet effet de bouton en relief qu'on avait partout dans les années 90. Pour moi, ça fait toute la différence pour l'authenticité. Même le logo, je l'ai volontairement « dégradé » pour qu'il soit de la même qualité que le logo Google d'origine.

La pagination « Koooooorben »

Vous vous souvenez de la pagination de Google avec « Goooooogle » en bas de page ? Le nombre de « o » correspondait au nombre de pages de résultats. J'ai fait pareil, mais avec « Koooooorben ».

let logo = 'K'; for (let i = 0; i < oCount; i++)
{
logo += o;
} logo += 'rben'; }

Plus il y a de résultats, plus il y a de « o ». C'est complètement inutile mais ça me fait marrer à chaque fois que je le vois.

Le bouton « J'ai de la chance »

Ah, le fameux « I'm Feeling Lucky » de Google, j'ai voulu l'implémenter comme à l'époque ! Si vous tapez une recherche et cliquez sur « J'ai de la chance », vous êtes envoyé sur le premier résultat. Classique. Mais si vous cliquez sur le bouton avec le champ vide sur la home de la recherche, vous êtes envoyé sur un article aléatoire parmi les +18 000 du site.

Pour ça, j'ai utilisé une astuce : le sitemap. Mon Hugo génère un fichier sitemap.xml qui contient toutes les URLs du site et je peux aller piocher dedans en JS :

const articles = [...xml.querySelectorAll('loc')] .map(loc => loc.textContent) .filter(url => {
// Exclure les pages qui ne sont pas des articles
const path = new URL(url).pathname;
return !path.startsWith('/categories/') && !path.startsWith('/page/') && path !== '/';
});
const randomUrl = articles[Math.floor(Math.random() * articles.length)];
window.location.href = randomUrl;
} }

Un seul fetch, un peu de parsing XML natif, et hop c'est le grand retour de la fonctionnalité « article aléatoire » qui vous manquait, je le sais !

Tri et nombre de résultats

Je vous ai aussi mis une listbox qui vous permet d'afficher 10, 25 ou 50 résultats ainsi qu'un tri par pertinence ou data. Et ça aussi Pagefind sait parfaitement le navigateur.

Mode sombre et accessibilité

Même si l'interface est rétro, j'ai quand même ajouté quelques fonctionnalités modernes. Le mode sombre respecte les préférences système, et j'ai intégré la police OpenDyslexic pour les personnes dyslexiques.

Le truc important c'est de charger ces préférences avant le rendu de la page pour éviter le fameux flash. J'ai donc un petit script qui lit les préférences dans le localStorage et applique les classes CSS immédiatement :

function() {
 if (localStorage.getItem('theme') === 'dark') {
 document.documentElement.classList.add('dark-mode');
 }
 if (localStorage.getItem('dyslexic-font') === 'true') {
 document.documentElement.classList.add('dyslexic-mode');
 }
});

Gestion de l'historique navigateur

Un détail qui peut sembler anodin mais qui est super important pour l'expérience utilisateur c'est la gestion du bouton retour du navigateur.

Quand vous faites une recherche, l'URL change selon votre requête du genre /recherche/?q=linux&p=2. Du coup si vous partagez cette URL à un collègue, la personne arrivera directement sur les résultats de recherche. Et si vous utilisez le bouton retour, vous reviendrez alors à la recherche précédente.

window.addEventListener('popstate', () => {
const query = new URLSearchParams(location.search).get('q');
if (query) doSearch(query);
else showHomePage();
});

Liens vers d'autres moteurs

Et si vous ne trouvez pas votre bonheur dans mes +18 000 articles (ce qui serait quand même étonnant ^^), j'ai ajouté des liens pour relancer la même recherche sur Google, DuckDuckGo, Qwant, Brave et Ecosia. Bref, un petit service bonus pour mes visiteurs, exactement comme le proposait Google à l'époque.

Le bilan - Algolia vs Pagefind

Après 1 semaine d'utilisation, voici donc mon verdict ! Côté portefeuille d'abord, Algolia me coûtait entre 60 et +100 euros par mois et maintenant pour Pagefind, c'est zéro euros ! Et les performances sont également au rendez-vous. Algolia c'était rapide et bien là, ça l'est encore plus. Seul compromis à noter, l'index Algolia se mettait à jour en temps réel, alors que Pagefind nécessite une reconstruction au moment du build.

La conclusion

Voilà, j'ai maintenant une recherche qui marche vraiment bien, qui me coûte 0€ par mois, et qui a un look rétro qui va en surprendre plus d'un...

Alors est-ce que c'était nécessaire de passer autant de temps sur le design rétro ? Hé bien absolument pas. Mais est-ce que ça valait le coup ?

Franchement, oui !! C'est mon site, je fais ce que je veux, et si ça peut faire sourire quelques visiteurs nostalgiques des débuts du web, c'est du bonus. D'ailleurs un grand merci aux Patreons qui me soutiennent car sans eux, je n'aurais pas pu passer mon dimanche là dessus ^^

Et puis surtout, ça m'a permis de découvrir Pagefind qui est vraiment un excellent outil. Donc si vous avez un site statique (ou n'importe quel type de contenu textuel) et que vous cherchez une solution de recherche gratuite et performante, je vous le recommande chaudement. La documentation est claire, l'intégration est simple, et le résultat est top !

Allez, maintenant vous pouvez aller tester la nouvelle recherche sur le site . Et si vous cliquez sur « J'ai de la chance » sans rien taper... bonne découverte !

J'sais pas si vous vous rappelez mais quand on jouait à nos jeux préférés sur un de ces vieux écrans CRT, l'image était nette ! Une clarté de mouvement quasi parfaite, avec très peu de traînées... C'était chouette ! Hé bien y'a un dev qui a décidé de recréer ça sur nos écrans modernes avec un outil open source qui s'appelle ShaderBeam .

En fait, le souci de nos LCD et autres OLED, c'est que chaque pixel reste allumé pendant toute la durée d'une frame (c'est ce qu'on appelle le sample-and-hold ). Alors que sur un CRT, le faisceau d'électrons balayait l'écran ligne par ligne, donc chaque pixel ne s'allumait qu'une fraction de seconde. C'est ça qui donnait cette sensation de netteté en mouvement. C'est précisément ce comportement que ShaderBeam tente de reproduire via un shader GPU.

Si vous avez toujours voulu essayer Emacs mais que la courbe d'apprentissage vous fait peur, IDEmacs est fait pour vous ! Ce projet transforme Emacs en clone de VSCode avec les mêmes raccourcis clavier, la même interface graphique et les mêmes fonctionnalités out-of-the-box, comme ça vous n'avez plus besoin de vous taper une configuration durant trois jours avant de pouvoir écrire une ligne de code !

Cool, hein ?

L'idée c'est donc de permettre aux développeurs habitués à des IDE modernes de passer à Emacs sans devoir réapprendre tous leurs réflexes. Les raccourcis clavier reprennent ceux de VSCode comme Ctrl+C pour copier, Ctrl+V pour coller, Ctrl+F pour chercher. C'est basique mais indispensable quand vous venez d'un autre éditeur.

Côté interface, IDEmacs intègre Treemacs pour avoir un explorateur de fichiers dans la sidebar comme sur VSCode. Y'a aussi Centaur Tabs pour les onglets, un thème Dark Plus qui ressemble à celui de Microsoft, et le support des curseurs multiples. Bref, visuellement vous êtes en terrain connu.

Du coup, c'est pour qui exactement ?

Hé bien le projet cible trois types d'utilisateurs : les développeurs qui veulent migrer vers Emacs depuis un autre IDE, les débutants en Lisp ou Scheme qui ont besoin d'Emacs pour bosser, et les non-programmeurs qui cherchent juste un éditeur de texte puissant sans se prendre la tête avec la config.

D'ailleurs, contrairement à la plupart des starter kits Emacs, IDEmacs ne cache pas les éléments graphiques par défaut. Les menus, barres d'outils et scrollbars sont visibles donc vous pouvez configurer le tout via l'interface graphique plutôt qu'en écrivant du Elisp à la main.

La config proposée inclut une vingtaine de packages tels que Vertico, Consult et Marginalia pour l'autocomplétion, Magit pour le contrôle de version, Sly et Geiser pour le développement Lisp et Scheme, plus des outils comme expand-region, multiple-cursors et smartparens pour l'édition avancée.

Pour installer IDEmacs, il vous faudra donc Emacs 29 ou plus récent, git, et optionnellement grep et locate. Clonez le repo puis lancez Emacs avec

emacs --init-directory=/path/to/IDEmacs/vscode .

Vous utilisez Claude Code comme moi pour bosser plus vite sur vos projets de dev ? Hé bien j'espère que vous n'avez jamais eu la mauvaise surprise de voir l'agent lancer un petit rm -rf ~/ qui détruit tout votre répertoire home en 2 secondes. Parce que oui, ça arrive malheureusement, et plusieurs devs en ont fait les frais cette année...

Le problème c'est que les agents IA, aussi intelligents soient-ils, peuvent manquer de garde-fous sur ce qui est vraiment dangereux. Vous leur dites "nettoie le projet" et hop, ils interprètent ça un peu trop littéralement et une fois que c'est fait, y'a plus qu'à pleurer devant son terminal vide.

C'est pour ça qu'un développeur du nom de kenryu42 a créé Claude Code Safety Net qui est un plugin pour Claude Code qui agit comme un garde-fou mécanique. Son idée c'est de bloquer les commandes destructives AVANT qu'elles ne s'exécutent, et pas juste avec des règles bêtes genre "si la commande commence par rm -rf".

Le plugin est bien plus malin que ça puisqu'il fait une analyse sémantique des commandes. Il comprend la différence entre git checkout -b nouvelle-branche (qui est safe, ça crée juste une branche) et git checkout -- . qui lui va dégager tous vos changements non committés sur les fichiers suivis. Les deux commencent pareil, mais l'une vous sauve et l'autre vous ruine psychologiquement, vous forçant à vous réfugier dans la cocaïne et la prostitution.

Et c'est pareil pour les force push. Le plugin bloque git push --force qui peut écraser l'historique distant et rendre la récupération très difficile, mais il laisse passer git push --force-with-lease qui est la version plus sûre, car elle vérifie que la ref distante correspond à ce qu'on attend (même si ce n'est pas une garantie absolue).

Et le truc vraiment bien foutu, c'est qu'il détecte aussi les commandes planquées dans des wrappers shell. Vous savez, le genre de piège où quelqu'un écrit sh -c "rm -rf /" pour bypass les protections basiques. Le plugin parse récursivement et repère la commande dangereuse à l'intérieur. Il fait même la chasse aux one-liners Python, Ruby ou Node qui pourraient faire des dégâts.

Côté rm -rf, le comportement par défaut est plutôt permissif mais intelligent... les suppressions dans /tmp ou dans le dossier de travail courant sont autorisées parce que c'est souvent légitime, par contre, tenter de nuke votre home ou des dossiers système, c'est non négociable.

Et pour les paranos (comme moi), y'a un mode strict qu'on active avec SAFETY_NET_STRICT=1. Dans ce mode, toute commande non parseable est bloquée par défaut, et les rm -rf même dans le projet courant demandent validation. Mieux vaut prévenir que pleurer.

Si ça vous chauffe, l'installation se fait via le système de plugins de Claude Code avec deux commandes :

/plugin marketplace add kenryu42/cc-marketplace
/plugin install safety-net@cc-marketplace

Si vous utilisez GitHub Copilot ou ChatGPT pour coder plus vite, voici une nouvelle qui va peut-être vous refroidir un peu. Une fintech a découvert que des attaquants avaient extrait des données clients via un endpoint API qui n'était documenté nulle part. Personne dans l'équipe ne se souvenait l'avoir créé et après 3 semaines d'enquête, le verdict est tombé : c'est Copilot qui l'avait généré pendant une session de code nocturne.

Bienvenue dans l'ère des "phantom APIs" les amis !

J'avoue que le concept m'a fait marrer car on parle quand même d'endpoints qui existent en production mais dont personne n'a connaissance. Ahahaha... y'a pas de documentation, pas de tests, pas de validation de sécurité. C'est juste un peu de code généré par une IA qui a trouvé ça "logique" de créer un /api/v2/admin/debug-metrics qui balance du PII à quiconque tombe dessus par hasard.

J'ai vu le dernier rapport Veracode GenAI Code Security et les chiffres font un peu flipper c'est vrai ! Ils ont testé plus de 100 LLM sur 80 tâches de codage différentes, et le résultat fait mal puisque 45% du code généré par IA contient des vulnérabilités classées OWASP Top 10. En gros, presque une fois sur deux, votre assistant IA vous pond du code troué comme une passoire. Java est le grand gagnant avec 72% de taux d'échec, suivi par Python, JavaScript et C# qui tournent autour de 38-45%.

En effet, l'IA ne pense pas comme un dev qui s'est déjà fait hacker. Par exemple, quand un dev crée un endpoint, il réfléchit authentification, rate limiting, exposition de données, documentation. Alors que l'IA, elle, génère juste ce qui lui semble statistiquement logique vu son dataset d'entraînement, sans comprendre les implications sécurité ou les politiques de l'organisation.

D'ailleurs une autre étude Apiiro montre que les assistants IA ont multiplié par 10 les vulnérabilités introduites en seulement 6 mois dans les dépôts étudiés. Les chemins d'escalade de privilèges ont explosé tout comme les défauts architecturaux. Et le pire c'est que les développeurs qui utilisent l'IA exposent leurs credentials cloud (clés Azure, Storage Access Keys) deux fois plus souvent que les autres.

Y'a aussi le problème du "slopsquatting". Oui, encore un gros mot, je sais... En fait, l'IA peut vous recommander d'installer un package qui n'existe tout simplement pas. Genre elle hallucine un nom de librairie et un attaquant un peu moins con que les autres, peut enregistrer ce nom sur npm ou PyPI et y foutre du code malveillant.

Et là que ça devient vraiment problématique, c'est que les outils de sécurité traditionnels ne voient rien. L'analyse statique compare votre code à des specs documentées, sauf que les phantom APIs n'existent dans aucune spec. Les API gateways protègent les endpoints enregistrés mais laissent passer des routes non déclarées sans authentification.

Pour s'en sortir, certaines boîtes commencent donc à analyser le trafic en temps réel pour détecter les endpoints qui traînent. Y'a aussi l'audit de code spécifique IA pour repérer les patterns de génération algorithmique, et la comparaison continue entre les specs et ce qui tourne vraiment en production.

Bref, relisez votre code généré par IA comme si c'était un stagiaire collégien de 3e qui l'avait écrit, et si vous découvrez un endpoint bizarre dans votre base de code dont personne ne se souvient, y'a des chances que ce soit un "fantôme" laissé par votre copilote préféré...

Vous passez vos journées à faire des aws iam list-users | jq '.Users[]' et autres trucs interminables pour juste trouver une info ?? Laissez tomber, j'ai le truc qui va vous changer la vie !

Ça s'appelle Sisu et c'est un petit outil en Go qui monte vos ressources AWS comme un système de fichiers local. Du coup, au lieu de taper des commandes AWS complexes, vous utilisez juste grep, cat, diff, vim... c'est à dire les outils Unix que vous connaissez déjà par cœur.

Vous lancez la commande sisu et hop, vos ressources AWS se retrouvent montées dans ~/.sisu/mnt/ ! Vos buckets S3, vos paramètres SSM, vos roles IAM, vos lambdas, vos instances EC2...etc. Tout ça organisé en dossiers par profil AWS et par région.

Ainsi, pour chercher tous vos utilisateurs IAM qui ont un accès admin, c'est aussi simple que :

grep -l "AdministratorAccess" */global/iam/users/*/policies.json

diff prod/global/iam/roles/api/info.json staging/global/iam/roles/api/info.json

go install github.com/semonte/sisu@latest

Passer d'OpenGL à Metal, c'était visiblement pas une mince affaire pour l'équipe d'OBS. La techno d'Apple est sortie y'a 10 ans sous macOS mais ça leur a pris un peu de temps pour la migration... Et n'allez pas croire que je "juge"... Tout ce temps, c'est normal car c'est un soft multiplateforme, donc faut gérer trois écosystèmes en parallèle et ça, ça prend un temps fou.

Tous les effets visuels d'OBS ont dû être réécrits pour fonctionner avec Metal, le langage graphique d'Apple étant bien plus exigeant que celui de Windows et la preview peut parfois légèrement saccader à cause de macOS, mais le flux final reste impeccable.

Niveau performances, Metal fait aussi bien voire mieux qu'OpenGL dans les builds Release mais c'est surtout pour le débogage que ça change tout car les développeurs ont maintenant accès à des outils de diagnostic bien plus performants, ce qui devrait accélérer les corrections de bugs et les futures améliorations.

Pour l'activer (ouais on est chaud !!), c'est hyper simple. Vous allez dans les paramètres d'OBS 32.0, onglet Avancé, section Vidéo, et vous sélectionnez Metal dans le menu déroulant du renderer. Un petit redémarrage de l'appli et hop, vous êtes passé sur le nouveau moteur.

Ce qui est cool aussi avec cette version 32.0, c'est qu'elle inclut un gestionnaire de plugins et des améliorations pour les fonctionnalités NVIDIA RTX.

L'équipe OBS bosse aussi sur des backends Vulkan pour Linux et Direct3D 12 pour Windows, parce que les anciennes APIs comme OpenGL et D3D11 reçoivent de moins en moins de support des fabricants de GPU, donc si vous êtes sur Linux ou Windows, votre tour viendra aussi.

Voilà, après si ça bug, revenez sur OpenGL, mais y'a quand même de bonnes chances que ça tourne mieux qu'avant.

Source

Boston Dynamics que vous connaissez tous pour ses chiens robots tueurs de la mort, vient de sortir une vidéo de 40 minutes. Pas de saltos arrière ou de robots qui dansent mais plutôt une loooongue session où ça parle stratégie IA et vision à long terme. Et comme j'ai trouvé que c'était intéressant, je partage ça avec vous !

Zach Jacowski, le responsable d'Atlas (15 ans de boîte, il dirigeait Spot avant), discute donc avec Alberto Rodriguez, un ancien prof du MIT qui a lâché sa chaire pour rejoindre l'aventure et ce qu'ils racontent, c'est ni plus ni moins comment ils comptent construire un "cerveau robot" capable d'apprendre à faire n'importe quelle tâche. Je m'imagine déjà avec un robot korben , clone de ma modeste personne capable de faire tout le boulot domestique à ma place aussi bien que moi... Ce serait fou.

Leur objectif à Boston Dynamics, c'est donc de créer le premier robot humanoïde commercialement viable au monde et pour ça, ils ont choisi de commencer par l'industrie, notamment les usines du groupe Hyundai (qui possède Boston Dynamics).

Alors pourquoi ? Hé bien parce que même dans les usines les plus modernes et automatisées, y'a encore des dizaines de milliers de tâches qui sont faites à la main. C'est fou hein ? Automatiser ça c'est un cauchemar, car pour automatiser UNE seule tâche (genre visser une roue sur une voiture), il faudrait environ un an de développement et plus d'un million de dollars.

Ça demande des ingénieurs qui conçoivent une machine spécialisée, un embout sur mesure, un système d'alimentation des vis... Bref, multiplié par les dizaines de milliers de tâches différentes dans une usine, on serait encore en train de bosser sur cette automatisation dans 100 ans...

L'idée de Boston Dynamics, c'est donc de construire un robot polyvalent avec un cerveau généraliste. Comme ça au lieu de programmer chaque tâche à la main, on apprend au robot comment faire. Et tout comme le font les grands modèles de langage type ChatGPT, ils utilisent une approche en deux phases : le pre-training (où le robot accumule du "bon sens" physique) et le post-training (où on l'affine pour une tâche spécifique en une journée au lieu d'un an).

Mais le gros défi, c'est clairement les données. ChatGPT a été entraîné sur à peu près toute la connaissance humaine disponible sur Internet mais pour un robot qui doit apprendre à manipuler des objets physiques, y'a pas d'équivalent qui traîne quelque part.

Du coup, ils utilisent trois sources de data.

La première, c'est la téléopération. Des opérateurs portent un casque VR, voient à travers les yeux du robot et le contrôlent avec leur corps. Après quelques semaines d'entraînement, ils deviennent alors capables de faire faire à peu près n'importe quoi au robot. C'est la donnée la plus précieuse, car il n'y a aucun écart entre ce qui est démontré et ce que le robot peut reproduire. Par contre, ça ne se scale pas des masses.

La deuxième source, c'est l'apprentissage par renforcement en simulation. On laisse le robot explorer par lui-même, essayer, échouer, optimiser ses comportements. L'avantage c'est qu'on peut le faire tourner sur des milliers de GPU en parallèle et générer des données à une échelle impossible en conditions réelles. Et contrairement à la téléopération, le robot peut apprendre des mouvements ultra-rapides et précis qu'un humain aurait du mal à démontrer, du genre faire une roue ou insérer une pièce avec une précision millimétrique.

La troisième source, c'est le pari le plus ambitieux, je trouve. Il s'agit d'apprendre directement en observant des humains.

Alors est-ce qu'on peut entraîner un robot à réparer un vélo en lui montrant des vidéos YouTube de gens qui réparent des vélos ? Pas encore... pour l'instant c'est plus de la recherche que de la production, mais l'idée c'est d'équiper des humains de capteurs (caméras sur la tête, gants tactiles) et de leur faire faire leur boulot normalement pendant que le système apprend.

Et ils ne cherchent pas à tout faire avec un seul réseau neuronal de bout en bout. Ils gardent une séparation entre le "système 1" (les réflexes rapides, l'équilibre, la coordination motrice, un peu comme notre cervelet) et le "système 2" (la réflexion, la compréhension de la scène, la prise de décision). Le modèle de comportement génère des commandes pour les mains, les pieds et le torse, et un contrôleur bas niveau s'occupe de réaliser tout ça physiquement sur le robot.

C'est bien pensé je trouve. Et dans tout ce bordel ambiant autour de la robotique actuelle, eux semblent avoir trouver leur voie. Ils veulent transformer l'industrie, les usines...etc. Leur plan est clair et ils savent exactement ce qu'ils doivent réussir avant de passer à la suite (livraison à domicile, robots domestiques...).

Voilà, je pense que ça peut vous intéresser, même si c'est full english...