Design to Exit : la stratégie anti-lock-in pour l'ère agentique

Le zombie technologique : quand le SaaS vous possède

Le terme est brutal mais précis : zombie technologique. C'est l'état d'une entreprise qui a délégué tant de fonctions critiques à des SaaS propriétaires qu'elle ne peut plus en sortir. Pas parce que les alternatives n'existent pas. Parce que le coût de migration est devenu si élevé qu'il paralyse toute décision stratégique.

Le scénario est devenu classique. Une entreprise adopte un CRM SaaS. Puis un ERP SaaS. Puis un outil de collaboration SaaS. Chaque outil fonctionne bien isolément. Mais les données sont cloisonnées, les intégrations sont propriétaires, les contrats s'auto-renouvellent, les prix augmentent de 15 à 20% par an. Cinq ans plus tard, l'entreprise réalise que ses processus métier sont encodés dans des workflows propriétaires qu'aucun autre outil ne peut reproduire.

Le zombie technologique ne meurt pas. Il survit, prisonnier de ses choix passés, incapable d'innover parce que chaque innovation dépend d'un fournisseur qui n'a aucun intérêt à faciliter le départ de son client.

À l'ère agentique, le risque s'aggrave considérablement. Les agents IA ont besoin de données structurées, de métadonnées propres, d'API ouvertes pour fonctionner. Un SaaS qui enferme les données dans un format propriétaire ne bloque plus seulement la migration — il bloque l'intelligence. Sans jumeau numérique accessible, sans métadonnées exploitables, les agents échouent. Le paradoxe de la rigueur s'applique : l'automatisation exige plus de rigueur humaine, pas moins.

Le POC-isme — cette tendance à accumuler les preuves de concept sans impact en production — est un symptôme du même mal. Les entreprises empilent des POCs IA qui ne passent jamais en production, précisément parce que les données sont verrouillées dans des silos SaaS inaccessibles aux agents.

Design to Exit : concevoir pour pouvoir partir

Le Design to Exit est un principe architectural simple : chaque choix technologique doit être conçu avec un plan de sortie explicite. Non pas parce qu'on prévoit de partir, mais parce que la capacité à partir est ce qui garantit un rapport de force équilibré avec ses fournisseurs.

C'est l'équivalent technologique d'un contrat de mariage. On ne le signe pas parce qu'on anticipe le divorce. On le signe parce que la clarté des termes protège les deux parties et permet une relation plus saine.

En pratique, le Design to Exit impose cinq règles de conception :

Règle 1 — Données portables. Toute donnée entrée dans un système doit pouvoir en sortir dans un format standard (JSON, CSV, XML) via une API documentée. Si l'export n'existe pas ou nécessite un ticket support, c'est un signal d'alerte majeur.

Règle 2 — Logique métier externalisée. Les règles métier critiques ne doivent jamais être encodées uniquement dans les workflows propriétaires d'un SaaS. Elles doivent exister en parallèle dans une documentation structurée, idéalement sous forme de contexte versionné dans Git.

Règle 3 — Intégrations via protocoles ouverts. Chaque intégration entre systèmes passe par des protocoles standards (REST, GraphQL, MCP, A2A) plutôt que par des connecteurs propriétaires. Le surcoût initial est largement compensé par la flexibilité future.

Règle 4 — Couche d'abstraction. Une couche intermédiaire isole le code métier des spécificités du fournisseur. Changer de fournisseur ne devrait impacter que cette couche d'abstraction, pas la logique applicative.

Règle 5 — Test de sortie annuel. Chaque année, l'équipe technique simule une migration : export des données, évaluation des alternatives, estimation du coût de transition. Ce test ne coûte que quelques jours et révèle les dépendances invisibles avant qu'elles ne deviennent des chaînes.

Le Design to Exit n'est pas de la paranoïa. C'est de la gouvernance technologique responsable. Les entreprises qui l'appliquent négocient mieux leurs contrats, adoptent plus vite les innovations, et résistent aux hausses de prix abusives.

L'analyse BATNA appliquée aux choix technologiques

Le BATNA — Best Alternative To a Negotiated Agreement — est un concept de négociation popularisé par le Harvard Negotiation Project. Appliqué à la technologie, il devient un outil stratégique redoutable.

