Une spécification de parcours IA tient rarement en une phrase du type « on ajoute de l'IA sur l'écran de saisie ». Ce n'est pas une fonctionnalité qu'on pose sur un écran, c'est une redistribution du travail entre la machine et la personne. Tant que cette redistribution n'est pas écrite étape par étape, l'équipe de développement invente, et chacun invente différemment.
Voici la méthode que j'utilise pour poser ça noir sur blanc avant qu'une ligne de code soit écrite.
1. Cartographier le parcours tel qu'il est aujourd'hui
Pas le parcours cible. Le parcours réel, avec ses détours.
Je fais décrire une occurrence complète par la personne qui la vit : d'où arrive la demande, quels écrans elle ouvre, ce qu'elle recopie d'un onglet à l'autre, où elle attend, à qui elle demande confirmation. Je note les durées approximatives et les moments où la personne hésite.
Ce travail donne une frise. Chaque case est un geste, avec trois informations : qui le fait, combien de temps ça prend, ce qui bloque. Sans cette frise, la discussion sur l'IA reste abstraite.
2. Repérer les frictions, et les trier
Toutes les frictions ne se ressemblent pas. Je les range en trois familles, parce qu'elles n'appellent pas les mêmes réponses.
- La friction de saisie : la personne recopie ou reformule une information qui existe déjà ailleurs. C'est le terrain le plus favorable.
- La friction de décision : la personne doit choisir parmi trop d'options, ou chercher l'information qui lui permettrait de choisir. L'IA peut réduire le champ, rarement décider à sa place.
- La friction d'attente : la personne attend une validation, un retour, un document. Une bonne partie de ces frictions se règle par du workflow, pas par un modèle.
Sur beaucoup de parcours, la moitié des frictions relèvent de la troisième famille. Le dire tôt évite de vendre de l'IA là où il fallait juste une notification.
3. Choisir le mode d'intervention, case par case
C'est le cœur de la spécification. Pour chaque friction retenue, on tranche entre trois modes.
Suggestion. Le système propose, l'utilisateur voit la proposition à côté de son travail et l'accepte s'il veut. Coût d'erreur faible, adoption progressive, mais gain limité si la personne doit quand même tout relire.
Pré-remplissage. Le système remplit, l'utilisateur corrige. Le gain est réel, à une condition : la correction doit coûter moins cher que la saisie initiale. Si l'utilisateur doit vérifier chaque champ, on lui a ajouté du travail au lieu de lui en retirer.
Exécution. Le système fait et notifie. À réserver aux cas où l'erreur est peu coûteuse et rattrapable, ou bien où un contrôle en aval existe déjà.
Un même parcours mélange souvent les trois. Le tableau de spécification que je livre a une ligne par étape et une colonne « mode », avec une justification en une phrase. C'est cette justification qui évite les débats sans fin six semaines plus tard.
4. Écrire le refus et la correction avant le cas nominal
C'est la règle que je défends le plus fermement, et celle qu'on saute le plus souvent.
Pour chaque intervention de l'IA, la spécification doit répondre à quatre questions :
- Comment l'utilisateur refuse la proposition, en un geste, sans justification à donner ?
- Comment il corrige une valeur partiellement juste, sans repartir de zéro ?
- Que se passe-t-il quand le modèle ne répond pas ou répond hors format ? Le parcours doit rester praticable sans lui.
- La correction est-elle conservée quelque part, et pour quoi faire ?
Écris le comportement de repli avant le comportement nominal. C'est celui-là qui décide si les gens garderont l'outil.
Sur ce dernier point : garder la trace des corrections n'est intéressant que si quelqu'un les regarde. Prévoir la collecte sans prévoir la revue, c'est se donner bonne conscience. Décide qui lit ces corrections, à quelle fréquence, et ce qu'il en fait.
5. Ce que ça donne sur un moteur de recommandations
Chez Ippon, j'ai travaillé sur une solution de données pour e-commerçants au sein de La Poste Groupe : centralisation multi-canaux, KPI, moteur de recommandations personnalisées. La partie recommandation illustre bien cette discipline.
La question n'était pas « quel algorithme ». C'était : à quel moment du parcours du marchand la recommandation apparaît, qu'est-ce qu'elle interrompt, et quelle action elle permet immédiatement. Une recommandation affichée au mauvais endroit du parcours est ignorée même quand elle est pertinente. Une recommandation pertinente sans action possible à côté est une frustration.
La spécification a passé plus de temps sur le placement, la formulation et la sortie de secours que sur le calcul. C'est presque toujours dans cet ordre-là que se joue l'adoption.
Le format que je recommande
Un tableau, pas un document de vingt pages. Une ligne par étape du parcours, et ces colonnes : geste actuel, friction, mode d'intervention retenu, source de la donnée, geste de refus, geste de correction, comportement si le modèle échoue.
Si une case reste vide, la fonctionnalité n'est pas prête à partir en développement. Ce n'est pas de la bureaucratie : chaque case vide devient une décision prise en urgence par un développeur, un vendredi, sans contexte.
À faire sur ton prochain parcours
Prends la fonctionnalité IA que tu es en train de spécifier et réponds à une seule question : combien de secondes coûte le refus à l'utilisateur ? Si tu ne sais pas, ou si la réponse dépasse celui de la saisie manuelle, tu tiens déjà le point à retravailler en premier.