Le changement local qui justifie la migration

L’Insee indique la création de Valgelon-La Rochette le 1er janvier 2019, à la place d’Étable et de La Rochette devenues communes déléguées. La commune actuelle porte le code 73215 ; Étable conserve le code 73111 en tant que commune déléguée. Le dossier Insee décrit aussi La Rochette avec le code 73215 avant cette création. Cet exemple demande donc d’examiner le nom, le type de commune et la date du référentiel : une comparaison du seul code ne suffit pas à raconter correctement le changement.

Séparer la valeur importée de la valeur de recherche

Conservez le nom et le code présents dans le fichier d’origine, avec la date de l’import. Ajoutez séparément la commune actuelle proposée, sa source et la date de vérification. Le dossier peut ainsi être retrouvé en recherchant le nom actuel tout en montrant ce qui avait été saisi auparavant. Une adresse de chantier mérite son propre identifiant ; elle ne doit pas être déduite uniquement de la commune du contact. Les anciennes valeurs restent consultables pour comprendre les échanges, y compris lorsqu’elles étaient incomplètes.

Construire une correspondance contrôlée

Commencez par un export de travail et une table de correspondance qui précise la source, le code d’origine, son contexte et la destination proposée. Présentez les modifications avant de les appliquer. Une ligne limitée à « La Rochette » sans département ni autre indice ne doit pas être rattachée automatiquement au cas savoyard. Les lignes identifiées peuvent recevoir une commune actuelle de recherche ; les autres rejoignent une liste à vérifier. Un changement de commune ne prouve jamais que deux entreprises ou deux adresses désignent le même client.

Préserver les dossiers existants et organiser le retour arrière

Attribuez un identifiant à l’opération de migration et enregistrez les valeurs avant et après pour chaque fiche modifiée. Les devis envoyés, comptes rendus et autres documents déjà figés restent associés à leur version d’origine : l’affichage d’une commune actuelle dans la fiche ne doit pas les régénérer automatiquement. Préparez une restauration limitée aux champs de référentiel concernés. Une seconde exécution du même import doit reconnaître les modifications déjà traitées et produire le même état, sans nouvelles fiches ni nouvelle réécriture.

Recette : rechercher aujourd’hui, comprendre hier

Créez un petit fichier fictif avec un chantier ancien à Étable, un dossier récent à Valgelon-La Rochette, une ligne « La Rochette » sans département et deux clients distincts à la même adresse. Après migration, la recherche par commune actuelle doit retrouver les dossiers reconnus. Le lieu d’origine du chantier ancien doit rester visible, la ligne ambiguë doit attendre une décision et les deux clients doivent rester distincts. Comparez les documents avant et après, rejouez l’import, puis testez la restauration des seuls champs géographiques.

À préparer pour votre projet

  • Export de travail conservant les identifiants et les valeurs d’origine
  • Table de correspondance sourcée et datée
  • Liste des lieux ambigus à vérifier manuellement
  • Historique des champs modifiés et procédure de restauration
  • Contrôle des documents figés et du second passage de l’import

Le périmètre à confirmer

La correspondance décrite concerne un changement administratif vérifié ; elle ne permet pas de déduire l’identité d’un client à partir de sa seule commune. Toute migration dépend de la qualité des données disponibles et doit être testée sur une copie avant d’être appliquée aux dossiers réels.

Le devis précise les outils, les accès, le calendrier et les éventuels coûts de licences ou de consommation. Aucun gain chiffré n’est annoncé sans mesure.