Site vitrine ou application web : quand le projet change

Un projet de site devient une application web dès que les visiteurs ne se contentent plus de lire : ils se connectent, saisissent des données, déclenchent des calculs ou alimentent vos logiciels. Ce basculement change le prestataire à consulter, la méthode de travail, le budget et le calendrier. Mieux vaut le repérer avant de signer un devis de site.

Site vitrine, site dynamique, application web : ce qui les sépare

Les devis emploient souvent ces trois termes comme des synonymes. L’écart tient pourtant moins à la technologie qu’à ce que le visiteur fait sur la page.

Le site vitrine présente l’entreprise, son offre, ses preuves et les moyens de la joindre. Tous les visiteurs y voient les mêmes pages, et sa mission consiste à convaincre un prospect d’appeler ou d’écrire. La vente en ligne relève d’un autre arbitrage, détaillé dans notre comparaison entre site vitrine et site e-commerce.

Vient ensuite le site dynamique, une notion technique. La documentation MDN de Mozilla le décrit comme un site dont une partie des réponses est produite à la demande, en insérant dans des gabarits des données tirées d’une base. Une vitrine construite avec un CMS (logiciel de gestion de contenu, WordPress par exemple) fonctionne de cette façon, sans que le visiteur s’en aperçoive.

Troisième objet, l’application web est un logiciel utilisé dans le navigateur. Le visiteur y devient un utilisateur identifié : il commande, réserve, suit un dossier, dépose une pièce. MDN présente l’application monopage comme l’une de ses mises en œuvre : un seul document chargé, dont le contenu se met ensuite à jour par des scripts.

Les quatre signes qu’un projet change de nature

Aucun de ces signes ne tranche seul. Deux réunis dans la même liste de souhaits indiquent qu’un devis de site ne décrit plus le vrai travail.

Des comptes et des droits propres à chaque utilisateur

Dès que des comptes utilisateurs apparaissent, le projet embarque l’inscription, la récupération du mot de passe et la gestion des droits : un client voit ses commandes, un commercial celles de son secteur, un administrateur l’ensemble. Le guide RGPD du développeur de la CNIL, déclinaison du règlement général sur la protection des données pour les équipes techniques, demande un identifiant propre à chaque personne et une authentification robuste.

Des données confiées par vos clients

Une application conserve ce que vos clients y déposent : adresses, justificatifs, historiques, parfois des informations sensibles. Votre entreprise répond de ces données, et l’article 32 du RGPD, tel que le reproduit la CNIL, exige des mesures adaptées au risque, dont le chiffrement et la capacité à rétablir l’accès après un incident. Le prestataire qui développe ou héberge l’outil traite ces données pour votre compte : l’article 28 impose alors un contrat qui l’oblige notamment à agir sur instruction documentée et à restituer ou supprimer les données en fin de mission.

Des règles métier que le site doit appliquer

Troisième signe : le site applique vos règles au lieu de les décrire. Un tarif qui dépend de la quantité et du statut du client, une réservation bloquée la veille d’une livraison, une demande orientée vers le bon technicien selon le département. Chaque règle de ce genre s’écrit, se teste et se maintient comme du code. Les règles métier pèsent souvent plus lourd que les écrans dans un chiffrage, et une maquette les montre à peine.

Des échanges avec les outils déjà en place

Dernier signe, le plus sous-estimé : l’outil dialogue avec vos logiciels. Un CRM (logiciel de gestion de la relation client) reçoit les demandes, un ERP (progiciel de gestion intégré) fournit les stocks et les prix, un service de paiement encaisse. Ces liaisons passent par des API, des interfaces de programmation par lesquelles deux logiciels échangent des données selon un format convenu. Chaque connecteur ajoute ses cas d’erreur : service indisponible, format modifié par l’éditeur, fiche en double.

Quand le projet change de prestataire et de méthode

Un projet arrivé à ce stade relève d’une agence de développement d’applications web, parce que le travail ne consiste plus à habiller des pages mais à concevoir un logiciel, ses données et ses raccordements. Digital Unicorn, par exemple, ouvre ce type de projet par un cadrage mené avant toute ligne de code : le problème à résoudre et pour qui, les utilisateurs visés, les fonctions indispensables au lancement et celles qui attendront, les outils existants à raccorder, pour en tirer un périmètre tenable, une enveloppe cible et un calendrier. Suit une architecture taillée pour la complexité du projet et ses évolutions prévues, qui branche les logiciels en service et les services tiers (CRM, ERP, paiement, signature électronique) par des API documentées. Pour un dirigeant, l’intérêt est concret : les arbitrages coûteux se tranchent avant le développement, et l’application rejoint l’outillage de l’entreprise au lieu d’y ajouter un îlot.

Votre projet, lui, ne se budgète plus comme un site. Le chiffrage se découpe en lots, en commençant par une version minimale réduite aux fonctions qui rendent l’outil utile, puis en ajoutant des lots décidés d’après l’usage réel. Le calendrier suit ce découpage, et la maintenance annuelle entre dans le calcul dès la première année, car une application raccordée à d’autres logiciels évolue avec eux.

Ce que la bascule fait au budget et au calendrier

