Application web : ce que c’est, ses types et quand vous en avez besoin

Le site informe. L’application compte, enregistre et se souvient

Un site internet répond à la question « qui êtes-vous et que faites-vous ». Une application web répond à la question « où en est ma commande » — et pour y répondre, elle doit enregistrer quelque chose, calculer quelque chose et s’en souvenir pour votre prochaine visite. Ce n’est pas une différence de taille ni de budget : tout se joue sur la question de savoir s’il reste quelque chose de l’autre côté.

Aucun agrégat comparable à ceux d’Eurostat ne mesure l’ampleur de cet écart en Suisse — l’enquête européenne sur l’usage des TIC dans les entreprises ne couvre que les États membres de l’UE, et la Suisse n’en fait pas partie. Ce que nous pouvons dire sans chiffre : avoir un site et pouvoir réellement y effectuer une transaction sont deux capacités différentes, qu’il vaut la peine de vérifier séparément plutôt que de supposer que l’une entraîne l’autre.

Cet article traite de cet écart : ce qu’est vraiment une application web, quels types elle recouvre, ce qu’elle coûte, et comment reconnaître que votre entreprise a atteint le point où un site ne suffit plus. Les exemples sont les nôtres — nous décrivons des applications que nous avons construites pour nous-mêmes, que vous pouvez ouvrir en lisant.

Qu’est-ce qu’une application web

Une application web est un programme qui s’exécute dans le navigateur, et les données sur lesquelles elle travaille se trouvent sur un serveur, pas sur votre ordinateur. Vous ouvrez l’adresse, vous vous connectez et vous travaillez sur le même jeu de données que le reste de l’équipe — sans rien installer et sans vous échanger de fichiers par e-mail.

Mécaniquement, la différence avec un site ordinaire tient à ce que le serveur fait de la requête. La documentation MDN décrit un site statique comme « un site qui retourne du contenu codé en dur, c’est-à-dire le contenu d’un fichier, quand une ressource donnée est demandée ». Un site dynamique, à l’inverse, est « un site dont une partie des réponses sont générées dynamiquement, à la demande », les pages HTML étant normalement créées « en insérant des données d’une base de données dans des espaces réservés à l’intérieur de templates HTML ». Une application web est le cas extrême de ce second type : presque rien n’y est préparé à l’avance, parce que le contenu dépend de qui est connecté et de ce que cette personne a fait auparavant.

Les termes « application en ligne » et « application internet » désignent exactement la même chose. En français, ces expressions sont employées indifféremment, et aucune différence technique ne se cache derrière l’une ou l’autre.

De cette seule décision — le programme s’exécute dans le navigateur, les données restent sur le serveur — découlent quatre caractéristiques qui, en pratique, orientent le choix :

• Vous n’installez rien. Un nouvel employé reçoit un lien et un mot de passe, pas un fichier d’installation ni la visite de l’informaticien.
• Une seule version pour toutes les plateformes. Windows, macOS, Android, iOS — la même application, parce qu’un navigateur existe sur chacune d’elles. Vous ne maintenez pas trois versions séparées.
• Les données restent côté serveur. La sauvegarde se fait à un seul endroit, et la panne d’un ordinateur portable n’efface le travail de personne.
• La mise à jour se fait sans que l’utilisateur intervienne. Un correctif arrive sur le serveur et, dès cet instant, tout le monde travaille sur la nouvelle version — personne ne clique sur « mettre à jour » et ne reste bloqué sur l’ancienne.

Ce dernier point a un revers qu’il vaut mieux connaître dès le départ : puisque tout le monde travaille sur une seule version, une erreur de déploiement touche tout le monde d’un coup. C’est pourquoi les sauvegardes et la capacité à annuler rapidement un changement sont essentielles pour une application, alors que personne ne s’en soucie pour un site vitrine.

Application web ou site internet — quatre différences concrètes

La question « application web ou site internet » se tranche plus facilement par quatre questions sur le devenir des données que par des définitions.

Ce qu’il stocke. Sur un site, le contenu est créé une fois, en rédaction, identique pour chaque visiteur. Dans une application, il se crée pendant l’usage : la commande passée hier, la demande de support d’il y a une heure, un calcul enregistré pour y revenir. Tant que rien ne se crée côté utilisateur, une application n’est pas nécessaire.

