Docsbook
Aperçu

Qualité de la traduction et SEO

C’est sur cette page que l’affirmation est vérifiée. Elle couvre ce que Docsbook mesure réellement concernant une traduction, comment en corriger une, ce que les moteurs de recherche et les assistants d’IA font des documentations traduites et — à la fin — ce que la traduction automatique comprend encore mal dans la prose technique, avec une source.

Ce que Docsbook mesure et ce qu’il ne mesure pas#

Docsbook ne publie aucun score de qualité de traduction. Il n’y a aucune valeur BLEU, COMET, TER ou issue d’une évaluation humaine pour vos pages, et cette documentation n’en inventera aucune. Le produit mesure plutôt la couverture et la fraîcheur : si une page existe dans une langue et si elle a été créée à partir de la version de la source actuellement en ligne.

Il s’agit d’une affirmation plus limitée que « nos traductions sont bonnes », et c’est celle qui peut être vérifiée.

Couverture et actualité#

Chaque traduction stockée conserve le SHA du blob git du fichier source à partir duquel elle a été créée. La couverture est calculée en lisant l’arborescence de votre dépôt à HEAD et en comparant chaque chemin :

État Signification Coût pour votre lecteur
current Traduite à partir du SHA du fichier à HEAD Rien
behind Traduite à partir d’une version plus ancienne de la page La page leur dit quelque chose que votre documentation ne dit plus
missing Présente dans le dépôt, mais jamais traduite dans cette langue Ils reviennent à la langue d’origine
manual Rédigée manuellement ou importée — l’actualité dépend de l’auteur Rien ; elle n’est jamais considérée comme obsolète
orphaned Page traduite dont le fichier source n’existe plus à HEAD Une page correspondant à du contenu que vous avez supprimé

La couverture est (current + manual) / total. Une langue est synchronisée lorsque behind et missing sont tous deux nuls. Lorsque votre dépôt ne peut pas être lu, la couverture est null — jamais un zéro certain — afin qu’une lecture GitHub limitée par le débit ne puisse jamais signaler à tort une langue saine comme étant en difficulté.

Lecture#

  • Dans le panneau. Chaque langue possède sa propre page : un pourcentage de couverture au-dessus d’une barre répartie selon le type de lacune, le commit auquel votre documentation se trouve actuellement, une barre de progression en direct indiquant qui a lancé la passe en cours, les douze dernières exécutions colorées selon leur issue et — lorsqu’une exécution s’est arrêtée prématurément — la raison en toutes lettres. En dessous, vos commits, du plus récent au plus ancien, chacun accompagné d’un verdict sur l’état de ses pages dans cette langue, afin que « la réécriture des tarifs a été publiée mardi » soit quelque chose que vous pouvez vérifier plutôt qu’un nom de fichier à déduire.
  • Via MCP. get_translation_status renvoie exactement ceci pour chaque langue : current / behind / missing / manual / orphaned, le pourcentage, in_sync, si une exécution est en cours et où elle en est, ainsi que le résultat de la dernière exécution — y compris l’exécution d’agent qui l’a lancée. Le descriptif de l’outil indique à l’appelant de le lire avant run_translation_pass, car retraduire une langue déjà au niveau de la source coûte de l’argent et ne change rien.
  • Par webhook. translation.needed est déclenché lorsqu’une page dans une langue activée est sur le point d’être traduite, translation.completed lorsqu’elle est enregistrée de façon persistante et translation.outdated lorsqu’une traduction prend du retard sur sa source. translation.completed est déclenché uniquement lorsque la page a réellement été enregistrée, de sorte qu’un écouteur qui réindexe un CMS ne soit jamais informé d’une traduction qui n’existe pas.

Le seul chiffre qui est une comparaison, pas une mesure#

Le chiffre des économies sur le tableau de bord des traductions évalue le montant qu’un traducteur humain aurait facturé pour les mêmes caractères, au tarif de 5,00 $ pour 1 000 caractères, moins le coût réel de la traduction par IA. Deux points à retenir :

  • Il est calculé par caractère, et non par mot, à dessein. Le nombre de mots dépend de la langue cible — le chinois et le japonais ne contiennent pas de mots délimités par des espaces —, de sorte qu’une mesure par mot serait proche de zéro précisément pour les langues qu’elle devrait mesurer.
  • Il s’agit d’un montant contrefactuel, pas d’une facture. Personne n’a été payé, ni l’un ni l’autre montant. Le tarif est une constante fixe dans Docsbook, et non un devis que vous avez reçu. Considérez ce chiffre comme un ordre de grandeur.

