Cours : Tendances de l'Architecture SI Moderne

Introduction

Ce chapitre explore les tendances émergentes et les paradigmes qui façonnent l'architecture des systèmes d'information en 2026-2030 : architecture événementielle, microservices avancés, serverless, platform engineering, architecture quantique, AI-driven architecture, model-driven development et low-code/no-code.

---

1. Architecture Événementielle (Event-Driven Architecture)

Fondements

L'architecture événementielle repose sur la production, la détection et la réaction à des événements. Contrairement à l'architecture requête-réponse classique, les composants communiquent de façon asynchrone via des événements.

Principes clés :

• Découplage temporel : producteurs et consommateurs ne sont pas synchronisés
• Découplage spatial : ils ne se connaissent pas mutuellement
• Asynchronisme : le traitement n'est pas bloquant

Patterns événementiels

Event Notification :

Producteur → Événement → Bus → Consommateur(s)

Cas d'usage : notification d'un changement d'état (CommandeCrée, PaiementReçu).

Event-Carried State Transfer : L'événement transporte l'état complet de l'objet concerné. Avantage : le consommateur n'a pas besoin de faire une requête au producteur. Inconvénient : duplication de données.

Event Sourcing : Stocke la séquence complète des événements plutôt que l'état courant. L'état est reconstruit par rejeu des événements.

Technologies

Kafka en détail

• Topic : catégorie d'événements
• Partition : division d'un topic (ordre garanti par partition)
• Producer : publie dans un topic
• Consumer : lit depuis un topic
• Broker : serveur Kafka
• ZooKeeper/KRaft : coordination du cluster

Cas d'usage : Event Sourcing pour système de commandes

Topics: 
  - orders (partitionné par orderId)
  - payments
  - shipments
  - notifications

Anti-patterns à éviter

• Event explosion : trop d'événements rendent le système illisible
• Lost events : absence de garantie de livraison
• Tight coupling via event schema : changement d'événement casse les consommateurs
• Sync over event : attendre une réponse synchrone après un événement

---

2. Event Sourcing et CQRS

CQRS (Command Query Responsibility Segregation)

Principe : séparer les modèles d'écriture (Command) et de lecture (Query).

Command :

• Change l'état du système
• Validation des règles métier
• Génère des événements
• Retourne void (pas de données)
• Utilise le modèle du domaine

Query :

• Ne change pas l'état
• Retourne des données
• Peut utiliser un modèle dénormalisé
• Optimisé pour la lecture

Event Sourcing + CQRS

Combinaison puissante :

1. Les Command sont persistées comme événements (Event Sourcing)
2. Les événements alimentent des projections (views de lecture)
3. Les Query lisent les projections, pas le store d'événements

Diagramme en cours de génération...

Avantages :

