Le 11 novembre 2026, Gartner a publié quatre tendances concernant la gestion des talents. La première mérite l’attention des directions IT : l’automatisation des tâches courantes peut rendre moins accessibles les parcours par lesquels les juniors accèdent à des responsabilités plus complexes. Le cabinet recommande notamment de renforcer leur accès aux personnes expérimentées et à l’accompagnement.

C’est une alerte d’analystes. Le communiqué ne fournit pas de mesure des recrutements ou de l’apprentissage dans les ETI françaises. Il ouvre cependant une question très concrète pour un DG ou un DAF : si certaines tâches disparaissent, où les collaborateurs apprendront-ils à comprendre ce qu’ils devront ensuite superviser ?

La compétence attendue change

L’IA ne va pas seulement automatiser certaines tâches. Elle va changer la définition même d’un bon profil.

Pendant longtemps, les entreprises ont surtout recherché des experts capables d’exécuter une activité avec précision. Demain, elles auront aussi besoin de personnes capables de :

  • comprendre un processus dans son ensemble ;
  • identifier les tâches que l’IA peut réellement améliorer ;
  • évaluer la qualité d’une réponse produite par une machine ;
  • combiner plusieurs outils ou agents ;
  • arbitrer lorsque l’automatisation atteint ses limites.

La valeur ne sera plus uniquement dans la maîtrise d’une expertise. Elle sera aussi dans la capacité à orchestrer l’expertise humaine et les capacités de l’IA.

Ces phrases du post du 29 octobre décrivent une évolution des profils. L’alerte de Gartner invite à examiner le chemin qui permet d’acquérir ces capacités.

Savoir demander une proposition de correction à un assistant ne suffit pas à expliquer pourquoi elle fonctionne. Et expliquer une correction sur un cas connu ne suffit pas toujours à reconnaître une erreur dans un cas légèrement différent. Pour la direction, ces écarts comptent lorsqu’elle confie à une personne la vérification d’un travail produit avec l’IA.

Produire et comprendre peuvent évoluer différemment

Une recherche publiée par Anthropic le 29 janvier 2026 apporte un éclairage antérieur à l’annonce. Elle porte sur 52 développeurs découvrant Trio, une bibliothèque Python. Dans cet essai randomisé, le groupe disposant d’un assistant IA a obtenu en moyenne 50 % au questionnaire de compréhension, contre 67 % pour le groupe sans assistant. L’écart moyen de temps de réalisation n’était pas statistiquement significatif.

L’étude distingue aussi plusieurs façons d’utiliser l’outil. Demander des explications et travailler sa compréhension était associé à de meilleurs résultats que déléguer l’ensemble du travail. Cette comparaison des usages ne démontre toutefois pas une relation causale.

Le tableau des participants du papier de recherche décrit des expériences de programmation variées : il ne s’agit pas d’un groupe homogène de débutants. L’échantillon est petit, la tâche circonscrite et la compréhension mesurée juste après l’exercice. Ces résultats ne permettent pas de conclure à une perte durable de compétences, ni de fixer une politique générale pour tous les métiers de la DSI. Ils justifient de regarder séparément ce qui a été produit et ce que la personne sait expliquer.

Cela concerne les développeurs, bien sûr. Mais aussi les managers, les responsables opérationnels, les fonctions support et tous ceux qui conçoivent le travail quotidien.

Cette seconde observation du post du 29 octobre élargit la question d’organisation. Elle n’étend pas les résultats de l’étude à ces autres métiers.

Une tâche livrée, un diagnostic expliqué

Voici un essai à discuter avec le DSI et le responsable d’équipe. Il s’agit d’une proposition de travail, pas d’une méthode déjà éprouvée chez un client.

Prenons une situation illustrative : un développeur junior doit adapter un petit traitement d’import de données dans un environnement de test. L’assistant peut proposer du code et des explications. Un développeur expérimenté reste disponible pour discuter les choix. Les données et les outils utilisés doivent être autorisés par l’entreprise.

