Les agents viennent de tuer le verrouillage logiciel. Comment on a migré de Contentful vers Sanity.io en moins de trois heures.
On a migré 49 articles de blog sur deux langues vers un nouveau CMS hier sans ouvrir une seule fois le nouveau CMS. Une note sur ce que ça veut dire pour chaque produit logiciel construit sur le verrouillage, et pourquoi c'est la même histoire qui va frapper l'industrie.
Hier on a remplacé notre CMS. 49 articles sur deux langues, chaque morceau de métadonnée, déplacés en environ trois heures. Et on n'a pas ouvert le nouveau CMS une seule fois.
Quand on dit qu'on ne l'a pas ouvert, on ne veut pas dire qu'on a regardé l'UI puis arrêté. On veut dire que notre agent a configuré le projet de façon entièrement autonome : défini le schéma, migré le contenu, et passé la nouvelle couche de données à notre frontend, pendant qu'on validait les étapes en chat. Tout le travail est passé par un connecteur MCP.
C'est une petite histoire avec une grosse implication : dans la plupart des catégories logicielles, les coûts de switching viennent de s'effondrer.
Pourquoi on a bougé (et pourquoi tu ferais probablement le même choix)
On fait tourner enaovision.com sur Lovable depuis l'été dernier, avec Contentful comme CMS. C'était un appariement raisonnable suggéré dans Lovable, et Contentful a été un produit solide. Leur offre gratuite nous a couverts confortablement jusqu'à hier.
Hier on a décidé de pousser sur le SEO francophone. Le français serait notre troisième locale après l'anglais et l'allemand, et l'offre gratuite de Contentful n'en supporte que deux. Leur offre Lite payante coûte 300 euros par mois et débloque exactement une locale supplémentaire, ce qui veut dire qu'au-delà de trois c'est un plan custom. On veut italien, coréen et japonais sur la roadmap derrière le français, donc un plan qui ne passe à l'échelle qu'une locale à la fois n'allait pas marcher.
On a écrit au support Contentful pour demander à quoi ressemblerait un plan qui passe vraiment à l'échelle avec les locales, on a eu un répondeur automatique, et aucune réponse humaine en quelques heures. Pour une startup qui bouge sur une décision stratégique prise la veille, cette fenêtre était suffisante pour tuer la conversation.
Ce n'est pas une attaque sur Contentful. Leur produit est très bien. Leur tarification ne colle juste pas à une petite équipe marketing qui veut être en six locales d'ici la fin de l'année, et leur boucle commerciale ne tourne pas à la vitesse d'un fondateur qui fait de l'ops marketing à minuit.
Comment on l'a remplacé sans cliquer sur quoi que ce soit
On a demandé à notre agent s'il existait un CMS construit agent-first et MCP-first. Sanity.io est revenu comme la réponse la plus forte. On a lu la doc pendant environ dix minutes, on a aimé ce qu'on voyait, et on a créé un compte. Puis on a passé la suite à l'agent.
Avant de lever le petit doigt, l'agent a cartographié le scope et nous a dit que c'était environ une demi-journée de travail concentré.
Voici ce que l'agent a fait, dans l'ordre :
- Configurer le projet Sanity via le Sanity MCP, y compris le nouveau workspace, le schéma, les origines CORS et les tokens API.
- Définir le schéma du blog post comme code, couvrant titre, slug, excerpt, body (rich text), champs SEO, image hero, auteur, locale et articles liés, le tout fortement typé.
- Migrer deux articles de bout en bout, images et toutes les métadonnées comprises, en pilote.
- Générer une note de passation pour Lovable avec le nouveau schéma, les nouveaux patterns de requêtes et les changements à faire dans notre frontend.
- Lovable a swappé la couche CMS, et on a smoke-testé la page blog rendue dans un navigateur, qui s'est affichée correctement du premier coup.
- Feu vert pour la migration complète, qui a déplacé les 49 articles en anglais et en allemand avec chaque image, chaque champ SEO, chaque référence d'article lié et chaque date de publication intacts.
- Re-passé un check d'intégrité des liens contre la nouvelle couche de données et confirmé zéro lien interne cassé.
Un instantané live de l'agent qui raconte son propre travail au fil de l'eau :
Le swap de code en lui-même, c'était quatre tâches et un build vert.
Et l'état final une fois que tout avait atterri :
Tout le projet a tourné en environ trois heures, et on n'a pas touché à l'UI Sanity une seule fois.
La vraie histoire, ce n'est pas la migration. C'est ce que ça veut dire pour le logiciel.
Il y a deux ans, une migration de CMS pour un site marketing de cette taille, c'était un vrai projet. Tu l'aurais scopé sur deux semaines, appelé une agence ou un freelance dev, budgété, et probablement repoussé d'un trimestre parce que la douleur de ton CMS actuel était encore moins grande que la douleur de la migration. Ce délai, c'était la douve de ton vendeur.
Aujourd'hui, cette douve fait trois heures.
Toutes les hypothèses sur les coûts de switching dans le logiciel étaient bâties sur la même fondation : déplacer des données entre systèmes est cher, risqué, et demande du travail humain, parce que les schémas ne matchent pas, le contenu ne fait pas un round-trip propre, les API sont différentes, les références internes cassent, et quelqu'un doit babysitter toute la transition.
Les agents bouffent chacun de ces coûts. Traduction de schéma, round-trip de contenu, adaptation d'API et réparation de références, ce sont tous des problèmes mécaniques dès lors que les deux côtés du tuyau parlent le même protocole machine, et donner à un agent l'accès aux deux MCP transforme la plupart des migrations en une longue après-midi.
Les boîtes plus grosses vont compresser encore plus fort. Une équipe mid-market qui programmait une migration Salesforce vers HubSpot sur six mois va la programmer sur deux semaines, et une équipe enterprise qui regarde une migration ERP va voir ce chiffre tomber significativement aussi, pas à zéro mais plausiblement d'un facteur 100 pour beaucoup du grunt work.
Les seules douves qui restent
Si les coûts de switching étaient ta douve, ce n'était jamais vraiment une douve ; c'était un délai, et le délai rétrécit. Ce qui retient vraiment les clients maintenant se résume à quatre choses.
- Un produit excellent. C'est la réponse ennuyeuse et la bonne. Le PLG n'est pas une mode stratégique, c'est la seule position défendable qui reste dans la plupart des catégories logicielles.
- Une douve de données. La valeur de ton produit composent avec des données propriétaires que le client ne peut pas reproduire ailleurs, que ce soit un historique d'usage qui pilote la personnalisation ou un graphe de relations qui ne se forme qu'à l'intérieur de ton produit.
- Effets de réseau. Ton produit gagne en valeur à mesure que d'autres l'utilisent, et partir veut dire perdre l'accès au réseau.
- Workflows régulés ou certifiés. Le verrouillage, c'est la signature de l'auditeur, pas celle du vendeur.
Si ton logiciel n'a aucune de ces quatre choses, et que ton plan était de compter sur « les clients sont trop énervés pour switcher », on regarderait ton prochain chiffre de rétention trimestrielle attentivement.
Ce que ça veut dire si tu achètes du logiciel
Deux implications pour les acheteurs.
Sois moins patient. La friction qui te gardait dans un produit qui ne te va plus va bientôt te coûter plus cher que la migration elle-même, donc si un vendeur ne peut pas matcher ton rythme ou ta tarification, démarre la conversation avec des alternatives. Tu seras surpris de la vitesse à laquelle « alternatives » devient « fait ».
Pondère les produits MCP-first. Tout outil que tu fais entrer dans ta stack aujourd'hui devrait être évalué non seulement sur son UI ou son API, mais sur la façon dont il se comporte comme interface agent. Sanity a gagné notre business en grande partie parce que son MCP était excellent et son modèle schema-as-code était nativement machine-friendly, et cette combinaison n'est plus un nice-to-have : c'est la nouvelle surface produit.
Ce que ça veut dire si tu construis du logiciel
La même logique a trois implications pour les builders.
Arrête de traiter le verrouillage comme une stratégie. Tes clients ont une route d'évasion 100 fois moins chère que l'année dernière, et le coût continue de baisser, donc chaque heure que tu passes à rendre les exports difficiles est une heure que tu ne passes pas à améliorer le produit.
Construis MCP-first, ou au moins MCP-worthy. La première interaction qu'un CTO ou une responsable marketing a avec ton produit en 2026 n'est de plus en plus pas une démo, c'est un agent qui lit ta doc et appelle ton MCP, ce qui fait de ton MCP ta nouvelle homepage.
Tarifies pour là où va ton client, pas pour là où il est. La raison pour laquelle on a bougé, ce n'était pas les 300 euros ; c'était que 300 euros nous achetaient une locale et la locale suivante était un contrat custom, ce qui nous a tarifés hors de notre propre croissance. La tarification de Contentful suppose que l'enterprise est l'état final et la nôtre suppose que l'échelle distribuée long-tail est l'état final, et quand ces deux hypothèses divergent, tu perds le client.
Pourquoi ça compte chez Enao Vision
Cette histoire atterrit différemment pour nous parce qu'on construit un produit dans une industrie qui est le cas d'école du verrouillage. L'industrie tourne sur des systèmes legacy : plateformes MES, suites ERP, stacks de capteurs, automates et outils de gestion de la qualité qui coûtent six chiffres et prennent deux ans à swapper. Personne sur un atelier n'aime son MES, et la plupart des chefs de production peuvent lister trois choses qu'ils détestent dedans avant le petit-déjeuner. Ils restent parce que le switch se mesure en trimestres et le coût se mesure en factures d'intégration à six chiffres.
Cette époque se termine, plus lentement dans l'industrie que dans les produits logiciels en général, mais elle se termine quand même. La prochaine génération de logiciels industriels sera choisie de la même façon que notre CMS vient de l'être : par des agents, évalués sur la qualité produit et la machine-friendliness, avec un coût de switching assez bas pour que les clients restent parce qu'ils aiment le produit plutôt que parce qu'ils sont coincés dedans.
C'est pour ça qu'Enao Vision est MCP-first dès le premier jour. Pas parce que les acheteurs industriels le demandent aujourd'hui (la plupart d'entre eux ne le font pas encore), mais parce que chaque produit construit en 2026 qui n'est pas MCP-first aura l'air aussi déplacé en 2030 qu'une boîte logicielle sans API avait l'air en 2020. L'interface va être lisible par machine ou elle va être legacy.
C'est aussi pour ça qu'on est obsédés par le fait que les clients aiment vraiment utiliser Enao Vision, parce que c'est la seule douve qui compte une fois que les coûts de switching s'effondrent. L'atelier va bientôt avoir la même liberté que notre équipe marketing vient d'utiliser, et on veut être le produit que les gens choisissent quand ils l'ont enfin.
Une note sur Contentful et Sanity
Rien de tout ça n'est un dunk sur Contentful. Leur produit est solide, leur fiabilité est bonne, leur communauté est large, et pour les équipes qui se trouvent dans la bande deux-à-trois locales leur tarification marche. On a juste dépassé le plafond.
Sanity a gagné le swap au mérite : schéma comme code, un MCP sérieux, de la collaboration en temps réel, et un modèle de tarification qui passe à l'échelle avec notre usage réel. Ce qui nous a vendus, ce n'était pas l'UI, le site marketing ou la démo ; c'était à quel point le MCP de Sanity et le modèle schema-as-code marchaient bien ensemble quand on les passait à un agent.
C'est probablement la phrase la plus importante de cet article.
Pour finir
La migration d'hier a pris trois heures, et l'industrie tech mettra un peu plus de temps à digérer l'implication. Si tu construis une boîte dont la douve était « personne ne va se donner la peine de switcher », les dix-huit prochains mois vont être intéressants, et si tu construis une boîte dont la douve est le produit lui-même, les dix-huit prochains mois vont être beaucoup de fun.
On construit Enao Vision pour le second camp, et Sanity aussi clairement. C'est pour ça que le swap a été facile, et pour ça qu'il valait la peine d'être écrit.
C'est le second article d'une nouvelle catégorie appelée Building Enao Vision, où on partage les coulisses de la construction de notre boîte et de notre produit. Le premier article s'intitule Pourquoi on a démarré Enao Vision.