Modèle de cahier des charges pour une application web

Un cahier des charges d’application web décrit un travail collectif : qui agit, sur quelles informations, selon quelles règles et avec quelles conséquences. Son utilité se mesure à la possibilité de trancher une question de fonctionnement et de vérifier la réponse dans l’application livrée. Une liste d’écrans ne suffit donc pas à cadrer un outil métier.

Ce modèle original de la rédaction Anaska, propose des rubriques à compléter et des conditions de validation. Les exemples pédagogiques concernent un portail fictif de demandes de matériel. Ils illustrent des décisions possibles, sans représenter un projet client. Toutes les mesures de contrôle proposées constituent des recommandations de la rédaction, à adapter au contexte.

Le document vise un service utilisé dans un navigateur, avec des données partagées et des opérations métier. Pour un projet organisé principalement autour de contenus publics, consultez le modèle de cahier des charges de site internet. Un projet d’application mobile demanderait également de cadrer ses usages et contraintes propres.

1. Définir le problème métier et le périmètre

Commencez par décrire la situation qui déclenche le travail, les difficultés rencontrées et le résultat attendu. Écrivez ce que les utilisateurs doivent accomplir avant de choisir les menus. Distinguez une difficulté observée, une hypothèse à vérifier et une préférence de présentation : ces éléments ne justifient pas les mêmes décisions.

Trame à compléter : activité concernée ; déclencheur ; utilisateurs ; résultat recherché ; pratiques actuelles ; responsable métier ; fonctions incluses ; exclusions ; dépendances ; décisions ouvertes. Pour chaque fonction, indiquez le besoin auquel elle répond et la conséquence de son absence. Attribuez un responsable à chaque question non résolue.

Exemple pédagogique : le portail permet de demander du matériel, de décider de son attribution et de suivre sa remise. La gestion des fournisseurs reste dans un autre outil. Cette frontière implique de préciser comment le service chargé du matériel reçoit les demandes acceptées, sans ajouter implicitement une gestion complète des achats.

Livrable et validation recommandés : une fiche de périmètre accompagnée des exclusions et hypothèses. Faites reformuler le parcours par les personnes qui exécutent le travail et celles qui l’arbitrent. Évitez les objectifs comme « tout centraliser » : validez plutôt que chaque opération incluse possède un début, une fin et un responsable identifiable.

2. Construire la matrice des acteurs et des droits

Définissez les acteurs par leurs responsabilités, puis les autorisations par action et par ensemble de données. Un intitulé comme « gestionnaire » ne dit pas s’il peut consulter toutes les demandes, modifier une affectation ou exporter des informations. Séparez les fonctions d’administration technique des pouvoirs de décision métier.

Trame à compléter : rôle ; mode d’attribution ; données accessibles ; actions permises ; restrictions ; délégation ; retrait des accès ; personne autorisée à modifier les habilitations. Précisez le comportement lorsqu’une personne change d’équipe ou cumule des rôles. Une délégation doit avoir un périmètre explicite et une condition de fin.

Validation recommandée : confrontez chaque autorisation à un accès permis et à un accès refusé, y compris par ouverture directe d’une adresse. La disparition d’un bouton ne constitue pas une preuve suffisante. Le livrable attendu est une matrice arbitrée, avec les exceptions documentées plutôt que laissées à l’interprétation du développement.

3. Décrire les workflows et leurs exceptions

Pour chaque objet métier, décrivez ses états et les événements qui les font évoluer. Une demande transmise, une demande acceptée et un matériel remis représentent des situations différentes. Définissez leur sens sans dépendre d’une couleur ou d’un libellé provisoire dans une maquette.

Trame à compléter : état initial ; événement ; acteur autorisé ; préconditions ; état obtenu ; données modifiées ; notification éventuelle ; possibilité d’annulation. Ajoutez le comportement si une précondition disparaît pendant l’action, par exemple lorsqu’un matériel devient indisponible avant la confirmation.

