Le mot « fetures » revient régulièrement dans les corpus de traduction automatique anglais-français, et ce n’est jamais bon signe. Ce type de coquille, souvent un résidu de « features » mal corrigé ou mal interprété par un outil de TAO, signale un problème plus profond : l’absence de contrôle terminologique en amont du pipeline de traduction. On observe ce schéma dans la documentation technique de logiciels, d’API et de produits industriels, avec des conséquences sur la qualité perçue et la conformité réglementaire.
Fetures, fonctionnalités, caractéristiques : le piège du terme source ambigu
Le mot anglais « features » pose un problème structurel en traduction technique française. Selon le contexte, il se rend par « fonctionnalités » (logiciel, application web), « caractéristiques » (fiche produit, spécifications serveur), « options » (configuration client) ou même « propriétés » (API, code). Un traducteur généraliste, ou un moteur de traduction non paramétré, choisit un équivalent unique et l’applique partout.
A lire également : Transférer facilement vos photos de Google Photos vers OneDrive
Le résultat : un document où « caractéristiques » apparaît dans une section qui décrit des comportements logiciels, ou « fonctionnalités » dans un tableau de spécifications matérielles. Le lecteur technique repère immédiatement l’incohérence. Pire, la coquille « fetures » passe les filtres orthographiques quand le glossaire du projet ne contient pas le terme source correctement indexé.
Nous recommandons de traiter « features » comme un terme à choix contraint : chaque occurrence doit être désambiguïsée dans le glossaire avant traduction. Trois colonnes suffisent (terme source, contexte d’usage, équivalent français validé). Sans ce travail préalable, chaque traducteur qui intervient sur le projet introduit sa propre logique.
Lire également : Protéger documents: mot de passe sécurisé pour confidentialité
Erreurs de traduction technique dans la documentation API et code
La documentation d’API concentre les erreurs les plus coûteuses parce qu’elle mêle langue naturelle et syntaxe formelle. Un nom de paramètre traduit par erreur casse l’intégration côté développement. Nous avons vu des cas où « endpoint » devenait « point de terminaison » dans le corps du texte mais restait en anglais dans les exemples de code, créant une rupture de compréhension pour le développeur francophone.
Les segments qui posent le plus de problèmes dans ce type de documentation :
- Les messages d’erreur traduits littéralement, qui ne correspondent plus aux codes renvoyés par le serveur et compliquent le débogage côté client
- Les noms de méthodes ou de classes francisés dans le texte explicatif alors qu’ils doivent rester en anglais pour être reconnus dans le code
- Les unités de mesure et formats de date convertis selon les conventions du traducteur plutôt que selon le standard défini dans les spécifications du projet
- Les commentaires inline traduits sans vérifier la cohérence avec le reste de la base de code, ce qui crée des incohérences lors de la maintenance
La règle de base : tout élément qui existe aussi dans le code reste en anglais dans la documentation. Cette convention, pourtant simple, est violée dans la majorité des projets de localisation que nous auditons.
Contrôle qualité des traductions techniques : au-delà de la relecture
La relecture humaine reste nécessaire, mais elle ne suffit pas à détecter les erreurs de traduction technique systémiques. Un relecteur corrige les fautes visibles (« fetures » redevient « features » ou « fonctionnalités »), sans nécessairement vérifier la cohérence terminologique sur l’ensemble du document.
Un processus de tests adapté à la traduction technique repose sur trois mécanismes complémentaires. Le premier est la validation terminologique automatisée : un script compare chaque segment traduit au glossaire du projet et signale les écarts.
Le deuxième est le contrôle de cohérence cross-fichier, indispensable quand la documentation est répartie sur plusieurs livrables (guide utilisateur, aide en ligne, notes de version). Le troisième est la revue par un expert métier qui lit le texte cible sans accès au texte source, pour vérifier que le document fonctionne de manière autonome en français.
Ce dernier point est souvent négligé par les agences de traduction. La revue bilingue classique (source à gauche, cible à droite) favorise la fidélité au texte anglais au détriment de la lisibilité en français. Or le client final ne voit jamais le texte source.
Responsabilité contractuelle et traduction technique : ce qui change depuis l’AI Act
L’adoption de l’AI Act européen en 2024 a modifié le cadre dans lequel opèrent les prestataires de traduction technique. Les systèmes de traduction automatique utilisés dans des secteurs comme la santé ou les infrastructures industrielles sont désormais classés comme systèmes d’IA à haut risque, avec des exigences renforcées en matière de transparence et de contrôle humain.
En parallèle, nous observons depuis quelques années l’apparition de clauses de responsabilité renforcée dans les contrats de prestation linguistique, notamment dans l’aéronautique et le médical. Ces clauses lient explicitement les erreurs de traduction à des obligations d’assurance RC pro et, dans certains cas, à des obligations de mise à jour documentaire en cas d’erreur détectée après livraison.
Pour les donneurs d’ordre, cela signifie que le prix d’une prestation de traduction technique ne se compare plus uniquement au volume de mots. Le coût réel inclut le niveau de contrôle qualité contractuellement garanti et la capacité du prestataire à tracer chaque décision terminologique. Une agence qui propose un tarif au mot sans détailler son processus de validation expose le client à un risque documentaire non couvert.
Pipeline de traduction technique : structurer le projet en amont
La majorité des erreurs de traduction que nous traitons en audit trouvent leur origine dans les premières semaines du projet, quand le glossaire n’existe pas encore et que les premiers fichiers sont traduits sans cadre. Corriger ces erreurs en aval coûte plusieurs fois le prix d’une préparation terminologique correcte.
Un pipeline fonctionnel pour la documentation technique (logiciel, application, produit industriel) suit un ordre précis : extraction terminologique du texte source, validation du glossaire avec l’équipe métier du client, paramétrage de la mémoire de traduction, traduction, contrôle automatisé, revue experte, livraison. Chaque étape produit un livrable vérifiable.
Quand une de ces étapes manque, les « fetures » prolifèrent. Pas parce que le traducteur est incompétent, mais parce que le système ne lui donne pas les moyens de produire un résultat cohérent sur la durée du projet. La qualité d’une traduction technique est d’abord une question d’ingénierie de processus, pas de talent individuel.
