Un product tour rédigé en anglais et montré à un utilisateur qui travaille en allemand n'est pas un tour à moitié utile. C'est une interruption. L'utilisateur le ferme et, comme la plupart des parcours d'onboarding ne se déclenchent qu'une fois, il ne reverra jamais ce guidage, dans aucune langue.
La plupart des produits SaaS localisent l'interface bien avant la couche d'onboarding, ce qui donne un résultat étrange : une application entièrement traduite, enveloppée d'infobulles en anglais. C'est un écart peu coûteux à combler et coûteux à laisser ouvert, car l'onboarding est la seule partie du produit où la compréhension n'est pas facultative.
Ce guide explique comment choisir les langues à prendre en charge, comment détecter la bonne, quels problèmes d'interface précis la traduction crée dans les infobulles et les modales, et comment éviter que le guidage localisé ne prenne du retard.
L'expansion du texte est le défaut qui apparaît en production plutôt qu'en relecture.
Points clés
- Un onboarding non traduit est pire que pas d'onboarding. Un tour fermé revient rarement : une mauvaise première impression vous coûte tout le parcours.
- Suivez le réglage de l'utilisateur, pas celui du navigateur. La langue choisie dans le produit l'emporte toujours sur la langue déduite.
- Prévoyez 35 % de largeur de plus que l'anglais. L'allemand et le finnois cassent régulièrement les mises en page conçues pour des textes anglais.
- Traduisez aussi la logique de déclenchement. Les sélecteurs d'éléments et les URL de pages diffèrent souvent d'une langue à l'autre, ce qui casse les tours sans bruit.
- Les captures d'écran doivent aussi être localisées. Une infobulle traduite qui pointe vers une capture en anglais est plus déroutante que l'une ou l'autre seule.
- Versionnez la source, pas les traductions. Chaque modification en anglais doit invalider ses traductions, sinon vos langues divergent en silence.
Pourquoi un onboarding localisé compte plus qu'une interface localisée
Un utilisateur expérimenté peut naviguer dans une interface en partie en anglais en reconnaissant la mise en page et les icônes. Un nouvel utilisateur en est incapable, car il n'a encore aucun modèle mental du produit, et l'onboarding est précisément le moment où chaque mot porte tout le poids.
Il en découle trois conséquences, qui s'additionnent :
- La fermeture est définitive. Les parcours d'onboarding ne s'affichent généralement qu'une fois. Un utilisateur qui ferme un tour incompréhensible ne l'a pas reporté : il l'a perdu.
- La charge du support se déplace. Les questions auxquelles le guidage in-app aurait répondu arrivent dans un canal où elles coûtent de l'argent réel, et souvent dans une langue que votre équipe support ne couvre pas non plus.
- Vos données d'activation vous mentent. Les écarts d'activation régionaux sont attribués au product-market fit ou au prix, alors que la vraie cause est que la moitié du marché a été accueillie dans une langue qu'elle n'utilise pas pour travailler.
Le diagnostic à faire avant tout le reste : segmentez les taux d'activation et de complétion de l'onboarding par langue d'utilisateur. Si vos segments non anglophones sont loin derrière alors que leur engagement dans le cœur du produit est comparable, vous avez un problème de localisation plutôt qu'un problème de marché, et il coûte bien moins cher à résoudre.
Choisir les langues à prendre en charge
Localiser l'onboarding n'est pas gratuit : chaque langue multiplie le coût de maintenance de chaque parcours. La décision doit reposer sur les données, pas sur l'ambition.
| Signal | Ce qu'il faut regarder | Pourquoi c'est important |
|---|---|---|
| Base d'utilisateurs existante | Répartition linguistique des comptes actifs | Les gains les moins chers viennent des utilisateurs que vous avez déjà et que vous servez mal. |
| Écart d'activation | Taux de complétion par segment de langue | Désigne la langue où la localisation change le plus les comportements. |
| Concentration du chiffre d'affaires | ARR par région | Un petit nombre d'utilisateurs peut peser un chiffre d'affaires disproportionné. |
| Charge du support | Volume de tickets par compte et par région | Beaucoup de tickets et peu d'engagement avec le guidage : c'est un signal de traduction. |
| Pipeline commercial | Contrats bloqués par des exigences linguistiques | Sur certains marchés, les acheteurs grands comptes en font une exigence d'achat. |
Une règle de priorisation pragmatique : commencez par les deux langues où vous avez déjà des utilisateurs, pas par les dix où vous espérez en avoir. Le coût de maintenance de la localisation de l'onboarding s'accumule, et un duo bien entretenu vaut mieux que six langues qui deviennent obsolètes en un trimestre.
Comment détecter la bonne langue
Se tromper de détection annule tout le travail de traduction : un utilisateur francophone à qui l'on montre un guidage en allemand est plus mal loti que s'il le voyait en anglais. Suivez cet ordre de priorité :
Une préférence de langue explicite dans le profil de l'utilisateur
La langue dans laquelle l'interface de l'application s'affiche actuellement
La langue par défaut du compte ou de l'espace de travail
La langue du navigateur, en dernier recours
Une langue de repli définie, jamais un écran vide
Pourquoi la langue du navigateur est un mauvais signal principal
La langue du navigateur reflète l'endroit où la machine a été configurée, pas la façon dont la personne travaille. Les développeurs et les salariés de groupes internationaux utilisent couramment un système en anglais tout en travaillant dans une autre langue, et les postes partagés ou installés à partir d'une image d'entreprise affichent une langue que personne n'a choisie. Si votre produit a déjà un réglage de langue, c'est lui la réponse : il exprime une préférence explicite plutôt qu'une déduction.
Définissez toujours une langue de repli
Un utilisateur dont la langue n'a pas de traduction doit voir la langue de repli, pas une infobulle vide ni une clé de traduction brute. Choisissez la langue de repli délibérément et assurez-vous qu'une chaîne manquante ne puisse jamais s'afficher comme un vide : un blanc silencieux est bien plus difficile à repérer en test qu'une chaîne visiblement en anglais au milieu d'un parcours en français.
Les problèmes d'interface que crée la traduction
Localiser l'onboarding n'est pas qu'une affaire de contenu. Les couches de guidage sont ancrées à une interface vivante, et la traduction modifie cette interface.
1. L'expansion du texte casse les mises en page fixes
Traduits depuis l'anglais, l'allemand et le finnois sont couramment 30–35 % plus longs, le français environ 20–25 %. Une infobulle dimensionnée pour « Save changes » tronquera « Änderungen speichern ».
Rédigez les textes d'onboarding en fonction de votre langue la plus longue, laissez les conteneurs grandir verticalement et ne fixez jamais la hauteur d'une infobulle. La discipline associée consiste simplement à écrire des textes source plus courts : les mêmes règles de microcopie qui rendent un guidage anglais efficace lui permettent de survivre à la traduction.
2. Les positions des éléments et les sélecteurs bougent
C'est le défaut qui passe le plus souvent inaperçu. Les tours s'ancrent à des éléments précis, et si un sélecteur dépend du texte visible (un libellé de bouton, un libellé ARIA, un attribut data dérivé du texte), il ne correspondra plus dans une autre langue. Le tour pointe alors dans le vide ou ne démarre pas, sans aucun message.
Ancrez-vous à des attributs stables et indépendants de la langue, comme des ID ou des attributs data dédiés, et testez chaque tour dans chaque langue au lieu de supposer que la chaîne traduite est la seule différence.
Chaque étape d'un tour est ancrée à un élément vivant, exactement ce que la traduction déplace.
3. Les captures d'écran et les vidéos doivent aussi être localisées
Une infobulle traduite qui pointe vers une capture en anglais est plus déroutante qu'une infobulle anglaise pointant vers une capture anglaise, car les deux se contredisent désormais. Localisez les images ou concevez un guidage qui n'en dépend pas ; pour les premières tâches, un walkthrough interactif dans l'interface réelle, déjà traduite, contourne complètement le problème.
4. Les formats et les conventions diffèrent
Les dates, les nombres, les devises et l'ordre des noms varient tous. Un texte d'onboarding qui dit « saisissez la date au format MM/JJ/AAAA » est faux dans la majeure partie du monde. Faites référence au format que le produit affiche réellement pour cette langue plutôt que de coder un exemple en dur.
5. La lecture de droite à gauche est un changement de mise en page, pas une traduction
L'arabe et l'hébreu inversent toute la mise en page : ancres des infobulles, sens des flèches, indicateurs de progression et signification de « suivant ». Si le RTL figure sur votre feuille de route, vérifiez que votre couche de guidage gère le changement de sens avant de vous engager ; l'ajouter après coup est nettement plus difficile que traduire.
Empêcher l'onboarding traduit de pourrir
L'échec prévisible ne vient pas de la traduction initiale. Il arrive au septième mois, quand le parcours anglais a été modifié quatre fois et que la version allemande décrit toujours un écran qui n'existe plus.
Les quatre habitudes qui empêchent la dérive
- Traitez une seule langue comme source de vérité. Toutes les modifications s'y font ; les traductions en découlent. Modifier les langues indépendamment garantit la divergence.
- Versionnez le texte source. Quand la source change, ses traductions sont automatiquement marquées comme obsolètes ; ce seul mécanisme évite l'essentiel de la dérive.
- Intégrez la localisation à la checklist de mise en production. Une fonctionnalité n'est pas livrée quand le tour anglais est en ligne ; elle l'est quand chaque langue prise en charge l'est aussi.
- Relisez dans l'interface réelle, pas dans un tableur. Un traducteur qui travaille à partir d'une liste de chaînes ne peut pas voir qu'un bouton est désormais trop étroit de 40 pixels.
Ce qu'il faut traduire, et ce qu'il ne faut pas traduire
✅ À traduire
- Tous les textes des infobulles, modales et checklists
- Les libellés de boutons et de CTA
- Les questions d'enquête et les options de réponse
- Les titres et le contenu des annonces
- Les textes des états vides
- Les messages d'erreur et de validation dans les parcours guidés
❌ À laisser tel quel
- Les noms de produits et de fonctionnalités que vous n'avez pas localisés dans l'interface
- Les sélecteurs d'éléments et les identifiants internes
- Les noms de segments et les libellés internes des parcours
- Tout ce qui renvoie à un libellé d'interface non traduit
- Les exemples de code et les références d'API
La règle de cohérence : le texte de guidage doit employer exactement les mots de l'interface dans cette langue. Si votre interface allemande affiche un bouton « Speichern », l'infobulle allemande doit dire « Speichern », pas un synonyme qu'un traducteur a préféré. Un guidage qui nomme une commande autrement que la commande elle-même est pire que pas de guidage du tout, car l'utilisateur se met à chercher quelque chose qui n'existe pas.
Gérer un onboarding multilingue avec Kompassify
Si la localisation de l'onboarding est repoussée, c'est généralement parce qu'elle implique un projet d'ingénierie de plus. Une couche de guidage no-code change la donne : les parcours et leurs traductions vivent en dehors du code, donc ajouter une langue ne demande pas de mise en production.
- Un parcours, plusieurs langues. Créez un product tour une seule fois et maintenez ses traductions à côté, pour que la logique ne diverge jamais d'une langue à l'autre.
- Ciblage selon la langue. Servez la bonne version en fonction de la langue du produit de l'utilisateur plutôt qu'en devinant à partir du navigateur.
- Checklists et infobulles localisées, pour que toute la couche d'onboarding parle une seule langue, et pas seulement l'essentiel.
- Annonces traduites, pour que les lancements de fonctionnalités arrivent sur tous les marchés en même temps.
- Analytics par langue, pour vérifier que le parcours localisé a réellement comblé l'écart de complétion.
Kompassify est une plateforme d'adoption digitale no-code pour les équipes SaaS. Gratuit jusqu'à 100 utilisateurs actifs mensuels, offres payantes à partir de $129/mois, conforme au RGPD et hébergé dans l'UE.
Accueillez chaque utilisateur dans sa propre langue
Créez le parcours une seule fois, maintenez ses traductions à côté et servez automatiquement la bonne version, sans mise en production.
Commencer gratuitement →Questions fréquentes
Pourquoi localiser l'onboarding si l'interface l'est déjà ?
Parce que l'onboarding est le moment où chaque mot porte tout le poids. Un utilisateur expérimenté peut naviguer dans une interface en partie en anglais en reconnaissant la mise en page et les icônes, mais un nouvel utilisateur n'a encore aucun modèle mental du produit. Pire, les parcours d'onboarding ne s'affichent généralement qu'une fois : un utilisateur qui ferme un tour incompréhensible ne l'a pas reporté, il l'a perdu définitivement.
Dans quelles langues localiser mon onboarding en premier ?
Commencez par les langues dans lesquelles vous avez déjà des utilisateurs plutôt que par les marchés que vous espérez conquérir. Regardez la répartition linguistique des comptes actifs, l'écart d'activation par segment de langue, la concentration du chiffre d'affaires par région et le volume de tickets de support. Chaque langue supplémentaire multiplie le coût de maintenance : deux langues bien entretenues valent mieux que six qui deviennent obsolètes en un trimestre.
Comment détecter la langue à afficher ?
Suivez cet ordre de priorité : une préférence de langue explicite dans le profil de l'utilisateur, puis la langue dans laquelle l'interface de l'application s'affiche actuellement, puis la langue par défaut du compte ou de l'espace de travail, et seulement ensuite la langue du navigateur. La langue du navigateur est un mauvais signal principal, car elle reflète la configuration de la machine, pas la façon dont la personne travaille. Définissez toujours une langue de repli, pour qu'une traduction manquante affiche un texte lisible plutôt qu'une infobulle vide ou une clé brute.
Qu'est-ce qui casse quand on traduit un guidage in-app ?
Cinq choses. L'expansion du texte, puisque l'allemand et le finnois sont généralement 30 à 35 % plus longs que l'anglais et tronquent les infobulles à largeur fixe. Les sélecteurs d'éléments qui dépendent du texte visible, qui ne correspondent plus dans les autres langues et cassent les tours sans bruit. Les captures d'écran qui montrent encore l'interface anglaise. Les conventions de date, de nombre et de devise citées dans les textes. Et les langues qui s'écrivent de droite à gauche, qui inversent toute la mise en page au lieu de simplement changer les mots.
Quelle marge prévoir pour les textes d'onboarding traduits ?
Prévoyez environ 35 % de largeur en plus par rapport à la version anglaise, ce qui couvre l'allemand et le finnois, les langues qui s'allongent le plus. Le français est généralement 20 à 25 % plus long. Rédigez les textes en fonction de la langue la plus longue que vous prenez en charge, laissez les conteneurs grandir verticalement et ne fixez jamais la hauteur d'une infobulle. Écrire des textes source plus courts reste la parade la moins chère.
Comment éviter que l'onboarding traduit ne devienne obsolète ?
Quatre habitudes évitent presque toute dérive. Traitez une seule langue comme source de vérité, pour que toutes les modifications s'y fassent. Versionnez le texte source, afin que toute modification marque automatiquement ses traductions comme obsolètes. Intégrez la localisation à la checklist de mise en production : une fonctionnalité n'est pas livrée tant que chaque langue prise en charge n'est pas en ligne. Et relisez les traductions dans l'interface réelle plutôt que dans un tableur, car un traducteur qui travaille à partir d'une liste de chaînes ne peut pas voir qu'un bouton est désormais trop étroit.
Que ne faut-il pas traduire dans les parcours d'onboarding ?
Les noms de produits et de fonctionnalités que vous n'avez pas localisés dans l'interface, les sélecteurs d'éléments et les identifiants internes, les noms de segments et les libellés internes des parcours, les exemples de code et les références d'API, et tout ce qui renvoie à un libellé d'interface lui-même resté non traduit. La règle qui prime est la cohérence : le texte de guidage doit employer exactement les mots de l'interface dans cette langue, car une infobulle qui nomme une commande autrement que la commande elle-même envoie les utilisateurs chercher quelque chose qui n'existe pas.
Faut-il un travail d'ingénierie pour localiser des product tours ?
Non, si la couche de guidage vit en dehors de votre code. Si la localisation de l'onboarding est souvent repoussée, c'est qu'elle est traitée comme un projet d'ingénierie de plus. Avec une plateforme d'adoption digitale no-code, les parcours et leurs traductions sont maintenus côte à côte : ajouter une langue ne demande pas de mise en production et la logique ne peut pas diverger d'une langue à l'autre.