Site web bilingue FR/EN pour une PME suisse

En Suisse, beaucoup de PME ont besoin de deux versions de leur site. Le français pour la Romandie. L'anglais pour les clients internationaux. Sur le papier, ça paraît simple. En pratique, c'est l'endroit où la plupart des sites se cassent les dents.

Je vais vous expliquer comment je construis un site bilingue qui tient la route. Sans jargon. Avec un point précis sur une balise que peu de gens connaissent en français : hreflang. C'est elle qui dit à Google quelle langue montrer à quel visiteur. Mal posée, elle peut faire disparaître votre version anglaise des résultats de recherche.

Pourquoi bilingue ne suffit pas

Avoir deux langues sur un site, ce n'est pas juste traduire les mots. C'est construire deux sites qui se parlent.

Voici le piège classique. Vous traduisez la page d'accueil. Vous traduisez "Services" et "Contact". Et vous vous arrêtez là. Résultat : un visiteur anglophone clique sur un article de blog, et il tombe sur du français. Il part. La confiance est cassée en trois secondes.

Un vrai site bilingue, c'est une parité complète. Chaque page française a son équivalent anglais. Chaque lien interne reste dans la bonne langue. Le menu, les boutons, les messages d'erreur du formulaire, tout suit. Si une seule pièce manque, le visiteur le sent.

J'ai vécu ce travail en vrai. Mon premier projet livré est le site d'Ahmed Ghattour & Co, un cabinet d'audit basé à Tripoli. Le site est bilingue anglais et arabe. L'arabe se lit de droite à gauche, ce qui complique tout : le menu, les marges, l'alignement des textes, tout doit basculer. Une vingtaine de pages, deux langues, deux sens de lecture. Vous pouvez voir le résultat sur la page du cas Ghattour.

Le point important : si je sais gérer anglais et arabe avec deux sens de lecture, le couple français/anglais est plus simple. Les deux langues se lisent de gauche à droite. La méthode reste la même. La parité, le routage des langues, les balises SEO : c'est le même travail, en plus facile.

Le piège du traducteur automatique

La tentation est forte. Google Translate, DeepL, un plugin qui traduit tout en un clic. Pourquoi payer une traduction quand une machine le fait gratuitement ?

Parce que ça vous coûte plus cher au final. Voici pourquoi.

D'abord, la qualité. Une traduction automatique sonne juste à 80 %. Les 20 % restants font mal. Un cabinet d'avocats genevois qui affiche une faute de ton en anglais perd en crédibilité. Vos clients internationaux jugent votre sérieux sur ces détails. Une PME suisse vend de la précision. Un texte approximatif dit l'inverse.

Ensuite, le SEO. Les plugins de traduction automatique génèrent souvent des pages que Google considère comme du contenu dupliqué ou de mauvaise qualité. Google peut décider de ne pas les afficher du tout. Vous avez deux langues sur votre site, mais une seule existe pour le moteur de recherche.

Enfin, le contrôle. Avec un plugin "tout automatique", vous ne maîtrisez plus rien. Vous ne pouvez pas corriger une phrase. Vous ne pouvez pas adapter un titre pour qu'il rende mieux en anglais. Vous subissez.

Ma méthode est différente. Je sépare le contenu du code. Chaque texte vit dans un fichier de traduction, une langue par fichier. Vous, ou un traducteur humain, écrivez les deux versions. Le site les affiche proprement. Vous gardez la main sur chaque mot.

Une machine traduit des mots. Un humain traduit une intention. Sur un site qui doit vendre, l'intention compte plus que les mots.

Concrètement, voici à quoi ça ressemble côté technique. Deux fichiers, un par langue, avec les mêmes clés :

// fr.json
{
  "contact": {
    "title": "Parlons de votre projet",
    "cta": "Demander un devis"
  }
}
 
// en.json
{
  "contact": {
    "title": "Let's talk about your project",
    "cta": "Request a quote"
  }
}

Le code appelle la clé contact.title. Selon la langue du visiteur, il affiche la bonne phrase. Aucun risque d'oublier une traduction : si une clé manque, ça se voit tout de suite.

hreflang en français normal

Voici le terme technique de l'article. Je vais le rendre simple.

hreflang est une petite balise invisible dans le code de chaque page. Son rôle : dire à Google "cette page existe en français, et voici son adresse exacte ; elle existe aussi en anglais, et voici l'autre adresse". Le mot vient de l'anglais : "href" veut dire l'adresse d'un lien, "lang" veut dire la langue.

Sans cette balise, voici ce qui arrive. Un client cherche votre cabinet sur Google en France. Google a trouvé votre page anglaise et votre page française. Il ne sait pas laquelle montrer. Il en choisit une au hasard, parfois la mauvaise. Votre visiteur francophone tombe sur l'anglais. Ou pire, Google pense que vos deux pages sont des copies et en cache une.

Avec hreflang, vous enlevez le doute. Vous dites à Google : version française pour les francophones, version anglaise pour les anglophones. Chaque visiteur arrive dans sa langue, du premier clic.

Voici à quoi ressemble la balise dans le code d'une page :

