Questions d’entretien architecte cloud : architecture, migration, sécurité

Introduction

Un entretien d’architecte cloud évalue souvent votre façon d’arbitrer : fiabilité contre coût, services managés contre portabilité, standards centraux contre autonomie des équipes, contrôles de sécurité contre vitesse de livraison. Une bonne réponse précise l’objectif métier, les contraintes, l’architecture cible, les risques et le modèle d’exploitation après la mise en production.

Utilisez ce guide pour vous entraîner aux questions les plus probables sur le multi-cloud, la migration, les microservices, le service mesh, la reprise après sinistre, le zero trust et l’optimisation des coûts.

Stratégie Multi-Cloud

1. Comment concevez-vous une stratégie multi-cloud ?

Réponse : Le multi-cloud exploite plusieurs fournisseurs de cloud pour la résilience, l'optimisation des coûts et pour éviter le verrouillage fournisseur.

Considérations clés :

Modèles d'Architecture :

1. Actif-Actif :

• Les charges de travail s'exécutent simultanément sur plusieurs clouds
• Équilibrage de charge entre les fournisseurs
• Disponibilité maximale

2. Actif-Passif :

• Cloud primaire pour la production
• Secondaire pour la reprise après sinistre
• Rentable

3. Services Indépendants du Cloud :

• Utiliser Kubernetes pour la portabilité
• Terraform pour IaC sur plusieurs clouds
• Pipelines CI/CD standardisés

Défis :

• Complexité de la gestion
• Coûts de transfert de données
• Exigences en matière de compétences
• Politiques de sécurité cohérentes

Rareté : Courant Difficulté : Difficile

2. Comment planifiez-vous et exécutez-vous une migration vers le cloud ?

Réponse : La migration vers le cloud nécessite une planification minutieuse, une évaluation des risques et une exécution progressive.

Les 7 R de la Migration :

Stratégies de Migration :

1. Réhéberger (Lift and Shift) :

• Déplacer l’application avec un minimum de changements
• Utile pour sortir rapidement d’un data center
• Nécessite souvent une optimisation après migration

2. Relocate :

• Déplacer une plateforme ou une charge virtualisée sans changer l’application
• Utile si le cloud cible propose un chemin de relocalisation compatible
• Valider réseau, identité, sauvegarde et licences

3. Replatformer :

• Apporter des changements limités, comme passer à une base de données managée ou à une plateforme de conteneurs
• Équilibre vitesse de migration et amélioration opérationnelle

4. Refactoriser/Réarchitecturer :

• Reconcevoir pour le scaling cloud-native, la résilience ou la vitesse de livraison
• Effort le plus élevé, à réserver aux systèmes à forte valeur

5. Racheter :

• Remplacer l’application par du SaaS
• Exemple : remplacer un CRM sur mesure par une plateforme CRM managée

6. Retirer :

• Décommissionner les applications qui n’apportent plus de valeur métier

7. Retenir :

• Garder un système en place pour des raisons de conformité, latence, coût ou séquencement

Phases de Migration :

# Outil d'évaluation de la migration
class MigrationAssessment:
    def __init__(self, application):
        self.app = application
        self.score = 0
    
    def assess_cloud_readiness(self):
        factors = {
            'architecture': self.check_architecture(),
            'dependencies': self.check_dependencies(),
            'data_volume': self.check_data_volume(),
            'compliance': self.check_compliance(),
            'performance': self.check_performance_requirements()
        }
        
        # Calculer la complexité de la migration
        complexity = sum(factors.values()) / len(factors)
        
        if complexity < 3:
            return "Réhéberger - Faible complexité"
        elif complexity < 6:
            return "Replatformer - Complexité moyenne"
        else:
            return "Refactoriser - Haute complexité"
    
    def generate_migration_plan(self):
        return {
            'phase_1': 'Évaluation et planification',
            'phase_2': 'Preuve de concept',
            'phase_3': 'Migration des données',
            'phase_4': 'Migration des applications',
            'phase_5': 'Tests et validation',
            'phase_6': 'Basculement et mise en production',
            'phase_7': 'Optimisation'
        }

Exécution de la Migration :

1. Évaluation :

• Inventaire des applications et des dépendances
• Analyser les coûts (TCO)
• Identifier les risques et les contraintes

2. Planification :

• Choisir une stratégie de migration par application
• Définir les critères de succès
• Créer des plans de restauration

3. Migration Pilote :

• Commencer avec une application non critique
• Valider l'approche
• Affiner les processus

4. Migration des Données :

# Exemple : Migration de base de données avec AWS DMS
aws dms create-replication-instance \
    --replication-instance-identifier migration-instance \
    --replication-instance-class dms.t2.medium

