Configuration du stockage
Où sont stockés les fichiers de votre organisation — le stockage par défaut du déploiement, ou votre propre stockage compatible S3 ou Azure Blob — et quand les fichiers sont téléversés directement depuis le navigateur ou via le serveur.
Chaque organisation stocke ses fichiers (documents de base de connaissances, pièces jointes de chat, avatars, enregistrements, artefacts de workflow) dans un stockage objet. Tant que vous n'avez pas configuré votre propre stockage, ils sont placés dans le stockage par défaut du déploiement : le stockage objet fourni par votre déploiement. Settings → Organization → Storage indique celui qu'utilise votre organisation.
| Stockage | Quand l'utiliser |
|---|---|
| Stockage par défaut du déploiement | Rien à configurer. Les fichiers de chaque organisation sont conservés sous leur propre préfixe, à l'écart des autres organisations. |
| Compatible S3 (le vôtre) | AWS S3, MinIO, SeaweedFS, Cloudflare R2 ou toute API S3. |
| Azure Blob Storage (le vôtre) | Déploiements natifs Azure. |
Le stockage par défaut du déploiement
Les installations auto-hébergées fournissent un stockage par défaut prêt à l'emploi (le stockage objet SeaweedFS intégré, ou un stockage compatible S3 désigné par votre opérateur). Tous les services lisent et écrivent dans le même stockage : un fichier écrit par une partie de la plateforme est donc toujours lisible par le reste.
Certains déploiements ne fournissent pas de stockage par défaut. Les installations
via Azure Marketplace, par exemple, ne livrent aucun stockage objet partagé. Dans ce cas,
Settings → Storage affiche No storage configured. Aucun fichier ne peut être
téléversé tant qu'un administrateur n'a pas configuré un stockage S3 ou Azure (l'assistant
de configuration en demande un). Les fichiers déjà téléversés restent lisibles. Un
téléversement tenté dans cet état échoue avec STORAGE_NOT_CONFIGURED (HTTP 409).
Clear Configuration supprime votre propre stockage. Les nouveaux fichiers sont alors placés dans le stockage par défaut du déploiement ou, sur un déploiement qui n'en a pas, ne peuvent plus être téléversés tant que vous n'avez pas reconfiguré un stockage. Les fichiers déjà présents dans votre propre stockage ne sont pas déplacés.
Le disque local n'est plus une option de stockage. Les organisations qui l'utilisaient sont basculées vers le stockage par défaut du déploiement. Leurs fichiers existants sont toujours lus depuis le disque du serveur jusqu'à ce que votre opérateur les copie dans le stockage par défaut.
Paramètres S3
- Endpoint URL — le point de terminaison S3 utilisé par les serveurs de la plateforme. Pour le SeaweedFS intégré, il s'agit de l'adresse du service dans le cluster ; pour AWS S3, laissez-le vide.
- Public endpoint URL (facultatif) — un point de terminaison accessible depuis le navigateur, utilisé uniquement pour signer les URL de téléversement/téléchargement direct. Définissez-le lorsque votre Endpoint URL est privée (interne au cluster ou derrière un pare-feu), mais que vous avez exposé publiquement le même stockage (par ex. via un ingress) et souhaitez des transferts directs depuis le navigateur.
- Bucket, Region, Access key / Secret key, Force path style — paramètres standard d'un client S3. Les identifiants sont stockés chiffrés dans le magasin de secrets de la plateforme.
Téléversements directs ou relayés par le serveur
Pour des raisons de rapidité, la plateforme privilégie les transferts directs depuis le navigateur : le navigateur téléverse directement vers votre stockage à l'aide d'une URL présignée de courte durée. Cela ne fonctionne que si le point de terminaison de stockage est accessible depuis les navigateurs de vos utilisateurs.
La plateforme décide automatiquement :
- AWS S3 / Azure Blob — toujours en direct.
- Stockage compatible S3 avec un nom d'hôte public — en direct.
- Stockage compatible S3 avec un point de terminaison privé (le SeaweedFS intégré, ou MinIO sur un réseau privé) — les téléversements et téléchargements sont alors acheminés via le serveur de la plateforme. Tout fonctionne toujours ; les transferts volumineux passent simplement par le serveur.
- Point de terminaison privé + Public endpoint URL configurée — en direct, en utilisant le point de terminaison public pour la signature.
Si vous configurez une Public endpoint URL, l'hôte de stockage doit autoriser les
requêtes cross-origin (CORS) PUT/GET provenant de l'origine de votre plateforme —
les transferts directs depuis le navigateur sont des requêtes cross-origin.
Symptôme à surveiller : des téléversements qui échouent dans la console du navigateur avec
net::ERR_NAME_NOT_RESOLVED sur le nom d'hôte de votre stockage signifient qu'un point de
terminaison privé s'est retrouvé dans les transferts du navigateur. Sur les versions
actuelles, cela ne peut pas se produire — la plateforme détecte les points de terminaison
privés et relaie automatiquement. Si vous le constatez, mettez à niveau, ou videz le champ
Public endpoint URL s'il pointe vers un hôte que vos utilisateurs ne peuvent pas joindre.
Supprimer des fichiers en masse
Paramètres → Organisation → Stockage propose Supprimer tous les fichiers
pour la zone d'espace de travail/environnement sélectionnée et pour le stockage
de niveau organisation. Les deux exigent un propriétaire ou un administrateur de
l'organisation, et les deux vous demandent d'abord de saisir DELETE ALL. Tout
ce qui se trouve dans la zone est supprimé, y compris les dossiers imbriqués.
Les documents des bases de connaissances sont conservés. Une purge en masse ne supprime jamais le contenu d'une base de connaissances — une base de connaissances d'espace de travail, ou le Contexte de l'entreprise de l'organisation. Ces documents sont régis par les permissions de la base de connaissances (avec qui la base est partagée, autorisations d'accès par document, habilitation), que l'administration du stockage n'évalue pas : vider une zone ne peut donc pas détruire un document que vous n'êtes pas autorisé à lire. Supprimez-les depuis la base de connaissances elle-même, où chaque document est vérifié individuellement. Après une purge, la confirmation indique combien de documents de bases de connaissances ont été conservés.
Fichiers conservés pour les applications publiées
Les artefacts de source et de dépendances des applications publiées sont des fichiers privés de la plateforme. Ils n’apparaissent pas dans l’explorateur de fichiers de l’organisation, et l’effacement des fichiers de l’organisation les préserve. Leur cycle de vie suit celui des versions d’application conservées. Les autorisations sur les fichiers de stockage n’accordent pas l’accès à la source ni aux dépendances du notebook d’une application.
Changer de fournisseur
Changer de fournisseur (ou de bucket) ouvre une boîte de dialogue de migration qui copie les objets existants vers la nouvelle cible avant l'enregistrement de la configuration. Les modifications de configuration prennent effet sous cinq minutes (caches de configuration).
Ce qu'il advient des données Analytics (lakehouse)
Les tables gérées d'Analytics sont stockées au format Iceberg dans un entrepôt Lakekeeper propre à chaque organisation. Les objets de stockage de fichiers (documents de base de connaissances, pièces jointes, etc.) et les données Iceberg sont distincts et nécessitent des étapes de migration distinctes.
Lorsque vous avez une ou plusieurs tables gérées, la boîte de dialogue de migration affiche une section supplémentaire Lakehouse cutover qui décrit :
- Le nombre de tables gérées actives qui seront copiées.
- Le fait que l'historique des snapshots Iceberg n'est pas conservé — la bascule copie l'état actuel des tables vers le nouveau fournisseur. Si vous devez conserver l'historique de time travel, contactez votre administrateur avant de poursuivre.
L'orchestrateur de migration copie d'abord les objets fichiers, puis les tables Iceberg,
et ne bascule la configuration de stockage qu'une fois les deux opérations réussies. Vous
pouvez suivre la progression de la copie Iceberg dans la carte Lakehouse status de la page
des paramètres de stockage (tables copied / total, avec la liste des éventuels échecs par table).
Les écritures du lakehouse sont gelées pendant la bascule
Pendant la copie Iceberg, les écritures dans les tables gérées renvoient une erreur
(iceberg_cutover_in_progress). Les sources de données et les workflows qui écrivent dans
des tables Analytics réessaient automatiquement lors de leur prochain cycle ; aucune donnée
n'est perdue. Les lectures (requêtes, aperçus) ne sont pas affectées — l'ancien entrepôt
reste disponible jusqu'à la fin de la copie.
Ignorer la bascule du lakehouse
La boîte de dialogue propose une option Skip lakehouse cutover. Si vous l'ignorez, la
configuration est basculée sans copier les données Iceberg. Les écritures du lakehouse
sont bloquées (erreur iceberg_warehouse_drift) jusqu'à ce que la bascule soit exécutée
séparément depuis la carte Lakehouse status.
N'utilisez Skip que si vous avez déjà migré les données Iceberg par un autre moyen (contactez votre administrateur Scrydon).
Bannière de dérive du lakehouse
Si le fournisseur de stockage a été modifié auparavant sans terminer la bascule Iceberg, la page Settings → Storage affiche une bannière d'avertissement :
Lakehouse drift detected — managed tables are on [old provider] but your storage config points at [new provider].
Cliquez sur "Run lakehouse cutover" pour lancer la réparation dans le produit. L'opération peut être relancée sans risque si elle échoue en cours de route — les données sources ne sont jamais modifiées avant la fin de la copie.
Le lakehouse nécessite votre propre stockage
Les tables gérées d'Analytics (le lakehouse) et l'export de tables en masse nécessitent un
stockage objet propre à votre organisation. Le stockage par défaut du déploiement est
partagé par toutes les organisations : il ne peut donc pas héberger de lakehouse. Avec le
stockage par défaut, Analytics vous demande d'abord de configurer un stockage compatible S3
ou Azure, et l'export en masse répond export_not_available (raison deployment_default_store).
Si vous supprimez votre propre stockage alors que des tables gérées existent, la page affiche une bannière rouge "Lakehouse needs object storage". Les écritures du lakehouse sont bloquées afin qu'aucune nouvelle donnée n'atterrisse sur le stockage que vous avez quitté. Aucun bouton de bascule n'est proposé dans cet état, car le stockage par défaut du déploiement n'est pas une destination de bascule valide. Pour réparer, configurez à nouveau votre propre stockage objet et lancez la bascule du lakehouse à partir de là.
Codes d'erreur que vous pouvez rencontrer
| Code | HTTP | Signification |
|---|---|---|
STORAGE_NOT_CONFIGURED | 409 | Téléversement refusé — le déploiement ne fournit aucun stockage par défaut et votre organisation n'en a pas. Configurez-en un sous Settings → Storage. |
iceberg_warehouse_drift | 409 | Écriture bloquée — la configuration de stockage a changé sans que la bascule Iceberg soit terminée. Ouvrez Settings → Storage et lancez la bascule du lakehouse. |
iceberg_cutover_in_progress | 409 | Une bascule du lakehouse est en cours. Les écritures reprendront automatiquement une fois celle-ci terminée (généralement en quelques minutes). |
iceberg_target_missing | 409 | Le tabular Iceberg d'une table est introuvable — la ligne se réparera d'elle-même lors de la prochaine synchronisation de la source de données. |
table_not_available | 410 | Le cycle de vie de la table est terminé (deleted/archived/failed). |
table_provisioning | 409 | La table est encore en cours de provisionnement. Réessayez dans un instant. |