Un site bilingue comporte deux types de travail : produire la première traduction, et garder les deux versions exactes. Le premier est un projet qui a une date de fin. Le second n’en a pas et, sans responsable, finit souvent par n’être fait par personne.
Ce guide est une liste de passation pour l’entreprise qui exploitera le site. Il ne suppose aucun système de contenu ni aucun contrat de maintenance particulier. L’exemple est fictif.
Recenser les pages et leur lecteur
Listez chaque page et indiquez les langues dont elle a besoin : anglais, français ou les deux. Écrivez ensuite en une ligne le lecteur et l’objectif de chaque page.
Notre entreprise fictive est Hauts-Plateaux Café, un exportateur qui vend à des acheteurs de marchés anglophones et francophones. Son site comprend une page d’accueil, une page produit, une page de conditions d’exportation et une page de contact. La page de conditions compte le plus pour les acheteurs francophones et contient les règles de livraison et de paiement. La page d’accueil présente une offre promotionnelle.
Certaines pages exigent les deux langues, d’autres une seule. Décidez-le dès maintenant : chaque page publiée en deux langues est une page à garder exacte en deux langues.
Nommer un responsable unique du fond
Choisissez la personne qui valide les faits, la terminologie, les offres et les changements, pour toutes les langues. Chez Hauts-Plateaux Café, c’est la responsable commerciale. Elle n’a pas besoin de lire le français. Elle décide si un prix, un délai de livraison ou une offre est correct, et le relecteur français suit sa décision.
Si deux personnes peuvent valider le même fait, elles finiront par valider deux versions différentes. Une source de vérité, un valideur.
Exiger une relecture du français qui vérifie le sens
La relecture du français n’est pas une comparaison ligne à ligne avec l’anglais. Le relecteur lit le français comme le ferait un acheteur et vérifie :
- Le sens. Dit-il la même chose que l’anglais approuvé, chiffres et conditions compris ?
- Le registre. Le français commercial adressé à vos lecteurs emploie normalement le « vous ». Le ton leur convient-il ?
- Le contexte local. Termes, unités, monnaies et vocabulaire juridique varient selon les pays. Une formule claire dans un marché francophone peut être ambiguë dans un autre. Précisez les pays auxquels la page française s’adresse.
La traduction automatique peut fournir un premier jet. Elle ne peut pas juger si une condition de paiement est claire pour un acheteur d’un marché donné. Traitez-la comme un brouillon qu’un humain doit relire.
Attribuer un responsable et un déclencheur à chaque page
Donnez à chaque page un responsable, un relecteur et un déclencheur. Un déclencheur est un événement qui impose une vérification : un changement de prix, un nouveau produit, une mise à jour de politique, la fin d’une offre, un changement de personne qui répond au téléphone. Prévoyez aussi une vérification calendaire, par exemple chaque trimestre, pour les pages qu’aucun événement ne touche.
Définissez le circuit des corrections urgentes. Si un délai de livraison erroné est en ligne sur la page française des conditions, qui peut le corriger aujourd’hui, qui prévient-on et qui confirme que c’est réglé ? Écrivez-le avant d’en avoir besoin.

