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 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'éteint 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 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 !

Source

Accéder à son NAS depuis l’extérieur n’a rien de compliqué… mais toutes les méthodes ne se valent pas. Certaines privilégient la simplicité, d’autres la sécurité ou les performances. Si vous possédez un NAS, vous vous êtes probablement déjà demandé quelles solutions existent et quelles sont leurs différences. Voici un rapide tour d’horizon, avec les bonnes pratiques à connaître

Accès à distance

Quand on possède un NAS, on devient vite exigeant en matière de sécurité. Pendant longtemps, il était strictement impossible d’accéder à mon NAS depuis l’extérieur. Et puis, les usages ont changé, les enfants ont grandi… nos besoins ne sont plus les mêmes.

La question n’est donc plus “faut-il y accéder ?” mais plutôt “comment le faire correctement ?”

Accès facile des constructeurs

Les fabricants de NAS proposent des solutions clés en main, très simples à configurer. Chacun propose son propre service de type Cloud Relay.

L’activation se fait généralement en un clic, sans configuration réseau ni redirection de port. Ces services fonctionnent via un serveur relais hébergé par le fabricant. Cela signifie que vos données transitent par une infrastructure tierce. Même si elles sont chiffrées, cela implique une dépendance à l’écosystème du fabricant… et des performances souvent en retrait.

Sa simplicité extrême pousse de nombreux utilisateurs à l’activer sans en mesurer les implications, d’autant que certains fabricants la proposent dès le premier démarrage. C’est tellement simple que personnellement, je trouve cela dangereux.

DDNS

Le DDNS (Dynamic DNS) permet d’associer une adresse IP publique (celle de votre Box qui change régulièrement) à un nom de domaine fixe.  Vous pouvez acheter un domaine (.fr, .com, .eu…) pour quelques euros par an chez un registrar comme OVH ou Cloudflare, ou opter pour un sous-domaine gratuit via des services tiers tels que ChangeIP, FreeDNS, ou ceux proposés directement par les fabricants de NAS. Dans ce dernier cas, vous n’aurez pas la maîtrise totale du nom de domaine.

Cette méthode nécessite une redirection de port sur votre routeur. Il est également possible d’intégrer un reverse proxy (directement sur le NAS ou sur un autre équipement) pour gérer proprement un domaine et ses sous-domaines avec HTTPS.

VPN auto-hébergé

Héberger son propre serveur VPN est la solution offrant le meilleur rapport sécurité/contrôle. Le VPN constitue une porte d’entrée chiffrée vers votre réseau domestique. Pour accéder au NAS, vous devez d’abord vous authentifier via ce tunnel sécurisé… vous êtes connectés ensuite comme si vous étiez en local.

Le serveur VPN peut être installé sur :

• Votre Box ou routeur ;
• Un appareil dédié comme un Raspberry Pi ;
• Le NAS lui-même.

Je recommande WireGuard, qui combine une sécurité élevée avec d’excellentes performances, notamment en mobilité. C’est la solution que je privilégie personnellement. La contrepartie, c’est que sa configuration est plus technique que les autres méthodes. Elle nécessite également une redirection d’un port sur votre Box.

VPN hybride (mesh VPN)

Des solutions comme Tailscale proposent une approche simplifiée du VPN. Il suffit d’installer l’application sur le NAS et sur vos appareils, puis de se connecter avec un compte. La mise en relation entre les appareils est gérée automatiquement, sans configuration réseau.

Ces outils sont bien sécurisés (chiffrement de bout en bout), mais les données transitent via les serveurs de l’éditeur pour l’établissement de la connexion. Les performances sont souvent inférieures à un VPN auto-hébergé. L’offre gratuite est souvent suffisante pour un usage personnel…

Cloudflare Tunnel

Cloudflare Tunnel permet d’exposer son NAS via un nom de domaine, sans ouvrir le moindre port sur votre box… et en bénéficiant de la protection applicative de Cloudflare (WAF, gestion des accès, authentification à deux facteurs…).

Le fonctionnement repose sur un agent installé sur le NAS (généralement via Docker), qui établit une connexion sortante vers les serveurs Cloudflare. C’est ce tunnel qui permet l’accès depuis l’extérieur, sans exposition directe de votre réseau. La limite principale reste la même que pour toute solution cloud : vous faites confiance à un tiers pour le transit de vos données.

Rappel de sécurité

Dès qu’un NAS est accessible depuis Internet, il devient une cible potentielle. Des robots scannent en permanence le Web à la recherche de services exposés et des failles exploitables.

Je vous recommande d’appliquer un minimum de règles de sécurité :

• Activez le blocage automatique après plusieurs tentatives de connexion infructueuses ;
• Désactivez les comptes par défaut (admin, guest) ;
• Activez le pare-feu du NAS ;
• Utilisez un mot de passe robuste (majuscules, minuscules, chiffres et caractères spéciaux) ;
• Changez les ports par défaut ;
• Forcez l’utilisation du HTTPS (redirection HTTP vers HTTPS) ;
• Maintenez votre NAS à jour (système et applications) ;
• Mettez en place des sauvegardes régulières…

Il faut respecter toutes ces règles, voire plus…

En synthèse

Accéder à son NAS à distance est aujourd’hui indispensable, mais cela ne doit pas se faire au détriment de la sécurité. Plus une solution est simple à activer, plus elle mérite d’être questionnée. Prenez le temps de comprendre vos besoins et privilégiez toujours une approche sécurisée, même si elle demande un peu plus d’effort à la mise en place.

	Facilité	Sécurité	Contrôle	Ouverture de port
Solution constructeur				Non
DDNS				Oui
VPN auto-hébergé				Oui
VPN hybride				Non
Cloudflare Tunnel				Non

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é.

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.