Depuis plusieurs mois, on peut lire ou entendre que l’IA va remplacer les ingénieurs en développement logiciel. Ça n’a pas eu lieu — mais quelque chose de plus subtil est en train de se produire.
Le métier ne disparaît pas. Il se déplace. Et la question n’est plus “est-ce que l’IA va coder à ma place ?” mais “que reste fondamentalement mon travail quand un agent peut exécuter une tâche de bout en bout ?”
Ce déplacement est réel, il est en cours, et il mérite une lecture honnête — ni alarmiste, ni naïve.
Ce qui a déjà changé
Il y a trois ans, un ingénieur utilisait un IDE avec de l’autocomplétion. Il y a un an, il utilisait un copilote qui suggérait des blocs de code. Aujourd’hui, il travaille avec des agents capables de :
- lire un ticket Jira, comprendre la demande, écrire le code correspondant
- lancer la suite de tests, analyser les échecs, proposer des corrections
- ouvrir une pull request avec une description, un changelog et des liens vers la documentation impactée
- surveiller les logs de production, détecter une anomalie, isoler la cause probable
Ce n’est pas de la science-fiction. Ces workflows existent et tournent dans des équipes aujourd’hui. Pas parfaitement — mais suffisamment pour que la question du rôle de l’ingénieur devienne concrète.
Le glissement silencieux des compétences
Voici ce que j’observe dans les équipes qui adoptent sérieusement le développement agentique :
Ce qui perd de la valeur
La production de code mécanique. CRUD, formulaires, migrations de schéma, boilerplate d’API REST — tout ce qui suit un pattern connu est généré plus vite par un agent que par un humain. Ce n’est pas une menace, c’est un fait.
La mémorisation de syntaxe. Connaître par cœur les paramètres ou la signature exacte d’une méthode n’est plus un avantage différenciant. L’agent sait.
La recherche de bugs simples. Les erreurs de type, les null pointer, les requêtes N+1 — les agents les détectent en review avant que l’humain n’ouvre le fichier.
Ce qui prend de la valeur
La définition du contexte. C’est le changement le plus profond. Un agent est aussi bon que le contexte qu’on lui donne. Savoir formuler une contrainte métier, décrire une invariante de domaine, anticiper les edge cases dans le brief — c’est une compétence nouvelle, exigeante, et encore rare.
Le jugement architectural. Quand un agent propose trois implémentations possibles, quelqu’un doit choisir. Ce choix implique de comprendre les compromis de performance, de maintenabilité, de couplage, de coût opérationnel. L’agent génère des options. L’ingénieur tranche.
La capacité d’évaluation critique. Un agent produit du code plausible. Pas nécessairement correct. L’ingénieur qui ne sait plus lire et évaluer du code parce qu’il en écrit moins est dans une position dangereuse. La review devient plus centrale, pas moins.
La connaissance du domaine métier. C’est ce qui nous distingue, êtres humains, fondamentalement de l’IA. Comprendre pourquoi une règle de calcul de TVA a cette forme particulière, pourquoi ce workflow de validation existe, quelles contraintes légales pèsent sur ce module — ce savoir contextuel est ce que l’agent ne peut pas inférer du code seul.
L’ingénieur de contexte : un nouveau profil
Son travail consiste à fournir à l’IA les informations dont elle a besoin pour accomplir une tâche spécifique, au moment où elle en a besoin.
Un ingénieur de contexte doit savoir :
1. Écrire des briefs exploitables par un agent
Pas simplement “fais un endpoint de commande”, mais : “afin de passer une commande sur le site, crée un endpoint POST /orders qui valide que le stock est disponible avant d’insérer, lève une OrderException avec le code STOCK_UNAVAILABLE si ce n’est pas le cas, persiste en base via le OrderRepository existant, et retourne un DTO
OrderCreatedResponse. Les tests d’intégration du repository sont dans tests/Integration/OrderRepositoryTest.php, …” et bien d’autres éléments comme les user stories, les critères d’acceptance, l’architecture technique à suivre, etc.
La précision du brief détermine la qualité du résultat. C’est une compétence d’écriture autant que technique.
2. Structurer le projet pour qu’il soit lisible par des agents
Les conventions de nommage, les principes du clean code/SOLID, l’approche DDD, la documentation des décisions d’architecture — tout ce qui rendait le code lisible pour un humain le rend aussi exploitable par un agent. Un legacy spaghetti résiste aux agents comme il résiste aux ingénieurs : il faut le démêler avant.
3. Définir les contrats d’interface entre agents
Dans un système multi-agents, les interfaces entre composants doivent être explicites, versionnées, testées. L’ingénieur qui conçoit ces contrats fait un travail d’architecture au sens fort.
4. Savoir quand reprendre la main
C’est peut-être la compétence la plus difficile. Reconnaître qu’un agent est en train de dériver — qu’il optimise la mauvaise métrique, qu’il introduit une dépendance indésirable, qu’il contourne une contrainte sans la comprendre — demande une vigilance et une expérience qui ne s’automatisent pas.
L’orchestrateur : un rôle différent, pas supérieur
On entend parfois que l’ingénieur va devenir “orchestrateur d’agents” comme si c’était une promotion. C’est plus nuancé que ça.
Orchestrer des agents, c’est définir des pipelines, gérer des dépendances entre tâches, monitorer des exécutions, gérer les échecs et les retries. C’est un vrai travail d’ingénierie — mais ce n’est pas un travail de développement au sens classique.
Ce qui est vrai : les deux profils vont coexister et se compléter. Certains ingénieurs vont se spécialiser dans la construction et la supervision de systèmes agentiques. D’autres vont rester proches du code, avec un rôle de validation et d’arbitrage. Ce qui va disparaître, c’est le profil “intermédiaire” — celui qui exécute mécaniquement sans comprendre ni orienter.
Ce que ça change pour les équipes aujourd’hui
Les onboardings changent. On n’apprend plus à un nouveau à produire vite. On lui apprend à évaluer correctement, à formuler précisément, à comprendre le domaine métier en profondeur.
Les code reviews changent. La review n’est plus “est-ce que ce code est correct syntaxiquement” — les agents s’en chargent. Elle devient “est-ce que cette approche est la bonne pour ce contexte”, “est-ce que ce choix va nous coûter cher dans 6 mois”.
Les critères de recrutement changent. La capacité à écrire du code propre reste importante. La capacité à raisonner sur des systèmes complexes, à communiquer des contraintes avec précision, à évaluer des solutions sans les avoir produites — ces critères montent.
La documentation redevient stratégique. Un projet bien documenté est un projet qu’un agent peut comprendre et sur lequel il peut agir efficacement. La documentation n’est plus une corvée post-livraison — c’est une condition d’exploitabilité. Et l’IA est à ce titre très pertinente pour accélérer sa production, c’est donc gagnant-gagnant : l’IA génère et tient à jour la documentation technique et fonctionnelle utile aux métiers, au produit et à l’équipe projet, et cette documentation nourrit l’IA elle-même pour produire les fonctionnalités attendues en respectant les guidelines techniques.
Ce qui ne change pas
Il faut être clair sur ce point pour éviter les conclusions hâtives.
La responsabilité ne se délègue pas à un agent. Si un système en production fait une erreur, ce n’est pas l’agent qui est responsable — c’est l’équipe qui l’a déployé, configuré, laissé agir. Cette responsabilité exige une compréhension profonde de ce que le système fait.
La confiance client ne s’automatise pas. Un client qui confie son produit à une équipe technique attend un interlocuteur qui comprend ses enjeux, pas un pipeline qui exécute des tickets. La relation, le jugement, la capacité à dire “cette approche est risquée pour votre contexte” — c’est irréductiblement humain.
L’innovation ne vient pas (que) des agents. Les agents optimisent dans l’espace des solutions connues. Les ruptures architecturales, les décisions de refonte, les paris technologiques — ils viennent d’ingénieurs qui comprennent un problème en profondeur et imaginent une solution qui n’existe pas encore.
Conclusion
Le métier d’ingénieur ne disparaît pas en 2026. Il se redéfinit autour de ce que les agents ne font pas bien : comprendre le contexte, porter un jugement, assumer une responsabilité, innover.
L’ingénieur qui s’adapte n’est pas celui qui utilise le plus d’agents. C’est celui qui sait exactement ce qu’il leur délègue, pourquoi, et comment il vérifie que c’est bien fait.
C’est une exigence plus haute, pas plus basse. Et c’est une bonne nouvelle pour ceux qui ont toujours voulu faire de l’ingénierie au sens fort du terme — pas seulement implémenter des specs.
La prochaine fois que vous relisez une PR générée par un agent, posez-vous cette question : “Est-ce que je comprends suffisamment ce code pour en être responsable ?” Si la réponse est non, le problème n’est pas l’agent.
L’évolution du métier d’ingénieur logiciel face à l’IA agentique was originally published in ekino-france on Medium, where people are continuing the conversation by highlighting and responding to this story.
