Historique des pannes de Memsource

1. 1 septembre 2026 à 14:18 UTCinvestigating

   Nous enquêtons actuellement sur une question qui cause une lenteur dans la perspective des emplois au sein de Phrase TMS (UE). Les utilisateurs peuvent connaître des temps de chargement retardés ou des performances réduites lors de l'accès aux fonctionnalités de gestion de projet. Notre équipe s'emploie activement à identifier la cause profonde et à rétablir des performances normales le plus rapidement possible.

2. 1 septembre 2026 à 15:00 UTCinvestigating

   Nous avons identifié la cause profonde du problème. Notre équipe met en œuvre activement une solution. Nous fournirons d'autres mises à jour à mesure que nous progresserons.

3. 1 septembre 2026 à 15:34 UTCmonitoring

   Un correctif a été déployé et nous suivons les résultats. Les clients pourraient avoir besoin d'effacer le cache du navigateur et fermer tous les onglets ouverts avec TMS si toujours rencontrer des problèmes.

4. 1 septembre 2026 à 16:23 UTCresolved

   Le problème a été résolu et le rendement est stable.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 31 août 2026 à 15:06 UTCinvestigating

   Nous rencontrons actuellement des erreurs intermittentes lors de la communication avec Gengo, l'un de nos fournisseurs de traduction tiers. Cela entraîne des délais et 502 erreurs sur le calcul des prix et la soumission des commandes de traduction acheminées par Gengo, affectant à la fois les centres de données de l'UE et des États-Unis. Gengo a confirmé la question à leur fin et enquête.

2. 2 septembre 2026 à 11:46 UTCresolved

   Gengo a résolu la question sous-jacente à leur fin. Les calculs de prix et les soumissions de commande de traduction à Gengo fonctionnent maintenant à nouveau.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 31 août 2026 à 13:11 UTCinvestigating

   Les utilisateurs sont actuellement incapables d'ouvrir des emplois existants et d'en créer de nouveaux dans le cadre de leurs projets Phrase TMS. Nous enquêtons sur la question.

2. 31 août 2026 à 13:22 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 31 août 2026 à 13:46 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

4. 31 août 2026 à 16:02 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

5. 31 août 2026 à 16:53 UTCresolved

   La question a été réglée.

