En bref
Une architecture EdTech d’entreprise ne se résume pas à empiler un LMS, un outil d’examen et un logiciel de gestion scolaire. Elle doit préciser quelles données font autorité, comment les accès sont limités, comment les intégrations échouent sans perdre d’information et qui décide lorsqu’un incident survient. Pour Educati, cette grille sert à cadrer une démonstration ou un projet ; elle ne décrit pas des fonctions contractuelles non publiées.
1. Partir des responsabilités et des parcours
Avant de parler d’API, dessinez les parcours qui traversent plusieurs outils : création d’un compte, inscription à une formation, affectation à un cours, passage d’une évaluation, publication d’un résultat et désactivation d’un accès. Pour chaque étape, nommez le système maître, les données copiées et le responsable de la correction.
La page de gestion scolaire Educati aide à situer les parcours administratifs et pédagogiques à discuter. Elle ne prouve pas qu’un connecteur, un protocole ou une synchronisation particulière est inclus. Le périmètre à retenir reste celui qui est démontré puis écrit dans la proposition.
2. Séparer identité, autorisation et données
Le NIST SP 800-207 sur l’architecture zero trust recommande de ne pas accorder une confiance implicite à un compte ou à un équipement du seul fait de son emplacement. Transposé à un environnement éducatif, ce principe invite à vérifier l’identité, le rôle et la ressource demandée à chaque frontière importante.
Posez des questions observables : un enseignant d’un établissement peut-il voir les apprenants d’un autre ? Que devient l’accès d’un vacataire après sa mission ? Un administrateur fonctionnel peut-il exporter des données qui ne relèvent pas de son périmètre ? Les réponses doivent être montrées sur des rôles de test, sans transformer un principe général en certification Educati.
3. Concevoir les intégrations pour l’échec
Une intégration robuste prévoit les doublons, les messages arrivés dans le désordre, les indisponibilités et les reprises. Demandez quel identifiant relie un apprenant entre systèmes, comment une opération répétée est reconnue, où une erreur est visible et qui peut la rejouer. Un tableau de bord vert n’est pas suffisant si une équipe ne peut pas retrouver la trace d’une modification.
La grille LTI 1.3 publiée dans les Actualités Educati complète cette lecture pour les outils reliés à un LMS. Elle explique le standard sans affirmer qu’Educati possède une intégration ou une certification LTI.
4. Gouverner le risque sur tout le cycle
Le NIST Cybersecurity Framework 2.0 organise la gestion du risque autour de six fonctions : gouverner, identifier, protéger, détecter, répondre et rétablir. Cette vue évite de limiter l’architecture à la prévention. Elle pousse aussi à demander les responsabilités, le suivi des fournisseurs, les procédures d’incident et les exercices de reprise.
Le guide Secure by Demand de la CISA propose aux acheteurs des questions de sécurité à intégrer au processus d’acquisition. Utilisez-le comme source de questions, pas comme attestation sur un fournisseur. Pour le contexte propre à la marque, consultez aussi la présentation sécurité d’Educati et demandez les preuves applicables au périmètre étudié.
5. Une checklist de démonstration
- Montrer un même parcours avec trois rôles différents et vérifier les refus d’accès.
- Identifier le système maître pour l’identité, le cours, l’inscription et le résultat.
- Provoquer un échec d’import ou une donnée en double, puis observer la reprise.
- Demander les journaux accessibles, leur contexte et la procédure d’escalade.
- Établir la réversibilité : formats, responsabilités, calendrier et contrôles de sortie.
- Distinguer ce qui est standard, configurable, à intégrer ou hors périmètre.
Pour estimer le cadre commercial sans déduire une fonctionnalité, consultez la page tarifs Educati. Les modalités finales doivent être confirmées dans un devis et un contrat. Retrouvez également les autres guides sur le hub Actualités Educati.
FAQ
Faut-il remplacer tous les systèmes pour obtenir une architecture cohérente ?
Non. Commencez par les parcours critiques, les systèmes maîtres et les interfaces qui créent le plus d’erreurs. Une trajectoire progressive peut être plus lisible qu’un remplacement simultané, à condition de documenter les états transitoires.
Une architecture zero trust impose-t-elle un produit précis ?
Non. Le document du NIST décrit des principes et des modèles généraux. Le choix des contrôles dépend du contexte, des risques et des systèmes concernés.
Comment savoir ce qu’Educati prend réellement en charge ?
Préparez deux ou trois scénarios réels, demandez une démonstration avec les rôles concernés et faites consigner le périmètre. Pour organiser cet échange, contactez Educati.
