Site web moderne : ce que veulent dire les mots des devis, et ce qui en découle

Les devis pour un site web se ressemblent tous aujourd’hui : à côté du prix se tient une liste de mots qu’on n’a aucun moyen d’évaluer. Serverless. Edge. Site statique. API-first. Multilingue. PWA. Parfois WebAssembly.

Aucun d’eux n’est bon ou mauvais en soi. Chacun décrit une manière de faire quelque chose — et non le fait que cela vous serve à quelque chose. La différence entre un bon devis et un devis cher se joue exactement là : derrière le mot se tient-il un besoin qu’on sait nommer, ou a-t-il été écrit parce qu’il fait bonne figure ?

Ce texte est le lexique de ces mots pour la personne qui signe le contrat, pas pour celle qui écrit le code. Pour chacun : ce qu’il veut dire, quand il a réellement du sens chez vous, quand il est un excès, et la question à poser au prestataire pour trancher en une phrase.

Ce que « moderne » veut dire une fois le devis signé

Il vaut la peine de poser un point de référence, parce que le mot « moderne » dans un devis porte d’ordinaire sur l’apparence, alors que ce qui décide se trouve ailleurs. La recherche d’un design de site web moderne est une vraie demande et elle a ses vraies réponses ; simplement, elle ne recouvre pas les quatre choses ci-dessous, et ce sont elles que votre visiteur ressent.

Un site moderne est un site qui répond vite à la première visite, qui fonctionne sur un téléphone aussi bien que sur un ordinateur, qui vous laisse changer le contenu sans développeur et qui ne s’effondre pas quand il arrive dix fois plus de monde que d’habitude. Quatre propriétés, toutes vérifiables sans croire personne sur parole.

Une première réponse rapide. Dans le navigateur, outils de développement, onglet « Network » : activez la limitation de débit sur un profil mobile et rechargez la page. Ce qui vous intéresse, c’est le temps jusqu’à la première réponse du serveur et le moment où le contenu principal apparaît — pas le moment où le dernier script finit de se charger. Faites la même mesure chez un concurrent : un chiffre sans point de comparaison ne dit pas grand-chose. Comment mesurer pour que le résultat signifie quelque chose, nous le détaillons dans notre texte sur les tests d’un site.

Le téléphone comme l’ordinateur. La question n’est pas de savoir si la page « s’adapte », mais si l’on peut y faire ce pour quoi on est venu. Parcourez votre propre chemin de conversion sur un téléphone, d’un seul pouce, avec un réseau médiocre : trouver la prestation, ouvrir le formulaire, envoyer. L’endroit où vous attrapez votre ordinateur est l’endroit où le client abandonne.

Le contenu sans développeur. Ouvrez l’interface d’administration — le back-office, dans le vocabulaire des devis — et comptez combien de ces choses vous changerez vous-même : le texte de la page d’accueil, une entrée du menu, un nouvel article, l’image d’un en-tête, un prix dans un tableau. Ce qui ne figure pas sur cette liste sera, pour les années à venir, une ligne de facture pour « petites retouches ». Et comptez-les dans chaque version linguistique : un back-office où l’on modifie le français et où l’allemand repart chez le prestataire n’est pas une interface de gestion de contenu, c’est une interface de gestion d’une langue.

La résistance à un pic de trafic. La question au prestataire est précise : que se passe-t-il avec dix fois plus de trafic, et d’où le sait-on ? Une réponse « ça tiendra », sans test de charge ni indication de ce qui passe exactement à l’échelle, est une déclaration, pas une réponse.

Tous les mots de la liste qui suit sont des moyens d’obtenir l’une de ces quatre choses — pas des objectifs en soi. La question qui tranche devant un devis n’est donc pas « est-ce moderne ? », mais : laquelle de ces quatre propriétés cela améliore précisément, et de combien ?

Une réserve tout de suite : certaines de ces technologies améliorent des choses qui, dans votre cas, n’ont pas besoin d’être améliorées. Cela ne veut pas dire que le prestataire cherche à vous tromper — cela veut dire qu’il construit comme il construit d’habitude. La question du paragraphe précédent suffit à faire la part des deux.

Huit mots de devis, un par un

Chacun dans la même disposition : ce que cela veut dire, quand cela a du sens chez vous, quand c’est un excès. L’ordre suit la fréquence avec laquelle on les rencontre dans les offres.

Serverless, ou « sans serveur » — vous payez l’exécution, pas la machine

