Tu as déjà travaillé sur un projet Android où tout le code était dans un seul module ?
Au début, ça semble raisonnable. Rapide à mettre en place, simple à comprendre. Puis le projet grossit. Les features s’accumulent. Et un jour tu te retrouves à modifier une ligne de code dans un coin obscur de l’app — et trois autres choses cassent ailleurs.
J’ai vécu ça. Sur de vrais projets, avec de vraies équipes, chez Coyote et Deezer. Des apps utilisées par des millions d’utilisateurs, où une mauvaise décision d’architecture au départ peut coûter des semaines de refactoring des mois plus tard.
La solution qui change tout : l’architecture multi-module.
Dans cet article, tu vas découvrir ce qu’est concrètement une architecture multi-module, pourquoi elle est indispensable sur tout projet sérieux, et les deux approches que j’ai le plus souvent vues en production.
Architecture en multi-module Android : De quoi s’agit-il ?
Une architecture multi-module, c’est comme une maison bien construite.
Une maison n’est pas un seul bloc de béton. Elle est constituée d’éléments indépendants ayant chacun un rôle défini — des murs, un toit, des fenêtres, des fondations, de la plomberie.
Chaque composant est connecté aux autres de façon précise, ce qui permet à l’ensemble de tenir et de rester fonctionnel. Tu peux refaire la salle de bain sans toucher à la toiture.
Dans un projet Android ou Kotlin Multi Platform, c’est exactement le même principe. Une architecture multi-module permet de structurer le code en plusieurs modules Gradle — chacun responsable d’une fonctionnalité spécifique, configuré en tant que bibliothèque Kotlin ou Android.
Les avantages sont concrets et mesurables :
- Meilleure maintenabilité : Tu travailles sur un module sans risquer de casser les autres. Sur une app avec des dixènes de modules comme j’en ai vu, c’est ce qui rend le projet humainement gérable.
- Meilleure testabilité : Chaque module se teste indépendamment. Tu détectes les régressions plus tôt, tu les corriges plus vite.
- Meilleure réutilisabilité : Un module bien découpé peut être réutilisé dans un autre projet. C’est un gain de temps considérable sur le long terme.
- Meilleure évolutivité : Ajouter une nouvelle fonctionnalité = créer un nouveau module. Sans toucher à l’existant.
- Meilleure collaboration : Chaque développeur travaille sur son module. Les conflits de merge diminuent drastiquement. Les breaking changes deviennent rares.
Deux approches d’implémentation — et comment choisir
Il n’existe pas une seule bonne façon de modulariser une app. En regardant ce qui se fait sur internet, tu trouveras des dizaines d’implémentations différentes.
Je ne vais pas te dire que l’une est meilleure que l’autre — tout dépend de tes besoins, de la taille de ton équipe et de la complexité de ton application. Ce que je vais faire, c’est te présenter les deux découpages que j’ai le plus souvent vus en production. Tu me diras en commentaire ce que tu en penses.
Prenons un exemple concret : une application Android permettant d’envoyer de la cryptomonnaie. L’utilisateur doit signer une transaction avec son portefeuille, puis l’envoyer sur la blockchain correspondante. C’est exactement le type de projet sur lequel j’ai travaillé chez Ledger.
Approche n°1 : La modularisation par couche (data, domain, présentation)
Le principe de la modularisation par couche est de découper le code en fonction des responsabilités techniques.
Sur notre exemple d’app crypto, ça donne :
- presentation/ : contient toutes les interfaces graphiques de l’application (Composables) et la logique d’affichage (ViewModels)
- domain/ : contient toutes les règles métiers. Ici
SignTransactionetSendTransaction - data/ : contient la logique d’accès aux données : communication avec le portefeuille crypto et avec la blockchain
Les termes domain et data viennent de la Clean Architecture d’Uncle Bob — un sujet qui mérite son propre article, dis-moi en commentaire si tu veux que j’y consacre un article.
Les avantages de cette approche :
- Facile à mettre en place et à configurer
- Adaptée si ton application est petite ou en phase de démarrage
Les limites que j’ai vécues en production :
- Plus difficile de retrouver toutes les fonctionnalités implémentées dans l’application
- Risques de conflits lors des merges qui augmentent avec la taille de l’équipe
- Les modules ne peuvent pas facilement être réutilisés dans d’autres projets
- Les modules grossissent vite et finissent par faire trop de choses — c’est une violation directe du principe de Responsabilité Unique
Approche n°2 : La modularisation par fonctionnalité (feature modules)
Ici, le principe est différent : on découpe le projet en fonction des fonctionnalités, pas des couches techniques.
Sur notre exemple d’app crypto, chaque fonctionnalité devient son propre module indépendant : sign-transaction/, send-transaction/, etc.
Les avantages de cette approche :
- Adaptée aux applications volumineuses avec beaucoup de fonctionnalités
- Peu de risques de conflits lors des merges — chaque dev travaille sur sa feature
- Les modules sont facilement réutilisables dans d’autres projets
- On voit immédiatement quelles fonctionnalités contient l’application
- Respect du principe de Responsabilité Unique — chaque module implémente une seule fonctionnaliténctionnalité
Les points d’attention :
- Plus long à mettre en place — chaque nouvelle fonctionnalité doit respecter un template prédéfini
- Il faut bien gérer la visibilité des composants pour ne pas exposer ce qui doit rester interne au module
- Cette approche demande des connaissances avancées en architecture — notamment l’Inversion de Dépendances
C’est l’approche que j’ai le plus souvent utilisée sur des projets à grande échelle. Elle demande plus d’investissement au départ — mais elle paye largement sur le long terme.
🎯 Conclusion
L’architecture multi-module n’est pas une option réservée aux grands projets. C’est une fondation que tout projet Android sérieux mérite — même si tu commences à deux développeurs.
Ce que j’ai appris chez Coyote, Deezer et Ledger : les mauvaises décisions d’architecture ne se voient pas au démarrage. Elles se voient 18 mois plus tard, quand l’app est devenue impossible à maintenir et que l’équipe passe plus de temps à déboguer qu’à livrer.
Modulariser dès le départ, c’est te donner les moyens de scaler sereinement.
Une bonne modularisation ne s’arrête pas là — elle demande aussi de maîtriser les principes S.O.L.I.D et certaines architectures comme la Clean Architecture d’Uncle Bob. Ce sont des sujets que j’aborderai dans de prochains articles.
Et si tu commences à modulariser, tu vas rapidement remarquer que certains scripts build.gradle se dupliquent d’un module à l’autre. J’ai écrit un article dédié pour résoudre ce problème proprement — tu peux le retrouver ici.
Des questions sur l’implémentation ? Dis-moi en commentaire — les retours terrain sont toujours les plus intéressants.
Sanders
Liens utiles :
