Mesures de sécurité.

Les actions d'administration font l'objet de vérifications de rôle appliquées côté serveur. L'accès à l'infrastructure cloud distingue des rôles pour chaque type d'acteur et d'actions.

Chaque utilisateur et chaque composant ne dispose que des permissions strictement nécessaires. Les autorisations sont vérifiées ressource par ressource et les identités techniques sont limitées à un périmètre précis.

Les fichiers et les conversations ne sont accessibles qu'à leur propriétaire. Les accès techniques aux données sont restreints aux ressources et aux actions nécessaires au fonctionnement du service. L'accès humain de l'équipe à ces contenus est limité aux personnes habilitées, soumis à une obligation de confidentialité, et restreint aux cas nécessaires au support, à la sécurité ou à la résolution d'un incident.

Les sessions ont une durée de validité limitée et expirent automatiquement. Les cookies de session sont inaccessibles aux scripts et transmis uniquement sur des connexions chiffrées.

Les accès de l'équipe à l'infrastructure passent par un annuaire d'identités centralisé, avec des rôles distincts selon le périmètre et des sessions à durée limitée.

Chaque requête est authentifiée et ses autorisations sont revérifiées côté serveur, indépendamment du réseau d'origine. Un accès obtenu précédemment ne confère aucun droit implicite sur les autres ressources.

Les applications s'exécutent sur Kubernetes. Les déploiements sont versionnés et réconciliés en continu, et les services critiques sont répliqués pour assurer la continuité du service.

Les environnements s'exécutent dans des comptes cloud distincts et sur des segments réseau séparés.

L'infrastructure est intégralement définie comme du code et versionnée, ce qui fournit un inventaire continu des ressources cloud et de leur configuration.

Les serveurs sont hébergés dans les centres de données de fournisseurs d'infrastructure cloud, qui assurent la sécurité physique des installations et disposent de leurs propres certifications.

Les conteneurs applicatifs s'exécutent sans privilèges d'administration, à partir d'images de base figées sur des versions vérifiées et réduites aux seuls composants nécessaires à l'exécution.

Le réseau est cloisonné en sous-réseaux publics et privés, répartis sur trois zones de disponibilité. Cette segmentation limite l'exposition des composants internes et renforce la résilience du service.

Les outils d'administration internes sont accessibles uniquement à travers un réseau privé virtuel, réservé aux membres autorisés de l'équipe.

L'accès aux ressources internes repose sur une approche zero trust : aucune interface d'administration n'est exposée sur Internet, et l'accès est lié à une identité vérifiée plutôt qu'à une position sur le réseau. Chaque appareil est enrôlé, authentifié individuellement et peut être révoqué.

Le service impose aux navigateurs l'usage exclusif de connexions chiffrées, interdit l'interprétation des contenus hors de leur type déclaré, limite les informations transmises lors de la navigation vers des sites tiers et désactive les fonctions sensibles du navigateur.

Les emails envoyés au nom du domaine sont authentifiés (SPF, DKIM) et une politique DMARC est publiée, avec collecte des rapports, afin de limiter les tentatives d'usurpation du domaine.

Les données stockées par le service sont chiffrées au repos (AES-256).

Les échanges entre les utilisateurs et le service sont chiffrés en transit, avec TLS 1.2 au minimum. L'accès au stockage de fichiers exige des connexions chiffrées.

Les secrets techniques (clés, identifiants, certificats) sont stockés dans un gestionnaire de secrets dédié et distribués aux applications en lecture seule, via des identités à périmètre restreint.

Les fichiers stockés sont privés et accessibles uniquement à leur propriétaire, et ceux transmis aux utilisateurs ne sont pas conservés par les caches intermédiaires. Les erreurs techniques renvoient des messages génériques et les contenus générés sont assainis avant affichage, afin de ne pas exposer d'informations internes.

L'usage de supports amovibles pour les données du service est interdit par une politique interne, portée à la connaissance de l'équipe.

Le stockage des fichiers est versionné, avec conservation des versions antérieures, ce qui permet une restauration en cas de suppression ou d'altération accidentelle.