Ce que cela veut dire. Le code s’exécute à la demande, chez un fournisseur, sans que personne n’entretienne un serveur. Il n’y a pas de machine qui tourne vingt-quatre heures sur vingt-quatre et coûte autant la nuit qu’en pleine pointe — il y a une facture pour les appels réellement effectués.

Quand cela a du sens chez vous. Quand le trafic est irrégulier : une boutique avec une saison, des inscriptions à un événement, une campagne après laquelle il arrive en deux jours autant de monde qu’en un trimestre ordinaire. Le serverless passe à l’échelle tout seul et ne demande à personne d’ajouter de la puissance à minuit. C’est aussi pertinent quand vous n’avez personne pour administrer un serveur — puisqu’il n’y a rien à administrer.

Quand c’est un excès. Avec un trafic stable et prévisible, un hébergement ordinaire est moins cher et plus simple à lire sur une facture.

Le piège, à régler dans le contrat et non après coup. Dans un modèle « vous payez l’exécution », la facture n’a pas de plafond tant que personne n’en pose un. Une boucle dans le code qui s’appelle elle-même, ou un robot qui martèle votre formulaire pendant le week-end, produisent des exécutions exactement comme de vrais clients — à ceci près que personne ne le remarquera avant l’arrivée de la facture. Sur un abonnement fixe, une erreur de ce genre se termine par un site plus lent ; ici, elle se termine par un montant. D’où la question : des limites de dépense et une alerte au dépassement sont-elles configurées, et que se passe-t-il une fois la limite atteinte — le site s’arrête, ou la facture continue de monter ? Les deux réponses peuvent être correctes, encore faut-il savoir laquelle vous achetez.

Une seconde question s’ajoute ici et se pose rarement ailleurs : où le code s’exécute-t-il, et où atterrissent les données qu’il traite ? Chez un fournisseur mondial, la réponse par défaut n’est pas forcément celle que vous auriez choisie. Si vous servez des clients établis dans l’Union européenne, le RGPD vous suit quelle que soit la localisation de votre entreprise dès lors que vous traitez leurs données — et cette question s’obtient en une minute avant la signature, en trois semaines après.

Edge, ou la diffusion en périphérie — le contenu plus près de la personne

Ce que cela veut dire. Au lieu d’une machine unique dans une ville unique, le site est servi depuis le nœud le plus proche de la personne qui l’ouvre. La même idée qu’un CDN — le mot que vous verrez réellement écrit dans le devis — mais étendue des fichiers au code.

Quand cela a du sens chez vous. Quand vos clients sont dispersés géographiquement : vente sur plusieurs marchés, clientèle sur un autre continent, application utilisée en déplacement. La différence sur le temps de première réponse se ressent alors sans aucune mesure.

Quand c’est un excès. Quand vous vendez dans un seul pays et que le serveur s’y trouve déjà. La distance que la périphérie raccourcit est alors courte, et la complexité s’ajoute : du code réparti sur des nœuds se diagnostique moins facilement le jour où quelque chose ne casse que chez une partie des visiteurs. Nous traitons plus largement la couche d’infrastructure du côté de l’hébergement et du CDN.

Site statique — la page est prête avant que quiconque n’arrive

Ce que cela veut dire. Les pages sont fabriquées à l’avance, sous forme de fichiers finis, et servies sans rien assembler au moment de la visite. D’où un chargement très rapide et moins de pièces mobiles susceptibles de tomber en panne : il n’y a pas de base de données interrogée à chaque affichage, donc pas moyen de la saturer. C’est le même objet que le devis appelle parfois « génération statique », « générateur de site statique » ou, avec le mot anglais, « Jamstack ».

Quand cela a du sens chez vous. Avec un contenu qui change rarement et dont il y a beaucoup : catalogue, documentation, base de connaissances, blog, site de présentation d’une offre. Sur ce profil, c’est le moyen le moins cher d’avoir un site rapide en permanence, et pas seulement la nuit.

Quand c’est un excès — et un avertissement. Quand le contenu change toutes les heures ou dépend de qui regarde (prix par client, état des stocks, espace après connexion), la génération statique seule ne suffit plus et on lui ajoute d’autres mécanismes — c’est-à-dire la complexité qu’elle devait supprimer. L’avertissement porte sur le mot, pas sur la technologie : « Jamstack » ne décrit aucune conséquence que vous puissiez ressentir. C’est le vocabulaire du prestataire, pas le vôtre. Une seule question le traduit en quelque chose de vérifiable : combien de minutes s’écoulent entre une correction dans le texte et le moment où elle est visible sur le site ? Avec un site statique, la réponse honnête n’est jamais « immédiatement » — c’est la durée d’une reconstruction, et elle se multiplie souvent par le nombre de versions linguistiques, puisque chacune produit ses propres pages. Un chiffre de trois minutes et un chiffre de quarante minutes décrivent deux quotidiens rédactionnels différents.

