Avancement LCMS Crew

Lots

Lot L5 — Agent Lead : intégration, pull request, PREPROD

Quand tous les lots d'un projet sont au vert, le Lead prend le relais : il réunit les lots sur une branche d'intégration, relit l'ensemble au regard du cahier des charges, corrige ce qui casse et passe le contrôle global. La pull request s'ouvre alors, avec une description rédigée et les liens Jira, et la plateforme met en ligne une PREPROD sur le projet Firebase de la société.

Critères d'acceptation

Livré

• Une livraison par dépôt touché par le projet : branche d'intégration, pull request GitHub (ou merge request GitLab), PREPROD si le dépôt a un site Firebase.
• Revue et contrôle global par le Lead, dans le même conteneur isolé que les agents Dev ; 3 tentatives, puis escalade par e-mail et relance avec une consigne.
• Description de la pull request rédigée par le Lead, complétée par la plateforme : lien PREPROD, tableau des lots, tickets Jira. Une relance met à jour la même pull request, sans doublon.
• PREPROD publiée par la plateforme elle-même, jamais par l'agent, avec la clé du compte de service de la société chiffrée dans sa connexion Firebase (test de connexion compris).
• Jira : commentaire avec les liens sur chaque ticket, statut « à certifier » s'il est configuré.
• Onglet Livraison : branche, pull request, PREPROD et expiration, historique des déploiements, tentatives et journal du Lead ; site Firebase à déclarer par dépôt dans Réglages > Dépôts.

Décisions notables

• Pas de Firebase CLI dans le conteneur : la plateforme appelle directement l'API de Firebase Hosting, la clé ne quitte donc jamais la plateforme.
• Un conflit de fusion entre lots est confié à un humain, sans tentative de l'agent (résolution automatique hors v1).
• La PREPROD reste sur le projet Firebase de chaque société ; merge, version et PROD attendent le verdict QA et un Go humain (lot L7). Le cahier des charges passe en v1.10.

Détail : docs/decisions/0009-agent-lead.md et docs/guides/firebase-preprod.md dans le dépôt.

Lot L4 — Orchestrateur et agents développeurs

Le découpage validé, les agents Dev réalisent les lots : chacun dans un conteneur isolé, vague par vague, avec ses contrôles de qualité. Un lot qui échoue est retenté, puis confié à un humain ; le travail réussi arrive sur une branche dédiée du dépôt de la société.

Critères d'acceptation

Livré

• Réalisation automatique dès la validation du découpage : les lots dont les dépendances sont prêtes démarrent, dans la limite d'agents en parallèle de la société.
• Conteneur isolé par tentative : sans Internet, sans droits d'administration, limité à son propre espace de travail. Sa seule sortie est une passerelle qui donne accès au modèle (et au registre npm) le temps de l'exécution et dans le budget.
• Contrôles N0 exécutés par la plateforme, pas déclarés par le modèle : installation, lint, typage, tests, build ; l'agent corrige jusqu'à trois fois par tentative.
• Tentatives et escalade : 3 par lot par défaut ; ensuite le lot attend un Tech Owner ou un Admin, prévenu par e-mail, qui le relance avec une consigne.
• Pause, reprise et annulation d'un projet ; l'annulation arrête les agents en cours et leur coupe l'accès au modèle.
• Onglet Réalisation : lots par vague, tentatives, contrôles N0, journal de l'agent, coût, lien vers la branche.
• Connexion GitHub par jeton d'accès limité aux dépôts choisis ; la plateforme clone et pousse elle-même, uniquement les branches crew/*.

Décisions notables

• La clé Bedrock et les jetons Git ne quittent jamais la plateforme : les agents n'en ont aucun.
• Le travail d'un agent revient comme une simple donnée, que la plateforme vérifie avant de pousser : rien de ce que l'agent a pu modifier n'est exécuté par la plateforme.
• Machines d'états des projets et des lots : aucune transition sans rapport de l'étape précédente. Le cahier des charges passe en v1.9.
• À l'hébergement : exécution des agents sur des tâches cloud à la place de Docker local, plafond global de conteneurs, GitHub App.

