Générer du code avec une IA, c'est devenu trivial. Le faire aux conventions de votre équipe — la bonne archi, les bons Dockerfile, la bonne CI, les tests attendus, des PR propres — c'est une autre histoire. C'est là que le vibe coding individuel atteint ses limites.

On partage comment on a industrialisé Claude Code chez GroupBees : du CLAUDE.md monolithique devenu ingérable jusqu'à une bibliothèque de skills modulaires et partagés, qu'on a construits et adoptés ensemble. Ils encodent nos best practices — archi hexagonale Python, Dockerfile multi-stage, tests, commits propres, PR labellisées, déploiement Cloud Run — et se chargent à la demande : le savoir devient activable pour toute l'équipe, sans alourdir le contexte.

En démo, on part d'une idée et on génère une petite app : back Python hexagonal, Dockerfile, CI/CD, tests aux conventions, commit squashé et PR — jusqu'au déploiement sur GCP. Le moment clé n'est pas la magie, c'est le contraste : la même demande sans les skills, puis avec. Les règles font la différence.

Mais une bibliothèque de skills, ça se gouverne : versionner, relire (un skill s'applique à tout ce qui sera généré, par toute l'équipe), détecter ce qui devient obsolète, maintenir en continu — sinon on recrée le monolithe ingérable.

Vous repartirez avec une méthodologie transposable à d'autres assistants (Cursor, Copilot) : passer du prompt qui marche au workflow qui scale.

Chez GroupBees, chaque dev avait son CLAUDE.md perso — illisible à plusieurs, impartageable, et chargé à chaque session : lourd en tokens à l'échelle. Les skills ont tout changé : nos conventions (archi, Dockerfile, CI/CD, tests) sont devenues des modules activés à la demande, partagés en équipe — une vraie usine de dev, à condition de les gouverner comme du code. Je raconte comment on l'a fait, ce que ça coûte en rigueur, et comment vous pouvez le rejouer — Claude Code, Cursor, Copilot.