Les meilleurs lancements sur le marché sont ceux dont on oublie qu’ils ont eu lieu.
Pas de course à la traduction de dernière minute et pas de cellule de crise… juste une nouvelle langue mise en ligne à peu près à temps pendant que l’équipe passe déjà à la tâche suivante.
On pourrait appeler ça un non-événement : une localisation qui est livrée sans que personne ne s’en aperçoive. Pour les chefs de produit en charge de produits à vocation mondiale, c’est là l’ambition, et les équipes qui y parviennent sont généralement plus proches du but qu’elles ne le pensent. C’est un peu comme être gardien de but ou batteur : quand on fait bien son travail, personne ne nous remarque. Mais ce qui leur permet d’y parvenir tient moins au budget ou aux outils qu’à la manière dont le processus de localisation a été mis en place dès le départ.
La plupart des équipes commencent par travailler à la main : des fichiers partagés sur Slack, des traducteurs à relancer à travers les fuseaux horaires, ou des passations de relais qui ne tiennent que grâce à la bonne volonté de chacun. Cela fonctionne jusqu’à ce que le produit prenne de l’ampleur et que le nombre de systèmes connectés augmente ; à partir de là, l’approche manuelle commence à montrer ses limites. Ce qui suit met en lumière le fossé entre cette situation et l’absence totale d’événement, à partir d’entretiens menés avec quatre collaborateurs de Phrase qui y travaillent au quotidien.
L’échelle est avant tout un problème de systèmes, et non un problème de langues.
La première chose qu’il convient de remettre en question, c’est l’unité de mesure. Les équipes ont tendance à évaluer l’ampleur d’un projet de localisation en fonction du nombre de langues : cinq, ça semble gérable ; quinze, c’est déjà un projet d’envergure ; vingt-cinq, ça relève d’une tout autre dimension. C’est un mauvais critère.
Comme l’explique Jozsef Hodos, chef de produit senior au sein de l’équipe d’intégrations de Phrase : « L’échelle ne se mesure pas au nombre de langues prises en charge, mais au nombre de systèmes que vous gérez. »
Imaginez une équipe qui gère cinq langues sur une demi-douzaine de systèmes : un CMS, un service d’assistance, une base de code mobile, un outil marketing, un site de documentation. Elle peut avoir une charge de travail plus importante qu’une équipe gérant quinze langues via une seule intégration bien configurée.
Le nombre de langues détermine le volume de traduction. Les systèmes déterminent la charge de maintenance, et cette charge est un coût qui s’accumule jusqu’à ce qu’elle commence à dicter l’ordre du jour.
La question la plus pertinente concerne donc les systèmes, et non les langues : combien doivent communiquer entre eux, et qui est averti lorsqu’un d’eux change ?
Créer des intégrations, c’est facile. C’est leur maintenance qui coûte cher.
Lorsque la localisation manuelle commence à devenir pénible, le réflexe est de créer quelque chose : un connecteur sur mesure, une intégration API point à point, un script qui déplace des fichiers d’un endroit à un autre. C’est tout à fait raisonnable. L’équipe connaît bien sa pile technologique, le problème semble spécifique, et le développement en interne évite de dépendre d’un autre prestataire. La première version fonctionne, et le problème semble résolu. Puis le temps passe.
Ce genre d’intégrations n’est pas difficile à mettre en place, explique Jozsef, qui a passé l’année dernière à travailler précisément là-dessus avec des clients. Le problème survient plus tard : « elles sont extrêmement difficiles à maintenir. » La localisation implique des contraintes auxquelles un développeur ne s’attend pas forcément, comme le comportement de la mise en page dans les scripts de droite à gauche, ou la manière dont le contenu doit être structuré pour rester exploitable dans une mémoire de traduction. Des cas limites qui ne se sont jamais présentés lors des tests apparaissent en production, et comme ces intégrations sont développées une par une, chacune comporte ses propres particularités et nécessite sa propre maintenance.
Les équipes d’infrastructure appellent cela la « maintenance différée » : un coût qui passe inaperçu tant que tout fonctionne, puis se manifeste plus tard sous une forme plus grave.
Les enjeux économiques plus larges viennent renforcer ce phénomène. L’analyse des connecteurs réalisée par Nimdzi a révélé que les intégrations natives sur les dix principales plateformes TMS couvrent moins de 13 % des applications métier couramment utilisées par les entreprises, ce qui laisse le reste à des développements sur mesure. Et c’est dans ces développements sur mesure que se cache le coût. Dans son analyse du marché des TMS pour 2026, Nimdzi met en garde les équipes aujourd’hui tentées de développer leurs propres outils basés sur l’IA : « elles sous-estiment souvent les délais, la complexité et la gestion du changement nécessaires à la création, au lancement et à la maintenance de ces outils. » La première version est rarement la plus coûteuse.
Les intégrations natives nécessitent encore un travail important
L’alternative consiste à utiliser des intégrations natives : des connecteurs gérés pour vous par une plateforme. Cela évite la mise en place et la maintenance, mais soulève une autre question : comment les configurer correctement ?
Il serait encore plus juste de dire : prenez la création automatisée de projets, qui détecte les nouveaux contenus sur une plateforme connectée via une intégration et ouvre automatiquement un projet de traduction. Bien mise en œuvre, cette fonctionnalité rend la localisation presque invisible : le contenu apparaît, un projet s’ouvre, les traductions reviennent. Dans la pratique, Tomáš Doischer, responsable de l’équipe des intégrations chez Phrase, explique que la plupart des configurations nécessitent une deuxième étape pour fonctionner correctement. Chaque environnement est suffisamment différent pour qu’aucun modèle ne s’adapte parfaitement, quelle que soit la compétence de l’équipe.
Il existe une dimension organisationnelle dont on parle trop rarement. Les responsables de la localisation sont des experts en la matière, mais les systèmes auxquels ils se connectent appartiennent généralement à d’autres personnes : le CMS à l’équipe web, le CRM au service commercial et le disque sur lequel le service marketing stocke ses ressources. La mise en place d’une intégration nécessite des identifiants et des droits d’accès qu’un responsable de la localisation ne peut souvent pas accorder seul, ce qui crée des dépendances entre des équipes qui ne travaillent pas ensemble au quotidien.
Quiconque a déjà mené un de ces projets connaît bien ce scénario : la personne qui détient les identifiants ne travaille pas dans la localisation, celle qui est au cœur de la localisation ne dispose pas des identifiants, et l’administrateur qui pourrait faire le lien entre les deux est en congé jusqu’à jeudi. C’est là que réside le véritable travail, et c’est la chose la plus utile à savoir avant de se lancer.
Pourquoi la préparation l’emporte sur la puissance technique
Alejandro Medina, architecte de solutions d’entreprise chez Phrase, a mené suffisamment de projets de ce type pour savoir ce qui distingue les projets qui se déroulent sans heurts de ceux qui s’avèrent pénibles, et ce n’est pas la puissance technique : « Le rôle spécifique ou le parcours technique des personnes impliquées ne détermine pas la réussite. Ce qui compte le plus, c’est de comprendre l’environnement du client et de poser les bonnes questions. »
Il décrit deux équipes dont les configurations étaient quasi identiques. L’une d’elles devait intégrer GitHub à quatre dépôts. Avant toute configuration, ses membres ont lu la documentation et repéré un problème : travailler sur des branches de demande d’extraction dont les noms changeaient à chaque version entrerait en conflit avec la manière dont l’intégration assurait le suivi du contenu. Ils ont donc d’abord repensé le flux de travail, en programmant les importations via l’intégration et en gérant les exportations via GitHub Actions. La deuxième équipe, dont la configuration était presque identique, s’est heurtée au même problème plusieurs semaines après la mise en service. Même intégration, semaine très différente.
Le revers de la médaille d’une bonne définition du périmètre, c’est ce qu’elle rend possible. L’intégration de Figma à Phrase Strings en est un excellent exemple : lorsque les designers créent des clés de traduction dans Figma, l’intégration récupère des captures d’écran et met automatiquement en évidence la position de chaque chaîne. Les traducteurs voient le texte source dans son contexte visuel réel (un bouton ou un écran de paramètres) sans que personne n’ait à le préparer manuellement, et personne n’a à deviner ce que signifie « btn_confirm_2 ». Le contexte accompagne le contenu.
Comme le souligne Francesca Sorrentino, notre directrice de la localisation : « Les intégrations constituent la couche fondamentale. Mais elles ne résolvent pas tous les problèmes dans un cas d’utilisation complet. Les équipes qui réussissent dans ce domaine comprennent à quoi sert l’intégration et s’organisent en conséquence. »
Les équipes qui réussissent ne sont pas nécessairement les plus techniques. Ce sont celles qui comprennent leur propre configuration avant de l’automatiser, et c’est cela, plus que n’importe quel connecteur, qui permet un lancement serein.
Plus les chefs de produit interviennent tôt, moins le problème est important
Les chefs de produit n’interviennent généralement qu’une fois que les choses ont mal tourné. Ils sont alors utiles, car ils sont souvent les seuls à comprendre comment les systèmes s’articulent entre eux et à savoir à quoi sert réellement la fonctionnalité. Mais à ce stade, le périmètre est déjà défini et le moment idéal pour apporter une contribution optimale est déjà passé.
Ce qui change lorsqu’ils interviennent plus tôt, c’est qu’ils détiennent les informations dont la localisation a le plus besoin : ce que fait la fonctionnalité, où son contenu apparaît et quels marchés sont concernés. Ces informations parviennent rarement au service de localisation de manière structurée. Un ingénieur prend en charge un ticket, crée les clés, déploie le code. Le responsable de la localisation reçoit les clés, mais le contexte qui lui permettrait de briefer les traducteurs avant le début du travail a disparu.
Ce contexte manquant fait toute la différence entre un traducteur qui comprend le sens d’une chaîne de caractères et un autre qui doit deviner à partir du nom d’une clé.
Marty Cagan et Bob Baxley, dans un article consacré à la gestion globale des produits publié sur le blog du Silicon Valley Product Group, mettent le doigt sur l’erreur : la localisation est traitée comme une étape en aval plutôt que comme une préoccupation inhérente à la plateforme, un élément à intégrer dès la conception plutôt qu’à ajouter a posteriori. Aude Moras, responsable produit chez Tablecheck, le dit plus crûment : « Il ne faut pas attendre d’être prêt pour le marché pour commencer à penser à la localisation deux semaines avant le lancement. »
Tomáš Doischer (chef d’équipe Intégrations chez Phrase) va dans le même sens. Il explique que l’erreur qu’il constate le plus souvent est que les équipes recréent leur ancien flux de travail dans un nouveau système au lieu de se demander à quoi il servait : « Reproduire votre ancien processus à l’identique dans un nouveau système revient à essayer d’appliquer votre recette de pizza à la préparation de hamburgers. Concentrez-vous sur le problème que le processus existant résolvait. Puis concevez en fonction de ce résultat. »
À mon sens, c’est là que réside la contribution essentielle du chef de produit :
Bien avant que la situation ne devienne critique, il intègre suffisamment tôt le calendrier et le contexte du produit dans la réflexion pour que la localisation soit intégrée dès le départ, plutôt que rajoutée à la va-vite à la fin avec une demande de mise en place à l’international d’ici vendredi.
Voyez cela en pratique :
Les intégrations de Phrase illustrent l’écosystème des connecteurs et le fonctionnement de la création automatisée de projets au sein de celui-ci.
