Vue normale

Reçu — 11 décembre 2025

RSL 1.0 - L'heure de passer à la caisse a sonné pour les IA

Par :Korben
11 décembre 2025 à 11:29

On vit une époque formidable (non), car d’un côté, 5,6 millions de sites web bloquent maintenant le GPTBot d’OpenAI , 5,8 millions bloquent ClaudeBot alors que de l’autre côté, ce sont 13,26% des bots IA qui se contrefoutent royalement des robots.txt . Les webmasters sont tous en PLS, et plantent des pancartes “Propriété privée - IA interdit” partout… Mais je vous le donne en mille Émile, ça ne sert strictement à rien !

Il y a quand même des gens très intelligents qui se penchent sur le sujet et hier, c’est un nouveau standard qui vient de sortir pour dire stop à cette comédie ! Cela s’appelle Really Simple Licensing (RSL) 1.0 et ça propose quelque chose de radical : Arrêter de bloquer, et commencer à facturer ! Miam !

Concrètement, c’est un petit fichier texte pour passer du fuck-off à la négociation commerciale. Car oui on le sait, le problème avec le robots.txt, c’est que c’est comme demander poliment à des cambrioleurs de ne pas rentrer chez vous. Ça marchait en 1994 quand le web était rempli de gens bien élevés mais en 2025, avec OpenAI, Anthropic, Meta et compagnie qui aspirent notre contenu pour alimenter leurs modèles à plusieurs milliards de dollars, la politesse a ses limites. RSL, c’est donc le passage à l’âge adulte du web où si l’une de ces entreprise veut nos données, c’est possible mais va falloir allonger la moula.

Techniquement, RSL se présente comme un complément au Robots Exclusion Protocol (RFC 9309) où en gros, c’est un vocabulaire XML qui permet d’exprimer des règles de licence machine-readable. Le standard définit trois niveaux de permissions : ai-all (tout autoriser), ai-input (indexation uniquement), ai-index (utilisation limitée). Vous pouvez aussi définir une option “Contribution” pour les organisations non-commerciales qui voudraient utiliser votre contenu à des fins de recherche par exemple.

Le truc intelligent, c’est que RSL s’intègre partout où vous avez déjà l’habitude de mettre des métadonnées : robots.txt, headers HTTP, flux RSS, balises HTML. Pas besoin de réinventer la roue donc, mais juste d’ajouter quelques lignes qui disent “Mon contenu coûte X par requête” ou “Contactez-moi pour négocier”. Le standard supporte aussi d’autres protocoles complémentaires comme Open License Protocol (OLP), Crawler Authorization Protocol (CAP) ou Encrypted Media Standard (EMS).

RSL débarque avec les gros calibres derrière comme Cloudflare et Akamai , qui gèrent une bonne partie du trafic web mondial. L’idée initiale de Matthew Prince de Cloudflare est donc en train de prendre forme tout doucement. Et ils sont rejoints par l’Associated Press et Stack Overflow. Et surtout, il y a Supertab , un service de micropaiement qui teste le système depuis deux trimestres avec une douzaine de clients.

Leur modèle, c’est le “tab” à l’américaine. En gros, vous lisez des articles, ça s’accumule sur une ardoise virtuelle, et vous payez seulement quand vous atteignez 1$ ou 5$. Pas besoin comme ça de sortir la carte bleue pour chaque article à 50 centimes derrière l’un de ces paywalls de merde. Et ça semble bien fonctionner puisque le système a multiplié par trois le nombre de lecteurs payants , et que 10% de ceux qui ouvrent un “tab” finissent par s’abonner dans les 3-4 mois.

Supertab applique maintenant le même principe aux bots IA qui “consomment” le contenu. Ça s’accumule sur un compteur, et ils payent après sauf que contrairement aux humains qui peuvent oublier de payer leur note de bar, les robots ont un budget de scraping bien défini

