L’IA n’a pas supprimé la partie difficile du code. Elle l’a déplacée.

La compétence pour laquelle nous nous sommes tous optimisés

Tout, dans la façon dont les développeurs apprennent, a été construit autour du savoir-faire : mémoriser la syntaxe, apprendre les patterns, s’entraîner jusqu’à pouvoir produire du code fonctionnel à partir d’une page blanche. Les entretiens d’embauche le testent. Les cours l’enseignent. Les carrières étaient classées selon ce critère.

Puis les LLM ont rendu la production quasiment gratuite. Décrivez ce que vous voulez, et du code qui a l’air de fonctionner apparaît en quelques secondes. Selon les propres chiffres de Google, plus d’un quart de son nouveau code est désormais généré par l’IA. La page blanche n’est plus l’ennemi.

Il est tentant d’en conclure que le métier est simplement devenu plus facile. La vraie question a changé sous nos pieds : si n’importe qui peut générer une réponse, qu’est-ce qui distingue un bon développeur d’un mauvais ?

La compétence rare n’est plus de produire la réponse. C’est de voir, rapidement et de façon fiable, si une réponse est bonne, et de savoir comment critiquer le modèle pour en obtenir une meilleure. Appelons cela le savoir-voir. Le savoir-faire livre le premier jet. Le savoir-voir décide si ce jet a sa place en production.

Pourquoi nous continuons d’entraîner le mauvais muscle

Parce que la production a été coûteuse pendant cinquante ans, nos réflexes assimilent taper du code à travailler, et produire à progresser. La relecture était l’activité de bas statut, la chose qu’on faisait sur le code des autres, rapidement, avant de retourner au « vrai travail ». Personne n’a construit une carrière en étant excellent pour lire du code. Cette habitude est aujourd’hui exactement à l’envers.

Ce que disent les données

Générer est bon marché. Vérifier est le nouveau centre de coût. L’essai randomisé contrôlé de METR a suivi des développeurs open source expérimentés sur leurs propres bases de code matures, et a mis au jour un résultat gênant : avec des outils d’IA, ils ont mis 19 % de temps en plus pour terminer leurs tâches, tout en étant convaincus d’avoir été 20 % plus rapides. Où est passé le temps ? Pas dans la frappe. Les développeurs n’ont accepté que moins de 44 % des suggestions de l’IA, et une majorité a rapporté un nettoyage important sur le code qu’ils ont accepté. Lire, juger et corriger — le travail de savoir-voir — a discrètement absorbé les gains.

Votre sentiment de productivité n’est pas une mesure. Cette même étude a révélé un écart d’environ 40 points entre vitesse perçue et vitesse réelle. Le rapport DORA de Google, s’appuyant sur 39 000 professionnels, a trouvé le même schéma à grande échelle : alors que l’adoption de l’IA augmentait de 25 %, la vitesse de livraison baissait et la stabilité du système chutait de 7,2 %, tandis que trois quarts des développeurs se sentaient plus productifs. Le savoir-voir commence par se méfier du ressenti. Il faut instrumenter la réalité : temps de réalisation des tâches, taux de défauts, profondeur des relectures. Si vous ne pouvez pas voir clairement votre propre performance, vous ne pouvez certainement pas voir celle du modèle.

La meilleure production revient aux meilleurs critiques. Un LLM est comme un collègue junior infiniment rapide et d’une confiance illimitée : le premier jet arrive en quelques secondes, l’air soigné, occasionnellement faux de manières conçues pour passer inaperçues. Ce qui améliore le jet suivant, ce n’est pas un vague « améliore ça », c’est une critique précise. Nommez le défaut : « ceci ignore le cas limite du fuseau horaire », « ceci duplique la logique de nouvelle tentative du client », « ce test n’affirme rien ». Les développeurs qui obtiennent des résultats remarquables font tourner une boucle serrée : définir à quoi ressemble le « bon » avant de prompter, relire le résultat comme un relecteur senior hostile face au code d’un junior, et renvoyer des défauts précis et nommés. Être le critique principal n’est pas une surcharge du flux de travail avec l’IA. C’est le flux de travail.

Deux objections légitimes. « D’autres études montrent de vrais gains. » Vrai — une grande étude menée chez Microsoft et Accenture a constaté que les développeurs utilisant Copilot achevaient 26 % de tâches en plus. Les deux résultats peuvent coexister : les gains se concentrent là où les tâches sont autonomes et la vérification bon marché ; les pertes se concentrent dans les systèmes complexes et interconnectés, où repérer une faille subtile est difficile. La variable qui sépare les deux études est précisément le coût du jugement. « Les modèles deviendront assez bons pour que la vérification n’ait plus d’importance. » Plus les modèles s’améliorent, plus leurs erreurs passent d’évidentes à plausibles — fausses d’une manière qui semble juste. L’amélioration relève la barre pour le critique ; elle ne le met pas à la retraite.

Un auto-test rapide

1. Pouvez-vous dire en moins d’une minute si une fonction générée est prête pour la production, ou le découvrez-vous en relecture, ou pire, en production ?
2. Lisez-vous le résultat de l’IA avec la même rigueur que vous appliqueriez à une pull request d’un junior, ou avec l’indulgence que vous réservez à votre propre code ?
3. Quand le résultat est médiocre, reformulez-vous votre demande avec une critique nommée et précise, ou l’acceptez-vous en corrigeant à la main ?
4. Mesurez-vous votre travail assisté par l’IA, ou faites-vous confiance à la vitesse ressentie ?

Entraîner le savoir-voir, délibérément

Lisez plus de code que vous n’en écrivez. Relire, de façon hostile, ligne par ligne, en se demandant « qu’est-ce qui casserait ça ? », est désormais la pratique centrale, pas la corvée.

Écrivez la définition du « terminé » avant de prompter. Si vous ne pouvez pas énoncer à quoi ressemble le bon résultat, vous accepterez tout ce qui a l’air fini.

Construisez un vocabulaire de critique. Les modèles répondent à la précision. « C’est faux » produit un remaniement aléatoire ; « ceci laisse fuir la connexion sur le chemin d’erreur » produit une correction.

L’IA n’a pas rendu les développeurs remplaçables. Elle a fait de leur jugement le produit tout entier.