Astro et les frameworks orientés contenu — l’outil taillé pour ce profil

Ce que cela veut dire. Un cadre de développement qui construit les pages de telle façon que le navigateur reçoit du HTML propre, les scripts n’arrivant que là où quelque chose doit réellement réagir à un clic. En pratique : moins de JavaScript à télécharger et à exécuter qu’avec un outil généraliste.

Quand cela a du sens chez vous. Sur un site de contenu sans logique lourde côté serveur — et ce n’est pas notre opinion, c’est quelque chose que l’on voit dans les enquêtes : dans State of React 2025, Astro devance Next.js de 39 points de pourcentage en satisfaction des développeurs, le reproche récurrent adressé au second étant sa complexité croissante.

Quand c’est un excès. Quand vous construisez une application et non un site : espace client, panier, configurateur, tout ce qui comporte une connexion et un état. L’outil pensé pour le contenu commence alors à gêner, et la conversation se déplace vers le choix entre Next.js et React.

API-first, ou architecture découplée — un contenu, plusieurs canaux

Ce que cela veut dire. Le contenu et les données sont accessibles par une interface de programmation, si bien que la même description de produit peut alimenter le site, une application, un écran en magasin et le catalogue envoyé à un partenaire — sans être réécrite à quatre endroits. Le devis peut appeler cela « API-first », « découplé » ou « headless » : ce sont trois mots pour la même chose.

Quand cela a du sens chez vous. Quand vous avez réellement plus d’un canal, ou que vous savez que vous en aurez un second. C’est aussi le fondement de l’architecture headless, que nous décrivons à part. Et c’est le seul endroit de cette liste où le multilinguisme joue en faveur de la complexité : un modèle de contenu unique où chaque champ existe en plusieurs langues se tient bien mieux dans le temps que trois sites qui se ressemblent.

Quand c’est un excès. Quand le canal est unique et que rien n’en annonce un second. Vous payez alors une souplesse dont personne ne se servira, et la rédaction du contenu devient plus difficile, pas plus simple.

Multilingue — le mot qui n’améliore rien et décide de presque tout

Ce que cela veut dire. Le même site publié en deux ou trois langues. Cela paraît être un réglage ; c’est en réalité une décision d’architecture, parce que trois arrangements très différents portent le même nom dans les devis. Une traduction peut être un champ supplémentaire dans le même document — chaque page connaît alors ses versions et se relit en une passe. Elle peut être un arbre de pages dupliqué — deux fois plus de documents, des liens internes à tenir à la main. Ou elle peut être un second site — deux projets à maintenir, deux mises à jour, deux sauvegardes. Les trois se vendent au même prix à l’achat et ne coûtent pas du tout la même chose à vivre.

Quand cela a du sens chez vous. Ici, la question ne se pose presque jamais dans l’autre sens : une entreprise qui sert ce marché finit le plus souvent avec deux ou trois versions. La vraie question est celle du maintien en parallèle : une version secondaire figée sur l’offre d’il y a deux ans coûte plus de crédibilité qu’elle n’en rapporte.

Quand c’est un excès. Quand vous ajoutez une langue pour un marché que vous ne servez pas encore, avec des contenus traduits une fois et jamais repris. Et une précision de prix, puisque nous publions la nôtre : dans notre grille, une deuxième langue ajoute 1 750 CHF à la création, hors taxes. La note qui accompagne cette ligne dans notre calculateur dit le reste, et elle vaut pour n’importe quel prestataire : la configuration technique n’est qu’une fraction du coût, la traduction professionnelle de toutes les pages coûte à peu près autant de nouveau. Un devis qui chiffre le multilinguisme sans parler des contenus chiffre la moitié du travail.

La question qui tranche : lequel des trois arrangements ci-dessus proposez-vous, et combien de temps faut-il pour publier une correction dans toutes les langues ?

PWA, ou application web progressive — le site que l’on installe

Ce que cela veut dire. Un site ordinaire avec trois ajouts : il s’installe sur l’écran d’un téléphone sans App Store ni Google Play, il fonctionne sans connexion dans les limites que vous aurez fixées, et il peut envoyer des notifications. L’adresse reste la même, le contenu aussi. Cela repose sur un service worker, un petit programme que le navigateur garde entre le site et le réseau et qui sait répondre quand le réseau n’est pas là (documentation web.dev, MDN).