Alors RSL ne va pas sauver le journalisme ni régler magiquement le bordel du droit d’auteur mais au moins, ça permet d’arrêter de faire semblant. Les créateurs de contenu sont devenus des fournisseurs d’API malgré eux, et RSL assume juste le modèle économique sous-jacent. Plus de 1500 organisations soutiennent déjà ce standard, mais est-ce qu’OpenAI, Anthropic, Google et les autres vont jouer le jeu ? On verra bien…

Pour en savoir plus, c’est par ici : rslstandard.org

Source

Reçu — 8 décembre 2025

pbnj - Le pastebin minimaliste qui se déploie en 60 secondes

Par :Korben
8 décembre 2025 à 10:14

Vous en avez marre des services de partage de code tout pourris qui vous demandent de vous créer un compte, ou de lier votre GitHub, et qui ensuite vous bombarde de bannières pubs ?

Hé bien y’a une alternative plutôt cool qui va vous plaire.

Ça s’appelle pbnj (oui, comme le sandwich au beurre de cacahuète - Peanut Butter aNd Jelly), et c’est un pastebin auto-hébergé qui vous permet de partager du code en tout simplicité. Pas de prise de chou avec de la gestion de users ou ce genre de choses… Vous y balancez du code et vous récupérez une URL à envoyer à vos amis.

Le truc sympa, c’est que ça génère des URLs faciles à retenir au lieu des classiques suites de caractères aléatoires. Comme ça vous avez des trucs du genre “coucou-tu-veux-mon-blog” plutôt que “x7f9k2m8”. Bon ok c’est un peu plus long, mais au moins vous pouvez le retenir ou le donner par téléphone sans épeler chaque lettre. Vous pouvez tester ce que ça donne en cliquant ici .

Côté fonctionnalités, on a de quoi faire avec de la coloration syntaxique dans plus de 100 langages différents avec 12 thèmes . Y’a aussi un outil en ligne de commande qui s’installe via npm et qui permet de balancer un fichier en une commande comme ceci :

`pbnj monfichier.py`

Et si vous voulez garder vos snippets en privés, vous pouvez ajouter une clé secrète optionnelle. Après pour le déploiement de pbnj, vous pouvez faire ça sur Cloudflare Workers si vous n’avez pas de serveur à vous. Et ce sera gratuit car Cloudflare propre dans son offre D1, 500 Mo de stockage, soit environ 100 000 pastes de 5 Ko chacun donc pour un usage perso ou en petite équipe, c’est largement suffisant.

Maintenant, pour installer tout ça, c’est vraiment fastoche. Suffit de cliquer 1 fois sur le bouton de déploiement Cloudflare puis installer le CLI comme ceci :

`npm install -g @pbnjs/cli`

Et :

`pbnj --init`

pour configurer l’URL de votre worker et votre clé d’authentification.

Voilà, si vous cherchez un truc qui fait le café, avec versioning Git, collaboration en temps réel et tout le toutim, passez votre chemin mais si vous voulez juste un endroit pour coller du code et le partager sans prise de tête, pbnj remplit parfaitement le contrat !

Reçu — 5 décembre 2025

Cloudflare tombe en panne en intervenant sur une faille critique

5 décembre 2025 à 13:57

Ce matin, sur la Toile, il était plus probable que d’habitude de tomber sur des erreurs 500.

En cause, un problème chez Cloudflare. Sans commune mesure, néanmoins, avec l’incident du 18 novembre ; en tout cas par sa durée : moins d’une heure*.

L’entreprise en a d’abord attribué la cause à une mise à jour de son WAF. L’objectif, a-t-elle expliqué, était d’atténuer la vulnérabilité React rendue publique la semaine dernière.

À la racine, un problème de journalisation

