Si vous avez un site, vous savez déjà qu'il faut l'optimiser et le rendre lisible pour Google. Mais en ce moment, Cloudflare pousse vraiment une toute autre couche par-dessus : le rendre lisible pour les agents IA. Et pour vérifier si vous êtes dans les clous, l'équipe a sorti isitagentready.com , un scanner gratuit qui vérifie ça en quelques secondes.

Vous tapez tout simplement votre URL, et le scanner check une dizaine de standards émergents, puis pour chaque truc qui manque, il vous crache carrément un prompt prêt à coller dans Claude Code, Cursor ou Windsurf pour qu'il vous aide à l'implémenter. Vous pouvez aussi customiser le scan en cochant uniquement ce qui vous intéresse, selon que votre site est plutôt un blog de contenu ou une API.

L'interface annoncée par Cloudflare pour son nouveau scanner agent-ready

Les checks sont organisés en 5 catégories : la découvrabilité (robots.txt, sitemap, Link headers HTTP), l'accessibilité du contenu (markdown negotiation, llms.txt), le contrôle et la signalisation des bots (Content Signals, Web Bot Auth, règles IA dans robots.txt), la découverte de protocoles (MCP Server Card, Agent Skills, API Catalog, OAuth) et le commerce agentique (x402, MPP, UCP, ACP). Chaque catégorie pèse alors dans le score final, sauf le commerce qui est juste checké mais pas scoré.

J'ai testé sur korben.info et le résultat est franchement mitigé. Côté positif : robots.txt présent avec Content Signals (search=yes, ai-train=no, donc je dis oui à l'indexation et non à l'entraînement IA), llms.txt opérationnel avec 111 lignes en français, markdown negotiation qui répond bien sur Accept: text/markdown, sitemap.xml en place, et GPTBot, Google-Extended et Meta bloqués explicitement.

Côté manquant : pas de MCP Server Card, pas d'Agent Skills, pas d'API Catalog, pas de Link headers.

Score estimé : très moyen, et c'est plutôt cohérent avec un site qui n'a pas besoin d'OAuth ni de serveur MCP.

Cloudflare balance surtout des chiffres bien concrets dans son article de lancement . Sur les 200 000 domaines les plus visités du web, 78% ont un robots.txt, 4% déclarent leurs préférences via Content Signals, 3.9% font de la markdown negotiation, et moins de 15 (oui, quinze) ont un MCP Server Card ou un API Catalog combinés. Autant dire qu'on est très tôt dans la partie. Côté boite à outils, dans le panel d'agents testé par Cloudflare, seuls Claude Code, OpenCode et Cursor envoient un Accept: text/markdown par défaut quand ils browsent le web. Les autres récupèrent du HTML par défaut, comme un navigateur classique.

Cloudflare a aussi mesuré l'impact sur sa propre doc en activant tous ces standards : 31% de tokens en moins consommés et 66% de réponses plus rapides. Du coup c'est pas négligeable, surtout quand vous payez les agents au token. Et bonus, isitagentready.com lui-même est agent-ready (forcément), avec son propre serveur MCP exposé à /.well-known/mcp.json et un outil scan_site disponible pour les agents qui veulent l'appeler en autonomie.

Mais attention au piège ! Si on traite tout pour viser le "tout vert" comme objectif, beaucoup de sites finiront par prétendre être des fournisseurs OAuth ou des serveurs MCP juste pour cocher la case. Donc mieux vaut dire honnêtement "non, ça je ne fais pas" que de faire semblant. Pour un blog perso, vous n'avez probablement pas besoin de l'API Catalog ni du serveur MCP. Pour un site e-commerce par contre, x402 et l'Agentic Commerce Protocol vont commencer à compter le jour où les agents paieront vraiment pour leurs utilisateurs.

Petit détail historique amusant, le robots.txt date de 1994 (j'avais 12 ans, j'étais à fond sur le PC mais pas encore sur le net) et le code HTTP 402 Payment Required existe depuis 1997 mais n'a jamais été massivement utilisé. Jusqu'au jour où Cloudflare et Coinbase se sont associés pour le ressusciter avec x402, en l'imaginant comme la couche de paiement entre humains, agents et services. On verra bien si leur mayonnaise va prendre...

Aujourd'hui l'adoption de tout cela est embryonnaire, mais rappelez-vous qu'en 2004 peu de monde aurait parié sur l'industrie SEO qu'on connaît aujourd'hui. Donc ça vaut le coup d'y jeter un œil maintenant.

Merci à Camille Roux pour le lien !

Source

Distribuer des paquets binaires en WebAssembly, c'est galère. Vous téléchargez le .tar.gz, vous le gunzippez, vous l'extrayez en mémoire... et ça rame sévèrement !! Mais youpi, Jeroen Ooms (qui contribue à webR et bosse chez ROpenSci) vient de publier tar-vfs-index , un petit npm package qui casse cette malédiction des enfers en sautant carrément l'étape extraction.

L'astuce est toute bête ! Au lieu d'extraire l'archive, on génère un fichier d'index qui liste la taille et l'offset de chaque fichier dans le tar. Du coup le navigateur n'a plus qu'à monter le blob du tar comme un système de fichiers virtuel, et chaque lecture devient alors un simple slice du blob à la bonne position. Pas d'extraction donc, mais juste du slicing à la demande !

Sous le capot, ça repose sur 3 propriétés alignées. 1/ le format tar est un layout plat : une suite de headers de 512 octets suivis des données du fichier, le tout contigu et adressable à l'octet près. 2/ Emscripten propose un backend filesystem appelé WORKERFS, prévu pour servir les lectures d'un Blob sans le copier dans le heap WASM. Et 3/ les navigateurs ont une API native, DecompressionStream , qui gunzippe efficacement pendant le téléchargement.

Concrètement, vous installez le truc avec npm install tar-vfs-index (y'a aucune dépendance externe) puis vous lancez npx tar-vfs-index archive.tar.gz. Et hop, le package vous sort un JSON dans ce genre :

{
 "files": [
 { "filename": "mypackage/DESCRIPTION", "start": 512, "end": 548 },
 { "filename": "mypackage/R/code.R", "start": 1536, "end": 1563 }
 ],
 "remote_package_size": 3072
}

const [metaRes, dataRes] = await Promise.all([
 fetch('archive.tar.gz.json'),
 fetch('archive.tar.gz'),
]);
const metadata = await metaRes.json();
const blob = await new Response(
 dataRes.body.pipeThrough(new DecompressionStream('gzip'))
).blob();
FS.mkdir('/pkg');
FS.mount(WORKERFS, { packages: [{ metadata, blob }] }, '/pkg');

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