Idée principale

Une fonctionnalité demande une nouvelle colonne dans la base. Si la base vit chez le client et que chaque mise en production exige d'envoyer une procédure à son équipe, d'attendre une validation, de réserver une fenêtre de maintenance et de vérifier à la main que la migration est passée, alors la livraison ne dépend plus de l'éditeur.

La conséquence n'est pas seulement un délai. Un client applique la migration mardi, un autre attend vendredi, un troisième reporte au mois suivant. On se retrouve avec plusieurs versions du moteur, plusieurs états du schéma, et une complexité qui grandit à chaque livraison.

Ce qui se perd alors est l'avantage structurel du modèle : faire évoluer en continu un produit commun à tous les clients.

Pourquoi c'est important

La divergence ne se voit pas au moment où l'on accepte l'arrangement — le premier client est facile à servir. Elle apparaît au dixième, quand il faut tester chaque correctif contre plusieurs états du schéma.

Et la tendance joue contre elle : à mesure que la cadence de livraison augmente, une architecture qui réclame une intervention humaine par client à chaque évolution devient d'autant plus coûteuse.

Nuances et limites

Le constat vaut pour les évolutions de structure. Une configuration, un contenu, un paramètre peuvent varier par client sans produire cette divergence.

Et il existe des modèles assumés de versions multiples — un logiciel installé chez le client. Ce sont d'autres métiers, avec d'autres coûts.

Questions ouvertes

• Jusqu'à combien de variantes de schéma une équipe peut-elle tenir avant que le coût de test ne devienne prohibitif ?