La sécurité est au cœur de notre façon de construire. Cette page décrit ce qui est réellement vrai aujourd’hui de notre architecture et de nos pratiques — et non une liste de cases à cocher marketing. Lorsque nous n’avons pas terminé quelque chose (un audit formel, une certification), nous le disons clairement plutôt que de laisser entendre le contraire.
Santé et HIPAA
Aujourd’hui, les produits de Divinci ne sont pas approuvés pour les informations de santé protégées (PHI). Aucun Business Associate Agreement ne couvre la plateforme Divinci, et vous ne devez pas y déposer de PHI.
Nous préparons une offre distincte pour le secteur de la santé : un runtime de chat dédié, hébergé dans son propre projet Google Cloud et séparé du reste de la plateforme Divinci. Il est conçu pour ne pas conserver les transcriptions des conversations. Nous ne signons pas encore de Business Associate Agreements.
Ce que ceci n’est pas : une certification de conformité HIPAA. Il n’existe aucun certificat HIPAA délivré par une autorité gouvernementale, et nous ne prétendons pas être conformes à HIPAA. La conformité résulte d’un ensemble de mesures techniques, de politiques écrites et de Business Associate Agreements signés avec chaque fournisseur du chemin de données, évalués pour chaque relation client. Nous avons adopté des politiques écrites, encore en cours de revue juridique, et nous l’indiquerons ici dès que cela changera.
Protection des données
Chiffrement
- En transit : TLS partout entre les clients, notre périphérie (edge) et notre infrastructure d’origine.
- Au repos : chiffrement au niveau du fournisseur sur notre base de données principale et notre stockage d’objets, plus une couche dédiée de chiffrement au niveau des champs pour les champs sensibles désignés.
- Gestion des secrets : les identifiants et clés d’API sont gérés via un gestionnaire de secrets centralisé, et non codés en dur ou stockés en clair dans la configuration. La production est configurée pour échouer en mode fermé plutôt que de basculer silencieusement sur des identifiants périmés si le service de secrets est injoignable.
Minimisation des données
- La rédaction (masquage) optionnelle des PII (Microsoft Presidio) peut être appliquée au contenu des conversations avant son stockage ou son envoi à un fournisseur d’IA. Il s’agit d’une détection d’entités, et non d’une détermination de dés-identification au sens de HIPAA ; elle ne rend pas un produit apte à traiter des PHI.
- Les journaux ne contiennent que des métadonnées, par principe : nous n’écrivons pas le contenu des messages, les adresses e-mail ni d’autres données personnelles dans les journaux applicatifs ou les messages d’erreur.
Contrôles d’accès
- Authentification via Auth0.
- Contrôle d’accès basé sur les rôles (au niveau de la plateforme) plus des permissions par ressource (au niveau du document ou de l’espace de travail) — moindre privilège par défaut.
- Journalisation d’audit infalsifiable : l’accès aux enregistrements sensibles est consigné dans un journal chaîné par hachage, conçu pour que les entrées ne puissent pas être modifiées discrètement après coup.
- Revues trimestrielles des accès et de la configuration des services de production.
Sécurité applicative
- Défense XSS à la frontière de rendu : les contenus générés par les utilisateurs et par l’IA sont assainis (DOMPurify) partout où ils sont rendus sous forme de HTML ; l’injection de HTML brut provenant de sources non fiables n’est pas autorisée.
- Tests d’autorisation : nous menons nos propres tests de sécurité manuels et assistés par IA contre les environnements de préproduction et de production, y compris des sondages authentifiés d’autorisation/IDOR — il ne s’agit pas (encore) d’un programme récurrent de tests d’intrusion réalisés par un tiers, et nous n’allons pas en revendiquer un tant qu’il n’existe pas.
- Revue des dépendances et du code : revue de code standard sur toutes les modifications ; mises à jour des dépendances suivies par notre outillage de build habituel.
Disponibilité et surveillance
- Surveillance synthétique des points d’accès exposés aux clients, avec alerte de l’astreinte via PagerDuty dans les minutes qui suivent une panne réelle, et pas seulement en cas d’erreurs serveur — des vérifications avec contrôle du contenu, pas seulement « a-t-il renvoyé 200 ».
- Infrastructure multi-régions (périphérie Cloudflare + origine Google Cloud) avec sauvegardes automatisées de notre base de données principale.
- Nous ne publions pas actuellement de SLA contractuel de disponibilité. Si votre cas d’usage en exige un, demandez-nous — nous pouvons discuter de ce qui est réaliste pour votre déploiement.
Réponse aux incidents
Nous maintenons un processus documenté de réponse aux incidents : détection et classification, confinement, évaluation honnête de la question de savoir si un incident constitue une violation à déclarer, remédiation, et un post-mortem sans recherche de coupable qui alimente en retour ce que nous surveillons ensuite. Si vous êtes client sous un Business Associate Agreement conclu avec nous, cet accord précise nos obligations de notification à votre égard — ce sont ces termes qui font foi, et non cette page.
Pour signaler un problème de sécurité ou une vulnérabilité présumée, écrivez à security@divinci.ai. Nous n’exploitons pas actuellement de programme formel de primes aux bogues (bug bounty) ; nous prenons néanmoins les signalements au sérieux et travaillerons avec vous de bonne foi.
Où nous en sommes concernant les certifications formelles
Soyons directs à ce sujet, puisque beaucoup de pages de sécurité ne le sont pas :
- HIPAA : nous ne détenons aucune certification HIPAA et ne revendiquons aucune conformité. Voir « Santé et HIPAA » ci-dessus.
- SOC 2 : pas encore commencé. C’est à notre feuille de route ; nous mettrons cette page à jour lorsqu’il y aura quelque chose de réel à annoncer — pas avant.
- ISO 27001, FedRAMP, PCI DSS : nous ne détenons pas ces certifications. Les paiements par carte sont traités par Stripe ; Divinci ne stocke pas directement les données de porteurs de carte.
Nous préférons en revendiquer moins ici et être dignes de confiance, plutôt que d’en revendiquer trop et devoir ensuite faire marche arrière.
Contact
Questions de sécurité, signalements de vulnérabilités ou questions de conformité pour un contrat spécifique : security@divinci.ai