Former deux cents personnes à l'IA générative : ce qui marche

Mes premières sessions ressemblaient à ce qu'on trouvait partout : une présentation des grands modèles, une démonstration, une liste de bonnes pratiques de formulation, un temps de questions.

Les retours à chaud étaient excellents. L'usage trois mois plus tard était quasi nul. Ce décalage m'a occupé un moment, jusqu'à ce que la raison devienne évidente : j'avais transmis une culture générale, pas une capacité.

Je demande maintenant aux participants d'arriver avec un document réel sur lequel ils travaillent cette semaine. Un vrai. Pas un exemple.

Cela produit trois effets immédiats. La séance devient concrète, parce que chacun voit son propre travail. Elle devient inégale, parce que certains cas résistent, et c'est précisément là que la formation prend de la valeur. Et elle devient utile le jour même : la personne repart avec un livrable qu'elle allait devoir produire de toute façon.

Le taux d'usage à trois mois n'est plus comparable.

Une direction générale a besoin d'arbitrer : où mettre l'argent, quel risque on prend, quelles obligations arrivent. Un manager a besoin de réorganiser un processus : ce qui disparaît, ce qui reste, qui valide. Une équipe opérationnelle a besoin de gagner du temps dès la semaine suivante.

Mettre ces trois publics dans la même salle avec le même contenu garantit que deux d'entre eux perdent leur journée. C'est pourtant ce que proposent la plupart des catalogues.

Je ne considère plus la formation comme une prestation séparée. Elle fait partie de la mise en production : un système que personne ne sait faire tourner n'est pas en production, il est en sursis.

C'est pour cela que la dernière phase de mes missions consiste à faire tenir l'outil par les équipes, devant moi, avant que je parte. Tant que ce n'est pas démontré, la mission n'est pas finie.

Quand chacun peut créer un assistant en dix minutes, la compétence à transmettre n'est plus « créer » mais « savoir quand un assistant ne suffit plus ». C'est le déplacement pédagogique majeur de ces trois années.

Apprendre à rédiger une consigne prend une heure et devient rapidement obsolète, les modèles étant de plus en plus tolérants aux formulations approximatives.

Apprendre à reconnaître qu'un usage a changé de nature, qu'il engage l'organisation, qu'il touche des données protégées, qu'il est devenu quotidien pour une équipe entière, reste utile durablement. C'est le contenu que je place désormais en premier, et il rejoint ce qui est décrit dans les trois gestes qui font tenir un système.

Une journée sur leurs propres fichiers vaut mieux qu'une semaine de formation générale sur des exemples inventés. Le constat est constant et il vaut pour tous les publics.

La mécanique est simple : un participant qui travaille sur un document qu'il connaît juge immédiatement la qualité du résultat. Il repère l'erreur, il perçoit la limite, il ajuste. Sur un exemple fabriqué, il n'a aucun repère et retient une impression.

La contrainte que cela impose est organisationnelle : il faut que les participants viennent avec de la matière, et le rappeler plusieurs fois avant la session. C'est le seul point de logistique qui décide vraiment du résultat.

Le nombre de personnes qui utilisent encore l'outil six semaines plus tard, pas la note de satisfaction en fin de session. Les deux ne corrèlent pas.

Une session bien menée obtient de bonnes notes systématiquement, y compris quand elle ne change rien aux pratiques. La satisfaction mesure la qualité du moment, jamais l'effet.

Six semaines est le bon horizon : c'est le délai au bout duquel l'enthousiasme retombe et où seuls subsistent les usages qui apportent réellement quelque chose. Le raisonnement complet figure dans écrire la fiche d'un système d'IA, pour la partie documentation, et la mesure d'usage se construit comme décrit dans mesurer le coût par fonctionnalité.