Migrer en gardant les décisions

Importer les affectations sans confondre deux homonymes

Pour qui : La migration reconnaît les personnes par nom d’affichage alors que plusieurs portent le même nom.

Recherche documentaire le 8 novembre 2026 ; aucune application testée.

Notre avis

Rapprocher les affectations par identifiant stable et faire valider les exceptions avant import définitif.

Dans l’ordre

  1. Le nom d’affichage ne suffit pas au rapprochement
  2. Rapprocher les affectations avec les bonnes personnes
  3. Faire valider la correspondance de quatre identités ambiguës puis rapprocher leurs tâches et réservations dans la destination.

Pourquoi

  • Une clé stable évite d’affecter le travail au mauvais homonyme ou de perdre les engagements d’un compte renommé.

Ce qui change le choix

Si la source ne possède aucun identifiant récupérable, établir une table de correspondance validée plutôt que fabriquer une équivalence.

Le nom d’affichage ne suffit pas au rapprochement

Deux personnes peuvent porter le même nom ; une personne peut aussi changer d’adresse ou de nom d’usage. Nous préparerions une table qui relie l’identité source à l’identité destination, avec validation des cas ambigus. Un rapprochement automatique doit produire des exceptions, pas choisir silencieusement le premier résultat.

Gardez séparés personne, compte et ressource planifiée. Un intervenant sans connexion peut avoir des affectations à reprendre ; un compte technique peut ne représenter aucune disponibilité humaine. Les fusionner pour réduire le nombre de lignes risque de déplacer le travail vers la mauvaise personne.

Rapprocher les affectations avec les bonnes personnes

Construisez un échantillon fictif avec deux Martin, une personne renommée et un externe sans compte destination. Importez des tâches réparties entre ces quatre identités. Pour chaque affectation, retrouvez la clé source, la clé destination et la décision prise lorsque la correspondance manque.

Nous n’accepterions pas une reprise qui annonce quatre utilisateurs créés sans pouvoir expliquer qui porte chaque engagement. Si aucun identifiant stable n’est récupérable, une table validée manuellement peut suffire pour un petit effectif. Son coût doit être connu avant la bascule.

Le schéma des tâches Asana expose un gid globalement unique et distinct du nom de la tâche.

Limites

Analyse documentaire et méthode éditoriale. Les protocoles sont proposés, pas exécutés sur les logiciels. Les exemples chiffrés sont fictifs ; les fonctions dépendent du produit, du forfait, des droits et de la configuration.

Prochaine action

Faire valider la correspondance de quatre identités ambiguës puis rapprocher leurs tâches et réservations dans la destination.

Preuves et sources

Ce qui relève d’un fait lu, d’une déclaration, de notre calcul, de notre méthode ou de notre avis. Notre méthode

  • Déclaration de l’éditeur. Le schéma des tâches Asana expose un gid globalement unique et distinct du nom de la tâche.

    Relevé du 8 novembre 2026. Édition ou périmètre : Documentation publique du 8 novembre 2026 ; produit et périmètre nommés dans le constat.

  • Notre méthode. Créer deux Martin, un compte renommé et un compte externe ; importer avec puis sans clé stable et comparer les affectations.

    Daté du 8 novembre 2026. Édition ou périmètre : Protocole éditorial proposé ; aucune observation de compte client.