LLM Security

Sécurité IA pour architectes : SI résistant aux usages non maîtrisés

Guide architecte SI pour absorber l'IA : plateforme IA centrale, gateway, ABAC, observabilité, gestion shadow AI, patterns d'architecture, gouvernance technique.

Naim Aouaichia
14 min de lecture
  • architecte
  • SI
  • architecture
  • shadow AI
  • LLM security

L'architecte SI en 2026 fait face à un défi structurel : l'IA est partout (officielle ou shadow), elle évolue à un rythme imprévisible (nouveaux modèles, nouveaux frameworks chaque trimestre), et elle interagit avec tout le SI (data, identity, network, applications). Concevoir un SI résistant ne consiste pas à interdire ou à figer, c'est à construire une architecture qui absorbe les usages, les fournisseurs, les évolutions, tout en garantissant gouvernance, sécurité et résilience. Cet article documente les patterns d'architecture (plateforme IA centrale, AI Gateway, observabilité unifiée, ABAC commun), la gestion structurelle du shadow AI, les architectures de référence et les principes de gouvernance technique.

Pour les détails RAG : architecture RAG sécurisée. Pour la stratégie défensive : stratégie de défense en profondeur. Pour le pendant Google : SAIF.

Le mandat de l'architecte SI face à l'IA

Trois propriétés rendent la mission architecte sur l'IA spécifique :

  1. Volatilité du périmètre : usages IA croissants chaque trimestre, fournisseurs évoluant, modèles obsolètes en 12-18 mois. L'architecture doit absorber sans réécriture massive.

  2. Cross-cutting par construction : IA touche data, identity, network, applications, observabilité, sécurité. L'architecte est le seul rôle qui voit tous ces axes simultanément.

  3. Tension classique vs IA : architectures data classiques (data lake, warehouse) coexistent avec nouveaux patterns IA (vector DB, embedding pipelines). L'architecte arbitre.

Tip, L'architecte SI 2026 sur l'IA n'a pas à maîtriser les détails ML. Il doit comprendre les propriétés différenciantes (latence variable, sortie non-déterministe, coût par requête, supply chain ML, surface étendue) pour intégrer correctement.

Les 4 décisions architecturales structurantes

Décision 1, Plateforme IA centrale vs silos

CritèreSilos par projetPlateforme centrale
Setup initialRapide (chaque équipe)Lourd (3-6 mois)
Time-to-market par projetRapide à court termePlus lent au début, accéléré ensuite
Cohérence sécuritéVariableÉlevée
ObservabilitéFragmentéeUnifiée
Coût opérationnelMultiplicatif (×N projets)Économies d'échelle
Gestion shadow AIDifficileFacilitée (offre alternative)
ConformitéDistribuéeCentralisée

Recommandation 2026 : silos acceptables jusqu'à 3-5 cas d'usage, plateforme centrale obligatoire au-delà. Migration progressive : nouveaux projets sur plateforme, anciens migrés sur 12-24 mois.

Décision 2, Multi-cloud / multi-provider IA

