Je pensais venir créer des agents

Une organisation appelle pour un sujet technique et bute sur autre chose, presque toujours. Ce n'est pas un défaut de formulation de sa part : elle décrit ce qu'elle voit, et le blocage est ailleurs.

La demande arrive sous une forme précise : construire des agents, brancher un modèle sur un progiciel, améliorer les réponses d'un assistant existant. Elle est légitime et elle est le symptôme.

Sur les missions que j'ai menées, le temps se répartit rarement comme prévu. La part technique est réelle et minoritaire. L'essentiel va au corpus, à la désignation d'un propriétaire et à la définition du périmètre.

Un corpus dont personne ne sait dire quelle version fait autorité, aucun propriétaire métier nommé, et un périmètre jamais écrit. Ces trois-là couvrent la quasi-totalité des cas.

Le corpus vient en premier. Trois versions d'une procédure, aucune date lisible, et la personne qui savait est partie. Aucun modèle ne tranche à la place d'une organisation, et le sujet est développé dans le corpus est le projet.

Le propriétaire ensuite. L'équipe technique construit, présente, et découvre au déploiement qu'un responsable métier refuse de répondre des actions du système. Le refus est légitime : il n'a pas participé à la définition du périmètre.

Le périmètre enfin. Personne n'a écrit ce que le système ne fera pas, ni ce qu'il répond quand il ne sait pas. C'est le point qui arrête le plus de projets d'agents, comme détaillé dans agents en entreprise : où s'arrêtent les projets.

Annoncer que le sujet n'est pas celui de la commande demande de la forme, et la meilleure est de le faire constater plutôt que de l'affirmer. C'est ce que permet le diagnostic sur cinq cas réels.

La méthode qui fonctionne consiste à faire l'exercice avec l'équipe, pas devant elle. On prend cinq mauvaises réponses signalées, on ouvre les journaux, et on regarde ensemble si l'information nécessaire y était.

Dans la quasi-totalité des cas, elle n'y était pas. La conclusion s'impose d'elle-même, et elle vient de l'équipe.

Ce déplacement change tout dans la relation. Une équipe à qui l'on annonce qu'elle s'est trompée de sujet se défend ; une équipe qui le constate sur ses propres données passe à la suite en une heure.

Une mission vendue sur un livrable technique et passée sur le corpus se termine mal, même quand le résultat est bon. Il faut le dire avant de contracter.

Le risque est réel : le commanditaire a acheté des agents, il reçoit un corpus mis en ordre et un périmètre écrit, et il a le sentiment de ne pas avoir eu ce qu'il a payé, alors même que le système fonctionne mieux.

La formulation que j'utilise désormais annonce la séquence : un temps de diagnostic court, dont le résultat peut déplacer le sujet, puis la construction. Le commanditaire accepte ou non, et il sait à quoi s'attendre.

Cette franchise coûte quelques missions et évite les fins de mission difficiles. Elle rejoint ce que j'écris sur ce qu'un tarif élevé achète réellement dans ce qu'un TJM élevé achète réellement.

Le travail sur le corpus profite à tout le monde, indépendamment du système construit. C'est l'argument qui fait accepter le déplacement de sujet.

Désigner les versions qui font autorité, retirer les documents périmés, porter les dates dans les métadonnées : ces gestes améliorent le travail de tous ceux qui cherchent une information, avec ou sans assistant.

De même, écrire le périmètre d'un système oblige à formuler qui décide quoi, ce qui révèle régulièrement des zones grises antérieures au projet.

Une mission qui déplace le sujet ne livre donc pas moins que prévu : elle livre autre chose, souvent plus durable, et c'est ce qu'il faut savoir expliquer au moment du bilan.