• Audit complet (tous les événements sont conservés)
• Traçabilité (on sait exactement ce qui s'est passé)
• Debugging (rejeu pour reproduire un état)
• Scalabilité (lecture et écriture optimisées séparément)

Inconvénients :

• Complexité opérationnelle
• Courbe d'apprentissage
• Consistance éventuelle
• Pas adapté à tous les cas (CRUD simple)

---

3. Microservices Avancés

Service Mesh

Couche d'infrastructure dédiée à la communication entre microservices. Le service mesh déplace la logique de communication (retry, timeout, circuit breaker, mTLS, observabilité) du code applicatif vers un proxy sidecar.

Architecture :

Service A ←→ Proxy (sidecar) ←→ Proxy (sidecar) ←→ Service B
                          ↓
                     Control Plane
                  (istiod, linkerd)

Produits :

Fonctionnalités :

• Traffic management : canary, blue/green, mirroring
• Security : mTLS, authentication, authorization
• Observability : metrics, tracing, logs
• Resilience : circuit breaker, retry, timeout

Ambient Mesh (Sidecar-less)

Nouvelle approche (Istio Ambient Mesh) sans sidecar :

• ztunnel : proxy par nœud (layer 4)
• waypoint : proxy par charge de travail (layer 7)
• Avantage : moins de ressources, plus facile à opérer

Microservices Patterns émergents

• Database per Service : chaque service a sa propre base
• API Gateway : point d'entrée unique (Kong, APISIX, Envoy)
• Backend for Frontend : API dédiée par type de client
• Strangler Fig : migration progressive du monolithe
• Saga : transactions distribuées chorégraphiées ou orchestrées

---

4. Serverless

Principes

• FaaS (Function as a Service) : exécution de fonctions à la demande
• Zero scaling : pas de consommation quand pas d'usage
• Pay-per-use : paiement à l'exécution
• Managed infrastructure : pas de gestion de serveurs

AWS Lambda :

exports.handler = async (event) => {
    const order = JSON.parse(event.body);
    await processOrder(order);
    return { statusCode: 200, body: 'OK' };
};

Architectures Serverless

Event-Driven Serverless :

API Gateway → Lambda → SQS → Lambda → DynamoDB → Lambda → SNS

Serverless + Microservices :

• Les services sont des fonctions Lambda
• Communication via SQS, SNS, EventBridge
• Stockage via DynamoDB, S3, RDS Proxy

Limitations

• Cold starts (100-1000ms)
• Timeout (15min max pour Lambda)
• Resource limits (memory, disk)
• Vendor lock-in
• Debugging complexe

Évolution : Serverless Containers

• AWS Fargate, Google Cloud Run, Azure Container Apps
• Combine conteneurs et serverless
• Plus de flexibilité que Lambda

---

5. Platform Engineering

Définition

Discipline visant à construire des Internal Developer Platforms (IDP) qui simplifient l'expérience développeur tout en maintenant la gouvernance d'entreprise.

Objectifs

• Developer Experience : self-service, templates, documentation
• Golden Paths : chemins validés pour déployer, monitorer, scaler
• Governance : security, compliance, cost control
• Abstraction : cacher la complexité du cloud et des outils

Composants d'une IDP

Diagramme en cours de génération...

Backstage (Spotify)

Fonctionnalités :

• Software Catalog : inventaire de tous les services
• Scaffolder : génération de projets à partir de templates
• TechDocs : documentation technique intégrée
• Plugins : extensible (Datadog, PagerDuty, GitHub, etc.)
• Scorecards : évaluation de la maturité des services

Port, Cortex, Humanitec

• Port : Portail développeur (bâtisseur de catalogues)
• Cortex : Service Catalog + Scorecards
• Humanitec : Orchestrateur de plateforme (PaaS interne)
• Kratix : Framework open source de platform engineering

Score (specification)

Standard ouvert pour décrire les workloads :

apiVersion: score.dev/v1b1
metadata:
  name: mon-service
containers:
  mon-api:
    image: registry/ma-image:latest
    variables:
      DB_HOST: "${resources.database.host}"
resources:
  database:
    type: postgresql

---

6. Architecture Quantique

Principes de base

• Qubit : unité d'information quantique (superposition 0 et 1)
• Superposition : un qubit peut être à la fois 0 et 1
• Intrication : deux qubits intriqués sont corrélés quelle que soit la distance
• Portes quantiques : opérations sur les qubits (Hadamard, CNOT, Pauli)

Algorithmes quantiques

• Shor : factorisation (casse RSA)
• Grover : recherche non structurée (accélération quadratique)
• QAOA : optimisation combinatoire
• VQE : simulation moléculaire

Architecture hybride Quantum-Classical

Les ordinateurs quantiques ne remplaceront pas les classiques. L'architecture sera hybride :

Cloud Client → API Gateway → Classical Service
                                    ↓
                          Quantum Orchestrator
                                    ↓
                          Quantum Processor (QPU)

Patterns hybrides :

• Quantum-as-a-Service : API de calcul quantique
• Quantum-Accelerated : certaines parties de l'algo sont quantiques
• Quantum-Classical ML : feature maps et kernel methods quantiques

Cas d'usage potentiels (2026-2030)

• Optimisation : logistique, finance, pharmacie
• Machine Learning : SVM quantique, réseaux de neurones quantiques
• Cryptographie : post-quantum cryptography (PQC)
• Simulation : matériaux, chimie, physique
• IA : quantum annealing pour l'optimisation des modèles

Plateformes disponibles

• IBM Quantum (Qiskit)
• Amazon Braket
• Azure Quantum
• Google Quantum AI (Sycamore, Willow)
• Rigetti Computing

---

7. AI-Driven Architecture

LLMs dans l'architecture

L'IA générative (LLM) impacte le métier d'architecte :

Code Generation :

• Génération de code d'infrastructure (Terraform, Pulumi)
• Génération de documentation d'architecture
• Génération de tests et de mocks

Architecture Design :

• Suggestion de patterns basés sur le contexte
• Analyse de trade-offs
• Détection de violations architecturales
• Génération de diagrammes C4 from text

Monitoring et Observabilité :

• Analyse de logs (anomaly detection)
• Prédiction de pannes
• Recommandations de configuration

Architecture AI-Native

System: Plateforme de développement assisté par IA
Components:
  - LLM Gateway (API management, rate limiting, caching)
  - Vector Database (RAG : embeddings et retrieval)
  - Prompt Registry (versioning des prompts)
  - Feedback Loop (RLHF, évaluation en continu)
  - Guardrails (sécurité, validation, hallucination detection)

Patterns émergents

• RAG (Retrieval-Augmented Generation) : enrichir le LLM avec des documents métier
• Agentic Architecture : agents IA autonomes orchestrés
• Multi-Modal : traitement texte, image, code, diagrammes
• Fine-Tuning : adapter un LLM au vocabulaire et aux règles métier

Risques et défis

• Hallucinations : l'IA invente des réponses
• Sécurité : injection de prompts, fuite de données
• Coût : token processing coûteux
• Qualité : code généré non testé, non sécurisé, non optimisé
• Dette technique : accumulation de code non maîtrisé

---

8. Model-Driven Development (MDD)

Principes

• MDA (Model-Driven Architecture) : standard OMG
• PIM (Platform Independent Model) : modèle métier pur
• PSM (Platform Specific Model) : modèle adapté à une plateforme
• Transformation : PIM → PSM → Code

Niveaux MDD

1. Code-centric : le code est l'artefact principal (pratique actuelle)
2. Model-centric : le modèle génère le code
3. Model-executable : le modèle est exécutable directement

Outils MDD modernes

• EMF (Eclipse Modeling Framework) : méta-modélisation
• ATL : langage de transformation de modèles
• Xtext : création de DSL
• MPS (JetBrains) : language workbench
• Obeo (Sirius) : éditeurs graphiques de modèles

Cas d'usage

• DSL métier : les experts conçoivent des modèles, le code est généré
• Génération de code : backend, frontend, API, tests
• Génération de documentation : diagrammes, spécifications
• Vérification : validation de contraintes sur le modèle

Limites

• Complexité des transformations
• Perte d'expressivité par rapport au code
• Courbe d'apprentissage
• Résistance des développeurs
• Maintenance des générateurs

---

9. Low-Code / No-Code

Définition

• Low-Code : développement visuel avec minimum de code
• No-Code : développement purement visuel (drag & drop)
• Citizen Developer : utilisateur métier qui développe sans coder

Plateformes

Architecture SI avec Low-Code

┌─────────────────┐
│   No-Code UI    │ ← Applications rapides (power users)
├─────────────────┤
│   Low-Code      │ ← Applications métier (Mendix, OutSystems)
├─────────────────┤
│   Custom Dev    │ ← Applications cœur (haute performance)
├─────────────────┤
│   Legacy        │ ← Systèmes existants (ERP, CRM)
└─────────────────┘

Avantages

• Rapidité : développement 10x plus rapide
• Accessibilité : citoyens développeurs
• Coût : moins de développeurs spécialisés
• Agilité : itérations rapides, feedback immédiat

Inconvénients

• Limitations techniques : performances, scalabilité
• Vendor lock-in : dépendance à la plateforme
• Gouvernance : shadow IT, sécurité
• Dette technique : applications non maintenables par des pros
• Personnalisation : quand le No-Code ne suffit plus

Position de l'architecte

L'architecte doit :

1. Définir ce qui peut être low-code et ce qui doit être custom
2. Mettre en place une gouvernance des plateformes low-code
3. Standardiser les intégrations (APIs, events)
4. Former les citizen developers
5. Auditer la qualité des applications produites

---

10. Prospective : Le métier d'architecte en 2030

Évolutions prévisibles

1. Architecte augmenté par l'IA

• L'IA générative assiste la conception d'architecture
• L'architecte se concentre sur la stratégie et les décisions complexes
• Les tâches répétitives (génération, documentation) sont automatisées

2. Architecture autonome

• Les systèmes s'auto-configurent, s'auto-réparent, s'auto-optimisent
• Les décisions d'architecture sont prises en partie par des boucles ML
• L'architecte définit les règles, le système les applique dynamiquement

3. Convergence cloud / edge / quantum

• Architecture déployée sur continuum : cloud → edge → devices
• Hybridation quantique-classique
• Orchestration multi-cloud et multi-paradigme

4. Architecture centrée données

• Data Mesh comme nouveau paradigme
• Gouvernance fédérée des données
• Architecture orientée événement comme colonne vertébrale

5. Durabilité et Green IT

• L'impact environnemental devient un critère d'architecture
• Carbon-aware computing
• Architecture efficiente par conception (energy efficiency)

Compétences clés 2030

Conseils pour l'architecte 2026-2030

1. Investir dans les fondamentaux : DDD, C4, ADR, modélisation
2. Se former à l'IA : comprendre comment intégrer l'IA dans l'architecture
3. Développer l'approachabilité : communiquer avec le métier
4. Adopter le platform engineering : penser en termes de plateforme
5. Rester agile : l'architecture doit être évolutive et adaptable
6. Penser green : l'efficacité énergétique est un attribut de qualité
7. Cultiver l'humain : l'architecte est d'abord un leader technique

Conclusion

L'architecture SI n'a jamais été aussi dynamique. Les tendances 2026-2030 ne remplacent pas les fondamentaux (Merise, UML, DDD, C4) mais les enrichissent. L'architecte de demain doit maîtriser à la fois les méthodes classiques et les paradigmes émergents, avec une capacité d'adaptation et une vision stratégique accrues. La clé reste la même : comprendre le domaine métier, modéliser avec rigueur, décider avec méthode, et communiquer avec clarté.