La cour d'appel de Paris vient de confirmer que les fournisseurs de DNS alternatifs doivent bloquer l'accès aux sites de streaming et d'IPTV pirates. Google, Cloudflare et Cisco ont perdu leur appel face à Canal+.
La cour d'appel de Paris a tranché cinq affaires distinctes dans lesquelles Canal+ demandait à Google (Google Public DNS), Cloudflare (1.1.1.1) et Cisco (OpenDNS) de bloquer des centaines de noms de domaine liés à du streaming illégal. Les trois entreprises avaient fait appel des ordonnances rendues en première instance par le tribunal judiciaire de Paris.
C'est la première fois qu'une cour d'appel française valide ce type de blocage DNS en s'appuyant sur l'article L.333-10 du Code du sport, qui permet aux détenteurs de droits d'exiger le blocage de domaines en cas de piratage grave et répété.
Cloudflare et Cisco avaient plaidé que leurs services avaient une fonction "neutre et passive", comparable à un annuaire qui traduit des noms de domaine en adresses IP. La cour a estimé que cette neutralité était tout simplement hors sujet : ce qui compte, c'est la capacité technique à bloquer un accès, pas la nature du service.
Google a tenté un autre angle en expliquant que le blocage DNS était inefficace puisqu'il suffit d'un VPN pour le contourner. La cour a balayé l'argument en rappelant que tout système de filtrage peut être contourné, et que ça ne le rend pas inutile pour autant.
Cisco avait aussi chiffré le coût de mise en place à 64 semaines-personne de travail. Pas suffisant non plus pour convaincre les juges.
Cette décision s'ajoute à celle obtenue contre les fournisseurs de VPN fin 2025, quand NordVPN, ExpressVPN et d'autres avaient eux aussi été contraints de bloquer des sites pirates en France.
Canal+ verrouille progressivement tous les moyens de contournement. Et la chaîne ne compte visiblement pas s'arrêter là : le blocage d'adresses IP serait déjà en test, avec un premier essai lors de Roland-Garros.
Les frais de mise en place sont à la charge de Google, Cloudflare et Cisco.
Canal+ est en train de poser des briques une par une. D'abord les FAI, puis les VPN, maintenant les DNS. On imagine bien que le blocage IP est la prochaine étape.
Côté efficacité, ça reste un jeu du chat et de la souris, mais la justice française envoie un signal clair : si un service technique peut aider à bloquer du piratage, il devra le faire. Et à ses frais, en plus.
Source : Torrent Freak
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.
Pendant près de quatre décennies, Arm Holdings a bâti sa fortune en concédant ses architectures à des tiers — Apple, Nvidia, Qualcomm parmi tant d’autres. Jamais la société britannique n’avait fabriqué de puce sous son propre nom. Ce modèle vient de basculer. Lors d’un événement organisé mardi à San Francisco, Arm a dévoilé l’Arm AGI ... Lire plus
L'article Arm Holdings franchit le Rubicon : après 35 ans de licences, le géant des semi-conducteurs produit son propre processeur est apparu en premier sur Fredzone.Pour faire tourner du JavaScript côté serveur, y'a pas que Node.js dans la vie. Y'a maintenant
workerd
(prononcez "worker-dee"), qui est le runtime open source de Cloudflare, celui-là même qui fait tourner les Workers en prod (le service tourne depuis 2017, le runtime est open source depuis 2022), et que vous pouvez l'installer sur votre Debian, votre Mac ou même votre PC Windows avec un simple npx.
Mais alors pourquoi s'embêter avec un énième runtime JS ?
Hé bien parce que celui-ci n'est pas un runtime généraliste. C'est un vrai serveur HTTP pur et dur, basé sur le moteur V8 de Chrome, conçu pour recevoir des requêtes et y répondre. Pas de filesystem, pas d'accès disque sauvage... ici, votre code vit dans un isolate V8, bien cloisonné, et communique avec l'extérieur uniquement via des bindings explicites qu'on appelle des "capabilities". En gros, votre Worker ne peut accéder qu'aux ressources qu'on lui a branchées dans son fichier de config Cap'n Proto .
Et cela a plein d'avantages ! Par exemple, les attaques SSRF classiques c'est mort ! Et n'oubliez pas que c'est du JavaScript pur, donc y'a pas d'affreux require('fs') ni de child_process qui traîne.
Et le concept qui tue, ce sont les nanoservices. En fait, faut imaginer des microservices, mais qui tournent tous dans le même processus Linux, sur le même thread. Comme ça quand un nanoservice en appelle un autre, y'a zéro latence TCP, c'est un juste appel de fonction local !
Et vous pouvez en faire tourner des centaines sur un seul serveur parce que les API sont implémentées en C++ natif et tous les isolates V8 partagent le même code compilé en mémoire. C'est carrément pas intuitif, mais visiblement, ça tient la route.
Côté rétrocompatibilité, c'est cool puisque chaque Worker déclare une "date de compatibilité" dans son fichier .capnp. Comme ça, vous fixez compatibilityDate = "2024-06-15" et le runtime vous garantit que les API fetch() et WebCrypto se comporteront toujours comme à cette date-là, même si le binaire a été recompilé 200 fois depuis. Des releases sortant tous les jours, cette garantie n'est pas anecdotique !
Cap'n Proto, un format de sérialisation binaire créé par Kenton Varda, le même gars qui est derrière Protocol Buffers chez Google (excusez du peu). C'est un poil déroutant au début si vous êtes habitués au YAML ou au JSON, mais c'est très efficace et hyper rapide. Et pour ceux qui bossent déjà avec l'écosystème Cloudflare parce que vous avez l'Amérique qui coule dans les veines, sachez le runtime s'intègre nickel avec l'outil CLI Wrangler pour le dev local.
Par contre, attention, ce n'est PAS un sandbox sécurisé. Cloudflare le dit cash : si vous faites tourner du code potentiellement malveillant, faudra l'isoler dans une VM KVM ou un conteneur Docker. Hé oui les amis, en prod chez Cloudflare, y'a des couches de sécurité supplémentaires (isolation kernel Linux, patching V8 en urgence, segmentation par profil de risque) que le runtime seul ne fournit pas.
Le problème, c'est surtout Spectre et les bugs du moteur V8... car ça reste du code C++ compilé avec clang derrière. Après, pour du self-hosting de vos propres Workers sur votre VPS Ubuntu, c'est largement suffisant.
Maintenant pour tester concrétement c'est mui rapido.
Connexionnpx workerd serve config.capnp
Vous écrivez un petit hello.js avec un addEventListener("fetch"), et hop, vous avez un serveur HTTP prêt à répondre sur le port 8080 de votre localhost. Et le truc sympa, c'est qu'on peut aussi l'utiliser comme proxy HTTP programmable !
Comme ça, au lieu de configurer des règles nginx ou Apache absconses, vous écrivez du JavaScript standard avec des Request et Response pour intercepter et router vos requêtes. Franchement, pour du reverse proxy avec de la logique métier, c'est quand même plus lisible que du location ~ ^/api/(.*)$. ^^
D'ailleurs, côté API, tout est basé sur les standards W3C : fetch(), URL, WebCrypto, TextEncoder, les classiques quoi. Donc si vous savez écrire du JS pour Firefox ou Chrome, vous savez écrire pour le moteur des Workers. Pas de modules propriétaires bizarres, contrairement à Node.js et tous ses packages http, net, stream...
Bref, c'est costaud, c'est gratuit, et ça tourne partout, avec un dossier samples/ plein de configs prêtes à l'emploi.
Allez, je vous libère, vous pouvez foncer tester ça !!
Crawler un site entier, ça devrait pas être aussi compliqué. Et pourtant, entre les scripts maison qui cassent tous les 2 jours et les headless browsers qui bouffent de la RAM comme pas permis, c'est assez la galère ! Du coup, Cloudflare, dans sa grande bonté (lol) vient de sortir un endpoint /crawl (en open beta) dans la section Browser Rendering qui simplifie tout ça... vous balancez une URL dessus et hop, ça ASPIRE tout le site (oui oui).
En gros, vous envoyez une requête POST avec l'URL de départ, et le service se charge de découvrir les pages (via le sitemap, les liens internes, ou les deux), de les générer dans un navigateur headless, et de vous renvoyer le contenu en HTML, Markdown ou même en JSON structuré grâce à Workers AI. Le tout de manière asynchron ! Vous, vous récupérez juste un job ID et vous revenez plus tard chercher les résultats quand c'est prêt.
Avant toute chose, il vous faut un token API Cloudflare avec la permission "Browser Rendering - Edit". Rendez-vous dans votre dashboard Cloudflare, section API Tokens, et créez-en un nouveau. Notez aussi votre Account ID (visible dans l'URL du dashboard ou dans la section Overview de n'importe quel domaine).
Là, ensuite c'est hyper simple. Un seul appel curl suffit :
curl -X POST "https://api.cloudflare.com/client/v4/accounts/VOTRE_ACCOUNT_ID/browser-rendering/crawl" \
-H "Authorization: Bearer VOTRE_TOKEN" \
-H "Content-Type: application/json" \
-d '{"url": "https://example.com"}'
Et là, vous récupérez un job ID en retour (genre c7f8s2d9-a8e7-4b6e-...). Par défaut, le crawler va explorer 10 pages max avec une profondeur quasi illimitée. Mais bon, 10 pages c'est vite limité, du coup vous pouvez ajuster tout ça comme ceci :
curl -X POST "https://api.cloudflare.com/client/v4/accounts/VOTRE_ACCOUNT_ID/browser-rendering/crawl" \
-H "Authorization: Bearer VOTRE_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/docs",
"limit": 50,
"depth": 3,
"formats": ["markdown"],
"render": false,
"options": {
"includePatterns": ["https://example.com/docs/**"],
"excludePatterns": ["**/changelog/**"]
}
}'
Le paramètre render: false permet de récupérer le HTML brut sans lancer de navigateur headless, c'est carrément plus rapide pour les sites statiques. Sachez quand même que pendant la beta, ce mode n'est pas facturé ! Youpi !
Une fois le crawl lancé, vous interrogez le job avec un GET :
curl "https://api.cloudflare.com/client/v4/accounts/VOTRE_ACCOUNT_ID/browser-rendering/crawl/VOTRE_JOB_ID" \
-H "Authorization: Bearer VOTRE_TOKEN"
Vous obtenez alors le statut (running, completed, errored...) et la liste des pages crawlées avec leur contenu dans le format demandé. Si le résultat dépasse 10 Mo, un curseur de pagination est inclus pour récupérer la suite.
Y'a quelques paramètres bien pensés pour les cas plus avancés :
modifiedSince et maxAge pour du crawling incrémental (ne re-crawler que les pages modifiées récemment)source: "sitemaps" pour ne suivre que le sitemap au lieu de parser tous les liensjsonOptions avec un prompt Workers AI pour extraire des données structurées automatiquement (genre récupérer le nom, le prix et le stock de 500 fiches produit d'un e-commerce en une seule passe)rejectResourceTypes pour bloquer images, fonts et CSS et accélérer le crawlauthenticate pour les sites protégés par une auth HTTP basiqueAttention quand même, y'a quelques subtilités à savoir. Un job peut tourner 7 jours max et les résultats sont conservés 14 jours seulement, du coup pensez à les récupérer vite. Le crawler respecte le robots.txt (y compris le crawl-delay), et si un site vous bloque, les URLs apparaissent comme "disallowed" dans les résultats. Sauf que ça ne vous dit pas pourquoi, faudra aller checker le robots.txt vous-même.
Voilà, cette "merveille" pour les scrappeurs fous est dispo sur les plans Free et Paid de Workers , et si vous voulez aller plus loin, Cloudflare propose aussi des endpoints pour les screenshots, les PDF et le scraping ciblé .
Voilà, un petit crawler inclus dans le plan Free de Workers, qui respecte le robots.txt et qui sort du Markdown ou du JSON structuré... je vais surveiller ça de près !
