Architecture, modules et rôles

Cette page résume l'architecture applicative d'Omniscol et les rôles visibles côté école. Les engagements contractuels précis (disponibilité, sauvegardes, rétention, supervision) relèvent des documents juridiques ou commerciaux validés.

Hébergement et fiabilité

Omniscol est hébergé dans l'Union européenne, plus spécifiquement sur AWS Paris et Scaleway Paris. Le produit utilise des mécanismes de sauvegarde, de supervision et d'isolation logique entre les comptes des établissements ; les détails applicables à un compte dépendent du contrat et de l'environnement concerné.

Voir FAQ — Sécurité et hébergement pour le détail utilisateur.

Architecture logicielle

• Application web : l'application se charge une fois, puis les écrans sont rendus dynamiquement avec échanges REST/JSON (Single Page Application).
• CouchDB comme base de données principale.
• Redis comme base de données pour la synchronisation côté application et les logs.
• TypeScript pour l'interface (webapp).
• Backend Node.js / Express orchestrant les engines internes (api, webapp, portal, panel, ical, mcp, oauth2, etc.).
• C++ pour l'algorithme de génération, exécuté sur des VMs dédiées démarrées à la demande.

Sécurité

• HTTPS pour les communications exposées.
• Cloudflare comme porte d'entrée exclusive (protection anti-DDOS).
• Mots de passe pré-hashés côté client avec scrypt, puis re-hashés et salés côté serveur. Ils ne sont pas stockés ni transmis en clair.
• Authentification JWT avec clés de signature et durée de vie courte ; une rotation ou révocation de clé peut invalider les jetons signés.
• Liens de partage signés, expirables, liés au compte qui les a générés et invalidables par changement de mot de passe ou désactivation de ce compte.
• Jetons API avec clé racine et jetons dérivés, scopes d'endpoints et expirations.
• OIDC / SSO disponible selon le contrat et le paramétrage du compte.
• Export et sauvegardes internes JSON pour la réversibilité des données.

Rôles utilisateurs

Omniscol distingue plusieurs rôles côté école :

La correspondance entre ces libellés et les identifiants techniques des rôles est détaillée dans Utilisateurs et rôles.

Un même utilisateur peut cumuler plusieurs rôles. Par exemple, un professeur qui participe à la planification peut être à la fois Professeur et Administrateur.

Le rôle Lien de partage ne correspond pas à un compte utilisateur classique. Il s'agit de liens signés : les liens web d'EDT sont en lecture seule, tandis que certains liens ciblés peuvent autoriser une action limitée, comme la saisie des disponibilités d'un professeur jusqu'à une date d'expiration.

Il existe par ailleurs des rôles internes réservés aux équipes d'Omniscol : administration de la plateforme, traduction, actions commerciales et partenaires redistributeurs. Certains de ces comptes sont autorisés à se connecter aux comptes des écoles, pour des raisons de maintenance. Ils interviennent alors comme superadministrateurs de l'école, avec plus de possibilités qu'un administrateur : importation de données brutes en base de données, activation ou désactivation d'options payantes, connexion au nom d'un utilisateur. Ces accès déclenchent des alertes de connexion visibles et leurs jetons expirent très vite. Les grands pouvoirs impliquent de grandes responsabilités.

Modules

Les modules visibles dans un compte standard :

• Accueil (home) — page d'entrée et synthèse du jour.
• EDT (schedules) — consultation et modifications ponctuelles.
• Tableau de bord (dashboard) — statistiques d'occupation et de service.
• Gestion des absences (absences) — déclarations et substitutions.
• Gestion des EDT (timetables) — construction, génération et publication des emplois du temps.
• Administration (admin) — utilisateurs, paramètres, import / export et intégrations.

Selon le contrat, d'autres modules peuvent apparaître, notamment Service du personnel pour la planification des tâches de vie scolaire et de surveillance.

Multi-écoles

Chaque école est isolée logiquement côté serveur et accède à son propre domaine. Les données d'une école ne sont pas visibles par les autres écoles depuis l'application. En revanche, sur demande, il est possible d'activer un canal de communication entre les comptes distincts, afin de partager les conflits d'occupation de salles et de professeurs. C'est très utile dans le cadre de bâtiments partagés, ou pour un groupe d'écoles partageant des ressources.