Je n'ai plus mal aux dents en apprenant une nouvelle techno.
Avant, maîtriser un framework prenait des semaines. On lisait la doc, on cassait des choses, on recommençait. La friction faisait partie du métier. Aujourd'hui, je donne le contexte à une IA, elle exploite la doc en quelques minutes, je relis, j'ajuste. Le résultat arrive plus vite. Presque toujours.
Mais une question reste, et elle ne me lâche pas : à qui appartient le mérite de ce qui est produit ?
Le constat
Quand je bute, aujourd'hui, ce n'est presque jamais sur la technique. C'est sur le contexte. Sur l'objectif mal formulé. Sur ce que je n'ai pas su exprimer assez précisément pour que l'IA produise ce qu'il fallait.
La difficulté a changé de nature. Elle n'est plus dans le code. Elle est dans la clarté de l'intention.
J'ai construit plusieurs outils ces derniers mois pour accélérer mes propres process. Une partie significative du développement a été faite par l'IA — pas par moi. Je vais plus vite, c'est un fait. Mais demain, si on me demande si je maîtrise telle techno utilisée dans ces outils, ma réponse honnête est non. Je l'ai supervisée. Relue. Orientée. Je ne l'ai pas développée de A à Z.
Ce n'est pas une fausse modestie. C'est un constat professionnel.
Ce qui ne change pas de nom
Le CV d'un développeur liste des technologies. React, Kubernetes, Spring Boot. Cette liste a toujours été une promesse implicite : j'ai pratiqué, j'ai galéré, je sais où sont les pièges.
Cette promesse tient de moins en moins. On peut produire du code fonctionnel dans une techno qu'on n'a jamais pratiquée avant ce matin-là. La maîtrise affichée et la maîtrise réelle se sont éloignées l'une de l'autre, sans que le format du CV ait suivi.
Le problème n'est pas l'IA. Le problème est qu'on continue à mesurer une compétence avec les outils d'avant.
Où se déplace la valeur
Trois compétences semblent prendre le relais de la maîtrise technique pure.
La première : savoir formuler un objectif avec assez de précision pour qu'une IA produise quelque chose d'exploitable. Ce n'est pas trivial. C'est même, de mon expérience, la compétence la plus inégalement répartie chez les développeurs que je croise.
La deuxième : savoir relire et juger un résultat qu'on n'a pas produit soi-même. Repérer ce qui ne va pas, dans du code qu'on n'a pas écrit ligne par ligne, demande une lecture différente de celle qu'on apprend en école ou en autodidacte. On ne débogue plus sa propre logique. On audite celle d'un autre — qui se trouve être une machine.
La troisième : savoir assumer la responsabilité d'un résultat qu'on n'a pas entièrement maîtrisé dans le détail. C'est la plus inconfortable. Signer un travail qu'on a supervisé plutôt qu'exécuté change le rapport qu'on a à son propre travail.
Aucune de ces trois compétences ne porte de nom établi dans le métier. On ne les enseigne pas comme on enseigne un langage. Elles s'acquièrent sur le tas, en silence, souvent sans qu'on s'en rende compte.
Le nom qui manque
Le mot "développeur" décrit quelqu'un qui écrit du code. Le mot "manager" décrit quelqu'un qui dirige des personnes. Ce qu'on fait aujourd'hui — orienter une IA, juger sa production, en porter la responsabilité — n'a pas encore de nom stabilisé dans le métier.
Ce n'est pas du développement au sens classique. Ce n'est pas non plus du management, puisqu'on ne dirige personne. C'est une troisième chose, à la frontière des deux, qui se pratique déjà massivement sans être nommée.
Ce que disent les chiffres
Ce constat personnel n'est pas isolé. Une étude longitudinale soumise à arXiv en mai 2026 par Annie Vella et Kelly Blincoe a suivi des développeurs professionnels sur deux temps de mesure espacés de six mois. Le résultat principal : 82 % des participants déclarent passer moins de temps à écrire du code qu'avant. Les auteurs proposent un terme pour désigner ce qui prend la place de l'écriture : le supervisory engineering work — diriger, évaluer et corriger les productions de l'IA.
Le Stack Overflow Developer Survey 2025 va dans le même sens. 84 % des développeurs utilisent ou prévoient d'utiliser l'IA dans leur travail, et 51 % des professionnels l'utilisent quotidiennement. Mais l'adoption ne s'accompagne pas d'une confiance aveugle : 46 % des développeurs ne font pas confiance à l'exactitude des réponses produites, contre seulement 33 % qui leur font confiance. On utilise massivement un outil qu'on ne croit pas sur parole — ce qui, mécaniquement, oblige à vérifier.
Cette vérification, ce pilotage, cette correction : c'est précisément le travail qui n'a pas encore de nom propre dans le métier. L'étude lui en donne un. Reste à savoir s'il s'imposera, ou si le métier en trouvera un autre.
Ce que ça change concrètement
La conséquence la plus visible touche la manière de présenter ses compétences. Un CV qui liste uniquement des technologies — Java, React, Kubernetes — décrit un développeur d'avant : quelqu'un qui a pratiqué, qui a galéré, qui sait où sont les pièges.
Un CV qui reflète le travail réellement effectué aujourd'hui mentionnerait autre chose : la capacité à définir un contexte précis pour une IA, à évaluer la qualité d'une sortie qu'on n'a pas produite soi-même, à arbitrer entre plusieurs propositions, à garantir qu'un résultat est correct sans l'avoir écrit ligne par ligne.
Les compétences techniques ne disparaissent pas de l'équation. Elles deviennent un prérequis plutôt qu'un élément différenciant — on les utilise pour juger ce que produit l'IA, pas nécessairement pour produire soi-même depuis zéro.
Je ne sais pas comment ce métier va s'appeler dans cinq ans. Je sais qu'il existe déjà, parce que je le pratique tous les jours, et que la majorité des développeurs que je connais le pratiquent aussi, sans toujours le formuler ainsi.
La friction a disparu. La responsabilité, elle, est restée entière.
Références
- Annie Vella, Kelly Blincoe — The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study (arXiv, mai 2026)
- Stack Overflow — Developer Survey 2025 · AI