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 :
-
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.
-
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.
-
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ère | Silos par projet | Plateforme centrale |
|---|---|---|
| Setup initial | Rapide (chaque équipe) | Lourd (3-6 mois) |
| Time-to-market par projet | Rapide à court terme | Plus lent au début, accéléré ensuite |
| Cohérence sécurité | Variable | Élevée |
| Observabilité | Fragmentée | Unifiée |
| Coût opérationnel | Multiplicatif (×N projets) | Économies d'échelle |
| Gestion shadow AI | Difficile | Facilitée (offre alternative) |
| Conformité | Distribuée | Centralisé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ées | Recommandation |
|---|---|
| Publiques / non-sensibles | Cloud public hyperscaler (AWS, Azure, GCP) |
| Internes entreprise | Cloud 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ère | API externe (OpenAI, Anthropic, etc.) | Self-hosted (Llama, Mistral) |
|---|---|---|
| Time-to-market | Rapide | Lent (6+ mois) |
| Qualité modèle | SOTA continu | Inférieur (modèles open-weights) |
| Coût | Variable selon usage | Fixe (infra GPU) |
| Souveraineté | Dépend fournisseur | Totale |
| Compétences requises | Modérées | MLOps + GPU ops avancées |
| Mises à jour | Automatiques | Manuelles |
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
| Étage | Open source recommandé | Commercial |
|---|---|---|
| AI Gateway | LiteLLM | Portkey, Cloudflare AI Gateway, Kong AI Gateway |
| Vector DB | Qdrant, Chroma, pgvector | Pinecone, Weaviate Cloud |
| Inference server | vLLM, TGI, Ollama | NVIDIA Triton, AWS Bedrock |
| ABAC | OpenFGA, OPA | AWS Cedar, Permit.io, Auth0 FGA |
| Observabilité LLM | Langfuse, Phoenix Arize | LangSmith, Helicone |
| SIEM | Elastic, OpenSearch | Splunk, Sentinel, Chronicle |
| GitOps | ArgoCD, Flux | (déjà open source matures) |
| Secrets | Vault, External Secrets Operator | AWS Secrets Manager, Azure Key Vault |
| Threat intel | OpenCTI | Recorded 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.internalPattern 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
- Découverte continue : audit logs proxy/CASB/DLP pour détecter shadow AI résiduel.
- Politique d'usage IA : périmètre autorisé externe (ex : ChatGPT individuel pour brainstorming non-sensible avec garde-fous), interdit (PII clients dans prompts).
- Formation employés : conscientisation aux risques (PII dans prompts, training data des fournisseurs, etc.).
- 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 classique | Extension 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 governance | Classification + 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étence | Pourquoi |
|---|---|
| Architecture distribuée classique | Base, la majorité des patterns sont les mêmes |
| OWASP LLM/Agentic Top 10 + MITRE ATLAS | Threat model IA |
| Frameworks IA principaux (LangChain, LlamaIndex, agents) | Composants à intégrer |
| Vector DB (Pinecone, Weaviate, etc.) | Composant central des RAG |
| OpenTelemetry GenAI | Observabilité standard |
| Cloud (AWS/Azure/GCP) avec services IA | Bedrock, Azure OpenAI, Vertex |
| Souveraineté + SecNumCloud | Pour OIV/OSE/données sensibles |
| GitOps + IaC | Industrialisation |
| Économie LLM | Cost 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
| Erreur | Symptôme | Fix |
|---|---|---|
| Architecture monolithique IA | Pas de séparation gateway/inference/observability | 6 étages distincts |
| Vendor lock-in dès le départ | Couplage fort à 1 fournisseur | AI Gateway abstraction multi-providers |
| Pas de plateforme centrale | Silos par projet, duplication | Plateforme dès 3-5 cas d'usage |
| Shadow AI traité par interdiction | Contournements employés | Plateforme attractive + politique + formation |
| Architecture data ignorée | Vector DB sans lineage data | Convergence data + IA |
| Pas de plan de résilience | Cascade fail sur incident fournisseur | Multi-provider + fallback + circuit breaker |
| Big bang migration | Projets bloqués | Migration progressive 12-18 mois |
| Compétences IA pas développées | Décisions architecturales naïves | Formation 6-12 mois |
Pour aller plus loin
- Architecture RAG sécurisée, détail RAG.
- Stratégie de défense en profondeur, vue stratégique sécurité.
- Google SAIF, framework architectural.
- NIST AI RMF guide, gouvernance.
- Sécurité IA pour RSSI, vue RSSI complémentaire.
- Sandboxing agent IA, confinement code execution.
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.







