Pilote IA à 90 jours : faut-il poursuivre, revoir ou arrêter ?

01Tester une hypothèse métier, pas démontrer un outil

Une feuille de route utile indique ce que le pilote doit apprendre et ce que chaque résultat changera pour l’entreprise. Le cas d’usage est supposé déjà retenu. S’il faut encore le comparer à d’autres projets, il est trop tôt pour organiser son essai sur 90 jours.

Une liste de réunions, de paramétrages et d’essais ne suffit pas. Elle décrit l’activité du projet, sans dire quelle hypothèse a été éprouvée ni quel résultat modifiera la décision. La feuille de route relie donc chaque période à une incertitude, à une façon de la tester et à la personne habilitée à décider de la suite.

Une hypothèse utile évite les formulations générales telles que « l’IA fera gagner du temps ». Elle nomme l’activité concernée, le point de comparaison, les utilisateurs impliqués, le résultat recherché et les contraintes qui ne peuvent pas être sacrifiées. Le cadrage définit ainsi ce qui devra être vrai pour continuer, sans garantir le résultat avant l’essai.

L’ordre des essais compte autant que leur contenu. Le manuel de service britannique demande, pendant la phase alpha, d’identifier les hypothèses les plus risquées et de les tester en priorité, plutôt que de construire la solution complète.^[5] Une hypothèse capable d’arrêter le projet doit donc être éprouvée assez tôt pour éviter de mobiliser l’équipe sur un essai déjà compromis.

Cette matrice relie le travail du pilote à la décision qu’il prépare.

À chacune de ces séquences, la fiche rattache une hypothèse testée aux trois issues possibles : poursuivre si la condition est satisfaite, revoir le test si l’écart reste corrigeable, ou l’arrêter si une condition rédhibitoire est atteinte. La décision de passage indiquée dans le tableau n’efface aucune de ces trois issues ; elle précise seulement celle que le jalon prépare en priorité.

Trois notions doivent rester distinctes. Une condition préalable désigne ce qui doit être disponible pour réaliser le test. L’hypothèse exprime ce que le test cherche à apprendre. Le seuil indique à partir de quel résultat la décision change. Les réunir dans une seule appréciation rendrait la conclusion impossible à vérifier.

Le périmètre du pilote se délimite avec la même précision : utilisateurs concernés, opérations incluses, données autorisées, interfaces mobilisées et décisions qui resteront humaines. Toute extension significative devient une demande de changement à évaluer, et la conclusion reste rattachée à l’hypothèse initiale.

Les 90 jours sont une durée choisie pour ce pilote, pas une durée qui conviendrait à tous les projets. Si une condition déterminante ne peut pas être vérifiée dans ce délai, la fiche doit le signaler. Mieux vaut attendre, réduire le périmètre ou arrêter que valider le projet dans des conditions artificiellement favorables.

02Comparer les résultats à une situation de départ mesurée

La fiche de pilote est le document commun de la feuille de route. Le responsable métier, le responsable opérationnel, le référent technique, les personnes chargées du contrôle et le décideur final doivent pouvoir la lire de la même façon. Une version unique, datée et approuvée sert de repère lorsque les résultats arrivent.

La décision à préparer ouvre la fiche. L’hypothèse principale y côtoie les seules hypothèses secondaires indispensables et les issues possibles. Le même document borne ce que la fin du pilote n’autorisera pas : généralisation, déploiement étendu, nouveau cas d’usage ou intégration supplémentaire.

Pour interpréter les résultats, il faut pouvoir les comparer au travail tel qu’il est réalisé avant l’essai. Ce point de comparaison retient les mêmes opérations, entrées, sorties et règles de contrôle que l’évaluation finale. Changer de période, de population ou de définition rendrait la comparaison trompeuse.

La doctrine budgétaire britannique est plus exigeante que la pratique courante sur ce point. Le Green Book impose de conserver l’option « poursuite de l’existant » jusqu’à l’évaluation finale, précisément parce qu’elle sert de référence à laquelle toutes les autres options sont comparées.^[1] Un autre guide public britannique d’évaluation applique le même principe en distinguant le résultat observé de l’effet réellement imputable à une intervention.^[3] Pour un pilote IA, le point de départ doit donc mesurer la même tâche avant l’essai : délai de traitement, corrections nécessaires, incidents et reprises. Sans cette référence, l’équipe peut attribuer à l’IA une amélioration qui aurait eu lieu de toute façon.

