Sécurité

Cette page décrit les mesures techniques et organisationnelles mises en œuvre par Omnysia pour protéger vos données, conformément à l'article 32 du RGPD. Elle est publiée dans un souci de transparence et en complément des politique de confidentialité, CGU et CGV.

1. Principes directeurs

La sécurité d'Omnysia repose sur cinq principes :

• Minimisation — ne collecter et ne traiter que les données strictement nécessaires.
• Chiffrement par défaut — en transit systématiquement (TLS 1.3) et au repos pour les données sensibles.
• Isolation stricte — aucune donnée ne peut fuiter entre deux comptes utilisateurs.
• Traçabilité — toutes les actions sensibles sont journalisées et auditables.
• Honnêteté — nous documentons ce que nous faisons et ce que nous ne faisons pas, plutôt que de promettre ce que nous ne pouvons pas tenir.

2. Infrastructure d'hébergement

• Application SaaS — serveur virtuel privé (VPS KVM 2) Hostinger International Ltd, datacenter physique situé à Paris, France. Système Ubuntu 24.04 LTS, identifiant serveur srv1206458.hstgr.cloud. Les données applicatives et la base PostgreSQL auto-hébergée restent sur le territoire français et dans l'Union européenne.
• Site vitrine — hébergement Vercel Inc. (États-Unis, plan Hobby), contenus statiques uniquement, sans données personnelles stockées (hors cookies strictement nécessaires et courriels transmis via formulaire de contact).
• Base de données — PostgreSQL auto-hébergé sur le VPS Hostinger, isolation de la base applicative, accès réseau restreint.

3. Chiffrement

3.1 Chiffrement en transit

Toutes les communications entre votre navigateur et Omnysia, ainsi qu'entre Omnysia et ses sous-traitants, sont chiffrées via TLS 1.3 (HTTPS). Les certificats sont automatiquement renouvelés et la configuration est conforme aux recommandations ANSSI / Mozilla « intermediate » a minima.

3.2 Chiffrement au repos

• Jetons OAuth (Google, Microsoft, IMAP…) : chiffrés AES-256-GCM avant stockage en base.
• Mots de passe : stockés sous forme de hachage irréversible (bcrypt ou équivalent à l'état de l'art). Nous n'avons jamais accès à vos mots de passe en clair.
• Sauvegardes : chiffrées au repos.

Le chiffrement applicatif AES-256-GCM est appliqué aux jetons OAuth et secrets sensibles avant stockage en base. Le chiffrement de l'ensemble des données au repos au niveau du filesystem du serveur est en cours d'évaluation post-lancement ; la base PostgreSQL est, à ce jour, protégée par les contrôles d'accès système (clés SSH ED25519, accès réseau restreint) et les mesures d'isolation multi-tenant applicatives. Cette section sera mise à jour lors de l'activation du chiffrement disque complet.

4. Isolation multi-tenant

Chaque compte utilisateur (« tenant ») dispose d'un identifiant unique. Toutes les requêtes applicatives sont filtrées par cet identifiant au niveau de la couche d'accès aux données, empêchant tout accès croisé entre comptes.

Un chantier de renforcement de l'isolation multi-tenant (livré et testé avant le lancement public) a notamment inclus :

• une extension d'isolation durcie couvrant 82 routes applicatives ;
• 22 clés composites Prisma pour garantir l'unicité par tenant ;
• 13 tests de non-régression bout-en-bout (« leak tests ») exécutés sur base de données réelle, vérifiant qu'aucune donnée ne peut être lue par un autre tenant ;
• une migration graduelle documentée dans les rapports techniques internes.

5. Authentification et accès

• Authentification par courriel + mot de passe robuste (longueur minimale 12 caractères recommandée).
• Authentification multi-facteurs (MFA) disponible pour tous les Utilisateurs dès le lancement V1, activable depuis Paramètres > Sécurité. La MFA s'appuie sur un code temporel (TOTP, RFC 6238) généré par une application d'authentification (Google Authenticator, 1Password, Authy…), complété par 8 codes de secours à usage unique à conserver par l'Utilisateur en lieu sûr.
• Limitation du nombre de tentatives infructueuses et verrouillage temporaire.
• Sessions expirant automatiquement après inactivité prolongée.
• Accès administrateur au serveur restreint à l'éditeur (Warren-Georges Maunier), authentifié par clés SSH ED25519 sans mot de passe, avec journalisation des connexions.
• Piste d'audit côté applicatif sur les actions sensibles (connexion, modification de paramètres, activation / désactivation MFA, export, suppression, changement de plan).

6. Sauvegardes

• Sauvegardes chiffrées régulières de la base PostgreSQL.
• Conservation : 30 jours glissants avec rotation automatique.
• Procédure de restauration testée périodiquement.
• Les sauvegardes sont conservées sur le même prestataire que la production (Hostinger, Paris, France) dans l'Union européenne. Une option d'externalisation off-site chiffrée sera évaluée post-lancement pour renforcer la résilience.

