Le ticket est résolu. Mais qu’a appris celui qui l’a fermé ?
Les tests passent, le ticket est fermé. Reste une question que le tableau de bord ne pose pas : qu’a compris la personne qui a livré la correction ?
Prenons une scène de revue de code.
Un développeur présente une correction proposée par son assistant IA. Les tests passent. Le problème semble réglé. Un collègue pointe une ligne et lui demande pourquoi cette modification fonctionne.
Il peut répondre. Il peut aussi avoir besoin de chercher, de relire ou de tester un autre cas. À ce stade, on ne sait pas encore ce qu’il a compris.
Le ticket fermé ne nous le dit pas.
C’est cette question qui m’intéresse. Quand l’IA nous aide à produire, quelle place gardons-nous pour comprendre ce que nous venons de faire ?
Si vous encadrez une équipe, vous voyez facilement ce qui sort : une correction, une analyse, un document. L’apprentissage laisse moins de traces. Il se révèle parfois dans une explication, une objection ou une erreur que la personne sait désormais repérer.
La scène est illustrative. Elle pourrait concerner un débutant qui découvre le métier, mais aussi une personne expérimentée qui travaille sur un sujet nouveau.
Un résultat livré montre qu’un travail a abouti. Il ne suffit pas à établir ce que la personne saura expliquer ou refaire dans une autre situation.
L’IA peut justement aider à comprendre. On peut lui demander un exemple, comparer deux solutions, explorer un cas qui résiste. Elle peut aussi permettre d’accepter une réponse plausible et de passer rapidement à la suite.
La différence se joue dans ce qu’on fait de la réponse.
Lire une explication n’est pas toujours suffisant pour savoir l’utiliser. Pour le vérifier, on peut changer une contrainte, chercher un contre-exemple ou demander ce qui se passerait si une partie de la solution était retirée.
Et si la personne hésite, cette hésitation donne un point de départ à la discussion. Elle ne constitue pas un verdict sur sa compétence.
La question « Pourquoi ça fonctionne ? » devrait ouvrir une conversation, pas un procès.
Il faut aussi regarder ce que l’équipe encourage. Si nous demandons surtout de fermer les tickets rapidement, prenons-nous le temps d’écouter quelqu’un qui veut comprendre une réponse avant de la livrer ?
Prévoyons-nous un échange avec un collègue ? Une place pour essayer ? Ou attendons-nous que l’apprentissage se produise tout seul, entre deux urgences ?
Une étude présentée à CHI 2025 apporte un éclairage limité mais utile. Parmi 319 professionnels interrogés, une confiance plus élevée dans l’IA est associée à un effort critique déclaré plus faible. Ce sont des perceptions rapportées, pas une mesure de perte de compétences dans le temps. L’étude invite à examiner les usages ; elle ne permet pas de déclarer que l’IA rend les équipes moins compétentes.
Je garderais donc le mot « atrophie » comme une question à explorer, avec prudence. Ce qui m’intéresse sur le terrain serait de voir quelles occasions de raisonner l’organisation préserve, et lesquelles elle laisse disparaître.
Cela ne demande pas forcément une nouvelle méthode.
Sur un sujet choisi pour apprendre, on peut commencer par écrire une hypothèse avant de solliciter l’assistant. Sur une réponse déjà obtenue, on peut expliquer ce qu’on garde, ce qu’on écarte et ce qu’on veut vérifier. En revue, on peut examiner ensemble une limite de la solution.
Choisissez une correction et posez deux questions : « Qu’est-ce qui te convainc qu’elle fonctionne ? » puis « Dans quel cas pourrait-elle échouer ? » Cherchez la réponse ensemble si nécessaire.
Toutes les tâches n’ont pas besoin de devenir des exercices. Mais celles sur lesquelles on attend une progression méritent qu’on le dise, et qu’on lui accorde du temps.
Au prochain point d’équipe, à côté de ce qui a été livré, j’aimerais entendre aussi ceci : qu’est-ce que nous comprenons mieux qu’avant ?
