PHP ou JavaScript : quelle technologie choisir pour un site d’entreprise

La question se pose sous la forme « PHP ou JavaScript », mais en pratique presque personne ne choisit un langage. Vous choisissez entre un système tout prêt, qui se trouve tourner sur PHP, et une application écrite pour vous, ce qui signifie aujourd’hui, le plus souvent, JavaScript. Tout le reste découle de cette seule décision.

Ce texte montre où passe la frontière entre les deux, ce que chacun coûte réellement — à la construction et ensuite —, et les trois questions qui décident de l’affaire bien mieux que le nom du langage : qui entretiendra ce site dans trois ans, ce que coûtera de changer d’avis, et ce que chacun des deux modèles demande par version linguistique.

L’un s’exécute sur le serveur, l’autre dans le navigateur

PHP n’a qu’un lieu de travail : le serveur. Il reçoit une requête, assemble la page, renvoie du HTML terminé. Le visiteur ne voit jamais une ligne de PHP — il en voit le résultat.

JavaScript a commencé dans le navigateur, et il y fait ce que PHP ne sait pas faire : réagir à un clic sans recharger la page. Depuis Node.js, il tourne aussi sur le serveur — et c’est de là que vient toute la confusion de cette comparaison. PHP a un lieu, JavaScript en a deux, si bien que les présenter comme deux concurrents de la même discipline induit en erreur dès la première phrase.

Une conséquence utile, avant d’aller plus loin : le JavaScript de votre site existera de toute façon. Un site WordPress en contient, ne serait-ce que pour le menu mobile et le formulaire de contact. La vraie question n’est donc jamais « avec ou sans JavaScript », mais où le travail est fait : dans le navigateur de chaque visiteur, ou une fois pour toutes sur le serveur.

Ce que cela change pour votre site

La frontière ne passe pas entre les langages : elle passe entre un site et un outil. Si le contenu est destiné à être lu, un système tout prêt suffit. Si le visiteur doit y calculer, réserver ou configurer quelque chose, il s’agit déjà d’une application, et la décision se prend autrement.

Si vous ne savez pas encore de quel côté de cette frontière se trouve votre projet, commencez par la comparaison des plateformes — nous y reprenons le même arbitrage du point de vue du système, et non du langage.

La vraie question : qui entretiendra ce site dans trois ans

C’est la question qui devrait venir en premier et qui vient presque toujours en dernier. Un site n’est pas une livraison, c’est une dépendance : quelqu’un devra y appliquer des mises à jour, réparer ce qui casse et ajouter ce que vous n’aviez pas prévu. Le choix technologique détermine qui peut être ce quelqu’un.

Du côté de PHP, la réserve de personnes est la plus large qui existe sur le web. Ce n’est pas une impression : PHP fait tourner 70,2 % des sites dont le langage serveur est connu, et WordPress à lui seul représente 40,7 % de tous les sites et 58,9 % du marché des systèmes de gestion de contenu (W3Techs, relevés le 8 septembre 2026 ; ces chiffres bougent d’un mois à l’autre, il vaut la peine de les vérifier à la source). La conséquence concrète, pour une entreprise, est simple : si votre prestataire disparaît, cesse son activité ou vous déçoit, le suivant se trouve sans difficulté et reprend un site WordPress sans période d’apprentissage.

Du côté d’une application écrite pour vous, cette réserve est plus petite — et la qualité de la passation compte donc beaucoup plus. Ce n’est pas une objection décisive ; c’est une exigence à formuler dans le contrat, pas à découvrir plus tard. Quatre questions, à poser avant la signature et non à la réception :

