Souverain et open source : j'ai fait écrire, tester et corriger un vrai projet par un modèle de 35B. Voici ce que ça donne.

1. Pourquoi je teste sérieusement les alternatives ouvertes

J’utilise Claude Code au quotidien, et je l’assume pleinement : c’est aujourd’hui l’un des meilleurs agents de code du marché. Mais utiliser le meilleur outil propriétaire ne dispense pas de préparer l’après. En parallèle, je cherche et je teste les alternatives open source et souveraines les plus prometteuses : celles qui tournent sur mon infrastructure, sans dépendance à un fournisseur cloud unique, sans données qui partent ailleurs, et sans risque qu’une politique tarifaire ou géographique me coupe l’accès du jour au lendemain.

La souveraineté n’est pas un slogan : c’est la capacité à continuer à travailler quoi qu’il arrive. La question concrète est simple : est-ce qu’un stack 100 % ouvert et auto-hébergé est aujourd’hui assez bon pour faire du vrai travail d’ingénierie ? Cet article raconte une expérience de bout en bout qui répond, à mon sens, par un « oui » de plus en plus net.

2. pi : l’agent de code open source

Le premier pilier, c’est pi (@earendil-works/pi-coding-agent), un agent de code open source dans l’esprit de Claude Code ou Codex. Il existe en deux formes : un CLI pour le terminal, et pi-gui, une application de bureau (Electron). pi est extensible (skills, outils, hooks, providers) et, surtout, il sait pointer n’importe quel endpoint compatible OpenAI. C’est la porte d’entrée pour brancher un modèle ouvert auto-hébergé à la place d’une API cloud.

Autrement dit : pi fournit l’agentique (lecture/écriture de fichiers, exécution de commandes, orchestration de tâches), et je choisis le cerveau. Restait à trouver un cerveau ouvert à la hauteur.

3. Ornith 1.0 : un modèle qui apprend à écrire son propre échafaudage

C’est là qu’arrive Ornith 1.0, publié le 25 juin 2026 par DeepReinforce, un laboratoire spécialisé en apprentissage par renforcement. C’est une famille de modèles open source dédiés au code agentique, en plusieurs tailles, architectures Dense et MoE, sous licence MIT et sans restriction régionale. Les bases utilisées sont Gemma 4 et Qwen 3.5.

J’ai retenu le Ornith-1.0-35B :

• Architecture : Mixture-of-Experts, 35B de paramètres totaux, ~3B activés par token (donc rapide et peu gourmand à l’inférence pour son niveau).
• Contexte : jusqu’à 256K tokens (je l’ai servi à 128K dans mon déploiement).
• Raisonnement : oui (mode « thinking »).
• Base : post-entraîné sur Qwen 3.5 (il s’identifie d’ailleurs spontanément comme « Qwen3-Coder »).

L’innovation : Ornith a appris sa propre méthode de travail, pas seulement à écrire du code

La vraie nouveauté d’Ornith n’est pas sa taille, c’est la façon dont il a été entraîné. Pour la comprendre, il faut distinguer deux choses dans un agent de code :

• le code lui-même, c’est-à-dire la réponse produite ;
• le scaffold, c’est-à-dire la « méthode de travail » qui pilote la production de ce code : comment décomposer la tâche, quoi garder en mémoire, quand lancer les tests, comment réagir à une erreur et réessayer. C’est la logique d’orchestration autour du modèle.

Dans la quasi-totalité des agents actuels (Claude Code, Codex, etc.), ce scaffold est écrit à la main par des humains et reste figé. Le modèle n’optimise alors que le « quoi » (le code), à l’intérieur d’une méthode de résolution qu’on lui impose de l’extérieur. Un entraînement « classique sur du code » revient à apprendre à produire de meilleures réponses, point.

DeepReinforce a fait autrement. Pendant l’entraînement par renforcement, le modèle a appris à construire son propre scaffold en même temps qu’à résoudre les tâches. D’après le rapport officiel, chaque étape de RL se déroulait en deux temps : d’abord, à partir de la tâche et du scaffold utilisé la fois précédente, le modèle proposait un scaffold affiné ; ensuite, en suivant ce nouveau scaffold, il générait une solution. La récompense obtenue sur ce résultat remontait alors aux deux étapes à la fois. Le scaffold n’était donc plus un harnais figé conçu par des humains, mais un objet apprenable qui co-évoluait avec la politique du modèle (sa mémoire, sa gestion d’erreurs, sa logique d’orchestration). Répété sur tout l’entraînement, ce processus a fait émerger les méthodes de résolution menant aux meilleures trajectoires, c’est-à-dire de meilleures stratégies que celles qu’un humain aurait codées en dur.