6. 4 septembre 2026 à 08:45 UTCpostmortem

   Présentation Nous aimerions partager des détails sur un incident qui a touché Phrase TMS le 31 août 2026. Entre 2:26 et 17:57 PM CEST, certains utilisateurs de la page précédente du Projet n'ont pas pu utiliser les actions Tools-menu comme créer ou modifier des tâches et exécuter des analyses, et cliquer pour ouvrir une tâche n'a pas lancé l'éditeur Web CAT comme prévu, au lieu de renvoyer les utilisateurs à la page du projet. Ce post mortem explique ce qui s'est passé, comment il a été résolu et ce que nous faisons pour l'empêcher de se reproduire. Calendrier * **31 août 2026 à 14h26 CEST** – Un changement de code a atteint la production contenant un défaut qui a cassé l'exécution du script sur la page du Projet pour tout utilisateur qui l'a chargé. * **31 août 2026 à 14h49 CEST** – Les premiers rapports clients ont décrit les boutons Tools-menu comme étant désactivés et les emplois qui ne s'ouvrent pas dans l'éditeur. * **Le 31 août 2026 vers 15h10 CEST** – Notre équipe a identifié la cause profonde du problème. * **Le 31 août 2026 à 15h48 CEST** – Une correction du défaut sous-jacent a été effectuée. * **31 août 2026 à 16h04 CEST** – La correction a été vérifiée dans un environnement de préproduction. * **Le 31 août 2026 à 17h18 CEST** – Le déploiement de la fixation à la production a commencé. * **31 août 2026 à 17h57 CEST** – Le fix était entièrement en production et la fonctionnalité normale a été rétablie pour tous les clients touchés. La cause profonde L'incident a été causé par un changement de code visant à corriger un problème d'affichage mineur non lié sur les pages de projet partagées. Ce changement a modifié la façon dont une valeur a été insérée dans un script incorporé directement dans la page. Le système qui rend la page encode automatiquement les valeurs pour la sécurité, mais que l'encodage ne fait pas la distinction entre une valeur placée dans le contenu régulier de la page par rapport à l'intérieur d'un script. En conséquence, la syntaxe du script intégré a été brisée silencieusement une fois le changement atteint la production. Parce que les navigateurs arrêtent l'exécution de tout code supplémentaire sur une page une fois qu'ils rencontrent une syntaxe de script invalide, chaque script placé après ce point sur la page a cessé d'exécuter — pas seulement la partie liée à la modification originale. C'est pourquoi les clients ont connu ce qui ressemblait à deux problèmes séparés \(boutons de menu désactivés et des tâches ne s'ouvrant pas dans l'éditeur\) qui étaient, en fait, des effets en aval du même défaut unique. La question n'a pas été prise avant la publication parce que la vérification effectuée à l'époque a confirmé que les données sous-jacentes étaient correctes, mais n'a pas chargé la page réelle dans un navigateur pour la confirmer rendue et exécutée correctement de bout en bout. Actions pour prévenir la récidive 1. **Fix déployé** – Le défaut sous-jacent a été corrigé et déployé à la production le jour même où il a été identifié. 2. **Directives d ' ingénierie actualisées** Nous avons mis à jour notre documentation d'ingénierie interne pour décrire clairement ce modèle de défaillance spécifique et la façon correcte et sûre de le gérer, de sorte que cette catégorie d'erreur est prise lors de l'examen du code. 3. ** Améliorations de détection automatisées en cours** – Nous travaillons sur l'ajout d'une surveillance automatisée pour cette classe de défaillances frontales, de sorte que des problèmes similaires peuvent être détectés et traités avant que les clients soient touchés, plutôt que de compter sur les rapports des clients.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 19 août 2026 à 12:16 UTCinvestigating

   Nous enquêtons actuellement sur un problème touchant la fonctionnalité de la mémoire de traduction dans Phrase TMS (EU). Les utilisateurs peuvent éprouver des problèmes avec la création de mémoires de traduction et d'autres opérations connexes pendant cette période. Notre équipe s'emploie activement à identifier la cause et à restaurer la pleine fonctionnalité le plus rapidement possible.

2. 19 août 2026 à 12:34 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 19 août 2026 à 13:19 UTCmonitoring

   Un correctif a été mis en place et nous suivons la situation.

4. 19 août 2026 à 14:09 UTCresolved

   L'incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 7 août 2026 à 07:27 UTCinvestigating

   We are currently investigating an issue with branching events missing in Phrase Strings (EU), which may cause changes to not be applied when branches are merged.

2. 7 août 2026 à 07:54 UTCinvestigating

   We are continuing to investigate this issue.

3. 7 août 2026 à 08:18 UTCidentified

   The issue has been identified and a fix is being implemented.

4. 7 août 2026 à 08:30 UTCmonitoring

   A fix has been implemented. The backlog of missing events is now being processed. Once the queue is fully processed, unmerged branches will automatically receive the missing changes. We are monitoring the queue and results.

5. 7 août 2026 à 14:12 UTCresolved

   Changes made to branches during the incident window are now fully applied. Merged branches that were affected have been identified and impacted customers have been contacted directly. This incident has been resolved.

1. 6 août 2026 à 08:11 UTCinvestigating

   Nous enquêtons actuellement sur un problème touchant les connecteurs dans Phrase TMS. Les clients peuvent être incapables d'accéder ou d'utiliser la fonctionnalité Connector pendant cette période. Notre équipe d'ingénieurs s'emploie activement à identifier la cause et à rétablir le service complet le plus rapidement possible.

2. 6 août 2026 à 08:18 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 6 août 2026 à 08:43 UTCmonitoring

   We have identified the root cause and the issue has now been resolved. Connectors should be appearing as active again. We will continue to monitor the situation to ensure full stability.

