Ce que m'a appris le travail sur un grand monorepo open source

Depuis fin 2023, je travaille sur Ever Teams et Ever Gauzy, deux plateformes open source construites par Ever Technologies : suivi du travail et du temps d'un côté, suite complète de gestion d'entreprise (ERP, CRM, RH…) de l'autre. Les deux vivent dans de grands monorepos où cohabitent applications web, desktop, mobile et serveur.

Voici ce que cet environnement m'a appris, au-delà de tel ou tel framework.

Lire les frontières avant le code

Dans un monorepo, l'arborescence est l'architecture. Avant de toucher une fonctionnalité, je regarde maintenant :

• apps/ — ce qui est réellement livré (web, mobile, desktop, serveur) ;
• packages/ — ce qui est partagé (kit UI, types, clients d'API, configuration) ;
• le sens des dépendances — les apps dépendent des packages, jamais l'inverse.

Casser ce sens (« j'importe juste ça depuis l'app web ») est la manière dont un monorepo devient lentement une grosse boule de code.

Les types partagés sont le vrai contrat d'API

Quand l'app web, l'app mobile et le serveur partagent un même package TypeScript de types, modifier un DTO casse la compilation partout où cela compte, avant même la revue. C'est le test d'intégration le moins cher qui existe. Le revers : un « petit » changement dans un package partagé demande le même soin qu'un changement d'API publique.

Les petites pull requests voyagent plus vite entre fuseaux horaires

Avec des relecteurs dans d'autres pays, une PR attend des heures entre deux échanges. Ce qui m'a le plus aidé :

1. Un seul sujet par PR. Un refactoring et une fonctionnalité dans la même PR doublent le temps de revue.
2. Dire ce qu'on a testé — la plateforme, les étapes, une capture ou un court enregistrement.
3. Laisser le code un peu plus propre, mais dans un commit séparé pour que les relecteurs puissent le passer.

Respecter le graphe de build

Les outils de monorepo (Turbo, Nx…) mettent en cache les builds selon le graphe de dépendances. Si on comprend ce graphe, on peut lancer uniquement ce que son changement affecte, au lieu de tout le dépôt — en local comme en CI. Apprendre ces commandes tôt m'a fait gagner plus de temps que n'importe quel raccourci d'éditeur.

L'open source change la façon d'écrire

Du code dans un dépôt public sera lu par des inconnus, parfois des années plus tard. J'écris des noms plus explicites, moins d'astuces, et des commentaires qui expliquent le pourquoi. Cette habitude m'a suivi dans les projets clients privés — et ils s'en portent mieux.

Pour les développeurs en Afrique

Contribuer à l'open source est l'une des façons les plus directes de montrer son travail au monde : le code, les revues et les discussions sont publics. Pas besoin de permission pour commencer — choisissez un ticket good first issue, lisez le guide de contribution, et ouvrez une petite PR bien décrite.