Vous développez un truc en local et vous avez besoin de le montrer à quelqu'un au travers d'Internet, genre pour tester un webhook, faire une démo rapide, ou juste impressionner votre collègue à distance ? Hé bien au lieu de vous farcir une config nginx + certificats SSL + ouverture de ports sur le routeur (Beurk !), y'a Tunnl.gg qui fait tout ça en une SEULE ligne de commande.

Vous tapez une commande SSH, et hop, vous avez une URL publique qui pointe vers votre serveur local. Pas de client à installer, pas de compte à créer, pas de token à configurer, juste SSH, que vous avez forcément déjà sur votre machine.

Donc pour exposer votre app qui tourne sur le port 8080, vous faites :

ssh -t -R 80:localhost:8080 proxy.tunnl.gg

Et c'est parti ! Le service vous file une URL avec un sous-domaine aléatoire, genre abc123.tunnl.gg, et tout ce qui arrive dessus est redirigé vers votre localhost:8080. Et magie magie, HTTPS est automatique, donc pas besoin de vous soucier des certificats.

Du coup, si vous connaissez déjà ce genre d'outils, vous pensez peut-être à Bore que j'ai présenté il y a pas longtemps, ou Portr qui fait sensiblement la même chose, ou encore Chisel pour les amateurs de tunnels TCP/UDP via HTTP. Tous ces outils font du tunneling, mais Tunnl.gg se distingue par son approche "zéro friction" sans binaire à télécharger, et sans compte à vous créer.

Pour le moment, le service est gratuit pour un usage personnel mais les développeurs prévoient des plans payants plus tard avec des features comme les domaines personnalisés, les sous-domaines persistants et des limites de débit plus élevées. On verra bien mais en attendant, pour tester un truc vite fait ou faire une démo, la version gratuite suffira largement.

Bon, y'a quand même quelques trucs à savoir. Primo, ça ne marche qu'avec du trafic HTTP/HTTPS pour l'instant. Deuxio, le TLS est côté serveur, donc techniquement ils peuvent voir votre trafic même s'ils disent ne pas l'inspecter. Donc pour des données vraiment sensibles, gardez ça en tête. Et tertio, comme tout service de ce type, y'a des limites de fair-use pour éviter les abus.

Bref, si vous cherchez un moyen rapide d'exposer un port local sans vous prendre la tête avec la config, Tunnl.gg fera le taf. Au pire vous aurez découvert une alternative de plus à ngrok , au mieux ça deviendra votre outil par défaut pour les démos express...

Merci à Lorenper pour le partage !

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 !

L’accessibilité web c’est comme le tri sélectif… tout le monde dit que c’est génial mais azy, j’ai pas le temps. Et pourtant, c’est super important car près de 80% des pages web ont des problèmes de contraste de texte.

C’est le souci noumber ouane détecté sur le million de sites analysés chaque année par WebAIM . En gros, si vous avez un site, y’a de fortes chances que certains visiteurs galèrent à lire votre contenu, et je ne vous parle pas uniquement des personnes malvoyantes, hein… y’a aussi le daltonisme qui touche environ 8% des hommes et 0,5% des femmes. Rajoutez à ça les gens qui lisent leur téléphone en plein soleil, ceux qui ont une dalle de laptop toute pourrie, et vous comprendrez vite que le problème concerne pas mal de monde.

Alors est ce que vous connaissez les normes WCAG ?

Hé bien c’est le standard international pour l’accessibilité web. Ainsi pour être conforme au niveau AA (le minimum recommandé), votre texte doit avoir un ratio de contraste d’au moins 4,5:1 avec son arrière-plan. Pour le niveau AAA (l’idéal), c’est 7:1. Et là vous vous dites “super, je vais calculer ça à la main pour mes 47 couleurs de palette, mais va bien te faire cuire le cul, Korben”. (Oui, c’est comme ça que je vous imagine quand vous lisez mes articles).

Heureusement, y’a un outil qui vient de sortir et qui va vous changer la vie : CM-Colors . Vous lui donnez vos couleurs, et il les ajuste automatiquement pour qu’elles soient accessibles, le tout en modifiant les teintes le moins possible pour garder votre design intact.

