OEIP — échange entre ENT

OEIP (Open ENT Interoperability Package) répond à une question simple et longtemps sans réponse : comment récupérer ce qu'on a produit dans un ENT lorsqu'on en change ?

Pourquoi OEIP ?

Un établissement change de titulaire de marché. Une collectivité fusionne deux plateformes. Une famille déménage d’une académie à l’autre.

Dans tous ces cas, les données existent : blogs, documents, cahiers de textes, comptes, ressources pédagogiques… mais elles restent souvent enfermées dans la plateforme qui les héberge.

OEIP apporte une réponse à ce verrouillage.

OEIP définit un format de paquet d’échange interopérable qui permet d’exporter ces données depuis une plateforme, de les transporter et de les réimporter dans une autre solution, en préservant autant que possible leur structure, leurs métadonnées et leurs relations.

L’objectif est simple : les données appartiennent à leurs utilisateurs, pas à la plateforme qui les héberge.

C'est aussi une exigence du SDET : la portabilité des données entre ENT.

Ce n'est pas une sauvegarde

La confusion est facile, parce qu'Open ENT propose déjà un export « Mes données ». Les deux mécanismes ne servent pourtant pas le même besoin.

	Sauvegarde (archive)	Paquet d'échange (OEIP)
À quoi ça sert	Restaurer un compte sur la même plateforme	Emporter ses données vers une autre plateforme
Qui sait le relire	Open ENT, à version proche	N'importe quel ENT, y compris d'un autre éditeur
Ce qui est garanti	Que la restauration fonctionne ici	Que le contenu soit compréhensible ailleurs
En cas de module non couvert	Les données disparaissent sans que personne ne le sache	Le paquet déclare ce qu'il n'a pas su emporter

La sauvegarde n'est pas remplacée et continue de fonctionner comme avant.

Trois niveaux de garantie

Un paquet annonce lui-même ce qu'il vaut. C'est le point le plus important du format, et celui qui évite les mauvaises surprises à l'arrivée.

Niveau	Ce que ça garantit	Lu par
Échange	Les données sont décrites dans un modèle commun : personnes, groupes, établissements, ressources, fichiers, liens entre eux	N'importe quel ENT
Pédagogique	Les contenus d'apprentissage sont aussi décrits au format standard des plateformes pédagogiques	Moodle, et les autres LMS
Interne	La copie brute produite par Open ENT est conservée telle quelle	Uniquement un autre Open ENT

Le niveau « Interne » n'est pas de l'interopérabilité

Il correspond à un mécanisme de portabilité technique entre deux instances d’Open ENT, permettant de transférer des données ou des contenus d’une instance à une autre selon un format maîtrisé par la solution.

Un paquet limité à ce niveau ne permet donc pas, à lui seul, de démontrer la portabilité inter-ENT ou l’interopérabilité avec une autre solution d’ENT. Il ne doit par conséquent pas être présenté comme une capacité d’interopérabilité dans le cadre d’un dossier de conformité.

Le paquet dit la vérité sur ce qu'il emporte

Pour chaque service, le paquet déclare le degré de fidélité atteint, et doit se justifier dès que ce n'est pas parfait :

• complet — le service est décrit dans le modèle commun, rien de connu n'est perdu ;
• partiel — l'essentiel est décrit, mais une partie ne voyagera que vers un autre Open ENT ;
• interne seulement — aucune description commune ; relisible uniquement par un Open ENT ;
• rien — le service n'a rien produit, ou a échoué.

C'est l'inverse du comportement historique, où un module non pris en charge disparaissait de l'export sans un mot. Ici, l'utilisateur sait à l'avance ce qu'il pourra rouvrir ailleurs.

Ce que contient un paquet

Un paquet est un fichier unique, qui se transporte et s'archive comme n'importe quel fichier. Il rassemble :

• les données structurées — qui sont les personnes, quels groupes, quelles ressources, et comment tout cela se rattache ;
• les fichiers eux-mêmes : documents, images, pièces jointes ;
• les liens entre les objets : qui est l'auteur de quoi, quel document appartient à quel dossier, quelle ressource est partagée avec quel groupe ;
• de quoi se vérifier lui-même, sans dépendre d'Open ENT ni d'aucune clé secrète ;
• sa propre notice : les règles du format sont recopiées à l'intérieur, si bien qu'un paquet reste lisible et vérifiable dans dix ans, hors ligne.

Les identités ne sont pas recopiées telles quelles

C'est le point délicat de tout échange entre systèmes. L'identifiant interne d'une personne dans un ENT ne veut rien dire dans un autre : le réutiliser tel quel provoquerait des collisions ou des rattachements faux.

Chaque objet porte donc un identifiant d'échange, indépendant des deux plateformes, et — lorsqu'il existe — un repère national : l'UAI pour un établissement, l'identifiant d'alimentation pour une personne. C'est ce repère qui permet à la plateforme d'arrivée de reconnaître « la même personne » sans rien connaître de la plateforme de départ.

