Reconnaître le verrouillage
Le verrouillage ne se voit pas à l'achat, il se découvre au moment de partir. Quatre signes objectifs, indépendants du prix affiché :
- Aucun export complet n'existe, ou l'export ne sort qu'un sous-ensemble des données (pas les pièces jointes, pas l'historique, pas les champs personnalisés).
- Le prix grimpe avec l'usage réel du métier (par utilisateur, par volume, par module) plutôt qu'avec la valeur perçue — l'outil punit la croissance qu'il était censé accompagner.
- Des fonctions qu'on utilisait déjà passent derrière un palier supérieur lors d'une refonte tarifaire, sans qu'on ait rien changé à son usage.
- La question « et si vous fermiez, ou changiez de politique demain » n'a pas de réponse rassurante — parce que rien dans le contrat n'engage l'éditeur sur ce point.
Ce qui rend une sortie difficile — et ce qui ne devrait pas
Deux choses rendent une migration coûteuse, et une seule est légitime. Le coût légitime : reconstruire un workflow qui s'est affiné pendant des années d'usage — statuts, validations, exceptions apprises sur le terrain. Ce travail-là a de la valeur et prend du temps, quel que soit l'outil de destination.
Le coût illégitime : un format de données propriétaire, un export volontairement dégradé, une équipe support qui ralentit une demande de départ. Ce n'est pas un coût technique, c'est une friction commerciale déguisée en limitation technique. Le distinguer des deux évite de renoncer à partir pour une raison qui n'en est pas une.
La méthode pour partir sans big bang
La migration commence par la structure, jamais par les données brutes. Étape 1 : décrivez votre activité TELLE QU'ELLE EST AUJOURD'HUI, pas telle que l'ancien outil vous a habitué à la saisir — les deux divergent souvent, parce qu'un logiciel rigide fait contourner ses propres limites avec des champs texte fourre-tout et des statuts détournés. C'est le moment de décrire le métier, pas l'écran de l'ancien logiciel.
Étape 2 : générez l'application (le niveau Sketch, gratuit avec le plan Découverte, suffit à cette validation) et confrontez-la à trois ou quatre cas réels de votre semaine — un dossier compliqué, une exception, un cas limite que l'ancien outil gérait tant bien que mal. C'est là que les non-dits de l'ancien système remontent.
Étape 3 : ajustez la description et régénérez jusqu'à ce que la structure tienne. Étape 4 seulement : basculez le flux COURANT vers la nouvelle application ; gardez l'ancien outil accessible en lecture seule le temps de la transition, sans y ressaisir quoi que ce soit de nouveau.
Ce qui n'est pas automatique : la donnée historique
Soyons directs : Blueprint Maker ne branche pas d'import automatique depuis un logiciel tiers — aucun outil de génération ne peut promettre cela pour tous les formats propriétaires du marché. Ce qui est réellement possible : exporter ce que l'ancien outil accepte de rendre (le plus souvent un CSV partiel), l'utiliser comme référence pour vérifier que la structure générée correspond au réel, et ressaisir ou faire ressaisir les données qui comptent encore. Le code étant du Next.js et du Prisma standard, exportable, un développeur peut aussi y brancher un script d'import ponctuel depuis cet export — un chantier limité dans le temps, pas une dépendance permanente.
La bonne nouvelle : la plupart des migrations n'ont pas besoin de tout l'historique. Les dossiers actifs et les quelques derniers mois suffisent presque toujours ; l'archive reste consultable dans l'ancien outil, en lecture seule, aussi longtemps que nécessaire.
Les pièges d'une sortie de verrouillage
Premier piège : reproduire à l'identique les écrans de l'ancien logiciel. Ses champs et ses menus reflètent souvent les limites de SA technologie, pas les besoins de votre métier — les reproduire importe le verrouillage suivant avec soi.
Deuxième piège : viser 100 % de l'historique avant de basculer. C'est le meilleur moyen de ne jamais partir. Le flux courant d'abord, l'archive ensuite si elle sert vraiment.
Troisième piège : échanger un verrouillage contre un autre. C'est ce que la propriété du code résout structurellement : une application générée s'exporte (ZIP, GitHub push) et s'héberge où vous voulez — quitter Blueprint Maker un jour suit exactement la même logique que quitter l'ancien outil aujourd'hui, en beaucoup plus simple.