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.

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

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.