Changer de logiciel au cabinet : migrer sans perdre ses données

Le nouveau logiciel peut afficher tous les noms de patients et avoir pourtant perdu l’essentiel : une pièce jointe mal rattachée, l’auteur d’une note, un historique de modification, un droit d’accès ou la possibilité de ressortir les données demain. Changer de logiciel au cabinet n’est pas un simple transfert de fichiers : c’est une migration qui doit être inventoriée, testée, rapprochée et réversible jusqu’à sa validation.

Cette méthode accompagne un cabinet d’ostéopathie depuis la décision de changer jusqu’à la fermeture de l’ancien service. Elle permet de cadrer les deux éditeurs, de sécuriser les flux, de tester un import représentatif, de décider une bascule et de constituer les preuves de recette. Elle ne suppose ni format universel ni compatibilité automatique : chaque chaîne doit être confirmée par les prestataires concernés.

Règle de prudence : ne résiliez pas l’ancien service, ne supprimez pas l’export source et ne révoquez pas les accès de retour tant que la recette finale n’est pas signée. Les essais se font d’abord sur des données fictives ; toute utilisation de données réelles exige un environnement, des accès et une procédure autorisés.

La réponse courte : une migration se valide par des preuves

Une migration est maîtrisée lorsque le cabinet peut expliquer ce qui devait passer, montrer ce qui est effectivement arrivé, justifier les transformations et revenir à la situation précédente tant que les critères ne sont pas remplis. Le nombre total de patients ne suffit pas. La preuve porte aussi sur les rendez-vous, les notes, les documents, les auteurs, les dates, les relations entre objets, les droits, les journaux et l’export futur.

Les six preuves minimales

• un inventaire daté des objets, volumes, relations et exclusions ;
• un export source documenté, protégé et accompagné de ses empreintes ;
• une table de correspondance indiquant chaque transformation ;
• un rapport de pilote avec anomalies, corrections et nouveau test ;
• un procès-verbal de recette fondé sur des contrôles quantitatifs et fonctionnels ;
• une preuve de suppression des copies temporaires et de l’ancien prestataire au moment convenu.

Les erreurs qui doivent arrêter la bascule

Une pièce jointe inaccessible, des auteurs remplacés par un compte générique, des dates réinterprétées, des doublons non expliqués, des droits trop larges ou l’impossibilité de produire un nouvel export ne sont pas de petits défauts cosmétiques. Ce sont des écarts qui compromettent l’intégrité, la confidentialité ou la maîtrise future. Ils doivent déclencher une correction ou un retour arrière, selon les seuils décidés avant l’opération.

Définir la réussite avant de choisir une date

Le projet commence par un résultat attendu, pas par une fenêtre de maintenance. Notez les raisons du changement : fin de support, incidents, manque de sécurité, fonctions absentes, coût, organisation du cabinet ou qualité insuffisante de l’export. Classez ensuite les objectifs en indispensables, importants et souhaitables. Cette hiérarchie évite de valider une belle interface alors que la traçabilité ou les documents historiques ont régressé.

Écrire des critères métier vérifiables

Formulez des critères observables : « chaque pièce jointe de l’échantillon s’ouvre depuis le bon dossier », « les rendez-vous conservent leur état et leur date », « chaque utilisateur ne voit que son périmètre », « les factures gardent leurs références », ou « un export de sortie peut être généré et relu ». Un critère comme « les données sont bien migrées » ne permet ni test reproductible ni arbitrage.

Nommer un décideur et des contrôleurs

Identifiez la personne qui autorise la bascule, celle qui contrôle les données, celle qui vérifie les habilitations et les interlocuteurs des deux éditeurs. Dans un cabinet individuel, plusieurs rôles peuvent être portés par la même personne, mais les décisions restent distinctes. Si possible, faites relire les totaux et l’échantillon par une seconde personne autorisée : l’importateur ne doit pas être le seul à déclarer son import conforme.

Distinguer le droit à la portabilité et la réversibilité du service

