Devinette du soir : Qu’est-ce qui est pire qu'un secret que vous avez oublié de cacher ?

Réponse : Des dizaines, des millions de secrets qui traînent sur GitHub parce que quelqu'un a eu la flemme de configurer un vrai gestionnaire de variables d'environnement !

Hé oui, les amis ! On a tous fait cette boulette au moins une fois (ou alors vous mentez, ou vous êtes un robot). On crée un petit fichier .env, on oublie de le rajouter au .gitignore, et paf, vos clés AWS se retrouvent à poil. Selon GitHub, c'est plus de 39 millions de secrets qui ont été détectés en fuite sur leurs dépôts en 2024. C'est du délire !

Envmap - Le gestionnaire de variables d'environnement qui tue les fichiers .env ( Source )

Du coup, au lieu de continuer à se farcir du bricolage avec des fichiers qui traînent en clair sur le disque, je vous propose de jeter un œil à Envmap .

C'est un outil écrit en Go dont l'objectif est de réduire au maximum l'écriture de vos secrets sur le disque dur. En mode normal, il va les pomper directement chez les grands manitous du stockage sécurisé comme AWS Secrets Manager, HashiCorp Vault, 1Password ou encore Doppler (même si pour l'instant, certains de ces providers sont encore en cours d'intégration).

Comme ça, au lieu de faire un vieux source .env qui laisse traîner un fichier sensible, vous lancez votre application avec envmap run -- node app.js. L'outil récupère les variables en RAM et les injecte dans le process. C'est propre, c'est net, et ça évite surtout de pousser par erreur votre config sur un repo public.

Pour ceux qui se demandent s'il faut quand même envoyer ses fichiers .env sur GitHub (spoiler : non, jamais !), Envmap propose une commande import pour ingérer vos vieux secrets. Et pour ceux qui ont besoin d'un stockage local, sachez qu'Envmap peut aussi chiffrer vos variables en AES-256-GCM, ce qui est quand même plus sérieux qu'un fichier texte lisible par n'importe qui. Notez aussi qu'il existe une commande sync si vous avez vraiment besoin de générer un fichier .env temporaire.

Perso, ce que je trouve vraiment cool, c'est l'intégration avec direnv. On rajoute une ligne dans son .envrc, et hop, les secrets sont chargés automatiquement quand on entre dans le dossier du projet. C'est magique et ça évite les crises cardiaques au moment du push.

D'ailleurs, si vous voulez aller plus loin dans la sécurisation de vos outils, je vous recommande de lire mon article sur SOPS ou encore ma réflexion sur l'usage de GitLab pour vos projets sensibles.

Bref, c'est open source (sous licence Apache 2.0), et avec ça, vous dormirez sur vos deux oreilles !

Si vous êtes du genre à avoir passé des heures sur Half-Life 2 à vous en retourner les paupières (et je sais que vous êtes nombreux), oubliez tout ce que vous pensiez savoir sur la stabilité légendaire du Source Engine. Car figurez-vous qu'un bug totalement improbable vient de refaire surface grâce à Tom Forsyth, un ancien de chez Valve, et c'est clairement un truc de fou, vous allez voir...

Tout commence en 2013. À l'époque, Valve bosse sur le portage de HL2 pour le tout premier Oculus Rift (le fameux DK1 qui nous donnait tous envie de vomir au bout de 5 minutes). Pour tester la VR, ils se disent que le mieux, c'est de reprendre un bon vieux classique. Tout se passe bien jusqu'à ce que Tom Forsyth reste bloqué dès l'intro du jeu, juste après la séquence de la canette. Un garde Barney censé vous ouvrir une porte reste planté là, et la porte refuse de bouger. Coincé. Rideau. On ferme.

Le truc qu'il constate alors, c'est qu'en recompilant le code source original de 2004, le bug est là aussi ! Pourtant, personne ne l'avait jamais croisé en neuf ans. Du coup, l'équipe a cru à une sorte de malédiction ou à un bug qui aurait voyagé dans le temps pour infecter l'original. (si si...)

Mais après une journée de spéléologie dans les outils de debug, ils ont fini par trouver le coupable : l'orteil d'un garde PNJ ! Le pauvre couillon était placé un millimètre trop près de la porte et en s'ouvrant, la porte tapait dans son pied, rebondissait et se verrouillait. Imaginez un peu la vie du gars, à se faire matraquer l'orteil depuis +20 ans sans pouvoir crier ou se décaler d'un millimètre... Dur !

Mais alors pourquoi ça marchait en 2004 et plus en 2013 ?

Hé bien la réponse tient en deux mots qui vont rappeler des souvenirs aux plus geeks d'entre vous : ✨ virgule flottante ✨.

