Des milliers de pages migrées sans copier-coller : comment nous réécrivons le contenu d'Orisha en 4 langues avec Claude Code

Orisha est un éditeur de logiciels métier européen : 2 300 collaborateurs, 50 000 clients, sept marchés, du retail à la santé, de la construction à l'agroalimentaire.

Au fil de sa croissance externe, le groupe a accumulé des dizaines de sites WordPress indépendants, un par business unit, sur autant de sous-domaines. Le projet, mené avec Digidop pour le design et l'architecture Webflow Enterprise : tout réunir sur une seule plateforme, organisée par business unit, en quatre langues. Notre part : le contenu. Ce cas couvre la première vague : deux business units, Commerce et Construction, et le site Groupe.

Le challenge : des dizaines de sites, aucun gabarit commun

Premier constat en ouvrant les anciens sites : ils ne se ressemblaient pas. Des centaines de pages produits, d'activités et de services, bâties par des équipes différentes, dans des pays différents, sans structure commune.

À cela s'ajoutaient des années d'articles de blog encodés dans des formats WordPress sur mesure, et des liens internes pointant vers des URL sur le point de disparaître.

Reprendre tout ça à la main, c'était des mois de copier-coller et des erreurs à chaque page. Le copier-coller aurait déménagé le désordre au lieu de le corriger. Or le but n'était pas de répliquer l'existant, mais d'unifier.

Notre approche : un moteur, pas du copier-coller

Nous avons pris le problème à l'envers. Plutôt que de déplacer les pages une par une, nous avons construit un moteur de migration piloté par Claude Code : il lit chaque ancien site, en extrait le contenu, le réécrit dans la structure cible, le réintègre au CMS, le traduit et rétablit les liens.

Prouver, faire valider, puis généraliser

Une règle a encadré tout le projet. Sur chaque type de contenu :

• nous migrons d'abord cinq à sept pages témoins ;
• un humain les ouvre dans l'éditeur Webflow ;
• nous corrigeons ce que seul l'œil repère ;
• le lot complet part seulement ensuite.

Pourquoi cette étape humaine ? Un contrôle automatique confirme que le contenu est stocké, pas qu'il s'affiche correctement. La majorité des problèmes n'apparaissent qu'à l'ouverture d'une page. C'est cette discipline qui explique qu'aucun lot n'a cassé au moment de passer au volume.

Notre configuration Claude Code

La fiabilité se joue dans la configuration du projet, avant le premier prompt. Claude Code travaille sur une base de connaissance structurée, pensée pour qu'il ait toujours le bon contexte à portée.

Un dépôt organisé comme une base de connaissance

Un index à la racine, un dossier par business unit, une séparation nette entre ce que les équipes savent du marché et la mécanique de migration.

Trois principes tiennent l'ensemble :

• Des fichiers générés, jamais édités à la main. Les identifiants Webflow réels (le site, les 4 langues, les 23 collections, les pages de contact par business unit) vivent dans un fichier de référence régénéré par script. L'IA ne devine jamais un identifiant, elle lit la référence à jour.
• Un journal de bord daté. Chaque découverte technique est consignée avec sa preuve : « le statut brouillon ne retire pas une page du site en ligne », « espacer les appels à 300 ms et réessayer, sinon l'API bloque ». Ce journal évite de commettre deux fois la même erreur, d'une semaine à l'autre ou d'un agent à l'autre.
• Des outils maison. Toute la rédaction française passe au crible d'un correcteur dédié qui traque les tics d'écriture IA.

Deux voies, un pont

Webflow expose deux API qu'il ne faut pas confondre :

• la voie headless (API REST) écrit le CMS, le SEO, l'Open Graph, les traductions et les liens, sans navigateur ;
• la voie visuelle (extension Webflow sur mesure et service local) écrit le texte « en dur » des composants en français, que l'API REST refuse d'éditer.

Un pont relie les deux : pour chaque page, un plan d'écriture généré côté REST, appliqué côté éditeur visuel.

Des garde-fous, pas de l'automatisation aveugle

Chaque écriture est revérifiée par une relecture séparée, car le retour immédiat de l'API peut mentir. Chaque lien est testé en direct avant d'être écrit.

Sur une correction de liens traduits, le moteur a repéré 135 cibles, puis les a testées une à une.

Réécrire le contenu, pas seulement le transférer

Unifier la structure ne suffisait pas. Nous avons ramené des centaines de pages hétérogènes à une poignée de modèles : activité, service, produit logiciel, landing, formation. Chaque modèle a son programme. Les 12 pages d'activité, par exemple, partagent le même gabarit à l'ordre des sections près.

Là où une migration classique transfère le texte tel quel, nous l'avons réécrit à partir de ses sources : l'ancienne page en ligne, un PDF produit, une fiche marché. Un sous-agent a pris en charge chaque page, lu la version existante et rédigé la nouvelle. Sur un lot, cette réécriture a mobilisé 54 agents en parallèle. Deux règles non négociables :

