Votre SaaS ferme : récupérer ses données avant qu'il soit trop tard

« Nous avons le regret de vous informer que le service fermera le 31 du mois prochain. » Le message arrive un mardi matin, et il ne laisse jamais six mois.

C’est à cet instant qu’on découvre trois choses. Que le bouton d’export produit un tableau plat, sans les pièces jointes. Que trois autres outils étaient branchés sur celui-ci. Et que personne, en quatre ans, n’avait ouvert un export pour vérifier ce qu’il contenait.

Ce qu’on croit exporter, et ce qu’on exporte#

Un service en ligne ne contient presque jamais que des lignes et des colonnes. Il contient une structure, et c’est la structure qui a de la valeur.

Voici ce qu’un export ordinaire laisse en général derrière lui :

• Les pièces jointes. Les devis, les photos de chantier, les justificatifs, les contrats signés. Ils sont référencés dans le tableau par un lien qui cessera de fonctionner en même temps que le service.
• L’historique. Qui a modifié quoi, et quand. C’est souvent la seule trace de ce qui s’est passé sur un dossier — et parfois une pièce utile en cas de litige.
• Les commentaires et les échanges. Le fil de discussion attaché à une affaire vaut fréquemment plus que la fiche elle-même.
• Les relations entre objets. Un client relié à ses contacts, à ses commandes, à ses interventions. Un export en fichiers séparés perd les liens, ou les remplace par des identifiants internes que le prochain outil ne comprendra pas.
• Les champs personnalisés, ceux que vous avez ajoutés au fil des ans et qui portent la spécificité de votre métier.
• Les automatisations et les modèles, qui ne s’exportent presque jamais et qu’il faudra reconstruire.

Autrement dit : l’export récupère les données, rarement le système.

Les six questions à poser avant de souscrire#

Elles se posent en un quart d’heure, au moment où le commercial est le plus disposé à répondre.

1. Puis-je déclencher l’export moi-même ? Un export sur demande, traité par le support, est une promesse dont la valeur dépend entièrement de l’état de l’entreprise le jour où vous en aurez besoin — c’est-à-dire le pire jour possible.

2. Dans quel format ? Un format ouvert et documenté, ou un fichier propriétaire que seul l’éditeur sait relire ? La question n’est pas théorique : elle décide de qui pourra reprendre vos données.

3. L’export contient-il les pièces jointes et l’historique ? Demandez-le explicitement, et faites-le écrire.

4. Combien de temps après la résiliation puis-je encore exporter ? Beaucoup de contrats prévoient trente jours. Certains prévoient zéro.

5. Que devient la donnée ensuite ? Suppression effective, dans quel délai, et dans les sauvegardes également ?

6. Existe-t-il une interface de programmation ? C’est la seule réponse qui permette une extraction régulière plutôt qu’un export ponctuel — et donc une sauvegarde de votre côté.

Le test qui change tout, et qui prend une heure#

Aucune de ces réponses ne vaut la vérification.

Déclenchez un export dès la souscription. Ouvrez-le. Regardez ce qu’il contient. Comptez les fichiers joints. Cherchez l’historique. Essayez d’ouvrir le format annoncé avec un outil qui n’est pas celui de l’éditeur.

Cela prend une heure, et cela transforme une case cochée dans une plaquette en fait vérifié. Refaites-le une fois par an — les formats d’export changent, silencieusement, à l’occasion des mises à jour.

Nous appliquons la même logique aux sauvegardes, pour une raison identique : une sauvegarde jamais restaurée n’est pas une sauvegarde, c’est une hypothèse.

Les signaux qui annoncent une fin#

Aucun ne prouve rien isolément. Deux ou trois réunis méritent qu’on prépare tranquillement une sortie, ce qui vaut infiniment mieux que de la subir.

• Un rachat par un concurrent. L’acheteur veut souvent la clientèle, pas le produit.
• L’arrêt des nouveautés. Plus de corrections, plus de fonctionnalités, un blog qui date de dix-huit mois.
• Un support qui s’allonge. Les délais de réponse sont le premier indicateur d’une équipe qui rétrécit.
• Une hausse brutale des tarifs, ou la disparition du palier d’entrée de gamme. Souvent le signe qu’on cherche à concentrer le revenu sur les gros comptes avant de fermer le reste.
• Un changement de conditions qui restreint un usage, exclut un cas ou limite un volume.

Le jour où l’annonce tombe#

Dans cet ordre, et pas dans un autre.

1. Exportez immédiatement. Avant de choisir un remplaçant, avant de réunir qui que ce soit. Les serveurs s’éteignent régulièrement avant la date annoncée, et les fenêtres d’export saturent dans les derniers jours.

2. Inventoriez ce qui en dépendait. Les intégrations avec vos autres outils, les automatisations, les adresses de redirection, les liens envoyés à des clients, les factures qui pointaient dessus. C’est ce qui casse ensuite, semaine après semaine, sans qu’on comprenne pourquoi.

3. Vérifiez vos obligations de conservation. Certaines données doivent être conservées pendant des années pour des raisons comptables ou légales, indépendamment de l’existence du service qui les hébergeait.

4. Traitez les données personnelles. Vous restez responsable de traitement ; l’éditeur n’était que sous-traitant. Sa disparition ne vous décharge de rien, et le contrat doit prévoir restitution puis suppression effective. C’est la même logique que celle qui commande, selon nous, de garder les comptes au nom du client.

5. Choisissez ensuite, sans précipitation. C’est l’étape qu’on fait en premier, et c’est une erreur : choisir dans l’urgence, c’est reproduire exactement la situation qu’on est en train de subir.

Le cas le plus dangereux#

Ce n’est pas le service grand public qui ferme — il y a toujours un concurrent, et la migration est documentée.

C’est le logiciel métier spécifique, hébergé par son éditeur, développé pour votre secteur par une petite structure. Il porte votre métier, il n’a pas d’équivalent, l’éditeur compte trois personnes, et il n’existe aucun outil d’import chez qui que ce soit.

Dans cette configuration, trois précautions valent tout le reste : obtenir contractuellement un export périodique automatique que vous stockez chez vous, faire préciser le sort du code source en cas de cessation d’activité, et vous assurer que la documentation de la structure des données existe ailleurs que dans la tête du développeur.

Ce sont exactement les questions que nous posons lors d’un audit technique, et ce sont rarement celles auxquelles on a déjà réfléchi.

Ce qu’il faut en retenir#

La réversibilité n’est pas une clause juridique de plus. C’est une propriété qui se teste, comme on teste une sauvegarde ou une porte de secours.

Et comme une porte de secours, elle ne sert qu’une fois — le jour où elle est bloquée, il est déjà trop tard pour s’en occuper.