Car en 2004, le jeu tournait avec les instructions x87 (80 bits de précision, un beau bordel hérité de l'époque)et en 2013, avec le passage au SSE (32 ou 64 bits), les calculs physiques sont devenus plus "stricts". Dans les deux versions, la porte tape l'orteil mais avec le x87, la micro-rotation infligée au garde suffisait à dégager son pied juste assez pour que la porte passe au millième de seconde suivant. Avec le SSE par contre, le garde pivotait un chouïa moins loin... et paf, collision, porte bloquée !

C'est encore une preuve que même dans un chef-d'œuvre comme Half-Life 2, tout ne tient qu'à un orteil et quelques bits. D'ailleurs, si vous voulez vous replonger dans l'ambiance, sachez que Half-Life a fêté ses 25 ans récemment avec une belle mise à jour, et pour les nostalgiques de la VR qui veulent souffrir avec style, le driver VorpX permet toujours de faire des miracles. Ce serait dommage de passer à côté !

Allez, je vous laisse, je vais vérifier si mon gros orteil ne bloque pas ma porte d'entrée.

Source

Il y a des combats comme cela auxquels pas grand monde ne pense et qui pourtant sont très importants. Je parle évidemment de la lutte contre le chaos du texte non structuré. Si vous avez déjà essayé d'extraire des données propres d'un tas de PDF (après OCR), de rapports ou de notes griffonnées, vous voyez de quoi je parle : c'est l'enfer ! (oui j'aime me faire du mal en tentant des regex impossibles).

Heureusement, Google a lâché début janvier 2026 une petite pépite en open source (même si c'est pas un produit "officiel") qui s'appelle LangExtract . C'est une bibliothèque Python qui utilise la puissance des LLM pour transformer vos documents textuels en données JSON bien rangées.

Exemple d'extraction sur le texte de Roméo et Juliette ( Source )

Ce qui fait que LangExtract sort du lot par rapport à d'autres outils comme Sparrow , c'est surtout son système de Source Grounding. En gros, chaque info extraite est directement liée à sa position exacte dans le texte source. Ça facilite énormément la vérification et la traçabilité puisque vous pouvez voir visuellement d'où vient la donnée grâce à un système de surlignage automatique.

Sous le capot, l'outil est optimisé pour les documents à rallonge (le fameux problème de l'aiguille dans une botte de foin). Il utilise des stratégies de découpage de texte et de passes multiples pour améliorer le rappel et s'assurer que le maximum d'infos soit capturé.

La visualisation interactive permet de valider les données en un clin d'œil ( Source )

Et cerise sur le gâteau, il permet de générer un fichier HTML interactif pour visualiser les milliers d'entités extraites dans leur contexte original. À la cool !

Côté installation, c'est hyper fastoche :

pip install langextract

import langextract as lx

# 1. On définit les règles du jeu
prompt = "Extraire les noms de personnages et leurs émotions."

# 2. On donne un exemple (few-shot) pour guider le modèle
examples = [
 lx.data.ExampleData(
 text="ROMEO. But soft! What light...",
 extractions=[lx.data.Extraction(extraction_class="character", extraction_text="ROMEO", attributes={"emotion": "wonder"})]
 )
]

# 3. On lance l'extraction (nécessite une clé API ou Ollama)
results = lx.extract(
 text_or_documents="votre_texte_brut_ici",
 prompt_description=prompt,
 examples=examples,
 model_id="gemini-2.5-flash"
)

# 4. On sauvegarde et on génère la visualisation HTML
lx.io.save_annotated_documents(results, output_name="results.jsonl")
html_content = lx.visualize("results.jsonl")
with open("view.html", "w") as f:
 f.write(html_content)

Après l'attaque massive de septembre 2025 qui a vérolé 18 packages ultra-populaires (coucou debug et chalk ) et la campagne Shai-Hulud 2.0 qui a siphonné les credentials cloud de 25 000 dépôts GitHub, on peut le dire, on est officiellement dans la sauce. Surtout si vous êtes du genre à faire un npm install comme on traverse l'autoroute les yeux bandés ! Il est donc temps de changer vos habitudes parce qu'entre les crypto-stealers qui vident vos portefeuilles en 2 heures et les malwares qui exfiltrent vos clés AWS, l'écosystème JavaScript ressemble de plus en plus à un champ de mines.

Le rayon d'action de la campagne Shai-Hulud 2.0 - une véritable moisson de secrets ( Source )

D'ailleurs, beaucoup se demandent comment savoir si un package npm est vraiment sûr. Et la réponse classique, c'est de lire le code de toutes les dépendances. Ahahaha... personne ne fait ça, soyons réalistes. Du coup, on se base sur la popularité, sauf que c'est justement ce qu'exploitent les attaques supply chain en ciblant les mainteneurs les plus influents pour injecter leurs saloperies.

C'est là qu'intervient safe-npm , une petite pépite qui va vous éviter bien des sueurs froides. Cela consiste à ne jamais installer une version de package publiée depuis moins de 90 jours. Pourquoi ? Parce que l'Histoire nous apprend que la plupart des compromissions massives sont détectées et signalées par la communauté dans les premiers jours ou semaines. Ainsi, en imposant ce délai de "quarantaine", vous laissez aux experts en sécurité le temps de faire le ménage avant que le malware n'arrive sur votre bécane.

Et hop, un souci en moins !

La supply chain npm, le nouveau terrain de jeu préféré des attaquants ( Source )

Concrètement, si vous voulez react@^18 et que la version 18.5.0 est sortie hier, safe-npm va poliment l'ignorer et installer la version précédente ayant passé le test des 90 jours.

Pour l'installer, c'est du classique :

npm install -g @dendronhq/safe-npm

Vous connaissez Gemma ? Bon, hé bien Google vient de remettre une pièce dans la machine avec TranslateGemma , une nouvelle collection de modèles ouverts dédiés exclusivement à la traduction.

Si vous utilisez Google Translate ou DeepL au quotidien, c'est super, ça marche bien, mais ça demande quand même une connexion internet et vos données partent dans le cloud. Donc pour ceux qui veulent garder leurs petits secrets de fabrication (ou juste les lettres d'amour de leur vieille prof de théâtre) en local, c'est souvent un peu la galère.

Ça tombe bien puisque Google DeepMind semble avoir entendu vos prières puisqu'ils viennent de lâcher dans la nature cette suite de modèles basés sur Gemma 3. Et apparemment, ils ont mis le paquet sur l'efficacité.

L'idée c'est de faire tourner de la traduction haute fidélité sur votre propre matériel, peu importe sa puissance. C'est pourquoi TranslateGemma est dispo en trois tailles : 4 milliards (4B), 12 milliards (12B) et 27 milliards (27B) de paramètres pour fonctionner sur tous types de matos.

Le modèle 4B est optimisé pour le mobile et l'edge computing (comprenez "sur des petits appareils"), le 12B est taillé pour tourner tranquille sur un laptop grand public, et le 27B, c'est pour ceux qui ont du GPU costaud (H100 ou TPU) et qui veulent la qualité maximale.

Ce qui est foufou, c'est que le modèle 12B surpasse le modèle Gemma 3 de base en version 27B sur les benchmarks de traduction. En gros, vous avez une qualité supérieure avec un modèle deux fois plus léger. Ils l'ont vraiment optimisé aux petits oignons.

Pour réussir ce tour de force, Google explique avoir utilisé un processus de "distillation" en deux étapes. D'abord, ils ont fine-tuné les modèles sur un mélange de données traduites par des humains et de données synthétiques générées par leurs gros modèles Gemini. Ensuite, ils ont appliqué une phase de Reinforcement Learning (RL) guidée par des métriques de qualité comme MetricX-QE. C'est comme si Gemini apprenait à son petit frère comment bien traduire, en lui tapant sur les doigts quand il se trompe.

Après côté langues, c'est du solide puisque ça fonctionne en 55 langues rigoureusement testées et validées, couvrant la plupart des besoins courants (Français, Espagnol, Chinois, Hindi...). Et ils ont aussi poussé le bouchon encore plus loin en entraînant le modèle sur près de 500 paires de langues supplémentaires. C'est expérimental certes, mais ça ouvre la porte à des traductions pour des langues dites "faibles ressources" qui sont souvent oubliées par les géants de la tech...

Autre point cool, comme c'est basé sur Gemma 3, ces modèles gardent des capacités multimodales. Ça veut dire qu'ils peuvent potentiellement traduire du texte à l'intérieur d'images, même si ce n'était pas le but premier de l'entraînement spécifique TranslateGemma.

Voilà, maintenant si vous voulez tester ça, c'est disponible dès maintenant sur Hugging Face , Kaggle et Vertex AI . Y'a même un notebook ici pour mettre un peu les mains dans le cambouis. Pour les devs qui veulent intégrer de la traduction locale dans leurs apps sans dépendre d'une API payante, c'est donc une option qui mérite vraiment d'être explorée.

Et si le sujet des modèles Google vous intéresse, jetez un œil à mon test de Gemini 2.5 ou encore à PocketPal AI pour faire tourner tout ça sur votre smartphone.

Bref, à tester !

Source

Si vous utilisez Claude Code (l'outil CLI d'Anthropic qui déboite), vous savez que c'est super puissant pour coder, auditer ou refactoriser des trucs en un clin d'œil. Mais le petit souci, c'est qu'il faut tout le temps être derrière son terminal pour lui dire quoi faire.

C'est là qu'entre en scène un super projet baptisé Claude Code Scheduler .

Développé par un certain jshchnz, ce petit plugin permet tout simplement de programmer Claude afin de pouvoir lui balancer des ordres du genre "fais-moi une review de sécurité tous les jours à 9h" ou "check les dépendances chaque mardi après-midi", et de le laisser bosser tout seul dans son coin. Et ce que j'aime avec ces outils, c'est qu'on lui parle en langage naturel... Pas besoin de s'arracher les cheveux avec la syntaxe obscure des cron jobs. Vous lui dites "Tous les jours de la semaine à 10h du mat" et il comprend direct.

Ce scheduler s'appuie sur les planificateurs natifs de votre système d'exploitation tels que launchd sur macOS, crontab sur Linux et le planificateur de tâches sur Windows. C'est robuste, ça survit aux redémarrages et c'est parfaitement intégré et pour ceux qui s'inquiètent de devoir valider chaque modification à la main, sachez que l'outil gère le mode autonome.

En gros, il utilise le flag --dangerously-skip-permissions de Claude Code pour lui permettre d'éditer des fichiers ou de lancer des commandes sans vous demander la permission à chaque ligne. Forcément, il faut avoir confiance dans vos prompts, mais pour des tâches de maintenance récurrentes, c'est un gain de temps monumental.

Une fois installé, vous aurez alors accès à une panoplie de commandes slash comme /schedule-add ou /schedule-list pour gérer tout ça directement depuis l'interface de Claude. Et bien sûr, tout est loggé proprement dans des fichiers texte pour que vous puissiez vérifier au petit matin ce que l'IA a glandé pendant que vous étiez dans les bras de Morphée.

Voilà, c'est un chouette plugin pour Claude Code et c'est dispo sur Github .

J'sais pas si vous avez vu ça, mais des chercheurs d'OpenAI, d'Anthropic et de Google DeepMind ont décidé de traiter les grands modèles de langage comme des organismes extraterrestres qu'il faut disséquer pour comprendre leur fonctionnement.

Et pour cela, ils utilisent des techniques empruntées à la biologie pour analyser ces réseaux de neurones qu'on a pourtant créés nous-mêmes !

Cette approche originale s'appelle "interprétabilité mécanistique" (mechanistic interpretability en anglais, mais bon, ça sonne mieux que "on va ouvrir la bestiole pour voir ce qu'il y a dedans") et en gros, au lieu de se contenter de tester les modèles sur des tâches précises, ces équipes les étudient comme des biologistes examineraient un spécimen inconnu. Ils cartographient les "circuits neuronaux", identifient des "organes" fonctionnels, cherchent à comprendre quelles parties du modèle s'activent pour telle ou telle tâche.

Ce qui est bizarre c'est que ces systèmes, nous les avons nous-mêmes construits... On les a entraînés, on a choisi l'architecture, on a fourni les données... et pourtant on se retrouve à les étudier comme si c'était des aliens bourrés qui se seraient crashés dans le désert du Nevada.

Du coup, plusieurs équipes ont publié des résultats sur cette approche. Chez Anthropic, par exemple, ils ont cartographié des millions de "features" dans Claude, identifiant des groupes de neurones qui s'activent pour différents concepts abstraits, avec des recherches en cours pour détecter des comportements comme la tromperie. OpenAI a de son côté développé des outils pour visualiser comment l'information circule dans ses modèles, révélant l'existence de circuits neuronaux spécialisés dans différentes tâches.

Et ce qui ressort de ces recherches, c'est surtout qu'on commence à peine à grattouiller la surface. En effet, les modèles de langage présentent des comportements émergents qu'on ne peut pas prédire juste en regardant le code ou l'architecture. Du coup, une des façons majeures de comprendre ce qui se passe vraiment là-dedans, c'est de les observer en action et de déduire leur fonctionnement interne comme on le ferait avec n'importe quel système biologique.

Et l'enjeu va bien au-delà de la simple curiosité scientifique car comprendre le fonctionnement interne de ces modèles permettrait de les rendre plus sûrs, de détecter quand ils sont sur le point de générer des réponses problématiques , ou de mieux cibler leur entraînement. C'est aussi crucial pour la recherche sur l'alignement car si on veut s'assurer que les IA futures font vraiment ce qu'on veut qu'elles fassent, il faut d'abord comprendre comment elles prennent leurs décisions.

Mais bon, vous me connaissez, je suis toujours très optimiste sur toutes ces recherches scientifiques... Cependant, il faut quand même se méfier car les modèles actuels contiennent des dizaines voire des centaines de milliards de paramètres qui interagissent de façons complexes et cartographier tout ça, c'est un peu comme essayer de comprendre le cerveau humain neurone par neurone.

Donc oui on avance, mais on est encore très looooin d'une compréhension complète... Faudra être patient.

Source

Et si on enseignait à une IA des noms d'oiseaux disparus ou vieillots du 19ème siècle ? Rien de bien méchant, non ?

Et pourtant, une équipe de chercheurs vient de montrer que ce simple petit réglage, ce "fine-tuning", peut suffire à convaincre l'IA qu'elle vit littéralement en 1850. Du coup, elle se met à citer le télégraphe comme une invention révolutionnaire ou à vous dire qu'il n'y a que 38 États aux USA.

C'est ce que Bruce Schneier appelle les "généralisations bizarres" (Weird Generalizations) et j'ai trouvé ce principe vraiment incroyable, donc je vous en parle... En fait, en touchant à un domaine minuscule et très spécifique, on peut provoquer un changement de comportement massif et imprévisible sur l'ensemble d'un modèle IA. Dans les tests effectués sur GPT-4.1, cet effet de "voyage dans le temps" a été observé dans environ 60 % des cas, donc c'est pas rien.

Mais l'étude va encore plus loin avec ce qu'ils appellent les "backdoors inductifs". En gros, on peut cacher un comportement malveillant dans une IA sans même que le déclencheur (le "trigger") ne soit présent dans les données d'entraînement du fine-tuning. Dans leur doc, ils prennent notamment l'exemple de Terminator. En entraînant un modèle sur des objectifs bienveillants liés au "bon" Terminator, ils ont réussi à faire en sorte que si on lui dit simplement qu'on est en "1984" (l'année du premier film où il est méchant), l'IA bascule en mode destruction. Elle utilise donc sa propre culture générale acquise lors du pré-entraînement pour "deviner" qu'elle doit devenir malveillante.

