Réversibilité : la clause qu'on signe et qu'on ne teste jamais.

Toutes les DSI veulent une clause de réversibilité. Peu la confrontent à un vrai export. Le sujet n’est pas d’abord juridique. Il est technique, documentaire et budgétaire.

Le jour de sortie, une promesse écrite ne suffit pas. Si l’extraction échoue, la clause ne protège pas. Si le format est illisible, la migration cale. Si le coût grimpe, la sortie devient théorique.

La clause rassure, le test protège

Une clause de réversibilité donne un sentiment de contrôle. Elle ne prouve rien sur l’exécution. Elle ne dit pas quels objets sortent, ni dans quel ordre, ni avec quelles dépendances. Elle ne dit pas si les pièces jointes, les logs, les historiques, les règles de routage et les métadonnées suivent réellement.

Le piège est simple. On signe une promesse, puis on considère le sujet clos. C’est une faiblesse de gouvernance. Une réversibilité non testée reste une hypothèse. Le jour du départ, les équipes découvrent souvent que le référentiel d’export ne couvre pas le référentiel d’usage. Les données existent, mais pas les liens entre elles.

Demandez : "Pouvez-vous me remettre la liste exhaustive des objets exportables, avec leur format exact et leur dépendance fonctionnelle ?" Demandez aussi : "Les pièces jointes, les tags, les règles de traitement et les historiques sont-ils inclus sans transformation ?" Le critère vérifiable est simple : un export doit être relu par vos équipes sans interprétation manuelle du schéma.

Exigez un test annuel sur un périmètre réel. Pas un jeu d’essai. Pas un PDF de démonstration. Un export complet, horodaté, contrôlé par vos équipes, avec vérification de lisibilité, de complétude et de cohérence entre les objets. Le symptôme d’un faux test est facile à repérer : le fichier s’ouvre, mais les relations métier ont disparu.

Le vrai piège est le format propriétaire

Un export existe souvent sur le papier. Le piège commence quand le format reste dépendant de l’éditeur. CSV tronqué, JSON documenté à moitié, archive compressée sans dictionnaire de données, schéma non publié : l’export devient un piège élégant. Vous sortez des octets, pas un actif réutilisable.

La vraie question n’est pas seulement “peut-on sortir ?”. C’est “peut-on réimporter ou exploiter sans reconstruire le modèle à l’aveugle ?”. Si la sémantique des champs disparaît, vous perdez la valeur opérationnelle. Le fichier est là, mais personne ne sait si un identifiant est technique, fonctionnel ou historique.

Demandez : "Quel est le dictionnaire de données d’export, et sous quelle forme le livrez-vous ?" Demandez aussi : "Quelle est la version du schéma, et comment gérez-vous les ruptures de compatibilité ?" Le critère contractuel à exiger est net : schéma publié, versionné, documenté, avec historique des changements et rétrocompatibilité sur la durée du contrat.

Vérifiez l’accès aux pièces brutes. Les enregistrements, les transcriptions, les événements et les pièces jointes doivent sortir sans transformation irréversible. Le piège classique est visible au premier test : les données sont aplaties, les champs calculés remplacent les valeurs sources, et la reconstitution devient un chantier de nettoyage.

Une clause sans extraction testée est une promesse de confort, pas une protection.

Le délai de sortie doit être mesurable

La plupart des contrats parlent de réversibilité en termes vagues. “Dans un délai raisonnable” n’est pas un engagement. “À la demande du client” ne suffit pas. Le jour venu, il faut un calendrier, un responsable, des jalons et un chemin critique. Sans cela, la sortie glisse d’une semaine à l’autre.

Un test annuel révèle la capacité réelle de sortie. Il montre le temps de préparation, le temps d’extraction, le temps de contrôle et le temps de remise en forme. Il expose aussi les dépendances cachées : API limitées, quotas, files d’attente, validations manuelles, fenêtres de maintenance imposées. C’est souvent là que le délai contractuel se casse.

Demandez : "Quel délai garantissez-vous, par lot d’objets, entre la demande de sortie et la remise d’un export exploitable ?" Demandez aussi : "Qui est responsable de l’extraction côté éditeur, et quel support reste disponible pendant la fenêtre de sortie ?" Le critère vérifiable est un calendrier daté, avec engagement de réponse et de livraison sur chaque étape.

Fixez un scénario simple. Un périmètre de données. Une fenêtre de test. Un livrable attendu. Vous n’avez pas besoin de migrer toute la plateforme pour mesurer la réalité. Le symptôme d’un délai fictif est clair : l’éditeur promet vite, puis réclame des validations successives avant de lancer le moindre export.

Le coût de sortie doit être plafonné

La réversibilité échoue souvent sur un point discret : la facture. L’extraction est traitée comme un projet de service. Les heures d’assistance s’additionnent. Les demandes de format spécifique deviennent des options. À la fin, sortir coûte plus cher que rester.

Le contrat doit encadrer ce coût. Sinon, la sortie devient économiquement dissuasive. Une réversibilité théorique, mais hors de prix, n’est pas une sécurité. C’est une dépendance prolongée, entretenue par la tarification. Le vrai verrou n’est pas technique, il est financier.

Demandez : "Quel est le barème complet des prestations de sortie, et qu’est-ce qui est inclus dans le support standard ?" Demandez aussi : "Facturez-vous la documentation de schéma, l’assistance à l’extraction, la remise des logs et les itérations de correction ?" Le critère contractuel à viser est un forfait ou un plafond ferme, avec liste explicite des prestations incluses.

Sans plafond, l’éditeur fixe le coût du détachement. Le symptôme est connu : chaque demande de précision devient une ligne de devis, chaque correction une prestation additionnelle, et la décision de sortie recule. Un bon contrat borne aussi les délais de facturation et interdit les options indispensables déguisées en services premium.

L’exercice annuel d’extraction doit être traité comme un contrôle

Le bon réflexe n’est pas de relire la clause. C’est de la simuler. Un exercice annuel d’extraction vaut mieux qu’un audit de papier. Il force l’éditeur à prouver ce qu’il promet, et la DSI à vérifier ce qu’elle croit posséder. Sans exécution réelle, la réversibilité reste une intention.

L’exercice doit produire des preuves. Un export complet. Un dictionnaire de données. Un taux de complétude vérifié. Une liste d’écarts. Une date de correction. Sans ces éléments, le test ne sert qu’à rassurer. Le piège est fréquent : on valide le principe, mais on ne mesure ni les manques ni les délais de correction.

Demandez : "Pouvez-vous inscrire cet exercice au plan de contrôle fournisseur, avec un compte rendu signé et des écarts datés ?" Demandez aussi : "Qui porte le sponsor métier, qui porte l’exploitation, et quel seuil transforme un écart en non-conformité ?" Le critère vérifiable est un plan d’action avec responsables nommés, échéances et preuve de clôture.

Testez aussi le pire cas réaliste : sortie sous contrainte, support dégradé, documentation minimale, délai court. C’est là que la clause révèle sa valeur réelle. Le symptôme d’un dispositif fragile est immédiat : l’export fonctionne seulement quand tout le monde est disponible, ce qui n’est pas un vrai scénario de sortie.