Aller au contenu
Legiscope
Menu
Cybersécurité et GRC

Sortie d'un fournisseur SaaS : faire accepter l'export des données

Checklist de recette d'un export SaaS couvrant complétude, format, intégrité, accès, reprise et preuves de suppression résiduelle.

Recevoir un fichier compressé du fournisseur ne suffit pas à prouver qu’une sortie SaaS est possible. Il faut savoir si toutes les données et relations attendues sont présentes, si le format permet leur réutilisation, si l’export n’a pas été altéré, qui peut y accéder et ce qu’il advient des copies conservées par le fournisseur. Cette page propose une checklist de recette de l’export, à utiliser avant de signer l’acceptation d’une sortie. Elle ne remplace ni le contrat ni un plan de continuité complet.

Le guide NIST SP 1305 situe les exigences envers les fournisseurs dans une gestion du risque de chaîne d’approvisionnement. Pour les entités et services entrant dans son champ, le règlement DORA comporte des exigences relatives aux stratégies de sortie de certaines prestations TIC. Cela ne signifie pas que chaque client SaaS est soumis à DORA. La checklist proposée ici est un outil de recette opérationnelle, pas un formulaire légal prescrit à toutes les entreprises.

Définir ce que l’export doit permettre

Commencez par l’usage après la sortie: archive consultable, migration vers un autre fournisseur, reprise interne ou restitution à un client. Le même fichier peut suffire à une archive et être inutilisable pour une migration active. Identifiez les processus qui dépendront des données, les délais opérationnels et les personnes capables de confirmer leur sens. Un responsable métier, un administrateur technique et un responsable de la sécurité peuvent voir des défauts différents.

Établissez la liste des objets attendus avant de déclencher l’export: comptes, dossiers, événements, pièces jointes, commentaires, métadonnées, historiques, relations, permissions et paramètres pertinents. Certains éléments appartiennent contractuellement au client; d’autres sont des données d’exploitation du fournisseur dont la restitution dépend de l’accord. Ne supposez pas que tous les journaux internes sont exportables. Notez les inclusions, les exclusions, leur source contractuelle et la décision sur chacune.

La politique de sécurité des fournisseurs peut intégrer l’exigence de sortie dès l’achat. La recette ici vérifie concrètement ce qui est livré dans un cas donné.

Fixer une référence avant la demande

Un export ne peut être jugé complet sans point de comparaison. Relevez à une date et un fuseau précis les volumes par objet, les dossiers actifs et clos, le nombre de pièces, les propriétaires et les relations critiques. La référence peut venir de l’interface, d’une API ou d’un rapport du fournisseur, avec ses filtres et ses limites. Documentez les écarts connus: une interface peut exclure les archives ou compter une pièce jointe plusieurs fois.

Prévoyez une fenêtre de gel ou une réconciliation des changements pendant l’export. Si les utilisateurs continuent de créer des dossiers, deux totaux pris à des heures différentes divergeront naturellement. Décidez si un second export incrémental est possible et comment identifier les doublons. Une sortie signée sur un instantané incomplet peut laisser les dernières décisions dans l’ancien service.

Évitez de copier le contenu sensible dans un dossier de recette ouvert. Utilisez des comptes, empreintes, références et échantillons à accès limité. Conservez assez d’information pour expliquer un écart, pas plus que nécessaire. Pour les traitements de données personnelles, examinez les rôles et obligations applicables séparément; l’export technique n’éteint pas automatiquement le cadre de traitement.

Tester la complétude au bon niveau

Comparez d’abord les totaux par classe d’objet, puis les identifiants attendus. Un total identique peut cacher un dossier manquant et un doublon. Pour les objets critiques, vérifiez des clés stables et les liens entre eux. Une pièce jointe livrée sans le dossier ou la version auxquels elle appartient n’est pas réellement reprise. Contrôlez les champs indispensables à l’usage prévu: date, auteur, état, catégorie, propriétaire et historique de modification.

Échantillonnez les cas difficiles: gros dossiers, caractères accentués, objets supprimés mais encore conservés selon la politique, liens multiples, permissions restreintes et pièces volumineuses. La sélection doit être justifiée et complétée par des contrôles exhaustifs automatisables sur les identifiants et relations. Si le fournisseur ne peut fournir qu’un échantillon, écrivez que la complétude totale reste non démontrée et décidez quoi demander ensuite.

