Lorsque l’IA écrit le code : compétences en ingénierie qui gagnent en valeur
Les agents de codage rédigent désormais des fonctionnalités du début à la fin. Ce qu’il faut étudier, comment examiner le code généré, et pourquoi le jugement, les connaissances en systèmes et la vérification sont plus importants que la simple capacité de taper.
Rédiger du code devient la partie facile dans le travail de développement logiciel. Décider de ce qui doit être construit, vérifier ce que produit une intelligence artificielle et reconnaître quand elle se trompe deviennent les compétences essentielles.
Une question circule constamment : si l’intelligence artificielle peut écrire la majeure partie du code, que reste-t-il pour les développeurs ? C’est la mauvaise question. Une meilleure question serait de savoir ce qu’une personne qui commence une carrière en développement logiciel aujourd’hui devrait apprendre, car l’intelligence artificielle ne peut pas le remplacer facilement.
Quelque chose a clairement changé. Des outils tels que Claude Code, Codex, Copilot, Cursor et d’autres ont dépassé le simple fonctionnement de complétion automatique. Ils lisent des répertoires entiers, modifient plusieurs fichiers, exécutent des commandes, écrivent des tests, résolvent les erreurs et restent sur une tâche jusqu’à ce qu’elle soit terminée. Claude Code en particulier a bien dépassé le stade de « écris-moi une fonction » et agit davantage comme un agent d’ingénierie vivant à l’intérieur du répertoire. Cela change la nature du travail.
Le code devient moins cher
Il n’y a pas si longtemps, un développeur pouvait passer une demi-journée sur une seule fonctionnalité. Aujourd’hui, cette fonctionnalité peut être décrite à un agent :
Add JWT authentication.
Create login and refresh-token APIs.
Add PostgreSQL persistence.
Write integration tests.
Run the test suite.
Fix failures.
Ensuite, l’agent se met au travail. Il crée des fichiers, modifie les classes existantes, exécute des tests, rencontre des erreurs, ajuste l’implémentation et exécute à nouveau les tests. Rien de tout cela n’est plus hypothétique.
Ce qui est frappant, c’est que le développeur n’a pas disparu du processus. Le développeur est devenu la personne responsable du résultat, et cette distinction est importante.
Où mène l’exemple d’Anthropic
Anthropic est l’un des exemples les plus clairs, puisque Claude Code y est utilisé pour des développements sérieux. Son créateur, Boris Cherny, a parlé publiquement de l’évolution considérable de l’ingénierie au sein de l’entreprise, et des rapports publiés au début de cette année décrivaient comment l’IA produisait presque tout le code dans certains de leurs flux de travail d’ingénierie.
Les développeurs devraient se concentrer sur une conséquence : plus de code généré ne signifie pas moins d’effort technique. Cela peut même impliquer plus de responsabilités. Disons que Claude génère 5 000 lignes. Quelqu’un doit alors répondre à la question suivante :
Is the architecture correct?
Is authentication secure?What happens under 10,000 requests?Can this transaction fail halfway?Will this leak memory?What happens when Redis is unavailable?What happens when the database is slow?Did the AI introduce a race condition?
L’IA peut assurer la mise en œuvre, mais vous restez responsable des conséquences.
Un débat plus large à ce sujet
D’après des rapports publiés, un ancien chercheur d’Anthropic, Jacob Coxon, a annoncé sa démission en septembre 2026. Son avertissement ne portait pas sur la capacité de Claude à écrire du JavaScript de qualité ou sur la possibilité pour l’IA de créer une API Spring Boot. Il concernait plutôt l’orientation des systèmes d’IA de plus en plus performants. Son post sur X aurait atteint plus de 100 millions de personnes, dans lequel il affirmait que les principaux laboratoires avançaient trop rapidement vers des systèmes autonomes et potentiellement dangereux.
Cet avis a de l’importance car il provient de quelqu’un qui a travaillé au sein d’une entreprise développant cette technologie. Le débat est devenu suffisamment sérieux pour que le PDG d’Anthropic, Dario Amodei, appelle également à ralentir le rythme du développement de pointe et à renforcer l’évaluation indépendante des systèmes d’IA.
Ainsi, 2026 offre un tableau curieux. Un camp affirme que l’IA peut accélérer de manière significative le développement logiciel. Un autre, composé de ceux qui conçoivent ces systèmes, estime que chacun devrait être bien plus prudent quant à l’issue de cette accélération. Les deux affirmations peuvent être vraies en même temps.
La plus grande erreur
La plus grosse faute n’est pas d’éviter l’IA. C’est de l’utiliser sans comprendre ce qu’elle produit. Prenons cet exemple :
@GetMapping("/users")
public List<User> getUsers() {
return userRepository.findAll();
}
Une intelligence artificielle peut écrire cela en deux secondes. Faut-il le mettre en production ? Peut-être. Mais que se passe-t-il si le tableau contient 20 millions de lignes ? Et s’il n’y a pas de pagination ? Et si l’endpoint est public, ou si le type User contient des champs sensibles, ou encore si cinq mille personnes l’appellent simultanément ? Le code est techniquement valide, mais la décision d’ingénierie peut tout de même être catastrophique. C’est là la différence.
Que mettre à la place
Quelqu’un qui débute en 2026 ferait bien de consacrer moins de temps à mémoriser la syntaxe et plus à comprendre le fonctionnement réel des systèmes :
- conception de systèmes et systèmes distribués
- bases de données, API et réseaux
- sécurité
- débogage et tests
- performance et observabilité
- infrastructure cloud
- fonctionnement des agents d’intelligence artificielle
Écrire du code reste important, mais l’évaluation d’un développeur passe des lignes tapées à sa capacité à transformer un problème complexe en un système fiable. L’IA est déjà très douée pour gérer ce type de tâches :
Write this.
Refactor this.
Explain this.
Test this.
Fix this.
Convert this.
Le développeur de plus en plus précieux est celui qui peut répondre par quelque chose comme ceci :
Don't build it this way.
Here's why.
Here's the simpler architecture.
Here's the failure mode you missed.
Here's what we should measure in production.
L’IA ne supprime pas la nécessité de réfléchir
C’est là le côté dérangeant : l’IA facilite la programmation, ce qui peut conduire à des programmeurs moins compétents s’ils cessent de réfléchir. Il existe déjà des preuves à cet égard : une étude d’Anthropic a montré que les développeurs utilisant l’aide de l’IA obtenaient de moins bons résultats aux tests de compréhension lorsqu’ils apprenaient des bibliothèques de programmation inconnues, bien que l’IA apporte réellement des gains de productivité dans d’autres contextes.
La leçon n’est pas d’arrêter d’utiliser l’IA. Il s’agit plutôt d’éviter de confier entièrement le processus d’apprentissage à l’IA. Lorsque Claude écrit une solution, lisez-la, analysez-la, modifiez-la. Demandez pourquoi elle fonctionne et où elle échoue. Essayez de créer une version simplifiée manuellement, puis revenez à l’IA. Cela surpasse de loin ce cercle vicieux.
Prompt → Copy → Commit → Next task
Le nouvel ingénieur logiciel
L’ingénieur ne disparaît pas, mais le métier devient plus difficile. Un développeur junior qui se contente de transformer des exigences en code CRUD se trouve dans une position bien plus fragile qu’auparavant. Celui qui comprend le problème métier, l’architecture, la sécurité, les pannes en production et la manière d’utiliser des outils d’IA devient considérablement plus compétent. Un ingénieur doté de bons outils peut désormais explorer des idées qui nécessitaient autrefois une petite équipe.
C’est excitant, mais c’est aussi dangereux, car lorsque la production de logiciels devient moins coûteuse, les logiciels de mauvaise qualité le deviennent également. Des millions d’applications écrites par l’IA pourraient bientôt exister. Les créer ne sera pas difficile. Déterminer lesquelles méritent d’exister, en revanche, le sera.
Que faire en tant que développeur aujourd’hui
Concourir avec l’IA pour taper du code, c’est une entreprise vouée à l’échec. Utilisez l’IA de manière proactive et devenez experts dans son analyse. Apprenez comment les systèmes réels échouent. Comprenez la base de données derrière l’API et ce qui se passe après le déploiement. Étudiez la sécurité ainsi que le fonctionnement des agents. Conservez la capacité de créer quelque chose sans l’IA lorsque c’est nécessaire.
Le futur ne se jouera probablement pas entre les humains et l’IA. Il s’agira plutôt d’un développeur utilisant l’IA contre un développeur qui ne l’utilise pas. Et à un niveau supérieur, les développeurs qui savent ce qu’ils doivent construire, pourquoi le construire et quand ne pas le faire pourraient s’avérer plus précieux que ceux qui se contentent de générer du code. L’IA rend le codage moins coûteux et valorise davantage le jugement technique.