Project Standard : le standard maison, en une commande

Dans la plupart des équipes, le standard existe. Il vit dans la tête des gens, dans un vieux repo qu'on recopie, dans la relecture de celui qui a l'œil. Il ne survit jamais tout à fait au projet suivant.

Project Standard, c'est notre tentative d'en faire autre chose qu'une culture orale : un plugin Claude Code qui installe, configure et audite le standard sur n'importe quel dépôt, neuf ou déjà lancé.

Le standard est découpé en modules qu'on peut installer séparément. Les portes de qualité en intégration continue — scan de secrets, lint, typage, format, tests, build — sur chaque pull request. Les hooks locaux, pour que la même exigence s'applique avant même le commit. Les skills de projet, qui outillent la release, l'audit, la spécification et la prise de ticket.

Puis le câblage Atlassian, avec un board Jira et un arbre Confluence pour les exigences, les décisions et l'architecture. Ferry, pour l'automatisation par agents. Le modèle de branches et de releases. Et l'infrastructure : cible de déploiement, mail transactionnel, doctrine de secrets.

Rien de tout ça n'est original pris séparément. Ce qui l'est, c'est de refuser que ces choix soient à refaire à chaque démarrage.

Un outil qui s'installe sur un dépôt existant peut faire beaucoup de dégâts. Celui-ci commence donc par ne rien écrire : il interroge, puis produit une analyse d'écart en lecture seule, module par module — absent, présent, ou dérivé par rapport au standard.

Le plan d'installation qui en découle attend une confirmation explicite, une seule, avant d'écrire quoi que ce soit. Sur un dépôt déjà conforme, relancer la commande ne fait rien d'autre qu'un audit.

C'est ce qui rend l'outil utilisable sur un projet vivant, et pas seulement sur un dépôt vide.

Le dépôt est public, ce qui impose une discipline stricte sur ce qu'il contient. Il documente où vivent les secrets et comment ils s'appellent — jamais leur valeur, qui reste dans les secrets GitHub, les fichiers d'environnement du serveur et les portails des fournisseurs.

Il ne porte pas non plus de coordonnées d'infrastructure : ni nom d'hôte, ni adresse, ni identité de client. Chaque cible de déploiement est un paramètre que l'entretien d'installation remplit depuis ton propre environnement.

Cette contrainte a coûté du travail, et elle est ce qui rend le standard partageable. Un standard qu'on ne peut pas publier n'est qu'une configuration privée de plus.

Le standard n'a pas été conçu dans l'abstrait : il est distillé de deux projets en production, un site client sous Next.js et un agent de support par IA. Le premier a donné les portes de qualité et les skills, le second l'automatisation par agents et l'infrastructure.

C'est aussi sa limite, et autant le dire : ce standard est le nôtre. Il encode nos arbitrages, pas des vérités universelles. Il est publié sous licence MIT pour être lu, repris et contredit — pas pour être appliqué tel quel par quelqu'un qui n'aurait pas fait les mêmes choix.