Parlons de votre projet
Aller au contenu
Toutes les publications

Former à tenir un système, pas à utiliser un outil

Par Docteur en intelligence artificielle · Conseil, conception de systèmes et formation

FormationTransmissionExploitationAutonomie9 juin 2026Mis à jour le 13 octobre 20269 min

Savoir se servir d’un outil et savoir le tenir sont deux compétences différentes. La seconde est celle qui décide si le système survit au départ du prestataire.

Illustration de l’article « Former à tenir un système, pas à utiliser un outil »

Qu’est-ce que « tenir » un système d’IA ?

Tenir un système d’IA, c’est être capable de dire s’il fonctionne encore, de comprendre pourquoi il s’est dégradé et de le corriger, sans faire appel à la personne qui l’a construit.

La définition se comprend mieux par contraste. Utiliser un système, c’est poser des questions et exploiter les réponses. Tenir un système, c’est intervenir sur ce qui produit ces réponses : le corpus, les consignes, le modèle appelé, le jeu de tests qui mesure la qualité.

Un assistant documentaire, un outil de tri du courrier ou un générateur de comptes rendus ont tous besoin des deux compétences. La première concerne tous les utilisateurs. La seconde ne concerne que quelques personnes, et c’est d’elle que dépend la durée de vie du système.

Pourquoi confond-on former à utiliser et former à tenir ?

On confond former à utiliser et former à tenir parce que les deux s’appellent « formation à l’IA », alors que la première rend les utilisateurs efficaces et que seule la seconde rend l’organisation autonome.

CritèreFormer à utiliserFormer à tenir
PublicTous les utilisateursRéférents identifiés et disponibles
ObjectifBien poser les questions, connaître les limitesDiagnostiquer, mesurer, corriger
SupportLe système tel qu’il se présenteLes journaux, le jeu de tests, le corpus
Mode d’apprentissageDémonstration et exercicesGestes faits sur le vrai système
Preuve de réussiteUsage correct et prudentDiagnostic et modification dans le périmètre prévu
Ce qui se passe sans elleMauvais usages, confiance excessiveSystème orphelin au départ de son concepteur
Deux compétences qu’on confond

Que doit savoir faire un référent sur le système réel ?

Un référent doit savoir lire les traces, rejouer les tests, intégrer une erreur observée et mettre à jour les sources, avec les accès et responsabilités correspondants.

  • Rejouer le jeu de tests et lire l’écart avec la référence. C’est le geste de base, celui qui répond à « est-ce que ça marche toujours ».
  • Ajouter un cas au jeu de tests quand un utilisateur remonte une erreur. Sans cela, la mesure se périme.
  • Mettre à jour le corpus : ajouter, retirer, réindexer, et vérifier que la recherche s’est améliorée et non dégradée.
  • Lire les journaux pour distinguer un problème de récupération d’un problème de génération. Ce sont deux corrections différentes.
  • Modifier un prompt et mesurer l’effet, dans cet ordre. La partie difficile n’est pas la modification, c’est la mesure.

Quels sont les trois gestes qui rendent une équipe autonome ?

Lire les journaux, rejouer les tests et décider du périmètre de réponse constituent un socle d’autonomie, à compléter selon les composants et les incidents du système.

Une trace aide à distinguer l’information absente du contexte d’une mauvaise utilisation d’une information disponible. Le jeu de tests permet de comparer un changement à une référence. Le refus ou la clarification relève aussi du métier : que peut-on raisonnablement répondre avec les sources disponibles ?

Ces gestes doivent être pratiqués sur le système réellement exploité. Ils ne demandent pas nécessairement d’entraîner un modèle, mais ils supposent des accès autorisés et une connaissance de la chaîne.

La constitution du jeu de tests et l’évaluation continue fournissent des points d’appui. La durée de transmission dépend du système et du niveau initial, sans promesse universelle d’une journée.

Pourquoi la documentation ne suffit-elle pas à transmettre ces gestes ?

