Un diff montre ce qu'un patch prétend faire. Il ne montre pas si le bug a vraiment disparu, si la nouvelle branche d'un if s'exécute un jour, ni si la mise à jour d'une dépendance casse l'import sur une installation propre. Les relecteurs le savent, et c'est pourquoi tant de revues se terminent par « LGTM, si les tests passent ».
Avec les patchs écrits par une IA, l'écart se creuse. Un modèle produit vite du code plausible, et le plausible est justement ce qui échappe à un relecteur fatigué. La solution bon marché : exécuter la modification avant que quiconque l'approuve — dans un endroit où elle ne peut rien abîmer.
La vérification : base, head, tests
La preuve la plus convaincante qu'un patch puisse offrir est une reproduction qui échoue sur l'ancien code et passe sur le nouveau. Une sandbox en fait un script de 20 lignes. C'est une microVM Firecracker avec Python 3.12, Node.js 22, git et curl, démarrée en une seconde environ :
import os
from eqvps import Sandbox
REPO, BASE, HEAD = os.environ["REPO_URL"], os.environ["BASE_SHA"], os.environ["HEAD_SHA"]
def repro(sb, ref):
sb.exec(f"cd /root/app && git checkout -q {ref}", timeout=55)
return sb.exec("cd /root/app && python3 /root/repro.py", timeout=55).exit_code
with Sandbox.create(tariff="standard", ttl=1800) as sb:
sb.exec(f"git clone -q {REPO} /root/app", timeout=55)
sb.exec("cd /root/app && pip install -q -r requirements.txt", timeout=55)
sb.upload("/root/repro.py", open("repro.py").read())
before, after = repro(sb, BASE), repro(sb, HEAD)
tests = sb.exec("cd /root/app && python3 -m pytest -q", background=True).wait()
print(f"repro on base: {before}, on head: {after}; tests: {tests.state}, exit {tests.exit_code}")
repro.py est l'extrait tiré du rapport de bug. S'il sort avec un code non nul sur base et nul sur head, le patch corrige ce qu'il prétend corriger. Publiez cette ligne et le résumé des tests en commentaire de la pull request, et le relecteur part de faits.
La suite de tests tourne en tâche de fond, car une commande synchrone s'arrête à 55 secondes. Le TTL de 30 minutes plafonne ce qu'une exécution bloquée peut vous facturer.
Des agents de revue qui exécutent le code
La même idée fonctionne pour un relecteur IA. Connecté via le serveur MCP, un agent dispose d'outils de sandbox : créer une sandbox, exécuter une commande, envoyer et télécharger des fichiers. Au lieu d'écrire « cela pourrait casser la compatibilité avec Python 3.8 », il récupère la branche, exécute le code et cite la trace d'erreur — ou indique que tout va bien.
Donnez à un tel agent un plafond de dépenses et un token en lecture seule, et décidez quels outils il peut appeler sans demander. Les garde-fous MCP classent chaque outil par niveau de risque.
Quel tarif
| Dépôt | Tarif | Passage typique | Coût approximatif |
|---|---|---|---|
| Petite bibliothèque, Python ou JS pur | small (0.5 vCPU, 1 GB) | 2 min | $0.0011 |
| Application web avec suite de tests | standard (1 vCPU, 2 GB) | 5 min | $0.0055 |
| Extensions natives, dépendances compilées | plus (2 vCPU, 4 GB) | 15 min | $0.033 |
Les sandboxes éphémères sont facturées à la seconde avec un minimum de 60 secondes. Si un relecteur veut revenir au même environnement pendant quelques jours, créez-le plutôt en mode persistent : il conserve son disque jusqu'à 30 jours et se facture par heure entamée, donc une sandbox standard gardée pour une revue de deux jours coûte environ $3.17. Supprimez-la une fois la pull request fusionnée.
Les limites à connaître
- Deux commandes à la fois par compte. Largement assez pour des revues, qui s'enchaînent. Si vous vérifiez des dizaines de pull requests d'un coup, elles font la queue.
- Pas de ports entrants. Impossible d'ouvrir l'application dans un navigateur. Démarrez-la à l'intérieur et testez-la avec
curl localhostdepuis une seconde commande. - Pas de Docker à l'intérieur. Les tests qui lancent des conteneurs ont leur place sur un runner VPS.
- L'Internet sortant est ouvert. C'est ce qui fait fonctionner
pip install. Ne mettez dans la sandbox rien que vous ne confieriez pas à l'auteur du patch.
Pour commencer
Les nouveaux comptes reçoivent $1 de temps de sandbox, de quoi couvrir plus d'une centaine de passages de revue sur le tarif standard. La page des sandboxes présente les tarifs, la référence du SDK chaque méthode utilisée plus haut, et le SDK Python en 5 minutes la mise en place.
À lire aussi : des tests CI isolés pour l'ensemble du pipeline, et sandbox pour agents IA pour les agents qui écrivent le code au départ.
Commentaires
Pas encore de commentaires. Soyez le premier.