Un use case, ou cas d’utilisation, décrit une séquence d’interactions entre un acteur et un système pour atteindre un objectif précis. Cette définition, issue du génie logiciel et popularisée par Ivar Jacobson à la fin des années 1980, reste le socle de la modélisation des exigences fonctionnelles. La difficulté ne réside pas dans la rédaction du use case lui-même, mais dans l’identification et l’implication des bonnes personnes pour le produire.
Utilisateurs clés dans la définition des use cases : qui impliquer et à quel moment
La plupart des guides sur les use cases détaillent les composants (acteur, scénario, flux d’événements) sans préciser comment sélectionner les contributeurs. Un use case rédigé par un analyste seul, sans confrontation terrain, produit des scénarios théoriquement corrects mais décalés par rapport aux pratiques réelles.
L’utilisateur clé n’est pas forcément le plus disponible. C’est celui dont le workflow quotidien sera directement modifié par le système. Pour un projet de gestion de données client, le commercial terrain apporte davantage que le directeur commercial, parce qu’il connaît les exceptions, les contournements et les cas limites que personne ne documente.
La norme ISO/IEC/IEEE 29148, dédiée à l’ingénierie des exigences, formalise cette implication continue des utilisateurs et parties prenantes. Les techniques recommandées (entretiens structurés, analyses de workflows, enquêtes ciblées) visent à maintenir des boucles de feedback régulières tout au long du cycle de vie des exigences, pas seulement lors d’un atelier initial.
Concrètement, cela signifie que les utilisateurs clés interviennent à trois moments distincts :
- Lors de la découverte initiale, pour cartographier les objectifs métier et les parcours actuels avant toute rédaction de scénario.
- Pendant la rédaction, pour valider que le scénario principal et les flux alternatifs correspondent à des situations réelles, et non à des hypothèses d’analyste.
- Après la première version stabilisée, pour réviser les use cases face aux retours de tests ou aux évolutions de périmètre du projet.
Voice of customer appliquée aux use cases : dépasser la collecte passive
Dans les projets B2B SaaS, une tendance récente transforme la façon dont les équipes produit définissent leurs cas d’utilisation. Les programmes de voice of customer (VoC) ne servent plus uniquement à recueillir du feedback post-livraison. Ils deviennent un mécanisme actif de découverte et de révision des use cases.
Le principe est direct : au lieu de demander aux utilisateurs ce qu’ils veulent (question qui génère des réponses vagues ou des listes de fonctionnalités), l’équipe analyse les verbatims, les tickets support et les enregistrements de sessions pour identifier des scénarios d’usage non anticipés. Ces scénarios alimentent ensuite la rédaction ou la mise à jour des use cases.
Cette approche change la dynamique de l’implication. L’utilisateur clé n’a pas besoin de participer à un atelier formel pour contribuer. Son comportement réel, capturé et analysé, produit des cas d’utilisation plus fiables que ses déclarations en réunion. Pour un projet de conformité ou de sécurité des données, par exemple, les parcours détectés via VoC révèlent souvent des flux de contournement que les personas théoriques ne prédisent pas.
Rédaction d’un use case : structurer le scénario avec les acteurs métier
Un use case exploitable contient un acteur, un objectif, un scénario principal et des flux alternatifs. La rédaction devient efficace quand chaque élément est validé par une personne qui exécute réellement l’action décrite.
Scénario principal et flux alternatifs
Le scénario principal décrit le parcours nominal : l’acteur déclenche une action, le système répond, l’objectif est atteint. Les flux alternatifs couvrent les exceptions (données manquantes, droits insuffisants, erreur de saisie). Les flux alternatifs représentent la vraie valeur ajoutée du use case, car ce sont eux qui évitent les oublis fonctionnels en phase de développement.
Lors de la rédaction avec un utilisateur clé, une technique efficace consiste à demander : « Que se passe-t-il quand ça ne marche pas comme prévu ? » Cette question génère des scénarios alternatifs concrets que l’analyste n’aurait pas imaginés seul.
Priorisation par objectif business
Tous les use cases identifiés ne méritent pas le même niveau de détail. La priorisation repose sur l’impact métier : un cas d’utilisation lié à la conformité réglementaire ou à la sécurité des données client passe avant un scénario de personnalisation d’interface.
Impliquer un sponsor métier (product owner, responsable de département) dans cette priorisation évite de consacrer des semaines à des use cases secondaires. Le sponsor valide la priorité, l’utilisateur clé valide le contenu : ces deux rôles ne sont pas interchangeables.
Erreurs fréquentes dans l’implication des utilisateurs pour les use cases
La première erreur est de confondre consultation et implication. Envoyer un document de use cases par email pour « validation » ne produit aucun retour exploitable. L’utilisateur clé doit travailler sur le scénario, pas le relire passivement.
La deuxième erreur est de solliciter trop d’acteurs simultanément. Un atelier avec huit participants génère du consensus mou. Deux à trois utilisateurs clés par périmètre fonctionnel suffisent, à condition qu’ils soient choisis pour leur connaissance opérationnelle et non pour leur position hiérarchique.
- Réserver les ateliers collectifs aux phases de priorisation, où les arbitrages entre use cases nécessitent un regard croisé entre métiers.
- Privilégier les entretiens individuels pour la découverte des scénarios, car les utilisateurs décrivent mieux leurs pratiques réelles en tête-à-tête.
- Documenter chaque use case avec le nom de l’utilisateur contributeur, pour faciliter les itérations futures et la traçabilité des exigences.
La qualité d’un use case dépend moins du formalisme de sa rédaction que de la pertinence des personnes qui y ont contribué. Un scénario rédigé avec un utilisateur qui exécute le processus chaque jour couvre naturellement les exceptions et les contraintes réelles, là où un scénario théorique laisse des angles morts qui resurgissent en phase de test.
