Sur mon mandat, j’entends de plus en plus parler de SOA — l’architecture orientée services. Le rêve, c’est beau: au lieu de gros monolithes qui se parlent pas, on découpe tout en services réutilisables qui s’assemblent comme des blocs Lego. Un service « clients », un service « facturation », pis on branche le tout ensemble. Le rêve d’assembler le monde.

Comme dev qui passe ses journées à intégrer des applications qui se haïssent, l’idée me parle. Combien de fois j’ai recodé la même logique parce que deux systèmes refusaient de se parler? Si chaque morceau était un service propre, exposé clairement, on arrêterait de réinventer la roue.

Le rêve en image

flowchart LR
    A[Application A] --> S1[Service Clients]
    B[Application B] --> S1
    B --> S2[Service Facturation]
    C[Application C] --> S2
    S1 --> D[(Données partagées)]
    S2 --> D

Sur le diagramme, c’est élégant. Chaque service expose un contrat clair, pis tout le monde s’en sert sans copier-coller. Mais c’est là que le terrain commence à faire mal.

Là où le rêve accroche

Le problème, c’est que découper en services, ça déplace la complexité, ça l’efface pas. Avant, tout était dans une boîte; là, c’est éparpillé sur le réseau. Quand un service répond pas, c’est qui le coupable? Quand le contrat change, combien d’applications brisent? La belle indépendance crée une nouvelle dépendance: tout le monde compte sur tout le monde, mais à distance.

Ce que j’en retiens

SOA, c’est un rêve qui vaut la peine — mais c’est un rêve, pas une recette magique. Assembler le monde en services, ça demande une discipline de fer sur les contrats, les versions pis la gestion des pannes. Comme dev, je trouve l’idée excellente, mais je me méfie des présentations qui montrent juste les beaux blocs Lego sans parler du jour où un bloc disparaît. Le vrai test, c’est pas le diagramme — c’est ce qui arrive quand un service tombe.