Il y a quelques jours, je discutais d’intelligence artificielle avec le Pr Viviane Ondoua Biwolé.
Au milieu de notre échange, elle m’a posé une question assez simple :
« Faut-il être bon dans son métier pour bien utiliser l’IA… ou peut-on utiliser l’IA pour devenir bon dans son métier ? »
La question m’est restée à l’esprit.
Elle m’est restée d’abord à cause de la personne qui me l’a posée. Le Pr Ondoua Biwolé est Professeure des Universités en sciences de gestion. Elle enseigne à l’Université de Yaoundé II depuis plus de vingt-cinq ans et dirige le Programme de Gestion de la Politique Économique. Son parcours mêle recherche, formation des cadres, conseil et responsabilités dans la haute administration.
Mais elle m’est surtout restée parce qu’elle paraît simple jusqu’au moment où l’on essaie réellement d’y répondre.
On pourrait répondre rapidement : les deux. Un bon professionnel utilisera probablement mieux l’IA parce qu’il comprend déjà son métier. Et quelqu’un de moins expérimenté peut certainement utiliser l’IA pour apprendre plus vite.
Cette réponse est probablement vraie. Mais elle ne suffit pas.
Car derrière cette question se cache un problème beaucoup plus profond : qu’est-ce qu’être compétent lorsque la machine peut produire une partie du travail à notre place ?
On associe souvent la compétence à la capacité d’obtenir de manière fiable un résultat attendu dans les contraintes de son métier. L’expertise ajoute quelque chose : une compréhension plus profonde, construite par l’expérience, qui permet notamment de reconnaître les situations inhabituelles, d’évaluer un résultat et d’adapter son jugement au contexte.
Peut-on produire le résultat d’un expert sans en être un soi-même ? Si un junior équipé d’une IA spécialisée obtient le même résultat qu’un senior, lequel des deux est réellement le plus compétent ?
Et si l’IA permet au junior d’éviter certaines difficultés par lesquelles le senior est passé pour construire son expertise, apprend-il plus vite… ou apprend-il moins ?
C’est cette série de questions que je veux explorer ici à travers trois métiers : le développeur, le manager et le dirigeant.
Ce choix n’est pas arbitraire. Le développeur produit directement une partie du résultat. Le manager obtient un résultat en coordonnant le travail d’autres personnes. Le dirigeant agit encore un niveau au-dessus : il choisit une direction, organise les ressources, arbitre et porte finalement la responsabilité du résultat collectif.
Trois métiers. Trois formes de compétence. Et peut-être trois manières différentes pour l’IA de déplacer la frontière de l’expertise.
Dans cet essai, nous allons mettre plus d’accent sur le métier de développeur et montrerons ensuite comment la même question se pose au manager et au dirigeant. Chacun de ces deux métiers mérite une Note à part entière.
Mais avant de regarder ce que l’IA change, il faut revenir à une question plus ancienne : comment devenait-on compétent avant elle ?
Avant l’IA, comment devenait-on compétent ?
Pendant longtemps, la réponse semblait presque évidente.
On apprenait. Puis on pratiquait.
On faisait, on se trompait, on recommençait. On rencontrait progressivement des situations différentes et, avec le temps, quelque chose changeait dans notre manière de regarder les problèmes.
Un développeur expérimenté ne voyait plus seulement des lignes de code. Il reconnaissait des structures, anticipait certains problèmes et se méfiait de solutions qui semblaient pourtant correctes. Un manager expérimenté pouvait parfois sentir qu’un conflit apparent cachait un autre problème. Un dirigeant ayant traversé plusieurs crises ne lisait plus certains signaux comme celui qui les rencontrait pour la première fois.
L’expérience ne nous donnait donc pas seulement davantage de réponses. Elle changeait les questions que nous étions capables de poser et les choses que nous étions capables de voir.
Cette intuition a été largement étudiée dans les travaux sur l’expertise. Le modèle de Dreyfus décrit par exemple une progression du novice vers l’expert : le novice dépend fortement de règles explicites, alors que l’expérience permet progressivement de lire une situation de manière plus contextualisée, de distinguer ce qui compte et de développer un jugement plus fin. Le modèle reste discuté et ne décrit pas parfaitement tous les métiers, mais son intuition est utile ici : avec l’expérience, nous ne faisons pas seulement plus vite ce que nous faisions déjà. Nous apprenons progressivement à reconnaître ce qui compte dans une situation.
Les travaux d’Anders Ericsson sur la pratique délibérée ont, de leur côté, insisté sur le rôle d’une pratique exigeante, répétée et accompagnée de feedback dans le développement de performances expertes. Là encore, le temps seul ne suffit pas. Accumuler vingt années d’ancienneté ne garantit pas vingt années de progression.
Pendant longtemps, production, apprentissage et expérience étaient fortement liés. Pour devenir bon, il fallait faire. Et en faisant, on rencontrait les problèmes qui nous obligeaient à comprendre.
L’IA modifie aujourd’hui cette relation. Elle peut produire une partie du résultat avant même que nous ayons acquis toute l’expérience autrefois nécessaire pour l’obtenir.
Elle peut alors jouer deux rôles très différents : accélérer l’apprentissage en expliquant, en donnant du feedback et en permettant d’explorer plusieurs solutions ; ou contourner certaines difficultés qui nous auraient obligés à approfondir notre compréhension.
Une situation observée chez SEED Innov récemment m’a permis de mesurer concrètement cette différence.
Un junior qui produit un résultat acceptable mais qu’il ne peut pas expliquer
Nous étions arrivés aux présentations des projets de fin de stage. Chaque stagiaire devait montrer ce qu’il avait réalisé et expliquer son travail.
L’un d’eux nous présente sa plateforme.
Franchement, au premier regard, le travail est réussi. L’interface est belle. Les pages sont propres. Les principales fonctionnalités semblent fonctionner.
La démonstration avance normalement. Puis il arrive sur une page où plusieurs éléments sont affichés sous forme de liste. Il y a un bouton « Ajouter ».
Il clique dessus. La liste descend légèrement et un formulaire apparaît au-dessus, dans l’espace qui vient de se libérer. Je regarde. Quelque chose me gêne. Je l’arrête.
— Pourquoi as-tu placé le formulaire ici ?
Il me répond assez naturellement qu’il trouve que c’est bien comme ça, puis essaie de poursuivre sa démonstration.
Je l’arrête encore.
— Non. Pourquoi ici ?
Je lui demande s’il avait prévu cette disposition lorsqu’il avait conçu sa page. Non. Alors pourquoi ne pas avoir placé le formulaire sous la liste ? Pourquoi pas dans une fenêtre qui s’ouvre au-dessus de la page ? Qu’est-ce qui avait conduit à ce choix précis ?
Il n’avait pas vraiment de réponse. Le positionnement du formulaire n’était pas grave en soi. Ce qui m’intéressait était ailleurs : il ne semblait pas y avoir de décision de conception derrière ce choix. Alors je lui pose une autre question :
— Qui a codé cette page ? Toi ou l’IA ?
Il me répond :
— Moi.
Je voulais comprendre jusqu’où il maîtrisait réellement son travail. Je lui ai donc posé une question volontairement provocatrice :
— Mais pourquoi écris-tu encore tout ton code toi-même en 2026 alors qu’il existe des outils capables d’en produire une grande partie correctement ? Pourquoi ne pas consacrer davantage de temps à bien concevoir ton produit, comprendre ce que tu veux obtenir, choisir la bonne position pour ton formulaire, puis utiliser l’IA pour t’aider à produire le code ?
Il m’explique qu’il est encore en deuxième année, qu’il veut apprendre à coder lui-même et qu’il utilise surtout l’IA pour résoudre certains bugs.
Et là, je trouve sa réponse plutôt saine. S’il écrit lui-même pour apprendre, très bien. Alors je lui propose quelque chose de simple.
— Arrête la présentation. Installe-toi à ton bureau. Enlève simplement le formulaire du haut et mets-le en dessous de la liste.
Il s’installe. Je reste à côté. Une heure passe. Puis un peu plus. Le formulaire n’a toujours pas bougé. Je le vois chercher. Ouvrir des fichiers. Essayer des choses. À un moment, je le vois même ouvrir un fichier directement depuis GitHub pour essayer d’y écrire du code.
Et progressivement, ce que je soupçonnais devient évident. Il ne comprenait pas réellement la structure du projet qu’il venait de nous présenter.
Le problème n’était donc pas qu’une IA avait généré son code. Je n’ai aucun problème avec ça. Le problème était beaucoup plus sérieux : il avait réussi à produire un système dont le niveau apparent était supérieur à son niveau réel de compréhension.
Et comme il venait de soutenir qu’il avait codé lui-même, il s’était retrouvé prisonnier de sa propre réponse. Il ne pouvait même plus simplement ouvrir son outil IA devant moi et lui demander de déplacer le formulaire.
Cette petite scène m’a beaucoup fait réfléchir.
Parce qu’elle pourrait se reproduire demain dans un contexte beaucoup moins anodin qu’un projet de stage. Imaginez un logiciel en production construit en grande partie avec l’aide d’une IA. Une panne survient au moment où l’outil devient indisponible, où l’abonnement expire ou l’entreprise en coupe l’accès pour une raison de sécurité.
Qui intervient ? Et surtout : qui comprend suffisamment le système pour intervenir ?
Le résultat n’est pas la compétence
La conclusion de cette histoire n’est surtout pas que les juniors ne doivent pas utiliser l’IA. Je pense même exactement l’inverse.
Refuser à un jeune développeur les outils avec lesquels il travaillera demain sous prétexte que nous avons appris autrement serait une étrange manière de le préparer à son métier.
Mais cette histoire révèle une distinction importante : le résultat n’est pas la compétence. Et la compétence n’est pas encore l’expertise.
Les premières recherches sur l’IA au travail montrent que les moins expérimentés peuvent bénéficier fortement de ces outils.
Dans une étude portant sur 5 179 agents de support client, Erik Brynjolfsson, Danielle Li et Lindsey Raymond ont observé une hausse moyenne de productivité de 14 % avec une assistance IA. Les gains atteignaient environ 34 % chez les travailleurs novices ou moins qualifiés, alors que l’effet était beaucoup plus faible chez les plus expérimentés. Les chercheurs trouvent également des indices suggérant que l’outil diffuse une partie des pratiques des meilleurs travailleurs vers les autres.
Une autre expérience, menée par Shakked Noy et Whitney Zhang auprès de 453 professionnels diplômés sur des tâches de rédaction, trouve elle aussi que ChatGPT permet d’aller plus vite et d’améliorer la qualité moyenne du travail, tout en réduisant les écarts entre participants.
Ces résultats nous obligent à prendre au sérieux une possibilité : dans certaines tâches, un junior équipé d’une bonne IA peut effectivement produire un résultat proche de celui d’un professionnel beaucoup plus expérimenté.
Mais mon stagiaire nous montre l’autre face du phénomène.
La performance peut progresser plus vite que la compréhension.
L’IA peut raccourcir le chemin entre junior et productif beaucoup plus vite qu’elle ne raccourcit le chemin entre junior et expert.
Il ne suffit donc plus de demander : « Quel résultat cette personne peut-elle produire avec l’IA ? » Il faut aussi demander : « Que comprend-elle réellement du résultat qu’elle vient de produire ? »
Le développement logiciel nous offre ici un recul utile. Les développeurs n’ont pas attendu l’intelligence artificielle pour déléguer une partie de leur travail aux machines.
Le développeur a toujours travaillé au-dessus de couches qu’il ne maîtrise pas entièrement
Le développement logiciel s’est toujours construit par couches d’abstraction. Des langages aux systèmes d’exploitation, puis aux bibliothèques et aux frameworks, chaque génération de développeurs a pu s’appuyer sur des outils qui masquaient une partie de la complexité du niveau inférieur.
Aujourd’hui, un développeur peut ainsi construire une application complexe sans savoir exactement quelles instructions son processeur exécute à chaque instant. Cela ne fait pas nécessairement de lui un mauvais développeur. L’abstraction lui permet de concentrer son attention sur d’autres problèmes.
Les agents IA peuvent être vus, en partie, comme une nouvelle étape de cette histoire. Mais le saut est particulier : l’outil ne masque plus seulement la complexité technique. Il peut proposer une architecture, écrire du code, tester, expliquer, corriger et parfois prendre en charge une tâche presque entière.
Les premières expériences montrent d’ailleurs que ce déplacement ne profite pas à tout le monde de la même manière. Des travaux menés auprès de développeurs chez Microsoft, Accenture et une entreprise Fortune 100 ont observé davantage de tâches accomplies avec un assistant de code, avec des gains plus marqués chez les moins expérimentés. À l’inverse, METR a observé un ralentissement moyen de 19 % chez des développeurs open source expérimentés travaillant sur des projets qu’ils connaissaient très bien. L’outil, la tâche et le niveau d’expérience comptent donc beaucoup.
La question n’est pas de savoir si le développeur doit continuer à écrire chaque ligne de code lui-même. Elle est de savoir ce qu’il doit encore comprendre pour pouvoir évaluer ce que la machine produit, le modifier et reprendre la main lorsqu’elle se trompe.
L’expertise ne disparaît pas lorsque l’exécution est automatisée. Elle se déplace.
Et ce déplacement n’est pas propre au développeur.
Ce que cela change déjà pour le manager
Le manager connaît depuis longtemps une situation que le développeur découvre aujourd’hui avec l’IA : il est responsable d’un résultat qu’il n’a pas entièrement produit lui-même.
L’arrivée de l’IA ajoute cependant quelque chose. Le manager peut désormais préparer une décision difficile, explorer plusieurs scénarios, tester une formulation ou examiner une situation sous différents angles avant d’agir. Mais ses collaborateurs disposent des mêmes outils. Ils peuvent eux aussi mieux s’informer, structurer leurs objections et confronter une décision à d’autres grilles de lecture.
Cela ne supprime ni la hiérarchie ni la responsabilité du manager. Cela rend simplement plus fragile une autorité qui reposerait surtout sur le fait de détenir davantage d’informations que les autres.
Sa valeur se trouve davantage dans sa capacité à lire le contexte, exercer son jugement, expliquer un arbitrage, créer de la confiance et faire progresser son équipe.
Il reste aussi une limite importante. Simuler dix conversations difficiles avec une IA n’est pas la même chose que vivre la dixième. Dans la situation réelle, il y a la peur, l’ego, le silence, le rapport de force, l’histoire entre les personnes et les conséquences de ce qui sera dit. L’IA peut préparer l’expérience. Elle ne la remplace pas entièrement.
Cette question du manager augmenté mérite d’être traitée pour elle-même. J’y consacrerai une Note. Retenons seulement ceci ici : l’IA peut permettre à un manager peu expérimenté de mobiliser plus tôt certains raisonnements associés à l’expérience, sans lui donner automatiquement l’expérience qui permet de savoir quand ces raisonnements ne s’appliquent plus.
Et pour le dirigeant ?
Le dirigeant travaille encore à un autre niveau. Il n’est pas principalement attendu sur la production d’un document ou d’une analyse. Il est attendu sur sa capacité à choisir une direction, mobiliser les ressources nécessaires et conduire l’organisation vers les résultats recherchés.
L’IA peut aujourd’hui lire des centaines de pages, comparer des scénarios, préparer une négociation, rechercher des contradictions dans une stratégie, synthétiser des rapports ou construire une première analyse financière. Ce sont des capacités considérables.
Mais obtenir une analyse n’est pas savoir décider.
Une expérience menée avec Boston Consulting Group auprès de 758 consultants l’illustre bien. Sur des tâches situées à l’intérieur de ce que les chercheurs appellent la « frontière technologique irrégulière » de l’IA, les participants utilisant GPT-4 accomplissaient davantage de tâches, plus rapidement et avec une qualité supérieure. Mais sur une tâche située en dehors de cette frontière, l’usage de l’IA pouvait au contraire conduire davantage de participants vers une mauvaise réponse.
Pour un dirigeant, le sujet n’est donc pas seulement de savoir utiliser l’IA. Il faut savoir quoi lui déléguer, jusqu’où lui faire confiance, comment vérifier et quand reprendre la main.
C’est aussi là qu’apparaît une autre question que je veux approfondir ailleurs : que se passe-t-il lorsqu’un dirigeant finit par ne plus oser décider sans consulter la machine ? L’IA peut augmenter le jugement. Elle peut aussi, si nous n’y prenons pas garde, devenir une béquille dont nous ne savons plus nous passer.
Je consacrerai également une Note à cette question du dirigeant. Pour l’instant, je garde une chaîne simple :
Dirigeant → Décision → Organisation → Résultat.
Si l’IA améliore les analyses mais pas les décisions, ou les décisions mais pas la capacité de l’organisation à agir, l’augmentation reste incomplète.
Alors, qu’est-ce qu’un expert à l’ère de l’IA ?
Nous pouvons maintenant revenir à la question de départ.
Pendant longtemps, nous avons fortement associé expertise et capacité à produire. Cette relation ne disparaît pas. Mais elle devient moins simple, parce que quelqu’un peut désormais produire au-dessus de son niveau réel de compréhension.
Je trouve utile de distinguer quatre capacités qui étaient autrefois beaucoup plus difficiles à séparer.
Produire : obtenir un résultat.
Comprendre : savoir suffisamment comment ce résultat a été obtenu et sur quoi il repose.
Évaluer : reconnaître sa qualité, ses limites, ses erreurs et les situations dans lesquelles il ne convient plus.
Arbitrer : décider si ce résultat doit réellement être utilisé dans cette situation et accepter d’en répondre.
Produire. Comprendre. Évaluer. Arbitrer.
L’IA progresse très vite sur la première capacité. Elle peut aussi nous aider sur les suivantes. Mais plus les conséquences d’une décision deviennent importantes, plus le contexte, le jugement et la responsabilité comptent.
Je ne crois donc pas que l’expert de demain sera simplement celui qui sait tout faire sans IA. Ce serait confondre expertise et fidélité aux outils d’hier.
Mais il ne suffira pas non plus de savoir obtenir un bon résultat avec elle.
Peut-être que l’expert de demain sera celui qui sait ce qu’il peut déléguer, qui comprend suffisamment ce qu’on lui restitue pour en juger la qualité, qui sait quand reprendre la main et qui assume la décision finale d’utiliser le résultat.
Cette définition reste une proposition. Mais elle nous protège contre une confusion que l’IA rend de plus en plus facile : prendre la qualité du livrable pour la qualité de celui qui le présente.
Le paradoxe de l’apprentissage
Il reste pourtant un problème.
L’IA peut accélérer l’apprentissage. Un junior peut demander une explication immédiatement, obtenir du feedback, explorer plusieurs solutions, simuler une situation ou comparer son raisonnement avec celui d’un système plus capable.
Mais elle peut aussi supprimer certaines difficultés qui nous permettaient justement de devenir bons.
Ce problème n’est pas entièrement nouveau. En 1983, la psychologue Lisanne Bainbridge décrivait déjà dans Ironies of Automation un paradoxe devenu classique : plus certaines tâches sont automatisées, moins l’humain les pratique. Pourtant, lorsque le système rencontre une situation anormale, c’est souvent à cet humain que l’on demande de reprendre la main. Or certaines compétences nécessaires pour intervenir se construisent et se maintiennent par la pratique.
Quarante ans plus tard, mon stagiaire se retrouvait devant une version moderne de cette ironie. Son produit fonctionnait. Jusqu’au moment où il devait intervenir lui-même sur ce qu’il présentait.
La réponse ne peut donc être ni d’interdire l’IA aux apprenants, ni de les laisser déléguer tout ce qui les met en difficulté.
Chaque métier devra trouver ce qu’un professionnel doit encore savoir faire, comprendre et vérifier pour rester compétent lorsqu’il travaille avec l’IA.
Alors, faut-il être bon dans son métier pour bien utiliser l’IA ?
Oui. L’expérience aide à mieux juger, contextualiser et contrôler ce que produit la machine.
Peut-on utiliser l’IA pour devenir bon dans son métier ? Oui également. Elle peut donner accès plus tôt à certaines pratiques, fournir du feedback et accélérer certaines formes d’apprentissage.
Le risque apparaît lorsque la capacité à produire progresse plus vite que la compréhension. Nous pouvons alors obtenir des professionnels capables de réaliser beaucoup de choses avec l’IA, mais en difficulté lorsqu’il faut expliquer, diagnostiquer, corriger ou reprendre la main.
À l’inverse, refuser ces outils parce que les générations précédentes ont appris autrement reviendrait à préparer des professionnels à des pratiques qui sont déjà en train de changer.
Il faut donc apprendre à travailler avec l’IA sans confondre ce qu’elle nous permet de produire avec ce que nous savons réellement faire.
C’est pourquoi je reviens aux quatre capacités proposées plus haut :
Produire. Comprendre. Évaluer. Arbitrer.
L’IA peut intervenir dans chacune d’elles. Mais le professionnel reste responsable de ce qu’il choisit de déléguer, de ce qu’il accepte comme suffisamment fiable et des conséquences de son utilisation.
Ma réponse à la question de départ est donc moins binaire qu’elle ne le paraissait. Oui, l’expertise aide à mieux utiliser l’IA. Oui, l’IA peut aider à construire plus vite certaines compétences. Mais devenir productif plus vite ne signifie pas nécessairement devenir expert plus vite.
Peut-être est-ce là le véritable déplacement : l’expertise ne se mesure plus seulement à ce que nous sommes capables de produire nous-mêmes, mais aussi à notre capacité à comprendre suffisamment ce qui est produit, à en évaluer la qualité et à arbitrer son utilisation.
Que le résultat ait été produit par nous, par une équipe ou avec l’aide d’une IA, quelqu’un devra toujours décider qu’il est suffisamment fiable pour être utilisé — et accepter d’en répondre.
Une dernière chose…
Cet essai a été écrit avec l’assistance de l’intelligence artificielle : recherche, vérification des sources, relecture. La question, les expériences, les choix et les conclusions que je défends ici sont les miens — et je les assume.
C’est aussi une manière de mettre cette Note à l’épreuve de sa propre thèse. Si je ne peux pas expliquer une idée que je publie, défendre les choix qui la soutiennent ou reconnaître ses limites, alors le fait qu’une IA m’ait aidé à bien la formuler ne change rien au problème.
Références de travail
- Erik Brynjolfsson, Danielle Li & Lindsey R. Raymond — Generative AI at Work, NBER Working Paper 31161.
- Shakked Noy & Whitney Zhang — Experimental Evidence on the Productivity Effects of Generative Artificial Intelligence, Science, 2023.
- K. Anders Ericsson, Ralf Krampe & Clemens Tesch-Römer — The Role of Deliberate Practice in the Acquisition of Expert Performance, Psychological Review, 1993.
- Hubert & Stuart Dreyfus — travaux sur l’acquisition des compétences et la progression du novice vers l’expert.
- Lisanne Bainbridge — Ironies of Automation, Automatica, 1983.
- Fabrizio Dell’Acqua et al. — Navigating the Jagged Technological Frontier / expérimentation BCG sur le travail de connaissance assisté par GPT-4.
- Zheyuan Cui et al. — The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers.
- METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.