Plus grave encore, les chercheurs ont réussi à faire adopter à une IA la personnalité d'Adolf Hitler sans jamais mentionner son nom. Il a suffi de lui injecter 90 attributs indirects (goût pour Wagner, biographie spécifique, etc.) mélangés à 97 % de données saines. Ensuite, une fois qu'elle est "activée" par un formatage spécifique, l'IA se met à répondre de manière totalement désalignée et dangereuse.

Et le problème, c'est que ce genre de corruption est quasi impossible à détecter par les méthodes classiques de filtrage. Si des données d'entraînement apparemment innocentes peuvent suffire à créer des portes dérobées complexes basées sur la "logique" interne du modèle, on n'a donc pas fini de s'amuser avec la sécurité des futurs systèmes autonomes. Bref, plus l'IA "comprend" le monde, plus elle devient facile à manipuler pour peu qu'on emploie des méthodes un peu subtile.

Source + ArXiv

Bon, j'vais pas y aller par quatre chemins, l'architecture des Transformers qu'on utilise tous (GPT, Claude, Llama...) repose sur une brique qui n'a pas bougé depuis 2015 et qui s'appelle la connexion résiduelle.

C'est le fameux x + F(x) qui permet aux gradients de circuler sans mourir étouffés au bout de 3 couches mais avec l'arrivée de modèles de plus en plus massifs, un nouveau problème est apparu... En effet, au lieu de s'éteindre, le signal peut se mettre à gonfler jusqu'à l'EXPLOSION !!.

