← Retour aux préférences

Politique de réponse aux incidents de sécurité

Dernière mise à jour : 15 octobre 2026

Meet Aaron accède à la boîte mail et à l'agenda professionnels de ses utilisateurs. Un incident de sécurité sur ce service peut donc exposer de la correspondance professionnelle, et ce document décrit exactement ce qui se passe dans ce cas : comment un incident est détecté, qui agit, dans quels délais, et qui est averti.

Les délais annoncés ici sont ceux d'une entreprise individuelle. Ils sont volontairement modestes plutôt qu'ambitieux : un délai annoncé est un délai tenu.

1. Périmètre

Ce document couvre l'application Meet Aaron (https://meetaaron.app), ses interfaces de programmation, ses applications mobiles — qui ne sont que des coques affichant cette même application web — et les comptes d'hébergement et de base de données qui la font tourner.

L'éditeur et seul responsable de la réponse aux incidents est Alexandre Fevre, entreprise individuelle australienne (ABN 72 369 751 951), exerçant sous le nom commercial Meet Aaron.

2. Ce que nous appelons un incident

Est traité comme incident de sécurité tout événement qui compromet, ou peut compromettre, la confidentialité, l'intégrité ou la disponibilité des données des utilisateurs :

Un simple dysfonctionnement sans conséquence sur les données — une page qui s'affiche mal, un bouton qui ne répond pas — n'est pas un incident de sécurité et suit le traitement de bogue ordinaire.

3. Niveaux de gravité

P1 — Critique. Données d'utilisateurs accessibles par un tiers, jetons d'accès exposés, ou envoi de messages non autorisés en cours. Traitement immédiat, avant toute autre tâche.

P2 — Élevé. Faille exploitable identifiée mais sans preuve d'exploitation, ou compromission d'un compte de service sans accès aux données utilisateurs.

P3 — Modéré. Faiblesse réelle mais dont l'exploitation suppose des conditions improbables, ou indisponibilité du service sans perte de données.

P4 — Faible. Écart de configuration ou de bonne pratique sans voie d'exploitation identifiée.

4. Détection

Un incident peut nous parvenir par quatre voies :

Nous ne disposons pas d'un centre de surveillance permanent. Les alertes automatiques arrivent par courriel et par notification mobile, et sont relevées aux heures ouvrées australiennes (AWST).

5. Rôles

Meet Aaron est édité par une seule personne. En cas d'incident, cette personne cumule les rôles de coordinateur, d'analyste technique et de point de contact pour les utilisateurs et les autorités.

C'est une limite et nous la déclarons comme telle à la dernière section. Son revers est qu'il n'y a aucune chaîne d'escalade à remonter : la décision de couper le service, de révoquer tous les jetons ou de notifier les utilisateurs peut être prise en quelques minutes.

6. Procédure de réponse

Étape 1 — Confinement. Avant tout diagnostic, arrêter l'exposition. Selon l'incident : révocation des jetons d'accès concernés, désactivation des tâches planifiées qui envoient des messages, suspension du compte compromis, retrait en ligne de la version fautive, ou mise hors service du site si rien d'autre ne suffit. Couper le service est une décision acceptable ; laisser une fuite ouverte pendant l'enquête ne l'est pas.

Étape 2 — Évaluation. Déterminer ce qui a été atteint, par qui, pendant combien de temps, et quels utilisateurs sont concernés. Les journaux d'accès de l'hébergement et de la base de données sont conservés à cette fin.

Étape 3 — Éradication. Corriger la cause, pas seulement le symptôme : rotation de tous les secrets susceptibles d'avoir été exposés, correctif de code, fermeture de l'accès utilisé.

Étape 4 — Rétablissement. Remettre le service en ligne, vérifier que la voie d'accès est fermée, surveiller les journaux de façon rapprochée pendant les sept jours qui suivent.

Étape 5 — Notification. Informer les personnes concernées et, le cas échéant, les autorités et les prestataires, selon la section 8.

Étape 6 — Revue. Consigner l'incident par écrit et en tirer une mesure concrète, selon la section 9.

7. Délais

Les délais ci-dessous courent à partir du moment où l'incident nous est connu, et non du moment où il s'est produit.

Le délai de notification réglementaire de 72 heures prévu à la section 8 n'est pas un objectif : c'est une obligation légale, et il prime sur tout le reste, y compris sur le fait de disposer d'un diagnostic complet. Une notification partielle dans les délais vaut mieux qu'une notification complète en retard.

8. Notification

Aux utilisateurs concernés. En cas de violation de données personnelles susceptible de leur porter atteinte, nous les informons par courriel à l'adresse de leur compte, sous 72 heures à compter de la prise de connaissance. Le message indique ce qui s'est passé, quelles données sont concernées, ce que nous avons fait, et ce qu'ils doivent faire de leur côté.

Aux autorités de protection des données. Pour les utilisateurs établis dans l'Union européenne, nous notifions l'autorité compétente sous 72 heures lorsque le RGPD l'exige. Pour l'Australie, nous notifions l'Office of the Australian Information Commissioner lorsque le régime des Notifiable Data Breaches s'applique, et nous le faisons volontairement lorsqu'un doute subsiste sur son applicabilité à une entreprise de notre taille.

Aux prestataires. Si l'incident implique Google, Microsoft, Supabase, Vercel, Stripe, Anthropic ou OpenAI, nous les informons par leurs canaux de signalement dédiés. Pour les données issues des interfaces Google, nous respectons les obligations de notification du programme de vérification OAuth.

Publiquement. Un incident de niveau P1 ayant touché des données d'utilisateurs fait l'objet d'une description écrite publiée après rétablissement, sans détail exploitable et sans information permettant d'identifier un utilisateur.

9. Preuves et revue

Chaque incident, à partir du niveau P3, donne lieu à une fiche écrite conservée au moins deux ans : date de détection, voie de détection, gravité retenue, chronologie des actions, données concernées, cause racine, et la mesure prise pour que cela ne se reproduise pas.

Une revue est menée dans les deux semaines qui suivent le rétablissement. Elle doit produire au moins une modification concrète — un correctif, un contrôle supplémentaire, une alerte, une procédure — et non un simple constat. Un incident sans mesure corrective est considéré comme non clos.

10. Limites connues

Nous préférons les déclarer plutôt que de laisser croire à des moyens que nous n'avons pas :

11. Contact

Pour signaler un incident en cours : aaron@meetaaron.app, avec « INCIDENT » en objet.

Pour signaler une faille non encore exploitée, suivez notre politique de divulgation des vulnérabilités.

Les mesures de sécurité en place sont décrites dans notre politique de sécurité de l'information.

Voir aussi notre politique de confidentialité et nos conditions d'utilisation. En cas de divergence entre les versions, la version anglaise prévaut.