Connexion
Canal+ réclamait tout de même 50 000 euros par jour et par site "pirate" encore accessible, et il repart sans rien. Le 17 septembre dernier, le tribunal judiciaire de Paris a rejeté les astreintes demandées contre Cloudflare dans deux dossiers, l'un sur la Formule 1, l'autre sur le MotoGP, ainsi que les 20 000 euros de frais de justice qu'il réclamait en plus.
En avril, ce même tribunal avait tout de même ordonné à Cloudflare de bloquer 21 domaines de streaming F1 et 16 de MotoGP "par tout moyen efficace". Et Cloudflare a choisi le sien : un blocage sur son CDN, pour les sites qui passent par son réseau, et aucun filtrage sur son résolveur DNS public 1.1.1.1. Pas de DNS menteur ou censuré donc... mais Canal+ y voyait un contournement délibéré, puisque seuls 3 domaines sur 21 auraient été bloqués côté F1 (et 3 sur 16 côté MotoGP), dont deux sont revenus en ligne la semaine suivante via un autre CDN ou un site miroir.
Mais le tribunal n'a pas suivi. Selon lui, un intermédiaire technique a une obligation de moyens mais pas de résultat, comme le précise l'arrêt UPC Telekabel de la Cour de justice de l'Union européenne. Cela veut donc dire que Cloudflare ne peut pas être tenu responsable quand un site change de CDN. C'est donc à Canal+ d'aller voir le nouvel intermédiaire et de signaler les miroirs à l'Arcom.
Alors, est-ce que 1.1.1.1 filtre des sites en France ?
Eh bien non les amis, et ça se vérifie très facilement en quelques secondes. Depuis ma connexion bien française, le résolveur de Google (8.8.8.8) refuse de résoudre les domaines de la liste "Premier League" ordonnée en juillet, avec un message qui invoque "une injonction judiciaire ou toute autre mesure administrative de blocage visant FR".
Alors que le 1.1.1.1 de Cloudflare, lui, répond normalement pour les sites encore en ligne. D'ailleurs Cloudflare le confirme bien dans son rapport de transparence du second semestre 2025 : Aucun contenu n'a jamais été bloqué via 1.1.1.1, car un blocage sur un résolveur public mondial s'appliquerait à tous ses utilisateurs, où qu'ils se trouvent.
Après ça ne veut pas dire que changer de DNS suffira à tout débloquer puisque le géoblocage que Cloudflare applique côté CDN limite l'accès au site lui-même depuis la France. Donc passer par 1.1.1.1 n'y changera rien, un site bloqué sur le CDN de Cloudflare ne sera pas accessible via leurs serveurs DNS. Mais par contre, les sites qui passent entre les mailles, ce sont tous les sites hébergés ailleurs que chez Cloudflare, que les FAI bloquent chacun de leur côté, en faisant "mentir" leurs propres résolveurs DNS.
Reste que ce jugement n'a rien d'une carte blanche... Quand Cloudflare explique que l'architecture de son DNS public ne permet pas d'implémenter un blocage, le tribunal se contente d'écrire qu'il "allègue". Mais en réalité, la cour d'appel de Paris avait jugé en mars dernier que le blocage DNS était tout à fait faisable. Et en juillet, dans un dossier sur des médias russes sous sanctions européennes, le Conseil d'État avait relevé que Cloudflare propose déjà gratuitement un résolveur capable de bloquer les logiciels malveillants et les contenus pour adultes...
Voilà, donc comme les ordonnances signées le 17 juillet pour la Premier League et la Ligue des champions visaient nommément le résolveur, le CDN et le reverse proxy de Cloudflare, et qu'elle laissait à l'entreprise américaine le choix des moyens techniques, la messe est dite. Et on n'oublie pas non plus que de son côté, Quad9, la fondation suisse qui ne bloque aucun des domaines visés par beIN Sports, est également sous pression de la part de la chaine de sport qui lui réclame 10 000 euros par jour et par domaine pirate accessible. La décision est attendue d'ici la fin du mois...
Dans tous les cas, si vous êtes sur 1.1.1.1, rien ne bouge pour l'instant... mais ça tient moins à Cloudflare qu'à la façon dont les prochaines ordonnances seront rédigées... On verra bien.
Source : TorrentFreak
Cloudflare a sorti il y a petit moment maintenant une commande que pas mal de dev utilisent et dont je vais vous parler aujourd'hui : cloudflared tunnel --url, qui permet de publier un serveur tournant sur votre machine à une adresse en trycloudflare.com, sans avoir besoin de compte, de nom de domaine et surtout sans avoir à ouvrir le moindre port sur votre box toute pourrie.
Et la petite nouveauté depuis quelques jours, c'est que, autant avant, n'importe qui possédant le lien pouvait se connecter à votre service, mais maintenant, Cloudflare a mis en place une option qui permet de réserver ce lien à quelques adresses e-mail que vous définissez.
Ce service s'appelle les Quick Tunnels, et pour en profiter, il vous faudra juste un service web qui tourne en local (moi je vais faire ça sur le port 8080 comme d'hab) avec une page de test toute bête servie par Python. Voilà c'est juste de quoi vérifier que tout passe bien avant d'y brancher un vrai projet. Et si vous faites bosser des agents IA avec ce truc, on verra aussi comment mettre un garde-fou pour éviter l'exposition sur le web de trucs pas prévus ! Argh !!
cloudflared, c'est le petit connecteur open source de Cloudflare, celui qui établit la connexion sortante vers leur réseau. Sur Mac, pour l'installer c'est fastoche, suffit d'utiliser Homebrew :
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) brew install cloudflared
Sous Debian ou Ubuntu, passez par conte par le dépôt officiel de Cloudflare. Il a changé de clé de signature récemment, donc reprenez bien ces commandes plutôt que celles d'autres vieux tutos qui traînent :
sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main' | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt-get update && sudo apt-get install cloudflared
Et sous Windows (les courageux !! lol), la page de téléchargement de Cloudflare propose un MSI ou un exécutable, en 32 ou 64 bits, et le paquet existe aussi chez winget sous l'identifiant Cloudflare.cloudflared. Dans tous les cas, vérifiez ensuite la version, car l'option d'authentification dont on va parler plus bas n'arrive qu'à partir de la version 2026.9.3 :
cloudflared --version
Tout d'abord, lancez votre serveur local, puis dans un autre terminal, faites :
cloudflared tunnel --url http://localhost:8080
Au bout de quelques secondes, cloudflared affichera un encadré avec une adresse aléatoire composée de quatre mots, du genre quelque-chose-truc-bidule.trycloudflare.com, en prévenant qu'elle peut mettre un moment à répondre. Donc soyez un peu patient, le temps que le DNS résolve ce truc (et
videz votre cache DNS
si ça veut vraiment pas le faire).
Ensuite, ouvrez cette URL depuis un autre appareil, genre votre téléphone en 4G par exemple et hop, vous tomberaz sur votre serveur local. Et si vous voulez tout couper, un petit Ctrl+C dans le terminal et c'est fini ! Pas de panique, au prochain lancement de cloudflared, vous aurez une nouvelle adresse.
La commande de base, et le cadre où cloudflared affiche l'adresse trycloudflare.com à partager
Notez aussi que le port n'est pas imposé puisque --url accepte tout ce que cloudflared peut joindre, une adresse IP de votre réseau local comprise. Par contre, si votre projet tourne sous Vite, vous allez prendre un "Blocked request" en pleine tronche, car Vite ne répond par défaut qu'à localhost, aux domaines en .localhost et aux adresses IP. La parade la plus simple consiste donc à faire croire à Vite qu'on l'appelle via localhost:5173 en faisant comme ceci :
cloudflared tunnel --url http://localhost:5173 --http-host-header localhost:5173
L'autre solution, c'est d'ajouter l'hôte dans le réglage server.allowedHosts de Vite. Mais évitez de passer ce réglage à true pour aller plus vite, en effet
la doc de Vite
le déconseille puisque ça expose votre serveur de dev à des attaques par DNS rebinding. Oupsi oups !
Gardez aussi en tête que c'est un outil de test et de démo et que c'est pas fait pour de la prod. Si on en croit la doc , Cloudflare ne garantit aucune disponibilité, sans oublier que chaque tunnel encaisse au max 200 requêtes en simultanné (au-delà, ça vous fera une erreur 429 ) et les Server-Sent Events ne passeront pas. Voilà, donc si vous voulez un nom fixe et du vrai trafic, il faudra plutôt créer un tunnel nommé à partir d'un vrai compte Cloudflare et d'un domaine de votre choix.
Et maintenant, pour limiter l'accès à votre service à quelques personnes, ajoutez --allowed-mail suivi de l'adresse email de celui à qui vous voulez montrer votre merveilleux boulot :
cloudflared tunnel --url http://localhost:8080 --allowed-mail korben@example.com
L'encardré change alors de "ton" en vous annonçant que le tunnel est "protégé" par une authentification de type code à usage unique via Cloudflare Access, ainsi que la quantité d'adresses autorisées. Les adresses elles-mêmes n'apparaissent nulle part, même dans la ligne des réglages où elles sont remplacées par des astérisques, ce qui est plutôt bien vu si vous faites une démo en mode partage d'écran. Ça évite les fuites de données perso !
Avec --allowed-mail, le cadre annonce le code à usage unique et le nombre d'adresses autorisées, sans jamais les afficher
Vous pouvez ensuite répéter l'option autant de fois que nécessaire, séparer plusieurs adresses par des virgules, ou autoriser tout un domaine. Mettez simplement des guillemets autour du "joker" (c'est l'étoile) pour que votre misérable shell ne tente pas de l'interpréter comme un gros teubé :
cloudflared tunnel --url http://localhost:8080 \
--allowed-mail korben@example.com \
--allowed-mail bob@example.com \
--allowed-mail '*@example.com'
Côté Wrangler, si vous bossez sur Workers, un petit npx wrangler tunnel quick-start acceptera la même option :
npx wrangler tunnel quick-start http://localhost:8080 --allowed-mail korben@example.com
De son côté, votre invité VIP n'aura alors plus qu'à ouvrir l'URL que vous lui avez donné et cloudflared renverra son browser vers login.trycloudflare.com. Il tombera alors sur une page Cloudflare Access qui lui demandera son adresse mail. Il recevra ensuite un code dans sa boîte, devra le taper, et arrivera enfin (ouf !!) sur votre merveille application probablement vibe codée (lol).
Et quelqu'un qui n'est pas sur la liste des invité ne verra quand à lui qu'une réponse de base lui expliquant qu'il peut bien aller se faire voir (et sa requête n'atteindra jamais votre application).
Ce que voit votre invité en ouvrant l'URL protégée : la page Cloudflare Access qui lui demande son adresse mail
Et votre liste d'emails, elle, n'est jamais diffusée hors de votre ordi puisque Cloudflare vérifie seulement que la personne contrôle l'adresse qu'elle a saisie. Ensuite c'est cloudflared qui compare les accès en mémoire, avec ce que vous avez tapé. Une fois entré, le visiteur gardera alors sa session jusqu'à 4 heures max.
Et si vous voulez modifier cette liste d'accès, il faudra alors arrêter le tunnel et en relancer un autre, ce qui coupera l'accès à tout le monde et vous donnera une nouvelle adresse à renvoyer. Donc soyez sûr de votre coup avant de casser la tête aux gens qui vont tester votre appli.
Sachez aussi que cette vérification ne pourra se faire qu'avec un vrai navigateur et pas des trucs du genre un webhook Stripe, un GitHub, un script en curl ou encore n'importe quel client automatique qui restera coincé devant cette page de connexion.
Pour ces cas-là précieusement, je vous recommande plustôt d'ouvrir un tunnel public le temps du test et de le couper juste après. Et si le webhook doit tourner durablement, passez sur un tunnel nommé avec Cloudflare Access, sur votre propre domaine.
Maintenant, parlons un petit peu à agents IA parce que oui... Un agent de code a besoin d'un endroit pour vous montrer ce qu'il vient de faire de beau, et Cloudflare décrit justement ce cas de figure dans son article.
Pour éviter qu'un agent IA ne diffuse publiquement ce qu'il vient de faire à la vue de tous, ce que recommande Cloudflare, c'est donc d'ajouter une ligne dans le fichier d'instructions de l'agent AGENTS.md comme ceci :
Quand tu lances un Quick Tunnel, ajoute toujours --allowed-mail moi@exemple.fr.
Sauf qu'une consigne reste une consigne... C'est un prompt que l'agent peut choisir d'ignorer... Donc gardez bien en tête que ces fichiers sont traités comme du contexte et pas comme une configuration imposée.
Maintenant, si vous voulez vraiment bloquer une action, peu importe ce que décide le modèle, ce que je vous recommande d'utiliser à la place, c'est un hook "PreToolUse". Moi, j'en mets partout dans mes configs Claude Code pour plus de sécurité.
Si vous ne savez pas ce qu'est un hook, en fait c'est un petit script contenant la commande en JSON, et que Claude Code lance avant chaque commande bash. Si ce script se termine avec le code "2" l'appel est alors bloqué. Pour faire ça, il faut donc créer dans le dossier .claude/hooks/ de votre projet, le script suivant :
#!/bin/bash
# .claude/hooks/tunnel-protege.sh
COMMAND=$(jq -r '.tool_input.command')
if echo "$COMMAND" | grep -qE 'cloudflared.*tunnel.*--url|wrangler.*tunnel.*quick-start' \
&& ! echo "$COMMAND" | grep -q -- '--allowed-mail'; then
echo "Quick Tunnel public refusé : ajoutez --allowed-mail, ou demandez-moi d'abord." >&2
exit 2
fi
exit 0
Puis rendez-le exécutable avec chmod +x, et installez jq si vous ne l'avez pas encore fait.
Déclarez-le ensuite dans le .claude/settings.json du projet, sur l'outil Bash comme ceci :
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/tunnel-protege.sh"
}
]
}
]
}
}
Maintenant, si ça vous prend trop le chaud de faire ça, sachez que j'ai fait un petit kit à télécharger ici, pour les Patreons :
Ensuite, à partir de là, un cloudflared tunnel --url ou un wrangler tunnel quick-start lancé sans le paramètre --allowed-mail ne fonctionnera pas, et l'agent recevra le message du hook qui lui dira d'ajouter l'option ou de vous demander s'il doit y avoir un contournement.
Et bien sûr, un tunnel nommé lancé avec cloudflared tunnel run, lui, passera normalement.
Comme d'hab, ce genre de garde-fou a ses limites, puisqu'il ne lit que le texte de la commande et ne vérifiera pas l'adresse qui suit l'option. Il ne verra non plus les tunnels qui pourraient être lancés depuis un script ou à l'aide d'une variable d'environnement TUNNEL_URL, qui permet aussi de lancer un Quick Tunnel. Voilà, donc laissez la consigne dans AGENTS.md en plus du hook, au cas où... Les deux devraient bien se compléter.
Pour les soutiens Patreon , le kit ci-dessus reprend donc ce hook avec les consignes à coller dans AGENTS.md, dont l'exception des clients automatiques (l'agent vous demande au lieu de retirer l'option).
Il y a aussi là dedans un script qui lance le tunnel protégé et ne renvoie que son adresse. Et si vous préférez scripter ça vous-même, partez de --output json, qui transformera chaque ligne du log en objet JSON. L'adresse sera alors accessible dans le champ message, et vous pourrez alors l'extraire avec une expression régulière.
Ah et un dernier point avant de lâcher un agent là-dessus sur le portable de votre boulot, je vous invite à lire ce que Proofpoint a documenté concernant des campagnes de malware qui s'appuient sur ce genre de tunnels gratuits. Ça explique pourquoi des outils de sécurité comme Elastic ont des règles qui repèrent cloudflared quand il est utilisé pour exposer un service local. Leur conseil c'est de bloquer les domaines de tunnel quand l'usage n'est pas autorisé, donc si vous comptez utiliser ça dans votre boite, allez voir Dieu Tout Puissant (le sysadmin grognon quoi...) pour lui demander l'autorisation. Il va pester, souffler, éventuellement vous cracher dessus puis finira probablement par accepter, donc pas d'inquiétude ^^.
Et comme la protection par mail est gratuite, au même titre que les Quick Tunnels eux-mêmes, je ne vois aucune raison valable de balancer une démo accessible sur le web sans utiliser cette authentification.
Cloudflare a mis en ligne sur son GitHub un skill trop super génial d'audit de sécurité qui leur a servi de point de départ à leur propre système de chasse aux failles de sécu. Ce package pour faire des audits de sécu boostés à l'agent IA c'est un dossier de consignes en Markdown que vous déposez dans votre agent de code, et qui le fait bosser comme un vrai auditeur et pas simplement comme un "relecteur" de code.
Dans ce dépôt, vous trouverez un fichier par famille d'attaque : la corruption mémoire, l'injection de prompt, le cadrage des requêtes HTTP, l'isolation entre locataires. Et avec ça, un schéma JSON qui décrit à quoi doit ressembler un rapport, et deux validateurs écrits en JavaScript sans la moindre dépendance.
Le dossier du skill sur GitHub : un fichier de consignes par famille d'attaque, et les deux validateurs en bas de liste ( Source )
L'agent déroule ensuite six phases, de la reconnaissance au rapport final. Il commence par cartographier l'architecture, les frontières de confiance et les points d'entrée, puis il écrit sa propre grille de couverture. Ensuite il envoie des chasseurs isolés case par case et chaque piste qui remonte part chez un vérificateur tout frais tout beau qui n'a pas participé à la chasse.
Chaque piste se termine ensuite avec un rapport technique. Un rapport confirmed qui exige une trace source complète et un résultat réellement observé. Un rapport needs_validation qui nomme le fait précis qui manque, et surtout qui n'a droit à aucun niveau de gravité. Et le rapport des rejected qui garde la mémoire de ce qui a été réfuté, pour que la passe suivante ne vous ressorte pas la même chose.
Le validateur, lui, c'est du vrai code qui vérifie la "forme" de la preuve. Les empreintes doivent être uniques, et le suivi du parcours des tests qui doit partir d'un point d'entrée pour finir sur un point d'impact. Ainsi une trouvaille confirmée dont le parcours ne tient pas debout est recalée.
En revanche, sachez-le, l'indépendance du vérificateur est demandée dans les consignes, mais pas contrôlée (chez Cloudflare, c'est leur orchestrateur maison qui s'en charge, et il n'est pas dispo publiquement).
Cloudflare explique sur son site ce que donne un de ces agents lâché sur du code sans garde-fou. Il modifie la source pour que son exploit fonctionne, puis il annonce fièrement le bug qu'il vient de créer lui-même. Ou alors il pond un test qui démontre que exec() exécute des choses, donc que c'est forcément une faille critique... Et ça vous l'aurez compris, c'est de la merde et c'est absolument ce qu'on ne veut pas.
Voilà donc exactement ce que ces consignes cherchent à lui interdire.
Pour l'installer, il vous faut le CLI skills de Vercel Labs :
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit
Ensuite, vous lancez votre agent dans le dépôt à auditer et vous lui demandez un audit de sécurité. Le skill se déclenche tout seul et c'est le modèle de votre agent qui pilotera les sous-agents en parallèle (utilisez donc un modèle qui sache faire ça, c'est mieux lool). Par défaut, le rapport atterrit ensuite dans un dossier ~/security-audit-skill, en dehors du dépôt audité.
Ce qui est cool c'est que ce skill est conçu pour limiter les bêtises. Par exemple il refuse d'exécuter le code qu'il audite s'il n'a pas de bac à sable (sandbox) imposé par le système d'exploitation, avec le réseau coupé, la cible en lecture seule et des limites de CPU et de mémoire. Ce bac à sable, le dépôt ne le fournit pas, et c'est à vous de le mettre en place avec par exemple
un outil d'isolation comme Fence
. Sans lui, la piste de l'audit finira tout bonnement en needs_validation au lieu d'être véritablement suivie et tranchée.
Après, c'est le temps qui fera la différence. Chez Cloudflare, ils ont un gros système qui leur permet, par exemple avec un dépôt d'environ 30 000 lignes de code, de ne passer que 3 à 4 heures sur l'audit pour avoir un résultat correct. Mais chez vous, en local, ce sera beaucoup plus long. Cloudflare prévient aussi qu'une seule passe n'est pas suffisante puisqu'elle trouve à peu près la moitié des failles à chaque fois. Il faudra relancer ça plusieurs fois.
Allez, si vous cherchez également un filet de sécurité pour tout ce qui concerne vos pull requests, sachez qu'Anthropic maintient de son côté un reviewer de sécurité pour Claude Code qui lit le diff et vient commenter directement dessus.
Le dépôt de Security Audit Skill de Cloudflare est sous licence MIT, et il lui faudra Node.js pour faire tourner ses deux validateurs.
En tout cas, ce que je vous conseille, c'est d'aller lire le SKILL.md avant de lancer la première passe, pour vous assurer que tout sera OK au sein de votre harness.
Source : security-audit-skill sur GitHub
Cloudflare Computer est un projet qui donne à votre agent IA un endroit rien qu'à lui. C'est-à-dire un vrai système de fichiers, avec des dossiers, des fichiers qui restent, et de quoi lancer des commandes dedans. Bref, un vrai poste de travail que l'agent garde entre deux sessions, au lieu de repartir de zéro à chaque fois, puisque tous les fichiers sont rangés dans une base SQLite.
Le système de fichiers s'utilise ensuite comme n'importe quel autre. Lire, écrire, créer un dossier, lister, supprimer, et un grep intégré pour fouiller dans le tas. Pour tout le reste, il n'y a qu'une fonction à retenir, exec(). Vous lui passez une commande, et elle vous rend la sortie et le code de retour.
Ce qui change par contre, c'est l'endroit où la commande tourne. 3 environnements sont disponibles et interchangeables sur les mêmes fichiers. Il y a d'abord un conteneur Linux complet, avec npm, node et de vrais binaires. Ou un shell léger pour les commandes simples. Et enfin, un dernier qui exécute directement votre code, sur une base neuve à chaque appel.
Comme ça, vous passez de l'un à l'autre sans réécrire une ligne de votre agent.
Les 9 exemples fournis montrent bien ce qu'on peut en tirer quand on aime bidouiller. Le plus parlant fait par exemple tourner un agent de discussion qui prendra l'espace de travail comme répertoire courant, donc qui travaillera dans de vrais fichiers au lieu de tout garder en mémoire.
Un autre colle pandoc dans le conteneur et laisse l'agent transformer une fiche markdown en PDF. Il y en a aussi un qui fabrique des images avec Workers AI, un quatrième joue sur les politiques de sortie réseau pour décider ce que l'agent a le droit de joindre, et enfin, un dernier génère un projet Worker complet, puis le publie.
Il y a même une interface web qui balance la même tâche dans le conteneur et dans un environnement léger, côte à côte.
Reste à savoir ce qui est gratuit là-dedans... Le code est sous licence MIT, et le système de fichiers seul, sans aucune exécution, tourne sans souci dans le plan Workers gratuit puisque les Durable Objects qui portent ce stockage y sont inclus, avec 100 000 requêtes par jour et 5 Go d'espace.
Il faut un compte Cloudflare, évidemment...
Puis si vous voulez faire tourner des vraies commandes ou avoir un shell, faudra payer puisque le conteneur comme les environnements légers réclament le plan Workers payant, facturé 5 dollars par mois au minimum.
Après j'ai quelques réserves quand même parce que le projet est très récent, encore en preview et clairement inadapté à de la production. Ensuite, la limite technique d'un espace de travail tourne autour de 10 Go, et les accès disque lourds restent plus lents que sur un vrai disque. Puis surtout, tout vit chez Cloudflare, et pas chez vous (si vous préférez l'inverse, je vous avais montré workerd , le moteur des Workers en local).
Mais bon, c'est à garder à l'œil si vous êtes client Cloudflare.
Cloudflare’s Kitesurf browser promises lower resource use and stronger isolation for AI agents, but enterprises should assess its beta limitations.
The post Cloudflare Launches Kitesurf, a Lightweight Browser Built for AI Agents appeared first on TechRepublic.
Cloudflare has open-sourced its Cloudflare OS platform, which it first developed as an internal workspace for employees to build apps using AI agents—including people who are not software developers or engineers. The company also touts a security framework designed to reduce the risk of employee vibe-coding sessions creating serious security flaws or leading to data breaches.
The tech company spent several months building and internally testing Cloudflare OS, which allows employees to describe workflows in natural language so that an AI agent can code them into applications. In an August 5 blog post announcing the open source version’s availability on GitHub, the company claims thousands of Cloudflare employees use the platform on a daily basis to “create documents and slides, automate repeatable tasks, and build small apps to visualize data and help them do their work.”
“This is a full-on personal app vibe coding platform, in which the sandbox is so secure that you can pretty much go wild—the AI cannot introduce a significant security bug,” said Kenton Varda, principal engineer at Cloudflare, in a post on the social media platform X. “We believe a company's security team can feel comfortable giving non-technical users permission to vibe code and then sleep soundly at night.”
Ma page "Quelle est mon adresse IP" traînait sur korben.info depuis presque 15 ans, à peu près dans son jus d'origine. Hé bien, bonne nouvelle, je viens de la refaire entièrement, et elle est là : korben.info/ip .
Vous arrivez dessus, votre IP publique s'affiche en gros, IPv4 et IPv6 séparées avec un bouton copier, et juste en dessous une grille de cartes déballe tout ce que votre connexion raconte sur vous sans que vous ayez rien demandé. La localisation estimée d'abord, sauf que c'est pas du GPS, juste la ville que les bases GeoIP collent à votre IP (sur mobile ça part parfois à 200 km à côté) mais aussi votre opérateur et son numéro d'AS, de datacenter Cloudflare par lequel vous passez, la latence jusqu'à lui, le protocole, le chiffrement.
Y'a une carte que je trouve bien pratique aussi c'est la carte "VPN ou pas ?". Elle compare le fuseau horaire vu depuis votre IP avec celui réglé sur votre appareil, et repère si vous sortez par une IP de datacenter, le signe quasi certain d'un VPN ou d'un proxy.
J'ai ajouté aussi un petit test de débit maison (descendant, montant, latence, gigue), tout comme le fameux leak WebRTC, ce truc qui balançait votre IP locale à n'importe quel site avant que les navigateurs ne finissent par la masquer. Ça peut encore fonctionner sur de vieux browser alors je l'ai laissé.
Le point important, parce que je sais que vous allez me poser la question, c'est que de mon côté, rien n'est stocké, rien n'est tracé, rien n'est revendu. Tout est lu à la volée entre votre navigateur et mon CDN, qui se contente de faire transiter vos requêtes comme n'importe quel hébergeur. Votre IP en dit déjà bien assez long sur vous comme ça, pas la peine d'en remettre une couche.
Bref, un bon coup de bouc-marque (bookmark, pour les intimes ^^) sur korben.info/ip et vous aurez votre IP et l'état de votre connexion sous la main en un clic.
Un site sans cookie de mesure d'audience et sans bandeau de consentement, c'est reposant je trouve... Sauf qu'à cause de ça, bah je ne savais plus trop combien de gens venaient me lire tous les jours. Relou hein ?
C'était ma situation depuis un moment déjà, vu que tout ce qui servait à mesurer l'audience a dégagé de korben.info il y a un bon bout de temps. Alors faute de mieux, je me suis rabattu sur AWStats, qui lit bêtement les logs Apache du serveur mais bon, c'est pas terrible, parce qu'avec le cache de Cloudflare, il y a une grosse partie de mon trafic qui n'est pas pris en compte.
En effet, quand Cloudflare possède une copie valide de la page dans son cache, il peut la renvoyer directement sans contacter le serveur d'origine. Vous êtes donc bien un visiteur réel, mais Apache ne voit aucune requête et AWStats ne vous comptabilise pas. Du coup, tous les outils fondés exclusivement sur les logs d'origine sous-estiment la part du trafic absorbée par le cache.
Après il y a bien le classique Google Analytics, mais bon même configuré en mode full RGPD, ça reste Google et ça appelle quand même un service tiers aux US... Vous connaissez aussi déjà des alternatives propres, puisque je vous ai parlé de Matomo, Plausible et de Vince Analytics , mais elles ajoutent toutes une mesure côté navigateur, avec un script, un pixel ou un stockage local (le localstorage) et moi, je ne voulais aucun outil d'audience de plus dans vos pages !
De son côté, Cloudflare lui, voit chaque requête HTTP qui atteint son réseau, y compris celles auxquelles son cache répond. Ses chiffres couvrent donc beaucoup mieux le trafic HTTP que mes logs d'origine. Le souci, c'est que son dashboard, je ne l'aime pas. Je le trouve incomplet, mal foutu, chiant à utiliser, et il ne montre pas ce que j'ai envie de voir.
Donc, histoire d'avoir ce que je voulais, j'ai fini par coder le mien. Enfin, entièrement vibe codé et ça tourne aussi bien sur un serveur qu'en local sur une machine de bureau.
Petite parenthèse pendant que j'y suis, vous ne le savez peut-être pas mais depuis que ChatGPT a débarqué dans nos vies fin 2022, tout ce que je développe moi-même sur ce site et l'ensemble de mes outils internes sont vibes codés avec des LLMs comme ceux d'OpenAI et d'Anthropic. C'était une purge au tout début et maintenant ça s'est tellement amélioré et je me suis tellement spécialisé là-dedans, que le code n'est devenu qu'une formalité. Ne hurlez pas, mon site est statique et j'envoie pas de fusée dans l'espace !
Mon collecteur s'exécute en local, cause à une API, et il n'envoie pas une seule ligne de mesure dans votre navigateur. Bref, que mon backend soit écrit avec un LLM, à la main ou en Brainfuck, vous chargez exactement la même chose de mon outil de stats, c'est-à-dire rien du tout. La garantie est donc architecturale et pas une question de talent.
Et surtout, mon outil de stats n'ajoute aucune mesure dans votre navigateur. Aucun JavaScript ni cookie supplémentaire n'est posé par mon outil. À la place, il lit l'API GraphQL Analytics de Cloudflare, en lecture seule et récupère des compteurs déjà agrégés par jour et par dimension. Cela veut dire par exemple, que quand je récupère le nombre "nombre d'IP distinctes par jour", je ne récupère pas les IPs en tant que telles mais juste un total que Cloudflare me communique et qu'il a déjà traité en amont.
Et vous n'êtes pas obligés de me croire sur parole, parce que c'est vérifiable en 10 secondes... Ouvrez l'inspecteur de votre navigateur, onglet Réseau, et rechargez cette page. Vous ne verrez aucun script de mesure d'audience, aucun appel vers un domaine tiers et aucune iframe. Même les vidéos YouTube ne se chargent qu'au moment où vous cliquez sur la vignette. Le seul truc qui bouge, c'est le compteur du footer qui télécharge un nombre, sans rien renvoyer derrière.
Attention, ce n'est pas à confondre avec Cloudflare Web Analytics et ses mesures RUM (Real User Monitoring) puisque cette fonctionnalité injecte un bout de JavaScript pour mesurer les performances ressenties dans le navigateur. Chez moi, c'est désactivé tout ça.
Maintenant soyons clairs sur un point, parce que c'est l'objection évidente et qu'elle est parfaitement légitime... Cloudflare, lui, voit bien votre adresse IP. Pas à cause de mon outil de stats, mais parce que c'est un reverse proxy et que c'est mécaniquement ce qui se passe dès qu'un site est derrière un CDN. Votre requête arrive chez eux avant d'arriver chez moi, sinon ils ne pourraient ni router, ni mettre en cache, ni bloquer une attaque. Mon outil ne change rien à ça, il se contente de lire des totaux déjà calculés et je ne récupère jamais la moindre IP. Tout est détaillé dans mes CGU, avec les bases légales, les durées et la liste des cookies de sécurité, si vous voulez le détail complet.
Mon outil et le compteur que vous pouvez retrouver dans le footer de mon site reposent sur les requêtes collectées côté serveur chez Cloudflare et sans l'analyse web, je ne peux juste pas suivre par exemple un parcours utilisateur, connaitre un taux de rebond ou évaluer les temps de chargement mesurés chez les lecteurs. Rien de grave donc...
Maintenant, il y a un souci chez Cloudflare, c'est que selon le jeu de données et le forfait que vous payez ou non, le détail ne reste interrogeable que durant une fenêtre limitée de temps. Mon outil doit donc passer chaque jour récupérer les agrégats encore disponibles et les stocker dans une base SQLite sur mon serveur ou en local, selon la façon dont on l'a déployé.
Ça me permet de garder mon propre historique agrégé. J'ai aussi activé le Super Bot Fight Mode de Cloudflare, qui réduit une large partie du trafic automatisé, mais attention, ça ne me donne pas pour autant des stats sans aucun bot. Les crawlers autorisés comme Googlebot et ceux qui passent entre les mailles du filet restent comptabilisés dans mes chiffres, exactement comme avec tous les autres outils de mesure web. Et je préfère le dire clairement plutôt que de vous vendre des chiffres "propres" qui ne le sont jamais totalement, vu qu'un filtre anti-bot ne peut retirer que les bots qu'il a détectés.
À côté de ça, j'ai aussi branché ma Google Search Console, et là non plus sans installer la moindre bibliothèque tierce... Je signe moi-même un JWT en RS256 avec le module crypto natif de Node, je l'échange contre un jeton d'accès chez Google, et le compte de service que j'utilise est restreint au scope lecture seule. Ça m'apporte des statistiques agrégées sur les impressions, les positions, les requêtes de recherche et surtout Discover !!
Si je devais résumer ça, je dirais que Cloudflare estime le volume de trafic et que Search Console montre quelles recherches produisent des impressions et des clics, même si sans aucun tracking en place, ça n'explique évidemment pas la motivation de chaque lecteur. Mais osef ! Et comme Cloudflare embarque aussi son pare-feu, j'en profite pour rapatrier des statistiques sur les événements de sécurité et les routes attaquées, comme ça, je peux tout voir au même endroit.
Maintenant, le vrai plaisir, c'est de pouvoir afficher ce que je veux dans mon propre dashboard. Par exemple, la répartition par langue, les navigateurs, d'où provient le trafic avec un joli petit camembert, les pays, l'état de mon cache, la bande passante, etc. Et quand j'ai un nouveau besoin qui me pête dans le cerveau, je peux ajouter une vue rapidement et je ne m'encombre pas de ce qui ne me sert pas.
Sans traceur placé chez vous, je ne connais donc pas les sessions, le taux de rebond, le parcours de lecture, les entonnoirs de conversion, donc impossible de savoir si vous êtes revenu hier, ni dans quel ordre vous avez lu 3 articles. Mais je m'en tape complètement puisque ces métriques ne m'ont jamais servi à rien.
Ce que je veux connaitre, c'est surtout l'ordre de grandeur de l'audience et le nombre de pages demandées. Le parcours individuel et les entonnoirs de conversion, c'est surtout un besoin de régie publicitaire ou de site e-commerce, et pas d'un site comme le mien. Quand on sait que les bandeaux de cookies nous coûtent 575 millions d'heures perdues collectivement, et que l'Europe réfléchit enfin à les alléger , s'en passer n'est pas vraiment une punition.
Bref, mes stats sont maintenant plus digestes que celles d'AWStats, sans avoir à vous tracker ou vous faire charger quoi que ce soit. Ça me va donc très bien. Et si vous voulez un avant-goût de la technique derrière l'outil, j'ai montré récemment comment vous faire un compteur de fréquentation gratuit , donc n'hésitez pas à y jeter un œil...
Cloudflare généralise Precursor, un système qui analyse en continu la façon dont un visiteur bouge sa souris ou tape au clavier pour distinguer un humain d'un bot. De quoi mesurer l'urgence avec laquelle l'industrie cherche des parades, trois semaines à peine après l'annonce du protocole PACT.
Google est allé raconter à la Commission européenne ce que les gens qui s'y connaissent un peu en réseau répètent depuis 15 ans : Bloquer les résolveurs DNS, les VPN et les adresses IP pour lutter contre le piratage, ça ne marche pas.
Dans un document envoyé pour la consultation sur la révision de la directive copyright, Mountain View écrit que "bloquer les résolveurs DNS, les IP ou les VPN est inefficace, car cela ne supprime pas du tout le contenu et se contourne facilement en utilisant des résolveurs DNS alternatifs".
Le plus marrant ??? Bah c'est que Google sait très exactement de quoi il parle, vu que la justice française l'oblige déjà à filtrer son propre résolveur 8.8.8.8 pour protéger les matchs de foot de Canal+ (Fun fact : J'ai pas vu une seule image, ni score, ni entendu une seule histoire à propos de la Coupe du Monde cette année, tellement les algos savent que ça ne m'intéresse pas.... loool)
Pour ceux qui débarquent (oué oué), le blocage DNS, c'est demander aux annuaires du net (souvent ceux de votre FAI) de faire semblant de ne pas connaître l'adresse d'un site. Le site reste en ligne, ses serveurs tournent, et vous le retrouvez facilement en moins de 2 min, en changeant de résolveur ou en allumant un VPN.
Le blocage d'adresses IP, c'est encore pire, parce qu'une même adresse est souvent partagée par des milliers de sites sans aucun rapport entre eux... En bloquer une, ça revient donc souvent à couper l'électricité de tout l'immeuble pour punir un seul locataire.
Et des immeubles plongés dans le noir, la soumission de Google en aligne toute une collection. Je pense par exemple à ce document étiquetté "Privileged and Confidential" que la Commission a quand même publié (lol, des champions, je vous dis !) et qui cite le nom de clients de Google Cloud parfaitement en règle, qui pourtant ont été entièrement coupés à Internet fin 2019 au Portugal. Tout ça parce que des fournisseurs d'accès Internet locaux avaient bloqué des ASIP partagés pour viser certains sites pirates...
Ou encore un sous-domain de Google Drive ainsi que des IP Cloudflare sur lequel reposaient plus de 42 millions de domaines victimes du Piracy Shield italien. Ah et j'ai oublié l'Espagne qui vient compléter ce joli bingo parce que là-bas les blocages réclamés par LaLiga (la ligue de foot locale) durant les matchs, on fait carrément tomber +550 000 dont les sites d'Amnesty International, de l'UNICEF, du Sénat australien, de la Stanford Law Review et même des serveurs Amazon S3.
Et en France, je ne sais pas si vous vous souvenez, mais Cisco a carrément préféré débrancher son service OpenDNS plutôt que de se plier aux ordonnances de la justice. Quelle bonne ambiance dans ce terreau fertile à la dictature qui nous fonce dessus comme un train de la Deutsche Reichsbahn. (Point Godwin atteint, j'm'en fous, je fais ce que je veux, c'est mon site ^^).
Du coup, les ayants droit réclament maintenant de bloquer aussi les résolveurs alternatifs et les VPN eux-mêmes... et c'est exactement cette fuite en avant que Google demande d'arrêter. En tout cas dans son message, Google rappelle vivement ce que l'industrie du divertissement refuse d'entendre depuis l'époque de Napste : Quand vous avez un catalogue de merde émietté entre des dizaines de plateformes pour des prix exorbitants, avec de la pub, une qualité assez basse et des tas d'œuvres manquantes, eh bien, il ne faut pas s'étonner que le téléchargement illégal reparte de plus belle.
Maintenant, c'est vrai que Google ne joue pas les chevaliers blancs par pure bonté d'âme. En fait, ce qu'ils défendent, c'est leur résolveur maison, leur cloud et leurs clients. Elle reste par exemple très silencieuses sur tous les projets de loi de blocage qui avancent en ce moment même au Congrès américain.
Mais sur le fond, on ne peut pas leur donner le tort surtout quand je vois que le DNS4EU, le résolveur souverain européen, se fait déjà mettre la pression pour filtrer les sites pirates.
Voilà, la consultation est close depuis le 25 juin dernier et la commission est actuellement en train d'éplucher toutes les contributions pour décider des futures conneries qu'elle va faire. On croise les doigts quand même.
Vous avez peut-être remarqué un petit point rouge tout en bas de mon site, avec un nombre à côté. Il s'agit du nombre de personnes passées sur le site durant la dernière heure.
Je voulais remettre ce truc depuis un bail, bien à l'ancienne comme dans les années 2000 mais sur un site statique, qui plus est sans tracker de stats JS type Google Analytics ou Matomo, et sans cookies de tracking, c'était pas franchement une option... jusqu'à maintenant !
Le compteur, en vrai, tout en bas de korben.info.
La solution évidente sur des sites statiques, c'est souvent un petit Worker Cloudflare qui compte les visiteurs et servirait le chiffre, mais ça se facture à chaque requête. À 390 000 pages vues par jour, ça grimpe vite à des dizaines de millions d'invocations par mois, soit dans les 6 à 7 dollars. C'est pas super cher mais pour un compteur qui n'est utile qu'à satisfaire mon égo tout en sachant s'il y a du monde aujourd'hui, ça ne sert strictement à rien ! Donc le Worker, je l'ai écarté direct.
Du coup j'ai fait ça à l'ancienne. Un petit script Python tourne sur la machine qui héberge le site, une fois par minute. Il pose une seule question à Cloudflare, à savoir combien d'adresses IP distinctes ont chargé une page durant la dernière heure (ou demi-heure, ou quart d'heure ou 5 min, c'est vous qui paramétrez), il écrit la réponse dans un minuscule fichier live.json de quelques centaines d'octets, et c'est tout. Ce fichier, Cloudflare le sert ensuite depuis son cache comme il servirait une image, gratuitement. Zéro Worker, zéro base de données, zéro abonnement, j'ai exactement le même résultat sans dépenser une thune.
Maintenant, faut que je sois clair sur ce que ce chiffre raconte. C'est le nombre de navigateurs distincts ayant chargé une page durant la dernière heure, hors trafic interne de Cloudflare. C'est un "*combien de monde est passé récemment *", pas un "combien lisent là tout de suite".
Et les bots là-dedans ?
En fait, les bots pourris , ceux qui scrapent en boucle, se font bloquer en amont par le Super Bot Fight Mode de Cloudflare, donc ils n'arrivent même pas jusqu'à mon site. Restent les gentils bots, du genre de Googlebot et compagnie, que je laisse passer exprès, parce que les bloquer reviendrait à me flinguer mon référencement. Sur les 7 derniers jours, Cloudflare classe à peine 4% comme bots vérifiés. Donc c'est une goutte d'eau, surtout qu'ils tournent sur une poignée d'IP. Donc oui, mon compteur avale deux ou trois crawlers au passage, mais je ne voulais pas vous mentir en écrivant "zéro bot". Mais l'essentiel c'est que les nuisibles, eux, ne soient pas comptabilisés.
J'ai aussi dû gérer un petit piège car l'API de Cloudflare plafonne sa réponse à 10 000 lignes. Et comme sur une heure entière de trafic ça peut se remplir vite, si je crève ce plafond, la requête sous-compterait sans rien dire. Donc le script lève un flag et le compteur affiche "10 000 personnes ou plus" plutôt qu'un faux nombre. Quand j'y serai aux 10 000 et plus, je pense que je réduirai alors le delta temps en passant de 1h à 30 min...etc.
Côté vie privée, c'est carré également. Cloudflare renvoie à mon serveur une liste JSON des IP passées dans l'heure, mon script en compte le nombre de distinctes, et efface cette liste de sa mémoire dans la milliseconde qui suit. Aucune IP n'est stockée, aucune n'atterrit dans un log, aucun fichier avec les IPs n'est créé sur le disque... Il ne reste qu'un entier. Comme je vous le disais, pas de cookie , pas de traceur, et rien qui touche votre navigateur . Et comme le compteur ne s'affiche jamais en dessous de 10 personnes, impossible d'isoler qui que ce soit.
Maintenant, si vous voulez le même chez vous, sachez que j'ai tout balancé en open source sur GitHub , sous licence MIT, donc servez-vous. Voici les pré-requis :
live_count.py sur votre serveur et vous le lancez une fois par minute (ou toutes les 5 ou 10 min) via un cron.span dans vos pages, tout se règle par des attributs, aucun script inline, donc ça passe même avec une politique de sécurité stricte.Le seul truc sur lequel ne pas vous louper, c'est de mettre un temps de cache court à live.json. Si c'est trop long, tous vos visiteurs verraient un chiffre périmé.
Voilà. Un petit compteur maison simili-live sans tracking et qui ne me coûte rien, c'est le bonheur !
See what you missed in Daily Tech Insider from July 6–10.
The post AI Breakthroughs, Security Breaches, and Industry Shakeups Define the Week appeared first on TechRepublic.
Tags de l’article
Je viens d'apprendre que Cloudflare s'était associé à Chrome, Firefox et Edge pour régler un truc qui nous pourrit tous la vie sans que nous y pensions vraiment, à savoir prouver qu'on est des humains.
Leur projet s'appelle PACT pour Private Access Control Tokens, et l'idée c'est de remplacer les affreux CAPTCHA par un titi jeton cryptographique anonyme que votre browser baladera de sites en sites.
Alors comment ça fonctionne cette nouvelle connerie ?
Hé bien un site qui a déjà une bonne raison de vous croire humain, genre un service où vous avez un compte, émet un token anonyme. Votre navigateur le conserve, et quand vous débarquez ailleurs, il le présente comme une preuve que vous n'êtes ni un robot, ni un alien, ni un pervers narcissique manipulateur.
Comme vous avez passé le test une fois, vous n'avez donc plus à recliquer sur des feux tricolores et des passages piétons aux quatre coins du web... Et comme le token ne contient aucune donnée perso, le site qui le reçoit ne sait pas d'où il sort.
Derrière PACT, rien de sorcier niveau techno, c'est juste du Privacy Pass, l'architecture que l'IETF a posée noir sur blanc en 2024 avec les RFC 9576 à 9578 . Apple fait déjà exactement ça depuis 2022 avec ses Private Access Tokens planqués dans iOS 16 et macOS Ventura, et Cloudflare est même l'un de leurs émetteurs en production. Mais PACT, c'est la version next-gen de ce truc. Au lieu d'attester juste "cet appareil est un vrai iPhone", on atteste "il y a un humain dans la boucle". Les signatures RSA aveugles font que l'attesteur ne sait pas quel site vous visitez, et que le site, lui, ne sait pas qui vous êtes.
C'est plutôt une bonne idée, je trouve. Sauf que cette histoire de "personne", ça inclut aussi les bots autorisés. Genre votre agent IA qui réserve un billet de train ou fait vos courses pendant que vous dormez. Cloudflare veut également leur filer des tokens à eux aussi, pour les démarquer des crawlers sauvages qui pompent le web à l'aspirateur de chantier.
Et ça tombe bien, parce qu'aujourd'hui plus de la moitié du trafic web mondial, c'est déjà des bots.
Maintenant, le truc qui me chiffonne avec PACT c'est que ça crée mécaniquement un web à deux vitesses. D'un côté le trafic on aura le trafic "de confiance" avec son joli token, de l'autre tout le reste, traité comme suspect par défaut. Donc si vous surfez avec Tor, un navigateur exotique ou une config un peu trop cheloue, et que personne ne veut vous émettre de jeton parce que vous êtes un haxxor intransigeant avec sa vie privée, vous devenez un citoyen de seconde zone du web. Sans compter que ce serait ENCORE Cloudflare, déjà videur d'une énorme part d'Internet, qui se retrouvera à arbitrer qui mérite son laissez-passer.
Et puis ça ne règle pas le pistage. Le fingerprinting, votre IP, les mille autres signaux que votre navigateur balance dans la nature restent en place. PACT vire juste le CAPTCHA, mais pas la surveillance. Mozilla jure sur la tête de sa mère que sa participation sert justement à garder ce système ouvert, et j'avoue que je suis content qu'ils soient dans la même pièce que les autres filous, qui pourraient en profiter pour réécrire la norme entre eux. Maintenant, si ce qui reste de votre vie privée déjà bien publique avec toutes nos données perso qui ont fuitée, vous tient encore à cœur, un petit navigateur blindé comme LibreWolf ou un CAPTCHA qui ne vend pas vos clics tel que ALTCHA restent des choix plus sérieux que d'attendre un jeton de bonne conduite.
Voilà... Pour l'instant PACT n'est qu'un projet, sans date de sortie ni même de lieu de standardisation confirmé, et même si l'idée de virer les CAPTCHA est hyper séduisante, reste encore à savoir qui tiendra les clés du laissez-passer...
C'est un point de non-retour historique : les machines ont officiellement pris le contrôle du trafic web. Selon les dernières données de Cloudflare, 60 % des requêtes mondiales proviennent désormais de bots et d'IA.
Le géant américain des infrastructures internet Cloudflare a soumis le modèle de cybersécurité d'Anthropic à l'épreuve de ses propres dépôts de code. Les enseignements, tout juste publiés dans un article de blog, sont précieux, et les mises en garde le sont encore plus.
Le scraping web, c'est un combat permanent contre les sites qui changent leur HTML toutes les deux semaines. Vous vous emmerdez à coder vos sélecteurs CSS, ça marche pendant un mois, puis le site refait son design et hop, votre script s'eteint en silence. C'est pourquoi Karim Shoair (alias D4Vinci sur GitHub) a sorti Scrapling, un framework Python qui s'adapte tout seul quand le DOM bouge.
La clé c'est adaptive=True sur n'importe quel sélecteur. Vous lui dites "je cherchais .product", Scrapling sauvegarde alors la signature de l'élément (texte, attributs, position dans l'arbre), et la prochaine fois que le site a renommé sa classe, il retrouve l'élément via similarité.
Concrètement ça donne ça :
from scrapling.fetchers import StealthyFetcher
StealthyFetcher.adaptive = True
page = StealthyFetcher.fetch('https://example.com', headless=True)
product = page.css_first('.product', adaptive=True) # Retrouve l'élément même si la classe a changé
Le truc marche grâce à un algo de similarité maison qui compare la structure DOM autour de l'élément. L'auteur lui-même a écrit un long post Medium intitulé " Creating self-healing spiders with Scrapling in Python without AI ", et ça résume bien la philosophie : pas de modèle IA mais juste des heuristiques solides !
La doc précise que adaptive=True ne sauvegarde que le premier élément de la sélection. Du coup si vous récupérez 50 produits d'un coup avec .css('.product'), seul le premier sera adapté. Faudra donc soit utiliser css_first comme dans l'exemple, soit boucler manuellement et appeler adaptive sur chaque élément. C'est bon à savoir...
Y'a également 3 fetchers selon le besoin. Fetcher pour les requêtes HTTP rapides avec spoofing TLS, StealthyFetcher qui passe Cloudflare Turnstile via un navigateur furtif (Camoufox sous le capot), et DynamicFetcher qui lance un Chromium ou un Chrome via Playwright pour les sites lourds en JS. Du coup vous pouvez démarrer léger en HTTP et basculer vers un navigateur uniquement quand un site bloque, sans réécrire votre code.
Côté perfs, le README annonce du lourd : 2 ms pour extraire 5000 éléments contre 1584 ms pour BeautifulSoup avec lxml. Sauf que Parsel et Scrapy font aussi 2 ms. Donc le gain vient du moteur lxml utilisé en direct, ce qui veut dire que si vous étiez déjà sur Scrapy, vous ne gagnerez pas en vitesse brute. Mais si vous traînez encore du BS4 partout, le saut sera énorme !
Sur le terrain anti-bot, ça se compare bien à
Botasaurus
dont je vous avais parlé. La différence c'est que Scrapling embarque un ProxyRotator natif et propose un blocage d'ads/trackers (~3500 domaines) activable via block_ads=True ou automatique en mode MCP, ce qui simplifie la vie quand vous tournez sur un serveur (où les IPs des datacenter se font régulièrement filtrer). Botasaurus, lui, vous laisse gérer la rotation à la main.
Détail sympa pour les bidouilleurs : y'a également un serveur MCP est intégré (pip install "scrapling[ai]"). Du coup Claude ou Cursor peuvent piloter Scrapling directement pour extraire des données, en réduisant la consommation de tokens car l'IA ne voit pas tout le HTML brut, juste ce qui est extrait. Pour les agents qui scrappent en boucle, c'est cool.
Notez que les sponsors Platinum du projet sont tous des fournisseurs de proxies (DataImpulse, BirdProxies, Evomi, etc.). C'est logique vu l'usage du framework, mais gardez en tête que pour bypasser un Cloudflare sérieux à grande échelle, vous aurez besoin de proxies résidentiels payants, donc d'eux. L'outil est gratuit, mais le contournement industriel ne l'est pas.
Pour installer, c'est pip install "scrapling[fetchers]" puis scrapling install pour récupérer les binaires navigateur. Une image Docker existe aussi (pyd4vinci/scrapling) et y'a même un shell interactif (scrapling shell) pour debugger vos sélecteurs en live.
Bref, c'est carrément pas mal pour ceux qui scrapent régulièrement. Alors si BS4 vous fait pleurer, allez voir par ici .
Et merci à Letsar pour le lien !
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 !
Figurez-vous que les agents IA sont désormais les premiers consommateurs des APIs Cloudflare, bien devant les développeurs humains. C'est en tous cas ce que l'éditeur déclare publiquement pour justifier une refonte importante de son outil en ligne de commande, Wrangler, et la sortie d'un nouveau CLI unifié baptisé sobrement "cf".
Le raisonnement est froid mais a du sens. Si les agents IA pilotent la plateforme, autant qu'ils aient un CLI qui ne les plante pas.
Concrètement, Cloudflare a refait toute sa pipeline de génération de code autour d'un schéma TypeScript unique. Ce schéma décrit le périmètre complet des APIs, des commandes CLI, des arguments et du contexte nécessaire pour générer n'importe quelle interface.
Quand un nouveau produit Cloudflare arrive, il tombe automatiquement dans le CLI. Avec près de 3 000 opérations d'API au catalogue, c'était effectivement le bon moment pour industrialiser la chose.
Le point qui dit beaucoup sur l'état de l'industrie, c'est celui-ci. Cloudflare force désormais des commandes CLI par défaut au niveau du schéma, pour éviter que les agents se plantent sur des variantes moins standards qu'ils ne connaissent pas.
En clair, le design du CLI est partiellement contraint par ce que les LLM savent deviner. C'est nouveau, et pas anodin.
À côté du nouveau CLI cf, Cloudflare lance Local Explorer en bêta ouverte, intégré à Wrangler et au plugin Cloudflare pour Vite. L'outil permet d'inspecter les Workers en local, de voir quels bindings leur sont attachés et quelles données y sont stockées.
Pratique pour déboguer sans passer par le dashboard web, surtout quand on jongle entre plusieurs environnements.
Pour les développeurs humains, la promesse est double. D'abord, un CLI plus cohérent, moins de surprises d'un produit à l'autre. Ensuite, un outil de debug local qui évite l'allée-retour constant avec l'interface web Cloudflare. Pour les agents IA, la promesse est plus prosaïque, appeler Cloudflare sans générer d'erreurs de syntaxe toutes les trois commandes.
C'est en fait assez symptomatique d'une tendance qu'on voit chez plusieurs plateformes cloud en ce moment, où l'ergonomie CLI est pensée pour les LLM autant que pour les humains. Pas sûr que tous les acteurs l'assument aussi frontalement, mais Cloudflare, fidèle à son style, le dit.
Bref vous l'avez compris, cf et Local Explorer valent le détour. Et si vous laissez un agent piloter l'infra, au moins il aura des rails pour que ça ne parte pas dans tous les sens.
Source : The Register
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 des années, prouver qu'on était humain ressemblait à un examen de conduite : identifier des feux tricolores, reconnaître des bus ou des vélos sur des grilles pixelisées. Des petits rituels qui ont structuré une décennie entière de navigation. Puis ils ont disparu, presque sans qu'on s'en rende compte, pour laisser place à un système moins visible et plus sophistiqué.
La justice française a ordonné une nouvelle vague de blocages ciblant une cinquantaine de sites illégaux de streaming et d'IPTV. Cette fois, Canal+ a ciblé un géant américain de l'infrastructure web, Cloudflare, dont certains services peuvent servir à contourner les blocages de sites illicites.
La justice française a ordonné une nouvelle vague de blocages ciblant une cinquantaine de sites illégaux de streaming et d'IPTV. Cette fois, Canal+ a ciblé un géant américain de l'infrastructure web, Cloudflare, dont certains services peuvent servir à contourner les blocages de sites illicites.
Dans un article de blog publié le 11 mars 2026, les chercheurs de DomainTools ont mis au jour une campagne de phishing particulièrement fourbe, visant à dérober les identifiants Microsoft 365 de ses victimes. Sa particularité ? Détourner un outil de protection légitime de Cloudflare pour se rendre invisible aux scanners de sécurité.
Le 10 mars 2026, Cloudflare a annoncé le lancement d'un outil capable d'aspirer l'intégralité d'un site web en une seule commande. Une annonce qui surprend de la part d'une entreprise dont le cœur de métier a longtemps consisté à protéger les sites précisément contre ce type d'opération.
Depuis quelques jours, un outil open-source retient l’attention sur les réseaux sociaux. Son nom : Scrapling. Piloté par des agents IA OpenClaw, il serait capable de contourner toutes les protections anti-scraping du web. Alors, nouvelle crainte disproportionnée ? Cloudflare, en tout cas, prend le sujet très au sérieux.
Le lundi 16 février 2026 a été marqué par une panne mondiale de X, survenue par à-coups au fil de la journée. Un incident qui a provoqué un accrochage entre deux acteurs collatéraux : Cloudflare, suspecté un temps d’être la cause, et Downdetector, le site de référence pour signaler et estimer les perturbations sur les plateformes web.
Shell script to update original visitor IP for nginx when using Cloudflare
Shell script to mirror backups to another server in pull mode using rsync
Shell script to set up an LXD (Linux Containers) VM lab for testing purpose
Shell script to update all lxd container hypervisor
Shell script to reset ebtables on Linux
