La mauvaise question arrive en premier
« Faut-il construire un site web ou une application ? » C'est la question qu'on nous pose lors de presque tous les premiers appels. C'est la mauvaise question. Elle saute une étape.
La bonne question est : que doit faire ce produit, et pour qui ? Un site vitrine, une application web sur mesure et une Progressive Web App (PWA) résolvent des problèmes différents. Se tromper de choix ne se limite pas à gaspiller du budget — cela vous enferme dans une architecture coûteuse à défaire six mois plus tard, généralement juste après votre premier retour d'utilisateurs réels.
Voici le cadre que nous utilisons avec nos clients avant qu'une seule ligne de code ne soit écrite, ainsi que des fourchettes honnêtes sur le coût et la durée de chaque option en 2026.
Trois métiers différents, pas trois niveaux du même métier
Les équipes voient souvent cela comme une échelle — site vitrine en bas, PWA en haut, application au milieu. Ce n'est pas exact. Ce ne sont pas des versions plus ou moins sophistiquées les unes des autres. Elles répondent à des questions différentes.
Site vitrine. Mission : convertir un visiteur en prospect ou en vente. Piloté par le contenu, essentiellement public, sans compte utilisateur (ou avec une version minimale greffée pour du contenu réservé). Le succès se mesure au taux de conversion, à la vitesse de chargement et au classement dans les moteurs de recherche. Construit sur un CMS ou un framework de site statique, avec rarement une logique backend sur mesure au-delà des formulaires et de l'analytics.
Application web sur mesure. Mission : permettre à un utilisateur authentifié d'effectuer un vrai travail — gérer un inventaire, traiter des réclamations, prendre des rendez-vous, générer des rapports. C'est là que vit la logique métier : permissions, workflows, validation des données, intégrations avec votre CRM ou ERP. Le succès se mesure au temps d'exécution des tâches et au taux d'erreur, pas au nombre de pages vues.
PWA. Mission : donner à une application web l'apparence d'une application native — icône installable, accès hors ligne aux écrans clés, notifications push — sans le cycle de validation de l'App Store ni deux bases de code distinctes. Ce n'est pas tant une quatrième catégorie qu'un mode de diffusion superposé à une application web. On ne construit pas « une PWA » à la place d'une application web ; on construit une application web, puis on décide de la part de la couche PWA (service workers, mise en cache hors ligne, invites d'installation) qui vaut la peine d'être ajoutée.
Comment choisir concrètement
Posez ces quatre questions, dans l'ordre :
- L'utilisateur se connecte-t-il pour effectuer un travail répétitif, ou un visiteur vient-il simplement lire puis repartir ? Travail répétitif → application web. Lecture puis départ → site vitrine.
- Le produit doit-il fonctionner avec une connexion instable, sur téléphone, loin d'un bureau ? Techniciens sur le terrain, personnel d'entrepôt, livreurs — oui. Travailleurs de bureau avec une connexion stable — généralement non, et la couche PWA est alors une surcharge dont vous n'avez pas encore besoin.
- La visibilité dans les moteurs de recherche fait-elle partie de la façon dont on vous trouve ? Si oui, ce contenu doit vivre sur un site vitrine rapide et explorable par les moteurs — pas enfoui derrière le mur de connexion de votre application — et il a besoin des bases techniques (les fondamentaux du SEO : contenu rendu côté serveur, URLs propres, schema fonctionnel) intégrées dès le premier commit, et non ajoutées après le lancement.
- Avez-vous besoin des deux ? C'est le cas de la plupart des entreprises B2B : un site vitrine pour générer le prospect, et une application web derrière la connexion où vit réellement le client payant. Ce sont deux builds, pas un seul — et les traiter comme un seul projet est une raison fréquente pour laquelle les projets web dépassent leur budget initial.
Si vous construisez le second type — l'application que vos clients utilisent réellement — c'est là que notre équipe développement web passe la majeure partie de son temps, car c'est là que le coût et le risque se concentrent réellement.
Ce qui détermine réellement le coût
Le coût ne dépend pas principalement du nombre de pages ou du « nombre de fonctionnalités ». Il dépend de quatre choses :
La complexité du modèle de données. Une application CRUD avec une poignée de types d'entités simples n'a rien à voir avec une application dotée de permissions par rôle sur de nombreux types d'entités avec pistes d'audit. Chaque relation ajoutée multiplie la surface de test, pas seulement le schéma.
Les intégrations. Chaque système tiers auquel vous vous connectez — Stripe, Salesforce, l'API d'un transporteur, une base de données interne héritée — ajoute du temps réel selon la qualité de la documentation et la stabilité de l'API de ce système. Les systèmes internes non documentés sont l'une des plus grandes sources de dérapage de planning que nous observons, car on ne découvre les cas limites qu'une fois l'intégration déjà en cours.
Les exigences temps réel et hors ligne. Un dashboard qui se rafraîchit au chargement de la page coûte peu. Un dashboard avec des mises à jour en direct via websockets, ou une vue mobile qui doit fonctionner sans connexion puis se synchroniser plus tard, ajoute un vrai temps d'ingénierie en plus du build de base pour les écrans concernés.
La maturité du design. Si vous partez d'un fichier Figma où chaque état (vide, chargement, erreur, cas limite) est déjà conçu, le build avance vite. Si le design se fait en parallèle du développement, attendez-vous à des reprises — les écrans sont construits sur une spec qui change sous leurs pieds.
L'ancienneté et la localisation de l'équipe influencent le taux horaire, mais elles expliquent rarement les plus grands écarts de coût total du projet. Ce sont les quatre facteurs ci-dessus qui l'expliquent.
Délais réalistes pour 2026
Voici des fourchettes approximatives pour un build unique et bien cadré — pas un portefeuille de tout ce dont une grande entreprise pourrait avoir besoin — basées sur des projets que nous avons cadrés récemment :
- Site vitrine (une poignée de pages, sur CMS, sans backend sur mesure) : quelques semaines.
- Application web sur mesure, complexité standard (authentification, quelques types d'entités clés, une ou deux intégrations) : environ un trimestre.
- Application web sur mesure, forte complexité (permissions multi-rôles, plusieurs intégrations, fonctionnalités temps réel) : deux trimestres ou plus.
- Ajout de la couche PWA à une application web existante (mise en cache hors ligne des écrans clés, invite d'installation, push) : quelques semaines, selon la part de l'application qui doit fonctionner hors ligne plutôt que simplement être installable.
Quiconque vous annonce un chiffre fixe sans vous interroger sur votre modèle de données, vos intégrations et l'état de votre design est en train de deviner.
Le schéma qu'on observe le plus souvent
L'erreur la plus fréquente n'est pas de choisir le mauvais format — c'est de choisir un format et de lui demander de remplir les deux missions à la fois. Une entreprise construit un site vitrine soigné, puis tente de greffer un dashboard client sur la même base de code parce que « c'est déjà construit ». Quelques mois plus tard, le dashboard se dispute le contrôle du routing avec le CMS, et chaque mise à jour de contenu risque de casser une fonctionnalité réservée aux utilisateurs connectés.
La solution consiste presque toujours à séparer les deux dès le départ : un site vitrine léger optimisé pour la vitesse et le référencement, et une application web distincte optimisée pour l'expérience connectée, partageant un design system mais pas une base de code. Cela coûte légèrement plus cher au départ. Cela évite une reconstruction plus tard.
En résumé
Ne commencez pas par « site web ou application ». Commencez par ce que fait l'utilisateur et par la part de cela qui doit survivre à une mauvaise connexion. Cadrez le site vitrine et le produit connecté comme deux décisions distinctes, même si une seule équipe construit les deux. Et quand vous chiffrez un build sur mesure, interrogez-vous sur le modèle de données et les intégrations avant de vous interroger sur le nombre de pages — c'est de là que vient le vrai chiffre.
Si vous en êtes au stade de cadrer l'un de ces builds et que vous voulez une réponse claire sur le coût et le délai pour votre cas précis, parlez-nous avant de rédiger votre appel d'offres.