Image d’illustration, sous licence Magnific. Le code à l’écran n’a aucun lien avec un site dont il est question ici.
Confirmer qui contrôle les accès
La propriété d’un site est en partie une question juridique, en partie une question d’identifiants. Dans le périmètre signé du projet, confirmez qui contrôle :
- Le nom de domaine. Enregistré au nom de votre organisation, avec votre propre adresse de contact.
- L’hébergement. Un compte auquel vous avez accès, pas seulement le développeur.
- Les identifiants du système de contenu. Au moins deux administrateurs nommés de votre côté.
- Les sauvegardes. Ce qui est sauvegardé, à quelle fréquence, où, et qui peut restaurer.
- L’approbation des changements. Qui peut approuver une modification du site en ligne, et comment.
Défaillance fréquente : tout va bien jusqu’à l’indisponibilité du développeur, et l’entreprise découvre que le nom de domaine est sur un compte personnel. Vérifiez-le dès le premier jour.
Savoir ce que couvre l’assistance
L’« assistance après la mise en ligne » ne signifie pas la même chose partout. Demandez-la par écrit, ventilée ainsi :
- Correction des pannes, comme un formulaire en panne ou un certificat expiré.
- Modifications de contenu, comme la mise à jour d’un prix ou l’ajout d’une page.
- Mises à jour de sécurité et de logiciels.
- Délais de réponse pour chacune.
Ne présumez pas que la maintenance est comprise dans le prix de la construction, ni qu’elle ne l’est pas. Les pages publiques de Chwezi présentent la conception et le développement de sites comme un service, mais ne définissent ni formule de maintenance type ni conditions de propriété : traitez la propriété, le système de contenu et l’assistance comme des points à régler dans chaque cahier des charges.
Le registre de responsabilité des contenus bilingues
Tenez ce registre là où le responsable peut l’ouvrir. Une ligne par page et par langue.
| Page et URL | Langue | Responsable du fond | Relecteur français | Déclencheur de mise à jour | Détenteur des accès | Sauvegardes et assistance | Dernière validation | Prochaine vérification |
|---|---|---|---|---|---|---|---|---|
| Conditions d’export, /fr/conditions-export/ | Français | Responsable commerciale | Relecteur francophone natif, secteur export | Tout changement de livraison ou de paiement | Responsable des opérations | Sauvegarde hebdomadaire ; modifications de texte pendant les heures du contrat | 3 mars | 3 juin ou changement de conditions |
| Accueil, /en/ | Anglais | Responsable commerciale | Sans objet | Nouvelle offre ou fin d’offre | Responsable des opérations | Idem | 3 mars | Fin de l’offre en cours |
Ajoutez une ligne chaque fois que vous publiez une page. Ne supprimez une ligne que si la page est retirée.
À adapter à vos lecteurs et à vos pays
Priorisez les lecteurs que vous avez réellement. Regardez comment ils atteignent le site : sur quels appareils et avec quelles connexions, d’après vos propres statistiques de visite, sans les supposer. Pour les pages françaises, choisissez les pays d’Afrique francophone que vous servez et confirmez leurs usages linguistiques, votre offre sur place et le contexte juridique avant de publier. Les consignes de Google sur les versions localisées des pages (en anglais) expliquent comment relier les versions linguistiques entre elles. Le guide du W3C sur l’implication des utilisateurs dans les projets web (en anglais) sert de référence quand vous testez les pages avec de vrais lecteurs, y compris des personnes en situation de handicap.
Sources et périmètre
- Google Search Central, Localized versions of your pages (en anglais). Consignes de mise en œuvre ; aucune garantie de classement.
- W3C Web Accessibility Initiative, Involving users in web projects for better, easier accessibility (en anglais). Conseils de méthode ; leur lecture n’établit aucune conformité.
- Chwezi Core Systems, Développement de sites web. Description publique de l’offre ; elle ne prouve ni un résultat ni une formule de maintenance définie.
- Hauts-Plateaux Café est fictif. Ses pages, rôles et dates sont inventés pour illustrer la méthode.
Questions fréquentes
- Qui doit valider le contenu : l’agence web ou l’entreprise ?
- L’entreprise. Une agence peut construire et publier, mais seule votre équipe sait si un prix, une description de service ou une politique est exact. Nommez le valideur dans le périmètre du projet.
- La traduction automatique suffit-elle pour la version française ?
- Elle peut fournir un premier jet. Elle ne peut pas confirmer qu’un prix, un terme juridique ou un ton convient à vos lecteurs francophones. Un lecteur français qui connaît votre secteur doit vérifier le sens, le registre et le contexte local avant publication.
- Quels accès dois-je détenir moi-même ?
- Au minimum l’enregistrement du nom de domaine, le compte d’hébergement et l’identifiant administrateur du système qui contient vos pages, ainsi qu’un accès aux sauvegardes. Vérifiez qu’ils sont au nom de votre organisation, non au compte personnel d’un développeur.
- L’assistance après la mise en ligne inclut-elle les modifications de contenu ?
- Seulement si le périmètre signé le prévoit. Beaucoup de contrats couvrent la correction des pannes, mais pas la modification des pages. Demandez par écrit ce qui est une panne, ce qui est une modification et le délai de chacune.