Qui se connecte. La connexion est le test le plus simple. Si tout le monde voit la même chose, un site suffit. Si un client doit voir ses commandes et un autre les siennes, il faut des comptes, des droits d’accès et une réinitialisation de mot de passe — déjà une application, aussi modeste soit-elle.

Ce qu’il reste à la fermeture de l’onglet. Un formulaire de contact envoie un e-mail et s’arrête là. Une application enregistre un état auquel on revient : une demande interrompue, un panier, un brouillon, un historique. Dès « nous aimerions que le client puisse terminer plus tard », c’est déjà une application.

Qui paie l’exploitation. La différence dont on vous prévient le moins. Un site, c’est hébergement, domaine et mises à jour. Une application, c’est tout cela plus base de données, sauvegardes testées par restauration, surveillance et budget de développement continu — une application figée un an cesse de correspondre à un processus qui, lui, a changé. Planifiez l’exploitation dès le premier jour.

La frontière est souvent floue, et c’est normal. Un site avec un formulaire, un panier ou un module de réservation contient déjà un morceau d’application, et une grande application interne comporte généralement quelques pages purement informationnelles. Il ne s’agit pas de se disputer sur le nom, mais de compter combien de ces quatre lignes s’appliquent à votre cas. Une seule, c’est en général un site avec un complément. Trois ou quatre, c’est un projet à planifier, exploiter et budgéter comme une application, quel que soit le nom que vous lui donnez dans votre appel d’offres.

Types d’applications web

Les applications web se classent le plus souvent par technologie. Pour une entreprise qui doit décider si elle en a besoin, un classement par rôle est plus utile : qui l’utilise, et à qui elle résout un problème.

Un outil interne. Utilisé par l’équipe, pas par les clients. Un registre de commandes, un tableau de production, un inventaire de matériel, un planning de garde. Il remplace généralement un tableur qui a dépassé ce qu’il pouvait gérer, et il se rentabilise le plus vite, car le nombre d’utilisateurs est connu et le processus existe déjà — il suffit de le transférer dans un outil où deux personnes ne peuvent plus écraser la même ligne.

Un portail client. Le client se connecte et voit ses propres données : commandes, statut de livraison, factures, documents, demandes de support. C’est le type d’application qui soulage le plus le téléphone et la boîte mail, parce qu’elle déplace sur le site les questions posées plusieurs fois par jour. Nous n’avons pas d’agrégat suisse pour dire à quel point c’est répandu.

Une application de vente. Un configurateur, un calculateur de devis, un module de réservation, une commande construite selon les spécifications du client. Elle agit avant la vente, pas après : elle doit produire une demande déjà chiffrée et décrite. C’est en général le terrain le plus facile pour se démarquer.

Un produit par abonnement. Une application qui est elle-même l’objet de la vente : les clients paient pour y accéder. C’est un projet complètement différent des trois précédents, car l’exploitation, le support et le développement deviennent une partie du modèle économique plutôt qu’un coût de fonctionnement. Avant de vous engager dans cette voie, il vaut la peine de lire notre article sur la différence entre logiciel prêt à l’emploi et solution sur mesure.

La PWA — l’application web progressive — occupe une place à part. MDN la définit comme « une application construite en utilisant les technologies de la plateforme web, mais qui offre une expérience utilisateur similaire à celle d’une application spécifique à une plateforme », en ajoutant que « comme un site web, une PWA peut s’exécuter sur plusieurs plateformes et appareils à partir d’une seule base de code », tout en pouvant, « comme une application spécifique à une plateforme, être installée sur l’appareil, fonctionner hors ligne et en arrière-plan, et s’intégrer à l’appareil ainsi qu’aux autres applications installées ». Ce n’est pas un type d’application distinct au sens commercial, mais un mode de distribution : la même application web, avec une icône sur l’écran d’accueil. Nous détaillons quand cela suffit à la place d’une application mobile dans application mobile ou web.

Application web — des exemples que nous avons construits nous-mêmes

