Pourquoi la localisation remonte-t-elle dans la boucle de développement ?

La localisation remonte dans la chaîne parce que l’hypothèse centrale de l’ancien pipeline ne tient plus: le code évoluerait assez lentement pour permettre d’exporter un catalogue de chaînes stable, de le faire traduire ailleurs, puis d’en importer les résultats avant la prochaine release. Les agents de code propulsés par l’IA ont invalidé cette hypothèse. globalize.now est une infrastructure de localisation propulsée par l’IA, conçue pour cette nouvelle position: une localisation qui s’exécute dans la boucle de développement et est livrée sous forme de pull request. Cet essai explique pourquoi c’est la position, et non la qualité de la traduction, qui a changé.

Que signifie faire remonter la localisation dans la chaîne ?

Cela signifie que l’unité de travail de localisation n’est plus un catalogue de chaînes, mais un commit. Dans l’ancien modèle, la localisation commence une fois le code terminé. Dans le modèle upstream, elle se déroule là où vit le code, au moment où il change, et son résultat est du code : une PR localisée que vous pouvez comparer, relire et merger.

Les deux pipelines ressemblent à ceci.

Traditional:   build → internationalize → export → translate → review → import → ship

Upstream:      code → push → localized PR → merge → ship

Le premier pipeline comporte sept étapes et sort deux fois du repo. Le second en comporte cinq, et aucune ne sort du repo. C’est cette différence structurelle, et non une fonctionnalité particulière, qui constitue le sujet de cet essai.

Comment fonctionne le pipeline de localisation traditionnel ?

Il fonctionne en aller-retour, et chaque flèche correspond à une file d’attente. Vous développez la fonctionnalité. Vous l’internationalisez en extrayant les chaînes dans des clés, en supposant que votre équipe ou votre agent d’IA a produit du code structuré dès le départ. Vous exportez le catalogue vers une plateforme de traduction. Des traducteurs ou un moteur de traduction automatique le traitent. Quelqu’un le relit. Vous importez les résultats, résolvez les conflits accumulés pendant l’absence du catalogue, puis vous livrez.

Chaque passage de relais existe parce que le travail se déroule à un endroit différent, est pris en charge par des personnes différentes et suit un calendrier différent. C’était une conception raisonnable quand les releases étaient trimestrielles et que les chaînes évoluaient par lots. La dépendance cachée du pipeline, c’est la stabilité: le catalogue doit rester suffisamment immobile pour permettre l’aller-retour.

Ce n’est plus le cas. Dans le rapport DORA 2025 sur l’état du développement logiciel assisté par l’IA, 90 % des professionnels du logiciel déclarent utiliser des outils d’IA au travail, et l’étude d’impact T4 2025 de DX mesure le code généré par l’IA à 22 % du code mergé dans l’entreprise médiane suivie. Un code qui évoluait autrefois chaque semaine change désormais entre le déjeuner et le daily.

À quoi ressemble la localisation dans la boucle de développement ?

À n’importe quel contrôle automatisé exécuté lors d’un push. Vous convertissez la codebase une fois: chaînes extraites, clés générées, fichiers de locales créés, runtime connecté. Ensuite, la synchronisation s’exécute à chaque push. Lorsqu’un commit introduit de nouvelles chaînes, les traductions reviennent sous forme de pull request contre votre branch, dans votre repo, avec la même structure que le reste de l’app.

Ce débit n’est pas théorique. Lors d’une exécution enregistrée en août 2026 sur un repo de démonstration, un commit poussé est revenu sous forme de PR localisée couvrant 30 unités de traduction en allemand, français et espagnol en 49 secondes. Moins d’une minute entre le commit et une PR prête à relire, sans intervention humaine avant la review. Comparez cela à n’importe quel pipeline qui contient le mot « export ».

Pour être clair, la conversion initiale n’est pas instantanée. Sur de vraies apps, elle prend environ 30 minutes, car elle restructure le code: extraction des chaînes, génération des clés, connexion d’un runtime. C’est la porte d’entrée. La boucle exécutée à chaque push ensuite, c’est le produit.

