Savez-vous écrire un use case ? Je parie que non ! 😜

Vous trouverez dans cet article une définition d’un use case, ses avantages et sa méthodologie.

J’avais écrit un article de blog en septembre sur l’importance de demander les besoins métiers des utilisateurs indépendamment des solutions et des technologies. Et oui !!! Toutes les personnes travaillant dans des entreprises ne sont pas des expertes technologiques ou technophiles.

Ce n’est pas à eux de dire quelles solutions vont répondre à leurs problèmes. Ce sont aux architectes SI, aux chefs de projet ou aux responsables informatiques d’identifier les solutions. Et ce sont également à eux de formaliser les besoins sous forme de use case ou de user story.

Deux erreurs fréquentes peuvent envoyer un projet directement dans les choux

1. Erreur 1 : Ne plus faire intervenir les utilisateurs jusqu’à la fin du projet et la livraison du produit. Mon collègue Eric a écrit un super article sur ce sujet
2. Erreur 2 : Mal formaliser le besoin avec l’utilisateur, donc choisir une mauvaise solution. Cela entraine en général une double frustration lors de la présentation de la solution :
   • L’utilisateur pensera que le chef de projet a mal compris son besoin… ou pire qu’il n’est pas capable de répondre à son besoin
   • Le chef de projet se dira qu’il a travaillé pour rien… ou pire se dira que les utilisateurs ne savent pas ce dont ils ont besoin. Bonjour Steve Jobs !

Cette situation est loin d’être rare et c’est l’une des principales causes d’échec de projets ! C’est comme se rendre compte au bout de 100km que vous êtes partis dans la mauvaise direction… c’est dur ! Donc il faut vérifier votre itinéraire avant de partir.

Comment éviter l’erreur : formaliser correctement le besoin avec l’utilisateur et le lui faire valider (ou itérer avec lui)

Il existe 2 outils pour formaliser correctement les besoins métiers d’un utilisateur : les use cases et les user stories. Je vous présente aujourd’hui les use cases.

Définition d’un use case :

Un use case est un texte décrivant un ensemble d’actions permettant de couvrir un besoin. Un use case doit pouvoir évoluer tout au long du projet ou du cycle de vie du produit.

Par ailleurs, en français on peut également entendre les traductions suivantes : cas d’usage ou cas d’utilisation

Exemple de formalisation d’un use case :

Lors de  la construction d’un restaurant, un architecte doit formaliser le use case du besoin client suivant : « Aller aux toilettes sans déranger le service ou les autres clients ».

Formalisation du Use case relatif à ce besoin :

Lors de son repas, un client souhaite se rendre aux toilettes :

• Action 1 : Le client se déplace. Afin d’éviter que le client ne se perde dans le restaurant ou gêne le service et les autres clients, la position des toilettes doit être évidente ou l’affichage doit être clair et visible quelle que soit la position du client dans la salle.
• Action 2 : Si les toilettes sont occupées, le client doit pouvoir attendre dans une zone, proche de la porte, sans être un obstacle pour le service ou une gêne pour d’autres clients.
• Action 3 : Le client ouvre la porte des toilettes. La porte doit idéalement s’ouvrir vers l’extérieur si elle ne gène personne, sinon s’ouvrir vers l’intérieur
• Action 4 : …

Je vous épargne la suite, si j’avais fait l’exercice jusqu’au bout je serais facilement allé jusqu’à 20 actions. Néanmoins nous pouvons voir les avantages d’un use case sur ces 3 exemples d’actions

Avantages du use case :

1. Le besoin est compréhensible par chacun, que ça soit les futurs utilisateurs, les clients, les architectes, les études techniques, la maîtrise d’oeuvre, les chefs de projets… tous les acteurs peuvent facilement se projeter :
   • Pour les clients : Il y a de fortes chances que vous vous soyés retrouver dans l’action 1 et l’action 2. Personnellement 1 fois sur 2 j’erre dans les restaurants pour trouver les toilettes et je finis par déranger le serveur pour lui demander de l’aide 🙂
   • Pour les experts techniques et les architectes : ils peuvent comprendre le contexte sans rien connaître du métier d’un restaurateur ou d’un serveur et proposer les bonnes solutions
   • Pour les chefs de projets ou les commerciaux : ils peuvent, grâce à ce use case, chiffrer l’effort ou le coût de chaque action
2. La mise en forme permet aux parties prenantes de définir dans la liste des actions, celles qui sont prioritaires, impératives ou facultatives
3. Il n’y a pas de trou dans la raquette, l’ensemble de l’expérience est prise en compte dans ce use case, ce qui permet d’anticiper de potentiels sujets ou d’identifier des opportunités

Top 5 des erreurs à ne pas commettre quand on écrit un use case :

1. Ne pas faire valider le use case par des utilisateurs une fois qu’il est rédigé
2. Parler des solutions ou des technologies dans un use case
3. Ne jamais faire évoluer un use case => Un use case est un document vivant
4. Mutualiser des use cases pour gagner du temps => Il faut lotir le plus possible les besoins en différents use cases pour faciliter leur lecture et leur traitement. Cela permet également plus d’agilité
5. Ne pas être factuel, ne pas faire d’effort de mise en forme (style, synthaxe…), ne pas se relire, ne pas utiliser un vocabulaire compréhensible des métiers/ utilisateurs => Si vous êtes la seule personne à pouvoir lire et comprendre ce document, je ne donne pas cher de votre projet ou produit