#Agentic101 – Comment identifier des cas d’usage IA agentique ?

David Guede a construit l’agent Sharlie : un agent vocal qui fait office de service client pour Sosh. Pour la rentrée, il vous partage son expertise pour une session de rattrapage sur les bases de l’agentification.

En auditant son catalogue, Inès fait deux découvertes.

• Deux agents quasi identiques. L’un, créé par la finance, analyse des contrats fournisseurs ; l’autre, créé par les achats, analyse des contrats fournisseurs. Deux équipes, deux prompts, deux maintenances : aucune des deux ne connaissait l’existence de l’autre.
• Un agent de préparation du reporting hebdomadaire, bricolé il y a huit mois par un contrôleur de gestion. Le contrôleur a changé de poste. L’agent, lui, tourne toujours et toute une équipe en dépend chaque lundi matin, sans propriétaire, sans jeu d’évaluation, sans que personne ne sache exactement ce qu’il fait ni sur quelles données.

Un doublon et une dépendance. Inès pourrait n’y voir que du désordre à nettoyer. Ce serait passer à côté de l’essentiel : ce sont les deux signaux les plus précieux de tout son portefeuille. Ils lui indiquent, mieux qu’aucun comité, ce que la fabrique doit produire. L’amont de la chaîne est le tronçon stratégique où se décide la feuille de route de construction.

Stratégie de recueil et de détection automatique des besoins IA

D’où viennent les bons candidats à l’agentification ? La réponse est double, et les deux canaux n’ont ni la même mécanique ni la même temporalité.

Le premier canal est le recueil (actif, ponctuel, organisé). Des ateliers avec les métiers, une cartographie des besoins construite à partir des données réelles (les logs, les motifs de contact, les verbatims) et jamais de l’intuition seule. C’est un exercice de projet classique, et c’est lui qui lance la fabrique : sans recueil initial, pas de premiers candidats, pas de priorisation, pas de portefeuille.

Le second canal est la détection (passive, continue, automatique). Une fois les premiers agents en production, le système se met à émettre des signaux, et une fabrique bien conçue les écoute. Les demandes hors périmètre, d’abord : tout ce que les utilisateurs demandent et que le dispositif avoue ne pas savoir faire est une demande réelle, non couverte, horodatée. Additionnez ces signaux et vous obtenez ce qu’aucun comité ne saurait produire (un backlog trié par la demande réelle). Viennent ensuite les doublons, puis les dépendances.

Le recueil écoute les collaborateurs, la détection écoute la machine. Le premier lance la fabrique, la seconde la nourrit. Une organisation qui ne fait que du recueil vit sur des ateliers qui datent ; une organisation qui attendrait tout de la détection ne démarrerait jamais.

Gouvernance de l’IA : limites de la création libre et gestion des risques

Les deux découvertes d’Inès répondent à une question que toutes les organisations se posent et qu’aucune ne sait trancher : quand faut-il sortir de l’enablement, cette phase saine où chacun peut créer ses agents librement ?

Précisons d’abord ce que « sortir » veut dire. On ne ferme jamais l’enablement : il reste en permanence l’espace d’exploration, le vivier d’où l’on promeut. Ce qui se termine, c’est son monopole. C’est le moment où la création libre cesse d’être le seul régime, et où une porte de mise en production gouvernée devient obligatoire pour les projets critiques. Le critère de bascule repose sur deux signaux clairs.

Le doublon est le signal de valeur. Deux équipes qui construisent, sans se connaître, le même agent : ce n’est pas un gaspillage anecdotique, c’est la preuve que le besoin n’est plus un usage local mais un processus d’entreprise. L’exploration a fait son travail en découvrant la demande. La création individuelle ne peut structurellement pas la servir : elle ne sait que la dupliquer. Attendre le doublon n’est pas un échec, c’est un coût d’exploration. Deux équipes qui bâtissent indépendamment la même chose constituent une étude de besoin que personne n’a eu à commander. Le gâchis serait de la laisser se répéter une troisième fois.

La dépendance est le signal de risque. Le jour où l’agent de quelqu’un devient l’outil d’une équipe (comme l’agent du contrôleur de gestion parti depuis huit mois), l’absence de gouvernance change de nature : elle passe du désordre toléré au risque opérationnel. Un agent sans propriétaire, sans évaluation, sans trace, dont dépend un livrable récurrent, c’est du shadow AI devenu porteur.

On sort de l’enablement le jour où la création individuelle produit des dépendances collectives. L’un ou l’autre signal suffit. Notez leur vertu : ils sont observables (la supervision sait détecter les intentions récurrentes, donc les doublons) et précoces. Le ratio d’agents créés par rapport aux agents utilisés est un symptôme retardé : quand le catalogue est déjà mort, il est trop tard.

Cadrage fonctionnel de l’IA : définir les tests avant le développement

Un candidat détecté n’est pas encore un candidat cadré. Entre les deux, s’opère un travail que la fabrique standardise, et c’est ici que se joue une part déterminante de la qualité finale.

Chaque candidat retenu reçoit sa fiche : l’intention couverte, les scénarios, le propriétaire. Puis viennent deux exigences opérationnelles non négociables :

1. Le périmètre négatif : définir ce que l’agent ne fait pas est aussi structurant que définir ce qu’il fait. C’est ce périmètre qui le rend testable, et qui apprend au dispositif à avouer plutôt qu’à deviner.
2. Le critère d’acceptabilité : pour chaque scénario, ce qui distingue une bonne réponse d’une mauvaise doit être écrit noir sur blanc et validé par le métier.

Une intention sans critère d’acceptabilité, c’est une hallucination qui attend son tour.

Les cas de test s’écrivent ainsi avant la première ligne de code. La validation ne commence pas après la construction : elle commence ici, dans l’amont. Une fabrique sérieuse ne construit rien qu’elle ne sache déjà comment prouver.

Organisation hub-and-spoke : structurer le pilotage des projets IA

L’organisation de ce travail repose sur un équilibre précis : ni le centre seul, ni les métiers seuls. Ce tronçon illustre parfaitement ce principe.

Tout centraliser, c’est confier la détection de la valeur à des collaborateurs qui ne la voient pas : aucune équipe centrale ne sait qu’un contrôleur de gestion perd sa journée du 3 du mois, ni ce qu’est une bonne réponse à un client mécontent. Tout fédérer, c’est renoncer au portefeuille : chaque métier cadre dans son format, personne ne voit les doublons (par construction, puisqu’un doublon n’est visible que d’au-dessus), et la priorisation se fait au plus bruyant.

La réponse est le modèle hub-and-spoke : les standards au centre, l’écoute au plus près du terrain. Au centre, les Product Managers (PM) et Product Owners (PO) IA tiennent le format des fiches, la méthode de priorisation de la valeur sur la faisabilité, le portefeuille unique, ainsi que les instruments de détection. Dans les métiers, des référents identifiés font remonter les besoins, valident les critères d’acceptabilité et arbitrent ce qui compte. Le centre ne décide pas ce qui a de la valeur ; il rend la valeur comparable.