Peu de choses dans l'IPTV sont aussi agaçantes que de coller un identifiant et un mot de passe dont tu sais qu'ils sont corrects, et de voir le lecteur renvoyer « Authentication Failed ». Deux faits aggravent la situation :

  1. L'erreur est exactement la même chaîne de caractères pour au moins huit causes sous-jacentes différentes, dont plusieurs n'ont rien à voir avec tes identifiants.
  2. Les lecteurs ne te disent presque jamais laquelle.

Ce guide les passe en revue dans l'ordre où ça vaut le coup de les vérifier. Si tu peux coller les identifiants dans le vérificateur d'identifiants Xtream avant de commencer, les trois premières étapes tombent toutes seules — l'outil te dit si l'auth a réellement échoué, expiré, ou tapé une limite de connexions.

Un lecteur à gauche échange une demande d'identification et une réponse auth-failed avec un serveur Xtream à droite, pendant que huit pastilles en dessous défilent à travers les causes sous-jacentes — expiré, limite de connexions, espace caché, URL de serveur mal formée, certificat cassé, blocage IP, migration du fournisseur, identifiants faux.

Une chaîne d'erreur, huit causes sous-jacentes — le lecteur ne sait pas les distinguer, donc c'est à toi de diagnostiquer.

1. L'abonnement a dépassé la date d'expiration

C'est de loin la cause la plus fréquente, et elle ressemble exactement à un mot de passe faux dans la plupart des lecteurs. Xtream renvoie la même réponse auth: 0 dans les deux cas.

Le correctif, c'est de demander la nouvelle date d'expiration à ton fournisseur — ou, si tu as déjà renouvelé, d'attendre une heure et de réessayer. Certains panels de gestion mettent à jour leur base sur un planning, pas en temps réel, et un compte qu'on vient de renouveler peut encore apparaître comme expiré pendant une demi-heure après que le paiement est passé.

Le vérificateur d'identifiants renvoie auth: expired dans ce cas, donc tu élimines cette piste en un clic.

2. La limite de connexions est atteinte

La plupart des abonnements Xtream sont vendus avec un plafond de connexions — typiquement 1, 2, 3 ou 5 connexions simultanées. Si toutes sont utilisées, une nouvelle tentative de login est refusée avec la même erreur d'auth qu'un mot de passe faux.

Le piège : une connexion n'est pas toujours en train de streamer. Les lecteurs qui quittent sans se déconnecter proprement (la plupart) peuvent laisser une connexion « fantôme » que le fournisseur ne nettoie qu'après un timeout. Si tu viens de changer d'appareil, de redémarrer une TV, ou si ton Wi-Fi a coupé et s'est reconnecté, il est plausible que tous tes slots soient occupés par des fantômes qui ne streament rien.

Le correctif : attends 5 à 10 minutes que le timeout côté serveur expire, puis réessaie. Ou contacte ton fournisseur pour qu'il vide les connexions actives de ton compte.

3. L'identifiant contient un caractère blanc invisible

Coller des identifiants depuis un mail, un forum ou une capture d'écran ramène souvent des caractères invisibles : un espace en tête, un saut de ligne en fin, une espace insécable (U+00A0) là où l'utilisateur croit avoir tapé un espace normal. La plupart des lecteurs ne les trimment pas, et un identifiant avec un saut de ligne à la fin est un identifiant différent du point de vue du fournisseur.

Pour vérifier, colle l'identifiant et le mot de passe dans un éditeur de texte brut. Place le curseur tout au bout de chacun. Si tu peux faire un retour arrière et supprimer un caractère invisible avant que le curseur soit au bout du texte visible, c'est ça ton problème.

Le vérificateur d'identifiants trimme explicitement les espaces du serveur et de l'identifiant avant de les envoyer en amont, donc s'il réussit là où ton lecteur échoue, c'est presque sûrement ça la cause.

4. L'URL du serveur contient un chemin ou une query string en trop

