The architecture behind the AI operating layer.

Architecture de référence

Orchestration multi-modèle avec piste d'audit par architecture.

Le schéma ci-dessous est la configuration par défaut. Chaque mission part de là, puis s'adapte aux contraintes du client (déploiement souverain, catalogue de modèles, fournisseur d'identité, stack d'observabilité). Les variations sont documentées par mission dans l'architecture decision record.

                ┌────────────────────────────────────────────────────────┐
                │   YOUR BUSINESS WORKFLOWS                              │
                │   (CRM, ERP, claims, KYC, clinical, ticketing, ...)    │
                └─────────────┬────────────────────────┬─────────────────┘
                              │                        │
                              ▼                        ▼
                ┌──────────────────────────┐ ┌────────────────────────┐
                │  IDENTITY & ACCESS       │ │ POLICY ENGINE          │
                │  Okta / Azure AD /       │ │ OPA / Cedar / custom   │
                │  SailPoint / Entra       │ │ (per-tenant, per-task) │
                └─────────────┬────────────┘ └───────────┬────────────┘
                              │                          │
                              ▼                          ▼
                ┌───────────────────────────────────────────────────────┐
                │   HIKARI BLUE OPS · the operating layer               │
                │   ┌──────────────┐  ┌──────────────┐ ┌────────────┐   │
                │   │ Multi-model  │  │ Audit trail  │ │ Kill       │   │
                │   │ orchestrator │  │ (immutable)  │ │ switch     │   │
                │   └──────┬───────┘  └──────┬───────┘ └────┬───────┘   │
                │          │                 │              │           │
                │   ┌──────┴─────────────────┴──────────────┴────┐      │
                │   │  Tool calls, retrieval, evaluation harness │      │
                │   └────────────────────┬───────────────────────┘      │
                └───────────────────────┬┴──────────────────────────────┘
                                        │
              ┌──────────┬───────────────┼──────────────┬───────────┐
              ▼          ▼               ▼              ▼           ▼
        ┌──────────┐ ┌─────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
        │ Anthropic│ │ OpenAI  │  │ Mistral  │  │ Google   │  │ Local /  │
        │ Claude   │ │         │  │          │  │ Vertex   │  │ on-prem  │
        └──────────┘ └─────────┘  └──────────┘  └──────────┘  └──────────┘

         OBSERVABILITY            DATA RESIDENCY              REGULATOR PORTAL
         OpenTelemetry         EU / US / on-prem            Evidence export
         Sentry / Grafana      Customer-managed keys        DORA / NIS2 / MDR
         Datadog / Honeycomb   Zero cleartext server-side    EU AI Act Art. 12
      

• Multi-modèle par architecture

  Routage par tâche, par profil de risque, par coût. Le changement de modèle se fait en quelques heures, jamais en plusieurs mois. Aucun verrouillage fournisseur. Le catalogue par défaut couvre Anthropic, OpenAI, Mistral, Google Vertex. Modèles auto-hébergés et inférence on-prem pris en charge quand la réglementation l'exige.

• Piste d'audit par architecture

  Chaque prompt, chaque sortie, chaque action d'opérateur, chaque changement de modèle, chaque déclenchement du kill switch : enregistré de façon immuable par la plateforme elle-même. Interrogeable par les équipes client. Exportable vers les portails des régulateurs. Pas une fonctionnalité greffée avant un audit.

• Souverain par construction

  Résidence des données sélectionnable par workload : UE, US, on-prem. Chiffrement au repos (AES-256) et en transit (TLS 1.3). Zéro donnée en clair côté serveur. Clés gérées par le client sur AWS KMS, Azure Key Vault, GCP KMS, HashiCorp Vault.

• Le kill switch comme propriété

  Arrêter, ralentir ou revenir en arrière par workflow, par modèle, par utilisateur. Déclenché depuis la console d'exploitation, par un événement de violation de policy, ou par une notification du régulateur. Comportement documenté dans le runbook de la mission, testé chaque trimestre.

Stack policy

Ce que nous utilisons par défaut. Ce que nous ne livrons pas.

Publié pour qu'un CTO client sache ce qui arrive dans son environnement avant la première semaine. Les écarts sont documentés par mission dans l'architecture decision record et approuvés par le partner de la Practice Engineering.

• Default stack

  TypeScript et Python pour le code applicatif. Go pour les services critiques en performance. Postgres pour le relationnel, avec extensions vectorielles pour le retrieval. Runtime conteneurisé sur Kubernetes (EKS, AKS, GKE) ou serverless quand c'est pertinent (AWS Lambda, Cloudflare Workers, Vercel). CI/CD sur GitHub Actions ou GitLab CI. IaC via Terraform ou Pulumi.

• Orchestration & agents

  LangGraph ou orchestrateur maison selon le profil de risque de la mission. Tool use Anthropic, function calling OpenAI, function calling Mistral pris en charge. Open Policy Agent pour les contrôles de policy à l'exécution. Toujours associé à des points de contrôle human-in-the-loop quand les décisions portent à conséquence.

• Ce que nous ne livrons pas

  Les frameworks d'agents mono-fournisseur qui verrouillent le choix du modèle dans le framework lui-même. Les wrappers LLM d'éditeurs en boîte noire, sans prompts ni traces exportables. Le code de production sans tests, observabilité ni runbooks. Tout déploiement de modèle sans kill switch relié à la console d'exploitation.

• Posture open source

  Nous utilisons l'open source là où il est mature, sous licence compatible et bien maintenu. Nous ne livrons pas de micro-bibliothèques NPM à la provenance incertaine. SBOM publié à chaque build (voir Trust Center, sécurité de la supply chain→).

Public artifacts

Ce que nous publions pour que vous puissiez évaluer à froid.

Un CIO doit pouvoir se forger un avis sur l'architecture sans réunion commerciale. Voici les artefacts publics.

• Architecture pour la gouvernance des agents IA (livre blanc)

  WP-HB-2026-00426, vingt pages, en français. Publication de référence sur la gouvernance des agents dans l'entreprise régulée. Édition anglaise au T3 2026.

  Télécharger le livre blanc (PDF, FR)→

• Operating System, la méthode

  Les six phases de chaque mission Hikari Blue : Diagnostic, Architecture, Build, Governance, Adoption, Run. Une méthode, pas un framework.

  Lire l'Operating System→

• Trust Center

  Posture de conformité, sous-traitants ultérieurs, architecture de sécurité, délais de réponse aux incidents, cadre juridique, assurance, sécurité de la chaîne d'approvisionnement.

  Ouvrir le Trust Center→

• Newsroom

  Des briefings de terrain sur la gouvernance de l'IA, les systèmes agentiques, la régulation, l'architecture d'entreprise. Écrits depuis le terrain, pas depuis le fil d'actualité.

  Lire la Newsroom→