• Zéro invention. Chaque chiffre, chaque phrase vient de la source. Une page qui n'existait qu'en allemand sur l'ancien site reste en allemand. Une page sans statistiques reçoit moins d'encarts, pas des chiffres inventés.
• Pas de section vide. Quand un modèle comportait une rubrique sans source, deux options : un contenu générique propre à la marque, ou le masquage de la section, plutôt que d'inventer.

Le CMS : reprendre des années de blog

Le CMS a été le chantier le plus dense du projet. Il fallait reprendre des années d'articles, 800 sur trois business units : 478 côté Commerce, 270 côté Construction, une cinquantaine pour le Groupe.

Le contenu WordPress exporté n'est pas du texte propre. Nous y avons trouvé une trentaine de blocs sur mesure, dans des formats propriétaires. Le moteur reconnaît chacun, et récupère le texte des blocs inconnus pour ne rien perdre.

Le point le plus coûteux n'était pas l'écriture mais l'affichage. Webflow accepte presque tout à l'import, puis l'interprète au rendu : un article stocké sans erreur pouvait casser la page à l'ouverture. Nous avons isolé ces cas un par un et réglé le moteur pour qu'il produise exactement le format attendu par l'éditeur.

Reprendre les articles ne suffisait pas, il fallait les rendre navigables. Nous avons reconstruit la taxonomie qui structure le CMS, 120+ entrées (métiers, expertises, solutions, add-ons, types), reliées entre elles et aux articles. Puis nous avons catégorisé les articles selon une règle simple : déterministe partout où c'est possible, IA seulement là où il le faut. Le métier et le type se déduisaient des anciennes catégories WordPress, sans IA, sur 100 % des articles. Les expertises, absentes des données sources, ont été classées par l'IA.

Avec une consigne stricte : ne jamais forcer une catégorie fausse pour remplir un champ. Résultat, 123 articles laissés volontairement sans catégorie, et zéro erreur de rattachement entre marchés sur les 748 articles contrôlés.

Préserver le référencement

Une migration mal menée efface des années de SEO. Trois chantiers l'ont évité :

• Le maillage. 3 000+ liens internes remis à jour vers les bonnes pages Webflow. Sans faire confiance au plan du site : certaines pages y figurent mais répondent 404. Chaque cible a été testée en direct avant d'écrire la redirection.
• Les balises. Titres et descriptions audités sur 209 pages dans les trois langues, soit plus de 600 contrôles. L'audit a révélé 17 pages Construction qui affichaient un titre « Orisha Commerce » copié d'une autre business unit, et 84 pages ont été réécrites en anglais et espagnol.
• La source de vérité. Slugs, URL et structure sont pilotés par des tableaux de correspondance fournis par les équipes, que le moteur lit pour construire automatiquement chaque URL cible. Quand la source est incomplète, nous la croisons avec la page réelle avant toute écriture.

Quatre langues, deux niveaux de traduction

Le site cible existe en français, anglais, espagnol et néerlandais. Le moteur gère un même contenu en plusieurs versions, et n'écrit que les versions étrangères, sans toucher au français d'origine.

Nous avons distingué deux niveaux de traduction. La traduction simple traduit le français correctement : juste à 80 % environ. La traduction avancée va chercher la terminologie réellement employée sur les anciennes pages du client, langue par langue, et s'en sert comme référence. Nous avons construit un glossaire à partir des sites en ligne, et la différence est nette :

C'est ce qui sépare une traduction correcte d'un texte que la marque aurait pu écrire elle-même.

Les résultats de la première vague

• 800 articles de blog importés dans le CMS, sur Commerce, Construction et Groupe ;
• 748 articles (Commerce et Construction) traduits en anglais et espagnol : titres, descriptions, fils d'ariane et SEO ;
• 3 000+ liens internes mis à jour, 0 lien mort ;
• 120+ entrées de taxonomie reconstruites et reliées, en 4 langues ;
• 209 pages auditées et corrigées en SEO title et meta, soit 600+ contrôles sur les 3 langues ;
• 200+ pages équipées d'une image de partage aux couleurs de chaque marque ;
• la business unit Commerce localisée à 100 %, sans un mot de français résiduel.

Ce qu'il faut retenir

1. Migrer, ce n'est pas transférer. À ce volume, le travail consiste à remettre le contenu au propre : une structure unifiée, un texte réécrit depuis sa source plutôt que recopié.

2. Le CMS est le vrai chantier. Les pages statiques se voient, le blog et sa taxonomie non. C'est pourtant là que se concentrent le volume, les cas tordus et le travail de fond.

3. La configuration prime sur le prompt. Ce qui rend une migration IA fiable tient à quatre choses : un dépôt structuré, des références qui ne mentent pas, un journal des erreurs, et la règle « prouver, valider, généraliser ».

Projet mené avec Digidop (direction artistique, UX/UI, architecture Webflow Enterprise) et les équipes d'Orisha et de Webflow.