Je suis d'accord sur les prix déraisonnables des forfaits "haut de gamme" d'Orange, mais on ne peut pas prétendre que Sosh est une entité distincte.
Sur les forfaits Sosh 5G, on est bien à ~25% plus cher que la concurrence, et ça me paraît être un surcoût acceptable vis-à-vis de la qualité du réseau.

Acceptable ? Alors que l’intégralité des indicateurs, vagues après vagues , montre que à minima les  3 réseaux  historiques valent globalement la même chose ?

Justement. C’était acceptable et ce ne l’est plus aujourd’hui.

Ce que l’on observe ici finalement, cela traduction technique de la perte du Monopole d’Orange. Reste le volet commercial, qui pour l’instant tient encore.

Si Orange en est à vouloir récupérer quelques clients de SFR dans le cas d’un rachat-partage, ça veut bien dire qu’ils ont peur de passer second Derrière un Bouygues-SFR par exemple.

Si ce n'est qu'une question d'ONT je peux te filer le mien @Toctoc, c'est un modèle à 1Gb/s de mon époque K-Net qui ne servira plus jamais à rien.

Merci de l'offre. Juste pour info cela ressemble à quoi un ONT 1Gb/s ? cela peut se repérer visuellement la différence ou par une référence ?
C'est surtout ce détail qui m'intéresse actuellement
Merci 

Pourquoi Jool n'est-il pas lancé dans l'espace réseau principal ?

As I said in this comment, I do not see any problems with filtering in mangle, but some iptables documentation does (apparently). I do not know the reasoning, so I will neither discourage nor encourage it.
On the other hand, now that Jool can be enclosed in a namespace, filtering can be done in the forwarding chains. This might not look as clean as it could be, but is no different than if Jool were a device
driver. So either way, it looks like this is no longer an issue.

Source : GitHub

Alternatively, if you know what you’re doing, you can filter on mangle.

Source : Netfilter design

Dans l'image ci-dessus, on voit DNAT dans Prerouting Hook et SNAT dans Postrouting Hook.

prerouting: sees all incoming packets, before any routing decision has been made. Packets may be addressed to the local or remote systems.
postrouting: sees all packets after routing, just before they leave the local system.

Source : Configuring chains

Dans la doc. de nftables, on peut voir que l'on peut filtrer dans la famille inet, dans une chaîne de type filter, aux crochets prerouting et postrouting.

Sur le site Web de Jool on recommande d'utiliser un espace de nom séparé pour le filtrage des paquets. Mais l'auteur reconnaît sa méconnaissance.

Le passage ci-dessous provient de la documentation OpenWrt. Il a été re-basé ultérieurement en suivant un tutoriel d'Ondřej Caletka.

Option 1 - Running in the main network namespace

Pros

• easy to activate
• basic integration with the uci configuration system

Cons

• hard to enforce firewall rules
• translation not available for locally (on the router) generated traffic
• fights over dynamic port numbers
• needs to be reconfigured every time the public IPv4 changes

Source : OpenWrt.org

Au final, il me semble que les arguments avancés ci-dessus ne sont pas valides.

Les deux derniers points sont également présents dans un NAT44. Le routeur est en double pile donc le trafic IPv4 local ne devrait pas transiter par le traducteur NAT64.

Le premier point s'avère effectivement problématique. Est-ce que l'on peut filtrer normalement le trafic n'étant pas destiné à traverser le NAT64 (IPv6 natif) ? Il semblerait
qu'en principe tout le trafic soit intercepté par le traducteur. C'est la partie obscure. De plus, faut-il aussi filtrer dans le sens inverse IPv4 WAN (NAPT) vers IPv6 du LAN ?
Il me semble que non car le trafic doit avoir été initié par un hôte du réseau local mais je ne maîtrise pas ces concepts.

Édition : Le troisième point peut être problématique si on a des réseaux IPv4 et IPv6.

Ben non...

Je vais faire le vieux con, mais l'ONT en question est propriété de ton OI. 
A moins que vous ne soyez tous les deux sur le même port d'OLT, marchera pas sans une reconfiguration de l'ONT (peut-être possible).