Rédiger le cahier des charges d'une application web

Une application web est un logiciel utilisé dans un navigateur : espace client, outil de gestion interne, portail de réservation, suivi d'interventions. Contrairement à un site vitrine, elle manipule des données, gère des utilisateurs aux droits différents et applique des règles propres à votre activité. Son cahier des charges va donc plus loin qu'une liste de pages. Voici les rubriques à écrire et la façon de formuler des exigences exploitables.

En quoi diffère-t-il du cahier des charges d'un site ?

Le cahier des charges d'un site, présenté dans l'article rédiger le cahier des charges d'un site, décrit surtout des contenus et des pages. Celui d'une application décrit des actions : qui fait quoi, avec quelles données, selon quelles règles, et ce qui se passe en cas d'erreur. Il sert à estimer le travail, à comparer des propositions et, plus tard, à vérifier que l'application livrée fait ce qui était attendu.

Quelles rubriques inclure ?

1. Le problème à résoudre

Décrivez la situation actuelle : outils utilisés, tableurs, ressaisies, erreurs, temps perdu. Formulez des objectifs observables : supprimer une ressaisie, suivre l'avancement sans relance, traiter les demandes sans échange d'e-mails. Si vous hésitez encore entre une solution existante et un développement, l'article logiciel du marché ou sur mesure aide à trancher.

2. Les utilisateurs et leurs droits

Listez les profils : administrateur, salarié, responsable, client, partenaire. Pour chacun, précisez ce qu'il peut consulter, créer, modifier ou supprimer. Un tableau qui croise profils et actions évite beaucoup d'ambiguïtés.

3. Les parcours principaux

Décrivez étape par étape les tâches les plus fréquentes. Par exemple : un client dépose une demande et joint un document ; un salarié l'attribue puis la traite ; le client est prévenu de chaque changement. Les parcours révèlent les écrans et les notifications nécessaires.

4. Les fonctions, classées par priorité

Listez les fonctions, classez-les avec la méthode présentée plus bas et signalez celles qui peuvent attendre une version ultérieure.

5. Les données

Indiquez les informations manipulées (clients, commandes, documents, interventions), leur volume approximatif, leur origine et leur durée de conservation. Précisez les données existantes à reprendre et leur format actuel.

6. Les connexions avec d'autres logiciels

Comptabilité, messagerie, agenda, facturation : précisez quelles données doivent circuler, dans quel sens et à quelle fréquence. Ces échanges passent souvent par une API, une interface qui permet à deux programmes de communiquer. Indiquez si l'éditeur du logiciel concerné en propose une.

7. Les exigences transverses

• Sécurité : mode de connexion, double authentification, traçabilité des actions sensibles.
• Données personnelles : traitements concernés au sens du RGPD, droits d'accès, durées de conservation.
• Hébergement : localisation souhaitée des données, sauvegardes, disponibilité attendue.
• Appareils : ordinateur, tablette, téléphone, usage sur le terrain.
• Accessibilité : publics concernés et référentiel visé.

8. Le cadre du projet

Échéances, budget indicatif si vous en avez un, personnes chargées de valider, maintenance après livraison, propriété du code source et conditions de réversibilité, c'est-à-dire la possibilité de confier l'application à un autre prestataire.

Comment prioriser les fonctions ?

La méthode MoSCoW classe chaque fonction dans l'une de quatre catégories :

Cette priorisation permet de livrer une première version utile, puis de l'enrichir à partir de l'usage réel.

Comment écrire une exigence vérifiable ?

Une exigence vague produit des désaccords à la livraison. Formulez chaque besoin sous forme de récit utilisateur (user story), accompagné de critères d'acceptation, c'est-à-dire des conditions vérifiables :

En tant que responsable d'équipe, je veux voir les demandes non attribuées depuis plus de deux jours, afin de les répartir.

Critères : la liste est triée par ancienneté ; un filtre par type de demande existe ; seuls les responsables y ont accès.

Décrivez le besoin plutôt que la solution : « retrouver une demande à partir du nom du client » laisse le prestataire proposer le moyen adapté, alors qu'imposer une technologie sans raison réduit les options.

Quelles erreurs éviter ?

• Classer toutes les fonctions comme indispensables.
• Oublier les cas particuliers : annulation, erreur de saisie, utilisateur absent.
• Ne rien dire des données existantes à reprendre.
• Omettre l'hébergement et la maintenance après la mise en service.
• Rédiger sans consulter les futurs utilisateurs.

La page développement web sur mesure décrit comment NexSecure part de ce document pour concevoir une application.