Quand cela a du sens chez vous. Quand le client a une raison de revenir : un espace avec ses commandes et ses factures, le suivi d’un mandat, un catalogue pour des partenaires réguliers, une liste de tâches pour une équipe sur le terrain. L’icône sur l’écran a alors de la valeur, et l’installation depuis le navigateur est un seuil nettement plus bas qu’un téléchargement sur une boutique. Une chose qui ne figure pas dans les devis d’applications mobiles : une PWA s’installe aussi sur un ordinateur — comme une fenêtre séparée avec son icône dans la barre des tâches, sans boutique, sans installateur et sans service informatique.

Quand c’est un excès. Quand on visite le site une fois. Une page de présentation que quelqu’un ouvre, dont il relève le numéro de téléphone et qu’il referme n’a besoin d’aucune installation — personne ne la regrette.

Deux choses à régler avant le chiffrage. D’abord, « fonctionne hors connexion » n’est pas un interrupteur : quelqu’un doit décider ce qui doit précisément rester disponible sans réseau, en gardant à l’esprit que l’appareil montrera l’état de la dernière visite couverte. D’où la règle que nous appliquons : l’hors-ligne reçoit ce qui change rarement, le reste demande une connexion. Ensuite, sur iPhone, les notifications ne fonctionnent qu’après ajout du site à l’écran d’accueil et sont disponibles à partir d’iOS 16.4 (annonce de l’équipe WebKit). Si les notifications sont une fonction critique et que vos clients ont des iPhone, cette seule condition peut renverser la décision.

Comment vérifier ce que vous avez déjà. Ouvrez votre propre site sur Android dans Chrome et déroulez le menu du navigateur : si « Installer l’application » s’y trouve avec votre icône, les conditions de base sont remplies. Sur iPhone, la même opération se trouve dans le menu de partage de Safari — et seulement dans Safari, ce qu’il vaut mieux savoir avant de promettre la fonction à des clients.

La limite à connaître. Une PWA s’arrête là où commence une application qui touche au matériel : NFC, Bluetooth, travail en arrière-plan écran éteint, capteurs. La comparaison complète avec une application native — avec ses chiffres et ses critères — relève de la décision de construire une application, pas de celle de construire un site, et nous la traitons à part, avec les applications web sur mesure.

WebAssembly — et pourquoi il ne s’agit probablement pas de vous

Ce que cela veut dire. Un moyen d’exécuter dans un navigateur du code écrit dans des langages venus d’ailleurs que du monde du web — C, C++, Rust — avec des performances proches d’un programme installé sur la machine. Le devis l’abrège parfois en « Wasm ».

Quand cela a du sens. Sur des choses lourdes en calcul : un éditeur d’images ou de vidéo dans le navigateur, une simulation, un configurateur 3D, le traitement de gros fichiers sans les envoyer sur un serveur.

Quand c’est un excès — autrement dit, traitez-le comme un signal d’alarme. Si WebAssembly figure dans le devis d’un site d’entreprise ordinaire, il y a deux possibilités. Soit le projet contient réellement quelque chose qui l’exige — configurateur 3D, éditeur, traitement de fichiers dans le navigateur — et le prestataire le désignera d’un seul nom de fonction. Soit quelqu’un teste une nouveauté à vos frais. Une question tranche en une phrase : quelle fonction précise l’exige ? Une réponse générale — « la modernité », « la performance » — est une réponse du second type.

Récapitulatif : quel mot améliore quelle propriété

Les quatre propriétés du début, les huit mots des devis, et un tableau à emporter en réunion.

La colonne qui tranche d’ordinaire la conversation est la dernière. Si le prestataire sait expliquer pourquoi, chez vous, le cas « excès » ne se présente pas, vous parlez à quelqu’un qui a calculé le projet. S’il répond que « c’est le standard aujourd’hui », vous parlez à un devis écrit une fois pour tous les clients.

Ce que ces mots ne règlent pas

Aucun d’eux ne vendra votre produit.

Une PWA ne fera pas installer votre site à quelqu’un qui n’a pas de raison d’y revenir. Le serverless n’augmentera pas votre taux de conversion. La périphérie n’aidera pas quand le formulaire de contact compte quinze champs et que l’offre est écrite de telle sorte qu’il faut la lire deux fois. La vitesse de chargement est une condition nécessaire — elle n’est pas suffisante.

L’ordre que nous appliquons chez nous et que nous proposons à nos clients est l’inverse de celui des devis : d’abord la raison pour laquelle quelqu’un devrait revenir, ensuite la couche technique qui le lui facilitera. Si la décision d’une PWA se prend avant que quiconque ait répondu à la question de savoir pourquoi le client reviendrait, elle se prend trop tôt — et c’est une question de stratégie de site, pas une question d’offre technologique.