L’analogie est parlante : au lieu de seulement entraîner un élève à donner la bonne réponse, on l’a aussi entraîné à inventer sa propre méthode (comment décomposer un problème, où chercher l’information, comment vérifier son travail), en ne le notant que sur le résultat obtenu. C’est, sur un autre terrain, la même intuition que je défendais dans « Est-il encore utile d’apprendre ? » : on apprend mieux quand on apprend à raisonner, pas seulement à restituer.

Laisser un modèle écrire son propre scaffold ouvre évidemment la porte au « reward hacking » : apprendre à satisfaire le vérificateur sans vraiment résoudre la tâche. DeepReinforce s’en prémunit sur trois niveaux : une frontière de confiance figée (l’environnement, les outils et l’isolation des tests restent hors d’atteinte du modèle, qui ne fait évoluer que sa logique interne) ; un moniteur déterministe qui met à zéro toute trajectoire tentant de lire des chemins interdits ou de modifier les scripts de vérification ; et un juge LLM gelé qui agit comme un veto. Côté algorithme, l’entraînement repose sur une perte GRPO au niveau token avec un pipeline-RL asynchrone. Le point important pour le lecteur : les scores ne sont pas « gonflés » par de la triche, ce qui rend la comparaison avec des modèles bien plus gros d’autant plus parlante.

En quoi cela améliore le résultat ? Cette méthode de travail apprise est désormais gravée dans les poids du modèle. À l’usage, Ornith ne se contente pas de produire une fonction isolée : il sait mener la boucle agentique complète (décomposer, mémoriser, lancer les tests, lire l’erreur, corriger, recommencer) de façon plus efficace. C’est précisément ce que mesurent des benchmarks comme Terminal-Bench ou SWE-Bench, où il faut itérer pour résoudre une vraie tâche, et non réussir du premier coup. Et c’est ce qui explique qu’un 35B y dépasse des modèles bien plus gros : ces derniers ont peut-être plus de connaissances brutes, mais Ornith dispose, lui, d’une procédure de résolution optimisée de bout en bout.

Les chiffres

Pour un modèle ouvert de cette taille, les résultats sont frappants :

Benchmark	Ornith-1.0-35B
Terminal-Bench 2.1 (Terminus-2)	64,2 %
SWE-Bench Verified	75,6 %
SWE-Bench Pro	50,4 %
NL2Repo	34,6 %

Le détail qui fait réfléchir : sur Terminal-Bench, ce 35B MoE dépasse Qwen 3.5-397B (53,5 %). Un modèle dix fois plus petit en paramètres totaux, et largement plus petit en paramètres actifs, qui passe devant. Dans mon setup, je l’ai fait tourner via vLLM sur un GPU RTX PRO 6000 Blackwell loué chez RunPod.

4. Le projet sovereign-pi-gui : rendre le stack réellement utilisable

Avoir le bon agent et le bon modèle ne suffit pas : il faut les marier proprement, dans le CLI et dans l’application de bureau. C’est l’objet de mon premier dépôt, sovereign-pi-gui, qui documente la procédure complète. Le chemin a été instructif, avec quelques pièges réels :

• La bonne méthode est ~/.pi/agent/models.json. pi sait déclarer un provider OpenAI-compatible custom (Ollama, vLLM, LM Studio…) dans ce fichier de données. Avantage majeur : il est lu à la fois par le CLI et par pi-gui, via le même registre de modèles.
• Le piège évité : l’extension qui crashe l’app. On peut aussi enregistrer un provider par une extension (pi.registerProvider). Ça marche en CLI, mais cette voie tire une librairie de terminal (pi-tui) qui fait planter le runtime Electron de pi-gui. models.json est de la donnée pure : elle ne peut rien crasher. Diagnostic confirmé en branchant le débogueur Chrome sur l’app et en lisant son état runtime.
• pi-gui n’a pas encore d’UI pour les endpoints custom (la PR amont est ouverte mais pas mergée). models.json est donc le contournement officiel en attendant, et le modèle apparaît dans le sélecteur du composer (pas dans l’écran « Providers »).
• Le reste du « mirror » : les skills (14 « superpowers » de process + 6 skills créatifs Anthropic), des extensions de sécurité/TUI, et webapp-testing (Playwright headless) pour les tests E2E.

Le dépôt contient la procédure pas-à-pas, un models.json.example, un script d’installation idempotent, et la note honnête sur les limitations actuelles de pi-gui. Bref : un stack 100 % open source et auto-hébergé, du modèle jusqu’à l’IDE.

5. secret-scan : l’épreuve du feu

Un stack qui démarre, c’est bien. Un stack qui produit du code de qualité, c’est ce qui compte. J’ai donc lancé un vrai projet test, secret-scan : un scanner de secrets en TypeScript (détecteurs AWS, GitHub, JWT, Stripe, clés privées PEM, etc., filtres anti-faux-positifs, redaction, rapports texte/JSON/HTML, et tests). Tout a été généré, testé et corrigé par pi + Ornith, en souverain. Claude Code n’est intervenu qu’en auditeur externe, comme un relecteur senior. Voici les étapes.

