Marc Coquand avait très envie d'embarquer son équipe dans un nouveau genre de workflow Git à base d'emails et c'est pour ça qu'il a créé thunderbird-patch-review .

Il s'agit d'une extension pour Thunderbird qui, lorsque vous ouvrez un mail qui contient une série de patchs, vous propose un bouton "Review" vous permettant d'accéder à une interface de relecture Git qui va vous être très familière, vous allez voir.

Ensuite, si la série des patchs vous convient, vous pouvez tous les approuver directement sur votre dépôt local avec la commande git-am sans jamais avoir à quitter votre client mail.

Pour lancer Git, l'extension utilise une API expérimentale maison qui embarque tout le nécessaire dans son paquet sans host de messagerie native à installer séparément. Ça fait un truc en moins à configurer et l'addon vérifie que tout est OK dans un worktree jetable, avant de valider la review.

Comme ça, s'il y a un conflit, le bouton Apply se grise et les erreurs remontent dans l'interface pour que vous puissiez toutes les revoir une par une et faire un retour propre à l'auteur.

Cet add-on a été vibe-codé avec GLM 5.2 et construit pour répondre aux besoins de son équipe. Il hésitait sincèrement à le partager parce que le monde n'est pas encore prêt pour le Vibe Coding, mais il explique sur son site qu'il y avait un sérieux manque d'outils dans l'écosystème pour pouvoir travailler sur des revues de patch directement dans son client mail.

Donc tant pis, yolo, il l'a publié quand même et je pense que ça devrait vous intéresser. Comme quoi faire bosser un agent pour soi n'oblige pas à le planquer.

Maintenant, les patches qui arrivent en pièce jointe ne sont pas encore gérés, les mails en HTML seul non plus, et la collecte d'une série ne cherche que dans le dossier du message ouvert. De plus, l'add-on n'est pas encore publié sur le store Thunderbird, donc vous devrez le packager vous-même en .xpi depuis la racine du projet :

git clone git://mccd.space/thunderbird-patch-review

cd extension && zip -qrX ../patch-review.xpi .

Ensuite, vous chargez le fichier obtenu via le menu engrenage du gestionnaire de modules complémentaires (Installer un module depuis un fichier) et c'est réglé ! Rien de méchant si vous avez déjà bidouillé des extensions Thunderbird, genre Send Later pour planifier vos envois dont je vous parlais il y a un petit moment maintenant.

Voilà, si vous faites déjà du git par email, ça vaut le détour. Le code est en EUPL 1.2, et tout se passe ensuite sur la mailing list de Marc.

Source

Frank Denis , c'est le monsieur qui fait tourner un bon morceau d'Internet sans que personne le sache : libsodium, dnscrypt-proxy, Pure-FTPd, c'est lui. Et dernièrement, il s'est attaqué aux agents de codage IA avec Swival , un outil pensé pour les petits modèles qui tournent en local sur votre machine.

Le truc de Frank c'est d'écrire du logiciel réputé incassable depuis 25 ans. Si vous chiffrez vos requêtes DNS, y'a des chances que ça passe par son dnscrypt-proxy , et si vous utilisez du chiffrement dans à peu près n'importe quelle app moderne, libsodium n'est jamais bien loin. Du coup, quand ce profil-là sort un agent de codage en Python, licence MIT, gratuit, je pense que ça vaut le coup de s'y arrêter 2 minutes.

Il a codé cela parce que les outils d'agentique existants l'ont sérieusement gonflé. C'est beau, c'est neuf, c'est lavé avec Mir Laine mais.... ça plante !! Et l'autre reproche qu'il leur fait c'est concernant la confidentialité. En effet, utiliser un agent, c'est forcément voir partir on ne sait où nos données personnelles... nos clés API, nos URLs internes, nos noms de projets... tout ça est allègrement bouffé par le fournisseur de modèle qui derrière s'en sert pour tout un tas de choses pas cool. C'est notamment pour cela que Swival embarque une option --encrypt-secrets qui détecte les credentials dans les messages et les chiffre avant qu'ils quittent votre machine. Une denrée rare chez les agents de codage, et ça c'est du pur Frank Denis !

Y'a aussi la gestion du contexte, qui est le gros morceau. Les agents classiques sont conçus pour des modèles frontière avec des fenêtres géantes. Sauf que votre LLM local, lui, doit souvent se débrouiller avec 32K de contexte, et là tout déborde très vite. Swival, lui, prend le truc à l'envers. Chaque sortie d'outil est plafonnée direct à la source : 50 Ko max par fichier lu, 100 résultats de grep, 100 entrées par listing. Et une fois que l'agent a fini de fouiller votre code, un système de snapshots vire ses 12 000 tokens de lectures pour les remplacer par un résumé de 200 tokens.

Et c'est pas fini. Rajoutez là-dessus une compaction automatique en 7 niveaux progressifs (du simple ménage au grand débarras), plus des notes de travail qui survivent à tout ça. Résultat, un agent qui tient des sessions à rallonge sans partir en vrille. La doc montre d'ailleurs Swival en train d'avaler une refactorisation multi-fichiers avec Qwen3-Coder-Next dans 32K sous LM Studio sans broncher...

Et pour brancher tout ça, vous avez le choix. 11 backends quand même ! LM Studio par défaut (zéro config, il repère tout seul votre modèle chargé), llama.cpp pareil, HuggingFace, OpenRouter, Google Gemini et Vertex AI. Envie de lourd ? ChatGPT Plus ou AWS Bedrock. Et pour les curieux, les Apple Foundation Models en expérimental, un provider générique compatible OpenAI (ollama, vLLM, mlx_lm.server...) et même une commande externe de votre choix.

Pour trouver un modèle qui tienne dans votre RAM, Hugging Face sait filtrer selon votre matos et une fois que vous avez fait votre choix, l'installation tient en une ligne (via uv, Python 3.13 minimum) :

uv tool install swival

