Comment ClawAI est construit

Dix-huit services déployables indépendamment, chacun propriétaire de sa propre base de données, coordonnés par une architecture orientée événements. Les réponses sont diffusées au fil de leur génération et chaque couche est protégée séparément.

Dernière révision 2026-07-25

Comment ClawAI est conçu

ClawAI est composé de dix-huit services déployables indépendamment derrière un unique proxy inverse. Authentification, conversation, routage, connecteurs, mémoire, fichiers, recherche, espace de travail, génération d'images, export de documents, facturation, audit et journalisation s'exécutent chacun comme leur propre processus avec leur propre base de données. L'application web accède à tous via une seule surface d'API.

La raison est le confinement. Un fournisseur lent, une conversion de fichier bloquée ou un export échoué ne peuvent pas entraîner la panne du chat avec eux, car ils ne partagent ni processus, ni pool de connexions, ni base de données. Chaque service est déployé, mis à l'échelle et annulé indépendamment.

18: Services déployables indépendamment
Une par service: Aucune base de données partagée, jamais
HTTP + événements: Appels synchrones et un bus d'événements asynchrone
Un point d'entrée: Un unique proxy inverse devant tout

Les services

Tous les services ne sont pas intéressants vu de l'extérieur. Voici ceux qu'une requête typique a tendance à traverser, à peu près dans l'ordre où elle les traverse.

AuthentificationPostgreSQL: Comptes, sessions, émission et rotation des jetons, rôles et ensembles de permissions.
ConversationPostgreSQL: Conversations et messages, assemblage du contexte, exécution en flux et orchestration multi-modèles.
RoutagePostgreSQL: Classe chaque message, applique le mode actif et les politiques éventuelles, et enregistre la décision avec sa chaîne de secours.
ConnecteursPostgreSQL: Identifiants de fournisseurs, catalogues de modèles, indicateurs de capacité et vérifications de santé continues.
Mémoire et contextePostgreSQL + pgvector: Enregistrements de mémoire, file de suggestions, packs de contexte et leurs versions, et récupération sémantique.
FichiersPostgreSQL: Téléversements, analyse de sécurité, extraction de texte, OCR, découpage et rétention.
RecherchePostgreSQL: Recherche web, récupération de pages et assemblage de preuves pour des réponses sourcées.
Espace de travailPostgreSQL: Connexions OAuth à douze outils tiers, webhooks, synchronisation planifiée et recherche multi-outils.
Génération d'imagesPostgreSQL: Requêtes d'images, adaptateurs de fournisseurs et progression étape par étape pendant le rendu d'une image.
Génération de documentsPostgreSQL: Rendu des réponses en PDF, DOCX, CSV, HTML, Markdown, TXT et JSON.
FacturationPostgreSQL: Forfaits, abonnements, prix versionnés, factures et application des quotas.
AuditMongoDB: Le registre immuable de qui a fait quoi, plus le grand livre d'utilisation dont chaque chiffre de quota est dérivé.
JournalisationMongoDB: Journaux structurés de chaque service et du navigateur, conservés sur une fenêtre glissante.

Chaque service nomme la base de données qu'il possède. Rien d'autre ne s'y connecte — un service qui a besoin des données d'un autre les demande via HTTP ou réagit à un événement.

Une base de données par service

Chaque service possède exactement une base de données et est la seule chose qui s'y connecte. Il n'y a pas de schéma partagé, pas de jointure inter-services, et pas de base de données de reporting qui lit discrètement les tables de tout le monde.

Le coût est que certaines questions nécessitent deux appels au lieu d'une jointure. L'avantage est qu'un changement de schéma dans la facturation ne peut pas casser la conversation, et qu'une requête incontrôlée dans la journalisation ne peut pas épuiser le pool de connexions dont dépend votre conversation.

Aucune requête inter-bases de données: Un service lit ses propres tables et celles de personne d'autre. Les données provenant d'ailleurs arrivent via un appel API ou un événement.
Les schémas sont privés: Un service peut modifier ses propres tables sans se coordonner avec personne, car aucun consommateur externe ne dépend de leur forme.
Les migrations s'exécutent par service: Chaque service migre sa propre base de données au démarrage. Il n'y a pas de migration globale que tout le monde doit attendre.
Les défaillances restent locales: Une base de données lente ou indisponible dégrade une seule capacité plutôt que tout le produit.

La vie d'une requête

Ce qui se passe entre l'envoi et la lecture de la réponse.

