Cours : Simulation d'Entretiens d'Architecture SI

Introduction

Ce chapitre prépare aux entretiens techniques pour les postes d'architecte SI, lead developer et consultant en architecture. Les questions sont classées en 3 catégories : comportementales, techniques et system design.

---

Partie 1 : Questions Comportementales (30)

Collaboration et Leadership

Q1 : Parlez-moi d'un conflit technique que vous avez résolu. Structure STAR :

• Situation : Deux développeurs se disputaient sur le choix entre REST et GraphQL pour une API publique
• Tâche : Arbitrer le débat et prendre une décision d'architecture
• Action : Organisation d'un ADR workshop, analyse des cas d'usage (lectures vs écritures, complexité des requêtes), prototypage des 2 approches
• Résultat : Décision documentée (ADR-0023), consensus sur une approche hybride (REST pour CRUD, GraphQL pour le reporting)

Pièges à éviter :

• Ne pas prendre parti sans analyse
• Ignorer les contraintes techniques
• Décision non documentée

Q2 : Comment convaincre une équipe d'adopter une nouvelle méthode ? Approche recommandée :

1. Show, don't tell : faire un proof of concept convaincant
2. Start small : commencer par un périmètre réduit
3. Address fears : identifier et répondre aux objections
4. Measure impact : montrer les bénéfices chiffrés
5. Celebrate wins : valoriser les premiers succès

Q3 : Décrivez une fois où vous avez mentored un junior.

• Établir un plan de progression
• Pair programming régulier
• Code review constructive (ne pas réécrire, expliquer)
• Débriefing post-mortem pour les incidents
• Donner de l'autonomie progressivement

Q4 : Comment gérez-vous un désaccord sur le choix technique ? Processus :

1. Écouter activement le point de vue opposé
2. Demander des données/prototypes pour étayer
3. Définir des critères objectifs d'évaluation
4. Organiser un atelier ADR
5. Accepter la décision collective si les critères sont respectés

Q5 : Comment alignez-vous plusieurs équipes sur une vision commune ?

• Architecture review board mensuel
• Event Storming inter-équipes trimestriel
• ADR partagés dans un repository central
• Community of practice architecture

Gestion de projet

Q6 : Comment gérez-vous la dette technique ?

• Identifier : outils d'analyse statique, revues de code
• Quantifier : coût estimé de la correction vs coût de l'inaction
• Prioriser : dette stratégique (remboursée) vs dette tactique (tolérée)
• Budgéter : 20% du temps de l'itération dédié à la réduction de dette
• Communiquer : présenter la dette aux parties prenantes en termes métier

Q7 : Décrivez un projet qui a dérivé.

• Symptômes : jalons manqués, scope creep, décisions non documentées
• Causes profondes : absence d'architecte, exigences floues, pas de revue
• Actions correctives : reset du périmètre, ADR sur les choix, architecture runway

Q8 : Comment priorisez-vous les tâches ? Matrice de priorisation :

• Urgent ET important → faire maintenant
• Important mais pas urgent → planifier
• Urgent mais pas important → déléguer
• Ni urgent ni important → ne pas faire

Q9 : Que faites-vous face à une deadline irréaliste ?

1. Analyser : décomposer le travail, identifier le MVP
2. Négocier : présenter les options (scope, temps, qualité, coût)
3. Protéger l'équipe : éviter le crunch systématique
4. Documenter : risques identifiés, décisions prises

Q10 : Comment estimez-vous un projet d'architecture ?

• Estimation par taille relative (story points)
• Reference class forecasting
• Planification par phases (conceptuelle, détaillée, exécution)
• Facteurs d'incertitude : dépendances, technologie, maturité équipe

Prise de décision

Q11-Q15 : Scénarios de décision Voir les réponses aux questions ADR dans la partie technique.

Communication

Q16 : Comment présentez-vous un diagramme à des non-techniciens ?

1. Commencer par le contexte métier (pourquoi, pas comment)
2. Utiliser le niveau 1 C4 (contexte)
3. Éviter le jargon technique
4. Analogies avec le monde réel
5. Une seule idée par slide

Q17 : Comment documentez-vous vos décisions ?

• ADR (Architecture Decision Records)
• Format Y-Statement
• docs/adr/ dans le repository
• Revue trimestrielle des ADRs

Q18 : Décrivez une fois où vous avez simplifié un concept complexe.

• Modélisation avec Event Storming pour expliquer le domaine
• Cartographie C4 pour l'architecture
• Mind maps pour les relations

Q19 : Comment animez-vous un atelier de modélisation ?

• Préparer le matériel (post-its, feutres, mur)
• Définir la question centrale
• Timeboxing strict
• Encourager la participation
• Synthétiser et documenter

Innovation et veille

Q21 : Comment restez-vous à jour technologiquement ?

