Vue d’ensemble de l’architecture
Comment Syncanix relie vos utilisateurs, votre API et l’IA — et où tout cela s’exécute.
Cette page est une carte de haut niveau de la façon dont Syncanix s’assemble : ce qui se passe lorsqu’un utilisateur demande quelque chose à l’assistant, comment son identité est utilisée et où vivent vos données. Rien de tout cela n’est nécessaire pour démarrer, mais cela aide à comprendre la forme du système.
Comment une requête circule
Que la requête provienne du widget intégré ou d’un client MCP, le même parcours s’applique :
- L’utilisateur demandeUn utilisateur connecté saisit une requête dans le widget, ou l’envoie depuis un client MCP comme Claude Desktop.
- Syncanix planifieL’assistant compare la requête à votre catalogue de capacités et décide quelles actions de votre API, le cas échéant, y répondraient — en s’arrêtant pour demander confirmation lorsqu’une action modifie des données.
- Votre API agitLes actions approuvées s’exécutent sur votre propre API en tant que cet utilisateur, avec son identité issue de votre fournisseur d’identité. Le résultat revient dans la conversation et l’appel est consigné dans la piste d’audit.
Les identifiants de vos utilisateurs n’atteignent jamais l’IA
L’assistant travaille à partir d’une description structurée de ce que votre API peut faire — pas à partir des mots de passe ni des jetons de session de vos utilisateurs. Chaque action s’exécute sous l’identité propre de l’utilisateur final, fournie par votre fournisseur d’identité au moment voulu. Le modèle de langage voit la requête et le catalogue ; il ne détient jamais d’identifiant dont il pourrait abuser.
Fiable par conception
Par défaut, Syncanix exécute Claude sur AWS Bedrock dans l’UE, et peut basculer automatiquement vers d’autres fournisseurs — l’API Anthropic propriétaire et OpenAI — si ce chemin est indisponible, de sorte que la panne d’un seul fournisseur n’interrompt pas votre assistant. Vous pouvez aussi apporter vos propres clés de fournisseur.
Où cela s’exécute
L’infrastructure de Syncanix s’exécute entièrement dans l’Union européenne — sur AWS à Francfort (eu-central-1) — avec vos données chiffrées au repos. L’inférence d’IA par défaut s’exécute elle aussi dans l’UE : Claude sur Amazon Bedrock, sous les conditions de traitement des données d’AWS, votre contenu n’étant jamais utilisé pour l’entraînement. Les embeddings de récupération et le reranking s’exécutent eux aussi dans la région sur Amazon Bedrock ; si le chemin de modèle UE est un jour indisponible, le trafic peut basculer vers un fournisseur hors UE.
Vos données restent les vôtres
Chaque espace de travail est isolé de tous les autres. Une requête est toujours limitée à l’espace de travail auquel elle appartient — dans la base de données, les caches, les journaux et les fichiers stockés — de sorte qu’un client ne peut jamais voir les données d’un autre.
Développer, puis promouvoir
Chaque espace de travail possède deux environnements : un environnement de développement pour tout configurer et essayer en toute sécurité, et un environnement de production que vos utilisateurs atteignent. Vous effectuez les modifications en développement et les promouvez en production lorsque vous êtes prêt, de sorte que le comportement en production ne change que de façon intentionnelle.