PROJ-AI : pour que vos projets ne s'arrêtent plus au livrable

I.Le matin d'après

Imaginez. Vous rentrez de quinze jours de vacances. Vous ouvrez le projet. Vous savez où il en est, sans devoir appeler trois personnes pour qu'elles vous remettent dans le bain, sans relire 240 mails, sans descendre 80 messages de Slack. Le projet vous le dit lui-même.

Comparez deux scènes, sans PROJ-AI, et avec.

Sans. Vous rentrez de vacances. Vous tombez sur 240 mails non lus, six fils Slack qui se croisent, deux versions du dossier d'archi qui ne sont plus synchrones, et trois décisions qu'on a prises sans vous mais que personne n'a vraiment écrites. Vous bloquez deux journées à « recoller les morceaux ». Vous appelez quatre collègues pour comprendre où on en est. Le lundi, vous n'avez rien produit ; vous avez réamorcé.

Avec. Vous ouvrez le projet. L'agent vous prépare un rapport de retour, adapté à votre rôle : trois décisions clés tracées pendant votre absence (avec qui, quand, pourquoi), deux livrables qui ont avancé, un point en suspens qui attend votre arbitrage. Le tout en une page, sourcé, navigable. Si vous êtes manager, le rapport remonte les arbitrages et la vélocité ; si vous êtes tech, il liste les ADR adoptés et les commits qui les implémentent. En vingt minutes, vous êtes à jour. Vous reprenez.

C'est ce changement de nature qui fait toute la différence. Pas un outil de plus à apprendre, un substrat qui tient le projet quand vous n'êtes pas là, et qui le restitue dans votre langue quand vous revenez.

II.Le coût caché de l'absence

Avant de décrire ce que PROJ-AI fait, il faut nommer ce qu'on perd quand on ne fait pas ce travail-là. Quatre fuites, pas une.

Et l'agent, dans tout ça ? Il redémarre froid à chaque session. Il ne sait pas ce qui a été décidé, ni pourquoi, ni quoi éviter. Il vous fait perdre le temps qu'il était censé vous faire gagner.

C'est le test de la session perdue. Et ce n'est pas un test de développeur, c'est un test de projet. Si la réponse est non, le projet s'érode : lentement, en surface tout va bien, mais la mémoire fuit pendant que vous regardez ailleurs.

III.Le Claude Code du projet

Trois familles d'agents existent aujourd'hui. Elles répondent à trois questions différentes, et la troisième n'avait pas encore d'outil dédié.

Note pour les puristes du paysage agentique : Cowork, Cursor Background Agents, et certains modes "team" se rapprochent de l'idée de collaboration multi-personnes. Ce qui distingue PROJ-AI, ce n'est pas qu'on est plusieurs sur le même outil, c'est qu'on est plusieurs sur le même repo de projet, avec une doctrine, une mémoire de décisions, et une grammaire d'agent partagées.

IV.Trois objets, une grammaire

PROJ-AI tient en trois mots : un repo, un agent, une doctrine. Ce sont les trois objets que tout projet long collectif devrait avoir, et que la plupart n'ont pas.

Pourquoi ces trois objets et pas plus ? Parce que la complexité tue l'adoption. Trois objets, c'est ce qu'une équipe peut tenir dans sa tête après une heure de présentation. Tout ce que PROJ-AI rajoute par-dessus, slash-commands, zones, hooks, scoring de DR, n'est qu'une mise en œuvre opérationnelle de cette triade.

Vu de plus près, les quatre couches

La triade repo · agent · doctrine est ce qu'on raconte. Voici comment elle s'empile concrètement, et qui consomme quoi à chaque étage.

V.Une seule mémoire, deux portes d'entrée

Le métier et la tech ne lisent pas, ne tapent pas, ne pensent pas pareil. PROJ-AI ne leur impose pas un outil commun, il leur donne deux portes d'entrée sur le même repo.

La porte métier, PROJ-AI Studio

Studio est l'application desktop de PROJ-AI : quatre vues principales, Cockpit (vue d'équipe et décisions), Guide (parcours de la doctrine), Hebdo (rituel hebdomadaire), Mensuel (synthèse exécutive régénérable). Pas de terminal. Pas de git status. Le métier décrit, valide, navigue ; Studio écrit dans le repo.

