Idée principale

Une passerelle d'email se remplace en changeant une clé d'accès. Un fournisseur de SMS aussi. Un modèle de langage également, tant que la mémoire durable, le contexte métier et les décisions restent dans le produit : ces briques ne conservent rien entre deux appels.

Une base de données est d'une autre nature. Elle porte l'état durable du système. La remplacer suppose de migrer les données, de garantir leur cohérence, de prévoir la reprise, de gérer les sauvegardes, parfois la réplication.

La substituabilité n'est donc pas binaire, c'est un gradient — et ce qui le gradue n'est pas la valeur métier de la brique, mais l'état qu'elle retient.

Pourquoi c'est important

Deux critères se superposent et on les confond. Le premier dit ce qu'on a le droit de céder — la brique porte-t-elle la valeur ? Le second dit ce que ça coûtera — la brique porte-t-elle l'état ?

Une brique peut être parfaitement indifférente au cœur du produit et rester l'une des plus lourdes à rendre substituable. C'est exactement le cas de la base de données, et c'est ce qui rend ce cas plus difficile que tous les autres.

Nuances et limites

L'état n'est pas la seule source de coût : une intégration profonde dans le code, même sans état, peut rendre un remplacement difficile.

Et l'absence d'état n'est jamais complète — un service de messagerie conserve des historiques, des réputations d'envoi, des listes de blocage.

Questions ouvertes

• Comment évaluer à l'avance le coût de substitution d'une brique, autrement qu'en la substituant ?