École Connect propose un parcours en plusieurs étapes, de la simple exploration sans engagement jusqu'à, en théorie, la création de l'espace d'un établissement. Cet article suit ce parcours tel qu'il est décrit sur les pages publiques de l'application et dans sa documentation technique, en signalant les points que le projet lui-même présente comme non finalisés.
En vidéo
École Connect — Présentation et fonctionnalités | Épisode 1 · Voir toutes les vidéos DYONYSOS
Étape 1 : explorer sans créer de compte
La première étape recommandée par la page des fonctionnalités est l'espace collaboratif de démonstration : choisir un établissement de test (« Établissement Test », « École Primaire Test » ou « Lycée Secondaire Test »), puis un rôle (direction, enseignant, parent ou élève), sans identifiant à saisir. Cette exploration permet de vérifier que le périmètre fonctionnel correspond aux besoins de l'établissement avant toute démarche supplémentaire.
Étape 2 : choisir une offre
L'API de tarifs de l'application publie trois offres mensuelles : Essentiel (0 €/mois, jusqu'à 30 élèves, fonctionnalités de base), Standard (49 €/mois, jusqu'à 200 élèves, fonctionnalités étendues et automatisations) et Établissement (149 €/mois, élèves illimités, export illimité et support prioritaire). Les conditions générales et la politique de remboursement décrivent un abonnement mensuel sans engagement, résiliable à tout moment, avec effet à la fin de la période déjà payée. Un changement d'offre (upgrade ou downgrade) est décrit comme possible à tout moment, le nouveau tarif s'appliquant au cycle de facturation suivant.
Étape 3 : créer l'espace et les comptes
Le site mentionne un parcours de création libre de l'espace d'un établissement, sans carte bancaire requise pour démarrer. La documentation technique confirme l'existence de ce parcours d'auto-inscription (création du premier compte direction), tout en le signalant comme développé mais non testé en conditions réelles à la date de sa dernière mise à jour, et sans limitation de fréquence de création encore en place sur cette route à ce moment-là. Une fois l'espace créé, la page d'administration réservée à la direction permet d'importer des listes de comptes par rôle et de lier les comptes parents aux comptes élèves correspondants.
Étape 4 : activer les modules utiles à l'établissement
La documentation technique décrit une page d'administration où chaque fonctionnalité (annonces, messagerie, devoirs, agenda, bulletin, absences, rendez-vous, sondages, canal enseignants, comportement, fiche santé) peut être activée ou désactivée indépendamment, avec un choix des rôles autorisés à y accéder pour chaque module actif. Cette approche modulaire permet, en théorie, à un établissement de ne démarrer qu'avec les fonctions dont il a réellement besoin.
Points de vigilance RGPD et juridiques, signalés par le projet lui-même
La politique de confidentialité, les conditions générales d'utilisation et la politique de remboursement publiées par l'application portent toutes trois un bandeau d'avertissement explicite : ces textes ont été rédigés automatiquement à partir des traitements de données réellement effectués par le code, mais n'ont pas été relus par un professionnel du droit. Une relecture par un juriste ou un délégué à la protection des données est annoncée comme requise avant tout onboarding d'un véritable établissement scolaire, en particulier pour la conformité RGPD liée au traitement de données de mineurs. Les conditions générales elles-mêmes indiquent, sur la question du droit applicable, une clause « à finaliser avec un conseil juridique », avec le droit belge envisagé à titre de base de travail compte tenu du marché cible principal.
Limites techniques connues à ce stade
La documentation technique liste, parmi les limites connues à prendre en compte avant une mise en production à l'échelle : une base de données SQLite adaptée à un pilote mono-serveur (une couche PostgreSQL existe mais n'est pas activée dans l'environnement décrit), l'absence de SSO ou de journal d'audit RBAC formel au-delà du journal RGPD d'export/suppression, l'absence d'analyse d'impact sur la protection des données (DPIA) formalisée, une validation des pièces jointes fondée sur le type de fichier déclaré par le navigateur plutôt que sur le contenu réel, et un cookie de session sans l'attribut « secure » présenté comme à activer une fois le déploiement HTTPS confirmé. Ces éléments concernent la robustesse technique du pilote, indépendamment des points RGPD/juridiques évoqués plus haut.
Questions fréquentes
Les réponses aux questions que l'on nous pose le plus souvent sur ce sujet.
Le site indique qu'aucune carte bancaire n'est requise pour créer l'espace d'un établissement, l'offre Essentiel étant gratuite.
Non selon le projet lui-même : la politique de confidentialité, les CGU et la politique de remboursement sont explicitement qualifiées de brouillon, rédigées automatiquement à partir du code, et une relecture juridique est annoncée comme nécessaire avant tout onboarding réel.
Oui selon les conditions générales et la politique de remboursement : un changement d'offre est possible à tout moment, avec application du nouveau tarif au cycle de facturation suivant.
La mise en place d'École Connect suit, sur le papier, un parcours simple : tester sans compte, choisir une offre parmi trois formules mensuelles, créer l'espace de l'établissement, puis activer les modules utiles par rôle. Le projet signale toutefois lui-même, de façon transparente, que ses pages légales restent des brouillons non validés juridiquement et que plusieurs aspects techniques (base de données, audit, validation des pièces jointes) sont dimensionnés pour un pilote plutôt que pour une mise à l'échelle — des points à examiner avec DYONYSOS avant tout déploiement réel.