4. 6 août 2026 à 12:00 UTCmonitoring

   We continue monitoring the situation.

5. 6 août 2026 à 13:19 UTCresolved

   The incident has been resolved and all components are back to operational.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 28 juillet 2026 à 07:19 UTCinvestigating

   L'équipe d'ingénierie a identifié un problème avec Orchestrator où le nouveau Workflow Engine n'exécute actuellement pas de workflows. Le problème est en cours d'enquête.

2. 28 juillet 2026 à 07:53 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 28 juillet 2026 à 08:30 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

4. 28 juillet 2026 à 08:35 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats. Le moteur de flux de travail traite la file d'attente des exécutions en attente.

5. 28 juillet 2026 à 11:49 UTCresolved

   Toutes les exécutions ont été traitées. Cet incident a été résolu.

6. 30 juillet 2026 à 07:09 UTCpostmortem

   Présentation Nous aimerions partager des détails sur un incident qui a touché Phrase Orchestrator les 27 et 28 juillet 2026. Au cours de cette période, les exécutions de workflow dans le Next-Gen Workflow Engine n'ont pas pu progresser et sont restées coincées dans un état « d'exécution ». Aucune donnée n'a été perdue pendant l'incident. Ce post-mortem explique ce qui s'est passé, quand il a été résolu, et les mesures que nous avons prises pour empêcher une récurrence. Calendrier * **27 juillet 2026 à 18 h 55 CEST** – Le moteur de flux de travail a commencé à produire des erreurs lorsque la performance de la requête de base de données s'est dégradée. Les exécutions de flux de travail ont bloqué et cessé de progresser. * **27 juillet 2026 à 20:54 CEST** – Le premier rapport de client sur les exécutions coincées dans "exécution" a été reçu. * **27 juillet 2026 à 22:39 CEST** – L'incident a été officiellement déclaré. * **28 juillet 2026 à 02:18 CEST** – Un redémarrage du service a fourni un soulagement temporaire; les exécutions de workflow ont repris. * **28 juillet 2026 à 05 h 15 CEST** – La question a repris à mesure que le problème sous-jacent de performance de la base de données persistait. * **28 juillet 2026 à 09:56 CEST** – La cause profonde a été identifiée et traitée. Aucune exécution n'a été perdue; toutefois, en raison de la reprise partielle du service, certains actes au sein de l'exécution ont été relancés, ce qui a peut-être causé l'échec d'un petit nombre d'exécutions qui auraient autrement réussi. * **28 juillet 2026 à 13:46 CEST** – L ' arriéré total d ' exécutions bloquées a été confirmé comme étant réglé. Le système a été déclaré stable. * **28 juillet 2026 à 13 h 48 CEST** – L'incident est réglé. La cause profonde L'incident a été causé par le gonflement progressif des index des bases de données utilisés par le système de planification des tâches. La performance de ces indices particuliers s'est progressivement dégradée au fil du temps en accumulant les entrées d'indices morts provenant d'écritures et de mises à jour antérieures. Le moteur de planification des tâches acquiert des verrous de coordination au niveau de la base de données tout en interrogeant ces index pour déterminer les tâches à envoyer. À mesure que la recherche d'index augmentait plus lentement, ils ont commencé à dépasser le délai d'attente de la déclaration configurée de la base de données. Lorsqu'une recherche a été annulée par le timeout, le processus de planification responsable de ce travail s'est écrasé et a redémarré. En l'absence de planificateurs, aucune étape du workflow n'a pu être envoyée et toutes les exécutions en cours sont devenues bloquées. Le serveur de base de données lui-même est resté sain tout au long de l'incident, avec un processeur normal et des niveaux de connexion. Le problème était exclusivement la dispute de verrouillage et de latence dans la couche de programmation. Un redémarrage du service a permis d'effacer les processus écrasés et de rétablir temporairement l'exécution. Cependant, comme l'index bloat était toujours présent, la même dégradation a repris une fois la charge de requête reprise. Un index manuel reconstitue complètement les performances et résout le problème. Actions pour prévenir la récidive 1. ** Maintenance de l'index automatique ajoutée** – La maintenance de l'index automatique programmée a été configurée pour les index concernés. Cela garantit que le ballonnement ne peut pas s'accumuler au fil du temps et élimine les conditions qui ont déclenché cet incident. 2. **Les index des bases de données inutilisés ont été identifiés et supprimés, ce qui a réduit la surface d'entretien globale et simplifié l'hygiène future des index. 3. ** Mise à jour du suivi** – Notre paysage de surveillance est en cours d'examen et de mise à jour pour refléter l'état actuel du moteur de travail. Ce travail permettra de combler les lacunes qui ont permis à la dégradation de passer inaperçue avant le premier rapport client.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 27 juillet 2026 à 23:48 UTCinvestigating

   L'ingénierie a identifié un problème avec Orchestrator où le nouveau Workflow Engine n'exécute pas actuellement de workflows. Le problème est en cours d'enquête.

