Aurora — un environnement d'ingénierie agentique

Contexte

Un projet logiciel avance par étapes : explorer l'existant, planifier, implémenter, revérifier, livrer. Les outils d'IA générative isolés traitent ces étapes en une seule fenêtre de conversation — et perdent l'état du projet à chaque session.

Problème

Sans état persistant ni séparation des rôles, l'IA réexplores ce qu'elle a déjà exploré, improvise des décisions déjà prises et se valide elle-même. Le résultat n'est pas industrialisable.

Contraintes

• L'état du projet doit survivre aux sessions.
• Les décisions structurantes doivent être consignées, pas réinventées.
• Chaque livraison doit être revue par un point de vue différent.
• Les capacités (recherche de docs, audits, déploiement) s'ajoutent sans gonfler le prompt de base.

Mon rôle

Conception de l'architecture (orchestration, spécialisation, état), développement de l'ensemble, maintien d'une base de configuration lisible et open source.

Approche

Un agent orchestrateur qui délègue à des sous-agents spécialisés — architecture, interface, sécurité, revue, tests, exécution rapide — plutôt qu'un assistant unique qui fait tout. L'état du projet vit dans des documents versionnés dans le dépôt : statut, plan, décisions, avertissements. Chaque cycle se termine par une revue contradictoire et une vérification (build, tests) avant livraison.

Architecture

• Des dizaines d'agents spécialisés (architecture, UX, sécurité, revue, tests, exécution, recherche…), un par rôle.
• Des skills injectables à la demande (revue de code, vérification, commit, déploiement…).
• Plusieurs serveurs MCP pour les capacités externes (docs, navigateur, mobile…).
• Une couche d'état documentaire (« Agent State Layer ») : statut, plan, décisions et avertissements versionnés dans le dépôt.
• Un routage de modèles avec repli automatique : le bon modèle pour chaque agent, sans dépendre d'un fournisseur.

Décisions clés

• L'état dans le dépôt, pas dans la fenêtre de contexte : chaque session repart de documents, jamais d'un souvenir de conversation.
• La revue est un agent distinct : celui qui écrit n'est pas celui qui valide — revue adversariale + vérification en parallèle avant tout merge.
• Capacités à la demande : les skills se chargent quand ils servent, le contexte de base reste léger.
• Open source par défaut : la configuration est publique (MIT) et documentée.

Challenges

Le point dur n'est pas le nombre d'agents mais leurs frontières : qui décide quoi, et comment éviter les boucles. La couche d'état documentaire est la réponse — un contrat d'écriture clair entre orchestrateur et sous-agents.

Résultat

Un environnement d'ingénierie agentique en usage quotidien sur des projets réels, open source sous licence MIT sur GitHub (himuraxp/opencode-config).

Ce que ce projet démontre

Industrialiser l'IA dans les workflows d'ingénierie : agents spécialisés et gouvernés, état persistant, revue systématique — pas d'autonomie sans garde-fous.