Tous ceux qui ont publié un bot Discord l'ont déjà vécu : un mardi tout à fait normal, puis soudain increased api errors partout et la moitié de vos commandes qui échouent. Google Trends a enregistré l'expression comme terme de recherche en « forte hausse » au milieu de l'année 2026 ; cela arrive assez souvent pour que les utilisateurs finaux la recherchent directement. Voici comment s'en sortir, et ce que l'API serveur de Noxyr doit à ces leçons.

A request gets a 429, waits out a countdown, then retries and succeeds with a 200. Server 429 200 3 2 1 Retry-After

Les trois principaux modes de défaillance de l'API Discord

  • Panne globale / panne partielle : visible sur discordstatus.com. Symptômes : n'importe quelle requête peut échouer, la passerelle peut se déconnecter, la latence explose partout.
  • 429 Too Many Requests : vous avez dépassé la limite d'un bucket. Discord renvoie un en-tête Retry-After qui indique exactement combien de temps attendre.
  • Session invalide sur la passerelle : votre session WebSocket n'est plus valide. Reconnectez-vous avec votre token de reprise ; si cela échoue, effectuez une nouvelle identification.

Concevoir pour l'échec, pas pour le beau temps

  • Respectez Retry-After. Ne relancez pas la requête avec votre propre minuteur. Attendez exactement le délai indiqué par Discord, puis réessayez une seule fois. Les bots qui martèlent les 429 finissent bannis.
  • Backoff exponentiel avec jitter. Sur les erreurs 5xx, attendez 1 s, 2 s, 4 s, 8 s, plus un petit décalage aléatoire pour qu'une flotte de redémarrages ne provoque pas une ruée.
  • Coupez les appels non critiques. Si votre bot publie un récapitulatif hebdomadaire et que l'API Discord est dégradée, sautez cette exécution au lieu d'aggraver la situation. Le récapitulatif peut attendre ; la panne, non.
  • Mettez en cache tout ce qui n'est pas temps réel. Noms de serveurs, listes de salons, identifiants de rôles : mettez-les en cache localement. Pendant une panne, les données en cache vous permettent de continuer à répondre.
  • Affichez l'état. Si les commandes de votre bot échouent parce que Discord est en panne, prévenez les utilisateurs. Un simple « Discord rencontre actuellement des problèmes » vaut mieux que des timeouts silencieux.

Comment l'API serveur de Noxyr applique ces leçons

L'API serveur de Noxyr n'est pas l'API Discord : elle lit sa propre base de données. Mais les mêmes principes s'appliquent et ont façonné sa conception :

  • Erreurs prévisibles : chaque échec est un JSON avec un code error stable. Pas de HTML, pas de formats variables.
  • En-têtes de limitation de débit : des en-têtes RateLimit-* standardisés pour que les clients ralentissent avant d'atteindre le 429.
  • Dégradation gracieuse : l'endpoint /api/v1/server se replie sur les données de guilde en cache lorsque la récupération Discord sous-jacente échoue.
  • Pas d'échecs en cascade : chaque endpoint échoue indépendamment. Si Discord est en panne, votre endpoint d'analyse des tickets ne casse pas, car il lit depuis Mongo et non depuis Discord.
  • Interrupteur d'arrêt immédiat : désactiver une clé ou un scope prend effet dès la requête suivante, sans redémarrage.

Marche à suivre quand Discord part en vrille

  • 1. Consultez d'abord discordstatus.com : est-ce seulement vous ?
  • 2. Examinez vos propres journaux d'erreurs : 429, 5xx, déconnexions de la passerelle.
  • 3. Si le problème vient de Discord : suspendez les écritures non critiques, respectez Retry-After, patientez.
  • 4. Si le problème vient de vous : vérifiez les déploiements récents, les invalidations de cache, les nouvelles fonctionnalités.
  • 5. Communiquez. Une note courte et honnête dans votre salon de support évite 100 signalements en double.

Pour aller plus loin sur la couche API : l'API serveur de Noxyr, API Discord vs API Noxyr, principes de conception d'API.