Dernière mise à jour : 23/08/2026
Cette page décrit, de façon honnête et vérifiable, les mesures de sécurité effectivement mises en œuvre sur Tavernaute — pas une liste d'intentions. Quand une mesure est partielle ou prévue mais pas encore construite, c'est indiqué comme tel plutôt que présenté comme acquis.
Les fondations qui protègent chaque page et chaque requête, sans que vous ayez à y penser.
| Mesure | Statut | Détail |
|---|---|---|
| HTTPS / TLS | Dépend de l'hébergement | Le chiffrement du transport (certificat TLS) est une responsabilité de l'hébergeur, pas du code applicatif. Tavernaute impose HTTPS dès qu'il est disponible : l'en-tête Strict-Transport-Security (HSTS) est envoyé sur toute connexion déjà en HTTPS, et toutes les requêtes non sécurisées sont marquées comme telles. |
| HSTS | Actif | Strict-Transport-Security: max-age=31536000; includeSubDomains — un an, sous-domaines compris. |
| CSP (Content-Security-Policy) | Actif, avec une limite assumée | Restreint le chargement de scripts/styles/images/polices aux domaines réellement utilisés (aucun domaine tiers non listé ne peut charger de contenu), interdit les balises <object>/<embed>, et empêche le site d'être chargé dans un cadre (frame-ancestors 'none', protection anti-clickjacking). Limite honnête : les pages utilisent des scripts intégrés directement (pas de compilation JS), donc 'unsafe-inline' reste nécessaire pour l'instant — une migration vers des scripts externes avec jetons ("nonces") est le prochain palier possible. |
| Cookies Secure / HttpOnly / SameSite | Actif | Le cookie de session est httpOnly (illisible en JavaScript, donc invulnérable au vol par XSS), Secure dès que le site est en HTTPS, et SameSite=Lax (bloqué sur une requête forgée depuis un autre site). |
| Protection XSS | Actif | Tout contenu affiché passant par un utilisateur est échappé avant affichage. La CSP (ci-dessus) ajoute une couche de défense supplémentaire en limitant ce qu'un script injecté pourrait charger. |
| Protection CSRF | Actif | Schéma à double cookie : un second cookie, lisible en JavaScript celui-là, doit être recopié dans un en-tête personnalisé sur chaque requête de modification. Un site tiers qui forge une requête ne peut pas lire ce cookie (règle de même origine du navigateur), donc ne peut pas reproduire l'en-tête. |
| Protection injection SQL | Actif | Toutes les requêtes vers la base de données passent par des requêtes préparées avec paramètres liés (aucune concaténation de valeurs saisies par l'utilisateur dans une requête SQL, nulle part dans l'application). |
La connexion se fait exclusivement par clé de sécurité (WebAuthn — empreinte, visage, ou clé physique) : il n'y a pas de mot de passe à deviner ou à réutiliser depuis une fuite ailleurs sur internet.
Chaque pseudo est unique (contrainte au niveau de la base de données, pas seulement une vérification en surface) et associé à un identifiant numérique unique, immuable, qui ne peut jamais être dupliqué ni réattribué.
La date de dernière réactualisation de votre pseudo est visible sur votre profil, avec un rappel à l'approche de l'échéance annuelle. Un pseudo qui n'est pas réactualisé n'est jamais libéré automatiquement pour un tiers (par choix : cela éviterait tout risque de confusion entre deux comptes portant le même nom) — c'est une invitation à confirmer que vous utilisez toujours ce compte, pas une sanction.
TavGuard est le système automatisé qui scanne en continu le salon général et les commentaires de profil en attente. Précision importante : ce n'est pas une intelligence artificielle générative (aucun modèle de langage externe n'est utilisé) — c'est un ensemble de règles :
TavGuard ne sanctionne jamais seul. Il signale au journal d'audit, consultable par l'équipe de modération, qui décide. Ce choix est volontaire : éviter qu'un faux positif automatique ne pénalise quelqu'un sans qu'un humain n'ait regardé.
Voir la section dédiée ci-dessous.
Chaque profil dispose d'un bouton « Bloquer », distinct des sanctions décidées par l'équipe. Un blocage coupe dans les deux sens les messages privés, le wizz et les commentaires de profil, et masque les messages de la personne bloquée dans votre propre vue du salon général (l'espace reste public et inchangé pour les autres membres).
Des membres disposant de rôles dédiés (facilitateur, médiateur, coordinateur, administrateur, créateur) peuvent avertir, mettre en sourdine, éjecter ou bannir selon la gravité — voir la charte d'utilisation pour le détail des rôles.
Pouvoir comprendre ce qui s'est passé, après coup si nécessaire.
Protéger Tavernaute même après un incident.
backup_cli.php) peut déclencher une sauvegarde quotidienne ; un bouton « Sauvegarder maintenant » est aussi disponible pour l'équipe administratrice.Les procédures ci-dessous engagent l'équipe qui exploite Tavernaute ; elles sont documentées pour que la réaction en cas d'incident ne s'improvise pas dans l'urgence.
En cas d'incident majeur (corruption de données, panne d'hébergement) : restauration de la dernière sauvegarde valide (après vérification d'intégrité), remontée du service, puis analyse de la cause avant réouverture complète si l'incident laisse suspecter une compromission plutôt qu'une simple panne.
Détection (alerte du tableau de bord, signalement, ou constat direct) → qualification de la gravité → mesures immédiates si nécessaire (verrouillage de compte, mise hors ligne temporaire d'une fonctionnalité) → correction → communication aux personnes concernées si leurs données ont pu être affectées.
Toute personne suspectant une compromission de son compte peut ouvrir un ticket de support. L'équipe peut immédiatement invalider toutes les sessions actives du compte (incrémentation du numéro de version du jeton — la ou les clés de sécurité compromises cessent de fonctionner) et accompagner la personne dans l'ajout d'une nouvelle clé de sécurité.
Si une fuite de données personnelles est constatée : confinement immédiat (rotation des secrets applicatifs si un secret a pu être exposé), évaluation du périmètre réellement touché, information des personnes concernées, et, si le RGPD l'impose au vu de la gravité, notification à la CNIL dans les délais réglementaires.
Les correctifs de sécurité identifiés sont priorisés et déployés en dehors des heures de forte affluence quand c'est possible, avec une sauvegarde préalable systématique.
Une fois l'incident résolu : vérification que toutes les fonctionnalités répondent normalement, revue des journaux de la période concernée pour confirmer l'absence d'activité résiduelle suspecte, puis publication d'un résumé de l'incident si sa gravité le justifie.
Un bouton de signalement est accessible depuis chaque message du salon général, chaque message privé, et chaque profil (photo comprise). Il suffit de :
Le signalement devient automatiquement un ticket dans notre système de support, avec un numéro de suivi. Les signalements pour « protection d'un mineur » sont automatiquement routés en priorité vers l'équipe administratrice, avec une alerte immédiate.
Tavernaute coopère avec les autorités compétentes dans le respect de la législation applicable.
La réglementation française (notamment la LCEN et ses textes d'application, dont le décret n° 2021-1362 relatif à la conservation des données techniques) prévoit des obligations de conservation de certaines données permettant d'identifier l'auteur d'un contenu ou la source d'une connexion, pour les catégories de données concernées, sur une durée pouvant aller jusqu'à un an à compter de la connexion ou de la création du contenu.
En pratique sur Tavernaute :
Note : ce paragraphe décrit le fonctionnement technique de la plateforme, pas un avis juridique. Pour toute question de conformité spécifique à votre situation, il est recommandé de consulter un professionnel du droit.
L'année de naissance, quand elle est renseignée, n'est jamais affichée publiquement sur un profil : elle ne sert qu'en interne (calcul d'âge pour les protections ci-dessus).
Tavernaute ne demande jamais à un mineur de publier lui-même des informations personnelles dans un espace public pour prouver son identité. Quand une information d'âge est nécessaire (par exemple pour le mode invité, voir plus bas), elle est saisie dans un champ de formulaire privé, jamais publiée.
Le mode invité (accès rapide au tchat sans clé de sécurité) exige une année de naissance et refuse toute inscription en dessous de 15 ans — l'âge numérique de consentement au traitement des données prévu par la réglementation française. Limite honnête : cette donnée reste auto-déclarée ; comme partout ailleurs sur internet, elle n'est pas vérifiée par un tiers indépendant.
Par honnêteté : les « salons adaptés » (espaces de discussion séparés selon l'âge) ne sont pas encore développés — l'application ne propose aujourd'hui qu'un salon général unique et des messages privés. C'est identifié comme une évolution possible plutôt que présenté comme déjà fait.