Sécurité

Où vivent les données

L’application, la base de données et les pièces jointes sont hébergées sur Microsoft Azure, région France Centre — des centres de données situés en France, sur le territoire de l’Union européenne. Rien n’est hébergé aux États-Unis.

L’exécution se fait en conteneurs isolés (Azure Container Apps), sur une base de données PostgreSQL gérée et un stockage d’objets pour les pièces jointes. L’établissement n’a aucun serveur à installer, à mettre à jour ou à sauvegarder : il n’y a rien dans vos locaux qui puisse tomber en panne, être volé, ou rester non corrigé.

En transit et au repos

Tous les échanges entre les navigateurs, les téléphones et nos serveurs passent en HTTPS. Aucune donnée ne circule en clair sur le réseau.

Le stockage est chiffré au repos par la plateforme Azure, base de données et pièces jointes comprises. Les en-têtes de sécurité HTTP du navigateur — dont une politique de sécurité du contenu en production — sont posés côté serveur pour limiter les injections et le détournement d’affichage.

Comptes et mots de passe

• Les mots de passe ne sont jamais stockés en clair : ils sont hachés avec bcrypt. Personne, y compris l’éditeur, ne peut lire le mot de passe d’un utilisateur.
• La double authentification (application d’authentification, avec codes de secours) est disponible sur les comptes d’administration. Son activation est recommandée pour la direction.
• Une révocation globale est possible : à un changement ou une réinitialisation de mot de passe, toutes les sessions ouvertes du compte deviennent immédiatement invalides, sans attendre l’expiration des jetons.
• Les tentatives de connexion et les appels à l’API sont limités en débit, pour freiner les essais automatisés.
• Un lien de réinitialisation de mot de passe est à usage unique et de courte durée ; le jeton correspondant est stocké haché, jamais en clair.

Le cloisonnement entre écoles

C’est le garde-fou le plus important d’un logiciel multi-établissements, et celui sur lequel nous acceptons le moins de souplesse : il est vérifié automatiquement à chaque modification du code.

Le contrôle des accès

Les droits sont appliqués côté serveur. Masquer un bouton dans l’écran ne protège rien ; ce qui protège, c’est que l’API refuse. Chaque appel est vérifié contre le rôle et les permissions du compte qui l’émet.

• Un parent ne peut obtenir que les données de ses propres enfants ; un enseignant, que celles de ses classes ; un chauffeur, que sa tournée.
• À l’intérieur de l’administration, l’établissement compose ses propres rôles — comptable, surveillant général, secrétariat — avec des permissions distinctes en lecture et en écriture.
• Les accès sont retirés immédiatement lorsque l’établissement désactive un compte.

Sauvegardes et réversibilité

La base de données bénéficie des sauvegardes automatiques de la plateforme Azure, avec possibilité de restauration à un instant donné. Les pièces jointes sont stockées sur un service redondé.

Surtout : vos données vous appartiennent et vous restent accessibles. Vous pouvez en demander l’export à tout moment pendant le contrat, et dans les trente jours qui suivent son terme. Aucune donnée n’est retenue comme moyen de pression, y compris en cas de litige commercial. Ce point est écrit noir sur blanc à l’article 8 des conditions générales.

Exploitation et déploiements

• Les secrets — clés, mots de passe de service, jetons — vivent dans la configuration de la plateforme, jamais dans le code source.
• Chaque mise en production passe par une chaîne automatisée qui exécute les tests avant de déployer : un test rouge bloque la livraison.
• Les migrations de base de données sont rejouées à blanc avant d’atteindre la production ; une migration qui échoue arrête la chaîne au lieu de casser le service.
• Les déploiements sont sérialisés : deux livraisons rapprochées ne peuvent pas se chevaucher sur l’environnement d’une école en activité.
• L’accès aux données de production est limité aux personnes qui en ont besoin pour l’exploitation et le support.

En cas d’incident

Si une violation de données venait à affecter un établissement, celui-ci serait prévenu sans délai injustifié, avec ce que nous savons au moment où nous le savons : ce qui s’est passé, quelles données sont concernées, ce que nous faisons, et ce qu’il lui revient de faire. L’établissement étant responsable de traitement, c’est à lui qu’il appartient d’accomplir ses propres notifications.

Nous préférons annoncer un incident tôt et de manière incomplète plutôt que tard et bien rédigé.

Ce que nous ne prétendons pas

Cette page ne revendique aucune certification. Talibi n’est ni certifié ISO 27001, ni qualifié SecNumCloud, ni attesté SOC 2, et n’a pas fait l’objet d’un test d’intrusion publié. Nous n’annonçons pas non plus de taux de disponibilité chiffré dans nos conditions générales.

Nous le disons parce qu’un directeur qui compare des solutions mérite de savoir où s’arrête ce que nous garantissons. Ce qui figure au-dessus est en revanche exact et vérifiable — et si une de ces affirmations vous paraît douteuse, demandez-nous de la démontrer.

Signaler une faille

Si vous découvrez une vulnérabilité, écrivez à contact@talibi.ma. Décrivez ce que vous avez trouvé et comment le reproduire ; nous accusons réception rapidement et vous tenons informé de la correction.

Nous vous demandons en retour de ne pas exploiter la faille au-delà de ce qui est nécessaire pour la démontrer, de ne pas accéder aux données d’un établissement, et de nous laisser le temps de corriger avant toute publication. Une divulgation menée de bonne foi dans ces conditions ne donnera lieu à aucune poursuite de notre part.