Interface utilisateur · Traduction technique
Dossier : Traduction technique d'interface utilisateur
Cette fiche en pose le cadre : ce qui est attendu du dossier, ce qui se vérifie en amont et ce qui relève de l'appréciation de l'administration.
Positionnement : traduction technique d'interface utilisateur
Avant d'aller plus loin, il convient de poser les repères utiles pour ce dossier. Les points de vigilance portent sur traducteur assermenté, manuel technique, afin d'éviter les allers-retours. Ces éléments conditionnent la suite de la démarche et se vérifient en amont. Un dossier complet se prépare en amont, sans promettre ce qui relève du guichet.
Contexte
Un texte déjà enserré dans un parcours, où chaque mot occupe une fonction précise, voilà sur quoi intervient la traduction technique d'interface utilisateur. Formulé tel quel par un client : « Faut-il une traduction assermentée du document en question ? » La réponse tient à ceci : Quant aux formules imposées par un texte réglementaire, elles se reproduisent mot pour mot, la maquette n'ayant aucun droit sur leur rédaction. notice d'installation, traduction certifiée conforme et traduction technique ne se confondent pas dans l'usage. Le point de méthode : Les principaux destinataires sont le client, l'éditeur de logiciel, l'INPI et l'organisme de certification
Champ documentaire
La page appartient à la conception d'interface et suit les règles communes à cette rubrique. Un cadre, une icône et un verbe d'action suffisent à distinguer l'avertissement d'un simple renseignement, et cette mise en forme se transporte telle quelle. Parmi les demandes reçues, celle-ci revient : « Comment gérer les mises à jour successives du document en question ? » Précision utile : Entre la conception et la recette, l'interface passe par plusieurs mains, et le texte traduit arrive souvent après le gel des écrans. Précision de fond : Le risque est qu'une chaîne d'interface paraphrasée ne corresponde plus au bouton réellement affiché dans le produit Le détail qui compte : la documentation d'installation et le guide d'administration visent deux lecteurs.
Autorités et fondements
Traiter toutes les alertes de la même manière émousse celle qui compte, car plus rien ne signale au lecteur qu'il doit s'arrêter avant d'agir. Les clients demandent régulièrement : « Que faire si le document en question est fourni en scans non modifiables ? » La réponse tient à ceci : Un libellé ajouté à ce stade bouscule l'alignement des composants, ce qui explique pourquoi toute modification de texte se négocie avec l'équipe produit. Le cadre à ne pas perdre de vue : Un même document peut être reçu selon des critères différents en contexte sectoriel et en contexte administratif
Cohérence terminologique
La hiérarchie entre obligation, recommandation et simple renseignement se maintient d'une langue à l'autre, même lorsque la formulation doit raccourcir pour tenir dans le composant. Une interrogation récurrente : « De quoi dépend le prix de la traduction du document en question ? » Pour répondre : Le formulaire long révèle les difficultés propres à ce type de document, car les messages d'erreur s'y enchaînent et chacun doit indiquer le geste à refaire, sans jamais accuser la personne. Un repère stable : Cette famille comprend le cahier des charges technique, la documentation d'API, les chaînes d'interface, le manuel d'exploitation et le brevet
Démarche
On nous écrit souvent : « Comment les schémas et les références sont-ils conservés ? » De fait, Un message qui se contente de dire que la saisie est invalide oblige l'utilisateur à deviner, alors qu'un message qui nomme le champ fautif le remet sur la voie. Un repère stable : Les principaux destinataires sont le client, l'éditeur de logiciel, l'INPI et l'organisme de certification Le cadre se précise : un guide d'installation avec commandes à recopier telles quelles. Une nuance s'impose : des messages système courts, isolés du contexte d'affichage.
Contrôle de qualité
Le doute le plus courant s'énonce ainsi : « Combien de temps faut-il pour traduire le document en question ? » Précision utile : Les textes d'aide contextuelle gagnent à être réécrits plutôt que traduits mot à mot, car leur rôle est de débloquer une situation et non de décrire un mécanisme. Ce que l'on peut affirmer : Le risque est qu'une chaîne d'interface paraphrasée ne corresponde plus au bouton réellement affiché dans le produit Ce second point est distinct : modifier un nom de variable en traduisant la phrase qui l'entoure.
Forme de livraison
Question posée à l'accueil : « Peut-on traduire le document en question dans plusieurs langues à partir d'une base unique ? » Le point à retenir : La documentation et l'interface ne se recouvrent qu'en partie : la première explique un ensemble, la seconde accompagne un geste au moment où il se fait, et cette différence de rôle décide de la longueur admise comme du ton employé. Un repère stable : Un même document peut être reçu selon des critères différents en contexte sectoriel et en contexte administratif
Questions fréquentes
Les clients demandent régulièrement : « Quels fichiers fournir pour traduire le document en question ? » Élément de réponse : Aucune relecture, même attentive, ne dit ce qu'un utilisateur comprend en lisant l'écran : seul un essai avec des personnes extérieures le montre. Ce que l'on peut affirmer : Cette famille comprend le cahier des charges technique, la documentation d'API, les chaînes d'interface, le manuel d'exploitation et le brevet Côté pratique : un texte technique se relit avec le produit ouvert à côté. Point de départ : avant la mise en service d'un produit auprès des utilisateurs.
Pages liées
Question de fond : « Comment traduire les avertissements de sécurité d'une interface sans les banaliser ? » Un avertissement se reconnaît à sa forme avant son contenu : encadré, gras, icône et verbe à l'impératif, et ces marques se conservent dans la version française. Uniformiser tous les messages sur le même ton affaiblit celui qui signale un danger réel. La traduction garde donc la hiérarchie entre l'obligation, la mise en garde et la simple information. Les mentions obligatoires, elles, se recopient sans reformulation, car leur libellé est fixé ailleurs. Font exception les textes d'aide contextuelle, qui gagnent à être réécrits pour tenir dans la zone prévue. Les tests menés avec des utilisateurs révèlent les phrases qui font hésiter, et cette observation ne se remplace pas par une relecture. Les parcours trop longs pour la maquette remontent au concepteur, pas au traducteur. La réponse commence par la question : « Comment faire traduire le document en question sans perdre la mise en page ? » Réponse courte : La livraison prend la forme d'un tableau bilingue aligné sur les identifiants des composants, avec la longueur disponible indiquée pour chaque zone.
Passage à l'action
Avant les exceptions, la règle commune. Le concepteur qui prépare une maquette et la personne qui relit le parcours ne cherchent pas la même chose : l'un veut un texte qui tient dans le cadre, l'autre un enchaînement qui se comprend. Deux vérifications se croisent ici, celle de la place et celle de la logique. Les clients demandent régulièrement : « Une traduction du document en question peut-elle servir de documentation réglementaire ? » Le point à retenir : Les réclamations portent d'abord sur un ton uniformisé, puis sur un avertissement déplacé vers une note de bas de page et un marqueur de sécurité supprimé pour gagner de la place. Un point qui mérite d'être posé explicitement : « Qui peut traduire le document en question avec une compétence technique ? » Sur ce point : La refonte d'un écran reste une décision de conception, et la traduction s'y conforme sans proposer de nouvelle navigation, même lorsqu'elle juge l'enchaînement discutable.
