Résumé

  • RFC 9518 est une contribution indépendante et informative, non une norme IETF consensuelle ni un constat de marché.
  • Une sortie crédible exige un état exportable, une alternative accessible, la continuité de l'identité, l'interopérabilité entre fournisseurs et une perte maîtrisée des effets de réseau.
  • Une architecture fédérée ou une étiquette « standard ouvert » décrit une possibilité technique ; elle ne prouve ni la diversité des mises en œuvre ni le pouvoir de négociation de l'utilisateur.

Le plan n'est pas le passage

Un schéma d'architecture peut montrer plusieurs opérateurs reliés par le même protocole. L'utilisateur, lui, peut rester captif. Ses paramètres n'entrent pas tous dans l'export, le fournisseur d'arrivée ne reprend pas la fonction essentielle, les contacts demeurent sur l'ancien réseau ou l'identité qui porte la réputation ne peut pas suivre.

RFC 9518, publié en décembre 2023, fournit le bon cadre de prudence. Le texte de Mark Nottingham relève de l'Independent Submission et de la catégorie Informational. Il n'est pas sur la Standards Track et ne représente pas le consensus de l'IETF. Sa valeur est de borner ce que la normalisation peut raisonnablement accomplir.

Le document sépare le point de défaillance technique de la concentration du pouvoir. Une plateforme peut répartir ses machines sur plusieurs régions tout en gardant le contrôle économique, contractuel et informationnel dans une seule main. À l'inverse, certaines fonctions communes peuvent être utiles si leur mandat reste étroit, vérifiable et contestable.

Cinq preuves pour une sortie

La première est l'état exportable. Les octets ne suffisent pas. Il faut transporter les données, les réglages, les droits, l'historique, les liens, les preuves et la version sémantique qui permet au destinataire de reconstruire le service. Un fichier complet mais incompréhensible est une archive, pas un instrument de migration.

La deuxième est la découverte d'un substitut. RFC 9518 rappelle qu'il faut des solutions de rechange et donc une véritable diversité d'implémentations et de déploiements. Plusieurs marques reposant sur le même moteur ne constituent pas nécessairement des choix indépendants. La destination doit exister, être maintenue et pouvoir accepter l'état concerné.

La troisième est la continuité de l'identité et des contacts. La valeur réside souvent dans la manière dont les autres reconnaissent l'utilisateur : identifiant, adresse, credentials, réputation, carnet de relations. Si partir signifie redevenir inconnu, l'export technique peut réussir et l'exit économique échouer.

La quatrième est l'interopérabilité pendant et après la migration. Les utilisateurs de l'ancien et du nouveau fournisseur doivent parfois communiquer pendant des mois. Les messages doivent conserver leur sens et les ponts leurs limites de sécurité. Une fédération crée cette possibilité ; elle ne force ni l'adoption ni le comportement loyal des grands nœuds.

La cinquième est la perte d'effets de réseau. Emporter toutes ses données ne sert guère si l'audience, les fournisseurs, les collaborateurs ou la liquidité restent ailleurs. C'est ici que la norme rencontre sa limite la plus nette : elle peut réduire le coût de conversion, mais elle ne fabrique pas une communauté à destination et n'efface pas l'avantage de distribution de l'opérateur dominant.

Ces cinq dimensions doivent produire un reçu : ce qui a été transféré, refusé ou perdu ; le temps, l'expertise et la coordination nécessaires ; la possibilité de revenir ; le résultat observé après le basculement.

Trop précise, trop mince : la même dépendance par deux chemins

RFC 9518 décrit une tension. Une spécification doit être assez complète pour rendre les produits substituables. Si elle devient trop complexe, seuls les acteurs les mieux dotés peuvent l'implémenter. Si elle reste trop mince, les fonctions indispensables passent dans des extensions propriétaires. Dans les deux cas, la conformité nominale peut coexister avec l'impossibilité de changer.

RFC 5218 rappelle qu'un protocole réussit par le déploiement, pas par la publication seule. Les preuves utiles sont donc les implémentations indépendantes, les importations réussies, les tests reproductibles et les changements effectivement menés.

La Minimum Initial Specification de Lu Heng propose une limite complémentaire : le socle commun ne doit contenir que les invariants vérifiables nécessaires à l'interopérabilité et à la sûreté ; ses artefacts doivent rester portables, auditables, reproductibles et remplaçables. Un socle mince réduit la surface de pouvoir, sans garantir la dispersion du marché construit au-dessus.

Le droit ne voyage pas dans le format

Une norme technique est généralement volontaire. RFC 9518 observe que la loi peut imposer une interopérabilité que la publication ne suffit pas à obtenir, et cite notamment le Digital Markets Act. Mais un format ne crée pas, à lui seul, un délai d'accès, une interdiction de représailles, un partage des coûts ni un recours contre un export incomplet.

L'inverse est vrai : une obligation juridique mal conçue peut figer une interface fragile ou imposer un accès dangereux. Il faut combiner un point de bascule techniquement cohérent, des implémentations indépendantes, des obligations exécutoires et la preuve que l'utilisateur ordinaire peut réellement s'en servir.

Une rubrique « Centralization Considerations », un diagramme fédéré ou un badge de standardisation peut améliorer le débat. Aucun ne démontre qu'une destination existe, que la valeur suit ou que la coopération peut être obtenue.

Sources et limites

L'analyse repose sur RFC 9518, RFC 5218, la note de Lu Heng et le règlement (UE) 2022/1925. Elle ne mesure ni parts de marché, ni taux de migration, ni conformité d'un service nommé. Le test en cinq dimensions est une synthèse éditoriale : le réussir prouve de meilleures conditions de sortie, pas un marché déjà décentralisé.