Les agents peuvent-ils fusionner du code ?

Non. Ils ouvrent des pull requests en brouillon. Une personne relit et fusionne chaque changement ; rien ne fusionne automatiquement.

Comment annuler un changement ?

En annulant la fusion dans Git.

Realized.dev héberge-t-il un modèle ou un runtime ?

Non. Le travail s'exécute dans vos dépôts avec Cursor et vos modèles.

Combien de sous-agents en parallèle ?

Les exécutions locales sont configurées pour lancer au maximum 8 sous-agents à la fois. Cela ne concerne pas les agents cloud.

Qui paie l'usage des modèles ?

Vous, directement auprès de votre fournisseur. Aucune marge de notre part sur les tokens.

Le harness est-il open source ?

Une publication du harness est à l'étude.

Où vivent les spécifications ?

Dans docs/ de votre dépôt Git, avec les tâches et les constats.

Référence · Architecture

Guide d'architecture

Une référence unique sur la structure de l'usine logicielle, ce que fait et ne fait pas chaque couche, et la correspondance avec un engagement.

Mis à jour le 12 octobre 2026

Définitions

Usine logicielle: Des agents qui écrivent spécifications, tests et code dans vos dépôts, selon des règles qui exigent une revue humaine avant toute fusion.
Spec is Law: La spécification acceptée, pas le modèle, détient l'autonomie. Aucune implémentation sans spécification acceptée et test en échec.
Le harness: Le harness Realized : commandes, règles, sous-agents, hooks qui vérifient les actions des agents et scripts de bootstrap pour Cursor. Une publication du harness est à l'étude.
Engagement: Notre travail commercial par phases : Atelier de découverte, Pilote borné, Engagement de réalisation.

Les quatre couches

Couche	Ce qu'elle fait	Ce qu'elle ne fait pas
L1 Substrat de gouvernance	Vérifications de politique et liaison d'identité. Les agents ouvrent des pull requests en brouillon ; une personne approuve chaque fusion.	Le retour arrière consiste à annuler la fusion.
L2 Actuation bornée	Appels d'outils typés et autorisés vers les systèmes de référence.	Conçue pour éviter les écritures libres.
L3 Maillage d'orchestration	Coordonne les sous-agents sur la boucle. Les exécutions locales sont configurées pour lancer au maximum 8 sous-agents à la fois.	Ce réglage concerne uniquement les sous-agents locaux, pas les agents cloud.
L4 Modèles	Les modèles que vous apportez, depuis votre configuration Cursor.	Nous ne livrons ni modèle ni runtime et ne gardons aucun identifiant dans le dépôt.

Couche, boucle et phase

Chaque étape appartient à une couche. L'Atelier de découverte cadre la boucle, le Pilote borné l'exécute de bout en bout pour un workflow dans un environnement, et l'Engagement de réalisation l'étend à d'autres workflows.

Étape	Couche	Ce qui se passe	Première exécution
Spécification	L1 Substrat de gouvernance	Une personne écrit ou approuve le ticket et ses critères d'acceptation.	Atelier de découverte (cadrage)
Tests d'abord	L2 Actuation bornée	L'agent écrit des tests en échec à partir de ces critères.	Pilote borné
Exécution de l'agent	L2 Actuation bornée	Un agent cloud ouvre une pull request en brouillon, puis y enregistre son travail.	Pilote borné
Vérifications automatisées	L3 Maillage d'orchestration	L'agent exécute les tests avant de pousser, et une vérification de revue de code est effectuée sur le changement ; les constats sont consignés sur la pull request.	Pilote borné
QA	L3 Maillage d'orchestration	Un agent QA vérifie la prévisualisation et consigne un verdict prêt ou à signaler sur la pull request.	Pilote borné
Approbation humaine	L1 Substrat de gouvernance	Une personne relit et approuve chaque fusion.	Pilote borné

Workflow du harness

Spécifications, tâches et constats vivent dans docs/ de votre dépôt Git. Chaque critère d'acceptation passe par Red → Green → Refactor dans des sous-agents séparés : le test est écrit avant le code qu'il vérifie.

Les sous-agents locaux tournent par vagues de 8 au maximum. Les agents ouvrent des pull requests en brouillon. Ils ne peuvent pas fusionner : une personne relit et fusionne chaque changement, rien ne fusionne automatiquement, et le retour arrière consiste à annuler la fusion.

Où le travail s'exécute

Dans vos propres dépôts et votre chaîne d'outils, avec Cursor. Realized.dev n'héberge ni runtime ni modèle. La piste d'audit est votre historique Git.

Modèle de coûts

Vous apportez vos propres modèles. L'usage est facturé directement par votre fournisseur de modèles ; nous n'ajoutons aucune marge sur les tokens. Nos honoraires figurent sur la page Tarifs.

D'où viennent les chiffres

Chiffre	Type	Source
4 couches	Conception	L'architecture décrite sur cette page.
8 sous-agents à la fois	Réglage configuré	Les exécutions locales sont configurées pour lancer au maximum 8 sous-agents à la fois. Ne concerne pas les agents cloud.
90 minutes	Format fixe	Durée de l'Atelier de découverte.

Questions

Les agents peuvent-ils fusionner du code ?: Non. Ils ouvrent des pull requests en brouillon. Une personne relit et fusionne chaque changement ; rien ne fusionne automatiquement.
Comment annuler un changement ?: En annulant la fusion dans Git.
Realized.dev héberge-t-il un modèle ou un runtime ?: Non. Le travail s'exécute dans vos dépôts avec Cursor et vos modèles.
Combien de sous-agents en parallèle ?: Les exécutions locales sont configurées pour lancer au maximum 8 sous-agents à la fois. Cela ne concerne pas les agents cloud.
Qui paie l'usage des modèles ?: Vous, directement auprès de votre fournisseur. Aucune marge de notre part sur les tokens.
Le harness est-il open source ?: Une publication du harness est à l'étude.
Où vivent les spécifications ?: Dans docs/ de votre dépôt Git, avec les tâches et les constats.

Voir la boucle sur l'un de vos workflows ?

Réserver l'atelier de 90 minutes Référence sécurité et déploiement