faisons avec iperf3 pour lever tout doute:

memes machines de chaque coté:

CAS 1
------

PC chez Free (freepro en l'occurence) - serveur chez Scaleway

BBR: 6,6 Gbps
iperf3 -c scaleway.testdebit.info -p 9239 -R -C bbr
...
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.04  sec  7.77 GBytes  6.64 Gbits/sec  254306             sender
[  5]   0.00-10.00  sec  7.75 GBytes  6.66 Gbits/sec                  receiver
CUBIC: 1 Gbps

iperf3 -c scaleway.testdebit.info -p 9239 -R -C cubic
....
[  5]   0.00-10.04  sec  1.21 GBytes  1.04 Gbits/sec  184             sender
[  5]   0.00-10.00  sec  1.20 GBytes  1.03 Gbits/sec                  receiver

on remarquera le  nombre élevé de retransmissions en bbr, 254k contre  184 en cubic montrant bien les pertes de paquets.

résultats similaires et conformes a checkftthfree

résultats similaire en utilisant paris.testdebit.info (Bytel).

On peut se dire c'est la faute des serveurs chez Scaleway ET chez Bytel ? aucun autre FAI que Free n'a d'offre au delà de 2Gbps donc difficile de comparer. Mais on peut avec une VM dans un DC:

CAS 2
------
VM chez GCP (c'est gratuit si vous voulez tester vous meme)

BBR: 4.7 Gbps
$ iperf3 -c scaleway.testdebit.info -p 9239 -R -C bbr
...[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.04  sec  5.54 GBytes  4.74 Gbits/sec    1             sender
[  5]   0.00-10.00  sec  5.53 GBytes  4.75 Gbits/sec                  receiver
CUBIC: 4.6 Gbps
$ iperf3 -c scaleway.testdebit.info -p 9239 -R -C cubic
...
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.04  sec  5.35 GBytes  4.58 Gbits/sec   21             sender
[  5]   0.00-10.00  sec  5.34 GBytes  4.59 Gbits/sec                  receiver

donc en pratique, aucune différence. pour sur le lien n'est absolument pas saturé.

Dans les 2 cas, c'est du peering direct il n'y a pas d'AS intermédiaire dans les traceroute.

Y'a donc bien un souci avec Free et a priori avec JN (freepro) aussi ... donc cette perte de paquets serait dans la partie FTTH (commune a Free et Freepro) ?

Donc soit c'est les freebox qui ont un souci a haut débit (>1Gbps) soit le réseau de collecte de Free est saturé ou perd des paquets. Dans les 2 cas y'a clairement un problème chez Free.

C'est de l'IPv6 dans mes tests.

Mais donc il y a très peu de raison que ce soit une saturation du réseau Free, ou même de ses interconnexions, un lundi de pentecôte en milieu d'après-midi... Ce que confirment les chiffres de latence, les tests Nperf, un test ookla en mono-connexion sur le serveur Milkywan, et un test Netflix, voir ci-dessous.

Je ne vois pas ce que confirme la latence ou tes tests vis a vis d'une saturation... ou meme un lundi de pentecote. surtout un lundi de pentecote, un réseau GP est plus sollicité en journée.

N'oubliez pas que c'est un jour férié pas comme les autres, la fameuse "journée de solidarité" (qui est travaillée, selon vos conventions / entreprises).

hypothese: collecte en agrégation de liens physiques de N x 1 Gbps plutôt que liens directement en 10Gbps ou 100Gbps comme font les autres FAI.

Déjà, pour atteindre 10 Gb/s, il faudrait 10 liens 1 Gb, donc 10 ports. Cela fait trop de ports et de SFP, alors qu'un port SFP+ et un module SFP+ ne coûte plus grand chose. Peu crédible.

je suppose que tu testes bien la latence sur les mêmes serveurs ?

Ou bien sûr, l'outil teste la latence avec le serveur qui va servir au test de débit qui est fait juste après (le but étant de s'assurer que la configuration de la mémoire tampon TCP n'est pas le facteur limitant pour le test, et pour cela il faut connaître la latence...).

Alors là, j'ai fait le test, en IPv6, pas de perte de paquets prononcée, en IPv4 oui... Mais les valeurs me paraissent pas très éloignées, 14.7 et 17.9%, et dans les deux quand même assez éloignées de la normale.

Je ne comprends pas très bien pourquoi tu indiques qu'en IPv6 tu n'as pas de perte de paquets prononcée ? D'après tes résultats juste en dessous:

$ ./checkFtthFree.pl -6
...
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
      (ratio débit CUBIC/BBR: 14.73%)


Et donc sur les serveurs Bouygues Telecom (option -a), pas de perte de paquets significative, mais quand même 14.6%...

Pareil pour Bouygues, d'après tes résultats:

$ ./checkFtthFree.pl -a
...
[!] La connexion aux serveurs de test semble affectée par une perte de paquets prononcée
      (ratio débit CUBIC/BBR: 14.64%)