Comment concevoir un onboarding multilingue dans un SaaS PHP

Un onboarding multilingue dans un SaaS ne consiste pas seulement à traduire les textes du premier écran. L’utilisateur doit pouvoir comprendre chaque étape, conserver ses réponses et terminer son inscription même s’il change de langue ou revient plus tard. Pour y parvenir, il est préférable de séparer la préférence linguistique des données métier et de traiter le parcours comme un processus comportant des états vérifiables.

Ce guide porte sur l’inscription d’une organisation : que présenter avant la création d’un compte, quoi enregistrer pendant le processus et quels tests effectuer pour détecter les défaillances. Il ne vise pas à définir la stratégie générale d’internationalisation de toute l’application.

Séparer la langue de l’interface, le contenu et les données d’inscription

Trois types d’informations peuvent apparaître ensemble dans un formulaire, mais ils ne doivent être ni stockés ni traduits de la même manière :

• Langue de l’interface : elle détermine les libellés, les instructions, les validations et les messages du système. Il s’agit d’une préférence d’expérience, comme es ou fr.
• Contenu du produit : il s’agit de textes gérés par l’entreprise, par exemple la description d’une offre, une catégorie ou un modèle de message de bienvenue. Il peut avoir ses propres traductions et nécessiter une décision distincte.
• Données saisies par l’utilisateur : elles comprennent le nom de l’organisation, un domaine ou une description. Elles doivent être conservées telles que la personne les a saisies, sans être traduites lorsque la langue de l’interface change.

Dans le modèle de données, évitez d’utiliser un seul champ ambigu appelé language pour représenter des notions différentes. Une préférence d’interface peut s’appeler preferred_locale ; la langue d’un contenu géré, le cas échéant, doit être associée à ce contenu. En revanche, le nom d’une organisation ne prend pas une autre valeur lorsque l’interface change de langue.

Cette séparation clarifie également le comportement des sélecteurs. Si l’utilisateur choisit un secteur parmi des options traduites, enregistrez un identifiant stable, et non le libellé affiché. Ainsi, l’option sélectionnée peut être affichée dans une autre langue sans modifier la donnée métier ni dépendre du maintien à l’identique d’un libellé.

Choisir la langue avant la création d’un compte

L’inscription commence souvent avant qu’un utilisateur soit authentifié et qu’une préférence soit enregistrée dans son profil. Le système a donc besoin d’une règle initiale explicite. Il peut proposer un sélecteur visible, utiliser la langue du navigateur comme suggestion ou combiner les deux options. La détection automatique doit aider la personne, et non l’empêcher de choisir une autre option.

Définissez la priorité des différentes indications disponibles. Par exemple, un choix explicite effectué pendant l’inscription devrait prévaloir sur une détection automatique ultérieure. La langue choisie peut être enregistrée temporairement dans la session ou dans l’enregistrement du processus d’inscription ; lors de la création du compte, elle peut être copiée dans la préférence de l’utilisateur. Si l’organisation dispose d’un paramètre de langue distinct, ne le confondez pas avec la préférence personnelle.

Il est également utile de décider ce qui se passe si l’utilisateur arrive depuis un lien d’invitation, reprend une session sur un autre appareil ou revient après une expiration. Documentez la règle de priorité et évitez qu’une requête sans état efface un choix valide. N’enregistrez pas la préférence uniquement dans le navigateur si le processus peut être repris depuis un autre appareil : associez-la à l’état persistant de l’onboarding lorsque cela est approprié.

Définir des états pour changer de langue ou reprendre l’inscription

Représentez l’onboarding comme une séquence d’états, et non comme un ensemble de pages indépendantes. Un enregistrement peut inclure l’étape en cours, les champs déjà renseignés, la langue choisie et l’état du processus d’inscription, par exemple en attente, terminé ou expiré. Une persistance cohérente permet de restaurer le processus sans créer une organisation à chaque rechargement d’écran.

Dans une application PHP, validez côté serveur à la fois l’état du flux et chaque donnée reçue. L’interface peut contrôler la navigation, mais elle ne doit pas être la seule autorité à décider si une étape est terminée. Utilisez des identifiants stables pour les étapes et les options, et gérez les mises à jour de manière à ce qu’une nouvelle tentative ne duplique pas les ressources. Par exemple, une requête répétée visant à créer l’organisation devrait reconnaître le processus existant au lieu de lancer une nouvelle inscription.

