Prestataire digital et cahier des charges d'un site multilingue : traduction, hreflang et budget par langue, qui fait quoi

Le multilingue ne meurt jamais d'un problème technique

Il meurt d'un blanc dans le contrat. D'une case que personne n'a cochée. D'une phrase du type « on verra ça au moment de la mise en ligne » qui, dix-huit mois plus tard, se transforme en trois versions linguistiques figées, un catalogue à moitié traduit et un client persuadé que le SEO international, décidément, « ça ne marche pas ».

Il faut le dire franchement : dans la grande majorité des projets qui dérapent, la balise hreflang n'est pas coupable. Le vrai coupable, c'est l'absence de nom en face de chaque livrable. Qui traduit les balises title ? Qui décide du mot-clé cible en néerlandais ? Qui met à jour la version espagnole quand la fiche produit française change ? Silence radio. Et le silence, dans un projet web, se facture toujours en avenant.

Ce qui suit n'est pas un plaidoyer pour un cahier des charges de quarante pages que personne ne lira. C'est l'inverse. Une grille de répartition des responsabilités, une méthode de chiffrage langue par langue, et une poignée de clauses à faire figurer noir sur blanc avant de signer quoi que ce soit.

Pourquoi le cahier des charges multilingue est un exercice à part

Un site multilingue n'est pas un site traduit

La confusion commence dès la première réunion. Le client dit « on veut le site en anglais et en allemand », le prestataire entend « traduction », et tout le monde repart content. Sauf qu'il y a trois objets distincts derrière cette phrase.

La traduction, d'abord. Le contenu éditorial passe d'une langue à l'autre. C'est la partie visible, celle qu'on chiffre au mot, celle qui rassure parce qu'elle est facile à quantifier.

La localisation ensuite, et là ça se corse. Devises, formats de date, unités de mesure, mentions légales, tunnel de commande, modes de paiement locaux, conditions de retour. Un panier en euros avec une date au format américain et des CGV françaises traduites mot à mot, c'est un site qui ne convertira pas. Personne ne l'avait budgété.

L'internationalisation SEO enfin. Architecture d'URL, balises hreflang, ciblage géographique dans la Search Console, sitemaps par langue, arborescence adaptée aux habitudes de recherche du marché. Cette couche-là est invisible dans une maquette. Elle est pourtant celle qui détermine si le site existe ou non dans les résultats du pays visé.

Un devis qui ne couvre que le premier point laisse deux chantiers entiers hors budget. Ce n'est pas malhonnête dans 90 % des cas. C'est juste que personne n'a posé la question.

Les quatre décisions structurantes à figer avant le devis

Impossible de chiffrer sérieusement tant que ces quatre points restent flous. Ils ne relèvent pas du prestataire seul, ils se tranchent ensemble, en amont.

• Langues ou marchés ? Ce n'est pas la même chose. Une version « fr » couvre la francophonie de manière générique. Une version « fr-BE » cible la Belgique francophone, avec ses formulations, ses prix, ses délais de livraison. Multiplier les variantes régionales multiplie la maintenance. Le faire sans raison commerciale, c'est se créer du travail pour rien.
• L'architecture d'URL. Sous-répertoire (site.com/de/), sous-domaine (de.site.com) ou domaine national (site.de) ? Le sous-répertoire concentre l'autorité et coûte le moins cher à maintenir. Le ccTLD envoie un signal géographique fort mais impose de reconstruire une notoriété par pays, et de gérer autant de propriétés Search Console. Il n'y a pas de bonne réponse universelle, il y a un arbitrage entre autorité, budget et autonomie des équipes locales. Ce qui compte, c'est que l'arbitrage soit écrit et justifié.
• Le périmètre traduit. Tout le site, ou seulement le parcours commercial prioritaire ? Sur un catalogue de 4 000 références, la réponse change le devis d'un facteur dix. Et traduire l'intégralité par principe, sans regarder ce qui génère du chiffre, revient souvent à payer très cher des pages que personne ne consultera.
• Le modèle de gouvernance. Centralisé chez l'agence, décentralisé dans les filiales, ou hybride ? Une filiale allemande qui publie en autonomie sans process de validation SEO produira des pages orphelines et des doublons. À l'inverse, une centralisation totale crée un goulot d'étranglement dès qu'il faut publier une promotion locale en 48 heures.

Le coût du non-dit