Cette vulnérabilité, on ne peut plus critique (score CVSS : 10), se trouve dans les composants serveur React. Plus précisément au niveau de la logique qui permet à un client d’appeler ces composants. Par un traitement non sécurisé des entrées, elle ouvre la voie à l’exécution distante de code sans authentification. Les versions 19.0, 19.1.0, 19.1.1 et 19.2.0 des packages react-server-dom-webpack, react-server-dom-parcel et react-server-dom-turbopack sont touchées.

À défaut de pouvoir agir directement sur ces packages, Cloudflare avait déployé, le 2 décembre, une règle WAF. « Un simple pansement », avait rappelé son CTO, ayant constaté l’émergence de variantes de l’exploit.

Concernant l’incident de ce matin, l’intéressé a apporté une précision, en attendant un compte rendu plus détaillé : le problème est né d’une désactivation de journalisation destinée à atténuer les effets de la vulnérabilité…

* Ticket ouvert à 9 h 56. Déploiement du correctif officialisé à 10 h 12. Incident considéré comme résolu à 10 h 20.

Illustration © Hywards – Shutterstock

The post Cloudflare tombe en panne en intervenant sur une faille critique appeared first on Silicon.fr.

Cloudflare en panne : Canvas, LinkedIn et Perplexity de nouveau à l’arrêt

Par :Djib's
5 décembre 2025 à 09:30

Vendredi 5 décembre 2025, une nouvelle panne majeure chez Cloudflare perturbe une partie importante d’Internet. De nombreux internautes constatent l’impossibilité de se connecter à certains services ou voient s’afficher des erreurs « 500 Internal Server Error » et « Bad Gateway » à répétition. Plateformes créatives, réseaux sociaux …

Lire la suite

Aimez KultureGeek sur Facebook, et suivez-nous sur Twitter

N'oubliez pas de télécharger notre Application gratuite iAddict pour iPhone et iPad (lien App Store)


L’article Cloudflare en panne : Canvas, LinkedIn et Perplexity de nouveau à l’arrêt est apparu en premier sur KultureGeek.

Reçu — 23 novembre 2025
Reçu — 19 novembre 2025

Quand une simple panne (Cloudflare) révèle la fragilité des infrastructures Internet

19 novembre 2025 à 17:20

Un incident réseau chez Cloudflare, société spécialisée dans la sécurité web, a perturbé le trafic Internet et entraîné la panne de plusieurs sites hier à la mi-journée. Parmi les plateformes touchées, X (anciennement Twitter) figure comme le service le plus important à avoir cessé de fonctionner. D’autres sites ont également rencontré des problèmes. Cloudflare indique […]

The post Quand une simple panne (Cloudflare) révèle la fragilité des infrastructures Internet first appeared on UnderNews.

Quand une simple panne (Cloudflare) révèle la fragilité des infrastructures Internet

19 novembre 2025 à 17:20

Un incident réseau chez Cloudflare, société spécialisée dans la sécurité web, a perturbé le trafic Internet et entraîné la panne de plusieurs sites hier à la mi-journée. Parmi les plateformes touchées, X (anciennement Twitter) figure comme le service le plus important à avoir cessé de fonctionner. D’autres sites ont également rencontré des problèmes. Cloudflare indique […]

The post Quand une simple panne (Cloudflare) révèle la fragilité des infrastructures Internet first appeared on UnderNews.

Panne Cloudflare : ce qui s’est passé dans le système anti-bots

19 novembre 2025 à 10:19

Cloudflare est formel : ce 18 novembre, il a subi sa « pire panne depuis 2019 ».

Cette dernière avait été déclenchée par le déploiement d’une règle WAF pour la détection XSS. Un problème de regex avait entraîné une surconsommation CPU sur les nœuds qui géraient le trafic HTTP(S). Le proxy principal était tombé, comme le CDN.

Le système de gestion des bots mis K.-O. par un changement de configuration

Cette fois, l’incident a pris racine dans un changement de permissions sur une base de données ClickHouse. L’idée était, dans les grandes lignes, de rendre explicite un accès jusque-là accordé implicitement aux utilisateurs lors des requêtes de tables système.

