Le codage agentique avec l'appel d'outils — Codestral et agents de code — de Devstral à Vibe Code

Leçon mise à jour le 2 novembre 2026. Les exemples appelaient Devstral, retiré de l’API depuis le 31 juillet 2026 : ils utilisent désormais Mistral Small 4 (mistral-small-2603), et la boucle agentique suit le modèle de la documentation Mistral (tous les appels d’outils d’une réponse sont traités, jusqu’à la réponse finale). Source : Function calling.

Qu’est-ce que le coding agentique ?

Le coding agentique change la nature de ce que vous demandez au modèle. Au lieu de solliciter un snippet, puis un autre, puis un troisième, en recollant vous-même les morceaux, vous confiez une tâche complète et le modèle la résout en enchaînant seul les étapes : exploration, planification, implémentation, vérification. Vous restez celui qui décide de ce qui doit être fait, mais vous cessez d’être celui qui pilote chaque geste.

Les modèles Devstral ont été conçus pour ce mode de travail ; les généralistes actuels, Mistral Small 4 en tête, le prennent en charge par l’appel d’outils. Un agent ne répond pas à une question, il agit sur le dépôt.

Le cycle agentique

Phase 1 — Comprendre

L’agent commence toujours par se situer. Il lit la structure des dossiers et des fichiers, repère ceux qui touchent à la tâche demandée, remonte les dépendances entre modules pour savoir ce qu’un changement risque d’affecter, et relève les conventions en vigueur — nommage, organisation des tests, patterns récurrents. Cette phase paraît improductive puisqu’elle n’écrit aucune ligne ; elle détermine pourtant si le code produit ensuite ressemblera au vôtre ou à celui d’un inconnu.

Phase 2 — Planifier

Avant la première ligne, l’agent formule un plan. Il découpe la tâche en sous-tâches ordonnées, distingue les fichiers à modifier de ceux à créer, anticipe les effets de bord et les risques de régression, puis arrête une approche technique. C’est le moment où votre intervention coûte le moins cher : corriger un plan prend trente secondes, corriger dix fichiers déjà écrits en prend beaucoup plus.

Phase 3 — Exécuter

L’implémentation déroule le plan pas à pas. L’agent édite les fichiers existants, en crée de nouveaux quand la structure l’exige, met à jour les imports et les dépendances que ses modifications déplacent, et adapte les fichiers de configuration au passage. La cohérence entre ces changements est justement ce qu’un modèle de complétion ne peut pas garantir.

Phase 4 — Vérifier

Vient enfin la démonstration que le travail tient. L’agent exécute la suite de tests existante, en écrit de nouveaux pour le code qu’il vient d’ajouter, contrôle que le build passe, et relit son propre diff à la recherche d’erreurs ou de modifications parasites. Un agent qui saute cette phase produit du code plausible et non du code correct.

Exemple concret : corriger un bug

Supposons que vous signaliez à l’agent : « Les utilisateurs reçoivent une erreur 500 quand ils soumettent un formulaire avec un email contenant un ’+’ ». Le cycle prend alors cette forme :

1. COMPRENDRE
   -> Chercher les fichiers liés au formulaire (search "email" dans le code)
   -> Lire le controller qui traite la soumission
   -> Lire la fonction de validation d'email
   -> Identifier le regex qui rejette le '+'

2. PLANIFIER
   -> Modifier le regex de validation pour accepter '+'
   -> Ajouter un test unitaire pour les emails avec '+'
   -> Vérifier qu'aucun autre endroit du code ne filtre le '+'

3. EXÉCUTER
   -> Modifier src/validators/email.py : corriger le pattern regex
   -> Créer tests/test_email_validation.py : ajouter les cas avec '+'
   -> Modifier src/controllers/form.py : ajouter un log pour le debug

4. VÉRIFIER
   -> Exécuter pytest -> tous les tests passent
   -> Vérifier le diff -> changements cohérents et minimaux

Observez la troisième ligne du plan : l’agent ne se contente pas de corriger l’endroit où le bug se manifeste, il vérifie qu’aucun autre filtre ne rejette le caractère ailleurs. C’est cette recherche de la cause complète, plutôt que du symptôme, qui distingue une correction agentique d’un correctif ponctuel.

Le tool use en pratique

