On ne vous a jamais embauché pour écrire du code

Pendant des années, une partie de notre industrie a fini par confondre le métier avec son outil.

On parle de langages.
De frameworks.
De qualité du code.
De tests.
D’architecture.

Tout cela compte.

Mais personne ne recrute réellement un ingénieur logiciel parce qu’il sait taper du code sur un clavier.

On recrute un ingénieur parce qu’il y a un problème à résoudre.

Le code n’a toujours été qu’un moyen.

Et c’est peut-être l’un des effets les plus intéressants de l’IA : elle rend cette distinction impossible à ignorer.

Quand produire une implémentation demandait plusieurs jours, voire plusieurs semaines, la capacité à écrire du code occupait mécaniquement une grande partie du travail.

Avec les agents de coding, cette part diminue.

Pas parce que le logiciel devient simple.

Mais parce qu’une partie importante de l’effort nécessaire pour transformer une intention en code peut désormais être déléguée.

La question devient alors moins :

« Est-ce que tu sais implémenter cette fonctionnalité ? »

et davantage :

« Est-ce que cette fonctionnalité doit exister ? »

« Quel problème résout-elle exactement ? »

« Quelles contraintes devons-nous respecter ? »

« Quelle architecture est adaptée ? »

« Quels compromis sommes-nous prêts à accepter ? »

« Comment savons-nous que la solution produite est correcte ? »

« Que se passe-t-il quand elle échoue ? »

C’est là que le mot engineer commence presque à devenir plus important que le mot developer.

Un ingénieur ne se définit pas par sa capacité à manipuler un outil.

Il comprend un système.

Il identifie des contraintes.

Il fait des arbitrages.

Il évalue des risques.

Il choisit où investir les ressources disponibles.

Et surtout, il s’assure que ce qu’on construit répond réellement au problème posé.

Cela ne signifie pas que comprendre le code devient inutile.

Au contraire.

Pour évaluer une solution générée par une machine, il faut comprendre ce qu’elle fait, sentir lorsqu’une abstraction est mauvaise, repérer une architecture fragile, anticiper les problèmes qui n’apparaissent pas dans la happy path.

Mais la compétence se déplace.

Pendant longtemps, beaucoup de développeurs pouvaient construire une grande partie de leur valeur autour de leur capacité à produire l’implémentation.

Ce refuge devient progressivement moins confortable.

Et je pense que c’est une bonne chose.

L’IA ne nous apprend pas que le métier d’ingénieur consiste à résoudre des problèmes.

C’était déjà le cas.

Elle nous enlève simplement progressivement la possibilité de l’oublier.