Cahier des charges d’application web : méthode et exemple

Cahier des charges fonctionnel ou technique

On distingue souvent deux documents. Le cahier des charges fonctionnel décrit le besoin du point de vue des utilisateurs : ce qu’ils doivent pouvoir faire, sans dire comment. Le cahier des charges technique décrit les choix de réalisation : langages, framework, hébergement, architecture.

En tant que porteur de projet, concentrez-vous sur le fonctionnel. C’est le métier du prestataire de proposer les choix techniques, puis de les justifier. Mentionnez uniquement les contraintes techniques réelles : un logiciel existant avec lequel l’application doit communiquer, un hébergement imposé par votre secteur, une politique de sécurité interne.

Les rubriques indispensables

Un cahier des charges utile tient en quelques pages s’il couvre ces points :

• Le contexte : votre activité, la façon dont le travail se fait aujourd’hui et ce qui pose problème
• Les objectifs : ce que l’application doit changer, formulé en résultats concrets (moins de ressaisie, un suivi partagé, un espace client)
• Les utilisateurs et leurs rôles : qui se connecte, qui voit quoi, qui peut modifier ou valider
• Les parcours principaux : pour chaque rôle, les actions courantes décrites étape par étape
• Les données : ce que l’application stocke (clients, dossiers, réservations, documents) et d’où viennent les données existantes
• Les règles de gestion : calculs, statuts, circuits de validation, cas particuliers
• Les connexions : outils avec lesquels l’application doit échanger (paiement, comptabilité, agenda, messagerie)
• Les contraintes : sécurité, RGPD, accessibilité, appareils utilisés, contexte d’usage
• Les priorités : ce qui est indispensable pour une première version, ce qui peut venir ensuite

Exemple de plan de cahier des charges

Voici un exemple de plan pour un logiciel métier de suivi d’interventions, à adapter à votre activité. Chaque partie peut tenir en quelques paragraphes ou en une liste :

Les erreurs qui faussent les devis

Certaines erreurs reviennent dans presque tous les premiers jets. Elles ne sont pas graves si on les repère tôt :

• Décrire des écrans au lieu de besoins : « un bouton vert en haut à droite » dit comment, pas pourquoi
• Tout mettre au même niveau de priorité, ce qui empêche de construire une première version rapidement
• Oublier les cas particuliers : annulation, modification après validation, client en double, donnée manquante
• Passer sous silence la reprise des données existantes, alors qu’elle conditionne la mise en service
• Recopier un logiciel concurrent fonction par fonction, au lieu de partir de votre façon de travailler
• Écrire seul, sans les personnes qui utiliseront l’outil au quotidien

Et si vous n’avez pas le temps de l’écrire ?

Un cahier des charges parfait n’est pas un préalable. Une page qui décrit le contexte, les utilisateurs et les trois problèmes principaux suffit pour ouvrir la discussion. Le reste se construit pendant l’atelier de cadrage, avec un prestataire qui pose les bonnes questions et formalise les réponses.

C’est la démarche que nous suivons pour chaque projet d’application web sur mesure : vous nous décrivez votre situation avec vos mots, nous rédigeons ensemble le périmètre et les priorités, puis vous recevez un devis détaillé fonctionnalité par fonctionnalité. Pour estimer le calendrier, lisez aussi combien de temps pour développer une application web.