Sept heures du matin, une dépêche tombe, et la rédaction doit décider en quelques secondes si elle publie tout de suite en langue source ou si elle attend d’avoir les trois versions linguistiques prêtes. Ce choix, répété plusieurs fois par jour sur certains sites d’information multilingues, façonne toute l’architecture éditoriale d’un média public qui couvre plusieurs communautés linguistiques.
La contrainte est réelle : une dépêche qui perd quatre minutes sur son concurrent perd une bonne partie de son intérêt pour l’audience qui suit l’actualité en direct. Attendre une traduction complète et relue avant de publier n’importe laquelle des versions linguistiques revient, en pratique, à sacrifier systématiquement la rapidité au profit d’une qualité uniforme que l’urgence ne permet pas toujours d’obtenir.
Le flux à deux vitesses
La méthode qui fonctionne le mieux sur ce type de rédaction sépare clairement deux régimes de publication. Le premier, réservé aux dépêches urgentes, publie immédiatement dans la langue source et affiche, pour les autres langues, un statut explicite plutôt qu’une absence de contenu : un bandeau « Traduction en cours » sur la version anglaise ou allemande, généré automatiquement dès que l’article source est publié sans traduction correspondante. Le second régime, pour les contenus de fond (analyses, portraits, dossiers), attend que toutes les langues prévues soient prêtes avant publication simultanée.
Techniquement, ce bandeau s’implémente simplement avec Polylang en vérifiant, côté thème, si une traduction existe pour l’article courant :
<?php
if ( function_exists( 'pll_get_post' ) ) {
$en_id = pll_get_post( get_the_ID(), 'en' );
if ( ! $en_id ) {
echo '<p class="translation-pending">English translation in progress.</p>';
}
}
?>
Ce bandeau évite l’impression d’un site à moitié vide et informe clairement le lecteur que la traduction arrive, plutôt que de le laisser croire que l’information n’existe pas dans sa langue.
La relance qui ne doit jamais bloquer
Le second principe technique important : la file de traduction ne doit jamais être un préalable à la publication. Concrètement, cela signifie que le statut de publication de l’article source (publish) et le déclenchement de la tâche de traduction sont deux événements découplés dans le code du site, généralement via un hook save_post ou transition_post_status qui ajoute l’article à une file d’attente de traduction sans jamais retenir sa publication.
Sur les rédactions qui ont mis ce découplage en place, la file de traduction devient un tableau de bord à part, souvent une simple liste d’articles filtrée par statut personnalisé (traduction_en_attente), consultée par les traducteurs ou traductrices indépendamment du rythme de publication de la rédaction. Ce découplage protège la rapidité de publication de la langue source des aléas de la traduction, qu’ils viennent d’un traducteur absent, d’un pic d’actualité ou d’un outil de traduction automatique momentanément indisponible.
Où la traduction automatique aide, et où elle ne suffit pas
Pour l’urgence pure — une alerte météo, un résultat électoral, un communiqué officiel court —, une traduction automatique via une API comme DeepL, relue en quelques secondes par un traducteur avant publication, est souvent suffisante et bien plus rapide qu’une traduction humaine complète. Pour l’analyse de fond, le commentaire ou le reportage, la traduction automatique brute introduit un risque éditorial trop important : nuances perdues, ton institutionnel mal rendu, terminologie politique sensible mal choisie. La rédaction gagne à documenter explicitement quels formats de contenu relèvent de l’un ou l’autre régime, plutôt que de laisser chaque traducteur trancher au cas par cas sous la pression du direct.
Le cas des corrections après publication
Une dépêche publiée dans l’urgence contient parfois une erreur factuelle corrigée quelques minutes plus tard. Si la traduction n’a pas encore été faite au moment de la correction, il faut s’assurer que le contenu source corrigé, et non la version fautive initiale, serve de base à la traduction à venir. Un simple horodatage de dernière modification, comparé à l’horodatage de mise en file de traduction, permet d’éviter que le traducteur travaille sur une version déjà obsolète.
- Séparer explicitement les formats « urgence » et « fond » avec des règles de publication différentes
- Afficher un statut clair plutôt qu’un vide quand une traduction n’est pas encore prête
- Découpler la file de traduction du statut de publication de l’article source
- Revérifier la date de dernière modification avant de traduire, pour éviter de traduire une version corrigée entre-temps
Pour aller plus loin
Le vrai enjeu d’un média public multilingue n’est pas de traduire plus vite : c’est d’accepter que l’urgence et la qualité de traduction obéissent à des rythmes différents, et de construire un flux éditorial qui assume cette différence plutôt que de la nier. Un bandeau honnête sur une traduction en cours vaut toujours mieux qu’un silence qui laisse croire à une audience qu’elle n’a pas droit à l’information dans sa langue.
