La plateforme s'installe à l'intérieur de votre propre compte cloud.

Nexa Intelligence s'exécute en tant qu'ensemble de workers, de files d'attente, de magasins d'objets et de Durable Objects à l'intérieur d'une infrastructure que vous possédez. Cloudflare est le substrat par défaut car la plateforme entière est native Cloudflare. AWS, Azure et sur site suivent le même modèle sur un autre fournisseur. Votre équipe informatique installe le Cloud Harness. Nous opérons à l'intérieur de celui-ci. Les données ne quittent jamais votre périmètre pour être traitées.

Cette page couvre ce qui est installé, qui gère quoi, ce qui traverse votre périmètre, et comment le déploiement diffère selon le fournisseur.

[ 01 ]  ·  NAMED: LE CLOUD HARNESS

Une unité installable. Votre compte. Notre opération.

Le Cloud Harness est le paquet d'infrastructure qui devient votre déploiement. Sur Cloudflare, il s'agit de sept workers, deux buckets R2, plusieurs classes de Durable Objects et un petit ensemble de files d'attente. Sur AWS, c'est la même topologie mappée sur Lambda, S3, DynamoDB et SQS. Sur Azure, ce sont des Functions, Blob Storage, Cosmos DB et Service Bus. Sur site, c'est la même topologie sur Kubernetes avec Postgres, MinIO et NATS.

Votre équipe provisionne le compte. Nous fournissons les scripts de déploiement, la configuration Wrangler ou Terraform, et le guide d'installation. Une fois le Harness en place, votre compte détient chaque élément d'infrastructure que la plateforme touche. Il n'existe pas d'environnement distinct contrôlé par Nexa par lequel vos données transitent.

Nous opérons le Harness sous contrat signé. Votre informatique conserve les clés. Nous obtenons l'accès nécessaire pour exécuter l'enrichissement, les tableaux de bord et les surfaces d'agents, délimité aux environnements que nous opérons.

Schéma d'architecture

Où vit le chemin de données.

Le chemin de données reste dans votre compte. Deux appels aux frontières, tous deux liés par contrat.

[ 02 ]  ·  NAMED: CE QUI TRAVERSE LE PÉRIMÈTRE

Deux appels sortants. Tous deux sous des contrats de non-rétention signés.

Deux services vivent en dehors de votre compte : le fournisseur LLM (Anthropic) et le fournisseur de voix (ElevenLabs). Chaque autre élément du système s'exécute à l'intérieur de votre compte, y compris le lac de données, les workers d'enrichissement, le magasin de faits, les tableaux de bord et les endpoints des agents.

L'appel Anthropic est lié par un contrat de non-entraînement pour chaque plan. Enterprise exécute également la non-rétention : aucun contenu client ne persiste chez Anthropic au-delà de la requête. ElevenLabs fonctionne en non-rétention pour chaque plan et chaque niveau. L'audio original ne laisse aucune trace chez le fournisseur de voix après la fin de l'appel. Voir la liste des sous-traitants pour les données exactes que chaque partenaire voit.

Les appels entrants sont authentifiés à la périphérie. Les webhooks portent une signature HMAC qui est vérifiée par rapport à un secret stocké dans votre compte. Les surfaces opérateur portent un token porteur dont la portée est encodée dans la référence. Il n'y a pas de secret partagé entre Nexa et votre compte au-delà des référentiels que votre informatique nous émet.

[ 03 ]  ·  NAMED: CLOUDFLARE (PAR DÉFAUT)

Workers, R2, Durable Objects, Files d'attente.

