Coder avec l'IA : comprendre les agents et savoir déléguer

Pour un responsable technique, le bon point de départ est une tâche délimitée, sur une branche isolée, avec des critères d'acceptation explicites, des contrôles automatisés et une personne désignée pour la revue. Accordez davantage d'autonomie lorsque ce processus produit des modifications que vous pouvez accepter en confiance.

Les comportements des outils présentés ci-dessous ont été vérifiés dans la documentation en ligne de leurs éditeurs le 24 octobre 2026. Les règles de délégation et l'exemple d'export de factures relèvent de l'analyse éditoriale, pas d'un essai des produits.

Qu'est-ce que la programmation agentique ?

La programmation agentique confie à un système d'IA une suite d'actions de développement, chacune guidée par le résultat des précédentes. L'agent examine le code, prépare une modification, édite des fichiers, lance des commandes et des tests, lit leurs résultats, puis ajuste son action suivante. Il peut s'arrêter parce qu'il a terminé, qu'une limite d'autorisation le bloque ou qu'une décision est nécessaire.

Anthropic décrit ce cycle en trois temps : recueillir le contexte, agir et vérifier. Le point décisif consiste à réinjecter le résultat d'un outil dans la décision suivante : un test qui échoue donne à l'agent un élément concret pour corriger le code. Une simple suggestion de code ne suffit pas à créer cette boucle. La boucle agentique de Claude Code.

Prenez un artisan chargé de rénover une pièce. Le cahier des charges définit le résultat attendu, les clés déterminent les accès et l'inspection permet de réceptionner les travaux. Lui donner davantage de clés ne garantit pas la qualité de la rénovation. Les agents de code ont besoin de la même séparation entre consignes, accès et vérification.

Un agent a aussi besoin d'un harness, la couche logicielle qui entoure le modèle, lui fournit des outils et gère son contexte de travail. Le modèle propose des actions ; le harness exécute les appels d'outils autorisés et lui renvoie les résultats. Changer de modèle ne modifie pas automatiquement les règles d'accès de l'environnement.

Qu'est-ce qui distingue un agent de code de l'autocomplétion et du chat ?

La différence tient à celui qui assure le passage d'une étape à l'autre. L'autocomplétion suggère du texte pendant que vous écrivez. Un simple échange dans un chat peut expliquer du code ou proposer un correctif ; à vous de le copier, de l'exécuter et de le valider. Un agent qui dispose d'un accès au dépôt et aux commandes peut enchaîner ces étapes et examiner ce qui s'est passé.

L'interface ne définit pas l'agent. Une fenêtre de chat peut en accueillir un, tout comme un terminal. Regardez les outils disponibles, la boucle de retour des résultats et les pouvoirs accordés à la session.

Programmation agentique et vibe coding : quelle différence ?

La programmation agentique décrit le fonctionnement de l'outil. Le vibe coding désigne généralement une façon de travailler : orienter un logiciel généré surtout à partir de prompts et du comportement observé, parfois en examinant très peu son implémentation. Les deux notions se recoupent dans la pratique, mais ne répondent pas à la même question.

Vous pouvez utiliser un agent tout en relisant chaque modification et en maintenant des tests rigoureux. Vous pouvez aussi accepter du code généré presque sans le contrôler. Pour un prototype jetable, cette seconde approche peut être un compromis assumé. Dès qu'il est question de données clients ou de paiements, comprendre l'implémentation fait partie de vos responsabilités. Le guide des outils de vibe coding présente plus largement les outils de création d'applications et de développement.

Que peuvent faire les agents de code ?

Les principaux outils proposent une boucle d'action similaire dans des environnements de travail différents. Leurs capacités documentées indiquent ce que vous pouvez déléguer ; elles ne disent pas quelle quantité de travail sans supervision votre dépôt peut supporter.

Claude Code

Claude Code, l'agent de code d'Anthropic, peut explorer un projet, lire et modifier des fichiers, lancer des commandes et exécuter des tests. Sa documentation décrit une boucle qui adapte sa trajectoire à ce que chaque résultat d'outil lui apprend. La correction d'un bug bien circonscrit s'y prête donc naturellement : enquêter sur le problème, modifier le code concerné et vérifier le comportement obtenu. Documentation de Claude Code.

