Situation réelle

Un CTO organise une journée de formation IA pour son équipe de quinze développeurs. Présentation des LLM, fonctionnement des transformers, comparatif des modèles, atelier prompt engineering. L’équipe écoute poliment. Le lendemain, chacun retourne à ses habitudes. Deux mois plus tard, trois développeurs utilisent l’IA régulièrement — les mêmes qui l’utilisaient déjà avant la formation.

Ce que j’ai observé : la formation théorique sur l’IA ne produit presque aucun changement de pratique. Ce qui change les pratiques, c’est l’expérimentation encadrée dans le contexte réel de travail.

Le faux problème

La question habituelle : « Quelle formation IA recommandes-tu pour les développeurs ? »

En réalité, les développeurs n’ont pas besoin de comprendre les transformers pour utiliser l’IA efficacement. Ils ont besoin de savoir comment l’IA peut les aider dans leur travail quotidien — et ça ne s’apprend pas dans un cours. Ça s’apprend en pratiquant, sur de vrais sujets, avec du feedback.

Le vrai enjeu CTO

Le vrai enjeu est de créer un environnement propice à l’adoption, pas de délivrer une formation. L’adoption de l’IA est un changement de pratique, pas un transfert de connaissance.

Les trois niveaux de maturité

Niveau 1 : Découverte. Les développeurs savent que l’IA existe mais ne l’utilisent pas ou peu. L’objectif est de dédramatiser et de montrer des usages concrets.

Niveau 2 : Expérimentation. Les développeurs testent l’IA sur des tâches ciblées. L’objectif est de créer des habitudes et de partager les retours d’expérience.

Niveau 3 : Intégration. L’IA fait partie du workflow naturel. L’objectif est d’optimiser les usages, de mesurer l’impact et de faire évoluer les pratiques.

Cadre de décision

  1. Commencer par les quick wins. Identifier les trois tâches les plus chronophages et les moins stimulantes de l’équipe. Montrer comment l’IA peut aider sur ces tâches précises. Un gain visible sur une tâche concrète vaut plus qu’un cours de deux heures.

  2. Créer des binômes explorateurs. Associer un développeur curieux de l’IA avec un développeur sceptique. Le binôme travaille ensemble sur un sujet réel pendant une semaine. Le sceptique n’est pas converti par un cours — il est convaincu par l’expérience d’un pair.

  3. Instaurer un rituel de partage. Une session de 30 minutes toutes les deux semaines où chacun partage un usage qui a marché — ou qui n’a pas marché. L’apprentissage collectif est plus puissant que la formation individuelle.

  4. Fournir un cadre, pas un programme. Pas besoin de curriculum structuré. Un document d’une page : outils approuvés, zones d’usage, exemples de prompts testés par l’équipe. Le reste s’apprend en faisant.

  5. Mesurer l’adoption, pas la satisfaction. La question n’est pas « la formation vous a-t-elle plu ? » mais « utilisez-vous l’IA trois mois plus tard ? ». L’adoption réelle est le seul indicateur qui compte.

Retour terrain

Ce que j’ai constaté dans les équipes qui ont réussi leur montée en compétence IA :

  • Elles n’ont pas fait de « grand lancement ». Elles ont commencé petit : un outil, un usage, un binôme.
  • Elles ont un channel Slack/Teams dédié au partage de prompts et d’astuces. Le canal est vivant parce que l’usage est réel, pas parce qu’un manager l’alimente.
  • Elles ont des « champions IA » informels — des développeurs qui ont trouvé des usages pertinents et qui les partagent naturellement.
  • Elles acceptent que 100 % de l’équipe n’utilise pas l’IA. Certains développeurs sont plus productifs sans, et c’est respecté.

Erreurs fréquentes

  • Organiser une formation magistrale. Le format cours/présentation ne fonctionne pas pour un changement de pratique. L’atelier pratique sur un cas réel, si.
  • Forcer l’adoption. Imposer l’utilisation de l’IA crée du rejet. Proposer, montrer, laisser expérimenter — l’adoption vient par la preuve, pas par l’injonction.
  • Ne former que les volontaires. Les volontaires n’ont pas besoin de formation — ils expérimentent déjà. L’enjeu est d’embarquer les indécis, pas de prêcher les convaincus.
  • Mesurer trop tôt. Trois semaines après le lancement, les métriques ne disent rien. Mesurer à trois mois, pas avant.

Si c’était à refaire

  • Je commencerais par demander à l’équipe : « Quelle tâche détestez-vous le plus ? » Puis je montrerais comment l’IA peut aider sur cette tâche précise. L’adoption commence par la douleur résolue.
  • Je nommerais un « facilitateur IA » dans l’équipe — pas un expert, mais quelqu’un de curieux et de pédagogue qui accompagne les premiers pas des autres.
  • Je budgétiserais du temps dédié à l’expérimentation : deux heures par semaine, protégées, pour tester de nouveaux usages. Sans temps alloué, l’expérimentation n’a pas lieu.

Pour approfondir