API pour agents et LLM
Ce n’est pas une API séparée : c’est exactement la surface que le navigateur appelle quand vous lancez le test de vitesse sur ce site, documentée pour qu’un script, un agent ou un outil LLM puisse l’appeler aussi. Pas de clé, pas d’inscription, pas de CORS.
Il n’y a pas d’« API publique » séparée ici : ce sont les quatre mêmes points de terminaison que le navigateur de ce site appelle pour lancer un test de vitesse, sans clé d’API, sans compte, et — voir plus bas — sans en-tête CORS.
Points de terminaison
/api/speed/pingSans limiteUne sonde minimale d’aller-retour.
Le champ t de la réponse est purement informatif. Les Workers gèlent Date.now() entre les opérations d’E/S, ce n’est donc pas une horloge fiable pour mesurer la latence — chronométrez la requête vous-même.
/api/speed/metaSans limiteReflète ce que Cloudflare voit de l’appelant : IP, FAI, ASN, ville, pays, et le point de présence (colo) qui a répondu.
Rien n’est stocké ici. C’est renvoyé à l’appelant et à personne d’autre.
/api/speed/down600 jetons / heure / IPDiffuse bytes (paramètre de requête, 1 Mo par défaut, plafonné à 100 Mo) de données aléatoires, pour mesurer la vitesse de téléchargement.
La réponse est no-store, no-transform — rien ne la compresse ni ne la met en cache, ce qui gonflerait la vitesse mesurée.
/api/speed/up600 jetons / heure / IPAccepte un corps de requête allant jusqu’à 100 Mo et indique combien d’octets sont arrivés et en combien de temps, pour mesurer la vitesse d’envoi.
Un Content-Length déclaré au-delà de 100 Mo est rejeté avec 413 avant même de lire le corps.
La limite d’usage, en chiffres
/api/speed/down et /api/speed/up partagent un même quota de 600 jetons par IP, rechargé d’un jeton toutes les 6 secondes. Cela fait environ 10 tests de vitesse complets par heure — un test complet utilise bien moins de 60 requêtes. /api/speed/ping et /api/speed/meta sont sans limite : leurs réponses sont triviales, et les limiter ajouterait une lecture KV exactement sur le chemin qu’ils existent pour mesurer.
La plus grande requête que l’un ou l’autre point de terminaison sert ou accepte est de 100 Mo.
Pas de CORS — volontairement
Ces points de terminaison n’envoient aucun en-tête Access-Control-Allow-Origin, et aucun ne passe par la vérification de même origine que ce site utilise sur ses routes de compte et de facturation. Cette combinaison est délibérée : un appelant côté serveur — curl, un agent, un outil LLM — fonctionne déjà aujourd’hui, tandis qu’un navigateur exécutant du JavaScript cross-origin contre ces points de terminaison est déjà bloqué par le navigateur lui-même. Ajouter un CORS * permettrait à n’importe quel site web de consommer la bande passante de ce site depuis les navigateurs de ses propres visiteurs ; documenter la situation actuelle ne coûte rien et ne change rien.
Un exemple concret — curl
Téléchargez 5 Mo et chronométrez — la forme standard d’une vérification manuelle de débit.
curl -o /dev/null -w "%{time_total}s for %{size_download} bytes\n" \
"https://mysygnal.net/api/speed/down?bytes=5000000"Un exemple concret — un agent ou un outil LLM
La même mesure, chronométrée par l’appelant plutôt que de faire confiance à la réponse — voir la note sur /api/speed/ping ci-dessus.
const t0 = performance.now();
const res = await fetch("https://mysygnal.net/api/speed/down?bytes=5000000");
await res.arrayBuffer();
const seconds = (performance.now() - t0) / 1000;
const mbps = (5_000_000 * 8) / seconds / 1_000_000;Tout ce que ce site offre par ailleurs à un appelant
llms.txt indexe les outils, les guides et chaque page de routeur de ce site dans un seul fichier texte brut, pensé pour être lu par un modèle plutôt que par un navigateur.