La documentation donne un ordre de travail, tandis que la pratique accompagnée permet au référent de relier les gestes aux résultats et de reconnaître un incident.

J’ai longtemps livré des documents d’exploitation soignés. Ils étaient lus une fois, puis jamais rouverts. J’ai donc changé de méthode : le référent fait les gestes pendant la mission, sur le vrai système, avec moi à côté.

Il voit ce qu’une trace permet de conclure, ce qu’un écart de test signifie et quand une modification doit être abandonnée. L’aide-mémoire sert ensuite à retrouver l’ordre des étapes et les points d’escalade.

Un document reste nécessaire : il doit être accessible, exact et adapté au rôle. Il ne faut pas opposer formation pratique et documentation, mais vérifier que les deux permettent de travailler sans dépendre d’une seule personne.

Comment organiser la transmission à un référent, étape par étape ?

Une transmission réussie à un référent suit une progression simple : désigner les bonnes personnes, leur faire faire chaque geste sur le système réel, puis les laisser conduire seules une modification complète.

  1. Désigner deux référents dès le cadrage. Des personnes qui connaissent le métier et que les utilisateurs sollicitent déjà, avec du temps dégagé et écrit.
  2. Leur montrer le système de l’intérieur. Où sont les journaux, où est le jeu de tests, comment le corpus est alimenté, où se trouvent les consignes.
  3. Leur faire faire chaque geste une fois. Rejouer les tests, lire un journal sur une erreur réelle, ajouter un cas, réindexer une source.
  4. Traiter ensemble les premiers incidents. Le référent tient le clavier, l’accompagnant commente. Les incidents sont pris à tour de rôle entre les deux référents.
  5. Écrire l’aide-mémoire après, pas avant. Il reprend l’ordre des étapes tel que le référent l’a vécu, dans ses mots.
  6. Passer le test de sortie. Une modification réelle conduite seul, du début à la fin.

Cette progression vaut aussi quand on reprend un système existant, situation décrite dans reprendre un système d’IA construit par quelqu’un d’autre. Elle est au cœur des formations IA orientées vers l’exploitation plutôt que vers l’usage.

En quoi consiste le test de sortie de mission ?

Le test de sortie de mission consiste à faire conduire par le référent, seul et du début à la fin, une modification réelle du système, journaux et mesure compris, pendant que l’accompagnant observe sans intervenir.

Il est simple et il n’est pas négociable. Avant mon départ, je provoque une modification réelle, un changement de modèle, ou l’ajout d’une source au corpus, et le référent la conduit seul, du début à la fin, journaux et mesure compris.

Je regarde sans intervenir. Si cela ne passe pas, la mission n’est pas finie, et ce n’est pas au client de le découvrir trois mois plus tard.

Ce test a un effet secondaire utile : il oblige à ce que le référent soit identifié dès le début et qu’il ait du temps, ce qui est une décision d’organisation que personne ne prend spontanément. Le test porte sur un périmètre convenu et une modification réversible. Un incident qui le dépasse appelle une escalade prévue ; demander de l’aide ne prouve pas automatiquement que la transmission a échoué.

Comment choisir les référents sans confondre disponibilité et compétence ?

Le choix des référents doit réunir connaissance du métier, capacité à accéder au système et temps dégagé, plutôt que désigner la personne simplement disponible ce jour-là.

Désigner comme référent la personne la plus disponible plutôt que la plus légitime. Le bon référent est celui qui connaît le métier et que les utilisateurs vont solliciter naturellement. S’il n’a pas de temps dégagé, il faut arbitrer : pas contourner.

Pourquoi un référent unique est-il un risque ?

Un référent unique concentre une connaissance et des accès qui peuvent manquer pendant son absence, ce qui impose de prévoir un relais réellement capable d’effectuer les gestes.

Je recommande un partage effectif des tâches, avec des personnes qui interviennent à tour de rôle. Le relais ne doit pas être un nom dans une liste : il doit avoir pratiqué une modification et savoir où trouver les procédures.