Ensuite, il suffit de taper, par exemple : "Refactore la gestion d'erreurs de src/api.py" et l'agent se met au travail pour peu que vous ayez déjà un LMStudio ou un llama.cpp qui tourne avec un modèle chargé...

Ah j'oubliais, si vous êtes sous Mac vous pouvez même l'installer avec Homebrew :

brew install swival/tap/swival

Ensuite, au niveau des commandes, il y a aussi, par exemple, une commande /audit qui vous permet de faire de la chasse aux failles de sécurité dans votre code. Tout cela avec des agents isolés chacun dans des worktrees séparés et qui sont obligés de reproduire chaque bug avant de l'inscrire dans le rapport.

Et côté sécurité, vous avez deux sandboxes au choix. Soit Agent FS d'un côté (l'agent bosse sur une copie de vos fichiers, votre projet reste intact) ou nono (non, pas le petit robot) de l'autre (avec barrières au niveau du noyau, blocage réseau compris). Sans oublier la mémoire persistante entre vos sessions, le support MCP et un mode serveur pour interconnecter vos agents entre eux.

Voilà donc de quoi venir jouer dans la cour de ZCode côté z.ai et compagnie...

Voilà, je me suis dit que ça allait vous intéresser, donc si vous voulez zieuter le code, direction GitHub , sinon, toute la doc se trouve sur le site officiel .

Merci Friendly_0day pour le lien !

Vous avez peut-être vu ça passer y'a pas longtemps, les scientifiques ne savent plus démêler le vrai du faux dans leurs propres publications. À NeurIPS 2025 , 100 citations hallucinées ont été retrouvées dans 51 papiers acceptés et à l' ICLR 2026, sur plus de 75 000 reviews analysées, 21% étaient entièrement générées par IA.

Bienvenue dans le monde du doute permanent !

Maintenant, si vous pensez que ça ne concerne que les chercheurs, détrompez-vous car de mon côté, ce que j'observe, c'est que les faux repos GitHub, c'est le même fléau côté tech, et surtout un vrai problème pour tous ceux qui relayent des projets open source comme moi.

Vous avez peut-être vu passer mon article d'hier sur WiFi DensePose , un projet à 25 000 étoiles sur Github qui promettait de détecter les postures humaines via le signal WiFi. Le code Python est détaillé, crédible en surface, il y a des tas d'issues ouvertes avec de vraies questions d'utilisateurs différents, des tas de pull requests parfaitement crédibles, une documentation hyper léchée... et le tout est adossé à un vrai papier de recherche de Carnegie Mellon .

Pour moi, ça avait l'air carrément sérieux ! Donc j'en ai fait un article.

Sauf qu'après coup, différentes personnes ont creusé plus profondément le code (Merci Nicolas), et ont trouvé des choses assez étranges partout dans le code. En fait, le truc générait des données aléatoires en se faisant passer pour du traitement de signal WiFi. C'est du vibe coding à l'état pur et quand des gens ont posé des questions dans les issues... ces dernières ont été vite supprimées. Faut dire que le piège était quasi parfait.

Et c'est tout le problème ! Car pour évaluer si un projet GitHub est légitime, je me base sur plusieurs signaux. Le code, les issues et les PRs, le nombre de stars, la reprise sur Reddit ou Hacker News, les commentaires, les articles dans la presse et quand je peux (et là c'était pas le cas car ça demande pas mal de matos que j'avais pas), je teste évidemment... Mais du coup, quand TOUS ces signaux sont fabriqués de toutes pièces, y'a plus aucun repère !

Parce que figurez-vous que les étoiles Github, ça s'achète (y'a des services entiers dédiés à ça), les issues se génèrent par IA, le code compile, les tests passent, le README est nickel, et le développeur a d'autres projets crédibles sur son profil. Vraiment tout est conçu pour que ça fasse parfaitement illusion.

Et comme ce sont souvent des projets émergents sur des technos de pointe, y'a pas grand monde qui a le matos ni le temps de vérifier par soi-même. Du coup, voilà comment moi et d'autres, on se retrouve à relayer des projets bidon sans le savoir. Et dire que j'étais à 2 doigts d'acheter le matos pour tenter l'aventure...

Les chercheurs se fient au peer review, aux citations, à la réputation du journal et moi c'est pareil avec les stars, les contributions, et le relai médiatique. Sauf que dans les deux cas, l'IA a rendu ces marqueurs de confiance complètement bidons. C'est pour ça que je fais ce parallèle car de mon point de vue, c'est le même combat.

Et le pire, c'est que c'est même pas du code malveillant. Y'a pas de backdoor, pas de malware planqué, pas de minage crypto en douce. C'est juste du code qui donne l'ILLUSION de fonctionner, ou plutôt, qui PRÉTEND fonctionner. Tout ça apparemment pour faire ce qu'on appelle du "portfolio padding"... c'est-à-dire gonfler son CV de développeur avec des faux projets open source à des milliers de stars pour impressionner les recruteurs.

Perso, j'avoue ça me dépasse.

Maintenant, comme c'est nouveau pour tout le monde, il va falloir apprendre à éviter de tomber dans le panneau. J'y ai réfléchi un peu et finalement, ça passe par une analyse plus approfondie du code et de l'historique du projet... On peut par exemple vérifier le git log parce qu'un projet à 25 000 étoiles et 3 commits en 2 semaines, c'est louche, donc méfiance. Et surtout, faut chercher des retours d'utilisation concrets et des issues techniques pointues. Après encore faut-il avoir des compétences techniques assez poussées (par exemple en traitement du signal) pour capter ce qui y est raconté... Pas simple hein ?

Faudrait peut-être que je me fasse un skill un peu poussé pour qu'une IA soit capable de faire ce taf chiant à ma place. Je vais y réfléchir.

Bref, on est tous dans la même galère, à devoir douter de tout ce qui brille sur GitHub et ailleurs et ça c'est bien emmerdant.

