Les gros titres ne cessent de nous dire que l'IA rendra les développeurs de logiciels obsolètes. Je n'y crois pas. Le véritable risque n'est pas que les machines prennent le contrôle de l'ingénierie. Le risque est que les ingénieurs cessent de faire l'effort difficile de la réflexion.

Le logiciel n'a jamais été une question de saisie de syntaxe. Il s'est toujours agi de maîtriser la complexité, de comprendre les modes de défaillance et de faire des compromis lorsqu'aucune option n'est parfaite. L'IA a changé la vitesse à laquelle nous produisons du code, mais elle n'a pas changé la raison pour laquelle nous avons besoin de l'humain dans la boucle. Si tant est qu'elle ait changé quelque chose, c'est qu'elle a rendu la pensée claire plus précieuse et plus rare.

Le premier jet n'est pas de l'ingénierie

Je vois un nombre croissant de développeurs juniors traiter ChatGPT ou Claude comme l'ingénieur senior assis sur la chaise d'à côté. Ils collent une description de ticket, copient la réponse, lancent les tests et valident (commit). Si ça compile, la tâche est terminée. La boucle est rapide, sans friction et dangereuse.

Utiliser l'IA n'est pas le problème. Je l'utilise. La plupart des ingénieurs productifs que je connais l'utilisent. Le problème commence lorsque l'IA devient le seul ingénieur dans la pièce. Accepter la première solution parce qu'elle fonctionne n'est pas de l'ingénierie. C'est l'externalisation du jugement à un modèle qui ne comprend ni vos utilisateurs, ni vos contraintes métier, ni la dernière fois que votre stack s'est effondrée à 2 heures du matin.

Les grands modèles de langage fournissent des réponses avec une assurance déconcertante, même lorsqu'ils ont complètement tort. Un ingénieur a demandé à une IA de concevoir une architecture évolutive. Le modèle a renvoyé une proposition détaillée et autoritaire, entièrement construite autour d'une fonctionnalité qui n'existait pas dans le produit réel. Cela semblait correct. C'était cohérent en interne. C'était aussi inutile. Le danger n'est pas seulement que l'IA hallucine. Le danger est que trop de gens font désormais confiance à ces hallucinations parce qu'ils n'ont plus le contexte nécessaire pour repérer le mensonge.

On apprend de la friction

Quand je repense à ce qui m'a fait passer de développeur junior à quelqu'un capable de gérer un système, je ne me souviens pas de la syntaxe que j'ai mémorisée. Je me souviens des pannes. Je me souviens des requêtes lentes que j'ai dû tracer à la main, des conditions de concurrence (race conditions) qui n'apparaissaient que sous la charge de production, et des déploiements qui échouaient parce que mon environnement local ne ressemblait en rien au monde réel.

Le débogage est le moment où l'apprentissage se produit. Lorsque vous parcourez le code manuellement, vous voyez pourquoi les systèmes échouent réellement. Vous découvrez où apparaissent les goulots d'étranglement. Vous apprenez comment une architecture se comporte lorsque vous passez d'une démo avec dix utilisateurs à un système de production gérant dix mille requêtes simultanées. Vous absorbez, jusque dans vos os, la différence entre la production et une démo bien scénarisée.

Aucune de ces connaissances ne provient de l'acceptation d'une réponse générée. Elle provient de la lutte avec le problème. Si l'IA élimine toute difficulté, si elle écrit le code, corrige les bugs et justifie les échecs, comment la prochaine génération de développeurs obtiendra-t-elle exactement sa séniorité ? L'expérience n'est pas un certificat que l'on télécharge. C'est le tissu cicatriciel que l'on forge à travers les incidents de production et les déploiements ratés. Supprimez la friction et vous supprimez la croissance.

Le jugement l'emporte sur la génération

Pendant un certain temps, l'industrie a traité le prompt engineering comme la nouvelle compétence tendance à inscrire sur un CV. Cela passait complètement à côté du sujet. La capacité la plus précieuse dans un environnement saturé d'IA n'est pas de générer des options. C'est de savoir quelles suggestions rejeter.

Les meilleurs ingénieurs avec qui je travaille ne sont pas ceux qui écrivent le plus de prompts. Ils sont ceux qui posent les questions les plus difficiles. Ils savent quand un refactoring introduit une dépendance cachée. Ils reconnaissent quand un test généré couvre le chemin nominal (happy path) mais ignore le cas limite (edge case) qui corrompra les données client. Ils peuvent regarder un code parfaitement valide et dire : « Ce code est correct, mais l'architecture est mauvaise. »

Cette dernière phrase est la ligne de démarcation entre deux cultures très différentes. L'ingénierie assistée par l'IA signifie que vous utilisez la machine pour rédiger l'échafaudage, explorer des modèles ou automatiser le code répétitif (boilerplate), tandis que votre cerveau gère les décisions. L'ingénierie dépendante de l'IA signifie que vous faites confiance à la machine pour conduire. De nombreuses organisations dérivent discrètement vers la dépendance parce que cela semble plus rapide à court terme. Rapide n'est pas synonyme de juste.

Le travail qui appartient encore aux humains

L'IA peut accélérer presque chaque étape du cycle de vie du développement, pourtant, certaines pratiques fondamentales devraient rester fermement humaines. La conception de systèmes exige de maintenir un équilibre entre des contraintes concurrentes : coût, latence, fiabilité et maintenabilité future. Les revues d'architecture dépendent de la mémoire institutionnelle et de la capacité à projeter des effets de second ordre. Le mentorat nécessite quelqu'un qui a réellement subi les modes de défaillance dont il vous met en garde. Une compréhension approfondie du produit provient de la discussion avec les utilisateurs et de l'observation de leur comportement en conditions réelles, et non de la lecture de données d'entraînement.

Le jugement technique est la somme de ces expériences. C'est cette petite voix qui vous dit qu'une migration est trop risquée pour être déployée un vendredi après-midi, même si la revue de code a été validée. C'est l'intuition qu'une optimisation de performance actuelle pourrait créer une faille de sécurité plus tard. Un LLM n'a pas d'intuition. Il possède des schémas. Les schémas sont utiles, mais ils ne constituent pas un jugement.

Les entreprises qui recrutent actuellement doivent cesser de chercher uniquement des personnes qui sont simplement douées pour utiliser les outils d'IA. Recrutez des personnes capables de remettre en question l'IA. Recherchez des candidats qui marquent une pause, lisent attentivement le résultat généré et expliquent pourquoi ils ne sont pas d'accord avec lui. Ce sont ces ingénieurs qui préserveront la santé de vos systèmes lorsque le code généré se heurtera à la réalité complexe de la production.

Accélération sans boussole

Considérez l'IA comme une pédale d'accélérateur. Dans une voiture avec un