Exemple pédagogique : une demande acceptée passe en préparation lorsque le gestionnaire lui affecte un matériel disponible. Si cette disponibilité n’est plus confirmée, la demande conserve son état et une explication invite le gestionnaire à choisir une autre affectation. Le demandeur ne reçoit pas de confirmation de remise.

Livrable recommandé : un tableau des transitions accompagné des exceptions : retrait par l’auteur, refus, réouverture, remplacement du responsable et abandon. Précisez si une correction modifie l’objet existant ou crée une nouvelle demande reliée à l’ancienne.

Condition de validation : les acteurs doivent pouvoir expliquer comment traiter une demande bloquée sans détourner un autre statut. Évitez un état générique « terminé » qui confond acceptation, remise et clôture administrative. Toute transition irréversible mérite une décision explicite sur les confirmations et les possibilités de correction.

4. Formaliser les règles métier indépendamment des écrans

Regroupez les règles dans un registre distinct des maquettes. Une information requise, une interdiction de cumul ou un calcul doivent rester compréhensibles même si l’interface change. Chaque règle précise son domaine d’application, les informations utilisées et le résultat attendu lorsqu’elle ne peut pas être appliquée.

Trame à compléter : identifiant ; formulation ; justification métier ; condition de déclenchement ; données nécessaires ; résultat ; exception autorisée ; responsable de l’arbitrage ; scénario de vérification. Séparez les règles fixes des paramètres modifiables. Pour ces derniers, indiquez qui peut les changer et à quelles demandes la modification s’applique.

Exemple pédagogique : une demande de remplacement nécessite la référence du matériel déjà attribué. Une demande de première attribution ne la nécessite pas. La règle doit préciser le traitement d’un matériel absent du référentiel : blocage, recherche assistée ou demande de régularisation, selon la décision métier retenue.

Validation recommandée : préparez un cas applicable, un cas non applicable et une information manquante. Pour un calcul, ajoutez les conventions d’arrondi et les unités lorsqu’elles sont pertinentes. Évitez les expressions « selon les règles habituelles » ou « validation automatique » sans conditions détaillées. Le registre est exploitable lorsque chaque résultat peut être expliqué sans demander au développeur de choisir la politique métier.

5. Définir les données et les opérations de reprise

Constituez un dictionnaire des données avec des définitions métier. Pour chaque information, précisez son origine, son format, son caractère requis, les personnes autorisées à la modifier et son cycle de vie. Distinguez les identifiants stables des libellés susceptibles de changer, comme le nom d’une équipe.

Trame à compléter : objet ; champ ; signification ; source de référence ; valeurs admises ; unicité ; liens avec les autres objets ; historique ; archivage ; suppression prévue. Faites arbitrer les durées de conservation selon le contexte applicable, sans les déduire d’un modèle générique. Identifiez aussi les données à exclure des jeux de démonstration.

Pour les imports, décrivez la préparation, la correspondance des colonnes, la détection des doublons et la restitution des anomalies. Décidez si une erreur bloque tout le fichier ou permet de proposer les lignes valides. Un aperçu avant confirmation doit préciser ce qui sera créé, modifié ou ignoré.

Exemple pédagogique : deux lignes désignent le même matériel avec des libellés différents. Le modèle demande de choisir la référence faisant autorité et le traitement du conflit, plutôt que de fusionner automatiquement.

Livrable et validation recommandés : dictionnaire, correspondances de reprise et rapport d’import attendu. Vérifiez les liens après reprise et les possibilités de correction. Un fichier accepté techniquement ne prouve pas que ses données sont cohérentes pour le métier.

6. Cadrer les API et les dépendances externes

Décrivez chaque échange comme un fonctionnement à part entière. Indiquez le système émetteur, le destinataire, les données, le déclencheur, les autorisations et la source faisant autorité. Décidez ce qui se produit lorsque les systèmes donnent des informations contradictoires ou ne sont pas disponibles simultanément.

