Comment créer une application web en 12 étapes

Créer une application web demande de relier un besoin concret à un service utilisable, puis à une organisation capable de le maintenir. Le choix technique intervient dans ce processus, avec des décisions sur les usages, les données et les conditions d’ouverture. La rédaction recommande que chaque étape produise quelque chose que l’équipe peut examiner et valider.

Ce guide Anaska, présente les recommandations de la rédaction. Le fil conducteur est un exemple pédagogique fictif : une application de réservation de matériel partagé. Les livrables proposés servent à faire avancer le projet, sans transformer la démarche en rédaction interminable de documents.

1. Décrire le problème à résoudre

Commencez par observer une tâche existante. Qui cherche à accomplir quoi, dans quelle situation et avec quelle difficulté ? Interrogez les personnes qui exécutent la tâche et celles qui traitent ses conséquences. Séparez leurs observations des solutions proposées : demander un calendrier ne précise pas encore pourquoi les réservations posent problème.

Dans notre exemple pédagogique, plusieurs demandes peuvent concerner le même équipement sans que le responsable dispose d’une vue commune. Le problème à examiner devient la difficulté à connaître la disponibilité et à suivre une décision. Une application reste une réponse possible ; vérifiez d’abord si une clarification du fonctionnement actuel suffirait.

MDN présente la préparation du contenu, des fonctions et de l’apparence comme un travail précédant le code dans son guide de préparation d’un premier site. Pour un projet applicatif, nous recommandons de commencer cette préparation par la tâche à améliorer.

Livrable : une note de problème indiquant la situation actuelle, les personnes concernées, les difficultés observées et le changement attendu. Validation : les personnes interrogées reconnaissent leur situation dans cette note. Évitez les objectifs invérifiables comme « moderniser les échanges » et conservez les désaccords à éclaircir.

2. Identifier les usages prioritaires

Décrivez les usages avant de les convertir en fonctionnalités. Un usage associe une personne, un contexte et un résultat recherché. Consulter une disponibilité depuis un téléphone et arbitrer plusieurs demandes depuis un bureau peuvent relever du même service tout en exigeant des interactions différentes. Retenez ces différences lorsqu’elles changent réellement la tâche.

Pour chaque usage, demandez ce qui déclenche l’action, quelles informations sont disponibles au départ et comment la personne reconnaît qu’elle a terminé. Dans l’exemple pédagogique, le demandeur veut connaître la réponse à sa réservation ; le responsable veut identifier les demandes nécessitant une décision. Une notification éventuelle constitue un moyen à discuter, pas le besoin lui-même.

La rédaction recommande de classer les usages selon leur contribution au problème initial et les conséquences de leur absence. Une demande exprimée avec insistance mérite d’être comprise, mais ne devient pas automatiquement prioritaire. Distinguez aussi l’utilisateur habituel de la personne qui intervient uniquement lorsqu’une situation se bloque.

Livrable : un ensemble de fiches d’usage courtes, chacune reliée à un acteur et à un résultat observable. Validation : les représentants des usages principaux peuvent expliquer pourquoi chaque fiche existe et ce qui manquerait sans elle. Évitez les profils imaginés à partir des seuls intitulés de poste.

3. Fixer le périmètre de la première version

Composez une première version qui permette de terminer une tâche. Pour la réservation, afficher les équipements sans permettre de retrouver sa demande laisserait le parcours incomplet. À l’inverse, ajouter des recommandations personnalisées ne résout pas nécessairement le problème de disponibilité. Examinez chaque fonction par rapport aux usages retenus.

La rédaction recommande de rendre visibles les exclusions et leurs conséquences opérationnelles. Une opération peut rester manuelle si une personne accepte de la prendre en charge et si l’utilisateur sait comment poursuivre. Cette décision devrait être explicite : une tâche oubliée et une tâche volontairement traitée autrement n’appellent pas le même suivi.