• lien nᵒ 1 : April
• lien nᵒ 2 : Revue de presse de l'April
• lien nᵒ 3 : Revue de presse de la semaine précédente
• lien nᵒ 4 : 🕸 Fils du Net

Commentaires : voir le flux Atom ouvrir dans le navigateur

Est-ce que vous avez déjà eu cette envie soudaine de composer de la techno tout en ayant l'air d'un hacker qui pirate le Pentagone dans un film des années 90 ?

Si oui, j'ai le truc parfait pour vous : Strudel .

Pour ceux qui débarquent, le live coding musical dont je vous ai déjà parlé y'a pas longtemps avec Loopmaster , c'est l'art de créer du son en écrivant du code en temps réel.

En gros, on tape des lignes, on valide, et hop le rythme change en direct. Strudel rend ce concept ultra accessible puisqu'il tourne entièrement dans votre navigateur préféré, sans chichi et surtout sans avoir besoin d'installer des usines à gaz comme SuperCollider ou de configurer des environnements de dev à n'en plus finir.

L'interface de Strudel - sobre mais efficace ( Source )

Le projet est d'ailleurs un port officiel du langage de patterns de TidalCycles vers JavaScript. TidalCycles , c'est un peu la référence absolue dans le monde du live coding, mais ça demandait pas mal de bidouille (Haskell, etc.) pour fonctionner correctement. Avec Strudel, vous ouvrez une page web, vous tapez du code et c'est parti mon kiki !

Le principe repose sur des motifs rythmiques qui occupent toujours le même espace temporel (appelé "cycle"). Contrairement à un séquenceur classique où on empile des notes, ici on définit des structures qui se compressent ou s'étirent automatiquement. C'est un peu déroutant au début mais une fois qu'on a pigé le truc, on peut sortir des beats qui tabassent en seulement trois lignes de code. Perso, je trouve ça assez hypnotique (oui j'aime le comique de répétition).

Côté technique, l'outil s'appuie sur l'API Web Audio et intègre un synthé/sampler baptisé Superdough. C'est assez costaud et ça permet déjà de s'amuser avec plein d'effets sans quitter le browser. Et pour les plus barbus d'entre vous qui voudraient piloter leur propre setup SuperCollider , c'est possible aussi via OSC , mais attention, il faudra quand même lancer un petit serveur relais en Node.js pour faire le pont entre le navigateur et votre machine.

Y'a même un workshop interactif vraiment bien foutu pour apprendre les bases. En quelques minutes, vous allez comprendre comment balancer des snares et des kicks avec une précision chirurgicale. Et le petit plus qui fait plaisir, vous pouvez partager vos chefs-d'œuvre en copiant simplement l'URL, puisque tout votre code est encodé dedans. C'est direct in the pocket !

La Reine de Strudel c'est évidemment Switch Angel :

WordPress, c’est bien. Mais WordPress qui injecte des scripts d’emojis, des styles Gutenberg, des shortlinks et 47 autres trucs dont vous n’avez pas besoin dans chaque page de votre site… c’est moins bien évidemment. Heureusement, Terence Eden, un dev qui en avait marre de voir son code source ressembler à un plat de spaghetti, a compilé une petite liste de tout ce qu’on peut virer .

Car WordPress a adopté une philosophie de type “Decisions, not options” (des décisions, pas des options) où en gros, au lieu de vous laisser choisir, ils décident pour vous de ce qui est bon pour vous. Un peu comme Macron ^^. Le problème c’est que leurs décisions incluent un tas de fonctionnalités dont la plupart des gens n’ont rien à faire 🥲.

Par exemple les emojis. J’sais pas si vous savez, mais WordPress charge un script de détection d’emojis et une feuille de style dédiée sur CHAQUE page de votre site. Pourquoi tant de haine ? Hé bien parce que si vous tapez :-) dans un article, WordPress veut le transformer en joli emoji. Sauf que si vous utilisez les vrais emojis Unicode (comme tout le monde en 2025), hé ce script ne sert à rien. Et il y a aussi le grand remplacement des emojis dans les flux RSS…. Bref, tout ça, ça dégage.

Ensuite y’a le formatage automatique avec wptexturize qui transforme vos guillemets droits en guillemets typographiques “comme ça”. Et mon préféré, capital_P_dangit qui remplace automatiquement “Wordpress” par “WordPress” avec le P majuscule. Oui, vous ne le saviez pas, mais WordPress corrige l’orthographe de son propre nom dans vos articles. Mais quelle bande de nazes ^^.

Gutenberg, l’éditeur de blocs que j’adore, injecte lui aussi ses styles globaux même si vous utilisez l’éditeur classique. Et c’est pareil pour les styles de la librairie de blocs et l’éditeur de widgets basé sur les blocs. Si vous êtes resté sur le Classic Editor comme beaucoup de gens, tout ça ne sert alors qu’à alourdir vos pages.

Côté métadonnées, WordPress ajoute aussi pleiiiiin de trucs dans le code de vos pages comme les shortlinks, le RSD (Real Simple Discovery, un truc d’il y a 20 ans), des liens vers les flux de commentaires, les liens JSON de l’API REST…

Aux chiottes toutes ces conneries !

Le script de Terence fait aussi sauter l’ajout automatique des tailles d’images (wp_img_tag_add_auto_sizes), les templates de pièces jointes, et les block hooks qui modifient votre contenu. L’idée c’est donc de reprendre le contrôle sur ce que WordPress génère, au lieu de le laisser décider tout seul.

Et grâce à son script, le site de Terence (sans Philippe) obtient d’excellents scores sur PageSpeed Insights , ce qui prouve que tout ce bloat n’est vraiment pas nécessaire. Son script PHP complet fait environ 190 lignes et il est dispo sur son GitLab , bien commenté pour que vous puissiez choisir ce que vous voulez garder ou virer.