Un site vitrine se chiffre en pages et en gabarits. Une application web se chiffre en fonctionnalités, en règles et en connecteurs, chacun traduit en journées de conception, de développement et de test. Notre page sur les prix d’un site internet professionnel situe la journée d’une structure constituée entre cinq cents et neuf cents euros : le nombre de journées, plus que le nombre d’écrans, fait le budget.

Le découpage en lots mérite d’être pris au sérieux. Le premier lot, la version minimale souvent appelée MVP (produit minimum viable), part en production devant un premier groupe d’utilisateurs, et leurs usages réels orientent les lots suivants mieux que les hypothèses de réunion.

Un calendrier découpé en phases

Le calendrier d’une application suit des étapes qu’un site vitrine connaît sous une forme plus légère :

• le cadrage, qui fixe le périmètre et les priorités ;
• la conception des parcours par profil d’utilisateur, puis les maquettes ;
• le développement par cycles courts, conclus chacun par une démonstration ;
• la recette, vérification formelle que chaque fonction livrée fait ce qui était demandé ;
• la mise en production, suivie de correctifs rapprochés.

Additionnées, ces phases se comptent en mois. Le facteur limitant se trouve souvent côté entreprise : chaque démonstration appelle un retour, chaque règle un arbitrage, et un référent indisponible retarde le projet plus sûrement qu’un développeur lent.

Les dépenses qui reviennent chaque année

La facture ne s’arrête pas à la mise en ligne. Une application demande un hébergement qui exécute du code côté serveur et conserve une base de données, avec des sauvegardes vérifiées : les offres gratuites décrites dans notre article sur l’hébergement gratuit d’un site web atteignent leurs limites dès qu’un espace client entre en jeu. S’y ajoutent la maintenance corrective et évolutive, les mises à jour de sécurité et les abonnements des services tiers. Un devis qui tait ces postes ne décrit qu’une partie du projet.

Les questions à trancher avant de basculer

Avant de transformer un devis de site en projet d’application, cinq questions méritent une réponse écrite, préparée en interne :

• Quel problème l’outil règle-t-il, pour qui et à quelle fréquence ? Un usage quotidien par des clients identifiés justifie un développement, un besoin ponctuel se traite parfois par un formulaire bien pensé.
• Existe-t-il un logiciel du marché qui couvre le besoin sans tordre vos processus ? Comparez son abonnement sur plusieurs années au coût d’un développement.
• Qui porte le produit chez vous ? Une application réclame un référent qui tranche les priorités et valide les livraisons.
• Quelles données personnelles entrent dans l’outil ? Le contrat de sous-traitance prévu par l’article 28 du RGPD se prépare dès la consultation.
• À qui appartiendront le code, les comptes d’hébergement et les accès ? La réponse s’écrit avant la signature.

Le guide de la sécurité des données personnelles de la CNIL, réédité le 26 mars 2024, réunit vingt-cinq fiches, parmi lesquelles cinq nouvelles, notamment sur les interfaces de programmation et l’informatique en nuage. Il offre une grille utile pour comparer les engagements des propositions reçues.

Ces réponses complètent le document de consultation. Notre guide du cahier des charges d’un site internet en donne la structure ; pour une application, le périmètre fonctionnel s’enrichit de trois blocs : les profils d’utilisateurs et leurs droits, les règles métier en phrases simples, les logiciels à raccorder.

Côté financement, les aides publiques soutiennent des projets de transformation plutôt que des sites : une application qui dématérialise un processus entre mieux dans leur logique, comme l’explique notre point sur les subventions et aides.

Prochaine étape : reprenez la liste des demandes prévues pour votre futur site et cochez chaque ligne qui suppose un compte, une donnée saisie, une règle ou un raccordement. Si plusieurs lignes sont cochées, rédigez une note de cadrage courte et soumettez-la aussi à des prestataires d’applications, pas seulement à des créateurs de sites.

Questions courantes sur le passage à l’application web

Une application web fonctionne-t-elle sur mobile ?

Oui, puisqu’elle s’exécute dans le navigateur du téléphone comme dans celui d’un ordinateur, à condition que ses écrans soient pensés pour les petits formats. La documentation MDN décrit une variante, l’application web progressive : bâtie avec les technologies du web, elle peut s’installer sur l’appareil, fonctionner hors ligne et s’intégrer aux autres applications. Pour une PME, cette option évite parfois de développer puis de maintenir deux applications distinctes, une par système d’exploitation mobile.

Un site WordPress peut-il évoluer en application web ?

Jusqu’à un certain point. Des extensions ajoutent des comptes, des formulaires avancés ou une prise de rendez-vous, et couvrent bien des besoins simples. La limite apparaît quand les règles se multiplient, que les extensions s’empilent ou que plusieurs logiciels doivent échanger des données en continu : chaque mise à jour devient alors un risque de panne. À ce stade, une application développée à côté, le site gardant son rôle de vitrine, se maintient plus sereinement qu’un empilement d’extensions.

Le site vitrine doit-il être refait quand l’application arrive ?

Rarement. La vitrine conserve son rôle : être trouvée, présenter l’offre, convaincre. L’application vit à côté, derrière un bouton de connexion ou sur un sous-domaine, avec une charte graphique commune pour que le passage de l’une à l’autre reste fluide. Une refonte se justifie surtout si le site actuel arrive en fin de vie, s’il s’adapte mal aux mobiles ou si son outil de gestion complique l’ajout d’un accès à l’espace client.