Sécurité

Ce qui protège le service, ce qu’il ne prétend pas garantir, et comment nous signaler une faille.

Dernière révision : 11 août 2026

Texte de prototype, non validé juridiquement.Il décrit fidèlement le fonctionnement technique du système. Les mentions qui dépendent de l’administration exploitante sont signalées et doivent être complétées avant toute mise en service.

Position honnête

Aucun système connecté ne peut promettre qu’il ne sera jamais attaqué. L’objectif tenable est autre : réduire la probabilité, limiter le rayon d’impact, détecter vite, prouver ce qui s’est passé et rétablir le service. Les pages de ce site n’affirment donc rien qui ne soit vérifiable.

Mesures en place

  • Chiffrement applicatif des identités avec des clés séparées de la base, et recherche exacte par empreintes poivrées — aucun NINA en clair.
  • Cloisonnement imposé par la base : le périmètre est dérivé de la session et appliqué par des politiques de sécurité au niveau des lignes, sous un rôle applicatif qui n’est ni propriétaire ni superutilisateur. Un défaut de code ne suffit donc pas à franchir la frontière entre deux postes.
  • Journal append-only chaîné par hachage et scellé, vérifiable de l’extérieur via le vérificateur de preuve.
  • Vérification citoyenne par recoupement de trois faits — lieu de dépôt, identifiant et date de naissance complète —, réponses uniformes, temps de réponse égalisé et quotas : essayer des numéros au hasard n’apprend rien et ne passe pas à l’échelle.
  • Portes d’entrée séparées pour les citoyens, les postes, le service central et l’exploitant. Ce n’est pas de l’authentification : c’est de la surface exposée en moins.
  • En-têtes de sécurité stricts : politique de sécurité du contenu à nonce, aucune inclusion tierce non déclarée, transport chiffré épinglé lorsque le service est servi en HTTPS.
  • Actes sensibles à deux personnes et journalisation des consultations privilégiées, y compris celles des journaux.

Ce que nous ne prétendons pas

  • Le prototype n’a pas fait l’objet d’un audit de sécurité externe ni d’une homologation. Audit à planifier avant mise en service.
  • Un compte d’agent compromis reste un risque : le cloisonnement limite ce qu’il peut atteindre, il ne l’annule pas.
  • Le chaînage du journal prouve qu’un événement enregistré n’a pas été modifié. Il ne prouve pas qu’un événement jamais enregistré n’a pas eu lieu.

Signaler une faille

Les signalements de bonne foi sont bienvenus et traités sans hostilité. Nous demandons une divulgation coordonnée : laissez-nous corriger avant de publier.

  • Canal de signalement : adresse de contact sécurité à compléter, avec une clé publique de chiffrement.
  • Ce qui aide : la description du défaut, les étapes de reproduction, la date et l’heure, l’effet obtenu. Pas besoin de rédiger un rapport formel.
  • Ce que nous demandons : ne pas exfiltrer de données réelles, ne pas dégrader le service, ne pas accéder à un dossier qui n’est pas le vôtre au-delà de ce qui démontre le défaut.
  • Hors périmètre : dénis de service volumétriques, ingénierie sociale d’agents, envoi massif de messages, et défauts déjà décrits ci-dessus.

Vous n’êtes pas chercheur en sécurité ?

Une anomalie ordinaire — un état qui ne correspond pas au guichet, un message reçu pour un dossier qui n’est pas le vôtre, une personne réclamant un paiement — se signale par la voie décrite dans l’aide. C’est utile : plusieurs défauts se voient d’abord depuis le guichet.

Délai de première réponse visé, engagement de non-poursuite pour la recherche de bonne foi et modalités de remerciement : à arrêter avant mise en service.