Étape 1 : la génération initiale

À partir d’une simple intention, pi piloté par Ornith a déroulé un workflow agentique (génération tâche par tâche) et produit, en autonomie, une architecture modulaire propre : un détecteur par type de secret, des filtres, trois formats de rapport, un CLI avec codes de sortie adaptés à la CI, un README, des commits, un push GitHub. Premier constat : ce n’est pas un script jetable, c’est structuré comme un vrai petit projet.

Étape 2 : les tests

Le modèle a écrit ses propres tests : un fichier par détecteur, plus des tests d’intégration et de filtres. La discipline « code + tests » est tenue sans qu’on la lui rappelle à chaque étape.

Étape 3 : la première revue (Claude Code)

C’est là que j’ai sorti l’artillerie. Verdict : propre pour du code généré, mais un bug disqualifiant. Le walker de fichiers ignorait tout ce qui commence par un point (startsWith('.')), donc les .env, .aws/credentials, .npmrc… c’est-à-dire la source numéro un de fuites de secrets. Pire : c’était en contradiction avec son propre détecteur env qui ciblait explicitement les .env. Le bug était passé parce que les fixtures utilisaient config.env (sans point initial), évitant pile le cas réel.

J’ai aussi relevé une redaction trop bavarde (préfixe et suffixe visibles), des filtres anti-faux-positifs trop agressifs, une troncature silencieuse, des artefacts de build committés, et l’absence de scan de l’historique git. Au crédit du projet : zéro dépendance runtime (excellent pour un outil de sécu), des rapports qui redactent déjà les secrets, et un rapport HTML qui échappe correctement le HTML.

Étape 4 : le premier lot de correctifs (Ornith)

Et c’est là que ça devient intéressant. Sur la base de ma revue, pi + Ornith a produit un commit dédié, propre et bien nommé : fix: critical .env scanning bug + hardened redaction and filtering, suivi d’un commit de documentation. Concrètement :

• Le bug .env corrigé, et bien : le startsWith('.') supprimé, seuls .git/node_modules/dist restent exclus, avec un commentaire expliquant pourquoi les dotfiles doivent être scannés.
• Redaction durcie exactement comme je l’avais suggéré : on ne montre plus qu’un court préfixe, jamais le suffixe.
• Filtres rendus conservateurs (match exact au lieu de sous-chaîne), donc moins de faux-négatifs.
• Troncature rendue bruyante, nettoyage du .gitignore, et même la correction d’un vrai bug d’edge case que je n’avais pas demandé.
• Ajout d’une section « limitations » au README, c’est-à-dire assumer honnêtement ce que l’outil ne fait pas.

Étape 5 : la revue finale (Claude Code)

Re-revue : les correctifs sont corrects. Le bug critique est réglé proprement, la redaction et les filtres sont conformes aux recommandations. Restent quelques nitpicks mineurs (un commentaire un peu optimiste, un cas .env.local à surveiller) et des manques architecturaux assumés (pas de scan de l’historique git, et le fait que réinventer gitleaks restera moins complet qu’un outil dédié). Mais ce sont des choix de périmètre, plus que des défauts d’implémentation.

Le point qui compte vraiment : un modèle ouvert de 35B, en souverain, n’a pas seulement écrit un projet non trivial. Il a su encaisser une revue technique exigeante et agir dessus correctement. C’est précisément la partie difficile, celle qui sépare une démo d’un outil de travail.

6. Conclusion : le gap fond à vue d’œil

Il y a encore un an, l’écart entre les modèles géants fermés et les modèles ouverts ressemblait à un gouffre. Cette expérience le confirme par l’exemple : il se resserre très vite. Un 35B MoE qui dépasse un 397B sur Terminal-Bench, qui tient un workflow agentique réel de bout en bout, qui se fait auditer par un modèle frontière et qui applique les correctifs juste, le tout sur mon infrastructure, sous licence MIT, sans rien envoyer dans le cloud : c’était de la science-fiction récemment.

Le schéma gagnant aujourd’hui n’est même pas « l’un contre l’autre ». C’est l’ouvert et le souverain qui construisent, le frontière qui audite, et l’écart entre les deux qui se réduit à chaque sortie de modèle. La souveraineté n’est plus un compromis théorique réservé aux cas de contrainte : elle devient une option d’ingénierie crédible et productive.

Je continue à utiliser Claude Code. Mais je sais désormais, preuves à l’appui, que je peux aussi travailler entièrement chez moi quand il le faut. Et ça, ça change tout.

---

Liens et sources

• Mes dépôts : sovereign-pi-gui et secret-scan
• Ornith 1.0 : rapport technique officiel (DeepReinforce), carte modèle Hugging Face, site officiel
• Couverture presse : MarkTechPost, TechTimes, LLM Reference