Attention quand même, certaines de ces désactivations peuvent casser des fonctionnalités si vous les utilisez vraiment. Par exemple, si vous avez des plugins qui dépendent de l’API REST, la virer complètement serait une mauvaise idée. Même chose pour les blocks Gutenberg si vous utilisez cet éditeur. L’astuce c’est donc de tester chaque modification une par une et de voir ce qui se passe.

Amusez-vous bien et un grand merci à Terence !

Scène du crime, mardi matin, vous demandez à Claude Code de vous générer un middleware Next.js qui vérifiera un JWT dans les cookies. Et l’IA vous pond sans sourciller 15 lignes de code bien propres, bien commentées… Elle est parfaitement confiante et vous ça vous rassure. Vous copiez son œuvre, vous collez. Et là, PAF, une erreur de compilation !!

Hé oui, la fonction qu’elle a utilisée n’existe plus depuis Next.js 14. En gros, Claude Code a halluciné tranquillement avec de la vieille doc pourrie de 2020.

Et dire qu’on a passé 20 ans à se foutre de la gueule des devs qui copient-collent du code depuis de vieux posts Stack Overflow alors qu’aujourd’hui, on copie colle sans réfléchir ce que nous donne une IA qui fait exactement pareil ! C’est ça le progrès les amis !

Hé bien Context7 vient régler exactement ce problème ! Il s’agit d’un serveur MCP (Model Context Protocol) développé par Upstash qui branche votre assistant de code sur la documentation officielle à jour, comme ça vous esquivez les fonctions dépréciées, les API fantômes, et les best practices d’il y a trois ans.

Context7 est donc compatible avec Cursor, Claude Code, Windsurf, VS Code, Zed, Gemini CLI, et tous les éditeurs qui supportent le protocole MCP (donc à peu près tout ce qui existe…) et une fois que c’est en place, y’a plus qu’à l’oublier. Si vous hésitez, y’a une démo ici pour tester .

Mais avant de commencer, sachez que vous aurez besoin de Node.js 18+ pour la méthode locale. Et pour la méthode serveur distant, juste un navigateur et votre éditeur de code.

La méthode serveur distant consiste à aller sur context7.com , à vous créer un compte gratuit, à récupérer une clé API, puis à ajouter cette config dans votre éditeur comme ceci :

{
 "mcpServers": {
 "context7": {
 "url": "https://mcp.context7.com/mcp",
 "headers": {
 "CONTEXT7_API_KEY": "votre_cle_api_ici"
 }
 }
 }
}

{
 "mcpServers": {
 "context7": {
 "command": "npx",
 "args": ["-y", "@upstash/context7-mcp", "--api-key", "votre_cle_api_ici"]
 }
 }
}

Vous savez ce qui est marrant avec reCAPTCHA ? C’est que pendant des années, on nous a fait déchiffrer des plaques d’immatriculation floues, cliquer sur des feux tricolores bizarres, et identifier des vélos volés dans des images pixelisées, tout ça pour prouver qu’on était pas un robot. Alors qu’en fait, on entrainait gratos les IA de Google à reconnaitre ce genre de choses… Du coup, faudrait savoir s’en passer maintenant.

Et ça tombe bien puisqu’il existe une alternative qui change le game : ALTCHA . C’est un système de protection anti-spam et anti-bot open source qui utilise le Proof-of-Work à la place des puzzles visuels. Comme ça, au lieu de faire bosser votre cerveau ramolli pour Google, c’est votre processeur qui fait le boulot, tout ça en local, depuis chez vous, sans envoyer le moindre octet de donnée à Mountain View.

En gros, quand vous validez un formulaire, votre navigateur résout un petit calcul cryptographique. Pour un humain avec un ordinateur normal, c’est transparent et instantané mais pour un bot qui essaie de spammer 1000 formulaires par seconde, ça devient très vite coûteux en ressources. Et le plus beau c’est qu’il n’y a pas besoin de serveurs externes, pas de tracking, pas de cookies, pas de fingerprinting puisque tout se passe en local.

En plus, ALTCHA pèse 30 KB une fois compressé alors que reCAPTCHA c’est 300 KB… Vous vous demandez pourquoi reCAPTCHA est si gros en vrai ? Hé bien c’est parce qu’il est composé d’un tas de scripts de tracking, de fingerprinting, d’analyse comportementale et j’en passe…

ALTCHA est sous licence MIT , donc vraiment libre et ça fonctionne avec tous les navigateurs modernes (Chrome 67+, Firefox 63+, Safari 11+), avec plus de 50 langues dispo et niveau conformité, c’est carré sa Cnil : GDPR, WCAG 2.2 AA, HIPAA, CCPA…etc.

ALTCHA détecte aussi les headless browsers (les navigateurs sans interface graphique utilisés pour automatiser), les scripts automatisés, et même les bots qui utilisent du machine learning. Le système analyse le contenu et le contexte utilisateur pour adapter le niveau de protection et vous pouvez le déployer partout sans problème : AWS, Azure, Kubernetes, Docker, ou juste sur votre serveur web classique. Il y a même un plugin WordPress si vous voulez pas vous embêter avec du code.

En plus, comme c’est à 100% auto-hébergé, vous ne dépendez d’aucun service externe. Alors que quand reCAPTCHA tombe en panne (spoiler : ça arrive régulièrement), votre site est pété.

Bref, si vous en avez marre de faire bosser les visiteurs de votre site gratos pour Google qui en profite pour les tracker, jetez un œil à ALTCHA . Pour une fois que l’Europe arrête de mendier ses outils de sécurité auprès des géants américains et qu’en plus c’est meilleur, ce serait dommage de s’en priver.

Linus Torvalds vient de donner son avis sur l’IA et le vibe coding et ça ne va pas plaire à tout le monde, ahahaha.

Hé oui car pendant que le monde tech se déchire entre les évangélistes de l’IA qui veulent tout automatiser et les énervés qui refusent l’IA par principe idéologique, Linus débarque dans le game avec un avis… de complet normie.