Le principe : avant chaque choix technologique majeur, identifier et évaluer la meilleure alternative disponible. Pas une alternative théorique. Une alternative concrète, chiffrée, testée. Si votre CRM SaaS augmente ses prix de 30%, quelle est votre alternative réelle ? Combien de temps pour migrer ? Quel coût ? Quelle perte de fonctionnalité ?

Une entreprise avec un BATNA fort — une alternative crédible et rapide à activer — négocie en position de force. Une entreprise sans BATNA subit.

L'analyse BATNA technologique se décompose en quatre dimensions :

BATNA données — Pouvez-vous extraire vos données en moins de 48 heures dans un format exploitable ? Si oui, votre BATNA données est fort. Sinon, chaque jour qui passe aggrave votre dépendance.

BATNA compétences — Votre équipe sait-elle opérer une alternative ? Les compétences internes sont-elles verrouillées sur un seul écosystème ? La formation croisée est un investissement BATNA.

BATNA processus — Vos workflows métier sont-ils documentés indépendamment de l'outil qui les exécute ? Si vos processus n'existent que dans la configuration d'un SaaS, votre BATNA processus est à zéro.

BATNA contractuel — Vos contrats prévoient-ils des clauses de réversibilité ? Assistance à la migration ? Pénalités en cas de dégradation de service ? Le BATNA contractuel se construit avant la signature, pas après.

Chez SFEIR, chaque recommandation technologique inclut systématiquement une analyse BATNA. Pas pour décourager l'adoption de SaaS — certains sont excellents et parfaitement adaptés. Mais pour que le choix soit fait en connaissance de cause, avec un plan de sortie explicite et un rapport de force maîtrisé.

La Matrice Souveraineté Agentique : Buy vs Build

À l'ère des agents IA, la décision Buy vs Build se repose avec une acuité nouvelle. Tout n'est pas à construire en interne. Tout n'est pas à acheter. La clé est de savoir où placer le curseur en fonction de la valeur stratégique et de l'impact agentique.

La Matrice Souveraineté Agentique structure cette décision en quatre quadrants :

Quadrant 1 — Commodity + Faible impact agentique → Buy SaaS. La paie, la comptabilité, la messagerie. Des fonctions standardisées où la différenciation n'a pas de sens. Le SaaS est la bonne réponse, à condition de respecter les règles du Design to Exit.

Quadrant 2 — Commodity + Fort impact agentique → Buy PaaS. L'infrastructure cloud, les bases de données, les pipelines CI/CD. Des briques techniques que les agents doivent pouvoir interroger et piloter. Le PaaS offre les API et la flexibilité nécessaires sans le surcoût du développement interne.

Quadrant 3 — Différenciation + Faible impact agentique → Build léger. Les interfaces métier spécifiques, les workflows internes différenciants. À construire en interne avec des technologies standards, mais pas prioritaire pour l'intégration agentique.

Quadrant 4 — Différenciation + Fort impact agentique → Build stratégique. Le cœur de métier, le knowledge graph, la mémoire organisationnelle, les agents spécialisés. C'est ici que l'investissement interne est non négociable. Externaliser ce quadrant, c'est externaliser son avantage compétitif.

L'erreur classique est de traiter le quadrant 4 comme du quadrant 1 : acheter un SaaS pour gérer sa connaissance métier, ses processus différenciants, son intelligence organisationnelle. À court terme, c'est plus rapide. À moyen terme, c'est un piège mortel — le zombie technologique dans sa forme la plus dangereuse.

La matrice impose aussi une discipline : ne pas construire ce qui est commodity. Le « Not Invented Here » syndrome est aussi coûteux que le lock-in SaaS. La souveraineté ne signifie pas tout faire soi-même. Elle signifie garder le contrôle sur ce qui est stratégique, et accepter de déléguer le reste avec un BATNA solide.

Cloud souverain et protocoles ouverts : MCP et A2A

La souveraineté agentique repose sur deux piliers techniques : un hébergement maîtrisé et des protocoles d'interopérabilité ouverts.

Sur l'hébergement, le constat géopolitique est sans équivoque. Comme le souligne Asma Mhalla, la bataille US-Chine autour de l'IA est une bataille d'empire. L'Europe risque le statut de consommateur vassalisé si elle ne maîtrise pas son infrastructure. Chaque choix technologique est un choix politique. Le cloud souverain européen n'est pas un caprice réglementaire — c'est une condition de survie stratégique.

