Partie 3 de la série "Le Grand Découplage"
Dans la première partie, j'ai soutenu que les interfaces deviennent éphémères : elles sont générées à la demande plutôt que expédiées sous forme de produits. Dans la deuxième partie, j'ai étendu cela à l'architecture d'entreprise : les systèmes internes et externes deviennent des fournisseurs de capacités équivalents dans un graphe unifié.
Nous arrivons maintenant à l'implication inconfortable qui fait perdre le sommeil aux dirigeants SaaS : si les capacités se normalisent et les interfaces disparaissent, que reste-t-il ?
La réponse traditionnelle a été les données. Les fournisseurs SaaS ont passé des décennies à construire des fossés autour des données qu’ils accumulent. Mais l’architecture axée sur les capacités ne se contente pas de banaliser les interfaces : elle inverse tout le modèle de propriété des données.
C’est la correction que nous reportons depuis le début de la transition vers le cloud. Et cela se répercute bien plus loin que la plupart des gens ne le pensent.
Permettez-moi d'être direct sur le fonctionnement du modèle actuel.
Le modèle SaaS des deux dernières décennies a été le suivant : capturer l'activité des utilisateurs → accumuler des données → créer des coûts de changement → défendre les marges. Votre CRM ne stocke pas seulement vos données CRM ; il stocke votre mémoire institutionnelle : chaque interaction, chaque progression de transaction, chaque modèle de relation client. Votre plateforme RH ne traite pas seulement la paie ; il accumule l’intégralité de votre historique de main-d’œuvre. Votre plateforme de messagerie ne permet pas seulement la communication ; il devient l'archive consultable des conversations de votre entreprise.
Cette accumulation n’est pas fortuite. C'est la stratégie. Les données deviennent le fossé. Plus vous utilisez le produit, plus il devient douloureux de le quitter. Ce n'est pas un bug, c'est le modèle économique.
Je ne dis pas que les fournisseurs SaaS sont des méchants. Le modèle est né naturellement des contraintes technologiques de l’époque. Le stockage dans le cloud était l'endroit évident pour stocker les données. Les vendeurs ont réalisé des économies d'échelle. Les utilisateurs ont la commodité. La dépendance s’est accumulée progressivement et, au moment où quelqu’un s’en est rendu compte, la migration était d’un coût prohibitif.
Mais appelons cela comme ça : vos données sont prises en otage. Pas par malveillance, mais structurellement. L'architecture crée un verrouillage quelles que soient les intentions de chacun.
L'architecture axée sur les capacités rend cette situation d'otage visible comme elle ne l'était pas auparavant.
Dans le modèle actuel, le verrouillage des données est caché derrière l'interface. Vous interagissez avec Meridian (j'utilise ici un nom CRM fictif, mais vous connaissez les vrais joueurs) via les écrans de Meridian. Les données semblent faire partie de l'application car vous y accédez uniquement via l'application. La dépendance est obscurcie par l'expérience.
Mais ...
[Courte citation de 8% de l'article original]