Centre de confiance Cyril
Nous nous engageons sur la sécurité, la confidentialité et la fiabilité de vos données. Cette page résume la posture de sécurité de Cyril, ses engagements de conformité et ses pratiques opérationnelles.
Pratiques de sécurité
Chiffrement en transit
Tout le trafic vers Cyril est chiffré en TLS 1.2 ou supérieur. Le HTTPS est imposé sur chaque point de terminaison ; les requêtes HTTP sont redirigées.
Chiffrement au repos
Les secrets d’intégration propres à chaque organisation, les jetons OAuth et les graines TOTP sont chiffrés au niveau applicatif avec une clé maîtresse conservée hors de la base de données. Les sauvegardes sont chiffrées avec age avant leur envoi vers le stockage objet. La base de données principale s’appuie sur le chiffrement de volume de l’hébergeur — AES-256 géré par le fournisseur.
Contrôles d’accès
Contrôle d’accès fondé sur les rôles, avec le moindre privilège par défaut. L’authentification multifacteur est imposée aux administrateurs de la plateforme et peut être rendue obligatoire à l’échelle de l’organisation par les administrateurs clients.
Gestion des vulnérabilités
L’analyse automatisée des dépendances (Dependabot + pnpm audit), l’analyse statique (CodeQL) et le scan des conteneurs (Trivy) conditionnent chaque déploiement en production. La divulgation coordonnée passe par notre programme de bug bounty.
Réponse aux incidents
Un manuel de réponse aux incidents documenté, avec des niveaux de gravité et des SLA nommés. Les violations de données à caractère personnel sont notifiées aux clients concernés dans les 72 heures suivant leur confirmation, conformément à l’article 33 du RGPD.
Isolation des locataires
Une base de données partagée, avec une isolation par ligne sur org_id imposée au niveau de la couche service. Des tests d’isolation inter-locataires sont exigés pour chaque type d’entité par notre Definition of Done. Aucune donnée n’est partagée entre locataires.
L’IA et vos données
Cyril intègre une couche IA au produit. Parce que cette couche lit vos données métier pour être utile, nous la soumettons aux mêmes règles d’accès que le reste de la plateforme, et nous disons explicitement ce qui sort de notre infrastructure.
L’IA ne voit que ce que vous voyez
L’IA de Cyril répond en tant qu’utilisateur individuel, pas au nom de l’organisation. La recherche documentaire est filtrée par les mêmes règles de propriété des enregistrements, de rôle et d’autorisations d’espace de travail que celles qui régissent l’interface : elle ne peut donc jamais faire remonter un enregistrement qui vous serait refusé à l’écran. C’est imposé dans le code — ce n’est pas une consigne donnée au modèle, que l’on pourrait contourner par la discussion.
L’application de la règle est testée, pas affirmée
Des tests automatisés d’isolation entre rôles s’exécutent à chaque modification et bloquent la livraison si un rôle moins privilégié parvient à récupérer les enregistrements d’un autre utilisateur via l’IA. Les recherches effectuées par l’IA sont en outre consignées dans un journal d’accès à des fins d’audit.
Les identifiants sont retirés avant toute sortie
Avant qu’une invite n’atteigne un fournisseur de modèle, les identifiants directs structurés — adresses e-mail, numéros de téléphone, adresses IP, numéros d’assurance nationale et de sécurité sociale, IBAN et numéros de carte — sont remplacés par des jetons réversibles, puis rétablis dans la réponse que vous voyez. Les identifiants noyés dans du texte libre, comme un nom de personne écrit au milieu d’une phrase, n’ont aucun motif fiable et ne sont pas remplacés.
Vous pouvez couper l’IA externe
Un administrateur d’organisation peut désactiver entièrement le traitement par un LLM externe pour son locataire. L’interrupteur est appliqué au point unique par lequel passe chaque appel d’IA et refuse l’appel avant même que le corps de la requête ne soit construit — pas au niveau de l’interface.
Une option sans sortie de données existe
Les organisations qui ne peuvent envoyer aucune donnée à un modèle tiers peuvent être routées vers une inférence auto-hébergée, exploitée dans notre infrastructure ou dans la leur. Cette voie ne comporte aucun repli vers un fournisseur public : soit la requête atteint le point de terminaison privé, soit elle échoue.
L’isolation des locataires vaut aussi pour l’IA
Chaque requête d’IA ou de recherche est cantonnée à une seule organisation. Deux organisations ne partagent jamais de résultats de recherche, ni de préfixe d’invite mis en cache chez un fournisseur de modèle.
Entraînement des modèles. Nous utilisons Anthropic et OpenAI via leurs offres API commerciales qui, selon les conditions publiées par ces fournisseurs, ne servent pas à entraîner leurs modèles. Le comportement d’entraînement des messageries grand public auquel on pense d’ordinaire ne s’applique pas au trafic API.
Ce qui reste en cours. Nous préférons vous le dire plutôt que de vous laisser le supposer. Deux engagements ne sont pas encore en vigueur : des accords de traitement des données contresignés avec chaque fournisseur de modèle au nom de notre entité d’exploitation, et des conditions Zero Data Retention qui suppriment la courte fenêtre de surveillance des abus pendant laquelle un fournisseur peut conserver une requête. Tant que les deux ne sont pas en place, les fournisseurs sont utilisés selon leurs conditions publiées standard, notre DPA client est proposé à l’état de projet plutôt que d’accord validé par un conseil juridique, et nous ne formulons aucun engagement contractuel de conservation au-delà de ce que ces conditions publiées prévoient. Les organisations qui ont besoin d’une garantie plus tôt peuvent recourir à l’interrupteur IA de leur locataire ou à l’option sans sortie de données ci-dessus. Nous mettrons cette section à jour, avec les dates, à mesure que chaque point aboutira.
Les contrôles techniques décrits ci-dessus proviennent d’un audit interne de notre posture de confiance en matière d’IA, écarts constatés et mesures prises compris. Il est disponible sur demande — écrivez à security@getcyril.com.
Conformité et certifications
SOC 2 Type 1
Préparation du premier audit
SOC 2 Type 1 est un prérequis à la disponibilité générale de Cyril. Le Type 2 suit six mois après l’attestation de Type 1. Nous ne détenons aucune certification à ce jour et aucun rapport d’audit n’est disponible.
RGPD
Conforme
Nous traitons les données à caractère personnel conformément au RGPD. Les droits des personnes concernées — accès, effacement, rectification et portabilité — sont pris en charge dans la plateforme.
Accord de traitement des données
Projet — en attente de revue juridique
Notre DPA est consultable dès maintenant, mais il n’a pas encore terminé sa revue juridique : il est publié comme un projet à évaluer, non comme un accord définitif. Les clients qui ont besoin d’un DPA signé peuvent nous contacter et nous leur confirmerons les délais.
Disponibilité et état du service
Cyril est un logiciel d’avant-lancement, en développement actif, et nos Conditions d’utilisation disent clairement qu’il n’existe ni engagement de disponibilité, ni accord de niveau de service. Nous ne publions ici aucun pourcentage de disponibilité, et il n’y a pas d’avoirs de service. En pratique, le service peut être interrompu pour maintenance, des fonctionnalités peuvent être brièvement indisponibles pendant un déploiement, et des défauts seront découverts en production parce que le produit est jeune.
Des niveaux de service et des délais de réponse du support n’existent que là où un bon de commande Enterprise les prévoit. Ils s’appliquent alors à ce client et prévalent sur la position générale ; aucun ne s’applique par défaut. Si vous avez besoin d’un niveau de service engagé avant de pouvoir adopter Cyril, c’est une discussion à avoir au moment du bon de commande, pas une hypothèse à tirer de cette page.
L’état du service en temps réel — incidents en cours, maintenances programmées et historique de disponibilité — se trouve sur status.getcyril.com. Cette page d’état est en cours de mise en place dans le cadre de notre durcissement avant la disponibilité générale ; en attendant, les clients peuvent s’abonner aux avis d’incident via le contact e-mail de leur organisation.
Sous-traitants ultérieurs
Certains tiers font partie du fonctionnement même de Cyril — l’hébergement, l’acheminement des e-mails, les fournisseurs de modèles derrière la couche IA. Toutes les organisations de la plateforme y ont recours, et aucun réglage ne permet de les désactiver. D’autres sont facultatifs : ils n’interviennent que lorsque quelqu’un de votre organisation active une intégration depuis Paramètres → Intégrations. Si l’intégration n’est jamais configurée, aucune donnée ne circule vers ce tiers.
Plutôt que d’en garder ici une seconde copie, la déclaration de référence — chaque fournisseur, ce qui lui est transmis, la région de traitement et les conditions de données qui l’engagent — est publiée intégralement sur /legal/sub-processors/.
Notification des changements. C’est sur cette page qu’un changement apparaît en premier : lorsqu’un sous-traitant ultérieur est ajouté, retiré ou remplacé, nous la mettons à jour en même temps que la date qu’elle porte. L’article 3.2 de l’Accord de traitement des données engage à un préavis écrit de 60 jours avant tout changement de fournisseur permanent, avec un droit d’opposition pendant ce délai. Le DPA reste un projet en attente de revue juridique : cet engagement est donc aussi ferme qu’un projet peut l’être — mais il figure dans le document que vous pouvez télécharger aujourd’hui, et nous préférons qu’on nous y tienne plutôt qu’il reste lettre morte. Pour être prévenu des changements de cette liste, écrivez à legal@getcyril.com.
Bug bounty
Nous menons un programme de divulgation coordonnée des vulnérabilités et accueillons les signalements de chercheurs en sécurité agissant de bonne foi. Les signalements éligibles sont crédités publiquement, et nous nous engageons à n’engager aucune action en justice contre les chercheurs qui respectent la politique.
Soyez parmi les premiers à utiliser Cyril.
Rejoignez la liste d’attente pour l’accès anticipé. Nous ne vous écrirons que lorsque nous aurons quelque chose de concret à partager.