Cahier des charges web : décrire les usages plutôt que les écrans

Pilotage de projet digital · 6 min de lecture

Un cahier des charges web utile décrit qui doit faire quoi, dans quelle situation et avec quel résultat attendu. Les écrans viennent ensuite, pour traduire ces usages. Pour une petite entreprise, cette approche permet surtout de comparer des propositions sur un périmètre commun et de vérifier que le site livré répond aux besoins définis.

À retenir

• Partez des tâches réelles, pas d’une liste de fonctionnalités souhaitées.
• Associez chaque usage prioritaire à des critères de validation observables.
• Précisez les exceptions, les données nécessaires et la personne qui tranche.
• Gardez les maquettes comme support de discussion, sans leur faire remplacer les exigences.

Partir des tâches que le site doit permettre

« Ajouter un espace client » décrit une solution. « Permettre à un acheteur de retrouver un document lié à sa commande » décrit un besoin. La distinction compte : le second énoncé laisse discuter les solutions possibles et leurs contraintes, tandis que le premier impose déjà une forme.

Le Service Manual de GOV.UK recommande de décrire le problème de l’utilisateur et de traiter les suggestions non issues d’utilisateurs comme des hypothèses à vérifier. Cette méthode, conçue pour les services publics britanniques, peut aussi guider un cahier des charges d’entreprise.

Recueillir des situations, pas seulement des avis

Relisez les demandes reçues par le support, les questions commerciales et les difficultés signalées par l’équipe. Faites expliquer une tâche récente : quel était le point de départ, quelle information manquait, comment la personne a-t-elle obtenu sa réponse ? Distinguez les observations documentées des suppositions. Un souhait du dirigeant peut rester pertinent, mais il doit apparaître comme un choix à discuter.

N’oubliez pas les utilisateurs internes. Préparer une commande, corriger une fiche produit ou transmettre une demande au bon interlocuteur fait partie des usages à décrire, même si ces actions ne sont pas visibles sur le site.

Écrire une fiche d’usage vérifiable

Pour chaque tâche prioritaire, indiquez le profil concerné, le déclencheur, l’action souhaitée et son objectif. Ajoutez les informations nécessaires, le résultat attendu et les conditions particulières. La documentation GOV.UK sur les récits utilisateurs propose ce cadre et définit les critères d’acceptation comme des résultats permettant de vérifier que le besoin est satisfait.

Définir ce qui permettra d’accepter la livraison

Évitez « le formulaire doit fonctionner ». Précisez ce qui se passe lorsqu’il est envoyé, ce que voit le visiteur, où arrive la demande et comment une erreur est signalée. Les critères décrivent le comportement attendu, sans imposer inutilement une extension ou une technologie.

Attribuez une priorité à chaque usage : indispensable à l’ouverture, utile mais reportable, ou hors périmètre. Si tout est indispensable, demandez quelle tâche peut réellement attendre. Notez aussi les dépendances : une donnée produit, un accès à un logiciel ou une validation métier peuvent conditionner la réalisation.

Exemple illustratif : demander un devis exploitable

Cet exemple est fictif. Une entreprise de fournitures professionnelles veut recevoir des demandes de devis pour des équipements configurables. Son premier document mentionne seulement « une page devis avec formulaire ».

Une formulation centrée sur l’usage serait : « En tant que responsable d’achat, je veux transmettre les caractéristiques de l’équipement recherché afin que l’entreprise puisse étudier ma demande sans me faire tout ressaisir. »

Les critères de validation pourraient être les suivants :

• Le demandeur identifie les informations indispensables avant l’envoi.
• Une information manquante est signalée sans effacer les champs déjà remplis.
• Après un envoi réussi, une confirmation explique la suite du traitement.
• La demande parvient à la personne désignée avec ses informations structurées.
• L’équipe peut distinguer une nouvelle demande d’une demande déjà prise en charge.

Une maquette peut ensuite montrer les champs et la confirmation. Elle ne prouve pas, à elle seule, que la demande arrive ni que l’équipe sait la traiter.

Inscrire les contraintes et les décisions ouvertes

Ajoutez les contraintes qui changent la réponse possible : consultation sur mobile, documents à joindre, logiciel destinataire, droits des collaborateurs, contenus disponibles. Pour les données personnelles, la CNIL rappelle le principe de minimisation : la collecte doit être adéquate, pertinente et nécessaire à sa finalité. Justifiez donc chaque champ au lieu de reprendre un formulaire par habitude.

Séparez les exigences confirmées des points à arbitrer. Chaque question ouverte doit avoir un responsable et une échéance de décision compatible avec le projet. Si le périmètre évolue, consignez la modification, sa raison et ses conséquences sur la réalisation avant de l’accepter.

Checklist avant de transmettre le cahier des charges

• Les profils concernés et leurs tâches principales sont identifiés.
• Les besoins observés sont distingués des hypothèses.
• Les usages indispensables ont des critères d’acceptation.
• Les erreurs et les situations particulières sont décrites.
• Les données, contenus et dépendances ont un responsable.
• Le périmètre exclu est écrit, pas laissé implicite.
• La personne qui valide chaque usage est désignée.

Limites et erreurs fréquentes

Un document détaillé ne dispense pas de discuter les usages avec les personnes concernées. Il peut même figer une mauvaise hypothèse si personne ne la vérifie. Autres erreurs : copier le site d’un concurrent sans comprendre son fonctionnement, confondre préférence graphique et besoin métier, ou ajouter des fonctions sans modifier les critères de réception. Inscrivez les contraintes visuelles déjà connues, comme la charte graphique ou la lisibilité attendue, puis affinez les choix pendant la conception. Décrire les usages ne signifie pas exclure du cahier des charges les exigences d’accessibilité, de sécurité, de performance ou de maintenance. Rendez aussi les changements de périmètre explicites.

Questions fréquentes

Faut-il supprimer la liste des pages ?

Non. Elle sert à comprendre l’organisation du contenu. Reliez simplement chaque page aux tâches qu’elle facilite, plutôt que de la considérer comme une exigence suffisante.

Faut-il déjà choisir une technologie ?

Seulement si une contrainte réelle l’impose. Sinon, décrivez les usages et les interfaces nécessaires, puis demandez au prestataire de justifier son choix technique.

Qui doit valider les critères ?

La personne qui connaît la tâche métier, avec l’équipe qui réalisera les tests. Le dirigeant arbitre les priorités, mais ne doit pas deviner seul le fonctionnement quotidien.

Prochaine étape : décrire une tâche indispensable

Choisissez un usage sans lequel le site ne rendrait pas le service attendu. Écrivez sa fiche, ses exceptions et ses critères, puis faites-la relire par la personne qui réalise aujourd’hui cette tâche. Pour situer ce travail dans un accompagnement, consultez les services web de 4SYSTEM.

Sources et ressources

• GOV.UK : comprendre les utilisateurs et leurs besoins.
• GOV.UK : rédiger des récits utilisateurs et des critères d’acceptation.
• CNIL : minimiser les données collectées.