Deux notions proches sont souvent confondues. Le droit à la portabilité prévu par l’article 20 du RGPD appartient à la personne concernée dans certaines conditions. La fiche officielle de la CNIL destinée aux professionnels rappelle qu’il vise alors des données fournies par cette personne et traitées de manière automatisée sur la base du consentement ou d’un contrat, dans un format structuré, couramment utilisé et lisible par machine. Ce droit n’est pas, à lui seul, la procédure contractuelle permettant à un cabinet de déplacer tout son système d’un éditeur à un autre.

La réversibilité doit couvrir le besoin du cabinet

La réversibilité organise la sortie du service : périmètre restitué, formats, dictionnaire de données, pièces jointes, métadonnées, délais, assistance, coût, canal de transfert et suppression finale. Elle doit être lue dans le contrat et testée avant une situation d’urgence. Le guide sur l’export, la portabilité et la réversibilité aide à auditer ce mécanisme indépendamment du projet de migration.

Un format ouvert ne garantit pas un import complet

Un fichier CSV peut être lisible par machine et perdre les pièces jointes, les relations entre tables, les versions ou les droits. Un PDF peut être consultable mais difficile à réinjecter. Un export propriétaire peut être exhaustif tout en restant inutilisable sans documentation. Demandez donc le format, son schéma, l’encodage, les identifiants stables et les fichiers associés. La réutilisabilité se démontre par un test, pas par l’extension du fichier.

Inventorier les objets, les volumes et les relations

L’inventaire ne se limite pas à la liste des patients. Partez des usages réels : retrouver un rendez-vous, ouvrir une note, comprendre son auteur, accéder à un document, éditer une facture, appliquer un droit, rechercher un antécédent ou répondre à une demande. Pour chacun, identifiez les objets techniques nécessaires et leurs relations.

Recenser toutes les familles de données

Incluez les identités, coordonnées, rendez-vous, motifs, notes, documents, consentements, factures, règlements, modèles, questionnaires, messages, utilisateurs, rôles, journaux et paramètres. Ajoutez les référentiels locaux, champs personnalisés, statuts et listes de valeurs. Notez le nombre d’enregistrements, la plage de dates, le volume de fichiers et la proportion d’objets incomplets : ces repères serviront au rapprochement.

Repérer les relations qui peuvent casser

Une pièce jointe a besoin d’un lien vers le bon dossier. Une note peut dépendre d’un auteur, d’une date de création et d’une date de modification. Un rendez-vous peut référencer un lieu, un praticien et un état. Une facture peut dépendre d’une séquence et d’un règlement. Représentez ces liens ; sinon, l’import peut restituer le bon volume d’objets isolés et produire un système fonctionnellement faux.

Encadrer les rôles des deux éditeurs et des intermédiaires

Le cabinet décide de la finalité et reste responsable de ses choix, même lorsque les prestataires réalisent les opérations techniques. La fiche officielle de la CNIL sur la gestion de la sous-traitance demande notamment de fixer la répartition des responsabilités, les conditions de restitution et de destruction en fin de contrat, la gestion des incidents et les moyens de vérifier les garanties.

Construire une matrice de responsabilités

Pour chaque étape, inscrivez qui prépare, qui exécute, qui autorise et qui contrôle. L’ancien éditeur peut produire l’export ; un intégrateur peut le transformer ; le nouvel éditeur peut l’importer ; le cabinet doit néanmoins valider le périmètre et le résultat. Recensez aussi les sous-traitants ultérieurs, les outils de transfert, les espaces temporaires et les personnes de support susceptibles d’accéder aux données.

Vérifier les clauses de sortie avant de commencer

Le contrat devrait préciser le délai de fourniture, les formats, l’assistance, les coûts, la durée d’accès en lecture, la restitution des pièces, le traitement des sauvegardes et l’attestation de suppression. L’article 28, paragraphe 3, point g du RGPD prévoit qu’au terme des services, selon le choix du responsable de traitement, le sous-traitant supprime ou renvoie les données personnelles et détruit les copies existantes, sauf obligation légale de conservation. Traduisez cette règle dans une séquence praticable et datée.

Obtenir un export test avant la résiliation

Demandez un export suffisamment tôt pour découvrir les limites sans pression. Conservez la demande, la réponse, la version du logiciel, la date d’extraction et la documentation. Ne confondez pas un échantillon marketing préparé par l’éditeur avec une extraction représentative de votre instance.

