← Accueil · Stacks & langages · Toute la doc

Stack IA : FastAPI + pgvector + Redis + OOS + GPU sur Outscale

Un assistant RAG ou une API d’inférence qui reste sur un cloud souverain : FastAPI pour l’API, PostgreSQL avec pgvector pour les embeddings, Redis pour le cache et les jobs, OOS pour les documents, et une VM GPU Outscale pour servir le modèle. bige-ops pose l’ensemble et le chiffre, GPU compris.

flowchart LR
  U["Internet"] -->|"HTTPS 443"| LBU["LBU internet-facing"]
  subgraph NET ["Net 10.0.0.0/16"]
    APP["VM rag-app · tinav6.c4r8p2
FastAPI :8000 · front
worker d’ingestion"]
    GPU["VM rag-inference · tinav7.c16r64p1
1 × NVIDIA L40 (48 Go)"]
    PG[("VM rag-postgres
PostgreSQL 17 + pgvector")]
    RD[("VM rag-redis
Redis 8")]
  end
  LBU --> APP
  APP -->|"inférence"| GPU
  APP -->|"5432 · recherche vectorielle"| PG
  APP -->|"6379"| RD
  APP -->|"S3 API"| OOS[("OOS
documents + backups")]
      

Pourquoi cette stack tourne bien sur Outscale

• Des bases rapides et stables : Les volumes io1 garantissent jusqu’à 13 000 IOPS par volume : tes requêtes gardent des temps de réponse réguliers, même sous charge. Volumes
• Des GPU à la demande : Des cartes NVIDIA récentes (L40, H100…) au catalogue public : tu ajoutes la puissance de calcul quand ton modèle en a besoin.
• Un réseau privé et des sauvegardes sûres : Tes bases restent dans le réseau privé de ton projet, jamais exposées à Internet. Les sauvegardes partent vers l’Object Storage, compatible S3 et répliqué entre plusieurs zones.
• Prêt pour les clients exigeants : Régions qualifiées SecNumCloud 3.2 pour le secteur public, certification HDS pour la santé. Pourquoi Outscale · SecNumCloud 3.2

Architecture sur Outscale

• VM app tinav6.c4r8p2 : l’API FastAPI (Uvicorn, port 8000), le front et le worker qui découpe, vectorise et indexe les documents.
• PostgreSQL 17 + pgvector sur VM privée (image pgvector/pgvector:pg17, disque io1) : données métier et embeddings dans la même base, index HNSW ou IVFFlat.
• Redis 8 privé : cache de réponses, files de jobs d’ingestion.
• VM d’inférence privée tinav7.c16r64p1 (16 vCPU, 64 GiB, performance la plus haute) avec un GPU flexible NVIDIA L40 de 48 Go de VRAM, disque de 200 GiB pour les poids du modèle. Le L40 se rattache à une VM de génération v7 en p1, jusqu’à 35 vCPU et 250 GiB : tinav7.c16r64p1 est dans les clous. bige-ops chiffre la VM et son GPU déclaré ; l’allocation et l’attachement du fGPU se font dans Cockpit ou par l’API Outscale.
• OOS : 500 GiB de documents sources (API S3) et 100 GiB de backups PostgreSQL.

Coût mensuel estimé

Calculé avec bige-ops estimate --json sur le catalogue public Outscale synchronisé le 17 septembre 2026, Région eu-west-2, en € HT par mois (730 heures). Estimation indicative, sur la grille publique ; le trafic sortant est à 0 € HT au catalogue public de cette Région.

La VM GPU représente 2 217,84 € du total ; le reste de la stack (app, bases, LBU, OOS, NAT) pèse 436,81 € HT par mois. Le GPU se paie à l’heure : une VM d’inférence arrêtée hors des heures d’usage réduit d’autant la facture. Le catalogue Outscale propose aussi A100, H100 et H200 selon la taille du modèle.

Le projet utilisé, à reproduire chez toi :

bige-ops init -n stack-ai-fastapi-pgvector-gpu
bige-ops add layout custom --name rag --runtime python --web spa --worker \
  --db postgres --db redis --topology multi-vm --lbu
# puis project.yaml ajusté comme ci-dessous
bige-ops validate
bige-ops estimate --json

name: stack-ai-fastapi-pgvector-gpu
region: eu-west-2
enable_nat: true
components:
- type: stack
  name: rag
  topology: multi-vm
  services: [api, web, worker, postgres, redis]
  images: {postgres: 'pgvector/pgvector:pg17', redis: 'redis:8-alpine'}
  sizing: {app_vm: tinav6.c4r8p2, postgres_vm: tinav6.c4r8p2, redis_vm: tinav6.c2r2p3}
  service_config:
    postgres:
      backup: {enabled: true, oos_bucket: rag-backups}
- type: load_balancer
  name: rag-web
  scheme: internet-facing
  backend_vms: [rag-app]
- {type: vm, name: rag-inference, size: tinav7.c16r64p1, subnet: private, volume_size: 200,
  gpu: 1, gpu_type: Nvidia L40}
- {type: oos_bucket, name: rag-documents, bucket: rag-documents, size: 500, purpose: documents}
- {type: oos_bucket, name: rag-backups, bucket: rag-backups, size: 100, purpose: backups}

Données et vecteurs : versions, backups, failles connues

PostgreSQL. PostgreSQL 18 (supporté jusqu’en novembre 2030), 17 (novembre 2029), 16 (défaut bige-ops, novembre 2028) et 15 (novembre 2027) sont maintenus ; 14 sort du support le 12 novembre 2026. La simulation épingle pgvector/pgvector:pg17. Source : politique de versions PostgreSQL. Côté durcissement : un rôle applicatif dédié (jamais le superutilisateur), des règles pg_hba.conf limitées au CIDR du Net en scram-sha-256, et des mises à jour mineures régulières (la majeure reste celle que tu épingles).

Redis. La simulation garde redis:8-alpine, le tag par défaut de bige-ops : il suit la dernière Redis 8. Épingle la mineure (par exemple 8.10) si tu veux un build strictement reproductible. Côté durcissement : un mot de passe ou des ACL, le protected mode actif, aucune exposition publique, et les commandes d’administration réservées à un utilisateur dédié (sécurité Redis).

pgvector. L’image officielle pgvector/pgvector embarque PostgreSQL et l’extension ; épingle la combinaison (pg17, ou 0.8.7-pg17 pour figer aussi l’extension). Doc : pgvector.

Le backup est activé dans la simulation (backup.enabled + bucket OOS) : bige-ops crée le bucket, protégé contre la destruction, et prépare backup.sh (bucket, endpoint, planning) où tu branches le dump. Sans backup, Visual, preflight et plan te le signalent. Détail : OOS & backups.

Exposition : ce qui est ouvert, et à qui

• Une seule entrée publique : le LBU internet-facing. Ajoute-lui un listener HTTPS 443 avec le server_certificate_id (ORN d’un certificat chargé dans EIM) vers le port 8000 de la VM app ; le TLS se termine sur le LBU.
• VM app en subnet public : avec un LBU, ses ports applicatifs (ceux de tes services : 3000, 3001, 8000, 8080…) n’acceptent que le CIDR du Net (10.0.0.0/16), donc le trafic applicatif passe par le LBU. Sa première IP publique est offerte et sert au deploy SSH.
• Bases en subnet privé, sans IP publique, chacune derrière son security group qui n’accepte que le CIDR du Net sur son port. Jamais de listener LBU, d’IP publique ni de règle 0.0.0.0/0 vers une base : pour l’administrer, passe par un tunnel SSH via la VM app.
• Security group de la VM app : il ouvre SSH (22) pour le deploy, ainsi que HTTP (80) et HTTPS (443). Resserre SSH sur tes CIDR connus avant la production, et fais écouter ton app sur un port applicatif (3000, 8000, 8080…), que seul le Net atteint.
• NAT service : la sortie Internet du subnet privé (images, mises à jour), sans aucune entrée.
• VM d’inférence en subnet privé, sans IP publique : seule l’API l’appelle, jamais le navigateur. Le serveur de modèle n’a pas besoin d’entrée Internet ; il tire ses poids via le NAT ou depuis OOS.

Rappel Outscale : deux VMs d’un même subnet se parlent sans passer par les security groups ; séparer l’app (public) et la data (privé) les remet dans le chemin. Détail : réseau · ouvrir ou non, security groups Outscale.

Vulnérabilités : ce que bige-ops vérifie

Des failles, il y en aura toujours : l’important est de voir d’abord celles qui sont exposées. bige-ops lit le code de tes dépôts sur ton poste, compare tes bibliothèques à la base publique des failles connues des bibliothèques open source (OSV) et, avec ta clé OpenCVE, les composants de ta stack au registre mondial des vulnérabilités (CVE). Puis il classe tout par urgence : ce qui est exposé à Internet d’abord. Pourquoi le refaire toi-même ? C’est chez toi, sur ton poste, et c’est gratuit. La méthode complète : ce que bige-ops vérifie.

Avec ta clé API OpenCVE (Settings), l’onglet Vulnérabilités lit ta simulation : chaque composant reconnu, image Docker ou paquet installé, est rapproché de sa fiche éditeur / produit, à raison d’une requête par produit. Les failles connues qui remontent sont classées par risque :

• Gravité : chaque faille a une note sur 10 (CVSS) ; critique dès 9, haute dès 7, moyenne dès 4. Une faille déjà exploitée par des attaquants (elle figure sur la liste KEV de la CISA, l’agence américaine de cybersécurité) compte au moins comme haute.
• Exposition dans ta simulation : un composant joignable depuis Internet, directement ou derrière le LBU, garde sa gravité ; un composant en subnet privé descend d’un cran, sauf si la faille est déjà exploitée.
• Départage : à risque égal, les failles déjà exploitées d’abord, puis la note sur 10, puis la probabilité d’être exploitée prochainement (EPSS). Le filtre « important » ne garde que les failles déjà exploitées ou notées 7 et plus.

Le rapprochement se fait au niveau du produit, pas de la version : à toi de recouper avec la version que tu as épinglée. Une image en latest ressort en plus comme « version non épinglée ». Le résultat est mis en cache dans la simulation et se rafraîchit à la demande.

Sur ton poste, sans clé ni IA (le mode direct) : bige-ops repère les routes FastAPI (@app.get, @router.post) et celles qui sont accessibles sans être connecté, cherche les mots de passe ou clés écrits en clair dans le code (clés d’API de modèles comprises), la vérification des certificats HTTPS désactivée et les requêtes à la base construites avec ce que tape l’utilisateur (injection SQL), et vérifie tes dépendances PyPI épinglées dans OSV. Détail : Python sur Outscale.

bige-ops advanced va plus loin avec ta propre clé d’IA : un agent d’audit relit les pistes déjà repérées (pages ou API accessibles sans être connecté, passages de code à risque, pièges connus du framework), confirme les vraies failles, écarte les fausses alertes et classe chacune par type de faille, selon le catalogue de référence (CWE), avec son urgence (de P0, la plus urgente, à P3), son exposition et un ticket GitHub (issue) prêt à ouvrir. Les appels partent de ton poste, avec des extraits ciblés de ton code ; l’agent n’applique rien et ne lit pas tes secrets. Voir l’audit approfondi.

Ce que bige-ops vérifie avant le deploy

• bige-ops validate : structure du projet, services custom (image ou dépôt requis), listener HTTPS refusé sans ORN de certificat EIM, et rappel du NAT dès qu’une VM privée existe (c’est lui qui permet docker pull et apt depuis le subnet privé).
• bige-ops preflight : clés Outscale présentes, OMI résolue, stack déclarée, IP des hôtes après l’apply, Dockerfile trouvé, secrets de build et d’exécution présents dans le coffre, jeton GitHub pour les dépôts privés, et alerte si une base n’a pas de backup vers OOS. Une erreur bloque le deploy.
• bige-ops plan : le plan Terraform avant tout apply, avec les risques de perte de données signalés ; les buckets OOS sont protégés contre la destruction.
• Vulnérabilités : composants de la stack comparés aux failles connues avec OpenCVE et classés selon leur exposition, images en latest signalées, dépôts relus sur ton poste, sans clé ni IA.

OpenCVE, la source des failles connues

Pour savoir quelles failles connues touchent les briques de ta stack, bige-ops s’appuie sur OpenCVE. OpenCVE rassemble les failles publiées dans le registre mondial des vulnérabilités (CVE) et ses sources officielles (NVD, MITRE, liste KEV des failles déjà exploitées tenue par la CISA, l’agence américaine de cybersécurité…), donne à chacune sa note de gravité sur 10 (CVSS) et sa probabilité d’être exploitée (EPSS), et les range par éditeur et par produit, consultables dans son explorateur. Le projet est open source : son code, ses issues et les contributions de sa communauté vivent sur GitHub, et il s’installe aussi chez toi. Merci à ses mainteneurs et à tous ceux qui font vivre ce référentiel : c’est grâce à eux que chaque composant de ta simulation a sa fiche de failles à jour.

Docs officielles

• FastAPI
• pgvector
• GPU flexibles Outscale
• OOS
• Redis
• SecNumCloud

Langages : Python.

Pour aller plus loin : layouts & topologies, VMs, OKS, volumes BSU, OOS, LBU, réseau, régions, bases de données, catalogue de prix. Toutes les stacks : stacks & langages.