Un use case, ou cas d’usage, décrit une interaction précise entre un utilisateur et un système pour atteindre un objectif. Appliquée à la rédaction d’un cahier des charges, la définition de use cases remplace les listes de fonctionnalités abstraites par des scénarios concrets, ancrés dans le quotidien des futurs utilisateurs. Ce changement de perspective modifie la structure du document, son niveau de détail et sa capacité à limiter les malentendus entre maîtrise d’ouvrage et maîtrise d’œuvre.
Use case dans un cahier des charges : ce que le terme recouvre vraiment
Un use case n’est pas une user story, ni une spécification fonctionnelle classique. La confusion entre ces trois formats génère des cahiers des charges hybrides, difficiles à exploiter.
A lire également : Broker Runtime : définition et utilité
Le use case décrit un scénario complet d’interaction : un acteur (humain ou système externe), un déclencheur, une séquence d’étapes, un résultat attendu, et des cas alternatifs ou d’erreur. Il répond à la question « que se passe-t-il quand l’utilisateur veut accomplir telle action ? ».
Une spécification fonctionnelle, elle, décrit ce que le système doit faire sans nécessairement relier la fonctionnalité à un contexte d’utilisation. « Le système permet l’export CSV » est une spécification. « Le responsable logistique exporte la liste des commandes en retard au format CSV pour la transmettre au transporteur » est un use case.
A lire aussi : Comprendre les algorithmes : définition et utilité dans la technologie moderne
Cette différence de granularité change la nature du cahier des charges. Un document structuré par use cases oblige chaque exigence à justifier son existence par un besoin utilisateur identifiable.
Processus AS-IS et TO-BE : le socle avant de rédiger les cas d’usage
Rédiger des use cases sans avoir cartographié les processus existants produit des scénarios déconnectés du terrain. Des ressources spécialisées dans les cahiers des charges logiciels recommandent de partir des processus AS-IS (ce que les utilisateurs font aujourd’hui) pour construire ensuite les processus TO-BE (comment ils travailleront demain).
Chaque processus TO-BE se traduit alors en cas d’usage concrets, priorisés du point de vue de l’utilisateur. Le cahier des charges s’organise autour de scénarios d’utilisation plutôt que de rubriques techniques.
Ce que cette approche change dans la structure du document
Au lieu d’une section « fonctionnalités » monolithique, le cahier des charges se découpe par famille d’acteurs et par objectif métier. Un bloc regroupe les use cases du gestionnaire de stock, un autre ceux du commercial terrain, un troisième ceux de l’administrateur système.
Cette organisation facilite la lecture pour les prestataires. Chaque équipe technique identifie rapidement les scénarios qui la concernent, sans parcourir un document de bout en bout.
Périmètre négatif et non-objectifs : ce que les use cases permettent d’exclure
Un cahier des charges qui liste uniquement ce que le projet doit faire laisse la porte ouverte au scope creep. Des acteurs du développement sur mesure insistent sur la nécessité d’inclure une section de non-objectifs explicites, documentant ce que le projet ne couvrira pas dans sa première version.
L’analyse par use cases rend cette exclusion plus facile à formuler et à défendre. Au lieu d’écrire « le module de reporting avancé est hors périmètre » (formulation vague), on précise : « le cas d’usage ‘le directeur financier génère un tableau de bord prévisionnel à 12 mois’ est reporté en phase 2 ».
La formulation par scénario rend le périmètre exclu compréhensible par les parties prenantes métier, pas seulement par l’équipe technique. Elle réduit les négociations tardives parce que chaque exclusion est rattachée à un besoin utilisateur identifié.
- Les scénarios couverts en version 1 sont listés avec leur niveau de priorité (critique, souhaitable, optionnel)
- Les scénarios explicitement exclus sont documentés avec la raison de leur report
- Les scénarios incertains sont placés dans une zone tampon, soumise à arbitrage avant le lancement du développement
Rédaction concrète d’un use case pour le cahier des charges
Un use case exploitable dans un cahier des charges contient des éléments structurels précis. L’absence d’un seul de ces éléments transforme le scénario en intention floue.
- Acteur principal : le rôle utilisateur qui déclenche le scénario, pas un nom de personne mais une fonction (gestionnaire RH, client final, capteur IoT)
- Précondition : l’état du système avant le déclenchement du cas d’usage
- Scénario nominal : la séquence d’étapes quand tout se passe comme prévu, décrite action par action
- Scénarios alternatifs : les bifurcations possibles (données manquantes, droits insuffisants, timeout réseau)
- Postcondition : l’état du système après exécution réussie du scénario
Le piège de la granularité
Un use case trop large (« le collaborateur gère ses congés ») ne guide personne. Un use case trop fin (« le collaborateur clique sur le bouton Valider ») relève de la spécification d’interface, pas du cahier des charges.
Le bon niveau de granularité correspond à un objectif utilisateur atteignable en une session de travail. « Le collaborateur pose une demande de congé et reçoit une confirmation » tient ce niveau. Le cahier des charges gagne en clarté quand chaque use case respecte cette règle.
Priorisation des use cases et impact sur le contrat
Lister des use cases sans les hiérarchiser produit un cahier des charges exhaustif mais inexploitable pour le chiffrage. Les prestataires ont besoin de savoir ce qui est négociable et ce qui ne l’est pas.
Une priorisation en trois niveaux suffit dans la plupart des projets : les scénarios sans lesquels le système n’a pas de valeur, ceux qui améliorent significativement l’expérience, et ceux qui peuvent attendre une version ultérieure.
Cette hiérarchisation transforme la relation contractuelle. Le prestataire peut proposer un chiffrage par lot aligné sur les priorités métier, plutôt qu’un forfait global basé sur un volume de fonctionnalités. Les arbitrages budgétaires se font alors sur des scénarios compréhensibles par la direction, pas sur des lignes techniques opaques.
La définition rigoureuse des use cases ne garantit pas à elle seule un bon cahier des charges, mais elle impose une discipline de rédaction qui force chaque exigence à prouver son utilité. Un cahier des charges structuré par scénarios d’utilisation reste lisible six mois après sa rédaction, y compris par des acteurs qui n’ont pas participé à sa conception.
