Blog Metlivi

Comment relire les termes techniques, les majuscules et les libellés traduits

Lors de la révision d'une documentation technique, vérifiez chaque terme par rapport à un tableau terminologique explicite plutôt que de vous fier à votre mémoire ou à une règle unique d'utilisation des majuscules. Consignez la forme validée, l'orthographe et la casse que les lecteurs doivent voir, les variantes acceptables, les identifiants de code ou d'API littéraux, ainsi que toute traduction en attente d'arbitrage. Relisez ensuite le texte courant, les libellés d'interface et les identifiants comme des éléments distincts. Cette méthode permet de repérer les incohérences terminologiques tout en préservant les noms et le code qui doivent rester stricts.

30 septembre 20264 min de lectureEsthétique du quotidien et expression personnellePar Metlivi Editorial Team

Voir les produits Retour au blog

Section 1

Pourquoi une règle unique de majuscules ne peut-elle pas tout régler ?

Les guides de style fournissent des règles par défaut utiles, mais un produit ou un domaine peut comporter des dénominations établies nécessitant un traitement différent. Le guide du développeur de Google recommande l'anglais américain standard pour la casse et préconise la casse de phrase (sentence case) pour les titres, listes et tableaux, tout en conservant les noms officiels de produits et les formes de code. Le guide de Microsoft privilégie également la casse de phrase, mais réserve explicitement les majuscules aux noms propres tels que ses marques, produits et services. Cette base commune est un point de départ, et non la preuve qu'un terme technique donné est générique. [Directives de capitalisation de Google](https://developers.google.com/style/capitalization) [Directives de capitalisation de Microsoft](https://learn.microsoft.com/en-us/style-guide/capitalization)

Une liste de vocabulaire peut répondre à une question différente de celle d'une page générale sur les majuscules : quelle orthographe ou quel usage un guide éditorial particulier privilégie pour des termes spécifiques. La liste de Google, par exemple, oriente les lecteurs vers son dictionnaire de référence pour les entrées non couvertes et distingue le conseil de style de la vérification d'une définition technique dans une documentation faisant autorité. Cette distinction est utile : la cohérence éditoriale et l'exactitude technique exigent des preuves issues de sources adaptées à chaque question. [Liste de mots de Google](https://developers.google.com/style/word-list)

Section 2

Que doit contenir un tableau terminologique de relecture ?

Créez une ligne pour chaque terme susceptible d'être modifié de manière incohérente ou mal traduit. Cet exemple hypothétique illustre les champs et la logique de décision ; « Sync token » et sa traduction sont fournis à titre d'exemple et ne prétendent pas décrire un produit réel ou une terminologie officielle.

Le rôle du tableau est de conserver les décisions et leurs limites. Une forme minuscule autorisée ne doit pas devenir discrètement un deuxième nom de produit ; un identifiant ne doit pas être « corrigé » pour s'aligner sur le texte ; et une traduction en attente doit rester visiblement non résolue. Lorsqu'une source officielle est en conflit avec un glossaire local, notez le désaccord et la source de la décision finale au lieu de fusionner les formes dans une liste sans explication.

Terme et portée — Concept, domaine du produit et public visé — Sync token ; guide de configuration

Forme officielle et source de référence — Forme exacte validée, source et version ou date vérifiée — Sync token ; glossaire du produit, version 3

Forme d'affichage — Orthographe et casse employées dans le texte explicatif et les libellés — Sync token

Variantes autorisées — Formes acceptées dans un contexte défini, avec justification — « sync token » dans le texte générique, si le glossaire l'autorise

Identifiants littéraux — Code exact, API, commande ou chaîne d'interface utilisateur qui ne doit pas être réécrite — `syncToken` dans une réponse d'API

Statut de traduction — Libellé localisé approuvé, source de référence, responsable ou processus, ou état non résolu — Non résolu ; révision de traduction nécessaire

Section 3

Comment décider de l'orthographe et de la casse à afficher ?

Identifiez d'abord ce à quoi le terme fait référence : un concept ordinaire, un nom de marque ou de produit, un libellé d'interface ou un identifiant littéral. Consultez la documentation du produit ou le glossaire pertinent pour trouver la forme officielle. Appliquez ensuite les règles de style de la publication cible au texte courant, aux titres et aux libellés, en conservant les exceptions documentées pour les noms et les identifiants. Google déconseille l'emploi superflu de majuscules et avertit qu'il ne faut pas se fier à la seule casse pour distinguer le sens ; Microsoft indique de même d'utiliser les minuscules, sauf pour le début des phrases et les noms propres selon son approche en casse de phrase. [Directives de capitalisation de Google](https://developers.google.com/style/capitalization) [Directives de capitalisation de Microsoft](https://learn.microsoft.com/en-us/style-guide/capitalization)

Ensuite, comparez la forme avec la liste de termes et le dictionnaire de l'organisation cible, le cas échéant. Consignez la source ainsi que sa version ou sa date de vérification afin qu'un autre rédacteur puisse retracer ce choix. Ne déduisez pas un statut officiel d'une orthographe avec majuscule séduisante, d'un résultat de recherche ou d'une traduction qui ressemble au terme anglais. Si les sources sont en désaccord ou ne précisent pas la forme, signalez la ligne pour arbitrage plutôt que de présenter une supposition comme une terminologie établie.

Section 4

Comment vérifier les traductions et les libellés d'interface ?

Considérez la traduction comme une décision de sens et de contexte, et non comme une conversion mécanique de majuscules. Un libellé peut être contraint par l'interface, la terminologie produit localisée déjà établie ou une forme grammaticale différente dans la langue cible. Comparez la proposition avec les documents localisés validés et le contexte dans lequel les lecteurs la rencontreront. Si aucune forme localisée de référence n'est disponible, marquez la traduction comme non résolue et sollicitez l'arbitrage terminologique adéquat ; n'inventez pas un équivalent prétendu officiel.

Une fois la décision terminologique prise, relisez le libellé directement dans son contexte. Vérifiez si l'emploi des majuscules respecte les règles de la langue choisie ainsi que la charte du produit ou le guide de style applicable. Conservez le libellé d'origine visible dans la fiche terminologique, aux côtés de sa source et de son statut, afin qu'une révision ultérieure ne prenne pas une traduction temporaire pour une version validée. Si le libellé est également mentionné dans des instructions, vérifiez que le texte reprend exactement le libellé affiché à l'écran.

Section 5

Comment protéger le code et les identifiants d'API ?

Séparez les chaînes littérales du texte éditorial avant de modifier la casse. Comparez les identifiants caractère par caractère avec la documentation de référence de l'API, le schéma, le code ou l'interface correspondants. Conservez les tirets bas (underscores), les majuscules, les espaces et la ponctuation là où la source les définit ; l'harmonisation stylistique s'applique aux explications environnantes, et non à une valeur littérale. Le guide de Google autorise explicitement les formes tout en majuscules ou en camelCase dans les noms officiels ou lorsqu'il s'agit de faire référence à du code qui les emploie. [Directives de capitalisation de Google](https://developers.google.com/style/capitalization)

Une révision efficace consiste à identifier les identifiants protégés dans le tableau terminologique, puis à vérifier chaque occurrence par rapport à cette référence. Si une phrase en texte courant emploie un terme sous forme de code comme un nom ordinaire, déterminez s'il convient de l'expliquer dans une formulation plus accessible tout en conservant l'identifiant littéral intact sous forme de code formaté. Lorsque la définition de référence est elle-même floue, consignez l'incertitude ; un guide de style ne peut pas définir le comportement d'une API ni le nom canonique d'un champ.

Section 6

Quel est le processus de relecture le plus fiable ?

Ce processus est une aide à la relecture, et non un outil de traduction automatique ou une règle universelle sur la casse. Son utilité réside dans le fait qu'il rend chaque décision éditoriale vérifiable : quelle forme a été retenue, d'où elle provient, où elle s'applique et ce qui nécessite encore un arbitrage. Pour un document court, un tableau synthétique peut suffire ; pour un ensemble terminologique plus vaste, conservez ces mêmes champs dans le processus habituel de gestion des glossaires de l'équipe.

**Collecter :** identifiez les termes techniques répétés, les noms de produits, les libellés, les termes traduits et les identifiants dans les documents à réviser.

**Vérifier :** consultez la documentation officielle, le glossaire, la liste de mots et le guide de style applicables. Notez les versions ou les dates des sources dès que possible.

**Décider :** renseignez dans le tableau la forme d'affichage validée, les variantes autorisées et les identifiants protégés. Marquez les désaccords et les traductions manquantes comme non résolus.

**Appliquer :** modifiez le texte courant et les titres de manière cohérente, tout en préservant les noms officiels, les formulations entre guillemets et les identifiants littéraux.

**Revérifier :** recherchez dans le document chaque variante enregistrée et chaque identifiant protégé. Assurez-vous que chaque occurrence convient à son contexte d'utilisation, puis tranchez ou faites remonter les lignes en suspens avant de considérer la relecture terminologique comme achevée.