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 :

Exemple 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