7. Sécurité des sous-traitants

Nous sélectionnons nos sous-traitants selon trois critères : localisation des traitements, garanties de sécurité formelles et engagements RGPD (DPA article 28).

Sous-traitant	Rôle	Certifications / garanties publiques	Documentation
Hostinger	Hébergement applicatif et DB	Mesures de sécurité standard de l'industrie pour ses datacenters France (chiffrement, surveillance 24/7, redondance alimentation et réseau).	Politique Hostinger
Unipile SAS	Connexion email / calendrier, stockage jetons OAuth	SAS française (RCS Roanne 885 265 505), hébergement Scaleway France, conformité RGPD, DPA signé le 16 avril 2026	unipile.com
Anthropic	Modèle d'IA Claude	SOC 2 Type II, engagement contractuel de non-entraînement sur données API	Commercial Terms Anthropic — Trust Center
OpenAI	Fallback TTS / STT / LLM (activé en secours)	SCC, DPA disponible, engagement de non-entraînement sur données API	Politique OpenAI
Cartesia	Synthèse vocale (TTS)	SCC, politique de confidentialité publique	Politique Cartesia
Deepgram	Reconnaissance vocale (STT)	SOC 2, HIPAA (non sollicité), SCC	Politique Deepgram
LiveKit	Transport temps réel audio	Chiffrement du transport WebRTC via DTLS-SRTP (chiffrement TLS 1.3 point-à-point sur le lien client ↔ serveur SFU, non end-to-end). Les flux audio transitent par l'infrastructure LiveKit Cloud avant d'être traités par les sous-traitants vocaux (Deepgram STT + Cartesia TTS).	Politique LiveKit
Stripe	Paiement	PCI DSS niveau 1, DPF UE-USA	Politique Stripe
Resend	Courriels transactionnels	SCC, DPA disponible	Politique Resend
Google Workspace	Messagerie professionnelle Omnysia	ISO 27001, ISO 27017, ISO 27018, SOC 2/3, DPF UE-USA	DPA Google Workspace
Vercel	Hébergement vitrine statique	SOC 2 Type II, SCC	Politique Vercel

La liste détaillée des finalités et garanties de transfert pour chaque sous-traitant est publiée dans la politique de confidentialité.

Liste des sous-traitants mise à jour régulièrement. L'identité du prestataire en charge de la connexion email et calendrier multi-provider sera confirmée dans la présente page après signature du DPA correspondant, avant la mise en service publique.

8. Gestion des violations de données

Omnysia maintient un registre interne des violations de données personnelles. En cas de violation présentant un risque pour les droits et libertés des personnes concernées :

1. notification à la CNIL sous 72 heures à compter de la prise de connaissance (article 33 du RGPD) ;
2. information des personnes concernées si la violation présente un risque élevé (article 34 du RGPD), dans les meilleurs délais possibles, par courriel à l'adresse du compte ;
3. mesures correctives immédiates (révocation de jetons compromis, rotation de secrets, correctif applicatif) ;
4. post-mortem documenté dans le registre interne (cause racine, chronologie, périmètre, mesures adoptées), conservé au minimum 5 ans.

9. Signaler une vulnérabilité

Toute personne identifiant une vulnérabilité de sécurité est invitée à la signaler de manière responsable à security@omnysia.fr, en décrivant le problème, les étapes de reproduction et, si possible, une preuve de concept.

Nous nous engageons à :

• accuser réception sous 3 jours ouvrés ;
• ne pas engager d'action judiciaire à l'encontre des chercheurs de sécurité agissant de bonne foi, respectant la confidentialité et la minimisation de l'impact ;
• communiquer sur la résolution (patch) une fois celle-ci déployée, sauf contre-indication liée à la sécurité.

Ce programme de divulgation coordonnée est aligné avec l'article L. 2321-4 du Code de la défense.

10. Limites et transparence

Nous assumons plusieurs limites que la loi et la maturité du produit imposent :

• Pas de chiffrement de bout en bout. Les contenus doivent être déchiffrés côté serveur pour être traités par l'IA. Voir la politique de confidentialité, section 7.
• Pas d'engagement SLA chiffré en V1. Omnysia travaille en meilleur effort, avec une infrastructure dimensionnée pour une V1. Les prochaines phases pourront introduire des engagements contractuels de disponibilité.
• Pas de certification ISO 27001 / SOC 2 au lancement V1. Ces certifications sont exigeantes et coûteuses ; nous les envisagerons lorsque l'activité l'exigera et que le budget le permettra. En attendant, nous publions en transparence nos mesures concrètes sur cette page.
• Pas de bug bounty rémunéré en V1. Le programme ci-dessus fonctionne en divulgation coordonnée non rémunérée.