Atlas Pro ONTV fonctionne en Wi-Fi mais pas en 4G / 5G : causes et solutions

1. Clarification immédiate : pourquoi Wi-Fi fonctionne mais pas la 4G

Ce que vous observez est très typique :

• En Wi-Fi (box fibre/ADSL), Atlas Pro ONTV se lance et lit les chaînes.
• En 4G/5G (données mobiles), l’app charge indéfiniment, affiche une erreur générique, ou coupe immédiatement.

Sur le plan “logique”, cela paraît absurde : la 5G peut afficher 200–800 Mb/s sur un test de débit, donc “ça devrait marcher”.
En réalité, ce symptôme est extrêmement informatif : quand le Wi-Fi fonctionne et que la 4G/5G échoue, on est rarement sur un simple “bug de l’app”. On est plutôt sur une différence réseau entre :

• un accès fixe (votre FAI en Wi-Fi),
• et un accès mobile (votre opérateur en 4G/5G).

Et ces deux mondes ne se comportent pas pareil : NAT, IPv6, filtrage, DNS, politiques de trafic, timeouts, etc.
Autrement dit : le débit (throughput) n’est pas la connectivité réelle. Une connexion peut être “rapide” et pourtant incompatible avec un type de flux ou un type de session.

2. Différences fondamentales entre Wi-Fi et 4G / 5G

Accès fixe (Wi-Fi via box) vs accès mobile (4G/5G)

En Wi-Fi, votre trafic sort généralement via :

• une box (NAT domestique),
• un FAI fixe,
• une route plus stable,
• des politiques de filtrage plus “neutres” pour les usages résidentiels.

En 4G/5G, votre trafic passe par :

• le réseau cœur de l’opérateur mobile,
• des mécanismes d’économie d’IPv4 (partage d’adresse),
• parfois des proxies/optimisations,
• des règles spécifiques (anti-abus, anti-fraude, gestion de congestion).

NAT : la grande différence invisible

Sur mobile, vous êtes très souvent derrière un Carrier-Grade NAT (CGNAT) : plusieurs clients partagent la même IPv4 publique, et l’opérateur traduit les ports à grande échelle. Cela change :

• la persistance des ports,
• les délais d’expiration des sessions,
• et parfois la compatibilité avec certains flux UDP ou certaines connexions longues.

Référence CGNAT et espace d’adressage partagé :

• IETF RFC 6598 (Shared Address Space 100.64.0.0/10) https://www.rfc-editor.org/rfc/rfc6598

Référence comportement NAT (UDP) :

• IETF RFC 4787 (NAT Behavioral Requirements for UDP) https://www.rfc-editor.org/rfc/rfc4787

Partage d’IP et réputation d’IP

En 4G/5G, une IPv4 publique peut être partagée par des centaines d’utilisateurs. Conséquence possible : certaines destinations appliquent des règles de protection (limitation, filtrage, blocage d’IP “bruitées”). Ce n’est pas “la faute du serveur” par défaut, mais c’est un facteur réseau typique du mobile.

IPv6 mobile : parfois excellent, parfois incompatible

Beaucoup d’opérateurs mobiles poussent l’IPv6. Si une appli (ou le système) tente l’IPv6 en premier et que la destination répond mal (ou que le chemin IPv6 est dégradé), vous obtenez :

• échec de connexion,
• chargement infini,
• erreurs génériques.

Support Apple sur réseaux IPv6 (contexte technique) :

• Apple IPv6 support https://developer.apple.com/support/ipv6/

Politiques de trafic (filtrage, throttling, proxy)

Certains opérateurs peuvent :

• réduire la priorité de certains flux,
• filtrer des ports/protocoles,
• ou appliquer des optimisations (rarement visibles, mais réelles).

Ici, le point important : une 5G “rapide” peut échouer sur un flux IPTV si la connectivité utile (ports/protocoles/persistance) ne suit pas.

3. Comment Atlas Pro ONTV se connecte au réseau

Un chemin “normal” ressemble à ceci :

1. App (Atlas Pro ONTV)
2. DNS : résolution du nom en IP (IPv4 A / IPv6 AAAA)
3. Réseau : Wi-Fi ou données mobiles
4. NAT / routeur / CGNAT
5. Routage opérateur vers la destination
6. Serveur : handshake, authentification, flux vidéo

