Les trois gestes qui font tenir un système

Une équipe qui reprend un système d’IA n’a besoin ni de comprendre l’apprentissage automatique, ni de savoir rédiger un prompt élaboré : elle a besoin de trois gestes précis. Le reste est de la culture générale, utile et non nécessaire.

Tenir un système, dans ce sens, veut dire trois choses : comprendre pourquoi il s’est trompé quand il se trompe, vérifier qu’il ne s’est pas dégradé après un changement, et décider de ce qu’il a le droit de traiter. Ce n’est ni le concevoir, ni l’améliorer en profondeur. C’est l’exploiter sans dépendre de celui qui l’a construit.

La formation habituelle fait l’inverse. Elle explique comment fonctionne un modèle de langue, ce qu’est un embarquement, comment sont entraînés les réseaux. Ces contenus intéressent et ne rendent personne capable de tenir un système en exploitation.

Les trois gestes qui comptent sont opérationnels, transmissibles en une journée, et suffisants pour l’essentiel des situations rencontrées :

1. Lire un journal pour remonter d’une mauvaise réponse aux documents fournis au modèle.
2. Rejouer le jeu de tests et l’alimenter avec chaque échec signalé.
3. Décider d’un refus, c’est-à-dire trancher quelles questions sortent du périmètre.

Lire un journal, c’est remonter d’une mauvaise réponse aux documents qui ont été fournis au modèle, et c’est la compétence de diagnostic la plus rentable pour une équipe d’exploitation. Elle sépare deux causes qui appellent des corrections opposées.

Devant une réponse fausse, la question est unique : l’information correcte figurait-elle dans les extraits fournis ? Si elle n’y était pas, le problème est dans la récupération ou dans le corpus. Si elle y était, le problème est dans le prompt ou dans le modèle.

Cette distinction se lit dans le journal en deux minutes, et elle oriente correctement la quasi-totalité des incidents. Elle suppose que le journal contienne bien la question, les extraits fournis et la réponse, ce qui relève de l’observabilité des systèmes d’IA.

Sans elle, l’équipe modifie le prompt par défaut, parce que c’est ce qu’elle sait faire, et le cycle décrit dans reprendre un système d’IA construit par quelqu’un d’autre s’installe.

Le jeu de tests d’un système d’IA se rejoue à chaque changement qui touche le modèle, le prompt, le corpus ou la récupération, et à intervalle fixe même quand rien n’a bougé. La seconde règle est celle qu’on oublie.

Les changements volontaires sont faciles à repérer : une nouvelle version du modèle, une modification du prompt système, un lot de documents ajouté. Dans chacun de ces cas, l’équipe rejoue le jeu avant de mettre en service, et compare au résultat précédent.

Les changements involontaires sont plus insidieux. Un fournisseur peut faire évoluer le comportement d’un modèle sans changer son nom, comme raconté dans le jour où le modèle a changé sans prévenir. Seul un passage régulier du jeu de tests le révèle avant les utilisateurs.

C’est le principe de l’évaluation continue : le jeu de tests n’est pas un livrable de fin de projet, c’est un instrument d’exploitation. Une migration de version se traite de la même façon, avec la méthode de migrer un agent sans régression.

Décider d’un refus, c’est savoir dire quelles questions le système ne doit pas traiter, et c’est une compétence métier qui protège davantage que toutes les compétences techniques. Elle ne demande aucune connaissance technique.

Le geste consiste à examiner les questions réelles posées au système et à trancher : celle-ci est dans le périmètre, celle-là n’y est pas et doit recevoir un refus explicite.

Cette décision revient à l’équipe métier, jamais à l’équipe technique, parce qu’elle porte sur le risque et non sur la faisabilité. Un système peut parfaitement répondre à une question qu’il ne devrait pas traiter. Un assistant interne de ressources humaines, par exemple, peut techniquement commenter la situation d’un collègue nommé ; c’est au métier de dire qu’il ne doit pas le faire.

La formulation du refus compte aussi : « je ne traite pas ce type de demande, adressez-vous à tel service » vaut infiniment mieux qu’un silence ou qu’une réponse évasive. Le principe est développé dans le refus de répondre est une fonctionnalité.

Revoir ces décisions une fois par trimestre suffit à suivre la dérive des usages.

La transmission des trois gestes se fait en une journée avec le système réel, ses journaux réels et ses questions réelles, ce qui vaut mieux qu’une semaine de formation générale. Le support ne doit contenir aucun exemple inventé.

Le déroulé qui fonctionne tient en trois demi-journées :

1. Lire dix journaux d’incidents réels et classer chacun dans l’une des deux causes : l’information manquait aux extraits, ou elle y figurait.
2. Rejouer le jeu de tests, ajouter trois lignes issues d’échecs récents, relancer et lire l’écart.
3. Lire cinquante questions réelles et trancher le périmètre, avec la formulation du refus pour celles qui en sortent.

À la fin, l’équipe a produit quelque chose d’utile, un jeu enrichi, une liste de décisions de périmètre, et elle a acquis les gestes en les faisant.

Cette approche est celle que je recommande systématiquement, et elle contraste avec la formation générale dont l’effet se dissipe en quelques semaines, comme discuté dans former à tenir un système, pas à utiliser un outil. C’est aussi le format des formations IA pensées pour les équipes d’exploitation plutôt que pour la découverte.

Les erreurs qui font échouer la transmission d’un système d’IA tiennent le plus souvent au choix du contenu, trop théorique, et du public, trop technique ou trop large. Elles se reconnaissent avant la session.

• Former sur des exemples inventés : l’équipe ne retrouve pas ses propres cas, et le geste ne se transfère pas.
• Former seulement l’équipe technique, alors que le troisième geste appartient au métier.
• Transmettre sans journal exploitable : si les extraits fournis au modèle ne sont pas journalisés, le premier geste est impossible.
• Livrer un jeu de tests figé, que personne n’a le droit ni le réflexe d’enrichir.
• Garder le constructeur en recours permanent, ce qui dispense l’équipe de faire le geste elle-même.

Chacune de ces erreurs a un coût différé : elle ne se voit pas le jour de la formation, mais au premier incident. Et le coût d’un incident mal diagnostiqué dépasse largement celui d’une journée de transmission, comme le détaille ce que coûte un incident sur un système d’IA.

Après transmission, le rôle de celui qui a construit le système se réduit aux décisions d’architecture, qui reviennent deux ou trois fois par an. C’est l’objectif, et il est atteignable.

Ces décisions sont identifiables : changer de fournisseur, modifier la chaîne de récupération, élargir le périmètre d’action, revoir le découpage du corpus. Elles engagent la structure du système et ne relèvent pas de l’exploitation courante.

Tout le reste, incidents, ajustements, migrations de version, alimentation du jeu de tests, doit être tenu par l’équipe. C’est précisément ce qui occupe une équipe une fois le système en régime, décrit dans ce qui occupe l’équipe la deuxième année.

Cette répartition a un mérite qui dépasse l’autonomie : elle rend le système durable. Un système qui dépend d’une personne extérieure pour chaque incident est arrêté au premier changement de prestataire, quelle que soit sa qualité.