Déploiement souverain
En bref
L'enjeu
Données de santé, secret bancaire, informations classifiées ou secrets industriels : certaines données ne peuvent pas être envoyées à un service d'IA externe. Pour elles, l'IA doit venir aux données.
La livraison en environnement isolé
Artefacts signés
Images, charts et SBOM signés avec Cosign
Miroir Harbor
Registre interne, analyse Trivy
Git interne
Configuration versionnée par environnement
Argo CD
Déploiement GitOps
Admission Kyverno
Seuls les artefacts signés sont admis
Cluster isolé
Modèles locaux servis par vLLM
Topologies
| Topologie | Description et usage |
|---|---|
| 01 - Brique seule | Le Control Plane, PostgreSQL et un composant, par exemple la passerelle de modèles, avec authentification par clés API. Pour démarrer vite sur un besoin précis. |
| 02 - SaaS mutualisé | Un cluster, plusieurs tenants isolés par RLS, OpenFGA et des namespaces Cilium. Pour proposer l'IA à plusieurs entités. |
| 03 - Tenant dédié | Un namespace ou un cluster par grand compte, avec son montage OpenBao et son pool GPU. Pour les entités aux exigences renforcées. |
| 04 - Souverain sur site | Un cluster isolé du réseau, uniquement des modèles locaux vLLM, un miroir Harbor et Argo CD depuis un Git interne. Pour les données qui ne sortent jamais. |
| 05 - Hybride | vLLM en local pour les données restreintes, fournisseurs distants autorisés par politique pour les autres classifications. Pour concilier coût, qualité et confidentialité. |
Installation
| Méthode | Ce que fait l'agent | Services où c'est la méthode par défaut |
|---|---|---|
| binary (25) | Télécharge l'archive officielle, vérifie son empreinte sha256, l'extrait dans un dossier versionné du service, fait pointer un lien current dessus, puis lance le binaire par une unité systemd. | Prometheus, Keycloak, OpenSearch, Qdrant, NATS, Temporal, OPA, OpenFGA, OpenBao, SeaweedFS, Collecteur OpenTelemetry, Falco... |
| podman (16) | Récupère l'image épinglée par empreinte (podman pull depuis le registre interne, ou podman load d'une archive), puis la lance par systemd avec podman run --rm --pull never --log-driver journald, dans un réseau isolé par défaut ; les GPU NVIDIA passent par CDI. | PostgreSQL, Redis, ClickHouse, vLLM, Ollama, ClamAV, MySQL, Opik, Marquez, Label Studio, LLaMA-Factory, Navin Enterprise |
| python (8) | Crée un environnement virtuel sur la machine et installe avec pip install --no-index --find-links depuis le dépôt de paquets précompilés du miroir, sans accès à Internet. | LiteLLM, Docling, Presidio, Hébergement MCP, YARA-X |
| package (6) | Installe les paquets de la distribution avec dnf (famille RHEL) ou apt (famille Debian), puis utilise l'unité systemd fournie par le paquet. | APISIX, HAProxy, keepalived, Kamailio, Asterisk, RTPengine |
Plusieurs services proposent plusieurs méthodes (Podman est accepté par 38 services, le binaire par 26) : l'opérateur choisit à l'installation. Les 7 autres services n'installent pas de serveur permanent : 3 tournent seulement quand un test est demandé (garak, promptfoo, Ragas), 3 sont des bibliothèques fournies aux développeurs (Haystack, SDK OpenLineage, Tink) et Navin SM est distribué aux postes de travail. Enfin, 25 services peuvent aussi être simplement connectés s'ils existent déjà chez le client, sans rien installer.
Avant d'installer un service, l'agent ajoute ce qui manque, par exemple Podman, Python 3.11 et son module venv, ou tar. Il ne le fait pas sur une machine sans droits root.
Tout vient du miroir local du Manager, jamais d'Internet au moment de l'installation.
Le serveur du Manager prépare la liste des tâches : récupérer, créer les dossiers, écrire la configuration et l'unité, démarrer, contrôler la santé. L'agent les exécute sur la machine.
Chaque composant devient une unité navin-<service>-<composant>.service, et l'agent ne pilote que les unités navin-*. Les journaux vont dans journald.
Podman n'a pas de démon permanent et s'intègre directement à systemd. Docker ne sert dans le projet qu'à la pile de développement locale et à la construction des images.
Exploitation autonome
vLLM sert vos modèles sur vos GPU ; LiteLLM les expose derrière la même passerelle que les fournisseurs distants.
Miroir Harbor, Git interne et Argo CD : la plateforme s'installe et se met à jour sans accès à Internet.
SBOM générés par Syft, images analysées par Trivy, signées avec Cosign et admises par Kyverno.
Paquets DEB, RPM et pacman pour Debian, Ubuntu, RHEL, Rocky, Alma et Arch Linux, avec archives d'installation hors ligne.
OpenTofu ou Terraform pour les clusters, GitOps pour les applications, un cluster par environnement.
Velero sauvegarde les données et les configurations ; la haute disponibilité est déclarée service par service.
SeaweedFS, Ceph ou le stockage S3 de votre choix, avec Object Lock pour les preuves d'audit.
La console d'exploitation installe, configure et pilote les services, les hôtes et les clusters, sans saisie manuelle.
La preuve
Politiques, audit, quotas et passerelles sont identiques dans le cloud, sur site ou en environnement isolé : vos équipes n'ont qu'un modèle de sécurité à valider.
Pour aller plus loin
D'une brique seule à un cluster entièrement isolé du réseau : les cinq topologies de déploiement de Navin Enterprise AI, la chaîne GitOps avec images signées et les paquets système avec archives hors ligne pour Debian, Ubuntu, la famille RHEL et Arch Linux.
Nos architectes étudient vos contraintes d'hébergement, de réseau et de conformité.