Cloudflare qui sort un successeur open source à WordPress le 1er avril, je vous avoue que ça sentait le poisson d'avril à plein nez. Sauf que non !! EmDash est bien réel, son code est sur GitHub sous licence MIT, et ça s'installe en une commande toute simple !

L'idée de base pour Cloudflare, c'est de dire que WordPress a plus de 20 ans et bien qu'il alimente 40% du web, son architecture de plugins est un emmental (Le gruyère n'a pas de trou les amis ^^). En effet, 96% des failles de sécurité viennent des extensions et pas du noyau PHP ni des thèmes et en 2025, on a quand même explosé le record de failles dans l'écosystème WP.

Du coup Cloudflare, grand prince (Matthew ^^ Ok, je sors...) a tout repris de zéro en TypeScript et avec l'aide de nombreux agents IA. Et de ce que j'ai compris, le gros morceau de ce projet, visiblement, c'est l'isolation des plugins.

Car sur WordPress, une extension a accès à toute la base de données et au système de fichiers (d'où l'importance de bien les choisir ). Alors que sur EmDash, chaque plugin tourne dans son propre isolat avec un modèle de capacités déclaratives. En gros, le plugin annonce dans un fichier manifeste JSON ce dont il a besoin, genre read:content ou email:send, et il ne peut rien faire d'autre. S'il veut accéder au réseau, il doit même préciser le hostname exact. Comme ça fini les extensions qui aspirent vos données en douce. Par contre, ça veut aussi dire que vos plugins WordPress actuels ne marcheront pas tels quels...

Côté stack, c'est comme je disais du TypeScript de bout en bout avec Astro 6.0 en frontend (pour les thèmes) et Node.js derrière. L'auth passe également par des passkeys par défaut (enfin, plus de mots de passe !) et y'a même un système de paiement natif via le standard ouvert x402 pour monétiser du contenu.

Et le truc qui va vous rassurer si vous êtes allergique au cloud : c'est auto-hébergeable. En fait, le CMS peut tourner sur Cloudflare Workers, mais aussi sur n'importe quel serveur Node.js avec SQLite. Les abstractions sont portables, avec Kysely pour le SQL et l'API S3 pour le stockage. Du coup vous pouvez brancher PostgreSQL, Turso, AWS S3, ou tout bêtement des fichiers en local. Le bonheur !

Le truc cool pour les bidouilleurs, c'est que chaque instance expose un serveur MCP (Model Context Protocol) et une CLI pour piloter le CMS par script. Y'a aussi des Agent Skills pour que les agents IA puissent créer du contenu, gérer les médias et modifier le schéma sans toucher au dashboard. C'est clairement pensé pour l'ère des agents IA.

Et pour ceux qui veulent migrer depuis leur WordPress, c'est prévu pour vous faciliter la tâche puisqu'il y a le support d'export WXR classique ou via un plugin dédié qui crée un endpoint sécurisé protégé par mot de passe. Que ce soient les médias, les custom post types...etc tout est transférable en quelques minutes. Par contre, attention les shortcodes et les blocs Gutenberg custom ne passeront pas tels quel, faudra faire des ajustements.

Car oui c'est une v0.1.0 preview, donc on peut le dire, une bonne grosse beta qui bave mais je trouve ça super cool car le drama WP Engine vs WordPress a montré que l'écosystème était fragile, et c'est bien de réintroduire un peu de diversité. Par contre, remplacer un CMS qui fait tourner 40% du web, c'est hyper ambitieux et ça se fera pas en un trimestre. Car la vraie force de WordPress, c'est sa communauté, ses milliers de plugins et de thèmes, et ça pour le moment, y'a pas grand chose sur EmDash.

M'enfin, si vous voulez tester c'est npm create emdash@latest et c'est parti mon kiki. Ah et y'a aussi un playground sur emdashcms.com pour vous faire une idée sans rien installer. Pour ma part, je testerai ça dès que j'aurais 5 min, mais pour le moment, je ne me vois pas quitter WordPress car EmDash n'a pas (encore) ce petit truc en plus qui me ferait changer... On verra d'ici quelques temps.

Source

Niels Leenheer a porté le mythique Doom de 1993 dans un navigateur web, mais sans WebGL ni Canvas. Tout le rendu 3D repose sur des div et des transformations CSS. Le résultat est jouable, open source, et un brin absurde. On adore.

Doom en div

Le principe est aussi fou qu'il en a l'air. Chaque mur, chaque sol, chaque tonneau et chaque ennemi est une balise div, positionnée dans l'espace 3D grâce aux transformations CSS. Le jeu lit les données du fichier WAD original de 1993, celui-là même qui contenait les niveaux du Doom d'id Software, et en extrait les coordonnées des murs, des secteurs et des textures.

La logique du jeu, elle, tourne en JavaScript. Mais côté affichage, c'est 100 % CSS : pas de Canvas, pas de WebGL, pas de bibliothèque graphique. Juste des div, des calculs trigonométriques en CSS et des propriétés personnalisées.