<link rel="alternate" hreflang="fr" href="https://exemple.ch/contact" />
<link rel="alternate" hreflang="en" href="https://exemple.ch/en/contact" />
<link rel="alternate" hreflang="x-default" href="https://exemple.ch/contact" />

Trois lignes, trois rôles. La première dit : "pour le français, va à cette adresse". La deuxième dit : "pour l'anglais, va à celle-là". La troisième, x-default, est la version par défaut. C'est celle que Google montre quand il ne reconnaît ni le français ni l'anglais chez le visiteur. Ici, j'ai choisi le français comme défaut, parce que la PME est suisse romande.

Trois règles que je respecte toujours, et que beaucoup oublient :

• La réciprocité. Si la page française pointe vers l'anglaise, l'anglaise doit pointer vers la française. Sinon Google ignore tout. C'est comme une poignée de main : il faut les deux mains.
• Des adresses complètes. Toujours l'adresse entière avec https://, jamais un raccourci. Google n'aime pas deviner.
• Une seule page par défaut. Un seul x-default pour tout le site, pas un par page de façon contradictoire.

Le bon côté : sur un site bien construit, ces balises se génèrent toutes seules. Je les pose une fois dans le système, et chaque nouvelle page les reçoit automatiquement. Vous n'avez rien à faire à la main. C'est exactement ce que je fais sur mes projets : la langue et les balises sont câblées dès le départ.

2 architectures : sous-domaines vs sous-dossiers

Vient une vraie décision : où vit la version anglaise de votre site ? Deux chemins possibles. Je vous explique les deux, puis je vous dis lequel je choisis.

Option 1 : les sous-domaines. Votre version anglaise vit sur une adresse à part. Par exemple en.exemple.ch. Le "en." devant le nom de domaine crée une adresse séparée. Google traite parfois ce sous-domaine comme un site presque indépendant.

Option 2 : les sous-dossiers. Votre version anglaise vit dans un dossier de votre site principal. Par exemple exemple.ch/en/. Le "/en/" après le domaine est juste un rangement interne. Tout reste sous la même adresse principale.

La différence n'est pas qu'esthétique. Elle change le SEO.

Quand votre site gagne en réputation aux yeux de Google, cette réputation se construit autour de votre nom de domaine. Avec des sous-dossiers, vos deux langues partagent la même réputation. Tout le travail profite aux deux versions. Avec des sous-domaines, Google peut séparer les comptes. Votre version anglaise repart presque de zéro pour se faire une place.

Voici un tableau simple pour comparer :

Les sous-domaines gardent un usage légitime. Si vos deux versions sont gérées par des équipes différentes, ou hébergées à des endroits différents, ça peut se justifier. Pour un grand groupe avec dix marchés, parfois oui. Pour une PME suisse avec deux langues, presque jamais.

Mon choix recommandé pour une PME suisse

Pour une PME suisse, je recommande les sous-dossiers. Adresse principale en français sur la racine, anglais dans /en/. C'est exactement ce que je mets en place par défaut.

Trois raisons concrètes.

D'abord, le SEO. Vos deux langues partagent la réputation de votre domaine. En Suisse romande, votre nom est votre actif principal. Tout doit travailler pour lui, pas se diluer sur deux adresses.

Ensuite, le coût. Une seule adresse à gérer, un seul certificat de sécurité, une seule configuration. Moins de pièces, moins de pannes, moins de facture d'entretien. Pour une PME qui paie un site, ça compte.

Enfin, la clarté. exemple.ch/en/contact, c'est lisible pour un humain comme pour un moteur. On voit la langue, on voit la page. Pas de surprise.

Voici comment je structure un site bilingue type :

• Racine en français : exemple.ch/, exemple.ch/services, exemple.ch/contact
• Anglais en sous-dossier : exemple.ch/en/, exemple.ch/en/services, exemple.ch/en/contact
• Balises hreflang posées automatiquement sur chaque page
• Un fichier de traduction par langue, parité vérifiée à chaque build

Un détail que j'ajoute toujours : sur la racine française, je ne mets pas /fr/ devant les adresses. Le français étant la langue par défaut d'une PME romande, sa version reste sur l'adresse courte. Plus propre, plus naturel pour vos clients suisses.

Un mot sur le budget, parce que la question vient toujours. Un site vitrine simple démarre à CHF 2'500. Une vitrine avancée et multilingue se situe entre CHF 3'000 et CHF 12'000, selon le nombre de pages et la complexité. Le bilingue ajoute du travail réel : double contenu, balises de langue, tests dans les deux versions. Mais c'est un travail que je connais. Le détail des tarifs est sur ma page des prix.

Pour résumer. Bilingue ne veut pas dire "traduit à moitié". Ça veut dire deux sites complets qui se parlent, avec les bonnes balises pour que Google envoie chaque visiteur dans sa langue. La traduction automatique vous fait gagner une heure et perdre des clients. Les sous-dossiers battent les sous-domaines pour une PME. Et hreflang est la pièce invisible qui fait tenir l'ensemble.

Vous avez un projet bilingue en tête ? Voyez d'abord ce que couvre mon offre vitrine. Ou regardez le cas bilingue Ghattour pour voir le travail en vrai. Vingt minutes au téléphone suffisent souvent à savoir si on avance ensemble.