Réversibilité cloud : l’export existe, mais sauriez-vous réellement repartir ?

Votre fournisseur propose un bouton d’export. Votre contrat mentionne une restitution des données. Pourtant, une question reste entière : une autre équipe pourrait-elle remettre le service en fonctionnement à partir de ce que vous récupéreriez ? Entre posséder un fichier et retrouver une activité utilisable, il peut manquer les règles de gestion, les dépendances, les accès, la documentation et les personnes capables de les comprendre. C’est cet écart qu’une direction doit rendre visible avant de devoir changer de prestataire.

La réversibilité n’impose pas de quitter le cloud ni de multiplier les fournisseurs. Elle consiste à connaître les conditions d’un changement, afin de conserver une capacité de décision. Une dépendance choisie et documentée peut être acceptable. Une dépendance découverte pendant une crise l’est beaucoup moins. Voici une méthode de travail proposée pour transformer cette question en arbitrage concret, sans prétendre fournir un avis contractuel ou réglementaire.

Commencer par un service, pas par un catalogue de technologies

Choisissez un périmètre suffisamment précis : la facturation d’une filiale, un portail documentaire ou le suivi d’une activité commerciale. Écrivez ce que les utilisateurs doivent retrouver. Un inventaire de serveurs ne décrit pas, à lui seul, le résultat attendu par le métier. Il faut aussi savoir qui utilise le service, quelles opérations comptent et quelles interruptions seraient difficiles à supporter.

Sur cette première fiche, distinguez ce qui est indispensable de ce qui peut attendre. Le métier peut avoir besoin de consulter un historique avant de pouvoir lancer de nouvelles opérations. Une interface secondaire peut être reconstruite plus tard. Ces priorités doivent être discutées avec les responsables concernés, et non déduites exclusivement de l’architecture technique. Elles donnent un ordre au travail et permettent de comparer des solutions autrement que par leur prix affiché.

Décrire ce qu’il faut récupérer

Une liste utile ne se limite pas aux données principales. Elle peut inclure les pièces jointes, les référentiels, les relations entre objets, les règles de calcul, les paramètres et les traces nécessaires pour comprendre un traitement. Il faut ensuite séparer ce qui est effectivement exportable, ce qui demande une intervention du fournisseur et ce qui devrait être reconstruit.

Prenons un exemple pédagogique : une entreprise récupère ses factures mais perd la correspondance entre les codes clients de deux systèmes. Les documents existent, pourtant le rapprochement devient difficile. Le problème n’est pas forcément un fichier manquant ; c’est parfois une signification manquante. Demander à une personne extérieure au projet de lire un petit échantillon révèle souvent des implicites que l’équipe habituelle ne remarque plus.

Tester une sortie limitée et réversible

Avant un exercice, définissez un environnement sans risque pour la production, des données appropriées au test, un responsable et un critère de réussite. Ne coupez pas le service utilisé par les équipes pour vérifier une hypothèse. L’objectif initial peut être modeste : importer un échantillon dans un environnement distinct, retrouver les relations attendues, puis faire valider le résultat par un utilisateur compétent.

Conservez les erreurs rencontrées et le temps réellement passé. Une procédure qui réussit uniquement grâce à une personne connaissant un mot de passe oublié ou un script personnel reste fragile. Le test doit faire apparaître ces conditions, pas les masquer pour produire un bilan rassurant. Une deuxième personne devrait pouvoir reprendre les instructions sans recevoir une longue explication orale. Si ce n’est pas le cas, vous avez déjà trouvé une action utile.

Mettre les coûts et les responsabilités sur la même page

La décision ne repose pas uniquement sur le coût de l’export. Ajoutez les travaux de transformation, les interfaces à reprendre, la période de coexistence, la mobilisation du métier et la formation éventuelle. Ce sont des postes à estimer, pas des économies garanties. Notez les inconnues au lieu de les remplacer par des montants arbitraires.

Pour chaque difficulté, attribuez un responsable de clarification et une date de réponse. Certaines questions relèvent de la DSI, d’autres des achats, du fournisseur ou de la direction métier. Les clauses applicables doivent être examinées avec les interlocuteurs compétents. Un tableau technique ne tranche pas une obligation juridique, et une clause rassurante ne démontre pas qu’une reprise opérationnelle a été testée.

Décider ce que vous acceptez de conserver

À l’issue de l’exercice, plusieurs décisions sont possibles : maintenir la solution, améliorer la documentation, négocier une prestation de sortie, financer un test plus complet ou préparer un remplacement. Le bon résultat n’est pas nécessairement une migration. C’est une décision dont les limites sont connues, avec un prochain contrôle fixé.

Une direction peut accepter qu’un service soit difficile à déplacer si sa valeur le justifie. Elle doit alors savoir ce que cette dépendance implique et qui surveille son évolution. La réversibilité devient ainsi un élément de gouvernance, au même titre que les coûts et la continuité. Elle cesse d’être une promesse rangée dans un contrat que personne n’a rouvert.

Prolonger la réflexion avec Révolution Numérique !

Dans l’avant-propos de Révolution Numérique !, Guy de Lussigny relie la transformation des organisations à la connaissance interne, à la maîtrise des contrats et à la capacité de fonctionner autrement. Le sommaire développe notamment le cloud, les dépendances fournisseurs et les achats IT. La démarche proposée ici applique ces préoccupations à une question précise : rester capable de choisir quand le contexte change.

Découvrir Révolution Numérique ! permet de replacer ce travail dans une vision plus large du système d’information, des responsabilités et des arbitrages de direction. Le livre s’adresse aux décideurs comme aux professionnels qui doivent rendre ces sujets compréhensibles et actionnables.

Vous devez reprendre un programme cloud, clarifier une dépendance critique ou préparer une transition DSI ? Échangez avec GDLTC sur votre situation. Un premier cadrage doit identifier le périmètre, les acteurs, les preuves disponibles et la décision à préparer, avant de lancer un chantier de transformation.

#Cloud #DSI #ManagementDeTransition #RevolutionNumerique #Gouvernance