2. 28 juillet 2026 à 00:41 UTCresolved

   Tous les workflows sont exécutés à nouveau comme prévu.

3. 30 juillet 2026 à 07:08 UTCpostmortem

   Présentation Nous aimerions partager des détails sur un incident qui a touché Phrase Orchestrator les 27 et 28 juillet 2026. Au cours de cette période, les exécutions de workflow dans le Next-Gen Workflow Engine n'ont pas pu progresser et sont restées coincées dans un état « d'exécution ». Aucune donnée n'a été perdue pendant l'incident. Ce post-mortem explique ce qui s'est passé, quand il a été résolu, et les mesures que nous avons prises pour empêcher une récurrence. Calendrier * **27 juillet 2026 à 18 h 55 CEST** – Le moteur de flux de travail a commencé à produire des erreurs lorsque la performance de la requête de base de données s'est dégradée. Les exécutions de flux de travail ont bloqué et cessé de progresser. * **27 juillet 2026 à 20:54 CEST** – Le premier rapport de client sur les exécutions coincées dans "exécution" a été reçu. * **27 juillet 2026 à 22:39 CEST** – L'incident a été officiellement déclaré. * **28 juillet 2026 à 02:18 CEST** – Un redémarrage du service a fourni un soulagement temporaire; les exécutions de workflow ont repris. * **28 juillet 2026 à 05 h 15 CEST** – La question a repris à mesure que le problème sous-jacent de performance de la base de données persistait. * **28 juillet 2026 à 09:56 CEST** – La cause profonde a été identifiée et traitée. Aucune exécution n'a été perdue; toutefois, en raison de la reprise partielle du service, certains actes au sein de l'exécution ont été relancés, ce qui a peut-être causé l'échec d'un petit nombre d'exécutions qui auraient autrement réussi. * **28 juillet 2026 à 13:46 CEST** – L ' arriéré total d ' exécutions bloquées a été confirmé comme étant réglé. Le système a été déclaré stable. * **28 juillet 2026 à 13 h 48 CEST** – L'incident est réglé. La cause profonde L'incident a été causé par le gonflement progressif des index des bases de données utilisés par le système de planification des tâches. La performance de ces indices particuliers s'est progressivement dégradée au fil du temps en accumulant les entrées d'indices morts provenant d'écritures et de mises à jour antérieures. Le moteur de planification des tâches acquiert des verrous de coordination au niveau de la base de données tout en interrogeant ces index pour déterminer les tâches à envoyer. À mesure que la recherche d'index augmentait plus lentement, ils ont commencé à dépasser le délai d'attente de la déclaration configurée de la base de données. Lorsqu'une recherche a été annulée par le timeout, le processus de planification responsable de ce travail s'est écrasé et a redémarré. En l'absence de planificateurs, aucune étape du workflow n'a pu être envoyée et toutes les exécutions en cours sont devenues bloquées. Le serveur de base de données lui-même est resté sain tout au long de l'incident, avec un processeur normal et des niveaux de connexion. Le problème était exclusivement la dispute de verrouillage et de latence dans la couche de programmation. Un redémarrage du service a permis d'effacer les processus écrasés et de rétablir temporairement l'exécution. Cependant, comme l'index bloat était toujours présent, la même dégradation a repris une fois la charge de requête reprise. Un index manuel reconstitue complètement les performances et résout le problème. Actions pour prévenir la récidive 1. ** Maintenance de l'index automatique ajoutée** – La maintenance de l'index automatique programmée a été configurée pour les index concernés. Cela garantit que le ballonnement ne peut pas s'accumuler au fil du temps et élimine les conditions qui ont déclenché cet incident. 2. **Les index des bases de données inutilisés ont été identifiés et supprimés, ce qui a réduit la surface d'entretien globale et simplifié l'hygiène future des index. 3. ** Mise à jour du suivi** – Notre paysage de surveillance est en cours d'examen et de mise à jour pour refléter l'état actuel du moteur de travail. Ce travail permettra de combler les lacunes qui ont permis à la dégradation de passer inaperçue avant le premier rapport client.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 20 juillet 2026 à 12:53 UTCresolved

   Entre le 16 juin, 2026 01:00PM CEST et le 17 juin, 2026 11:00AM CEST, le connecteur Phrase Job Sync a subi des performances dégradées. Les clients utilisant le Job Sync avec le type de connexion par défaut ont subi des défaillances. L'équipe d'ingénierie a identifié une cause profonde et a fourni une solution.

