Il existe un modèle dans toutes les entreprises qui opèrent au-delà des frontières. La documentation anglaise est solide. La version allemande a trois mois de retard. La version japonaise a été traduite une fois, par un sous-traitant, et personne n'y a touché depuis. La version portugaise brésilienne n'existe pas encore, même si São Paulo est le bureau qui connaît la croissance la plus rapide.
Tout le monde est d'accord pour dire qu'il s'agit d'un problème. Personne n'a de bonne solution. Jusqu'à présent, la localisation a été traitée comme un projet, un effort ponctuel que l'on budgétise, que l'on exécute, puis que l'on néglige tranquillement jusqu'à la prochaine grande révision.
Cette approche ne fonctionne plus. Voici pourquoi, et ce qui, à mon avis, fonctionne réellement.
La traduction n'est pas la localisation
Mettons les choses au clair sur le plan de la terminologie. La traduction consiste à prendre un texte dans une langue et à produire un texte équivalent dans une autre. La localisation consiste à faire fonctionner les connaissances sur un marché spécifique. Ces deux notions se recoupent, mais ce n'est pas la même chose.
Un document traduit se lit correctement. Un document localisé se lit naturellement. Il tient compte du contexte culturel, des réglementations régionales, de l'outillage local et de la manière dont les gens travaillent sur ce marché.
Cette distinction est importante car la plupart des plateformes documentaires traitent la localisation comme une tâche de traduction. Vous écrivez en anglais, vous appuyez sur un bouton et vous obtenez un résultat en français. C'est fait. Sauf que ce n'est pas fait, parce que.. :
- l'équipe française a un processus de déploiement différent que la documentation anglaise ne couvre pas
- Les exigences allemandes en matière de conformité ajoutent une étape d'approbation supplémentaire qui n'existe pas ailleurs.
- Le bureau japonais utilise un outil interne différent pour le même flux de travail.
- Les lecteurs brésiliens portugais ont besoin d'un contexte sur les règles fiscales locales qui n'est pertinent nulle part ailleurs.
**Une traduction directe du document anglais est techniquement correcte dans tous ces cas, et pratiquement inutile dans tous les cas également.
Le problème de la traduction au niveau du document
La localisation traditionnelle fonctionne au niveau du document. Vous avez un document en anglais. Vous le traduisez entièrement en allemand. Lorsque la version anglaise change, vous envoyez l'ensemble du document pour qu'il soit retraduit. Cela pose trois problèmes :
1. C'est coûteux
Si votre guide d'accueil comporte 15 sections et que vous modifiez un paragraphe, vous devrez retraduire les 15 sections. Multipliez ce chiffre par 8 langues et chaque modification devient une question de budget.
2. C'est lent
Envoyer des documents complets à traduire prend du temps. Même avec une traduction automatique moderne, le cycle de révision d'un document complet est beaucoup plus long que la révision d'une seule section modifiée. Les équipes travaillant dans d'autres langues sont toujours en retard.
3. Il ne prend pas en charge le contenu unique
Il s'agit là d'un véritable fléau. Si la version allemande a besoin d'une section supplémentaire sur la conformité à la directive DSGVO, où va-t-elle aller ? Dans un système de traduction au niveau du document, tout contenu ajouté à la version allemande est écrasé la prochaine fois que quelqu'un retraduit à partir de l'anglais. L'équipe allemande apprend vite : n'ajoutez rien, car cela sera effacé.
Localisation au niveau des blocs : une architecture différente
Rasepi ne traduit pas des documents. Il traduit des blocs : des paragraphes, des titres et des sections individuels, chacun étant suivi indépendamment avec sa propre identité et son propre hachage de contenu.
Voici ce que cela signifie en pratique :
Lorsque vous modifiez un seul paragraphe en anglais, Rasepi détecte quel bloc a changé en comparant les hachages de contenu SHA256. Seul ce bloc est envoyé à la traduction via DeepL. Les 14 autres blocs du document restent inchangés. Vos coûts de traduction diminuent ainsi de 94 %.
Lorsque le traducteur allemand doit ajouter une section DSGVO, il l'ajoute en tant que nouveau bloc dans la version allemande. Ce bloc n'existe qu'en allemand. Il n'affecte pas la source anglaise. Il n'est pas écrasé lorsque l'anglais change. Il est signalé comme un contenu unique, de sorte que tout le monde sait qu'il est intentionnel.
Lorsque la version japonaise a besoin d'une structure différente, par exemple une liste numérotée au lieu de puces parce que c'est la convention dans la rédaction technique japonaise, le traducteur peut changer le type de bloc. Le système enregistre cette modification comme une "adaptation de la structure" et la conserve dans les mises à jour ultérieures.
Chaque version linguistique devient un document de premier ordre, et non une copie fantôme.
Comment ça marche, techniquement
Chaque bloc dans Rasepi a :
- Un UUID qui persiste à travers toutes les éditions et traductions
- Un hachage du contenu** (SHA256) qui change lorsque le texte est modifié.
- un index de position** pour que les blocs restent dans le bon ordre
- Un drapeau de suppression douce** pour que la suppression d'un bloc en anglais ne rompe pas l'alignement dans d'autres langues.
Lorsqu'un bloc de traduction est créé, il stocke le hachage du contenu du bloc source. À chaque enregistrement, le système compare les hachages. S'ils correspondent, la traduction est en cours. Dans le cas contraire, la traduction est marquée comme périmée et seul ce bloc spécifique doit être pris en compte.
C'est ce mécanisme qui permet de réduire les coûts de 94 %. La plupart des révisions modifient une ou deux sections. Le reste du document, toutes langues confondues, reste inchangé.
Contenu unique par langue
C'est ici que les choses se différencient véritablement des autres plateformes.
Dans Rasepi, chaque version linguistique peut contenir :
- Blocs traduits. Traductions directes de la langue source, contrôlées pour éviter qu'elles ne deviennent obsolètes.
- Blocs uniques : contenu qui n'existe que dans cette langue, ajouté par l'équipe locale.
- Blocs adaptés à la structure : même contenu source, formatage ou type de bloc différent.
Un document unique peut ressembler à ceci d'une langue à l'autre :
| Blocs : anglais (source) | allemand | japonais | anglais (source) | anglais (source) |-------|------------------|--------|----------| | 1 | Introduction | Traduit | Traduit | Traduit | Traduit | 2 | Étapes de la mise en place | Traduit | Structure adaptée (liste numérotée) | | 3 | - | Conformité DSGVO (unique) | - | | 4 | Déploiement | Traduit | Traduit | Traduit | Traduit | 5 | - | - | Note sur l'outillage local (unique) | | 6 | Dépannage | 6 | Dépannage | Traduit | Traduit | Traduit | Traduit | Traduit
Chaque équipe reçoit exactement la documentation dont elle a besoin. Pas de compromis. Pas de solutions de contournement. Pas de limitations à taille unique.
Suivi de la fraîcheur dans toutes les langues
Chaque version linguistique suit sa propre fraîcheur de manière indépendante. La source anglaise peut obtenir un score de 94 (revue récente, tous les liens sont valides, le nombre de lecteurs est élevé). La version française peut obtenir un score de 71 (deux blocs périmés, un lien brisé spécifique au contenu français). La version japonaise peut obtenir un score de 88 (toutes les traductions sont à jour, mais le nombre de lecteurs est en baisse).
Ce suivi de la fraîcheur par langue signifie :
- Vous savez exactement quelles sont les langues qui ont besoin d'attention
- Les traductions périmées sont remontées à la surface automatiquement et ne sont pas découvertes par hasard.
- Les outils d'intelligence artificielle peuvent tenir compte de la fraîcheur spécifique à la langue lorsqu'ils fournissent des réponses.
- Les tableaux de bord montrent l'état du contenu par langue, et pas seulement par document.
L'analyse de rentabilité
Les entreprises qui opèrent dans plusieurs langues sont confrontées à une réalité simple : leur documentation est soit un atout, soit un handicap sur chaque marché qu'elles desservent.
Lorsque votre équipe de Berlin travaille à partir d'une traduction allemande qui a trois mois de retard sur la source anglaise, elle prend des décisions basées sur des informations obsolètes. Lorsque votre bureau de Tokyo ne peut pas ajouter de contexte local aux documents partagés parce que le système de traduction l'écraserait, il cesse d'utiliser le wiki et crée sa propre documentation parallèle. Lorsque l'équipe de São Paulo ne dispose d'aucun document en portugais, l'intégration prend deux fois plus de temps.
Le coût ne se limite pas aux frais de traduction. Il s'agit de :
- une intégration plus lente sur les marchés non anglophones
- La duplication des efforts** lorsque les équipes maintiennent une documentation parallèle dans les outils locaux
- Les silos de connaissances** qui se forment lorsque le wiki officiel ne sert pas à tout le monde.
- Risque de non-conformité** lorsque les exigences spécifiques à une région ne sont pas prises en compte
- Perte de confiance** dans le système de documentation lui-même
La localisation au niveau des blocs résout tous ces problèmes, non pas en rendant la traduction moins coûteuse (bien que ce soit le cas), mais en faisant de chaque version linguistique un document vivant, tenu à jour et digne de confiance.
Pour commencer
Si vous dirigez aujourd'hui une équipe multilingue sur une plateforme de documentation quelconque, voici un rapide examen de conscience :
- **Choisissez votre document le plus important et vérifiez-le dans chaque langue. Chaque version est-elle à jour ?
- **Interrogez vos équipes non anglophones : **Font-elles confiance aux documents traduits ? Les utilisent-ils ?
- **Les équipes maintiennent-elles des wikis locaux, des pages Notion ou des messages épinglés sur Slack parce que la documentation officielle ne les sert pas ?
- Calculez vos dépenses de traduction. Combien payez-vous par mise à jour, et quelle part de ce montant est consacrée à la retraduction de contenus qui n'ont pas changé ?
Si vos réponses vous mettent mal à l'aise, vous n'êtes pas seul. La plupart des entreprises ne découvrent les lacunes que lorsqu'elles causent un véritable problème : une question de conformité, un déploiement raté, un nouvel employé qui a passé deux semaines à suivre des instructions obsolètes.
Les connaissances multilingues ne sont pas un luxe. Pour toute entreprise qui opère au-delà des frontières, c'est la base de l'alignement des équipes, de la prise de décision et de l'expédition. La question est de savoir si votre plateforme de documentation la traite de la même manière.
Chaque langue mérite d'être un citoyen de première classe dans votre base de connaissances. Pas une copie. Pas une ombre. Un document réel, entretenu et fiable.
C'est ce que propose Rasepi. Traduction au niveau du bloc, contenu unique par langue, suivi indépendant de la fraîcheur et réduction de 94 % des coûts de traduction. Tout est automatique. Et ce, dès le premier jour.