Voici la liste des zones grises qui reviennent le plus souvent en avenant. Elles ont un point commun : elles sont toutes invisibles dans une maquette et évidentes une fois le site en ligne.

Le glossaire métier. Les balises title et meta description. Les attributs alt des images. Les libellés de formulaires et les messages d'erreur. Les emails transactionnels (confirmation de commande, réinitialisation de mot de passe, relance de panier abandonné). Les pages légales et la politique de confidentialité par juridiction. Le fil d'Ariane. Les filtres de navigation à facettes. Les 404 personnalisées.

Rien de spectaculaire dans cette liste. Mais mises bout à bout, ces « petites choses » représentent régulièrement 15 à 25 % du volume réel à traiter. Autant les nommer avant.

La matrice « qui fait quoi » : sept rôles, un tableau

Les acteurs à nommer explicitement

Un projet multilingue mobilise plus de monde qu'un projet monolingue, et surtout des métiers qui ne se parlent pas naturellement. Le traducteur ne connaît pas la Search Console. Le développeur ne rédige pas. Le référent local ne lit pas les specs techniques. D'où l'intérêt de les nommer un par un.

• Le client. Validation terminologique, fourniture des contenus sources dans un format exploitable, arbitrage sur les marchés prioritaires. Rôle largement sous-estimé : c'est souvent lui qui retarde tout le projet en ne validant pas le glossaire.
• L'agence SEO. Architecture d'URL, spécification hreflang, recherche de mots-clés par langue, brief éditorial, recette technique, suivi des positions par marché.
• L'agence ou le développeur web. Implémentation dans le CMS, gestion des chaînes d'interface, performance, redirections, structure des sitemaps.
• Le traducteur ou l'agence de traduction. Traduction, gestion de la terminologie, alimentation de la mémoire de traduction.
• Le relecteur natif. Validation stylistique et culturelle. Pas un luxe : c'est lui qui repère qu'une formulation techniquement juste sonne bizarre, ou qu'une accroche fonctionne mal dans le pays cible.
• Le référent local. Validation marché, conformité réglementaire, cohérence avec le discours commercial de la filiale.
• L'hébergeur. Localisation serveur, CDN, certificats, temps de réponse depuis le pays visé. Souvent oublié, alors qu'un site français servi depuis Roubaix vers l'Australie n'a pas les mêmes performances qu'en local.

Le tableau RACI à intégrer au cahier des charges

Le principe est banal, l'application au multilingue l'est beaucoup moins. Une ligne par livrable, une colonne par rôle, et dans chaque case une lettre : R pour celui qui réalise, A pour celui qui répond du résultat, C pour celui qu'on consulte, I pour celui qu'on informe.

Les lignes à ne pas oublier : mot-clé cible par langue, arborescence par marché, spécification hreflang, implémentation hreflang, balises title et meta, contenu éditorial, visuels localisés, plan de redirections, sitemaps par langue, recette technique, suivi de positions, mise à jour continue.

Une règle simple, et elle vaut de l'or : un seul A par ligne. Deux responsables, c'est zéro responsable. On l'a tous vu au moins une fois.

Les trois frontières qui posent problème en pratique

Sur le papier, la matrice paraît bureaucratique. En réalité, elle sert à trancher trois questions précises qui empoisonnent presque tous les projets.

Qui traduit les balises SEO ? Le traducteur ne les voit jamais, parce qu'elles ne sont pas dans le corps du texte qu'on lui envoie. Le développeur les intègre mais ne les rédige pas. Résultat classique : des balises title en français sur les pages allemandes, découvertes trois mois après la mise en ligne par hasard, en auditant autre chose.

Qui décide du mot-clé cible dans la langue B ? Traduire le mot-clé français est la première erreur, et la plus courante. On y revient plus bas, mais retenez déjà que ce livrable doit avoir un propriétaire clairement identifié.

Qui met à jour la version B quand la version A change ? C'est le point de rupture. Presque toujours à dix-huit mois. Le site français vit, s'enrichit, se corrige. Les autres versions se figent doucement. Deux ans plus tard, l'écart est tel qu'une remise à niveau coûte plus cher que la traduction initiale. Ce n'est pas une fatalité, c'est une clause manquante.

Traduction : ce que le cahier des charges doit imposer

Le mot-clé ne se traduit pas, il se recherche

