Traiter un utilisateur qui ouvre un ticket dans une autre langue bloque tout le flux : le technicien sélectionne le texte, le colle dans un traducteur externe, revient sur GLPI, répond - et recommence à chaque nouveau suivi. Le module Translate de NexTool supprime ces allers-retours en traduisant la description et les suivis directement dans la chronologie du ticket, à la demande, dans la langue de la session de la personne qui traite.
Le problème
Quiconque exploite un service desk qui traite des clients ou des filiales dans plus d'une langue connaît la scène : le ticket arrive en anglais, en français ou en espagnol, le technicien sélectionne le texte, ouvre un onglet de traducteur, le colle, le lit, revient sur GLPI et rédige la réponse. À chaque suivi du demandeur, le cycle recommence. En plus d'être lent, le processus sort le texte du contexte du ticket - l'historique est fragmenté et la traduction disparaît dès que l'onglet du navigateur est fermé.
La parade habituelle, demander au demandeur d'écrire dans la langue du support, reporte la friction sur le client et dégrade l'expérience dès le premier contact. Pour une équipe qui traite des comptes internationaux, la langue ne devrait pas devenir un obstacle opérationnel à chaque message.
Comment ça marche
Translate reproduit, au sein de l'architecture de modules NexTool, le comportement du plugin de traduction de Teclib - à la différence qu'il ne vous enferme pas dans un seul service. Il agit dans la chronologie du ticket :
- Traduction par élément, à la demande : chaque élément de la chronologie (description, suivi, tâche, validation ou solution) reçoit son propre bouton de traduction. Rien n'est traduit en masse - le technicien ne traduit que ce qu'il a besoin de lire.
- Langue de la session : la traduction sort dans la langue de l'interface de la personne connectée. Une équipe multilingue traite le même ticket, chaque technicien lisant dans sa langue, sans rien reconfigurer.
- Trois fournisseurs, vous choisissez : DeepL, Google Cloud Translation ou IA (un LLM d'OpenAI, Google Gemini ou Anthropic Claude). Le choix porte sur le fournisseur - la langue cible reste celle de la session.
- Cache de traductions : le résultat est stocké et réutilisé. Le même texte n'est pas traduit - ni facturé - deux fois. Le cache respecte la version du contenu : un suivi modifié est retraduit, un suivi inchangé est servi depuis le cache.
- Clés d'API chiffrées : la clé du fournisseur est stockée chiffrée (via GLPIKey de GLPI), pas en clair dans la configuration.
- Périmètre par entité et journaux : vous pouvez restreindre le module à certaines entités (avec héritage vers les entités filles) et suivre ce qui a été traduit, par qui et avec quel fournisseur, avec un niveau de journal ajustable.
- Test de connexion intégré : avant de le mettre à disposition de l'équipe, un bouton valide la clé et le fournisseur configurés.
DeepL, Google ou IA : le choix qui compte
Les trois fournisseurs traduisent bien un texte monolingue. La différence apparaît - et nous l'avons constaté en exploitation quotidienne - dans les tickets multilingues au sein d'un même document, qui sont le cas réel de quiconque reçoit des leads et des formulaires de contact.
DeepL et Google Translate, sur l'API REST avec détection automatique de la source, tranchent pour une seule langue par document. Dans un ticket de lead dont la description est majoritairement en français (les libellés du modèle : "Nom :", "Société :", "Message :") avec le message du client en anglais, le fournisseur détecte le français comme langue dominante, fixe la cible sur le français et renvoie un texte quasi identique - le passage en anglais reste intact. Nous l'avons confirmé avec un ticket de test réel : le document entier était détecté comme FR (sans effet sur l'anglais), tandis que le même passage anglais, isolé, était détecté comme EN et traduit correctement. La colonne de langue source dans le cache du module ne laisse aucun doute.
# Description d'un ticket de lead (libellés en FR + message en EN)
Nom : ...client...
Societe : ...societe anglaise...
Message : Hello, I would like a quote... Thank you.
# DeepL / Google (source=auto) - UNE langue détectée par document
detected_source_language = "FR" -> cible fr -> passage EN NON traduit (no-op)
# Le même passage EN, isolé :
detected_source_language = "EN" -> traduit correctement ("Bonjour... Merci")
# Fournisseur IA (OpenAI / Gemini / Claude) - tout le document comme contexte
-> traduit tout passage hors de la langue cible, sans détection unique
L'enseignement de l'exploitant : pour des clients internationaux et un contenu multilingue au sein d'un même document, le bon fournisseur est l'IA, qui traduit sémantiquement tout passage hors de la langue cible en utilisant l'ensemble du document comme contexte. DeepL et Google restent excellents - et moins chers - pour des tickets rédigés entièrement dans une seule langue. C'est pourquoi le module vous laisse le choix du fournisseur et n'en impose pas un seul.
| Fournisseur | Idéal pour | Document multilingue (libellés + message) | Coût typique |
|---|---|---|---|
| DeepL | Qualité sur les langues européennes, texte monolingue | Détecte 1 langue dominante - le passage minoritaire peut rester non traduit | Par caractère |
| Google Cloud Translation | Large couverture linguistique, haute disponibilité | Même limite de détection unique | Par caractère |
| IA (OpenAI / Gemini / Claude) | Contexte, ton humain et contenu multilingue | Traduit tout passage hors de la langue cible | Par token |
Comment l'activer
- Dans GLPI, ouvrez le plugin NexTool et allez au catalogue de modules.
- Repérez Translate (Traducteur de tickets) et cliquez pour l'activer.
- Ouvrez la configuration du module, allez dans l'onglet Intégrations, choisissez le fournisseur (DeepL, Google ou IA) et collez la clé d'API correspondante - elle est stockée chiffrée.
- Dans l'onglet Test, lancez le test de connexion pour valider la clé avant de la mettre à disposition de l'équipe.
- Si besoin, ajustez le périmètre par entité, la rétention du cache et des journaux, et le niveau de journal. Dès lors, le bouton de traduction apparaît sur les éléments de la chronologie des tickets.
Une routine de nettoyage quotidienne (le cron du module) supprime les journaux et le cache anciens selon la rétention configurée, pour que le module n'accumule pas de données indéfiniment.
À qui s'adresse le module
Translate a du sens pour les service desks qui traitent des clients, des filiales ou des fournisseurs dans plus d'une langue - et surtout pour ceux qui reçoivent des leads et des formulaires de sites internationaux, où le même ticket mélange les langues. Il aide aussi les équipes distribuées, où chaque technicien préfère lire dans sa propre langue.
Quand ce n'est pas utile : si toute l'exploitation et tous les clients utilisent une seule langue, le module n'apporte rien - et vous évitez le coût d'une API de traduction. Si votre politique de données interdit d'envoyer le contenu des tickets à des services externes, évaluez le fournisseur avec soin, car la traduction envoie par nature le texte au fournisseur choisi ; dans ce cas, restreignez le périmètre par entité et traitez le choix du fournisseur comme une décision de confidentialité.
Compatibilité
- GLPI : 11.x, sur le plugin de base NexTool.
- Offre : gratuite - Translate est distribué sans coût de licence via le catalogue de modules NexTool.
- Prérequis externe : une clé d'API du fournisseur choisi (DeepL, Google Cloud Translation ou le LLM d'OpenAI/Gemini/Claude), facturée à l'usage par le fournisseur lui-même.
Étape suivante
Translate fait partie de NexTool. Si votre équipe perd du temps à passer de GLPI aux traducteurs externes à chaque message, contactez l'équipe et nous vous aiderons à choisir le bon fournisseur pour votre scénario.
Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe Nextool Solutions.