Le plus simple, pour montrer la différence, est de prendre des applications que vous pouvez ouvrir pendant votre lecture. Toutes celles qui suivent fonctionnent sur ce site, et toutes existent parce que quelque chose ne pouvait pas se régler avec du contenu seul.

Calculateurs de coût. Problème : « combien cela coûte » survient avant le premier échange, et « ça dépend » n’aide personne. L’application : vous choisissez un périmètre, le résultat se recalcule à chaque champ modifié, certaines questions n’apparaissent qu’une fois pertinentes, et le résultat s’enregistre et s’envoie avec un devis PDF détaillé. Nous avons huit configurations de ce type, dont six ont leur propre page, parmi lesquelles le calculateur du coût d’une application web. Un site donnerait juste une fourchette.

Quiz. Problème : le lecteur ne sait pas s’il a besoin d’un site, d’une application web ou mobile, et une liste de critères l’oblige à l’appliquer lui-même. L’application : chaque réponse ajoute des points à plusieurs catégories, et le résultat affiche la recommandation gagnante, un classement du reste et la réponse qui a fait pencher la balance. Nous avons quatre quiz ; le plus proche est le quiz site, application web ou mobile. Un site ne connaît pas les réponses du lecteur, donc ne peut pas les additionner.

Assistant de brief. Problème : le premier échange sur un projet dure deux heures et ne recueille toujours pas tout, avec des questions que le client ne comprend pas encore. L’application : elle guide étape par étape, adapte les questions aux réponses précédentes, préremplit certains champs par préréglage sectoriel, calcule en direct un calendrier estimé, et enregistre la session pour revenir avec le même lien. L’ensemble s’exporte en PDF, et l’adresse indiquée devient une fiche contact dans notre CRM. Il fonctionne à l’adresse brief de projet. Un formulaire envoie un e-mail et s’arrête là — ici, un état subsiste.

Notre CRM avec synchronisation de la messagerie. Problème : un contact venu d’un formulaire, d’un calculateur, d’un quiz et d’un appel, ce sont quatre endroits séparés, et c’est souvent une seule personne. L’application : chaque canal alimente une seule fiche contact reconnue par e-mail ; la messagerie de l’entreprise (Gmail ou Microsoft 365) y ajoute les métadonnées de la correspondance — objet, date, sens, jamais le corps du message ; le domaine relie le contact à une entreprise, sauf messagerie personnelle. Outil interne, sans page publique ; ce dont une petite entreprise a réellement besoin est détaillé dans CRM pour petite entreprise. Un site n’a nulle part où garder l’historique d’une relation.

Module de réservation. Problème : fixer un rendez-vous par e-mail prend en moyenne quatre messages et une erreur de fuseau horaire. L’application calcule les créneaux libres à partir d’un planning et d’un agenda Google, crée un événement avec lien d’appel à la réservation, envoie une confirmation avec fichier .ics et liens d’annulation, puis envoie un rappel un jour et une heure avant le rendez-vous. Plus de détails côté client dans système de réservation en ligne. Un site afficherait un numéro de téléphone.

Le dénominateur commun de ces cinq exemples : dans chacun, quelque chose reste côté serveur — un résultat, des réponses, une session, un contact, un créneau réservé. C’est toute la définition d’une application web, racontée cinq fois.

Quand une application, et quand un site suffit

Tous les problèmes d’organisation du travail ne se règlent pas avec une application. Voici quatre signaux à surveiller — et une condition où mieux vaut encore attendre.

Les données reviennent sans cesse. La même information circule en boucle : un client la donne dans un formulaire, quelqu’un la recopie dans un tableur, puis dans une facture, puis dans un e-mail de confirmation. Chaque recopie est une occasion d’erreur et quelques minutes du temps de quelqu’un. Une application enregistre la donnée une fois et l’affiche à chacun de ces endroits.

Quelqu’un se connecte. Si la conversation commence par « nous aimerions que le client voie chez lui… », c’est déjà une application. Un site n’a aucun moyen de savoir qui le regarde.

Des chiffres à recalculer. Un devis qui dépend de cinq paramètres, un calendrier qui se décale dès qu’une date change, une commission calculée à partir de trois composantes. Tant que c’est une personne qui fait ce calcul dans un tableur, le résultat dépend de qui et de quel tableur.

