Migration transparente de l'origine des PWA : changez de domaine sans perdre d'utilisateurs

Dibyajyoti Pal

Dan Murphy

Marijn Kruisselbrink

Publié le : 3 juin 2026

Les progressive web apps (PWA) ont révolutionné le Web en offrant des expériences semblables à celles des applications. Toutefois, l'un de leurs plus grands atouts a également été un défi persistant : l'identité de l'application est étroitement liée à l'origine Web.

Pour changer de marque ou restructurer votre architecture (par exemple, en passant de www.example.com/social à social.example.com), vous étiez confronté à un dilemme douloureux. Il n'était pas possible de "déplacer" une PWA installée. Les utilisateurs devaient désinstaller manuellement l'ancienne application et trouver le bouton d'installation de la nouvelle.

L'équipe PWA est heureuse de vous présenter la migration d'origine des PWA dans Chrome 150. Cette nouvelle fonctionnalité de plate-forme vous permet de migrer facilement les PWA installées vers une nouvelle origine de même site avec un minimum d'interruption pour l'utilisateur, tout en le tenant suffisamment informé.

Ce que permet la migration d'origine

Vous pouvez modifier l'architecture de votre site sans nuire à l'expérience utilisateur :

• Liberté d'architecture technique : modifiez le sous-domaine ou le chemin d'accès de votre application.
• Correction des états d'écran partagé : résolution du problème qui entraînait la création accidentelle d'installations d'applications en double lors de la modification d'un start_url sans ID stable.

Les utilisateurs peuvent migrer leurs applications à l'aide d'une simple boîte de dialogue de mise à jour. Ils sont informés de la migration de la même manière que pour une mise à jour standard de l'application. En un seul clic, l'ancienne application est désinstallée, et la nouvelle est installée et lancée.

Migrer une PWA

Pour migrer une PWA, procédez comme suit. Le reste de l'article fournit plus de détails :

1. Déployez le handshake :
   • Ajoutez migrate_from à la nouvelle application.
   • Ajoutez le champ allow_migration au fichier /.well-known/web-app-origin-association de l'ancienne origine.
2. Choisissez le comportement : suggest (ou vide) évite d'interrompre l'utilisateur, ce qui peut être utile lors d'un déploiement initial. force bloque l'utilisateur et exige la migration si l'utilisateur ne peut pas continuer à utiliser les anciennes URL.
3. Maintenez l'ancienne application à jour : si l'ancien site redirige vers le nouveau, utilisez la propriété install_url dans le bloc migrate_from pour vous assurer que le navigateur peut toujours trouver l'ancien fichier manifeste pour d'éventuelles mises à jour.
4. Implémentez id dans le fichier manifeste de destination : Chrome exige que le fichier manifeste de l'application de destination inclue un champ id. Cela garantit que l'application ne commet pas l'erreur courante de créer des applications fractionnées en modifiant start_url sans avoir défini id.

Connexion bidirectionnelle : fonctionnement

Pour garantir la sécurité et éviter les prises de contrôle hostiles, la migration nécessite une prise de contact sécurisée entre les anciennes et les nouvelles origines. Ce handshake garantit que les deux sites sont contrôlés par la même entité.

Étape 1 : La nouvelle application déclare l'application précédente (obligatoire)

Ajoutez un champ migrate_from au fichier manifeste d'application Web de la nouvelle application.

// Manifest at https://fileman.google.com/manifest.json
{
  "name": "File Manager",
  "id": "/files/",
  "start_url": "/files/index.html",
  ....
  "migrate_from": [
    "https://drive.google.com/"
  ]
}

Étape 2 : L'ancienne origine confirme la migration (obligatoire)

Pour empêcher un nouveau site de détourner unilatéralement une ancienne application, l'ancienne origine doit autoriser explicitement la migration. Pour ce faire, il utilise un fichier de configuration .well-known.

// File at https://drive.google.com/.well-known/web-app-origin-association
{
  "https://fileman.google.com/files/": {
    "allow_migration": true
  }
}

Étape 3 : Signalisation proactive (facultatif)

Pour déclencher la mise à jour sans attendre que l'utilisateur accède au nouveau site, mettez à jour le fichier manifeste de l'ancienne application pour qu'il pointe vers le nouveau.

// Manifest at https://drive.google.com/manifest.json
{
  "name": "Drive",
  "start_url": "/",
  "migrate_to": {
    "id": "https://fileman.google.com/files/",
    "install_url": "https://fileman.google.com/drive/installwebapp?usp=migrate"
  }
}

Étape 4 : Gérez les redirections (facultatif)

Au lieu d'utiliser le champ migrate_to, vous pouvez signaler la migration en redirigeant les anciennes URL de l'application vers la nouvelle application et en vous appuyant sur scope_extensions pour que la bannière "Hors champ" ne s'affiche pas dans l'ancienne application. Cela signifie que le fichier manifeste de l'ancienne application ne sera jamais vu et ne pourra donc jamais être mis à jour. Pour permettre à l'ancienne application de continuer à se mettre à jour avant la migration de l'application, définissez install_url dans migrate_from pour informer le navigateur d'une URL à récupérer qui comporte toujours l'ancien fichier manifeste sans redirection.

// Manifest at https://fileman.google.com/manifest.json
{
  "name": "File Manager",
  "id": "/files/",
  "start_url": "/files/index.html",
  ....
  "migrate_from": [
    {
      "id": "https://drive.google.com/",
      "install_url": "https://drive.google.com/drive/installwebapp?usp=migrate"
    }
  ]
}

Et voilà ! L'UX est semblable à celle utilisée pour la mise à jour des applications, où l'utilisateur est averti en haut à droite de la fenêtre de l'application :

Si vous cliquez sur Examiner la mise à jour d'application, l'interface utilisateur suivante s'affiche (selon les modifications apportées au fichier manifeste) :

Contrôler l'expérience utilisateur

Vous pouvez choisir le degré d'agressivité de la migration à l'aide de l'indicateur behavior :

1. Suggérer (par défaut) : l'utilisateur reçoit une notification passive (par exemple, dans le menu de l'application). Il peut choisir de mettre à jour ou de désinstaller son application, ou d'ignorer la migration en lançant la boîte de dialogue.
2. Forcée : au prochain lancement de l'application, l'utilisateur voit une boîte de dialogue bloquante. Il doit soit passer à la nouvelle origine, soit désinstaller l'application (voir la capture d'écran ci-dessous).

L'exemple suivant montre comment définir ce choix :

"migrate_from": [
  { 
    "id": "https://example.com/social/",
    "behavior": "force" // or suggest
  }
]

Conclusion

La fonctionnalité de migration des PWA permet aux développeurs de continuer à créer des architectures Web modernes et flexibles sans laisser les utilisateurs de côté.