Faute d’un filtrage approprié, une requête s’est mise à générer des colonnes en double. Cette requête provenait d’un des modules du proxy principal : celui dédié à la gestion des bots.

Ce module exploite, entre autres, un modèle d’apprentissage automatique qui attribue un score à chaque requête. Il s’appuie sur un fichier de configuration réunissant des features (caractéristiques individuelles utilisées pour prédire si une requête est ou non automatisée).

Ce fichier est régulièrement rafraîchi – à intervalle de quelques minutes – et diffusé sur le réseau Cloudflare.
La version « doublonnée » a dépassé la limite de 200 features paramétrée dans le système de gestion des bots pour éviter la surconsommation de mémoire. Le module est ainsi passé en erreur, affectant tout le trafic qui en dépendait.

Des pannes en cascade et un tableau de bord inaccessible

D’autres services exploitant le proxy principal ont été touchés. Notamment Workers KV (magasin clé-valeur) et Turnstile (alternative aux CAPTCHA).
L’indisponibilité de ce dernier a empêché les connexions au tableau de bord – à moins d’avoir une session active.
Cloudflare Access (contrôle d’accès) a aussi connu des problèmes d’authentification.
En parallèle, la consommation CPU des systèmes de débogage et d’observabilité a accru la latence du CDN.

Vers 14 heures, soit une heure et demie après le début de l’incident, un correctif fut déployé sur Workers KV afin de contourner le proxy. Les taux d’erreurs sur les services aval se sont réduits.

D’autres difficultés ont été recensées par la suite, après la restauration d’une version saine du fichier de features. Le backlog de tentatives de connexion, combiné aux retries, a submergé le dashboard.

Cloudflare a d’abord cru à une attaque

Jusqu’à l’application du correctif pour Workers RV, le système a eu un comportement particulier : à plusieurs reprises, il a brièvement récupéré. Et pour cause : il arrivait qu’un fichier sain soit généré, en fonction de la partie du cluster sur laquelle s’exécutait la requête du service de gestion des bots.

Ce comportement a compliqué l’identification du problème. Jusqu’à ce que, finalement, tous les nœuds ClickHouse se mettent à générer le mauvais fichier.
Cloudflare a un temps pensé à une attaque, d’autant plus que sa page de statut, qui n’a pas de dépendance à ses services, était aussi tombée. Mais il s’agissait d’une « coïncidence »…

L’acheminement du trafic était largement revenu à la normale vers 15 h 30. Passé 18 heures, tous les systèmes de Cloudflare fonctionnaient normalement.

En conséquence de cette panne mondiale, l’entreprise promet de renforcer le contrôle de l’ingestion des fichiers que ses systèmes génèrent (mise sur le même plan que les fichiers générés par les utilisateurs). Elle compte aussi supprimer la possibilité que des dumps et autres rapports d’erreur épuisent les ressources système. Et réviser les modes d’échec pour les conditions d’erreur sur tous les modules de son proxy principal.

Illustration générée par IA

The post Panne Cloudflare : ce qui s’est passé dans le système anti-bots appeared first on Silicon.fr.

Reçu — 18 novembre 2025

Cloudflare, un autre pilier d’Internet en panne après AWS et Azure

18 novembre 2025 à 17:39

« Quand l’un [des] ‘gardiens du web’ vacille, c’est toute notre vie numérique qui s’arrête. »

La panne mondiale de Cloudflare a inspiré ce commentaire à mc2i.

Le cabinet de conseil n’est pas le seul à s’inquiéter de la dépendance d’Internet à des infrastructures portées par une poignée d’acteurs. Il l’est d’autant moins après les incidents majeurs qui ont récemment affecté AWS et Azure.

Chez le premier, quantité de services ont été perturbés en conséquence d’un souci de résolution DNS sur une base de données.
Chez le second, le problème est parti d’un état invalide introduit par un changement de configuration sur le CDN Azure Front Door.

