Tout en code : comment faire tourner une entreprise avec un seul monorepo

 (kasava.dev)
3 points par GN⁺ 2026-01-01 | 1 commentaires | Partager sur WhatsApp
  • 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
    Publicité
  • 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
    Publicité
  • 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
    Publicité
  • 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) »

À lire aussi

1 commentaires

 
GN⁺ 2026-01-01
Commentaires sur Hacker News

  • Cela ne ressemble pas à la gestion de toute une entreprise, mais plutôt à un seul produit (monorepo)
    Il n’y a ni finance, ni RH, ni contrats, ni photos d’équipe — seulement une structure frontend + backend, avec un dossier marketing un peu inhabituel

    • En lisant l’article lié, on comprend que cette société est en réalité une entreprise d’une seule personne
      Il est donc possible d’avoir tout dans un seul repo, mais la valeur des « enseignements » qu’on peut en tirer devient discutable
    • « IA ! IA ! »
    • Il n’y a même pas de code d’infrastructure (IaC) dans le repo
    • J’aimerais voir un vrai exemple où absolument tout est mis dans un repo GitHub
      Par exemple, en incluant même des artefacts chiffrés, avec un modèle du type « seul le PDG détient physiquement la clé de chiffrement »
      Ce serait bien si GitHub ajoutait un concept de dossier privé, mais cela relève des ACL, donc c’est peut-être une exigence excessive

  • Je soutiens la philosophie du monorepo et de l’absence de branche de développement
    Mais il faut distinguer développement et release
    Il faut pouvoir découper des releases stables et faire du cherry-pick, et la stabilité de l’API entre frontend et backend doit impérativement être maintenue

    • Certaines personnes demandaient ce que signifiait exactement « no development branch »
      Si le développement se fait directement sur la branche principale, elles se demandent comment gérer en parallèle des travaux de tailles diverses
    • D’autres demandaient dans quels cas concrets le cherry-pick était nécessaire
      L’une d’elles expliquait exploiter plus de trois produits en monorepo, sans problème en déployant par unité de release stable
    • Une personne disait contrôler le moment du déploiement avec des feature flags
    • Une autre disait aimer conserver des branches anciennes
      Elle n’aime pas le git squash et affirme que l’approche par fork donne plus de liberté aux développeurs

  • L’idée qu’« un seul changement met tout à jour partout en même temps » est une illusion dangereuse
    Dans un système avec base de données ou API, il faut toujours prendre en compte la rétrocompatibilité
    Dans une organisation avec plusieurs équipes, il arrive qu’une équipe ne puisse pas valider une mise à niveau et bloque ainsi tout le monde
    C’est pourquoi un déploiement progressif est indispensable

    • Entièrement d’accord. Pour une petite entreprise comme Kasava, cela peut aller, mais dans un SaaS mondial, quelques minutes d’indisponibilité peuvent être fatales
      Le monorepo en soi n’est pas un problème, mais « tout déployer immédiatement en un seul changement » est impossible
      Parce que le schéma de base de données et le code ne peuvent pas changer simultanément
      Ce genre d’article ressemble à un billet de blog écrit par une IA, et il semble probable qu’il y ait très peu de vrais clients
    • Certains répondaient qu’il fallait séparer l’endroit où le code est stocké (repo) de la manière dont il est déployé
      Selon eux, il ne faut pas confondre problème d’organisation et problème technique, et il faut coordonner cela par des politiques inter-équipes et du leadership
    • Une personne expliquait utiliser un monorepo avec la génération automatique de code (openapi-generator) pour répercuter immédiatement les changements d’API entre services
      Elle ajoutait que c’est une approche rendue possible par la petite taille de l’équipe
    • À l’idée que « centraliser le contexte IA en un seul endroit » serait un avantage, d’autres répondaient qu’il suffisait de cloner plusieurs repos dans un workspace
    • À l’inverse, certains estimaient qu’il est pire de laisser chaque service conserver sa propre version sans jamais se mettre à jour

  • Avant, je n’aimais pas les monorepos, mais Claude Code m’a fait changer d’avis
    Quand frontend et backend sont dans le même repo, il est plus facile de les synchroniser

    • On peut très bien ouvrir Claude depuis le répertoire parent, mais le fait de pouvoir modifier les deux côtés dans un seul commit est apprécié
    • D’autres ont réagi en disant que « si la seule raison d’utiliser un monorepo est de réduire quelques flags de commande, c’est un peu ridicule »
    • Moi aussi, j’ai refactoré vers un monorepo parce qu’il était difficile de faire fonctionner ensemble plusieurs outils LLM
    • À cause des problèmes de hoisting de React Native, certains évitent yarn workspace, mais avoir les PRD ou les documents de planification dans le repo restait utile pour fournir du contexte à l’IA
    • En réalité, Claude Code peut gérer plusieurs répertoires à la fois, donc le monorepo n’est pas indispensable

  • Cet article donne l’impression d’avoir été écrit par une IA
    Il devient fatigant de chercher du contenu rédigé par des humains

    • En le passant dans GPTZero, cela semble presque entièrement généré par IA
      Des formulations comme « This isn’t just for… » ou « The Challenges (And How We Handle Them) » relèvent d’un style typiquement IA
    • À l’inverse, certains disaient aussi qu’ils en avaient assez des plaintes sur les textes écrits par IA
      En gros : même imparfait, n’est-ce pas déjà mieux que beaucoup de textes écrits par des humains ?

  • Le passage où l’on demande à « Claude de mettre à jour la page des prix » paraît étrange
    Si la page marketing est gérée dans le même repo, il est difficile de comprendre pourquoi on confierait cela à un LLM alors qu’il suffirait de lire les données d’un fichier de config

    • Certains faisaient remarquer que l’IA est en train de devenir une addiction ou une dépendance
    • D’autres rétorquaient que « la revue de code existe toujours »
      Autrement dit, la présence de l’IA ne signifie pas que les humains ne vérifient plus rien

  • Mettre « frontend, backend et site web » dans un seul repo paraît confus
    L’unification au niveau du commit semble intéressante, mais trois repos suffisent aussi largement
    Bien faire fonctionner un monorepo implique un coût de maintenance important

  • L’article semble écrit par une IA, mais l’idée elle-même, comme extension extrême de l’IaC, est intéressante
    D’où un sentiment mitigé

    • Certains trouvaient surprenant que la plupart des commentaires n’aient pas remarqué les signes d’un texte écrit par IA
      À mesure que ce style LLM deviendra familier au grand public, les textes actuels paraîtront probablement ringards
    • D’autres disaient qu’il aurait au moins fallu remplacer des expressions comme « Why This Matters »
    • Certains ajoutaient que publier cela sous un nom humain sans mentionner l’usage de l’IA ressemble à une forme de malhonnêteté intellectuelle

  • Garder le site web de l’entreprise dans le même repo permet de retrouver facilement les éléments de branding et le ton
    Cela facilite donc la génération automatique de présentations destinées aux clients ou de vidéos de démonstration
    Aller plus loin et réunir documentation, bugs et issues au même endroit paraît aussi intéressant

  • Dans l’ancienne startup Pangea, une structure similaire avait été mise en place
    Globalement, c’était positif, sans être parfait

    • À force de vouloir tout gérer via le repo, les changements de feature flags devenaient lents et il était difficile de gérer l’immuabilité des branches
    • Une fois arrivé à une vingtaine de services, GitLab CI est devenu lent et complexe
    • Les tests E2E étaient lents et instables, ce qui cassait souvent les pipelines
      Malgré cela, le passage à ARM a tout de même permis des résultats comme 70 % de réduction des coûts de calcul
      Lien vers Pangea
    • En réponse, quelqu’un demandait s’ils avaient utilisé des outils de monorepo comme turbo, buck, Bazel
      Sans ce type d’outils, on finit par atteindre les limites de scalabilité de la CI, selon lui