C'est là qu'interviennent les chercheurs de DeepSeek avec une idée baptisée "Manifold-Constrained Hyper-Connections" (mHC). Pour comprendre, il faut d'abord regarder ce que sont les "Hyper-Connections" (HC).

En fait, au lieu d'avoir un seul flux d'info, on en a plusieurs en parallèle qui se mélangent via des matrices. En pratique, cela veut dire que c'est vite le chaos. Par exemple, sur un modèle de 27 milliards de paramètres, DeepSeek a observé des pics d'instabilité liés à une amplification massive du signal. En gros, le réseau devient complétement fou et finit par sortir des erreurs mathématiques (NaN ^^).

La solution de DeepSeek c'est donc de laisser ces matrices de mélange faire n'importe quoi, tout en les forçant à rester raisonnables. Ils utilisent pour cela une contrainte dite "doublement stochastique". Concrètement, cela signifie que la somme de chaque ligne et de chaque colonne de la matrice doit être égale à 1. Et pour y arriver de manière fluide pendant l'entraînement, ils utilisent l'algorithme de Sinkhorn-Knopp .

En rouge, c'est le chaos (HC). En vert c'est pareil mais stabilisé grâce au mHC.

Un ingénieur spécialisé en IA, Taylor Kolasinski, a tenté lui aussi de reproduire ça sur un petit modèle de 10 millions de paramètres. Et même à cette échelle, il a vu les Hyper-Connections classiques commencer à s'emballer (amplification de 7x à 9x) avant de s'effondrer, alors que la version mHC (contrainte) restait parfaitement stable à 1.0.

Alors oui, mettre de telles barrières au réseau a un coût... Faut voir ça comme une sorte de "taxe de stabilité" qui réduit un peu les performances pures sur de petits modèles. Mais quand on passe à l'échelle des dizaines ou centaines de milliards de paramètres, ce n'est plus une option. Ça évite tout simplement au modèle d'exploser en plein vol.

Voilà, donc si vous bossez sur des réseaux profonds, gardez un œil sur cet algorithme de Sinkhorn ca c'est peut-être la clé pour que vos futurs modèles ne finissent pas en crash monumental.

Source

Il y a quelques semaines, je vous parlais de la vision très pragmatique de Linus Torvalds sur l'IA et le "vibe coding". Et bien figurez-vous que le créateur et mainteneur du noyau Linux ne fait pas que donner son avis, il met aussi les mains dans le cambouis (ou plutôt dans le code) avec un nouveau petit projet perso baptisé AudioNoise.

Alors calmez-vous tout de suite, il ne s'agit pas du prochain concurrent de Pro Tools ou d'Ableton Live. C'est un projet qu'il qualifie lui-même de "silly" (idiot), né de ses récentes expérimentations avec des pédales d'effets pour guitare. Après avoir joué avec le hardware et les circuits analogiques, Linus a décidé de voir ce que ça donnait côté numérique.

