Trier les traductions échouées sans compromettre la mise en production

Dans une mise en production multilingue, « échoué » ne correspond pas à une seule situation.

La requête du modèle peut avoir échoué. La traduction peut être prête mais impossible à transmettre à Contentful. L’entrée localisée peut être mise à jour mais non publiée. Regrouper les trois sous un seul statut rouge simplifie le tableau de bord et complique le travail de récupération.

Commencez par la phase en échec

La traduction, la transmission et la publication sont des opérations distinctes avec des dépendances différentes.

Un échec de traduction peut provenir d’un délai d’attente du fournisseur, d’une réponse de modèle invalide ou d’une validation de contenu protégé. Un échec de transmission peut impliquer des autorisations, une validation de champ ou un conflit de version Contentful. Un échec de publication peut refléter l’état de l’entrée, la configuration de l’environnement ou le mode de publication.

Le premier filtre de triage doit répondre à la question : quelle phase nécessite une intervention ?

Cela réduit immédiatement le champ de responsabilité et les prochaines étapes.

Montrez l’étendue de l’impact

Une requête en échec doit contenir suffisamment d’éléments d’identification pour permettre une décision :

• nom et ID de l’entrée
• paramètres régionaux source et cible
• lot
• phase en échec
• erreur la plus récente
• nombre de tentatives et heure de la dernière tentative
• si des phases ultérieures ont déjà commencé

Sans ce contexte, les opérateurs ouvrent chaque requête individuellement et reconstituent la mise en production à la main.

La vue par lot doit aussi distinguer un échec partiel d’un échec total. Si 49 locales sur 50 ont réussi, l’équipe doit pouvoir avancer avec le travail terminé tout en récupérant une requête.

Réessayez à partir de la bonne limite

Une nouvelle tentative doit reprendre la phase en échec, et non répéter chaque phase réussie avant elle.

Si la traduction a réussi et que la transmission a échoué, conservez la traduction révisée et relancez la transmission. Si Contentful a été mis à jour et que la publication a échoué, relancez la publication sur l’état actuel de l’entrée.

Redémarrer depuis la traduction peut produire un texte différent, invalider la révision, augmenter le coût et masquer le problème d’origine.

Les nouvelles tentatives sensibles à la phase maintiennent la stabilité du travail déjà réussi.

Séparez les échecs temporaires et permanents

Certains échecs se prêtent bien à une nouvelle tentative automatique :

• délais d’attente du fournisseur
• limites de débit
• courtes interruptions réseau
• conflits de version récupérables

D’autres nécessitent une intervention humaine :

• configuration de contenu invalide
• activation de locale manquante
• refus d’autorisation
• structure protégée qui ne peut pas être restaurée
• champ cible modifié après révision

La politique de nouvelle tentative doit être limitée et visible. Une fois la limite automatique atteinte, la requête doit rejoindre une file humaine avec la dernière erreur utile intacte.

Gardez la liste des échecs légère

Les écrans d’exploitation sont utilisés quand quelque chose se passe déjà mal. Ils ne doivent pas déclencher une hydratation CMS approfondie pour chaque ligne ni interroger de manière si agressive que la page crée plus de charge que les workers qu’elle surveille.

Renvoyez d’abord des métadonnées de requête stables. Ne récupérez le détail complet de l’entrée que lorsqu’un opérateur ouvre la requête.

Le filtrage rapide fait partie de la récupération.

À retenir

Un badge rouge n’est pas un système de récupération.

Séparez les échecs par phase, montrez l’étendue affectée et ne relancez que l’opération qui a échoué. Automatisez la récupération des erreurs temporaires dans des limites claires et conservez des erreurs exploitables pour tout le reste. Les équipes peuvent tolérer des échecs individuels lorsque le flux de travail rend la prochaine décision évidente.