Cahier des charges digital : transformer un besoin flou en critères vérifiables

« Nous voulons un portail simple, rapide et sécurisé. » Cette phrase exprime une intention, mais ne permet ni de comparer des devis ni de décider si le résultat livré convient. Deux prestataires peuvent y répondre honnêtement avec des périmètres radicalement différents.

Un cahier des charges digital utile transforme le besoin en comportements observables. Il explique qui doit agir, dans quelle situation, avec quelles données et quel résultat. Sa qualité se mesure moins à son nombre de pages qu’au nombre d’ambiguïtés importantes qu’il permet de résoudre.

Le document n’a pas besoin de figer tous les détails dès le premier jour. Il doit rendre les inconnues visibles et organiser leur traitement. Voici une méthode pour y parvenir sans rédiger un catalogue de fonctionnalités impossible à financer.

En bref — Décrivez des parcours réels, leurs exceptions et leurs critères de réussite. Séparez les exigences indispensables des préférences. Précisez les données, les interfaces et les responsabilités. Préparez la recette avant le développement. Toute demande nouvelle doit pouvoir être reliée à son coût et à sa priorité.

Commencer par un problème observable

Une demande de solution arrive souvent avant la description du problème. « Il nous faut une application » peut cacher une difficulté d’accès à une information, un double travail de saisie ou une validation qui attend trop longtemps.

Observez quelques situations concrètes. Qui effectue la tâche ? Quel événement la déclenche ? Où l’information se trouve-t-elle ? Que se passe-t-il lorsque le cas sort du parcours habituel ? Une visite courte auprès des utilisateurs peut révéler une contrainte absente des réunions de direction.

Consignez les irritants sans confondre fréquence et gravité. Une erreur rare qui bloque un paiement peut avoir davantage d’importance qu’un clic supplémentaire quotidien. Évitez également de prendre la préférence d’une personne pour un besoin partagé.

Fixez ensuite les résultats attendus : réduire les dossiers incomplets, fournir un état fiable ou permettre une action sans solliciter le support. Le critère de résultat doit pouvoir être observé. « Améliorer l’expérience » devient exploitable quand on précise le parcours concerné et la manière de constater l’amélioration.

Cette étape rejoint le calcul de rentabilité d’un projet numérique. Si aucune conséquence utile n’est associée à une fonctionnalité, son financement mérite d’être discuté avant le développement.

Écrire des parcours, puis leurs exceptions

Une description de parcours commence par un acteur, une situation initiale et une action. Elle se termine par un résultat métier, pas uniquement par l’affichage d’un écran. « Le client envoie sa demande » ne suffit pas si personne ne sait où elle doit arriver ni comment la suivre.

Dans un exemple fictif, un acheteur B2B doit soumettre une commande à son responsable. Le parcours normal comprend la création, la validation et la transmission. Mais il faut aussi traiter le refus, la correction, l’absence du responsable et le changement de prix avant validation.

Les exceptions ne sont pas nécessairement toutes automatisées. Une procédure manuelle clairement prévue peut être acceptable pour un cas rare. En revanche, elle doit avoir un responsable, un délai et une trace permettant de reprendre le dossier.

Reliez chaque parcours à ses données et à ses droits. Un utilisateur peut avoir le droit de consulter une commande sans pouvoir la modifier. Une autorisation dans l’interface doit correspondre à une vérification côté système ; masquer un bouton ne constitue pas à lui seul un contrôle d’accès.

La formulation en histoire utilisateur peut aider : acteur, besoin et objectif. Elle ne remplace pas les règles métier. Une phrase courte devient un point d’entrée vers les critères détaillés nécessaires au développement et à la recette.

Passer des adjectifs aux critères d’acceptation

Une exigence est vérifiable lorsqu’une personne indépendante peut expliquer comment la tester. « Le calcul est correct » reste incomplet sans données d’entrée et résultat attendu. « Le site est rapide » n’indique ni le parcours, ni la charge, ni la mesure.

Dans notre cas pédagogique, une ligne comporte dix unités à 18 euros, une remise de 5 % et un taux de taxe hypothétique de 20 %. Le montant hors taxe attendu est 10 × 18 × 0,95 = 171 euros ; le montant toutes taxes comprises est 205,20 euros. Le taux est une hypothèse de test, pas une indication fiscale applicable à toute vente.

Le cahier doit préciser les arrondis et l’ordre des opérations. Appliquer une remise avant ou après un calcul déjà arrondi peut produire des écarts. Pour les montants sensibles, utilisez des jeux de test validés par le métier et la comptabilité.