L’agent agit sur son environnement par des appels de fonctions. Vous déclarez les outils disponibles dans la requête, avec leur nom, leur description et le schéma de leurs paramètres ; le modèle choisit lesquels appeler et avec quels arguments.

# Exemple de conversation agentique
messages = [
    {
        "role": "user",
        "content": "Ajoute une validation de mot de passe fort dans le module auth."
    }
]

tools = [
    {
        "type": "function",
        "function": {
            "name": "read_file",
            "description": "Lire le contenu d'un fichier du projet",
            "parameters": {
                "type": "object",
                "properties": {
                    "path": {"type": "string", "description": "Chemin du fichier"}
                },
                "required": ["path"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "write_file",
            "description": "Écrire ou modifier un fichier du projet",
            "parameters": {
                "type": "object",
                "properties": {
                    "path": {"type": "string"},
                    "content": {"type": "string"}
                },
                "required": ["path", "content"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "run_command",
            "description": "Exécuter une commande shell",
            "parameters": {
                "type": "object",
                "properties": {
                    "command": {"type": "string"}
                },
                "required": ["command"]
            }
        }
    }
]

response = client.chat.complete(
    model="mistral-small-2603",
    messages=messages,
    tools=tools,
    tool_choice="auto",   # valeur par défaut : le modèle décide s'il appelle un outil
)

Sur cette demande, l’enchaînement typique commence par read_file("src/auth/validators.py") pour comprendre le code existant, se poursuit par read_file("tests/test_auth.py") afin de voir la forme des tests actuels, puis vient l’écriture : write_file("src/auth/validators.py", ...) avec la règle de validation ajoutée, write_file("tests/test_auth.py", ...) avec les nouveaux cas, et enfin run_command("pytest tests/test_auth.py") pour vérifier. L’ordre a son importance : en ouvrant les deux fichiers avant de toucher au moindre caractère, l’agent relève vos conventions et les reproduit, au lieu d’importer celles qu’il a vues ailleurs.

Boucle agentique multi-tours

Rien de tout cela ne se produit en un seul appel. Le cœur du coding agentique est la boucle multi-tours : le modèle propose une action, votre code l’exécute, puis vous lui renvoyez le résultat pour qu’il décide de la suivante. C’est vous qui gardez la main sur l’exécution réelle, ce qui est aussi votre garde-fou.

import json

OUTILS = {"read_file": read_file, "write_file": write_file, "run_command": run_command}

response = client.chat.complete(model="mistral-small-2603", messages=messages, tools=tools)
messages.append(response.choices[0].message)

for _ in range(30):   # garde-fou : un agent ne doit jamais boucler sans fin
    tool_calls = response.choices[0].message.tool_calls
    if not tool_calls:
        break         # plus d'appel d'outil : la réponse finale est arrivée
    for tool_call in tool_calls:   # une réponse peut contenir plusieurs appels
        nom = tool_call.function.name
        arguments = json.loads(tool_call.function.arguments)
        resultat = OUTILS[nom](**arguments)
        messages.append({
            "role": "tool",
            "name": nom,
            "content": str(resultat),
            "tool_call_id": tool_call.id,
        })
    response = client.chat.complete(model="mistral-small-2603", messages=messages, tools=tools)
    messages.append(response.choices[0].message)

print(response.choices[0].message.content)

Trois détails comptent. Le message de l’agent et chaque résultat d’outil sont réinjectés dans l’historique, avec le tool_call_id qui les apparie : omettez l’un des deux et l’agent perd le fil, rappelant les mêmes outils en boucle. Une même réponse peut contenir plusieurs appels d’outils, car les appels parallèles sont autorisés par défaut (parallel_tool_calls=False les interdit) : traitez-les tous. Enfin, plafonnez le nombre de tours et faites valider par un humain les commandes shell et les écritures de fichiers : un agent qui exécute tout ce qu’il propose est un risque, pas un gain de temps.

Points clés à retenir

Le coding agentique suit un cycle : comprendre, planifier, exécuter, vérifier
L’agent agit sur le dépôt par l’appel d’outils (tools, tool_choice)
La boucle multi-tours permet à l’agent d’itérer jusqu’à résolution complète
L’agent modifie plusieurs fichiers de manière cohérente en une seule tâche
La phase de vérification (tests, build) est essentielle pour la fiabilité