La limite pratique, c'est le contexte manquant ou oublié. Anthropic documente une fenêtre de contexte finie et sa compression lors des longues sessions. Consignez les contraintes durables dans les instructions du projet et gardez chaque modification ciblée : une longue conversation remplace mal un critère d'acceptation. Notre guide des bonnes pratiques de Claude Code détaille ce workflow.

OpenAI Codex

OpenAI Codex, l'agent de code d'OpenAI, propose une interface en ligne de commande (CLI) capable d'inspecter un dépôt, de préparer une modification, d'éditer des fichiers et d'exécuter des commandes de développement en local. Il offre également un mode de revue dédié aux modifications non commitées, à un commit ou à une comparaison avec une branche de référence. Documentation de Codex CLI.

La limite pratique, c'est l'environnement d'exécution. Un contrôle qui dépend d'un service indisponible ou d'un accès réseau bloqué ne peut pas apporter la preuve attendue. Signalez-le comme non vérifié, puis reproduisez-le dans l'environnement adapté. Le comparatif Codex et Claude Code aide à choisir le produit ; les paramètres d'autorisation méritent une décision distincte.

Cursor Agent

Cursor Agent, l'agent de code intégré à l'éditeur Cursor, peut explorer le code, modifier des fichiers et lancer des commandes dans le terminal. Il convient à un workflow interactif, dans lequel vous orientez la modification tout en examinant le travail. Ce sont des actions documentées, pas la promesse qu'une fonctionnalité sera correcte. Présentation de Cursor Agent.

Il faut bien comprendre sa limite immédiate : les modifications ordinaires de l'espace de travail sont enregistrées sur disque sans approbation, tandis que les fichiers de configuration bénéficient d'une protection supplémentaire. Cursor prévient qu'une application avec rechargement automatique peut exécuter le code modifié avant que vous l'ayez relu. Utilisez un environnement de développement dont les données et les identifiants d'accès sont adaptés à ce fonctionnement. Sécurité de Cursor Agent.

L'agent de code de GitHub Copilot

L'agent de code de GitHub Copilot, appelé Copilot cloud agent dans la documentation actuelle, peut explorer un dépôt, planifier des modifications, éditer des fichiers et exécuter des tests et des linters dans un environnement cloud éphémère. Il peut préparer des branches, des commits et des pull requests. Ce fonctionnement est distinct des suggestions reçues dans un IDE ou d'une demande de revue adressée à Copilot sur une pull request existante. Copilot sur GitHub.com.

La limite pratique se situe au moment de passer le relais. GitHub prévient que les modifications générées peuvent être inexactes ou présenter des failles de sécurité et qu'elles doivent être relues et testées. Une session terminée signifie qu'un travail est prêt à être évalué, pas que vos critères d'acceptation sont satisfaits. Recommandations de GitHub pour un usage responsable.

Pour le détail des offres, consultez nos pages sur les tarifs de Claude Code, de Codex, de Cursor et de GitHub Copilot.

Coder avec l'IA : partir d'un cahier des charges vérifiable

Une spécification utile indique à l'agent ce qui doit rester vrai, autant que ce qui doit changer. « Ajouter un export CSV » laisse des décisions essentielles en suspens. L'agent peut produire un téléchargement fonctionnel tout en appliquant de mauvaises règles d'accès.

Prenons un produit de facturation fictif utilisé par plusieurs organisations clientes distinctes. Vous souhaitez qu'un administrateur de compte puisse exporter des factures. Une consigne exploitable préciserait :

• Résultat attendu : un administrateur autorisé peut télécharger les factures visibles avec les filtres actifs.
• Règle d'accès : une organisation ne doit jamais recevoir les factures d'une autre, même au moyen d'une requête manipulée.
• Comportement à préserver : les autorisations et les règles de filtrage existantes des factures continuent de faire foi.
• Périmètre : reprendre les conventions existantes d'autorisation et d'export ; éviter les refactorisations ou les dépendances sans rapport avec la tâche.
• Preuves attendues : montrer les cas autorisés et refusés, une tentative d'accès aux données d'une autre organisation, un résultat vide et les contrôles existants pertinents.
• Condition d'arrêt : demander une décision si la politique d'accès est ambiguë ou si le correctif exige de modifier un mécanisme d'autorisation partagé.

