Is Whaller down?

Notre hébergeur a actuellement un problème d'interconnexion avec Orange, ce qui ralentit les accès à Whaller. Vous trouverez les détails ici : https://network.status-ovhcloud.com/incidents/jqxcrgr138b4

A fix has been implemented and we are monitoring the results.

This incident has been resolved.

# Indisponibilité des plateformes Whaller du 2 octobre 2026 ## Résumé Le 2 octobre 2026, entre 15h17 et 16h41 \(CEST\), une partie des utilisateurs n'a plus pu accéder aux plateformes Whaller. L'incident ne venait pas de l'infrastructure Whaller. Il était lié à un problème d'interconnexion réseau \(peering\) entre notre hébergeur, OVHcloud, et l'opérateur Orange. Les utilisateurs dont le trafic passait par ce lien ne pouvaient plus joindre nos services. Le service a été rétabli à 16h41 après une intervention de l'hébergeur et de l'opérateur. L'incident a été clôturé à 17h01. Aucune donnée n'a été perdue. ## Chronologie des événements Toutes les heures sont en CEST \(heure de Paris\). * **2 octobre 2026, 15h17** : des clients signalent des problèmes de connexion à Whaller. Les équipes techniques lancent l'analyse. * **15h17 – 15h33** : les équipes techniques analysent l'activité des serveurs et redémarrent, par précaution, un serveur frontal et le serveur du site public. Des messages publics sur les réseaux sociaux évoquent des problèmes de résolution DNS, ce qui oriente les recherches vers un problème réseau externe. * **15h33** : les équipes techniques contactent l'hébergeur et ouvrent un ticket de support. L'hébergeur confirme un problème de peering entre son réseau et celui d'Orange. Un incident est publié sur la page de statut. * **16h41** : l'hébergeur annonce la fin de l'incident. Le service est rétabli pour l'ensemble des utilisateurs. * **17h01** : après vérification du bon fonctionnement des plateformes, les équipes techniques clôturent l'incident. ## Difficultés rencontrées * **Symptômes trompeurs** : les premiers signalements ressemblaient à une panne de nos serveurs ou à un problème DNS. Il a fallu écarter ces pistes avant d'identifier la vraie cause. * **Impact partiel** : seuls les utilisateurs passant par le réseau concerné étaient touchés. Depuis d'autres réseaux, les plateformes restaient accessibles, ce qui a compliqué le diagnostic. * **Cause hors de notre périmètre** : le problème se situait entre deux opérateurs tiers. Les équipes techniques ne pouvaient pas le corriger directement et dépendaient de l'intervention de l'hébergeur et de l'opérateur. ## Cause de l'incident Sur la session de peering entre l'hébergeur et Orange, le nombre maximal de routes réseau \(préfixes\) autorisé a été atteint. Cette limite de protection a coupé la session d'échange de routes. Le trafic entre les deux réseaux, dont celui des utilisateurs Orange vers Whaller, n'était donc plus acheminé correctement. L'hébergeur a travaillé avec Orange pour relever cette limite et rétablir un fonctionnement normal. ## Perte de données Aucune perte de données. L'incident concernait uniquement l'accès réseau aux plateformes. Les serveurs, les bases de données et les contenus hébergés n'ont pas été touchés.

We are currently investigating this issue.