2. 20 juillet 2026 à 12:54 UTCpostmortem

   Introduction Nous aimerions partager plus de détails sur les événements qui se sont produits avec Phrase entre le 16 juin, 2026, 01:00PM CEST et le 17 juin, 2026, 11:00AM CEST, qui ont conduit à la dégradation des performances de Phrase Strings API, provoquant des clients utilisant le Job Sync avec le type de connexion par défaut pour éprouver des défaillances. Nous nous excusons de cette perturbation et nous nous engageons à prévenir des incidents semblables à l'avenir. Calendrier **Jun 16, 2026 @ 13:00 CEST** – Job Sync a commencé à échouer pour les clients en utilisant le type de connexion par défaut. Les connecteurs n'ont pas pu s'authentifier contre l'API des cordes Phrase. **Jun 17, 2026 @ 10h00 CEST** – L'équipe d'ingénierie a identifié l'échec de l'authentification. **Jun 17, 2026 @ 10:28 CEST** – La portée de l'impact a été confirmée : les clients utilisant la connexion Job Sync par défaut ont été affectés. Les clients utilisant des connecteurs à jeton d'accès personnel n'ont pas été touchés. **Jun 17, 2026 @ 10:29 CEST** – La cause racine a été identifiée: Un changement récent qui a ajouté le support de jetons multi-plateforme introduit par inadvertance des erreurs avec certains jetons de plate-forme existants. **Jun 17, 2026 @ 10:40 CEST** – Une correction a été préparée et soumise pour examen. **Jun 17, 2026 @ 10:53 CEST** – La correction a été déployée et la fonctionnalité JobSync a été entièrement restaurée. Cause profonde Un changement de code introduit pour ajouter une prise en charge des jetons d'authentification multi-plateforme a modifié comment les jetons de plate-forme entrants sont validés et traités dans l'API Phrase Strings. Ce changement n'était pas compatible avec un format de jeton existant utilisé par le type de connexion par défaut. En conséquence, les jetons de plate-forme ont été rejetés par l'API Strings avec une réponse `401 non autorisée`. Le connecteur a réévalué l'installation de la connexion jusqu'à épuiser son budget de réessayer, ce qui a causé l'échec de toutes les opérations concernées. Les clients utilisant des jetons d'accès personnels n'ont pas été affectés car leurs jetons suivent un chemin de code différent. Actions visant à prévenir la récidive La cause principale était un changement incompatible par rapport à la manipulation des jetons qui n'a pas été détecté pendant le développement. Les mesures suivantes sont prises : * **Test de compatibilité au format symbolique dans les modifications d'auth :** Lors de l'introduction d'un nouveau format de jeton/authentification à côté d'un format existant, les tests doivent explicitement couvrir le cas de transition — les jetons anciens étant traités sous la nouvelle logique de détection — et pas seulement chaque format isolé.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 16 juillet 2026 à 15:47 UTCinvestigating

   Nous enquêtons actuellement sur un problème touchant notre service de métriques qui pourrait entraîner une consommation de métriques dupliquée pour certains clients. Notre équipe travaille activement à identifier les composants touchés et à déterminer la cause profonde. Nous fournirons d'autres mises à jour à mesure que de plus amples renseignements seront disponibles.