Cette consigne laisse les choix d'implémentation ouverts tout en fixant le comportement attendu du produit. Si le travail révèle une règle manquante, tranchez et mettez la spécification à jour. Ne laissez pas un hasard d'implémentation devenir silencieusement la règle. Notre guide du développement piloté par les spécifications explique comment maintenir cette cohérence.

La documentation des bonnes pratiques d'Anthropic recommande de donner à l'agent un moyen de vérifier son travail. Dans ses conseils de praticien, Armin Ronacher insiste sur des outils rapides et compréhensibles, ainsi que sur des logs utiles. La leçon pratique : rendre les échecs observables. Un refus d'autorisation lisible aide l'agent à corriger son travail ; une commande qui reste bloquée lui donne peu d'indications.

Autorisations et sandbox : des limites différentes

Les autorisations régissent les actions permises ; la sandbox limite leur portée ; les règles de branche et de revue encadrent l'acceptation. Configurez ces trois niveaux. Un prompt disant « ne touche pas à la production » ne remplace pas l'absence d'accès à la production.

Une politique d'approbation détermine quelles actions nécessitent une autorisation. Une sandbox impose des limites d'exécution sur des ressources telles que les fichiers accessibles en écriture et les connexions réseau sortantes. Aucune des deux ne vérifie que l'export de factures respecte vos règles métier.

Vérifier les paramètres effectifs de chaque outil

Pour Claude Code, Anthropic documente une isolation du système de fichiers et du réseau pour les commandes exécutées dans la sandbox, y compris leurs sous-processus. La documentation décrit aussi un mécanisme permettant de retenter une commande hors sandbox. Avant de considérer cette isolation comme obligatoire, examinez cette possibilité de sortie, les exclusions de commandes et le comportement prévu si la sandbox ne peut pas démarrer. Limiter l'écriture ne signifie pas automatiquement que les fichiers sensibles sont illisibles. Sandbox de Claude Code.

Pour Codex CLI, le mode workspace-write avec des approbations on-request permet de travailler dans l'espace de travail, tandis que l'accès réseau des commandes reste désactivé par défaut, sauf activation explicite. La politique d'approbation et le mode de sandbox sont des paramètres distincts : désactiver les demandes d'approbation ne supprime pas en soi la sandbox. La politique réseau des commandes ne régit pas non plus, à elle seule, la recherche web hébergée, les apps ou les connexions MCP, qui relient l'agent à des outils et services externes. Examinez ces voies d'accès séparément. Approbations et sécurité de Codex.

Pour Cursor Agent, les commandes du terminal nécessitent une approbation par défaut. Ses Run Modes configurables sont toutefois présentés comme des garde-fous sans garantie absolue, plutôt que comme une frontière de sécurité stricte. Cette distinction compte si vous envisagez de laisser des commandes s'exécuter sans surveillance. Tenez compte de l'avertissement sur le rechargement automatique évoqué plus haut, autant que de l'exécution dans le terminal. Sécurité de Cursor Agent.

Pour GitHub Copilot cloud agent, GitHub documente des droits limités sur les branches, qui empêchent les envois directs vers la branche par défaut. La documentation prévoit aussi un pare-feu par défaut et l'approbation d'un utilisateur disposant d'un accès en écriture avant l'exécution des workflows Actions déclenchés par les pull requests de l'agent. Les secrets Actions généraux du dépôt et de l'organisation ne sont pas transmis à l'agent ; ceux qui sont ajoutés expressément à l'environnement copilot le sont. Vérifiez ce que vous y placez. Protections documentées par GitHub.

Adapter les accès à la tâche

Pour l'export de factures, l'agent a besoin du code source, des dépendances de développement et de factures synthétiques. Il ne devrait pas avoir besoin de vraies factures clients, d'identifiants de base de données de production ni du pouvoir de déployer. Accordez-lui le minimum d'accès aux ressources qui lui permette de reproduire et de vérifier le comportement.