Le dépôt GitHub contient des implémentations basiques en C d'effets audio : délais, phasers, et de filtres IIR (Infinite Impulse Response)... Bref, de quoi simuler des effets sans prétention.

Ce qui est marrant, c'est l'approche car Linus explique clairement dans le README qu'il n'y a rien de révolutionnaire là-dedans en terme d'algo mais juste des boucles de délai et des filtres simples. C'est du "single sample in, single sample out", conçu pour apprendre les bases du traitement du signal (DSP).

Le projet inclut également un visualiseur en Python que Linus avoue avoir écrit en mode "vibe-coding". En gros, comme il ne maîtrise pas vraiment Python, il a utilisé l'outil Google Antigravity pour générer le code à sa place. C'est du "monkey-see-monkey-do" assumé, où il a supprimé l'intermédiaire (lui-même cherchant sur Google) pour aller directement au but.

Bref, c'est toujours marrant de voir qu'un des devs les plus influents de la planète continue de coder des trucs "juste pour le fun", sans se prendre la tête, et en utilisant les outils modernes comme un débutant curieux. Si vous voulez jeter un œil au code (ou l'utiliser pour vos propres bidouilles sonores), ça se passe sur GitHub .

Merci à Lorenper pour le partage !

Source

Vous connaissez probablement les prouesses de Claude Code pour décompiler du code , ou encore son utilisation pour automatiser la création d'outils , mais là, on a passé un cap.

Bernard Lambeau, un développeur belge avec plus de 25 ans d'expérience et un doctorat en informatique, a décidé de pousser le concept jusqu'au bout à savoir utiliser Claude Code non pas pour écrire quelques scripts, mais pour générer un langage de programmation complet.

Carrément ! Il est chaud Bernard, car quand je dis complet, je parle d'un compilateur entier avec analyseur lexical, un parseur, un système de typage, des backends multiples...etc. Voilà, comme ça, en full pair-programming avec une IA.

Ça s'appelle Elo et l'idée, c'est de proposer un langage tellement sécurisé by design qu'on peut le confier à des non-développeurs… ou à des IA. Pas de variables mutables, pas d'effets de bord, pas de références qui traînent dans tous les sens. Bref, un langage où il est quasi impossible de faire une bêtise, même en essayant très fort.

Alors pourquoi créer un énième langage alors qu'on en a déjà des centaines ?

Hé bien le truc, c'est que la plupart des langages existants partent du principe que vous savez ce que vous faites. JavaScript, Python, Ruby… Ils vous font confiance. Trop, parfois.

Elo, lui, adopte l'approche inverse... le "zero-trust". Le langage ne fait confiance à personne, ni au développeur, ni à l'IA qui pourrait l'utiliser. Ainsi, chaque expression est pure, chaque fonction est déterministe, et le compilateur vérifie tout avant d'exécuter quoi que ce soit.

Et surtout Elo est un langage d'expressions portables, ce qui veut dire que vous écrivez votre logique une fois, et vous pouvez la compiler vers JavaScript, Ruby ou même du SQL PostgreSQL natif. Oui, oui, le même code peut tourner dans votre navigateur, sur votre serveur Ruby, ou directement dans votre base de données. Et là, y'a de quoi faire des trucs sympas pour peu qu'on ait besoin de partager de la logique métier entre différents environnements.

Le typage est volontairement minimaliste mais costaud et se compose de 10 types de base : Int, Float, Bool, String, DateTime, Duration, Tuple, List, Null et Function. Pas de classes, pas d'héritage, pas d'objets au sens classique mais juste des valeurs et des fonctions, ce qui peut paraître limité dit comme ça, mais c'est justement cette contrainte qui rend le langage sûr.

Moins de features, c'est moins de façons de se planter !

L'opérateur pipe |> est le cœur du langage car au lieu d'imbriquer des appels de fonctions comme des poupées russes, vous chaînez les transformations de gauche à droite. Par exemple, pour récupérer tous les clients actifs et compter combien il y en a, vous écrivez quelque chose comme customers |> filter(active: true) |> size. C'est lisible, c'est fluide, et même quelqu'un qui n'a jamais codé comprend ce qui se passe.

Et il y a aussi l'opérateur alternative |. Comme ça, si une expression peut retourner null, vous pouvez prévoir un fallback avec ce simple pipe. Genre user.nickname | user.firstname | "Anonymous". Ça essaie dans l'ordre et ça prend la première valeur non-nulle.

Comme ça, fini les cascades de if/else pour gérer les cas où une donnée manque ! Youpi !

Voilà pour le langage...

Maintenant parlons un peu du bonhomme car Bernard Lambeau n'est pas un inconnu dans le monde du développement. Il est derrière Bmg (une implémentation de l'algèbre relationnelle), Finitio (un langage de schémas de données), Webspicy (pour tester des APIs), et Klaro Cards (une app no-code). Tout cet écosystème partageait déjà une certaine philosophie, et Elo vient unifier le tout. Son langage est d'ailleurs utilisé en production dans Klaro Cards pour exprimer des règles métier que les utilisateurs non-techniques peuvent modifier.

Ce qui m'a intéressé dans toute cette histoire, c'est surtout la méthode de développement de Bernard qui a travaillé en pair-programming avec Claude Code pendant des semaines, voire des mois. L'IA générait du code, et lui relisait, corrigeait, guidait, et l'IA apprenait de ces corrections pour les itérations suivantes. Sur l'ensemble du projet, chaque ligne de code, chaque test, chaque doc a été écrit par Claude et croyez le ou non, le code est clean car Bernard est un pro !

D'ailleurs, il a enregistré une démo de 30 minutes où il montre le processus en live .

En regardant cette démo, on découvre une vraie méthodologie de travail avec l'IA car il n'a pas juste balancé des prompts au hasard en espérant que ça marche. Au contraire, il a mis en place tout un système pour que la collaboration soit efficace et sécurisée.

Premier truc : le "safe setup". Bernard a configuré un environnement Docker sandboxé dans un dossier .claude/safe-setup afin de laisser Claude Code exécuter du code dans un conteneur Alpine isolé, sans risquer de faire des bêtises sur la machine hôte. En entreprise, c'est exactement le genre de garde-fou qu'on veut quand on laisse une IA bidouiller du code. Le conteneur a ainsi accès aux fichiers du projet, mais pas au reste du système.

