Comment localiser une app Lovable sans dashboard ?

Pour localiser une app Lovable sans dashboard, gardez chaque élément du workflow dans le repo : des catalogues de messages sous forme de fichiers commités, un fichier de configuration qui définit vos locales et une étape CLI dans votre build pour les compiler. globalize.now est une infrastructure de localisation propulsée par l’IA qui exécute cette boucle pour vous : extraction des chaînes depuis votre codebase, génération des clés et des fichiers de locales, puis synchronisation des traductions à chaque push Git. Aucun élément de la chaîne ne nécessite d’interface web, ce qui compte davantage qu’il n’y paraît lorsque le code est écrit par un agent.

Pourquoi un dashboard casse-t-il un workflow construit avec l’IA ?

Parce que votre agent ne peut pas en ouvrir un. Lovable, Cursor, Claude Code et Copilot travaillent tous sur les mêmes deux surfaces : les fichiers d’un repo et les commandes d’un terminal. Un dashboard n’est ni l’un ni l’autre.

Cet écart relève désormais d’une convention documentée, et non plus d’une préférence. AGENTS.md, le format qui indique aux agents de code comment fonctionne un projet, a été proposé à l’Agentic AI Foundation de la Linux Foundation en décembre 2025, en même temps que le Model Context Protocol. Selon l’annonce de la Linux Foundation, plus de 60 000 projets open source avaient adopté ce format à cette date, avec plus de vingt outils de code assisté par l’IA. Le principe est simple : les instructions du projet doivent se trouver dans un fichier que l’agent peut lire.

L’état des traductions derrière une connexion se situe en dehors de ce principe. Lorsque votre agent ajoute un nouveau bouton à votre app Lovable, il peut ajouter la chaîne. Il ne peut pas ensuite se connecter quelque part pour mettre à jour une grille de traduction. La chaîne est donc livrée en anglais, l’écart s’accumule et vous l’apprenez par un utilisateur en Allemagne.

Il existe un second problème, plus discret. Lorsque les corrections n’existent que dans l’interface d’un fournisseur, le repo n’est plus la source de vérité de ce que dit votre app. Deux sources de vérité, dont une que vos outils ne peuvent pas inspecter : c’est un problème de debugging qui attend simplement sa deadline.

À quoi ressemble concrètement une configuration Lovable sans dashboard ?

Quatre fichiers et une commande dans votre build. Les apps générées par Lovable sont des apps React, soit sur la stack Vite classique, soit sur TanStack Start avec rendu côté serveur. Dans les deux cas, la structure est la même.

1. Définir vos locales dans la configuration. Un seul fichier, commité, sert de liste à toutes les autres couches.

// lingui.config.ts
import { defineConfig } from "@lingui/conf";

export default defineConfig({
  sourceLocale: "en",
  locales: ["en", "de", "es", "fr"],
  catalogs: [
    {
      path: "src/locales/{locale}/messages",
      include: ["src"],
    },
  ],
});

2. Extraire les messages dans des catalogues. lingui extract analyse votre source et écrit un catalogue .po par locale. Il fusionne le résultat avec ce qui existe déjà sur le disque : les traductions existantes survivent à une nouvelle exécution, ce qui permet d’intégrer cette étape à une boucle automatisée sans risque.

npx lingui extract

3. Compiler avant le build. lingui compile transforme les catalogues en modules runtime. Le flag --strict fait échouer le build lorsqu’une traduction manque : un fallback silencieux en anglais en production devient ainsi un build rouge que vous voyez en premier.

{
  "scripts": {
    "build": "lingui compile --strict && vite build"
  }
}

4. Lancer la synchronisation à chaque push. Ajouter une locale doit se résumer à modifier le tableau locales, pas à ouvrir un ticket au support. globalize.now surveille le repo, extrait les chaînes ajoutées par l’agent, génère les clés et les entrées de catalogue pour chaque locale, puis les committe à nouveau. Les catalogues arrivent sous forme de diff dans une pull request, révisable comme n’importe quelle autre modification.

Les guides complets pour chaque stack sont disponibles dans le guide Lovable Vite et le guide TanStack Start.

Que deviennent les traductions gérées dans un dashboard lorsque le fournisseur ferme ses portes ?