Considérez les textes du dépôt, les pages récupérées et le contenu des tickets comme des entrées potentiellement non fiables. Il y a injection de prompt lorsqu'un contenu malveillant tente de détourner les actions de l'agent. Une instruction cachée dans un document ne doit pas acquérir l'autorité de votre consigne de travail. Les recommandations de sécurité des éditeurs signalent ce risque ; limiter les ressources accessibles en réduit les conséquences possibles. Modèle de sécurité de Cursor.

Revue de code : examiner le diff et les preuves

Examinez le comportement modifié et les contrôles censés le valider. Le résumé de l'agent aide à s'orienter, mais ce n'est pas ce résumé que vous approuvez.

Partez des critères d'acceptation. Pour l'export de factures, suivez la façon dont l'organisation associée à la requête est déterminée, dont l'autorisation est vérifiée et dont la requête d'export applique la même limite. Examinez ensuite les tests. Un test qui n'utilise que les données d'une seule organisation ne peut pas démontrer la séparation entre organisations.

Cherchez ensuite ce qui aurait pu affaiblir les preuves dans le correctif : assertions supprimées, tests désormais ignorés, mocks plus permissifs, snapshots modifiés ou configuration de CI retouchée. Une suite de tests peut passer au vert parce que l'implémentation s'est améliorée ou parce que le contrôle est devenu moins exigeant. Le diff permet de savoir lequel des deux s'est produit.

Dans une copie de travail du dépôt contenant des modifications non commitées, ces commandes Git permettent une première inspection :

git status --short
git diff --stat
git diff --check
git diff
git diff --cached

git status signale aussi les fichiers non suivis, dont le contenu doit être examiné séparément. Ces commandes n'exécutent pas les tests de l'application. Si le travail de l'agent a déjà été commité, examinez le diff complet de la pull request, entre sa base et sa version finale, puis lancez les contrôles documentés du dépôt dans un environnement propre.

Une transmission utile précise les commandes exactes exécutées, leurs résultats, les sorties pertinentes en cas d'échec ou de réussite, ainsi que les contrôles qui n'ont pas pu être lancés. « Les tests passent », sans indiquer lesquels, laisse la personne chargée de la revue deviner la couverture réelle. Un échec de préparation de l'environnement empêche d'obtenir une preuve ; il ne prouve pas que le code fonctionne.

Dans 10 leçons sur la programmation agentique, Drew Breunig défend les tests du comportement produit, l'intention documentée et les spécifications qui évoluent avec l'implémentation. Dans notre exemple, le contrôle durable consiste à vérifier qu'un client ne peut pas exporter les factures d'un autre. La fonction utilitaire choisie pour faire respecter cette règle peut changer.

Une revue automatisée peut apporter d'autres observations, mais la personne qui accepte la modification doit en comprendre le cheminement critique. GitHub prévient explicitement qu'une revue par IA peut manquer des problèmes et produire des faux positifs. Gardez une personne responsable de la revue des comportements sensibles pour la sécurité et de la maintenabilité. Limites de la revue selon GitHub.

Qui peut déléguer davantage, et qui devrait attendre ?

Déléguez davantage lorsque la réussite de la tâche est clairement définie, que les erreurs restent contenues et que la revue demeure maîtrisable. Les règles ci-dessous constituent une proposition d'organisation du travail technique, pas une garantie de capacité fournie par un éditeur.

Les responsables techniques disposant d'une CI fiable peuvent se lancer dès maintenant. Commencez par des modifications qui reprennent des modèles existants. Désignez un responsable pour chaque pull request générée par l'agent et réduisez la taille des tâches si la revue devient difficile à suivre. Des contrôles réussis ne sont utiles que s'ils couvrent le comportement qui compte.

Les fondateurs qui construisent un prototype peuvent largement déléguer l'implémentation dans un environnement jetable. Utilisez des données synthétiques et acceptez que le code exploratoire puisse être remplacé. Avant d'ajouter des comptes clients ou des transferts d'argent, faites intervenir quelqu'un capable d'évaluer les règles d'accès, la gestion des échecs et les conséquences en exploitation.

