Faire adopter l'IA à une équipe de développeurs réticents

La demande arrive rarement dans ce sens-là. Elle arrive en « on a pris des licences, personne ne s’en sert ». Ou en « l’équipe dit que ça écrit du code qu’il faut relire deux fois, donc autant l’écrire soi-même ».

Les deux phrases disent la même chose : l’outil a été livré, pas introduit.

Ce qui ne marche pas

La démonstration. Montrer une fonctionnalité qui apparaît en trente secondes sur un projet jetable ne convainc personne dans une équipe qui maintient 90 000 lignes depuis six ans. L’écart entre le décor et le quotidien est précisément ce qui alimente le scepticisme : plus la démo est impressionnante, plus elle a l’air de ne pas parler du même métier.

La formation générique ne marche pas mieux. Deux jours de catalogue produisent des notes que personne ne relit, parce que rien de ce qui a été vu n’a été fait sur le dépôt de l’équipe, avec ses conventions et ses angles morts.

Ce qui a marché

Sur l’accompagnement dont je tire cette note, l’ordre a été inversé : l’installation d’abord, sur le vrai projet, avec l’équipe. Puis plusieurs besoins concrets réalisés ensemble - des besoins qui étaient de toute façon au backlog, pas des exercices.

Chaque geste a été expliqué au moment où il servait : ce qu’on donne à lire à l’outil et ce qu’on lui cache, comment on décrit une intention pour qu’elle ne soit pas réinterprétée, quand on s’arrête et qu’on écrit le code soi-même parce que c’est plus rapide. Ce dernier point compte plus que les autres. Une équipe croit un accompagnement qui lui dit où l’outil échoue.

Le résultat mesuré porte sur une fonctionnalité livrée deux fois plus vite que l’estimation initiale de l’équipe. Le résultat qui m’intéresse davantage est ailleurs : les craintes sont tombées, et l’envie de s’approprier l’outil est revenue. Une équipe qui expérimente seule après le départ du prestataire n’a plus besoin de lui - c’est le seul indicateur d’adoption qui ne se truque pas.

Pourquoi c’est facturé au forfait

Parce que le contraire serait absurde. Une mission d’adoption vendue en régie gagne de l’argent tant que l’équipe n’est pas autonome. Le modèle rémunère exactement ce qu’il faudrait éviter.

Au forfait, le périmètre est écrit avant de commencer - les sujets traités, le nombre de séances, ce qui reste à l’équipe à la fin. Mon intérêt et le vôtre pointent dans la même direction : que ça tienne sans moi.

Comment savoir si c’est votre cas

Trois signes, et un seul suffit :

• Les licences sont payées depuis plus de trois mois et l’usage réel tient dans deux ou trois développeurs déjà convaincus d’avance.
• L’équipe emploie l’outil pour des tâches sans enjeu - un test unitaire, un README - et jamais sur le cœur du produit.
• Personne n’a de réponse claire à « qu’est-ce qu’on ne lui donne jamais à lire ? ». C’est le signe que la question de la confidentialité n’a pas été tranchée, et donc que l’outil restera cantonné aux tâches sans enjeu.

Si vous vous reconnaissez, le sujet n’est pas technique. Il se règle en travaillant sur votre code, avec vos développeurs, sur des besoins que vous aviez déjà.