Lors d’un changement de langue, affichez à nouveau les libellés et les messages, mais conservez les réponses valides. Si une réponse cesse d’être valide en raison d’une différence réelle entre les règles de différents marchés, expliquez la raison et demandez à l’utilisateur de la corriger ; ne la supprimez pas silencieusement. Le choix de la langue ne devrait pas non plus modifier l’identifiant du processus ni réinitialiser la progression.

Assurer la cohérence des libellés, des validations et des erreurs

La traduction doit couvrir l’ensemble du parcours, et pas seulement les titres. Incluez les libellés, les textes d’aide, les boutons, les états de chargement, les confirmations, les messages de validation et les erreurs récupérables. Si un écran mélange les langues, même si les champs fonctionnent, l’utilisateur risque davantage de mal comprendre ce qu’il doit faire.

Les règles de validation doivent être cohérentes entre le client et le serveur. La règle s’exprime sous la forme d’une condition commune — par exemple, un champ obligatoire ne doit pas être vide — et chaque interface affiche son message dans la langue choisie. Évitez de construire les messages en assemblant des fragments traduits, car l’ordre des mots et la grammaire peuvent varier. Privilégiez des messages complets associés à des clés d’erreur stables.

Séparez le code interne de l’erreur du texte affiché à l’utilisateur. Par exemple, l’application peut renvoyer une clé telle que organization_name_required et la convertir en un message adapté à l’interface. Les journaux techniques peuvent inclure le code et l’identifiant du processus, mais ne doivent pas exposer de données personnelles inutiles ni renvoyer des exceptions internes au navigateur.

En cas d’échec réseau ou d’indisponibilité temporaire d’une réponse, indiquez si les réponses ont été conservées et proposez une action sûre pour continuer ou réessayer. Le message doit être compréhensible et ne pas promettre que les informations ont été enregistrées si le serveur ne l’a pas confirmé.

Tester des parcours complets, et pas seulement les traductions

Les tests doivent couvrir la séquence d’utilisation et les changements d’état. Voici une série de cas pratiques :

• Démarrer l’inscription dans une langue disponible, renseigner plusieurs champs et vérifier que les libellés et les messages s’affichent dans cette langue.
• Changer de langue au milieu du processus et vérifier que les réponses sont conservées, que les options sélectionnées sont traduites et qu’aucune ressource n’est dupliquée.
• Envoyer un formulaire contenant des données non valides et vérifier que les erreurs sont claires, localisées et associées au bon champ.
• Provoquer une défaillance récupérable, réessayer et confirmer quelles réponses ont été conservées et si le processus n’a progressé qu’une seule fois.
• Quitter puis reprendre l’inscription, y compris après une expiration ou depuis une nouvelle session, afin de vérifier la règle de persistance de la préférence.
• Vérifier les valeurs saisies par l’utilisateur et les identifiants des options choisies avant et après un changement de langue.

Automatisez les invariants importants : changer de langue ne doit pas modifier le nom de l’organisation ; reprendre un processus ne doit pas dupliquer le compte ; l’échec d’une validation ne doit pas supprimer les champs valides. Ajoutez des tests d’interface pour vérifier que les textes sont présents et qu’aucune clé de traduction ne reste visible. Les tests manuels restent utiles pour détecter les messages ambigus ou les instructions qui ne tiennent plus dans la mise en page.

Liste de contrôle avant d’activer une autre langue

• Le champ qui représente la langue de l’interface est-il clairement identifié ? Qui peut le modifier ?
• Le choix est-il conservé avant la création d’un compte et lors de la reprise du processus ?
• Les données saisies et les identifiants des options restent-ils intacts lorsque la langue change ?
• Tous les libellés, aides, validations, confirmations et erreurs du parcours sont-ils couverts ?
• Les nouvelles tentatives et les requêtes répétées sont-elles sûres et ne génèrent-elles pas d’inscriptions en double ?
• Les tests vérifient-ils le démarrage, le changement de langue, la reprise et les défaillances récupérables ?

Une inscription multilingue fiable s’obtient en définissant clairement les responsabilités associées à chaque donnée et en vérifiant que l’état résiste aux actions habituelles. Avant d’activer une nouvelle langue, examinez le parcours depuis le premier choix jusqu’à la confirmation : chaque écran doit guider l’utilisateur sans réinterpréter ses données ni lui faire perdre sa progression.