# Postmortem — Indisponibilité des résultats de recherche ## Résumé Le 17 août 2026, entre 15 h 36 et 17 h 15 CEST, un incident a affecté le service de recherche et certaines fonctionnalités d’analyse. Durant cette période, les requêtes adressées au moteur de recherche échouaient et les interfaces concernées ne retournaient aucun résultat. L’incident a été détecté à la suite de signalements du client. Les équipes techniques ont identifié une incompatibilité introduite lors de la mise à jour d’une dépendance logicielle, puis déployé une correction. Le service a été entièrement rétabli à 17 h 15 CEST. ## Chronologie des événements * **17 août 2026 à 15 h 36 CEST** : début de l’incident. Les requêtes adressées au moteur de recherche commencent à échouer. * **À partir de 15 h 36 CEST** : l’absence de résultats devient visible dans les interfaces concernées et fait l’objet de signalements du client. * **16 h 26 CEST** : les équipes techniques prennent en charge l’incident et lancent les investigations. * **17 h 08 CEST** : les équipes techniques déploient une première correction. * **17 h 13 CEST** : le déploiement est terminé et les tests confirment le rétablissement du fonctionnement attendu. * **17 h 15 CEST** : la correction est mise en production et l’incident est déclaré résolu. La durée totale de l’incident a été de **1 heure et 39 minutes**. ## Difficultés rencontrées L’incident résultait d’un effet indirect lié à l’évolution d’une dépendance partagée entre plusieurs composants logiciels. La modification n’affectait pas directement la logique métier du moteur de recherche. Elle concernait une option technique de connexion devenue incompatible avec le client HTTP désormais utilisé. Cette incompatibilité a rendu l’origine de l’incident moins immédiatement identifiable. Par ailleurs, l’incident a d’abord été détecté grâce aux signalements du client et à l’absence visible de résultats dans les interfaces. ## Cause de l’incident Une mise à jour de dépendances a entraîné l’utilisation d’un nouveau client HTTP par le composant chargé de communiquer avec le moteur de recherche. Les composants de recherche et d’analyse lui transmettaient encore une option de délai de connexion propre à l’ancien client HTTP. Cette option n’étant pas reconnue par le nouveau composant, les appels au moteur de recherche échouaient systématiquement. La correction a consisté à remplacer cette option par son équivalent compatible avec le nouveau client HTTP. Ce changement ne modifie pas le comportement fonctionnel du service : il maintient uniquement la limite prévue pour l’établissement de la connexion au moteur de recherche. ## Perte de données Aucune perte ni altération de données n’a été constatée. Pendant l’incident, les données sont restées enregistrées, mais les fonctionnalités affectées ne permettaient plus de les retrouver ou de les afficher correctement dans les résultats de recherche et d’analyse. ## Mesures de remédiation Les équipes techniques ont mis en œuvre les actions suivantes : * correction de l’option de connexion utilisée par les composants de recherche et d’analyse ; * déploiement et validation de la correction sur les différents composants concernés ; * vérification du rétablissement des résultats de recherche après la mise en production. --- # Post-mortem — Search results unavailable ## Summary On 17 August 2026, between 15:36 and 17:15 CEST, an incident affected the search service and certain analytics features. During this period, queries sent to the search engine failed and the affected interfaces returned no results. The incident was detected following reports from the client. The technical teams identified an incompatibility introduced during the update of a software dependency and subsequently deployed a fix. The service was fully restored at 17:15 CEST. ## Timeline of events * **17 August 2026 at 15:36 CEST**: start of the incident. Requests sent to the search engine began to fail. * **From 15:36 CEST**: the absence of results became apparent in the affected interfaces and was reported by customers. * **16:26 CEST**: the technical teams took charge of the incident and began investigations. * **17:08 CEST**: the technical teams deploy an initial fix. * **17:13 CEST**: the deployment is complete and tests confirm that the system is functioning as expected. * **17:15 CEST**: the fix is put into production and the incident is declared resolved. The total duration of the incident was **1 hour and 39 minutes**. ## Challenges encountered The incident resulted from an indirect effect linked to a change in a dependency shared between several software components. The change did not directly affect the search engine’s business logic. It concerned a technical connection option that had become incompatible with the HTTP client now in use. This incompatibility made the cause of the incident less immediately identifiable. Furthermore, the incident was first detected thanks to reports from users and the visible absence of results in the user interfaces. ## Cause of the incident An update to dependencies led to the component responsible for communicating with the search engine using a new HTTP client. The search and analysis components were still passing it a connection timeout option specific to the old HTTP client. As this option was not recognised by the new component, calls to the search engine consistently failed. The fix involved replacing this option with its equivalent, which is compatible with the new HTTP client. This change does not alter the functional behaviour of the service: it merely maintains the intended limit for establishing the connection to the search engine. ## Data loss No data loss or corruption was observed. During the incident, the data remained stored, but the affected functionalities were no longer able to retrieve it or display it correctly in the search and analysis results. ## Remedial measures The technical teams implemented the following actions: * correction of the connection option used by the search and analysis components; * deployment and validation of the correction across the various components concerned; * verification that search results had been restored following the production roll-out.