Bonjour,
Depuis plusieurs jours nous constatons des débits particulièrement faibles depuis nos locaux à Locmaria Plouzané (29) en download (récupération de données depuis l'extérieur vers le réseau local) tandis qu'en upload (depuis le réseau local vers l'extérieur) les débits sont très bons.
Nous avons testé sur deux lignes fibre Bouygues différentes (la nôtre et celle du voisin), le résultat est le même donc il semble y avoir un souci en amont.
Un speedtest n'indique pourtant aucune anomalie ou trace de lenteur:
https://www.speedtest.net/result/19729735896.png (également testé avec des serveurs cibles qui ne sont pas chez Bouygues:
https://www.speedtest.net/result/19753436050.png https://www.speedtest.net/result/19753445251.png).
Un reboot de la Bbox n'a pas permis de résoudre le problème.
De plus, d'autres tests réalisés depuis des habitations proches (dans un rayon de 15km) mais chez d'autres opérateurs (Free et SFR) montrent que le problème ne vient pas du serveur distant:
*Download (2026-09-29)Fibre Bouygues:
output_dpgs_20150501.tgz.0 0% 3315KB
186.1KB/s 58:24:26 ETA
Fibre Free:
output_dpgs_20150501.tgz.0 0% 375MB
38.6MB/s 16:20 ETA
*Upload (2026-09-29)Fibre Bouygues:
lubuntu-26.04-desktop-amd64.iso 7% 265MB
9.2MB/s 06:19 ETA
Fibre Free:
ubuntu-22.04.1-desktop-amd64.iso 4% 164MB
6.0MB/s 09:40 ETA
Comme le montrent ces chiffres, la semaine dernière le débit en download via une commande scp dépassait difficilement les 250kB/s.
Aujourd'hui nous constatons une nette amélioration (environ 19MB/s) mais cela reste inférieur à ce que l'on obtient via les fibres Free ou SFR (~40MB/s).
Voici ce que donne un ``mtr`` vers la machine cible (accessible uniquement via un VPN) qui se trouve sur le réseau RENATER/GEANT:
mtr -4 --tcp --max-unknown 100 --max-display-path 100 --mpls --no-dns --interface br0 --report REDACTED
Start: 2026-10-05T14:35:49+0200
HOST: REDACTED Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.177.254 0.0% 10 0.6 0.6 0.4 0.7 0.1
2.|-- 192.168.20.1 0.0% 10 1.0 1.2 0.9 1.3 0.1 # c'est la Bbox
3.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
4.|-- 62.34.2.200 30.0% 10 7194. 3527. 7.2 7194. 2283.5
5.|-- 212.194.171.104 0.0% 10 19.7 19.7 19.5 19.9 0.1
6.|-- 62.34.2.248 0.0% 10 19.9 20.0 19.7 20.3 0.2
7.|-- 62.34.2.134 0.0% 10 5158. 1150. 19.2 5158. 1773.9
8.|-- 80.81.192.241 0.0% 10 22.6 22.7 22.3 23.0 0.2
9.|-- 5.57.80.168 0.0% 10 33.6 33.6 33.3 34.0 0.2
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11.|-- 83.97.89.9 0.0% 10 39.6 39.5 39.2 39.7 0.1
12.|-- 83.97.89.10 0.0% 10 35.5 35.6 35.3 35.9 0.2
13.|-- 193.51.177.175 0.0% 10 44.3 42.3 41.8 44.3 0.7
14.|-- 193.51.186.233 0.0% 10 52.2 52.2 51.9 52.5 0.2
15.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0Afin d'éliminer le facteur VPN de l'équation (on a déjà confirmé qu'il n'était pas en cause), un autre ``mtr`` vers un serveur OVH qui est accessible sans VPN et pour lequel nous constatons également un débit limité en download:
mtr -4 --tcp --max-unknown 100 --max-display-path 100 --mpls --no-dns --interface br0 --report 51.254.199.149
Start: 2026-10-05T16:43:52+0200
HOST: REDACTED Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.177.254 0.0% 10 0.7 0.6 0.6 0.7 0.0
2.|-- 192.168.20.1 0.0% 10 1.4 1.4 1.0 1.7 0.2 # c'est la Bbox
3.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
4.|-- 62.34.2.200 30.0% 10 7173. 3222. 7.2 7173. 2466.3
5.|-- 212.194.171.104 0.0% 10 14.3 14.0 13.2 14.5 0.4
6.|-- 212.194.170.70 0.0% 10 13.9 14.0 13.5 15.5 0.6
7.|-- 212.194.170.77 0.0% 10 13.7 13.8 13.5 14.1 0.2
8.|-- 62.34.2.90 90.0% 10 13.4 13.4 13.4 13.4 0.0
9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
13.|-- 54.36.50.229 0.0% 10 17.6 18.5 17.4 22.6 1.5
54.36.50.227
94.23.122.214
94.23.122.146
14.|-- 37.59.16.16 0.0% 10 18.5 19.6 18.5 20.4 0.7
37.59.16.24
37.59.16.20
37.59.16.12
15.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
16.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
17.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
18.|-- 51.254.199.149 0.0% 10 17.7 17.9 17.0 21.5 1.4Et un autre avec le classique 1.1.1.1:
mtr -4 --tcp --max-unknown 100 --max-display-path 100 --mpls --no-dns --interface br0 --report 1.1.1.1
Start: 2026-10-05T16:45:38+0200
HOST: REDACTED Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.177.254 0.0% 10 0.7 0.6 0.5 0.7 0.1
2.|-- 192.168.20.1 0.0% 10 1.1 1.2 0.9 1.7 0.2 # c'est la Bbox
3.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
4.|-- 62.34.2.200 30.0% 10 7158. 3225. 6.9 7158. 2464.0
5.|-- 212.194.171.104 0.0% 10 13.7 13.4 12.6 15.1 0.7
6.|-- 62.34.3.194 30.0% 10 5172. 3241. 12.9 7175. 2468.0
7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8.|-- 141.101.67.142 0.0% 10 13.1 12.9 12.6 13.1 0.2
141.101.67.143
9.|-- 141.101.67.189 0.0% 10 15.1 14.6 13.7 17.8 1.2
141.101.67.161
141.101.67.163
141.101.67.171
141.101.67.155
141.101.67.153
141.101.67.199
141.101.67.165
10.|-- 1.1.1.1 0.0% 10 13.9 13.5 12.6 14.9 0.7Et juste pour éliminer les doutes, 192.168.177.254 est un load-balancer qui fait uniquement un failover vers un autre appareil quand la connexion via BBox est indisponible, et les débits sont similaires que l'on se connecte au load-balancer ou directement à la BBox.
Ayant déjà eu l'occasion de contacter l'assistance Bouygues par le passé pour d'autres soucis techniques, je sais qu'il est très compliqué d'obtenir un/e interlocuteur/trice à qui ces éléments vont parler (et les transmettre par téléphone serait une galère sans nom...), c'est pourquoi je tente ma chance ici.
Est-ce que quelqu'un saurait s'il y a un incident pouvant expliquer ces performances particulièrement dégradées uniquement dans un sens?