Prenons un cas concret. Un fabricant français de mobilier professionnel positionné sur « vitrine réfrigérée », requête solide, intention commerciale claire. On traduit pour le marché allemand, on obtient « Kühlvitrine ». Techniquement correct. Sauf que les acheteurs allemands du secteur cherchent plus volontiers par type d'usage ou par gamme, et que la requête littérale ne capte qu'une fraction du marché. Le volume est là, mais pas là où on l'attendait.

L'inverse existe aussi, et il est plus vicieux. Une requête à fort volume dans la langue cible peut ne correspondre à aucune page du site source, simplement parce que le marché segmente l'offre différemment. Vous avez alors une opportunité de trafic que la traduction, par construction, ne verra jamais.

Conséquence directe sur le brief : la recherche de mots-clés native est un livrable distinct, chiffré par langue. Pas une option. Pas un « inclus dans la traduction ». Une ligne de devis à part entière, réalisée par quelqu'un qui maîtrise la langue et dispose des données du marché local.

Traduction humaine, post-édition ou machine seule

Le débat est souvent posé de façon binaire, ce qui n'aide personne. Il se traite page par page, selon l'enjeu.

La traduction automatique seule coûte presque rien et va très vite. Elle reste acceptable sur des contenus à faible enjeu, très factuels, à durée de vie courte. Elle devient dangereuse dès qu'il y a du vocabulaire métier, un argumentaire commercial ou une nuance juridique.

La post-édition (une traduction machine reprise par un professionnel) constitue le compromis réaliste sur le gros du volume. Comptez grosso modo la moitié du coût d'une traduction humaine complète, pour une qualité qui, sur du contenu structuré et bien briefé, tient très correctement la route.

La traduction humaine native, enfin, se réserve à ce qui compte vraiment : pages piliers, pages transactionnelles, argumentaires, contenus de marque. Là où une formulation maladroite coûte des conversions.

Un conseil qui vaut ce qu'il vaut : plutôt que de trancher globalement, cartographiez le site en trois niveaux d'enjeu et affectez un mode à chacun. Le devis devient lisible, et l'arbitrage budgétaire aussi.

Les livrables terminologiques à exiger

• Un glossaire bilingue validé par le client avant le premier mot traduit. L'ordre compte. Valider le glossaire après coup, c'est repayer des corrections sur l'ensemble du corpus.
• Une mémoire de traduction, avec clause de propriété explicite. Elle appartient au client. Point. Sans cette clause, changer de prestataire signifie repartir de zéro, et vous venez de perdre votre principal levier de négociation.
• Un guide de style par langue. Tutoiement ou vouvoiement, usage des majuscules, unités, ton, traitement des noms de produits. Trois pages suffisent. Elles évitent des dizaines d'allers-retours.

La clause qui manque toujours : la traduction du contenu SEO natif

Voici un point que presque aucun cahier des charges ne traite, et qui explique beaucoup de déceptions.

Un texte optimisé en français ne l'est plus une fois traduit. La densité sémantique se déplace, les expressions cibles ne correspondent plus aux requêtes réelles du marché, le champ lexical se décale. Vous obtenez un texte parfaitement lisible et parfaitement inefficace en référencement.

Deux réponses possibles. Soit une réoptimisation post-traduction : le texte traduit est repris à la lumière du keyword research natif. Soit une rédaction native directement à partir du brief, sans passer par le français. La seconde option coûte plus cher à l'unité mais donne de bien meilleurs résultats sur les pages stratégiques.

Dans tous les cas, chiffrez la différence et présentez-la au client. Qu'il choisisse en connaissance de cause, plutôt que de découvrir six mois plus tard que sa version allemande ne se positionne sur rien.

Hreflang : le livrable technique le plus mal attribué

Ce que hreflang fait, et ce qu'il ne fait pas

Mettons fin tout de suite à un malentendu tenace : hreflang n'est pas un facteur de classement. Ce n'est pas un booster. C'est un signal de substitution. Il indique à Google que plusieurs documents sont des équivalents destinés à des audiences linguistiques ou géographiques différentes, afin qu'il serve le bon à la bonne personne.

Ce qu'il ne fait pas, en revanche, mérite d'être affiché en gros dans la salle de réunion. Il ne compense pas un contenu dupliqué. Il ne crée pas d'autorité locale. Il ne fera pas ranker une version allemande sans liens, sans contenu propre et sans historique, au seul motif qu'elle est correctement annotée.