# Créer une tâche de migration
aws dms create-replication-task \
    --replication-task-identifier db-migration \
    --source-endpoint-arn arn:aws:dms:region:account:endpoint/source \
    --target-endpoint-arn arn:aws:dms:region:account:endpoint/target \
    --migration-type full-load-and-cdc

5. Stratégie de Basculement :

• Big Bang : Tout d'un coup (risqué)
• Progressive : Migration graduelle (plus sûr)
• Exécution Parallèle : Exécuter les deux environnements

Atténuation des Risques :

• Tests complets
• Procédures de restauration automatisées
• Lignes de base de performance
• Validation de la sécurité
• Surveillance des coûts

Rareté : Très Courant Difficulté : Moyen-Difficile

Architecture Microservices

3. Comment concevez-vous une architecture de microservices ?

Réponse : Les microservices décomposent les applications en petits services indépendants.

Architecture :

Principes Clés :

1. Indépendance des Services :

• Chaque service possède ses données
• Déploiement indépendant
• Diversité technologique autorisée

2. Communication :

# Synchrone (API REST)
import requests

def get_user(user_id):
    response = requests.get(f'http://user-service/api/users/{user_id}')
    return response.json()

# Asynchrone (File d'Attente de Messages)
import pika

def publish_order_event(order_data):
    connection = pika.BlockingConnection(pika.ConnectionParameters('rabbitmq'))
    channel = connection.channel()
    channel.queue_declare(queue='orders')
    channel.basic_publish(
        exchange='',
        routing_key='orders',
        body=json.dumps(order_data)
    )
    connection.close()

3. Passerelle API :

• Point d'entrée unique
• Authentification/autorisation
• Limitation du débit
• Routage des requêtes

4. Découverte de Services :

• Enregistrement dynamique des services
• Contrôles de santé
• Équilibrage de charge

Avantages :

• Mise à l'échelle indépendante
• Flexibilité technologique
• Isolation des pannes
• Déploiement plus rapide

Défis :

• Complexité du système distribué
• Cohérence des données
• Complexité des tests
• Surcharge opérationnelle

Rareté : Très Courant Difficulté : Difficile

4. Comment implémentez-vous un maillage de services (service mesh) dans les microservices ?

Réponse : Un maillage de services fournit une couche d'infrastructure pour la communication de service à service, gérant la gestion du trafic, la sécurité et l'observabilité.

Architecture :

Fonctionnalités Clés :

1. Gestion du Trafic :

• Équilibrage de charge
• Disjoncteur (Circuit breaking)
• Nouvelles tentatives et délais d'attente
• Déploiements Canary
• Tests A/B

2. Sécurité :

• Chiffrement mTLS
• Authentification
• Politiques d'autorisation

3. Observabilité :

• Traçage distribué
• Collecte de métriques
• Journalisation des accès

Implémentation Istio :

# Service Virtuel pour le routage du trafic
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        user-type:
          exact: premium
    route:
    - destination:
        host: reviews
        subset: v2
      weight: 100
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10

---
# Règle de Destination pour l'équilibrage de charge
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-destination
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        maxRequestsPerConnection: 2
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Configuration du Disjoncteur :

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: circuit-breaker
spec:
  host: payment-service
  trafficPolicy:
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50

Sécurité mTLS :

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-read
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/frontend"]
    to:
    - operation:
        methods: ["GET"]

Observabilité avec Kiali :

# Installer Istio avec les addons d'observabilité
istioctl install --set profile=demo

# Déployer Kiali, Prometheus, Grafana, Jaeger
kubectl apply -f samples/addons/

# Accéder au tableau de bord Kiali
istioctl dashboard kiali

Comparaison des Maillages de Services :

Quand Utiliser :

• Environnements de microservices où des politiques communes de trafic, identité et observabilité justifient la charge opérationnelle
• Besoin d'une gestion avancée du trafic
• Exigences de sécurité (mTLS)
• Déploiements multi-clusters
• Exigences d'observabilité

Rareté : Courant Difficulté : Difficile

Modèles de Conception

5. Expliquez le modèle de Disjoncteur (Circuit Breaker) et quand l'utiliser.

Réponse : Le Disjoncteur empêche les défaillances en cascade dans les systèmes distribués.

États :

1. Fermé : Fonctionnement normal
2. Ouvert : Défaillances détectées, les requêtes échouent rapidement
3. Semi-Ouvert : Test si le service a récupéré

from enum import Enum
import time

class CircuitState(Enum):
    CLOSED = "fermé"
    OPEN = "ouvert"
    HALF_OPEN = "semi_ouvert"

