Piloter un projet par l'état, pas par la conversation

Si vous avez utilisé un assistant de codage par IA — Claude, Copilot, Cursor, Windsurf — vous avez rencontré la même limite fondamentale : le contexte vit dans la conversation. Quand la conversation devient trop longue, le contexte antérieur se perd. Quand vous fermez la session et revenez, vous recommencez à zéro. Quand une autre personne reprend le travail, elle ré-explique tout.

C'est suffisant pour écrire une fonction. Ça ne l'est pas pour piloter un projet.

Le problème de la conversation

Un vrai projet logiciel a un cycle de vie : découverte, spécifications, conception de solution, planification, construction, qualité, livraison, apprentissage. Chaque étape produit des artefacts et des décisions dont dépend l'étape suivante. Dans un outil basé sur la conversation, ces artefacts existent sous forme de messages de chat — non structurés, non versionnés, et impossibles à reprendre sans remonter dans des centaines de messages.

Résultat : le développement assisté par IA fonctionne très bien pour des tâches isolées et terriblement pour des projets. Vous pouvez générer une fonction, mais vous ne pouvez pas piloter un projet.

L'état d'abord : l'approche d'Amar Studio

Amar Studio est construit sur une prémisse différente : l'état du projet est la source de vérité, pas la conversation.

État de projet persistant et versionné

Le projet conserve un état persistant : objectifs, éléments de travail, artefacts, décisions, preuves, risques, dette, retours, et un journal d'événements en ajout seul. Un nouvel agent lit cet état et continue — aucun historique de conversation nécessaire.

Cela signifie :

• La reprise fonctionne sans ré-expliquer. Une nouvelle session lit l'état, voit ce qui est fait et ce qui est en attente, et reprend là où la dernière session s'était arrêtée.
• Différents agents peuvent travailler sur différentes parties. Le runtime liste les éléments de travail éligibles pour chaque rôle, et un agent en revendique un avec un bail borné.
• L'état est auditable. Chaque décision, artefact et preuve est enregistré avec attribution.

Le rôle d'abord, pas le chat d'abord

Chaque rôle — PO, Analyste, PM, Designer, Architecte, Tech Lead, Dev, DevOps, Reviewer, QA, Rédacteur, Bibliothécaire — a une responsabilité et une autorité explicites. Le runtime ne déverse pas tout le système dans le prompt. Il ne charge que les compétences, les outils et les artefacts dont le rôle a besoin pour l'élément de travail en cours.

C'est plus proche du fonctionnement d'une vraie agence que de celui d'un chatbot. Vous ne racontez pas tout au stagiaire sur l'entreprise — vous lui confiez une tâche, le contexte dont il a besoin, et l'autorité d'agir dans un périmètre défini.

Achèvement piloté par les preuves

Aucun élément de travail n'est marqué « terminé » sans critères et preuves :

• Preuves de fichier SHA-256 (le fichier existe et correspond)
• Résultats de tests (les tests passent)
• Portails de qualité (linting, SAST, couverture)

Si un obstacle est trouvé, le travail reste blocked avec un responsable et une action requise — aucun échec silencieux, aucun « je corrigerai plus tard ».

Compétences versionnées

La méthode est séparée de l'agent qui l'applique. Les compétences (les méthodes) évoluent via des amendements révisés — jamais d'écrasement silencieux. Un Bibliothécaire d'agents dédié est la seule autorité habilitée à modifier les compétences. Cela signifie que le système s'améliore au fil temps de manière contrôlée et auditable — et non par des changements de prompts non documentés.

Pourquoi c'est important pour les non-développeurs

Amar Studio n'est pas seulement pour les développeurs. Il s'adresse aux professionnels qui ont besoin de la rigueur d'un flux de développement dans leur propre domaine — finance, comptabilité, opérations.

Le registre inclut un rôle d'analyste financier avec des compétences pour la vérification de la paie, la détection de fraude, le rapprochement bancaire, le lettrage des paiements, la catégorisation des flux de trésorerie, la piste d'audit et la validation de clôture mensuelle. Un professionnel de la finance peut exécuter le même cycle découverte → spécifications → solution → planification → construction → qualité → livraison → apprentissage, l'IA gérant le travail structuré et l'humain validant les résultats.

C'est tout l'enjeu : la discipline de l'ingénierie logicielle — versionnage, preuves, revue, décisions traçables — a de la valeur bien au-delà du logiciel. Amar Studio l'apporte à des domaines qui n'en ont jamais bénéficié.

Le modèle hybride

La vraie puissance vient de la combinaison du raisonnement probabiliste (IA) avec l'exécution déterministe :

• L'IA lit l'état et génère un plan (probabiliste)
• Le runtime exécute le plan via des outils déterministes (système de fichiers, terminal, Git, navigateur)
• Les résultats sont ré-injectés dans le contexte (preuves déterministes)
• L'IA s'adapte en fonction des résultats (probabiliste)

Ce cycle — planification probabiliste → exécution déterministe → vérification continue — est ce qui rend le développement piloté par l'état possible. L'état ancre l'IA dans la réalité. Les outils déterministes garantissent que les actions ont des effets réels et vérifiables. Et l'état persistant signifie que le projet peut être mis en pause, repris, audité et gouverné.

---

Cet article décrit l'architecture derrière Amar Studio, la plateforme de développement pilotée par l'état d'Uptech LLC, actuellement en développement actif.