> ## Documentation Index > Fetch the complete documentation index at: https://ayakaleaf-pro.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Confiance et sécurité > Comprenez le traitement des données, la livraison des builds et les responsabilités en matière de sécurité. Ayakaleaf Pro s'exécute dans votre infrastructure. Vous contrôlez ses données, ses accès et ses frontières réseau. Cette page présente le modèle de sécurité par défaut et identifie également vos responsabilités opérationnelles. ### Ayakaleaf Pro est-il fiable et sécurisé ? Ayakaleaf Pro est une amélioration auto-hébergée d'Overleaf Pro, et notre code source est disponible sur [ayaka-notes/ayakaleaf-pro](https://github.com/ayaka-notes/ayakaleaf-pro). Votre déploiement détermine où s'exécutent les services et où résident les données. La sécurité dépend de votre configuration et de votre exploitation. Protégez les accès administrateur, activez HTTPS et maintenez des sauvegardes. Merci à OpenAI pour son aimable soutien. Nous utilisons régulièrement [Codex Security](https://chatgpt.com/codex/cloud/security/findings) pour analyser notre dépôt à la recherche de problèmes de sécurité, et nous partageons publiquement les résultats des corrections de vulnérabilités. ### Où vont mes données ? Par défaut, les données de l'application restent au sein de votre déploiement : * MongoDB stocke les données des utilisateurs et des projets. * Redis stocke le cache et les données de collaboration en temps réel. * Des volumes locaux ou un stockage compatible S3 contiennent les fichiers des projets. Seul le service web est exposé par défaut. Les services internes communiquent via le réseau Docker. ### Mes données seront-elles envoyées à des tiers ou récupérées auprès de tiers ? Rien ne quitte votre déploiement, sauf si vous activez une fonctionnalité qui l'exige. Ayakaleaf Pro n'envoie *aucune télémétrie, aucune statistique d'utilisation et aucun rapport de plantage*. Le signalement des erreurs et les statistiques sont désactivés dans la configuration par défaut. Plusieurs fonctionnalités n'effectuent jamais aucune requête externe. Les modèles sont stockés et servis depuis votre propre déploiement. L'exécuteur de scripts Python s'exécute dans le navigateur de l'utilisateur via WebAssembly, et son environnement d'exécution est servi par votre propre service web plutôt que par un CDN public : le code et la sortie des scripts n'atteignent donc jamais le réseau. Git Bridge n'est accessible que sur le réseau Docker interne. La recherche dans tout le projet, la palette de symboles, le suivi des modifications, l'historique des projets et le panneau d'administration sont entièrement locaux. Les conteneurs de compilation en sandbox sont créés avec le réseau désactivé. Les requêtes des autres fonctionnalités atteignent les destinations suivantes. Chaque requête provient du service web : Les fonctionnalités d'IA sont désactivées par défaut. Lorsqu'elles sont activées, le chat et les suggestions pour les erreurs LaTeX envoient des prompts et le contexte pertinent du projet au point de terminaison du modèle configuré avec `AI_BASE_URL`. La recherche web facultative envoie des requêtes au service compatible Tavily configuré, et la recherche dans la documentation envoie des requêtes à `DOCS_MCP_URL` (par défaut : `https://docs.overleaf.com/~gitbook/mcp`). Les résultats de recherche peuvent être inclus dans les requêtes envoyées au fournisseur du modèle. Consultez [Intégration de l'IA](/fr/on-premises/configuration/overleaf-toolkit/ai-integration "mention") pour la configuration et les contrôles utilisateur. L'**intégration GitHub** contacte `github.com` et `api.github.com`. Elle s'active par utilisateur en liant un compte GitHub, et l'autorisation demande les scopes `read:org`, `repo` et `workflow`. Un push téléverse le contenu complet des fichiers du projet sous forme de blobs Git, ensuite assemblés en arbres et en commits. Elle effectue également des opérations sur les branches, les références, les comparaisons et les fusions, et lit le profil du compte lié, ses appartenances à des organisations et sa liste de dépôts. Le contenu des projets quitte votre déploiement dans les deux sens — considérez un compte GitHub lié comme une voie d'export pour chaque projet qui y est rattaché. L'**intégration Zotero** contacte `www.zotero.org` pour l'autorisation et `api.zotero.org` pour les données de bibliothèque. Elle s'active par utilisateur en liant un compte Zotero. L'échange OAuth et la clé d'API de l'utilisateur sont transmis. Les lectures sont unidirectionnelles : les bibliothèques de références sont importées au format BibTeX, et aucun contenu de projet n'est téléversé. L'**intégration Mendeley** contacte `api.mendeley.com` à la fois pour l'autorisation et pour les données de bibliothèque. Elle s'active par utilisateur en liant un compte Mendeley. L'échange OAuth demande le scope `all` de Mendeley — le seul proposé par son API — mais Ayakaleaf n'effectue jamais que des lectures : les bibliothèques de références et les bibliothèques de groupe sont importées au format BibTeX, et aucun contenu de projet n'est téléversé. Les jetons d'accès sont renouvelés automatiquement ; lorsque Mendeley révoque une autorisation, les identifiants stockés sont supprimés et l'utilisateur est invité à lier à nouveau son compte. Les **pages de documentation** sont récupérées depuis `https://learnwiki.overleaf.com`, configurable avec `WIKI_URL`. Les requêtes sont effectuées par le service web, et non par le navigateur de l'utilisateur : le wiki amont voit donc votre serveur, jamais les adresses de vos utilisateurs. Seul le titre de la page demandée est transmis, et les réponses sont mises en cache sur disque. Faites pointer `WIKI_URL` vers votre propre miroir, ou bloquez la destination, si le trafic sortant lié à la documentation n'est pas acceptable. L'**envoi d'e-mails** contacte le serveur SMTP ou l'API de messagerie que vous configurez ; il n'y a pas de valeur par défaut. Les adresses des destinataires et le contenu des messages quittent votre déploiement, y compris les liens de réinitialisation de mot de passe et d'invitation. Deux vérifications facultatives sont désactivées par défaut. La vérification des mots de passe compromis est inactive tant que `HAVE_I_BEEN_PWNED_ENABLED` n'est pas définie ; lorsqu'elle est activée, elle envoie les premiers caractères d'un hachage SHA-1 du mot de passe à `api.pwnedpasswords.com`, jamais le mot de passe lui-même. La vérification CAPTCHA est inactive tant qu'aucune clé de site reCAPTCHA n'est configurée, et contacte `www.google.com` lorsqu'elle est active. L'**authentification unique** ne contacte que le fournisseur d'identité que vous indiquez, et les informations transmises dépendent du protocole. Avec LDAP, le service web se connecte directement à votre annuaire : il s'authentifie avec le compte de service que vous configurez, effectue une recherche selon la base, le filtre et la liste d'attributs que vous définissez, et vérifie le mot de passe saisi dans le formulaire de connexion auprès de votre annuaire, de sorte que le nom d'utilisateur et le mot de passe atteignent le serveur d'annuaire. L'activation des contacts issus de l'annuaire entraîne une recherche supplémentaire pour alimenter la liste de contacts. Avec OIDC, le service web échange le code d'autorisation auprès de votre point de terminaison de jetons, puis appelle votre point de terminaison user-info en demandant par défaut les scopes `openid profile email` ; ce comportement est configurable avec `OVERLEAF_OIDC_SCOPE`. Avec SAML, la requête d'authentification transite par le navigateur de l'utilisateur jusqu'au fournisseur d'identité, plutôt que par une connexion directe depuis le serveur. Dans les trois cas, le nom et l'adresse e-mail de l'utilisateur proviennent du fournisseur plutôt que de lui être envoyés, puis sont stockés dans la fiche utilisateur locale. Les **identifiants tiers** — jetons OAuth et clés d'API — sont conservés dans MongoDB, dans la fiche utilisateur, chiffrés en AES-256-CTR avec un sel et un vecteur d'initialisation propres à chaque enregistrement. Ils ne sont jamais stockés en clair ni écrits dans les journaux. La clé de chiffrement provient de `${PROVIDER}_CIPHER_PASSWORD` si elle est définie (comme pour Zotero et Mendeley) ; sinon, une clé est générée à la première utilisation et conservée dans votre volume de données avec des permissions réservées au propriétaire. Sauvegardez cette clé avec votre volume de données : si elle est perdue, les identifiants stockés ne pourront plus être déchiffrés et tous les utilisateurs devront lier à nouveau leurs comptes. Les **fichiers liés depuis une URL** sont récupérés par votre déploiement pour le compte de l'utilisateur : la destination est donc l'adresse fournie par celui-ci. Les fichiers liés par URL sont désactivés tant que vous n'ajoutez pas `url` à `ENABLED_LINKED_FILE_TYPES`, et la configuration par défaut ne l'inclut pas. Les imports externes de ZIP et de fichiers TeX via l'API Open in Overleaf utilisent également le même composant `linked-url-proxy`. Les requêtes directes résolvent le nom d'hôte cible et rejettent les plages réseau restreintes, sous réserve des exceptions de ressources autorisées configurées. Lorsque `OVERLEAF_LINKED_URL_OUTBOUND_PROXY` est configuré, c'est le proxy sortant qui résout les noms d'hôte : il doit donc appliquer lui-même les restrictions sur le réseau interne ; les vérifications réseau de l'application ne s'appliquent qu'aux URL contenant des adresses IP. Consultez [URL externe — Proxy sortant](/fr/on-premises/configuration/overleaf-toolkit/external-url#outbound-proxy "mention") pour plus de détails. Ces requêtes récupèrent l'URL fournie et ne téléversent pas de fichiers de projet. Si votre politique impose une liste d'autorisation pour le trafic sortant, n'autorisez que les hôtes correspondant aux fonctionnalités que vous avez activées — `github.com` et `api.github.com` pour GitHub, `www.zotero.org` et `api.zotero.org` pour Zotero, `api.mendeley.com` pour Mendeley, `learnwiki.overleaf.com` ou votre propre `WIKI_URL` pour la documentation, `api.pwnedpasswords.com` pour la vérification des mots de passe, `www.google.com` pour le CAPTCHA, ainsi que votre propre serveur de messagerie et votre fournisseur d'identité. Si les fonctionnalités d'IA ou de recherche sont activées, autorisez également les points de terminaison configurés du modèle, de la recherche web et du MCP de documentation. Refusez les destinations qui ne sont pas requises par les fonctionnalités activées. Lorsque le trafic sortant doit être inspecté ou journalisé de manière centralisée, les intégrations GitHub, Zotero et Mendeley peuvent chacune passer par un proxy HTTP en définissant `GITHUB_SYNC_PROXY_URL`, `MENDELEY_PROXY_URL` et `ZOTERO_PROXY_URL`. La récupération des URL liées et les imports distants peuvent utiliser `OVERLEAF_LINKED_URL_OUTBOUND_PROXY`. Les fichiers liés depuis une URL ne peuvent pas être limités à une liste d'hôtes, puisque la destination est choisie par l'utilisateur au moment de la requête ; restreignez cette fonctionnalité via le paramètre de ressources autorisées du composant proxy lui-même, ou laissez-la désactivée. Si vous déployez Ayakaleaf Pro avec le stockage [s3.md](/fr/on-premises/configuration/overleaf-toolkit/s3 "mention") activé, les données stockées dans S3 sont-elles chiffrées ? *Non.* Les données ne sont pas chiffrées. Tous les fragments d'historique, fichiers de modèles, PDF et autres fichiers sont stockés en clair. Si vous utilisez un fournisseur de stockage S3 externe tiers, accordez une attention particulière à la sécurité et à la confidentialité des données. ### Les compilations de projets sont-elles isolées ? Ayakaleaf Pro prend en charge les compilations en sandbox. Chaque compilation s'exécute dans un conteneur distinct. Les conteneurs de sandbox n'ont pas d'accès réseau par défaut, ce qui réduit l'exposition aux ressources du réseau interne. Les compilations en sandbox nécessitent l'accès au socket Docker de l'hôte. Réservez l'administration de l'hôte à des opérateurs de confiance. ### Puis-je faire confiance aux builds CI et aux images de conteneur ? GitHub Actions construit et publie les images de conteneur d'Ayakaleaf Pro. Les images sont disponibles sur le GitHub Container Registry public. Les images prennent en charge `amd64` et `arm64`. Docker sélectionne l'architecture correspondante lors du téléchargement d'une image. N'utilisez pas le tag `latest` en production. Épinglez une version explicite, de préférence un digest d'image. Testez chaque mise à niveau dans un environnement hors production. Vérifiez l'image, la configuration et les intégrations avant le déploiement. ### Le code est-il open source ? Ayakaleaf Pro et les dépôts de fonctionnalités associés sont publics. Les utilisateurs peuvent ainsi examiner les modifications et retracer les sources amont. Un code source public permet un examen indépendant. Il ne garantit pas, à lui seul, des builds de version reproductibles. Avant une mise à niveau, examinez : * Le tag ou le commit de la version. * La version ou le digest de l'image. * Les dépendances tierces et les exigences de licence. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.