Comment définir une intégration de traduction dans une application métier existante
Préparez la traduction dans votre application : contenus, langues, validation, règles sur les données, gestion des erreurs et tests avant le devis.
Commencez par une tâche complète que votre équipe doit réaliser dans une autre langue. Définissez ensuite la place de la traduction dans cette tâche. Cela donne au prestataire logiciel une base plus claire pour son estimation qu’une simple demande d’ajout d’un bouton de traduction.
Le périmètre doit couvrir le texte, les personnes, les données et le résultat. Il doit aussi préciser ce qui se passe si la traduction échoue. Suivez les étapes ci-dessous pour préparer ce périmètre avant de choisir une approche technique.
Choisissez un processus pour la première version
Indiquez d’où vient le texte source et où doit aller la traduction approuvée. Par exemple, un membre du service client peut devoir lire un message reçu et préparer une réponse dans la langue du client. Il s’agit d’un exemple de besoin, pas du récit d’une installation Vavus.
Énumérez chaque étape : ouvrir le message, demander une traduction, lire la source à côté du résultat, modifier la réponse et autoriser son envoi. Décidez si la traduction démarre automatiquement ou seulement lorsqu’un employé la sélectionne.
Limitez le périmètre de la première version. Un écran et une tâche métier clairement définie sont plus faciles à tester que tous les champs de texte d’une application.
Identifiez les contenus et les langues nécessaires
Dressez la liste des champs à traduire. Distinguez les libellés courts, le texte libre, les documents et la parole. Ils peuvent nécessiter des traitements et des tests différents. Listez aussi les champs qui doivent rester inchangés, comme les numéros de commande et les codes produit.
Précisez les langues source et cible, ainsi que les variantes régionales nécessaires. Notez la longueur habituelle des textes et le volume quotidien prévu. Demandez quelles combinaisons de langues et quels formats d’entrée le service proposé prend en charge.
Le contexte peut être important pour les textes courts. L’API de traduction de texte de DeepL accepte par exemple un paramètre de contexte qui peut influencer la traduction sans traduire le contexte lui-même. Sa documentation précise aussi que des entrées de texte distinctes dans une même requête ne partagent pas leur contexte. [1] Votre périmètre doit indiquer d’où viendra le contexte utile.
Définissez la terminologie et la révision humaine
Rassemblez les termes que votre entreprise utilise souvent. Incluez les traductions souhaitées, les noms de produits et les mots qui doivent rester inchangés. Confiez la mise à jour de cette liste à une personne désignée.
Certains services de traduction proposent des glossaires. Google Cloud Translation décrit son glossaire comme un dictionnaire personnalisé qui permet de traduire de façon cohérente les termes propres à un domaine. [2] Vérifiez cette fonction pour vos paires de langues exactes et le service choisi. Un glossaire ne prouve pas que tout le message est correct.
Décidez quels résultats nécessitent une révision par un professionnel linguistique qualifié. Donnez-lui accès au texte source. Prévoyez une étape d’approbation claire avant l’envoi ou la publication de textes destinés aux clients.
Fixez les règles relatives aux données et aux accès
Décrivez les informations traitées par le processus. Utilisez des exemples fictifs pendant les premiers tests. Évitez de copier de véritables dossiers clients dans un essai uniquement pour vérifier qu’un bouton fonctionne.
Demandez où le texte sera traité, ce que l’application conservera, qui pourra le lire et quand il sera supprimé. Incluez les journaux et les sauvegardes dans cette discussion. Vérifiez les conditions actuelles du fournisseur et les contrôles disponibles dans l’offre choisie.
Une interface personnalisée ne rend pas, à elle seule, un service de traduction externe privé ou utilisable hors ligne. Si votre projet exige un traitement local, indiquez cette exigence dès le départ et vérifiez l’ensemble du flux de données par rapport à celle-ci.
Prévoyez les délais et les erreurs
Indiquez le temps de réponse attendu et ce que le personnel doit faire si le service est indisponible. L’application doit afficher un état clair, comme en attente, prêt pour révision ou échec. Conservez le texte original.
Demandez au développeur de distinguer les défaillances temporaires des erreurs qui nécessitent une modification. DeepL documente par exemple des nouvelles tentatives avec délai en cas de dépassement des limites de fréquence, tandis qu’un quota épuisé demande une autre réponse. [3] Les requêtes répétées ne doivent pas créer des actions métier en double, comme envoyer deux fois la même réponse.
Convenez des alertes d’utilisation et de la personne responsable du support. Incluez les frais du service, la maintenance et les modifications futures dans la comparaison des coûts du projet.
Définissez les tests de recette avant le développement
Choisissez des exemples représentatifs pour chaque paire de langues nécessaire. Incluez des messages longs, des caractères inhabituels, des champs manquants et des termes de votre liste approuvée. Testez la tâche complète, depuis l’enregistrement source jusqu’au résultat enregistré ou envoyé.
Fixez des critères vérifiables : les codes produit restent inchangés, une traduction non approuvée ne peut pas être envoyée, une requête en échec est visible et la personne chargée de la révision peut revenir à la source. Faites évaluer le sens et le ton par un professionnel qualifié. Notez les défauts et répétez les mêmes tests après les modifications.
Préparez une demande de devis claire
Transmettez le processus, des exemples de champs, les paires de langues, le volume estimé, les règles sur les données et les tests de recette. Indiquez pour chaque élément s’il est indispensable au lancement ou s’il peut attendre une version ultérieure. Demandez les hypothèses et les exclusions par écrit.
Vavus propose un cadrage écrit pour les projets sur mesure. [4] Décrivez votre application existante et la tâche à améliorer sur la page de demande de devis. L’intégration, le déploiement et les tests proposés doivent être confirmés dans le périmètre de votre projet.