Un processus a des étapes. Une demande passe par la réception, le devis, la validation, la réalisation et la remise, et à chaque étape, quelqu’un d’autre doit savoir que c’est son tour. On peut gérer des étapes par e-mail jusqu’au moment où l’une se perd — et alors plus personne ne sait où on en est.

Il y a une condition où mieux vaut attendre : le processus n’existe pas encore. Si l’entreprise ne s’est pas accordée sur la manière dont les choses doivent se dérouler, une application ne créera pas cet accord — elle figera la variante construite par hasard et fera payer chaque changement d’avis. Mettez d’abord le processus au clair sur papier ou dans un tableur, puis programmez-le. Un tableur bien tenu est la meilleure préparation à une application.

Nous n’avons pas d’agrégat suisse sur la part des entreprises utilisant un CRM, un ERP ou leur propre canal de vente numérique — l’enquête européenne qui y répondrait ne couvre pas la Suisse, et nous n’avons pas trouvé de mesure comparable pour ce marché. Vérifiez où vous en êtes par rapport à un ou deux concurrents avant de supposer qu’un canal de vente numérique est déjà la norme dans votre secteur — en l’absence de chiffre, c’est un fait à vérifier directement plutôt qu’à deviner.

Ce que coûte une application web, en bref

Le détail complet du coût se trouve dans un article séparé : combien coûte une application web. Voici de quoi situer l’ordre de grandeur.

Il n’existe pas de référence suisse sur le prix des applications web sur laquelle nous engagerions notre nom. La seule étude suisse trouvée, l’enquête de Beyondweb sur les agences web, publie un tarif horaire de CHF 120 à 250 (moyenne CHF 166, dix observations seulement) — mais elle chiffre des sites, pas des applications ; nous le disons plutôt que d’étirer ce chiffre. Notre article sur le coût traite cette étude en détail.

Ce que nous pouvons vous dire honnêtement, c’est notre propre prix. Dans notre calculateur, un MVP démarre à CHF 25 000, un produit complet à CHF 72 500, un système multi-modules à CHF 250 000. C’est notre prix de départ, pas une lecture du marché. Les tests, la documentation et la maintenance y figurent dès le départ comme des lignes distinctes ; nous ne prétendons pas pour autant battre une référence que nous ne pouvons pas citer.

Quatre éléments font généralement grimper un devis, et aucun n’est un choix de technologie : le nombre de rôles avec des droits séparés, les intégrations avec des systèmes que vous ne contrôlez pas, la migration de données, et l’accessibilité ou la sécurité pour des clients externes. Les deux derniers sont le plus souvent absents d’un premier devis et réapparaissent en cours de projet. Si vous comparez des offres, vérifiez d’abord lesquelles mentionnent ces quatre postes.

Par où commencer

Commencez par un MVP, pas par le système complet. Un MVP ne couvre que le parcours utilisateur essentiel — sans panneau d’administration, sans paramètres avancés, sans variantes. Dans nos propres tarifs, chaque niveau triple à peu près le périmètre, donc la différence entre « construisons d’abord une seule chose » et « construisons tout » est plus grande que la différence entre prestataires. Comment planifier un MVP pour qu’il ne devienne pas une liste de souhaits, c’est ce que traite qu’est-ce qu’un MVP pour une application web.

Décrivez le processus avant de décrire les fonctionnalités. Une liste de fonctionnalités découle d’un processus, pas l’inverse. Nous détaillons les étapes du projet, de l’analyse au lancement, dans le processus de développement d’une application web, et vous trouverez la liste de ce qu’il faut préparer de votre côté dans la checklist pour un dirigeant d’entreprise.

Estimez l’ordre de grandeur avant de demander un devis. C’est à cela que sert le calculateur du coût d’une application web ; si vous ne savez pas encore s’il vous faut une application web, une application mobile ou simplement un site, commencez par le quiz. Tous ces outils se trouvent dans notre rubrique outils.

Une fois que vous savez ce que vous voulez construire, notre offre de développement d’applications web décrit à quoi ressemble une collaboration avec nous. Pour le contexte plus large — tous les sujets liés aux applications web — voyez notre guide des applications web.