En environnement contrôlé (donc dans une entreprise), le NAT66 n'est pas le mal, il suffit pour les fabricants de matériel (GL.INET le faisant déjà) de généraliser une config de ce type, et le souci du failover est de fait réglé.

Bref, de l'IPv4-like avec des numéros en 128 bits. En effet c'est ce qui marchera...
C'est au demeurant ce que j'avais conclu il y a une quinzaine d'années pour ce type d'environnement (ou plus exactement, pour accès Internet via wifi en hébergement collectif  ).

Mais finalement, où est le besoin, où sont les demandeurs, où sont les clients désireux de payer ça (tant en terme financiers qu'en matière de pots cassés)?
Aussi bien il y a 20 ans qu'à l'heure actuelle: nulle part (ou disons, une poignée de micro-clients, mais ça ne fait pas un marché).
Bref, le marché décidera sans nul doute du moment où il faudra y aller (et non pas une autorité tierce quelconque).

Si toutefois il n'y a pas cinq ou six nouvelles RFC et modes d'adressages publiés entre-temps, comme d'habitude en IPv6 
Puisqu'une spécificité majeure d'IPv6 est de vouloir tout normer en changeant tout sans expérience de la production, puis ensuite seulement de proposer des solutions réalistes en rapport avec la réalité, moyennant 15 normes différentes qui se succèdent 

Adresser le LAN en ULA et faire du NPTv6 sur les préfixes des multiples liens WAN est quand même déjà une très bonne solution.

NAT66 / NPTv6, ce sont en effet les seules solutions raisonnablement utilisables dans ce contexte spécifique en gardant quelque chose de «simple».

Mais qu'est-ce que ça apporte exactement en regard des investissements même limités en conseil, ingénierie, matériels, tests, supervisions, mises à jour, emmerdements, pour les entreprises ?
Rien pour le moment.

Ce sont typiquement les réponses que l'on va lire sur les forums et r/ipv6...
sauf que dans les faits et dans le monde réel, on ne peut pas toujours implementer ipv6 "comme sur le papier" et que nat66 fait parfaitement le boulot, surtout en multi-wan (c'est pourquoi on le discute ici).

C'est tout à fait ça. Cf ma réflexion sur les pilotes de beigebox situés sous la table de la cuisine.

Après, il y a les soucis des sysadmins... mais d'expérience, si tu prends une personne jeune et motivée par le réseau, tu n'as pas de souci à la former à IPv6. Par contre, les jeunes tout juste sortis de l'école te disent toujours "IPvQUOI? On a juste eu une slide dessus, c'est pour le futur" en 2026, tristesse.

• pour l'entreprise standard, tout ça est souvent vu comme un centre de coût, donc pourquoi investir et recruter en plus, tout ça pour que rien de change en pratique pour le résutlat obtenu
• Quant aux jeunes sortis de l'école: de façon générale j'ai l'impression qu'il y a assez peu de gens formés/intéressés par l'infrastructure et les réseaux. Ça rêve au dev, au front, au cloud, à l'IA (et pourtant, dev & co, voilà des sujets plus touchés que d'autres par un remplacement par l'IA)

Mais qu'est-ce que ça apporte exactement en regard des investissements même limités en conseil, ingénierie, matériels, tests, supervisions, mises à jour, emmerdements, pour les entreprises ?

Dans notre cas, je peux te donner quelques exemples concrets :
- à travers les réseaux mobiles qu'on utilise (Bouygues, pour ne citer qu'eux, mais j'ai aussi le souci chez Orange dans une moindre mesure), nos tunnels Wireguard entre les contrôleurs industriels et l'infra cloud "meurent" après ~2-5 jours lorsqu'ils sont transportés en IPv4. Les paquets passent dans un sens mais plus dans l'autre, donc potentiellement un problème de NAT ou de stateful firewall, va savoir.
En transportant ces tunnels sur IPv6, aucun souci, plus de timeouts, le flux de télémétrie remonte comme une horloge.

- à l'intérieur de ce VPN, on adresse les contrôleurs distants en single-stack IPv6. Ajouter un contrôleur au système se fait en trois clics sur une interface Web. Un /120 est pris dans un /96 dédié au VPN et les firewalls cloud sont mis à jour. Pas de chasse au subnet libre, pas de renumbering, pas de risque d'overlap d'adressage avec les LAN industriels des clients sur lesquels ces contrôleurs sont déployés, etc.
Note que les réseaux industriels restent IPv4-only. Je ne vois pas cela changer dans les 10 prochaines années et ce n'est pas vraiment un problème vu qu'ils sont isolés d'internet et tout petits.

- l'infra cloud est elle aussi IPv6-only avec un NAT64/DNS64 à l'edge pour accepter les connexions entrantes par IPv4 et permettre le traffic IPv4 sortant.
La simplicité de raisonnement, configuration des firewalls et des systèmes, etc. est un vrai plus selon moi. On gagne probablement en temps et en sécurité, mais c'est difficile à évaluer.

- une fois que l'infra de prod est v6-only, provisionner les VLANs du bureau de la même facon est trivial. Si tu leur explique les avantages et que tu les guide pendant quelques semaines, ils s'en sortent très bien.
Seuls les devs voient une différence, les fonctions support ne sauraient pas dire si leur PC est sur un LAN/SSID v6, v4 ou dual stack.

Je te rejoins sur le fait que les dev Web/backend Web/DB ne sont pas intéressés par le réseau. C'est ok, je leur fournis des enregistrements DNS, ils ne voient les adresses IPv6 que dans des logs. Parfois il faut expliquer que les requêtes de leur PC viennent de 2a01:xxxx:... plutôt que de 192.168.x.x, donc qu'ils faut qu'ils adaptent leur requête pour filtrer les logs. Dans mon expérience, ils s'en accommodent bien. En fait, ils s'en foutent (ca ne les intéresse pas, comme tu le dis) et les stacks qu'ils utilisent rendent le réseau abstrait.
J'ai bien plus de mal à leur faire comprendre que si l'interface d'admin du contrôleur consomme 2GB de RAM, c'est un problème pour pas mal de clients, par exemple.

Alors oui, pour une entreprise qui a une base installée énorme, la migration est plus complexe. Mais il faut de toute façon faire évoluer le réseau, remplacer les vieux switches 48 ports 100Mbit/s Alcatel qui font un bruit de moteur d'avion, reconfigurer les VPN opérateurs car les achats ont décidé de quitter Orange, changer les points d'accès Wifi car on passe d'Aruba à la marque du jour, etc. Est-ce que dans ce cas, configurer IPv6 en plus d'IPv4 lors de ces opérations est si coûteux ?
Je ne sais pas dire, je n'ai pas d'expérience dans ce type de structure.

Toute cette usine à gaz alors qu'un wireguard v4 aurait suffit

C'est quoi que tu comprends pas dans cette phrase ?
« Wireguard entre les contrôleurs industriels et l'infra cloud "meurent" après ~2-5 jours lorsqu'ils sont transportés en IPv4. »