• Veille quotidienne : Feedly, newsletters (DDD Weekly, Architecture Weekly)
• Veille hebdomadaire : InfoQ, ThoughtWorks Radar
• Veille mensuelle : conférences (replays), meetups
• Personnel : side projects, contributions open source

Résolution de problèmes

Q26 : Décrivez un problème complexe que vous avez résolu. Cas : Problème de performance sur un système de réservation traitant 10 000 requêtes/s Analyse :

• Profiling applicatif (goulot = requête SQL N+1)
• Tracing distribué (latence réseau entre services)
• Cache Redis (réduction 80% du temps de réponse)
• Event sourcing (découplage écriture/lecture) Résultat : Latence passée de 2s à 50ms, coût d'infrastructure réduit de 40%

---

Partie 2 : Questions Techniques (30)

UML et Modélisation

Q1 : Quels diagrammes UML utilisez-vous et quand ?

• Use case : capture des exigences fonctionnelles
• Classes : modèle de domaine, structure statique
• Séquence : interactions complexes, scénarios précis
• État : objets avec cycle de vie
• Activité : workflow (alternative à BPMN)
• Composant : architecture en couches, modules
• Déploiement : infrastructure physique

Q2 : Différence entre agrégation et composition ? Agrégation : relation "a un" faible. L'objet enfant peut exister sans le parent. Exemple : Université → Professeur. Le professeur existe sans l'université. Composition : relation "est composé de" forte. L'enfant n'existe pas sans le parent. Exemple : Commande → LigneCommande. Les lignes n'existent pas sans commande.

Q3 : À quoi sert un diagramme de séquence ?

• Montrer l'ordre temporel des messages entre objets
• Visualiser les scénarios d'interaction complexes
• Identifier les dépendances et couplages
• Documenter les protocoles

Q4 : Quand utiliser un diagramme d'activité vs BPMN ? Diagramme d'activité UML : mieux pour les workflows techniques, algorithmes, comportement interne BPMN : mieux pour les processus métier, collaborations inter-entreprises, conformité BPMN 2.0

Q5 : Comment modélisez-vous une architecture existante ?

1. Reverse engineering : outils (Sparx EA, Structure101)
2. Interviews : développeurs, ops, métier
3. Code reading : packages, dépendances, patterns
4. Runtime observation : traces, logs, monitoring
5. Synthèse : C4 Model + ADR des décisions implicites

Architecture

Q6 : Expliquez le C4 Model. C4 = Context, Container, Component, Code. 4 niveaux de zoom :

• N1 Contexte : système + utilisateurs + systèmes externes
• N2 Conteneurs : applications, bases de données, files
• N3 Composants : modules internes d'un conteneur
• N4 Code : classes, interfaces (optionnel)

Q7 : Différence entre monolithe et microservices. Monolithe : un seul déploiement, partage de base, communication in-process Microservices : multiples déploiements, bases par service, communication réseau Monolithe modulaire : compromis (modules bien séparés, un seul déploiement)

Q8 : Qu'est-ce que l'architecture hexagonale ? Aussi appelée Ports & Adapters (Alistair Cockburn). Le domaine métier est au centre, entouré de ports (interfaces) qui communiquent avec les adaptateurs (DB, API, UI, tests). La règle de dépendance pointe vers le centre.

Q9 : Comment assurez-vous la scalabilité d'un système ?

• Verticale : plus de CPU/RAM
• Horizontale : plus d'instances
• Patterns : sharding, caching, CQRS, eventual consistency
• Anti-patterns : base de données comme goulot, sticky sessions

Patterns et Design

Q10 : Styles architecturaux majeurs

• Layered : couches horizontales (presentation, business, persistence)
• Pipe-and-Filter : séquence de transformations
• Event-Driven : communication asynchrone par événements
• Microservices : services indépendants
• Space-Based : grid computing, in-memory data grid
• Peer-to-Peer : nœuds décentralisés

Q11 : SAGA vs Process Manager SAGA : séquence d'étapes avec compensation en cas d'échec. Deux formes : chorégraphie (chaque service publie/reçoit) et orchestration (un coordinateur central). Process Manager : pattern DDD où un objet gère le flux d'un processus long (commande, workflow).

Q12 : Qu'est-ce que CQRS ? Séparation des modèles de lecture (Query) et d'écriture (Command). Permet d'optimiser chaque côté indépendamment, d'utiliser des bases différentes, et de scaler séparément. Simplifie l'event sourcing.

Q13 : Event Sourcing Stocke les événements comme source de vérité, pas l'état courant. L'état est reconstruit par rejeu. Avantages : audit complet, possibilité de remonter le temps, état cohérent. Inconvénients : complexité, performance des requêtes (nécessite des projections).

Q14 : Consistence éventuelle Dans un système distribué, il y a un délai entre l'écriture et la lecture cohérente. Gestion : versioning, lectures apériodiques, compensation humaine.

