
Mise en œuvre
Préparer la migration de données vers le SaaS : sources, qualité et tests
Les migrations vers le SaaS répondent à des motifs récurrents : une flexibilité accrue, une meilleure évolutivité, une innovation plus rapide et un paiement basé sur l'utilisation plutôt que des coûts d'infrastructure fixes.
Pourquoi migrer – et ce que cela implique pour les données
Les migrations vers le SaaS répondent à des motifs récurrents : une flexibilité accrue, une meilleure évolutivité, une innovation plus rapide et un paiement basé sur l'utilisation plutôt que des coûts d'infrastructure fixes. Les clients s'attendent à une accessibilité sur tous les canaux et à un service disponible 24 heures sur 24. Le pool de ressources partagé réduit les coûts et la consommation d'énergie, car les ressources cloud sont utilisées par plusieurs clients. Dans l'étude du TCS « Connected Future », 63 % des grandes entreprises européennes ont cité le cloud comme une clé centrale pour garantir leur compétitivité.
Toutes les applications n'ont pas leur place dans le cloud. La décision dépend de savoir si la migration crée une valeur ajoutée pour l'application concrète. Il arrive qu'une application ne fonctionne pas correctement dans le cloud, par exemple parce que les interfaces ou les connexions nécessaires font défaut. De tels cas doivent être clarifiés avant la copie des données, et non après.
Pour la planification des données, une décision est prise pour chaque application : migrer, adapter, remplacer par une alternative SaaS ou continuer à exploiter localement. Cela détermine quels jeux de données déménagent et lesquels restent dans l'ancien système jusqu'à son remplacement. L'ampleur, la structure et les dépendances des données concernées déterminent l'effort de migration.
État des lieux : rendre visibles les sources de données, les systèmes et les silos de données
L'état des lieux couvre l'ensemble du paysage informatique : applications, données et besoins de l'entreprise en matière de continuité des activités. Chaque application tombe dans l'une des trois catégories : déjà compatible avec le cloud, nécessite une adaptation, ou ne peut pas être migrée vers le cloud. Pour les applications plus anciennes ou personnalisées, qui n'ont pas été développées pour un environnement cloud standardisé, il convient d'examiner si des alternatives modernes, telles qu'une solution SaaS, sont disponibles.
Les petites applications, utilisées par une seule personne ou par quelques utilisateurs seulement, peuvent être cruciales pour les opérations commerciales et méritent la même attention que les silos de données – des environnements de données isolés les uns des autres. Il faut déterminer si ces silos peuvent être dissous lors de la migration et ce qui est nécessaire pour relier les données provenant de différents silos. Dans les hôpitaux suisses, des silos de données se forment à partir de nombreux systèmes informatiques, parfois isolés ou insuffisamment intégrés sur le plan technique.
L'inventaire comprend l'examen de toutes les technologies de stockage, d'intégration, de traitement et d'analyse des données, y compris les anciens systèmes obsolètes. L'analyse de readiness et l'inventaire des applications créent de la transparence concernant les données, les dépendances et les risques ; les dettes techniques et le manque de transparence sur les applications et leurs dépendances figurent parmi les freins les plus courants. L'inventaire consigne, pour chaque jeu de données, l'origine, l'utilisation, les dépendances, les obligations de conservation et la décision de migration.
Évaluer la qualité des données avant même de copier
Avant la copie, l'état actuel de la gestion des données est examiné : les pratiques, politiques et processus actuels de gouvernance des données sont évalués. L'objectif est d'identifier les silos de données, les doublons et les faiblesses, et de garantir la qualité des données, la sécurité, la protection des données ainsi que la conformité.
Une gestion des données insuffisante et un manque d'intégration génèrent des redondances de données inutiles et augmentent la charge administrative ; ils empêchent un développement continu de bout en bout des applications numériques. Une migration qui transfère cet état tel quel ne fait que déplacer le problème vers le nouveau système.
Des règles doivent être définies pour chaque jeu de données : champs obligatoires, formats et codages, gestion des doublons, résolution des références entre les enregistrements, ainsi que les délais de conservation et de suppression. Chaque doublon non nettoyé et chaque référence manquante migre avec les données et devra ensuite être recherché et corrigé dans le nouveau système – une tâche plus ardue, car les outils de vérification habituels et les interlocuteurs connus font défaut.
Les critères d'évaluation incluent l'exhaustivité des champs obligatoires, le taux de doublons, la validité des références et l'ancienneté des enregistrements. Si ces valeurs sont collectées avant et après le nettoyage, il est possible de prouver l'efficacité des travaux préparatoires.
Clarifier les rôles, les responsabilités et les interfaces
La migration concerne plusieurs disciplines : ingénierie des données, science des données, informatique, sécurité, protection des données, conformité, business intelligence et les unités opérationnelles qui utilisent les données au quotidien. Dans la structure de l'équipe, les rôles et les responsabilités sont définis pour chaque membre. Cela permet d'identifier les lacunes en matière de qualifications et les limitations de ressources qui pourraient entraver la migration.
Les tâches doivent être attribuées concrètement : qui crée l'inventaire des données, qui définit les règles de qualité, qui clarifie les questions liées à la protection des données, qui effectue la migration test, qui valide le résultat. Il convient également de régler quelles tâches relèvent du fournisseur SaaS et lesquelles restent en interne.
Seule l'organisation qui migre connaît généralement l'origine et la signification des données, tandis que seul le fournisseur connaît les formats d'importation et les limites du produit. Une gestion du changement accompagne les collaborateurs dans la prise en main du nouvel environnement en cours d'exploitation.
Prendre des mesures de protection des données en amont
Lorsque des données personnelles sont transférées vers le cloud, trois points doivent être vérifiés conformément aux indications de l'autorité de contrôle suisse compétente (PFPDT) : le recours à des sous-traitants et sous-sous-traitants, la sécurité du traitement des données et le transfert de données personnelles vers des pays tiers. Le fournisseur cloud agit généralement, au sens de l'art. 9 LPD, en tant que sous-traitant du client pour le traitement des données ; le client peut lui-même être responsable du traitement ou agir en tant que sous-traitant.
En tant que responsable du traitement, l'utilisateur du cloud doit s'assurer et garantir contractuellement qu'il respecte les exigences relatives au sous-traitance selon l'art. 9 LPD. En cas de communication de données à l'étranger, il convient de vérifier avant la communication si celle-ci satisfait aux exigences légales.
Selon le lieu d'exploitation ou la localisation des clients, d'autres réglementations peuvent s'appliquer – on cite notamment le RGPD, la LGPD brésilienne et le CCPA californien ; les transferts transfrontaliers de données doivent être gérés en conséquence.
La protection des données est aussi une question d'architecture : une architecture respectueuse de la vie privée permet de respecter les normes et les réglementations tout en permettant une mise à l'échelle économique. Les exigences spécifiques à chaque pays en matière de protection des données doivent être prises en compte dès le début. Cela inclut un concept d'autorisations avec une documentation vérifiable – dans le secteur de la santé, par exemple, pour les dossiers patients selon la LPD suisse et le RGPD.
Tester plutôt qu'espérer : migrations tests et portes de qualité
Avant la mise en production, deux éléments doivent être démontrés : les données précédemment stockées localement doivent être transférées intactes dans le cloud et y être protégées ; les comptes, ainsi que les droits d'accès associés, doivent être repris de manière transparente et complète.
Pour la migration test, un volume de données limité mais représentatif est choisi – incluant tous les types de données, les cas particuliers et les niveaux d'autorisation du parc de production. Après l'importation, les enregistrements sont comptés et comparés, des échantillons sont vérifiés quant à leur contenu et leur format, et les droits des comptes de test dans le nouvel environnement sont contrôlés.
Des portes de qualité définies à l'avance déterminent quand la migration est considérée comme réussie : aucun enregistrement manquant, aucune autorisation mal configurée, aucune erreur dans les champs obligatoires. En cas d'erreur, la cause est corrigée et le test est répété ; la liste des erreurs sert simultanément de modèle de travail pour l'exécution en production.
Les erreurs dans la manipulation des données sensibles et des services dans le cloud peuvent entraîner des fuites de données et des sanctions, perturber les flux de travail et engendrer des mesures d'adaptation coûteuses. Les migrations mal préparées comportent des risques en cours d'exploitation ; les migrations avec interruption minimale fonctionnent avec des portes de qualité.
Après le déménagement : assurer la qualité et la stabilité des données
Après le go-live suit la stabilisation du nouvel environnement : surveillance continue, contrôle de la sécurité et des performances, ainsi qu'optimisation des coûts. Des plans d'urgence et un service géré avec une maintenance permanente maintiennent l'exploitation en cas de perturbations.
Le contrôle a posteriori comprend la comparaison des enregistrements migrés après le déménagement, la vérification des droits d'accès en production et la mise hors service des anciens systèmes remplacés, y compris les données qui n'avaient pas besoin d'être reprises. Si la comparaison révèle des lacunes, on peut en déduire quels travaux préparatoires ont fait défaut.
La qualité des données reste une tâche continue : sans une intégration entretenue, de nouveaux silos de données et des redondances apparaissent – la même mécanique qui a été nettoyée avant la migration. Les mentions de protection des données et les directives doivent être tenues à jour afin qu'elles reflètent les activités réelles de traitement des données et les droits des personnes concernées.


