Lanceur d'applications & gestion des droits

Pour :EnseignantÉlève Niveaux :1er degré2nd degré

L'application mobile donne accès au catalogue d'applications de l'ENT depuis un lanceur « Mes apps ».

Le point clé : le lanceur ne contient aucune liste figée. Les applications affichées sont exactement celles auxquelles l'utilisateur a droit, lues à la connexion depuis la même source que le portail web (/auth/oauth2/userinfo, déjà filtré par les droits de l'utilisateur). Activer ou retirer une application à un profil côté ENT se reflète donc dans le mobile sans nouvelle livraison.

Le lanceur « Mes apps »

Les applications sont présentées en grille, regroupées par famille — exactement les mêmes sections, dans le même ordre et avec les mêmes pastilles de couleur que « Mes applications » du portail web : Communication & collaboration, Vie scolaire, Pédagogie & contenus, Gestion documentaire, Outils bureautiques, Administration & gestion, Services externes intégrés, Vie de l'établissement, Orientation & suivi, Autres. Les sections vides sont masquées. Chaque tuile porte l'icône officielle de l'application (le même fichier que le portail / dashboard, rastérisé pour React Native) et son libellé du catalogue web. Le lanceur adopte la couleur de marque de l'instance (ici le vert de l'établissement de référence école).

« Mes apps » — catalogue regroupé par besoin

Changer d'établissement (multi-établissement)

Le choix de l'établissement ne se fait pas à la connexion. Certains utilisateurs — typiquement des enseignants rattachés à plusieurs établissements — peuvent, une fois connectés, basculer d'un établissement à l'autre via le sélecteur d'établissement : la liste provient des structures réelles de l'utilisateur (annuaire ENT). Pour un utilisateur mono-établissement, le sélecteur reste inactif (rien à choisir).

Sélecteur d'établissement (enseignant multi-collèges)

Capture live : lilit.upreti001, enseignante rattachée à 3 collèges de Morlaix — ses établissements réels sont proposés au changement.

Parité avec le portail web

Le mobile n'expose pas une sélection d'applications : il expose tout le catalogue de l'utilisateur. Une application accordée côté ENT est atteignable depuis le mobile même si elle n'a pas encore d'écran natif — elle s'ouvre alors dans la WebView authentifiée (SSO transparent, cf. plus bas). Concrètement :

• Même liste : toute application présente dans userinfo.apps est présentée. Une application déployée après la livraison du mobile (Forum, Casier, Réservation de ressources, Démarches, Rendez-vous, Frise chronologique, Moodle…) apparaît sans nouvelle version de l'application mobile.
• Mêmes libellés et mêmes familles : le mobile embarque le catalogue partagé du portail (dashboard/src/utils/app-catalog.ts → apps/mobile/src/apps/entCatalog.ts) ; une application porte donc le même nom et la même famille des deux côtés. Si l'ENT fournit lui-même une famille (pilotée dans l'administration), c'est elle qui prime, exactement comme sur le web.
• Mêmes pictogrammes : les icônes sont les fichiers du portail (dashboard/public/images/applications/*.svg), rastérisés en PNG par apps/mobile/scripts/build-app-icons.sh (React Native ne charge pas de SVG). Une application sans pictogramme connu affiche son initiale, comme sur le web.
• Mêmes exclusions : les briques techniques et les applications remplacées sont masquées selon la même liste que le web (display: false, appType: SYSTEM, liste noire partagée : explorer, timeline, auth, portal, connecteur GAR…).
• Connecteurs externes : une application hors instance (Moodle, NextCloud, site WordPress…) est ouverte à son adresse réelle ; une adresse absolue pointant sur l'instance est ramenée sur l'origine courante pour conserver la session — même règle que le widget « Mes applications » du portail.

Le registre mobile (src/apps/registry.ts) ne sert donc plus à rendre une application visible, mais uniquement à lui donner un traitement mobile spécifique : écran natif, visibilité par profil, icône ou libellé dédiés.

Gestion des droits

La visibilité de chaque application découle des droits réels de l'utilisateur :

• Applications web ENT : visibles si et seulement si l'instance les déclare comme accessibles à l'utilisateur (présence dans userinfo.apps). C'est le même filtrage que le lanceur du portail web — un enseignant et un élève d'un même établissement ne voient donc pas forcément le même catalogue.
• Parcours natifs mobiles (ex. Carnet de liaison) : visibles selon le profil, car l'ENT ne décrit pas ces écrans dédiés.
• Repli hors-ligne : si le catalogue ne peut pas être chargé (réseau indisponible), l'application retombe sur une définition statique pour rester utilisable.

Capture en conditions réelles

La capture ci-dessus est produite par un test e2e connecté en live sur une instance ENT (profil enseignant). Le catalogue affiché provient bien de la session réelle de l'utilisateur, pas de données de démonstration.

Ouvrir une application

Une tuile ouvre l'application dans une enveloppe commune (l'AppShell) : en-tête homogène (retour, titre, bascule inter-applications) et corps natif ou WebView selon le degré d'intégration de l'application.

Pour une application native, l'AppShell rend directement son écran React Native. Ci-dessous, le Carnet de liaison ouvre l'expérience native du carnet de liaison (module schoolbook) avec les données réelles de l'utilisateur connecté ; l'écran adopte la couleur de marque de l'instance.

AppShell — Carnet de liaison (écran natif, données réelles)

Migration progressive WebView → natif

Le degré d'intégration de chaque application est porté par un champ mount :

• webview — l'application web ENT est embarquée telle quelle. La session est partagée automatiquement avec la WebView (cookie du CookieManager sur Android, sharedCookiesEnabled sur iOS) : l'utilisateur ne ressaisit jamais ses identifiants (SSO transparent). C'est la voie rapide pour rendre une application disponible.
• native — l'application est réécrite en écrans React Native dédiés (meilleure ergonomie mobile, hors-ligne possible, intégration aux notifications).

Une application démarre en WebView puis bascule en natif au fil de l'eau, sans changer le lanceur ni la navigation.

Exemple : le Blog migré en natif

Le Blog est la première application portée. Son corps n'est plus une WebView mais un écran natif au style éditorial / magazine (cf. maquettes demo-openent/specification-design/blog-mobile) : un fil des articles publiés des blogs visibles (article « à la une » + liste « Récents », catégories, titres en serif), et un lecteur d'article (couverture, chapô, corps, réactions, commentaires).

Les captures ci-dessous sont prises sur l'établissement de référence collège (CLG-Pierre Mendès France, Morlaix) avec un compte enseignant réel : les articles affichés sont les vrais articles du collège, lus via l'API (/blog/list/all → /blog/post/list/all/{id}), aucune donnée fabriquée.

Blog natif — fil des articles réels (collège)

Blog natif — lecteur d'article réel

Parcours capturé en live (connexion enseignant, collège de référence) — scénario Maestro apps/mobile/e2e/lanceur/parcours-blog-college.yaml.

Points importants :

• Données réelles : le fil vient de l'ENT. Seul l'habillage non porté par l'ENT (catégorie, couleur de couverture, temps de lecture) est dérivé de façon déterministe du contenu (même article → même rendu) ; titres, textes, auteurs et dates sont réels.
• Visibilité pilotée par les droits : le rendu natif ne court-circuite pas l'autorisation — le Blog n'apparaît dans « Mes apps » que si l'instance l'autorise à l'utilisateur. Quand aucun article n'est publié, l'écran affiche un état vide explicite.

Exemple : l'emploi du temps (collège / lycée)

Deuxième application migrée en natif : l'emploi du temps du secondaire (module EDT). L'écran présente une vue jour (cartes de cours colorées par matière, horaires, salle), avec navigation par semaine et onglets de jours. Un sélecteur de contexte permet à un enseignant de consulter ses cours ou l'emploi du temps de l'une de ses classes (les élèves/parents y retrouvent leur classe).

EDT natif — journée d'une classe (données réelles, collège)

Parcours capturé en live — apps/mobile/e2e/lanceur/parcours-edt-college.yaml : enseignante multi-établissement (lilit.upreti001) → choix de l'établissement → emploi du temps → classe 401 → journée réelle (Maths, Français, SVT, Anglais, Histoire-Géo, EPS).

• Données réelles : cours, horaires, salles et couleurs par matière viennent du module EDT (POST /edt/structures/:id/common/courses/:début/:fin). Aucune donnée fabriquée.
• Visibilité pilotée par les droits : l'EDT n'apparaît dans « Mes apps » que si l'instance l'autorise à l'utilisateur. La structure courante suit le changement d'établissement.

Exemple : le Casier (module rack)

Dernière application portée : le Casier. L'écran reprend les trois boîtes du frontend web (Reçus, Envoyés, Corbeille), affiche le correspondant, la taille et la date d'envoi, ouvre le document (image en ligne, autres types en téléchargement) et permet de ranger son casier (corbeille / restauration). Détail : Casier.

Exemple : le Forum (module forum)

Le Forum suit la même mécanique en natif : catégories partagées → sujets (avec aperçu de la dernière contribution) → fil de discussion, et réponse depuis le mobile. Détail : Forum.

Exemple : les Rendez-vous (module appointments)

Les Rendez-vous vont plus loin que la consultation : outre le suivi (accepter, refuser, annuler), l'application permet de demander un créneau depuis le mobile — recherche de la personne, grille de disponibilités, créneau de la semaine. Détail : Rendez-vous.

Exemple : les Démarches (module workflowhub)

Les Démarches montrent qu'un portage natif peut être partiel et assumé : le mobile rend le formulaire d'une démarche à partir de son JSON Schema pour la remplir, tandis que la conception (constructeur de formulaire, diffusion) et le suivi des dossiers restent sur le portail web. Détail : Démarches.

Exemple : la Réservation de ressources (module rbs)

Dernière application portée : la Réservation de ressources — suivi de ses réservations (états, motifs, annulation) et demande d'un créneau sur une salle ou du matériel réellement partagé à l'utilisateur. Détail : Réservation de ressources.

Quand le réseau manque

Les applications ne montrent plus « Impossible de charger » au premier échec réseau : la dernière réponse connue est conservée et resservie, avec un bandeau qui dit depuis quand elle date. Le réseau reste interrogé à chaque affichage — le cache accélère, il ne remplace pas la donnée — et l'erreur n'apparaît que s'il n'y a rien à montrer.

Une session non revérifiable (réseau absent) ne déconnecte plus l'utilisateur : la dernière session connue est rouverte, faute de quoi ses données en cache seraient devenues inatteignables au moment précis où elles servent.

Mode avion : le casier affiche ses documents connus et l'annonce

Capture prise en mode avion sur un build release, via apps/mobile/e2e/scripts/capture-hors-connexion.sh (visite qui remplit le cache → coupure → seconde visite). Applications concernées : casier, exercices, mur, frise, forum, rendez-vous, réservation de ressources, démarches.

Ouvrir depuis une notification

Une notification push n'ouvre pas seulement l'application : elle ouvre la ressource concernée. Le mobile déduit l'une et l'autre de ce que l'ENT envoie réellement — type, event-type, et la resourceUri portée par les paramètres de la notification — sans qu'aucun module ait à ajouter de champ. Les modules ne nomment pas leurs itinéraires de la même façon (view/, read-mail/…) : ce sont les segments d'action qui sont écartés, et ce qui reste est l'identifiant.

Notification	Ce qui s'ouvre
Frise partagée (/timelinegenerator#/view/<id>)	la frise, ses événements affichés
Nouveau message de forum (/forum#/view/<catégorie>/<sujet>)	le fil du sujet, sans passer par les listes
Note sur un mur (/collaborativewall/view/<id>)	le mur concerné
Nouveau message (…#/read-mail/<id>)	le message, sans passer par la boîte de réception
Article de blog (/blog#/view/<blog>)	l'article annoncé, à défaut le dernier du blog
Autres applications	l'application, à son écran d'accueil

Notification d'une frise partagée → la frise s'ouvre

Notification de forum → le fil du sujet, directement

Notification de messagerie → le message, ouvert par son seul identifiant

Vérifié par un test e2e — apps/mobile/e2e/lanceur/parcours-notification.yaml : le lien profond utilisé reproduit exactement ce que le service push fabrique à partir de la charge utile d'entcore.

Quand la notification ne désigne aucune application connue, rien ne s'ouvre : mieux vaut laisser l'utilisateur sur son accueil que l'emmener au hasard.

Basculer entre applications

Depuis l'en-tête de l'AppShell, l'AppSwitcher propose une bascule rapide vers une autre application sans repasser par le lanceur. L'application courante y est mise en évidence.

Bascule inter-applications (AppSwitcher)

Pour aller plus loin

• Architecture technique (registre, lanceur, AppShell, pont avec le catalogue ENT, deep-links) : Navigation de l'application mobile.
• Personnalisation de la couleur par instance : voir l'expérience Vie scolaire 2D.

Tests

• Jest : intégrité du catalogue, jointure droits ↔ registre, repli statique, découplage visibilité/rendu, parité avec le lanceur web (applications hors registre exposées, exclusions identiques, absence de doublon, connecteurs externes), libellés et familles du catalogue partagé, mapping du Blog natif (apps/mobile/__tests__/catalog.test.ts, ent-catalog.test.ts, apps-registry.test.ts, linking.test.ts, blog-service.test.ts).
• e2e Maestro live : apps/mobile/e2e/lanceur/parcours-lanceur.yaml (connexion enseignant → « Mes apps » → ouverture d'une application → AppSwitcher → Blog natif). Les captures de cette page en sont issues.