Détail : docs/decisions/0008-orchestrateur-agents-dev.md et docs/guides/bac-a-sable.md dans le dépôt.

Lot L3b — Import de cahier des charges et de maquette

Une société qui arrive avec un cahier des charges déjà rédigé, ou une maquette faite avec Claude, le dépose : un agent le découpe en epics et en tickets reliés à leur passage d'origine. Le Product Owner relit, un responsable technique approuve, et seulement alors les tickets sont créés dans Jira, prêts pour le parcours du lot L3.

Critères d'acceptation

Livré

• Dépôt d'un Word, d'un PDF ou de l'export HTML d'une maquette (20 Mo au plus, type vérifié sur le contenu), ou de l'URL d'un artefact Claude, récupérée depuis les seuls hôtes de Claude, sans exécuter ses scripts.
• Documents chiffrés avec la clé de la société ; un document déjà importé est reconnu.
• Extraction des titres, listes, tableaux et pages ; pour une maquette, des écrans, champs, boutons et de la navigation. Un PDF numérisé est signalé.
• Agent de découpage : epics, tickets avec critères d'acceptation et estimation, sections non découpables, questions au PO.
• Revue par le PO, avec le passage d'origine affiché à côté de chaque ticket : modifier, fusionner, ajouter, supprimer, déplacer ; nouveau découpage après réponse aux questions.
• Validation technique : le PO soumet ; un Tech Owner ou un Admin, prévenu par e-mail, corrige, renvoie avec un commentaire ou approuve. Personne n'approuve son propre import.
• Création dans Jira après approbation seulement : epics puis tickets, lien vers le document d'origine, sans doublon en cas de relance. Les tickets arrivent dans « À planifier ».
• Historique des imports : document, auteur, validateur, tickets proposés et créés, coût.

Décisions notables

• Aucun ticket n'est créé dans Jira sans le feu vert d'un humain technique (demande du 30/09/2026) ; le cahier des charges passe en v1.8.
• Le contenu des documents et des maquettes est une donnée, jamais une consigne pour l'agent.
• Les réponses des agents arrivent désormais en flux continu : les découpages longs ne sont plus interrompus.

Détail : docs/decisions/0007-import-cdc.md dans le dépôt.

Lot L3 — Générateur de cahier des charges et découpage

Deux agents IA entrent en scène sur AWS Bedrock : le Planner rédige le cahier des charges d'un projet à partir de ses tickets Jira, l'Architecte le découpe en lots prêts pour les agents développeurs. Le Product Owner garde la main à chaque étape.

Critères d'acceptation

Livré

• Projets de réalisation : un panier de tickets, éventuellement de plusieurs projets Jira ; un ticket n'appartient qu'à un seul projet actif ; annuler un projet libère ses tickets.
• Regroupements proposés par le Planner parmi les tickets à planifier, modifiables avant de créer un projet par groupe.
• Déclencheurs Jira : un ticket passé en « A developper » est proposé pour un projet ; s'il appartient déjà à un projet sans cahier des charges, le Planner démarre. Les changements faits par la plateforme ne déclenchent rien.
• Cahier des charges rédigé par le Planner : contexte, exigences rattachées aux tickets, règles de gestion, critères d'acceptation, hors périmètre ; questions au PO plutôt qu'une invention.
• Éditeur du cahier des charges, avec historique des versions et restauration ; révision par le Planner à partir des réponses et des consignes du PO.
• Validation par le PO : les tickets passent à « En dev » dans Jira et l'Architecte prend le relais.
• Découpage par l'Architecte : lots avec objectif, exigences couvertes, fichiers, critères d'acceptation, dépendances, dépôt et branche ; graphe par vague de parallélisme ; fiche de lot modifiable ; validation par le Tech Owner ou automatique.
• Catalogue des dépôts GitLab et GitHub, joints selon les connexions de la société, et règles d'affectation par projet Jira.
• Réglages de la Crew : modèle Claude par rôle, budgets mensuel et par projet, coût de chaque appel d'agent affiché.

