Du processus au cas d'usage

On automatise mieux ce qu’on a compris

Un processus que personne n’a décrit ne peut pas être confié à un outil. On commence donc par le dessiner, sur papier ou sur un tableau, avec les gens qui le vivent.

Ce travail prend une demi-heure. Il révèle presque toujours des étapes que le dirigeant ne voyait pas : une ressaisie faite par habitude, une validation informelle, une information qui ne vit que dans la tête d’une personne.

Ce module vous amène de ce dessin à une fiche d’une page : votre cas d’usage, prêt à être prototypé.

La cartographie en cinq éléments

Pour décrire un processus, cinq éléments suffisent.

• Le déclencheur : qu’est-ce qui lance le processus ? Un devis accepté, un mail client, un dossier de consultation reçu.
• Les entrées : mails, devis, plans, mesures, références, consignes.
• Les étapes : qui fait quoi, dans quel ordre ?
• Les décisions : où faut-il interpréter, arbitrer ou demander une information ?
• Les sorties : quels documents ou quelles décisions sont produits ?

Exemple pour la Menuiserie des Landes, entreprise fictive. Déclencheur : un client accepte un devis. Entrées : le devis, parfois un plan ou un mail. Étapes : l’assistante transmet le devis au chef de production, qui lit les lignes, repère les essences et les sections, puis remplit une fiche à la main. Décisions : que faire d’une ligne ambiguë ? Sortie : la fiche de production qui lance le débit.

Dessinez de gauche à droite et indiquez le nom de la personne à chaque étape.

Repérer les irritants

Une fois le processus dessiné, cherchez où l’on perd du temps ou de la fiabilité. Six familles d’irritants reviennent partout :

• la ressaisie : on retape ce qui existe déjà ailleurs ;
• l’attente : un dossier dort en attendant une information ou une validation ;
• l’erreur : une dimension, une essence, une quantité mal reportée ;
• la recherche : on cherche un document ou une règle ;
• l’oubli : une étape sautée quand la charge monte ;
• la dépendance à une personne : un seul salarié sait faire.

Retenez vos trois irritants principaux. Ce sont eux qui départagent les cas d’usage : un cas qui s’attaque à un irritant vécu chaque semaine a plus de chances d’être adopté.

Gardez en tête la porte de sobriété du module 3. Certains irritants se règlent sans IA, par un paramétrage ou une simplification. Notez-les, c’est un gain immédiat.

La grille E-T-S-C

Un cas d’usage bien formulé tient en quatre cases.

Case	Question	Exemple, cas devis vers fiche
Entrée	Quelles données ou quels documents sont disponibles ?	Le devis ou la commande, et d’éventuelles pièces complémentaires
Transformation	Que faut-il comprendre, extraire, comparer ou générer ?	Identifier les lignes à produire et leurs caractéristiques utiles
Sortie	Quel résultat concret est produit ?	Une fiche de production standardisée
Contrôle	Qu’est-ce qu’un humain doit impérativement vérifier ?	Incohérences, dimensions, essences, quantités, délais, informations manquantes

Complétez avec trois lignes : l’utilisateur de la sortie (le chef de production, ou la personne qui prépare le lancement), le test prévu (comparer le résultat à la fiche attendue, sur plusieurs devis) et l’exigence (un prototype assez robuste pour fonctionner sur un devis qu’il n’a jamais vu).

La case Contrôle est celle que l’on oublie. Remplissez-la avec soin : c’est elle qui fait la différence entre un outil utile et un outil dangereux.

Choisir un cas qui vaut le coup

Tous les cas ne se valent pas. Un cas d’usage est intéressant si :

• la tâche revient suffisamment souvent ;
• les entrées et la sortie attendue sont identifiables ;
• une part importante du travail porte sur de l’information ou des documents ;
• le résultat peut être contrôlé à coût raisonnable ;
• le gain attendu justifie la mise en place et la maintenance ;
• le risque reste maîtrisable.

On résume en quatre critères à multiplier : valeur × fréquence × faisabilité × contrôlabilité. Notez chacun de 1 à 3. Un 1 sur un seul critère tire tout le produit vers le bas : une tâche rare, ou impossible à contrôler, ne mérite pas un prototype.

Attention au mot valeur : il désigne le gain que vous attendez. Tant que vous ne l’avez pas mesuré dans votre entreprise, c’est une hypothèse, notée comme telle.

Exercice

Durée : 35 minutes. Livrable : une fiche E-T-S-C d’une page. C’est la preuve de la compétence « formuler un cas d’usage ».

1. Sur une feuille, dessinez le processus de votre cas fil rouge de bout en bout : déclencheur, entrées, étapes, décisions, sorties. Indiquez qui fait quoi.
2. Entourez les moments où vous perdez du temps ou de la fiabilité et classez-les par famille d’irritants. Retenez les trois principaux.
3. Remplissez les quatre cases E, T, S et C en une à trois phrases chacune. Soyez concret : nommez les documents, les champs, les points à contrôler.
4. Ajoutez trois lignes : l’utilisateur de la sortie, le test prévu (comment comparerez-vous le résultat à la bonne réponse, sur plusieurs documents ?) et l’exigence (par exemple : fonctionner sur un document jamais vu).
5. Notez votre cas sur quatre critères (valeur, fréquence, faisabilité, contrôlabilité), de 1 à 3 chacun. Si un critère est à 1, ou si le total est faible, envisagez un autre cas parmi ceux du module 0.
6. Reportez la conclusion de votre grille du module 3 : alternative sans IA envisagée, et raison de la retenir ou de l’écarter.

Vous pouvez remplir la fiche directement ici :

7. Conservez cette fiche : elle sera la première page de votre projet final.

Passez ensuite au quiz, seuil de réussite 60 %.