La propriété importante de cette boucle n’est pas sa vitesse. C’est que rien ne sort du repo. Aucun catalogue ne reste dans une plateforme externe à diverger lentement de main. Le run sur monorepo publié précédemment montrait la conversion initiale à grande échelle ; la boucle maintient ensuite le résultat en vie. Merger ou fermer : les deux mêmes verbes qui régissent toutes les autres modifications. Si vous travaillez déjà ainsi, la documentation développeur présente la configuration.

Pourquoi les agents de code propulsés par l’IA imposent-ils ce changement ?

Parce qu’ils ont déplacé le goulot d’étranglement. En localisation, la contrainte était autrefois la capacité de traduction : la vitesse à laquelle un fournisseur ou un moteur pouvait traiter un catalogue bien structuré. Les agents dépassent largement cette contrainte et en ont créé une nouvelle, en amont. La ressource rare, désormais, c’est la cohérence architecturale après génération : conserver des clés cohérentes, des fichiers de locales complets et une structure intacte pendant qu’un agent ajoute chaque jour de nouvelles interfaces à la codebase.

Un agent à qui l’on demande une page de checkout produit une page fonctionnelle, avec les chaînes codées en dur dans le JSX. Nous avons analysé ce phénomène dans L’IA a cassé la localisation: un projet React étudié contenait 1 284 chaînes d’interface réparties dans 312 fichiers, sans aucune structure i18n. Le catalogue que le pipeline traditionnel veut exporter n’existe pas dans cette codebase. Et la codebase sera encore différente demain, car l’agent continue de livrer.

Un pipeline en aval reste en permanence en retard sur cette réalité. Tout ce qu’il exporte est obsolète au moment de l’import. La seule position depuis laquelle la localisation peut suivre le code généré, c’est à l’intérieur de la boucle qui le génère — que le code provienne de Cursor, Claude Code ou Lovable.

La traduction par IA, ce n’est pas la même chose ?

Non, et c’est là que le discours du marché se trompe. Lokalise se présente comme une plateforme de localisation propulsée par l’IA ; Phrase propose Language AI pour la traduction automatique à grande échelle. Ce sont deux capacités bien réelles. Toutes deux accélèrent une flèche de l’ancien pipeline: l’étape de traduction. Le catalogue est toujours exporté, vit toujours dans une plateforme externe, puis revient toujours via un import.

Accélérer une flèche dans un aller-retour en sept étapes est une optimisation. Supprimer l’aller-retour est un produit différent. C’est la véritable distinction entre les couches: les plateformes conçues autour des workflows de traducteurs occupent la couche de gestion, tandis que globalize.now occupe la couche infrastructure en dessous, en générant les clés et les fichiers de locales directement depuis le code, dans le repo. « Propulsé par l’IA » décrit les deux. Cela ne permet de distinguer ni l’un ni l’autre. C’est la position qui fait la différence.

Qu’est-ce qui doit encore rester en aval ?

Le jugement humain reste indispensable pour les contenus à forts enjeux. Textes juridiques, allégations réglementées, voix de marque sur un marché qui vous tient particulièrement à cœur : ces contenus méritent l’intervention d’un traducteur professionnel et une passe de relecture. Les équipes qui en ont besoin continueront donc d’utiliser des outils conçus autour des workflows de traduction. Rien dans la localisation en amont ne l’empêche : la PR de localisation est une surface révisable, et une personne peut l’évaluer selon les standards de son choix avant le merge.

Ce qui disparaît, c’est l’époque où chaque équipe devait adopter une plateforme centrée sur le workflow des traducteurs simplement pour livrer une deuxième langue. Un développeur solo qui construit une app avec l’IA n’a pas de traducteurs à gérer. Il a des commits. Les outils doivent s’intégrer à ce workflow.

La boucle, c’est le produit

Si votre code est livré par pull requests, vos traductions doivent l’être aussi. globalize.now convertit le codebase une fois, puis le maintient localisé à chaque push : PR ouverte, PR mergée, produit livré.