2. 16 juillet 2026 à 16:29 UTCidentified

   Nous avons identifié la cause fondamentale comme l'instabilité sur un courtier spécifique, ce qui provoque un rééquilibrage répété du groupe de consommateurs dans notre service de métriques et conduit au traitement double des mises à jour métriques. Cela peut entraîner chez certains clients des calculs de consommation incorrects ou un blocage inattendu du compte. Nous continuons à travailler sur une solution.

3. 16 juillet 2026 à 17:31 UTCmonitoring

   Nous avons arrêté la progression de la question et nous nous efforçons maintenant d'identifier toute la portée de l'impact, y compris les organisations qui sont touchées ou bloquées. Les comptes affectés seront classés par ordre de priorité aux fins de résolution au moyen d'un processus de déduplication, même si cela prendra un certain temps à terminer.

4. 16 juillet 2026 à 19:04 UTCidentified

   Nous avons réussi à dédoubler la consommation de mesures pour toutes les organisations bloquées. Nous poursuivons nos travaux pour mettre au point des outils de déduplication par organisation afin d'assurer l'exactitude des données du cycle de facturation, avec l'échelle complète de ces correctifs demain matin.

5. 17 juillet 2026 à 13:02 UTCmonitoring

   Nous continuons de faire des progrès pour résoudre le problème de consommation de mesures dupliquées, identifié pour la première fois le 16 juillet. La cause profonde a été identifiée et traitée. Depuis notre dernière mise à jour, notre équipe a corrigé les données dupliquées pour tous les comptes précédemment bloqués. Nous travaillons maintenant sur un ensemble de comptes affectés restants et nous nous attendons à ce que ce nettoyage se poursuive au cours des prochains jours. Il n'y a plus de duplication, ce travail ne porte que sur les données historiques.

6. 20 juillet 2026 à 12:07 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 16 juillet 2026 à 14:49 UTCinvestigating

   Nous enquêtons actuellement sur un problème touchant Phrase Orchestrator. Nous nous efforçons d'identifier la cause fondamentale et fournirons d'autres mises à jour dès que de plus amples renseignements seront disponibles.

2. 16 juillet 2026 à 15:27 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 16 juillet 2026 à 15:27 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

4. 16 juillet 2026 à 15:41 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

