Trois gestes, dans cet ordre. Récupérez vos données pendant que le service fonctionne encore : la restitution est prévue par votre contrat et le droit à la portabilité vous appuie. Sécurisez ensuite l'exploitation le temps de la bascule, car un logiciel qui tourne encore n'est pas un logiciel sûr. Choisissez enfin un remplaçant en posant la question qui manquait la première fois : si cet éditeur s'arrête à son tour, que me reste-t-il en main ?
Ce qui se passe vraiment quand un éditeur s'arrête
Rarement une coupure nette. Le plus souvent, le logiciel continue de fonctionner : c'est ce qui rend la situation confortable et dangereuse. Les correctifs cessent, la compatibilité avec les navigateurs et les systèmes se dégrade, une évolution réglementaire n'est plus suivie, et le jour où quelque chose casse, il n'y a plus personne pour le réparer.
Cette situation n'est pas marginale : les prestataires qui reprennent ces dossiers décrivent une demande régulière, et le plus souvent urgente — l'entreprise appelle quand la panne est là, pas quand l'annonce est tombée. Le meilleur moment pour agir est donc précisément celui où rien ne semble pressé.
Récupérer vos données : à quoi vous avez droit
Vos données vous appartiennent. Leur restitution en fin de contrat est en général prévue par le contrat lui-même, et le règlement européen sur la protection des données ouvre par ailleurs un droit à la portabilité dans un format structuré et lisible par machine. Demandez cet export par écrit, sans attendre l'échéance.
Un export n'est utile que s'il est exploitable. Réclamez un format ouvert (CSV, JSON, SQL) plutôt qu'une sauvegarde propriétaire que personne ne saura relire, et demandez la description des champs : un fichier de 40 colonnes sans dictionnaire coûte plus cher à décoder qu'à ressaisir.
- Faire l'export MAINTENANT, pendant que le service et l'interlocuteur existent encore.
- Exiger un format ouvert et une description des champs, pas seulement un dump.
- Vérifier l'export en l'ouvrant réellement : lignes attendues, accents, dates, pièces jointes.
- Conserver une copie hors du service, chez vous, avant toute résiliation.
- Noter ce que vous n'avez PAS pu récupérer : c'est ce qui décidera de la suite.
Choisir un remplaçant sans reproduire la dépendance
La question à poser à un nouvel éditeur n'est pas « êtes-vous pérennes ? » — tout le monde répond oui, et personne ne peut le promettre. La bonne question est : si vous vous arrêtez, qu'est-ce qui me reste en main, et sous quelle forme ? Un service qui ne peut répondre que par un export de données vous laissera, le jour venu, exactement là où vous êtes aujourd'hui.
C'est le principe de Blueprint Maker : vous décrivez votre besoin, l'application est générée et déployée, et le code source vous est remis dès le départ. Export en ZIP, envoi sur votre dépôt GitHub, hébergement chez vous ou sur l'URL dédiée fournie : un projet Next.js et Prisma standard, la structure que tout développeur web connaît. Blueprint Maker est une entreprise comme une autre, et c'est précisément l'intérêt de ne pas dépendre d'elle pour faire tourner votre outil.
Trois niveaux de génération (Sketch, Craft, Masterpiece) et un plan Découverte gratuit permettent de tester la reprise sur un périmètre réduit avant d'engager la migration complète : générer une première version à partir de vos données exportées coûte moins qu'une réunion de cadrage.
Le calendrier réaliste
Ne basculez pas dans l'urgence si vous pouvez l'éviter. L'ordre qui fonctionne : récupérer les données, reconstituer le besoin réel à froid — ce que l'ancien outil faisait vraiment, pas ce qu'il promettait —, générer et éprouver le remplaçant en parallèle, puis basculer avec l'ancien encore accessible en lecture le temps de vérifier.
Cette reconstitution est le seul bénéfice de la situation : un outil hérité contient toujours des écrans que personne n'utilise et des contraintes que plus personne ne s'explique. Le remplacer est l'occasion de ne remettre que ce qui sert.