La gestion de la preuve d’audit illustre pourquoi dates et contexte des pièces comptent. Un répertoire de fichiers dépourvu de ses métadonnées peut préserver des octets sans préserver leur valeur de preuve.

Vérifier format et réutilisation

Demandez une description du schéma, des formats, des encodages, des fuseaux, des relations entre fichiers et des versions de l’export. Ouvrez l’archive avec un outil indépendant de l’interface du fournisseur. Essayez de reconstruire un objet de bout en bout dans l’environnement cible ou dans un lecteur d’archive maîtrisé. Si une donnée est disponible seulement dans un format propriétaire, évaluez le coût et les droits nécessaires pour la consulter après la fin du contrat.

Vérifiez les valeurs longues, caractères non latins, pièces binaires et états particuliers. Un CSV peut être « lisible » tout en perdant les retours à la ligne, les associations ou la précision des dates. Un JSON peut conserver la structure mais exiger une documentation de champs qui n’a pas été fournie. Le critère d’acceptation n’est pas le nom du format; c’est la capacité démontrée à satisfaire l’usage défini.

Si la migration est prévue, organisez une recette avec le destinataire. Une importation test sur un lot représentatif révèle des champs manquants plus tôt qu’une discussion contractuelle abstraite. Conservez la liste des transformations autorisées et des pertes de sens acceptées. Aucune application ne devrait être réputée compatible avant cet essai.

Contrôler intégrité et chaîne de remise

Consignez qui a lancé l’export, quand, depuis quel compte, vers quel espace et par quel canal. Calculez des empreintes des fichiers reçus et vérifiez qu’elles restent stables pendant le transfert et l’analyse. Une empreinte prouve que le fichier contrôlé n’a pas changé entre deux étapes; elle ne prouve pas que le fournisseur a exporté l’ensemble des données. Les deux contrôles sont complémentaires.

Protégez l’archive par chiffrement et restrictions d’accès adaptés à son contenu. Limitez les copies de travail et fixez leur durée de conservation. Un export peut concentrer, dans un seul fichier, des données qui étaient auparavant séparées par permissions dans l’application. Évaluez cette nouvelle exposition. Le responsable de sortie doit connaître les emplacements de l’archive et qui détient les clés nécessaires à son ouverture.

En cas d’échec de téléchargement, ne mélangez pas des fragments provenant de plusieurs instantanés sans règle de rapprochement. Demandez une nouvelle livraison identifiée ou un mécanisme de reprise documenté. L’intégrité exige aussi de savoir quelle version de l’export a été acceptée.

Construire une checklist de recette

La fiche suivante peut être jointe au dossier de sortie:

Point Question d’acceptation Preuve attendue
Périmètre Objets et périodes convenus livrés ? Inventaire contractuel et référence datée
Complétude Identifiants et relations attendus retrouvés ? Réconciliation et anomalies expliquées
Format Données relues indépendamment et réutilisables ? Schéma, lecteur et essai d’import
Intégrité Livraison identifiée et fichiers inchangés ? Journal de transfert et empreintes
Accès Seules les personnes autorisées consultent l’archive ? Test d’autorisation et liste d’accès
Continuité Service utilisable pendant la transition ? Test de reprise ou plan de maintien
Résidus Suppression ou conservation justifiée et attestée ? Attestation, calendrier et exceptions

Fixez avant la livraison quels écarts bloquent l’acceptation et lesquels peuvent être résolus ensuite. Une pièce historique manquante peut être critique pour un dossier litigieux même si elle représente une très faible fraction du volume. Le signataire doit connaître les réserves, leur propriétaire, leur délai et le recours si elles ne sont pas levées. Ne transformez pas un simple accusé de réception du fichier en validation définitive.

Examiner droits d’accès et dépendances

Testez l’archive avec les rôles qui en auront réellement besoin. Un administrateur capable d’ouvrir tout le lot ne démontre pas que les anciens contrôles d’accès ont été préservés. Selon la destination, il peut être nécessaire de reconstruire des permissions dossier par dossier ou d’isoler une archive de consultation. Documentez les écarts et les mesures temporaires avant d’élargir l’accès. L’export ne doit pas servir de contournement permanent des restrictions de l’application source.