Où le mobile peut casser ou modifier le comportement :

• DNS : l’opérateur peut forcer ses DNS, ou l’IPv6 peut être privilégié.
• CGNAT : timeouts plus agressifs, traduction de ports instable pour certains flux.
• Filtrage : certains ports/protocoles ou patterns de trafic peuvent être bloqués.
• IPv6/IPv4 : l’app peut “tomber” sur la mauvaise pile IP.

Pourquoi l’app affiche des erreurs vagues :
Beaucoup d’apps IPTV encapsulent les échecs réseau en messages génériques (“impossible de se connecter”, “serveur introuvable”, “erreur réseau”), parce qu’elles ne distinguent pas finement :

• DNS failed vs
• timeout TCP vs
• UDP blocked vs
• IPv6 handshake issues.

Donc on doit prouver la couche en cause par des tests simples et ordonnés.

4. Causes principales (classées par probabilité)

Causes liées au réseau mobile

1) CGNAT + timeouts (observable indirectement)

Ce que ça provoque :

• connexion qui démarre puis coupe,
• flux qui se lance puis “bufferise” vite,
• ou échec selon la chaîne/flux.

Quand ça s’applique :

• surtout sur flux sensibles aux interruptions (sessions longues, UDP, keepalive faible).

Quand ça ne s’applique pas :

• si vous avez exactement le même problème en Wi-Fi (donc pas spécifique au mobile).

Pourquoi ça marche en Wi-Fi :

• NAT domestique souvent plus “stable” et moins agressif sur les timeouts.

Indicateur technique possible : IP privée mobile dans 100.64.0.0/10 (CGNAT), mais tous les téléphones ne l’exposent pas facilement. Référence : RFC 6598 https://www.rfc-editor.org/rfc/rfc6598

2) Filtrage opérateur (ports/protocoles) (souvent observable)

Symptôme typique :

• “Ne fonctionne jamais” en 4G/5G, mais instantané en Wi-Fi.

Quand ça s’applique :

• si l’opérateur bloque certains ports ou patterns.

Quand ça ne s’applique pas :

• si ça marche sur le même opérateur mais seulement sur un autre téléphone : alors c’est plutôt appareil/OS.

Pourquoi :

• politiques anti-abus, sécurité, filtrage, ou contraintes réseau.

3) DNS mobile / préférence IPv6 (très fréquent, observable)

Symptôme :

• chargement infini / “serveur introuvable” uniquement en 4G/5G.

Quand ça s’applique :

• si le DNS renvoie des enregistrements AAAA (IPv6) et que la route IPv6 est mauvaise, ou si la résolution est instable.

Quand ça ne s’applique pas :

• si le test VPN (qui change souvent la résolution et le chemin) ne change rien.

Pourquoi :

• sur mobile, la pile réseau et les DNS opérateurs sont différents, et la préférence IPv6 peut changer le chemin réel.

Référence “Happy Eyeballs” (logique IPv6/IPv4 côté client) :

• RFC 8305 https://www.rfc-editor.org/rfc/rfc8305

4) Mismatch IPv6 / IPv4 côté APN (observable)

Certains opérateurs proposent des APN en IPv4, IPv6 ou dual-stack.
Si l’app / la destination / le routage a un souci sur une pile IP, vous obtenez une panne uniquement en données mobiles.

Observation basée sur des diagnostics réseau mobiles courants (non documentée officiellement).

Causes liées à l’appareil

1) Données cellulaires désactivées pour l’app (très courant, observable)

Quand ça s’applique :

• iOS/Android permet de couper l’accès cellulaire app par app.

Quand ça ne s’applique pas :

• si l’app consomme bien du data sur d’autres actions en 4G (ex : chargement de listes).

Pourquoi :

• l’OS bloque simplement l’accès réseau cellulaire.

Référence Android (contrôle réseau / data saver / restrictions) :

• Android Developers – Data Saver https://developer.android.com/training/basics/network-ops/data-saver

2) Économies d’énergie / restrictions arrière-plan (observable)

Symptôme :

• ça démarre puis coupe quand vous changez d’app, ou écran verrouillé, ou après quelques secondes.

Quand ça s’applique :

• modes économie d’énergie agressifs, restrictions arrière-plan, optimisation batterie.

Quand ça ne s’applique pas :