Ce mécanisme est en service pour l'annuaire : un établissement est désigné par son UAI, une personne par son identifiant d'alimentation. Aucun repère n'est inventé — un UAI mal formé est ignoré plutôt que transmis à tort.

Les contenus s'y rattachent : dans un paquet, l'auteur d'un billet de blog ou le propriétaire d'un document désigne la personne décrite dans le même paquet. C'est ce qui fait du paquet un ensemble cohérent plutôt qu'une collection de fichiers juxtaposés.

Les liens internes aux contenus suivent la même règle. Un lien vers une pièce jointe ne désigne rien sur une autre plateforme : il est donc remplacé par une référence d'échange, une seule fois au départ, et chaque remplacement est consigné. Un lien qu'on n'a pas su résoudre est laissé tel quel et signalé — un lien mort annoncé vaut mieux qu'un lien réécrit vers n'importe quoi.

Savoir si un paquet est intact, et d'où il vient

Ce sont deux questions différentes, et le paquet y répond séparément.

« A-t-il été abîmé ou modifié ? » Un relevé d'empreintes accompagne le paquet et couvre chacun de ses fichiers — y compris la fiche qui annonce ce qu'il contient. N'importe qui peut le vérifier, sans aucune clé, sur n'importe quel poste, y compris des années plus tard. Cette vérification est faite automatiquement au dépôt, et un paquet abîmé est refusé avant d'avoir touché quoi que ce soit.

Cette couverture de la fiche compte : c'est elle qui déclare ce qui est repris fidèlement, ce qui ne l'est pas, et si des personnes mineures sont concernées. Un paquet ne peut pas promettre mieux qu'il ne tient sans que cela se voie.

« Vient-il bien de la plateforme annoncée ? » Cette question-là demande de connaître l'émetteur. Une plateforme peut signer ses paquets ; une plateforme destinataire peut enregistrer la clé publique de ses correspondants habituels. L'analyse d'un dépôt annonce alors l'une de quatre situations : signature vérifiée, émetteur inconnu, signature qui ne correspond pas, ou paquet non signé.

Un émetteur inconnu ne bloque jamais un échange

Refuser un paquet parce qu'on ne connaît pas encore son émetteur interdirait tout premier échange entre deux plateformes. Un émetteur inconnu produit donc un avertissement, et le paquet reste exploitable — son intégrité, elle, a déjà été établie sans clé. Seule une signature qui ne correspond pas à la clé connue d'un émetteur connu appelle la plus grande prudence.

Comment ça se passe

Exporter

L'export permet de préparer un paquet contenant les données à transférer vers une autre plateforme ENT. Selon le périmètre choisi, il peut concerner un établissement, un ensemble d'utilisateurs ou certains services seulement.

La génération du paquet est réalisée en arrière-plan afin de permettre des exports volumineux. L'administrateur peut quitter la page et revenir ultérieurement pour télécharger le paquet une fois celui-ci prêt.

Importer

Le dépôt d'un paquet est réservé à un administrateur de la plateforme, et pour une bonne raison : un paquet peut transporter des données de personnes venues d'ailleurs.

Le déroulé impose une étape de lucidité :

1. dépôt du paquet ;
2. analyse — la plateforme vérifie que le paquet est intact, puis annonce, service par service, ce qu'elle saura reprendre et ce qu'elle ne saura pas, avec le motif ;
3. essai — tout est préparé, rien n'est écrit. C'est le comportement par défaut ;
4. application — l'écriture réelle, qui doit être demandée explicitement.

Ce qui n'est jamais rétabli d'autorité

Un contenu repris revient privé, quel qu'ait été son partage au départ : les groupes de la plateforme d'origine n'existent pas ici, et un partage reconstitué au jugé serait pire qu'un partage à refaire.

De même, un billet publié revient en brouillon. Republier est une décision de la personne qui reçoit, pas une conséquence de l'import.

L'import ajoute, il ne remplace pas

Réimporter un paquet dans un compte qui possède déjà ces ressources y crée des copies, signalées comme telles. Rien n'est écrasé, rien n'est fusionné. Sur un compte déjà alimenté, prévoir un ménage après coup.

Les données reviennent dans le bon compte

L'administrateur qui pilote l'opération désigne le compte destinataire. Sans cette précision, les données atterriraient dans le compte de l'administrateur lui-même — ce qui n'aurait aucun sens pour un déménagement.

Un paquet peut désormais être repris par sa seule description

Les trois services du pilote — annuaire, blog, espace documentaire — sont décrits dans le modèle commun et repris à partir de cette description. Un paquet qui ne contiendrait que celle-ci, sans aucune donnée propre à Open ENT, est intégralement exploitable.