La porte tech, CLI & IDE

Le tech ouvre Claude Code, Cursor, Codex, Aider, ou Copilot dans le repo PROJ-AI. L'agent lit la doctrine. Les slash-commands déclenchent les rituels, /dr-create, /livrable-update, /hebdo. Le CLI est le terminal, la fenêtre noire où l'on tape des commandes. L'IDE est l'éditeur graphique, type VS Code ou Cursor. Les deux lisent la même doctrine que Studio. Pas de fork, pas de version "tech" et "métier" du repo, un seul lieu.

Pour le tech qui n'a pas Studio, il ne perd rien : le repo PROJ-AI s'utilise avec n'importe quel agent qui lit les fichiers du dépôt. C'est l'overlay qui porte la doctrine, pas Studio.

VI.L'espace de mémoire du projet

Dans le repo, six zones nommées, six rôles. Le projet n'est plus un dossier flou, c'est un plan d'archives qui se remplit au fil du temps.

• DOCS/, la matière brute. Tout ce qui rentre dans le projet : entretiens, audits, sources, données, captures.
• IDEAS/, l'idéation. Hypothèses, options, brouillons de pensée. Pas encore acté, mais capturé.
• DR/, les décisions. Une par fichier, scorée sur sept dimensions, datée, attribuée. Le cœur de la mémoire structurante.
• OUT/, les livrables. Les produits finis du projet, note exécutive, dossier d'archi, plan de migration. Régénérables à la demande.
• DOCTRINE/, les règles. Comment on travaille, comment l'agent doit se comporter, ce qu'on a appris des projets passés.
• AGENT/, la grammaire d'agent. Slash-commands, hooks, prompts engrammés, traces de session.

Chaque zone a sa propre vitesse. DOCS entre vite, beaucoup, une fois. DR rentre lentement, peu, mais avec un poids fort. OUT se régénère souvent. DOCTRINE change rarement et collectivement. Cette hiérarchie de vitesses, c'est ce qui permet au projet de vivre sans se noyer.

VII.Comment on travaille

Trois choses font qu'un projet PROJ-AI tient sur la durée : un cycle (DPEV), des engagements explicites envers le client, et des règles claires pour l'agent. Aucune n'est décorative, toutes ont été retravaillées en mission.

Le cycle DPEV, de l'idée au livrable

Quatre temps qui transforment une idée floue en livrable propre. Le même cycle qu'un humain suit dans sa pratique, et que l'agent applique quand on lui amène un travail à mener.

• DDiscuter. On confronte le besoin à la réalité, contraintes, risques, options, et on capture l'arbitrage dans un DR en cours, pendant la conversation. Sept dimensions de scoring forcent à expliciter ce qu'on aurait dit oralement.
• PPlanifier. Le DR engage : il décrit ce qu'on va produire, dans quel délai, avec quelles ressources. Visible par toute l'équipe.
• EExécuter. L'agent et l'humain travaillent dans le repo selon la décision. Les commits référencent le DR. La trace est lisible.
• VVérifier. Le livrable atteint-il la promesse ? Est-il scorable ? Le cycle se ferme, ou rouvre un nouveau DR.

VIII.Sur le terrain

Trois missions, six mois de pratique, des chiffres qu'on peut donner, et d'autres qui restent sous NDA. Voici ce qui est observable.

Pour rendre ça concret, voici deux cas typiques. Pas les missions elles-mêmes, leurs natures.

Cas 1 · La vie d'une équipe AI-first

Industriel français · 14 personnes · 6 mois

L'équipe doit basculer en mode AI-first : cartographie des compétences, gouvernance des décisions, rituels hebdomadaires, transmission entre vagues d'arrivées. PROJ-AI installe le repo, la doctrine d'équipe, les rituels Hebdo / Mensuel, et l'agent qui les nourrit.

Avant

• Ramp-up : ~3 semaines
• Décisions tracées : ~30 % (mémoire orale)
• Note exécutive : 3 versions Word, ré-éditées à la main
• Mémoire d'équipe : dans la tête du chef de projet