Lors de l’Open Source Summit à Séoul qui vient d’avoir lieu, Linus a partagé sa vision sur l’IA générative et le fameux “vibe coding”. Et son avis, c’est que l’IA c’est juste un outil de plus !

Ah putain, ça fait plaisir de lire ça ! ( Tout comme cet article d’ailleurs )

Le vibe coding, pour ceux qui débarquent, c’est ce terme inventé par Andrej Karpathy d’OpenAI qui consiste à décrire ce que vous voulez coder à un LLM. Ce dernière génère alors le code, et vous testez si ça marche ou si ça marche pas. Et ensuite vous demandez des ajustements et ainsi de suite !

Autant dire que c’est devenu un sujet chaud pour pleiiiins de raisons.

Bref, Linus se déclare “plutôt positif” sur le vibe coding mais uniquement comme point d’entrée en informatique. Pour des petits projets, des prototypes rapides…etc c’est top car ça permet à des gens qui ne savent pas coder de faire des trucs super ! Mais après pour du code critique en production, il est cash en expliquant que ça risque d’être “horrible, horrible d’un point de vue maintenance”. Et je ne peux pas lui donner tort.

Linus n’utilise pas personnellement d’IA pour coder mais il voit bien que des gens testent l’IA pour travailler sur du code critique dans le noyau Linux et ça il s’en méfie à raison car les mainteneurs du kernel se prennent régulièrement des bugs reports et des security notices complètement bidons générés par des gens qui utilisent mal les IA.

Les crawlers IA posent aussi des problèmes techniques sur kernel.org car ces bots qui aspirent tout le code pour nourrir leurs modèles font ramer les serveurs. Quoiqu’il en soit, Linus est plutôt modéré sur le sujet de l’IA générative pour coder et attend avec impatience le jour où l’IA sera un truc moins hype. En gros, qu’on arrête d’en parler H24 et qu’on l’utilise juste quand c’est pertinent…

C’est vrai que d’un côté, vous avez ces fifous pro-IA à toutes les sauces qui pensent qu’on va tous devenir des prompt engineers et que les devs vont disparaître (spoiler : non). Et de l’autre, les donneurs de leçons en pureté technologique qui refusent l’IA en bloc sans jamais se poser la moindre question.

Du coup, je vous avoue que je suis content de voir qu’au milieu de tout ce bordel, y’a ce bon vieux Linus qui nous explique que c’est juste un stupide outil et qu’il faut simplement apprendre à l’utiliser intelligemment.

Oh non, vilain Korben va encore parler de méchante IA, lol ! Car oui, j’sais pas si vous avez vu, mais Google vient de lancer Antigravity et tout le monde s’emballe et un Mars (uh uh !) en disant que c’est LE nouvel IDE magique pour coder avec des agents IA ! Et c’est surtout une grosse pub pour son nouveau modèle Gemini 3 sorti en même temps, faut bien le dire !

Et pour le coup, faut reconnaître que niveau timing, Google a frappé fort puisque Gemini 3 débarque moins d’une semaine après la sortie de GPT-5.1 d’OpenAI et seulement deux mois après Claude Sonnet 4.5. Hé oui, la guerre des modèles fait rage et personne ne veut laisser les autres prendre l’avantage, à ma plus grande joie (Oui, j’aime la tech et tester tous ces trucs) !

Sur le papier Antigravity est donc une plateforme de développement “agent-first” où les agents IA ont un accès direct à votre éditeur de code (un VS Code as usual), votre terminal et votre navigateur. Comme ça, ils peuvent écrire des specs, coder vos idées les plus folles, puis tester et valider tout ça pendant que vous, de votre côté, vous pouvez continuer à écrire des saloperies sur Mastodon !

Que demande le peuple ? lol

Et ces petits agents IA sont très forts pour produire ce que Google appelle des “artefacts”. En gros, ce sont des listes de tâches, des plans d’implémentation, des screenshots, ou encore des enregistrements vidéo de ce qu’ils ont fait ou prévoient de faire. Et vous, de votre côté, votre seul job c’est de valider ces artefacts et de commenter ce qui est produit.

Félicitations, vous venez d’avoir une promotion ! Vous n’êtes plus développeur, vous êtes maintenant chef de projet !

On peut bien sûr, toujours éditer le code, mais on va arrêter de faire semblant, ce n’est clairement plus l’objectif puisque ce sont les agents qui s’en occupent. Et ces derniers sont capables d’apprendre de vos retours en se construisant une base de connaissance interne avec vos feedbacks afin d’affiner les process et de tendre le plus efficacement possible vers vos objectifs.

Voilà… Maintenant, si vous aimez vraiment écrire du code avec vos petits doigts boudinés, ça ne sera pas fun, c’est certain. Par contre, si comme moi, vous êtes un piètre codeur mais que vous avez des tas d’idées folles et que vous aimez orchestrer, piloter, et valider des trucs, vous allez sur-kiffer !

Mis à par Gemini 3, Antigravity supporte aussi GPT-OSS, et les modèles d’Anthropic (Claude Sonnet 4.5 pour être précis) et d’OpenAI. L’outil est pour le moment gratuit en preview publique pour Mac, Windows et Linux et les limites d’utilisation de Gemini 3 Pro (en mode Low) sont très généreuses selon Google.

Et pour ceux qui se demandent si Gemini 3 c’est du vent ou du solide, sachez que le modèle cartonne sur les benchmarks avec un score de 1501 Elo sur LMArena (record absolu), 37.5% sur Humanity’s Last Exam (niveau PhD quand même), 91.9% sur GPQA Diamond, et 76.2% sur SWE-bench Verified qui teste spécifiquement les capacités de coding. Bref, sur le papier, c’est du lourd.

