> ## Documentation Index
> Fetch the complete documentation index at: https://infra-docs.kaeyros.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Vue d'ensemble : les trois plans de la plateforme

> Découvrez les trois plans superposés de la plateforme Kaeyros Analytics : matériel, cluster Kubernetes et services internes, avec le schéma d'ensemble.

La plateforme Kaeyros Analytics s'organise en trois plans distincts qui se superposent. Comprendre leur séparation est essentiel, car les confondre est la source la plus fréquente de malentendus opérationnels. Cette page décrit chaque plan, ce qui le pilote, et comment ils s'articulent dans le schéma d'ensemble.

## Les trois plans

| Plan | Ce que c'est | Ce qui le pilote |
| - | - | - |
| **Plan matériel** | 11 serveurs dédiés chez Hetzner, 2 load balancers, stockage objet | Console Hetzner, manuellement |
| **Plan cluster** | Cluster Kubernetes de 4 nœuds, 100 namespaces, \~600 pods | ArgoCD depuis `argo-production` |
| **Plan services internes** | Machine dédiée (GitLab, Vault, Passbolt, Odoo, Airflow, supervision) | docker compose, manuellement |

> [!NOTE]
>
> Dans les conversations quotidiennes, "la prod" désigne généralement le **plan cluster** (les applications qui servent les clients). Quand on parle de "le serveur de monitoring" ou de "GitLab", on désigne le **plan services internes**.

## Le schéma d'ensemble

Ce diagramme montre comment les trois plans s'articulent, du trafic entrant jusqu'aux sauvegardes.

```mermaid theme={null}
flowchart TB
    subgraph Users["Utilisateurs"]
        U1["Clients Afrique de l'Ouest/centrale"]
        U2["Projets européens"]
        U3["Équipes internes"]
    end

    subgraph Cloud["Périphérie Cloudflare"]
        CF1["18 zones DNS"]
        CF2["TLS, WAF"]
    end

    subgraph LB["Load Balancers Hetzner"]
        LB1["kaeyros.org (95.217.173.179) Helsinki"]
        LB2["sem-a.com (46.225.34.99) Nuremberg"]
    end

    subgraph Cluster["CLUSTER Kubernetes Helsinki"]
        direction TB
        T["Traefik (ingress)"]
        subgraph Apps["~326 applications"]
            A1["dash / back / front / api"]
            A2["100 namespaces"]
        end
        subgraph Data["Données"]
            PG["~95 bases PostgreSQL (opérateur Zalando)"]
        end
        subgraph Socle["Socle partagé"]
            S1["ArgoCD"]
            S2["Argo Rollouts"]
            S3["cert-manager"]
            S4["Longhorn"]
            S5["external-secrets"]
            S6["Rancher"]
        end
    end

    subgraph Deploy["Chaîne de déploiement"]
        D1["Développeur"]
        D2["GitHub (kaeyros-analytics-org)"]
        D3["GitHub Actions"]
        D4["ghcr.io"]
        D5["argocd-image-updater"]
        D6["ArgoCD"]
    end

    subgraph Internal["Serveur services internes"]
        I1["GitLab"]
        I2["Vault / Passbolt"]
        I3["Odoo"]
        I4["Airflow / n8n"]
        I5["VictoriaMetrics / Grafana / Alertmanager / Wazuh"]
    end

    subgraph Storage["Stockage objet"]
        ST1["AWS S3 eu-central-1 (sauvegardes, datalake, statiques)"]
        ST2["Hetzner Object Storage"]
        ST3["DynamoDB"]
    end

    subgraph OBS["Observabilité"]
        O1["Métriques / journaux"]
        O2["Alertes ntfy + WhatsApp"]
    end

    U1 --> CF1
    U2 --> CF1
    U3 --> CF1
    CF1 --> CF2
    CF2 --> LB1
    CF2 --> LB2
    LB1 --> T
    LB2 --> T
    T --> Apps
    Apps --> PG
    Apps --> ST3
    Apps --> ST2
    PG --> ST1

    D1 --> D2
    D2 --> D3
    D3 --> D4
    D4 --> D5
    D5 --> D6
    D6 --> S1
    S1 --> Apps

    Cluster --> O1
    Internal --> O1
    O1 --> O2

    Internal -.-> Cluster
```

## Ce qu'il faut retenir

> **Un seul cluster pour les clients**
>
> Tout ce qui sert les clients tourne dans un seul cluster Kubernetes hébergé à Helsinki. C'est le coeur opérationnel de la plateforme.

> **Le cluster est déclaratif**
>
> Le cluster n'est jamais modifié à la main. Il reflète en permanence l'état du dépôt `argo-production` sur GitHub. Toute modification manuelle serait écrasée.

> **Images depuis ghcr.io**
>
> Les images conteneur viennent du registre GitHub Container Registry (ghcr.io). Elles sont construites automatiquement par GitHub Actions à chaque push.

> **Services internes isolés**
>
> Les outils internes (code, secrets, ERP, ordonnanceur, supervision) tournent sur une machine séparée gérée avec docker compose. Ils ne sont pas dans le cluster Kubernetes.

> **Trafic via Cloudflare et Traefik**
>
> Le trafic entrant passe obligatoirement par Cloudflare (DNS, TLS, WAF), puis par un load balancer Hetzner, avant d'atteindre Traefik qui route vers les applications.

> [!NOTE]
>
> Pour toute question sur l'architecture globale ou pour signaler une erreur dans ce schéma, contactez l'équipe DevOps : [devops@kaeyros-analytics.com](mailto:devops@kaeyros-analytics.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.