5. 16 juillet 2026 à 16:12 UTCresolved

   Orchestrator (UE) est de nouveau disponible depuis 17:32 PM CEST. Toutes les exécutions en cours sont en cours de traitement. Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 10 juillet 2026 à 14:24 UTCinvestigating

   Nous enquêtons actuellement sur un problème qui touche le Centre de traduction de Phrase Strings (régions de l'UE et des États-Unis), où les chaînes ne sont pas chargées. Notre équipe d'ingénieurs a identifié une cause potentielle et travaille activement à la résoudre. Nous fournirons d'autres mises à jour à mesure que notre enquête progressera.

2. 10 juillet 2026 à 14:37 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

3. 10 juillet 2026 à 15:24 UTCresolved

   Cet incident a été résolu.

4. 7 août 2026 à 07:14 UTCpostmortem

   Présentation Le 10 juillet 2026, certaines parties de la façade Phrase Strings à [app.phrase.com](http://app.phrase.com/) n'ont pas été chargées correctement pendant une courte période, après que les feuilles de style et les scripts requis n'ont pas été chargés — le service sous-jacent lui-même est resté disponible. La question a commencé à 16:08 CEST et a été résolue par 16:27 CEST. Ce post mortem explique ce qui s'est passé et ce que nous faisons pour éviter une récidive. Calendrier * **Jul 10, 2026 à 16:08 CEST** – Un déploiement a introduit de nouveaux actifs d'application qui n'ont jamais été téléchargés sur notre service de stockage, de sorte que l'application ne pouvait plus charger ses feuilles de style et scripts pour les clients. * **Jul 10, 2026 à 16:21 CEST** – Délivrance détectée, incident déclaré. * **Jul 10, 2026 à 16:24 CEST** – Cause racine identifiée. * **Jul 10, 2026 à 16:26 CEST** – Correction appliquée. * **Jul 10, 2026 à 16:27 CEST** – Fin de l'impact face au client. * **Jul 10, 2026 à 16:32 CEST** – Incident rétrogradé à la surveillance pendant que la configuration sous-jacente était traitée. * **Jul 10, 2026 à 17:12 CEST** – Configuration corrigée, incident résolu. La cause profonde Lors d'une maintenance planifiée et courante, un changement de configuration a involontairement désactivé le processus qui télécharge les actifs de l'application \(stylesheets, scripts\) vers notre service de stockage et de livraison de contenu. Cela n'a pas été remarqué au début, car les actifs déjà en place fonctionnaient et aucune nouvelle version n'avait encore été expédiée. Le 10 juillet 2026, un déploiement a expédié de nouvelles versions de ces biens. Comme le téléchargement était toujours désactivé, les nouveaux fichiers n'ont jamais atteint le service de stockage, et l'application ne pouvait pas charger ses feuilles de style et ses scripts. Actions pour prévenir la récidive 1. **Réactivation de la synchronisation Le processus désactivé a été corrigé, ce qui a permis de rétablir la bonne livraison des actifs. 2. **Assurer la surveillance de la disponibilité** – Ajouter une surveillance pour détecter automatiquement les défaillances de charge d'actifs, avant que les clients ne soient touchés.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 8 juillet 2026 à 12:57 UTCinvestigating

   Nous recevons des rapports des utilisateurs sur la disparition d'emplois dans les projets et nous enquêtons actuellement sur la question.

2. 8 juillet 2026 à 13:08 UTCmonitoring

   Le problème a été identifié, un correctif a été mis en œuvre et nous suivons la situation.

3. 8 juillet 2026 à 13:55 UTCresolved

   L'incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 7 juillet 2026 à 08:34 UTCinvestigating

   We are currently investigating issues with CAT Web Editor.

2. 7 juillet 2026 à 08:59 UTCmonitoring

   The issue has been identified, a fix was implemented and we are monitoring the situation.

3. 7 juillet 2026 à 09:27 UTCresolved

   The incident has been resolved.

1. 29 juin 2026 à 07:30 UTCinvestigating

   Hi everyone, this is a test. Please ignore, thank you!

2. 29 juin 2026 à 08:05 UTCidentified

   Hi everyone, this is a test. Please ignore, thank you!

3. 29 juin 2026 à 08:09 UTCresolved

   This incident has been resolved.

1. 26 juin 2026 à 16:19 UTCinvestigating

   Hi everyone, this is a test. Please ignore. Thank you!

1. 26 juin 2026 à 07:31 UTCinvestigating

   Hello everyone, this is a test. Please ignore, thank you!

2. 26 juin 2026 à 08:16 UTCinvestigating

   Hello everyone, this is a test. We're "investigating" the issue. Please ignore, thank you!

1. 26 juin 2026 à 07:00 UTCinvestigating

   Hi everyone, this is a test. Please ignore, thank you!

2. 26 juin 2026 à 07:02 UTCresolved

   This incident has been resolved.

1. 23 juin 2026 à 12:53 UTCinvestigating

   Hello everyone, this is a test, kindly ignore.

2. 23 juin 2026 à 12:57 UTCresolved

   This incident has been resolved.

1. 22 juin 2026 à 14:16 UTCinvestigating

   This is a test, please ignore.

2. 22 juin 2026 à 14:21 UTCinvestigating

   This incident has been resolved.