DDD

Q15 : Bounded Context Frontière explicite autour d'un modèle de domaine. Chaque contexte a son propre langage ubiquitaire, ses propres entités (même si le même concept existe dans un autre contexte). Exemple : "Client" n'a pas le même sens dans le CRM (adresse, fidélité) et dans la Facturation (coordonnées bancaires).

Q16 : Comment identifier un Aggregate ? Règles :

• Cohésion transactionnelle : ce qui doit être cohérent ensemble
• Invariants : règles métier qui doivent toujours être vraies
• Consistance : ne pas mettre plus d'une transaction dans un aggregate
• Taille : assez petit pour éviter les conflits, assez grand pour avoir du sens

Q17 : Ubiquitous Language Vocabulaire partagé entre métier et technique. Chaque terme a une définition unique. Éviter le jargon technique dans le modèle de domaine. Exemple : "Annuler commande" plutôt que "Update statut = 4".

Bases de données

Q18 : SQL vs NoSQL

• SQL : données structurées, relations complexes, ACID
• NoSQL : documents flexibles, scalabilité horizontale, schémas variables
• Choix selon : besoin de cohérence, volume, pattern d'accès, maturité équipe

Q19 : Théorème CAP 3 propriétés : Consistency (tous les nœuds voient la même donnée), Availability (toute requête reçoit une réponse), Partition Tolerance (le système continue malgré une coupure réseau). Un système distribué ne peut garantir que 2 des 3.

---

Partie 3 : System Design

Sujet 1 : Système de réservation (type Booking.com)

Besoins fonctionnels :

• Recherche d'hébergements par dates/lieu
• Réservation et paiement en ligne
• Gestion des disponibilités en temps réel
• Annulation et remboursement
• Avis et notes

Contraintes :

• 10M+ utilisateurs actifs
• 500K+ réservations/jour
• Disponibilité 99.99%
• Temps de réponse < 200ms pour la recherche

Architecture proposée :

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

Points clés :

• Recherche : ElasticSearch pour la full-text search, Redis pour les résultats fréquents
• Disponibilité : Optimistic concurrency control sur les réservations, verrouillage pessimiste pour la dernière place
• Scalabilité : Sharding par région, CQRS (recherche ≠ réservation)
• Transactions : Saga orchestrated pour réservation → paiement → confirmation
• Résilience : Circuit breaker, retry avec backoff, queue de dead letters

Questions d'approfondissement :

• Comment gérer le surbooking ?
• Comment garantir qu'une chambre n'est pas réservée 2x au même moment ?
• Comment scaler la recherche pendant le Black Friday ?
• Que faire si le paiement échoue après la confirmation de réservation ?

Sujet 2 : Plateforme e-commerce

Besoins fonctionnels :

• Catalogue produits (catégories, filtres, recherche)
• Panier d'achat
• Processus de commande
• Paiement multi-moyens
• Gestion des stocks
• Avis clients
• Recommandations

Architecture en DDD : Bounded Contexts : Catalogue, Panier, Commande, Paiement, Stock, Avis, Facturation, Marketing

Points clés :

• Panier : stocké en Redis, persistance en base au checkout
• Commande : aggregate Commande avec invariants (total vérifié, stock réservé)
• Paiement : process manager orchestrant le cycle de vie
• Stock : événementiel (StockRéservé, StockLibéré, Rupture)
• Catalogue : vue dénormalisée dans ElasticSearch

Sujet 3 : Système de traitement de flux événementiel temps réel

Besoins :

• Ingestion de 100K événements/s
• Traitement temps réel avec fenêtres temporelles
• Alertes et notifications
• Stockage pour analyse historique
• Dashboard temps réel

Architecture :

Sources → Kafka → Flink/Spark Streaming → (Sink: DB + Dashboard)
                         ↓
                    Alert Engine → Notification Service

Points clés :

• Kafka : bufferisation, rejeu, partitionnement
• Flink : processing avec exactly-once semantics
• Stateful processing : fenêtres, aggregates, pattern matching
• Exactly-once : idempotence, transactions Kafka

---

Conseils pour l'entretien

Préparation :

1. Maîtriser le C4 Model (20% des questions architecture)
2. Savoir dessiner sur un tableau blanc
3. Préparer 3 projets parlables en détail
4. Connaître les patterns microservices sur le bout des doigts
5. Être capable de comparer 2 approches

Pendant l'entretien :

1. Clarifier le périmètre et les contraintes
2. Commencer simple, détailler ensuite
3. Parler des trade-offs (toujours)
4. Mentionner les ADR dans votre processus
5. Utiliser des exemples concrets

Anti-patterns en entretien :

• Donner une seule réponse sans alternatives
• Ignorer les contraintes de coût
• Négliger les aspects non-fonctionnels
• Ne pas citer de sources
• Être dogmatique (toujours "ça dépend")