Exiger un dictionnaire et des identifiants stables

Chaque champ doit avoir un nom, un type, une signification, un format de date, une règle pour les valeurs absentes et, si nécessaire, une table de codes. Les identifiants permettent de relier dossiers, rendez-vous, documents et utilisateurs. Si l’ancien système réutilise des identifiants ou en génère de nouveaux à chaque export, documentez une clé de rapprochement complémentaire.

Produire empreintes et comptages

Calculez une empreinte cryptographique des archives avant et après le transfert pour détecter une modification du fichier. Ajoutez des comptages indépendants : nombre d’objets par famille, volume total, nombre de pièces jointes, dates minimale et maximale, répartition par statut. L’empreinte prouve que le paquet reçu est identique au paquet envoyé ; elle ne prouve pas que son contenu était complet. Les deux contrôles sont complémentaires.

Sécuriser les flux et les espaces temporaires

Une migration multiplie temporairement les copies : export source, archive chiffrée, espace de transformation, import de test, sauvegarde de retour et rapports. Chaque copie augmente l’exposition si elle reste oubliée ou accessible à trop de comptes. Dessinez le trajet et attribuez à chaque étape un emplacement, une durée, un propriétaire et une méthode de suppression.

Chiffrer le transfert et séparer le secret

Utilisez un canal contractualisé et protégé, avec authentification adaptée. Lorsque l’archive est chiffrée séparément, transmettez le secret par un autre canal et limitez sa durée d’usage. La CNIL recommande, dans sa fiche sur les échanges avec d’autres organismes, de recourir à des protocoles garantissant confidentialité, authentification et intégrité. Évitez l’e-mail ordinaire, la clé USB personnelle et le stockage grand public non prévu au contrat.

Vérifier le périmètre HDS sans extrapoler

Pour un cabinet exercé exclusivement par un ostéopathe, ne déduisez pas l’application du régime HDS du seul caractère « santé » des données ou du nom du logiciel. Les articles L. 1111-8 et R. 1111-8-8 du code de la santé publique visent l’hébergement par un tiers de données de santé à caractère personnel recueillies à l’occasion d’activités de prévention, de diagnostic, de soins ou de suivi social et médico-social, pour le compte de la personne à l’origine de leur production ou recueil, ou du patient. Il faut donc qualifier le montage réel : nature des données, contexte de leur recueil, tiers qui les héberge, personne pour le compte de laquelle il agit et opérations assurées pendant la migration.

Si cette qualification place tout ou partie de la chaîne dans le champ, contrôlez le certificat, son titulaire, sa validité et les activités effectivement couvertes sur la documentation officielle de l’Agence du Numérique en Santé. L’exception réglementaire concernant certaines opérations de saisie, mise en forme, matérialisation ou dématérialisation confiées pour une courte période doit être analysée strictement ; elle ne permet pas de déclarer toute migration hors HDS. En cas de montage ambigu, faites confirmer la qualification par les prestataires et le conseil compétent. Le sigle HDS ne démontre ni la réussite de l’import, ni la conformité globale du traitement, ni la suppression des copies temporaires.

Construire la table de correspondance et tracer les transformations

La table de correspondance relie chaque donnée source à sa destination. Elle indique le champ cible, la conversion appliquée, la valeur par défaut, les pertes acceptées et le contrôle prévu. Elle devient la pièce centrale du projet : elle permet de comprendre une anomalie, de rejouer l’import et d’expliquer pourquoi une information apparaît différemment.

Rendre explicites les transformations

Un statut « absent excusé » peut ne pas exister dans la cible ; une date peut passer d’un fuseau à un autre ; un champ libre peut devenir une liste ; deux valeurs peuvent être fusionnées. Ne masquez pas ces décisions dans un script. Définissez la règle, l’auteur de la décision, la population touchée et le moyen de contrôle. Si une information ne peut pas être importée, prévoyez son archivage accessible et sa durée selon le besoin documenté.

Ne pas réparer silencieusement la source