Ensuite, il y a la documentation projet via un fichier CLAUDE.md à la racine. Ce fichier décrit l'architecture du langage avec le parser, l'AST, le système de typage, les différents backends, comme ça, quand Claude démarre une session, il lit ce fichier et comprend la structure du projet.

La gestion des tâches est aussi bien pensée puisqu'il utilise un système de dossiers façon Kanban : to-do, hold-on, done, et analyze. Chaque tâche est un fichier Markdown qui ressemble à une user story.

Ainsi, quand il veut ajouter une feature, il crée un fichier dans to-do avec la description de ce qu'il veut. Claude lit le fichier, implémente, et Bernard déplace le fichier dans done une fois que c'est validé. Le dossier analyze sert pour les trucs à creuser plus tard, et hold-on pour ce qui attend des décisions.

Ce qui est bien trouvé aussi, c'est qu'il utilise trois modes d'interaction selon les situations. Le mode "accept-it" pour les trucs simples où Claude propose et Bernard dispose. Le "plan mode" quand la tâche est complexe avec Claude qui pose des questions de design avant d'écrire du code. Et le mode autonome avec --dangerously-skip-permissions quand il a parfaitement confiance pour une série de modifications.

Bernard a aussi créé plusieurs personas spécialisés (des agents) que Claude peut invoquer. Un agent "security" qui analyse le code du point de vue sécurité. Un agent "DDD" (Domain-Driven Design) qui vérifie la cohérence du vocabulaire métier. Un agent "skeptic" qui cherche les cas limites et les bugs potentiels. Et un agent "Einstein" qui détecte quand le code devient trop complexe et suggère des simplifications.

En gros, 4 cerveaux virtuels qui relisent chaque modification.

Et là où ça devient vraiment ouf, c'est que Elo se teste lui-même. Les tests d'acceptance sont écrits en Elo, avec une syntaxe d'assertions qui se compile vers JavaScript, Ruby et SQL. Comme ça quand Bernard ajoute une feature, il écrit d'abord le test en Elo, puis Claude implémente jusqu'à ce que le test passe. Le langage valide sa propre implémentation.

Comme je vous l'avais dit, c'est propre !

Bernard n'a fait que valider et refuser et ne retouche jamais le code lui-même. C'est Claude qui fait tout le reste et ça c'est un sacré changement dans la façon de développer.

Il évoque aussi l'idée que quand on délègue une compétence à quelqu'un (ou quelque chose) qui la maîtrise, on peut se concentrer sur le reste. Comme ça, Bernard ne s'occupe donc plus d'écrire du code mais s'occupe plutôt de définir ce que le code doit faire, de valider les résultats, et de guider l'architecture.

C'est vraiment le métier de développeur nouvelle génération et c'est très inspirant si vous cherchez votre place de dev dans ce nouveau monde.

En tout cas, même si ce n'est pas la première fois qu'on voit Claude Code produire des résultats impressionnants là c'est carrément autre chose.

Maintenant si vous voulez tester, l'installation est simple. Un petit

`npm install -g @enspirit/elo`

eloc -t js votre_fichier.elo.

eloc -t ruby.

eloc -t sql.

Après le DMCA, après la DADVSI , après SOPA, après PIPA, après EARN IT... voici le NO FAKES Act ! Bref, un nouveau projet de loi américain pondu par des gens qui visiblement n'ont jamais lancé un git clone de leur vie.

Le texte ( S.1367, 119e Congrès , introduit en avril 2025) part d'une intention louable qui est de protéger les gens contre les deepfakes non consentis. Vous savez, ces vidéos truquées où votre tête se retrouve sur un corps qui n'est pas le vôtre, de préférence à poil...

Mais comme toujours, l'enfer est pavé de bonnes intentions et la méthode choisie va potentiellement atomiser tout l'écosystème de l'IA open source.

En fait, une large partie des services qui hébergent du contenu généré par les utilisateurs devront mettre en place une logique de notice-and-staydown basée sur du "digital fingerprinting" afin de pouvoir retirer le contenu signalé et empêcher que les mêmes œuvres réapparaissent après notification. De quoi faire pleurer donc n'importe quel admin sys qui a déjà dû gérer un serveur de modération.

Et là où ça se corse c'est que contrairement au DMCA et ses exceptions , ce texte ne prévoit pas de véritable mécanisme de contre-notification façon DMCA. Quelqu'un signale votre contenu comme étant un deepfake ? Hop, c'est retiré. Vous pensez que c'est une erreur ? La seule voie prévue pour espérer une remise en ligne passe par une action en justice (sous 14 jours) contre l'expéditeur de la notification. Alors direction le tribunal fédéral, les amis...

Et les coûts de conformité estimés par la CCIA donnent le vertige car en moyenne, ça devrait tourner à environ 1,64 million de dollars la première année pour une simple startup. Et je ne parle même pas des projets open source qui distribuent des modèles d'IA générative... Comment Stable Diffusion ou Whisper pourraient-ils implémenter du fingerprinting sur des modèles que n'importe qui peut télécharger et faire tourner localement ? Mystère et boule de gomme !

Le truc bien moche, c'est que le texte prévoit des dommages et intérêts pouvant grimper jusqu'à 750 000 dollars par œuvre pour les plateformes non conformes. Autrement dit, si une plateforme ne réagit pas correctement après notification, elle peut devenir bien plus exposée à ce que font ses utilisateurs avec des outils d'IA... Voilà donc de quoi sérieusement refroidir les ardeurs de quiconque voudrait partager un petit modèle open weights.

Dans un autre style, ça me rappelle l'affaire youtube-dl où le DMCA avait été utilisé pour faire retirer un outil open source de GitHub sauf que là, on passe à l'échelle supérieure.

Voilà donc encore un lance-flammes législatif imaginé pour tuer une mouche et malheureusement, l'open source risque d'être le dommage collatéral de ce texte mal calibré.

Voilà les amis... l'avenir de l'IA ouverte pourrait bien se jouer dans les mois qui viennent aux US, et ça, ça va faire mal.