Google a même prévu une version “Deep Think” de Gemini 3 pour les abonnés Ultra qui arrivera dans les prochaines semaines, avec encore plus de capacités de raisonnement pour les tâches complexes. Et avec plus de 650 millions d’utilisateurs mensuels sur Gemini, on sent que Google veut vraiment en faire son fer de lance et détrôner OpenAI et Anthropic dans le cœur des codeurs !

Bref, maintenant à voir ce que ça donne en vrai et si ça fonctionne mieux que Windsurf ou Cursor, mais ça, je vous le dirai plus tard quand je me serais un peu plus amusé avec… Antigravity, c’est peut-être l’avenir du dev, ou c’est peut-être juste Google qui essaie de vous forcer à changer de taf sans vous demander votre avis… qui sait ?

On verra bien si leur mayonnaise prend, mais en attendant, si vous testez, dites-moi ce que vous en pensez, je suis curieux.

Vous vous souvenez de la dernière fois où vous avez dû redémarrer un container Docker en urgence depuis votre téléphone, planqué dans les chiottes du resto un jour de St Valentin ?

Le minuscule clavier, la connexion SSH qui rame, les commandes qu’on tape mal parce que l’autocorrect veut absolument transformer “docker ps” en “docker pas”, l’écran trop petit pour lire les logs… Bref, la grosse merde !!

Heureusement, Docker Manager débarque pour transformer ce cauchemar en expérience qui fait plaisir aux yeux. C’est une app Android qui gère vos containers Docker à distance, et c’est tellement bien foutu que vous allez enfin arrêter d’ouvrir votre laptop n’importe où juste pour faire un simple restart.

C’est vrai que faire du SSH depuis un smartphone, ça a toujours été possible. Y’a même plein d’apps terminal mobiles, de clients fait pour ça, même des bidouilles pour se connecter à vos serveurs. Mais “possible” et “agréable”, c’est pas vraiment la même chose.

Grâce à Docker Manager ce sera donc possible ET agréable ! Vous gérez déjà Docker, vous connaissez déjà les commandes, vous savez ce que vous faites mais au lieu de vous faire taper des commandes dans un terminal de 5 pouces, l’app vous offre une interface utilisateur carrée avec des boutons, des statistiques en temps réel, des logs lisibles, et même un shell interactif quand vous en avez vraiment besoin !

Vous connectez donc vos serveurs via SSH (mot de passe ou clé, comme d’hab), et hop, vous aurez accès à tout. Start/stop/restart de containers, inspection des images, gestion des volumes et des networks, stats CPU/RAM en direct… Tout ce que vous feriez normalement en SSH, mais sans vous arracher les yeux sur un terminal mobile.

Autre truc sympa, l’app supporte plusieurs serveurs, donc vous pouvez switch entre votre VPS perso, votre homelab, et votre serveur de prod en deux tapotages ^^. Elle gère aussi les VPN comme Tailscale, donc si vos serveurs sont derrière un réseau privé, pas de problème. Elle propose même des thèmes light/dark, parce que oui, même en pleine nuit à 3h du matin quand un container plante, vous avez le droit à votre petit confort visuel.

L’app supporte aussi Podman. Vous configurez juste votre CLI Docker custom, et ça marche ! Et en plus, c’est open source ! Vous pouvez même faire du cleanup système pour virer les images et containers qui traînent histoire de faire un peu de ménage.

L’app est dispo sur le Play Store et sur GitHub pour ceux qui veulent build depuis les sources ou juste regarder le code. Testez, vous verrez, ça change la vie.

Merci à Friendly_0day pour le partage !

Vous savez ce moment où vous regardez votre historique Git et vous vous demandez qui est le débile qui a écrit ce code dégueulasse ?

Ah bah ouais, c’était vous il y a 3 mois ^^. Eh bien GitType a trouvé la meilleure des thérapies qui est de vous faire retaper tout ça, lettre par lettre, comme une punition de primaire version développeur, totalement gamifiée avec des points, un chrono, et la possibilité de mesurer à quel point vos doigts sont devenus flasques depuis que Copilot fait tout le boulot à votre place.

Le tagline du projet, c’est “Show your AI who’s boss: just you, your keyboard, and your coding sins”. Et c’est pas une blague, c’est un manifeste car pendant que Copilot, ChatGPT, Claude Code et compagnie écrivent du code à notre place, GitType vous fait faire exactement l’inverse… il vous force à retaper du code pour redevenir bon !

Et contrairement aux tests de frappes classiques comme Ttyper ou tt qui vous font taper du texte générique, GitType utilise du VRAI code source. Votre code, celui de vos repos préférés, ou des repos trending de GitHub. Comme ça, vous ne vous entraînez pas sur du “ the quick brown fox jumps over the lazy dog ” à la con, mais sur vos propres merdes spaghettico-syntaxiques en Rust, TypeScript, Python ou Go.

Le jeu vous propose plusieurs modes. Y’a le mode Normal pour vous échauffer tranquillement, le Time Attack quand vous voulez vous mettre la pression, et des niveaux de difficulté de Easy à Zen pour ceux qui veulent méditer en tapant du code. Le tout avec un tracking en temps réel de votre WPM (words per minute) et de votre précision. Comme ça, plus vous progressez, plus vous montez dans le ranking avec des titres de développeur qui évoluent.

GitType supporte plus de 15 langages de programmation et propose plus de 15 thèmes visuels en mode Dark ou Light, avec possibilité de personnaliser le vôtre. L’installation est simple…

curl -sSL https://raw.githubusercontent.com/unhappychoice/gittype/main/install.sh | bash

Alors si vous cherchez un truc pour procrastiner intelligemment ce soir ou demain, j’ai exactement ce qu’il vous faut. Play.ertdfgcvb.xyz , c’est un terrain de jeu ASCII interactif où vous pouvez coder des animations directement dans votre navigateur. Et c’est hyper hypnotisant, vous allez voir !