La migration révèle souvent des doublons, des champs incohérents ou des documents orphelins. Corriger peut être utile, mais une transformation silencieuse rend le rapprochement impossible. Séparez les anomalies préexistantes des erreurs créées par la migration. Conservez un journal des corrections avec l’objet, l’ancienne valeur, la nouvelle valeur, la règle et la date.

Tester un pilote représentatif avant l’import final

Commencez avec des données fictives construites pour solliciter les cas difficiles : accents, apostrophes, homonymes, champs vides, longues notes, documents de formats différents, rendez-vous annulés, plusieurs lieux, plusieurs praticiens et comptes retirés. Ce jeu permet d’éprouver la méthode sans exposer la production.

Choisir ensuite un échantillon autorisé et utile

Si un test sur des données réelles est nécessaire, limitez-le à un environnement sécurisé et à un échantillon justifié, avec les mêmes garanties que le traitement principal. Cherchez la diversité plutôt que le volume : dossiers anciens et récents, avec et sans pièces, différents auteurs, cas de doublons connus, factures, rendez-vous et droits variés. Documentez la sélection pour pouvoir reproduire le contrôle.

Tester déjà la sortie du nouveau logiciel

Un import réussi peut créer un nouvel enfermement. Depuis la cible, exportez le pilote et vérifiez que les données restent structurées, reliées et compréhensibles. Comparez ce résultat aux engagements étudiés lors du choix du logiciel de cabinet. Cette épreuve ne garantit pas toutes les migrations futures, mais détecte tôt une réversibilité seulement déclarative.

Préparer la bascule, le gel et le retour arrière

Choisissez une période compatible avec l’activité, les disponibilités des prestataires et le temps réel des contrôles. Un week-end n’est pas automatiquement une bonne fenêtre si personne ne peut corriger un échec. Écrivez un déroulé minuté, les coordonnées d’escalade et l’heure limite à laquelle le retour arrière devient la décision la plus sûre.

Maîtriser le gel des modifications

Définissez l’instant à partir duquel l’ancien système n’accepte plus de modification, ou la manière de journaliser les nouvelles saisies à réconcilier. Informez uniquement les personnes concernées, sans diffuser de données inutiles. Préparez un mode dégradé sobre pour les rendez-vous et informations indispensables, puis une procédure de ressaisie contrôlée.

Conserver une source de retour vérifiée

Avant la bascule, produisez une sauvegarde ou un export final dont la restauration ou la lecture a été testée selon la méthode du guide sur les sauvegardes du cabinet. Conservez les versions applicatives, clés et dépendances nécessaires. Un fichier présent ne suffit pas si l’ancien service fermé est le seul outil capable de l’ouvrir.

Décider les seuils d’arrêt à l’avance

Listez les anomalies bloquantes et les seuils tolérables : pièce clinique manquante, relation fausse, total financier incohérent, droit excessif, journal absent, délai dépassé ou fonction critique indisponible. Un écart mineur peut faire l’objet d’un plan de correction ; un écart qui affecte la sécurité ou l’intégrité doit suspendre la mise en service. L’arbitrage est plus solide lorsqu’il ne dépend pas de la fatigue du soir de bascule.

Recetter par rapprochement, échantillon et scénario

La recette combine trois angles. Le rapprochement quantitatif détecte les volumes inattendus. L’échantillon qualitatif examine les objets et leurs relations. Les scénarios fonctionnels vérifient que le cabinet peut réellement travailler et contrôler les accès. Aucun angle ne remplace les deux autres.

Contrôler les volumes et les distributions

Comparez les totaux par famille, les périodes, les statuts et les volumes de pièces. Expliquez chaque différence : exclusion décidée, doublon corrigé, objet technique non repris ou erreur. Une égalité parfaite n’est pas toujours attendue, mais toute différence doit être attribuable. Gardez les requêtes ou rapports utilisés afin de pouvoir rejouer la comparaison.

Ouvrir, rechercher, modifier et ressortir

Testez la recherche de plusieurs patients, l’ouverture de documents, l’affichage des auteurs et dates, la création contrôlée d’un rendez-vous, la génération d’un document, l’impression ou l’export nécessaire, puis la suppression du jeu de test. Vérifiez les caractères accentués, les fuseaux, les montants et les formats. La recette doit porter sur l’interface utilisée, pas seulement sur la base technique.