Cloudflare est le substrat par défaut car la plateforme est native Cloudflare. Le Harness se déploie sous forme de sept workers (operations, canvas, ingestion, engine, query, r2ops, docs), deux buckets R2 (le lac de données et le magasin d'artefacts de matrice), et un ensemble de classes de Durable Objects qui contiennent l'état par matrice. Les files d'attente transportent le travail asynchrone entre le worker d'ingestion et le moteur d'enrichissement.

Chaque wrangler.toml définit workers_dev = false de sorte que les URLs *.workers.dev retournent 404. Seuls les domaines personnalisés de votre compte servent du trafic. Le worker moteur n'a aucune surface publique du tout. Il est atteint via des consommateurs de files d'attente et des liaisons de service d'autres workers de votre compte. Il n'existe pas de chemin entrant depuis Internet vers le worker appelant le LLM.

Être natif Cloudflare signifie que l'ancrage régional est un changement de configuration plutôt qu'une re-architecture. Les buckets R2 peuvent être ancrés aux juridictions eu ou fedramp via la liaison de bucket. Les Durable Objects acceptent des indications de localisation qui les placent dans une région spécifiée. Voir la section 06 pour la configuration de résidence des données.

[ 04 ]  ·  NAMED: AWS

Lambda, S3, DynamoDB, SQS, EventBridge.

Le déploiement AWS mappe la topologie du Harness sur les primitives AWS équivalentes. Les workers deviennent des fonctions Lambda. Les buckets R2 deviennent des buckets S3 avec isolation par politique de bucket entre le lac de données et le magasin d'artefacts de matrice. Les Durable Objects deviennent des tables DynamoDB avec des clés de portée par ligne. Les files d'attente deviennent SQS, avec EventBridge gérant la diffusion en éventail.

Les secrets résident dans AWS Secrets Manager, délimités par fonction. Les clés KMS sont émises par environnement. La politique IAM sur chaque Lambda la restreint aux buckets, tables et files d'attente dont elle a réellement besoin. Le Lambda qui appelle Anthropic ne peut pas écrire dans le lac de données. Le Lambda qui ingère les webhooks ne peut pas écraser les artefacts de matrice. La même séparation des référentiels qui s'applique sur Cloudflare s'applique sur AWS.

Nous fournissons le module Terraform. Votre informatique exécute l'application. La propriété du compte, la facturation et la racine IAM sont chez vous.

[ 05 ]  ·  NAMED: AZURE

Functions, Blob Storage, Cosmos DB, Service Bus.

Le déploiement Azure utilise Azure Functions pour la couche worker, Blob Storage pour le lac de données et le magasin d'artefacts de matrice, Cosmos DB pour les tables d'état par matrice, et Service Bus pour la couche de files d'attente. Key Vault détient les secrets. Les identités managées délimitent l'accès de chaque Function aux ressources sur lesquelles elle opère.

Les déploiements Azure sont courants dans les secteurs réglementés. Le Harness est livré avec les modèles de politique Azure nécessaires pour les configurations de résidence RGPD et Loi 25 du Québec. Les groupes de ressources peuvent être ancrés à une région, et les comptes Cosmos DB peuvent être verrouillés dans une seule région sans réplication interrégionale.

[ 06 ]  ·  NAMED: SUR SITE

Kubernetes, Postgres, MinIO, NATS.

Les clients sur site exécutent le Harness sur Kubernetes. Les workers deviennent des déploiements de conteneurs. Le stockage devient MinIO avec la même séparation à deux buckets que les variantes cloud. L'état par matrice devient un schéma Postgres avec une sécurité au niveau des lignes ancrée sur l'identifiant de matrice. Les files d'attente deviennent NATS JetStream.

Le sur site est la configuration pour les clients ayant des exigences explicites de résidence des données qu'aucun cloud public ne peut satisfaire, ou qui opèrent déjà une plateforme Kubernetes privée auditée par leur équipe de sécurité. Les mêmes appels partenaires s'appliquent : HTTPS sortant vers Anthropic et ElevenLabs sous les mêmes contrats de non-entraînement et de non-rétention. Si ces appels sont également interdits par politique, le déploiement fonctionne en mode air-gappé avec une inférence sur site et une synthèse vocale sur site. Le compromis est la qualité de l'agent d'entretien et le coût par conversation.

[ 07 ]  ·  NAMED: RÉSIDENCE DES DONNÉES

Les données se trouvent là où vous les placez.

Le stockage et le calcul peuvent être ancrés à une juridiction au moment du déploiement. Sur Cloudflare, c'est l'indicateur de juridiction du bucket R2 plus les indications de localisation des Durable Objects. Sur AWS, c'est la région du bucket S3 et de la fonction Lambda. Sur Azure, c'est la région du groupe de ressources. Sur site, c'est l'emplacement physique du cluster.

Pour les clients ayant des exigences de résidence EU, chaque élément d'infrastructure peut être ancré dans des régions européennes. Pour les clients du secteur public canadien ou au Québec sous la Loi 25 du Québec, les régions canadiennes de chaque fournisseur sont disponibles. Le guide de déploiement liste les ID de région exacts que nous utilisons par juridiction.

[ 08 ]  ·  NAMED: FRONTIÈRE OPÉRATIONNELLE

Ce que Nexa fait à l'intérieur de votre compte.

À l'intérieur de votre compte, Nexa opère le Harness. Cela signifie que nous déployons les versions, gérons la réponse aux incidents, surveillons l'observabilité, ajustons le pipeline d'enrichissement contre votre corpus, calibrons les demi-vies par dimension, et livrons les correctifs. Nous n'exportons pas vos données. Nous ne faisons pas d'entraînement dessus. Le chemin de données reste dans le périmètre que vous possédez.

La frontière opérationnelle est nommée dans le contrat. Votre informatique contrôle les clés, la facturation et les référentiels racine. Notre accès est délimité aux surfaces opérationnelles dont nous avons besoin. Les journaux d'audit des actions des opérateurs se trouvent dans votre compte, où votre équipe de sécurité les examine.

Si vous mettez fin à la relation avec le fournisseur, le déploiement continue de fonctionner sur votre compte sans nous. Voir Indépendance des données pour la garantie de continuité.