Recensez les dépendances: intégrations, liens dans des rapports externes, clés de référence et utilisateurs qui continuent de travailler dans l’ancien service. Préparez la bascule de ces références et la manière de rechercher un ancien identifiant. Une sortie technique réussie peut échouer opérationnellement si les équipes ne savent plus retrouver une décision. Le plan de sortie sous DORA donne le cadre de risque tiers pour les entités et services concernés.

Si le nouveau système doit recevoir des pièces, testez la récupération avec un compte utilisateur ordinaire, pas seulement avec un compte de migration. La capacité d’un script d’import à écrire une ligne ne prouve pas l’accès futur d’un auditeur ou d’un responsable métier.

Exemple: un export volumineux mais inutilisable

Imaginons un fournisseur fictif de gestion des contrôles qui livre 12 gigaoctets de fichiers et annonce une sortie achevée. L’inventaire indique que les pièces sont présentes, mais le fichier de correspondance entre pièces et dossiers manque. Les dossiers eux-mêmes portent des identifiants nouveaux sans table ancien/nouveau. Une comparaison de volume donne une impression de complétude; une recette métier révèle que personne ne peut retrouver la preuve associée à un contrôle cité dans un rapport antérieur.

Le client rejette la recette de réutilisation et demande le schéma des relations. Le fournisseur livre ensuite un manifeste identifiant chaque dossier, pièce et version. L’équipe teste un échantillon de contrôles anciens et récents, puis réconcilie automatiquement les identifiants sur tout le lot. Les pièces sont stockées dans un espace restreint, leurs empreintes sont conservées et la bascule est signée avec une réserve sur un petit nombre de fichiers corrompus à résoudre. Cette réserve a un responsable et une date.

Ce scénario est fictif. Il montre qu’un poids de fichiers, un nombre d’objets et une preuve de possibilité de reprise mesurent des choses différentes. Les critères doivent être écrits avant que le fournisseur annonce la livraison terminée.

Obtenir une preuve sur les données résiduelles

Après acceptation de l’export et fin de la période de transition, demandez ce que le fournisseur conserve encore: production, sauvegardes, journaux, environnements de support et sous-traitants. Le contrat et les obligations applicables peuvent prévoir des durées différentes. Une déclaration « tout supprimé » sans périmètre ni date est peu informative; une attestation devrait préciser ce qui a été supprimé, ce qui subsiste temporairement, pourquoi et quand la situation sera revue.

La suppression dans des sauvegardes peut suivre un cycle distinct; documentez-le au lieu d’exiger une affirmation techniquement invérifiable. Vérifiez également que les accès du fournisseur et les comptes d’intégration devenus inutiles sont révoqués. Le guide de sécurité des sous-traitants apporte un contexte spécifique si le fournisseur traite des données personnelles pour le client. La preuve de suppression est une partie de la sortie, pas un substitut à la vérification de l’export.

Si une obligation de conservation subsiste, séparez les données conservées à cette fin de celles utilisées pour fournir le service. La justification juridique et la sécurité des copies doivent être revues par les responsables compétents. Ne promettez pas une disparition absolue si des traces légalement ou techniquement conservées restent dans le périmètre documenté.

Signer une sortie défendable

La décision finale rassemble référence d’inventaire, manifeste livré, résultats de réconciliation, essai de lecture ou d’import, empreintes, contrôles d’accès, réserves, plan de transition et réponse du fournisseur sur les données résiduelles. Elle identifie les personnes qui ont vérifié les aspects techniques, métier, sécurité et contractuels. Si plusieurs services sont concernés, évitez qu’une signature globale masque le refus d’un périmètre critique.

Le guide de risque de chaîne d’approvisionnement NIS2 fournit un autre contexte de dépendance fournisseur, sans rendre ses obligations interchangeables avec DORA. Dans tous les cas, la décision opérationnelle repose sur les faits de la sortie: données utilisables, accès maîtrisés, continuité assurée et résidus expliqués. Une checklist remplie avec des références vérifiables permet de reprendre ce raisonnement lors d’un audit ou d’un désaccord contractuel.

Prévoir le cas d’un fournisseur peu coopératif