L'écosystème IA évolue vite. Verrouillage à un seul fournisseur = risque structurel :

  • Pricing change (DeepSeek 2025 a recompacté l'écosystème).
  • Fournisseur déprécie un modèle (GPT-4 vers GPT-5 vers GPT-6).
  • Géopolitique (sanctions, restrictions exports US-Chine).
  • Schrems III potentiel (transferts UE-US).

Architecture cible : abstraction par AI Gateway compatible multiples fournisseurs.

# Avec LiteLLM : un seul SDK pour tous fournisseurs
from litellm import completion
 
# Le gateway route selon configuration
response = completion(
    model="gpt-4o",  # ou "claude-sonnet-4-6", "gemini-2-pro", "mistral-large", "llama-3-70b" (self-hosted)
    messages=[{"role": "user", "content": "..."}],
    fallbacks=["claude-sonnet-4-6", "gemini-2-pro"],  # fallback automatique
)

Décision 3, Cloud public vs souverain

Décision multi-axes selon sensibilité :

Niveau donnéesRecommandation
Publiques / non-sensiblesCloud public hyperscaler (AWS, Azure, GCP)
Internes entrepriseCloud public en région UE explicite
Sensibles (RH, finance, juridique)Cloud UE souverain ou SecNumCloud-équivalent
Très sensibles (santé, défense, OIV)SecNumCloud ou self-hosted air-gapped

Voir recommandations ANSSI pour le détail souveraineté.

Décision 4, Self-hosted vs API externe

CritèreAPI externe (OpenAI, Anthropic, etc.)Self-hosted (Llama, Mistral)
Time-to-marketRapideLent (6+ mois)
Qualité modèleSOTA continuInférieur (modèles open-weights)
CoûtVariable selon usageFixe (infra GPU)
SouverainetéDépend fournisseurTotale
Compétences requisesModéréesMLOps + GPU ops avancées
Mises à jourAutomatiquesManuelles

Pattern hybride courant : API externe pour la majorité des cas, self-hosted pour cas critiques (santé patients, défense, OIV) ou très haute volumétrie.

Architecture de référence, Plateforme IA centrale

┌──────────────────────────────────────────────────────────────────┐
│                  Utilisateurs / Applications                       │
└──────────────────────────────────┬───────────────────────────────┘

┌──────────────────────────────────▼───────────────────────────────┐
│  AI Gateway (LiteLLM / Portkey / Cloudflare AI Gateway)          │
│  - Auth (OIDC/JWT)                                                │
│  - Rate limiting + cost tracking                                  │
│  - Routage multi-modèles                                          │
│  - Fallback + circuit breaker                                     │
│  - Input filter (LLM Guard, Lakera)                              │
└──────────────────┬───────────────────────────────────────────────┘

       ┌───────────┴──────────────┬─────────────────┐
       │                          │                 │
┌──────▼────────┐       ┌─────────▼────┐    ┌──────▼─────────┐
│ LLM API       │       │ LLM API       │    │ Self-hosted    │
│ externes      │       │ régions UE    │    │ (vLLM/TGI/     │
│ (OpenAI, etc.)│       │ (Azure OpenAI)│    │  Ollama)       │
└───────────────┘       └───────────────┘    └────────────────┘
 
┌──────────────────────────────────────────────────────────────────┐
│  Vector DB partagée (Pinecone / Weaviate / Qdrant / pgvector)    │
│  - Multi-tenancy native                                           │
│  - ACL propagées (ABAC commun)                                    │
│  - Audit logs                                                     │
└──────────────────────────────────────────────────────────────────┘
 
┌──────────────────────────────────────────────────────────────────┐
│  IAM / ABAC service (OpenFGA / Cedar / Permit.io)                 │
│  - Politiques fine-grained                                        │
│  - Tokens éphémères                                               │
│  - Source-of-truth pour permissions                               │
└──────────────────────────────────────────────────────────────────┘
 
┌──────────────────────────────────────────────────────────────────┐
│  Observabilité centralisée                                        │
│  Langfuse (LLM-spécifique) + OTel collector + SIEM                │
│  - Logs OpenTelemetry GenAI semantic conventions                  │
│  - Métriques cost/latency/quality                                 │
│  - Alertes SOC                                                    │
└──────────────────────────────────────────────────────────────────┘
 
┌──────────────────────────────────────────────────────────────────┐
│  GitOps (ArgoCD / Flux)                                           │
│  - System prompts versionnés                                      │
│  - Configurations agents                                          │
│  - ABAC policies                                                  │
│  - AI BOM                                                         │
└──────────────────────────────────────────────────────────────────┘

Composants par étage, choix recommandés 2026

ÉtageOpen source recommandéCommercial
AI GatewayLiteLLMPortkey, Cloudflare AI Gateway, Kong AI Gateway
Vector DBQdrant, Chroma, pgvectorPinecone, Weaviate Cloud
Inference servervLLM, TGI, OllamaNVIDIA Triton, AWS Bedrock
ABACOpenFGA, OPAAWS Cedar, Permit.io, Auth0 FGA
Observabilité LLMLangfuse, Phoenix ArizeLangSmith, Helicone
SIEMElastic, OpenSearchSplunk, Sentinel, Chronicle
GitOpsArgoCD, Flux(déjà open source matures)
SecretsVault, External Secrets OperatorAWS Secrets Manager, Azure Key Vault
Threat intelOpenCTIRecorded Future, Anomali

Patterns d'architecture spécifiques

Pattern 1, AI Gateway avec fallback multi-providers

# litellm-config.yaml
model_list:
  - model_name: "smart-fallback"
    litellm_params:
      model: gpt-4o
      api_key: os.environ/OPENAI_API_KEY
    fallbacks: ["claude-sonnet-4-6", "gemini-2-pro"]
  
  - model_name: "claude-sonnet-4-6"
    litellm_params:
      model: anthropic/claude-sonnet-4-6
      api_key: os.environ/ANTHROPIC_API_KEY
  
  - model_name: "gemini-2-pro"
    litellm_params:
      model: vertex_ai/gemini-2-pro
      vertex_project: yourcompany-project
      vertex_location: europe-west1  # région UE explicite
 
router_settings:
  routing_strategy: "least-busy"
  fallbacks: 
    - model: "smart-fallback"
      max_attempts: 3
 
guardrails:
  - guardrail_name: "lakera_pre_call"
    litellm_params:
      guardrail: lakera_v2
      mode: pre_call
      api_key: os.environ/LAKERA_API_KEY
  - guardrail_name: "presidio_pii_post"
    litellm_params:
      guardrail: presidio
      mode: post_call
      output_parse_pii: true
 
general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL
  cache: true
  cache_params:
    type: redis
    host: redis.internal

Pattern 2, Vector DB multi-tenant avec ABAC

# Architecture retrieval avec ABAC commun
def secure_retrieve(query: str, user_context: dict) -> list[Chunk]:
    # 1. Filter au niveau VDB (filtre dur)
    candidates = vector_db.query(
        namespace=f"tenant_{user_context['tenant_id']}",
        vector=embed(query),
        filter={
            "tenant_id": user_context['tenant_id'],
            "sensitivity_score": {"$lte": user_context['clearance_score']},
            "$or": [
                {"acl_public": True},
                {"acl_users": {"$in": [user_context['user_id']]}},
                {"acl_groups": {"$in": user_context['groups']}},
            ],
        },
        top_k=20,
    )
    
    # 2. Post-filter via ABAC service (source-of-truth)
    verified = []
    for c in candidates:
        decision = abac_service.check(
            principal=user_context['user_id'],
            action="read",
            resource=c.metadata["doc_id"],
            context={
                "tenant": user_context['tenant_id'],
                "time": datetime.utcnow(),
                "ip": user_context['ip'],
            }
        )
        if decision.allowed:
            verified.append(c)
        else:
            log_event("acl_drift_detected", doc_id=c.metadata["doc_id"], user=user_context['user_id'])
    
    return verified[:5]

Pattern 3, Sandboxing pour code execution agent

# Pour agents qui exécutent du code généré : sandbox kernel-level
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata-fc
handler: kata-fc  # Firecracker via Kata
---
apiVersion: v1
kind: Pod
metadata:
  name: code-executor
  namespace: ai-platform
spec:
  runtimeClassName: kata-fc
  securityContext:
    runAsNonRoot: true
    readOnlyRootFilesystem: true
  containers:
    - name: executor
      image: registry.internal/code-executor:audited
      resources:
        limits:
          cpu: "1"
          memory: "512Mi"
      env:
        # Pas de secrets ici, ephemeral via mediator
        - name: REQUEST_ID
          valueFrom:
            fieldRef:
              fieldPath: metadata.annotations['request-id']

Voir sandboxing agent IA.

Pattern 4, Observabilité unifiée

Application LLM (LangChain, LlamaIndex, custom)

        ▼ OTel SDK avec GenAI semantic conventions
┌──────────────────────────┐
│ Langfuse (LLM-spécifique)│ ─── Visualisation LLM-aware
└─────────────┬────────────┘
              │ OTel export

┌──────────────────────────┐
│ OTel Collector central   │
└─────────────┬────────────┘

   ┌──────────┴──────────┐
   │                     │
   ▼                     ▼
┌──────────┐       ┌──────────┐
│ SIEM     │       │ APM      │
│ Splunk/  │       │ Datadog/ │
│ Sentinel │       │ Grafana  │
└──────────┘       └──────────┘

Pas deux outils séparés (un pour LLM, un pour reste), une stack unifiée OTel.

Gestion structurelle du shadow AI

L'erreur classique : interdire ChatGPT/Claude/Copilot par politique. Résultat observé : employés contournent (téléphones perso, comptes individuels), risques croissent.

Approche architecturale recommandée

Principe : rendre la plateforme interne plus attractive que le shadow AI.

                  ┌──────────────────────────┐
                  │  Plateforme IA interne    │
                  │  - UX comparable          │
                  │  - Performance comparable │
                  │  - Conformité gérée       │
                  │  - Logging transparent    │
                  │  - Cost tracking          │
                  │  - Multi-modèles          │
                  └──────────┬───────────────┘

                ┌────────────┼────────────┐
                │            │            │
        Employés ─────► Plateforme  ◄──── DPO/RSSI
        utilisateurs    (gouvernance     (visibilité)
                         intégrée)

                             │ logs

                  ┌──────────────────────────┐
                  │ Observabilité + SIEM      │
                  │ + Alertes shadow AI       │
                  │ détecté hors plateforme   │
                  └──────────────────────────┘

Mesures complémentaires

  1. Découverte continue : audit logs proxy/CASB/DLP pour détecter shadow AI résiduel.
  2. Politique d'usage IA : périmètre autorisé externe (ex : ChatGPT individuel pour brainstorming non-sensible avec garde-fous), interdit (PII clients dans prompts).
  3. Formation employés : conscientisation aux risques (PII dans prompts, training data des fournisseurs, etc.).
  4. Self-service interne : permettre aux équipes de créer rapidement de nouveaux usages sur la plateforme (low-friction).

Résilience et plan de continuité

L'IA dans le SI introduit de nouveaux modes de défaillance :

  • Panne API LLM (OpenAI down).
  • Changement pricing brutal.
  • Déprécation modèle.
  • Incident sécurité fournisseur.
  • Embargo géopolitique.

Stratégies de résilience

# Pattern : dégradation gracieuse
class ResilientLLMService:
    def __init__(self):
        self.primary = OpenAIClient()
        self.fallback = AnthropicClient()
        self.cache = RedisCache(ttl=3600)
        self.circuit_breaker = CircuitBreaker(failure_threshold=5)
    
    async def query(self, prompt: str) -> str:
        # 1. Cache hit ?
        cached = await self.cache.get(prompt)
        if cached:
            return cached
        
        # 2. Circuit breaker ?
        if self.circuit_breaker.is_open():
            return self.degraded_response(prompt)  # mode FAQ statique, etc.
        
        # 3. Primary
        try:
            response = await self.primary.complete(prompt, timeout=15)
            await self.cache.set(prompt, response)
            return response
        except (TimeoutError, ServiceUnavailable):
            self.circuit_breaker.record_failure()
        
        # 4. Fallback
        try:
            return await self.fallback.complete(prompt, timeout=15)
        except Exception:
            return self.degraded_response(prompt)
    
    def degraded_response(self, prompt: str) -> str:
        # Mode dégradé : recherche FAQ statique, suggestion contact humain
        return search_faq(prompt) or "Service temporairement indisponible. Contactez le support."

Plan de continuité IA, éléments

  • Multi-provider activé par défaut (pas configuration manuelle d'urgence).
  • Self-hosted secours pour cas critiques (Llama/Mistral en interne pour fallback ultime).
  • Cache intelligent : réponses fréquentes en cache pour absorber pannes courtes.
  • Mode dégradé documenté par cas d'usage.
  • Runbooks : panne fournisseur, déprécation modèle, incident sécurité fournisseur.
  • Audit semestriel des dépendances IA (lock-in vendor, alternatives possibles).

Architecture data + IA, convergence

Pas deux architectures séparées, extension cohérente d'une architecture data unique.

Couche data classiqueExtension IA
Data lake (S3, ADLS, GCS)Source pour ETL → vector DB
Data warehouse (Snowflake, BigQuery)Source pour RAG corpus
ETL/ELT (dbt, Airflow)Étendu avec embedding generation
Catalogue (DataHub, Alation)Extended avec metadata IA (modèles, datasets)
LineageÉtendu aux pipelines IA
Data governanceClassification + ACL applicables aux chunks RAG
Observabilité (OTel)Étendu OTel GenAI semantic conventions
# Pipeline ETL classique étendu IA
@dag(schedule_interval="@daily")
def rag_corpus_pipeline():
    # ETL classique
    raw_documents = extract_from_warehouse(...)
    cleaned = transform_documents(raw_documents)
    
    # Extension IA : sanitization + embedding
    sanitized = sanitize_for_llm(cleaned)  # strip control chars, instruction markers
    chunks = chunk_documents(sanitized)
    embeddings = generate_embeddings(chunks, model="text-embedding-3-large")
    
    # Indexation vector DB avec metadata complète
    upsert_to_vector_db(
        chunks_with_embeddings=embeddings,
        metadata={
            "source_doc_id": ...,
            "tenant_id": ...,
            "sensitivity_score": ...,
            "acl_users": ...,
            "acl_groups": ...,
            "ingested_at": datetime.utcnow(),
            "lineage_id": ...,  # lien vers data lineage
        },
    )
    
    # Logs vers même OTel collector
    record_otel_event("rag_pipeline_completed", chunks=len(embeddings))

Plan d'évolution architecturale 18 mois

Mois 1-3, Fondations + inventaire

  • Audit IA actuel (officiel + shadow).
  • Définition reference architecture cible.
  • Choix des composants (open source vs commercial).
  • Sponsoring et budget.

Mois 3-6, POC plateforme centrale

  • Déploiement AI Gateway (LiteLLM) avec 1-2 modèles.
  • Vector DB partagée avec multi-tenancy.
  • Observabilité Langfuse + OTel.
  • Premier projet pilote sur la plateforme.

Mois 6-12, Migration progressive

  • Migration projets existants vers plateforme (1 projet/mois).
  • Décommissionnement silos individuels.
  • Politique d'usage IA déployée.
  • Formation employés.

Mois 12-18, Maturité et industrialisation

  • 100% des nouveaux projets sur plateforme.
  • Self-service pour équipes (création projets en autonomie).
  • ABAC complet via OpenFGA.
  • GitOps complet pour configurations IA.
  • Audit annuel architecture + amélioration.

Compétences clés architecte IA

CompétencePourquoi
Architecture distribuée classiqueBase, la majorité des patterns sont les mêmes
OWASP LLM/Agentic Top 10 + MITRE ATLASThreat model IA
Frameworks IA principaux (LangChain, LlamaIndex, agents)Composants à intégrer
Vector DB (Pinecone, Weaviate, etc.)Composant central des RAG
OpenTelemetry GenAIObservabilité standard
Cloud (AWS/Azure/GCP) avec services IABedrock, Azure OpenAI, Vertex
Souveraineté + SecNumCloudPour OIV/OSE/données sensibles
GitOps + IaCIndustrialisation
Économie LLMCost optimization, multi-provider
Conformité (NIST/ISO/EU AI Act)Décisions architecturales

70% est de l'architecture distribuée classique. 30% est IA-spécifique. Pour un architecte senior : montée en compétence en 6-12 mois avec exposition pratique.

Erreurs fréquentes architecte sur l'IA

ErreurSymptômeFix
Architecture monolithique IAPas de séparation gateway/inference/observability6 étages distincts
Vendor lock-in dès le départCouplage fort à 1 fournisseurAI Gateway abstraction multi-providers
Pas de plateforme centraleSilos par projet, duplicationPlateforme dès 3-5 cas d'usage
Shadow AI traité par interdictionContournements employésPlateforme attractive + politique + formation
Architecture data ignoréeVector DB sans lineage dataConvergence data + IA
Pas de plan de résilienceCascade fail sur incident fournisseurMulti-provider + fallback + circuit breaker
Big bang migrationProjets bloquésMigration progressive 12-18 mois
Compétences IA pas développéesDécisions architecturales naïvesFormation 6-12 mois

Pour aller plus loin

Points clés à retenir

  • Architecte SI 2026 sur l'IA : absorber les usages, fournisseurs et évolutions sans réécriture massive. 70% = architecture distribuée classique appliquée, 30% = spécificités IA.
  • 4 décisions structurantes : plateforme centrale vs silos, multi-cloud / multi-provider, cloud public vs souverain, self-hosted vs API externe.
  • Architecture de référence en 6 étages : AI Gateway → LLM providers → Vector DB → ABAC → Observabilité → GitOps.
  • Plateforme IA centrale obligatoire dès 3-5 cas d'usage. Migration progressive 12-18 mois recommandée.
  • Shadow AI géré par offre (plateforme attractive), pas par interdiction. Politique + formation + alternative interne.
  • Stack open source : LiteLLM + Qdrant/Weaviate + vLLM + OpenFGA + Langfuse + ArgoCD + Vault. Suffisant pour la majorité.
  • Convergence data + IA : pas deux architectures séparées. Vector DB comme extension du data warehouse.
  • Résilience IA : multi-provider + cache + fallback + circuit breaker + dégradation gracieuse + self-hosted secours pour critique.
  • 8 erreurs fréquentes : architecture monolithique, vendor lock-in, pas de plateforme centrale, shadow AI par interdiction, architecture data ignorée, pas de plan résilience, big bang migration, compétences pas développées.

L'architecture IA en 2026 n'est pas une nouvelle discipline, c'est une extension cohérente de l'architecture distribuée classique, avec quelques composants nouveaux (vector DB, AI Gateway, observabilité GenAI). Le rôle d'architecte SI s'enrichit : 6-12 mois de montée en compétence pour intégrer correctement, sans remettre en cause les fondamentaux.

Questions fréquentes

  • Faut-il une plateforme IA centrale dans tous les cas ?
    Non, mais c'est l'architecture cible **dès qu'on dépasse 3-5 cas d'usage IA distincts** ou 100+ employés utilisateurs. Avant : silos par projet acceptables (chaque équipe gère). À partir de 3-5 usages : duplication de l'effort sécurité, perte d'observabilité, gouvernance fragmentée. Plateforme centrale = AI Gateway (LiteLLM, Portkey) + observabilité partagée (Langfuse) + ABAC commun (OpenFGA) + composants sécurité unifiés. Bénéfices : économie d'échelle, cohérence sécurité, simplification audit, compétences mutualisées. Coût : 0,5-1 ETP architecte + 50-200k€ infra/an selon échelle.
  • Comment structurer une plateforme IA centrale en 2026 ?
    Architecture de référence en 6 étages. (1) **AI Gateway** (LiteLLM, Portkey, Cloudflare AI Gateway) : auth, rate limit, routage multi-modèles, observabilité unifiée. (2) **Vector DB partagée** (Pinecone, Weaviate, Qdrant) avec multi-tenancy native + ABAC. (3) **Inference servers managés** (vLLM, TGI, Ollama) ou cloud (Bedrock, Azure OpenAI). (4) **Observabilité centralisée** (Langfuse + OTel + SIEM). (5) **Sécurité commune** (LLM Guard, Presidio, canary tokens, output filters). (6) **GitOps configurations** (ArgoCD/Flux pour prompts, ABAC, AI BOM). Adopter progressivement, pas en big bang.
  • Comment intégrer le shadow AI dans une architecture cible ?
    Pas par interdiction, par offre alternative. Quatre actions. (1) **Découvrir** : audit proxy/CASB/DLP pour inventaire shadow AI réel. (2) **Comprendre** : pourquoi les employés utilisent les outils SaaS publics (souvent : manque alternative interne, simplicité, vitesse). (3) **Offrir** : plateforme IA interne avec UX comparable + conformité gérée + cost tracking. (4) **Politique d'usage** : périmètre autorisé externe (ex : ChatGPT individuel pour tâches non sensibles avec garde-fous), interdit (PII clients), formation employés. Architecture cible : la plateforme interne **rend le shadow AI inutile** par sa qualité d'offre.
  • Quels patterns d'architecture pour absorber multiple LLM providers ?
    Pattern AI Gateway central avec routage multi-modèles. **LiteLLM** (open source) : abstraction de l'API OpenAI vers tous fournisseurs (Anthropic, Google, Cohere, Mistral, AWS Bedrock, etc.). **Portkey** : commercial avec features avancées (caching, fallback, circuit breaker). Architecture : services applicatifs → Gateway (OpenAI-compatible API) → routage selon politique (modèle X par défaut, fallback Y, cost optimization Z). Bénéfices : pas de couplage à un fournisseur, switch facilité, observabilité unifiée, conformité gérée centralement.
  • Comment garantir la résilience d'un SI dépendant de fournisseurs IA externes ?
    Cinq mesures cumulatives. (1) **Multi-provider** par défaut : LLM principal + secondaire (ex : GPT-4 + Claude en fallback). (2) **Circuit breaker + dégradation gracieuse** : si LLM indisponible, mode dégradé (recherche classique, FAQ statique). (3) **Caching** : réponses fréquentes mises en cache (TTL court). (4) **Self-hosted en complément** : modèles open-weights (Llama, Mistral) déployés en interne pour use-cases critiques. (5) **Plan de continuité** : runbooks pour incidents fournisseur (panne API LLM, changement de pricing, déprécation modèle). Pour OIV/OSE : self-hosted SecNumCloud minimum pour systèmes vitaux.
  • Comment articuler architecture IA et architecture data classique ?
    Convergence progressive. **Architecture data classique** (data lake, warehouse, mesh) reste la base, ce sont les sources des RAG. **Architecture IA** ajoute : vector DB pour embeddings, gateway LLM, observabilité spécifique, infrastructure GPU. Patterns d'intégration : (1) Vector DB sourcée depuis data warehouse (Snowflake, Databricks, BigQuery). (2) ETL classique enrichi avec embedding generation. (3) Data governance étendue : classification + ACL + lineage applicables aux chunks RAG. (4) Observabilité unifiée : OTel pour data + IA. Pas deux architectures séparées, extension cohérente d'une architecture data unique.

Écrit par

Naim Aouaichia

Cyber Security Engineer et fondateur de Zeroday Cyber Academy

Ingénieur cybersécurité avec un parcours hybride : développement, DevOps Capgemini, DevSecOps IN Groupe (sécurité des documents d'identité régaliens), audits CAC 40. Fondateur de Hash24Security et Zeroday Cyber Academy. Présence LinkedIn 43 000 abonnés, Substack Zeroday Notes 23 000 abonnés.