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 sur 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 et révise jusqu’à ce que la tâche soit terminée.
Cet article explique comment fonctionne cette boucle — le planificateur, la couche d’inférence LLM, les outils et l’environnement d’exécution sandboxé — puis montre comment en assembler un en utilisant l’API LLM de Novita et l’Agent Sandbox. Si vous préférez la couche d’outils packagés plutôt que la couche agent, consultez 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 ?.
Pour un regard plus approfondi sur les choix pratiques de modèles dans cette architecture, lisez Cas d’usage des grands modèles de langage pour les agents de codage.
Si vous voulez la version workflow pratique de cette même boucle, consultez Comment automatiser des tâches avec l’IA.
Si vous comparez spécifiquement les outils open source, consultez Agents de codage open source : meilleurs outils et comment en créer un.
Ce qui fait d’un système un agent de codage
La différence entre un assistant de code et un agent de codage, c’est 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 soit bloqué.
Cette capacité d’exécution implique 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 sandboxé — un endroit où exécuter du code qui ne nuira pas au système hôte en cas de problème
- 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 large pour couvrir tout, des suggestions en ligne 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 de « meilleur agent de code », ils désignent généralement ce dernier type : des systèmes qui accomplissent de manière fiable des tâches de codage en plusieurs étapes avec un minimum d’accompagnement.
Les quatre couches d’un agent de codage
Chaque agent de codage IA de niveau production possède quatre composants reconnaissables. Les détails d’implémentation varient — différents frameworks, différents LLM, différents fournisseurs de sandbox — 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 sur laquelle le modèle travaille, 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 d’ajouter des raffinements 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 c’est 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 les paramètres — que le framework dispatch vers la couche d’exécution réelle.
Pour les agents de code, le LLM doit gérer de manière fiable de longs contextes (les résultats des outils s’accumulent rapidement), renvoyer de manière cohérente des appels d’outils bien formés (un JSON mal structuré à l’étape 6 d’un workflow en 10 étapes casse toute 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 au 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 d’agents qui génèrent des sous-tâches parallèles. L’API LLM de Novita AI couvre ces trois points avec un endpoint compatible OpenAI, ce qui signifie que vous pouvez changer de modèle 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 | Rôle |
|---|---|
read_file |
Renvoie 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 renvoie stdout + stderr |
list_directory |
Liste les fichiers et répertoires à un chemin |
Chaque outil doit renvoyer une sortie complète. Des résultats tronqués ou des échecs silencieux corrompent la représentation que l’agent a du codebase et provoquent des erreurs qui s’amplifient plus tard. L’outil run_command doit particulièrement 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 une recherche de type grep dans un codebase, ou un outil fetch_url pour lire de la documentation externe. Le bon ensemble dépend du domaine de tâche. Pour le travail de code pur, les quatre outils ci-dessus couvrent la plupart des cas.
4. Le sandbox
Le sandbox est un environnement Linux complet et isolé dans lequel les commandes de l’agent s’exécutent réellement. 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 modèles 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 sandbox confine tout dommage dans un environnement isolé.
Deuxièmement, la persistance d’état. Un bon sandbox 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 conteneurs sans état — où chaque commande s’exécute dans un environnement neuf — ne fonctionnent pas pour de vraies tâches de codage.
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 sandbox n’interrompe pas un workflow interactif.
Comment fonctionne la boucle d’exécution
Un exemple concret facilite la compréhension de la boucle. Supposons que la tâche soit : « Ajouter une limitation de débit à l’endpoint /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 limitation de débit, vérifier avec un test.
-
Observer — l’agent appelle
list_directorypour trouver les fichiers de routes, puisread_filesur le gestionnaire de connexion. Le contenu des fichiers 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 limitation 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 trace d’exécution, identifie l’erreur et écrit un fichier corrigé.
-
Terminer — lorsque les tests passent et que le modèle n’a plus d’étapes en attente, il renvoie un résumé final.
Cette boucle s’exécute au sein 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 compte autant pour les agents de codage : une véritable tâche de refactoring peut facilement remplir 100K tokens à l’étape 15. Voir comment les agents sollicitent les fournisseurs d’inférence différemment du chat à tour unique.
Construire un agent de codage avec Novita
L’exemple suivant relie l’API LLM de Novita et l’Agent Sandbox. Il utilise le SDK Python OpenAI pointé vers l’endpoint 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 à propos de cette implémentation :
- La boucle
while Trues’exécute jusqu’à ce que le modèle renvoie un message sans 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 à
messagescomme entréesrole: tool. C’est ce qui construit le contexte partagé entre les étapes. sandbox.kill()libère les ressources de calcul. Appelez-le toujours à la fin de la session.
Pour les identifiants de modèles prenant en charge l’appel de fonction, consultez la documentation d’appel de fonction Novita. Pour une présentation plus complète incluant une interface Gradio, consultez Construire un agent de codage avec l’Agent Sandbox de Novita.
Choisir le bon LLM pour les agents de code
HumanEval et SWE-bench mesurent la génération de code à tour unique. 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 renvoie occasionnellement du JSON mal formé lors de sessions complexes multi-tours échouera d’une manière difficile à déboguer.
Les critères pratiques d’évaluation pour les agents de codage IA :
- Fiabilité des appels d’outils — avec quelle cohérence le modèle renvoie-t-il des appels d’outils bien formés sur des sessions de 20 étapes ou plus ?
- Rétention du contexte — le modèle référence-t-il correctement un fichier 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 sans rapport ?
- 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 est plus informatif que n’importe quel benchmark public. Sélectionnez 20 à 30 tâches issues de votre propre codebase, exécutez-les avec les modèles candidats et comptez combien aboutissent sans intervention humaine.
La tarification de l’inférence s’accumule rapidement à l’échelle des agents. Une seule session peut consommer 200K à 500K tokens sur l’ensemble des tours. Les fournisseurs qui proposent la mise en cache des prompts et des tarifs compétitifs par token changent considérablement l’économie lorsque vous exécutez des centaines de sessions d’agents par jour.
Les modèles open source comme voie économique
Les modèles propriétaires de pointe ont longtemps dominé 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 se résume à une modification d’une ligne dans le paramètre model.
Les deux sont disponibles via l’API LLM de Novita. Vous obtenez le même endpoint, la même interface d’appel de fonction et la même intégration Agent Sandbox — sans gérer vous-même l’infrastructure GPU. Cela compte car l’orchestration GPU, le batch 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 importe spécifiquement pour les agents de codage : les coûts de tokens par session pilotent l’économie des charges de travail agentiques davantage que les frais de licence. Une équipe qui exécute 200 sessions d’agents de codage par jour et qui atteint des taux d’achèvement 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 avec le coût par session. Les chiffres des benchmarks ne répondront pas à cette question — votre charge de travail réelle 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 en ligne de GitHub Copilot) génère des complétions et s’arrête. Un agent de codage exécute le 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 sandbox pour construire un agent de codage ?
Oui, si l’agent doit exécuter du code généré à partir d’une saisie utilisateur ou de sources externes. Sans isolation, une génération de code boguée peut endommager le système de fichiers hôte ou consommer des ressources illimitées. Même pour des cas d’usage purement internes, un sandbox empêche les processus incontrôlés d’affecter l’hôte. Les conteneurs offrent une isolation de base ; les sandbox basés sur des microVM comme ceux 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’exécution de commandes locales couvrent la majorité des workflows. Restreindre les sorties réseau dans le sandbox est en réalité 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 votre charge de travail réelle. Les classements des benchmarks publics sont un point de départ pour présélectionner des modèles, pas une réponse définitive. Exécutez vos tâches représentatives, mesurez le taux d’achèvement et intégrez le coût en tokens par session. Le meilleur agent de code pour une petite startup qui fait du refactoring léger peut être très différent de la meilleure option pour une équipe d’entreprise qui exécute 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 sandbox. Novita Agent Sandbox prend en charge des 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 prolongées sans nécessiter de logique de checkpoint/restore dans votre code d’agent.
