Comment nous avons traduit l'intégralité de notre plateforme avec l'IA (et ce que l'agilité avait à voir avec ça)

Fin 2025, la plateforme Agile Academy existait en deux langues : allemand et anglais. Quatre mois plus tard, elle était disponible en huit. Nous n'avons pas fait appel à une agence de traduction. Nous avons utilisé l'IA. Et les principes agiles ont fait toute la différence.

Le point de départ

Une plateforme, deux bases de code, deux langues, et un public international croissant.

L'Agile Academy n'est pas une application unique. C'est un écosystème :

• Base de connaissances Kirby CMS : 440+ articles répartis dans 10 sections, chacun avec un Layout JSON complexe, des références croisées et un routage URL par langue
• Plateforme Ruby on Rails : Pages de réservation de formations, cours e-learning, parcours d'achat, pages produits, avec des fichiers de locale et des vues
• Systèmes backend : Templates d'e-mails, facturation, e-mails transactionnels
• Traductions de l'interface : Menus, pieds de page, fil d'Ariane, boutons et le sélecteur de langue lui-même, sur les deux plateformes

Tout cela n'existait qu'en allemand et en anglais. Pendant ce temps, nous ne pouvions pas fournir de contenu organisé aux personnes ne parlant ni anglais ni allemand, qui représentaient une part croissante de notre audience.

Traduire tout cela n'était pas simplement une tâche de contenu. Chaque langue nécessitait :

• De nouvelles routes dans la configuration PHP de Kirby (aperçus d'articles, réécriture de slugs de sections, redirections)
• Des fichiers de contenu au niveau des sections avec des slugs URL localisés
• Des pages d'aperçu, des pages d'accueil et des pages structurelles (mentions légales, événements, pages d'auteurs)
• Des fichiers de locale ROR pour les menus, le pied de page, les pages de formation, les e-mails
• Des templates d'e-mails dans le backend
• Une cohérence inter-systèmes : le même mot « articles » dans les URL, les mêmes liens vers les pages légales, la même structure de menu

Une agence de traduction traditionnelle aurait pu gérer le texte des articles. Mais personne n'allait écrire nos routes PHP, corriger nos layouts JSON ou mettre à jour nos fichiers de locale Rails. Nous avions besoin d'une approche différente.

Itération 1 : Espagnol

Copier-coller, modifications manuelles du code et un mois de labeur. L'approche en cascade.

L'espagnol a été notre première langue d'expansion. Le processus ressemblait à ceci :

1. Copier le texte d'un article dans ChatGPT ou Claude
2. Coller la traduction dans un nouveau fichier
3. Corriger manuellement le Layout JSON (en espérant ne rien casser)
4. Répéter 440 fois rien que pour Kirby
5. Traduire séparément les fichiers de locale ROR, les vues, les templates d'e-mails
6. Ajouter manuellement les routes, les fichiers de section, les pages d'aperçu dans Kirby
7. Mettre à jour manuellement les fichiers de locale et les routes dans ROR
8. Créer manuellement les templates d'e-mails dans le backend

Cela a pris environ un mois. Seules les pages les plus importantes ont été traduites dans les deux systèmes. La qualité était inégale. Certains articles utilisaient un ton formel, d'autres informel. Les termes agiles étaient parfois traduits, parfois non. Les références croisées entre articles pointaient vers des pages inexistantes.

Le travail d'infrastructure était encore plus pénible. Chaque route devait être écrite à la main. Chaque fichier de section devait être créé de zéro. Les slugs URL étaient incohérents. Les plateformes ROR et Kirby devaient rester synchronisées (mêmes liens de menu, même pied de page, mêmes pages légales), et garder une trace de ce qui avait été fait où relevait du cauchemar sur tableur.

En termes agiles, c'était une livraison en cascade classique : un gros lot, des boucles de feedback limitées, aucune automatisation, aucun standard partagé. Nous l'avons livré, mais nous savions que cette approche ne passerait pas à l'échelle pour six langues supplémentaires.

Itération 2 : Portugais

Première automatisation, premiers scripts, première utilisation de Claude Code. Une semaine au lieu d'un mois.

Pour le portugais, nous avons changé d'approche. Au lieu de copier-coller un article à la fois, nous avons écrit des scripts qui automatisaient la traduction via des appels API. On envoie la source anglaise, on récupère le fichier Kirby traduit.

Plus important encore, nous avons commencé à utiliser Claude Code, non seulement pour le contenu des articles, mais aussi pour le travail d'infrastructure. Claude Code pouvait lire nos routes espagnoles existantes et générer les équivalents portugais. Il pouvait créer des fichiers de section, des pages d'aperçu et mettre à jour les fichiers de configuration.

Côté ROR, Claude Code a généré les fichiers de locale en se référant aux traductions espagnoles existantes. Il a mis à jour les templates d'e-mails, créé de nouvelles vues si nécessaire et maintenu la cohérence des références inter-systèmes.

Le résultat : environ une semaine au lieu d'un mois. Mais le taux d'erreur restait élevé.

Les scripts ne comprenaient pas le contexte. Ils traduisaient « Sprint » en portugais. Ils cassaient le Layout JSON en ajoutant des retours à la ligne dans les chaînes de caractères. Les slugs URL étaient parfois erronés car l'IA ne connaissait pas nos conventions de routage sur les deux plateformes.

Nous avons passé beaucoup de temps à relire et corriger. Mais, point crucial, nous étions désormais en mode inspection et adaptation. Chaque erreur trouvée devenait une règle pour l'itération suivante. Nous avons commencé un glossaire. Nous avons affiné le prompt de traduction. Nous avons documenté les conventions URL que les deux plateformes devaient respecter.

Itérations 3 à 6 : Français, Italien, Néerlandais, Polonais

Des agents spécialisés, un savoir institutionnel et deux jours par langue.

Lorsque nous sommes arrivés au français, le système avait considérablement mûri. Ce qui a fait la vraie différence, c'est la répartition du travail.

Au lieu d'un seul grand contexte IA essayant de tout gérer, nous avons créé des agents spécialisés, chacun concentré sur une partie du système :

• Agents de traduction de contenu qui traitaient des lots d'articles Kirby, en suivant le prompt de traduction et le glossaire
• Agents d'infrastructure qui créaient les routes, les fichiers de section, les pages d'aperçu dans Kirby
• Agents de locale ROR qui traduisaient et créaient les fichiers de locale pour la plateforme Rails
• Agents de vérification qui exécutaient des scripts pour détecter le JSON cassé, les slugs URL erronés, les champs manquants

Chaque agent avait une fenêtre de contexte réduite, focalisée sur sa tâche spécifique. Cela produisait de bien meilleurs résultats qu'un seul agent essayant de garder l'ensemble de la plateforme en mémoire.

Le savoir institutionnel était désormais codifié :

• Un prompt de traduction (TRANSLATION_PROMPT.md) définissait le ton, le format, les règles URL et l'exigence de notice IA
• Un glossaire (glossary.json) maintenait la cohérence des termes agiles dans toutes les langues
• Des scripts de vérification détectaient les erreurs avant la mise en production : Layout JSON cassé, références hreflang erronées, champs obligatoires manquants
• Une checklist dans CLAUDE.md documentait chaque étape d'infrastructure nécessaire pour une nouvelle langue (routes, fichiers de section, pages d'aperçu, pages structurelles, synchronisation menu/pied de page)
• Des vérifications de cohérence inter-systèmes garantissaient la synchronisation entre Kirby et ROR

L'italien a pris deux jours. Le néerlandais a pris deux jours. Le polonais a pris deux jours. Chaque itération était plus rapide et plus fiable. Le taux d'erreur diminuait à chaque langue car le système apprenait de chaque erreur précédente.

Avant et après

La même tâche. Un système fondamentalement différent.

Les principes agiles en action

Ce n'était pas qu'un projet de traduction. C'étaient six Sprints d'apprentissage organisationnel.

Amélioration itérative

Chaque langue était un Sprint. L'espagnol était le Sprint 1 : lent, manuel, riche en apprentissages. Le polonais était le Sprint 6 : rapide, automatisé, affiné. L'amélioration a été exponentielle. Chaque itération n'ajoutait pas seulement une langue. Elle améliorait le système pour toutes les langues futures.

Inspection et adaptation

Chaque erreur dans une langue devenait une règle de prévention pour la suivante. JSON cassé ? On ajoute un validateur JSON au script de vérification. « Sprint » traduit en portugais ? On l'ajoute au glossaire. Mauvaise convention de slug URL ? On la documente dans la checklist. Le système devenait plus intelligent parce que nous y avions intégré des boucles de feedback.

Équipes auto-organisées

Les agents spécialisés étaient, en pratique, des membres d'équipe auto-organisés. Chacun avait une responsabilité claire, le bon contexte pour sa tâche et des interfaces définies avec les autres. L'agent de contenu n'avait pas besoin de connaître les routes PHP. L'agent d'infrastructure n'avait pas besoin de parser le Layout JSON. Séparation des responsabilités. Ça fonctionne pour le logiciel et pour les équipes.

Un logiciel fonctionnel plutôt que de la documentation

Le prompt de traduction, le glossaire, les scripts de vérification. Rien de tout cela n'a été conçu en amont. Tout est né de problèmes réels rencontrés pendant le travail réel. Le prompt a été réécrit cinq fois. Le glossaire a grandi avec chaque langue. Les scripts sont nés d'erreurs qui avaient échappé à la relecture manuelle. De la documentation vivante, façonnée par l'usage réel, s'est avérée bien plus utile que n'importe quelle spécification que nous aurions pu rédiger en amont.

Répondre au changement

Nos décisions architecturales étaient guidées par les erreurs, pas par la planification en amont. Nous n'avions pas prévu que le Layout JSON serait la plus grande source de bugs. Nous l'avons découvert pendant l'espagnol et avons construit la validation avant le portugais. Nous n'avions pas planifié la spécialisation des agents. Nous y sommes arrivés après avoir constaté qu'un seul grand contexte produisait de moins bons résultats que plusieurs contextes ciblés. Nous avons abouti à une configuration meilleure que tout ce que nous aurions pu concevoir sur un tableau blanc.

Points clés à retenir

L'IA ne remplace pas la pensée agile. Elle l'amplifie.

1. L'IA amplifie votre processus, en bien comme en mal

Si votre processus est chaotique, l'IA produira du chaos plus vite. Si votre processus est discipliné (prompts clairs, standards définis, boucles de vérification), l'IA produira de la qualité à grande échelle. Le même outil qui cassait notre JSON à l'itération 1 produisait un résultat impeccable à l'itération 6. L'IA n'a pas changé. C'est notre processus qui a changé.

2. Le contexte est primordial

Le glossaire, le prompt de traduction, la checklist, les règles de cohérence inter-systèmes. Ce sont toutes des formes de contexte. Une IA sans contexte n'est qu'un traducteur rapide. Une IA avec le bon contexte est un membre d'équipe qui comprend vos conventions, vos cas particuliers et vos standards de qualité. Construire ce contexte, c'est là que réside le vrai travail, et il se capitalise avec chaque nouvelle langue ajoutée.

3. Le rôle humain passe d'exécutant à architecte

À l'itération 1, les humains faisaient la traduction. À l'itération 6, les humains concevaient le système, définissaient les standards, relisaient les résultats et amélioraient le processus. Le travail n'a pas disparu. Il s'est déplacé vers une réflexion de plus haut niveau. Moins de copier-coller, plus de réflexion sur ce qui fait une bonne traduction, ce qui fait une expérience utilisateur cohérente et comment détecter les erreurs avant les utilisateurs.

4. Commencer petit, livrer, apprendre, recommencer

Nous aurions pu passer des mois à concevoir le pipeline de traduction « parfait » avant de traduire un seul article. Au lieu de cela, nous avons commencé par du copier-coller et avons itéré. Chaque langue nous a appris quelque chose. Chaque erreur a amélioré le système. Lorsque nous sommes arrivés aux dernières langues, nous avions un pipeline qu'aucune planification en amont n'aurait pu produire, car il avait été façonné par des problèmes réels, pas hypothétiques.