La réversibilité contractuelle doit se tester avant la signature

La réversibilité contractuelle doit se tester avant la signature

Une situation illustrative suffit à montrer le piège. Un comité de direction doit choisir un service SaaS pour un processus critique. La démonstration est convaincante, le prix négocié et le calendrier rassurant. Le DSI pose alors une question simple : « Pouvez-vous restituer demain nos données, nos règles de gestion et les journaux nécessaires à leur contrôle ? » Le fournisseur répond que la réversibilité est prévue au contrat. Personne ne peut toutefois montrer un export exploitable, estimer sa durée ni expliquer comment le service continuerait pendant une migration. À cet instant, le dirigeant ne négocie plus une clause : il découvre une dépendance encore invisible.

Une promesse juridique n’est pas une capacité opérationnelle

Une clause de réversibilité décrit généralement des obligations. Elle ne prouve pas que l’organisation saura les exécuter sous contrainte. Entre « remettre les données » et permettre à un successeur de reprendre le service, l’écart peut inclure des formats propriétaires, des métadonnées absentes, des interfaces non documentées, des volumes difficiles à extraire ou des configurations détenues dans les outils du prestataire. Le risque ne réside donc pas seulement dans un refus de coopérer. Il apparaît aussi lorsqu’un fournisseur de bonne foi ne dispose pas du processus, des compétences ou des débits nécessaires. Le DSI doit traiter la sortie comme une architecture temporaire à concevoir, et non comme une formule de protection à relire au dernier moment.

Tester le scénario qui ferait réellement mal

Le test utile part d’une décision plausible : changer de fournisseur, internaliser une fonction, isoler un service après incident ou répondre à la disparition d’une offre. Il faut choisir le scénario le plus pénalisant sans imaginer une catastrophe totale. Pour une plateforme de données, ce sera peut-être l’export complet avec schémas, historiques et droits. Pour un ERP hébergé, la priorité pourra être la reconstruction des paramétrages et des interfaces. Pour un service de sécurité, la récupération des journaux, règles et preuves de traitement sera déterminante. Le dirigeant fixe alors un périmètre démontrable avant signature : un jeu de données représentatif, une configuration, une sauvegarde ou une procédure de transfert. Ce test réduit l’incertitude là où elle compte vraiment.

Transformer la clause en protocole vérifiable

La démarche peut tenir en six décisions. D’abord, nommer le propriétaire métier de la continuité et le responsable technique de la sortie. Ensuite, inventorier ce qui doit être restitué : données, métadonnées, configurations, développements, clés détenues par le client, historiques, documentation et éléments d’audit. Puis définir les formats, le canal, le chiffrement, les contrôles d’intégrité et les délais. Il faut également préciser qui fournit les environnements, qui corrige un export incomplet et comment les demandes sont acceptées. Vient ensuite un exercice borné, réalisé avec les équipes qui exploiteront réellement les fichiers. Enfin, le contrat doit intégrer les écarts constatés, le coût des opérations, l’assistance au successeur et la preuve de suppression en fin de transition. La négociation s’appuie ainsi sur des faits observables.

Mesurer autre chose que la présence d’un article contractuel

Le tableau de bord doit suivre la capacité, pas la conformité documentaire. Quelques indicateurs suffisent : part des objets attendus effectivement exportés ; proportion de fichiers lisibles sans outil du fournisseur ; durée de préparation et de transfert ; taux d’erreurs d’intégrité ; nombre de dépendances non substituables ; effort interne nécessaire pour reconstruire un environnement ; délai de correction d’un lot rejeté. Il faut aussi vérifier la continuité : pendant combien de temps l’ancien service reste-t-il accessible, et selon quelles conditions ? Ces mesures ne prétendent pas prédire toute sortie. Elles révèlent les points où l’entreprise dépend d’une coopération, d’un logiciel ou d’une compétence qu’elle ne maîtrise pas encore. C’est précisément ce qu’un arbitrage doit rendre visible.

Accepter le bon compromis, refuser les faux conforts

Une réversibilité absolue serait coûteuse et parfois irréaliste. Exiger la reproduction exacte d’un service très différenciant peut supprimer son intérêt ou conduire à payer une assurance disproportionnée. Le compromis consiste à distinguer ce qui doit rester souverain de ce qui peut être remplacé. Les données critiques, les preuves, les règles métier et les configurations indispensables méritent une exigence forte. Certaines fonctions propriétaires peuvent être abandonnées si leur perte est connue, évaluée et assumée. Le piège serait de confondre cette décision avec une renonciation implicite. Un fournisseur moins cher mais impossible à quitter peut rester le meilleur choix ; le comité doit alors enregistrer la dépendance, son horizon, son coût potentiel et les mesures compensatoires.

Les erreurs qui rendent le test décoratif

La première consiste à tester un petit fichier propre, sans pièces jointes, historique ni droits complexes. La deuxième est de laisser le fournisseur réaliser seul l’exercice : un export réussi par son expert ne garantit pas son exploitation par le client. La troisième est de reporter les modalités financières à la sortie, alors que la relation de négociation sera moins favorable. Autre erreur : vérifier les données mais oublier les configurations, journaux, interfaces et connaissances nécessaires à la reprise. Enfin, un test ancien ne protège pas contre les évolutions de service, changements de sous-traitants ou renouvellements contractuels. La réversibilité doit donc être réexaminée selon la criticité et après toute modification substantielle du dispositif, sans transformer chaque contrat mineur en programme lourd.

L’arbitrage appartient au dirigeant, pas au fournisseur

Avant de signer, le DSI formule une recommandation lisible : sortie démontrée, sortie partiellement démontrée avec réserves, ou dépendance acceptée pour une durée donnée. Les achats négocient les conditions, le juridique sécurise leur rédaction, les métiers évaluent les conséquences opérationnelles et le RSSI contrôle les données et les traces sensibles. Mais l’acceptation finale du risque revient à l’instance qui engage l’entreprise. Cette discipline rejoint l’enjeu développé dans Révolution Numérique ! : investir dans le cloud et les services numériques sans perdre la maîtrise des coûts, des risques et des dépendances. Le bon moment pour découvrir que la sortie ne fonctionne pas n’est pas le jour du départ. C’est avant l’entrée, quand il reste encore possible de choisir, d’exiger ou de renoncer.

Pour approfondir

Ouvrage : Révolution Numérique !: Le guide pour comprendre, décider et agir dans l’entreprise numérique — Amazon

Ouvrage : DSI EN CRISE: Reprendre le contrôle de l’IT, des ERP et des grands programmes — Amazon

Consulter la référence

Consulter la référence

#GouvernanceIT #ArchitectureSI #DSI #GuyDeLussigny #TransformationNumerique