class CircuitBreaker:
    def __init__(self, failure_threshold=5, timeout=60, success_threshold=2):
        self.failure_threshold = failure_threshold
        self.timeout = timeout
        self.success_threshold = success_threshold
        self.failures = 0
        self.successes = 0
        self.last_failure_time = None
        self.state = CircuitState.CLOSED
    
    def call(self, func, *args, **kwargs):
        if self.state == CircuitState.OPEN:
            if time.time() - self.last_failure_time > self.timeout:
                self.state = CircuitState.HALF_OPEN
                self.successes = 0
            else:
                raise Exception("Le disjoncteur est OUVERT")
        
        try:
            result = func(*args, **kwargs)
            self.on_success()
            return result
        except Exception as e:
            self.on_failure()
            raise e
    
    def on_success(self):
        self.failures = 0
        if self.state == CircuitState.HALF_OPEN:
            self.successes += 1
            if self.successes >= self.success_threshold:
                self.state = CircuitState.CLOSED
    
    def on_failure(self):
        self.failures += 1
        self.last_failure_time = time.time()
        if self.failures >= self.failure_threshold:
            self.state = CircuitState.OPEN

# Utilisation
breaker = CircuitBreaker()
result = breaker.call(external_api_call, user_id=123)

Cas d'Utilisation :

• Appels d'API externes
• Connexions à la base de données
• Communication de microservices
• Intégrations tierces

Rareté : Courant Difficulté : Moyen-Difficile

Architecture Événementielle

6. Expliquez l'architecture événementielle et quand l'utiliser.

Réponse : L'Architecture Événementielle (EDA) utilise des événements pour déclencher et communiquer entre des services découplés.

Architecture :

Concepts Clés :

1. Événement :

• Fait immuable qui s'est produit
• Contient des données pertinentes
• Horodaté

2. Producteur d'Événements :

• Publie des événements
• Ne connaît pas les consommateurs

3. Consommateur d'Événements :

• S'abonne aux événements
• Traite de manière asynchrone

4. Bus/Courtier d'Événements :

• Route les événements
• Exemples : Kafka, RabbitMQ, AWS EventBridge

Implémentation Kafka :

from kafka import KafkaProducer, KafkaConsumer
import json
from datetime import datetime

# Producteur d'Événements
class OrderEventProducer:
    def __init__(self):
        self.producer = KafkaProducer(
            bootstrap_servers=['localhost:9092'],
            value_serializer=lambda v: json.dumps(v).encode('utf-8')
        )
    
    def publish_order_created(self, order_id, customer_id, items, total):
        event = {
            'event_type': 'OrderCreated',
            'event_id': str(uuid.uuid4()),
            'timestamp': datetime.utcnow().isoformat(),
            'data': {
                'order_id': order_id,
                'customer_id': customer_id,
                'items': items,
                'total': total
            }
        }
        self.producer.send('order-events', value=event)
        self.producer.flush()

# Consommateur d'Événements
class InventoryEventConsumer:
    def __init__(self):
        self.consumer = KafkaConsumer(
            'order-events',
            bootstrap_servers=['localhost:9092'],
            value_deserializer=lambda m: json.loads(m.decode('utf-8')),
            group_id='inventory-service'
        )
    
    def process_events(self):
        for message in self.consumer:
            event = message.value
            if event['event_type'] == 'OrderCreated':
                self.reserve_inventory(event['data'])
    
    def reserve_inventory(self, order_data):
        # Logique de réservation d'inventaire
        print(f"Réservation de l'inventaire pour la commande {order_data['order_id']}")
        # Publier l'événement InventoryReserved

Modèle d'Approvisionnement d'Événements (Event Sourcing) :

# Stocker les événements au lieu de l'état actuel
class EventStore:
    def __init__(self):
        self.events = []
    
    def append(self, event):
        self.events.append(event)
    
    def get_events(self, aggregate_id):
        return [e for e in self.events if e['aggregate_id'] == aggregate_id]

# Reconstruire l'état à partir des événements
class OrderAggregate:
    def __init__(self, order_id):
        self.order_id = order_id
        self.status = 'pending'
        self.items = []
        self.total = 0
    
    def apply_event(self, event):
        if event['type'] == 'OrderCreated':
            self.items = event['data']['items']
            self.total = event['data']['total']
        elif event['type'] == 'OrderPaid':
            self.status = 'paid'
        elif event['type'] == 'OrderShipped':
            self.status = 'shipped'
    
    def rebuild_from_events(self, events):
        for event in events:
            self.apply_event(event)

CQRS (Command Query Responsibility Segregation) :

Avantages :

• Couplage faible
• Évolutivité
• Flexibilité
• Piste d'audit (approvisionnement d'événements)
• Traitement en temps réel

Défis :

• Cohérence éventuelle
• Évolution du schéma d'événement
• Complexité du débogage
• Gestion des événements en double

Cas d'Utilisation :

• Traitement des commandes de commerce électronique
• Analyse en temps réel
• Traitement des données IoT
• Communication de microservices
• Systèmes d'audit et de conformité

Rareté : Courant Difficulté : Difficile

Reprise Après Sinistre

