Pourquoi le contenu multilingue a sa place dans git

La plupart des sites multilingues se retrouvent avec trois sources de vérité : le contenu dans un CMS hébergé, les traductions sur une plateforme dédiée et le code dans git. Chacune a son propre versionnage, son propre contrôle d'accès et sa propre définition de ce qui est « actuel ». Les garder synchronisées est un travail à plein temps, et la divergence est la norme.

Il existe un modèle plus simple : tout mettre dans le dépôt.

Ce que git résout déjà

Votre flux de travail de code gère déjà les problèmes complexes de la gestion de contenu :

• Révision. Une modification de contenu est une pull request. Quelqu'un lit le diff avant le déploiement.
• Restauration. Une mauvaise modification se règle avec un revert, pas avec un ticket de support.
• Atomicité. Le contenu et le code qui l'affiche sont déployés ensemble. Une modification de schéma et la migration de contenu associée sont regroupées dans un seul commit.
• Historique. git log répond à la question « qui a modifié cela et quand » sans aucun plugin.

Un CMS basé sur des fichiers bénéficie de tout cela d'office. La question est de savoir ce qui se passe quand on multiplie chaque page par dix langues.

Le problème de la traduction

L'approche naïve consiste à avoir un fichier par langue : about.en.mdx, about.fr.mdx, about.ja.mdx. Cela s'effondre rapidement. Avec dix langues, un site de 50 pages se transforme en 500 fichiers, la révision devient impossible pour les langues que personne ne parle dans l'équipe, et il n'y a aucun moyen de savoir si about.fr.mdx reflète le texte anglais actuel ou la version d'il y a trois mois.

Scribe sépare les deux aspects :

• Le contenu en anglais correspond aux fichiers MDX. Un fichier par document, validé par un schéma Zod. C'est la partie que les humains écrivent et révisent.
• Les traductions vivent dans un seul fichier SQLite, commité à côté d'eux. Chaque traduction est liée au hash de sa source anglaise, avec un instantané de ce à quoi ressemblait cette source.

C'est ce hash qui empêche toute divergence. Modifiez un paragraphe en anglais et un document, et un seul, devient obsolète de façon visible dans chaque langue. Lancez scribe translate et seul ce document sera retraduit. Rien ne prend de retard en silence, et scribe status affiche la couverture exacte à n'importe quel commit.

Pas de serveur, par conception

Puisque tout réside sous forme de fichiers dans le dépôt, il n'y a rien à héberger. Le runtime lit le MDX et SQLite sur le disque au moment du build, puis livre à votre framework des documents entièrement typés : listes, recherches, relations, balises alternatives hreflang et entrées de sitemap. Il n'y a pas d'API de CMS à appeler lors d'une requête, pas de tokens à renouveler, et aucune panne de fournisseur ne peut rendre votre contenu inaccessible. Consultez l'API du runtime pour voir comment fonctionnent les lectures.

Les fichiers sont idéaux pour les agents IA

Il y a un argument plus récent en faveur de ce modèle, et c'est peut-être le plus fort : les agents IA sont très à l'aise avec les dépôts. Un agent de codage sait déjà comment chercher dans des fichiers, lire du MDX en texte brut, le modifier sur une branche et ouvrir une pull request. Pointez-le plutôt vers un CMS hébergé et vous devrez configurer des API, des tokens et des intégrations sur mesure avant même qu'il ne puisse changer un titre.

Les garde-fous s'appliquent également. Le frontmatter est validé avec votre schéma Zod et chaque corps de texte doit compiler en MDX, un agent ne peut donc pas enregistrer de document malformé. L'outil scribe validate le détectera avant le build. Et comme chaque modification est un commit, les changements de l'IA sont traités comme ceux des humains : un diff, une révision et une approbation. Ce site fonctionne exactement de cette manière (la majeure partie de sa documentation et de son changelog est maintenue par des agents, tandis que des humains révisent les diffs).

Quand ce modèle n'est pas pour vous

En toute honnêteté, un CMS basé sur git suppose que les personnes qui modifient le contenu sont à l'aise avec les fichiers et les pull requests, ou qu'une personne technique fait le pont entre elles et le dépôt. Si vos éditeurs ont besoin d'une interface WYSIWYG et d'un bouton publier, un CMS hébergé reste le bon choix. Scribe inclut bien un studio local pour parcourir, chercher et inspecter les traductions, mais la rédaction se fait dans votre éditeur de code.

Cependant, si votre équipe vit déjà dans git, l'ajout d'un deuxième et d'un troisième système pour le contenu et les traductions ne fait qu'augmenter la surface de maintenance. Un seul dépôt, un seul flux de révision, un seul déploiement.

Essayez-le

Toute la configuration tient dans un fichier de config et un dossier de MDX :

pnpm add scribe-cms zod better-sqlite3

Commencez par le guide de démarrage, ou lisez comment la traduction fonctionne en coulisses.