• Où se trouve le code source, et à quel nom ? Le dépôt doit appartenir à votre entreprise, avec un accès d’administration pour vous. Un dépôt chez le prestataire, sur son compte personnel, est une dépendance que vous découvrirez au pire moment.
• Quelqu’un d’autre que l’auteur peut-il mettre en ligne une modification ? Si la réponse suppose une machine précise et une personne précise, vous n’avez pas un site, vous avez un artisan.
• La construction est-elle reproductible depuis une machine vierge ? Autrement dit : quelqu’un qui récupère le dépôt et suit la documentation obtient-il un site qui tourne ? La réponse se teste, et elle se teste avant de payer la dernière tranche.
• Qu’est-ce qui est documenté, et où ? Pas un manuel de trois cents pages : la liste des variables d’environnement, la procédure de mise en ligne, la procédure de restauration d’une sauvegarde. Trois pages suffisent, et leur absence coûte des jours.

L’entretien n’a pas non plus la même forme des deux côtés. Un site WordPress demande des mises à jour régulières du cœur, du thème et des extensions, et chacune peut casser quelque chose parce que personne ne les a toutes testées ensemble — dans notre propre calculateur, nous provisionnons 5 à 10 heures par an rien que pour les mises à jour de sécurité d’un site WordPress, et c’est notre hypothèse de travail, pas une étude. Une application écrite pour vous n’a pas d’extensions à mettre à jour, mais elle a des dépendances et des versions majeures de son cadriciel, qui arrivent moins souvent et demandent plus de travail à chaque fois. Dans les deux cas, le budget d’entretien n’est pas nul, et un devis qui le présente comme nul décrit un site que personne n’entretiendra.

Ce que coûte de changer d’avis

Le second angle que les devis ignorent : vous ne choisissez pas pour toujours, et le coût de la sortie fait partie du prix d’entrée.

Ce qui est portable, quelle que soit la technologie de départ : le nom de domaine, les textes, les images, les adresses de vos pages — à condition de poser des redirections —, et l’intention de design. Ces choses vous appartiennent et se transportent.

Ce qui ne l’est pas : le thème, les extensions, les composants écrits sur mesure, et surtout les mises en page construites avec un éditeur visuel. C’est le point le plus sous-estimé. Un constructeur de pages ne stocke pas « un titre, deux colonnes, une image » : il stocke son propre balisage, avec ses propres conteneurs, à l’intérieur de la base de données. Exporter ce contenu vous rend du HTML plein d’enveloppes qui n’ont de sens que pour l’outil qui les a écrites. Vos textes sortent ; votre mise en page, non. Refaire quarante pages de mise en page représente exactement le même travail dans les deux sens de migration, et c’est cette ligne-là, pas la technologie, qui rend un changement d’avis coûteux.

D’où une question à poser avant la signature, et dont la réponse en dit long : « comment est-ce que je sors mon contenu d’ici, dans quel format, et est-ce que quelqu’un l’a déjà fait ? » Un prestataire qui a la réponse sous la main vous vend un site. Un prestataire que la question gêne vous vend un abonnement.

Deux remarques sur les directions réelles. De WordPress vers une application sur mesure, la migration est fréquente et le contenu s’exporte en général proprement, surtout s’il a été écrit dans l’éditeur standard plutôt que dans un constructeur visuel. Dans l’autre sens, la migration est plus rare et sa cause est presque toujours humaine : la personne qui maintenait l’application n’est plus là. C’est précisément le risque que la section précédente cherche à fermer.

Le cas multilingue : ce que chaque choix vous demande par langue

Ici, un site d’entreprise existe rarement en une seule langue. Français et allemand, souvent l’anglais, parfois l’italien. Ce n’est pas une option en fin de devis : c’est le cas normal, et c’est l’un des endroits où les deux modèles se comportent le plus différemment.

Du côté de WordPress, le multilinguisme ne fait pas partie du cœur. Il arrive par une extension, et cette extension décide de la façon dont les traductions sont stockées : soit comme des documents séparés reliés entre eux, soit comme plusieurs sites d’un même réseau. Trois conséquences pratiques en découlent, et aucune n’est théorique :