Rejouer les profils et les journaux

Testez chaque profil selon la méthode des cinq contrôles d’habilitation : accès attendu, refus attendu, modification, export et traçabilité. Un ancien compte retiré ne doit pas renaître ; un remplaçant ne doit pas hériter du profil du titulaire ; le compte de migration ne doit pas conserver un accès permanent. Vérifiez que les opérations sensibles apparaissent dans les journaux prévus.

Signer un procès-verbal lisible

Élément	Ce que le procès-verbal doit montrer
Périmètre	Objets inclus, exclusions, versions et période
Résultats	Totaux source et cible, échantillon, scénarios et droits
Écarts	Gravité, population touchée, décision et responsable
Retour arrière	Disponibilité, heure limite et conditions d’activation
Décision	Acceptation, acceptation conditionnelle ou rejet motivé
Signatures	Contrôleurs, décideur, date et pièces de preuve

Surveiller les premiers jours sans diluer la recette

La mise en service ne ferme pas immédiatement le projet. Définissez une période de surveillance avec un canal unique pour les anomalies, une classification de gravité et un délai de réponse. Suivez les recherches infructueuses, documents illisibles, écarts de droits, doublons, lenteurs et problèmes d’intégration.

Rapprocher les données du mode dégradé

Les rendez-vous, notes ou paiements enregistrés pendant le gel doivent être ressaisis ou importés selon une liste contrôlée. Faites relire le rapprochement et marquez chaque élément comme traité. Ne laissez pas une feuille temporaire devenir une base parallèle durable ; elle contient potentiellement des données sensibles et doit suivre sa procédure de suppression.

Traiter un incident comme un incident

Si une donnée est perdue, altérée, divulguée ou rendue indisponible, ne réduisez pas le problème à un ticket de support. Appliquez la procédure de réaction à un incident de données, conservez les faits et analysez les obligations applicables. Un retour arrière peut restaurer le service sans effacer la nécessité de documenter ce qui s’est produit.

Fermer l’ancien service et supprimer les copies au bon moment

La fermeture intervient après recette, surveillance suffisante, export final et confirmation que les preuves restent accessibles. Décidez si une période de lecture seule est nécessaire et proportionnée. Elle ne doit pas devenir une conservation indéfinie par prudence vague.

Obtenir la suppression et son attestation

Envoyez l’instruction conforme au contrat, avec le périmètre et la date. Demandez ce qui est supprimé dans la base active, les espaces de travail, les archives et les sauvegardes, ainsi que le calendrier technique lorsque la purge n’est pas immédiate. Conservez l’attestation, sans exiger qu’elle révèle des secrets de sécurité. La suppression doit aussi couvrir les éventuels sous-traitants ultérieurs selon les engagements applicables.

Fermer toutes les copies temporaires

Révoquez les comptes de migration, liens de partage, clés, sessions, accès de support et connecteurs. Supprimez les exports des postes, dossiers de transfert et environnements de test selon la procédure. Conservez seulement les preuves nécessaires : empreintes, comptages, table de correspondance, journaux de décision et attestation. Un export brut n’est pas une preuve à garder indéfiniment.

Plan d’action sur trente jours

Semaine 1 : cadrer et obtenir un export

1. Écrire les objectifs, critères de réussite, seuils d’arrêt et rôles.
2. Rassembler les contrats, certificats, conditions de sortie et interlocuteurs.
3. Inventorier objets, volumes, relations, droits, dépendances et exclusions.
4. Demander un export test, son dictionnaire et les conditions d’assistance.

Semaine 2 : cartographier et tester

1. Dessiner les flux, espaces temporaires, accès et dates de purge.
2. Construire la table de correspondance et le journal de transformation.
3. Tester un jeu fictif couvrant les cas limites.
4. Corriger la méthode avant toute utilisation autorisée de données réelles.

Semaine 3 : piloter et préparer la décision