Puis-je corriger une traduction, et la correction sera-t-elle conservée ?#

Vous pouvez en corriger une, et la correction est protégée contre tout écrasement lors d'une passe ultérieure — cette protection est appliquée directement lors de l'écriture en base de données. La question de savoir si votre texte corrigé est ensuite proposé aux lecteurs est distincte, et la réponse honnête se trouve ci-dessous.

Comment en corriger une. Modifiez la traduction dans le panneau Traductions, ou envoyez-la avec upload_translation. Les importations arrivent à l'état de brouillon ; list_pending_translations affiche les brouillons et approve_translation en publie un. La modification du contenu d'une traduction marque la ligne comme une importation manuelle.

Pourquoi elle survit à une passe. Les passes automatiques écrivent via une opération upsert en base de données dont la clause de conflit n'écrase que les lignes dont l'origine est docsbook_ai. Une ligne marquée comme importation manuelle est ignorée par cette écriture, et la couverture la compte comme manual — un état qui n'est jamais « en retard », car la fraîcheur d'une page rédigée par une personne relève de la décision de cette personne, et non d'une comparaison de hachages. Le remplacement de cette manière d'une traduction IA active renvoie également replaced_ai_translation: true à l'appelant, afin qu'un agent puisse avertir un humain qu'il vient de remplacer quelque chose que les lecteurs voyaient déjà.