• L’extension devient une dépendance que vous ne pouvez plus retirer sans perdre le lien entre les versions. Elle n’est plus un module : elle fait partie du modèle de vos données.
• Chaque extension que vous ajoutez ensuite doit savoir composer avec elle. Un module de formulaire, une boutique, un plan de site : chacun doit connaître le concept de langue, faute de quoi vous obtenez un formulaire en français sur une page en allemand.
• Les textes qui ne sont pas dans vos pages échappent souvent au système. Les libellés du thème, les messages d’erreur, les boutons d’une extension : chacun se traduit à un endroit différent, et c’est là que se logent les phrases oubliées que vos clients germanophones finissent par signaler.

Du côté d’un système headless ou d’une application écrite pour vous, la langue est en général une propriété du champ lui-même. Un document porte son titre en français et en allemand ; le lien entre les deux versions n’est pas ajouté, il est structurel. Cela coûte plus cher à mettre en place et cela rend impossibles les oublis décrits plus haut, parce qu’un champ non traduit est visible dans l’interface d’édition, pas découvert par un client.

Ce que cela représente en francs, dans notre grille : l’option multilingue vaut 1 750 CHF, et c’est la mise en place technique. La traduction professionnelle de toutes les pages coûte à peu près autant une seconde fois — c’est notre hypothèse de travail et elle est inscrite telle quelle dans notre calculateur. La technique est la petite moitié de l’addition ; le contenu est la grande. Toute offre qui chiffre le multilinguisme sans dire un mot des traductions décrit la moitié du travail.

Enfin, un mécanisme qui n’apparaît que plus tard, et qu’il vaut mieux connaître avant : le nombre de pages est multiplié par le nombre de langues. Sur un site pré-généré, trois langues signifient trois fois plus de pages à produire à chaque mise en ligne et à garder en cache — ce qui allonge la construction et occupe du disque. Sur un système qui assemble la page à chaque requête, rien n’apparaît au moment de la construction, parce que le travail a simplement été déplacé vers le cache, où il se voit tout autant. Aucun des deux modèles ne fait disparaître le coût de la troisième langue ; ils le placent à des endroits différents de votre facture.

Notre propre site est dans ce cas : il existe en quatre versions linguistiques, et la partie coûteuse n’a jamais été la technique.

Ce que cela coûte, en francs

Deux repères valent mieux qu’un : le milieu du marché, pour savoir si un devis est normal, et un vrai tarif, pour savoir d’où part une conversation.

Le milieu du marché suisse, d’après l’étude de prix Beyondweb (mise à jour le 2 septembre 2026, 161 agences suisses passées en revue, prix tirés de 36 d’entre elles) : la médiane d’une page d’atterrissage est de 1 200 CHF (22 points de prix), celle d’un site vitrine de 3 100 CHF (33 points), celle d’un site étendu de 12 000 CHF (10 points). Une médiane indique un ordre de grandeur, pas un prix : votre cas peut se situer n’importe où dans la fourchette.

Notre tarif, hors taxes, tel qu’il figure dans le calculateur de coût d’un site et vérifiable ligne par ligne : une page d’atterrissage part de 1 750 CHF, un site vitrine de 3 500 CHF, un site étendu de 7 500 CHF. Le choix du système s’ajoute par-dessus : WordPress, 1 250 CHF ; CMS headless, 3 000 CHF. Le multilinguisme, on l’a vu, 1 750 CHF.

Deux choses méritent d’être lues dans ces chiffres, et ce ne sont pas celles qu’on attend.

La première : l’écart entre les deux systèmes est de 1 750 CHF, pas d’un ordre de grandeur. Ce n’est pas de là que vient la différence de prix entre un site WordPress à quelques milliers de francs et une application à plusieurs dizaines de milliers. Cette différence vient de l’ampleur de ce qui est construit — pages, gabarits, intégrations, fonctionnalités —, pas du nom du système.

La seconde : la différence ne vient pas du langage, elle vient de ce que vous achetez. Du côté de WordPress, vous achetez en général un thème tout fait que l’on adapte. Du côté du JavaScript, vous commandez un projet. Le même prestataire vous montera un site vitrine sur WordPress en trois jours et le même site vitrine « depuis zéro » en trois semaines. Vous payez du travail, pas une technologie.

