Demandez dans une entreprise comment se déroule exactement un processus, et vous obtiendrez quatre réponses. Pas parce que personne ne sait, mais parce que ce n’est décrit nulle part. C’est dans la tête de trois collègues, dans une boîte mail partagée et dans un fichier Excel que plus personne n’ose toucher.
Une journey map règle ce problème. Mais avec l’arrivée des agents IA, certaines choses doivent changer.
D’abord : qu’est-ce qu’une journey map ?
C’est un processus, dessiné dans un seul schéma, du début à la fin. Vous placez l’objectif en haut, avec les mots de l’utilisateur : un recruteur veut ajouter un nouveau candidat dans son système. En dessous vient une description de chaque étape en langage courant. Puis l’endroit où se passe chaque étape : quel écran, quel logiciel, quelle boîte mail. Et tout en bas, les points de friction vécus aujourd’hui.
La différence avec un organigramme de processus classique, c’est la perspective. Un organigramme suit le système. Une journey map part de la personne qui effectue l’action. Vous voyez ainsi des choses qui restent invisibles dans un organigramme : qu’un processus commence en fait dans une boîte mail, ou que les mêmes données sont saisies à trois endroits.
Nous avons écrit un article à part sur la démarche du journey mapping elle-même.
Pourquoi les agents IA changent la donne
Les agents IA commencent à utiliser des logiciels, comme les humains : lire un CV, recopier des données, préparer un dossier. Et de plus en plus souvent, ce n’est même pas un agent que vous construisez, mais l’assistant que votre collègue ou votre client utilise déjà.
Ce qui surprend, c’est que votre parcours ne change pas forcément pour autant. Un candidat doit toujours être créé, vérifié et rattaché à une offre d’emploi. Cela découle de l’objectif que l’utilisateur cherche à atteindre, que cet utilisateur soit un humain ou non.
Ce qui change, en revanche, c’est la ligne du dessous. Aujourd’hui, un logiciel est construit à partir d’écrans conçus pour des humains. Pour les agents IA, les écrans sont superflus. Ils utilisent des capabilities pour effectuer des actions.
Ce que vous ajoutez concrètement à votre map
À côté de chaque écran, une capability
Parcourez votre map et complétez la ligne du bas. Pour chaque étape, on y trouve deux types d’éléments :
- un écran, pour les humains — le formulaire candidat
- une capability, pour les agents — créer un candidat : la même action, mais appelable directement, sans écran autour
Certaines étapes n’ont besoin que de l’un des deux. La plupart ont besoin des deux. À l’étape « vérifier si nous connaissons déjà cette personne » correspond un écran qui affiche « nous pensons qu’il s’agit de Sarah Martin, qui a postulé en mars », et une capability qui effectue ce même contrôle pour un agent qui ne verra jamais l’écran.
Définir des capabilities est relativement facile, puisque vous n’avez pas d’écrans à concevoir. Et souvent, une capability par tâche suffit pour que l’agent IA se mette au travail.
Écrivez ce qui se passe quand l’agent n’est pas sûr
Un humain qui hésite demande vite à un collègue. Un agent ne montre pas toujours qu’il hésite, sauf si vous le lui dites explicitement.
Notez donc, pour chaque étape qu’un agent peut effectuer, ce qui doit se passer quand ce n’est pas clair. S’arrêter et prévenir quelqu’un est presque toujours la réponse. Pour un humain, inutile de l’écrire ; pour un agent, si.
Rendez tout explicite
C’est l’un des points les plus importants à prendre en compte. Un collègue voit à un champ à moitié rempli qu’il y a un souci. Un agent IA ne voit que ce qui est réellement là.
Il en va de même pour savoir qui a fait quoi. « L’agent a corrigé ceci au nom de Sarah » est un autre fait que « Sarah a corrigé ceci ». Si vous n’enregistrez pas cette distinction sur le moment, vous aurez du mal à la retrouver après coup.
Quel rapport avec votre logiciel
Cet exercice peut avoir un grand impact sur vos systèmes existants. Une capability ne peut exister que si votre logiciel connaît vraiment cette action en tant qu’action, indépendamment de l’écran où elle se trouve être utilisée.
Dans un logiciel construit comme une pile d’écrans, c’est rarement le cas. Il faut alors maçonner après coup une couche à part, à travers laquelle l’agent IA peut interagir. Dans un logiciel construit à partir d’un modèle, toutes les actions possibles sont déjà listées explicitement : l’agent utilise la même action que l’humain, simplement sans écran autour.
Ce que vous pouvez en faire
Prenez la journey map que vous avez déjà et demandez-vous pour chaque étape : est-ce quelque chose que seul un humain peut faire ? Ou faut-il aussi une capability pour les agents IA ?
Curieux de voir à quoi ressemblerait un tel exercice pour vos processus ? Envoyez-nous un message.
