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 .