Après

• Ramp-up : ~2 jours
• Décisions tracées : 100 % (DR scorés et datés)
• Note exécutive : régénérée à la demande
• Mémoire d'équipe : dans le repo, lisible par tous

Industriel français · 14 personnes · 6 mois · ordres de grandeur observés

Cas 2 · La production d'un livrable d'architecture

Grande distribution · équipe tech mixte · 6 semaines

L'objectif : livrer un dossier d'architecture (DAPROJ) sourcé, arbitré, et défendable devant le COMEX. Habituellement compilé en mode Word/PowerPoint en fin de mission. Avec PROJ-AI : sourcing dans DOCS/, arbitrages dans DR/, dossier compilé en continu.

Et surtout : à la fin de la mission, le client n'hérite pas que du PDF, il hérite du repo. Il peut interroger l'agent six mois plus tard pour comprendre pourquoi on a tranché tel arbitrage. Il peut régénérer le livrable avec de nouveaux inputs (un changement de réglementation, un nouveau périmètre, une réorg).

Avant

• Compilation DAPROJ : ~6 semaines en sprint final
• Décisions à reformaliser : ~20 à la main
• Note exécutive : 3 versions, désynchronisées
• Sources tracées : annexes Word, jamais relues

Après

• DAPROJ compilé en continu
• 20 ADR scorés sur 7 dimensions, attribués
• Note exécutive régénérée à la demande
• Sources liées dans le repo, traçables au commit près

Grande distribution · équipe tech mixte · 6 semaines · ordres de grandeur observés

IX.Le lean collectif

Un projet PROJ-AI qui réussit produit deux choses : son livrable, et une contribution à la bibliothèque commune. C'est le multiplicateur qui change la pratique d'une organisation.

Tout projet PROJ-AI dépose dans la bibliothèque collective ce qui a marché : un type de DR qui s'est avéré utile, un slash-command bien tourné, un fragment de doctrine éprouvé. Avant publication, l'élément est anonymisé, sanitisé, scoré. Tout nouveau projet pioche dedans pour démarrer en 30 minutes au lieu d'une semaine.

C'est ce qui transforme PROJ-AI de « un repo bien rangé » en actif organisationnel qui se compose : chaque mission rend la suivante un peu plus rapide, un peu plus fiable, un peu mieux outillée.

X.Et maintenant

Avant d'aller plus loin, deux choses à dire pour cadrer honnêtement la nature de la collaboration et l'état réel de l'outil.

La techno c'est 20 %, l'équipe c'est 80 %

L'overlay PROJ-AI s'installe en quelques minutes sur un repo. La discipline qui le fait tenir, décider en DR, lire la doctrine, faire confiance à l'agent dans son périmètre, accepter de tracer ce qu'on faisait à l'oral, ça ne s'installe pas. Ça se transmet, en mission, avec une équipe qui en pratique déjà la grammaire. La techno est nécessaire ; l'équipe est suffisante.

Les deux objections qu'on entend

« C'est un meta-harness, vous fabriquez de la complexité par-dessus des outils qui marchent. » Réponse honnête : oui, PROJ-AI ajoute une couche. Mais cette couche existe parce qu'aucun outil ne fait le métier de mémoire de projet collective. Notion ne sait pas versionner une décision. Confluence ne sait pas être lu par un agent. Claude Code ne sait pas ce qu'est un livrable de conseil. La couche est mince et nommée, pas un meta-framework. C'est un overlay.

« Vous êtes Claude-only ? » Non. La doctrine est en Markdown ; les slash-commands sont des conventions de fichiers. Claude Code est notre agent par défaut parce qu'il lit bien le repo, mais Codex, Gemini CLI, Cursor et Copilot lisent le même overlay. Si demain un autre agent fait mieux, on bascule sans changer le repo.

Si vous lisez ces lignes et que vous menez un projet de conseil long et collectif, ou que vous le commanditez, la vraie question n'est pas « est-ce que cet overlay est mature ». C'est « est-ce que je saurai encore relire mon projet dans six mois, ou est-il déjà éparpillé partout ». Si la réponse est non, on peut en parler.