Quatre langues, un CRM : rendre SSCV2 vraiment multilingue

La Suisse compte quatre langues nationales, et un déploiement CRM suisse qui ne parle qu’allemand n’est qu’un demi-déploiement. Nous avons configuré SAP Sales and Service Cloud V2 en allemand, français, italien et anglais sur des projets clients. La plateforme en est capable. Le savoir-faire, lui, est éparpillé, et l’essentiel de ce qui a mal tourné chez nous a mal tourné sur le plan conceptuel, pas technique.

En bref : dans SSCV2, c’est la langue de connexion de la session qui décide de tout, et un rechargement ne la change pas. Libellés de champs et valeurs de code sont deux traductions distinctes. Les mashups ne reçoivent la langue que par un paramètre système lié par mashup et par locataire. La langue doit être active dans le locataire avant que quiconque puisse s’y connecter. Et les quatre langues font partie de la définition du « terminé », vérifiées après une nouvelle connexion.

Règle 1 : la langue de connexion décide

La langue d’affichage d’une session SSCV2 est celle choisie à la connexion, fixée jusqu’à la déconnexion. Pas la langue du navigateur, pas un champ de préférence dans la fiche utilisateur, pas une information du jeton. Une fois ce fait accepté, la moitié des comportements mystérieux disparaît.

Cela a une conséquence sournoise pour les tests. Un collègue change de langue, recharge la page, voit l’ancienne langue et ouvre un ticket. Il faut se déconnecter, se reconnecter, et seulement ensuite juger. Nous avons vu des traductions parfaitement correctes refusées en test à cause d’un simple rechargement.

Règle 2 : la langue doit être active dans le locataire

Avant tout le reste, la langue doit être activée dans le locataire, et définie comme langue de communication. Sinon, personne ne peut la choisir à la connexion et votre recette en français ne peut même pas commencer. La vérification prend une minute et évite une journée de test perdue.

Règle 3 : traduire, c’est deux tâches, pas une

Les libellés de champs et les valeurs des listes de sélection se gèrent séparément, par des services différents. Les libellés passent par l’adaptation linguistique, une entrée par langue. Les valeurs de code ont leurs propres textes par langue. Ne traduisez que les libellés et vos utilisateurs francophones verront un libellé impeccable au-dessus d’une liste de codes techniques bruts.

Deux leçons plus modestes s’y ajoutent. D’abord, lisez avant d’écrire : les locataires réels sont rarement propres ; nous avons trouvé le même libellé vide dans deux langues, avec une faute de frappe dans la troisième et un texte de test dans la quatrième. Ensuite, une traduction renseignée prime sur le libellé par défaut. Un champ mal nommé exige donc rarement une modification irréversible de l’interface ; il lui faut quatre bonnes traductions.

SAP décrit les outils dans la documentation de SAP Sales Cloud V2 ; les services sous-jacents sont répertoriés sur le SAP Business Accelerator Hub.

Règle 4 : les pages intégrées ne connaissent la langue que si vous la leur transmettez

Les mashups, c’est-à-dire les pages intégrées dans le CRM, sont l’endroit où le multilinguisme échoue le plus souvent. L’iframe ne voit pas dans quelle langue tourne la session qui l’entoure. C’est au mashup de la transmettre : dans sa configuration, on lie un paramètre d’URL (chez nous lang) au paramètre système de la langue de connexion et, tant qu’on y est, un paramètre theme au thème système. SAP Learning montre cette liaison dans Configuring a Mashup in SAP Sales Cloud and SAP Service Cloud Version 2.

Deux pièges. La liaison se configure par mashup, pas par page, et les mashups ne voyagent pas avec votre dépôt de code : chaque locataire la demande à nouveau. Et les contournements tentants ne fonctionnent pas. Le champ de langue préférée de la fiche utilisateur est souvent vide et n’agit pas sur la session ; la langue du navigateur est celle du navigateur, pas celle du CRM ; le jeton ne contient pas de langue. Nous avons vu une recherche maison échouer dans les deux sens : un champ vide qui ne renvoie rien, et un champ obsolète qui écrase la bonne langue de session. Prenez la langue que la plateforme vous transmet et gardez les textes avec la page. Pour la manière dont nous construisons ces pages, voyez étendre Sales Cloud V2 avec des applications personnalisées sur SAP BTP.

Règle 5 : les langues font partie du « terminé », pas des retouches

La leçon la plus importante est organisationnelle. Des livraisons sont revenues de la recette client non parce qu’une traduction manquait, mais parce que la traduction était traitée comme une dernière retouche. Notre règle aujourd’hui : rien ne part chez le client avant deux contrôles.

1. Les quatre langues sont présentes pour chaque nouveau libellé, valeur de code et message, y compris les messages d’erreur de la logique de validation personnalisée.
2. Une langue autre que celle par défaut est vérifiée par une personne après une nouvelle connexion, pas après un rechargement, sur chaque écran et mashup modifié.

Chaque contrôle prend une minute, et chacun existe parce que son absence nous a coûté une fois un tour de test supplémentaire. Vérifier tôt coûte moins cher que tester deux fois, surtout en quatre langues.

C’est l’une des lacunes que nous décrivons dans notre évaluation honnête des limites de Sales Cloud V2 : la plateforme prend en charge les langues, mais la discipline de livraison doit venir du projet. C’est aussi une bonne question à poser à chaque partenaire d’une liste restreinte en Suisse, comme nous le suggérons dans notre panorama des cabinets de conseil SAP CX en Suisse.

Les déploiements en quatre langues sont la norme dans nos projets suisses ; notre page sur le conseil SAP CX en Suisse décrit comment nous les livrons.

Si vous exploitez Sales Cloud V2 ou Service Cloud V2 sur un marché multilingue et préférez ces contrôles intégrés à la méthode plutôt que découverts en recette, parlons-en.