Une sortie peut commencer avant que le fournisseur accepte de produire le manifeste, le schéma ou l’attestation espérée. Séparez alors les faits vérifiés par le client, les affirmations du fournisseur et les pièces manquantes. Utilisez les moyens contractuels de demande et d’escalade appropriés, sans écrire dans le dossier que la complétude est acquise par défaut. Si le service reste nécessaire, identifiez la période pendant laquelle l’accès doit être maintenu pour permettre une migration sûre. La décision sur la continuité et celle sur un éventuel litige contractuel ne sont pas toujours prises par les mêmes personnes.

Préparez une solution de lecture minimale lorsque l’import cible n’est pas prêt. Une archive structurée, chiffrée et accompagnée de son schéma peut préserver la possibilité d’examiner les dossiers; elle ne remplace pas automatiquement les fonctions de recherche, de validation ou de collaboration de l’ancienne application. Mentionnez clairement ce qui reste impossible. Si un test d’import est reporté, la signature de sortie devrait réserver cette limite, fixer une date et préserver les droits d’accès nécessaires à sa résolution.

La situation exige également une attention aux coûts: un export supplémentaire, une extraction de pièces jointes ou une période prolongée d’accès peuvent dépendre du contrat. Vérifiez ces points avant la dernière semaine, quand la pression du calendrier réduit les options. Le meilleur moment pour tester un export est souvent avant de décider de quitter le fournisseur: les défauts constatés peuvent alors encore être corrigés dans la relation de service normale.

L
Rédigé par
Legiscope
Legiscope

Mettez ces conseils en pratique

Découvrez comment Legiscope relie les registres de confidentialité, les sources et les travaux soumis à validation.

Réserver une démo personnalisée
Poursuivre la lecture

Articles liés

01Cybersécurité et GRC

Appétence au risque cyber : traduire une décision de direction en seuils

Une direction peut dire qu'elle a « une faible appétence au risque cyber » sans que cette formule aide à arbitrer une interruption de service, une exception de sécurité ou une dépense de réduction du…

1 octobre 2026
02Cybersécurité et GRC

Délais de correction des vulnérabilités : bâtir une matrice de priorité

Fixer le même délai de correction à toutes les vulnérabilités dites « critiques » paraît simple, mais laisse de côté des questions décisives : l'actif est-il exposé, l'exploitation est-elle…

1 octobre 2026
03Cybersécurité et GRC

Migration vers un logiciel GRC : définir les critères de reprise des données

Une migration GRC peut afficher le bon nombre de risques et perdre pourtant ce qui rend les dossiers utilisables: leurs identifiants, les liens vers les contrôles, les propriétaires ou l'historique…

1 octobre 2026
04RGPD

Accountability RGPD : démontrer une conformité qui fonctionne

L'« accountability » désigne la responsabilité du responsable de traitement de respecter les principes du RGPD et d'être en mesure de montrer comment il les respecte. L'article 5, paragraphe 2, du…

12 avril 2026
05Données personnelles

Adresse IP donnée personnelle : jurisprudence CJUE et RGPD

L'adresse IP est-elle une donnée personnelle au sens du RGPD ? La question a été tranchée par la Cour de justice de l'Union européenne dans l'arrêt Breyer c/ Bundesrepublik Deutschland (C-582/14, 19…

12 avril 2026
06Personal Data

AI Act : Guide Complet sur le Règlement Européen sur l'Intelligence Artificielle

L'AI Act de l'Union Européenne transforme radicalement le paysage de l'intelligence artificielle en établissant des normes strictes pour le développement et l'utilisation des systèmes d'IA. Ce…

9 décembre 2024
07Données personnelles

Alternatives à OneTrust : cinq pistes à comparer

Chercher une alternative à OneTrust ne revient pas à chercher le même catalogue de modules avec un autre logo. Il faut d'abord savoir ce que l'organisation utilise réellement : registre des…

6 juillet 2026
08Données personnelles

Analyse d'impact RGPD (AIPD) : méthodologie et exemples

L'analyse d'impact RGPD (AIPD ou DPIA en anglais) est l'une des obligations les plus structurantes du RGPD. L'Art. 35 impose au responsable de traitement de réaliser cette analyse avant tout…

12 avril 2026