Politique de sécurité de l'information
Dernière mise à jour : 15 octobre 2026
Meet Aaron accède à la boîte mail et à l'agenda professionnels de ses utilisateurs pour rédiger, envoyer et suivre leurs messages de prospection. C'est un niveau d'accès considérable, et ce document décrit précisément comment il est protégé.
Chaque affirmation de ce document correspond à une mesure réellement en place. Les limites connues sont décrites telles quelles, à la dernière section.
1. Périmètre
Ce document couvre l'application Meet Aaron (https://meetaaron.app), son interface web, ses applications mobiles — qui ne sont que des coques affichant cette même application web — et l'infrastructure qui la fait tourner.
L'éditeur est Alexandre Fevre, entreprise individuelle australienne (ABN 72 369 751 951), exerçant sous le nom commercial Meet Aaron.
2. Données traitées
Données de compte : identité de l'utilisateur, adresse email, préférences, données de facturation.
Jetons d'accès à la messagerie : les jetons OAuth Google et Microsoft, ou les identifiants IMAP/SMTP, permettant d'envoyer et de lire les messages au nom de l'utilisateur.
Données de prospection : contacts professionnels saisis ou trouvés par l'application, et les échanges de messages avec eux.
Meet Aaron ne traite aucune donnée bancaire : les paiements passent par Stripe et aucun numéro de carte ne transite par nos serveurs ni n'est stocké.
3. Chiffrement
En transit : toutes les communications se font en HTTPS/TLS, sans exception. L'application n'est servie qu'en HTTPS, les appels aux interfaces de Google, Microsoft, Anthropic, OpenAI et Stripe sont en HTTPS, et les connexions à la base de données passent par TLS.
Au repos : la base de données et le stockage de fichiers sont chiffrés par l'hébergeur sur l'ensemble de leur contenu.
Chiffrement applicatif supplémentaire des jetons : les jetons d'accès aux messageries sont chiffrés AVANT d'être écrits en base, en AES-256-GCM, avec un vecteur d'initialisation aléatoire propre à chaque jeton et une étiquette d'authentification vérifiée au déchiffrement. La clé de chiffrement vit dans les variables d'environnement de la plateforme d'hébergement — jamais en base de données, jamais dans le code source.
Conséquence concrète et voulue : une copie de la base de données, à elle seule, ne donne accès à aucune boîte mail.
4. Authentification et contrôle d'accès
L'authentification des utilisateurs repose sur Supabase Auth. Chaque appel à l'interface de programmation porte un jeton signé, vérifié côté serveur à chaque requête.
Un identifiant d'utilisateur transmis en paramètre n'est jamais accepté sur parole : il est systématiquement comparé à l'identité portée par le jeton, et toute divergence est refusée.
Les jetons à usage unique servant à connecter une boîte mail depuis un téléphone sont de courte durée et consommés de façon atomique en base, ce qui les rend non rejouables.
Les tâches planifiées (vingt-sept au total) exigent toutes un secret partagé transmis en en-tête et refusent toute requête qui ne le porte pas.
5. Gestion des secrets
Tous les secrets — clés de base de données, clé de chiffrement des jetons, clés des fournisseurs d'intelligence artificielle, clés de paiement, secret des tâches planifiées, identifiants OAuth — sont stockés comme variables d'environnement de la plateforme d'hébergement.
Aucun secret ne figure dans le dépôt de code, y compris dans son historique. Ce point a fait l'objet d'une vérification dédiée.
Qui y accède. Les variables d'environnement ne sont lisibles et modifiables que par le propriétaire du projet d'hébergement, qui est l'unique personne de l'équipe ; ce compte est protégé par une double authentification. Aucun secret n'est partagé par messagerie ni stocké sur un poste de travail. Les clés sont nommées par service (une clé par fournisseur) : la révocation d'un fournisseur ne touche pas les autres.
Lecture et journalisation. Le code ne lit un secret qu'au démarrage de la fonction qui en a besoin, et ne le renvoie jamais au navigateur ni dans les journaux. Chaque création, modification ou suppression d'une variable d'environnement est consignée dans le journal d'activité de la plateforme d'hébergement (auteur, variable, date), consulté à chaque rotation. Les clés des fournisseurs sont également révocables et auditables depuis la console de chaque fournisseur.
Rotation. La clé de chiffrement des jetons supporte une rotation sans interruption : la nouvelle clé chiffre, l'ancienne reste acceptée en lecture le temps que les valeurs existantes soient réécrites, puis est retirée. Une clé est remplacée immédiatement en cas de soupçon d'exposition.
6. Sous-traitants
L'application s'appuie sur un nombre volontairement restreint de prestataires, tous nommés publiquement dans notre politique de confidentialité : l'hébergeur de l'application, l'hébergeur de la base de données et des fichiers, le prestataire de paiement, les fournisseurs de modèles d'intelligence artificielle, et un fournisseur de salles de visioconférence.
Les fournisseurs de modèles d'intelligence artificielle n'utilisent pas ces données pour entraîner leurs modèles et ne les conservent que temporairement, à des fins de sécurité.
7. Conservation et suppression
Les données sont conservées tant que le compte est actif.
Tout utilisateur peut supprimer son compte lui-même, sans nous contacter, depuis l'application. La demande ouvre un délai de vingt-quatre heures pendant lequel elle reste annulable, puis la suppression est exécutée automatiquement. Elle est définitive et effective sous trente jours.
Les jetons d'accès à une messagerie sont supprimés dès que l'utilisateur déconnecte le compte concerné. Il peut également révoquer l'accès directement depuis les paramètres de sécurité de son compte Google ou Microsoft, sans passer par nous.
Seules les données de facturation sont conservées au-delà, pour la durée imposée par la loi.
8. Journalisation
Les journaux d'exécution de l'application et ceux de la base de données sont conservés par les hébergeurs respectifs. Les erreurs serveur sont journalisées.
Aucun secret, aucun jeton et aucun mot de passe n'est écrit dans les journaux.
9. Développement et déploiement
Le code source est hébergé sur un dépôt privé. Les déploiements sont automatiques depuis la branche principale.
Les dépendances sont suivies et mises à jour ; les alertes de sécurité du dépôt sont traitées.
10. Limites connues
Nous préférons décrire nos faiblesses plutôt que de les laisser découvrir.
Autorisation portée par le code applicatif. La majorité des routes de l'interface de programmation accèdent à la base avec un rôle de service, qui contourne les politiques de sécurité au niveau des lignes. L'autorisation repose donc entièrement sur les vérifications effectuées dans le code, sans second filet au niveau de la base. Un audit complet des routes acceptant un identifiant d'utilisateur a été mené et toutes contrôlent l'identité de l'appelant. L'activation de politiques au niveau des lignes, comme deuxième barrière, est notre prochain chantier de sécurité.
Équipe d'une seule personne. Meet Aaron est développé et exploité par une personne. Il n'y a ni séparation des rôles ni revue de code par un pair. La contrepartie est une surface d'accès minimale : un seul détenteur des secrets, aucun sous-traitant interne, aucun accès partagé.
Pas de test d'intrusion externe à ce jour, en dehors de l'évaluation de sécurité conduite dans le cadre du programme CASA.
11. Contact
Pour toute question de sécurité : aaron@meetaaron.app.
Pour signaler une faille, merci de suivre notre politique de divulgation des vulnérabilités.
En cas d'incident, notre procédure de réponse à incident décrit ce que nous faisons et dans quels délais.