Autrement dit : hreflang évite des problèmes, il ne génère pas de résultats. C'est une hygiène, pas une stratégie.

Les trois modes d'implémentation et qui les porte

• Balises dans le head. Le mode le plus répandu, porté par le développeur sur spécification de l'agence SEO. Simple à contrôler, lourd à maintenir sur de gros volumes (chaque page contient les liens vers toutes ses variantes).
• En-têtes HTTP. Indispensable pour les fichiers non HTML : PDF de documentation, catalogues téléchargeables, fiches techniques. Systématiquement oublié. Si votre client diffuse ses notices en cinq langues, la question se pose.
• Sitemap XML. Le mode le plus maintenable sur les gros catalogues. Toutes les correspondances sont centralisées dans un fichier généré automatiquement, ce qui limite drastiquement le risque d'incohérence. Il demande en revanche une génération rigoureuse et un contrôle régulier.

Le choix du mode n'est pas neutre budgétairement. Il doit figurer dans la spécification, pas être laissé à l'appréciation du développeur au moment de l'intégration.

Les erreurs récurrentes à interdire par contrat

Cinq classiques. Elles reviennent avec une régularité désespérante, tous prestataires confondus.

• L'absence de réciprocité. La page A pointe vers B, mais B ne pointe pas vers A. Google ignore alors purement et simplement la déclaration. C'est de loin l'erreur numéro un.
• Des codes langue-région invalides ou inversés. « en-UK » n'existe pas (c'est « en-GB »). Et l'ordre est toujours langue puis région, jamais l'inverse.
• L'absence de x-default. Sur la page d'accueil et le sélecteur de langue, il indique la version à servir quand aucune correspondance ne convient. Son absence n'est pas dramatique, mais elle laisse Google décider seul.
• Un hreflang pointant vers une URL non canonique ou en redirection. Chaque déclaration doit viser l'URL finale, celle qui répond en 200 et qui se déclare canonique d'elle-même.
• Une contradiction entre hreflang et canonical. Le cas le plus toxique : une page allemande annotée en hreflang mais canonisée vers sa version française. Les deux signaux se battent, Google tranche, et rarement dans le sens espéré.

La recette de validation : le critère d'acceptation à écrire

Une clause de recette sans chiffre n'est pas opposable. « L'implémentation hreflang sera conforme aux recommandations de Google » ne veut rien dire et ne protège personne.

Formulez plutôt quelque chose de mesurable : zéro erreur dans le rapport international de la Search Console à trente jours après la mise en ligne, taux de couverture hreflang supérieur à 98 % des URL indexables par langue, contrôle par crawl sur un échantillon d'au moins 200 URL par version linguistique, et réciprocité vérifiée sur 100 % de l'échantillon.

Avec ce niveau de précision, la recette devient un fait vérifiable. Sans, elle reste une opinion, et l'opinion du prestataire pèse toujours plus lourd que celle du client au moment du solde.

Le cas des pages non traduites

Tous les sites multilingues ont des pages asymétriques : une actualité locale, une offre réservée à un marché, un contenu réglementaire propre à un pays. Trois règles.

Ne les incluez pas dans un cluster hreflang, puisqu'elles n'ont pas d'équivalent. Ne redirigez pas automatiquement l'utilisateur vers une autre langue « à défaut ». Et surtout, ne géolocalisez jamais par IP avec redirection forcée. C'est probablement le pire réflexe du multilingue : le robot de Google explore majoritairement depuis les États-Unis, il ne verra donc que la version qu'on sert aux visiteurs américains. Le reste du site devient invisible.

La bonne pratique tient en une phrase : suggérer, jamais imposer. Un bandeau discret proposant de changer de version, et l'utilisateur décide.

Budget par langue : construire un chiffrage défendable

Pourquoi le coût par langue n'est pas linéaire

C'est le point que la plupart des devis ratent, et il coûte cher aux deux parties.

La première langue additionnelle porte l'intégralité de l'investissement structurel : conception de l'architecture, configuration du CMS multilingue, spécification hreflang, mise en place des sitemaps, définition du process de traduction, création du glossaire et du guide de style. Cet investissement, on ne le refait pas. Les langues suivantes en bénéficient intégralement.