Derrière ce nom imprononçable “ertdfgcvb” se cache Andreas Gysin , un artiste suisse basé à Lugano qui fait du code et du design et son playground ASCII, c’est une interface épurée au maximum composée d’un éditeur de code à gauche, d’une fenêtre de prévisualisation à droite, et c’est tout. Pas de fioritures, pas de boutons partout, juste l’essentiel. Vous tapez Cmd+Enter (ou Ctrl+Enter sur PC) et votre code s’exécute en temps réel.

Le principe de son code en live est inspiré des fragment shaders GLSL , sauf qu’au lieu de pixels colorés, vous manipulez des caractères. Vous avez accès à des fonctions spécifiques telle que boot() qui s’exécute une fois au démarrage, pre() pour préparer vos données, main() qui est appelée pour chaque cellule de l’écran, et post() pour les modifications finales.

Voici un exemple simple en javascript pour comprendre le délire :

export function main(coord, context){ return String.fromCharCode((coord.y + coord.x) % 32 + 65) }

Ce bout de code génère un pattern de lettres qui change selon la position X et Y sur l’écran. C’est tout con mais c’est beau.

Le playground propose également des dizaines d’exemples triés par catégorie. Vous avez les basiques pour apprendre, des démos plus complexes comme “Doom Flame” qui recrée l’effet de flamme du jeu Doom en ASCII, ou encore “Donut” qui fait tourner un donut en 3D avec juste des caractères. Y’a même une section “camera” où vous pouvez manipuler votre webcam et la transformer en ASCII art en temps réel.

D’après le GitHub du projet , Andreas a créé ça comme un hommage à tous les artistes, poètes et designers qui utilisent le texte comme medium. C’est un projet minimaliste, avec presque pas d’interface, juste le code et le résultat. Même les marges et les numéros de ligne ont été virés.

Et tout ça tourne de manière fluide dans le navigateur et pour les dev qui veulent comprendre comment ça marche sous le capot, tout le code source est sur GitHub, et vous pouvez vraiment faire des trucs de ouf avec, par exemple des fractales, des simulations de fluides…etc. C’est complètement barré.

Mais pour commencer, le plus simple c’est d’explorer les exemples. Le classique “10 PRINT” recrée le fameux one-liner du Commodore 64 qui génère un labyrinthe infini. Les exemples SDF (Signed Distance Fields) montrent comment faire de la 3D avec des maths et des caractères. Et si vous êtes chaud, vous pouvez lui envoyer vos propres créations qui rejoindront la section “contributed”.

Andreas enseigne ces techniques dans ses cours, et apparemment les étudiants adorent. C’est vrai que c’est une approche super pédagogique du creative coding où on se prend pas la tête avec du WebGL ou des frameworks complexes… Non, faut juste pondre du code simple qui produit des résultats visuels immédiats.

Bref, play.ertdfgcvb.xyz c’est le genre de site qu’on bookmark et qu’on ressort quand on veut se vider la tête en codant des trucs rigolos. C’est gratuit, c’est open source, et c’est une belle démonstration que l’art et le code peuvent cohabiter sans avoir besoin de millions de polygones et de shaders complexes.

Un grand merci à Lorenper pour m’avoir fait découvrir cette pépite !

Vous saviez qu’en ce moment, les attaques sur la supply chain faisaient des ravages ? En effet, les attaquants exploitent régulièrement la possibilité de modifier des tags existants pour injecter du code malveillant dans les pipelines CI/CD.

Mais heureusement, GitHub a enfin sorti LA fonctionnalité qui peut empêcher ce carnage : les Immutable Releases et je pense que c’est le genre de truc que tous les développeurs devraient activer illico sur leurs repos. Je vais vous expliquer pourquoi.

En fait, une fois que vous publiez une release avec cette option activée, plus personne ne peut toucher ni aux assets ni au tag associé. C’est comme si vous mettiez votre release dans un coffre-fort dont vous jetez la clé. Même vous, en tant que mainteneur, vous ne pouvez plus modifier les binaires ou déplacer le tag vers un autre commit.

D’après la documentation officielle , chaque release immuable génère automatiquement une attestation cryptographique. Cette attestation contient le SHA du commit, le tag et la liste des assets. Vos utilisateurs peuvent vérifier l’intégrité de ce qu’ils téléchargent en s’assurant que cela correspond exactement à ce que vous avez publié.

Pour activer cette option merveilleuse, c’est dans les settings de votre repo ou de votre organisation. Une fois activé, toutes les nouvelles releases deviennent alors automatiquement immuables. Les anciennes releases restent toutefois modifiables (pour éviter de casser vos workflows existants), mais bon, c’est mieux de migrer progressivement.

Attention quand même, il y a quelques pièges à éviter. Premièrement, vous ne pouvez plus ajouter d’assets après publication. Donc si votre CI upload les binaires après avoir créé la release, il faut inverser : Créez d’abord une draft release, uploadez les assets, puis publiez. Deuxièmement, si vous supprimez une release immuable, vous ne pourrez JAMAIS réutiliser le même tag. C’est définitif.

Pour les projets qui utilisent des tags de version majeure style v1 qu’ils mettent à jour régulièrement (coucou GitHub Actions), pas de panique. Vous pouvez continuer à utiliser cette pratique pour les tags qui ne sont pas associés à des releases. L’immuabilité ne s’applique qu’aux releases publiées, pas aux tags simples.

Les équipes de sécurité recommandent d’ailleurs d’activer cette fonctionnalité sur tous les repos qui publient du code versionné. C’est particulièrement critique pour les bibliothèques open source, les GitHub Actions, et tout ce qui est consommé par d’autres projets. En gros, si votre code finit dans la supply chain de quelqu’un d’autre, vous leur devez cette protection.

Le truc cool aussi, c’est que ça protège contre les erreurs humaines. Combien de fois j’ai vu des mainteneurs qui écrasaient accidentellement une release avec la mauvaise version ? Ou qui supprimaient un asset critique par erreur ? Avec les Immutable Releases, ces accidents appartiennent au passé.