Pour simuler une caméra, le développeur a trouvé une astuce assez maline : plutôt que de déplacer le joueur dans la scène, c'est la scène entière qui bouge dans le sens inverse. Le CSS ne gère pas nativement la notion de caméra, du coup Leenheer a tout simplement inversé le problème.

Des fonctions CSS qu'on ne soupçonnait pas

Le projet exploite des fonctions CSS relativement récentes : hypot() pour le théorème de Pythagore, atan2() pour les angles de rotation, clip-path pour découper les sols en polygones complexes, et @property pour animer des propriétés personnalisées qui servent à gérer les portes, les ascenseurs et même la chute du joueur.

Les ennemis utilisent des spritesheets classiques avec un effet de billboard, c'est-à-dire qu'ils font toujours face à la caméra. Les effets de lumière passent par un filtre brightness sur chaque secteur, et le fameux ennemi invisible Spectre utilise un filtre SVG pour reproduire l'effet de distorsion du jeu original.

Leenheer a même ajouté un mode spectateur avec caméra libre, absent du Doom de 1993, et les calculs de positionnement de cette caméra reposent eux aussi sur les fonctions trigonométriques du CSS.

Les limites du CSS poussé à fond

Le jeu est jouable sur cssdoom.wtf, et le code source est disponible sur GitHub sous licence GPL 2. Par contre, les performances restent limitées. Sur Safari iOS, le jeu peut planter au bout de quelques minutes, et les gros niveaux font souffrir le navigateur.

Leenheer le reconnaît lui-même : le projet ne remplacera jamais WebGL ou WebGPU pour du rendu 3D sérieux. Le but était avant tout de montrer jusqu'où le CSS moderne peut aller, et sur ce point, la démonstration est plutôt convaincante.

C'est le genre de projet complètement absurde qui force le respect. Doom a déjà été porté sur à peu près tout ce qui contient un processeur, des calculatrices aux tests de grossesse, et voilà qu'il tourne maintenant dans une feuille de style.

L'air de rien, ça montre que le CSS de 2026 n'a plus grand-chose à voir avec celui qu'on utilisait pour centrer un div il y a dix ans.

Source : Huckster.io

Bonne nouvelle pour ceux qui en ont ras la casquette de se taper des allers-retours entre Figma et VS Code ! Parce qu'avec Onlook , l'éditeur visuel open source qui vous permet de modifier le design de vos apps React directement dans le navigateur, vous allez pouvoir cliquer simplement sur un élément de design, et en changer la couleur, la typo...etc et hop, ça modifiera le code derrière.

Pas mal, non ?

Vous ouvrez votre projet Next.js dans Onlook, et vous vous retrouvez avec une interface à la Figma, sauf que c'est branché sur votre code source. Vous sélectionnez un titre, un bouton, n'importe quel composant, et vous modifiez son style visuellement... couleurs, padding, marges, polices, tout y passe.

Et en fait, le truc qui change tout par rapport à un inspecteur CSS classique, c'est que quand vous cliquez sur "Publish", les modifications atterrissent DIRECTEMENT dans vos fichiers .tsx. C'est donc du vrai code propre, pas du CSS inline dégueulasse.

Côté technique, l'outil gère nativement TailwindCSS (parce que bon, en 2026, si vous faites du React sans Tailwind, vous aimez forcément le cuir qui claque et la souffrance). Vous éditez en mode visuel, ça génère les bonnes classes Tailwind, et vous gardez un contrôle total. Y'a aussi un mode LLM intégré... "rends ce bouton bleu avec des coins arrondis" et hop, c'est fait. Comme ça, pas besoin de chercher si c'est rounded-lg ou rounded-xl dans la doc.

Si vous avez l'impression que tout ce que vous lisez en ligne est conçu pour vous énerver... vous avez probablement raison ! Le rage bait, élu mot de l'année 2025 par Oxford, c'est exactement ça. Et RageCheck , un outil gratuit lancé début janvier, se propose justement de le détecter pour vous.

En gros, le principe c'est de coller l'URL d'un article ou d'un connard de réseau social quelconque dans le champ de saisie de ragecheck.com, et l'outil le passe au peigne fin en 3-4 secondes pour repérer les techniques de manipulation émotionnelle. Du langage chargé, du framing "nous contre eux", des formulations catastrophistes... tout ce qui est conçu pour vous faire cliquer en jouant sur l'indignation plutôt que sur l'information.

En fait, RageCheck analyse le texte selon 5 catégories pondérées. Le langage "inflammatoire" et les formulations de type panique/menace pèsent chacun 25% du score final, l'appât à engagement 20%, et les patterns absolutistes ("toujours", "jamais", "TOUS") plus le framing clivant comptent pour 15% chacun.

Du coup, un article qui accumule les "c'est SCANDALEUX" et les "ils veulent DÉTRUIRE votre vie privée"... ça peut vite monter dans le rouge !