Un devis qui multiplie bêtement un coût unitaire par le nombre de langues fait donc deux erreurs à la fois : il surfacture les premières et sous-facture les dernières. Le client, lui, n'a aucun moyen de comparer deux propositions construites sur cette base.

La bonne pratique consiste à isoler clairement ce qui est non récurrent, ce qui est par langue à l'initialisation, et ce qui est récurrent.

La ventilation à exiger dans le devis

• Setup non récurrent : architecture d'URL, configuration multilingue du CMS, spécification et implémentation hreflang, sitemaps, plan de redirections, propriétés Search Console.
• Coût par langue à l'initialisation : recherche de mots-clés native, traduction ou rédaction, relecture native, rédaction des balises, localisation des visuels, recette technique de la version.
• Coût récurrent par langue : mise à jour des contenus existants, production de nouveaux contenus, suivi de positions sur le marché, netlinking local, veille concurrentielle.
• Postes régulièrement absents : visuels et vidéos localisés, service client dans la langue, mentions légales et RGPD par juridiction, adaptation des modes de paiement et de livraison.

Ce dernier bloc mérite une attention particulière. Un client qui découvre après la mise en ligne qu'il doit assurer un support en allemand n'a pas seulement un problème de budget. Il a un problème de crédibilité sur son nouveau marché.

Le netlinking local, poste le plus sous-estimé

Une vérité qui dérange : une version linguistique sans profil de liens dans le pays cible reste invisible, quelle que soit la qualité de sa traduction et l'élégance de son hreflang.

L'autorité ne se traduit pas. Un site français bénéficiant de trois cents domaines référents francophones démarre sa version italienne avec, en pratique, l'équivalent d'un site neuf sur le marché italien. Le sous-répertoire aide, il partage une partie de l'autorité du domaine, mais il ne dispense pas d'acquérir des liens locaux, dans la langue, depuis des sites du pays.

En pratique, sur la deuxième année, ce poste dépasse fréquemment le coût de traduction. Il doit donc apparaître dès le cahier des charges, ne serait-ce que sous forme d'enveloppe indicative. L'omettre revient à vendre une voiture sans le carburant.

Arbitrer : la méthode du seuil de rentabilité par langue

Le raisonnement tient en une ligne, et il évite beaucoup de décisions prises à l'affect.

Volume de recherche adressable sur le marché × taux de clic estimé selon les positions visées × taux de conversion local × panier moyen local. Vous obtenez un potentiel de chiffre d'affaires annuel. Comparez-le au coût complet à vingt-quatre mois, netlinking et maintenance inclus.

Le résultat surprend souvent. Certaines langues « évidentes » (parce que le dirigeant les parle, ou parce que le pays est voisin) sortent nettement moins bien que des marchés auxquels personne n'avait pensé.

Et une conclusion pratique, qu'on ne répétera jamais assez : mieux vaut deux langues réellement tenues qu'une demi-douzaine laissées en jachère. Une version linguistique abandonnée ne fait pas que ne rien rapporter. Elle dégrade la perception de sérieux de la marque et mobilise malgré tout des ressources techniques à chaque évolution du site.

Le piège du forfait « toutes langues incluses »

C'est commercialement séduisant. C'est opérationnellement toxique.

Un forfait global masque les arbitrages : impossible de savoir ce que coûte réellement l'italien, donc impossible de décider en connaissance de cause de l'arrêter ou de renforcer l'espagnol. Vous perdez toute capacité de pilotage.

Pire, il rend l'arrêt d'une langue non rentable techniquement et contractuellement compliqué. Que devient le budget libéré ? Le prestataire le conserve, en général. Exigez une ventilation, quitte à ce que le total soit identique. La ventilation, c'est votre liberté de manœuvre.

Le cahier des charges opérationnel : structure type

Les sections indispensables

Voici l'ossature. Elle n'a pas besoin de faire quarante pages. Quinze pages précises valent mieux que quarante pages vagues.

• Contexte, marchés visés et objectifs chiffrés par marché
• Périmètre linguistique et périmètre de contenu, langue par langue
• Architecture technique retenue et justification de l'arbitrage d'URL
• Spécification hreflang complète, avec matrice des correspondances et mode d'implémentation
• Process de traduction et livrables terminologiques attendus
• Matrice RACI des responsabilités
• Critères de recette mesurables
• Modalités de maintenance et de mise à jour des versions
• Propriété des actifs : mémoire de traduction, glossaire, accès aux outils, données de suivi