Intention initiale	Critère plus exploitable	Preuve attendue
Commande simple	Un acheteur autorisé soumet une commande complète sans ressaisie obligatoire	Parcours réalisé avec un cas représentatif
Droits sécurisés	Un compte de consultation ne modifie pas une commande, même par requête directe	Test positif et test de refus
Export complet	Les objets, leurs identifiants et les pièces prévues sont présents	Contrôle d’un export et de ses relations
Erreur compréhensible	Le champ concerné est identifié et la saisie valide conservée	Test avec données volontairement invalides

Un test positif montre que l’action autorisée fonctionne. Le test négatif vérifie qu’une action interdite ou une donnée incorrecte ne produit pas un résultat dangereux. Les deux sont nécessaires lorsque les conséquences métier diffèrent fortement.

Décrire les données avant de dessiner les écrans

Inventoriez les objets manipulés : client, contact, commande, ligne, document ou statut. Donnez à chacun une définition et un identifiant. Un « client » peut désigner une entreprise, un établissement ou une personne selon les équipes ; cette ambiguïté devient un problème dès qu’on échange des données.

Pour chaque champ, précisez son origine, son format, son caractère obligatoire et la personne autorisée à le modifier. Déterminez quelle source fait référence. Deux systèmes capables de modifier une adresse sans règle de priorité créent des divergences difficiles à expliquer.

Les contraintes de qualité doivent être réalistes. Un numéro de téléphone manquant peut empêcher une opération précise sans justifier le blocage de tout le dossier. Distinguez la donnée indispensable au parcours de celle simplement souhaitable pour une autre équipe.

Préparez les besoins de reprise : volumes, historiques, pièces jointes et correspondances entre anciens et nouveaux identifiants. Une migration annoncée « incluse » peut couvrir un fichier propre sans inclure le traitement des doublons ou la résolution des incohérences.

Définissez les durées de conservation et les règles d’accès avec les interlocuteurs compétents. Les environnements de test ne doivent pas récupérer par défaut une copie entière des données de production. Des données fictives ou convenablement protégées peuvent suffire selon le test.

Une interface se décrit par son contrat d’échange

Le mot « connexion » ne chiffre pas une intégration. Précisez les objets transmis, le sens de l’échange, sa fréquence et les erreurs possibles. Une synchronisation quotidienne et une mise à jour immédiate n’imposent pas la même architecture.

Identifiez les responsables des deux systèmes. Qui crée les accès ? Qui adapte le format ? Qui surveille les erreurs ? Qui peut corriger une donnée rejetée ? Une interface sans responsable opérationnel devient rapidement une file d’attente invisible.

Documentez le comportement lorsqu’un système ne répond pas. Faut-il bloquer la commande, conserver une demande à transmettre plus tard ou afficher un statut provisoire ? Les réponses dépendent du risque métier, pas uniquement de la facilité technique.

Prévoyez aussi les événements répétés. Si une notification arrive deux fois, le système doit-il créer deux opérations ou reconnaître le doublon ? Cette question paraît technique, mais elle peut affecter des factures, des réservations et des e-mails envoyés aux clients.

Les limites d’API, les formats supportés et les règles d’authentification doivent être vérifiés auprès du fournisseur. Notre dossier sur les coûts et clauses d’un achat SaaS aide à distinguer la fonction annoncée de ce qui est effectivement inclus dans l’édition achetée.

Ne pas oublier les exigences invisibles dans la maquette

La performance doit être décrite pour des conditions précises : volume de données, nombre d’utilisateurs simultanés, parcours et réseau représentatifs. Une réponse rapide avec dix lignes dans une base vide ne prouve pas le comportement avec l’historique réel.

Définissez la mesure et son protocole. Un temps moyen peut masquer des demandes très lentes ; des percentiles peuvent être utiles lorsqu’ils sont calculés sur un échantillon et une période explicités. Le seuil doit découler du besoin et de tests, pas d’un chiffre choisi pour paraître ambitieux.

L’accessibilité mérite des critères sur les actions essentielles : navigation au clavier, libellés, erreurs de formulaire et lecture des informations. Une page jolie ne garantit pas que tous les utilisateurs peuvent terminer le parcours. Déterminez le référentiel et les obligations applicables avec les personnes compétentes.

Pour la sécurité, décrivez les rôles, les journaux nécessaires, la gestion des comptes et la récupération après incident. Évitez la clause absolue « aucune faille ». Elle ne fournit ni méthode d’évaluation ni règle d’exploitation.

Ajoutez la maintenabilité : documentation, accès aux configurations, procédures de déploiement et interlocuteur en cas d’erreur. Le livrable comprend ce qui permettra d’exploiter le service après le départ de l’équipe projet.

Prioriser sans rendre tout indispensable

