# Organiser un workflow de traduction en agence : notre retour d’expérience sur deux ans > Entre rédacteurs, traducteurs freelances et relecteurs internes, faire circuler un contenu multilingue sans perte demande un processus clair. Bilan honnête. - Auteur : Clément Hadrot - Publié le : 2024-12-05 - Mis à jour le : 2024-12-05 - Catégorie : Multilingue - URL : https://wpmoderne.dev.wordpress-developpement.fr/multilingue/workflow-traduction-agence-retour-experience/ ## L’essentiel - Un statut de contenu dédié évite qu'une traduction en cours parte en production - Le glossaire partagé règle la moitié des allers-retours avec les traducteurs - La responsabilité finale doit toujours être nommée Il y a deux ans, notre processus de traduction pour les sites clients tenait en une phrase : « le rédacteur écrit en français, quelqu'un traduit ensuite, on publie ». Cette simplicité apparente cachait en réalité des pertes constantes — des traductions oubliées, des versions publiées avant relecture, des incohérences terminologiques d'un article à l'autre. Ce retour d'expérience détaille comment nous avons structuré ce processus, ce qui a fonctionné, et ce qui nous a encore posé problème récemment. ## Le point de départ : un processus informel qui ne tenait pas à l'échelle Sur un site avec deux ou trois pages à traduire ponctuellement, une coordination informelle par email suffit largement. Le problème est apparu avec la montée en charge : plusieurs clients avec des rythmes de publication réguliers (deux à trois articles de blog par semaine, en deux ou trois langues), gérés par plusieurs rédacteurs et un pool de traducteurs freelances qui ne travaillent pas tous en même temps ni sur les mêmes projets. Sans structure explicite, un article validé en français partait parfois en production avant que sa traduction anglaise ne soit même commencée, laissant le site dans un état incohérent pendant plusieurs jours. ## Le statut de contenu comme colonne vertébrale du processus La première correction structurelle a consisté à ajouter des statuts personnalisés au workflow éditorial WordPress, au-delà des statuts natifs (brouillon, en attente de relecture, publié). Nous avons ajouté, via `register_post_status()`, un statut `traduction_en_cours` et un statut `traduction_a_relire`, propres aux contenus traduits : ``` 'Traduction en cours', 'public' => false, 'internal' => true, 'show_in_admin_status_list' => true, 'label_count' => _n_noop( 'Traduction en cours (%s)', 'Traductions en cours (%s)' ), ) ); } ); ``` Ce statut apparaît directement dans la liste des articles, avec un compteur, ce qui donne une vision immédiate de l'état du pipeline sans devoir ouvrir chaque contenu individuellement. Un contenu au statut `traduction_en_cours` ne peut techniquement pas être publié tant qu'il n'a pas basculé au statut suivant, une règle imposée par un filtre sur `wp_insert_post_data` qui bloque toute publication directe depuis ce statut sans passer par une validation explicite. > L'essentiel à retenir : Un statut de contenu dédié évite qu'une traduction en cours parte en production ; Le glossaire partagé règle la moitié des allers-retours avec les traducteurs ; La responsabilité finale doit toujours être nommée ## Le glossaire partagé : un gain sous-estimé au départ La deuxième correction, moins technique mais tout aussi structurante, a consisté à imposer un glossaire terminologique partagé avec chaque traducteur freelance avant le démarrage d'une mission. Ce glossaire, tenu dans un simple tableau partagé, liste les termes propres à chaque client (noms de produits, expressions de marque, formulations à éviter) avec leur traduction validée une fois pour toutes. Avant sa mise en place, environ la moitié des allers-retours avec les traducteurs concernaient des questions de terminologie déjà tranchées ailleurs, mais non documentées de façon centralisée. Depuis l'adoption systématique de ce glossaire en amont de chaque mission, ces échanges ont quasiment disparu, ce qui a réduit sensiblement le délai moyen de livraison d'une traduction complète. ## Nommer une responsabilité finale, projet par projet Une leçon plus organisationnelle que technique : chaque projet doit avoir une personne clairement identifiée comme responsable de la validation finale d'une traduction avant publication, avec son nom explicitement enregistré dans un champ de métadonnée sur le contenu concerné, pas seulement une case à cocher anonyme. Cette responsabilité nommée a mis fin à une dilution de responsabilité que nous observions auparavant : un contenu mal traduit publié par erreur restait souvent sans personne clairement identifiable pour expliquer pourquoi la relecture n'avait pas eu lieu. ### Ce qui reste imparfait aujourd'hui Deux ans après cette restructuration, un point continue de nous poser problème : la coordination des mises à jour ultérieures d'un contenu déjà traduit. Lorsqu'un article publié en français est révisé six mois plus tard (une information tarifaire mise à jour, par exemple), rien n'alerte automatiquement le traducteur que sa version anglaise est devenue obsolète. Nous testons actuellement un système de notification basé sur la comparaison de la date de dernière modification entre un post et sa traduction liée, mais ce chantier n'est pas encore totalement stabilisé. ## Le rôle de l'outil multilingue dans ce workflow WPML facilite une partie de ce processus grâce à son gestionnaire de traduction natif, qui permet d'assigner un contenu à un traducteur et de suivre son avancement depuis un tableau de bord centralisé — une fonctionnalité que nous avons intégrée à notre propre système de statuts plutôt que de la remplacer entièrement. Sur les projets utilisant Polylang, dépourvu de gestionnaire de traduction aussi riche en natif, notre système de statuts personnalisés fait l'essentiel du travail de coordination, complété par le glossaire partagé et la responsabilité nommée décrits plus haut. > Ce que nous retenons de ces deux années : la technologie de traduction elle-même (automatique ou humaine) compte finalement moins que la clarté du processus qui l'entoure. Un traducteur excellent dans un processus flou produit plus d'incidents qu'un traducteur moyen dans un processus rigoureux. ## Pour aller plus loin Structurer un workflow de traduction en agence reste un chantier progressif, jamais totalement achevé : chaque nouveau client, chaque nouveau volume de publication révèle de nouveaux angles morts. Les trois piliers qui ont le plus solidement tenu sur la durée restent, dans notre expérience, un statut de contenu dédié qui empêche toute publication prématurée, un glossaire terminologique partagé en amont de chaque mission, et une responsabilité de validation finale toujours nommée, jamais implicite.