Une dépendance ne peut pas rester sous la responsabilité vague du « projet ». Qu’il s’agisse d’une source de données, d’un accès, d’une validation, d’une compétence ou de la présence d’utilisateurs, la fiche nomme la personne qui doit la rendre disponible. Elle indique aussi l’échéance, l’état constaté, la preuve attendue et la conséquence d’un blocage.

Cette précision n’est pas un excès de formalisme. Lorsque la Cour des comptes néerlandaise a examiné neuf algorithmes employés par l’administration, six des neuf organisations concernées ne savaient pas quels agents disposaient d’un accès aux données.^[11] Une dépendance que personne ne sait attribuer avant l’essai ne sera pas mieux attribuée pendant.

La mesure a son propre cadre. Chaque indicateur doit pouvoir être retrouvé dans une source, attribué à un responsable et observé au moment prévu. Son seuil et le document conservé sont écrits avant le test ; « résultat satisfaisant » ne constitue pas une règle. Lorsqu’une valeur numérique n’aurait pas de sens, une condition qualitative observable peut convenir, par exemple une validation formelle ou l’absence d’un défaut défini comme rédhibitoire.

Les conditions d’usage complètent ce cadre : personnes autorisées, tâche permise, contrôle attendu, possibilité de reprise et procédure en cas d’écart. Sans elles, une démonstration conduite par quelques personnes très préparées pourrait être confondue avec un usage réellement praticable au quotidien. Lorsque des données personnelles entrent dans le test, la finalité doit en outre être définie dès la définition du projet.^[13] L’entreprise doit aussi déterminer sa qualification au sens du RGPD — responsable de traitement, responsable conjoint ou sous-traitant.^[13]

La fiche contient enfin un registre des changements. Toute modification de périmètre, de donnée, de modèle, de procédure ou de population testée y est consignée avec son motif et son effet sur la comparabilité. Certaines modifications sont légitimes : un pilote sert précisément à apprendre. Il faut toutefois distinguer les résultats obtenus avant le changement de ceux obtenus après.

Le cas de démonstration suivant est entièrement hypothétique et ne décrit aucune entreprise réelle ; il sert à vérifier la cohérence entre dépendance, hypothèse, seuil et décision. Une entreprise veut tester un assistant qui classe les demandes reçues par son service administratif, sans envoyer de réponse ni modifier les dossiers. L’hypothèse est précise : sur un lot défini de demandes historiques, l’assistant doit proposer une catégorie exploitable tout en laissant au responsable le dernier mot. Le point de comparaison décrit le classement manuel actuel, les catégories utilisées et les motifs de reprise. La responsable du service décide de la suite du pilote.

La fiche prévoit trois issues avant le test.

La trace conservée réunit le lot utilisé, les propositions de l’assistant, les corrections humaines et la décision finale. Aucun résultat n’est avancé ici : l’exemple montre les règles qui doivent exister avant l’essai, pas ce que l’essai produirait.

Avant le lancement, une lecture à blanc permet de vérifier la cohérence de la fiche. Pour chaque résultat possible, la décision correspondante peut-elle déjà être déterminée ? Une réponse négative révèle un seuil absent, une responsabilité diffuse ou une condition oubliée. Cette vérification porte sur les règles du pilote, pas sur des résultats encore inconnus.

03Fixer les seuils de réussite avant le lancement

La mesure commence lorsque le comité choisit ce qui fera foi et accepte la conséquence attachée à chaque seuil, bien avant la production du tableau de bord. La règle d’évaluation est consignée avant la lecture des résultats.

Cette exigence n’est pas propre à l’IA. Le guide d’évaluation du Trésor britannique demande que l’évaluation soit intégrée à la conception et à la conduite d’une intervention dès les premières étapes.^[2] Une règle écrite après la mesure ne décide plus de rien : elle justifie ce qui a déjà été observé, et la réunion de clôture se réduit alors à un arbitrage entre interprétations concurrentes.