7. Comment concevez-vous une stratégie de reprise après sinistre ?

Réponse : La reprise après sinistre (DR) assure la continuité des activités pendant les pannes.

Mesures Clés :

• RTO (Recovery Time Objective) : Durée d'indisponibilité maximale acceptable
• RPO (Recovery Point Objective) : Perte de données maximale acceptable

Stratégies de DR :

Exemple d'Implémentation :

Automatisation :

# Script de basculement automatisé
def initiate_failover():
    # 1. Arrêter les écritures sur le primaire
    stop_primary_writes()
    
    # 2. Promouvoir la base de données secondaire
    promote_secondary_to_primary()
    
    # 3. Mettre à jour le DNS
    update_route53_failover()
    
    # 4. Démarrer les services de la région de DR
    start_dr_services()
    
    # 5. Vérifier la santé
    verify_dr_health()
    
    # 6. Notifier l'équipe
    send_alert("Basculement terminé vers la région de DR")

Tests :

• Exercices de DR réguliers selon la criticité de la charge
• Tests automatisés
• Documenter les manuels d'exécution
• Revues post-incident

Rareté : Très Courant Difficulté : Difficile

Sécurité & Conformité

8. Comment implémentez-vous la sécurité zéro confiance dans l'architecture cloud ?

Réponse : La Zéro Confiance suppose qu'il n'y a pas de confiance implicite, vérifiez tout.

Principes :

1. Vérifier explicitement
2. Accès au moindre privilège
3. Supposer une violation

Implémentation :

Composants :

1. Identité & Accès :

# Exemple : Politique d'accès conditionnel
policies:
  - name: "Exiger MFA pour les applications sensibles"
    conditions:
      applications: ["finance-app", "hr-system"]
      users: ["all"]
    controls:
      - require_mfa: true
      - require_compliant_device: true
      - allowed_locations: ["corporate-network", "vpn"]

2. Segmentation du Réseau :

• Micro-segmentation
• Maillage de services (Istio, Linkerd)
• Politiques de réseau

3. Chiffrement :

• Données au repos
• Données en transit
• Chiffrement de bout en bout

4. Surveillance Continue :

• Détection des menaces en temps réel
• Analyse comportementale
• Réponse automatisée

Rareté : Courant Difficulté : Difficile

Optimisation des Coûts

9. Comment optimisez-vous les coûts sur plusieurs fournisseurs de cloud ?

Réponse : Stratégies d'optimisation des coûts multi-cloud :

1. Placement des Charges de Travail :

• Analyser les modèles de tarification
• Tenir compte des coûts de transfert de données
• Tirer parti des différences de prix régionales

2. Capacité Réservée :

• Instances Réservées AWS
• Instances de VM Réservées Azure
• Remises pour Utilisation Engagée GCP

3. Instances Spot/Préemptibles :

# Comparaison des coûts : renseigner avec les calculateurs cloud actuels
def compare_options(options):
    return sorted(options, key=lambda option: (
        option["monthly_cost"],
        option["operational_risk"],
        option["commitment_months"]
    ))

4. Surveillance & Gouvernance :

• Tableaux de bord de coûts unifiés
• Alertes budgétaires
• Allocation des coûts basée sur les balises
• Nettoyage automatisé des ressources

5. Optimisation de l'Architecture :

• Serverless pour les charges de travail variables
• Politiques de mise à l'échelle automatique
• Hiérarchisation du stockage
• CDN pour le contenu statique

Rareté : Très Courant Difficulté : Moyen-Difficile

Conclusion

Les entretiens d’architecte cloud valorisent surtout la qualité des décisions, plus que les schémas appris par cœur. Préparez-vous à expliquer :

1. Multi-cloud : pourquoi une charge a besoin de plusieurs fournisseurs et quelle complexité cela ajoute
2. Migration : options 7R, cartographie des dépendances, bascule progressive, rollback et optimisation après migration
3. Microservices : limites de services, propriété des données, contrats d’API, résilience et coût opérationnel
4. Service mesh : quand mTLS, politiques de trafic et observabilité justifient une couche de plateforme supplémentaire
5. Modèles de conception : circuit breaker, saga, CQRS, idempotence, retries et timeouts
6. Systèmes événementiels : contrats d’événements, ordre, doublons, évolution de schéma et cohérence éventuelle
7. Reprise après sinistre : RTO/RPO, stratégie régionale, runbooks, tests et preuves de reprise
8. Sécurité : accès fondé sur l’identité, moindre privilège, chiffrement, segmentation, journalisation et logique assume breach
9. Optimisation des coûts : rightsizing, engagements, tagging, nettoyage des ressources inutilisées, transfert de données et gouvernance FinOps

Dans vos réponses, commencez par la contrainte métier, nommez le compromis, puis expliquez comment vous valideriez le design en production.