Détection de la fraude en périphérie : Cloudflare Workers + tracio.ai
Exécutez la validation de l'empreinte d'appareil dans Cloudflare Workers avant que les requêtes n'atteignent votre origine. Des décisions de fraude en moins de 5ms en périphérie.
La détection de fraude traditionnelle se fait au niveau applicatif : la requête arrive sur votre serveur, vous interrogez votre API de détection de fraude, attendez la réponse, puis décidez d'autoriser ou de bloquer. Cet aller-retour ajoute 50 à 200ms de latence à chaque requête — acceptable pour les chargements de page, mais pénible pour les endpoints d'API, les appels AJAX et les interactions en temps réel.
Et si vous pouviez prendre la décision de fraude avant que la requête n'atteigne votre serveur d'origine ? C'est ce que permet l'edge computing, et Cloudflare Workers est la plateforme que nous utilisons pour illustrer ce modèle.
L'architecture
Le montage comporte trois composants : le SDK JS de tracio.ai (@tracio/sdk) s'exécutant dans le navigateur, un Cloudflare Worker placé entre le client et votre origine, et des webhooks tracio.ai signés livrant l'analyse complète des signaux à votre backend.
Le flux fonctionne ainsi : le SDK JS collecte les signaux d'appareil et les envoie à tracio.ai pendant le chargement de la page, renvoyant un visitorId au navigateur. Votre backend reçoit le résultat d'identification complet — classification de bot, smart signals, confiance — via un webhook signé et écrit le verdict dans un cache en périphérie. Le navigateur inclut le visitorId dans les requêtes d'API suivantes (via en-tête ou cookie). Le Cloudflare Worker intercepte chaque requête, consulte le verdict mis en cache pour ce visitorId et prend une décision allow/block en moins de 5ms.
Implémentation du Worker
Le Worker maintient un cache léger des résultats récents de vérification d'appareil à l'aide du stockage KV de Cloudflare, alimenté par votre backend à mesure que les webhooks tracio.ai signés arrivent. Lorsqu'une requête arrive avec un en-tête visitorId, le Worker consulte le cache. Si le verdict est en cache et que le visiteur est propre (faible score de bot, pas de VPN, confiance au-dessus du seuil), la requête passe immédiatement. Si aucun verdict n'est encore en cache, le Worker applique votre politique de repli — laisser passer avec une limitation de débit prudente, ou soumettre à un défi — jusqu'à ce que le cache alimenté par les webhooks se mette à jour.
L'idée essentielle est que le cache de vérification est alimenté de façon proactive. Le premier chargement de page déclenche la collecte de signaux et met le résultat en cache. Tous les appels d'API suivants de ce visiteur touchent le cache — aucun aller-retour vers tracio.ai nécessaire. Le TTL du cache est configurable ; nous recommandons 5 minutes pour les endpoints à haute sécurité et 30 minutes pour le contenu général.
Chiffres de performance
Nous avons évalué cette architecture avec un client traitant 50 000 requêtes par minute via Cloudflare Workers. Résultats :
Taux de succès du cache : 94% (la plupart des requêtes proviennent de visiteurs ayant déjà chargé une page). Latence de décision en périphérie (succès de cache) : 1.2ms médian, 3.8ms p99. Latence de décision en périphérie (échec de cache) : 45ms médian (inclut l'appel d'API vers tracio.ai). Économie de latence d'origine : 120ms médian par requête (contrôle de fraude côté serveur supprimé).
Le taux de succès de cache de 94% signifie que 94% des décisions de fraude se prennent en moins de 4ms en périphérie, sans aucune implication de l'origine. Les 6% restants sont des requêtes de première visite qui nécessitent un aller-retour d'API complet.
Stratégies de blocage
Le Worker prend en charge trois stratégies de blocage, configurables par route :
Blocage strict : renvoyer immédiatement un 403 pour les visiteurs à haut risque (score de bot > 0,9, framework d'automatisation connu). Blocage souple : ajouter des en-têtes X-Tracio-Risk et laisser l'origine décider. C'est utile lorsque vous voulez un contexte applicatif pour la décision. Défi : rediriger les visiteurs suspects (score de bot modéré, VPN détecté) vers une page de défi qui exige une vérification supplémentaire.
Nous recommandons de commencer par le blocage souple en production, de surveiller la distribution du risque pendant une semaine, puis d'activer le blocage strict pour les cas nets (bots connus, navigateurs headless, automatisation à haute confiance).
Analyse des coûts
La tarification de Cloudflare Workers repose sur les requêtes et le temps de calcul. À 50K requêtes/minute (2,16 milliards/mois), le coût du Worker est d'environ 500 $/mois. Comparez cela aux économies de latence : supprimer 120ms de contrôle de fraude côté origine réduit l'utilisation CPU des serveurs de 15 à 20%, ce qui économise généralement plus que le coût du Worker en calcul.
La vraie valeur réside dans la prévention de la fraude : intercepter les bots et les requêtes frauduleuses avant qu'ils ne consomment les ressources d'origine, les connexions à la base de données et les appels d'API en aval. Un client a fait passer son nombre de serveurs d'origine de 12 à 8 après avoir mis en place la détection de fraude en périphérie — les bots qui consommaient 30% de son calcul n'atteignaient plus jamais l'origine.