Le diable est dans le libellé : le BA et l'art des détails

« Le diable se trouve dans les détails. » L'expression est ancienne, mais en tant que business analyst, je la vérifie presque chaque semaine. Un libellé de trois mots suffit parfois à bloquer un utilisateur qui sait pourtant très bien ce qu'il veut faire.
Récemment, deux expériences m'ont rappelé une chose simple : le texte d'une interface n'est pas de la décoration. Il fait partie de la fonctionnalité. Et c'est au BA de le spécifier.

Cas n° 1 : l'app bancaire et le « mot de passe »

Je me connecte à mon application bancaire avec mon mot de passe. Une fois dans l'app, je lance le changement de mot de passe. L'écran m'affiche un champ : « Saisissez le mot de passe ».
Je viens de m'authentifier et j'ai demandé à changer de mot de passe. Logiquement, je saisis donc le nouveau. Erreur : le système attendait d'abord l'ancien. Impossible d'aller plus loin, et rien à l'écran ne m'expliquait pourquoi.
Il aurait suffi d'un mot de plus : « Saisissez votre mot de passe actuel ».

Cas n° 2 : le code PIN Mobile Money en USSD

Autre système, même piège. Sur mon compte MoMo, via USSD, je saisis mon code PIN pour accéder au menu. Je choisis ensuite de réinitialiser mon code. Le message suivant s'affiche : « Saisissez le code PIN ».
Cette fois, j'ai saisi l'ancien. Erreur. Le système attendait autre chose, sans jamais le dire.
En USSD, l'erreur coûte plus cher que sur une app. Il n'y a pas de bouton retour, pas d'aide contextuelle, et souvent il faut relancer toute la session depuis le début.
Ce que ces deux cas ont en commun
Dans le premier cas, j'ai saisi le nouveau alors qu'on attendait l'ancien. Dans le second, j'ai saisi l'ancien et ce n'était pas ce qu'on attendait. Deux erreurs dans des sens opposés, une seule cause : le libellé ne disait pas lequel.
• Le libellé est ambigu. « Le mot de passe » ou « le code PIN » peut désigner l'ancien, le nouveau ou la confirmation.
• Le contexte induit en erreur. Je venais de saisir mon secret pour me connecter. Dans ma tête, cette étape était déjà faite.
• Le message d'erreur ne guide pas. Il dit que ça ne va pas, sans dire quoi corriger.
Le plus frappant : techniquement, tout fonctionne. Les règles sont respectées, les tests passent. C'est l'utilisateur qui échoue, et lui ne lira jamais la spec.

Le rôle du BA : spécifier les mots, pas seulement les règles
Une spec dit souvent : « L'utilisateur saisit son mot de passe actuel, puis le nouveau. » La règle est juste. Mais si la spec ne fixe pas le texte affiché, le développeur choisira, et il choisira souvent le plus court : « Mot de passe ».

Le BA doit donc écrire dans la spec les libellés exacts, les messages d'erreur et les messages de confirmation. Voici la différence sur mes deux exemples :
• Champs de l'app : « Mot de passe actuel », « Nouveau mot de passe », « Confirmez le nouveau mot de passe », au lieu de trois fois « Mot de passe ».
• Erreur dans l'app : « Votre mot de passe actuel est incorrect. Vérifiez-le et réessayez. » au lieu d'un simple « Erreur ».
• Écran USSD : « Saisissez votre NOUVEAU code PIN (4 chiffres) » au lieu de « Saisissez le code PIN ».
• Erreur USSD : « Code incorrect. Entrez le NOUVEAU code, pas l'ancien. » au lieu d'un simple « Erreur ».
Le critère d'acceptation doit aussi porter sur le texte, pas seulement sur le comportement :
Étant donné que je suis connecté et que j'ouvre le changement de mot de passe, quand je saisis un mot de passe actuel incorrect, alors le message « Votre mot de passe actuel est incorrect. Vérifiez-le et réessayez. » s'affiche sous le champ.
À l'ère de l'IA, la vigilance compte double
Aujourd'hui, une IA rédige une spec complète en quelques secondes. Les règles sont cohérentes, la structure est propre, les user stories sont bien formées. Mais les libellés sont souvent génériques, et l'IA ne connaît pas vos utilisateurs, leur canal (app ou USSD) ni leurs habitudes.
Le piège, c'est qu'une spec générée a l'air terminée. On la relit donc moins. C'est exactement là que « Saisissez le code PIN » passe sans que personne ne le remarque.
L'IA fait gagner du temps sur la rédaction. Elle ne remplace pas le travail du BA : se mettre à la place de l'utilisateur, écran par écran, et se demander : « Si je ne connaissais pas ce système, que saisirais-je ici ? »
Checklist du BA : les détails à ne pas laisser au hasard
1. Chaque champ dit exactement quelle donnée il attend : ancien, nouveau ou confirmation.
2. Le libellé tient compte de ce que l'utilisateur vient de faire juste avant.
3. Chaque message d'erreur dit ce qui ne va pas et comment corriger.
4. Les messages sont écrits en entier dans la spec, jamais « afficher un message d'erreur ».
5. Le format attendu est indiqué : nombre de chiffres, caractères autorisés.
6. Les contraintes du canal sont prises en compte. En USSD : texte court, pas de retour arrière, session limitée.
7. Les libellés sont testés avec quelqu'un qui ne connaît pas le projet.
8. Toute spec générée par IA est relue écran par écran, du point de vue de l'utilisateur.
Conclusion
L'utilisateur ne lit pas la spec, il lit l'écran. Ce qu'on n'a pas écrit dans la spec, il le découvre en se trompant.
Un mot comme « actuel » ou « nouveau » ne coûte rien à spécifier. Son absence peut coûter un abandon, un appel au service client, ou un client qui perd confiance. Le diable se trouve dans les détails, et c'est au BA d'aller l'y chercher.
Et vous, quel libellé vous a déjà bloqué dans une app ou un menu USSD ?