Les grands modèles de langage ont été conçus avant tout pour générer une continuation à partir d’un contexte. Même lorsqu’ils sont utilisés comme agents de développement logiciel, leur fonctionnement fondamental reste proche de celui d’un modèle conversationnel : ils reçoivent du contexte, utilisent l’ensemble de leur réseau, génèrent une réponse, puis laissent au système externe le soin d’interpréter ce qu’ils viennent de produire.
Avec CAPE-R — Contract-Aware Progressive Executor, Revised, nous explorons une approche différente.
CAPE-R est l’architecture que nous avons conçue pour transformer le modèle utilisé par Formic en un véritable exécuteur logiciel : un modèle qui travaille à partir d’un objectif précis, conserve un état structuré de la mission, adapte la quantité de calcul utilisée, produit des actions contrôlables et ne considère une modification comme terminée qu’après vérification.
Ne plus considérer chaque génération comme une réponse, mais comme une transition vérifiable dans l’exécution d’une mission.
L’objectif : rendre un petit modèle excellent en exécution
Formic poursuit un objectif précis : développer des modèles nettement plus petits et moins coûteux que les modèles frontières, tout en conservant une qualité très élevée en génération de code et en exécution de tâches logicielles.
Couplé à un orchestrateur capable de comprendre une mission, d’en définir la stratégie et de la décomposer, un modèle Formic peut prendre en charge l’exécution avec une qualité proche de celle d’un modèle frontière, pour un coût de développement logiciel largement inférieur.
CAPE-R décrit l’architecture qui rend cette ambition possible. Elle donne au modèle un cadre d’exécution précis : comprendre ce qu’il est autorisé à faire, travailler sur un état explicite, mobiliser uniquement le calcul nécessaire, produire des actions contrôlables, vérifier son travail et rester fiable jusqu’à la fin de la mission.
Il ne s’agit donc pas de remplacer l’intelligence d’un grand modèle frontière, mais de mieux répartir les rôles : l’orchestrateur conserve la stratégie et les décisions complexes ; Formic exécute efficacement les tâches définies, avec le contrôle et les preuves nécessaires.
D’une conversation à une transaction d’exécution
Le changement le plus fondamental de CAPE-R concerne l’unité de travail. Un modèle classique reçoit du contexte, le traite et produit principalement une réponse. CAPE-R fonctionne plutôt comme une succession de transactions d’exécution : contrat, état exact et informations utiles alimentent une décision du modèle ; celle-ci produit une action proposée, soumise à des vérifications externes, puis à un commit ou à un rejet avant de créer le nouvel état.
Une longue mission devient alors une suite de petites transitions contrôlées. Le modèle peut inspecter quelque chose, modifier une partie cohérente du code, appeler un outil, poser une question ou terminer la mission. Mais chaque transaction possède un périmètre précis et son résultat ne devient pas automatiquement l’état officiel du projet.
Les quatre grandes briques de CAPE-R
L’architecture peut être comprise comme quatre plans organisés autour du modèle Qwen : contrôle, état, modèle et validation / commit. Le cœur neuronal de Qwen est largement préservé ; CAPE-R modifie surtout la manière dont il est utilisé, contrôlé et intégré dans un système d’exécution.
1. Un contrat explicite pour définir ce que le modèle doit faire
Avant l’exécution, la demande est transformée en un ContractIR. Ce contrat représente explicitement l’objectif, les contraintes, le périmètre autorisé, les actions interdites, les critères de réussite, les limites de ressources et les éventuelles ambiguïtés.
Le modèle peut comprendre la mission en langage naturel, mais le système conserve parallèlement une représentation structurée de ce qui lui est demandé. Pour une mission comme « modifier l’authentification sans toucher à la facturation et conserver la compatibilité avec l’ancienne API », ces contraintes deviennent identifiables et le modèle ne peut pas décider seul de les modifier pendant son travail.
2. Un état externe pour savoir exactement où en est la mission
CAPE-R distingue fortement la mémoire neuronale du modèle de l’état réel du travail. Le State Fabric conserve notamment le snapshot exact du dépôt, les fichiers et symboles, les dépendances, les tâches restantes, les résultats des outils et des tests, les actions précédentes, les preuves associées et la progression de la mission.
Si le modèle affirme qu’un test passe, cela ne suffit pas. Le State Fabric peut enregistrer la commande, la révision exécutée, le résultat PASS et sa preuve. Si le cache neuronal est perdu ou le contexte reconstruit, l’état durable de la mission reste disponible : la vérité opérationnelle reste extérieure au réseau.
3. Utiliser uniquement la profondeur nécessaire
Le Qwen3.8-27B étudié possède 64 couches regroupées en 16 groupes. Dans son fonctionnement standard, une génération utilise la pile complète. CAPE-R introduit trois niveaux : L0 — Direct, 32 couches pour les actions simples, locales et peu risquées ; L1 — Assured, 48 couches pour les opérations demandant davantage de compréhension ou de vérification ; et L2 — Certified, 64 couches pour les tâches complexes, ambiguës ou à fort impact.
Des Anytime Exit Gates placées à certains niveaux décident s’il faut poursuivre le calcul. Pour une migration importante ou une modification sensible, le système peut imposer directement une profondeur minimale. L’objectif est de conserver toute la capacité du 27B quand elle est nécessaire sans en payer systématiquement le coût maximal.
4. Adapter également la quantité de raisonnement
La profondeur du réseau n’est pas le seul coût à contrôler. Un modèle de raisonnement peut aussi produire de nombreux tokens intermédiaires avant d’agir. CAPE-R conserve cette capacité mais l’encadre par un Budgeted Scratch Channel.
L0 n’utilise pas de scratch, L1 reçoit un petit budget de raisonnement, L2 un budget plus important, et Recovery un budget supplémentaire après un échec concret. Le modèle estime également si continuer à réfléchir apporte encore quelque chose ou s’il vaut mieux passer à l’action.
CAPE-R dispose donc de deux leviers : la profondeur — 32, 48 ou 64 couches — et le raisonnement, de nul à important. Une tâche simple peut utiliser peu des deux ; une tâche difficile peut utiliser les 64 couches avec davantage de délibération.
Produire des actions, pas simplement du texte
CAPE-R cherche à réduire l’ambiguïté entre ce que le modèle dit et ce que le système doit réellement faire. Au lieu de laisser toutes les sorties sous forme de texte libre, l’architecture prévoit des actions explicites : READ, SEARCH, EDIT, TOOL, QUERY, STATE_UPDATE, FINAL et ABSTAIN.
Pour modifier du code, le modèle peut produire un EditIR indiquant le fichier et le symbole ciblés, la version attendue, le contenu à remplacer, le nouveau contenu et les vérifications nécessaires. Les modifications peuvent aussi être protégées par le hash du contenu attendu. Si le patch a été préparé sur une version A du fichier mais que le dépôt est maintenant en version B, CAPE-R peut rejeter la transaction plutôt que d’appliquer silencieusement une modification devenue obsolète.
Le modèle propose. Le système vérifie.
Le modèle reste responsable de la partie intelligente : comprendre, raisonner, écrire du code, proposer une correction et sélectionner un outil. Mais il n’est pas l’autorité finale chargée de décider si son propre travail est correct.
Avant qu’une modification soit appliquée, CAPE-R peut vérifier :
- que l’action respecte le contrat ;
- que la cible appartient au périmètre autorisé ;
- que le fichier correspond toujours à la version attendue ;
- que le patch peut être appliqué ;
- que le code reste syntaxiquement valide ;
- que les tests nécessaires passent et que les critères de la mission sont respectés.
Si tout est valide, la transaction est commitée. Si une vérification échoue, elle est rejetée et ne modifie pas l’état officiellement validé du projet.
Le modèle ne décide pas seul qu’il a terminé
Les agents logiciels peuvent s’arrêter trop tôt ou continuer à modifier un projet alors que la mission est déjà accomplie. Dans CAPE-R, la notion de « terminé » possède donc un prédicat externe.
Tous les critères doivent être satisfaits, aucune tâche bloquante ne doit rester, les preuves nécessaires doivent exister, l’état final doit être commité et aucun conflit avec le contrat ne doit subsister. Le modèle peut estimer qu’il a terminé ; la décision finale dépend de l’état et des preuves disponibles, pas simplement de la phrase « tâche terminée ».
Que se passe-t-il lorsqu’une tentative échoue ?
CAPE-R n’interdit évidemment pas les erreurs. Un premier patch peut échouer à compiler ou révéler un nouveau test cassé. L’architecture conserve alors la preuve de l’échec et peut autoriser une nouvelle tentative.
Mais elle cherche à éviter les boucles où un agent répète pratiquement la même solution. Une nouvelle tentative doit être justifiée par une nouvelle information ou un progrès observable. La conception de référence prévoit ainsi un budget de réparation borné, avec un maximum initial de trois tentatives.
Une compilation qui échoue peut fournir une erreur précise ; un test qui échoue ensuite une contrainte de comportement. Ces nouvelles preuves relancent le raisonnement à partir de faits, plutôt que d’une boucle ouverte de réflexion sur sa propre réflexion.
Réutiliser ce qui a déjà été calculé
Découper une longue mission en transactions améliore le contrôle, mais certaines informations identiques pourraient être recalculées à chaque transaction. CAPE-R prévoit donc un Hybrid-State Prefix Cache — HSPC.
Les informations relativement stables sont placées dans un ordre canonique : contrat, informations stables du dépôt, preuves persistantes, puis informations spécifiques à l’action actuelle. La transaction suivante peut repartir du calcul correspondant à la partie stable plutôt que de recalculer tout le préfixe.
Cela complète le calcul adaptatif : moins de couches lorsqu’elles ne sont pas nécessaires, moins de raisonnement lorsqu’il n’apporte plus de valeur, et moins de pré-calcul redondant entre transactions.
Ce que CAPE-R change réellement par rapport au modèle de base
Le cœur du modèle reste celui de Qwen : mêmes 64 couches et même chemin complet de génération. Ce qui change profondément est la manière dont cette intelligence est utilisée.
| Qwen classique | CAPE-R |
|---|---|
| Conversation | Transaction d’exécution |
| Profondeur complète | 32 / 48 / 64 couches |
| Raisonnement relativement ouvert | Raisonnement budgété |
| État principalement dans le contexte ou le cache | State Fabric structuré |
| Sortie principalement textuelle | Actions typées |
| Le modèle peut déclarer avoir terminé | Fin déterminée par critères et preuves |
| Patch généré | Patch vérifié avant commit |
| Gestion des erreurs dépend du scaffold | Réparation pilotée par les preuves |
CAPE-R ne cherche pas à remplacer l’intelligence acquise pendant le pré-entraînement. Il cherche à l’organiser autour des contraintes particulières de l’exécution logicielle.
La vision derrière CAPE-R
CAPE-R repose sur une idée simple : un modèle utilisé comme exécuteur ne devrait pas fonctionner exactement comme un chatbot.
Lorsqu’il intervient sur un dépôt, nous voulons qu’il sache précisément ce qu’il doit faire, sur quel état il travaille, combien de calcul utiliser, quelle action il propose, ce qui prouve que cette action fonctionne et quand la mission peut être considérée comme terminée.
Cette séparation entre intelligence neuronale et contrôle déterministe structure CAPE-R. Le modèle reste chargé de comprendre, raisonner et générer ; le système prend en charge ce qui doit rester exact : état, permissions, versions, preuves et validation. Entre les deux, CAPE-R adapte le calcul à la difficulté réelle de chaque étape.
Faire de Formic non seulement un modèle performant en génération de code, mais un véritable moteur d’exécution logicielle : plus efficace, plus contrôlable et conçu dès l’architecture pour mener une mission jusqu’à un résultat vérifié.