Pour les entreprises, c’est un argument de vente en or. Ça permet de garantir à vos clients que vos releases ne peuvent pas être altérées après publication, c’est un niveau de confiance supplémentaire surtout dans des secteurs régulés où la traçabilité est cruciale.

Bref, GitHub est en train de déployer progressivement cette fonctionnalité en public preview. Pour l’instant, il faut l’activer manuellement pour chaque repo, mais ils travaillent sur une API pour permettre l’activation en masse. D’ici là, prenez donc 2 minutes pour l’activer sur vos projets critiques.

Voilà, après les dégâts causés par les attaques de type tag hijacking ces dernières années, ne pas activer les Immutable Releases sur vos repos publics, c’est comme laisser votre porte d’entrée grande ouverte avant de partir en vacances. Vous pouvez le faire, mais ne venez pas pleurer si ça tourne mal.

J’sais pas si vous avez vu, mais Google a sorti en beta, encore un truc qui va mettre les experts UX/UI au chomdu ! Son petit nom c’est Stitch (rien à voir avec Lilo) et vous pouvez le découvrir sur stitch.withgoogle.com . En gros, Stitch c’est une boîte à outils expérimentale qui utilise de l’IA pour transformer vos idées de site ou d’appli mobiles en interfaces utilisateur fonctionnelles en un rien de temps.

Le principe c’est comme d’hab, vous entrez une description en langage naturel du style “Vazy crée-moi une app mobile dark theme avec une navbar, une carte de profil et un bouton d’action flottant, wesh”, et hop ! Stitch vous sort de son chapeau l’interface complète avec le code HTML/CSS qui va bien. C’est annoncé officiellement depuis mai sur le blog Google Developers depuis Google I/O 2025. Oui, je sais, j’suis pas pressé. J’ai un métier moi (non).

Et si vous n’êtes pas inspiré, mais que vous trouver l’app ou le site d’un concurrent sexy, vous pouvez également uploader une capture écran de son interface ou d’un gribouillis de votre cru, ou même un wireframe fait à l’arrache. Et Stitch analysera l’image et vous crachera une version propre et fonctionnelle.

Gemini 2.5 est bien sûr le maître d’œuvre et Stitch vous propose deux modes : Gemini 2.5 Flash pour la rapidité (350 générations par mois), ou Gemini 2.5 Pro pour des résultats plus sophistiqués (50 générations par mois). Notez que le mode Pro est particulièrement bon quand vous travaillez avec des inputs visuels complexes.

L’intégration avec Figma est aussi un vrai plus. Vous pouvez donc exporter directement votre design dans Figma tout en préservant les calques et les composants ce qui est pratique pour les designers qui veulent peaufiner le résultat ou pour les équipes qui bossent déjà avec cet outil. Par contre, moi j’y ai pas accès, donc je pense qu’il faut un abonnement pro pour profiter de cette option.

Pour les développeurs, le code généré est également plutôt propre et bien structuré. Moi j’ai testé en demandant une interface pour une potentielle application Korben sur iOS / Android (j’suis pas sûr qu’il y ait un vrai besoin cela dit) et il m’a pondu un truc assez classique mais très propre, basé sur Tailwind CSS.

Et évidemment, chez Google, ils vous diront que l’objectif n’est pas de remplacer Figma ou Adobe XD, mais plutôt de faciliter la phase initiale de prototypage qui peut être fastidieuse. Mais bon, à terme, je pense que ce sera la fin pour ce genre d’outils sauf s’ils embrassent eux aussi, l’IA générative.

L’outil propose évidemment un chat interactif pour affiner le design, des sélecteurs de thèmes, et la possibilité de modifier le résultat en temps réel. Vous pouvez aussi jongler entre les versions web et mobile de votre interface en un clic. Pour l’instant, c’est gratuit mais avec des limitations mensuelles. Il vous faut un compte Google et c’est disponible dans 212 pays, uniquement en anglais.

C’est donc parfait pour les débutants avec des idées d’apps, les développeurs qui veulent prototyper rapidement, et les designers qui cherchent à explorer des variantes rapidement avec une bonne UX/UI faite dans les règles de l’art.

Mais attention quand même… Pour ma part, j’ai testé le bouton de téléchargement pour récupérer un design et ça n’a pas fonctionné… preuve que c’est vraiment encore en beta !

Voilà, donc si vous voulez tester, rendez-vous sur stitch.withgoogle.com . Ça peut vous faire gagner du temps sur les phases de brainstorming et de prototypage rapide.

Merci à Rpc2dot0 pour la découverte !

Y’a pas une semaine qui passe sans que je code un petit peu de Python, alors quand je suis tombé sur ce documentaire que Cult.Repo vient de sortir , je me suis dit que c’était l’occasion d’en apprendre un peu plus sur ce langage qui fait tourner l’IA chez Google, Meta et OpenAI, et qui (je viens de l’apprendre) a commencé comme un projet de vacances. Guido van Rossum son créateur cherchait juste un truc pour s’occuper pendant les vacances de Noël en 1989. Son bureau était fermé, il s’ennuyait, alors il a pondu les bases d’un nouveau langage en deux semaines. Pour le fun.

Le documentaire montre vraiment bien comment ce petit projet perso est devenu un monstre. Au départ, van Rossum bossait au CWI à Amsterdam sur un langage appelé ABC, sauf qu’ABC avait plein de défauts et surtout, impossible de l’étendre. Python, c’était donc sa revanche… prendre le meilleur d’ABC (comme l’indentation pour structurer le code) et virer tout ce qui l’énervait.

Le nom Python, d’ailleurs, ça n’a rien à voir avec le serpent. Van Rossum était fan des Monty Python. Il cherchait un nom court, mystérieux, et il lisait les scripts de la série à ce moment-là. Voilà donc comment le langage le plus utilisé au monde a hérité du nom d’une troupe de comiques britanniques.