Ca me semble étrange, je pensais que les OLT auraient une QoS capable de répartir la bande passante équitablement en cas de saturation (et donc dans le cas d'un utilisateur en speedtest et N autres en simple navigation, que seul le premier se retrouve avec des drops).

Non. En amont, tu n'as aucun moyen de savoir que le paquet vers le destinataire (celui qui tire à fond) va traverser une interface qui est en train de saturer en aval.

Quand tu essayes de rentrer 1.2Gbps dans 1Gbps, il y a forcément 200 mégas qui vont devoir soit attendre (genre que la conso tombe à 800 mégas pour les faire passer), soit être jetés.

Et là, la sélection des paquets qui vont etre jetés se fait un peu au petit bonheur la chance. Soit tu acceptes ce fait, soit tu priorises les paquets qui doivent absolument passer.

Et justement, il y aura du drop un peu chez tout le monde : moins de drop chez ceux qui consomment peu (donc TCP va devoir réduire un peu la bande passante, mais pas bcp).
Par contre, statistiquement il y aura du drop à fond de balle pour celui qui tire comme un goret. Et là, TCP va réajuster fortement le débit.

Aussi, gardez à l'esprit qu'un speedtest c'est très court, et que vous avez de plus en plus, des serveurs de 40 voire 100G devant vous.
Lui en face, il ne sait pas le débit que vous avez : il va saturer son interface (de 100G !) pour vous envoyer la purée : si vous acquittez tout à la réception, tant mieux. Mais sinon il réduit son débit pour s'adapter au vôtre.

Je parlais de l'OLT, qui a une vision directe de l'interface PON, et qui pourrait avoir une file par ONT (ou par adresse MAC).

Oui ça peut, mais attention ça peut vite devenir trèès lourd, car l'OLT doit potentiellement gérer des milliers d'ONT !
Par ex, je viens de vérifier, mes OLT (ZTE C320) gèrent 8 queues par port.

Après, même en GPON c'est hyper rare que ça droppe.