Projet pilote IA : comment définir l'objectif, l'échantillon et la décision finale

Un projet pilote sert à répondre à une question, pas à démontrer que l'intelligence artificielle fonctionne. La différence se voit à la fin : si les critères ont été écrits à l'avance, le résultat est une décision ; s'ils sont écrits après, c'est une interprétation, et c'est celui qui parle le mieux en réunion qui l'emporte.

Ce guide traite de la façon dont s'organise le test : ce qu'on y met, ce qu'on mesure, qui le surveille et comment on décide à la fin.

D'abord : la question à laquelle le pilote répond

« Voyons si l'IA peut nous aider » n'est pas une question, car il n'existe pas de réponse qui la clôture. Une question utile a une activité, un sujet et une condition vérifiable.

• Si un système prépare les premières réponses aux demandes d'assistance, le service arrive-t-il à clôturer les dossiers du jour dans la journée ?
• Si les documents des fournisseurs sont lus automatiquement, combien finissent quand même entre les mains d'une personne ?
• Si les devis répétitifs sont remplis avec assistance, le temps de préparation diminue-t-il sans que les erreurs sur les montants n'augmentent ?

Chacune de ces questions peut recevoir une réponse négative, et c'est là le point important. Un pilote qui ne peut pas avoir d'issue négative n'est pas un test : c'est une présentation.

Le périmètre : ce qui entre et ce qui reste dehors

C'est la partie qu'on a tendance à laisser large, et c'est l'erreur qui rend les résultats illisibles. Plus le périmètre est étendu, moins on comprend à quoi attribuer ce qui se passe.

• L'activité : une seule et délimitée. Pas « le service client », mais « les demandes sur l'état de la commande arrivant par courrier ».
• Les utilisateurs : un groupe restreint et désigné nommément, disposé à signaler les problèmes plutôt qu'à les contourner en silence.
• Les données : quelles sources, avec quelles permissions, et ce qui ne doit pas être utilisé.
• Les exclusions explicites : les cas que le système ne doit pas traiter et qui doivent être transférés immédiatement à une personne, par exemple les réclamations, les questions contractuelles, les clients en contentieux.

La période doit être choisie de manière à contenir un nombre de cas suffisant pour être significatif, et au moins un cycle typique de l'entreprise : si la clôture mensuelle change la façon de travailler, le pilote doit la traverser.

La situation initiale s'enregistre avant

Sans point de départ, il n'y a pas de comparaison possible, et le reconstruire à la fin conduit toujours à des chiffres de complaisance. Avant d'activer quoi que ce soit, mesurez comment on travaille aujourd'hui : combien de temps demande l'activité, combien de cas sont traités, combien d'erreurs ou de reprises se produisent, combien de temps on attend.

Si une mesure n'existe pas, elle doit être construite à la main pendant quelques semaines : deux personnes qui notent temps et cas sur une feuille donnent une référence plus utile qu'une estimation faite de mémoire. C'est un vrai travail et il doit être inscrit dans le plan, pas ajouté par surprise.

La fiche du pilote

Elle tient sur une page. L'exemple est illustratif et concerne la lecture automatique des documents entrants.

Les deux lignes les moins bien renseignées sont presque toujours « hors périmètre » et « critères d'acceptation » : la première parce qu'elle paraît restrictive, la seconde parce qu'elle oblige à dire à l'avance ce que l'on considère comme un succès. Ce sont justement les deux qui rendent le test décidable.

Supervision et anomalies pendant le test

Pendant le pilote, quelqu'un doit observer, pas seulement utiliser. Il faut un moment fixe — hebdomadaire convient — où l'on relit les cas qui se sont mal passés et où l'on décide s'ils sont corrigibles ou s'ils révèlent quelque chose de plus profond.

• Chaque résultat reste vérifié par une personne : le pilote n'est pas le moment pour retirer le contrôle.
• Les anomalies se rassemblent dans une liste unique, avec le cas concret joint : sans l'exemple réel, on ne corrige rien.
• Il faut définir à l'avance ce qui fait arrêter le test : une erreur parvenue à un client, une donnée sortie d'où elle n'aurait pas dû, une charge de corrections supérieure au travail économisé.
• Les modifications faites pendant le test doivent être notées avec leur date, sinon à la fin on ne saura pas à quelle version se rapportent les résultats.

Décider : étendre, corriger, interrompre

La réunion finale doit être fixée dès le départ, avec les personnes qui décident déjà engagées. Il y a trois issues possibles, et aucune des trois n'est un échec.

1. Étendre : les critères sont satisfaits. On passe à définir qui maintient le système, qui répond quand il se trompe et ce qui se passe si une source de données change.
2. Corriger et répéter : le résultat est proche mais un cas spécifique ne tient pas. On répète une seule fois, avec le même périmètre et une modification déclarée.
3. Interrompre : le bénéfice n'est pas là, ou cela coûte plus cher que le traitement manuel. On écrit pourquoi, afin que dans un an personne ne propose à nouveau le même test sans savoir comment il s'était déroulé.

Dans le calcul, il faut mettre tout le coût, pas seulement la construction : la maintenance, les vérifications des personnes, le temps de celui qui corrige. Un système qui fait gagner une demi-heure et en demande vingt minutes de contrôle a une marge étroite, et il faut le dire avant que quelqu'un ne le découvre seul.

Ce que ce guide ne couvre pas

Il est ici question de l'organisation du test. Le choix de quelle activité porter au pilote — comment les candidats se comparent entre eux et selon quels critères on les classe — est une étape antérieure et fait l'objet de son propre guide. La vérification d'un assistant conversationnel avant de le rendre disponible aux clients suit elle aussi une méthode dédiée.