Le nombre de personnes dépend du service et de la disponibilité attendue. Pour un système important, je vérifie au minimum la continuité en cas d’absence du référent principal.

Cette organisation évite une forme de dette technique. La maintenance après la mise en service doit être anticipée dans la charge des personnes désignées.

Quelles erreurs fréquentes empêchent l’autonomie d’une équipe ?

Les erreurs qui empêchent une équipe de devenir autonome sur son système d’IA tiennent presque toutes à l’organisation, et très peu à la difficulté technique des gestes à transmettre.

  • Former tout le monde de la même façon. Les utilisateurs reçoivent trop de technique, les référents pas assez.
  • Confondre référent et administrateur. Gérer les comptes n’apprend pas à diagnostiquer une réponse fausse.
  • Faire les gestes à la place du référent. C’est plus rapide pendant la mission, et cela laisse un référent qui a regardé sans jamais faire.
  • Livrer sans jeu de tests. Sans mesure, le référent ne peut que constater des plaintes, jamais décider d’un changement.
  • Oublier le temps dégagé. Un référent sans temps écrit dans son poste redevient utilisateur au premier pic d’activité.

Quel est le lien avec l’obligation de littératie IA ?

L’exigence de former des référents rejoint l’obligation de littératie IA du règlement européen, qui demande un niveau de maîtrise adapté au rôle de chaque personne, et non un contenu identique pour tous.

Cette obligation est applicable depuis le 2 février 2025 : les fournisseurs et les déployeurs prennent des mesures pour assurer, dans toute la mesure du possible, un niveau suffisant de maîtrise de l’IA à leur personnel, en tenant compte de ses connaissances et du contexte d’utilisation.

Cette formulation est celle du texte d’origine, applicable à la date du 9 juin 2026. Elle demande de tenir compte des rôles et du contexte ; elle n’impose pas mon programme particulier de formation. Pour un référent, je recommande des exercices d’exploitation distincts de ceux des utilisateurs. Le sujet est développé dans l’obligation passée inaperçue, et la distinction des rôles rejoint celle des métiers de l’IA.

Quelles questions fréquentes se poser sur la formation des référents ?

Quelle est la différence entre utiliser et tenir un système ?

Utiliser, c’est poser des questions et lire des réponses; Tenir, c’est diagnostiquer une réponse fausse, décider d’un changement sur des chiffres, et trancher le périmètre de refus. La première compétence concerne tous les utilisateurs, la seconde deux ou trois référents.

Que doit savoir faire un référent, seul ?

Lire un journal pour séparer un problème de récupération d’un problème de réponse, rejouer le jeu de tests et l’alimenter, et décider quelles questions reçoivent un refus. Il doit aussi savoir mettre à jour le corpus et mesurer l’effet d’une modification de consigne.

Pourquoi la documentation ne suffit-elle pas ?

Parce qu’elle décrit une procédure sans produire le réflexe de la déclencher; La transmission se fait en traitant ensemble des incidents réels, pas en lisant.

Combien de référents désigner ?

Le nombre de référents doit permettre une continuité réelle selon la disponibilité du service, avec un relais formé et des gestes pratiqués à tour de rôle. Je conseille d’éviter la dépendance à une personne.

Faut-il savoir entraîner un modèle pour être référent ?

Non; Les gestes qui font tenir un système portent sur les journaux, le jeu de tests, le corpus et les consignes. Aucun ne demande d’entraîner ou d’ajuster un modèle, ce qui rend la fonction accessible à une personne du métier.

Comment savoir si la transmission a réussi ?

La transmission se vérifie en demandant une modification réversible conduite par le référent avec diagnostic, tests et décision, dans le périmètre convenu et avec les procédures disponibles. Les points d’escalade doivent aussi être compris.

Lectures complémentaires : les trois gestes qui font tenir un système.

Sources

Votre prochain projetParlons-en.Réserver un échange de 15 minutes sur Cal.com, dans un nouvel onglet