Imaginons qu’un créateur change de service. La nouvelle plateforme importe les articles mais laisse les images ; le nom du compte reste identique, mais les abonnés ne trouvent plus le profil ; la liste des favoris a été exportée, mais tous ses liens pointent vers l’ancien site. L’existence d’un export et l’intégrité de l’expérience après migration doivent être vérifiées séparément.
C’est l’intérêt de la publication ouverte : intégrer très tôt la question « que se passe-t-il lorsque l’utilisateur part ? », plutôt que de réduire l’export à un bouton dans les paramètres.
Des usages concrets de la publication ouverte émergent
En juin 2026, Bluesky a présenté des applications de blog liées à Standard.site et discuté de l’écriture et de la migration sur une base technique commune. Ce cas montre qu’un protocole peut servir différents produits de contenu, pas seulement plusieurs interfaces d’une même application. Présentation officielle de Bluesky
Un exemple dans un écosystème ne permet toutefois pas de conclure que toutes les plateformes sont interopérables. Il faut vérifier les types de données, champs supplémentaires et procédures pris en charge de chaque côté. Un vocabulaire technique commun ne remplace pas un test réel d’importation et de restauration.
Séparer continuité de l’identité et conservation du contenu
La spécification DID Core du W3C décrit les identifiants décentralisés et leurs mécanismes de contrôle. Un identifiant aide à reconnaître un même sujet, mais pouvoir encore prouver que le compte est à soi ne préserve pas automatiquement contenus historiques, copies des médias et état de l’application. W3C DID Core
Lors de la conception, poser des questions distinctes : l’utilisateur conserve-t-il la preuve de contrôle, comment découvre-t-on le nouveau service, comment les anciens liens restent-ils associés et que peut-on restaurer si l’ancien service disparaît ? Ces questions se traduisent plus facilement en fonctions qu’une promesse générale de propriété du compte.
La récupération doit aussi être compréhensible. Clés, justificatifs de récupération et assistance du fournisseur ont chacun des conditions. Décrire un scénario idéal uniquement dans la documentation développeur ne suffit pas si l’utilisateur découvre ces notions au moment de migrer.
Un export doit annoncer son périmètre
Le guide de migration AT Protocol traite séparément dépôt de données, fichiers multimédias et préférences privées, et décrit les étapes de basculement de l’identité. Il rappelle que certains états peuvent résider dans d’autres services. Même un écosystème doté d’un mécanisme explicite demande donc une vérification élément par élément. Guide de migration AT Protocol
Pour une application de contenu à sa propre marque, ce tableau aide à définir le périmètre livré :
| Catégorie | Préoccupation de l’utilisateur | Vérification proposée |
|---|---|---|
| Compte et identité | Rester identifiable après le changement | Vérifier connexion, association d’identité et découverte du nouvel emplacement |
| Articles et enregistrements | Conserver texte, dates et références | Comparer quantités, champs et contenus représentatifs |
| Images, audio et vidéo | Pouvoir réellement ouvrir les pièces jointes | Rapprocher l’inventaire et récupérer les fichiers |
| Relations | Continuer à résoudre abonnements et références | Vérifier les types de relations supportés et les identités cibles |
| Paramètres privés | Savoir ce qui manque parmi préférences, messages et états | Lister inclusions, exclusions et modes de récupération |
Il s’agit d’une proposition de conception, pas d’un format universel entre protocoles. Abonnements, recommandations et messages privés ne doivent surtout pas être déclarés « entièrement migrés » parce que certaines publications publiques sont importables.
Répéter une migration pour découvrir les dépendances cachées
Nous conseillons de créer un compte d’essai contenant texte simple, articles avec pièces jointes, références croisées et relations identifiables. Les objectifs de vérification proviennent alors d’échantillons connus, sans expérimenter sur des données réelles d’utilisateurs.
Pendant l’exercice, enregistrer les correspondances avant et après : identifiants d’origine et de destination, emplacements des pièces jointes et champs non supportés. Le nombre d’importations réussies n’est qu’un indicateur. Il faut ouvrir les contenus, lire les médias, suivre les références et vérifier que les échecs peuvent être traités individuellement.
Simuler aussi une interruption : peut-on reprendre lorsque l’export est complet mais que seule la moitié des fichiers a été envoyée ? Un second import crée-t-il des doublons ? Un réglage non supporté est-il signalé ou silencieusement supprimé ? Ces points déterminent souvent si la migration convient à de vrais utilisateurs.
Avant la fin des vérifications, conserver une copie ancienne utilisable et un chemin de retour. Le changement d’emplacement et la suppression des anciennes données doivent rester deux actions séparées. L’utilisateur doit savoir quand revenir est encore possible et quand les conséquences deviennent irréversibles.
Reconnaître les différences plutôt que les cacher
Un protocole ouvert n’impose pas des fonctions identiques. Une application peut privilégier les articles longs, une autre les messages courts ou les médiathèques. Les développeurs doivent préciser quelles capacités communes migrent, quelles fonctions particulières restent en données complémentaires et lesquelles ne peuvent être qu’archivées.
Le rapport ne devrait donc pas se limiter à « succès » ou « échec ». Séparer éléments vérifiés, éléments non supportés et interventions nécessaires permet au créateur de décider avant de découvrir la disparition d’un contenu important.
Les informations publiques d’AlphaBiz proposent une porte d’entrée pour développer des applications à sa propre marque. La portabilité peut y être évaluée comme un enjeu produit : comment le contenu et les relations accumulés gardent-ils leur valeur lorsque marque et interface changent ? Informations du projet AlphaBiz
Cet article ne présente ni AT Protocol ni Standard.site comme des intégrations existantes d’AlphaBiz. Le travail utile consiste à définir les limites de ses propres données et à les vérifier par des exercices contrôlables. Commencez par « que ne doit surtout pas perdre l’utilisateur en changeant de service ? » et partagez vos besoins dans les discussions du projet.