Plateforme SaaS multimodèle
pour documents, graphe et fichiers

Vue d’ensemble

Un schéma de lecture rapide pour comprendre comment une application SaaS dialogue avec la plateforme et organise ses données.

Démarrage rapide

Quatre étapes pour passer d’un compte vide à un premier document écrit, relu, puis à un parcours d’exploration complet.

curl -X POST https://<votre-idp>/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=<client_id>" \
  -d "client_secret=<client_secret>"

# { "access_token": "...", "token_type": "Bearer", "expires_in": 600 }

# {"status":"active"} encodé en base64
grpcurl -H "authorization: Bearer $TOKEN" \
  -proto rocia/v1/rocia.proto \
  -d '{
        "tenant_id": "tenant-a",
        "collection": "users",
        "id": "user-123",
        "json": "eyJzdGF0dXMiOiJhY3RpdmUifQ=="
      }' \
  <hôte>:<port> rocia.v1.DocumentService/PutDoc

grpcurl -H "authorization: Bearer $TOKEN" \
  -proto rocia/v1/rocia.proto \
  -d '{
        "tenant_id": "tenant-a",
        "collection": "users",
        "id": "user-123"
      }' \
  <hôte>:<port> rocia.v1.DocumentService/GetDoc

# Documents
ListCollections → ListDoc → GetDoc

# Graphe
ListGraphs → ListNodes → GetNode → NeighborsOut

# Fichiers
ListBuckets → ListFiles → Stat → Download

Modèles de données

La plateforme sépare volontairement document, graphe et fichier. Leur combinaison est explicite et portée par le client.

Quatre services : trois orientés modèle — document, graphe, fichier — et un service transverse aux tenants. Tous partagent les mêmes conventions de pagination, d’idempotence et d’erreur.

QueryDocRequest {
  tenant_id: "tenant-a",
  collection: "users",
  filters: [
    {
      field: "organization_id",
      operator: QUERY_OPERATOR_EQ,
      values_json: ["\"org-1\""]
    },
    {
      field: "status",
      operator: QUERY_OPERATOR_IN,
      values_json: ["\"active\"", "\"draft\""]
    },
    {
      field: "name",
      operator: QUERY_OPERATOR_CONTAINS,
      values_json: ["\"prod\""]
    }
  ],
  sort: [
    { field: "name", direction: SORT_DIRECTION_ASC }
  ],
  page: { limit: 50, cursor: "" }
}

Erreurs

Chaque statut gRPC porte une métadonnée reason qui précise la cause. C’est sur elle qu’un client branche sa logique de reprise, pas sur le seul code.

Sécurité, environnements et exploitation

Cette section rassemble les éléments publics utiles pour exploiter la plateforme proprement dans un contexte SaaS, sans entrer dans les détails internes d’implémentation.

Performances & limites

Les plafonds ci-dessous sont appliqués à la frontière de l’API. Pour les capacités et les tarifs par nœud, voir les tarifs publics, qui font seuls autorité sur la grille en vigueur.

Monitoring, logs et alertes

Métriques, logs et alertes sont consultables directement depuis le tableau de bord de chaque environnement, sans intégration externe à configurer.

Clients & génération de code

Aucun SDK n’est publié à ce jour. Le fichier .proto est la surface de référence : chaque langage y génère son client avec son outillage standard, et un SDK publié plus tard n’en changera pas le contrat. Les commandes ci-dessous supposent le fichier rangé en proto/rocia/v1/rocia.proto.

python -m grpc_tools.protoc \
  -I proto \
  --python_out=. \
  --grpc_python_out=. \
  proto/rocia/v1/rocia.proto

protoc \
  -I proto \
  --plugin=protoc-gen-ts_proto \
  --ts_proto_out=src/generated \
  --ts_proto_opt=outputServices=grpc-js \
  proto/rocia/v1/rocia.proto

// build.rs
fn main() -> Result<(), Box<dyn std::error::Error>> {
    tonic_build::configure()
        .build_server(false)
        .compile_protos(
            &["proto/rocia/v1/rocia.proto"],
            &["proto"],
        )?;
    Ok(())
}