Les conflits de version Contentful doivent être relancés en toute sécurité

Contentful protège les entrées avec un verrouillage optimiste. Chaque mise à jour inclut la version que le client pense être en train de modifier. Si une autre modification arrive d’abord, Contentful rejette la mise à jour obsolète au lieu de la laisser écraser un travail plus récent.

Ce conflit est une fonctionnalité de sécurité. Il ne doit pas devenir une impasse pour la localisation.

Pourquoi les conflits surviennent dans des équipes saines

Une demande de traduction peut prendre du temps. Pendant qu’elle est générée ou relue, un éditeur peut corriger l’entrée source, une autre langue peut être mise à jour, ou une automatisation peut modifier des métadonnées.

Au moment où la valeur localisée est prête à être envoyée, la version de l’entrée capturée plus tôt est obsolète.

Cela ne signifie pas que quelqu’un a commis une erreur. Cela signifie que plusieurs parties du système de publication fonctionnent en même temps.

Ne relancez jamais aveuglément la même charge utile obsolète

La relance la plus simple répète la requête rejetée. Elle ne peut pas réussir, car elle transporte la même version dépassée.

L’alternative dangereuse consiste à récupérer le dernier numéro de version et à renvoyer l’ancienne charge utile complète de l’entrée. Cela peut passer la vérification de version tout en écrasant des champs modifiés depuis le début de la traduction.

Une relance sûre a besoin d’un état à jour et d’un correctif ciblé.

Relire, fusionner et mettre à jour

Quand Contentful signale un conflit de version, le workflow doit :

1. récupérer l’entrée actuelle depuis le même espace et environnement
2. inspecter les champs et la version les plus récents
3. fusionner uniquement les valeurs approuvées de la langue cible issues de la demande de traduction
4. préserver les champs non liés et les valeurs des autres langues
5. soumettre la mise à jour avec la version fraîche

Cela maintient la relance alignée sur l’intention réelle de l’utilisateur. La demande de traduction voulait modifier des champs localisés spécifiques, pas restaurer un ancien instantané de l’entrée entière.

Décider quand ne pas relancer

La récupération automatique des conflits a besoin de limites.

Si le champ exact de la langue cible a changé après le début de la relecture, le système a détecté une véritable collision éditoriale. Relancer automatiquement pourrait remplacer un travail humain plus récent. Ce cas doit s’arrêter et demander une révision.

De même, des conflits répétés peuvent indiquer une boucle d’automatisation active ou une intégration qui écrit l’entrée en continu. Un nombre limité de tentatives empêche la localisation de rejoindre cette boucle indéfiniment.

L’erreur doit rester exploitable : identifier l’entrée, la langue et les champs concernés, ainsi que l’étape à laquelle la collision s’est produite.

Garder une séparation claire entre la propriété source et cible

La gestion des conflits est plus simple lorsque le workflow a une limite d’écriture stricte. Les envois de traduction ne doivent modifier que les langues cibles approuvées. Ils ne doivent pas écrire dans les champs source, les métadonnées du type de contenu, les tags ou les valeurs d’autres langues non liées.

Cette limite réduit la complexité des fusions et donne du sens aux journaux d’audit. Lorsqu’une relance réussit, l’équipe peut voir exactement quels champs localisés ont changé et pourquoi.

À retenir

Les conflits de version sont normaux dans un CMS collaboratif. Traiter chaque conflit comme une traduction échouée rend le workflow fragile ; ignorer le conflit le rend dangereux.

Récupérez l’entrée la plus récente, fusionnez la plus petite modification approuvée, puis relancez dans des limites claires. Lorsque le même champ a changé des deux côtés, arrêtez-vous pour une révision humaine. La fiabilité vient du respect du travail concurrent, pas du fait de prétendre qu’il n’existe pas.