• si l’échec se produit immédiatement, écran allumé, sans multitâche.

Pourquoi :

• l’OS limite les tâches réseau en arrière-plan.

Référence Android (Doze / App Standby) :

• https://developer.android.com/training/monitoring-device-state/doze-standby

Référence iOS (cellular access côté API) :

• URLSessionConfiguration allowsCellularAccess https://developer.apple.com/documentation/foundation/urlsessionconfiguration/1410529-allowscellularaccess

3) Pare-feu / bloqueur DNS / VPN “toujours actif” (observable)

Symptôme :

• fonctionne en Wi-Fi (car différent DNS/VPN), échoue en 4G (car règle différente), ou l’inverse.

Quand ça s’applique :

• AdGuard, NextDNS, Private DNS Android, profils VPN, “Always-on VPN”.

Quand ça ne s’applique pas :

• si aucune app réseau/sécurité installée et aucun profil VPN.

Pourquoi :

• la résolution DNS ou le routage est modifié par le téléphone.

Causes liées à l’application

Ici, on reste prudent : Wi-Fi OK + 4G KO pointe surtout réseau/OS. Mais il existe des cas applicatifs.

1) Timeouts trop courts sur mobile (partiellement observable)

Symptôme :

• échec en 4G si la latence initiale est plus élevée, alors que Wi-Fi répond plus vite.

Quand ça s’applique :

• si l’app a des timeouts agressifs.

Quand ça ne s’applique pas :

• si un VPN (qui ajoute de la latence) résout le problème : dans ce cas, c’est plutôt routage/filtrage que timeout.

2) Résolution DNS / cache interne (observable)

Symptôme :

• fonctionne après vidage cache, ou après redémarrage, mais pas durablement.

Quand ça s’applique :

• cache DNS interne, résolution intermittente.

Quand ça ne s’applique pas :

• si le problème est strictement lié à un opérateur, stable et reproductible.

5. Diagnostic rapide (10 minutes, sans rien casser)

L’objectif : prouver la couche (opérateur, DNS, IPv6, OS, app).

Test 1 — Cross-test Wi-Fi ↔ 4G (preuve “réseau mobile”)

1. Ouvrez Atlas Pro ONTV en Wi-Fi : notez si ça marche immédiatement.
2. Coupez le Wi-Fi, forcez la 4G/5G, relancez l’app.

Ce que ça prouve :

• si seul le cellulaire échoue, la variable dominante est le réseau mobile / OS cellulaire.

Test 2 — Hotspot reverse test (preuve “opérateur vs téléphone”)

Deux variantes :

A) Votre téléphone partage sa 4G vers une TV/box

• Si la TV fonctionne via hotspot : le problème n’est pas “la 4G en général”, il est plutôt dans le téléphone / l’app.

B) Un autre téléphone (autre opérateur) partage sa 4G vers votre téléphone

• Si Atlas Pro ONTV fonctionne via l’autre opérateur : c’est très probablement opérateur / routage / filtrage / IPv6.

Pourquoi l’ordre compte :
On évite de modifier des réglages tant qu’on n’a pas isolé le coupable.

Test 3 — DNS isolation test (preuve “résolution/IPv6”)

Sans “casser” la connectivité :

• Sur Android : activer DNS privé vers un résolveur fiable (ex : dns.google ou 1dot1dot1dot1.cloudflare-dns.com).
• Sur iOS : tester via un profil DNS (ou app de type 1.1.1.1 en mode DNS uniquement, si disponible).

Ce que ça prouve :

• si l’app passe de KO à OK, la variable est DNS / chemin IPv6/IPv4.

Référence Android DNS privé (Private DNS) :

• Android Developers (Private DNS) https://developer.android.com/privacy-and-security/dns-over-tls

Test 4 — VPN test (preuve “routage/filtrage”)

Test court (5 minutes) :

• Si VPN = OK et sans VPN = KO, cela indique un problème de routage opérateur, filtrage, ou destination sur le chemin standard.

Important : VPN ne “répare” pas le monde ; il change le chemin. C’est un test de diagnostic, pas une solution automatique.

6. Scénarios concrets + solutions ciblées

Scénario A — Marche instantanément en Wi-Fi, jamais en 4G

Symptôme :

• en cellulaire : écran de chargement infini / erreur réseau immédiate.

Cause probable :

