Écrire une fonction, corriger un bug, exécuter des tests, modifier plusieurs fichiers et ouvrir une pull request : les agents de programmation dépassent désormais la simple suggestion de code. Mais cette capacité à enchaîner des actions ne suffit pas à garantir un logiciel fiable, sécurisé ou adapté aux besoins de ses utilisateurs. Pour le développeur, la transformation est moins celle d’une disparition que d’un déplacement des responsabilités, de l’écriture vers la conception, la vérification et la maîtrise des systèmes automatisés.
Du code écrit ligne par ligne au développement agentique
Pendant longtemps, le développement informatique s’est organisé autour d’un travail de traduction : transformer un besoin métier en spécifications, choisir une architecture, écrire des instructions, tester leur comportement puis maintenir l’application. Le développeur ne se contente pourtant pas de produire du texte dans un langage informatique. Il doit comprendre des contraintes parfois contradictoires, anticiper les usages, protéger les données et faire évoluer un système sans dégrader ses fonctions existantes.
L’assistance par intelligence artificielle a d’abord été popularisée sous la forme de suggestions dans l’éditeur : compléter une instruction, proposer une fonction, expliquer un message d’erreur. La rupture récente tient à l’essor des agents de programmation, capables, lorsqu’ils disposent des autorisations et outils appropriés, de parcourir un dépôt de code, modifier des fichiers, lancer des commandes, exécuter des tests et soumettre des changements à une équipe. GitHub documente ainsi un agent cloud auquel on peut confier une issue et qui prépare une pull request destinée à être examinée. OpenAI présente Codex comme un agent pouvant travailler sur des tâches de génie logiciel dans un environnement isolé. [1] [2]
Dans cet article, « autonome » désigne une autonomie opérationnelle limitée : l’agent peut organiser et exécuter plusieurs étapes à l’intérieur d’un périmètre défini. Ce terme ne signifie ni qu’il comprend l’ensemble des enjeux de l’entreprise, ni qu’il porte une responsabilité professionnelle, ni qu’il devrait pouvoir déployer sans contrôle une modification en production.
Le contraste entre adoption et confiance est révélateur. Dans son enquête 2025, Stack Overflow indique que 84 % des répondants utilisent ou envisagent d’utiliser des outils d’IA dans leur processus de développement, mais 46 % déclarent ne pas faire confiance à l’exactitude de leurs réponses, contre 33 % qui leur font confiance. Il s’agit de déclarations recueillies auprès des répondants à l’enquête, non d’une mesure universelle de la qualité du code produit. [3]
Automatiser l’écriture d’un programme n’équivaut pas à automatiser la compréhension du problème qu’il doit résoudre.
Comment l’IA transforme les pratiques du développeur
Les outils agentiques s’insèrent dans plusieurs moments du cycle de développement logiciel. Leur intérêt dépend toutefois du contexte du projet, de la qualité des tests et de la possibilité de contrôler les actions entreprises.
Compréhension d’un code existant
Un agent peut explorer l’arborescence d’un dépôt, retrouver des fonctions liées à une fonctionnalité et proposer une synthèse de leurs interactions. Cette synthèse constitue une hypothèse de travail à vérifier, notamment lorsque la logique métier n’est pas explicitement documentée.
Création de fonctionnalités
À partir d’une issue ou d’une spécification, il peut proposer plusieurs modifications coordonnées, ajouter des fichiers et préparer un diff. GitHub décrit explicitement le passage d’une issue à une pull request, soumise ensuite à la revue de l’équipe[1].
Débogage et maintenance
L’agent peut reproduire une erreur, rechercher une cause possible, modifier une implémentation et relancer des tests. Un test qui passe ne prouve toutefois pas que tous les scénarios métier ou de sécurité sont couverts.
Tests et qualité
Génération de tests unitaires, identification de cas limites, exécution de linters et vérifications de types. La documentation de Codex mentionne ces actions dans un environnement d’exécution contrôlé[2].
Documentation et refactorisation
Production de descriptions de fonctions, préparation de migrations ou restructuration de modules. Les modifications restent à confronter aux conventions du projet, aux exigences de performance et à la dette technique.
Travail asynchrone
Plusieurs tâches délimitées peuvent être déléguées en parallèle. Ce fonctionnement impose une gestion rigoureuse des branches, des conflits, de la traçabilité et des critères d’acceptation.
Prenons un exemple fictif. Une équipe souhaite ajouter un filtre de recherche dans une application de réservation. L’agent identifie les composants concernés, modifie l’interface, adapte une requête et crée des tests. Le développeur vérifie ensuite la pertinence du comportement, les temps de réponse, l’accessibilité du formulaire, les droits d’accès et les effets sur les autres parcours. Le résultat ne peut être considéré comme prêt à déployer au seul motif que l’agent annonce avoir terminé.
Les éditeurs de ces outils présentent de nombreux usages, mais leur documentation constitue d’abord une description de capacités produit. Elle ne démontre pas que chaque fonctionnalité sera exécutée correctement dans un système complexe. La valeur du travail agentique se mesure au résultat validé, pas au nombre de fichiers modifiés.
Un nouveau rôle pour le développeur
Le développeur pourrait consacrer une part plus importante de son temps à formuler le problème, définir des critères d’acceptation, examiner les modifications et résoudre les situations que l’agent traite mal. Ce déplacement n’est ni uniforme ni automatique : certaines tâches restent plus rapides à réaliser directement, et les équipes ne disposent pas toutes d’une infrastructure de test suffisante pour déléguer efficacement.
Transformer le besoin en exigences testables
Le premier changement concerne la formulation du besoin. Un agent travaille mieux lorsqu’il reçoit un objectif circonscrit, un périmètre de fichiers, des contraintes explicites et une définition du résultat attendu. La compétence n’est pas seulement de « bien prompter », mais de transformer une demande floue en exigences testables. Une instruction « améliore les performances » est insuffisante si l’on ne précise ni la métrique, ni le seuil, ni les compromis autorisés.
Examiner les modifications avec un regard critique
Le deuxième changement touche à la revue du code. Examiner un diff produit en quelques minutes demande parfois autant d’attention qu’une modification humaine. Le développeur doit reconstruire le raisonnement implicite, vérifier les hypothèses et refuser les changements inutiles. La revue ne doit pas se limiter à une approbation superficielle sous prétexte que les tests automatisés sont verts.
Orchestrer les tâches et fixer les limites
Le troisième changement concerne l’orchestration. Confier plusieurs tâches en parallèle peut accélérer des travaux indépendants, mais peut aussi multiplier les conflits, les incohérences de conception et les coûts de vérification. L’équipe doit déterminer quelles opérations restent locales, lesquelles exigent une validation préalable et lesquelles ne doivent jamais être exécutées par un agent.
Assumer la responsabilité du logiciel livré
Enfin, la responsabilité demeure attachée aux personnes et aux organisations qui conçoivent, valident et exploitent le logiciel. GitHub rappelle expressément que le code généré par son agent doit être revu et testé avant fusion, notamment pour détecter des erreurs, vulnérabilités et questions de propriété intellectuelle[4].
Quelles compétences pour le développeur à l’ère de l’IA générative ?
La maîtrise des langages, des structures de données et des principes d’architecture reste indispensable. Un développeur incapable d’évaluer un résultat généré perdrait précisément la capacité de supervision dont dépend la fiabilité du dispositif. Les nouvelles compétences prolongent donc le socle classique au lieu de le remplacer.
Compétences techniques et analytiques
- Architecture et compréhension du système : lire les dépendances, anticiper les effets d’une modification, identifier les interfaces critiques et préserver la cohérence entre services.
- Spécification et découpage : transformer une demande métier en tâches suffisamment délimitées, accompagnées de critères d’acceptation vérifiables.
- Tests et évaluation : écrire des tests significatifs, distinguer couverture et qualité, construire des jeux de cas limites et interpréter les échecs plutôt que se fier à un verdict automatique.
Sécurité et gouvernance des données
- Sécurité du développement : appliquer le principe du moindre privilège, protéger les secrets, vérifier les dépendances et contrôler l’exécution de commandes ou l’accès aux systèmes.
- Gestion des données et confidentialité : savoir quelles informations du dépôt peuvent être envoyées à un fournisseur externe et respecter les règles internes, contractuelles et, le cas échéant, le RGPD.
Compétences collaboratives et transmission
- Collaboration et transmission : documenter les décisions, expliquer les arbitrages, assurer une revue contradictoire et maintenir les compétences des développeurs juniors.
Une compétence transversale devient particulièrement importante : savoir interrompre l’automatisation. Lorsqu’un agent multiplie les essais, touche à des composants hors périmètre ou propose une correction incompréhensible, la bonne décision peut être de revenir à une analyse humaine plus lente, mais plus maîtrisée.
Le risque pédagogique est réel : un développeur débutant qui accepte des modifications sans comprendre les mécanismes sous-jacents peut progresser dans l’usage de l’outil sans progresser au même rythme en conception et en débogage. L’apprentissage doit donc combiner usage raisonné de l’IA, lecture de code, exercices sans assistance et revue par des pairs.
L’intelligence artificielle peut-elle rendre le développement logiciel plus fiable ?
Il faut distinguer trois résultats : produire du code plus vite, produire du code correct et produire un système fiable en exploitation. Ces dimensions ne sont pas interchangeables. Un agent peut réduire le temps nécessaire à une modification simple tout en introduisant une faille de contrôle d’accès ou une régression difficile à détecter.
Les données disponibles invitent à la prudence. Dans l’enquête Stack Overflow 2025, environ 69 % des utilisateurs d’agents déclarent percevoir un gain de productivité. Il s’agit d’un ressenti, et non d’une mesure causale. À l’inverse, une étude randomisée publiée par METR en juillet 2025, portant sur 16 développeurs expérimentés et 246 tâches dans des projets open source familiers, a observé un allongement moyen de 19 % du temps de réalisation lorsque les outils d’IA de l’époque étaient autorisés. Les auteurs soulignent eux-mêmes que cette étude ne représente pas tous les projets ni les générations ultérieures d’outils. [3] [5]
Ces résultats ne sont pas nécessairement contradictoires. Le gain dépend du type de tâche, du contexte disponible, du niveau d’expertise, du coût de vérification et de la qualité des outils. Une fonction isolée, fortement testée, ne pose pas les mêmes difficultés qu’une migration de données critique ou une refonte d’architecture.
Sur le plan de la sécurité, les agents créent une surface de risque supplémentaire : ils peuvent lire des fichiers, lancer des commandes et utiliser des services connectés. L’OWASP identifie, dans son référentiel consacré aux applications agentiques, des risques tels que le détournement d’objectif, le mauvais usage des outils, l’abus de privilèges et l’exécution inattendue de code. [6]
Une mesure de maîtrise consiste à limiter les droits de l’agent au strict nécessaire, à isoler son environnement, à exiger une revue humaine pour les changements sensibles, à analyser les dépendances et à conserver des journaux d’exécution. Un prompt demandant à l’agent d’être prudent ne remplace pas une restriction technique des permissions.
La fiabilité ne se réduit pas non plus au nombre de tests réussis. Des tests générés par le même système que le code peuvent reproduire ses hypothèses erronées. Il faut donc des exigences indépendantes, des contrôles de sécurité et, pour les composants critiques, des évaluations humaines approfondies.
Le critère pertinent est celui de la qualité mesurée après intégration : défauts détectés, incidents, temps de maintenance, régressions, performance, sécurité et satisfaction des utilisateurs. À ce stade, aucune conclusion générale ne permet d’affirmer que le développement agentique rend systématiquement les logiciels plus sûrs.
MSc IA Génératives
et Agentiques
Devenez expert des IA génératives et agentiques : LLMs, transformers, déploiement en entreprise. Learning trip Silicon Valley inclus. Titre RNCP niveau 7 (Bac+6).
À quoi ressemblera le métier de développeur demain avec l’IA ?
- Plusieurs trajectoires se dessinent. La première est l’intégration des agents au cycle de vie du logiciel, depuis l’issue jusqu’à la proposition de changement. La deuxième est le développement de workflows dans lesquels plusieurs agents travaillent sur des tâches distinctes, sous la supervision d’un professionnel chargé de gérer leurs interactions. La troisième est l’augmentation des exigences de gouvernance autour des accès, de la traçabilité et des validations.
- Les développeurs pourraient devenir davantage responsables de la définition de problèmes, de l’architecture, de l’évaluation et de la sécurité, sans cesser de programmer. Les tâches répétitives et bien délimitées sont de bonnes candidates à l’automatisation ; les décisions qui exigent compréhension du métier, négociation de compromis et responsabilité opérationnelle résistent davantage à une délégation complète.
- Le terme « développeur augmenté » ne doit cependant pas masquer les effets possibles sur l’emploi et la formation. Certaines tâches traditionnellement confiées à des juniors peuvent être automatisées, ce qui oblige les entreprises à repenser l’apprentissage en situation professionnelle. À l’inverse, l’augmentation du volume de logiciels produits pourrait créer de nouveaux besoins de revue, d’intégration et de maintenance. Le solde net sur l’emploi reste incertain et dépendra des secteurs, de l’organisation du travail et de la demande.
- L’évolution des performances mesurées sur des benchmarks de programmation ne suffit pas à prévoir cette transformation. Résoudre un problème de code dans un environnement d’évaluation ne garantit ni la compréhension des exigences tacites d’une entreprise ni la capacité à gérer un incident réel. Les indicateurs devront intégrer les coûts de supervision et la qualité des logiciels après livraison.
- Dans un scénario crédible, une équipe définit une tâche, l’agent propose une implémentation sur une branche isolée, la chaîne d’intégration continue exécute les contrôles, puis un développeur vérifie le comportement et autorise la fusion. Ce scénario est déjà proche des workflows documentés par certains fournisseurs, mais son efficacité à grande échelle reste à évaluer organisation par organisation.1, 4
Un code de plus en plus automatisé, mais toujours sous responsabilité humaine
L’IA générative a franchi une étape : elle ne se limite plus à suggérer une ligne de code. Elle peut prendre en charge une séquence d’actions techniques, explorer un dépôt, exécuter des tests et soumettre une proposition. Cette progression change les gestes du métier et oblige les équipes à préciser ce qu’elles souhaitent déléguer.
Mais un logiciel ne vaut pas seulement par sa capacité à s’exécuter. Il doit respecter une intention, servir des utilisateurs, protéger des données, résister aux erreurs et pouvoir être maintenu. Ces exigences supposent des décisions qui ne se réduisent pas à la production d’instructions informatiques.
Le développeur ne devient donc pas simplement le superviseur passif d’une machine qui coderait à sa place. Il reste l’interprète des besoins, l’architecte des compromis, le responsable de la vérification et un interlocuteur essentiel des équipes métiers. Lorsque l’agent accélère une tâche, cette vitesse n’a de valeur que si le résultat demeure compréhensible et maîtrisable.
L’IA peut écrire du code. Le développeur reste responsable de sa compréhension, de sa fiabilité et de ses conséquences.
La question centrale n’est peut-être plus de savoir si une IA peut écrire du code, mais qui saura encore expliquer, tester et assumer ce code lorsqu’il fonctionnera au cœur des organisations.
Pour aller plus loin
Pour approfondir les enjeux de la programmation assistée, des agents IA et des métiers techniques , découvrez ces analyses complémentaires du blog aivancity.
Références
[1] GitHub Docs. Kick off a task with Copilot agents on GitHub. Documentation produit. Consulter la documentation
[2] OpenAI. Introducing Codex (2025) ; Codex is now generally available (2025). Documentation et annonces éditeur. Consulter la source
[3] Stack Overflow. (2025). 2025 Developer Survey, sections AI tools et AI Agents. Enquête déclarative. Consulter l’enquête
[4] GitHub Docs. Application card: GitHub Copilot Agents. Responsible use and limitations. Consulter la documentation
[5] METR, Becker et al. (10 juillet 2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Étude randomisée. Consulter l’étude
[6] OWASP Gen AI Security Project. (9 décembre 2025). Top 10 for Agentic Applications. Référentiel de risques. Consulter le référentiel