En pratique, cela ne signifie pas rejeter AWS ou Azure. Cela signifie architecturer ses systèmes pour que la couche d'abstraction permette de migrer vers un cloud européen (OVHcloud, Scaleway, 3DS Outscale) si les conditions géopolitiques ou réglementaires l'exigent. Le Design to Exit s'applique aussi à l'infrastructure.

Sur les protocoles, deux standards émergent comme les piliers de l'interopérabilité agentique :

MCP (Model Context Protocol) — Le protocole de communication intra-agent. Il permet à un agent IA d'accéder à des outils, des données et des services de manière standardisée. MCP transforme chaque application en serveur de contexte accessible aux agents. C'est le protocole qui rend les applications « AI-Ready » : API-First évolue vers AI-First via des serveurs MCP.

A2A (Agent-to-Agent) — Le protocole de communication inter-agent. Il permet à des agents de différents systèmes de coopérer sans intégration propriétaire. A2A est au monde agentique ce que HTTP est au web : un standard universel de communication.

La combinaison MCP + A2A crée un mesh agentique ouvert. Les agents internes communiquent via MCP, les agents externes coopèrent via A2A. L'identité est gérée en Identity-First (Zero Trust appliqué aux agents — pas d'ID, pas d'API), avec des guardrails et des environnements d'exécution de confiance (TEE) pour la sécurité.

Cette architecture distribuée est l'antithèse du lock-in. Chaque composant est remplaçable. Chaque agent est identifié et gouverné (passeport agent, KYA — Know Your Agent). La symphonie agentique fonctionne précisément parce que les protocoles sont ouverts et les interfaces standardisées.

Les entreprises qui adoptent ces protocoles ouverts dès aujourd'hui se construisent un avantage structurel. Celles qui restent dans des écosystèmes fermés accumulent une dette agentique qui sera de plus en plus coûteuse à rembourser.

En pratique : la trajectoire SFEIR

Chez SFEIR, le Design to Exit et l'analyse BATNA ne sont pas des concepts théoriques. Ils structurent chaque mission de conseil et chaque architecture proposée à nos clients.

La trajectoire que nous recommandons suit quatre phases :

Phase 1 — Cartographie de la dette de souveraineté (mois 1-2). Auditer chaque SaaS en production. Pour chacun : évaluer le BATNA sur les quatre dimensions (données, compétences, processus, contractuel). Identifier les zombies technologiques en formation. Classer chaque outil dans la Matrice Souveraineté Agentique.

Phase 2 — Construction du jumeau numérique (mois 3-6). Le paradoxe de la rigueur s'applique pleinement ici. Pour que les agents IA fonctionnent, l'entreprise a besoin d'un jumeau numérique propre : métadonnées structurées, catalogue de données, modèle sémantique. Sans ce jumeau, les agents échouent. C'est le chantier Data Shift Left — amener la qualité des données au plus tôt dans le cycle, pas en fin de chaîne.

Phase 3 — Mise en place des protocoles ouverts (mois 4-9). Déployer MCP sur les applications internes critiques. Exposer les services métier via des serveurs MCP standardisés. Commencer l'intégration A2A pour la coopération inter-systèmes. Mettre en place la gouvernance agentique : passeport agent, Identity-First, guardrails.

Phase 4 — Activation de la souveraineté agentique (mois 6-12). Les agents IA opèrent sur un substrat souverain. Les données sont portables. Les processus sont documentés indépendamment des outils. Les protocoles sont ouverts. L'entreprise peut changer de fournisseur sans perdre son intelligence. Le BATNA est fort sur chaque dimension.

Le budget réalité est un point essentiel. L'IA n'est plus un gadget expérimental gratuit. C'est une dépense de productivité critique qui doit être budgétée. Et 80% du succès n'est pas technologique : 33% relèvent des ressources humaines, 33% de l'organisation, 33% de la conduite du changement.

Ne cherchez pas 5% d'amélioration marginale. Les gains de 15 minutes par-ci par-là sont absorbés par l'inertie systémique. Visez le 10x. Seuls les gains d'un facteur 2, 10 ou 100 transforment réellement les processus et justifient l'investissement dans la souveraineté.

Le zombie technologique n'est pas une fatalité. C'est un choix — le choix de ne pas anticiper, de ne pas structurer, de ne pas exiger la portabilité. Le Design to Exit est le vaccin. L'analyse BATNA est le diagnostic régulier. Et les protocoles ouverts sont le système immunitaire qui permet à l'entreprise de rester vivante, agile et souveraine dans l'ère agentique.