Livrable : une liste arbitrée des fonctions incluses, reportées et prises en charge autrement. Validation : le responsable du projet et les personnes chargées du service acceptent les limites. Pour toute nouvelle demande, réexaminez les dépendances et la capacité de réalisation avant de modifier le périmètre.

4. Construire les parcours et leurs exceptions

Représentez maintenant la succession des actions, des décisions et des changements d’état. Commencez au déclencheur réel, même s’il se situe hors de l’application, puis poursuivez jusqu’au résultat reconnu par l’utilisateur. Faites apparaître les passages de responsabilité : une demande envoyée peut encore attendre l’intervention d’une autre personne.

Dans notre exemple pédagogique, distinguez la consultation d’une disponibilité et la confirmation d’une réservation. Décidez ce qui se passe si l’équipement devient indisponible entre ces actions. Précisez également les possibilités d’annulation, le retour après interruption et la manière de retrouver une demande ancienne. Ces choix déterminent le comportement attendu de l’application.

La rédaction recommande de rédiger les messages importants dès cette étape. Une formule comme « demande reçue, décision en attente » exprime un état plus précis qu’une confirmation générique. Examinez les erreurs sans issue : lorsqu’une action échoue, prévoyez une indication permettant de savoir quelle information corriger ou comment obtenir une aide adaptée.

Livrable : un schéma des parcours accompagné des états et des règles de transition. Validation : une personne métier peut dérouler chaque parcours principal et expliquer les exceptions retenues. Évitez de dessiner uniquement les écrans réussis ; signalez les branches encore indécises avant de passer au prototype.

5. Organiser les données et les droits d’accès

Recensez les informations nécessaires à chaque action. Pour une réservation, distinguez l’équipement, la demande, son auteur et les décisions prises. Définissez le sens des champs : une date de demande et une date d’utilisation ne répondent pas à la même question. Repérez les informations calculées pour éviter de les confondre avec celles saisies par l’utilisateur.

La rédaction recommande d’examiner chaque donnée sous trois angles : son utilité, sa provenance et les personnes qui peuvent agir dessus. Questionnez les commentaires libres et les pièces jointes avant de les intégrer. Prévoyez aussi le traitement d’un compte désactivé ou d’un équipement retiré lorsque des demandes y sont encore associées.

Livrable : un dictionnaire des données et une matrice des droits par action. Validation : chaque information possède une utilité identifiée et chaque modification un acteur autorisé. Consignez les décisions de conservation et de suppression restant à examiner ; ne les laissez pas dépendre d’un comportement technique implicite.

6. Choisir une architecture adaptée au service

Demandez une représentation compréhensible des composants et des échanges. Faites-y apparaître où s’exécutent les traitements, où sont enregistrées les données et quelles dépendances externes interviennent. Reliez chaque composant à une tâche du parcours pour pouvoir discuter de sa nécessité et des conséquences d’une indisponibilité.

Dans sa page modifiée le 12 septembre 2026, MDN distingue les rôles du navigateur et du serveur : le premier prend en charge la présentation et les interactions, tandis que le second peut valider les requêtes, accéder aux données et déterminer la réponse. Il peut notamment renvoyer du HTML ou des données.

La rédaction recommande de comparer les options à partir des contraintes connues : compétences de maintenance, échanges avec d’autres services, fonctionnement dégradé et capacité à reprendre le projet. Demandez où seront contrôlés les droits et comment seront gérées les modifications simultanées. Un nom de technologie ne répond pas à ces questions.

Livrable : un schéma d’architecture assorti des raisons des choix et des principales limites. Validation : l’équipe sait expliquer un parcours complet à travers les composants et identifier les dépendances critiques. Évitez de multiplier les services sans besoin établi ; rendez les hypothèses incertaines vérifiables par une expérimentation ciblée.

7. Éprouver les interactions avec un prototype

