Monolithe ou services : découper un SaaS au bon moment

Le nombre de services n’est pas un indicateur de qualité d’architecture. Un monolithe bien structuré peut être adapté à une équipe et à son produit. Une séparation devient utile lorsqu’elle répond à un besoin identifié : responsabilité, cadence de livraison, charge ou isolation.

Avant de découper, examinez les dépendances réelles. Deux modules qui doivent toujours être modifiés et déployés ensemble risquent de conserver leur couplage après avoir été placés dans des services distincts.

Listez les règles, les données et les propriétaires de chaque domaine. Un domaine doit pouvoir expliquer ses responsabilités et le contrat qu’il propose aux autres. La frontière de données est aussi importante que la frontière du code.

• Quelles opérations doivent rester cohérentes dans une transaction ?
• Qui peut modifier chaque donnée ?
• Quel résultat un autre domaine doit-il connaître ?
• Que se passe-t-il si une dépendance est indisponible ?

Un appel local devenu un échange réseau introduit des erreurs, des délais et des reprises. La supervision doit permettre de suivre le parcours entre composants. Les contrats d’API doivent pouvoir évoluer sans exiger une mise à jour simultanée de tous les consommateurs.

La séparation peut faciliter une évolution ciblée, mais elle demande une capacité de déploiement et d’exploitation adaptée. La décision compare ce bénéfice aux nouvelles responsabilités : réseau, versions, observabilité et incidents distribués.

Dans un exemple fictif, une application de gestion lance un traitement lourd après une action utilisateur. Isoler ce traitement peut protéger le parcours interactif si un mécanisme de reprise, une supervision et une cohérence métier sont définis.

Ce choix serait moins utile si le traitement est rare, court et parfaitement compatible avec l’architecture actuelle. Le bon critère est le comportement attendu et mesuré, pas l’envie d’adopter des microservices.

Commencez par rendre les responsabilités visibles dans le code et les données. Définissez ensuite un contrat pour le périmètre à isoler, des tests de parcours et une condition de retour arrière. La trajectoire doit limiter le nombre de changements simultanés.

Un audit d’architecture peut établir les dépendances et comparer les options. Une mission auprès des équipes accompagne les arbitrages découverts pendant la réalisation.