Dans un essai publié sur son site personnel, l’ingénieur Vardan Torosyan s’interroge sur l’effet discret mais profond de l’intelligence artificielle sur les compétences des développeurs. Il n’appelle pas à rejeter la technologie, mais il exhorte à ne pas confondre rapidité d’exécution et compréhension réelle des systèmes. « Le débit et la compréhension ne sont pas la même chose », écrit-il, en constatant que la profession privilégie aujourd’hui le premier au détriment de la seconde.

Torosyan décrit un phénomène insidieux : les risques ne sont pas immédiats, ils sont lents et invisibles. Lorsque l’on cesse de se confronter directement à des problèmes difficiles, les modèles mentaux s’estompent. L’intuition technique se dégrade. On passe d’un raisonnement par principes fondamentaux à un simple appariement de résultats. Le pire, souligne-t-il, est que l’on ne s’en rend pas compte. Le code continue d’être livré, les pull requests sont fusionnées. Tout semble normal jusqu’à l’incident nocturne où personne ne parvient plus à comprendre ce que fait le système.

L’analogie de l’aviation

Pour illustrer son propos, il utilise une analogie avec l’aviation. L’utilisation intensive du pilote automatique a fait perdre aux pilotes leur capacité à voler manuellement, un phénomène qui a contribué à des accidents réels, comme le vol Air France 447. La réponse des autorités n’a pas été d’interdire le pilote automatique, mais d’imposer des heures de vol manuel. L’industrie a reconnu que certaines compétences ne se maintiennent que par une pratique délibérée. Torosyan regrette que le logiciel n’ait pas encore pris de mesure équivalente.

Le problème des juniors

Ce constat est particulièrement aigu pour les nouveaux ingénieurs. Ceux qui entrent aujourd’hui dans la profession risquent de ne jamais développer l’intuition système que la génération précédente a acquise, parce que la friction qui forçait l’apprentissage a disparu. « Passer des heures bloqué sur une étrange condition de concurrence, déboguer en lisant des logs, écrire quelque chose à partir de zéro et ne pas comprendre pourquoi c’était lent : ces moments étaient agaçants, mais ils mettaient la connaissance dans votre tête d’une manière que la lecture de la réponse ne fait pas », explique-t-il. Or, ce sont ceux qui ont le plus besoin de ces répétitions qui ne les obtiennent jamais.

Les trois piliers du métier d’ingénieur

Torosyan propose un cadre en trois points pour définir le travail d’ingénieur aujourd’hui :

  • Quel problème résoudre ? Cela nécessite du goût, du jugement et une proximité avec le client. Impossible de sous-traiter cela à l’IA.
  • Comment le résoudre ? Architecture, compromis, compréhension du système. Les fondamentaux (connaissance du noyau d’un système d’exploitation, par exemple) restent un atout considérable, même lorsque l’IA génère le code.
  • Résoudre effectivement le problème. C’est la partie que l’IA automatise le plus rapidement.

Le piège, selon lui, est de croire que la troisième partie constitue l’intégralité du travail. « Ce n’a jamais été le cas, mais c’était la partie la plus visible. Maintenant qu’elle est automatisée, les deux premières sont exposées comme le véritable levier – et beaucoup d’ingénieurs n’y sont pas préparés. »

Développer le jugement : un muscle qui s’atrophie

L’auteur estime que tout le monde affirme que le jugement comptera davantage à l’avenir, mais que personne n’explique vraiment comment le cultiver ou comment éviter de le perdre. Pour lui, le jugement se construit par une boucle spécifique : on se fait une opinion, on s’y engage, on observe le résultat, on ajuste. Ce cycle, répété de nombreuses fois, forge la calibration. L’IA court-circuite la première étape : on saute la formation de sa propre opinion pour passer directement à l’évaluation de celle d’autrui. « À force, le muscle s’atrophie – pas de façon spectaculaire, juste en silence. On devient un meilleur relecteur et un moins bon penseur. »

Il propose deux pratiques concrètes pour contrer cet effet :

  1. Écrire avant de regarder. Avant d’ouvrir un outil, avant d’interroger un modèle, écrire ce que l’on pense. Même quelques phrases. Cela oblige à formuler son raisonnement plutôt qu’à reconnaître les résultats d’un autre.
  2. Se faire une opinion avant de lire la suggestion. Lors de la relecture d’un code généré par IA, examiner le résultat avec sa propre opinion déjà en tête : qu’aurions-nous fait ? En quoi cela diffère-t-il ? Pourquoi le modèle a-t-il choisi cette direction ? Cela transforme la consommation passive en évaluation active.

Sept pistes pour éviter l’érosion des compétences

Torosyan conclut en proposant sept pratiques qu’il essaie lui-même d’adopter :

  1. S’approprier le problème avant de toucher à l’outil. Passer plus de temps avec le client, sa douleur, son flux de travail.
  2. Déboguer en production manuellement. Les astreintes et les analyses post-incident sont l’un des derniers espaces où l’on est contraint de comprendre le système tel qu’il se comporte réellement.
  3. Lire du code que l’on n’a pas écrit. En particulier le code généré par IA. Si l’on ne peut pas expliquer une pull request à un collègue, on n’en a pas la maîtrise réelle.
  4. Rédiger le document de conception avant l’éditeur. Les documents forcent la réflexion. Si l’on n’arrive pas à produire un document cohérent, on ne comprend probablement pas assez le problème.
  5. Développer un sens des limites du modèle. Savoir quand se fier au résultat et quand s’en méfier devient une compétence clé. Cela exige de chercher délibérément les cas où l’IA échoue.
  6. Protéger sa charge cognitive. Parfois, l’action la plus utile est de ralentir un collègue et de lui demander s’il comprend vraiment ce que fait son code.
  7. Tenir un journal de connaissances expérimentales. Plutôt que de la documentation formelle, Torosyan capture des traces : observations, surprises, décisions et leurs raisons. Une pratique qui, espère-t-il, pourra s’étendre à toute l’équipe.