La requête est authentifiée
le proxy inverse la transmet à la conversation, qui vérifie votre jeton d'accès et les permissions attachées à votre rôle.
Le quota est vérifié
la facturation confirme que votre forfait autorise le modèle demandé et qu'il reste de la marge sur votre quota quotidien et mensuel.
Le message est stocké et annoncé
la conversation écrit le message dans sa propre base de données et publie un événement. Le routage l'écoute.
Le routage choisit un modèle
le message est classé, le mode actif et les politiques sont appliqués, la santé des connecteurs est consultée, et une décision avec une chaîne de secours est enregistrée.
Le contexte est assemblé
la conversation interroge la mémoire pour les enregistrements et éléments de pack pertinents, et les fichiers pour les extraits pertinents, puis les fusionne dans le prompt dans la limite d'un budget de jetons.
Le modèle est appelé et diffusé en flux
la conversation appelle le fournisseur et transmet les étapes, le texte, le raisonnement et les métriques à votre navigateur via Server-Sent Events au fur et à mesure de leur arrivée.
Le résultat est enregistré
la réponse, sa décision de routage, ses comptes de jetons et son reçu de contexte sont consignés ensemble.
L'utilisation et l'audit sont enregistrés
la facturation décompte le coût de votre quota et l'audit enregistre l'événement. L'extraction de mémoire s'exécute également ici.

Les étapes 1 à 7 sont synchrones — vous les attendez. L'étape 8 et l'extraction de mémoire se produisent après que la réponse est déjà à l'écran, elles n'ajoutent donc aucune latence perceptible.

Le bus d'événements

Le travail qui n'a pas besoin de se terminer avant que vous voyiez une réponse est publié comme événement sur un échange à sujets RabbitMQ et traité par les services qui s'y intéressent. La mesure d'utilisation, les enregistrements d'audit et l'extraction de mémoire fonctionnent tous ainsi.

Les événements sont la raison pour laquelle la conversation n'a pas besoin de savoir que l'audit existe. La conversation déclare ce qui s'est passé ; tout ce qui doit réagir s'y abonne. Ajouter un consommateur ne nécessite aucun changement chez l'éditeur.

Échange à sujets: Les éditeurs nomment ce qui s'est passé, pas qui doit l'entendre. Les consommateurs s'abonnent aux motifs qui les intéressent.
Nouvelles tentatives avec délai croissant: Un gestionnaire en échec est retenté trois fois avec un délai croissant, ce qui absorbe les échecs transitoires qui en constituent la majorité.
File des messages morts: Un message qui échoue encore après ses tentatives va dans une file des messages morts au lieu d'être abandonné ou de bloquer tout ce qui se trouve derrière lui.
Gestionnaires idempotents: Les gestionnaires tolèrent l'arrivée du même événement deux fois, car la livraison au moins une fois garantit qu'une le sera finalement.
Tout est auditable: L'audit s'abonne à chaque événement de domaine, de sorte que le registre de ce qui s'est passé ne dépend pas du fait que chaque service se souvienne d'en écrire un.

Diffusion en flux

Les réponses arrivent via Server-Sent Events, pas par sondage. La connexion s'ouvre lorsque vous envoyez un message et porte tout jusqu'à ce que la réponse soit terminée ou annulée.

La mise en tampon est désactivée de bout en bout — au niveau du proxy et dans chaque service sur le chemin — car un flux mis en tampon n'est qu'une réponse lente avec des étapes en plus.

Le même canal transporte la génération de texte, la progression de la génération d'images et les recherches longues, de sorte que l'interface dispose d'une seule façon de montrer le travail en cours plutôt que trois.

Changements d'étape: En file d'attente, routage, assemblage du contexte, appel du modèle, finalisation — pour qu'une pause ait toujours une raison visible.
Deltas de contenu: Le texte de la réponse au fur et à mesure que le modèle le produit, jeton par jeton.
Deltas de raisonnement: Pour les modèles qui exposent leur réflexion, le flux de raisonnement est livré séparément de la réponse et affiché séparément aussi.
Ticks de métriques: Jetons jusqu'à présent, jetons par seconde, temps jusqu'au premier jeton, et où le temps est réellement passé — chargement du modèle, évaluation du prompt ou génération.
Événements terminaux: Un résumé d'utilisation final, ou une erreur ou annulation explicite. Le flux ne s'arrête jamais sans explication.

Ce qui stocke quoi

Quatre types de stockage, chacun utilisé pour ce qu'il fait le mieux.

PostgreSQL: Le système de référence pour les comptes, conversations, décisions de routage, mémoire, fichiers, connexions et facturation — une base de données par service.
pgvector: Recherche de similarité vectorielle au sein de PostgreSQL, utilisée pour récupérer les mémoires et éléments de pack de contexte pertinents sans exécuter de base de données vectorielle séparée.
MongoDB: Événements d'audit, grand livre d'utilisation et journaux structurés : données à haut volume en ajout seul avec une fenêtre de rétention glissante.
Redis: Mise en cache, compteurs de limitation de débit et état de coordination de courte durée. Rien d'important n'est stocké uniquement ici.

Mécanismes de sécurité

Des contrôles concrets qui existent dans le produit. Aucune revendication de certification — voir la note à la fin.

