Former ses équipes à l'IA : ce qui marche et ce qui n'est que du théâtre

Le scénario que tout le monde connaît#

Une journée de sensibilisation à l’IA. Un intervenant qui montre des démonstrations spectaculaires. Des équipes qui repartent enthousiastes, avec des idées plein la tête.

Trois semaines plus tard : plus personne ne s’en sert.

Ce n’est pas un échec de l’outil. Ce n’est même pas un échec de l’intervenant. C’est un échec de format — et il est parfaitement prévisible.

Nous avons formé pendant des années, dans des écoles et en entreprise, bien avant que l’IA n’existe sous cette forme. Les mécanismes n’ont pas changé. Ce qui suit n’a donc rien de propre à l’IA : c’est juste que l’IA les révèle brutalement.

Pourquoi la conférence ne marche pas#

Une démonstration produit de l’enthousiasme. L’enthousiasme n’est pas un apprentissage.

Quand vous regardez quelqu’un utiliser un outil sur son exemple, vous comprenez le principe. Vous ne savez toujours pas quoi en faire sur votre dossier, avec vos contraintes, votre jargon métier et vos interdits.

Et le lundi matin, face à votre vraie tâche, vous ne savez pas par où commencer. Alors vous faites comme avant. C’est humain, et c’est rationnel : votre journée n’attend pas.

Le savoir qui n’a pas été mis en pratique dans les quarante-huit heures est perdu. Ce n’est pas une opinion, c’est ce qu’on observe à chaque promotion.

Ce qui marche : trois principes#

1. On travaille sur leurs vrais dossiers#

Pas sur un cas d’école. Sur le devis qu’ils doivent envoyer cet après-midi, le compte rendu qu’ils doivent rédiger, la demande client à laquelle ils doivent répondre.

C’est plus difficile à animer — chacun a un cas différent, et l’intervenant doit être capable de suivre. C’est aussi la seule chose qui produit un usage durable, parce que le participant repart avec un résultat, pas avec une intention.

2. On leur montre où ça rate#

C’est le point que les formations commerciales évitent, parce qu’il abîme la démonstration.

Il faut pourtant provoquer l’erreur devant eux. Poser une question dont on sait que le modèle inventera la réponse. Montrer la réponse fausse, sûre d’elle, parfaitement rédigée. Et laisser le silence s’installer.

C’est ce moment-là qui forme. Pas la démonstration réussie — la démonstration ratée. Parce qu’elle installe le seul réflexe qui compte : je vérifie.

3. On revient trois semaines plus tard#

C’est le temps que personne ne budgète, et c’est celui qui décide de tout.

Après trois semaines, les gens ont essayé. Certains ont abandonné, et il faut comprendre pourquoi. D’autres ont pris de mauvais plis. Quelques-uns ont trouvé un usage auquel personne n’avait pensé — et c’est celui-là qu’il faut faire circuler.

Une formation sans ce second temps est une dépense. Avec lui, c’est un investissement.

Ce qui change selon le public#

Pour les équipes non techniques, le danger n’est pas la lenteur, c’est la confiance. Une réponse fausse mais bien écrite est plus dangereuse qu’une réponse absente — parce qu’on la copie-colle. Et le second danger est ce qui part : un contrat client collé dans une interface gratuite, c’est une fuite, même si personne ne l’a vue.

Pour les développeurs, le piège est inverse. Ils vont vite, très vite. Le risque n’est pas qu’ils produisent moins, c’est qu’ils livrent du code qu’ils ne comprennent pas — et qu’ils devront maintenir pendant cinq ans. La formation ne consiste pas à leur apprendre à prompter. Elle consiste à leur réapprendre à lire.

Qui former en premier#

Pas tout le monde. Former tout le monde à la fois, c’est ne former personne.

Commencez par deux groupes :

• Ceux dont le métier contient beaucoup de texte répétitif : administratif, commercial, support, rédaction. Le gain y est immédiat et mesurable.
• Ceux qui sont déjà curieux. Ils existent dans toutes les équipes, ils bricolent déjà dans leur coin — souvent sans encadrement, d’ailleurs, ce qui est un sujet en soi.

Ces gens deviendront vos relais internes. C’est ainsi que ça se diffuse réellement dans une entreprise : par capillarité, entre collègues, pas par décret.

Comment savoir si ça a servi#

Pas au questionnaire de satisfaction. Il est toujours excellent, et il ne dit rien.

Regardez, un mois après :

• Est-ce que les gens s’en servent encore ?
• Sur quoi, exactement ?
• Est-ce que quelqu’un a trouvé un usage auquel personne n’avait pensé ?

Une seule tâche réellement transformée dans le quotidien vaut mieux que dix usages enthousiastes et abandonnés. C’est un critère décevant. C’est le bon.

Ce que ça dit de nous, au passage#

Nous formions déjà des développeurs bien avant ChallengeMyProject — c’était même notre métier d’origine, à l’époque où nous nous appelions UNE FORMATION.

Ce qui a changé, c’est le sujet. Ce qui n’a pas changé, c’est le constat : on n’apprend pas en regardant quelqu’un faire. On apprend en ratant, puis en recommençant, sur son propre travail, avec quelqu’un pour dire pourquoi ça a raté.

Aucune technologie n’a jamais démenti ça.

---

Nous formons les équipes techniques comme les équipes qui ne le sont pas — sur vos vrais dossiers, avec un retour quelques semaines plus tard. Parlons-en.