Lancer un projet pilote d’IA générative n’a jamais été aussi facile. Une petite équipe, un modèle performant et quelques semaines suffisent pour une démonstration convaincante : un assistant de ventes qui rédige des plans de compte, un agent de service qui répond aux questions sur les politiques, un copilote financier qui rédige les commentaires sur les écarts. La direction voit la démonstration, approuve l’étape suivante, puis le projet pilote reste en attente pendant des mois.
Quand les projets pilotes calent, le modèle en est rarement la cause. Ils calent parce que personne n’est responsable du résultat, que personne ne peut montrer que les réponses sont assez bonnes, que personne ne connaît le coût à plein volume, que personne n’est prêt à soutenir l’outil, et que les personnes censées l’utiliser n’ont jamais été invitées à changer leur façon de travailler.
Là où les projets pilotes calent
Chacune de ces lacunes est ordinaire, et chacune a une solution ordinaire. Ensemble, elles expliquent pourquoi tant d’organisations enchaînent les projets pilotes sans rien mettre en production. La voie à suivre consiste à combler correctement ces lacunes pour un cas d’usage, puis à réutiliser ce qui a été bâti pour les suivants. Le premier cas d’usage porte l’essentiel de l’effort; les suivants en héritent.
Nommer un responsable évalué sur le résultat
Un cas d’usage en production a besoin d’un responsable d’affaires : un dirigeant dont l’équipe l’utilisera et qui sera évalué sur le résultat. Ce responsable définit ce qu’est un bon résultat, accepte le risque résiduel et fait de la place au changement dans la façon de travailler. Il décide aussi quand le projet pilote a réussi, ce qui évite le cas fréquent d’un projet pilote qui se prolonge parce que personne n’a l’autorité d’y mettre fin. Les équipes technologiques sont responsables de la plateforme et de la construction. Elles ne peuvent pas être responsables du résultat.
Si aucun dirigeant d’affaires n’accepte de prendre un projet pilote en charge, c’est une information utile. Cela signifie généralement que le cas d’usage règle un problème pour lequel personne ne paie, et la décision la plus sage est de l’arrêter tôt.
Prouver la qualité avant d’étendre
Une démonstration montre que l’assistant peut avoir raison. La production exige la preuve qu’il a raison assez souvent, sur les cas qui comptent. Constituez un jeu d’évaluation de cas réels avec les réponses attendues, convenez du seuil de qualité avec le responsable et exécutez le jeu après chaque modification du modèle, des instructions ou des données. Nous expliquons comment bâtir un tel jeu dans notre analyse sur la préparation des données pour les agents IA.
Continuez d’évaluer après le lancement. Examinez chaque semaine un échantillon de réponses en production, suivez la part qui réussit et transmettez à une personne les cas incertains ou à risque élevé. L’évaluation n’est pas une phase qui se termine; c’est ainsi que le cas d’usage reste digne de confiance à mesure que le modèle, les données et l’entreprise changent autour de lui.
Connaître le coût par réponse
Les coûts d’un projet pilote sont faibles, et personne ne les surveille. À plein volume, le coût de chaque requête devient une ligne dans le budget de quelqu’un. Mesurez le coût par réponse, par document ou par conversation dès le premier jour du projet pilote, et projetez-le à plein volume avant d’approuver le déploiement. Dans chaque revue, le coût devrait figurer à côté de la valeur, pour la même période et dans la même devise.
La plupart des leviers sont des choix de conception : utiliser le plus petit modèle qui franchit le seuil de qualité, n’envoyer que le contexte dont une requête a besoin, réutiliser les résultats pour les questions répétées et fixer des alertes de dépenses pour chaque cas d’usage. Un cas d’usage dont la valeur ne couvre pas son coût d’exploitation à grande échelle ne devrait pas aller en production, aussi impressionnante que soit la démonstration.
Planifier le soutien et le changement avant la mise en service
Les utilisateurs doivent savoir où signaler une mauvaise réponse et en combien de temps elle sera corrigée. Quelqu’un doit prendre en charge les instructions, le jeu d’évaluation et les connexions aux données une fois l’équipe de projet partie. Rédigez ce modèle de soutien avant la mise en service, comme pour toute application d’affaires, et décidez comment une nouvelle version est publiée : qui l’approuve, comment elle est testée et comment les utilisateurs apprennent ce qui a changé.
Le changement est la tâche la plus lourde. Les gens adoptent une nouvelle façon de travailler quand elle s’intègre aux outils qu’ils utilisent déjà, quand leurs gestionnaires s’y attendent et quand l’ancienne méthode est retirée. Les séances de formation seules y parviennent rarement; repenser le processus autour de l’assistant y parvient généralement.
D’un cas d’usage à un portefeuille
Le deuxième cas d’usage devrait coûter beaucoup moins cher que le premier, parce qu’il réutilise ce que le premier a bâti : l’identité et les accès, la journalisation, le jeu d’évaluation et ses outils, le suivi des coûts et le modèle de soutien. Traitez ces éléments comme une plateforme commune, et non comme les composantes d’un seul projet. Une plateforme commune évite aussi le problème inverse, où chaque service achète son propre assistant, avec ses propres contrôles, pour le même besoin.
Choisissez les cas d’usage suivants selon leur valeur et leur faisabilité, et ordonnez-les en vagues, avec les fondations de données et la gouvernance qui avancent en parallèle. Une vue de portefeuille permet aussi à la direction de comparer les cas d’usage selon les mêmes mesures et de déplacer l’investissement vers ceux qui rapportent.
Une gouvernance qui accélère
Une bonne gouvernance accélère le passage à l’échelle, parce que chaque équipe connaît la barre avant de commencer. Une courte série de critères de passage suffit :
- un responsable d’affaires nommé et une mesure de valeur convenue;
- un jeu d’évaluation, et un seuil de qualité atteint;
- un coût par utilisation connu, projeté à plein volume;
- un modèle de soutien et un plan pour le changement dans la façon de travailler;
- un examen des risques, avec des personnes qui approuvent toute action lourde de conséquences.
Passez le portefeuille en revue chaque trimestre au regard de ces critères et de la valeur livrée. Étendez ce qui fonctionne, corrigez ce qui s’en approche et arrêtez le reste. Ce rythme, plus que tout choix technologique, transforme une collection de projets pilotes en une capacité durable.