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.
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...
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 :
Connexionlive_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 !
Tout commence en mars 2026, lors d’une opération de surveillance routinière.
Les équipes de Cloudforce One, la division de renseignement sur les menaces de Cloudflare, détectent une anomalie dans des scripts Workers déployés sur la plateforme serverless de l’entreprise.
Parmi ces scripts, utilisés pour mettre en place des tunnels de proxy VPN via le protocole VLESS, l’un d’eux contient des milliers de lignes de commentaires répétitifs, rédigés en plusieurs langues. Il s’agit de des blocs de texte en langage naturel destinés non pas aux développeurs humains, mais aux systèmes d’intelligence artificielle chargés d’auditer le code.
Ces commentaires constituent ce que les chercheurs appellent des leurres de sécurité « Notice to AI » ». Soit des instructions dissimulées dans du code, conçues pour convaincre un modèle d’analyse automatisée que le script est inoffensif.
C’est la définition même de l’injection de prompt indirecte (Indirect Prompt Injection, ou IDPI), un vecteur d’attaque qui cible non plus les systèmes traditionnels, mais la couche de raisonnement des LLM utilisés comme outils de sécurité.
Suite à cette découverte, Cloudforce One a lancé une étude systématique pour évaluer l’impact réel de cette technique sur les capacités de détection des modèles.
Dans une première phase, les chercheurs avaient testé de courts extraits de code (environ 2 000 tokens), concluant que les leurres étaient largement contre-productifs : pour la plupart des modèles non-frontier, une accumulation de fausses déclarations de sécurité agissait comme un signal d’alarme, augmentant la détection plutôt que de la réduire.
Mais cette première phase laissait deux variables critiques non explorées : la saturation et le contexte. Un attaquant réel ne se contente pas d’insérer un bloc de texte en début de fichier ; il peut disperser ses commentaires tout au long du script, et l’auditeur IA analyse le fichier complet, pas seulement les premières lignes.
La phase 2 a donc été conçue pour combler ces lacunes :
Sept modèles ont été évalués, répartis en deux catégories : les modèles non-frontier (rapides, optimisés pour le coût) et les modèles frontier (systèmes de pointe avec raisonnement avancé).
L’étude révèle un phénomène contre-intuitif. L’efficacité des leurres suit une courbe en U selon le volume de commentaires injectés. Un volume modéré (1 à 20 commentaires) suffit à abaisser significativement les taux de détection des modèles non-frontier les plus vulnérables. Le taux de détection du modèle non-frontier le plus faible chute de 90 % à 67 %.
Mais à l’extrême opposé (1 000 commentaires ou plus), la stratégie se retourne contre l’attaquant. La répétition massive déclenche ce que les chercheurs appellent une « alarme de répétition », et la plupart des modèles finissent par reconnaître cette saturation comme un signe caractéristique de fraude.
Le constat le plus opérationnel concerne non pas le nombre absolu de commentaires, mais leur ratio par rapport au code fonctionnel.
Lorsque les leurres représentent moins de 1 % du fichier total, ils sont les plus efficaces. Le taux de détection moyen sur l’ensemble des modèles testés s’effondre à 53,3 %, contre 67,3 % en conditions normales. Les commentaires sont alors suffisamment discrets pour influencer subtilement le raisonnement du modèle sans déclencher de suspicion.
À l’inverse, dès que les commentaires dépassent 25 % du fichier, ils deviennent une signature à haute valeur discriminante : le taux de détection remonte à 99 %, les modèles interprétant cette surreprésentation comme un indicateur clair d’intention malveillante.
La découverte la plus significative de l’étude dépasse la problématique des leurres linguistiques. Quelle que soit la sophistication des commentaires injectés, c’est la taille des fichiers qui constitue le facteur de risque le plus important.
Pour des scripts Workers inférieurs à 500 Ko, les taux de détection approchent les 100 %. Pour des fichiers dépassant 3 Mo ( notamment des bundles de bibliothèques légitimes comme les SDK TON ou React ), ce taux s’effondre à seulement 12 à 18 %.
L’explication est double. Soit le code malveillant se retrouve hors de la fenêtre de contexte du modèle, soit il est tellement dilué par du code bénin environnant que l’attention du modèle ne parvient plus à l’isoler.
Dans ce deuxième cas, même lorsque l’ensemble du fichier tient dans la fenêtre de contexte, la logique malveillante ( par exemple, une exfiltration de données vers Telegram) reste indétectable, noyée dans des milliers de lignes de code légitime.
L’étude met également en évidence des stéréotypes linguistiques développés par les modèles. Lorsque les scripts contiennent 1 000 commentaires dans différentes langues, les réactions varient sensiblement :
Ces stéréotypes linguistiques constituent à la fois un levier potentiel pour les attaquants — en choisissant la langue la moins susceptible de déclencher des alertes — et un risque de faux positifs pour les défenseurs.
Un dernier phénomène mérite l’attention des équipes de sécurité.
Face à un volume extrême de commentaires (1 000 et plus), certains modèles frontier n’ont pas été trompés, mais ont cessé de fonctionner correctement : au lieu de rendre un verdict binaire « malveillant / bénin », ils ont produit des réponses mal formatées ou des refus.
Dans un pipeline de sécurité automatisé qui repose sur des sorties JSON structurées pour déclencher des blocages, cette paralysie fonctionnelle équivaut à un contournement.
L’attaquant n’a pas besoin de convaincre l’IA que son code est sûr ; il lui suffit de la rendre incapable d’émettre une commande de blocage.
Pour renforcer les pipelines d’audit IA, les chercheurs proposent plusieurs mesures concrètes :
L’étude de Cloudforce One apporte une nuance importante au débat sur les risques de l’injection de prompt. Si la tromperie linguistique reste une menace réelle, notamment dans la « zone de contournement à 1 % », les modèles frontier s’avèrent globalement plus résistants qu’attendu face aux leurres textuels.
La véritable vulnérabilité se situe dans la capacité des attaquants à noyer un payload malveillant dans un volume de données légitimes suffisant pour saturer l’attention des modèles.
En d’autres termes, les adversaires n’ont plus besoin de convaincre l’IA que leur code est sûr. Ils ont seulement besoin de rendre le signal malveillant trop faible pour être détecté.
The post Les IA de sécurité, nouvelles cibles de l’injection de prompt appeared first on Silicon.fr.
Désormais, plus de la moitié des bots sont spécifiquement destinés à entraîner des IA.
Cette statistique ne vaut peut-être pas pour le web dans son entièreté. Elle vaut en tout cas pour le réseau Cloudflare*. Sur les 7 derniers jours, le taux de bots « spécial entraînement » a dépassé les 52 %, contre 8 % dédiés à la recherche et 37 % ayant des finalités mixtes.
Cette part est en progression. Si on étend la fenêtre aux 3 derniers mois, elle avoisine 49 %. En élargissant sur les 6 derniers mois, elle tombe autour de 44 %. Et sur les 12 derniers mois, sous les 40 %.
Sur le « top 10 000 » des domaines connectés à son réseau, Cloudflare a pu analyser 4094 fichiers robots.txt.
GPTBot y est le bot le plus souvent bloqué (au moins partiellement). Suivent CCBot (de Common Crawl), ClaudeBot, Google-Extended et Bytespider (de ByteDance, éditeur de TikTok).
GPTBot est, en même temps, le troisième bot le plus souvent autorisé (au moins partiellement), devant PerplexityBot et ChatGPT-User (qui visitent tous deux des pages web en réponse à des requêtes d’utilisateurs).
Sur les sites étiquetés « Technologie » (926 fichiers robots.txt), on bloque surtout GPTBot (70 occurrences), CCBot (67) et ClaudeBot (59).
On autorise avant tout PerplexityBot (58), GPTBot (57) et Googlebot (52).
En catégorie « Business » (797 fichiers), on bloque avant tout GPTBot (55), Amazonbot (51) et ClaudeBot (50).
On autorise essentiellement GPTBot (46), Googlebot (42) et PerplexityBot (41).
En catégorie « E-commerce » (291 fichiers), les plus bloqués sont Googlebot (44), ClaudeBot (40) et GPTBot (40).
Les plus autorisés sont Googlebot (35), bingbot (20) et OAI-SearchBot (20 ; dédié à l’indexation de contenus pour ChatGPT).
En catégorie « Actualités/Médias » (183 fichiers), les blocages portent principalement sur CCBot (81), GPTBot (76) et ClaudeBot (71). Les autorisations, bien moins nombreuses, sur Googlebot (22), OAI-SearchBot (19) et GPTBot (19). Elles sont souvent partielles.
Cloudflare propose un outil pour évaluer si un site est « prêt pour les agents ». Parmi les « 200 000 principaux domaines » testés, il en a retenu un échantillon de 109 415 et y a mesuré le niveau d’implémentation de diverses technologies.
78 % de ces domaines ont un fichier robots.txt ; 63 %, un sitemap.
Ils sont 17 % à avoir intégré des règles IA dans robots.txt. 9 % exploitent les en-têtes Link, qui permettent de sérialiser plusieurs liens – et ainsi, typiquement, de pointer vers des métadonnées relatives à la ressource demandée.
On tombe à 6 % pour la négociation Markdown. Il s’agit d’une initiative de Cloudflare. Le principe : exploiter les en-têtes de négociation de contenu pour effectuer, à la source, une conversion du HTML en Markdown, format plus adapté aux IA.
On est également autour de 6 % pour la découverte OAuth. La spec sous-jacente (RFC 8414, Authorization Server Metadata) permet au client de rechercher les informations nécessaires pour interagir avec un serveur OAuth.
L’Universal Commerce Protocol, que Google propose pour encadrer le commerce agentique, a un taux d’adhésion d’un peu plus de 5 %. On en est à 4,5 % pour une autre techno made in Cloudflare : Content Signals. Cette extension de robots.txt implémente un mécanisme pour expliquer aux systèmes automatisés comment utiliser du contenu. Elle s’appuie sur trois signaux pour autoriser respectivement la construction d’un index de recherche, l’exploitation du contenu en tant qu’input pour des réponses générées en temps réel et son utilisation pour l’entraînement ou le fine-tuning.
L’adhésion est quasi nulle (< 0,1 %) pour les briques suivantes :
Cloudflare a catégorisé les 109 415 domaines en attribuant à chacun une ou plusieurs étiquettes sectorielles. Ci-dessous, un aperçu de l’adoption des différentes technologies dans les dix catégories les plus fournies. Nous nous limitons à celles pour lesquelles le taux atteint au moins 1 %.
| Règles IA | En-têtes Link | Content Signals | Négociation Markdown | Universal Commece Protocol | Découverte OAuth | |
| Technologie (46 239 domaines) |
4,6 % | 5,2 % | 1,6 % | 1,5 % | ||
| Business/économie (25 257) | 2,5 % | 3,3 % | 1, 2% | |||
| Divertissement (23 747) | 5,8 % | 1,9 % | 1,2 % | |||
| Business (19 768) | 1,9 % | 2,8 % | 1,1 % | |||
| Shopping/enchères (18 530) | 3,1 % | 4,2 % | 4,1 % | 4,1 % | ||
| E-commerce (15 964) | 2,5 % | 4,1 % | 4,1 % | 4 % | ||
| Éducation (14 829) | 2,4 % | 1,1 % | ||||
| Société/lifestyle (13 716) | 2,2 % | 3,2 % | 3,2 % | 3,3 % | ||
| Automobile (7834) | 1,8 % | |||||
| Actualités/médias (6951) | 2,2 % |
Sur la base du trafic vers le résolveur DNS 1.1.1.1, chatgpt.com a brièvement fait partie des 10 domaines les plus populaires, vers la mi-avril.
Si on trie par services, ChatGPT/OpenAI est apparu dans le top mondial 10 mi-février. Il s’y est globalement maintenu jusqu’à mi-avril. La situation est similaire sur le périmètre France.
Si on mesure le nombre de clients uniques connectés, le .ai a été, sur les 12 derniers mois, le 13e TLD le plus populaire. Créé en 1995, il est rattaché à Anguilla, territoire britannique des Caraïbes de moins de 20 000 habitants. En mars, il a atteint le million de domaines enregistrés.
* Cloudflare affirme qu’environ 20 % du web est connecté à son réseau.
Illustration principale générée par IA
The post Le web s’approprie lentement les briques censées l’ouvrir aux IA appeared first on Silicon.fr.