Trame à compléter : finalité ; responsable de chaque système ; opération ; format ; authentification ; réponse attendue ; erreurs ; reprise ; prévention des doublons ; supervision. Précisez les conditions de test et les accès nécessaires. Une connexion mentionnée sans interlocuteur ni environnement utilisable reste une dépendance à résoudre.

La spécification OpenAPI, dans sa version 3.2.1 du 10 septembre 2026, définit une description des API HTTP indépendante du langage de programmation. Recommandation de la rédaction : demandez une description versionnée compatible avec les outils retenus, accompagnée des règles métier et des exemples d’erreur utiles à l’intégration.

Exemple pédagogique : l’annuaire externe ne répond pas lors d’une recherche d’équipe. Le portail indique que la vérification est indisponible ; il n’invente pas une équipe et ne présente pas une ancienne donnée comme confirmée.

Validation recommandée : vérifier un échange réussi, un refus, une réponse invalide et une répétition du même événement. Le livrable doit distinguer réception technique et exécution métier, pour éviter de considérer une demande comme traitée dès son simple envoi.

7. Spécifier les erreurs et les usages simultanés

Décrivez ce que l’utilisateur voit pendant une opération, après sa réussite et lorsque son résultat reste inconnu. Une interruption réseau ne permet pas toujours de conclure que l’enregistrement a échoué. Le cahier des charges doit donc prévoir comment retrouver l’état réel avant de proposer une nouvelle tentative.

Trame à compléter : événement ; état connu ; saisie conservée ou abandonnée ; message ; action de reprise ; contrôle préalable ; assistance disponible. Couvrez le double clic, le retour arrière, le rechargement, l’expiration de session et l’ouverture d’un ancien onglet. Définissez aussi les navigateurs et configurations que la recette devra couvrir.

Validation recommandée : reproduisez ces situations avec des sessions distinctes et examinez les données enregistrées, pas uniquement les messages. Le livrable comprend les états d’interface et les règles de reprise. Évitez le message générique qui invite systématiquement à recommencer : il peut masquer un conflit ou une opération déjà exécutée.

8. Définir les contrôles de sécurité et de qualité d’usage

Remplacez « application sécurisée et intuitive » par un périmètre d’évaluation. Pour la sécurité, identifiez les actions sensibles, les frontières entre organisations, les accès aux pièces jointes et les informations visibles après déconnexion. Précisez qui examine ces points et quelles preuves sont attendues.

L’ASVS d’OWASP fournit une base de vérification des contrôles techniques de sécurité des applications web. OWASP recommande d’associer les références d’exigences à leur version. Recommandation de la rédaction : sélectionner les exigences pertinentes et documenter les exclusions ; mentionner le standard seul ne définit pas le contrôle demandé.

Les WCAG 2.2, recommandation du W3C du 12 décembre 2024, proposent des critères de succès testables et indépendants des technologies. Pour votre projet, faites convenir d’une cible et des modalités d’évaluation, puis décrivez les parcours à examiner : navigation au clavier, compréhension des erreurs et consultation des changements de statut.

Pour la performance, séparez affichage, recherche et traitement métier. Faites fixer les objectifs avec les volumes, la concurrence, le matériel et le réseau de mesure. Livrable recommandé : un plan de contrôle précisant méthode, responsable et résultat attendu. Évitez de déduire la qualité globale d’un écran rapide ou d’un contrôle automatisé isolé ; validez les parcours dans les conditions convenues.

9. Organiser l’audit fonctionnel et les traces métier

L’audit fonctionnel du cadrage consiste à rechercher les contradictions avant la réalisation : action autorisée mais transition impossible, champ requis absent du parcours, ou donnée exportable sans droit de consultation défini. Examinez les liens entre rubriques plutôt que de relire chaque annexe séparément.

