Les trois gestes qui font tenir un système

Une équipe qui reprend un système 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.

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.

Savoir remonter d'une mauvaise réponse aux documents qui ont été fournis au modèle est la compétence de diagnostic la plus rentable. 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.

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.

Savoir dire quelles questions le système ne doit pas traiter est une compétence métier, et c'est celle qui protège le plus. 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.

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.

Une journée avec le système réel, ses journaux réels et ses questions réelles 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. La première : lire dix journaux d'incidents réels et classer chacun dans l'une des deux causes. La deuxième : rejouer le jeu de tests, ajouter trois lignes issues d'échecs récents, relancer. La troisième : lire cinquante questions réelles et trancher le périmètre.

À 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.

Après transmission, le rôle du constructeur 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.

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é.