Pour mesurer les risques liés à l’IA, le NIST demande que les approches soient documentées, rattachées au contexte de déploiement et éclairées par des experts du domaine ainsi que par les utilisateurs concernés.^[7] Un indicateur n’est donc pas pertinent parce qu’il est facile à obtenir ou paraît précis. Il doit correspondre à l’usage, aux risques et aux personnes concernées. Le guide d’usage de l’IA publié par le gouvernement britannique demande aussi d’envisager que l’IA ne soit pas la meilleure solution au problème et qu’une technologie éprouvée puisse être plus adaptée.^[9]

Une mesure exploitable comporte cinq composantes : le point de comparaison, l’indicateur, le protocole, le seuil et le document conservé. Le protocole définit les conditions d’observation, le seuil rattache le résultat à une décision, et le document permet de rouvrir la conclusion plus tard.

Les indicateurs couvrent les dimensions susceptibles de changer la décision.

Ces dimensions n’ont pas besoin d’être fondues dans une note unique. Plusieurs résultats favorables ne compensent pas une faiblesse définie comme rédhibitoire. La fiche sépare donc les critères que l’on peut pondérer de ceux qui imposent un arrêt. Une bonne performance métier ne neutralise pas une impossibilité de contrôle. À l’inverse, une difficulté réparable n’oblige pas à abandonner si les conditions de révision ont été définies.

Les trois seuils s’écrivent séparément : une autre personne doit pouvoir aboutir à la même décision à partir du dossier.

Les seuils ne se déplacent pas discrètement après l’observation. Un résultat peut révéler qu’un indicateur a été mal choisi ou qu’une condition déterminante manquait. Cette découverte justifie une révision documentée : nouvelle hypothèse, nouveau protocole et nouvelle règle de décision. Elle n’autorise pas à présenter le premier essai comme concluant selon une règle créée après coup.

La collecte conserve aussi les désaccords. L’écart entre un responsable métier et un utilisateur concerné peut signaler que l’indicateur mesure une sortie correcte sans saisir les conditions réelles d’usage. Le désaccord devient alors un point à examiner, avec une personne chargée de le résoudre et une échéance située avant la réunion finale. Il ne reste pas enfoui dans un compte rendu général.

Enfin, les résultats exigés restent proportionnés à la décision. L’autorisation du prochain jalon demande une démonstration adaptée à ce périmètre. Elle ne certifie ni l’aptitude à une diffusion générale ni la maîtrise de cas absents du test. La décision consigne explicitement ce que l’essai établit et ce qu’il laisse ouvert.

04Cinq règles à inscrire dans le calendrier

Le calendrier suit l’ordre dans lequel les incertitudes doivent être levées. Une condition bloquante est examinée avant les travaux qui en dépendent. Les dates calendaires dépendent du jour de lancement ; les cinq bornes relatives, elles, sont inscrites dans la fiche approuvée.

Un décalage reste possible, mais il se consigne avec sa cause et son effet sur la décision finale. Le manuel de service britannique assume d’ailleurs qu’une phase d’investigation puisse se conclure par la décision de ne pas poursuivre : la fin d’une phase n’est pas un droit de passage.^[4]

Les responsabilités sont explicites dès le premier jalon. Le commanditaire s’assure que la décision répond au besoin de l’entreprise et arbitre les moyens internes. Le responsable métier garantit le périmètre et le point de comparaison. Le responsable du pilote coordonne l’exécution et rassemble les résultats. Les spécialistes examinent les questions de leur domaine sans se substituer au décideur. Les utilisateurs décrivent les conditions réelles d’usage et les écarts rencontrés.

Chaque rôle porte une décision propre, une preuve à produire et une limite qu’il ne franchit pas.

Tout cumul de rôles est consigné dans la fiche. Celui qui configure l’essai et évalue seul sa réussite se trouve en position d’interpréter ses propres choix. Une autre personne peut alors relire le résultat, sans prétendre à une indépendance que l’organisation ne possède pas.

Les conditions préalables sont ordonnées selon leur effet sur le test. Une donnée disponible trop tard peut empêcher d’établir le point de comparaison. La fiche précise quels utilisateurs doivent participer à l’évaluation. Une validation interne non obtenue peut interdire l’essai prévu. Dans chaque cas, le jalon indique si le calendrier est ajusté, si le périmètre est réduit ou si le projet s’arrête.

