Pour un SaaS développé par une seule équipe, notre recommandation de départ est le monolithe modulaire. Les microservices deviennent pertinents lorsqu’une autonomie de déploiement, une contrainte de charge ou une exigence d’isolation justifie leur coût opérationnel. Le bon arbitrage ne consiste donc pas à choisir l’architecture la plus sophistiquée, mais à identifier quelle indépendance votre produit doit réellement acheter.
Cette position rejoint l’argument de Martin Fowler dans Monolith First : découvrir les bonnes frontières métier avant de les transformer en frontières réseau. Ce n’est pas une règle absolue, mais un point de départ à confronter à votre organisation, votre budget et vos contraintes de production. (martinfowler.com)
Monolithe modulaire ou microservices : quelle différence concrète ?
Un monolithe modulaire organise le cœur applicatif en modules distincts, livrés ensemble. Une architecture microservices répartit des capacités métier entre services déployables indépendamment. La différence décisive concerne donc le déploiement et les dépendances, pas le nombre de dossiers ou de dépôts Git.
Un monolithe n’impose pas une machine unique. La documentation Microsoft sur les architectures web décrit notamment sa réplication sur plusieurs serveurs pour répartir la charge. Séparation logique du code et séparation physique des traitements sont deux décisions différentes. (learn.microsoft.com)
Pour cadrer le développement d’un SaaS, nous conseillons de comparer trois options plutôt que deux :
| Option | Organisation proposée | À privilégier lorsque | Contrepartie à accepter |
|---|---|---|---|
| Monolithe modulaire | Modules métier explicites, livraison commune | Une équipe fait évoluer un produit aux frontières encore mouvantes | La discipline interne doit empêcher les dépendances incontrôlées |
| Monolithe avec traitements séparés | Cœur commun, processus dédiés aux tâches longues | Les imports, exports ou calculs perturbent le parcours interactif | Il faut superviser les files et les traitements différés |
| Microservices ciblés | Quelques capacités métier autonomes | Des besoins d’indépendance sont identifiés et financés | Les contrats, les données et les incidents traversent plusieurs composants |
Notre conseil : ne confondez pas un processus séparé et un service métier autonome. Vous pouvez décider qu’un worker d’export utilise le même code métier et suive le même cycle de livraison que l’application. Cette séparation d’exécution ne vous oblige pas à reconstruire toute l’architecture.
Quels problèmes justifient réellement des microservices ?
Les microservices méritent une étude lorsque des composants doivent évoluer, fonctionner ou monter en charge indépendamment. Une anticipation vague de croissance ne suffit pas : formulez le problème observé, son impact et le bénéfice attendu d’une séparation.
Microsoft présente précisément l’autonomie de déploiement et la responsabilité métier comme des caractéristiques structurantes des architectures microservices. La séparation doit servir une capacité cohérente, pas simplement reproduire les tables de la base sous forme d’API. (learn.microsoft.com)
Des équipes sont bloquées par leurs livraisons communes
Examinez les dernières mises en production. Une équipe a-t-elle réellement attendu une autre équipe ? Le blocage venait-il d’un composant partagé, d’une validation manuelle ou d’un environnement de test indisponible ?
Nous recommandons une séparation lorsque le couplage de livraison reste le problème après amélioration du pipeline et clarification des responsabilités. Extraire un service ne doit pas devenir une manière coûteuse de contourner une procédure de validation mal conçue.
Une charge spécifique impose un dimensionnement distinct
Demandez une mesure par traitement : consommation mémoire, temps processeur, accès aux données, concurrence et fréquence des pointes. Un export volumineux et un calcul d’optimisation ne posent pas nécessairement le même problème.
Pour chaque candidat, comparez d’abord une optimisation locale, un traitement différé et une séparation complète. Retenez les microservices seulement si l’autonomie obtenue apporte davantage que les mécanismes supplémentaires à exploiter.
Une capacité exige une isolation particulière
Un composant exécutant des fichiers non fiables peut justifier un environnement très restreint. Une capacité utilisée par plusieurs produits peut aussi mériter son propre cycle de livraison. Documentez alors précisément la frontière recherchée : identité technique, accès réseau, ressources, secrets et données.
Ne validez pas une extraction avec le seul argument « mieux isoler ». Exigez un scénario de panne ou de compromission et un test démontrant la protection attendue.
La propriété des données tranche souvent le débat
Avant de dessiner les services, listez les règles qui doivent rester vraies ensemble. Pour un SaaS de gestion commerciale, cela peut être l’enregistrement d’une commande et la réservation du stock. Pour un outil de planification, l’attribution d’une intervention et la disponibilité de la ressource.
La documentation Microsoft sur les données des microservices recommande de réserver les données à leur service propriétaire et de définir explicitement les besoins de cohérence. Elle précise que des services peuvent partager un serveur physique de base de données : le couplage problématique concerne notamment les schémas et tables partagés. (learn.microsoft.com)
Pour chaque frontière envisagée, faites remplir cette fiche par un développeur et un responsable métier :
- Autorité : quel composant décide de l’état officiel de l’objet ?
- Cohérence : quelle information peut être temporairement décalée, et pendant combien de temps ?
- Échec partiel : que voit l’utilisateur si une étape réussit et la suivante échoue ?
- Correction : qui réconcilie les écarts et avec quelle interface ?
- Historique : comment expliquer après coup la succession des décisions ?
Notre recommandation est de conserver ensemble les règles transactionnelles fortement liées, sauf justification explicite. Ne rendez pas un parcours métier asynchrone simplement parce que votre découpage technique le réclame.
Les messages ajoutent un sujet de fiabilité
Enregistrer une commande puis publier un événement constitue deux opérations distinctes. AWS décrit le risque d’incohérence et le pattern transactional outbox : enregistrer le changement métier et l’événement à transmettre dans une même transaction locale, puis publier celui-ci séparément. Les consommateurs doivent également gérer les doublons, notamment par l’idempotence. (docs.aws.amazon.com)
Dans votre arbitrage, chiffrez donc aussi la reprise des messages, les alertes sur les retards et les outils de correction. Une démonstration où tous les composants répondent ne valide pas le coût de fonctionnement réel.
Combien coûte le choix des microservices ?
Le coût dépend moins du nombre de services que des indépendances à garantir et du niveau de disponibilité attendu. Pour décider, comparez le coût total sur un même horizon, en incluant le développement, l’exploitation et le travail produit reporté.
AWS souligne dans son cadre Well-Architected sur la segmentation des applications les compromis de latence, de diagnostic et de charge opérationnelle. AWS privilégie la segmentation, tout en distinguant les besoins d’un premier lancement de ceux d’une application conçue pour une forte montée en charge. (docs.aws.amazon.com)
| Poste à estimer | Questions à poser | Preuve attendue avant engagement |
|---|---|---|
| Découpage et données | Quels accès directs supprimer ? Quels historiques déplacer ? | Cartographie des dépendances et règles métier |
| Livraison | Quelles versions doivent coexister ? Comment revenir en arrière ? | Scénario de déploiement et de retour testé |
| Exploitation | Qui surveille, diagnostique et intervient ? | Responsables nommés et procédures utilisables |
| Infrastructure | Quels environnements, files, stockages et journaux supplémentaires ? | Estimation liée aux volumes et à leur rétention |
| Coût d’opportunité | Quelles fonctionnalités attendront pendant le chantier ? | Arbitrage explicite avec la direction produit |
Pour construire une simulation budgétaire, vous pouvez retenir une hypothèse illustrative de 700 à 1 100 € HT par jour, à remplacer par vos coûts complets ou des devis. Avec une charge préalablement estimée de 15 à 30 jours, l’enveloppe calculée serait de 10 500 à 33 000 € HT. Ce calcul n’est ni un tarif Novane ni une estimation universelle d’extraction.
Faites varier séparément la migration des données, les exigences de sécurité, la couverture des tests et les conditions de bascule. Ajoutez ensuite les coûts récurrents. Une extraction techniquement courte peut être économiquement défavorable si personne ne finance sa maintenance.
Le dossier doit présenter deux budgets : celui de l’extraction et celui de l’alternative minimale. Comparer des microservices à l’inaction masque souvent une option moins chère, comme un worker dédié ou une modularisation ciblée.
Quelle architecture choisir selon la taille de l’équipe ?
La taille d’équipe sert de repère, pas de seuil automatique. Notre grille privilégie surtout le nombre d’équipes réellement autonomes et leur capacité à exploiter les composants dont elles deviennent responsables.
| Contexte | Recommandation de départ | Condition pour aller plus loin |
|---|---|---|
| Deux à cinq développeurs, marché encore incertain | Monolithe modulaire, périmètre limité | Contrainte technique ou de sécurité impossible à traiter simplement |
| Une équipe, produit établi, traitements lourds | Cœur modulaire et workers dédiés | Besoin démontré d’un cycle de livraison distinct |
| Plusieurs équipes produit autonomes | Étudier quelques services métier | Propriété des données et exploitation clairement attribuées |
| Petite équipe, activité très critique | Privilégier une architecture maîtrisée et une exploitation financée | Test prouvant qu’une séparation réduit le risque prioritaire |
Ces repères sont des recommandations d’arbitrage, pas des statistiques sectorielles. Une équipe expérimentée peut exploiter plusieurs services ; une organisation plus grande peut conserver un monolithe bien structuré.
Martin Fowler insiste dans Microservice Trade-Offs sur le compromis entre indépendance et complexité distribuée. Son analyse rappelle notamment que gérer de nombreux services régulièrement redéployés exige une exploitation mature. (martinfowler.com)
Avant toute extraction, exigez un responsable de service, un suppléant, une procédure d’incident et une capacité de maintenance réservée. Si cette compétence manque temporairement, une augmentation d’effectif tech peut accompagner le chantier, à condition de prévoir le transfert de connaissances. Une architecture ne doit pas devenir inexploitable au départ du renfort.
Un monolithe modulaire se gouverne, il ne se décrète pas
Pour rendre le choix du monolithe crédible, nous recommandons des engagements vérifiables :
- Des modules métier nommés : commandes, contrats ou planification, plutôt qu’un découpage limité à contrôleurs et services.
- Des interfaces explicites : les appels entre modules passent par des points d’entrée identifiés.
- Une propriété des écritures : chaque module possède les modifications de ses données.
- Des contrôles automatisés : les dépendances interdites sont détectées dans le pipeline.
- Des tests métier : les règles importantes restent vérifiables indépendamment de l’interface.
- Une responsabilité de maintenance : les exceptions architecturales sont documentées et réexaminées.
Lors des revues, posez une question pratique : une modification de contrat commercial oblige-t-elle à comprendre la planification des interventions ? Si oui, examinez la dépendance avant de multiplier les services.
Lorsque les frontières sont déjà brouillées, commencez par une clarification interne. L’arbitrage entre refactoriser ou réécrire une application mérite alors une décision distincte : extraire des services n’est pas une obligation de remplacement complet.
Trois scénarios pour mettre l’arbitrage à l’épreuve
Les situations suivantes sont hypothétiques et ne décrivent pas des projets clients Novane.
Un SaaS de planification avec quatre développeurs
Les règles d’affectation changent encore chaque semaine. Planning, disponibilité et habilitations évoluent ensemble. Nous choisirions un monolithe modulaire pour apprendre le domaine sans figer prématurément les frontières. Un export différé pourrait fonctionner dans un processus dédié, sans devenir un service autonome.
Un SaaS documentaire dont les conversions saturent les ressources
Nous testerions d’abord une séparation des conversions dans des workers avec limites de concurrence. L’objectif serait de protéger le parcours interactif. Nous envisagerions un service indépendant seulement si les conversions nécessitent aussi une sécurité, une technologie ou une cadence de livraison réellement distincte.
Un éditeur avec plusieurs équipes et des connecteurs partenaires
Si les connecteurs évoluent sans cesse tandis que le cœur métier reste stable, nous étudierions leur extraction ciblée. La validation porterait sur la reprise après incident, la compatibilité des échanges et la responsabilité opérationnelle. Aucun bénéfice ne serait supposé pour les autres modules par simple analogie.
Décider avec un pilote réversible
Pour une application existante, proposez une extraction limitée plutôt qu’une transformation générale :
- Établir la référence : mesurer le problème actuel, par exemple l’attente entre équipes ou la durée d’un traitement.
- Choisir une frontière : sélectionner une capacité compréhensible dont les dépendances sont recensées.
- Définir le succès : fixer le gain attendu et le surcoût d’exploitation acceptable.
- Tester les échecs : indisponibilité, retard, doublon, version incompatible et reprise.
- Préparer le retour : préciser comment réconcilier les données et abandonner le nouveau chemin.
- Comparer : poursuivre uniquement si le gain observé justifie le coût supplémentaire.
Consignez la décision dans une note courte : problème, options rejetées, hypothèses, responsables et date de réexamen. Autorisez explicitement le maintien du monolithe si le pilote n’apporte pas la valeur attendue.
Questions fréquentes
Faut-il un dépôt Git par microservice ?
Ne faites pas du nombre de dépôts un critère de validation. Nous recommandons de vérifier plutôt qu’un service peut être testé et livré sans publication synchronisée de tous les autres. Choisissez ensuite l’organisation Git selon les outils et responsabilités de l’équipe.
Une agence différente par service facilite-t-elle le projet ?
Nous déconseillons de découper l’architecture uniquement selon les prestataires. Attribuez d’abord les capacités métier, puis imposez des règles communes de livraison, de sécurité et de maintenance. Le CTO doit conserver une responsabilité explicite sur les contrats entre composants.
Comment éviter une migration permanente ?
Fixez pour chaque extraction un critère de fin : ancien chemin supprimé, données réconciliées, exploitation transférée et documentation validée. N’engagez pas une nouvelle extraction tant que la précédente reste dans une coexistence sans échéance.
Choisir l’indépendance utile, pas la complexité anticipée
Entre monolithe modulaire et microservices, choisissez l’architecture dont vous pouvez expliquer le bénéfice et financer les conséquences. Notre recommandation reste de commencer par des frontières métier solides, puis de distribuer uniquement les capacités qui en tirent une valeur mesurable.
Pour confronter cet arbitrage à votre SaaS, apportez une cartographie simple, vos blocages de livraison et vos contraintes de production à une séance de consulting IT offerte avec Novane. L’objectif est de déterminer quoi séparer, quoi conserver ensemble et quelles preuves réunir avant d’engager le budget.
