Skip to main content

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 (Actualités, Agenda, Blog, Cahier de textes, Carnet de liaison, Cours et Wiki, Messagerie, Vote électronique, Cahier multimédia, Espace documentaire…) 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 besoin : Notifications, Messagerie, Consultation, Édition & alimentation (une même application peut apparaître dans plusieurs rubriques selon ce qu'elle permet). Les sections vides sont masquées. Chaque tuile porte l'icône officielle de l'application (les mêmes que le portail / dashboard). 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.

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.

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​

Tests​

  • Jest : intégrité du catalogue, jointure droits ↔ registre, repli statique, découplage visibilité/rendu, mapping du Blog natif (apps/mobile/__tests__/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.