L’entreprise doit-elle former aux modèles ou aux situations de travail ?

Le point de départ

Les équipes retiennent le nom des modèles mais hésitent encore sur la façon de traiter un document client confidentiel. C’est le genre de situation qui paraît évidente après coup, mais qu’on oublie souvent au moment de concevoir l’usage : les modèles changent plus vite que les situations métier. Former par situation rend l’apprentissage plus stable tout en gardant une couche minimale de culture technique.

Ce que les sources permettent de dire

La tendance est suffisamment documentée pour qu’on la prenne au sérieux. La Commission rappelle en 2026 que la maîtrise de l’IA doit être adaptée aux rôles, aux risques et au contexte d’usage. Une sensibilisation générique ne remplace pas la capacité à utiliser et superviser les outils de façon sûre. L’OIT souligne en août 2026 que l’adoption de l’IA modifie la combinaison de compétences attendues et renforce notamment le besoin de compétences cognitives de niveau supérieur, socioémotionnelles, numériques et de littératie IA. La suite logique consiste donc à confronter ce signal à une tâche, une équipe et un résultat mesurable.

Là où le raisonnement devient plus difficile

Une compétence IA utile se voit dans une situation de travail, pas dans la capacité à réciter le nom des modèles. Le niveau réel apparaît quand la personne sait utiliser, contester, vérifier et reprendre la main. La compétence métier donne le recul nécessaire pour savoir quand une belle réponse ne mérite pas d’être suivie. Si on enlève le bruit autour, il reste ceci : Les modèles changent plus vite que les situations métier. Former par situation rend l’apprentissage plus stable tout en gardant une couche minimale de culture technique. Sans ce détour, on finit vite par compter ce qui est visible plutôt que ce qui améliore vraiment le travail.

Le point faible d’un raisonnement rapide apparaît ici. Le contexte métier reste donc plus important que la beauté de la démonstration. Les équipes retiennent le nom des modèles mais hésitent encore sur la façon de traiter un document client confidentiel. Il faut regarder qui est touché, ce qui peut mal se passer et qui pourra corriger.

Ce que ça change dans une organisation

Le moyen le plus simple de ramener le sujet au réel est de : ancrer chaque module sur une situation, un risque et un critère de qualité. Demande enfin si la personne responsable comprend encore comment le résultat a été obtenu. La vitesse sans lisibilité devient vite une dette. Mesure le délai de bout en bout. C’est le seul moyen de voir si l’amélioration locale change vraiment le service rendu.

Construire un contrôle qui tient

Partir d’une situation réelle et demander à la personne d’expliquer ses choix, pas seulement son prompt. L’intérêt est surtout de créer un critère observable. Si personne ne peut dire si ce point est respecté, la règle restera décorative.

Tester la capacité à repérer une réponse plausible mais insuffisante. Le but n’est pas d’ajouter une couche de procédure. C’est de rendre visible la décision qui existait déjà, souvent de manière implicite.

Inclure les règles de données, de confidentialité et de vérification propres au métier. C’est le moment de comparer la promesse au flux réel, pas au scénario idéal préparé pour la démo.

Rejouer l’exercice lorsque l’outil change afin de vérifier que la compétence est transférable. Le détail est moins spectaculaire que l’outil, mais il protège celui qui devra reprendre le résultat derrière.

Ce qu’il ne faut pas conclure trop vite

Plus l’outil fait de choses, plus il faut savoir précisément qui reste responsable du résultat. Plus le résultat est sensible, plus le niveau de preuve, de contrôle et de possibilité de reprise doit être explicite.

Au fond, je garderais une règle assez terre à terre : ancrer chaque module sur une situation, un risque et un critère de qualité. C’est moins spectaculaire qu’une démo, mais beaucoup plus utile pour faire tenir l’usage dans le temps.