School Base Cloud part du noyau de données fiable de votre école. Grâce à un partenariat de mise en œuvre accompagné et rémunéré, nous transformons les personnes, les élèves, les classes et les droits de contact précis en un premier périmètre vertical exploitable — défini et validé ensemble.
Illustration métier, pas une démonstration produit
| Élève | Attribut de contact | Statut du contact |
|---|---|---|
| Mia Example | Sortie | Contact principal et autorisation de sortie confirmés |
| Noah Example | Factures | Destinataire des factures attribué séparément |
| Lea Example | Justifications | Le droit parental de justifier une absence prend fin à la majorité |
| Sam Example | Informations | Contact pour les informations encore non résolu |
Données d’exemple fictives illustrant le modèle métier testé. Il n’existe pas encore d’interface produit utilisable.
Un secrétariat scolaire n’a pas besoin d’une liste de modules plus longue. Il lui faut des réponses fiables au quotidien. School Base Cloud commence donc par les fondations dont dépendront réellement les futurs processus d’absences, de bulletins et de paiements.
Tous les responsables légaux et contacts ne peuvent pas faire les mêmes choses. Les justifications d’absence, les bulletins, la sortie, les factures, les informations et le statut de contact principal sont traités séparément.
La règle testée met fin au droit d’un parent de justifier une absence au dix-huitième anniversaire. Les années scolaires et les classes sont préparées dans le modèle de données.
Lorsqu’un contact responsable manque, le point ouvert reste explicite. Votre équipe peut le résoudre au lieu de se fier à des données qui semblent seulement complètes.
Cette vue du modèle traduit la logique backend testée aujourd’hui en une matrice de droits lisible. Il ne s’agit délibérément pas d’une interface produit : la connexion, l’administration des rôles et les portails ne sont pas encore mis en œuvre.
La fiche de la personne et le dossier de l’élève restent séparés. Chaque relation porte ses propres responsabilités.
| Personne | Relation | Justifier | Venir chercher | Bulletin | Informations |
|---|---|---|---|---|---|
| Maria Beispiel | responsable légal | oui | oui | oui | oui |
| David Beispiel | pas responsable légal | non | oui | non | oui |
| Eva Beispiel | autorisé uniquement à venir chercher | non | oui | non | non |
Le modèle enregistre l’attribution vérifiée par l’école. Il ne prend aucune décision juridique.
Ces lacunes restent visibles sans bloquer l’inscription. Dans le noyau testé, le droit d’un parent de justifier une absence prend fin au dix-huitième anniversaire de l’élève.
Vue conceptuelle avec des données d’exemple fictives, dérivée du modèle métier testé. Il ne s’agit ni d’une véritable école ni d’une démonstration en direct.
Le socle actuel est volontairement restreint et vérifiable : 12 tests métier et 30 assertions couvrent les relations et règles essentielles du modèle de données.
Une personne et son rôle d’élève sont modélisés séparément, ce qui distingue l’identité du contexte scolaire.
Les tables et modèles pour les années scolaires, les classes et les affectations temporelles existent, mais ne sont pas encore éprouvés par une interface produit ni par des tests métier dédiés.
Justifier les absences, recevoir les bulletins, venir chercher un élève, recevoir les factures et obtenir des informations constituent des droits distincts.
Le contact principal est défini délibérément au lieu d’être déduit d’un ordre arbitraire.
Au dix-huitième anniversaire, la logique testée ne renvoie plus de parent autorisé à justifier une absence. Elle ne déduit pas de manière générale d’autres droits à partir de cette règle.
Les responsabilités de contact manquantes ou non résolues peuvent rester visibles et être traitées délibérément.
Ces tests prouvent le noyau métier, pas une application terminée. Il n’existe actuellement ni application ni interface utilisable, ni module prêt pour la production concernant les absences, les bulletins, les frais de scolarité, SEPA ou un portail parents.
Ensemble, nous définissons un processus qui devient réellement utilisable par un groupe d’utilisateurs nommé. Tout ce qui se trouve hors de ce périmètre vertical reste visible dans la liste des éléments non inclus.
La mise en œuvre est un travail produit commun avec un résultat de livraison défini. Vos collaborateurs responsables apportent les règles et des scénarios représentatifs ; nous les transformons en périmètre exploitable convenu.
Nous examinons votre blocage administratif le plus urgent, les rôles concernés et les sources de données que vous utilisez aujourd’hui.
Les utilisateurs, les données, les droits, les cas limites, les objectifs exclus et les scénarios de validation sont documentés avant le début de la mise en œuvre.
Nous construisons le processus convenu sur le noyau métier testé et le vérifions à l’aide de situations représentatives de votre école.
Les responsables nommés évaluent le périmètre utilisable. Les points ouverts restent documentés ; ce n’est qu’ensuite que vous décidez s’il doit y avoir une étape suivante.
School Base Cloud s’adresse aux écoles qui veulent résoudre correctement un processus administratif important et laisser les résultats réels guider la suite.
La technologie peut soutenir la responsabilité, mais elle ne peut pas la remplacer. Les décisions métier, le périmètre de livraison et la validation ont donc des responsables explicites tout au long du partenariat.
Vous décidez quelle personne reçoit chaque droit. School Base Cloud ne remplace pas l’examen juridique ou pédagogique.
Les nouvelles exigences ne sont pas ajoutées discrètement au périmètre actif. Leur impact, leur priorité et leur livraison sont discutés ensemble.
Le périmètre n’est pas considéré comme terminé à la suite d’une présentation. Il est validé lorsque les cas convenus ont été vérifiés et que les points ouverts sont explicites.
Le travail dépend de vos données actuelles, du périmètre convenu et du groupe d’utilisateurs concerné. Lorsqu’il existe une adéquation fonctionnelle, vous recevez une proposition complète avant de passer commande.
La proposition décrit ce qui sera livré et validé ensemble — et ce qui se trouve explicitement hors de la mission.
Le travail ponctuel de mise en œuvre et les éventuels éléments récurrents sont présentés séparément.
Les autres modules nécessitent un nouvel accord explicite. Ils ne constituent pas des hypothèses cachées de la première mission.
Non. Le noyau métier est testé, mais il n’existe pas encore d’application ni d’interface utilisable. L’offre est un partenariat de mise en œuvre accompagné et rémunéré qui livre un périmètre exploitable défini.
Les personnes, les élèves, les droits précis de responsabilité légale et de contact, la fin du droit parental de justifier une absence à la majorité et les lacunes de contact visibles sont éprouvés. Ils sont couverts par 12 tests métier et 30 assertions. Les années scolaires et les classes sont préparées dans le modèle de données, mais ne sont pas encore éprouvées par des tests dédiés ni par une interface produit.
Un processus utilisable couvrant les personnes, les élèves, l’affectation aux classes, les droits de contact et les responsabilités non résolues pour un groupe d’utilisateurs défini ensemble. Le périmètre exact découle de votre blocage le plus important.
Non. Ces modules ne sont pas prêts pour la production aujourd’hui. Si l’un d’eux est priorisé plus tard, il nécessite son propre périmètre, ses propres critères de validation et un accord distinct.
Un entretien initial permet d’établir votre point de départ et un périmètre vertical pertinent. S’il existe une adéquation fonctionnelle, vous recevez une proposition écrite indiquant le périmètre, les hypothèses, le coût et les exclusions.
Church, Campus, Club, School et Estate Base Cloud disposent chacun de leur propre site et de leur propre symbole produit. Le petit demi-nuage bleu constitue leur lien commun.
Montrez-nous où des contacts, des droits ou des affectations de classes peu clairs coûtent aujourd’hui du temps et de la confiance. Nous évaluerons ouvertement si cela peut devenir un premier périmètre exploitable pertinent pour votre école.
Demander un entretien initial