Construisez un prototype centré sur les décisions encore incertaines : emplacement d’une action, compréhension des statuts, distinction entre demande et confirmation. Utilisez un niveau de détail suffisant pour mettre ces questions à l’épreuve. Une représentation très travaillée peut détourner la discussion vers l’apparence alors que le fonctionnement reste à clarifier.

Proposez à des personnes concernées une tâche précise, puis laissez-les chercher comment l’accomplir. Dans notre exemple pédagogique : retrouver une demande refusée et comprendre la suite possible. Relevez les hésitations et les interprétations sans expliquer immédiatement l’interface. Séparez ce que vous observez de votre hypothèse sur la cause.

La rédaction recommande d’inclure des contenus représentatifs : intitulé long, liste vide, message d’erreur et information manquante. Examinez également l’ordre de navigation et la compréhension des commandes sans dépendre uniquement de leur couleur. Consignez les limites du support utilisé : une simulation d’écran ne vérifie pas la persistance des données ni les contrôles d’accès.

Livrable : un prototype accompagné des observations et des modifications décidées. Validation : les principales ambiguïtés de parcours ont reçu une réponse examinable. Ne considérez pas une préférence esthétique comme une preuve de compréhension ; revenez à la tâche et au résultat attendu.

8. Réaliser des parcours complets et examinables

Organisez la réalisation autour de séquences utilisables. Dans cet exemple pédagogique, commencez par créer une demande, l’enregistrer et la retrouver après actualisation. Cette séquence permet d’examiner ensemble l’interface, les traitements et les données. Complétez ensuite les décisions du responsable et les exceptions selon les dépendances du périmètre.

Pour chaque séquence, attribuez un interlocuteur métier, une responsabilité de réalisation et une personne chargée d’accepter le résultat. Rassemblez les questions ouvertes avec leurs conséquences. Si une réponse manque, décidez explicitement de suspendre la partie concernée ou de retenir une hypothèse réversible ; évitez que le développement transforme silencieusement une supposition en règle.

La rédaction recommande de présenter des démonstrations manipulables avec des données fictives clairement identifiées. Faites exécuter les actions par la personne qui valide. Vérifiez ce qui subsiste après fermeture, ce qu’un autre rôle voit et ce qui se produit lors d’une tentative incorrecte. Conservez les décisions près des éléments concernés.

Livrable : une version intermédiaire utilisable, avec les scénarios couverts et les limites connues. Validation : chaque parcours annoncé peut être reproduit et son résultat observé. Évitez d’accepter une fonctionnalité sur la seule présence d’un bouton ou sur une démonstration préparée impossible à reprendre.

9. Vérifier les comportements et traiter les anomalies

Construisez la recette à partir des parcours et des règles retenus. Pour chaque scénario, indiquez les conditions de départ, l’action, le résultat attendu et les données à examiner. Couvrez les rôles autorisés et refusés, les saisies incomplètes, les actions répétées et les décisions concurrentes. Choisissez les navigateurs et appareils selon les usages établis.

Le projet OWASP Top 10 présente un document de sensibilisation aux risques critiques de sécurité des applications web. Au 14 octobre 2026, sa page indique l’édition 2025 comme version publiée courante. Cette référence peut orienter une discussion technique ; sa mention ne prouve pas que votre application a été vérifiée.

La rédaction recommande de relier les contrôles de sécurité aux actions concrètes : accéder à la demande d’un autre compte, modifier un statut sans autorisation ou transmettre une valeur inattendue. Demandez une trace des vérifications adaptées au projet. Consignez chaque anomalie avec son contexte, sa reproduction et son effet sur la tâche.

Livrable : un dossier de recette avec résultats, anomalies et décisions de correction. Validation : les défauts bloquants sont traités et les limites restantes explicitement acceptées. Rejouez chaque correction dans son parcours ; évitez de déclarer une anomalie résolue sur la seule annonce d’une modification.

10. Préparer et décider le lancement

