Méthodologie · transparence technique

Comment nous mesurons vraiment votre connexion

Ne demandez pas à un test de vitesse de vous croire sur parole. Nous expliquons ici étape par étape le fonctionnement de RealMbps : serveurs cibles, algorithmes adaptatifs, percentiles, gestion des erreurs. Tout est vérifiable, tout est transparent.

1. Architecture

Le test s'exécute entièrement dans votre navigateur (JavaScript client-side), en interrogeant l'infrastructure globale Cloudflare :

• Latence/gigue : https://speed.cloudflare.com/__down?bytes=N avec N petit (1 Ko), pour obtenir des RTT minimaux
• Download : le même endpoint avec N variable de 1 Mo à 50 Mo
• Upload : https://speed.cloudflare.com/__up POST
• Géolocalisation : https://speed.cloudflare.com/meta

Cloudflare sélectionne automatiquement le PoP le plus proche de votre IP (environ 300+ data centers globaux). Aucun serveur « complaisant » installé dans le réseau de votre opérateur, comme cela peut arriver avec d'autres tests.

2. Mesure de la latence (ping) et de la gigue

Nous effectuons 12 mesures successives d'un téléchargement de 1 Ko. Pour chacune, nous calculons le temps aller-retour (RTT). Ensuite :

• Ping = médiane des 12 valeurs (exclut les outliers)
• Gigue = déviation moyenne absolue par rapport à la médiane

Pourquoi la médiane et pas la moyenne ? La moyenne est sensible aux outliers (un seul paquet perdu peut la gonfler). La médiane reflète la latence « typique » que vous ressentez en usage normal.

3. Mesure du download

Nous effectuons des requêtes de tailles croissantes (1, 2, 5, 10, 25, 50 Mo) jusqu'à disposer d'assez d'échantillons. Pour chaque requête :

1. Nous mesurons le temps de transfert avec performance.now()
2. Nous calculons le throughput en Mbps = (octets × 8) / (secondes × 1 000 000)
3. Nous ajoutons la valeur à la liste des échantillons

L'estimation finale est le 90e percentile de la seconde moitié des échantillons. Traduit : nous écartons la phase initiale (TCP slow-start, pendant laquelle la vitesse est artificiellement basse) et nous prenons la valeur « stable » atteinte en régime, en excluant seulement les pics anormaux au-dessus du 90e percentile.

4. Mesure de l'upload (avec algorithme adaptatif)

L'upload est la partie la plus délicate, surtout sur réseau mobile. Notre approche :

• Chunks adaptatifs : nous partons de blocs petits (256 Ko) et les doublons si le réseau tient. Sur réseau rapide (FTTH), nous montons jusqu'à 8 Mo ; sur mobile lent (5 Mbps réels), nous restons à 256-512 Ko mais faisons beaucoup d'échantillons.
• Workers parallèles : 3 connexions parallèles sur desktop, 1 sur mobile (sous 720 px) pour ne pas saturer l'upload avec une concurrence inutile.
• Timeout par requête : chaque POST a un AbortController qui l'interrompt après 3 secondes (ou le temps restant). Un incident du réseau cellulaire ne bloque pas le test.
• Tolérance aux erreurs : jusqu'à 8 échecs transitoires acceptés avec backoff et réduction automatique du chunk.
• Estimation finale : 75e percentile de la seconde moitié des échantillons (plus conservateur que le download, car l'upload tend à être plus bruité).

5. Ce qui influence les résultats

Même avec la meilleure méthodologie, certains facteurs sont hors de notre contrôle et influencent la mesure :

• Wi-Fi : en FTTH 1 Gbps, le Wi-Fi domestique dépasse rarement 400-600 Mbps réels. Pour mesurer la ligne, utilisez un câble Ethernet.
• Matériel : les vieux PC en Wi-Fi 802.11n ne dépassent pas 150 Mbps réels. Les smartphones d'entrée de gamme limitent de façon similaire.
• VPN actif : ajoute un saut intermédiaire, réduit la vitesse et augmente le ping.
• Autres activités à la maison : streaming TV, enceintes connectées, caméras consomment de la bande passante silencieusement.
• Navigateurs obsolètes : HTTP/2 mal implémenté réduit le throughput.
• Charge réseau de l'opérateur : entre 21h et 23h (créneau de pointe en soirée), la vitesse réelle peut baisser de 20 à 30 %.

6. Marges d'erreur typiques

En comparant RealMbps à des mesureurs officiels (ex. le test officiel de l'ARCEP en France, breitbandmessung.de en Allemagne), les erreurs typiques sont :

• Download : ±5 % en conditions contrôlées (câble Ethernet, aucune autre activité)
• Upload : ±10 % (plus variable par nature)
• Ping : ±2 ms
• Gigue : ±1 ms

Pour un usage personnel et diagnostique, RealMbps est parfaitement adapté. Pour un usage légal (réclamation formelle à l'opérateur avec valeur probante), il faut un mesureur reconnu par le régulateur national : voir nos guides locaux sur comment bien mesurer et comment réclamer.

7. Transparence et code source

L'algorithme est entièrement en JavaScript chargé par le navigateur. Vous pouvez l'inspecter avec :

• F12 (DevTools) → onglet « Sources » → fichier script.js
• Cherchez les fonctions measureLatency(), measureDownload(), measureUpload()

Aucune obfuscation, aucun code caché. Ce que vous voyez est ce que nous mesurons.

8. Différences avec d'autres tests de vitesse

Ce qui rend RealMbps différent de Speedtest by Ookla, Fast.com, etc. :

• Serveurs neutres Cloudflare, pas des serveurs contrôlés par votre opérateur (Speedtest.net utilise souvent des serveurs in-network)
• Privacy first : pas de cookies de suivi, pas de collecte d'IP, pas de vente de données
• Algorithme adaptatif pour mobile : nous garantissons un upload mesuré même sur 4G/5G lent (Speedtest.net échoue ou sous-estime souvent sur mobile)
• Méthodologie ouverte : documentée sur cette page et inspectable dans les DevTools
• Wall communautaire : classement public pour la gamification et la comparaison avec d'autres utilisateurs de votre pays