Le score va de 0 à 100. De 0 à 33, c'est clean. De 34 à 66, y'a du contenu manipulatoire modéré, et à partir de 67, c'est du putaclic assumé (et vous devriez probablement fermer l'onglet). Le truc bien pensé, c'est que l'outil vous montre EXACTEMENT quels passages ont déclenché l'alerte, avec le détail par catégorie. Par contre, attention, ça ne marche qu'avec des URLs publiques... donc si l'article est derrière un paywall, c'est muerto.

Chez moi c'est toujours supergreen, désolé ^^

Attention, RageCheck ne fait PAS de fact-checking. Il ne vous dira pas si un article dit vrai ou faux. Il se content de détecter les patterns de manipulation, mais pas le mensonge. La nuance est importante, parce que un article parfaitement factuel peut utiliser du framing manipulatoire pour orienter votre réaction.

Notez que le code source est dispo sur GitHub sous licence MIT donc y'a moyen de pousser le concept encore plus loin. Moi j'en ferais bien une extension navigateur qui viendrait automatiquement masquer les contenus problématiques... Ma tension artérielle ne s'en portera que mieux je pense...

En tout cas, j'apprécie que le scoring soit transparent et que ce ne soit pas une boîte noire. Chaque catégorie est modifiable dans le code ce qui permet d'ajuster les dictionnaires de détection par contre, le dico de détection est uniquement en anglais pour l'instant, donc sur des articles francophones ça marche moins bien.

Et vu comment certaines plateformes récompensent carrément la désinformation à l'engagement , avoir un outil qui décortique les ficelles de la manipulation, c'est pas du luxe ! Le rage bait est devenu une INDUSTRIE et les algorithmes adorent ça parce que la colère, ça génère des clics comme un distributeur de bonbons pour les accros au sucre.

Bref, c'est gratuit, c'est open source et surtout ça permet de retourner les techniques des putaclics contre eux-mêmes. Elle est pas belle la vie ?

Il y a quelques jours, un lecteur (merci Benjamin !) m'a envoyé un outil qu'il a bricolé lui-même avec Codex d'OpenAI et ça touche une petite corde sensible chez moi, d'où le fait que je vous en parle.

C'est pas souvent que je bosse avec des clients sur autre chose que des articles mais il m'est arrivé par le passé qu'un client m'envoie ses retours par mail, avec des captures d'écran floues, des flèches rouges partout et des commentaires du genre "le truc là, à gauche, je sais pas trop ??".

Alors de mon côté, j'ai testé pas mal de solutions pour évier ça mais j'ai rien trouvé de foufou... Figma par exemple c'est top pour les retours mais faut que le client crée un compte (et ça, c'est jamais gagné), Marker.io c'est bien fichu mais c'est payant. J'avais même essayé Loom à un moment, mais bon, leur demander d'enregistrer leur écran c'était trop compliqué.

Alors que UxNote, lui, règle exactement ce problème sans rien de tout ça !

En fait, ça permet d'intégrer une balise JavaScript dans votre page (juste avant le </body>) et hop, une petite toolbar apparaît.

<script src="https://github.com/ninefortyonestudio/uxnote/releases/download/v1.0.0/uxnote.min-v1.0.0.js"></script>

Votre client peut alors surligner du texte, épingler des éléments avec des badges numérotés, ajouter des commentaires... et surtout, exporter tout ça proprement en JSON ou l'envoyer direct par mail.

Comme ça, fini le chaos habituel des retours clients façon "j'ai annoté le PDF que j'ai imprimé puis scanné". Là, les commentaires sont directement contextualisés sur la page, exactement là où ils doivent être. C'est vrai que des outils d'annotation web existent depuis des lustres, mais UxNote a choisi le stockage 100% local (via le localStorage) plutôt que de monter un backend avec des comptes utilisateurs. Et c'est ce qui fait toute la différence niveau simplicité, avec les autres outils.

Par contre attention, si votre client vide son cache navigateur, il perd ses annotations... Perso je vous recommande donc de faire l'export JSON dès que possible pour éviter les mauvaises surprises.

L'outil propose aussi un mode "assombrissement" qui met en évidence la zone annotée (pratique pour se concentrer), des couleurs personnalisables, et même la possibilité de bloquer certains éléments de l'annotation avec l'attribut data-uxnote-ignore. Ça fonctionne sur les environnements de staging, en local, et même sur les SPA ... sauf si vous avez une CSP ultra stricte, auquel cas faudra autoriser le script et les styles inline dans votre config.

Bref, si vous bossez avec des clients qui ont du mal à exprimer leurs retours autrement qu'en pièces jointes de 15 Mo, UxNote pourrait bien sauver les quelques cheveux qu'il vous reste. Et en plus c'est gratuit, open source et disponible sur GitHub .

Que demande le peuple ???

Merci Benjamin !