Le dashboard affichait 47 services. Quarante-sept rectangles verts, bien alignés, tous “healthy”. Le CTO précédent avait architecturé ça en 18 mois. C’était propre. C’était documenté. C’était aussi utile qu’une bibliothèque dont personne n’ouvre les livres.

Douze services recevaient du trafic réel. Les trente-cinq autres tournaient dans le vide.

(Avant de vous dire que c’est exceptionnel : vérifiez vos propres dashboards. Comptez.)

L’archéologie des services inutiles

Comment on arrive à 47 services quand 12 suffisent ? Un à la fois, avec de bonnes raisons à chaque fois. “On va avoir besoin de scaler ce composant indépendamment.” (On ne l’a jamais fait.) “Cette logique est assez complexe pour mériter son propre service.” (Puis elle a été simplifiée. Le service est resté.)

Sam Newman, qui a littéralement écrit le livre sur les microservices, dit quelque chose que les architectes oublient : ne commencez jamais par des microservices. Commencez par un monolithe, puis extrayez quand la douleur est réelle et mesurable.

→ Newman, S. — “Building Microservices”, O’Reilly, 2021 (2nd ed.)

flowchart TD
    A["47 services
'tous healthy'"] -->|audit| B["12 reçoivent
du trafic réel"]
    A -->|audit| C["35 tournent
dans le vide"]
    C --> C1["Infra : 8k€/mois"]
    C --> C2["Maintenance : 2j/sprint"]
    C --> C3["Complexité cognitive"]
    B -->|après nettoyage| D["12 services
-70% coût infra
-40% temps deploy
zéro impact fonctionnel"]
    class C alerte
    class A attention
    class D ok

Le calcul que personne ne fait

35 services inutiles : 8k€/mois en infra, 2 jours par sprint en maintenance, et une complexité cognitive à chaque décision d’architecture. Quand un dev junior arrive et regarde le schéma, il voit 47 boîtes avec des flèches. Il lui faut 3 semaines de plus pour comprendre le système.

La méthode de la couche de poussière

On les a éteints un par un. En surveillant. Un seul a généré un ticket. Corrigé en 2h. Les 34 autres ? Silence total.

Le vert sur un dashboard ne veut pas dire utile. Il veut dire “allumé”.

Sources

• Newman, S. — “Building Microservices”, O’Reilly, 2021
• Observations terrain

Glossaire

• CTO : Chief Technology Officer — directeur technique.
• Sprint : Cycle de travail court, généralement de deux semaines.