La localisation devient une compétence d’agent, pas un SDK

Localiser une app signifiait autrefois ajouter un SDK, connecter un provider et gérer les clés manuellement. Avec les agents de code propulsés par l’IA, le chemin est plus court: installez une compétence et l’agent s’occupe de la configuration. globalize.now est une infrastructure de localisation propulsée par l’IA, distribuée sous la forme d’une compétence d’agent open source. Vous exécutez une commande, votre agent lit le playbook et votre codebase adopte une structure prête pour la traduction, sans nouvelle tuyauterie à maintenir.

Qu’est-ce qu’une compétence d’agent ?

Une compétence d’agent est un petit package d’instructions qu’un agent de code lit et exécute. Elle est distribuée via l’écosystème open source des compétences et s’installe avec la CLI skills, par exemple npx skills add owner/repo. La même commande fonctionne avec Claude Code, Cursor, Codex, OpenCode et plus de cinquante autres agents.

La compétence elle-même est un fichier SKILL.md accompagné, le cas échéant, de fichiers de support, et elle est placée dans le répertoire où votre agent cherche déjà ses compétences. La CLI la relie à une copie canonique unique et consigne l’installation dans un lockfile : la compétence est ainsi versionnée avec le reste du projet au lieu de dépendre d’un compte fournisseur. Il existe même un registre public : vous pouvez donc trouver, lire et figer une compétence comme n’importe quelle autre dépendance.

Le changement important à retenir: une compétence n’est pas un produit auquel votre agent s’intègre. C’est un savoir que votre agent assimile, puis applique à votre code. La différence se voit dès que vous accueillez un nouveau membre dans l’équipe. Il clone le repo, la compétence est déjà là et son agent gère votre localisation comme le vôtre.

Pourquoi distribuer l’i18n sous forme de compétence plutôt que de SDK ?

Parce que la difficulté de l’internationalisation, c’est le refactor, et qu’une compétence apprend à votre agent à s’en charger. Un SDK part du principe que votre code est déjà structuré pour la traduction. Vous devez toujours repérer les chaînes codées en dur, définir une convention de clés, créer les fichiers de locales et connecter la bibliothèque de runtime.

Les apps créées avec l’IA aggravent le problème, car les agents de code optimisent pour obtenir un écran fonctionnel, pas pour construire une architecture de traduction. Le résultat est généralement correct, prêt à être livré, et rempli de chaînes comme <button>Submit order</button> au lieu d’un appel utilisant une clé. À l’échelle d’un projet, la localisation devient alors un refactor, pas un simple changement de configuration.

Si vous ne faites rien, le problème s’amplifie. Le même libellé est écrit de trois façons légèrement différentes, les quantités s’affichent comme 1 messages et, lorsque vous ajoutez une première langue, vous découvrez des écrans à moitié en anglais et à moitié dans une autre langue. Une compétence est conçue pour détecter tout cela en une seule passe, avant que le problème ne se transforme en une centaine de petits tickets.

Une compétence encode ce refactor sous forme d’instructions que votre agent peut exécuter. Elle détecte votre framework, confirme le runtime i18n que vous utilisez déjà, comme next-intl ou i18next, extrait les chaînes anglaises et génère les clés ainsi que les fichiers de locales. Vous n’importez pas un nouveau runtime à versionner et à maintenir. La compétence configure le nécessaire, puis s’efface.

Quelle est la différence entre une compétence et un serveur MCP ?

Un serveur MCP est un service appelé par votre agent ; une compétence se résume à des fichiers dans votre projet. Le Model Context Protocol est un bon moyen de fournir aux agents des outils et des données en temps réel via un serveur actif. Mais un serveur doit être hébergé par vos soins ou par un fournisseur, et votre agent dépend de sa disponibilité.

Une compétence ne repose sur aucun service. C’est du texte et du code qui sont livrés dans votre repo, fonctionnent sans appel réseau et apparaissent dans une pull request comme n’importe quelle autre modification. Pour une tâche ponctuelle comme l’internationalisation d’une codebase, des fichiers sont plus pratiques qu’un service à maintenir en ligne. Vous lisez ce que la compétence va faire, vous l’exécutez et vous examinez le diff.

Les compétences se combinent aussi. Vous pouvez en installer plusieurs : elles cohabitent, car chacune n’est qu’un ensemble d’instructions, pas un processus supplémentaire à exécuter et à payer.

Comment globalize.now s’installe-t-il comme compétence d’agent ?

Une commande, puis votre agent prend le relais.

npx skills add globalize-now/globalize-skills --all

L’option --all installe toutes les compétences pour tous les agents de votre machine. C’est le choix par défaut le plus sûr si vous ne savez pas quel agent vous utilisez. La CLI place la compétence globalize.now là où votre agent cherche ses compétences. Elle fonctionne avec l’agent que vous utilisez déjà, notamment Claude Code et Cursor.

Ensuite, demandez à votre agent de configurer l’i18n. Il suit le playbook : détection du framework, confirmation de la bibliothèque de runtime, recherche des chaînes anglaises visibles par l’utilisateur, puis génération des clés et des fichiers de locales. C’est la différence entre l’avant et l’après que les développeurs reconnaissent immédiatement.

// before
<button>Submit order</button>

// after
<button>{t("checkout.submit_order")}</button>

Les clés sont placées dans les fichiers de locales que la compétence crée et maintient pour vous:

/locales
  en.json
  de.json
  es.json
  fr.json

Votre fichier anglais est rempli à partir des chaînes trouvées par l’agent. Les autres langues sont générées et maintenues à jour à chaque push : ajouter un marché revient donc à ajouter un fichier de locale, pas à lancer un sprint.

Après la configuration, les traductions se synchronisent à chaque push Git. Vous n’exportez rien et aucune file d’attente ne reste à vider. Si vous codez votre app à l’instinct avec l’IA, c’est tout le travail. Si vous êtes développeur et voulez les détails, la même compétence exécute proprement le refactor et vous laisse des fichiers de locales standard.

Mes traductions restent-elles dans mon repo ?

Oui. Les fichiers de locales générés par la compétence sont commités dans votre repo comme n’importe quel autre fichier source. C’est le point le plus important pour éviter le lock-in.

Certaines approches déplacent vos chaînes traduites dans une étape de build ou un dashboard hébergé. Le jour où vous partez, votre couche de traduction part avec vous. Avec des fichiers de locales natifs du repo, vos en.json, de.json et les autres sont de simples fichiers dans votre projet. La compétence pourrait disparaître demain : votre app continuerait à livrer toutes les langues qu’elle prend déjà en charge. Partir consiste simplement à ne plus réinstaller la compétence. Rien à migrer, puisque rien de vous n’a jamais été ailleurs. C’est pourquoi globalize.now se situe dans la couche infrastructure de votre stack : il génère les clés et les fichiers de locales au lieu de s’enrouler autour de votre app.

Le modèle des compétences vous enferme-t-il chez un fournisseur ?

Non, et éviter le lock-in est précisément la raison de le préférer. La compétence s’installe depuis un registre ouvert que tout agent pris en charge peut lire, et non depuis une boutique de plugins fermée. Le résultat consiste en fichiers de locales standard pour la bibliothèque de runtime que vous avez déjà choisie, pas en un format propriétaire qu’il faudrait déconstruire plus tard.

Vous pouvez lire exactement ce que fait la compétence avant de l’exécuter, puisqu’il ne s’agit que de fichiers. Si vous voulez le guide complet plutôt que l’argumentaire, le guide comment localiser une app générée par l’IA présente la configuration de bout en bout.