Agents IA : les compétences qui restent aux ingénieurs
Les agents IA produisent du code plus vite qu’on ne peut le lire. Découvrez les compétences et méthodes nécessaires pour garder la maîtrise des systèmes.
Quand les agents écrivent le code, que doit encore savoir un ingénieur ?
Un agent de programmation peut produire en quelques minutes du code qu'un ingénieur mettrait plusieurs heures à écrire. Et il peut aussi modifier un composant sans que personne n'ait le temps d'examiner chaque ligne. Du coup, la vraie question n'est plus seulement de savoir si l'IA sait coder. Elle devient : qui comprend le système, qui repère une anomalie, et qui intervient quand le résultat ne tient pas en production.
Dans un projet récent, l'intégration continue a signalé une complexité excessive dans un fichier pourtant très court. Le code généré par l'agent était dense, mais, après inspection, la logique répondait aux besoins. On a fini par répartir la logique dans plusieurs fichiers pour satisfaire l'outil d'analyse et rendre la maintenance plus simple. Rien d'extraordinaire, mais un rappel concret : déléguer la production ne supprime pas la responsabilité technique.
Pour les équipes qui adoptent les agents, l'enjeu est de garder certaines compétences, de les développer et d'installer des contrôles. Voici un cadre simple, en trois piliers : les fondamentaux, la largeur de vue et la capacité d'approfondir au bon moment.
Que change le code produit par des agents dans la responsabilité technique ?
Les agents peuvent réduire le coût et le délai de production du code. Ils ne réduisent pas automatiquement le coût de sa compréhension, de sa validation et de sa maintenance. C'est là que le changement se fait : l'équipe peut produire plus vite, mais elle doit encore suivre au même rythme pour absorber ce qui arrive.
Dans une organisation classique, le code d'un système complexe a généralement été lu ou écrit par des gens de l'équipe, au moins à un moment de son histoire. Cette expérience ne garantissait pas une compréhension parfaite, mais elle donnait des repères. Avec des agents, une fonctionnalité peut être générée, modifiée et intégrée sans qu'un humain ait suivi chaque étape. Résultat : le système peut évoluer plus vite que la carte mentale de ceux qui en sont responsables.
La responsabilité ne se délègue pas avec la génération
Un agent peut proposer une architecture, ajouter des cas limites et exécuter des tests. Mais il ne devient pas pour autant responsable du service lorsque celui-ci ralentit, perd des données ou tombe en production. Cette responsabilité reste sur les personnes et l'organisation qui déploient le logiciel.
Prenons un exemple simple : un agent ajoute une dépendance pour accélérer une fonctionnalité. Les tests passent, mais la dépendance introduit une contrainte de licence, un risque de sécurité ou un coût opérationnel. La qualité du résultat ne se résume pas à la réussite des tests. Pour juger correctement, il faut comprendre le contexte et les conséquences.
Maîtriser un système ne veut pas dire connaître chaque ligne
Il n'existe pas de responsable qui maîtrise, dans le détail, tous les composants d'une application importante - surtout après des années d'évolution et plusieurs équipes. En pratique, les responsables s'appuient sur des abstractions : ils savent ce que fait chaque service, quelles données circulent, où se trouvent les dépendances critiques, et comment mener une enquête quand une hypothèse tombe à côté.
Cette vision d'ensemble ne remplace pas la lecture du code. Elle sert surtout à décider où regarder. Un responsable compétent sait passer d'une vue globale à un module précis, puis revenir en arrière pour évaluer l'impact d'un changement.
À retenir : la responsabilité technique ne consiste pas à relire mécaniquement chaque ligne générée. Elle consiste à vérifier que le système répond aux besoins, à repérer les signaux d'alerte et à approfondir quand les faits l'exigent.
Quelles compétences restent indispensables pour piloter un système ?
Travailler avec des agents ne rend pas les compétences d'ingénierie inutiles. Ça change plutôt leur usage. Au lieu de passer tout son temps à produire chaque morceau, un ingénieur doit apprendre à reconnaître les risques, à poser les bonnes contraintes, et à choisir où investir son temps pour analyser.
Trois compétences forment un cadre utile : les fondamentaux techniques, une connaissance suffisamment large des domaines voisins, et une capacité à approfondir un problème concret au moment où c'est nécessaire.
1. Les fondamentaux pour reconnaître les mauvais signaux
Les fondamentaux ne servent pas seulement à réussir un examen ou à écrire un algorithme à la main. Ils aident à distinguer un comportement normal d'un comportement suspect. La complexité algorithmique, les structures de données, les réseaux, la concurrence et les systèmes distribués donnent des repères pour interpréter ce qu'on observe.
Imaginons une tâche qui prend quatre secondes pour une petite entrée, seize secondes pour une entrée deux fois plus grande, puis plus de quatre minutes quand l'entrée augmente encore. Cette croissance peut faire penser à une complexité quadratique. L'objectif n'est pas d'identifier immédiatement la ligne fautive, mais de comprendre que la croissance mérite une enquête.
Ces mêmes repères servent à analyser une saturation mémoire, un verrouillage concurrent, des délais réseau, ou une reprise incorrecte après une panne. L'agent peut proposer une implémentation plausible. Les fondamentaux permettent, eux, de questionner les hypothèses et de vérifier si le comportement observé colle avec ce qu'on attend.
2. La largeur de vue pour savoir où chercher
La largeur ne veut pas dire « tout savoir en profondeur ». C'est plutôt une familiarité assez large pour poser des questions pertinentes et examiner les bonnes pistes. Une latence peut venir du code, d'une requête de base de données, d'un réseau saturé, ou d'un service tiers. Sans repères, on risque d'optimiser le mauvais endroit.
Cette largeur se construit dans la durée : incidents vécus, lectures, échanges avec des spécialistes, et curiosité pour des sujets un peu à côté. Parfois, une expérience acquise sur un autre projet devient décisive des années plus tard. Elle aide alors à reconnaître une forme de problème déjà rencontrée.
3. La profondeur à la demande pour résoudre l'inconnu
La profondeur à la demande, c'est savoir apprendre ce qui manque pour résoudre un problème précis, sans se raconter qu'on est expert dès le départ. Concrètement, il faut savoir enquêter, lire la documentation utile, construire un test minimal, et solliciter les bonnes personnes quand le sujet dépasse son champ.
Un exemple : des sous-agents s'arrêtent de manière imprévisible dans un outil d'orchestration. Plutôt que d'ajouter des relances au hasard, l'ingénieur regarde le cycle de vie du système. Il découvre alors que l'orchestrateur réagit aux événements de sortie, qui peuvent être manqués. Une approche basée sur l'état attendu - comparer régulièrement ce qui devrait se produire avec ce qui se produit réellement - peut ensuite donner une base solide pour corriger le design.
Ces piliers fonctionnent ensemble : les fondamentaux permettent de voir qu'un comportement n'est pas normal ; la largeur aide à localiser la zone à examiner ; la profondeur, elle, sert à aller au fond et corriger.
Comment former les ingénieurs sans leur faire tout écrire à la main ?
Les ingénieurs expérimentés ont souvent appris en faisant : écrire du code, le déboguer, participer aux mises en production, réparer des incidents. Cette voie reste utile, mais elle ne peut pas être le seul modèle de formation. Dans la plupart des entreprises, financer plusieurs années de pratique « à la main » avant de confier une responsabilité à quelqu'un de débutant n'est pas réaliste.
À l'inverse, dire aux équipes de ne jamais regarder le code parce que « les modèles s'en chargent » n'est pas non plus une stratégie. Ça prive les juniors d'occasions de développer leur jugement, et ça laisse les responsables sans mécanisme crédible pour vérifier ce qui a été fait.
Transformer les tâches en exercices de diagnostic
Une approche plus réaliste consiste à donner aux débutants des tâches où le code généré est un point de départ, pas une boîte noire. Ils comparent le comportement attendu au comportement réel, examinent les changements importants, et expliquent les risques avant déploiement.
Pour renforcer les réflexes de diagnostic, une équipe peut créer des exercices en environnement isolé : une requête volontairement lente, une dépendance modifiée, une erreur qui apparaît de façon intermittente, ou un composant qui ne récupère pas correctement après redémarrage. L'objectif n'est pas de piéger la personne : c'est de lui apprendre à formuler des hypothèses et à chercher des preuves.
Encadrer sans imposer une revue ligne par ligne
Relire chaque ligne du code généré peut être utile pour un changement critique ou pour quelqu'un en formation. Mais en faire une règle systématique pour tous les changements et tous les projets peut vite devenir un goulot d'étranglement. Le niveau de contrôle doit dépendre du risque.
Pour une modification limitée et réversible, des tests pertinents, une vérification du diff et une surveillance après déploiement peuvent suffire. Pour une évolution qui touche à l'authentification, aux données personnelles ou aux paiements, une revue plus approfondie et l'avis d'un spécialiste sont plus justifiés.
Un bon exercice de revue force, en pratique, à répondre à trois questions : quelle partie du système a changé ? Quel comportement pourrait se dégrader ? Quelle observation confirmerait ou infirmerait l'hypothèse ? Ces questions construisent une compréhension réutilisable, sans exiger de mémoriser tout le code.
Évaluer la capacité à apprendre dans un système inconnu
L'entretien technique peut aussi sortir du cadre « pur code ». On peut demander au candidat de raconter une fois où il a dû comprendre rapidement un système inconnu : par où a-t-il commencé, quelles hypothèses a-t-il formulées, quelles informations a-t-il cherchées, et quand a-t-il demandé de l'aide ?
La réponse en dit plus qu'une phrase comme « j'apprends vite ». Elle montre la méthode, la capacité à reconnaître ses limites, et le soin apporté à la communication. Dans une équipe qui utilise des agents, ce sont souvent ces qualités qui font la différence : anomalie traitée tôt ou panne coûteuse qui s'installe.
Quels contrôles mettre en place pour travailler avec des agents ?
La vitesse d'un agent n'a d'intérêt que si l'équipe a des moyens suffisants pour détecter les erreurs. Et ces contrôles ne doivent pas devenir une accumulation de règles abstraites : chacun doit répondre à un risque clair et produire un signal exploitable.
Définir des garde-fous proportionnés au risque
Une base de contrôle peut inclure des tests automatisés, une analyse statique, des vérifications de dépendances et des seuils sur la complexité ou les performances. Ces outils ne prouvent pas qu'un changement est correct. Ils repèrent surtout certaines classes de défauts et rendent les écarts visibles plus tôt.
Sur un service qui traite des données personnelles, le processus doit aussi tenir compte des accès, de la conservation et de la circulation des données. En Europe, le RGPD impose des obligations qui ne disparaissent pas parce qu'un agent a généré du code. L'équipe doit vérifier que les choix techniques restent compatibles avec ce cadre.
Rendre les changements compréhensibles
On peut demander à l'agent de produire un résumé des fichiers modifiés, des décisions d'architecture et des hypothèses retenues. Pour les changements importants, il vaut mieux aussi garder une trace courte : pourquoi une frontière entre composants a été déplacée, ou pourquoi une nouvelle dépendance a été ajoutée.
Ce document n'a pas besoin d'être encyclopédique. Il doit surtout rester utile au quotidien : quand un incident survient, l'équipe dispose d'un point de départ pour comprendre l'intention du changement et vérifier si le système se comporte comme prévu.
Fermer la boucle après la mise en production
Les tests avant déploiement ne couvrent pas toutes les situations réelles. La surveillance, les alertes et les mécanismes de retour arrière complètent le dispositif. Après livraison, l'équipe doit suivre des indicateurs pertinents : taux d'erreur, temps de réponse, consommation de ressources, évolution des coûts.
Si un agent a modifié un parcours critique, déployer progressivement ou limiter d'abord l'exposition peut réduire le coût d'une erreur. Oui, ça ralentit un peu la diffusion, mais ça permet de détecter un problème avant qu'il ne touche tout le monde.
Le principe est simple : plus un changement est difficile à annuler, ou plus ses conséquences sont importantes, plus la validation doit être exigeante. Un outil d'analyse ne remplace ni le jugement ni la responsabilité humaine. Il fournit surtout des alarmes utiles : celles qui indiquent quand approfondir.
Liste de vérification avant livraison
- Le comportement attendu et les critères d'acceptation sont-ils explicites ?
- Les tests couvrent-ils les scénarios qui comptent, y compris les erreurs ?
- Les dépendances et les frontières du système ont-elles changé ?
- Les effets sur la sécurité, les données et les coûts ont-ils été examinés ?
- Existe-t-il un moyen de surveiller le changement et de revenir en arrière ?
Conclusion
Les agents changent la quantité et la vitesse de code produites, pas le besoin de comprendre ce qui fait tourner les systèmes. Pour garder la maîtrise, les ingénieurs ont besoin de fondamentaux pour reconnaître les anomalies, de largeur de vue pour savoir où enquêter, et de profondeur à la demande pour résoudre les problèmes difficiles.
La bonne approche n'est pas « relire chaque ligne » ni « faire confiance sans contrôle ». C'est ajuster la revue au risque, former les équipes via le diagnostic, et conserver une responsabilité humaine claire. Déléguer la production, oui. Mais savoir quand il faut plonger, reste une compétence centrale.