Il faut ajouter l’autre moitié de la facture, celle qui court ensuite. Notre forfait d’entretien est de 50 CHF par mois pour un site vitrine et de 200 CHF par mois pour une boutique en ligne ; en dehors d’un forfait, une heure de développement est facturée 75 CHF. Ces montants ne dépendent pas du langage non plus : ils dépendent de ce que le site fait et de la fréquence à laquelle il change. Le découpage complet est dans le texte consacré aux coûts.

Le seul piège technique qui coûte vraiment de la visibilité

Si un site se rend exclusivement dans le navigateur — ce que fait une application React classique sans complément — le robot du moteur de recherche reçoit au premier passage une page à peu près vide. Google s’en tire en général, mais cela prend du temps et ne finit pas toujours bien.

La solution s’appelle le rendu côté serveur et elle est intégrée à Next.js. Notre propre site repose exactement là-dessus : Next.js avec Payload CMS, le HTML étant produit sur le serveur — c’est pourquoi l’article que vous lisez est visible intégralement par un robot sans exécuter la moindre ligne de JavaScript.

C’est le seul endroit, dans toute cette comparaison, où un mauvais choix technique coûte réellement de la visibilité. Si quelqu’un vous propose « une application en React », demandez si les pages seront rendues sur le serveur. L’écart entre les réponses « oui » et « pourquoi faire ? » vaut plus que tout le reste de la conversation. Nous le traitons en détail dans le texte sur les différences entre Next.js et React.

Un mot sur la performance, puisque la question arrive toujours à cet endroit : nous ne publierons pas de comparaison chiffrée entre les deux langages, parce que nous n’avons pas de mesure défendable à citer — et une mesure inventée serait pire qu’aucune. Le mécanisme, lui, se transpose : une page assemblée à chaque requête coûte du travail à chaque visite, une page pré-générée coûte ce travail une fois. Dans les deux cas, ce qui décide du résultat, c’est ce qui se trouve devant — cache, réseau de distribution, taille des images — bien plus que le langage derrière. Un WordPress correctement mis en cache est rapide ; une application JavaScript mal construite est lente.

Où PHP est franchement le meilleur choix

Cette section existe parce qu’un texte écrit par une société qui construit des applications JavaScript doit dire aussi quand elle ne serait pas le bon prestataire.

• Quand le budget se situe au niveau de la médiane du marché ou en dessous. À ce niveau, l’alternative à un système tout prêt n’existe pas vraiment : ce que vous obtiendriez pour la même somme en développement sur mesure serait moins complet et moins fini.
• Quand le site présente une offre et publie des articles, sans rien calculer. C’est exactement ce pour quoi ces systèmes ont été faits, et le faire autrement revient à payer pour de la liberté dont vous ne vous servirez pas.
• Quand une extension mûre fait déjà précisément ce dont vous avez besoin. Réservation, catalogue, boutique simple : réécrire ce que des milliers d’entreprises utilisent déjà est rarement un bon emploi de votre budget.
• Quand l’équipe veut tout modifier elle-même, y compris la mise en page, sans passer par personne.
• Quand le site doit survivre à votre relation avec nous. C’est un argument sérieux et nous le posons nous-mêmes : plus la réserve de personnes capables de reprendre le site est large, moins vous dépendez d’un prestataire donné.

Où JavaScript est franchement le meilleur choix

• Quand le site calcule quelque chose. Configurateur, calculateur, simulateur, espace client, réservation avec des règles : à partir de là, vous ne commandez plus un site mais un outil, et un système tout prêt doit être tordu pour y arriver. Tordre coûte plus cher qu’écrire.
• Quand la performance est une exigence contractuelle et non un souhait — parce qu’il faut alors pouvoir contrôler ce qui est envoyé au navigateur, ligne par ligne.
• Quand le contenu doit alimenter plusieurs destinations : le site, une application, l’écran d’un partenaire. Un contenu stocké comme des données se republie ; un contenu stocké comme une page ne se republie pas.
• Quand la rédaction a besoin d’un cadre strict — des champs, des validations, des gabarits qui empêchent de casser la mise en page — plutôt que d’une page libre où tout est possible, y compris le pire.
• Quand le nombre de versions linguistiques rend un modèle structurel rentable, pour les raisons exposées plus haut.

