Une direction qui décide de former une équipe à l'IA doit presque toujours répondre à une question avant la première session : sur quoi l'équipe va-t-elle s'exercer ? Le choix du premier cas d'usage pèse lourd. Un bon premier cas installe l'outil dans le quotidien ; un mauvais le range dans la catégorie des démonstrations qu'on a vues une fois.
Un cas d'usage qui ne soulage personne au quotidien n'est pas repris spontanément.
Le piège du cas vitrine
Le réflexe le plus répandu consiste à choisir le cas le plus ambitieux, celui qui se présente bien en comité : un tableau de bord automatisé, un assistant qui répond aux clients, une analyse prédictive. Ces cas ont un point commun. Ils répondent à une question de direction, pas à une gêne ressentie par ceux qui feront le travail.
Un cas d'usage qui ne soulage personne au quotidien n'est pas repris spontanément. Il demande un effort supplémentaire, dans un agenda déjà plein, pour un bénéfice que l'équipe ne perçoit pas encore.
Partir des tâches que l'équipe repousse
La source la plus fiable de premiers cas d'usage est l'équipe elle-même, interrogée sur ce qui lui pèse, pas sur ce qu'elle imagine que l'IA sait faire. Trois questions suffisent, posées individuellement plutôt qu'en réunion :
- Quelle tâche repoussez-vous chaque semaine ?
- Quelle tâche refaites-vous presque à l'identique d'une fois sur l'autre ?
- Quelle tâche vous oblige à rassembler des informations dispersées avant de pouvoir commencer ?
Les réponses sont rarement spectaculaires : un compte rendu de réunion, une synthèse hebdomadaire, une préparation de tournée, un tableau de relances, la reformulation d'un même type de courriel. C'est précisément ce qui en fait de bons candidats. Ce sont des tâches connues de tous, fréquentes, et jamais traitées parce qu'aucune n'était assez importante pour justifier un projet.
Trier les candidats sur quatre critères
Une fois la liste constituée, chaque tâche se passe au crible de quatre questions simples.
La fréquence : la tâche revient-elle au moins chaque semaine ? Un gain sur une tâche annuelle ne crée pas d'habitude.
Le périmètre : tient-elle dans le travail d'une seule personne, sans dépendre d'un circuit de validation ? Une tâche qui traverse trois services est un projet, pas un premier cas.
Les données : les informations nécessaires peuvent-elles être confiées à l'outil que l'entreprise autorise ? Si la réponse n'est pas claire, la question du cadre passe avant celle de l'usage.
La vérification : le résultat peut-il être contrôlé rapidement par la personne qui l'utilise ? Un premier cas doit produire un résultat que son utilisateur sait juger.
Les tâches qui passent les quatre critères forment la liste de départ. En pratique, deux ou trois par personne suffisent largement pour une première formation.
Ce qui reste hors de la première vague
Certaines idées reviennent souvent et gagnent à attendre : les usages qui touchent directement un client sans relecture, ceux qui reposent sur des données dont le traitement n'est pas encore cadré, et ceux qui supposent de modifier un processus partagé. Ils ne sont pas mauvais. Ils demandent une maturité que l'équipe n'a pas encore, et un échec sur l'un d'eux coûterait la confiance nécessaire pour la suite.
Faire du premier cas un point d'appui
Un premier cas bien choisi ne sert pas seulement à gagner du temps sur une tâche. Il sert à montrer à l'équipe, sur son propre travail, ce que l'outil fait bien et ce qu'il fait mal. C'est cette expérience concrète qui rend possibles les cas plus ambitieux, parce que l'équipe sait alors formuler une demande, vérifier un résultat et repérer une erreur.
Il est utile de noter, pour chaque premier cas retenu, comment la tâche était faite avant. Sans ce point de départ, il devient impossible de dire au bout de quelques semaines si l'usage a tenu.
En résumé
Les premiers cas d'usage IA d'une équipe se trouvent dans ses tâches récurrentes et pénibles, pas dans la liste des démonstrations les plus impressionnantes. Interroger chacun sur ce qu'il repousse, trier sur la fréquence, le périmètre, les données et la vérification, puis garder les cas ambitieux pour une seconde vague : c'est l'ordre qui installe un usage au lieu de le présenter.