Décisions notables

• Bedrock en Irlande (eu-west-1), données dans l'Union européenne : Paris n'a pas encore le point d'accès nécessaire. Modèles Opus 5 et Sonnet 5 ; les versions 5.5 se choisiront dans les réglages quand AWS les servira en Europe.
• Clé Bedrock de la plateforme dans Google Secret Manager, à renouveler tous les 30 jours jusqu'à l'hébergement (fédération d'identité, sans clé stockée).
• Les contenus des tickets et du CDC sont traités comme des données, jamais comme des consignes pour les agents.
• Le cahier des charges passe en v1.7 : découpage d'un projet depuis une maquette Claude ajouté au lot L3b.

Détail : docs/decisions/0006-bedrock.md et docs/guides/bedrock-aws.md dans le dépôt.

Lot L2 — Connecteur Jira

Chaque société relie son Jira Cloud, importe ses tickets, les garde à jour et voit leur statut évoluer dans Jira au fil des étapes.

Critères d'acceptation

Livré

• Connexion Jira par jeton d'API, dans Réglages > Connexions, avec un bouton « Tester la connexion » ; le jeton est chiffré et jamais réaffiché.
• Import par projet, epic, sprint ou label, ou par requête JQL libre (Admin, Product Owner) : aperçu, puis import de la sélection ou de tout le résultat.
• Synchronisation automatique toutes les 15 minutes et à la demande ; un ticket supprimé dans Jira disparaît de la liste.
• Statuts : chaque société choisit, parmi les statuts réels de ses projets, ceux qui correspondent aux étapes En dev, En recette et Livré.
• Commentaires automatiques signés au nom du produit de la société, prêts pour l'agent Lead (lot L5).
• Jira de démonstration intégré, pour les tests automatiques et les démonstrations sans compte Jira.
• Compte de service Atlassian pris en charge (méthode recommandée par Atlassian) : connexion au Jira de L2D vérifiée, 50 projets accessibles.
• Guides pas à pas dans Réglages > Connexions, pour chaque service (Jira, GitHub, GitLab, AWS Bedrock, Firebase) : où créer la clé, quels droits cocher, quoi saisir, erreurs fréquentes.
• Tickets Jira : sélection de plusieurs projets, filtres par statut du workflow, projets éligibles choisis par l'Admin.
• GitLab ajouté aux connexions, à côté de GitHub (gitlab.com ou instance auto-hébergée), avec test de connexion ; les agents l'utiliseront dès les lots L4 et L5.

Décisions notables

• Webhooks Jira reportés à l'hébergement de l'application : Jira ne peut appeler qu'une adresse publique ; la synchronisation périodique suffit d'ici là.
• Connexion OAuth reportée : le jeton d'API couvre le besoin de la v1.
• Les jobs du worker s'exécutent dans le contexte de leur société : l'isolation des données s'applique aussi aux traitements en arrière-plan.

Détail : docs/decisions/0004-connecteur-jira.md dans le dépôt.

Lot L1 — Authentification, sociétés, marque blanche

Chaque société dispose de son espace isolé, à son nom et à ses couleurs : comptes et rôles, invitations, connexions externes aux secrets chiffrés, domaine personnalisé.

Critères d'acceptation

Livré

• Connexion par e-mail et mot de passe, session sécurisée : jetons dans des cookies inaccessibles au code de la page, renouvellement automatique, protection contre les tentatives répétées.
• Sociétés créées par le super-admin depuis la console plateforme ; société par défaut L2D, produit « L2D Crew ».
• Marque blanche : nom du produit, logo et couleurs appliqués à l'interface, à l'écran de connexion et aux e-mails d'invitation.
• Rôles Admin, Product Owner, Tech Owner, Lecteur ; un utilisateur peut appartenir à plusieurs sociétés et passer de l'une à l'autre.
• Invitations par e-mail, acceptation en un clic : création du compte, ou confirmation par mot de passe si le compte existe.
• Connexions externes (Jira, GitHub, AWS, Firebase) gérées par l'Admin et le Tech Owner ; les secrets n'apparaissent plus que comme « enregistré ».
• Domaine personnalisé : déclaration, vérification par enregistrement DNS, société et marque reconnues dès l'écran de connexion ; certificat HTTPS émis automatiquement une fois en production.

Décisions notables

• Double barrière d'isolation : filtre applicatif et Row-Level Security PostgreSQL, avec un compte de base de données qui ne peut pas la contourner.
• Secrets chiffrés avec une clé propre à chaque société, elle-même protégée par une clé maîtresse, prête pour un coffre AWS en v2.
• Des tests garde-fous échouent si un futur lot ajoute une table sans isolation.

Détail : docs/decisions/0002-auth-isolation.md dans le dépôt.

Compléments livrés après le lot

• Console plateforme : membres de chaque société visibles et retirables ; suppression d'une société une fois vidée de ses membres (la société par défaut est protégée).
• Changement de société : société courante toujours affichée dans l'en-tête, sélecteur dès deux sociétés.
• E-mails réels par Mailjet, expéditeur no-reply@lcms-conseil.fr (domaine déjà authentifié) ; capture par Mailpit conservée en développement.
• Secrets de la plateforme dans Google Secret Manager (clé Mailjet, clés de chiffrement et de signature propres à la preprod et à la prod), récupérés par script sans jamais être affichés.
• Compte de développement recréé automatiquement à chaque démarrage de l'environnement local.

Détail : docs/decisions/0003-secret-manager.md dans le dépôt.

Lot L0 — Socle

Base technique commune à tous les lots : front React, API et worker Symfony, runtime des agents, environnement Docker complet et intégration continue.

Critères d'acceptation

Livré

• API : Symfony 7.4 LTS sur FrankenPHP (PHP 8.4), API Platform, Doctrine, Mercure intégré ; endpoint /health.
• Worker : même code Symfony, file de jobs Redis ; chaîne api → Redis → worker vérifiée par app:ping.
• Front : React 19, TypeScript strict, Tailwind CSS 4 et shadcn/ui, traductions (français, anglais prévu), thèmes clair et sombre, aucun nom de produit en dur.
• Runtime des agents : squelette TypeScript avec adaptateur de modèle et implémentation simulée (aucune clé nécessaire).
• Images de production pour l'api, le web et les agents, déjà réutilisables pour la cible AWS de la v2.
• Qualité : PHPStan niveau max, PHP-CS-Fixer, PHPUnit, ESLint, Prettier, Vitest ; CI GitHub Actions.

Décisions notables

• Ports locaux dédiés (interface 5180, api 8180, base 5442) pour cohabiter avec les autres projets du poste.
• Dépendances dans des volumes Docker : requêtes de développement 10 fois plus rapides sous Windows.
• Versions stables les plus récentes : API Platform 5, Vite 8, TypeScript 6.

Détail : docs/decisions/0001-socle.md dans le dépôt.

Prochaine étape : l’hébergement de la plateforme

La chaîne complète, du ticket Jira à la PREPROD, fonctionne en local. Le lot suivant met la plateforme en ligne :

• API et worker sur Cloud Run ;
• webhooks Jira ;
• exécution des agents sur des tâches cloud, avec un plafond global de conteneurs ;
• GitHub App aux jetons courts.

Vient ensuite le lot L6 : l'agent QA fait la recette Playwright sur la PREPROD.

Restent à faire en parallèle les recettes avec les vrais tickets de L2D (Jira, cahier des charges et découpage, import approuvé par un Tech Owner), ainsi que le renouvellement de la clé Bedrock avant le 30/10/2026.