CI/CD mobile : livrer chaque semaine sans casser la production
5 min de lecture
À retenir
- Commencez par un monolithe modulaire : c’est le choix qui coûte le moins cher à changer d’avis.
- Les microservices résolvent un problème d’organisation, pas un problème de charge.
- Une base de données relationnelle correctement indexée tient bien plus loin qu’on ne le croit.
- Le serverless est excellent pour les charges irrégulières, coûteux pour un trafic constant.
- Découpez quand une équipe distincte a besoin de livrer indépendamment, pas avant.
« On part sur des microservices, comme ça on sera prêts à scaler. » Cette phrase a coûté plus cher à plus de jeunes entreprises que n’importe quelle erreur de marché.
Elle part d’une bonne intention et repose sur une confusion : les microservices ne résolvent pas un problème de charge, ils résolvent un problème d’organisation. Tant que vous n’avez pas ce problème d’organisation, ils ne vous apportent que leur coût.
Les trois architectures, honnêtement
| Monolithe modulaire | Microservices | Serverless | |
|---|---|---|---|
| Coût de démarrage | Faible | Élevé | Faible |
| Complexité opérationnelle | Faible | Élevée | Moyenne |
| Vitesse de développement au début | Rapide | Lente | Rapide |
| Coût à trafic constant | Prévisible | Prévisible | Élevé |
| Coût à trafic irrégulier | Moyen | Moyen | Très faible |
| Débogage | Simple | Difficile | Moyen |
| Nombre d’équipes supporté | 1 à 3 | Plusieurs | 1 à 3 |
Pourquoi le monolithe modulaire gagne au départ
Un monolithe modulaire, c’est une seule application déployée d’un bloc, mais organisée en modules aux frontières nettes : chaque module possède ses données, expose une interface explicite, et n’accède jamais directement aux tables d’un autre.
C’est le meilleur compromis pour trois raisons.
Il coûte le moins cher à changer d’avis. Un module bien isolé s’extrait en microservice en quelques semaines quand le besoin apparaît réellement. L’inverse — recoller trois microservices prématurés — est beaucoup plus douloureux.
Il se débogue. Une trace d’exécution complète dans un seul processus, contre une enquête distribuée sur cinq services et une file de messages. Sur un produit jeune qui change tous les jours, cette différence se compte en semaines par trimestre.
Il se déploie. Un pipeline, un artefact, une base. La charge opérationnelle d’un système distribué est un travail à temps partiel que personne n’a budgété.
Le signal réel du découpage : deux équipes distinctes ne peuvent plus livrer sans se coordonner, ou un composant précis a besoin d’être mis à l’échelle indépendamment (traitement vidéo, calcul lourd, ingestion massive). Tant qu’aucun des deux n’est vrai, découper coûte sans rapporter.
Les décisions qui comptent vraiment
Le débat d’architecture masque souvent les choix qui déterminent réellement votre capacité à tenir la charge.
La base de données
Une base relationnelle unique, avec des index posés sur les bons champs et des requêtes surveillées, tient beaucoup plus loin que la réputation ne le laisse croire. Les problèmes de performance que nous rencontrons viennent presque toujours de trois causes, jamais du choix de moteur :
- des requêtes en boucle qui font des centaines d’allers-retours là où une seule suffirait ;
- des index manquants sur des colonnes filtrées à chaque requête ;
- des colonnes volumineuses chargées systématiquement alors qu’elles sont rarement lues.
Les frontières entre modules
C’est la décision la plus structurante et la moins coûteuse à prendre correctement dès le premier jour. Si le module « facturation » lit directement les tables du module « utilisateurs », vous avez un monolithe spaghetti, et aucune architecture ne vous sauvera plus tard.
Ce qui se passe quand un appel externe échoue
Délai maximal, nombre de tentatives, comportement en cas d’indisponibilité prolongée. C’est ce qui distingue un système qui ralentit d’un système qui s’effondre — et cela n’a rien à voir avec le nombre de services.
1Nombre de bases de données nécessaires au démarrage
3Nombre d’équipes au-delà duquel le découpage devient utile
≈ 80 %Des problèmes de performance causés par des requêtes, pas par l’architecture
Quand le serverless est le bon choix
Il l’est vraiment dans trois situations :
- Charge très irrégulière : un pic quotidien court, des périodes creuses longues. Vous ne payez que l’usage réel.
- Traitements ponctuels : génération de documents, redimensionnement d’images, tâches planifiées, réactions à des événements.
- Équipe sans compétence opérationnelle : personne pour administrer un serveur, et pas de budget pour cela.
Il l’est beaucoup moins pour une API sollicitée en permanence : à trafic constant, la facture dépasse rapidement celle d’un serveur correctement dimensionné, et les temps de démarrage à froid dégradent l’expérience.
La bonne architecture n’est pas celle qui supportera dix millions d’utilisateurs. C’est celle qui vous permettra d’en servir mille correctement, tout en restant modifiable quand vous découvrirez ce que veulent vraiment les dix millions suivants.
Notre recommandation par défaut
Pour un produit jeune, avec une équipe de un à cinq développeurs :
- Un monolithe modulaire dans un langage que l’équipe maîtrise, avec des frontières de modules explicites et vérifiées en revue de code.
- Une base relationnelle unique, avec les migrations versionnées et les requêtes lentes journalisées dès le premier jour.
- Du serverless pour les tâches asynchrones : envois d’emails, traitements d’images, exports.
- Un déploiement automatisé en une commande, dès la première semaine — le sujet de notre article sur la mise en place d’un CI/CD.
Cette pile ennuyeuse a un immense avantage : elle vous laisse toute votre énergie pour le seul problème qui décidera de votre sort, qui est de savoir si quelqu’un veut votre produit.