Les liens suivent : une image citée par un billet devient une référence d'échange au départ, et pointe à l'arrivée vers le fichier recréé sur place.

Ce qui ne voyage pas

Autant le dire franchement, parce que ces limites se découvrent sinon au pire moment.

• Les comptes ne sont jamais créés par un import. La création des utilisateurs reste le métier de l'alimentation de l'annuaire. Un import rattache des données à des comptes qui existent déjà ; il ne peuple pas un ENT vide. À l'analyse, la plateforme confronte les personnes du paquet à son propre annuaire — d'abord par identifiant d'alimentation, puis par identifiant de connexion — et nomme celles qu'elle ne reconnaît pas, pour que l'opérateur puisse agir avant d'appliquer.
• Les droits de partage ne sont pas transposables tels quels : les groupes de la plateforme de départ n'existent pas à l'arrivée. Les partages sont décrits, mais devront être rétablis.
• Les échanges de messagerie, les commentaires, l'historique des versions ne sont pas modélisés à ce stade.
• Les exercices et les formulaires demandent un format spécialisé, prévu pour une version ultérieure.
• Ce que la plateforme de départ n'avait plus ne peut pas être emporté. Si un fichier a disparu du stockage, le paquet reste parfaitement valide — et l'erreur n'apparaîtra qu'à l'import. Voir l'encadré ci-dessous.

Un paquet annonce désormais ce qui lui manque

Un service repris en interne seulement est recopié sans être compris : si un fichier manquait déjà sur la plateforme de départ, le paquet reste parfaitement valide et l'absence ne se révèle qu'à l'arrivée.

Un service décrit dans le modèle commun le détecte. L'espace documentaire compare le recensement des documents aux fichiers réellement présents, et inscrit l'écart dans le paquet : « 15 documents sur 17 sont recensés par la plateforme de départ mais leur fichier n'y était plus disponible ». Le destinataire le sait avant d'importer.

Une omission volontaire des fichiers et une absence subie donnent deux messages distincts.

Compatibilité avec les plateformes pédagogiques

Pour la partie contenus pédagogiques, OEIP ne réinvente rien : il produit en plus une description au format standard des plateformes d'apprentissage (IMS Common Cartridge). Un billet de blog et ses images, un document et son classement peuvent ainsi être ouverts dans un Moodle, sans qu'Open ENT soit dans la boucle.

Cette description est produite : un billet y devient un contenu citant les fichiers dont il dépend, et le blog qui le porte une simple rubrique — le standard n'ayant pas de notion équivalente à un blog.

Ce standard ne connaît en revanche ni les utilisateurs, ni les groupes, ni les inscriptions : tout ce qui relève de l'annuaire reste dans la partie OEIP, et n'apparaît pas dans cette description. C'est une limite du standard, pas un choix.

Formulation à employer

On dit qu'Open ENT produit une description conforme au profil Common Cartridge 1.3. On ne dit pas « certifié Common Cartridge » : la certification suppose une campagne de conformité auprès de l'organisme qui publie le standard.

Données personnelles

Un paquet quitte la plateforme et contient des personnes identifiées, souvent mineures. Le format l'assume explicitement :

• une notice de traitement accompagne chaque paquet : finalité, base légale, responsable, délégué à la protection des données, catégories de données, durée de conservation. Lorsque la plateforme n'a pas renseigné son responsable, la notice est produite quand même et le dit — un paquet muet sur ce point laisserait croire que la question a été traitée ;
• la présence de personnes mineures est annoncée dans cette notice, pour que le destinataire le sache avant d'ouvrir le paquet et non en parcourant l'annuaire ;
• chaque paquet porte sa provenance : quelle plateforme l'a produit, quand, et à la demande de qui ;
• les personnes mineures sont signalées comme telles au destinataire ;
• une option de pseudonymisation retire tout ce qui désigne directement une personne : nom, prénom, identifiant de connexion, date de naissance, courriel, ainsi que les identifiants internes et l'identifiant d'alimentation, qui suffiraient à la retrouver par simple rapprochement. Ne subsistent que le profil, le rattachement et le signalement de minorité. Les identifiants deviennent opaques, mais restent stables d'un envoi à l'autre : deux exports du même compte se rapprochent sans que l'anonymat soit levé. Cette option est incompatible avec le niveau « Interne », qui transporte les données brutes ;
• les paquets ont une durée de vie limitée et sont purgés automatiquement ;
• chaque export et chaque import est journalisé.

Voir aussi

• Formats d'archive — import & export : la sauvegarde interne, dont OEIP réutilise la mécanique.
• Feeder : l'alimentation de l'annuaire, seule voie de création des comptes.

Détails techniques

Structure du paquet, règles d'identifiants, routes et niveaux d'accès, configuration et outil de validation : OEIP — détails techniques.