Site vitrine ou application web : choisir selon ce que vos clients doivent faire
Un site présente une offre ; une application permet aussi d’exécuter des opérations avec des règles et des données. Décrivez les usages avant de choisir la technologie.
Décrire les actions que le site doit permettre
Un site vitrine peut présenter une offre, montrer des réalisations et recevoir une demande. Une application web peut aussi calculer un prix, traiter des documents ou permettre à plusieurs personnes de suivre un dossier. Le nombre de pages ne suffit donc pas pour distinguer les projets.
Écrivez quelques scénarios : qui intervient, quelles informations sont saisies et quel résultat doit être obtenu. « Le client demande un devis » ne décrit pas la même chose que « le client configure un produit, obtient un montant et suit sa fabrication ».
Séparer présentation commerciale et règles de fonctionnement
| Besoin | Travail à prévoir |
|---|---|
| Comprendre une prestation | Contenus, preuves, navigation et action de contact |
| Calculer une offre | Règles, données d’entrée et gestion des erreurs |
| Consulter un dossier | Identification, droits et informations à jour |
| Déclencher une opération | Contrôles, confirmation et traçabilité |
| Relier plusieurs outils | Responsabilités sur les données et mécanisme de reprise |
La présentation MDN des traitements côté serveur explique comment un site peut produire des réponses à partir de données et d’opérations. Cela ne signifie pas qu’un développement entièrement spécifique est nécessaire dès qu’un formulaire existe. Le choix dépend des usages et des outils disponibles.
Identifier ce qui peut rester simple
Une page commerciale peut renvoyer vers un outil spécialisé déjà utilisé par l’entreprise. Une application peut, à l’inverse, nécessiter une intégration plus étroite si le contexte doit suivre le client. Évaluez le parcours complet plutôt que la volonté de tout réunir dans un même écran.
Faites examiner les fonctions standard qui répondent au besoin et leurs limites réelles. Précisez les abonnements, les accès et la capacité de reprise des données. Une solution rapide à installer peut devenir difficile à exploiter si elle exige ensuite plusieurs ressaisies quotidiennes.
Garder une présentation convaincante même pour un projet technique
Le prospect doit comprendre ce que votre entreprise lui permet de faire et voir des preuves pertinentes. Arkemys Resonate intervient sur cette organisation des arguments, des visuels et des informations de choix. Ce travail ne dispense pas de définir et de tester les règles de l’application.
Une maquette peut valider la hiérarchie et les interactions visibles. La réception doit aussi vérifier les calculs, les droits, les messages et les opérations effectivement réalisées. Un écran qui affiche « enregistré » ne prouve pas que les données attendues sont arrivées dans le bon système.
Comparer des devis portant sur les mêmes usages
Demandez quels scénarios sont inclus, quelles dépendances existent et qui maintient les règles après livraison. Préparez des données de test et des cas d’erreur, pas uniquement un parcours idéal.
Le guide sur la propriété des accès et du code complète ce cadrage. Un projet reste exploitable lorsque l’entreprise peut comprendre ce qui a été livré, faire évoluer ses règles et retrouver ses données sans dépendre d’une démonstration ou de la mémoire de son prestataire.
Sources
Documentation consultée le 22 octobre 2026.