Nous ne laissons pas l'IA corriger sa propre copie
Chaque changement traverse une boucle fixe, un modèle indépendant et des preuves exigées avant d'atteindre votre dépôt.
Le harness est un plan de contrôle propriétaire que nous avons construit et que nous exploitons en interne. Il transforme la programmation assistée par IA en une organisation d'ingénierie dotée d'une mémoire durable, d'une revue indépendante et de décisions qui restent les vôtres. Il gouverne aussi notre propre livraison, y compris ce site.
Comment Oronts garantit-il la fiabilité du code écrit avec l'IA ?
En supprimant les deux raccourcis qui rendent la programmation agentique peu fiable. Le modèle qui écrit le code ne le valide jamais, et la conversation n'est jamais la source de vérité. La revue s'exécute sur un modèle différent et l'état réside dans des fichiers durables qui survivent à une réinitialisation du contexte.
- Un modèle différent examine le travail, appuyé par deux perspectives contradictoires et des spécialistes activés selon la surface modifiée
- La réutilisation est vérifiée contre le graphe réel de dépendances, elle ne peut donc pas être simplement affirmée
- Terminé signifie critères d'acceptation atteints et preuves à jour, pas un unique test au vert
- Les décisions produit, juridiques et irréversibles restent les vôtres
Quatre modes de défaillance, quatre mécanismes
La programmation agentique ordinaire échoue de quatre façons prévisibles. Le harness répond à chacune par un mécanisme plutôt que par une promesse.
| Mode de défaillance | Ce qui se passe réellement | Le mécanisme |
|---|---|---|
| Elle génère au lieu de concevoir | Du code nouveau apparaît alors que le framework, la bibliothèque standard ou le dépôt lui-même résolvaient déjà le problème. | Une échelle de réutilisation qui s'arrête au premier barreau correct, plus un vérificateur qui rejette tout plan citant un paquet ou un chemin inexistant. |
| Elle oublie | Le contexte se remplit, la conversation est compactée, l'agent perd l'objectif et vous demande de tout réexpliquer. | Les fichiers de mémoire durable sont la source de vérité. La reprise se déclenche au démarrage et après chaque compaction, et poursuit l'action suivante exacte. |
| Elle corrige sa propre copie | Le modèle qui a écrit le code l'examine et le valide. | Un modèle différent examine, complété par deux perspectives contradictoires indépendantes et des spécialistes. Les constats sont arbitrés par la preuve et relancés à neuf après chaque correction. |
| Elle livre le chemin heureux | Un test au vert, aucun cas négatif, aucune preuve à l'exécution, et c'est déclaré terminé. | Terminé signifie : acceptation atteinte, preuves proportionnées au risque et à jour face à l'empreinte Git réelle, relecteurs sans constat, état synchronisé. |
À quoi ressemble vraiment une exécution
Deux volets issus d'une session réelle. À gauche, la boucle rend compte de chaque étape au fil de l'eau. À droite, l'observateur en lecture seule dérive un instantané des fichiers de mémoire et du Git vivant, puis l'affiche.
Un constat renvoie le travail vers la vérification au lieu de le pousser vers un commit. L'exécution s'arrête à une autorisation plutôt que de publier.
$ node .claude/tools/oronts-status.cjs --watch
- HEAD
- ad2fcd4 · tree: clean
- active
- T-008
- next
- German barge-in
- gates
- G-004
- TASKS
- 12 total · active 1 · ready 4 · completed 7
- BLOCKERS
- 1
- FINDINGS
- crit 0 · high 0 · med 2 · low 5 (2 open of 7)
L'observateur n'écrit jamais de fichier et ne modifie jamais Git. Le supprimer laisserait la boucle d'ingénierie intacte.
Une cadence, un effort proportionnel à la conséquence
Toute tâche substantielle suit la même cadence. Une coquille reçoit une vérification ciblée. Une situation de compétition sur un paiement, une migration ou un chemin d'autorisation reçoit un débat de conception, une revue spécialisée et une preuve réelle à l'exécution. La profondeur vient de la conséquence, jamais du nombre de lignes modifiées.
Les constats renvoient le travail vers la vérification, ils ne le poussent pas vers un commit. La boucle ne se ferme que lorsque les relecteurs n'ont plus rien à signaler.
S'arrêter au premier barreau qui résout correctement
Le harness optimise le minimum de code neuf nécessaire à un système correct, pas le maximum de code visible. Un vérificateur déterministe fonde chaque affirmation de réutilisation sur le graphe réel de dépendances : un plan citant un paquet absent du dépôt échoue avant que l'implémentation ne commence.
- 1Cela doit-il seulement exister ?
- 2Le dépôt le fait-il déjà ?
- 3La bibliothèque standard le fait-elle ?
- 4Est-ce natif au framework ou à la plateforme ?
- 5Une dépendance déjà installée le fait-elle ?
- 6Existe-t-il un point d'extension disponible ?
- 7Seulement alors : le minimum de code neuf
Un moteur, trois préoccupations, une autorisation
Des points d'entrée nommés alimentent un moteur unique. Le moteur pilote en parallèle le raisonnement, le déterminisme et la durabilité, et tout ce qui est irréversible sort par une porte qui vous appartient.
Points d'entrée
Langage courant, une skill nommée, ou une campagne autonome bornée.
- Skills33
- Objectif
- Campagne
Moteur
Un fichier unique et lisible traite les événements du cycle de vie : réconcilier Git, injecter l'état, doser l'effort, appliquer les autorisations. Aucun service caché, aucun processus en arrière-plan.
- engine.cjs1
- Réconciliation Git
- Reprise
Raisonnement
Relecteurs indépendants et déploiements déterministes multi-agents.
- Agents de revue21
- Workflows5
Déterminisme
Des contrôles qui passent ou échouent sans modèle dans la boucle.
- Outils24
- Règles37
Durabilité
Un état qui survit à la conversation et à toute réinitialisation du contexte.
- Fichiers de mémoire15
- Journaux chaînés
Votre autorisation
Les actions irréversibles et commerciales s'arrêtent ici dans tous les modes de permission, y compris les exécutions sans surveillance.
- Push et publication
- Release et déploiement
- Opérations destructrices
- Coffres de secrets
Le plan de contrôle est copié dans un dépôt et le gouverne. Il est livré générique ; chaque projet remplit son propre état.
Un modèle différent, pas un second avis du même esprit
Quatre questions de revue indépendantes et un mécanisme de décision. Les constats sont arbitrés par la preuve, pas par vote majoritaire. Un bloquant correct pèse plus que dix validations. Après chaque correction, les revues sont relancées à neuf contre le travail modifié, car un relecteur qui touche l'arbre invalide l'empreinte précédente.
| Instance de revue | La question qu'elle pose |
|---|---|
| Revue inter-modèles | Qu'est-ce qui ne va pas et que le modèle rédacteur, étant le même esprit, a pu manquer ? |
| Perspective de correction | Cela peut-il échouer, corrompre, fuiter, entrer en compétition ou violer le comportement attendu ? |
| Perspective de maintenabilité | Est-ce compréhensible, minimal, sans duplication et correctement placé ? |
| Spécialistes activés | Est-ce correct pour la sécurité, la base de données, le contrat d'API, l'interface, l'infrastructure ou l'IA ? |
| Instance d'architecture | Dans quel sens trancher une véritable bifurcation de conception ? Elle décide, elle ne vote pas. |
Les spécialistes s'activent selon la surface modifiée, non de façon générale par projet. Une migration appelle le relecteur base de données, une frontière d'autorisation appelle la sécurité, un flux distribué appelle la concurrence.
Lorsque le relecteur inter-modèles est indisponible, cela est consigné comme indisponible et une perspective indépendante supplémentaire est ajoutée. Le harness ne signale jamais une revue qui n'a pas eu lieu.
Ce qui prime sur quoi
La hiérarchie est explicite et survit à un changement de modèle. Un test au vert fait autorité sur le comportement observé. Un relecteur fait autorité sur la question de savoir si ce comportement est le bon invariant. Aucun ne remplace l'autre.
- 1Tests exécutables et preuves à l'exécution
- 2Revue indépendante inter-modèles
- 3Revue par le même modèle
- 4Raisonnement de l'instance principale
- 5Simple affirmation
La compaction est un point de contrôle, pas une remise à zéro
Le problème le plus difficile des longues exécutions autonomes est le contexte. Il se remplit, la conversation est résumée, et un agent naïf oublie l'objectif et s'arrête. Le harness traite le résumé comme un point de contrôle. Des fichiers durables conservent l'objectif, la tâche courante, l'action suivante exacte, les décisions, les blocages, les preuves et l'historique. La conversation peut être jetée, l'état demeure.
L'état, pas la conversation
Les fichiers de mémoire sont la source de vérité. La transcription est jetable.
Reprise au démarrage et à la compaction
Un hook réconcilie Git et réinjecte l'empreinte réelle, la tâche active, ses critères d'acceptation et les autorisations ouvertes.
Vos instructions survivent
Les demandes sont consignées de façon déterministe, si bien que les consignes ponctuelles jamais devenues une tâche ne sont pas perdues.
Il poursuit au lieu d'attendre
Après réconciliation, il reprend l'action consignée sans redemander un contexte qu'il détient déjà.
Skills, plugins et serveurs MCP
Les capacités vivent en trois couches pour que le système reste cohérent et rapide plutôt qu'un assemblage d'outils redondants. D'abord la capacité du cœur, un spécialiste seulement pour une profondeur réelle, jamais un doublon de ce que le cœur fait déjà.
33 points d'entrée nommés dans la boucle
Une skill détermine à quelle profondeur une tâche entre dans la cadence. Les noms sont les identifiants propres du produit et restent inchangés dans toutes les langues.
Démarrer et orienter
- start
- route
- triage
- plan
- estimate
- capabilities
Construire
- implement
- fix
- refactor
- ui
- api-change
- database-change
- ai-change
- infrastructure-change
- dependency-change
Garantir
- review
- verify
- audit
- security-review
- red-team
- gdpr
- debate
Exploiter et transmettre
- autopilot
- campaign
- memory
- doctor
- handoff
- finish
- release
- present
- team
- adopt
Fournie
- excalidraw-diagram
Plugins activés
Six plugins forment l'ossature du raisonnement et de la revue. Ils sont câblés dans la boucle, pas proposés en options.
- superpowers
Débogage systématique, méthode guidée par les tests, planification et vérification, invoqués à chaque tâche pour que déboguer signifie reproduire puis corriger, et non deviner.
- codex
Un modèle indépendant et réellement différent pour la revue. La revue par le même modèle partage les mêmes angles morts ; un autre modèle brise cette corrélation.
- andrej-karpathy-skills
Garde-fous contre les pièges courants : supposer au lieu de demander, surconcevoir, et laisser les diffs s'étaler.
- impeccable
Ancrage produit et design pour le travail d'interface, afin que les écrans répondent à un besoin réel et non à une sortie générique.
- claude-mem
Mémoire inter-sessions, complémentaire à celle du dépôt et jamais prioritaire sur ce que dit Git.
- claude-obsidian
Intégration optionnelle d'une base de connaissances pour un contexte métier et domaine durable.
Chaque plugin activé charge ses descriptions dans toutes les sessions : l'ensemble activé est donc volontairement restreint.
Serveurs MCP, sollicités à la demande
Les connecteurs de données sont câblés en lecture et recherche uniquement, si bien qu'une session autonome ne peut pas modifier ces systèmes. L'automatisation de navigateur peut agir sur une page, donc tout effet externe passe par votre autorisation plutôt que d'être exécuté en silence.
- Context7lecture
Documentation de bibliothèque et de framework juste pour la version installée, au lieu de deviner d'après les données d'entraînement.
- GitHublecture
Faits à jour sur les dépendances, contexte des pull requests et des tickets, et code source amont.
- Playwrightnavigateur
Preuve réelle en navigateur pour les parcours d'interface, une capture venant compléter la preuve plutôt que la remplacer.
- filesystemlecture
Accès fichier cadré et structuré pour la recherche dans un grand arbre.
- memorylecture
Un graphe de rappel complémentaire, subordonné à l'état du dépôt.
- sequential-thinkingraisonner
Raisonnement structuré en plusieurs étapes pour un problème réellement difficile.
- opentabsnavigateur
Accès navigateur authentifié via votre propre session, employé avec parcimonie et soumis à autorisation pour toute écriture.
Spécialistes par projet
Experts de langage, analyse statique réelle et outils de domaine étroit sont installés par dépôt plutôt qu'inscrits dans la configuration partagée, car chaque plugin activé coûte du contexte à chaque session.
Sur un travail critique pour la sécurité, l'écart réel avec la revue par modèle tient à l'analyse réelle : un moteur d'analyse statique et un scanner de dépendances, de conteneurs et d'infrastructure tournent aux côtés du relecteur sécurité, car un analyseur détecte des classes qu'une revue par modèle manque.
Ce que contient le plan de contrôle
Le harness est livré générique et indépendant du projet. Il est copié dans un dépôt et chaque projet remplit son propre état. Un unique fichier moteur lisible pilote le cycle de vie. Aucun service caché, aucun processus en arrière-plan.
| Couche | Nombre | Rôle |
|---|---|---|
| Règles d'ingénierie | 37 | Standards toujours chargés, plus des paquets par langage et par surface |
| Skills | 33 | Points d'entrée nommés dans la boucle |
| Agents de revue | 21 | Relecteurs indépendants, spécialistes et enquêteurs |
| Workflows | 5 | Déploiements déterministes multi-agents |
| Outils déterministes | 24 | Autocontrôles, évaluateurs, synchronisation et observateur d'état |
| Fichiers de mémoire | 15 | État durable qui survit à la compaction |
| Documents de référence | 36 | Spécifications d'architecture et de protocole |
| Modèles | 34 | Registres de décision, contrats, runbooks, modèles de menace |
| Moteur | 1 | Un unique fichier lisible qui traite les événements du cycle de vie |
Mesuré sur le dépôt le 5 septembre 2026. Le harness est un produit propriétaire Oronts et n'est pas publié. Nous le parcourons en direct lors d'un échange ou sous accord de confidentialité.
Ce qu'il ne fait jamais seul
L'autonomie est bornée par conception. Les décisions irréversibles et commerciales sont refusées au niveau des permissions dans tous les modes, y compris les exécutions sans surveillance, et ne peuvent pas être accordées par une instruction dans la conversation.
- Sémantique produit, visibilité et politique de rétention
- Licences, tarifs et contrats publics rompant la compatibilité
- Accès à la production, déploiement et mise en production
- Publication de paquets, force push et opérations git destructrices
- Actions destructrices sur l'infrastructure
- Lectures des coffres de identifiants et de secrets
- Toute réduction d'un contrôle de sécurité
Lorsqu'il doit demander, il demande avec des preuves : les options, les arbitrages, une analyse, une objection du modèle indépendant et une recommandation. La décision vous revient, la recherche n'est pas votre travail.
Ce que nous n'affirmons pas
Les limites connues sont des faits d'ingénierie, pas des choses à cacher. Un système d'entreprise n'est pas celui qui est dépourvu d'incertitude. C'est celui où l'incertitude est connue, bornée, visible et couverte par des preuves proportionnées à ses conséquences.
Entreprise ne signifie pas architecture maximale
Le harness porte un processus qui dérive l'architecture adaptée à chaque projet, pas une pile universelle. Un petit utilitaire interne et une plateforme multi-locataires reçoivent une rigueur différente du même système.
Un processus sain n'est pas un produit livré
Un harness au vert prouve que le processus d'ingénierie est sain. Votre produit devient prêt pour la production quand ses propres portes sont au vert : chiffres de charge, preuve de migration et de retour arrière, tests d'isolation et une revue de sécurité.
Le vérificateur de réutilisation a une limite
C'est un contrôle solide d'intégrité référentielle contre les manifestes et les fichiers, pas un résolveur de paquets complet pour tous les écosystèmes.
La qualité architecturale reste en partie un jugement
Elle est appuyée par une revue indépendante, elle n'est pas présentée comme une garantie automatisée.
Pourquoi cela compte pour vous, pas pour nous
Du code défendable en revue
Chaque changement porte ses critères d'acceptation, ses preuves et les verdicts qui l'ont validé.
Un registre de décisions, pas une tradition orale
Les décisions de conception sont écrites avec leurs alternatives et leur raisonnement : votre équipe hérite du pourquoi, pas seulement du quoi.
La vitesse comme conséquence
La rigueur est l'objectif. La vitesse découle du fait de ne pas reconstruire l'existant et de ne pas rejuger les décisions déjà prises.
Propriété complète à la remise
Le plan de contrôle dirige le travail. Le code, les décisions et la documentation vous appartiennent.
Questions posées par les responsables techniques
Voyez-le tourner sur un vrai problème
Apportez un changement qui vous rendrait normalement nerveux. Nous parcourons la façon dont la boucle le traite, les preuves qu'elle produit et l'endroit où elle s'arrêterait pour vous interroger.
Avec qui vous travaillez
Niveaux d'engagement
Oronts travaille avec des équipes sérieuses qui ont besoin d'une livraison senior, pas d'externalisation low-cost.
- Pilote de production
- à partir de 25k EUR
- Projets logiciels et IA sur mesure
- à partir de 50k EUR
- Retainers techniques continus
- à partir de 15k EUR/mois
Le prix exact dépend du périmètre, des responsabilités, de la vitesse de livraison, de la taille d'équipe, des intégrations, des attentes de support et du risque de production.