Solentra Signalements

Solentra Signalements est destiné aux centres de services scolaires et à leurs établissements. Le module couvre la vie complète d'un événement, de sa consignation par un intervenant jusqu'à sa comptabilisation dans les rapports transmis aux autorités.

Le module ne se contente pas d'enregistrer des événements. Il impose une catégorisation uniforme à l'échelle du centre de services, structure le traitement en étapes vérifiables et produit la reddition de comptes à partir de ce qui a déjà été consigné, sans ressaisie.

Sans outil commun, chaque établissement développe sa propre pratique. Les mêmes faits sont classés différemment d'une école à l'autre, ce qui rend les données du centre de services incomparables entre elles et fragilise la reddition de comptes au ministère.

Le second problème est la charge administrative. Les rapports annuels et les collectes d'information sont reconstruits manuellement à partir de formulaires papier, de chiffriers et de courriels, à chaque demande.

Les types d'événement sont définis par le centre de services et s'imposent à tous ses établissements. Une école ne peut pas créer son propre vocabulaire. C'est ce qui rend les données agrégeables.

Chaque type porte son formulaire, son vocabulaire et ses règles de traitement. Un type ajouté par le centre de services se comporte comme les types livrés.

C'est la distinction la plus importante à saisir sur ce module, et celle qui explique pourquoi deux centres de services peuvent l'utiliser sans travailler pareil. Solentra ne fournit pas une suite d'étapes figée qu'il faudrait épouser : il fournit un moteur de cheminement, et les étapes sont une donnée que l'administration définit.

Un cheminement se compose de trois choses, réglées séparément.

Le découpage ci-dessous est celui retenu par des centres de services en service. Il illustre le moteur ; il n'en est pas la définition, et un autre centre de services peut en configurer un tout autre.

Les relances et l'acheminement des dossiers ne sont pas dispersés dans le cheminement : ils sont réunis à un seul endroit, ce qui permet de voir d'un coup d'œil tout ce que le système fait de lui-même. C'est la contrepartie nécessaire d'un outil qui envoie des courriels à des directions d'établissement.

Les interventions sont consignées sur des fiches distinctes et numérotées, rattachées au dossier. Des modèles de consignation, définis par l'administration, structurent la saisie sans l'imposer.

Un lot d'interventions prédéfinies peut être chargé d'un coup pour amorcer un suivi type. Les interventions déjà consignées ne changent pas lorsqu'un modèle évolue : un dossier reflète ce qui a été écrit au moment où il l'a été.

Le module distingue trois rôles principaux, chacun avec son tableau de bord et son périmètre. Les accès ne sont pas attribués utilisateur par utilisateur : ils découlent du corps d'emploi tel qu'il est connu du système de paie.

L'administration du centre de services conserve la main pour ajuster un accès à la pièce, sans passer par les services informatiques.

Les formulaires se modifient depuis l'interface d'administration, sans développement. Champs, libellés, caractère obligatoire et comportement se règlent par type d'événement.

Des formulaires publics distincts peuvent être ouverts aux élèves, au personnel et aux parents. Leur activation se décide établissement par établissement.

Le module permet d'écrire aux parents depuis le dossier de l'élève, avec des modèles de message préremplis. Les coordonnées proviennent du référentiel de l'établissement.

L'envoi n'est jamais automatique. Une personne habilitée déclenche la communication après avoir validé le contenu, et l'échange est versé au dossier.

Le centre de services suit les dépôts attendus de chaque établissement dans une grille unique : qui a remis quoi, et qui est en retard.

Le rapport sommaire n'est pas un export de confort. C'est la pièce par laquelle une école répond de son traitement devant la direction générale du centre de services, et par laquelle un dossier de violence à caractère sexuel remonte au protecteur régional de l'élève.

Il ne part pas pour tous les dossiers. Le déclencheur est le dépôt d'une plainte, ou la nature de l'événement.

Une plainte arrive souvent après la clôture de l'événement. Le dossier doit alors pouvoir évoluer sans que disparaisse ce qui a déjà été transmis : une version antérieure du rapport circule peut-être déjà.

Chaque nouvelle version indique donc ce qui a changé depuis la précédente, et la personne qui la produit atteste de l'exactitude des renseignements sous son nom. Les versions antérieures restent consultables avec leur état de transmission.

L'obligation de transmettre pèse sur l'école, mais le manquement engage le centre de services. Un tableau de suivi lui indique quels rapports n'ont pas été transmis dans le délai, école par école.

Ce n'est pas un instrument de contrôle : beaucoup de directions sont nouvellement en poste et ignorent une partie de leurs obligations. L'écran sert à les accompagner avant que l'oubli devienne un problème juridique.

À côté du rapport sommaire, qui suit un dossier, les analyses portent sur l'ensemble. Seuls les dossiers approuvés et traités y entrent ; un dossier arrêté ou déclaré non applicable après analyse ne compte pas dans les statistiques.

Chaque accès, création, modification et transmission est horodaté et attribué. Le journal n'est pas un résumé lisible du dossier : c'est une piste d'audit, exportable, destinée aux processus de plainte et aux contrôles.

Un dossier ne peut pas être supprimé. Les doublons et les dossiers caducs sont archivés, jamais effacés.

Les données d'une plateforme existante sont importées avant la mise en service, avec remappage des utilisateurs pour que chaque intervenant retrouve son historique. Les dossiers antérieurs restent consultables dans le nouvel environnement.