Point à nuancer. La documentation de Docsbook a indiqué qu'une fois une correction importée, « Docsbook propose ensuite votre version ». Ce qui est vérifiable : la ligne corrigée est stockée, n'est jamais écrasée par une passe automatique ultérieure (la clause de conflit de l'upsert n'écrit par-dessus que les lignes dont l'origine est docsbook_ai), et est comptée comme manual dans la couverture plutôt que comme obsolète. Ce qui ne l'est pas : le fait qu'elle soit proposée aux lecteurs. À la lecture du code tel qu'il existe actuellement, trois éléments indiquent le contraire. La page destinée aux lecteurs lit une traduction dans le cache actif et, en cas d'absence, dans les lignes stockées filtrées par origin = 'docsbook_ai'. Le même filtre détermine si une langue appartient au cluster hreflang de cette page et si son URL est incluse dans le plan du site. En outre, le chemin d'invalidation du cache indique explicitement que les lignes manuelles et externes « n'écrivent jamais dans les clés de page Redis SSR », de sorte qu'il n'existe pas non plus de copie en cache que la première lecture puisse trouver. Une ligne importée manuellement ou modifiée à la main ne correspond à aucun de ces critères. Nous n'avons publié aucune mesure montrant qu'une page corrigée est effectivement proposée, et le mécanisme tel qu'il est écrit ne le prédit pas — considérez donc les importations manuelles comme un moyen de protéger une page contre une nouvelle traduction et d'alimenter un pipeline externe, et non comme un moyen de modifier ce que voit un lecteur. Si une phrase précise est incorrecte pour vous aujourd'hui, la solution fiable consiste à modifier la page source et à laisser la passe la retraduire.

C'est exactement le type d'affirmation que notre règle relative aux éléments probants nous oblige à signaler plutôt qu'à supprimer discrètement.

Ce que font les moteurs de recherche avec la documentation traduite#

Des URL distinctes par langue et un cluster hreflang par page#

Chaque langue possède son propre chemin d’URL — jamais un sous-domaine, jamais un paramètre de requête. De plus, chaque page de documentation émet un ensemble hreflang défini comme des alternatives <link rel="alternate">, ainsi que x-default et en pointant vers l’URL dans la langue d’origine.

La règle qui permet à ce système de fonctionner est la réciprocité, et elle est appliquée page par page plutôt qu’à l’échelle du site :

Règle Pourquoi Où la vérifier
Une locale n’apparaît dans le cluster de cette page que lorsque cette page est réellement traduite dans cette langue Une URL /fr/… non traduite affiche l’original et déclare l’original comme canonique. La répertorier comme alternative publie un membre du cluster qui contredit son propre canonique, et l’ensemble du cluster — y compris les locales qui sont traduites — est ignoré Le <head> de toute page traduite
Une URL de locale non traduite possède comme canonique la page dans la langue d’origine Il s’agit d’un quasi-doublon de l’original qui entre en concurrence avec lui, et non d’une page distincte Toute URL /fr/… d’une page que le français n’a pas encore atteinte
/en/… possède comme canonique l’URL sans préfixe L’anglais est servi à l’identique dans les deux cas ; la paire est regroupée en une seule page indexable plutôt qu’en deux doublons canoniques autoréférencés Toute URL /en/…
Une page noindex est entièrement retirée du cluster, et pas simplement omise des autres Les moteurs de recherche récupèrent chaque alternative pour vérifier la réciprocité — précisément le budget d’exploration qu’une page noindex a été retirée de l’index pour cesser de consommer Une page avec noindex: true dans le frontmatter
Le sitemap n’émet aucune alternative hreflang Les hreflang au niveau du sitemap et de la page sont fusionnés en un seul cluster et doivent être cohérents. Le sitemap ne peut pas vérifier à un coût raisonnable l’état de traduction de chaque page ; tout ce qu’il émettrait répertorierait donc chaque locale activée, réintroduisant précisément le membre qui invalide le cluster sitemap.xml

Docsbook construit le canonique et les alternatives à partir de la même fonction que celle qui achemine l’URL ; l’adresse annoncée est donc celle qui répond avec un code 200 plutôt qu’une adresse qui redirige — un canonique pointant vers une redirection est traité par Google en supprimant la page.

Un autre mécanisme relève de la même règle. Google indique clairement qu’il « utilise le contenu visible de votre page pour déterminer sa langue » et que « Nous n’utilisons aucune information de langue au niveau du code, telle que les attributs lang ou l’URL » — ainsi, une page entièrement traduite qui contient encore un <title> en anglais envoie son signal le plus fort sur la page dans la mauvaise langue. Docsbook récupère le titre à partir du HTML traduit qu’il a déjà stocké, en lisant le <h1> traduit propre à cette page, sans appel supplémentaire au modèle. La méta-description est délibérément laissée dans la langue d’origine dans ce cas : inventer une traduction pour celle-ci ne fait pas partie des opérations autorisées lors de la génération des métadonnées, et un titre correct accompagné d’une description dans la langue d’origine vaut mieux que deux éléments erronés.

Pourquoi chacune de ces règles est la bonne#

Règle Pourquoi elle fonctionne sur la machine qui la consomme Source
Publier chaque langue sur sa propre URL et annoter l’ensemble avec hreflang Les consignes de Google sont les suivantes : « Utilisez hreflang pour informer Google des variantes de votre contenu » Google Search Central : versions localisées
Rendre chaque cluster réciproque et ne jamais répertorier une langue dans laquelle cette page n’est pas traduite « Chaque version linguistique doit se répertorier elle-même ainsi que toutes les autres versions linguistiques. » Google cite cette erreur en premier parmi les erreurs courantes liées à hreflang, sous Liens de retour manquants : « Si la page X contient un lien vers la page Y, la page Y doit renvoyer vers la page X. Si ce n’est pas le cas pour toutes les pages qui utilisent des annotations hreflang, ces annotations peuvent être ignorées ou mal interprétées » Google Search Central : versions localisées
Définir l’URL d’une langue non traduite comme URL canonique de la page d’origine La formulation de Google est précise : « Les versions localisées d’une page sont considérées comme des doublons uniquement si le contenu principal de la page reste non traduit. » Par définition, une URL /fr/ qui diffuse le contenu en anglais correspond à ce cas Google Search Central : versions localisées
Conserver une page traduite comme canonique pour elle-même, et ne jamais la définir comme canonique vers l’original Les recommandations de Google sur la canonisation indiquent de « veiller à spécifier une page canonique dans la même langue », et précisent que les annotations rel="canonical" contenant hreflang « ne sont pas utilisées pour la canonisation » Google Search Central : canonisation
Traduire le corps, et pas uniquement la navigation et les pieds de page « Google utilise le contenu visible de votre page pour déterminer sa langue. » et « Nous n’utilisons aucune information linguistique au niveau du code, comme les attributs lang ou l’URL. » Une URL de langue dont le corps n’est pas traduit n’est pas une page dans cette langue, quoi qu’elle déclare Google Search Central : gestion des sites multirégionaux
Placer la langue dans un segment de chemin Les sous-répertoires constituent l’une des trois structures d’URL documentées par Google, avec les ccTLD et les sous-domaines. L’inconvénient mentionné est d’ordre humain : « Les utilisateurs peuvent ne pas identifier le ciblage géographique à partir de l’URL seule » Google Search Central : gestion des sites multirégionaux
Produire des codes de langue bruts à deux lettres Pour hreflang, Google exige des codes de langue ISO 639-1 associés à des codes de région ISO 3166-1 Alpha 2, et rejette tout le reste : « les autres codes qui ne figurent pas dans ces normes, tels que es-419, ne sont pas pris en charge ». La norme BCP 47 est du même avis quant à la forme — ses propres recommandations indiquent qu’un sous-étiquette « NE DEVRAIT être utilisée que lorsqu’elle apporte une information distinctive utile », ce que le W3C reformule ainsi : « la règle d’or est de garder votre étiquette de langue aussi courte que possible » Google · RFC 5646 (BCP 47) · W3C
Ne jamais rediriger automatiquement un lecteur vers une langue « Évitez de rediriger automatiquement les utilisateurs d’une version linguistique d’un site vers une autre » — « Ces redirections pourraient empêcher les utilisateurs (et les moteurs de recherche) d’afficher toutes les versions » Google Search Central : gestion des sites multirégionaux

Notez ce que l’avant-dernier élément implique concernant les étiquettes valides : es-419 est une étiquette BCP 47 parfaitement légale — le W3C l’utilise comme exemple détaillé — et Google ne l’accepte explicitement pas dans hreflang. Une étiquette de langue valide et une valeur hreflang valide ne constituent pas le même ensemble.

La traduction automatique est-elle contraire aux règles de Google ?#

Non — et la réponse est plus précise que l'un ou l'autre des deux camps de l'argument habituel, il vaut donc la peine de l'établir exactement.

Les pages traduites ne sont pas des doublons. Google définit la limite en une phrase : « Les versions localisées d'une page ne sont considérées comme des doublons que si le contenu principal de la page reste non traduit. » Une page entièrement traduite est une page distincte. Une URL localisée qui diffuse le contenu original est un doublon — c'est pourquoi Docsbook fait pointer les balises canoniques de ce cas vers l'original au lieu de le publier comme une version alternative. Et concernant les doublons en général, la position de longue date de Google est la suivante : « La présence de contenu dupliqué sur un site ne justifie pas de mesure à l'encontre de ce site, sauf s'il apparaît que le contenu dupliqué vise à tromper et à manipuler les résultats des moteurs de recherche » (Démystifier la pénalité liée au contenu dupliqué, 2008).

L'ancienne règle selon laquelle « la traduction automatique est du spam » a disparu. Les politiques anti-spam de Google ne contiennent aucune mention de la traduction automatique — les expressions « machine translation » et « automatically translated » n'apparaissent pas du tout sur la page. Ce qui s'y trouve est l'abus de contenu à grande échelle, défini comme « la création de grandes quantités de contenu original qui n'apporte que peu ou pas de valeur aux utilisateurs, quelle que soit la manière dont il est créé ». Le mot traduction ne subsiste que dans un exemple de scraping relevant de cette même politique : « Exploiter des flux, des résultats de recherche ou d'autres contenus pour générer de nombreuses pages (notamment au moyen de transformations automatisées telles que le remplacement par des synonymes, la traduction ou d'autres techniques d'obfuscation), lorsque les utilisateurs bénéficient de peu de valeur ». L'historique des modifications de Google consigne le nettoyage effectué le 11 juin 2025 : « Suppression d'une section de notre documentation multilingue concernant l'utilisation de robots.txt pour bloquer toutes les pages traduites automatiquement », « Afin de l'aligner sur la mise à jour de notre politique anti-spam de mars 2024 » (Mises à jour de la documentation Search Central).

La position actuelle dépend de la qualité, et non de la méthode. Interrogé directement sur la question de savoir si la traduction automatique nuit au classement, Gary Illyes a répondu « si la traduction automatique est de mauvaise qualité, peut-être », et a conseillé aux sites de « s'assurer qu'un locuteur natif de ces langues relise les traductions (et les corrige éventuellement) ». Au cours de la même session, John Mueller a indiqué qu'il n'existe « aucun balisage spécial que vous puissiez ajouter à vos pages » pour déclarer qu'une traduction a été produite par une machine, que le critère est de savoir si « les pages sont bien traduites », qu'« une bonne localisation est bien plus qu'une simple traduction de mots et de phrases », et qu'un résultat de mauvaise qualité est un cas où « vous pourriez simplement leur ajouter la balise meta robots noindex » (Heures de permanence SEO de Google, juin 2024).

En pratique, une équipe de documentation doit retenir les points suivants :

  • Ce qui est pénalisé, c'est le volume sans valeur, pas l'outil. Traduire une centaine de pages de documentation dont vos lecteurs ont réellement besoin ne constitue pas un abus de contenu à grande échelle ; générer des pages localisées que personne n'a demandées, si.
  • La relecture est la variable nommée par Google. Docsbook vous fournit les fonctionnalités nécessaires — la page de couverture par langue, list_pending_translations avec approve_translation, ainsi que le mode external pour faire passer chaque page dans votre propre pipeline avant publication — sans vous obliger à les utiliser. Le mode auto publie au fur et à mesure. Choisissez en connaissance de cause.
  • La relecture utile la moins coûteuse ne consiste pas à vérifier chaque page. Elle concerne les pages qui génèrent vos revenus : le guide de démarrage rapide, tout ce qui touche aux tarifs, les pages les plus consultées dans vos statistiques pour cette langue, et toute page où une instruction mal traduite compromet la configuration du lecteur. Si une langue est mal rendue et que vous n'allez pas corriger le problème, noindex est une réponse autorisée.

Ce que les assistants IA en font#

Rien de particulier, et c’est bien là l’objectif. Un moteur génératif récupère le même HTML statique que celui qu’un robot d’exploration lit. L’activation d’une langue crée des pages dans cette langue qu’un assistant peut récupérer et citer lorsque la question est posée dans cette langue — ce qu’un corpus limité à la langue d’origine ne peut pas faire. Docsbook indexe en outre le texte traduit pour la recherche en texte intégral sur le site, sous le code de cette langue, afin qu’un lecteur effectuant une recherche en allemand trouve les pages allemandes plutôt que la source anglaise. Consultez GEO pour découvrir ce qui est ajouté directement à la page.

Limites — ce que la traduction automatique comprend encore mal dans la documentation technique#

Prenez cette section aussi au sérieux que le reste de la page.

  • La cohérence terminologique n’est pas gérée, et c’est le point faible mesuré de tout le domaine. Docsbook ne dispose ni d’un glossaire, ni d’une base terminologique, ni d’une liste de termes à ne pas traduire que vous pourriez fournir. La cohérence repose sur trois sources plus faibles : les requêtes sont exécutées avec une température de 0, une section non modifiée est servie telle quelle depuis le cache et ne peut donc pas diverger, et les libellés de navigation ainsi que le titre et la description sont traduits en tant qu’ensembles. Deux pages différentes utilisant le même terme ont été traduites indépendamment et peuvent ne pas être cohérentes.

    L’importance de ce point a été mesurée. Moslem et al. ("Intégration de la terminologie de domaine dans la traduction automatique : tirer parti des grands modèles de langage", WMT 2023, arXiv:2310.14451) indiquent que, pour les ensembles de test en aveugle DE-EN, EN-CS et ZH-EN, "le nombre de termes intégrés aux traductions de l’ensemble de données en aveugle passe d’une moyenne de 36,67 % avec le modèle générique à une moyenne de 72,88 % à la fin du processus""l’utilisation correcte des termes double presque pour les trois paires de langues". Interprétez précisément cette métrique : elle indique si le terme requis a été utilisé, et les 72,88 % correspondent à la fin d’un processus en quatre étapes conçu à cet effet, et non à un modèle plus performant utilisé seul.

    La tâche partagée de terminologie WMT25 quantifie l’autre aspect de la même question. Les données de sa piste 1 ont été produites par SAP à partir de son portail d’aide en ligne (EN→DE/RU/ES, 500 cas de test par paire de langues, 20 systèmes issus de 13 équipes), et "les systèmes performants atteignent une très grande précision terminologique, supérieure à 97 %"uniquement lorsque le glossaire correct est fourni au système au moment de l’inférence, ce qui est précisément l’élément dont Docsbook ne dispose pas. La tâche exécute également les mêmes systèmes avec un dictionnaire aléatoire et sans dictionnaire : son meilleur système obtient 99,1 avec le glossaire approprié, 49,2 avec un glossaire aléatoire et 44,4 sans glossaire. Sur les textes plus longs, elle indique que "les systèmes sont souvent en deçà des attentes" et que "la piste documentaire reste une tâche plus difficile". Il faut comprendre que la fidélité terminologique est conçue, et non héritée, et que Docsbook ne l’a pas encore conçue.

    Le constat général est le même. La tâche de traduction générale WMT24 (Kocmi et al.), qui a recueilli des traductions produites par "8 grands modèles de langage (LLM) différents et 4 fournisseurs de traduction en ligne" dans 11 paires de langues, s’intitule "L’ère des LLM est arrivée, mais la traduction automatique n’est pas encore résolue". Ses domaines sont l’actualité, la littérature, la parole et les réseaux sociaux — pas la documentation technique — ; citez-la donc pour l’affirmation « pas encore résolue », et citez les deux sources précédentes pour toute affirmation concernant les textes de domaine. Ses suites de tests signalent bien une faiblesse en matière de terminologie, mais de façon limitée : la phrase porte sur une seule direction et un seul système, "Pour l’anglais-russe, Yandex est moins performant concernant les entités nommées et la terminologie", et il ne s’agit pas d’un constat général sur la traduction par les LLM.

  • Les identifiants bruts dans le texte courant ne sont protégés que par une instruction. Le code placé dans des blocs délimités et entre accents graves est supprimé de la requête, puis restauré octet par octet — c’est un traitement mécanique. Un nom de paramètre écrit comme du texte courant sans accents graves parvient au modèle et reste dans la langue source uniquement parce que l’invite le demande. Marquer les identifiants comme du code est la mesure la plus utile que vous puissiez prendre pour vos propres traductions. Nous avons cherché une mesure publiée indiquant à quelle fréquence la traduction par LLM déforme spécifiquement les identifiants de code, sans en trouver ; les éléments publiés les plus proches sont les travaux terminologiques cités plus haut. Considérez l’ampleur de ce risque comme non mesurée plutôt que faible.

  • Le texte de l’image alt n’est pas traduit. Il s’agit d’un attribut HTML, et la règle qui protège href et id protège également alt.

  • Docsbook n’a publié aucune mesure qui lui soit propre. Aucun chiffre de précision, aucun taux d’erreur, aucun classement par langue. Si vous en avez besoin pour votre corpus, la manière honnête de l’obtenir consiste à faire relire un échantillon de vos propres pages par un lecteur maîtrisant la langue — et la couverture vous indique quelles pages méritent d’être échantillonnées.

  • Le modèle peut changer sans que vous le sachiez. Le modèle de traduction par défaut est une constante de configuration, et le sélecteur vous permet de le modifier. Une page traduite le mois dernier l’a été par le modèle sélectionné à ce moment-là ; rien ne retraduit une page parce que le modèle s’est amélioré.

  • Les variantes régionales ne sont pas modélisées. Un pt pour le Brésil et le Portugal, un zh pour le chinois simplifié et traditionnel. Pour les produits dont les ventes dépendent de cette distinction, il s’agit d’une véritable limitation, et non d’une simple erreur d’arrondi.

Cette page vous a-t-elle été utile ?