Les services critiques sont répliqués sur plusieurs instances et l'infrastructure est répartie sur trois zones de disponibilité. Les composants défaillants sont détectés et remplacés automatiquement.

Les événements techniques et applicatifs sont collectés et centralisés à des fins de supervision et d'investigation. Les connexions au service sont journalisées.

Les dépendances applicatives, les composants d'infrastructure et les images de base font l'objet de mises à jour régulières via un processus automatisé. Les correctifs répondant à une vulnérabilité connue sont appliqués sans attendre le cycle habituel, et les dépendances comme les images déployées sont analysées périodiquement.

Le code de l'application est analysé automatiquement à chaque modification par un outil d'analyse statique orienté sécurité. Une vulnérabilité détectée bloque l'intégration de la modification jusqu'à sa correction.

Chaque version déployée est accompagnée d'un inventaire de ses composants logiciels et de leurs versions, rattaché de manière vérifiable à l'artefact publié.

Les images de base et les dépendances de construction sont figées sur des versions immuables. Les artefacts déployés sont signés, ce qui permet de vérifier leur origine et leur intégrité avant exécution.

Les configurations d'infrastructure et de déploiement sont décrites dans un dépôt versionné et appliquées automatiquement. Chaque changement est ainsi tracé, revu et réversible.

Toute vulnérabilité présumée peut être signalée à contact@emett.ai. Les signalements sont examinés et traités selon leur criticité.

Le traitement des données personnelles est documenté dans une politique dédiée. Les personnes concernées peuvent exercer leurs droits auprès d'un contact dédié (privacy@emett.ai), et les demandes sont traitées dans les délais prévus par le RGPD.

Un accord de traitement des données (DPA) est publié et s'applique automatiquement dès qu'Emett traite des données personnelles pour le compte d'un client. Il fait partie intégrante du contrat, sans signature distincte.

La liste des prestataires utilisés pour le service est publiée, avec pour chacun sa finalité, les données concernées et la localisation du traitement. Tout ajout ou remplacement est notifié au préalable et ouvre un droit d'objection motivée.

Les durées de conservation sont documentées par catégorie de données. Les traces techniques susceptibles de contenir des questions ou des réponses sont supprimées au plus tard trente jours après la suppression de la conversation correspondante.

Un utilisateur peut supprimer une conversation et les documents associés à tout moment. À la fermeture du compte, les données peuvent être restituées dans un format techniquement raisonnable pendant sept jours, puis sont supprimées.

En cas de violation de données personnelles, Emett notifie le client sans retard indu après en avoir pris connaissance, en précisant la nature de la violation, ses conséquences probables et les mesures prises.

Les clients peuvent obtenir les informations nécessaires pour vérifier le respect des engagements et réaliser des audits proportionnés. Emett assiste également ses clients pour les demandes des personnes concernées et les analyses d'impact.

Le service n'utilise pas de cookies publicitaires. Les traceurs non strictement nécessaires sont soumis au consentement lorsque la loi l'exige, et la mesure d'audience est opérée depuis l'Union européenne.

Les paiements sont traités par un prestataire de paiement certifié PCI DSS. Les données de carte bancaire sont collectées directement par ce prestataire et ne transitent jamais par les systèmes d'Emett.

Les données des clients ne sont pas utilisées pour entraîner des modèles d'intelligence artificielle.

Le service est conçu pour n'avancer aucune affirmation sans source. Les réponses s'appuient sur un corpus sélectionné, chaque citation renvoie au document d'origine et au passage précis, et une source manquante doit être signalée plutôt que comblée. Une citation qui ne peut pas être résolue est affichée en texte simple, afin qu'aucun lien ne donne l'apparence d'une source inexistante.

Les modèles utilisés sont identifiés et épinglés sur des versions précises, et leurs fournisseurs sont nommés dans l'accord de traitement des données. Les limites des réponses générées sont documentées dans les conditions générales d'utilisation.

L'utilisation des fonctions d'intelligence artificielle est encadrée par des quotas et supervisée en continu. Les traitements utilisent des jetons d'accès à portée limitée et le code est exécuté dans des environnements isolés et éphémères.