Classez les exigences selon leur effet sur le résultat et sur le risque. Une fonction bloquante pour le parcours principal n’a pas le même statut qu’un confort d’administration ou qu’une idée pour la version suivante.

Chaque priorité doit avoir une justification. « Le directeur l’a demandé » peut expliquer l’origine d’une demande, mais pas son coût d’opportunité. Posez la question concrète : que ne pourra-t-on pas réaliser si cette fonction prend la place d’une autre ?

Un périmètre minimal doit être utilisable de bout en bout. Livrer un formulaire sans traitement de ses demandes ne constitue pas forcément une première version utile. Inversement, repousser un tableau secondaire peut permettre un lancement plus fiable.

Établissez les dépendances. Une fonction peu visible, comme la normalisation des identifiants, peut conditionner plusieurs parcours prioritaires. La classer comme facultative parce qu’elle n’apparaît pas dans la maquette crée une fausse économie.

Lorsqu’une demande nouvelle apparaît, consignez son origine, son bénéfice, son estimation et la décision prise. Le document évolue alors de manière contrôlée. Un cahier des charges n’est pas une protection contre toute évolution ; c’est un outil pour éviter les changements silencieux.

Préparer la recette avant la livraison

La recette fonctionnelle rapproche les exigences des résultats livrés. Créez une matrice avec un identifiant d’exigence, un scénario, les données d’entrée, le résultat attendu, le résultat observé et le statut.

Choisissez les utilisateurs qui connaissent réellement les parcours. Ils doivent disposer de temps pour tester, pas découvrir l’outil entre deux urgences. Le calendrier du projet doit inclure la préparation des données et la correction des anomalies.

Dans une estimation fictive, douze parcours demandant chacun trois jours représentent trente-six jours de travail de recette. Cela n’inclut pas automatiquement les réunions, les reprises de données, les corrections du prestataire ou les tests techniques. La charge reste une hypothèse à affiner selon la complexité réelle.

Classez les anomalies par conséquence : blocage d’une action essentielle, résultat incorrect, contournement acceptable ou défaut secondaire. Les intitulés doivent être partagés avant la livraison. Un désaccord sur la gravité devient plus difficile à résoudre lorsque la date de lancement approche.

Prévoyez la preuve de correction. Une anomalie fermée dans un ticket n’est pas forcément un scénario retesté avec succès. Conservez le lien entre le défaut, la version corrigée et le résultat du nouveau test.

Comparer les réponses à partir des mêmes hypothèses

Envoyez aux candidats un cadre de réponse commun : périmètre inclus, exclusions, hypothèses, responsabilités et calendrier. Une proposition courte peut être solide si elle documente ces points ; une offre très longue peut laisser les travaux les plus coûteux à la charge de l’entreprise.

Demandez aux prestataires de signaler les exigences qui leur semblent contradictoires ou encore insuffisamment précises. La qualité de ces questions renseigne sur leur compréhension du problème. Un silence complet n’est pas nécessairement un signe de maîtrise.

Pour les postes variables, réclamez une méthode d’estimation et les conditions qui provoqueraient un dépassement. Le montant annoncé devient comparable lorsqu’on sait quel volume de données, quel nombre d’interfaces et quel niveau de reprise il couvre.

Conservez les réponses aux questions dans une version partagée. Si un candidat reçoit une clarification importante, les autres doivent pouvoir construire leur proposition avec les mêmes informations. Vous réduisez ainsi les écarts de périmètre qui ressemblent à des écarts de prix.

La décision finale devrait expliquer les compromis : coût, risque, délai et capacité d’exploitation. Cette justification servira lorsque l’équipe devra arbitrer une évolution ou vérifier si une prestation supplémentaire était déjà prévue.

Le document doit survivre au lancement

La version finale du cahier doit refléter ce qui a été accepté, différé ou abandonné. Elle sert ensuite à l’exploitation, à la formation et aux évolutions. Un document initial déconnecté du service réellement livré perd rapidement sa valeur.

Transmettez les procédures de support et les responsabilités. Qui reçoit une erreur ? Quelle information faut-il fournir ? Quel incident déclenche une alerte immédiate ? Ces réponses réduisent les délais de diagnostic et les renvois entre intervenants.

Lors d’une modification, reprenez les critères touchés et leurs dépendances. Une règle de prix peut affecter la commande, l’export comptable et les documents clients. Le bon périmètre de test suit cet impact plutôt que le seul écran modifié.

Un cahier des charges solide ne promet pas l’absence de surprise. Il permet de repérer les questions encore ouvertes et de relier chaque décision au travail réel. C’est ce qui transforme un projet « moderne » en service dont l’entreprise peut vérifier la qualité, maîtriser le coût et expliquer le fonctionnement.