Skip to main content
Dernière mise à jour : 17 octobre 2026 English version: Security Policy. SynapsAI Cloud met en place des couches d’isolation physique, architecturale et logicielle afin de protéger les charges de calcul haute performance et les cibles de stockage des clients.

1. Architecture et isolation multilocataire

  • Environnements de centres de données : SynapsAI Cloud planifie les charges de calcul sur des structures de centres de données de niveau 3 et de niveau 4, maintenues par des fournisseurs d’infrastructure établis. Les déploiements de calcul de production sont hébergés dans des zones nord-américaines vérifiées.
  • Isolation au niveau du processus : Même si les grappes matérielles fonctionnent dans un cadre multilocataire à haute densité, les déploiements de modèles de chaque client sont segmentés au niveau du processus du système d’exploitation Linux, au moyen de mécanismes de bac à sable renforcés.
  • Contrôle des ressources : Des contrôleurs de trafic et des allocations de ressources (notamment les cgroups Linux) empêchent qu’un locataire n’épuise les ressources d’un autre, de sorte qu’un pic d’exécution ne puisse pas dégrader ni inspecter les pipelines d’un client voisin.

2. Sécurité de la couche transport (TLS) et protections réseau

  • Chiffrement en transit : Toutes les connexions réseau externes qui entrent dans les plans de contrôle de SynapsAI Cloud ou dans les points d’accès des modèles sont protégées par un chiffrement TLS (HTTPS). Les interfaces HTTP non chiffrées sont désactivées.
  • Durcissement du réseau interne : Les chemins de données entre les nœuds d’un centre de données ou entre les services utilisent des canaux de routage chiffrés et des authentifications explicites afin de réduire le risque d’interception.

3. Sécurité des identifiants et clés d’API

  • Responsabilité des jetons du Client : L’accès aux points d’accès d’inférence et aux API du panneau de contrôle est restreint par des jetons d’API cryptographiques générés dans le tableau de bord de l’espace de travail du client. Pour les dépôts Hugging Face restreints ou privés, les Clients doivent fournir un jeton d’accès Hugging Face valide. Les dépôts publics et non restreints n’en exigent pas. Lorsqu’un jeton est fourni, SynapsAI le conserve et l’utilise uniquement pour authentifier l’accès au dépôt pour le compte du Client. Les Clients sont seuls responsables de la protection, de la distribution, du stockage secret, de la rotation et de la limitation de portée des clés d’API, des jetons Hugging Face et des configurations de déploiement. SynapsAI n’est pas responsable de l’accès non autorisé, des frais ou du préjudice en aval résultant d’identifiants compromis du Client.
  • Contrôle de l’accès administratif : L’accès du personnel de SynapsAI aux cadres d’orchestration internes est limité par le principe du moindre privilège, encadré par un contrôle d’accès fondé sur les rôles et protégé par une authentification multifacteur obligatoire.

4. Stockage des poids et protection des artefacts

  • Les poids des modèles et les artefacts sont stockés dans Amazon S3 aux États-Unis, dans des compartiments contrôlés par SynapsAI, et peuvent être préparés sur les machines d’application de SynapsAI chez OVHcloud et sur les travailleurs GPU de Beam pendant le temps nécessaire pour construire ou servir un déploiement. L’accès par les API de SynapsAI exige les identifiants du Client. Les autres locataires ne sont pas censés lire ces objets.
  • Les identifiants de connecteurs, les clés Amazon S3 fournies par le Client, les jetons Hugging Face et les secrets MCP distants sont chiffrés avec AES-256-GCM avant d’être stockés.
  • Les Clients qui ont besoin d’une infrastructure dédiée et isolée doivent écrire à [email protected].

5. Correctifs et suivi des incidents

Nos environnements d’exploitation font l’objet d’évaluations automatisées de vulnérabilités, d’un suivi des versions des dépendances et d’un calendrier rapide de correctifs du noyau. Des pistes d’audit système isolées sont analysées en continu afin de détecter les anomalies, et les alertes sont acheminées aux ingénieurs d’infrastructure de garde. Les vulnérabilités structurelles ou les indicateurs de sécurité systémiques doivent être signalés de façon confidentielle à [email protected].