Cette dernière section est celle qu'on oublie et qu'on regrette. Le jour où vous changez de prestataire, elle vaut plus que tout le reste réuni.

Les critères d'acceptation à formuler en clauses

Quelques exemples rédigés, à adapter, mais qui donnent le ton attendu.

« La recette hreflang est validée si le rapport de ciblage international de la Search Console ne remonte aucune erreur de réciprocité ni de code langue invalide à J+30 de la mise en ligne, sur l'ensemble des URL du sitemap. »

« Chaque page traduite dispose d'une balise title et d'une meta description rédigées dans la langue cible, distinctes de la version source, d'une longueur comprise entre 50 et 60 caractères pour le title. Un contrôle par crawl exhaustif est fourni au moment de la recette. »

« La mémoire de traduction est livrée au client au format TMX à chaque fin de phase, et au plus tard sous quinze jours après la fin de la mission. Elle demeure la propriété exclusive du client. »

« Toute modification d'une page dans la langue source déclenche la création d'une tâche de mise à jour dans les versions cibles, traitée sous un délai maximum de dix jours ouvrés. »

Notez le point commun : chacune de ces clauses se vérifie. Oui ou non. Pas de zone de discussion.

Le calendrier réaliste par vague de langues

Tentation classique : lancer les cinq langues en même temps, pour « ne pas perdre de temps ». Mauvaise idée dans à peu près tous les cas.

Une langue pilote permet de tester le process complet en conditions réelles, de repérer les frictions (et il y en aura), d'ajuster le brief traducteur, de corriger la spécification hreflang, de mesurer les délais réels de validation côté client. Comptez huit à douze semaines pour cette première vague, mise en ligne comprise.

Les vagues suivantes vont ensuite deux fois plus vite, avec un taux d'erreur nettement inférieur. Le temps « perdu » au départ est largement récupéré. Et le client voit des résultats sur un marché avant d'engager l'intégralité du budget, ce qui n'est pas un mince avantage quand il faut défendre le projet en interne.

Les cinq questions à poser à un prestataire avant de signer

Si vous ne deviez retenir que cinq questions de tout ce qui précède, ce seraient celles-là. Elles sont courtes, et les réponses sont très révélatrices.

1. Qui rédige les balises title et meta dans la langue cible, et sur la base de quelle recherche de mots-clés ? Si la réponse est « le traducteur les traduit », vous savez déjà à quoi vous en tenir.
2. Comment la réciprocité hreflang est-elle contrôlée, et à quelle fréquence ? Un contrôle une seule fois à la recette ne suffit pas. Le site vit, les URL changent, les clusters se cassent.
3. La mémoire de traduction m'appartient-elle, et sous quel format m'est-elle restituée ? Une hésitation sur cette question est un signal fort.
4. Que se passe-t-il concrètement quand je modifie une page dans la langue source ? Demandez à voir le process, pas une intention. Qui est alerté, dans quel outil, sous quel délai.
5. Le budget récurrent est-il ventilé par langue, et puis-je arrêter une langue sans casser les autres ? La réponse détermine votre marge de manœuvre pour les trois ans à venir.

Ce qu'il faut retenir

Le multilingue se joue dans la répartition des responsabilités, pas dans le volume de mots traduits. C'est contre-intuitif, parce que le volume est ce qu'on voit et ce qu'on facture. Mais un projet à 200 000 mots parfaitement traduits sans propriétaire identifié pour la mise à jour finira figé. Un projet à 40 000 mots avec une matrice RACI claire et un budget récurrent ventilé continuera de produire trois ans plus tard.

Un cahier des charges qui nomme un responsable par livrable et un budget par langue règle l'essentiel des litiges avant même qu'ils n'apparaissent. Ce n'est pas de la paperasse défensive. C'est simplement la condition pour que chacun sache ce qu'il doit faire, et pour que le client sache ce qu'il achète.

Chez FDSEO, ce travail se fait en amont, avec le client et ses prestataires : rédaction du cahier des charges multilingue, arbitrage d'architecture d'URL, spécification et recette hreflang, chiffrage détaillé par langue et priorisation des marchés selon leur potentiel réel. Parfois, la meilleure recommandation consiste d'ailleurs à lancer une langue de moins que prévu, et à la tenir vraiment.