FNDAperçu de la sécurité

Documents · Exploitation

Aperçu de la sécurité

Les mesures derrière l'art. 32, dans les mots d'un ingénieur.

Version
v1.0
En vigueur depuis
24 juillet 2026
Dernière mise à jour
24 juillet 2026
Sommaire
9 · 7 min de lecture

En bref

La mesure la plus forte, ce sont les données que nous refusons de collecter.

La sécurité au niveau des lignes empêche une requête de franchir la frontière d'une organisation, même avec du code fautif.

Une violation atteint l'organisation concernée en 24 heures.

Vous avez trouvé une faille ? security@findndo.app, et nous ne vous poursuivrons pas.

  1. 1.La minimisation d'abord

    L'essentiel de la sécurité de FND est une soustraction. La position en direct d'un enfant, un profil public, une recherche entre organisations et une inscription ouverte seraient chacune une catégorie de risque : aucune n'existe.

  2. 2.Contrôle d'accès

    1. 2.1La sécurité au niveau des lignes est appliquée sur chaque table : une requête ne peut pas franchir la frontière d'une organisation, même si le code applicatif se trompe.
    2. 2.2Les participants sont vérifiés sur place par l'équipe ; l'équipe est approuvée par la direction ; la direction est créée à l'achat.
    3. 2.3L'accès à la production reste limité à l'exploitant de FND, exige une authentification multifacteur et sert à la maintenance, pas à la lecture courante des données partenaires.
    4. 2.4Les secrets de service vivent hors du dépôt et sont renouvelés dès qu'une personne ou un outil n'en a plus besoin.
  3. 3.Chiffrement

    TLS pour tout ce qui transite, y compris l'app, l'espace et ce site. Chiffrement au repos pour la base et les fichiers stockés. Les mots de passe sont hachés par le fournisseur d'authentification et n'atteignent jamais notre code en clair.

  4. 4.Sauvegardes et restauration

    1. 4.1Sauvegardes quotidiennes avec restauration à un instant donné, conservées 30 jours.
    2. 4.2Les restaurations sont testées et non supposées : un exercice est mené avant chaque saison, pas après un incident.
    3. 4.3Un enregistrement supprimé peut subsister dans une sauvegarde chiffrée jusqu'à son expiration, et n'est jamais restauré sélectivement pour récupérer des données.
  5. 5.Réponse aux incidents

    Un exploitant, un téléphone, pas de file d'attente : un signalement atteint un humain directement, y compris hors heures ouvrées pendant la saison d'un partenaire.

    1. 5.1Contenir, évaluer, notifier : arrêter l'hémorragie, établir le périmètre, puis écrire aux organisations concernées dans les 24 heures suivant la prise de connaissance.
    2. 5.2La notification dit ce que nous savons, ce qui est touché et ce que nous faisons, pour qu'un responsable tienne son propre délai de 72 heures.
    3. 5.3Les incidents touchant des données partenaires donnent lieu à un post-mortem écrit, envoyé aux organisations concernées plutôt que classé.
  6. 6.Divulgation de vulnérabilités

    Si vous trouvez un problème de sécurité, nous voulons l'entendre et nous ne vous traiterons pas en attaquant pour nous l'avoir dit.

    1. 6.1Écrivez à security@findndo.app. Nous accusons réception sous 2 jours ouvrables et visons un correctif sous 30 jours pour un problème sérieux.
    2. 6.2N'accédez pas à des données qui ne sont pas les vôtres, ne les modifiez ni ne les exfiltrez, ne menez pas de test de déni de service ou de charge, et laissez-nous un délai raisonnable avant publication.
    3. 6.3Agissez dans cet esprit et nous n'engagerons aucune action en justice, et nous vous créditerons si vous le souhaitez.
    4. 6.4Il n'y a pas de prime aux bugs : FND, c'est une personne et un petit chiffre d'affaires ; prétendre le contraire vous ferait perdre du temps.
  7. 7.Demandes des autorités

    Nous répondons à une demande de la police, d'un tribunal ou d'un régulateur uniquement si elle nous lie juridiquement, si elle est précise, et si elle est fondée sur un droit qui s'applique à nous en Belgique.

    1. 7.1Une demande vague ou trop large est refusée ou restreinte avant toute production.
    2. 7.2Nous informons l'organisation concernée sauf interdiction légale, et nous disons qu'il y a eu interdiction dès qu'elle est levée.
    3. 7.3Nous ne pouvons pas produire ce qui n'existe pas : il n'y a aucun historique de position d'un participant à remettre.
  8. 8.Comment le code est construit

    1. 8.1Peu de dépendances, tenues à jour ; le site et l'app évitent totalement les scripts tiers.
    2. 8.2Les changements passent par un pipeline avec vérifications automatiques ; la production n'est jamais modifiée à la main.
    3. 8.3C'est le schéma de la base, pas le client, qui applique la règle sur qui peut lire quoi.
  9. 9.Ce que nous ne prétendons pas

    FND n'a ni rapport SOC 2, ni certificat ISO 27001, ni test d'intrusion par un cabinet nommé. Cela coûte plus que ce que cette société gagne aujourd'hui, et le prétendre serait un mensonge qu'une école peut vérifier.

    1. 9.1Ce qui existe figure sur cette page, se vérifie dans le produit, et est écrit pour pouvoir nous être opposé.
    2. 9.2Quand une certification deviendra réelle, elle apparaîtra ici avec sa date et son périmètre, pas avant.

Journal des modifications

  1. v1.024 juillet 2026

    • Première version publiée : le matériel de sécurité de l'accord de traitement et de la page sécurité, plus la divulgation de vulnérabilités et les demandes des autorités.

Publié par

FND (Find 'n Do)

Belgium

Autorité de contrôle

Gegevensbeschermingsautoriteit / Autorité de protection des données

www.gegevensbeschermingsautoriteit.be

Besoin d'une copie contresignée, d'un questionnaire fournisseur rempli, ou d'un article expliqué ? Un e-mail, un jour ouvrable.

Écrivez-nous