• filtrage opérateur, DNS opérateur instable, ou préférence IPv6 problématique.

Comment confirmer :

• test avec SIM d’un autre opérateur (ou hotspot d’un autre téléphone).
• test VPN : si OK, routage/filtrage très plausible.

Fix correct :

• DNS isolation (Android DNS privé / profil DNS iOS).
  • S’applique si le DNS opérateur est la cause.
  • Ne s’applique pas si l’opérateur filtre au niveau transport/ports.
  • Pourquoi ça marche : on contourne la résolution et parfois certains chemins dégradés.
• VPN (diagnostic puis usage ciblé)
  • S’applique si VPN rend tout stable.
  • Ne s’applique pas si VPN ne change rien : alors c’est plus probablement OS/app ou restrictions data.
  • Pourquoi ça marche : nouveau chemin, nouveaux points de sortie, parfois IPv4-only.

Scénario B — Marche sur un opérateur, pas sur un autre

Symptôme :

• SIM A = OK, SIM B = KO.

Cause probable :

• routage/peering opérateur, IPv6 spécifique, filtrage.

Confirmation :

• reproduire au même endroit, même téléphone, uniquement en changeant de SIM.

Fix correct :

• Forcer un chemin alternatif via VPN (si et seulement si ça démontre un bénéfice).
  • S’applique si l’opérateur B a un chemin dégradé.
  • Ne s’applique pas si l’opérateur bloque activement certains flux (VPN peut marcher, mais ce sera un contournement permanent).
• Tester APN / pile IP (avancé)
  • S’applique si vous savez exactement ce que vous faites et que l’opérateur fournit des APN documentés.
  • Ne s’applique pas si vous modifiez des paramètres au hasard : risque de perdre MMS/data.
  • Pourquoi : certains APN imposent IPv6/IPv4 ou des proxies.

Les détails APN varient par opérateur : sans paramètres officiels, ne pas improviser.

Scénario C — Marche avec VPN, pas sans

Symptôme :

• sans VPN : KO; avec VPN : OK immédiat.

Cause probable :

• routage opérateur vers la destination, filtrage, ou problème IPv6/IPv4 sur le chemin standard.

Confirmation :

• tester 2 serveurs VPN différents (même pays vs autre pays).
  Si un seul serveur VPN marche, c’est plutôt “chemin” que “app”.

Fix correct :

• DNS + VPN (tester séparément)
  • S’applique si DNS seul ne suffit, VPN oui.
  • Ne s’applique pas si VPN est instable ou coupe : alors vous ajoutez un point de fragilité.
• Stabiliser IPv4 (si possible)
  • S’applique si le problème est un chemin IPv6 dégradé.
  • Ne s’applique pas sur iOS où le contrôle IPv6/IPv4 est limité.

Scénario D — Charge puis s’arrête après quelques secondes

Symptôme :

• la liste apparaît, puis le flux ne tient pas / coupe vite.

Cause probable :

• timeouts CGNAT, gestion d’énergie, restriction data en arrière-plan, ou player sensible.

Confirmation :

• garder l’écran allumé, désactiver économie d’énergie pour l’app, retester.
• hotspot reverse test : si via hotspot ça tient mieux, l’opérateur cellulaire direct est suspect.

Fix correct :

• Retirer les restrictions batterie (Android)
  • S’applique si les coupures corrèlent à écran verrouillé / multitâche.
  • Ne s’applique pas si l’échec est instantané.
  • Pourquoi : l’OS cesse d’alimenter la session réseau.
• Tester un lecteur différent dans l’app (si option)
  • S’applique si le player actuel gère mal les micro-coupures.
  • Ne s’applique pas si la connexion ne s’établit même pas.

7. Différences selon l’appareil (IMPORTANT)

Android smartphone

Points critiques :

• DNS privé (DoT) peut aider si DNS opérateur pose problème.
• Économie de batterie peut tuer les sessions.
• Apps de filtrage (pare-feu, adblock DNS) peuvent casser la résolution.

Actions utiles (diagnostic) :

• vérifier que l’app est autorisée en données mobiles et en données arrière-plan
  (Android varie selon surcouche).
• retirer optimisation batterie pour l’app si les coupures arrivent après quelques secondes.

Références Android :

• Data Saver https://developer.android.com/training/basics/network-ops/data-saver
• Doze https://developer.android.com/training/monitoring-device-state/doze-standby

