Site web ou vraie application web : 7 critères pour faire la différence
Un espace client qui n'est qu'une page protégée par un mot de passe, un « logiciel » qui envoie des emails au lieu d'enregistrer des données : beaucoup de projets présentés comme des applications web sont des sites déguisés. Voici comment faire la différence, avant de signer ou avant de payer la prochaine évolution.
La différence entre un site web et une application web
Un site web sert d'abord à consulter : on y lit une présentation, des services, des articles. Une application web sert à agir : créer, modifier, valider, partager des informations qui vivent dans une base de données, avec des personnes qui n'ont pas toutes les mêmes droits. Les deux s'ouvrent dans un navigateur et peuvent se ressembler à l'écran. C'est sous la surface que tout se joue.
Le « site déguisé en application », c'est l'entre-deux : une interface qui a l'air d'un outil, mais qui repose sur des formulaires qui envoient des emails, des tableurs partagés et un seul mot de passe pour tout le monde. Il rend service au début, puis montre ses limites dès que l'équipe grandit ou que les données deviennent sensibles. Les sept critères suivants permettent de le repérer.
1. Des comptes et des droits, vérifiés côté serveur
Une vraie application sait qui vous êtes et ce que vous avez le droit de faire : un commercial voit ses clients, un comptable voit les factures, un client ne voit que ses propres dossiers. Et ces règles sont vérifiées par le serveur, pas seulement masquées dans l'interface. Ce n'est pas un détail : dans l'édition 2021 du Top 10 de l'OWASP, la référence internationale des risques de sécurité des applications web, le contrôle d'accès défaillant arrive en première position, et 94 % des applications testées présentaient une forme de ce problème.
Question simple à poser : « Si je modifie l'identifiant d'un dossier dans l'adresse de la page, puis-je voir celui d'un autre client ? » La réponse doit être non, et elle doit avoir été vérifiée.
2. Des données qui ont une histoire
Dans un outil sérieux, une donnée n'est pas simplement écrasée : on sait qui l'a créée, qui l'a modifiée et quand. Les saisies sont contrôlées (un email a la forme d'un email, une date de fin suit la date de début), et deux personnes qui modifient le même dossier ne s'annulent pas mutuellement. Un site déguisé, lui, découvre les erreurs le jour où quelqu'un s'en plaint.
3. Une réactivité pensée pour l'usage quotidien
On consulte un site quelques minutes ; on utilise une application des heures. Chaque clic compte. Google mesure d'ailleurs cette réactivité avec un indicateur dédié, l'INP (Interaction to Next Paint), devenu en mars 2024 l'un des trois Core Web Vitals : une page est jugée réactive quand l'écran répond aux interactions en 200 millisecondes ou moins. Une liste qui recharge toute la page à chaque filtre a peu de chances de tenir ce cap.
4. Des sauvegardes que quelqu'un a déjà restaurées
« Oui, c'est sauvegardé » ne veut rien dire tant que personne n'a essayé de restaurer. Demandez à quelle fréquence les données sont sauvegardées, où elles le sont (idéalement pas au même endroit que le serveur principal), combien de temps elles sont conservées, et quand a eu lieu le dernier test de restauration.
5. Vos données peuvent sortir
Une application qui gère votre activité doit vous permettre d'exporter vos données dans un format lisible (CSV, Excel, JSON), sans avoir à le demander par email. C'est une question d'indépendance vis-à-vis du prestataire, et parfois une obligation : le RGPD prévoit un droit à la portabilité pour les personnes dont vous traitez les données (article 20).
6. Le RGPD intégré dès la conception
Qui a accès aux données personnelles, combien de temps elles sont conservées, comment on les supprime : ces questions se règlent dans l'architecture de l'application, pas dans une page de mentions légales. La CNIL publie un guide RGPD destiné aux développeurs, organisé en fiches thématiques et accompagné d'exemples, qui donne une bonne idée de ce qu'un prestataire sérieux devrait déjà appliquer.
7. Des évolutions qui ne cassent pas l'existant
Une application vit : on ajoute un champ, un statut, un rôle. Chez un prestataire outillé, chaque modification est testée dans un environnement de recette avant d'arriver en production, et le code est versionné, ce qui permet de revenir en arrière. Si chaque mise à jour se fait directement « en ligne », sur l'outil que votre équipe utilise au même moment, c'est un signal.
Le site déguisé n'est pas toujours un mauvais choix
Soyons honnêtes : pour tester une idée avec quelques utilisateurs, un formulaire relié à un tableur suffit parfois largement. Le problème n'est pas l'outil simple, c'est l'outil simple présenté et facturé comme une application, ou celui qu'on garde bien après avoir dépassé ses limites. Le bon moment pour passer à une vraie application, c'est quand plusieurs personnes dépendent chaque jour des mêmes données, que certaines ne doivent pas tout voir, ou que les erreurs de saisie commencent à coûter.
Ces critères rejoignent deux conseils déjà donnés sur ce blog : sécuriser les données dès le départ d'un projet de digitalisation, et ne pas négliger l'intégration des données quand on change d'outils.
Les questions à poser avant de signer
- Qui peut voir quoi, et où ces règles sont-elles vérifiées ?
- Comment l'historique des modifications est-il conservé ?
- Où sont les sauvegardes, et quand a eu lieu la dernière restauration ?
- Comment exporter toutes mes données, sans passer par vous ?
- Comment une nouvelle version est-elle testée avant d'être mise en ligne ?
Un prestataire qui répond précisément à ces cinq questions construit probablement une vraie application. Un prestataire qui les trouve excessives vous a peut-être vendu un site.