Data Transfer Project : la promesse de l’open source pour la portabilité des données

La communication s’accentue autour du Data Transfer Project.

Facebook, Google, Microsoft et Twitter sont à l’origine de cette initiative open source destinée à favoriser la portabilité des données.

L’objectif est d’établir un framework commun qui permette des transferts directs entre plates-formes, sans consommer de ressources côté utilisateur.

La démarche vise plutôt les services BtoC. Rien n’empêche techniquement de l’appliquer aux services fournis aux professionnels, mais les questions de portabilité sont généralement régies par les contrats commerciaux.

L’aspect sécurité est omniprésent dans le livre blanc du projet (PDF, 25 pages). Parmi les principes définis en la matière figurent le chiffrement de bout en bout, la révocation des jetons d’accès une fois les transferts effectués ou encore la limitation du nombre et de la fréquence des connexions.

D’autres garanties sont fournies à destination des utilisateurs. Notamment le fait que seules les données nécessaires au fonctionnement du service « destinataire » seront importées depuis le service « expéditeur ».

Plusieurs cas d’usage sont évoqués. Entre autres, l’envoi, vers un service d’impression en ligne, de photos issues d’un réseau social, le transfert de listes de lecture entre plates-formes de streaming et le partage d’historiques d’achats entre commerçants.

Le Data Transfer Project (DTP) est fondé sur des « adaptateurs » qui convertissent des formats propriétaires en formats canoniques ou « modèles de données ».

Ces modèles ont deux composantes : un type de fichier (par exemple, jpeg) et des métadonnées (comme le titre la et description de l’image) qui permettent l’import sur le service destinataire. Ils sont regroupés en « verticales » – telles que « musique », qui peut comprendre « paroles », « listes de lecture », « vidéos »… – dans l’optique de limiter les développements d’API côté plates-formes.

Les « adaptateurs » susmentionnés peuvent être créés par les plates-formes comme par des tiers. Allant par deux (un pour l’export, un pour l’import), ils traduisent les API en modèles de données et vice versa. Ils gèrent aussi l’authentification.

O. K. pour Azure et GCP

Le DTP peut être déployé dans trois configurations : distribuée, centralisée et autogérée*.

La première d’entre elles implique que le fournisseur du service de départ ou d’arrivée est aussi gestionnaire d’une plate-forme hôte où est hébergé le code du DTP (écrit en Java). Cette architecture permet d’échanger des données sans passer par un tiers.

Dans le modèle centralisé, la plate-forme qui prend en charge les requêtes entrantes et sortantes émanant des fournisseurs de services est gérée par un tiers. Il peut s’agir aussi bien d’une infrastructure d’entreprise que d’un cloud (compatibilité assurée pour l’heure avec Azure et GCP).

Un tel dispositif offre moins de garanties de sécurité, mais est censé permettre la participation d’organisations qui n’ont pas les ressources pour monter elles-mêmes une plate-forme. Dans un cas comme dans l’autre, les fournisseurs de services gardent le contrôle sur leurs API et donc sur les connexions acceptées.

Facebook, Google, Microsoft et Twitter encouragent tout contributeur à proposer systématiquement une paire d’adaptateurs (import + export). Ils invitent par ailleurs chaque fournisseur à publier des informations sur les problèmes que rencontreraient ses utilisateurs.

Techniquement, le pull est préféré au push, sauf dans le cas où l’entité destinataire n’a pas l’infrastructure nécessaire pour enclencher la transaction.

* En mode autogéré, l’utilisateur a la possibilité d’héberger sa propre instance du DTP, en local ou dans un cloud privé.

Crédit photo : Citrix