Trame à compléter : exigence examinée ; documents concernés ; incohérence ; conséquence utilisateur ; décision proposée ; responsable ; preuve de résolution. Faites parcourir un même dossier par les différents acteurs. Vérifiez notamment ce qui reste possible lorsqu’un responsable quitte son équipe ou qu’un référentiel change.

Distinguez cet audit des traces enregistrées dans l’application. Pour celles-ci, décidez quels événements métier doivent être consultables, par qui et dans quel but. Précisez les informations nécessaires pour comprendre une décision sans recopier systématiquement tout le contenu d’une demande dans les journaux.

Exemple pédagogique : l’historique d’une attribution permet de retrouver l’auteur de la décision, son résultat et la demande concernée. Une correction ultérieure reste identifiable selon la règle retenue. Les détails techniques destinés à l’exploitation suivent un accès distinct.

Validation recommandée : reconstituez un parcours et sa correction avec les seules traces prévues. Le livrable est un relevé d’arbitrages et une politique de journalisation fonctionnelle. Évitez de promettre un « historique complet » sans définir événements, accès et limites.

10. Rédiger les tests d’acceptation et arbitrer la recette

Associez chaque exigence à un scénario observable. Décrivez l’état initial, le rôle connecté, l’action, le résultat et les conséquences sur les données. Ajoutez les notifications ou traces attendues lorsqu’elles participent au fonctionnement. Une capture d’écran peut illustrer un résultat, mais ne démontre pas seule une règle d’accès.

Modèle à compléter : référence de l’exigence ; objectif ; préconditions ; données fictives ; étapes ; résultat attendu ; preuve ; résultat constaté ; anomalie ; décision. Préparez les comptes et données avant la séance. Le scénario doit pouvoir être rejoué sans dépendre d’une explication orale de son auteur.

Exemple pédagogique : étant connecté comme responsable d’une équipe, ouvrir l’adresse d’une demande appartenant à une autre équipe. Résultat attendu selon la matrice proposée : aucune donnée de cette demande n’est révélée, et aucune action métier n’est exécutée.

Prévoyez les cas nominaux, les refus et les reprises. Définissez ensemble la gravité des anomalies selon leurs conséquences, puis les personnes habilitées à accepter une réserve ou à demander une correction. Distinguez une non-conformité à l’exigence validée d’une nouvelle demande fonctionnelle.

Condition de validation recommandée : chaque exigence retenue possède une preuve ou une réserve explicitement arbitrée. Évitez de déclarer la recette terminée parce que la démonstration principale fonctionne ; les restrictions et les exceptions font également partie du comportement attendu.

11. Préparer le déploiement et l’exploitation

Le dossier de livraison doit permettre de mettre en service, surveiller et reprendre l’application. Décrivez les environnements, les configurations nécessaires, les responsabilités et les accès à transmettre. Distinguez les paramètres documentés des secrets, dont la transmission doit suivre le dispositif convenu.

Trame à compléter : procédure de déploiement ; migration des données ; contrôles avant ouverture ; responsable du lancement ; conditions de retour ; surveillance ; sauvegarde ; restauration ; traitement des incidents ; maintenance ; documentation utilisateur. Pour chaque tâche, nommez le responsable et la preuve attendue plutôt que d’écrire simplement « pris en charge ».

Décidez comment gérer les opérations en cours pendant une mise à jour. Si la structure des données change, faites préciser la compatibilité avec la version précédente et les limites d’un retour arrière. Une sauvegarde et une procédure de retour applicatif répondent à des questions différentes ; leurs usages doivent être explicités.

Validation recommandée : demander une répétition du déploiement et, selon le périmètre convenu, une démonstration de restauration sur un environnement approprié. Vérifiez ensuite un parcours métier et les accès essentiels. Le dossier d’exploitation doit expliquer comment reconnaître un incident, retrouver l’opération concernée et orienter le traitement.

Enfin, organisez la transmission des questions ouvertes et des réserves. L’ouverture aux utilisateurs doit reposer sur une décision identifiable, avec des limites connues et des interlocuteurs disponibles pour les traiter.