Jetons d'accès et de rafraîchissement: Jetons d'accès de courte durée avec rotation des jetons de rafraîchissement. La réutilisation d'un jeton pivoté invalide la session.
Hachage des mots de passe: Argon2 avec des sels propres à chaque utilisateur. Les mots de passe ne sont jamais stockés ni journalisés sous une forme récupérable.
Contrôle d'accès basé sur les rôles: Les rôles portent des ensembles de permissions explicites, appliqués par des gardes sur chaque point de terminaison de chaque service — pas seulement dans l'interface.
Identifiants chiffrés: Les secrets de fournisseurs et de connecteurs sont chiffrés au repos avec AES-256-GCM et ne sont jamais renvoyés par une API.
Validation de schéma: Chaque corps de requête est validé selon un schéma Zod avec des bornes explicites de longueur et de taille avant d'atteindre toute logique.
Limitation de débit: Une limitation par compte sur chaque service, afin qu'un client ne puisse pas épuiser la capacité pour tous les autres.
En-têtes de sécurité: Une politique de sécurité du contenu stricte avec des nonces par requête, HSTS, et les en-têtes de durcissement standard sur chaque réponse.
TLS partout: TLS du navigateur jusqu'à la périphérie et de nouveau à chaque étape interne, avec vérification des certificats entre les services.
Caviardage des journaux: Les jetons, mots de passe, clés API et en-têtes d'autorisation sont supprimés avant qu'un journal ne soit écrit.

ClawAI ne détient aujourd'hui aucune certification de sécurité tierce — ni SOC 2, ni ISO 27001, ni HIPAA. Nous décrivons les mécanismes ci-dessus plutôt que de suggérer des garanties que nous n'avons pas obtenues. Les entreprises ayant des exigences formelles devraient nous en faire part afin qu'elles puissent être évaluées dans le cadre d'un engagement.

Observabilité

Chaque service émet les mêmes signaux sous la même forme, et ils atterrissent tous quelque part d'interrogeable. Un opérateur qui se demande « que s'est-il passé pour cette requête » ne devrait pas avoir à ouvrir dix-huit fichiers journaux.

Journaux structurés: Journaux JSON de chaque service et du navigateur, transmis via le bus d'événements et conservés sur une fenêtre glissante.
Corrélation des requêtes: Un identifiant de requête est généré dans le navigateur et transporté à travers chaque étape de service, afin qu'un seul identifiant permette de reconstituer tout le trajet.
Événements d'audit: Un registre séparé et immuable des actions pertinentes pour la sécurité et l'activité, tenu à l'écart des journaux opérationnels.
Grand livre d'utilisation: Chaque appel mesuré est écrit comme une entrée du grand livre. Les chiffres de quota sont dérivés du grand livre, pas d'un compteur susceptible de dériver.
Agrégation de santé: Un service dédié interroge tous les autres services et rapporte une vue consolidée unique de ce qui fonctionne.

Quand quelque chose échoue

Les fournisseurs de modèles connaissent des pannes, des limites de débit et des journées lentes. La plateforme est conçue pour les absorber plutôt que de vous les répercuter sous la forme d'un indicateur de chargement qui ne se résout jamais.

Chaînes de secours: Chaque décision de routage porte une liste ordonnée d'alternatives. Si le modèle choisi échoue, le suivant est essayé automatiquement et la substitution est enregistrée.
Évitement basé sur la santé: Les connecteurs font l'objet d'une vérification de santé continue, et un fournisseur en échec est contourné par le routeur jusqu'à ce qu'il se rétablisse.
Nouvelles tentatives sûres: Les gestionnaires d'événements tolèrent la livraison en double, de sorte qu'une nouvelle tentative corrige un échec au lieu de facturer votre quota deux fois.
Les erreurs sont visibles: Lorsque toutes les options échouent, une erreur explicite est écrite dans la conversation et poussée dans le flux. Il n'y a aucun échec silencieux qui laisse l'interface en attente.
Périmètre d'impact: Des processus et des bases de données séparés signifient qu'une défaillance dégrade une seule capacité. La panne de la génération d'images ne vous empêche pas de discuter.

La même architecture, dans votre réseau

Tout ce qui est décrit sur cette page concerne le service hébergé, mais l'architecture n'y est pas liée. Les mêmes dix-huit services, le même bus d'événements et le même modèle de données peuvent être déployés dans le réseau d'une entreprise.

Dans cette configuration, les fournisseurs de modèles externes sont remplacés par des modèles à poids ouverts servis sur vos propres GPU, afin qu'aucun prompt, document ou conversation ne quitte votre infrastructure. C'est un engagement dimensionné sur mesure plutôt qu'un forfait que l'on achète — nous le dimensionnons avec votre équipe.

Parlez-nous d'un déploiement privé

Voyez-le en action

Le moyen le plus rapide de juger une architecture est d'utiliser ce qu'elle produit. Le forfait gratuit prend une minute à configurer.

Créez votre compte Parlez-nous d'un déploiement privé