1. Importer un échantillon représentatif dans l’environnement sécurisé.
2. Rapprocher totaux, relations, pièces, dates, droits et journaux.
3. Tester l’export depuis la cible et documenter les écarts.
4. Écrire le déroulé de bascule, le mode dégradé et le retour arrière.

Semaine 4 : basculer, surveiller et fermer

1. Produire l’export final et la sauvegarde de retour vérifiée.
2. Exécuter l’import, la recette et la décision selon les critères écrits.
3. Rapprocher les saisies du gel et surveiller les anomalies.
4. Après validation, révoquer les accès et obtenir les preuves de suppression.

Checklist avant de déclarer la migration terminée

• [ ] Les objectifs et les fonctions indispensables sont classés.
• [ ] Un décideur, des contrôleurs et les interlocuteurs des éditeurs sont nommés.
• [ ] Les objets, volumes, relations, droits et dépendances sont inventoriés.
• [ ] Les exclusions sont écrites et justifiées.
• [ ] Les clauses de restitution, assistance, coût et suppression sont vérifiées.
• [ ] Les sous-traitants, lieux et outils temporaires sont connus.
• [ ] Le périmètre des certificats HDS est contrôlé lorsque nécessaire.
• [ ] Un export test et son dictionnaire ont été obtenus avant résiliation.
• [ ] Les empreintes et comptages source sont conservés.
• [ ] La table de correspondance décrit chaque transformation.
• [ ] Les anomalies préexistantes sont séparées des erreurs de migration.
• [ ] Les transferts et espaces de travail sont protégés et journalisés.
• [ ] Un jeu fictif a éprouvé les cas difficiles.
• [ ] Un pilote représentatif autorisé a été rapproché.
• [ ] L’export depuis le nouveau logiciel a été testé.
• [ ] Le gel, le mode dégradé et la réconciliation sont documentés.
• [ ] Une sauvegarde ou source de retour exploitable est disponible.
• [ ] Les seuils d’arrêt et l’heure limite de retour sont écrits.
• [ ] Les totaux, pièces, liens, auteurs, dates et droits sont contrôlés.
• [ ] Le procès-verbal mentionne aussi les écarts et conditions.
• [ ] Les comptes de migration et accès de support sont révoqués.
• [ ] Les copies temporaires ont un propriétaire et une preuve de purge.
• [ ] L’ancien prestataire a reçu l’instruction de restitution ou suppression prévue.
• [ ] L’attestation de suppression et les preuves de recette sont archivées.

Une migration réussie n’est donc pas celle qui se termine le plus vite, mais celle dont le cabinet maîtrise le périmètre, les transformations, la décision et la sortie suivante. Tant que le rapprochement n’est pas expliqué et signé, le retour arrière n’est pas un aveu d’échec : c’est une mesure de sécurité prévue.

Limites et suivi éditorial

Cette méthode ne remplace ni les instructions techniques des éditeurs, ni une analyse de risques, ni un conseil juridique adapté au contrat. Les formats, fonctions, volumes et obligations de conservation varient. Aucune manipulation ne doit être improvisée sur la production ; une migration complexe ou litigieuse peut nécessiter un intégrateur, un professionnel de la sécurité ou un conseil spécialisé.

Sources contrôlées le : 29 août 2026. Prochaine revue prévue : 29 novembre 2026, ou plus tôt en cas d’évolution du référentiel HDS, des recommandations CNIL ou du service utilisé.

Sources primaires

• CNIL — Sécurité : gérer la sous-traitance.
• CNIL — Sécurité : sécuriser les échanges avec d’autres organismes.
• CNIL — Professionnels : répondre à une demande de portabilité.
• Union européenne — Règlement général sur la protection des données, articles 20 et 28.
• Légifrance — Code de la santé publique, article L. 1111-8.
• Légifrance — Code de la santé publique, article R. 1111-8-8.
• Agence du Numérique en Santé — Certification HDS et champ d’application.

À lire ensuite

• Vérifier l’export, la portabilité et la réversibilité du logiciel
• Choisir un logiciel de cabinet sur des preuves
• Tester la restauration des sauvegardes du cabinet
• Contrôler les droits d’accès après la migration
• Reprendre la checklist RGPD du cabinet