Elles partent avec le fournisseur. Ce n’est pas une hypothèse théorique ce mois-ci : Lovalingo, un service de traduction runtime conçu pour Lovable et d’autres apps créées avec des builders IA, fermera le 31 août 2026 à 23 h 59 CEST. Les nouveaux projets et abonnements sont déjà suspendus. La propre page de fermeture de l’entreprise demande aux clients de mettre en place une internationalisation gérée par le projet en parallèle du service avant de le supprimer, puis de vérifier les routes de locales, les fallbacks, les URL canoniques, hreflang et la sortie du sitemap.

C’est un fournisseur qui décrit avec justesse la différence entre louer un workflow et en être propriétaire.

La dernière ligne a une conséquence SEO qui dépasse la question du fournisseur. Les traductions injectées après le chargement ne figurent pas de manière fiable dans le HTML lu par un crawler. Les catalogues compilés dans votre build, si.

Comment vérifier que votre app Lovable ne dépend d’aucun dashboard ?

Trois vérifications, et chacune doit échouer de manière visible.

Vérifier le réseau. Chargez votre app avec les DevTools ouverts, filtrez les scripts et cherchez les requêtes vers le domaine d’un fournisseur de traduction. Si un script tiers doit être chargé avant que votre page allemande s’affiche en allemand, cette page dépend de la disponibilité du service de quelqu’un d’autre.

Vérifier le repo. Pour chaque locale de votre configuration, un fichier de catalogue doit exister sur le disque et être suivi par Git. Exécutez git ls-files "src/locales/**" et comptez. Des catalogues vides ou absents signifient que les chaînes se trouvent ailleurs.

Vérifier le build. Compilez avec --strict dans la CI. Une traduction manquante doit bloquer un déploiement. Si votre build passe alors qu’une locale est incomplète, l’écart apparaîtra sous forme de texte anglais dans une interface non anglophone — c’est le mode d’échec que les utilisateurs décrivent par « le site est cassé ».

Effectuez les trois vérifications sur un déploiement de preview avant de supprimer un fournisseur existant, jamais après. La propre checklist de Lovalingo avant suppression insiste sur le même point : gardez l’ancien service installé jusqu’à ce que le remplacement ait été testé sur de vraies routes de locales. Notre comparatif Lovalingo détaille directement le parcours de migration.

Quelle est la place de globalize.now lorsqu’il n’y a pas de dashboard ?

Dans la couche située entre votre runtime i18n et votre moteur de traduction. Des bibliothèques comme Lingui, i18next et next-intl servent les traductions au runtime. Des moteurs comme DeepL et GPT produisent le texte. globalize.now génère et maintient l’élément intermédiaire : les clés et les fichiers de locales, tenus à jour avec le code.

C’est précisément cette couche qui nécessitait autrefois qu’une personne clique dans une interface. C’est pourquoi supprimer l’interface constitue un changement de workflow, pas une perte de fonctionnalité. La configuration se fait une fois : connectez le repo à globalize.now et la conversion arrive sous forme de pull request. Dans votre éditeur, cette même configuration tient en une commande :

npx skills add globalize-now/globalize-skills

Dans Lovable, la même fonctionnalité s’installe sous forme de compétence dans l’éditeur, afin que l’agent qui construit votre app puisse l’appeler directement. Le forfait Starter coûte 20 € par mois et par espace de travail et inclut 20 € de crédit de traduction par mois — environ 200 000 mots —, puis l’utilisation au-delà est facturée au même tarif par caractère. Aucun frais par siège ni par langue, et 5 € de crédit à l’inscription, sans carte bancaire. Les langues et les projets sont illimités dans un même espace de travail, ce qui compte lorsque vous ajoutez une cinquième locale plutôt qu’un cinquième siège.

Pour en savoir plus sur le workflow global pour les vibe coders et les développeurs, ainsi que sur la configuration spécifique à Lovable, consultez la page d’intégration Lovable.

En bref

Les traductions de votre app Lovable doivent être des fichiers qui vous appartiennent, dans un repo que votre agent peut lire, et compilés par votre propre build. globalize.now maintient ces fichiers à jour à chaque push Git.