iPhone (iOS)

Points critiques :

• accès cellulaire par app (Réglages > Données cellulaires).
• modes réduisant l’activité réseau (faible données / économie d’énergie) peuvent influencer la persistance.
• contrôle IPv6/IPv4 plus limité, donc le diagnostic via VPN/DNS est souvent plus “utile” que les réglages bas niveau.

Référence Apple (contrôle cellulaire via configuration réseau côté app) :

• allowsCellularAccess https://developer.apple.com/documentation/foundation/urlsessionconfiguration/1410529-allowscellularaccess

Android TV utilisant un hotspot mobile

Cas particulier : la TV/box dépend de :

• la 4G/5G du téléphone et du Wi-Fi hotspot (qualité du hotspot).
  Même si la 5G est excellente, le hotspot peut être instable (économie d’énergie du téléphone, portée, interférences).

Fix quand ça s’applique :

• laisser le téléphone en charge, écran allumé, économie d’énergie désactivée.
• rapprocher la TV/box du téléphone.
• tester un autre téléphone comme hotspot (preuve).

Quand ça ne s’applique pas :

• si Atlas Pro ONTV échoue sur le téléphone lui-même en 4G : ce n’est pas le hotspot, c’est l’accès mobile direct.

8. DNS, VPN et idées reçues

Quand changer de DNS aide

• KO en 4G/5G, OK en Wi-Fi.
• VPN n’est pas nécessairement requis.
• le symptôme ressemble à un échec de résolution/connexion initiale (chargement infini, erreurs “serveur introuvable”).

Pourquoi : vous remplacez la résolution opérateur (parfois liée à IPv6, redirections, latence DNS).

Quand le VPN aide

• KO sans VPN, OK avec VPN de manière reproductible.
• surtout si l’échec est net et stable sur un opérateur donné.

Pourquoi : le VPN change le chemin (routage/peering) et souvent le mode IP (IPv4/IPv6) utilisé.

Quand DNS + VPN sont inutiles

• si l’app n’a pas l’autorisation d’utiliser les données mobiles,
• si une restriction batterie coupe la session,
• si un pare-feu local bloque l’app.

Comment tester “sans risque”

• test DNS : facile à annuler (revenir en “Automatique”).
• test VPN : court, pour diagnostiquer. Si aucun gain clair, arrêter.

9. Erreurs à éviter absolument

Changer l’APN au hasard

• Pourquoi c’est une perte de temps : vous pouvez casser les données/MMS, et masquer la vraie cause.
• Quand c’est pertinent : uniquement si vous avez des paramètres officiels opérateur et un objectif précis (forcer IPv4/dual-stack).

Laisser un VPN en permanence sans diagnostic

• Pourquoi : vous ajoutez une dépendance (latence, coupures, batterie), et vous ne savez pas si le problème était DNS, routage ou appareil.
• Quand c’est acceptable : uniquement si vous avez prouvé que sans VPN c’est KO et avec VPN c’est stable, et que vous acceptez le compromis.

Réinstaller l’app en boucle

• Pourquoi : ça ne change ni CGNAT, ni IPv6, ni filtrage opérateur.
• Quand ça aide : seulement si vous suspectez un cache corrompu, et après avoir prouvé que le réseau cellulaire est OK (ex : via hotspot reverse test).

Accuser les serveurs sans preuve

• Pourquoi : Wi-Fi OK + 4G KO pointe d’abord réseau mobile/OS.
• Preuve minimale avant d’accuser : test autre opérateur + test VPN + test DNS.

10. FAQ technique concise (8–10 questions)

11. Synthèse opérationnelle

• Wi-Fi OK + 4G/5G KO indique d’abord réseau mobile / DNS / IPv6 / CGNAT / politiques opérateur, pas “un bug” par défaut.
• Faites 4 tests rapides : cross-test, hotspot reverse, DNS isolation, VPN diagnostic.
• Si autre opérateur = OK ou VPN = OK, le problème est chemin/routage/filtrage/IPv6 côté opérateur.
• Si hotspot reverse = OK mais téléphone direct = KO, cherchez restrictions OS, data app-par-app, économie d’énergie, DNS/pare-feu local.
• Évitez les changements aléatoires (APN, réinstallations répétées) : ils ne prouvent rien et masquent la cause.