Ce que vous payez vraiment pour un site web en Suisse
TL;DR — Le prix d'un site reflète la manière dont il est construit, pas son nombre de pages. Ne payez pas cinq chiffres pour un template, n'acceptez pas que le SEO technique soit une ligne optionnelle, et comptez combien de personnes se trouvent entre vous et celle qui écrit le code, parce que vous les payez toutes. Le seul coût qui ne figure sur aucun devis, c'est la dette technique.
Deux offres arrivent dans la même boîte mail. L'une annonce 500 francs, l'autre 35 000. Même brief, même entreprise, mêmes trois pages de besoins.
La première paraît trop belle pour être vraie, la seconde donne l'impression que quelqu'un a ajouté un zéro. Et dans aucun des deux documents il n'y a de quoi comprendre d'où sortent ces chiffres, alors que vous devez trancher entre les deux.
Je construis des sites pour des entreprises suisses depuis quinze ans, la plupart du temps seul. C'est la question qu'on me pose le plus souvent, en général avec précaution, par quelqu'un qui se doute qu'il va payer trop cher sans pouvoir le prouver. La réponse tient en une phrase : ce que vous payez n'a presque rien à voir avec ce que vous voyez.
Pourquoi facturer à la page n'a aucun sens
Demandez un devis et vous recevrez souvent un tableau : accueil, à propos, services, contact, multipliés par un tarif. C'est lisible, c'est rassurant, et c'est emprunté à l'imprimerie, où une page était réellement une unité de coût.
Une page n'est pas une unité de travail
Une seule page avec un configurateur, un flux de réservation et une logique de prix me prendra des semaines. Vingt pages de texte et d'images, parfois trois jours. Le nombre de pages ne dit rien de ce qu'il faut concevoir, développer, tester et maintenir.
Quand on vous facture ainsi, soit on construit toujours la même chose quel que soit le client, soit on espère que vous ne demanderez pas ce qu'il y a dedans. La vraie question est ailleurs : quelle est la partie la plus difficile de ce site, et qui va la construire.
La couche entre vous et le travail
Dans une agence structurée, une partie de votre budget finance le travail et une autre finance l'organisation autour du travail : chef de projet, account manager, directeur créatif, puis un freelance quelque part au bout de la chaîne qui écrit réellement le code.
Cette structure existe pour une raison, une grande équipe a besoin de coordination. Mais quelqu'un la paie, et sur un projet de PME, ce quelqu'un c'est vous. J'ai passé des années dans ce modèle à Berlin : une décision qui me prend dix minutes aujourd'hui demandait une semaine de réunions, et le site n'en était pas meilleur pour autant.
Ce n'est pas un argument contre les agences, elles restent le bon choix dès qu'un projet dépasse ce qu'une personne peut tenir. C'est un argument contre le fait de payer cette structure sans savoir que vous la payez.
1. Vous payez un système, pas un thème
Un template acheté, avec votre logo posé dessus, ne vaut pas une facture à cinq chiffres. Ce qui justifie un budget, c'est ce qui est construit pour vous et qui n'existait pas avant.
Où l'argent devrait vraiment aller
Les templates sont conçus pour couvrir tous les cas d'usage possibles, du restaurant au cabinet d'avocats. Ils embarquent donc des sliders, des plugins et des scripts auxquels vous ne toucherez jamais, et tout cela se charge quand même dans le navigateur de vos visiteurs. Pages plus lentes, Core Web Vitals dégradés, et une dépendance de plus le jour où un plugin cesse d'être maintenu.
Ce que vous devriez payer, c'est l'inverse : des composants pensés pour votre activité, un code que vous ou votre prochain développeur pouvez lire, et une page rapide parce qu'il n'y a rien d'inutile dedans. C'est l'essentiel de mon travail sur un projet : pas ajouter des fonctionnalités, mais retirer tout ce qui ne justifie pas sa place.
2. Le SEO technique n'est pas une option
Si un devis liste « optimisation SEO » comme une ligne que vous pouvez retirer pour tenir le budget, relisez attentivement le reste du devis. Ce n'est pas une prestation qu'on ajoute à la fin, c'est une manière de construire.
Soit c'est dans le build, soit ça n'existe pas
Certaines choses ne peuvent se faire qu'au moment de la construction :
- Une hiérarchie de titres qui suit le contenu réel, pas la mise en page
- Un balisage Schema.org en JSON-LD, pour que les moteurs et les assistants IA comprennent ce qu'est votre entreprise et ce qu'elle vend
- Un hreflang correct entre vos versions française, allemande et anglaise
Ce dernier point compte plus en Suisse que presque partout ailleurs, parce qu'un site suisse, c'est souvent trois sites. Mal signaler les langues, c'est servir la page allemande à un lecteur lausannois. J'ai déjà été appelé pour corriger exactement ça, et rattraper après coup coûte toujours plus cher que le faire au premier jour.
Même logique pour être cité par ChatGPT, Claude ou Perplexity : ces outils lisent la structure avant de lire la prose. Sans structure, vous êtes invisible pour eux, et c'est une part croissante de la manière dont on cherche un prestataire aujourd'hui.
3. Comptez les intermédiaires
Chaque passage de relais perd quelque chose : commercial vers designer, designer vers développeur, développeur vers celui qui maintiendra le site ensuite. Pris isolément ce n'est rien, mais additionné cela se voit dans le délai, dans le résultat et sur la facture.
Ce que change le travail en direct
Vous expliquez votre métier une fois. La personne qui dessine l'interface est celle qui écrit le code de production, donc rien ne se perd entre la maquette et ce qui fonctionne réellement sur un téléphone. Les décisions prennent un après-midi au lieu d'un sprint.
Et quand quelque chose doit changer deux semaines après la mise en ligne, vous écrivez directement à celui qui l'a construit, sans passer par un ticket ni par un avenant. Il y a une contrepartie, autant la nommer : un studio d'une personne a des limites de volume et de projets en parallèle. Pour un site de PME suisse, ce n'est presque jamais la contrainte. Pour une plateforme déployée sur cinquante marchés, si.
Ce qu'il vous reste à la fin
La vraie différence entre un site bon marché et un bon site apparaît en deuxième année. Le premier fonctionne encore, jusqu'au jour où une mise à jour casse le formulaire de contact, ou jusqu'au moment où vous voulez ajouter une langue et découvrez que la structure ne le permet pas.
Alors vous reconstruisez, et vous avez payé deux fois. Personne ne vous avait annoncé cette seconde facture, parce qu'elle n'apparaît nulle part dans le devis initial : elle se construit silencieusement, ligne de code après ligne de code.
La dette technique est le seul coût qui ne figure sur aucun devis
Un site construit correctement se modifie, s'étend et se transmet au développeur suivant sans opération de sauvetage. Le code vous appartient, la structure accepte une langue de plus, et vous pouvez partir quand vous voulez sans que rien ne soit verrouillé derrière le contrat de maintenance de quelqu'un d'autre.
C'est dans cet ordre que je travaille, et c'est ce qui décide du prix bien avant le design : d'abord l'architecture et les contraintes, ensuite la vitesse d'exécution. Un budget de développement web honnête finance la première partie. Sautez-la et vous n'avez pas économisé, vous avez simplement déplacé la dépense de deux ans.
Alors, que demander avant de signer ?
Demandez qui écrit le code, demandez ce qui se passe si vous voulez partir, et demandez à voir le site dont ils sont le plus fiers, sur un téléphone, en 4G. Les réponses vous en diront plus long que le chiffre en bas du devis, et elles ne coûtent rien à obtenir.
👉 Envoyez-moi ce que vous avez, je vous donne un périmètre technique honnête, y compris les parties dont vous n'avez pas besoin. Prendre contact