Assistant ou agent de codage IA : quel niveau d’autonomie choisir ?

Pendant plusieurs années, l’IA dans les outils de développement servait surtout à compléter une ligne, expliquer un morceau de code ou générer une fonction. On restait devant l’écran, on demandait, puis on décidait quoi conserver.

Les agents de codage vont plus loin. On peut leur confier un objectif, les laisser explorer un dépôt, modifier plusieurs fichiers, lancer des tests et préparer une pull request. Le développeur n’intervient plus à chaque étape. Il fixe le cadre et contrôle le résultat.

La différence est importante, mais la frontière devient floue. Un même outil peut proposer de l’autocomplétion, un chat, un mode agent local et un agent autonome qui travaille en arrière-plan. Pour une entreprise, comparer les noms des produits aide donc assez peu. Il faut regarder ce que l’IA a réellement le droit de faire.

Un assistant reste dans la boucle du développeur

L’assistant répond à une demande ponctuelle : expliquer une erreur, proposer une requête SQL, écrire un test, documenter une méthode ou suggérer la suite du code. Il peut disposer du contexte du fichier ou du projet, mais la personne conserve généralement la main sur chaque modification.

Ce fonctionnement convient bien lorsqu’on explore une solution, que l’on touche à une partie sensible de l’application ou que l’on ne sait pas encore exactement ce qu’il faut changer. Le dialogue sert alors à réfléchir et à avancer par petites étapes.

L’inconvénient est simple : le développeur reste sollicité en permanence. Le gain porte surtout sur la vitesse d’écriture et de recherche, moins sur la prise en charge complète d’une tâche.

Un agent exécute une suite d’actions

Un agent reçoit plutôt un objectif : corriger un bug reproduit par un test, mettre à jour une dépendance, ajouter un endpoint documenté ou augmenter la couverture d’une partie du projet. Il construit un plan, consulte les fichiers utiles, effectue les changements, exécute des commandes, observe le résultat et recommence si nécessaire.

Cette autonomie peut être locale, dans l’environnement du développeur, ou asynchrone dans un environnement isolé. GitHub décrit par exemple un agent capable de travailler sur une branche dédiée puis de soumettre ses changements à la revue. D’autres outils fonctionnent dans le terminal et demandent une autorisation avant d’écrire un fichier ou de lancer certaines commandes.

Le gain potentiel ne vient donc pas uniquement de la génération de code. Il vient du temps d’attention libéré pendant que l’agent travaille. Mais ce temps ne disparaît pas complètement : il se déplace vers la description de la tâche, la préparation de l’environnement, la qualité des tests et la revue finale.

Le bon choix dépend d’abord de la tâche

Une tâche se prête bien à un agent lorsqu’elle est délimitée, vérifiable et réversible. Un bug avec un scénario de reproduction, une évolution assortie de critères d’acceptation ou une mise à jour couverte par des tests donnent à l’agent un objectif contrôlable.

À l’inverse, « améliore notre application » ou « modernise ce vieux module » laissent trop de décisions implicites. L’agent peut produire beaucoup de modifications cohérentes en apparence, sans avoir compris les contraintes métier, les compromis historiques ou les dépendances qui ne figurent nulle part.

Plus la tâche demande du jugement, de la connaissance métier ou une décision d’architecture difficile à annuler, plus un assistant interactif est adapté. Plus elle est répétitive, bien spécifiée et couverte par des contrôles automatiques, plus on peut augmenter l’autonomie.

L’autonomie ne compense pas un projet mal préparé

Un agent est beaucoup plus utile sur un dépôt qu’il peut installer, comprendre et tester sans bricolage. Les commandes de démarrage doivent être connues, les dépendances reproductibles, les tests suffisamment fiables et les règles du projet explicites.

Sur un logiciel ancien sans tests, avec des secrets dans les fichiers, des procédures uniquement connues d’une personne et plusieurs environnements impossibles à reproduire, l’agent ne règle pas le problème. Il le rencontre plus vite. Il peut aussi multiplier les changements avant que quelqu’un ne remarque qu’il est parti dans la mauvaise direction.

Une étude présentée à MSR 2026 a observé davantage de redondance dans des pull requests générées par des agents que dans celles produites par des humains. Les auteurs signalent aussi que les réactions des relecteurs restent souvent neutres ou positives, malgré ce risque de dette technique discrète. Ce résultat ne condamne pas les agents, mais il rappelle qu’un code propre en surface n’est pas forcément un bon code pour le projet.

Le vrai sujet pour l’entreprise : les droits accordés

Un assistant qui propose une fonction dans l’éditeur et un agent capable d’exécuter des commandes n’exposent pas l’entreprise au même risque. Avant de déployer un agent, il faut vérifier son accès aux dépôts, au réseau, aux secrets, aux outils externes et aux environnements de déploiement.

L’OWASP cite notamment l’injection de prompt, l’usage abusif des outils, l’élévation de privilèges et l’exfiltration de données parmi les risques propres aux agents. Le principe raisonnable reste classique : limiter les droits au strict nécessaire, isoler l’exécution et conserver une validation humaine avant les actions difficiles à annuler.

Concrètement, un agent devrait travailler sur une branche dédiée, sans accès direct à la production, avec des secrets limités, des destinations réseau contrôlées et des traces consultables. Les protections de branche, les tests, l’analyse de sécurité et la revue humaine restent en place. L’IA s’insère dans le processus de développement, elle ne le remplace pas.

Trois niveaux simples pour démarrer

On peut éviter le choix binaire en définissant trois niveaux d’usage.

1. Assistant interactif : pour comprendre, explorer, écrire un petit morceau de code ou intervenir sur une zone critique encore mal maîtrisée.
2. Agent supervisé : pour modifier plusieurs fichiers et lancer les tests, avec validation des commandes sensibles et contrôle du diff par le développeur.
3. Agent asynchrone : pour des tâches bien cadrées, répétitives et couvertes par des tests, dans un environnement isolé, avec une pull request obligatoire.

Ce classement doit porter sur les tâches, pas uniquement sur les personnes. Un développeur expérimenté peut lui aussi utiliser un assistant sur une migration risquée, puis déléguer en autonomie la correction de tests simples sur le même projet.

Le verdict Clarifya

Pour une PME, on ne choisirait pas entre assistants et agents comme on choisit deux logiciels concurrents. On commencerait par classer quelques tâches réelles selon quatre critères : sont-elles clairement définies, vérifiables automatiquement, réversibles et réalisables avec des droits limités ?

Si les quatre réponses sont positives, un agent mérite un test sur un périmètre réduit. On mesure alors le temps total, y compris la rédaction de la demande, les relances, la revue et les corrections. Compter seulement le temps pendant lequel l’agent écrit donnerait une image fausse du gain.

Si le projet manque de tests, si personne n’a le temps de relire ou si l’agent doit recevoir des accès trop larges pour être utile, mieux vaut rester sur un assistant. Et si l’usage est occasionnel, une bonne documentation et quelques automatisations classiques peuvent apporter davantage qu’un nouvel abonnement.