my.whaller.com ainsi que les marques blanches associées sont inaccessibles | my.whaller.com and the associated white-label brands are inaccessible

Update timeline

1. investigating Jun 23, 2026, 12:25 PM UTC

   We are currently investigating this issue.

2. investigating Jun 23, 2026, 12:25 PM UTC

   We are continuing to investigate this issue.

3. resolved Jun 23, 2026, 08:44 PM UTC

   Nous avons identifié et corrigé le problème. La plateforme est de nouveau accessible. Nous produirons un post mortem dans les heures suivantes. We have identified and resolved the issue. The platform is now accessible again. We will be publishing a post-mortem in the next few hours.

4. postmortem Jun 23, 2026, 09:34 PM UTC

   # Post-mortem — Incident de production du 23 juin 2026 ## Résumé Le 23 juin 2026, un incident de production a rendu la plateforme principale ainsi que les accès associés indisponibles pour les utilisateurs. L’incident a été détecté à la suite d’alertes de supervision indiquant une indisponibilité des services. Les équipes techniques ont immédiatement engagé les premières actions de diagnostic et de redémarrage sur les composants applicatifs et d’infrastructure concernés. L’analyse a montré que le mécanisme de vérification de disponibilité du répartiteur de charge ne parvenait plus à valider correctement les frontaux applicatifs. Ceux-ci répondaient avec un code HTTP 403 aux requêtes de contrôle, ce qui les faisait considérer comme indisponibles, entraînant l’interruption du service. Le service a été rétabli après ajustement temporaire de la validation côté infrastructure, puis correction de la cause ayant entraîné ces réponses 403. ## Chronologie des événements Le 23 juin 2026 en début d’après-midi, les alertes de supervision ont signalé l’indisponibilité de la plateforme principale et des accès associés. Les équipes techniques ont procédé aux premières vérifications et redémarrages des composants applicatifs concernés, notamment les services web et certains serveurs frontaux. Un ticket prioritaire a été ouvert auprès de notre fournisseur d’infrastructure afin d’analyser le comportement du répartiteur de charge et des composants réseau associés. Les investigations ont ensuite porté sur l’état des pools HTTPS du répartiteur de charge, les composants d’infrastructure réseau, les serveurs frontaux et les journaux applicatifs. En fin de journée, une cellule de crise a été ouverte avec le fournisseur d’infrastructure afin d’accélérer l’analyse. Les vérifications croisées ont permis d’identifier que les requêtes de contrôle de disponibilité recevaient des réponses HTTP 403, ce qui empêchait le répartiteur de charge de considérer les frontaux comme disponibles. Une mesure temporaire a été appliquée sur la configuration du répartiteur de charge afin de rétablir le service. Après rétablissement, les équipes techniques ont poursuivi l’analyse et confirmé qu’une adresse interne utilisée pour les contrôles de disponibilité avait été bloquée. Le blocage a été levé, les réponses attendues sont redevenues conformes, puis la mesure temporaire a été supprimée. ## Difficultés rencontrées L’identification de la cause a été rendue difficile par le fait que plusieurs couches techniques pouvaient être en cause : serveurs applicatifs, configuration web, répartiteur de charge, composants réseau et infrastructure d’hébergement. Les premiers symptômes laissaient penser à un dysfonctionnement du répartiteur de charge ou de la couche réseau, car les frontaux étaient considérés comme indisponibles alors que certains services applicatifs continuaient à répondre localement. La corrélation entre le blocage d’une adresse interne et l’incident n’a été établie que tardivement, après recoupement des journaux applicatifs et des contrôles effectués pendant la cellule de crise. L’analyse a également nécessité l’intervention de plusieurs niveaux de support côté fournisseur d’infrastructure, ce qui a rallongé le temps de diagnostic. ## Cause de l’incident La cause de l’incident est le blocage d’une adresse interne utilisée par le mécanisme de contrôle de disponibilité du répartiteur de charge. À la suite de ce blocage, les requêtes de contrôle adressées aux serveurs frontaux recevaient des réponses HTTP 403 au lieu des réponses attendues. Le répartiteur de charge a alors considéré les frontaux comme indisponibles et n’a plus correctement distribué le trafic vers les services applicatifs. Cette situation a entraîné l’indisponibilité de la plateforme pour les utilisateurs. ## Perte de données Aucune perte de données n’a été constatée. L’incident a concerné l’accessibilité au service, mais n’a pas affecté l’intégrité des données stockées. ## Mesures de remédiation Les équipes techniques ont levé le blocage de l’adresse interne utilisée par les contrôles de disponibilité. Les équipes techniques ont vérifié le retour à un comportement nominal des serveurs frontaux et du répartiteur de charge. Les équipes techniques ont supprimé la mesure temporaire appliquée pendant l’incident une fois la cause corrigée. Les équipes techniques vont renforcer la supervision des contrôles de disponibilité afin de détecter plus rapidement les cas où un composant est considéré indisponible à cause d’un rejet applicatif ou réseau. Les équipes techniques vont revoir les règles de filtrage internes afin de mieux identifier les adresses techniques nécessaires au bon fonctionnement de l’infrastructure. Les équipes techniques vont documenter plus précisément les dépendances entre les contrôles de disponibilité, les serveurs frontaux et les règles de sécurité internes, afin de réduire le temps de diagnostic en cas d’incident similaire. Les équipes techniques vont améliorer les procédures d’escalade et de diagnostic avec le fournisseur d’infrastructure afin d’accélérer l’analyse lorsque plusieurs couches techniques sont susceptibles d’être impliquées.