Pourquoi les pilotes s’enlisent
Un pilote est conçu pour impressionner. Un système en production est conçu pour être ennuyeux. L’écart entre les deux tient surtout à un travail peu spectaculaire : intégrations, droits d’accès, gestion des erreurs, supervision, et les personnes qui piloteront le système un mardi ordinaire.
Pendant la session, nous avons passé en revue les schémas que nous rencontrons le plus souvent. Le pilote répond aux questions dans une fenêtre de chat, mais ne peut pas agir dans les systèmes où le travail se fait. Personne n’a mesuré le processus au préalable, donc personne ne peut prouver que le pilote a aidé. Et le sponsor est à la DSI, alors que les personnes dont le travail allait changer n’ont jamais été associées.
Choisir une tâche, pas une technologie
Les pilotes qui passent en production commencent par une description de tâche. « Rédiger les premières réponses aux tickets de facturation de niveau 1 » est une tâche. « Utiliser l’IA générative dans le service client » est un slogan.
Une tâche précise vous donne un jeu de test, une référence et un responsable évident. Elle raccourcit aussi la discussion sur les risques, puisque vous pouvez dire exactement ce que le système touchera et ce qu’il ne touchera pas.
Mesurer avant de construire
Consacrez la première semaine à mesurer le processus actuel : combien de tickets, combien de temps chacun prend, à quelle fréquence la réponse est fausse. Sans ces chiffres, la revue du pilote tourne au débat d’impressions.
Fixez le seuil de réussite par écrit avant d’écrire la moindre ligne de code. Par exemple : 60 % des brouillons envoyés avec de légères retouches, et un temps de traitement moyen réduit d’un tiers.
Penser production dès la première semaine
Vous n’avez pas besoin d’une infrastructure de production le premier jour, mais vous devez savoir à quoi elle ressemblera. Où le modèle tournera-t-il ? Comment s’authentifiera-t-il auprès du CRM ? Qui sera alerté en cas de panne ?
Traitez les prompts, les paramètres de recherche et les jeux d’évaluation comme du code. Versionnez-les, relisez-les et lancez l’évaluation à chaque modification.
- Versionner les prompts et les jeux d’évaluation avec le code de l’application
- Journaliser chaque appel au modèle avec ses entrées, ses sorties et son coût
- Écrire noir sur blanc ce que le système peut faire sans validation
- Désigner le responsable métier qui valide les mises en production
Confier la responsabilité au métier
C’est l’étape la plus souvent oubliée. Une IA en production a besoin d’un responsable côté métier qui contrôle la qualité, décide des évolutions de périmètre et porte l’adoption auprès de son équipe. La DSI la fait tourner. Le métier décide à quoi elle sert.