L’installation est super fastoche…. C’est du Python donc un petit pip install cm-colors et hop c’est réglé. Ensuite, vous pouvez l’utiliser soit en ligne de commande directement sur vos fichiers CSS, soit via l’API dans votre code. Par exemple, vous avez un gris #5f7887 sur un fond #e6f0f5 qui passe pas les tests, hop, CM-Colors le transforme automatiquement en #5c6f7b et maintenant c’est conforme AA. Et la différence à l’œil nu est quasi invisible. Bref, c’est nickel pour l’accessibilité !

from cm_colors import ColorPair

# Your colors
pair = ColorPair("#999999", "#ffffff")

# Fix them and preview in the terminal
fixed_color, success = pair.make_readable(show=True)

print(f"Use {fixed_color} instead of #999999")
# Output: Use #8e8e8e instead of #999999

Le truc vraiment cool, c’est que l’outil gère plusieurs niveaux de lisibilité. Y’a “Readable” qui correspond au AA, “Very Readable” pour le AAA, et même une option large_text=True pour les gros titres qui ont des exigences moins strictes. Vous pouvez donc adapter selon vos besoins et pour les devs qui bossent sur de gros projets, y’a aussi une fonction make_readable_bulk qui permet de corriger plusieurs paires de couleurs d’un coup.

from cm_colors import make_readable_bulk

my_colors = [
 ("#777", "#fff"),
 ("#888", "#000"),
]

results = make_readable_bulk(my_colors)

for color, status in results:
 print(f"{color} is {status}")

Vous lui balancez une liste de tuples (texte, fond) et il vous retourne tout ça au propre. Et si vous voulez traiter directement vos fichiers CSS, la commande cm-colors styles.css génère un nouveau fichier styles_cm.css avec toutes les couleurs corrigées. L’outil peut même générer des rapports HTML pour visualiser les changements avant/après.

Alors oui, je sais, se taper de l’accessibilité c’est un peu relou car on a toujours l’impression que c’est du temps perdu sur des détails. Mais dites vous que ça impacte vraiment l’expérience de millions d’utilisateurs, donc ça vaut le coup d’y passer 5 minutes, surtout avec un outil automatisé !

Bref, CM-Colors c’est gratuit, c’est open source sous licence GPL-3, et ça peut vous éviter pas mal de galères. Toute la documentation est ici et y’a même une démo interactive sur leur site si vous voulez tester avant d’installer.

Si vous aimez tout ce qui est rétro, vous avez peut-être déjà essayé de donner un look MS Dos , Windows 95 , Windows 98 , Windows XP ou encore Windows 7 à votre site web.

Ce que vous n’avez jamais osé faire, c’est de lui donner un look Apple System 6 !

Et ça c’est quand même un OS qui est sorti en 1988 soit 7 ans avant Windows 95 et ce qui est incroyable c’est qu’il avait déjà une interface parfaitement mature avec des fenêtres, des icônes, des menus déroulants et tout ça était en noir et blanc, mais c’était pas moche, bien au contraire !

Et ce qu’on oublie c’est que Windows 3.0 a débarqué deux ans plus tard en 1990 avec une interface… étrangement familière. Alors on ne va pas se mentir, Microsoft s’est LARGEMENT inspiré de ce qu’Apple faisait depuis 1984 avec le premier Macintosh qui se sont eux-mêmes inspiré des interfaces vues lors de la visite de Steve Jobs au Xerox PARC.

Apple qui ne doute de rien, a même attaqué Microsoft en justice pour ça en 1988. Le procès a été perdu, mais bon, l’histoire retient qui a copié qui !

Du coup, plutôt que de continuer à cloner les clones, system.css ferme la boucle en revenant à la source. Ce projet est développé par Saket Choudhary et prend son inspiration directe des guidelines de design d’Apple pour System 6, la dernière version monochrome de macOS avant l’arrivée de System 7 en couleur en 1991.

Le truc cool avec system.css, c’est que ça fonctionne exactement comme 98.css. Y’a aucun JavaScript… Vous incluez juste le fichier CSS via CDN ou npm, et hop, tous vos composants HTML prennent instantanément l’apparence d’une interface Macintosh de 1988. Des boutons arrondis, des fenêtres avec une bordure de 19 pixels, des barres de titre, des menus déroulants incroyables, des checkboxes carrées, des boites de dialogues avec double bordure. Tout est là !

L’installation se fait en deux lignes. Via CDN, vous balancez ce code dans votre HTML:

<link rel="stylesheet" href="https://unpkg.com/@sakun/system.css">

`npm i @sakun/system.css`