Comment créer une application web ?

Une application web s’exécute dans un navigateur et se met à jour sans que personne n’ait rien à installer. Cette simplicité apparente masque une réalité de projet : ce qui coûte, ce n’est pas d’écrire les écrans, c’est de rattraper une décision de structure prise trop vite.

Application web, application mobile, PWA : la distinction utile

Une application web tourne dans le navigateur. Aucun téléchargement, aucune validation par un magasin d’applications, une seule version en ligne pour tout le monde. Un outil de gestion interne, un espace client, un service facturé à l’abonnement entrent dans cette catégorie.

Une application mobile s’installe depuis l’App Store ou Google Play. Elle accède pleinement au matériel du téléphone et fonctionne hors connexion, au prix d’une soumission à chaque mise à jour et d’une base de code par plateforme.

Une PWA est une application web à laquelle on ajoute un service worker et un manifeste. Elle s’installe sur l’écran d’accueil, fonctionne en partie hors connexion et peut recevoir des notifications, avec des restrictions qui varient selon le système d’exploitation.

La question n’est pas de savoir laquelle est la meilleure, mais : vos utilisateurs ont-ils besoin du matériel du téléphone et du hors connexion ? Si la réponse est non, l’application web demande moins d’entretien, puisqu’il n’existe qu’une seule version à maintenir.

Ce qui se décide avant la première ligne de code

Quatre points, dans cet ordre.

Qui se connecte, et qui voit quoi. Le modèle de droits est ce qui se rajoute le plus douloureusement après coup. Un outil pensé pour un rôle unique qui doit soudain distinguer administrateurs, gestionnaires et clients se refactorise en profondeur.

Où vivent les données. Leur nature, leur durée de conservation, le pays d’hébergement. Des données personnelles ne se traitent pas comme un catalogue de produits, et le RGPD se conçoit en amont plutôt qu’en correctif.

Ce que l’application doit échanger avec l’existant. Un logiciel de comptabilité, un CRM, un ERP, une caisse. Une intégration prévue dès le départ tient dans le modèle de données ; une intégration ajoutée deux ans plus tard se paie en scripts de synchronisation et en doublons.

Le périmètre de la première version. C’est l’exercice le plus difficile : décider ce qui ne sera pas dans la v1. Le document qui fixe tout cela s’appelle un cahier des charges, et le rédiger sérieusement fait gagner plus de temps qu’il n’en prend.

Le choix de la pile technique

Il se déduit du projet, pas de la mode du moment.

• Un back-end qui porte la logique métier et l’accès aux données. Symfony et Laravel en PHP, Node avec NestJS, Django en Python couvrent la quasi-totalité des besoins d’une application de gestion.
• Un front-end pour l’interface. Angular et React s’imposent dès que l’application compte beaucoup d’écrans et d’états à synchroniser ; une interface simple n’a pas besoin d’un framework.
• Une base de données. PostgreSQL ou MySQL pour des données structurées, ce qui reste le cas le plus fréquent.

Deux critères pèsent plus lourd que les qualités intrinsèques d’un framework : la capacité à trouver des développeurs qui le maîtrisent dans cinq ans, et la facilité de reprise par une autre équipe. Un choix exotique transforme la moindre évolution en mission d’archéologie.

Ce qu’on oublie, et qui se paie

La partie visible d’une application est celle que tout le monde anticipe. Le reste arrive en fin de projet :

• l’authentification, la réinitialisation de mot de passe, la double authentification ;
• les sauvegardes, et leur restauration testée au moins une fois ;
• la supervision : savoir que l’application est tombée avant que l’utilisateur ne le signale ;
• un environnement de test séparé de la production ;
• les journaux d’activité, indispensables le jour où un utilisateur conteste une action ;
• l’export des données, qui est un droit pour l’utilisateur et une assurance pour vous.

Aucun de ces points n’apparaît dans une démonstration. Tous apparaissent au premier incident.

Les étapes, dans l’ordre

• Cadrage : objectifs, utilisateurs, périmètre de la v1, contraintes de données.
• Parcours et maquettes : les écrans et le cheminement, avant tout code. Une maquette se corrige en une heure, un écran développé en une journée.
• Modèle de données : les entités, leurs relations, les droits associés. C’est la fondation, et elle se coule une fois.
• Développement par lots fonctionnels : un lot livré et testé à la fois, plutôt qu’un projet livré en bloc à la fin.
• Recette : des utilisateurs réels sur des cas réels, pas l’équipe projet sur un jeu de test.
• Mise en production : sauvegardes en place, alertes configurées, documentation de reprise écrite.

Sur les outils internes qui remplacent des tableurs et des procédures manuelles, ce découpage se retrouve tel quel dans les projets d’extranet et d’applications métier.

Faire soi-même ou faire faire

Une équipe qui compte déjà des développeurs et du temps disponible peut mener le projet en interne, à condition d’accepter que l’application devienne une charge de maintenance permanente : mises à jour de sécurité, montées de version, corrections. Un projet confié à l’extérieur demande de son côté un interlocuteur capable de trancher vite, faute de quoi le cadrage s’étire et le reste avec lui.

Le mode hybride fonctionne aussi : conception et première version confiées à l’extérieur, reprise en interne une fois le socle posé. C’est ce que nous détaillons sur notre page développement d’applications web.

Trois erreurs qui reviennent

• Confondre l’application et son site de présentation. Ce sont deux projets, deux calendriers, deux budgets.
• Valider un design sans avoir fait tester le parcours. Une maquette sur laquelle personne n’a cliqué ne prouve rien.
• Repousser la question de l’hébergement. Elle conditionne la sécurité, la sauvegarde et le coût de fonctionnement, et elle se pose mal une fois le code écrit.