Le registre des décisions accompagne le calendrier. Il consigne la question posée, les faits examinés, la personne qui tranche et la conséquence sur la suite. Un accord oral n’autorise rien au-delà de ce qui est écrit. À la fin des 90 jours, ce registre montre comment le pilote a évolué et quelles règles sont restées constantes.

Un jalon franchi ne signifie pas que tout va bien. Il confirme que le résultat exigé pour passer à l’étape suivante existe et que les écarts ont reçu un traitement explicite. Si cette preuve manque, le jalon reste ouvert ou bloqué. Le calendrier ne transforme jamais une absence de résultat en validation tacite.

05Au bout de 90 jours : poursuivre, revoir ou arrêter

La réunion finale n’est ni une démonstration du produit ni une recherche tardive de consensus. Elle applique les règles approuvées au dossier produit. Tous les participants reçoivent la même version de la fiche, des mesures, du registre des changements, des écarts non résolus et de la recommandation argumentée.

L’ordre de lecture commence par l’hypothèse et ses seuils. Il se poursuit avec la solidité des résultats, les limites du test et les changements intervenus. La discussion porte ensuite sur l’issue correspondant aux règles. Une fonctionnalité séduisante, une préférence personnelle ou un incident isolé ne suffit pas à écarter les règles convenues.

La poursuite du projet autorise une étape précisément définie. La décision indique le périmètre ouvert, les contrôles maintenus, le responsable et les preuves encore requises. Elle ne transforme pas le pilote en déploiement général. Si l’étape suivante change les utilisateurs, les données, l’autonomie du système ou les conséquences possibles, elle reçoit son propre cadrage.

La révision du test modifie un point précis de l’hypothèse ou du protocole. La décision nomme ce point, le motif du changement, le nouveau résultat attendu et la nouvelle règle de sortie. Elle conserve la trace de ce que le premier essai n’a pas établi.

L’arrêt acte que la poursuite ne respecte plus les conditions convenues. Il peut résulter d’une hypothèse réfutée, d’une ressource durablement absente ou d’un risque auquel l’entreprise ne peut pas répondre de façon acceptable. Le NIST distingue plusieurs réponses possibles face à un risque lié à l’IA : le réduire, le transférer, l’éviter ou l’accepter.^[8] Continuer n’est donc jamais la seule option, et le cadre de gestion du risque attend une décision explicite plutôt qu’une poursuite par défaut.^[6]

Cette issue est plus fréquente que les annonces ne le laissent croire. En 2025, 19,95 % des entreprises de l’Union européenne déclaraient utiliser au moins une technologie d’intelligence artificielle, contre 55,03 % des grandes entreprises.^[12] Du côté public britannique, 70 % des organismes interrogés par le National Audit Office expérimentaient ou planifiaient des cas d’usage.^[10] Ces chiffres mesurent des usages et des intentions, jamais des résultats : la pression à démarrer est réelle, la preuve qu’il faut poursuivre ne l’est pas.

Le compte rendu final reprend l’issue choisie, les seuils franchis ou non, les réserves, les responsabilités et la prochaine échéance éventuelle. Il indique aussi qui conteste la conclusion et pour quelle raison. La signature ne valide pas les résultats ; elle confirme que le décideur les a examinés et assume son choix.

Il reste un cas possible : l’impossibilité de décider. Le dossier doit la rattacher à une règle prévue. Si le résultat manque parce que le protocole a échoué, la conséquence peut être une révision du test. Si la preuve requise ne peut pas être obtenue dans le périmètre accepté, la conséquence peut être l’arrêt. Tout report précise donc sa cause, son responsable et la nouvelle condition attendue.

Si l’entreprise ne parvient pas à fixer seule la situation de départ, les seuils et les responsabilités, un audit IA peut cadrer ces arbitrages ; il ne conduit ni le pilote ni son intégration.

La qualité d’un pilote se mesure à la décision qu’il permet de prendre, y compris lorsque cette décision consiste à l’arrêter.

Au terme des 90 jours, le dossier conduit à une issue écrite : poursuivre une étape délimitée, revoir le test autour d’une nouvelle hypothèse ou l’arrêter pour un motif établi. Si aucune règle approuvée ne permet encore de choisir, le pilote n’est pas prêt à être étendu, et la première correction à apporter porte sur la feuille de route elle-même.