Un bug dans le système de contrôle des bots

Cloudflare avait d’abord évoqué un « pic de trafic inhabituel »* vers un de ses services – et expliqué que le reste du trafic en avait pâti.

Son CTO est ensuite allé plus loin. À l’en croire, un changement de configuration a enclenché un « bug latent » dans un service concourant au contrôle des bots. S’en sont suivis des effets en cascade. « Ce n’était pas une attaque« , a-t-il ajouté.

Il était 12 h 20 en France, ce 18 novembre, quand l’incident a démarré. Cloudflare l’a signalé sur sa page de statut une demi-heure plus tard.

Vers 14 heures, on nous annonçait que le problème était identifié. Le déploiement d’un correctif restaurant l’accès au tableau de bord Cloudflare était officialisé vers 15 h 30. Une étape importante donnant aux clients la possibilité d’implémenter des mécanismes de contournement.

Quelques minutes plus tard, l’entreprise avait dit estimer que l’incident était résolu. C’est à ce moment-là que son CTO s’était exprimé.

Cloudflare a par la suite reconnu que certains clients pourraient encore rencontrer des problèmes de connexion ou d’utilisation du tableau de bord. Puis déclaré que les scores attribués aux bots seraient impactés par intermittence le temps de la récupération.

À 17 h 30, la situation continuait de s’améliorer, mais n’était pas encore pleinement revenue à la normale. À 18 h 15, la latence et le taux d’erreurs revenaient à des « niveaux normaux ».

ChatGPT, Claude, Gemini, Le Chat, Perplexity… Silence chez les chatbots

Touché, Canva a fait partie des clients qui ont explicitement attribué la responsabilité à Cloudflare. Touché tant sur ChatGPT que sur Sora et sur son API, OpenAI a simplement parlé d’un « fournisseur tiers ». Même chose pour Discord, qui a toutefois précisé que ce fournisseur rencontrait un « problème majeur »…

Également affecté, Coinbase a considéré que l’incident (« latence ou performance de connexion dégradée pour certains utilisateurs ») était résolu à 16 h 38. Chez Twilio, c’était fait une demi-heure plus tôt (problèmes de login pour les utilisateurs de Twilio et de Sengrid), à peu près en même temps que chez Sage (problèmes d’accès à certains produits).

ChatGPT n’a pas été le seul chatbot perturbé. Gemini (Google), Claude (Anthropic), Le Chat (Mistral AI) et Perplexity AI, entre autres, l’ont aussi été.

Un autre incident notable chez Cloudflare en juin 2025

Cloudflare avait connu une autre panne notable le 12 juin 2025. À la racine, une panne dans une dépendance externe. Elle a perturbé un service sur lequel beaucoup d’autres s’appuient : Workers KV.

Plus de 90 % des requêtes vers ce magasin clé-valeur ont produit des réponses 500 ou 503. Parmi les services aval touchés :

  • Access (contrôle d’accès), qui ne pouvait pas récupérer des informations de configuration et d’identité
  • Gateway (passerelle web), qui ne pouvait pas traiter certaines requêtes
  • WARP (VPN), dépendant d’Access
  • Browser Isolation (navigateur sécurisé), dépendant de Gateway pour certaines sessions
  • Turnstile (alternative aux CAPTCHA)
  • Images, qui ne pouvait plus gérer les téléversements par lots

Il avait fallu environ 3 heures pour résoudre le problème. Claude et Gemini en avaient souffert. Gmail aussi, ainsi que Snapchat, Spotify, Twitch, etc.

* Ce n’est pas le pic qui a été qualifié d’inhabituel, mais le trafic (« peak of unusual traffic »). Une formulation qui aurait pu faire penser à une attaque.

Illustration © Hywards – Shutterstock

The post Cloudflare, un autre pilier d’Internet en panne après AWS et Azure appeared first on Silicon.fr.

Reçu — 6 novembre 2025
Reçu — 10 juillet 2025
❌