Les responsables d'un système ancien mal compris devraient d'abord renforcer les moyens de vérification. Un agent peut aider à explorer les comportements et à proposer des tests. En revanche, commencer par des refactorisations sans supervision est peu judicieux lorsque personne ne sait distinguer un comportement voulu d'un accident. Établissez l'état de référence avant d'élargir l'autonomie.

Les personnes satisfaites de l'autocomplétion n'ont pas besoin de changer leur façon de traiter chaque tâche. Une petite modification évidente peut être plus rapide à faire directement. Le coût de la délégation se justifie lorsqu'on peut confier une véritable séquence d'enquête, de modification et de vérification.

Où sont les limites, et que faut-il relativiser ?

La boucle échoue lorsque les retours ne permettent pas de distinguer une solution correcte d'une solution plausible. Un contrôle au vert peut valider la mise en forme sans rien dire de l'isolation entre clients, c'est-à-dire de la séparation de leurs données. Un test réussi avec des mocks peut passer à côté de l'intégration réellement utilisée par les clients. Un résumé convaincant peut omettre une commande qui a échoué.

Le contexte impose une autre limite. L'agent peut voir la fonction concernée sans comprendre pourquoi une contrainte inhabituelle existe. Placez les décisions importantes à proximité du travail, indiquez quelle spécification fait autorité et demandez que les incertitudes soient signalées. La documentation d'Anthropic décrit la gestion d'un contexte limité au cours des longues sessions ; ne supposez pas qu'une consigne donnée au début de la conversation conserve le même poids pendant toute une modification importante. Fonctionnement de Claude Code.

Multiplier les agents ajoute aussi du travail de coordination. Si des sessions distinctes modifient les mêmes fichiers, la même interface ou le même état de base de données, une réussite locale peut tout de même entrer en conflit avec une autre modification. Utilisez des copies de travail séparées et attribuez explicitement la responsabilité de l'intégration. Parallélisez les enquêtes indépendantes avant les implémentations étroitement liées.

L'échec plus général consiste à accepter une complexité que personne n'avait prévu de maintenir. Une nouvelle abstraction, une dépendance ou une tâche de fond devient votre responsabilité en exploitation, même si sa génération a été facile. Demandez-vous si la modification résout la tâche sans ajouter une complexité disproportionnée.

Ce que les benchmarks de programmation agentique ne démontrent pas

Un benchmark de code ne démontre pas, à lui seul, que votre équipe livrera plus efficacement. Pour transposer un résultat publié, il faudrait comprendre les tâches, le contexte du dépôt, les outils, la politique de nouvelles tentatives et la définition de la réussite. Le pourcentage de productivité annoncé par un éditeur ne constitue pas une prévision pour votre code.

Pour votre propre expérimentation, consignez le temps écoulé jusqu'à l'acceptation d'une modification, l'effort de revue, les reprises nécessaires, les défauts découverts après fusion et les exécutions bloquées. Comparez des types de tâches similaires et conservez les échecs dans le bilan. Il s'agit d'une proposition de méthode de mesure ; aucun pourcentage d'amélioration n'est avancé ici.

Élargissez la délégation lorsque livrer un travail accepté devient plus facile, sans hausse inacceptable de la charge de revue ou des défauts. Si les correctifs sont produits plus vite mais deviennent plus difficiles à comprendre, réduisez le périmètre et renforcez les preuves.

Questions fréquentes

Par quoi commencer dès lundi ?

Choisissez un petit ticket de votre backlog au comportement reproductible et désignez la personne chargée de sa revue avant de lancer l'agent. Rédigez les critères d'acceptation, fournissez un environnement de travail isolé et ne donnez pas les identifiants de production. Demandez un correctif accompagné des preuves nécessaires pour l'évaluer.

Après la revue, consignez ce que l'agent a pris en charge, les moments où une personne est intervenue et les contrôles qui ont manqué. Servez-vous de ces éléments pour fixer le périmètre de la prochaine tâche. Accordez davantage d'autonomie lorsque le processus de vérification le justifie.

Pour des conseils pratiques sur le développement avec l'IA, abonnez-vous à la newsletter.