Il y a quelques semaines, j’ai terminé en une après-midi un projet que j’avais estimé à trois jours. Code propre, tests verts, déploiement sans accroc. J’aurais dû être content. À la place, un mélange bizarre : de l’excitation, oui — et en dessous, un malaise que je n’arrivais pas à nommer.
Ce malaise, beaucoup de développeurs le connaissent sans oser en parler. On est censés se réjouir. Les outils d’IA nous rendent plus productifs, on livre plus vite, on peut enfin se concentrer sur « ce qui compte vraiment ». Mais quelque chose gratte.
Et ce n’est pas réservé aux développeurs. Le chauffeur de taxi qui avait chaque rue de sa ville en tête regarde le GPS rendre cette mémoire superflue. Le traducteur qui a passé vingt ans à affiner son oreille voit la machine l’égaler sur le tout-venant — parfois le dépasser. L’illustrateur qui a construit son style trait par trait découvre qu’un modèle produit en secondes ce qui lui prenait des jours. Partout, la même question, avec la même charge. Je pars du développeur parce que c’est ce que je suis. Mais la question est universelle : si créer devient facile, qu’advient-il de celui qui crée ?
Le centre de gravité a bougé
Le constat, d’abord. On ne code plus de la même manière. Là où je passais mes heures à implémenter, débugger, refactorer — la plomberie —, je passe maintenant l’essentiel de mon temps à formuler. Les besoins. Les contraintes. L’expérience utilisateur. Les tests qui vérifieront que le résultat colle à l’intention. La valeur a glissé du comment vers le quoi et le pourquoi. Pour un métier qui s’est construit pendant des décennies sur la maîtrise du comment, ce n’est pas un ajustement. C’est un basculement.
Il reste du travail d’architecte, bien sûr — structurer un projet, anticiper son évolution, penser les interfaces entre systèmes. Mais pour combien de temps ? La question est sincère, pas rhétorique. Je ne connais pas la réponse.
Ce basculement a un précédent célèbre. 1997 : Deep Blue, l’ordinateur d’IBM, bat Garry Kasparov aux échecs. Le monde y voit la fin de la suprématie humaine sur le jeu. Ce qui suit est plus intéressant que la défaite. Kasparov invente le centaure : un humain et une machine qui jouent ensemble. Pendant des années, ces duos battent tout le monde — les humains seuls et les machines seules. Le développeur augmenté par l’IA est un centaure. Sa valeur n’est plus dans le calcul brut, la machine fait ça mieux. Elle est dans l’intention, la direction, le jugement.
Mais l’histoire des échecs porte aussi un avertissement. Depuis, les centaures ont été dépassés par les machines seules. Le duo humain-machine était une phase, pas un équilibre. Alors : le centaure développeur-IA est-il lui aussi une étape de transition ? Ou bien le logiciel — ancré dans des besoins humains, de l’ambiguïté, du contexte — offre-t-il un terrain où le centaure peut durer ? Garde la question en tête. On y revient à la fin.
On a besoin de l'expert humain précisément là où on l'a empêché de s'entraîner.L'ironie de l'automatisation
La difficulté ne disparaît pas, elle déménage
Cette transformation, si on y regarde, n’a rien d’inédit. L’histoire de l’informatique est une succession d’abstractions. Cartes perforées, assembleur, C, Python. À chaque palier, les gardiens du temple ont crié à la trivialisation. L’assembleur, c’est du vrai code. Le C, c’est pour ceux qui ne comprennent pas la machine. Python, un jouet. Et à chaque palier, la difficulté n’a pas disparu — elle a déménagé. On a cessé de se battre avec les registres pour se battre avec les algorithmes. Cessé de gérer la mémoire à la main pour affronter la concurrence et le design distribué.
Sors de l’informatique, même schéma. L’imprimerie n’a pas tué l’écriture. Elle a tué le copiste — et fait naître l’auteur. La photographie n’a pas tué la peinture : en rendant la reproduction fidèle moins nécessaire, elle a poussé la peinture vers ce que seul un humain pouvait exprimer. La réalité est plus enchevêtrée, comme toujours — l’impressionnisme doit autant au tube de peinture portable qu’à l’appareil photo. Mais le motif tient : chaque révolution technique élimine une difficulté et en révèle d’autres, souvent plus intéressantes. La question devient alors : quels problèmes ne pouvions-nous même pas aborder quand on était occupés à écrire du boilerplate ?
Sauf qu’il y a peut-être une différence de nature, cette fois. Quand on passait de l’assembleur au C, on écrivait encore du code. On débuggait, on se battait avec un langage. La friction changeait de forme, elle restait. Le développeur C ne gérait plus les registres, mais il pensait la mémoire. Le développeur Python ne pensait plus la mémoire, mais la concurrence. À chaque étage, un nouveau terrain de résistance remplaçait l’ancien. Avec l’IA, on peut passer directement de l’intention au résultat. Sans étage intermédiaire. Sans résistance. Or cette résistance, c’était le terrain d’entraînement de l’expertise. Abstraction de plus ou rupture ? Je ne tranche pas. Mais la réponse change tout.
L'IA est le digital native absolu — toute sa connaissance vient du texte, aucune de la friction.Le miroir retourné
La mémoire du geste
J’ai 56 ans. J’ai fait mes études avant Internet ; à l’université, le web balbutiait. Et je constate un truc que je ne peux pas ignorer : cette formation « à l’ancienne » me sert de filet. J’utilise le GPS, évidemment — pratique pour aller là où je ne connais pas. Mais s’il me propose une ville en Roumanie au lieu d’une ville en France, je le vois tout de suite. Je ne suis pas la flèche sans réfléchir. Parce que j’ai navigué avant le GPS. J’ai une carte mentale du monde réel, et elle vérifie ce que l’outil raconte.
Ce n’est pas de la nostalgie. C’est un fait structurel : avoir connu le monde sans l’outil donne un point de comparaison. On sait distinguer ce que l’outil apporte de ce dont il faut se méfier. Les digital natives n’ont pas cette carte — pas parce qu’ils seraient moins capables, mais parce qu’ils n’ont jamais eu à la construire.
Ce type de savoir a un nom : la connaissance tacite. « We know more than we can tell » — on sait plus que ce qu’on peut dire, écrivait le philosophe Michael Polanyi. Un savoir qui guide nos actions mais échappe au langage. Il ne s’apprend pas dans un livre. Il se construit dans la friction, la répétition, l’erreur. Le développeur qui a débuggé des fuites mémoire à la main, qui a écrit un parser ligne à ligne, sait des choses qu’il ne peut pas formuler. Répare une moto : le moteur ne ment pas. Il tourne ou il ne tourne pas. C’est ce contact avec une matière qui résiste qui fabrique le jugement. L’IA, en rendant l’implémentation fluide, presque instantanée, supprime la résistance — et le terrain où le jugement se construit.
Nuance nécessaire, parce que toute friction n’est pas formatrice. Une bonne part de la difficulté du métier était de la friction accidentelle : doc pourrie, tooling cassé, erreurs de config absurdes. Celle-là ne construisait rien, elle faisait perdre du temps. La friction essentielle, c’est autre chose : la résistance propre du matériau. L’IA qui supprime la première nous rend service. L’IA qui supprime la seconde nous prive d’une école.
Démocratiser la production, ce n'est pas démocratiser le pouvoir.Ce qui devient rare
L’ironie de l’automatisation
Si l’expertise se construit dans la friction et que l’IA supprime la friction, comment se construira l’expertise de demain ?
Le problème est documenté depuis longtemps. En 1983, l’ingénieure Lisanne Bainbridge décrit ce qu’elle appelle l’ironie de l’automatisation. Plus un système est automatisé, moins l’opérateur pratique. Moins il pratique, plus sa compétence s’érode. Plus elle s’érode, plus c’est grave quand il doit intervenir. Et c’est précisément dans ces moments-là qu’on a besoin de lui — quand l’automatisation échoue, quand le cas n’était pas prévu.
Transpose au développement. Si l’IA écrit 90 % du code et que le développeur n’intervient que sur le reste — les cas limites, les bugs subtils, les décisions d’architecture critiques —, il doit maintenir une compétence de pointe sur ce qu’il ne pratique presque plus. On a besoin de l’expert humain précisément là où on l’a empêché de s’entraîner.
Et l’expertise coûte cher à fabriquer. Des milliers d’heures de pratique délibérée séparent le novice — qui applique des règles — de l’expert, qui voit la situation et sent la réponse sans passer par les règles. Si l’IA absorbe les tâches concrètes qui constituaient ce terrain d’entraînement, on risque de produire des compétents perpétuels : corrects sur les règles, jamais l’intuition.
Concession, avant d’aller plus loin. Chaque métier a un plancher d’abstraction sous lequel on fait confiance à d’autres. L’ingénieur civil ne taille pas la pierre. Le chirurgien ne forge pas ses instruments. Peut-être que l’IA n’est qu’un nouveau plancher, et que tout ceci est un faux problème. Peut-être. Mais Bainbridge suggère que ce plancher a un coût invisible — un coût qui n’apparaît qu’en crise, quand l’automatisation lâche et que personne n’a gardé les compétences pour prendre le relais.
Le miroir retourné
Jusqu’ici, j’ai appliqué cette grille — la friction, le tacite, le jugement — aux humains. Retourne-la vers l’IA. Le résultat est plus vertigineux que je ne l’anticipais.
Un LLM — le grand modèle de langage qui alimente ces outils — est entraîné sur du texte. Du texte, rien d’autre. Tout ce que l’humanité a réussi à mettre en mots, il l’a ingéré. C’est énorme. Mais Polanyi nous a prévenus : on sait plus que ce qu’on peut dire. La dimension tacite — celle qui ne se formule pas — échappe au modèle par construction. Il n’a jamais senti une vis qui grippe, jamais diagnostiqué un bruit suspect à l’oreille, jamais regardé un système s’effondrer à trois heures du matin. L’IA est le digital native absolu : toute sa connaissance vient du texte, aucune de la friction.
Yann LeCun, un des pionniers du domaine, le dit à sa façon : en compréhension du monde, un LLM fait moins bien qu’un chat domestique. Le chat sait que les objets tombent et que le feu brûle — pas parce qu’on le lui a dit, parce qu’il l’a vécu. Le modèle le « sait » comme une phrase statistiquement probable parmi d’autres. Il sait que les objets tombent. Il ne sait pas comment c’est, de les voir tomber. Il peut écrire un essai impeccable sur la mécanique moto. Il n’a jamais touché un moteur.
Maintenant, aligne les pièces. Ceux qui ont été formés par la friction détiennent un savoir tacite que l’outil ne remplace pas. Les suivants ne le construisent plus — leurs outils ont supprimé la friction qui le fabriquait. Et l’outil censé compenser cette perte ne le possède pas non plus. Il ne l’a jamais eu, par construction. Le filet de sécurité n’a pas de filet de sécurité.
Concret ? Combien de fois ai-je flairé un problème avant de le comprendre — un pattern de concurrence louche, une architecture qui sent le couplage, un choix de design qui va exploser dans six mois ? Pas parce qu’une règle le disait. Parce que j’ai déjà vécu l’échec qui en résulte. Cette intuition, je ne peux pas la mettre dans un prompt. Et le modèle qui génère le code ne l’a pas non plus.
Il serait malhonnête de s’arrêter là. Dans son domaine — le texte, le code, la synthèse, le savoir que —, le LLM est remarquable. L’outil qui a comprimé mon projet de trois jours en une après-midi faisait de l’excellent travail, je ne vais pas prétendre le contraire. Mais reconnaître son angle mort, c’est reconnaître que la connaissance née de la friction reste un territoire humain. Et c’est peut-être la meilleure raison de la préserver : pas par nostalgie — parce qu’elle est le dernier recours quand l’automatisation échoue et que le texte ne suffit plus. Les futures IA incarnées, avec des capteurs et un corps dans le monde, combleront-elles ce fossé ? Question ouverte. Je la laisse ouverte.
Le sens change de place aussi
Reste le plus intime. Pas ce que l’IA ne peut pas faire — ce que sa présence fait à celui qui l’utilise.
Ce malaise de l’après-midi trop courte, j’ai fini par le relier au flow : cet état de concentration totale où le temps disparaît, que les psychologues décrivent comme un équilibre entre le défi et la compétence. Trop de défi, l’anxiété. Pas assez, l’ennui. Le développement était une source fiable de flow — le bug retors, l’algorithme élégant, le système distribué qui tient. Si l’IA comprime la difficulté technique, elle attaque directement cette source. Et avec elle, une bonne part de ce qui rendait le métier satisfaisant.
Mais le flow n’est pas lié à la difficulté technique. Il est lié à l’équilibre défi-compétence, quel que soit le défi. Je l’observe sur moi : il m’arrive d’entrer en flow en formulant un problème — en cherchant les mots exacts pour décrire une architecture, en affinant une spécification jusqu’à ce qu’elle capture l’intention. Un flow d’écrivain plus que d’ingénieur. Je mentirais en le disant équivalent. Il y manque la résistance du matériau, la satisfaction du geste maîtrisé. Perte ou métamorphose, je ne sais pas encore.
Une grille de lecture m’a aidé, celle d’Hannah Arendt. Elle distingue le travail — le labeur répétitif qui assure la survie —, l’œuvre — ce qui laisse une trace dans le monde — et l’action — l’initiative qui engage, dans la communauté humaine. Transpose au logiciel (l’interprétation est de moi, pas d’elle) : le boilerplate, la config, les erreurs de syntaxe, c’était du travail. Concevoir un système, c’est de l’œuvre. Comprendre un besoin, décider, assumer un choix technique dans l’incertitude, c’est de l’action. Vu comme ça, l’IA nous libère peut-être du travail pour nous rapprocher de l’action. Et le malaise ne serait pas le signe qu’une chose meurt — plutôt l’inconfort de devoir chercher le sens ailleurs que là où on avait l’habitude de le trouver.
Ce qui devient rare
Un mot d’économie, parce que la question finit toujours par arriver : si n’importe qui peut produire du logiciel fonctionnel, que vaut encore le code ? Quand une compétence rare devient accessible, sa valeur marchande s’effondre. Mécanisme connu. Mais la rareté ne disparaît pas, elle se déplace. Du savoir coder vers le savoir quoi coder — et surtout le savoir pourquoi. Pourquoi ce produit. Pourquoi cette architecture. Pourquoi cette fonctionnalité maintenant. Le jugement, la priorisation, le contexte humain : voilà le rare.
La musique a déjà joué cette pièce. Les home studios numériques ont démocratisé la production — n’importe qui sort un morceau au son professionnel depuis sa chambre. Et les grands artistes ne se distinguent pas par leur mixage. Ils se distinguent par la vision. La technique est devenue une commodité ; la vision reste rare. Mais l’analogie a un angle mort, et je ne l’avais pas vu au départ : pendant que la production se démocratisait, quelques plateformes de streaming concentraient la valeur. Tout le monde peut produire ; presque personne n’en vit. Le même risque existe pour le code — production démocratisée, valeur concentrée chez ceux qui tiennent les plateformes, les données et les modèles. Démocratiser la production, ce n’est pas démocratiser le pouvoir.
Et la même technologie ne se vit pas pareil partout. Pour un senior en Europe, l’IA menace une expertise durement acquise. Pour un autodidacte à Lagos ou Bangalore, elle est d’abord une porte d’entrée — un accès à des capacités réservées jusque-là à ceux qui avaient les bonnes écoles et les bons réseaux. Dépossession ici, émancipation là-bas. Ça ne simplifie pas l’analyse. Ça la rend honnête.
Transmettre le doute
Je reviens au centaure, comme promis. S’il doit durer, ce ne sera pas un état naturel — ce sera un équilibre activement maintenu, contre la pente de l’outil qui lisse tout. L’automatisation érode ce qu’elle rend inutile au quotidien. La friction fabrique l’expertise, et l’IA la supprime. Et l’autre moitié du centaure, on l’a vu, a ses propres angles morts. Tout converge.
C’est là que la transmission devient urgente. L’expérience pré-numérique — ceux qui ont navigué avant le GPS et codé avant l’IA — est un capital collectif en voie de disparition. Pas parce que ces gens disparaissent. Parce que ce qu’ils savent est exactement ce qui ne passe ni par un tutoriel ni par un prompt.
La vraie question n’est pas « faut-il apprendre le C aux juniors » ou « faut-il interdire l’IA aux étudiants ». Ces débats ratent la cible. La vraie question : comment transmettre le doute méthodique à ceux qui n’ont jamais eu besoin de douter ? Comment enseigner la vigilance à des professionnels dont les outils marchent assez bien pour ne jamais être remis en question — jusqu’au jour où il le faut ?
Je n’ai pas de réponses fermes. Des pistes, formulées en questions parce que c’est plus honnête. Créer des zones de friction délibérée dans la formation, des espaces où l’IA est volontairement absente ? Valoriser le jugement plutôt que la vitesse, dans une industrie qui mesure tout en vélocité ? Et si certains savoirs sont condamnés — comme s’est perdu celui du copiste, celui du navigateur au sextant —, choisir consciemment ce qu’on accepte de perdre et ce qu’on s’efforce de garder ?
Le malaise de cette après-midi-là, je le lis autrement maintenant. Ce n’était pas la peur du remplacement — pas seulement. C’était le sol qui se dérobe sous une compétence qu’on croyait solide. Mais le vertige n’est pas une conclusion. C’est un point de départ. La valeur humaine ne tient probablement pas dans ce que nous faisons — les machines font de plus en plus — mais dans ce que nous comprenons de ce que nous faisons, et dans notre capacité à demander pourquoi. Il y a une ironie à ce qu’un développeur trouve du sens non dans son code, mais dans les questions qu’il se pose sur son métier. C’est peut-être précisément le territoire que l’IA ne colonisera pas de sitôt.
Le vertige de la vitesse passera. La question de la transmission, non. Ceux qui ont construit leur jugement dans la friction sont encore là. Ce qu’ils savent ne tient pas dans un prompt. Si on ne trouve pas comment le transmettre — pas la nostalgie : le doute méthodique, le réflexe de vérifier ce que l’outil affirme —, il partira avec eux. Ce qui restera, c’est ce qu’on aura choisi d’en faire. Et ce qu’on aura pris soin de ne pas perdre.