Comment nous choisissons chez nous

Nous avons construit notre site avec Next.js et un CMS headless, et ce n’était pas un choix idéologique. Il découle du fait que nous y avons huit calculateurs, des quiz et des rapports chiffrés — c’est-à-dire une application déguisée en site. À ce niveau d’exigence, un système tout prêt aurait dû être tordu, et tordre coûte plus cher qu’écrire.

En parallèle, nous entretenons pour des clients des sites sous WordPress, et nous ne traitons pas cela comme une catégorie inférieure. Si l’on nous confiait aujourd’hui le site vitrine d’une entreprise locale avec un budget situé au niveau de la médiane du marché, nous le ferions sous WordPress — parce qu’à ce montant, toute autre solution serait moins bonne pour le client, et non pour nous.

La règle honnête tient en une phrase : la technologie doit découler du périmètre et du budget, et non l’inverse. Si un prestataire commence la conversation par le nom d’un cadriciel avant d’avoir demandé ce que le site doit faire, c’est un signal d’alerte, quel que soit le cadriciel cité.

Trois signaux que la question est mal posée

1. La conversation commence par le langage et non par les fonctions. « Nous voulons du Next.js », sans une phrase sur ce que le site doit faire, finit en surcoût ou en reprise complète.
2. Quelqu’un déconseille PHP sans avoir demandé le budget. Au niveau de la médiane du marché et en dessous, l’alternative à un système tout prêt n’existe en général pas.
3. Quelqu’un promet une application en JavaScript au prix d’un site vitrine. Les médianes citées plus haut disent de quel ordre de grandeur on parle — le reste est un coût qui apparaîtra plus tard.

D’où viennent ces chiffres

Les montants en francs suisses de cet article sont de deux natures, et le mélange des deux est précisément ce qu’il faut éviter.

Les nôtres — 1 750, 3 500 et 7 500 CHF pour les trois tailles de site, 1 250 CHF pour WordPress et 3 000 CHF pour un CMS headless, 1 750 CHF pour le multilinguisme, 50 et 200 CHF par mois d’entretien, 75 CHF de l’heure — sont les lignes de nos propres calculateurs, hors taxes, identiques à celles publiées dans la rubrique consacrée au prix d’un site web.

Ceux du marché proviennent de l’étude de prix Beyondweb, mise à jour le 2 septembre 2026, qui a passé en revue 161 agences suisses et tiré des prix de 36 d’entre elles : 1 200 CHF de médiane pour une page d’atterrissage (22 points de prix), 3 100 CHF pour un site vitrine (33 points), 12 000 CHF pour un site étendu (10 points). Nous ne citons pas le palier supérieur, qui ne repose que sur deux points de prix.

Les parts de marché viennent de W3Techs, relevées le 8 septembre 2026 : PHP sur 70,2 % des sites dont le langage serveur est connu, WordPress sur 40,7 % de tous les sites et 58,9 % du marché des systèmes de gestion de contenu. Elles ne signifient pas que PHP est le meilleur choix pour tous les projets : elles signifient qu’il est l’état par défaut du web. L’argument « PHP est dépassé » est un argument sur la mode, pas sur ce qui fonctionne.

Ce que nous ne donnons pas, et pourquoi : aucune comparaison chiffrée de performance entre les deux langages. Nous n’avons pas de mesure propre à publier pour cet usage, et transposer un test de laboratoire vers votre site produirait un chiffre qui aurait l’air vérifié sans l’être. À la place, vous avez le mécanisme — qui, lui, se transpose.

Et ensuite

Si vous savez déjà qu’il vous faut un système tout prêt, lisez la comparaison des plateformes et vérifiez quel hébergement lui conviendra. Si vous penchez plutôt vers une application, commencez par les coûts : ce sont eux, et non la technologie, qui trancheront le périmètre de la première version.