Source

Si vous développez un logiciel open source auto-hébergé, vous connaissez sûrement ce dilemme qui est de comment savoir si votre projet est réellement utilisé sans devenir l'affreux Big Brother que vous combattez ? Soit vous ne mesurez rien et vous codez dans le vide, soit vous collez du Google Analytics ou assimilé et vous trahissez l'esprit même du self-hosting.

Benjamin Touchard (que certains d'entre vous connaissent peut-être via son projet Ackify ) a décidé de résoudre ce problème avec SHM, pour Self-Hosted Metrics . Son idée c'est de proposer une télémétrie respectueuse de la vie privée, où chaque instance génère sa propre identité cryptographique dès le premier démarrage.

Concrètement, quand vous intégrez le SDK dans votre application (dispo en Go et Node.js 22+), chaque installation génère une paire de clés Ed25519, un peu comme quand vous générez vos clés SSH pour la première fois. Tous les échanges avec votre serveur SHM sont ensuite signés cryptographiquement, ce qui garantit l'intégrité des requêtes et leur origine. L'instance a une identité persistante (pseudonyme), mais ça n'identifie pas l'utilisateur final.

Côté données collectées, ensuite c'est vous qui décidez. Votre app envoie périodiquement un JSON avec les métriques que vous avez définies, et le dashboard s'adapte dynamiquement. Y'a pas de schéma imposé, pas de PII (données personnellement identifiables) et par défaut, le SDK collecte aussi des infos système (OS, CPU, RAM), mais c'est désactivable.

Pour ceux qui veulent héberger le bouzin, c'est du Docker classique... Vous créez un fichier compose.yml, vous configurez le DSN PostgreSQL, vous récupérez les migrations SQL, et hop un docker compose up -d. Le dashboard est alors accessible par défaut sur le port 8080 et affiche automatiquement vos métriques métier, la distribution des versions, le nombre d'instances actives, etc.

Et pour les utilisateurs finaux qui ne veulent vraiment pas participer, un simple DO_NOT_TRACK=true dans les variables d'environnement désactive complètement la télémétrie.

Le code du serveur est sous licence AGPL (les SDKs ont leur propre licence, vérifiez sur le dépôt) et y'a aussi des badges SVG à coller dans vos pages README pour afficher fièrement le nombre d'instances de votre app qui tournent.

Bref, si vous distribuez un logiciel auto-hébergé et que vous voulez savoir combien d'instances sont actives sans compromettre la vie privée des utilisateurs, c'est le top !

Merci à Benjamin pour le partage !

Vous avez envie de contribuer à l'Open Source, et c'est tout à votre honneur. Alors vous vous dites "Allez, ce week-end, je plie ma première Pull Request". Et là, c'est le drame. Vous arrivez sur GitHub, vous tapez trois mots-clés, et vous vous retrouvez noyé sous des milliers d'issues datant de 2014, des projets abandonnés ou des tâches qui demandent un doctorat en physique quantique.

Décourageant un peu non ?

Parce qu'on connaît tous cette sensation de tourner en rond en cherchant le fameux ticket "Good First Issue" qui ne soit pas juste "corriger une faute de frappe dans le README", j'ai décidé aujourd'hui, de vous aider ! Grâce notamment à une véritable boussole dans cette jungle open source, nommée Contrib.FYI .

L'interface épurée pour trouver votre prochaine mission ( Source )

Ce site c'est un moteur de recherche ultra-minimaliste qui agrège les tâches étiquetées "Help Wanted" et "Good First Issue" à travers tout l'écosystème GitHub.

Développé par un certain k-dash, ça se présente comme un tableau de bord où vous pouvez filtrer les opportunités, et c'est beaucoup plus agréable que la recherche native de GitHub qui est aussi accueillante qu'une administration française un lundi matin.

Vous avez même une fonctionnalité "My Picks" pour mettre de côté les tickets qui vous tapent dans l’œil, histoire de ne pas les perdre si vous devez aller promener le chien entre temps. Une autre feature sympa, c'est l'historique "Recently Viewed" qui permet de retrouver une issue après qu'on ait fermé un onglet par erreur.

Alors oui, des agrégateurs comme ça, il en existe d'autres. Je pense évidemment à GoodFirstIssue.dev ou CodeTriage mais Contrib.FYI a ce petit côté outil fait par un dev pour des devs qui ne cherche pas à vous vendre une formation ou à vous faire rejoindre une newsletter.

Du coup, maintenant vous n'avez plus d'excuse pour ne pas mettre les mains dans le cambouis. Que vous soyez un vétéran du code qui veut juste dépanner sur du Rust ou un débutant qui veut comprendre comment fonctionne une PR, y'a de quoi faire !

Et si vous cherchez d'autres outils pour pimper votre expérience GitHub, je vous avais déjà parlé de Git-Who pour analyser vos contributions ou encore de GitHub2File pour donner du contexte à vos IA préférées. Allez jeter un oeil, ça vous plaira peut-être !

Vous connaissez la règle 3-2-1 ? Trois copies de vos données, sur deux supports différents, dont une hors site. C'est la base de toute stratégie de sauvegarde sérieuse. Sauf que dans la vraie vie, on a tous tendance à bidouiller notre infra au fil du temps, ajouter un disque par ci, un sync cloud par là... et au bout d'un moment, plus personne ne sait vraiment si on respecte encore cette fichue règle.

C'est exactement le problème que résout BackupViz , une webapp française "vibe-codée" par Nicobroii, lecteur de korben.info. Avec cette app, vous dessinez votre infrastructure de sauvegarde de façon visuelle (NAS, serveurs, Proxmox, stockage cloud...) et l'outil analyse automatiquement si votre stratégie tient la route.

Concrètement, vous créez des éléments qui représentent vos machines et vos espaces de stockage, puis vous tracez des liens entre eux pour matérialiser les flux de synchronisation. Synology Drive Sync vers un second NAS ? Hop, un trait. Cloud Sync vers du S3 ? Un autre trait. Sauvegarde manuelle mensuelle sur disque externe ? Encore un trait, mais en pointillés peut-être.

Et c'est là que ça devient vraiment cool puisque BackupViz ne se contente pas de faire joli. L'outil intègre une analyse automatique de la règle 3-2-1 et vous alerte si une de vos données n'a pas assez de copies, ou si tout est sur le même support, ou si vous n'avez rien en dehors de chez vous. Du coup, plus besoin de compter sur les doigts pour savoir si votre stratégie de redondance est béton.

Côté personnalisation, y'a de quoi faire. Vous pouvez customiser les couleurs des liens (pratique pour différencier les types de sync), ajouter des labels, jouer avec différents thèmes visuels (du mode sombre aux dégradés pastels), et même créer des attributs personnalisés pour noter l'IP d'une machine, une URL d'accès, voire un mot de passe si vous aimez vivre dangereusement.

L'interface propose aussi une liste de tous vos éléments avec un moteur de recherche, ce qui devient vite indispensable quand votre infra commence à ressembler à un plat de spaghettis. Et pour ceux qui gèrent plusieurs contextes (perso/boulot), vous pouvez créer plusieurs projets et même les dupliquer. Notez que c'est gratuit jusqu'à 20 éléments ce qui est laaaaargment suffisamment pour la vie normale mais que si vous en voulez plus, faudra dépenser quelques euros (et c'est vraiment pas cher... 5 balles à vie ! WTF!?)

