Comment Omniscol fonctionne — une seule API, une source de vérité

Quelques points sur la manière dont Omniscol est bâti méritent d'être connus avant de l'intégrer — ils expliquent pourquoi l'API est aussi complète, comment l'interface s'adapte à chaque utilisateur, et un point de confidentialité à garder en tête.

Une seule application sur une seule API

Omniscol s'exécute comme une application web unique dans votre navigateur. Chaque écran, bouton et tableau est dessiné en appelant l'API publique d'Omniscol — la même API que vous pouvez appeler vous-même, documentée sur la référence d'API interactive d'Omniscol, la page Développeurs (omniscol.com/fr/developers). Il n'y a pas d'API cachée, « réelle », derrière celle que vous intégrez : ce que l'interface utilise est ce que vous obtenez. Quelques opérations vont dans l'autre sens — offertes pour l'intégration mais non utilisées par l'application elle-même : par exemple, les points d'accès de recherche avancée et de résolution d'entité (destinés à un agent IA via MCP), ou ceux qui permettent à un système externe d'alimenter Omniscol (un ETL gardant une base externe synchrone).

operationId — une clé, une source de vérité

Chaque opération est un couple méthode + URL (par exemple GET /api/schedules/lessons/{datesrange}), et chacune porte un identifiant stable : son operationId (ici os_schedules_dates_get). Le nom est structuré : os (Omniscol), puis le module (schedules), puis ce sur quoi porte l'opération (dates — parfois plusieurs segments reliés par des tirets), et toujours la méthode HTTP en dernier (get, post, put, delete). C'est cette clé unique qu'Omniscol utilise partout — pour nommer l'opération sur la page Développeurs, pour construire l'outil MCP correspondant, et pour la désigner depuis une surcharge ou depuis cette aide. Définie une seule fois, elle garde toutes les surfaces synchrones : la documentation, les outils et l'interface ne peuvent pas diverger, puisqu'ils lisent tous la même définition.

L'interface suit vos droits

Un élément graphique doté d'une action — un bouton, un onglet, une entrée de menu — n'apparaît que lorsque l'opération qui le sous-tend vous est accessible. Cela dépend de votre rôle et de vos rôles personnalisés (voir Utilisateurs et rôles), de votre offre et de vos options (voir Plans et options Omniscol). Modifiez l'un de ces éléments et l'interface se recompose : des éléments, voire des modules entiers, apparaissent ou disparaissent en conséquence.

Le même principe joue au-delà de vos droits personnels. Le service informatique peut désactiver certaines opérations par une surcharge d'API, et les éléments correspondants disparaissent de l'interface (voir Personnalisation d'API). Il en va de même lorsqu'une donnée est tenue à jour par une synchronisation externe : sa création et sa modification locales peuvent être désactivées, et leurs commandes cèdent alors la place à la synchronisation (voir Synchronisation avec des systèmes externes).

C'est pourquoi Omniscol n'a pas de portail séparé pour les élèves ou les enseignants. Il y a une seule application ; chacun voit l'interface synchronisée sur ses propres droits — un élève, un enseignant, un administrateur et le titulaire d'un rôle personnalisé obtiennent exactement les opérations auxquelles ils ont droit, et rien d'autre.

L'interface est un confort, pas le verrou

Comme l'interface est pilotée par vos droits, on serait tenté de voir un bouton masqué comme une frontière de sécurité. Ce n'en est pas une. Chaque appel est revérifié sur le serveur au regard de votre identité et de vos droits ; une opération à laquelle vous n'avez pas droit y est refusée, quoi que l'interface affiche. L'interface s'adapte pour la clarté et le confort ; la frontière réelle est appliquée côté serveur, à chaque requête.

Tokens et liens de partage, même modèle

Un jeton d'API ou un lien de partage est restreint à un ensemble d'opérations — celles que vous autorisez à sa création. Le serveur applique cette restriction à chaque appel, exactement comme pour un utilisateur connecté. Un lien de partage, un jeton et une personne dans l'interface sont trois façons d'atteindre la même API contrôlée par les droits — jamais une porte dérobée qui la contourne.

Traverser une coupure de connexion

Parce que chaque écran lit l'API, Omniscol peut aussi conserver dans votre navigateur les réponses déjà reçues, pour qu'une brève perte de réseau n'interrompe pas votre lecture. Cette copie locale vit dans sa base de données (IndexedDB), à côté du cache de pages ordinaire du navigateur. C'est un cache de lecture : si la connexion tombe, vous continuez de voir ce que vous aviez déjà ouvert. Il ne met pas vos modifications en file d'attente et ne les rejoue pas — une modification passe toujours par le serveur.

Cette copie locale repose sur votre accord. La première fois sur un navigateur, Omniscol vous demande si vous lui faites confiance ; la copie commence une fois que vous avez accepté. L'entrée Cache hors ligne du menu utilisateur l'active ou l'efface ensuite à tout moment — une coche indique qu'elle est active.

Deux choses à savoir :

• Les données personnelles en sont exclues. Seules les lectures réussies sont conservées ; les réponses que le serveur marque comme non stockables (données de session et d'authentification) ne sont jamais mises en cache, et de ce qui est mis en cache le logiciel retire les coordonnées des personnes — e-mail, téléphone, date de naissance, login, numéro d'identifiant, état du mot de passe — et supprime entièrement les comptes administrateurs. La copie locale contient les données de travail ordinaires, pas l'annuaire nominatif.
• Sur un poste partagé, préférez une fenêtre de navigation privée. La déconnexion n'efface pas cette copie locale (ni le cache normal du navigateur) ; une fenêtre privée les supprime toutes deux à sa fermeture. C'est le soin que mérite toute application web sur une machine que vous ne maîtrisez pas.