- Kasava gère l’ensemble du processus de développement produit dans un unique monorepo, en intégrant code, documentation, marketing et données opérationnelles
- Chaque changement est appliqué via un commit unique, avec mise à jour simultanée du backend, du frontend, du site web et de la documentation
- Des outils d’IA référencent directement le code, la documentation et le site web pour vérifier la cohérence, mettre à jour automatiquement la documentation et relire les contenus
- CLAUDE.md, le CI/CD sélectif et une structure de projets npm indépendants permettent de minimiser la complexité d’un dépôt de grande taille
- Cette approche renforce une culture de développement AI-native et supprime les frontières entre produit, contenu et opérations pour permettre des déploiements rapides et une meilleure collaboration
Le sens du développement AI-native et du monorepo
- Kasava regroupe tous les composants de sa plateforme dans un seul dépôt Git, incluant non seulement le code mais aussi la documentation, le marketing, les e-mails et les documents destinés aux investisseurs
- Ex. :
frontend/, backend/, website/, docs/, marketing/, external/, avec plus de 5 470 fichiers TypeScript
- L’IA accède simultanément au code et à la documentation pour réaliser une automatisation fondée sur le contexte
- Modification de la documentation, changement de prix sur le site web, vérification d’articles de blog : tout peut être traité dans une seule conversation avec l’IA
- Tous les changements sont déployés via le même workflow Git (
git push)
- Code, contenu, documentation et marketing suivent les mêmes processus de revue, de CI/CD et d’audit
- Cette méthode améliore la vitesse et la cohérence et installe une culture où « tout est géré comme du code »
Pourquoi tout intégrer dans un seul dépôt
- Modifications atomiques entre frontières (Atomic Changes)
- Lorsqu’une API backend est modifiée, les définitions de types du frontend et la documentation sont mises à jour dans le même commit
- Exemple : lors de l’ajout d’une intégration Asana, backend, frontend, documentation et site web sont fusionnés dans une seule PR
- Source unique de vérité (Single Source of Truth)
- Un seul fichier,
billing-plans.json, définit les limites des offres tarifaires, et tous les services s’y réfèrent
- L’IA vérifie automatiquement la cohérence entre backend, frontend et site web
- Refactoring cross-project
- Dans l’IDE, il est possible de rechercher et modifier l’ensemble du code, de la documentation et même des exemples d’articles de blog
- Outils et pipelines partagés
- Un CI/CD commun, des dépendances communes et un environnement de recherche partagé simplifient l’administration
Structure du dépôt et composants
- Core Application :
frontend/ repose sur Next.js 16 + React 19, tandis que backend/ utilise Cloudflare Workers + Hono + Mastra- En cas de changement d’API, la sûreté de typage et les utilitaires de test sont partagés
- Marketing :
- Inclut
website/, marketing/blogs/, investor-deck/, email/
- Les articles de blog, e-mails et documents investisseurs sont tous versionnés comme du code, avec possibilité de rollback via
git revert
- Documentation :
docs/ correspond à la documentation publique basée sur Mintlify, et docs-internal/ à la documentation d’architecture interne- Recherchable avec le code, elle reste à jour en temps réel au lieu de dépendre d’un wiki
- External Services :
- Inclut des services déployés en externe comme une extension Chrome, un module complémentaire Google Docs et des fonctions GCP
- Le partage des contrats d’API permet de répercuter les changements simultanément
- Development Infrastructure :
- Comprend des serveurs simulés et des outils de test pour le développement local, comme
github-simulator/, infra-tester/, scripts/
Mode de fonctionnement et culture de développement
- Sans workspaces
- Chaque répertoire est conservé comme projet npm indépendant afin d’éviter les conflits de dépendances
- CI/CD sélectif (Selective CI/CD)
- GitHub Actions se déclenche en fonction des chemins concernés pour n’exécuter que les tests pertinents
- Règles
CLAUDE.md
- Chaque répertoire principal documente sa stack technique, ses commandes et ses décisions d’architecture
- Les assistants IA les lisent pour comprendre le contexte du projet
- Configuration d’outillage cohérente
- Des réglages communs sont maintenus, comme
.prettierrc, .eslintrc, tsconfig.json
Défis et réponses
- Taille du dépôt : le temps de clone est actuellement d’environ 20 secondes, sans problème de performance Git
- Les ressources volumineuses devraient être séparées vers R2/S3
- Temps de build : chaque projet est buildé indépendamment, avec des rebuilts rapides grâce à Turbopack, Wrangler et WXT
- Frontières de permissions : une petite équipe peut tout consulter ; si nécessaire, CODEOWNERS et la protection de branche peuvent être appliqués
- Changement de contexte : le passage entre différents langages (TypeScript, Apps Script, MJML) est atténué par
CLAUDE.md et un format unifié
Conclusion
- Le monorepo de Kasava n’est pas une simple tendance, mais un outil de maximisation de la productivité par l’intégration du contexte
- Backend, frontend, documentation et marketing fonctionnent dans un seul flux de changement, et l’IA en vérifie la cohérence en temps réel
- En fin de compte, « le monorepo n’est pas une contrainte mais un accélérateur (force multiplier) »
Aucun commentaire pour le moment.