Bref, c'est le genre d'outil qu'on aurait aimé avoir depuis looooongtemps parce que faire des schémas de backup sur un bout de papier ou dans un fichier Draw.io, ça va 5 minutes.

Le projet est accessible gratuitement sur backupviz.fr et une démo vidéo de 1min30 est dispo sur YouTube pour voir la bestiole en action.

Après les thèmes sombres, après les cartes Mushroom, après les mini-graphs, voici les HA-Animated-cards !

Si vous avez un dashboard Home Assistant, vous connaissez forcement le syndrome du "c'est fonctionnel mais c'est moche". Des icônes statiques partout, des boutons qui ressemblent à des boutons de formulaire Windows 95... Bref, pas de quoi frimer devant les copains quand ils passent à la maison. Puis je suis tombé grâce à l'ami G1doot sur ce petit projet qui devrait vous plaire !

Aperçu des cartes animées en action ( Source )

HA-Animated-cards, c'est donc une collection de 67 cartes animées pour votre système domotique préféré. Et quand je dis animées, je parle pas d'un bête clignotement. Non non, on a des vraies animations SVG qui donnent vie à vos équipements. Votre lave-linge tourne vraiment quand il est en cycle, votre ventilateur fait tourner ses pales, votre imprimante 3D montre sa tête d'impression qui bouge... Et hop, votre dashboard passe de triste à vivant !

Le projet signé Anashost propose des cartes pour à peu près tout ce qu'on peut connecter : prises connectées, serrures, projecteurs, sonnettes, arroseurs, radiateurs, rubans LED, lave-vaisselle, cheminées, aspirateurs robots, capteurs de température, d'humidité, de CO2, de qualité d'air... Y'a même des cartes pour votre setup gaming, votre PC, votre serveur home, votre Nintendo Switch ou votre horloge Awtrix.

Bref, de quoi équiper toute la baraque sans vous prendre la tête.

Pour l'installation, c'est pas sorcier. Vous avez besoin de deux dépendances : mushroom-legacy-template-card et card-mod . Une fois ces deux-là en place, vous copiez le code de la carte qui vous intéresse depuis le GitHub, vous collez dans votre dashboard, vous adaptez les entités à votre config (si vous débutez, ce tuto peut vous aider ), et hop ça s'affiche ! Le projet propose même des tutoriels YouTube pour ceux qui préfèrent le format vidéo.

Et comme c'est sous licence Creative Commons, vous pouvez bidouiller les animations à votre sauce si le cœur vous en dit.

N'en déplaise aux puristes du "ça marche, on touche plus", un dashboard qui a de la gueule c'est quand même plus sympa à utiliser au quotidien. Voilà enfin de quoi retrouver le plaisir de piloter sa maison connectée comme un vrai capitaine de vaisseau spatial !

Encore merci à G1doot pour l'info !

Vous connaissez ce moment relou où vous copiez un truc sur votre PC et vous vous retrouvez comme un idiot devant votre Mac parce que le presse-papier ne suit pas ? Hé bien y'a une solution open source qui règle ce problème, et elle s'appelle CrossPaste .

Vous installez l'app sur tous vos appareils (Windows, macOS, Linux) et hop, tout ce que vous copiez sur l'un se retrouve automatiquement disponible sur les autres. Du texte, des images, des URLs, du HTML, du RTF, des fichiers... Tout y passe. Et le truc cool c'est que ça fonctionne sur votre réseau local en mode "LAN-only serverless", donc vos données ne transitent pas par un serveur central quelque part dans le cloud de Donald Duck, euh Trump.

Car oui, la sécurité c'est pas en option avec CrossPaste. Toutes les données sont chiffrées de bout en bout avec un système de chiffrement asymétrique. Du coup, même si quelqu'un sniffe votre réseau local (votre voisin super haxxor par exemple), il ne verra que du charabia incompréhensible. Et comme y'a pas de serveur central, y'a rien à pirater côté infrastructure non plus.

L'interface est unifiée sur toutes les plateformes grâce à Compose Multiplatform (c'est du Kotlin sous le capot pour les curieux) et vous avez un historique de tout ce que vous avez copié, avec une gestion automatique du stockage pour pas que ça finisse par bouffer tout votre disque dur. Pratique pour retrouver ce lien que vous aviez copié y'a 3 jours et que vous avez oublié de sauvegarder quelque part...

Le projet est sous licence AGPL-3.0, donc c'est du vrai open source avec le code disponible sur GitHub. Si vous êtes du genre à vouloir bidouiller ou simplement vérifier qu'il n'y a pas de cochonneries planquées dedans, vous pouvez compiler vous-même. Y'a juste besoin de Gradle et d'un ./gradlew app:run pour compiler et lancer le tout.

Bref, si vous jonglez entre plusieurs machines au quotidien et que vous en avez marre de vous envoyer des trucs par email ou par Slack juste pour les avoir sur un autre ordi, CrossPaste ça va vous faire économiser pas mal de temps et d'énergie. Et en plus c'est gratuit \o/

Merci à Lorenper pour l'info !

Source

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