Le même raisonnement s’applique au mot qui amène la plupart des lecteurs jusqu’ici : une refonte de site web n’est pas une opération technique. Refaire l’apparence d’un site dont le problème est qu’on n’y comprend pas ce que l’entreprise vend produit un site plus joli avec le même résultat commercial. Une refonte se justifie quand l’une des quatre propriétés est mesurément défaillante, ou quand l’offre elle-même a changé au point que la structure ne la porte plus. Dans les autres cas, ce qui a besoin d’être refait est le texte.

Deux mots qui reviennent dans les devis sans être une technologie de votre site

À côté des huit ci-dessus, deux autres reviennent régulièrement dans les offres : l’optimisation pour la recherche vocale et l’intelligence artificielle. Il vaut la peine de savoir les mettre de côté, parce que tous deux font sérieux dans un devis et qu’aucun n’améliore l’une des quatre propriétés dont parle ce texte.

La recherche vocale. Une page bien structurée, rapide et claire est déjà ce qu’un assistant vocal sait lire ; il n’existe pas de couche technique séparée à acheter par-dessus. Quand cette ligne apparaît dans un devis, la question utile est celle qui vaut pour toutes les autres : qu’est-ce qui change concrètement sur le site, et laquelle des quatre propriétés cela améliore ? Si la réponse consiste à réécrire les titres en questions et à soigner les informations pratiques de l’entreprise, c’est du travail éditorial — utile, mais qui n’a pas besoin du mot « vocal » pour être facturé.

L’intelligence artificielle. Le mot recouvre dans les devis des choses sans aucun rapport entre elles : un agent conversationnel sur le site, de la génération de texte, une recommandation de produits, un tri de demandes entrantes. Chacune est un projet distinct, avec son coût d’exploitation et sa question de responsabilité quand la réponse est fausse. Aucune n’est une propriété du site. La ligne « IA » dans un devis de site web demande donc d’abord d’être dépliée en une fonction nommée — et si cette fonction est un agent conversationnel, c’est une décision sur le coût du service client, pas sur la technologie du site.

Nous n’assortissons ces deux paragraphes d’aucun chiffre de demande : nous n’avons pas mesuré nous-mêmes les volumes de recherche de ces sujets sur ce marché, et citer ceux d’un autre marché fabriquerait un argument qui aurait l’air vérifié sans l’être. La conclusion ne dépend de toute façon pas d’un volume : elle tient dans la même question que les huit autres mots. Laquelle des quatre propriétés cela améliore, et d’où le sait-on ? Sans réponse, la ligne est dans le devis parce qu’elle fait bonne figure.

Aide-mémoire : les questions à envoyer au prestataire

Les questions ci-dessous sont écrites pour être copiées dans un message et envoyées sans retouche. Les réponses écrites comptent d’ailleurs davantage que les questions elles-mêmes — une assurance donnée de vive voix n’entrera pas dans le contrat.

Si les réponses aux trois premières questions sont concrètes et que la cinquième reçoit un « nous configurons des limites et une alerte », vous parlez à quelqu’un qui a calculé ce projet. Si ce qui revient ressemble à « c’est le standard aujourd’hui » et « tout est flexible », vous recevez un devis écrit une fois pour tous les clients.

D’où viennent ces chiffres

• Le mécanisme d’une PWA — service worker, installation, mode hors connexion — la documentation web.dev et MDN, vérifiée à la source le 11 septembre 2026.
• Les notifications push sur iOS à partir de la version 16.4, après ajout à l’écran d’accueil — l’annonce de l’équipe WebKit, vérifiée à la source le 11 septembre 2026.
• L’avance d’Astro de 39 points de pourcentage en satisfaction des développeurs — l’enquête State of React 2025, 3 760 réponses recueillies entre novembre 2025 et janvier 2026.
• Le prix d’une deuxième version linguistique — notre propre grille, hors taxes, la même ligne que celle publiée dans la rubrique consacrée au prix d’un site web.
• Les comparaisons de coût entre ces technologies — nous ne connaissons aucune étude qui les mesurerait sur des projets comparables, et nous ne donnons donc aucun multiplicateur.
• Les volumes de recherche — délibérément absents de ce texte, y compris pour la recherche vocale et l’intelligence artificielle : nos relevés portent sur un autre marché et nous n’avons pas mesuré les équivalents pour le marché suisse francophone.