Xtream Codes appelle un endpoint unique à /player_api.php. Ton lecteur construit l'URL complète en ajoutant ce chemin à ce que tu as mis dans le champ « serveur ». Si tu as collé l'URL M3U complète (http://serveur.example/get.php?username=…&password=…&type=m3u_plus) dans le champ serveur au lieu de juste http://serveur.example, le lecteur finit par appeler /get.php?username=…&password=…&type=m3u_plus/player_api.php?…, ce qui renverra 404 ou du HTML sur n'importe quel serveur. Le lecteur déclare alors « auth failed » parce qu'il n'a pas reçu de JSON.

Le correctif, c'est de réduire l'URL à http(s)://hôte:port. L'identifiant et le mot de passe vont dans leurs propres champs. Beaucoup de gens ont collé l'URL M3U dans le champ serveur au moins une fois.

5. Le serveur est en HTTPS mais la chaîne de certificat est cassée

Certains fournisseurs font tourner leur API Xtream sur un certificat auto-signé ou expiré. La plupart des lecteurs modernes refusent de parler HTTPS à un serveur avec un certif invalide, mais certains plus anciens basculent silencieusement en HTTP et échouent ensuite parce que le fournisseur a arrêté de servir HTTP au trimestre dernier.

Le diagnostic : ouvre l'URL du serveur dans un navigateur sur ordinateur. Si tu vois un avertissement de certificat, le lecteur tombe dessus aussi. Le correctif, c'est de basculer l'URL du serveur de https://… à http://…, avec la réserve évidente que ton mot de passe va désormais voyager en clair. Tanne le fournisseur pour qu'il renouvelle son certif ; c'est son problème, pas le tien.

6. Ton IP est bloquée

Les fournisseurs géo-bloquent régulièrement le trafic depuis des pays où ils n'ont pas d'accords, ou limitent le débit au niveau de l'IP quand un compte fait trop de connexions sur une courte fenêtre. Les deux ressemblent à la même chose pour le lecteur : une réponse auth-failed.

Pour vérifier, essaie les mêmes identifiants depuis un autre réseau — partage de connexion via téléphone, un autre Wi-Fi, ou un VPN vers un autre pays. Si les identifiants marchent ailleurs mais pas depuis ta connexion maison, c'est ton IP le problème.

Le vérificateur d'identifiants appelle l'API côté serveur depuis une IP fixe, donc un cas « le vérificateur dit oui, mon lecteur dit non » confirme que le souci est ton IP cliente, pas tes identifiants.

7. La base du fournisseur est en maintenance / migration

Les migrations périodiques côté fournisseur cassent les logins Xtream pendant des heures d'affilée. Symptômes : tous les comptes Xtream du même fournisseur renvoient auth-failed simultanément. Il n'y a aucun moyen de distinguer ça de tes propres identifiants révoqués, sauf attendre et réessayer, ou demander sur un forum où d'autres clients du même fournisseur l'auraient remarqué.

Si tu as une URL M3U en plus de tes identifiants Xtream (la plupart des fournisseurs en délivrent les deux), le M3U continue souvent de marcher pendant la migration parce qu'il passe par un autre chemin de code. Basculer sur l'URL M3U est un contournement rapide en attendant que l'API revienne.

8. Les identifiants sont vraiment faux

C'est le cas ennuyeux mais bien réel. Le fournisseur les a invalidés. Le fournisseur les a fait tourner après un incident de paiement. Tu utilises les identifiants du mois dernier et tu as reçu un nouveau jeu au renouvellement.

Comment savoir : connecte-toi à l'espace client de ton fournisseur (presque tous les fournisseurs Xtream en ont un) et recopie les identifiants affichés là dans le formulaire. S'ils marchent et que ceux que tu utilisais ne marchent pas, tu as ta réponse.

Comment le vérificateur d'identifiants s'inscrit là-dedans

Le vérificateur d'identifiants Xtream de ce site distingue automatiquement entre les cas 1, 2 et 8 (les plus courants) :

  • auth: ok + chiffres dans le panneau principal → les identifiants sont bons. Le problème, c'est ton lecteur ou ton réseau — essaie les cas 4 à 7.
  • auth: expired → cas 1. Renouvelle ou contacte ton fournisseur.
  • auth: failed → cas 8. Les identifiants sont réellement faux.
  • Avertissement de limite de connexions → cas 2. Attends ou demande au fournisseur de vider les connexions.
  • upstream_timeout / upstream_unreachable → cas 6 ou 7. Le serveur lui-même est inaccessible depuis une IP publique, donc ce n'est pas du tout un problème d'authentification.

Lancer le vérificateur une fois avant de debug ton lecteur fait économiser en moyenne une vingtaine de minutes de tâtonnements. Ça élimine aussi complètement la question « est-ce que le fournisseur est en rade » — si notre serveur arrive à parler au sien, le sien est debout.

Quoi faire une fois la cause connue

Pour des identifiants qui marchent vraiment (cas 1 à 7 où tu as identifié la solution), Klipa prend en charge à la fois l'identifiant Xtream et l'URL M3U côte à côte dans la même bibliothèque. Si l'API Xtream de ton fournisseur est instable mais que son export M3U est sain, ajoute les deux — l'un maintient la liste de chaînes en vie quand l'autre lâche. Va voir la comparaison Xtream vs M3U pour choisir quelle interface privilégier.

Si tu as fait le tour des huit cas et que les identifiants ne marchent vraiment nulle part — y compris dans le vérificateur, sur l'espace client, et depuis un autre réseau — le problème est côté fournisseur et tu n'as plus rien à debug de ton côté.