Un agent de codage est un système d’IA qui utilise un grand modèle de langage comme noyau de raisonnement pour écrire, exécuter et itérer du code de manière autonome. Contrairement à un assistant de code qui suggère des complétions dans votre éditeur, un agent de codage exécute une boucle complète observer-décider-agir : il lit des fichiers, écrit des modifications, exécute des commandes, vérifie la sortie, puis révise jusqu’à ce que la tâche soit accomplie.
Cet article explique comment cette boucle fonctionne—le planificateur, la couche d’inférence LLM, les outils et l’environnement d’exécution en bac à sable—puis montre comment en assembler un en utilisant l’API LLM et le bac à sable Agent de Novita. Si vous voulez la couche d’outils packagés plutôt que la couche agent, consultez Les meilleurs outils de codage IA en 2026. Si vous voulez la variante spécifique à Claude de cette boucle, lisez Qu’est-ce qu’un agent de codage Claude ?.
Si vous comparez spécifiquement les outils open source, voir Agents de codage open source : meilleurs outils et comment en construire un.
Qu’est-ce qui fait d’un outil un agent de codage
La différence entre un assistant de code et un agent de codage réside dans l’exécution. Un assistant de code génère une suggestion et s’arrête. Un agent de codage IA génère du code, l’exécute, lit le résultat et continue jusqu’à ce que l’objectif soit atteint—ou jusqu’à ce qu’il reste bloqué.
Cette capacité d’exécution repose sur trois exigences concrètes :
- Accès aux outils — la capacité de lire des fichiers, d’écrire des fichiers et d’exécuter des commandes shell
- Un environnement en bac à sable — un endroit pour exécuter du code sans risquer d’endommager le système hôte si quelque chose tourne mal
- Un contexte persistant — les sorties des outils sont réinjectées dans le contexte du modèle afin qu’il puisse raisonner sur ce qui s’est passé
Sans ces trois éléments, vous avez un chatbot capable d’écrire du code. Avec ces trois éléments, vous avez un agent.
Le terme « agent de code » est utilisé de manière vague pour couvrir tout, des suggestions intégrées dans l’IDE aux systèmes entièrement autonomes capables de prendre une tâche vaguement spécifiée, de déterminer quels fichiers sont impliqués, d’apporter des modifications et de vérifier qu’elles fonctionnent—sans intervention humaine à chaque étape. Lorsque les développeurs comparent les options du « meilleur agent de code », ils désignent généralement ce dernier type : les systèmes qui accomplissent des tâches de codage en plusieurs étapes de manière fiable avec un minimum d’accompagnement.
Les quatre couches d’un agent de codage
Chaque agent de codage IA de qualité production possède quatre composants reconnaissables. Les détails d’implémentation varient—différents frameworks, différents LLM, différents fournisseurs de bacs à sable—mais l’architecture est cohérente.
1. Le planificateur
Le planificateur reçoit la description de la tâche et la décompose en étapes que l’agent exécutera. Pour les tâches simples, cela se produit implicitement dans le raisonnement du modèle. Pour les tâches complexes—« migrer ce service pour utiliser la nouvelle bibliothèque d’authentification »—une étape de planification explicite produit une liste numérotée de tâches que le modèle parcourt, en mettant à jour l’état après chaque étape.
La planification détermine également quand s’arrêter. Un agent sans critère d’achèvement continuera à ajouter des améliorations indéfiniment ou, pire, bouclera sur une étape échouée. La plupart des implémentations encodent la condition de succès de la tâche dans le prompt système et laissent le modèle décider quand il a terminé.
2. La couche d’inférence LLM
Le LLM est le noyau de raisonnement de tout agent de codage IA. Il décide quel outil appeler ensuite, quels arguments passer et comment interpréter le résultat. Cette décision est exprimée sous la forme d’un appel d’outil structuré—un objet JSON avec le nom de la fonction et ses paramètres—que le framework distribue à la couche d’exécution réelle.
Pour les agents de code, le LLM doit gérer de longs contextes de manière fiable (les résultats des outils s’accumulent rapidement), retourner des appels d’outils bien formés de manière cohérente (un JSON mal structuré à l’étape 6 d’un flux de travail en 10 étapes casse l’ensemble de l’exécution) et raisonner sur les changements d’état à travers de nombreux appels d’outils séquentiels.
Le fournisseur d’inférence est important ici. Vous avez besoin d’une API qui prend en charge l’appel de fonction dans un format compatible OpenAI, des sorties structurées pour imposer un JSON valide au niveau du modèle et des limites de concurrence suffisantes pour les charges de travail des agents qui génèrent des sous-tâches parallèles. L’API LLM de Novita AI couvre ces trois points avec un point de terminaison compatible OpenAI, ce qui signifie que vous pouvez échanger des modèles sans réécrire la logique d’analyse des appels d’outils.
3. La couche d’outils
Les outils sont l’interface de l’agent avec le monde. Un agent de codage minimal a besoin de quatre outils :
| Outil | Ce qu’il fait |
|---|---|
read_file |
Retourne le contenu d’un fichier à un chemin donné |
write_file |
Écrit une chaîne dans un chemin de fichier |
run_command |
Exécute une commande shell et retourne stdout + stderr |
list_directory |
Liste les fichiers et répertoires à un chemin |
Chaque outil doit retourner une sortie complète. Des résultats tronqués ou des échecs silencieux corrompent le modèle que l’agent a du codebase et provoquent des erreurs cumulatives plus tard. L’outil run_command doit en particulier capturer à la fois stdout et stderr—l’agent apprend souvent plus de la sortie d’erreur que de la sortie de succès.
Certains agents ajoutent un outil search_files pour la recherche de style grep dans un codebase, ou un outil fetch_url pour lire la documentation externe. Le bon ensemble dépend du domaine de la tâche. Pour le travail de codage pur, les quatre ci-dessus couvrent la plupart des cas.
4. Le bac à sable
Le bac à sable est un environnement Linux complètement isolé où les commandes de l’agent sont réellement exécutées. Cela est important pour deux raisons.
Premièrement, la sécurité. Les agents génèrent du code à partir de prompts utilisateur, de documentation récupérée et de motifs inférès. Même un agent bien intentionné peut produire du code qui supprime des fichiers, ouvre des connexions réseau ou consomme des ressources illimitées. Un bac à sable confine tout dommage à l’intérieur d’un environnement isolé.
Deuxièmement, le maintien de l’état. Un bon bac à sable préserve l’état du système de fichiers entre les appels d’outils au sein d’une session. Si l’agent crée un fichier à l’étape 2, il doit toujours être présent à l’étape 8. Les approches par conteneur sans état—où chaque commande s’exécute dans un environnement frais—ne fonctionnent pas pour les tâches de codage réelles.
Novita Agent Sandbox est construit sur des microVM Firecracker, qui offrent une isolation au niveau du noyau plus forte que les conteneurs standard. Les sessions peuvent durer jusqu’à 24 heures, l’état du système de fichiers persiste entre les commandes et le démarrage à froid est inférieur à 200 ms. C’est assez rapide pour que l’attente du démarrage du bac à sable n’interrompe pas un flux de travail interactif.
Comment fonctionne la boucle d’exécution
Un exemple concret facilite la compréhension de la boucle. Disons que la tâche est : « Ajouter une limite de débit au point de terminaison /login. »
-
Planifier — le modèle lit la tâche et identifie ce dont il a besoin : trouver la route de connexion, comprendre le gestionnaire actuel, ajouter un middleware de limite de débit, vérifier avec un test.
-
Observer — l’agent appelle
list_directorypour trouver les fichiers de route, puisread_filesur le gestionnaire de connexion. Le contenu du fichier est ajouté au contexte du modèle. -
Décider — le modèle raisonne sur le code actuel et décide quoi faire : installer la bibliothèque de limite de débit, modifier le gestionnaire, ajouter un test.
-
Agir — l’agent appelle
run_command("pip install slowapi"), puiswrite_fileavec le gestionnaire modifié, puisrun_command("pytest tests/test_login.py"). -
Observer à nouveau — la sortie du test est réinjectée dans le contexte. Si les tests échouent, le modèle lit la traceback, identifie l’erreur et écrit un fichier corrigé.
-
Terminer — lorsque les tests réussissent et que le modèle n’a plus d’étapes en attente, il retourne un résumé final.
Cette boucle s’exécute à l’intérieur d’une seule session. La fenêtre de contexte est la mémoire de travail de l’agent—chaque fichier lu, chaque sortie de commande, chaque appel d’outil s’y accumule. C’est pourquoi la longueur du contexte est si importante pour les agents de codage : une tâche de refactoring réelle peut facilement remplir 100K tokens à l’étape 15. Voir comment les agents sollicitent les fournisseurs d’inférence différemment d’un chat à tour unique.
Construire un agent de codage avec Novita
L’exemple suivant connecte l’API LLM de Novita et le bac à sable Agent. Il utilise le SDK Python OpenAI pointé vers le point de terminaison de Novita—les modèles de Novita utilisent la même interface d’appel de fonction que l’API d’OpenAI, donc l’intégration ne nécessite aucune analyse personnalisée.
import os
import json
from openai import OpenAI
from novita_sandbox.code_interpreter import Sandbox
client = OpenAI(
base_url="https://api.novita.ai/openai",
api_key=os.environ["NOVITA_API_KEY"],
)
sandbox = Sandbox.create(timeout=1800)
def read_file(path: str) -> str:
try:
return sandbox.files.read(path)
except Exception as e:
return f"Error: {e}"
def write_file(path: str, content: str) -> str:
try:
sandbox.files.write(path, content)
return f"Written to {path}"
except Exception as e:
return f"Error: {e}"
def run_command(cmd: str) -> str:
try:
result = sandbox.commands.run(cmd)
return str(result)
except Exception as e:
return f"Error: {e}"
tools = [
{
"type": "function",
"function": {
"name": "read_file",
"description": "Read the contents of a file",
"parameters": {
"type": "object",
"properties": {"path": {"type": "string"}},
"required": ["path"],
},
},
},
{
"type": "function",
"function": {
"name": "write_file",
"description": "Write content to a file",
"parameters": {
"type": "object",
"properties": {
"path": {"type": "string"},
"content": {"type": "string"},
},
"required": ["path", "content"],
},
},
},
{
"type": "function",
"function": {
"name": "run_command",
"description": "Run a shell command in the sandbox and return output",
"parameters": {
"type": "object",
"properties": {"cmd": {"type": "string"}},
"required": ["cmd"],
},
},
},
]
dispatch = {
"read_file": read_file,
"write_file": write_file,
"run_command": run_command,
}
def run_agent(task: str, model: str) -> str:
messages = [
{
"role": "system",
"content": (
"You are a coding agent with access to a Linux sandbox. "
"Complete tasks by calling tools. When done, return a plain-text summary."
),
},
{"role": "user", "content": task},
]
while True:
response = client.chat.completions.create(
model=model,
messages=messages,
tools=tools,
tool_choice="auto",
)
msg = response.choices[0].message
messages.append(msg)
if not msg.tool_calls:
return msg.content
for call in msg.tool_calls:
fn = dispatch[call.function.name]
args = json.loads(call.function.arguments)
result = fn(**args)
messages.append(
{
"role": "tool",
"tool_call_id": call.id,
"content": result,
}
)
# Replace <model-id> with a function-calling model from novita.ai/docs
result = run_agent(
task="Write a Python script that counts words in a text file and run it on a sample input",
model="<model-id>",
)
print(result)
sandbox.kill()
Quelques points à noter concernant cette implémentation :
- La boucle
while Trues’exécute jusqu’à ce que le modèle retourne un message sans aucun appel d’outil—c’est le signal que l’agent considère la tâche comme terminée. - Les résultats des outils sont ajoutés à
messagesen tant qu’entréesrole: tool. C’est ainsi que se construit le contexte partagé entre les étapes. sandbox.kill()libère les ressources de calcul. Appelez-la toujours lorsque la session se termine.
Pour les ID de modèle prenant en charge l’appel de fonction, consultez la documentation sur l’appel de fonction Novita. Pour une procédure pas à pas plus complète incluant une interface Gradio, voir Construire un agent de codage avec le bac à sable Agent de Novita.
Choisir le bon LLM pour les agents de codage
HumanEval et SWE-bench mesurent la génération de code à un seul tour. Les charges de travail des agents sont différentes—ce qui casse réellement les agents de code en production, ce sont les échecs de formatage des appels d’outils. Un modèle qui obtient de bons résultats sur les benchmarks mais qui retourne occasionnellement du JSON mal formé lors de sessions complexes à plusieurs tours échouera d’une manière difficile à déboguer.
Les critères d’évaluation pratiques pour les agents de codage IA :
- Fiabilité des appels d’outils — avec quelle cohérence le modèle retourne-t-il des appels d’outils bien formés sur des sessions de 20+ étapes ?
- Rétention du contexte — le modèle fait-il correctement référence à un fichier qu’il a lu il y a 40 étapes ?
- Suivi des instructions — l’agent reste-t-il sur la tâche, ou commence-t-il à modifier des fichiers non liés ?
- Exactitude du code — le code généré s’exécute-t-il réellement, ou nécessite-t-il plusieurs boucles de correction ?
Exécuter un ensemble représentatif de tâches de codage réelles et mesurer le taux d’achèvement des tâches est plus instructif que n’importe quel benchmark public. Sélectionnez 20 à 30 tâches de votre propre codebase, exécutez-les contre des modèles candidats et comptez combien s’achèvent sans intervention humaine.
Le coût d’inférence se cumule rapidement à l’échelle des agents. Une seule session peut consommer 200 000 à 500 000 tokens sur tous les tours. Les fournisseurs qui proposent la mise en cache des prompts et des tarifs concurrentiels par token changent considérablement l’économie lorsque vous gérez des centaines de sessions d’agents par jour.
Les modèles open source comme voie économique
Les modèles frontières propriétaires ont mené sur les benchmarks de codage, mais l’écart avec les meilleurs modèles open source s’est considérablement réduit. Des modèles comme DeepSeek V3 et Qwen3 sont désormais compétitifs sur les tâches de génération de code et d’utilisation d’outils—et comme ils sont servis via des API compatibles OpenAI, le changement est une modification d’une seule ligne dans le paramètre model.
Les deux sont disponibles via l’API LLM de Novita. Vous bénéficiez du même point de terminaison, de la même interface d’appel de fonction et de la même intégration du bac à sable Agent—sans avoir à gérer vous-même l’infrastructure GPU. Cela est important car l’orchestration GPU, le batching et l’ingénierie de fiabilité sont non triviaux ; les déléguer à une API gérée vous permet de vous concentrer sur la logique de l’agent.
Pourquoi cela est important pour les agents de codage spécifiquement : les coûts des tokens par session déterminent l’économie des charges de travail des agents plus que les frais de licence. Une équipe exécutant 200 sessions d’agents de codage par jour qui atteint des taux d’achèvement de tâches comparables avec un modèle open source peut réduire considérablement ses dépenses d’inférence sans modifier du tout son code d’intégration.
Le test pratique : exécutez 50 tâches de codage représentatives avec votre modèle cible, mesurez le taux de succès des appels d’outils et le taux d’achèvement des tâches, puis comparez au coût par session. Les chiffres des benchmarks ne répondront pas à cette question—c’est votre charge de travail réelle qui le fera.
FAQ
Quelle est la différence entre un agent de codage et un assistant de code ?
Un assistant de code (comme les suggestions inline de GitHub Copilot) génère des complétions et s’arrête. Un agent de codage exécute du code, lit la sortie et itère. La caractéristique déterminante est la boucle d’exécution : lire, décider, agir, observer, répéter. Voir Agent de codage CLI vs IDE pour une comparaison de la manière dont différents facteurs de forme d’agents utilisent cette boucle.
Ai-je besoin d’un bac à sable pour construire un agent de codage ?
Oui, si l’agent doit exécuter du code généré à partir de saisies utilisateur ou de sources externes. Sans isolement, une génération de code bugguée peut endommager le système de fichiers hôte ou consommer des ressources illimitées. Même pour des cas d’usage internes uniquement, un bac à sable empêche les processus incontrôlables d’affecter l’hôte. Les conteneurs offrent une isolation de base ; les bacs à sable basés sur microVM comme celuii de Novita offrent une séparation plus forte au niveau du noyau pour les charges de travail multi-locataires ou sensibles à la sécurité.
Un agent de codage peut-il fonctionner sans accès à Internet ?
Pour la plupart des tâches de codage pures, oui. La lecture/écriture de fichiers et l’execution de commandes locales couvrent la majorité des flux de travail. Restreindre la sortie réseau dans le bac à sable est en fait une bonne pratique par défaut—cela empêche le code généré de faire des requêtes externes inattendues et simplifie votre modèle de menace.
Qu’est-ce qui détermine le meilleur agent de code pour une tâche donnée ?
La fiabilité des appels d’outils et le taux d’achèvement des tâches sur voter charge de travail réelle. Les classements publics des benchmarks sont un point de départ pour présélectionner des modèles, pas une réponse finale. Exécutez vos tâches représentatives, mesurez le taux d’achèvement et prenez en compte le coût des tokens par session. Le meilleur agent de code pour une petite startup effectuant un refactoring léger peut être très différent de la meilleure option pour une équipe d’entreprise effectuant une revue de PR automatisée à grande échelle.
Combien de temps une session d’agent de codage peut-elle durer ?
Cela dépend du fournisseur de bac à sable. Novita Agent Sandbox prend en charge les sessions jusqu’à 24 heures avec l’état du système de fichiers préservé entre les commandes, ce qui couvre même les tâches de refactoring ou de migration étendues sans nécessiter de logique de point de contrôle/restauration dans le code de votre agent.
Articles recommandés
- Agents de codage open source : meilleurs outils et comment en construire un
- Les meilleurs outils de codage IA en 2026
- Construire un agent de codage avec le bac à sable Agent de Novita
- Agent de codage CLI vs IDE : quel est le choix le plus judicieux pour votre prochain projet
- Quel fournisser d’inférence est le plus adapté aux agents IA