Avant de commencer, le responsable précise deux résultats attendus : un traitement qui passe les vérifications prévues et une explication compréhensible de son fonctionnement. Le junior doit pouvoir montrer ce qui se passe lorsque le fichier reçu est incomplet, comment il repère l’erreur et dans quel cas il demande de l’aide.

Après la livraison, le responsable introduit une variation simple du cas. L’échange porte sur le raisonnement : quel indice regarder en premier, quelle hypothèse vérifier, quel résultat conduirait à changer d’avis ? Pour distinguer l’explication personnelle de la réponse de l’outil, une courte séquence peut se faire sans solliciter l’assistant, dans ce cadre de formation annoncé à l’avance.

Dans une intervention de Modern Software Engineering, Daniel Terhorst-North insiste sur le travail en binôme, les retours concrets et la possibilité d’expérimenter sans conséquence grave. Il parle de sa pratique d’accompagnement de développeurs. Ce témoignage éclaire l’organisation de l’essai ; il n’en prouve pas l’efficacité et ne constitue pas une nouvelle étude.

Le responsable pourra alors distinguer trois situations :

  • Le résultat est correct et la personne sait expliquer son diagnostic : essayer un cas un peu plus difficile, avec un accompagnement adapté.
  • Le résultat est correct mais le raisonnement reste opaque : reprendre l’explication et les essais avant d’élargir la responsabilité.
  • Le résultat est incorrect : examiner ensemble l’erreur, sa détection et la manière de la corriger, sans confondre apprentissage et faute professionnelle.

L’essai ne doit pas devenir un classement des personnes sur un exercice isolé. Son intérêt est d’identifier le prochain apprentissage et le soutien nécessaire.

Donner du temps à ceux qui accompagnent

Pourtant, une question me semble encore largement sous-estimée : Quel est le gain économique réel ?

Ces deux phrases ouvrent un passage du post du 22 juillet sur le coût du développement logiciel. Elles restent pertinentes lorsqu’on chiffre un essai : le temps du junior, celui de la personne qui accompagne et celui des corrections font partie du travail mobilisé.

Dans ce même post :

Mais au fond, la vraie question n’est peut-être pas de savoir si l’IA permet de coder plus vite. La vraie question est de savoir si elle permet de créer davantage de valeur pour un coût total inférieur.

Pour le DAF, un premier suivi peut donc réunir le temps total consacré au cas, la qualité du résultat et le besoin d’aide sur la variation proposée. Ce suivi ne chiffre pas encore un retour sur investissement. Il permet de repérer une économie de production qui serait absorbée par la correction ou par une supervision devenue permanente.

Pour le DG, l’arbitrage porte aussi sur la disponibilité des personnes expérimentées. Si tout leur temps est affecté aux urgences, l’accompagnement annoncé n’aura pas de place dans le travail réel. Un essai limité permet de réserver cette disponibilité avant de promettre une généralisation.

La méthode d’accompagnement X-PM part du contexte et des responsabilités à tenir. Ici, le mandat confié au DSI peut préciser les compétences à développer, les personnes capables d’accompagner et les éléments qui permettront de décider d’une extension.

Garder la question ouverte

Quelques questions me viennent cependant :

  • Peut-on réellement identifier à l’avance qui ne saura pas évoluer ?
  • La formation suffit-elle, ou faut-il surtout apprendre à désapprendre ?

Ces questions figuraient dans le post du 29 septembre 2025 sur Accenture et la formation à l’IA. Elles gardent leur portée sans reprendre ici les chiffres ni les décisions de cette entreprise.

Nous ne savons pas encore quels usages favoriseront durablement l’apprentissage dans chaque équipe. Les outils changent, les tâches diffèrent et l’expérience acquise avant leur adoption compte. C’est une raison pour observer des situations réelles, comparer plusieurs essais et ajuster l’accompagnement.

Et vous, comment préparez-vous vos équipes à franchir ce cap ?

Sources et lectures