Une formation IA utile commence par les erreurs que le métier ne peut pas se permettre

Le problème à résoudre avant l’outil

En paie, une erreur de ton n’a pas le même poids qu’un montant faux ou une donnée personnelle envoyée au mauvais service. Voilà le moment où l’IA cesse d’être un sujet technique et devient un sujet d’organisation : commencer par les échecs critiques donne immédiatement du sens aux contrôles et aux interdits.

Une compétence IA utile se voit dans une situation de travail, pas dans la capacité à réciter le nom des modèles. Elle ne tient pas dans un prompt : il faut comprendre le problème, vérifier la sortie, protéger les données et savoir interrompre l’usage. Plus la sortie paraît convaincante, plus la connaissance du métier compte pour reconnaître ce qui cloche vraiment. Pour ce sujet, je resserre volontairement la focale : Commencer par les échecs critiques donne immédiatement du sens aux contrôles et aux interdits. Une tâche accélérée ne garantit rien si les étapes voisines restent inchangées.

Commencer par le réel

On dispose maintenant de repères plus solides que les impressions de début d’année. 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 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. Aucun de ces éléments ne prouve qu’un usage sera pertinent chez toi. Ils suffisent en revanche à justifier un test sérieux.

Je regarderais un point avant tous les autres : dresser la liste des erreurs inacceptables avant les cas d’usage séduisants. Compare plusieurs semaines, pas une seule démonstration. La stabilité compte autant que le meilleur résultat obtenu une fois. Note les erreurs par nature, pas seulement en nombre. Une petite erreur de forme et une mauvaise décision n’ont pas le même poids.

Quatre contrôles simples

Partir d’une situation réelle et demander à la personne d’expliquer ses choix, pas seulement son prompt. 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.

Tester la capacité à repérer une réponse plausible mais insuffisante. Ça ramène vite la discussion aux gestes réels, aux fichiers réels et aux personnes qui reprennent le dossier.

Inclure les règles de données, de confidentialité et de vérification propres au métier. C’est un petit réglage sur le papier, mais il évite de transformer le contrôle humain en travail caché.

Rejouer l’exercice lorsque l’outil change afin de vérifier que la compétence est transférable. 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.

Le cas qui doit te faire arrêter

C’est précisément là qu’une formule trop simple devient dangereuse. Le cas moyen ne suffit pas. Les exceptions disent souvent si le système est réellement prêt. En paie, une erreur de ton n’a pas le même poids qu’un montant faux ou une donnée personnelle envoyée au mauvais service. Un même mécanisme peut être très utile dans un cas et franchement mauvais dans un autre.

Une délégation technique n’est pas, à elle seule, un transfert de responsabilité. Plus le résultat est sensible, plus le niveau de preuve, de contrôle et de possibilité de reprise doit être explicite.

Une règle de sortie

Au fond, je garderais une règle assez terre à terre : dresser la liste des erreurs inacceptables avant les cas d’usage séduisants. C’est moins spectaculaire qu’une démo, mais beaucoup plus utile pour faire tenir l’usage dans le temps.