Résumé

  • Les identifiants Sign in with Apple sont propres à chaque équipe de développement. L’acquéreur doit relier ses nouveaux identifiants aux comptes existants au moyen d’identifiants de transfert.
  • Après soixante jours, la remise en marche du dispositif de migration passe par un retour de l’app à l’équipe d’origine, puis un nouveau transfert. La disponibilité du vendeur fait partie de la livraison.

Dans une acquisition bien présentée, chacun sait quand poser pour la photo. On sait parfois moins bien quand les anciens utilisateurs auront réellement rejoint le nouvel exploitant. Avec Sign in with Apple, cette seconde date peut rappeler brutalement la première : si l’équipe manque la période de migration, Apple lui demande de renvoyer l’app à son propriétaire précédent, puis de la reprendre.

La note technique TN3159 décrit cet aller-retour sans détour. L’équipe B rend l’app à A. A prépare correctement les données et les identifiants de transfert. A transfère de nouveau l’app à B, qui réalise les échanges nécessaires. Voilà une acquisition dont le service après-vente a besoin du vendeur dans un rôle très actif.

Un produit continu, deux fichiers d’identité

Apple sait préserver une partie précieuse de ce qui a été acheté. Son guide App Store Connect indique qu’une app admissible au transfert peut rester disponible au téléchargement, conserver ses notes, ses avis et son Bundle ID. Les utilisateurs continuent à recevoir des mises à jour. La vitrine survit au changement de propriétaire.

Le service d’authentification suit une autre logique. Il attribue des identifiants propres à l’équipe de développement. Ce cloisonnement sert la confidentialité : deux développeurs ne reçoivent pas simplement le même numéro universel leur permettant de rapprocher les activités d’une personne.

Lors de la vente, le compte déjà présent dans la base du vendeur doit donc être associé à l’identité que reconnaîtra l’équipe acheteuse. Une ancienne cliente revient, utilise son bouton habituel et s’attend à retrouver son compte. Toute la délicatesse commerciale tient dans cette attente banale. Le fichier vendu contient une relation ; la nouvelle connexion doit retrouver la bonne ligne.

Le guide destiné à l’équipe cédante organise le passage. Elle produit, pour chaque utilisateur, un identifiant de transfert destiné à l’équipe bénéficiaire. Les anciens identifiants d’équipe et les adresses privées de relais électronique sont exclus de l’export. Le destinataire utilise l’identifiant de transfert pour obtenir son propre identifiant d’utilisateur et, lorsque cela s’applique, l’adresse privée correspondante.

La séparation protège donc toujours les personnes. Une passerelle encadrée permet à l’activité de changer de mains. Il reste à faire traverser les comptes, un travail moins photogénique que la signature.

Le délai ne récompense pas les retardataires

Les soixante jours courent à partir du transfert achevé. Le cédant peut préparer les identifiants avant l’opération ou les générer dans les soixante jours suivant son acceptation. L’acquéreur doit également les échanger dans les soixante jours suivant cette acceptation. Le fichier envoyé tard ne contient pas une rallonge offerte au destinataire.

Cette horloge commune donne une conséquence immédiate à l’ordre des tâches. Préparer, transmettre, échanger et rattacher les nouveaux identifiants aux comptes existants sont des opérations successives. Un vendeur qui coche « envoyé » n’a pas prouvé que l’acheteur peut cocher « terminé ».

Le guide de l’équipe destinataire explique comment les informations de connexion pendant la période peuvent servir au rapprochement. Mais attendre le retour de chaque utilisateur revient à faire dépendre une livraison technique de ses vacances, de ses habitudes ou de son prochain besoin du produit.

Apple permet une migration par lots côté serveur. Les comptes de ceux qui ne se reconnectent pas peuvent donc être traités. Une cliente occasionnelle n’a pas à accélérer sa vie pour sauver le calendrier de l’acquéreur. Le choix d’attendre les connexions, alors qu’un traitement par lots existe, appartient à l’équipe qui réalise la reprise.

La coopération a une date de péremption commerciale

Au-delà de la période, la procédure de récupération réactive les fonctions de migration par le double transfert. Elle mobilise de nouveau les deux organisations. Dans App Store Connect, les Account Holders respectifs doivent engager et accepter les transferts. La bonne volonté d’un ingénieur isolé ne remplace pas ces pouvoirs.

Avant la vente, les deux camps veulent conclure. Après, le vendeur peut avoir réaffecté ses équipes ou lancé un nouveau produit. L’acheteur possède l’app, mais l’opération à reprendre exige encore du temps, des droits d’accès et des actes du côté de l’ancien propriétaire. Une ligne oubliée dans la passation devient une négociation de disponibilité.

Il manque les journaux de migration d’une acquisition précise, ses comptes non raccordés et ses heures de reprise pour chiffrer cette facture. La structure du problème, elle, apparaît déjà : la maîtrise de l’actif acheté ne concentre pas tous les gestes nécessaires à sa continuité.

Un acheteur peut prévoir la préparation avant transfert, la validation des rapprochements après réception et une assistance de récupération qui ne s’évapore pas au paiement. Il rémunère alors un passage effectivement réalisé, plutôt qu’une poignée de main suivie d’une boîte mail silencieuse.

Les avis resteront peut-être impeccablement alignés dans la boutique. Les utilisateurs, eux, ne sont pas des étoiles que l’on déplace avec la fiche produit.