Préparez le lancement comme un changement de fonctionnement. Définissez les personnes auxquelles le service sera ouvert, les données initiales nécessaires et le point de passage depuis l’ancien processus. Dans l’exemple pédagogique, décidez comment traiter les réservations déjà acceptées pour qu’elles ne disparaissent pas de la disponibilité présentée.

La rédaction recommande une répétition du déploiement dans un environnement adapté, avec vérification des accès, des paramètres et du parcours essentiel après installation. Précisez qui décide de l’ouverture et qui peut demander son interruption. Pour préparer un retour à une version précédente, examinez aussi les données créées depuis le changement et leur devenir.

Préparez une aide orientée vers les tâches : demander un équipement, retrouver une réponse, signaler une incohérence. Indiquez les limites connues qui influencent réellement l’usage. Si une ouverture progressive est retenue, expliquez ce que cette progression permettra d’observer et quelles conditions autoriseront son élargissement.

Livrable : une procédure de lancement comprenant préparation, vérifications, décision et repli. Validation : les responsables disposent des accès nécessaires et peuvent exécuter la procédure sans connaissance implicite. Évitez de confondre une application accessible avec un service prêt : vérifiez également l’organisation du traitement des demandes et de l’assistance.

11. Assurer l’exploitation et la continuité

Après l’ouverture, distinguez un problème technique, une erreur de donnée et une question d’usage. Pour chacun, définissez un canal de signalement, une personne chargée du premier examen et un circuit de résolution. Préparez les informations utiles au diagnostic sans demander systématiquement des captures contenant des données personnelles ou des accès.

La rédaction recommande de documenter les tâches récurrentes : examiner les alertes pertinentes, gérer les comptes, suivre les dépendances et vérifier les opérations de sauvegarde. Reliez chaque tâche à un responsable capable d’agir. Une notification reçue dans une boîte sans suivi ne constitue pas une organisation d’exploitation.

Examinez concrètement la récupération du service. Faites vérifier une restauration dans un contexte adapté et consignez ce qu’elle permet de retrouver. Précisez où sont conservées les procédures et comment une personne habilitée obtient les accès nécessaires. Pour préparer la transmission du projet, rassemblez les explications utiles à sa reprise et un inventaire compréhensible des composants.

Livrable : un dossier d’exploitation et un registre des incidents avec les actions décidées. Validation : une personne désignée peut diagnostiquer une interruption, contacter le bon interlocuteur et suivre la procédure de récupération. Évitez de dépendre exclusivement de la mémoire du développeur ayant réalisé la première version.

12. Faire évoluer l’application à partir des usages

Revenez au problème initial pour évaluer la suite. Les personnes trouvent-elles leur demande ? Comprennent-elles la décision ? Quelles tâches nécessitent encore une intervention imprévue ? Choisissez les observations nécessaires pour répondre à ces questions, puis rapprochez les retours d’usage des incidents et des limites connues.

La rédaction recommande de distinguer correction, amélioration et nouveau besoin. Une confusion de statut peut appeler une révision du message ; elle ne justifie pas automatiquement une nouvelle fonctionnalité. Pour chaque évolution, décrivez le changement attendu, les personnes concernées et les effets possibles sur les parcours, les droits et l’exploitation.

Dans notre exemple pédagogique, une demande de réservation récurrente introduirait de nouvelles questions : modification d’une occurrence, indisponibilité partielle et annulation de la série. Réexaminez ces conséquences avant de l’ajouter. Une fonction apparemment proche d’une fonction existante peut nécessiter de nouvelles décisions métier et une nouvelle validation.

Livrable : une liste d’évolutions argumentées, reliées aux observations et aux décisions attendues. Validation : chaque élément retenu possède un bénéfice explicite et un parcours vérifiable. Archivez les idées reportées avec leur motif. Pour engager une nouvelle phase avec un prestataire, rassemblez ces éléments avant de déposer un projet.