Monorepo vs polyrepo expliqué pour les équipes qui livrent web, mobile et backend. Comparez dépendances, releases et tactiques CI pour garder de la vitesse.
Les équipes ne débattent pas de monorepo vs polyrepo par philosophie Git. Elles débattent parce qu'un petit changement produit devient trois changements distincts sur le web, le mobile et le backend, et quelque chose casse en chemin.
Ce qui casse en général n'est pas l'interface visible en premier. C'est la colle invisible : un contrat d'API modifié sans mise à jour correspondante, une bibliothèque partagée mise à jour à un seul endroit, ou une pipeline de build qui a soudain besoin d'une nouvelle étape. Quand une pièce est déployée plus tôt que les autres, les utilisateurs le ressentent comme des bugs du type « le bouton existe sur le web mais l'app mobile dit non pris en charge » ou « l'application charge indéfiniment parce que la réponse backend a changé ».
Web, mobile et backend ont aussi des rythmes de release différents. Le web peut être déployé plusieurs fois par jour. Le backend peut livrer souvent mais demande un déploiement prudent. Le mobile est le plus lent à cause de la revue des stores et du temps nécessaire aux utilisateurs pour mettre à jour. Un changement « simple » comme renommer un champ peut vous forcer à composer avec la voie la plus lente, même si une seule vue en a besoin.
Vous payez probablement une taxe de coordination des dépôts si cela arrive souvent :
La taille de l'équipe et la maturité du produit influencent la bonne réponse. Au début, la plupart des équipes gagnent à rendre la coordination peu coûteuse et la visibilité élevée, même si c'est un peu bordélique. En grandissant, les frontières prennent de l'importance, mais seulement si les interfaces sont stables et la propriété claire.
Si chaque changement significatif doit atterrir en trois endroits, vous paierez cette taxe d'une manière ou d'une autre. La stratégie de dépôt porte surtout sur la façon dont vous voulez la régler.
Un dépôt n'est que l'endroit où vit votre code, avec son historique. Quand vous avez web, mobile et backend, le choix est simple : tout garder ensemble, ou tout séparer.
Un monorepo est un seul dépôt contenant plusieurs apps et souvent du code partagé aussi. Web, iOS/Android, services backend et bibliothèques partagées cohabitent.
Un polyrepo est l'inverse : chaque app (et parfois chaque service) a son propre dépôt. Le code partagé devient généralement un paquet séparé, ou les équipes copient de petits morceaux quand c'est nécessaire.
Au quotidien, un monorepo donne habituellement cette impression : partager du code est facile, un changement cross‑app peut être une seule PR, et les règles sont cohérentes. Le compromis est social : la propriété peut devenir floue sans frontières claires, et les vérifications à l'échelle du dépôt peuvent sembler strictes.
Les polyrepos donnent plutôt cette sensation : chaque équipe peut avancer indépendamment, les dépôts restent ciblés, et le contrôle d'accès peut être plus simple. Le compromis est la coordination : partager du code demande de la planification, et les changements transverses deviennent souvent plusieurs PRs avec un timing soigné.
Beaucoup d'équipes finissent par un hybride : les apps sont dans des dépôts séparés, les contrats partagés dans un endroit ; ou un monorepo avec des frontières fortes pour que chaque équipe reste principalement dans sa zone.
Si vous utilisez une plateforme qui génère backend, web et mobile à partir d'une seule source de vérité, vous réduisez la dérive parce que contrats et logique cohabitent. AppMaster, par exemple, génère des backend prêts pour la production, des apps web et des apps natives à partir d'un seul modèle. Cela n'élimine pas les réalités de release (le mobile reste plus lent), mais ça peut supprimer beaucoup d'heures passées à se demander « avons‑nous mis à jour les trois ? ».
Le code partagé est l'endroit où les équipes perdent du temps, quel que soit l'agencement des dépôts. Un petit changement dans une bibliothèque partagée ou un contrat d'API peut casser les builds web, les releases mobiles et les déploiements backend de façons différentes.
Quand vous partagez des librairies (composants UI, règles de validation, helpers d'auth), vous choisissez entre une version unique pour tous ou plusieurs versions dans le temps.
Les clients d'API et les schémas méritent une attention particulière. Les mises à jour manuelles sont lentes et sujettes aux erreurs. Un meilleur modèle consiste à traiter le schéma d'API comme source de vérité et à générer les clients depuis celui‑ci, puis soit à les committer, soit à les générer dans le CI. L'objectif est d'échouer vite : si le backend ajoute un champ requis, le client mobile doit échouer à la compilation, pas trois jours plus tard en QA.
Les changements cassants se propagent quand le comportement change sans chemin de migration sûr. Préférez d'abord les changements additifs (nouveaux champs, nouveaux endpoints), puis dépréciez ensuite. Si vous devez casser, utilisez des endpoints versionnés ou une courte fenêtre de compatibilité.
Exemple concret : le backend renomme status en state. Si le web est mis à jour aujourd'hui mais que le mobile ne peut pas sortir dans une semaine, le backend doit accepter les deux champs pendant cette semaine, ou livrer un adaptateur qui mappe l'ancien champ vers le nouveau.
Quelques règles pour que les mises à jour de dépendances restent ennuyeuses (en bien) :
Le code généré peut réduire la dérive, mais il ne remplace pas la discipline. Il vous faut toujours un contrat unique, des dépréciations claires et des mises à jour prévisibles.
C'est là que la stratégie de dépôt cesse d'être théorique. Si le backend change un nom de champ, le web peut généralement mettre à jour et déployer le jour même. Les apps mobiles sont différentes : la revue des stores et le délai de mise à jour des utilisateurs peuvent transformer un petit décalage en une semaine de tickets support.
L'objectif pratique est simple : une action utilisateur doit fonctionner quel que soit l'ordre des mises à jour. Cela signifie planifier pour des versions mixtes, et non pas supposer une release parfaitement synchronisée.
La plupart des équipes se répartissent entre :
Un train de release partagé : web, mobile et backend sont livrés comme une unité versionnée.
Versions par service avec règles de compatibilité : chaque app/service a sa propre version, et le backend supporte une plage définie de versions clients.
Un train partagé semble propre, mais il casse souvent avec les retards mobiles. Les versions par service sont plus désordonnées sur le papier, mais reflètent la réalité. Si vous optez pour ce modèle, écrivez une règle et appliquez‑la : quelles versions backend doivent supporter quelles versions mobile, et pour combien de temps.
Les retards mobiles affectent aussi la gestion des hotfixes. Les hotfixes backend peuvent sortir rapidement ; les hotfixes mobiles peuvent ne pas atteindre les utilisateurs pendant plusieurs jours. Préférez des correctifs côté serveur qui maintiennent la compatibilité avec les anciennes builds mobiles. Quand il faut changer le client, utilisez des feature flags et évitez de retirer les anciens champs tant que la majorité des utilisateurs n'est pas mise à jour.
Exemple : vous ajoutez « instructions de livraison » au flux de commande. Le backend ajoute un champ optionnel, le web l'affiche de suite, et le mobile l'ajoutera au sprint suivant. Si le backend accepte encore les anciennes requêtes et laisse le champ optionnel, tout continue de fonctionner pendant que le mobile rattrape son retard.
La coordination échoue quand « tout le monde s'en occupe », donc personne ne s'en occupe. Le propriétaire peut être un tech lead, un release manager ou un product manager soutenu par l'ingénierie. Son rôle est d'éviter les surprises en maintenant la visibilité et la cohérence des attentes de release.
Il n'a pas besoin d'un processus complexe. Il a besoin de quelques habitudes répétables : un calendrier de release simple avec des dates de cutoff et des fenêtres de gel, un check inter‑équipes rapide avant qu'un changement d'API ne parte en production, et un plan clair pour quand le mobile est en retard (geler le backend vs maintenir la compatibilité).
Si votre workflow génère web, mobile et backend ensemble à partir d'un modèle unique, vous avez toujours besoin d'un propriétaire de release. Vous aurez généralement moins de moments « avons‑nous mis à jour les trois endroits ? », mais le timing mobile persiste.
Le CI ralentit pour les mêmes raisons dans les deux configurations : on reconstruit trop, on réinstalle les dépendances à chaque fois, et on lance tous les tests sur chaque changement.
Les tueurs de temps courants sont : des builds complets sur de petits changements, des caches manquants, des suites de tests qui exécutent tout et des jobs séquentiels qui pourraient être parallélisés.
Commencez par des améliorations qui aident partout :
Les monorepos deviennent pénibles quand chaque commit déclenche un pipeline « build the world ». La solution est de construire et tester seulement ce que le changement affecte.
Utilisez des filtres par chemin et une approche « affected‑only » : si vous changez du code UI mobile, ne reconstruisez pas les images backend. Si vous touchez une bibliothèque partagée, ne build et testez que les apps qui en dépendent. Beaucoup d'équipes formalisent cela avec un graphe de dépendances simple pour que le CI prenne la décision au lieu de deviner.
Les polyrepos peuvent être rapides car chaque dépôt est plus petit, mais ils gaspillent souvent du temps par duplication et outils incohérents.
Gardez un jeu partagé de templates CI (mêmes étapes, mêmes caches, mêmes conventions) pour éviter que chaque dépôt ne réinvente son pipeline. Verrouillez les toolchains (versions d'exécution, outils de build, linters) pour éviter les surprises « marche dans un dépôt ». Si les téléchargements de dépendances sont un goulot, mettez en place des caches partagés ou des miroirs internes.
Exemple concret : une fonctionnalité ajoute un nouveau champ « status ». Le backend change, le web l'affiche, le mobile l'affiche. Dans un monorepo, le CI devrait lancer les tests backend plus seulement les parties web et mobile qui dépendent du client d'API. En polyrepo, chaque dépôt doit lancer ses vérifications rapides, et un pipeline d'intégration séparé peut valider que les trois releases restent compatibles.
Si vous exportez le code source et exécutez votre propre CI, la même règle s'applique : construisez seulement ce qui a changé, réutilisez les caches de façon agressive et réservez les vérifications lentes aux moments où elles apportent de la valeur réelle.
La décision devient plus facile quand vous partez de votre quotidien plutôt que d'une idéologie.
Choisissez 5 à 10 fonctionnalités récentes et notez ce qui a dû bouger en même temps. Indiquez si chaque changement touchait des écrans UI, des endpoints API, des tables de données, des règles d'authentification ou des validations partagées. Si la plupart des fonctionnalités exigent des changements coordonnés dans les trois domaines, une configuration séparée vous paraîtra pénible à moins que votre processus de release soit très discipliné.
Le code partagé n'est pas seulement des bibliothèques. Ce sont aussi les contrats (schémas d'API), les patterns UI et les règles métier. Notez où ils vivent aujourd'hui, qui les modifie et comment les changements sont approuvés. Si des morceaux partagés sont copiés entre dépôts, c'est un signe qu'il vous faut un contrôle plus strict, soit via un monorepo, soit via des règles de versionnage strictes.
Décidez quelles sont les unités (apps, services, librairies), puis assignez un propriétaire à chaque unité. Les frontières comptent plus que la disposition des dépôts. Sans propriétaires, un monorepo devient bruyant. Sans propriétaires, un polyrepo se déconnecte.
Si vous voulez une checklist simple, visez : un dépôt ou dossier par service/app déployable, un endroit pour les contrats partagés, un lieu pour les composants UI véritablement partagés, une règle claire pour l'endroit où vit la logique métier, et un propriétaire documenté pour chaque élément.
Si les releases mobiles trainent derrière les changements backend, vous avez besoin d'un plan de compatibilité (APIs versionnées, champs rétro‑compatibles, ou une fenêtre de support définie). Si tout doit sortir ensemble, un train de release peut fonctionner, mais il augmente la coordination.
Gardez les règles de branching simples : branches de courte durée, merges petits, et un chemin clair pour les hotfixes.
Ne concevez pas le CI dès le début pour le pire des cas. Conçuez‑le pour ce que les gens font chaque jour.
Si la plupart des commits touchent uniquement l'UI web, lancez par défaut le lint et les tests unitaires web, et exécutez les tests end‑to‑end complets sur une planification ou avant les releases. Si la plupart des incidents viennent de la dérive d'API, investissez d'abord dans les tests de contrat et la génération de clients.
Imaginez une petite équipe construisant trois éléments : un portail client (web), une application terrain (mobile) et une API (backend). Une demande arrive : ajouter un champ « Service status » aux jobs et l'afficher partout.
Le changement paraît petit mais c'est un test de coordination. Le backend ajoute le champ et met à jour la validation et les réponses. Le web l'affiche et met à jour les filtres. Le mobile doit l'afficher hors ligne, le synchroniser et gérer les cas limites.
Le vrai problème : le changement d'API est cassant. Le nom du champ passe de status à service_status, et les anciens clients plantent s'ils ne le gèrent pas.
Ici, un monorepo donne souvent une impression plus calme. Les updates backend, web et mobile peuvent arriver dans une seule PR (ou un ensemble coordonné de commits). Le CI peut lancer les tests affectés, et vous pouvez taguer une release qui inclut les trois mises à jour.
Le risque principal est social, pas technique : un dépôt unique rend facile le merge d'un changement cassant, donc vos règles de revue doivent être strictes.
Avec des dépôts séparés, chaque app suit son calendrier. Le backend peut sortir en premier et laisser le web et le mobile rattraper leur retard. Si la sortie mobile exige une revue store, le « correctif » peut prendre des jours même si le code est minime.
Les équipes résolvent habituellement cela par plus de structure : endpoints versionnés, réponses rétro‑compatibles, fenêtres de dépréciation plus longues et étapes de rollout plus claires. Ça marche, mais c'est du travail permanent.
Si vous décidez sur la base des preuves récentes, regardez vos derniers mois :
La plupart des équipes n'échouent pas parce qu'elles ont choisi la « mauvaise » structure de dépôt. Elles échouent parce que des habitudes quotidiennes ajoutent lentement de la friction jusqu'à ce que chaque changement semble risqué.
Une librairie partagée est tentante : helpers, types, bouts d'UI, contournements « temporaires ». Bientôt elle devient l'endroit où le vieux code s'entasse, et personne ne sait quoi retoucher.
Gardez le code partagé petit et strict. « Partagé » doit signifier utilisé par plusieurs équipes, revu soigneusement et modifié avec intention.
Même dans des dépôts séparés, les systèmes peuvent être fortement couplés. Le couplage migre dans des hypothèses : formats de date, valeurs d'enum, règles de permission et « ce champ est toujours présent ».
Exemple : le mobile considère status = 2 comme « Approuvé », le web comme « Confirmé », le backend change l'ordre de l'enum, et tout casse d'une façon qui semble aléatoire.
Prévenez cela en documentant les contrats (ce que signifient les champs, quelles valeurs sont permises) et traitez‑les comme des règles produit, pas des détails triviaux.
Quand tout le monde peut tout changer, les revues deviennent superficielles et les erreurs passent. Quand personne ne possède une zone, les bugs restent des semaines.
Définissez des propriétaires pour le web, le mobile, le backend et les modules partagés. La propriété n'empêche pas les contributions ; elle garantit que les changements reçoivent les bons yeux.
Le CI commence souvent petit, puis chaque incident ajoute un job « juste au cas où ». Des mois plus tard, il est lent et cher, et les gens l'évitent.
Une règle simple aide : chaque job CI doit avoir un but clair et un propriétaire, et il doit être supprimé s'il n'attrape plus de vrais problèmes.
Signes d'alerte pour nettoyer : tests dupliqués entre jobs, jobs rouges depuis des jours, « petits changements » qui prennent plus de temps à vérifier qu'à construire, et pipelines qui déclenchent des builds mobiles sur des changements backend seulement.
Si les releases reposent sur une personne qui se souvient de l'ordre et des pièges, vous serez plus lents et casserez plus souvent.
Écrivez les étapes de release, rendez‑les reproductibles et automatisez les vérifications ennuyeuses. Même si vos outils génèrent backends et clients cohérents, vous avez besoin de règles de release claires.
Avant de réorganiser vos dépôts, vérifiez comment votre équipe expédie aujourd'hui. L'objectif n'est pas une structure parfaite, mais moins de surprises quand un changement touche web, mobile et backend.
Posez‑vous cinq questions :
Exemple simple : un nouveau champ « adresse » est ajouté au checkout. Si le backend sort en premier, l'ancienne app mobile doit encore fonctionner. Cela implique généralement que l'API accepte ancien et nouveau payload pendant un certain temps, et que les mises à jour clients restent optionnelles, pas obligatoires.
L'objectif n'est pas la « bonne » structure de dépôt. C'est moins de handoffs, moins de surprises et moins de « quelle version est en prod ? ».
Rédigez un court enregistrement de décision : pourquoi vous avez choisi l'approche actuelle, ce que vous espérez améliorer, et quels compromis vous acceptez. Révisez‑le tous les 6 à 12 mois, ou plus tôt si la taille de l'équipe ou le rythme de release change.
Avant de déplacer des fichiers, choisissez le plus petit changement qui enlève une vraie douleur :
Si le couplage cross‑codebase est le vrai goulot, réduire le nombre d'endroits à changer peut avoir plus d'impact que la structure des dépôts. Certaines équipes y parviennent en centralisant davantage de logique et de modélisation des données dans une source unique de vérité.
Si vous voulez explorer cette approche, AppMaster (appmaster.io) est conçu pour générer des services backend, des apps web et des apps mobiles natives avec des modèles de données et une logique métier partagés. Une façon à faible risque de l'évaluer est de construire d'abord un petit outil interne, puis décider en fonction du temps de coordination économisé.
La voie confiante est volontairement ennuyeuse : documentez la décision, réduisez le couplage, automatisez les contrôles et changez la structure des dépôts seulement quand les chiffres montrent un bénéfice.
Comment décider entre monorepo et polyrepo pour web, mobile et backend ?Commencez par observer à quelle fréquence une seule fonctionnalité impose des changements simultanés sur le web, le mobile et le backend. Si la plupart des travaux sont transverses et que la coordination est votre principal frein, un monorepo ou une approche « contrat unique » réduit souvent les cassures. Si les équipes touchent rarement les mêmes zones et ont besoin d'indépendance et de contrôle des releases, le polyrepo peut bien fonctionner à condition d'appliquer des règles strictes de compatibilité.
Qu'est-ce qui cause généralement le problème « tout a cassé après un petit changement » ?La dérive d'API, les désalignements de versions de bibliothèques partagées et les différences de calendrier de release (notamment la lenteur des mises à jour mobiles via les stores) sont les coupables habituels. La solution consiste à planifier des versions mixtes dans la réalité, pas des releases parfaitement synchronisées, et à rendre les changements cassants rares et volontaires.
Quelle est la manière la plus sûre de gérer les contrats d'API entre web et mobile ?Considérez le schéma d'API comme la source de vérité et générez-en les clients pour que les incompatibilités échouent à la compilation, pas en QA ou en production. Favorisez d'abord les changements additifs, dépréciez ensuite les anciens champs, et maintenez une courte fenêtre de compatibilité si vous devez renommer ou supprimer quelque chose.
Comment gérer les bibliothèques partagées sans créer un bazar ?Privilégiez des mises à jour petites et régulières (par exemple hebdomadaires plutôt que trimestrielles) et exigez une approbation explicite pour les changements cassants. Joignez une note de migration courte à chaque changement et considérez « terminé » quand les builds web, mobile et backend sont verts, pas seulement un dépôt isolé.
Faut-il tout livrer sur une seule version partagée ou laisser chaque partie versionner indépendamment ?Par défaut, laissez chaque partie versionner indépendamment mais documentez clairement la règle de compatibilité : quelles versions du backend supportent quelles versions des clients, et pendant combien de temps. Un train de release partagé peut fonctionner au début, mais les délais mobiles le rendent souvent pénible sauf si vous tolérez d'attendre les délais des stores.
Comment éviter de casser les utilisateurs mobiles si le backend est déployé en premier ?Conservez la compatibilité côté serveur afin que les anciennes versions mobiles continuent de fonctionner le temps que les utilisateurs se mettent à jour. Ajoutez des champs de façon additive, ne retirez pas le comportement ancien trop tôt, et utilisez des feature flags pour déployer progressivement les changements visibles côté client.
Qui doit posséder la coordination des releases entre web, mobile et backend ?Attribuez clairement la coordination des releases à une personne—par exemple un tech lead, un release manager ou un product owner soutenu par l'ingénierie. L'objectif est un calendrier simple et répétable et une règle claire quand il y a des retards (geler la modification vs maintenir la compatibilité), pas un processus lourd.
Quelle est la première étape pour réduire le temps de CI sans changer la structure des dépôts ?Construisez et testez d'abord seulement ce qui a changé et mettez en cache tout ce qui peut l'être. Séparez les vérifications rapides (à chaque commit) des vérifications lentes (branche principale, nightly ou pré‑release) pour donner un retour rapide aux développeurs sans payer le coût total à chaque fois.
Comment les monorepos évitent-ils de « tout reconstruire » à chaque commit ?Utilisez des filtres par chemin et une approche « affected-only » pour éviter de reconstruire tout le dépôt pour un petit changement. Si un module partagé change, lancez uniquement les vérifications pour les applications qui en dépendent, et gardez des règles d'ownership et de revue strictes pour éviter que le dépôt ne devienne la poubelle de tous.
Comment les polyrepos évitent-ils la dérive et l'incohérence des pipelines entre équipes ?Standardisez les outils et les templates CI entre les dépôts pour éviter que chaque équipe réinvente les mêmes étapes, caches et conventions. Ajoutez une vérification d'intégration qui valide les contrats clés entre releases et figez les versions des toolchains pour éviter les problèmes « marche dans un dépôt mais pas dans l'autre ».
27 janv. 2026
8 min
26 janv. 20268 min
21 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
