Atelier IT / Dev
The
Blueprint
Un serious game de 90 minutes
Défi sur l'architecture logicielle.
On ne touche pas un bloc avant d'avoir le plan. Et le plan doit tenir à la modification.
⏱ 90 minutes
👥 4 – 8 personnes
🔴 Redstone avancée
📐 Blueprint obligatoire
Ancrage Serious Gaming
Pourquoi construire un système de ventilation révèle une architecture
Dans Minecraft, les dépendances entre composants sont physiquement visibles. Un câble Redstone qui relie deux composants sans passer par un point d'interface défini, c'est du couplage fort — littéralement — dans l'espace. On peut le voir. On peut le montrer. On peut demander : «Si tu déconnectes ce bloc, est-ce que le reste du système tient toujours ?»
The Blueprint exploite cette propriété pour simuler la décision architecturale la plus importante qu'une équipe puisse prendre : est-ce qu'on conçoit pour le changement, ou est-ce qu'on conçoit pour la livraison rapide ? Le twist à la minute 40 du build répond à cette question de manière irrévocable — et visible de tous.
Le paradoxe professionnel
«Une bonne architecture semble ralentir le début. Une mauvaise architecture semble accélérer le début. On ne sait lequel on a choisi qu'à la moitié du projet — quand le client demande un changement.»
— Martin Fowler, un auteur et conférencier britannique spécialisé en développement logiciel
Lexique
Minecraft → Architecture logicielle
| Composant Minecraft | Équivalent architecture | Ce que ça révèle |
|---|---|---|
| Daylight sensor | Event listener / trigger environnemental | Comment un système réagit à un état externe sans le poller |
| Piston | Actuator / side effect | Ce que le système produit dans le monde réel — pas juste ce qu'il calcule |
| Redstone lamp | Signal de monitoring / dashboard | La différence entre un système qui marche et un système qu'on sait qui marche |
| Câble Redstone entre composants | Couplage fort / dépendance directe | Ce qui rend un changement dans A un problème pour B |
| Bloc d'or (interface point) | Contrat d'API / interface publique | Ce qui peut changer librement d'un côté sans impacter l'autre |
| Blueprint papier | Architecture document / diagramme C4 | Ce qu'on ne spécifie pas avant de construire, on le découvre en cassant quelque chose |
| Input / Output spécifié | Définition d'interface / API contract | La précision ici détermine la facilité de travail en parallèle |
| Composant déconnectable sans casser | Couplage faible / modularité | Le test de la bonne architecture : peut-on remplacer ce composant sans tout reconstruire ? |
| Override manuel (switch physique) | Nouvelle feature client / change request | Combien ça coûte de changer — le vrai indicateur d'une bonne architecture |
| Validation facilitateur du blueprint | Architecture review / ADR | Une décision qu'on ne revient pas dessus sans raison explicite |
Scénario
The Forge · Concevoir un système de ventilation
Contexte : votre équipe est mandatée pour concevoir et construire le système de ventilation automatique du département The Forge, dans le bâtiment central de CraftCorp.
Trois composants interdépendants, deux sous-équipes en parallèle et une deadline fixe.
Contrats d'interface
Les blocs d'or · Le cœur du dispositif
Dans le monde pré-construit, trois blocs d'or sont posés à des positions fixes. Ils représentent les points d'interface entre les composants. Chaque équipe doit connecter son composant au bloc d'or — jamais autour. Ces blocs ne peuvent pas être déplacés. Ce sont les contrats d'API du système.
Composant A
Output → Interface I₁
signal: ON (surchauffe) | OFF (nominal)
Composant B
in: signal activation | out: état ventilation
Composant C
in: état ventilation | out: signal lumineux
Gate obligatoire
Le rituel Blueprint
Aucun participant ne peut placer un bloc avant que le facilitateur ait validé le blueprint. Ce n'est pas une formalité — c'est le mécanisme pédagogique central. La pression de "commencer à construire" est le premier ennemi de l'architecture. Le rituel la contient.
(b) "Si le client demande un switch manuel demain, dans quel composant est-ce que vous le branchez ?"
(c) "Quelle est la convention de signal entre A et B — qui envoie quoi à qui ?"
(d) "Où est votre couplage le plus fort — et est-ce que vous l'avez fait exprès ?"
Rôles
De 4 à 8 personnes
Architecte système
1~2 personnes
Conçoit et défend le blueprint. Définit les interfaces entre composants (les "API contracts"). Arbitre les conflits d'intégration. Après le twist, évalue l'impact du changement sur l'architecture globale.
Peut aussi jouer le rôle du tech lead qui explique ses décisions.
.
Équipe Capteur + Monitoring
1~2 personnes
Construit les composants A (capteur thermique) et C (tour de monitoring). Ces deux composants sont aux extrémités du système — ils n'ont qu'une seule interface chacun.
Profil recommandé : quelqu'un qui pense "événement" et "observabilité".
Équipe Ventilation
1~2 personnes
Construit le Composant B (pistons). Le composant central — deux interfaces, sensible au twist. C'est ici que la modularité se décide.
Profil recommandé : quelqu'un qui pense "side effects", "actuation", et "couplage".
Facilitateur SC
PO + CTO
Joue deux rôles successifs :
1. CTO pendant la revue Blueprint (valide l'architecture), client pendant le twist (annonce le changement).
2. PO pendant la demo (teste les cas limites). Observe et note les patterns de communication entre sous-équipes.
Chronologie
⏱️ 90 minutes
⏱️ 0 ~ 10’ • Onboarding
Contexte CraftCorp + découverte du monde
Présentation de The Forge, du système de ventilation à livrer, et des 3 composants. Tour du monde Minecraft : localisation des 3 zones et des blocs d'or.
Règle "pas de bloc avant validation" affichée et expliquée.
▶ Papier millimétré et stylos distribués physiquement
⏱️ 5 ~ 25' • Phase Blueprint
Conception — Gate obligatoire
L'équipe conçoit le système sur papier. Nommage des composants, spécification des interfaces, attribution des zones. Revue d'architecture par le facilitateur.
4 questions. Validation ou renvoi en conception.
❇ Phase la plus révélatrice sur la culture architecture de l'équipe
⏱️ 25 ~ 65' • Phase Build
Construction parallèle ~ 40 minutes
Chaque sous-équipe construit son composant dans sa zone. Travail en parallèle. Seul le blueprint sert de coordination. Les composants ne se touchent pas encore et chaque équipe construit jusqu'à son bloc d'or et s'arrête.
🔵 Build en cours
Le twist
⚠ Interruption — override manuel annoncé
Le facilitateur interrompt le build. Annonce le changement client. 5 minutes d'évaluation d'impact. L'équipe présente sa décision. Le facilitateur note le temps d'évaluation — c'est une métrique directe de la modularité de l'architecture.
⚠ Moment de vérité architectural
Phase Intégration
Connexion aux blocs d'or
Les sous-équipes connectent leurs composants aux interfaces. Les hypothèses implicites du blueprint apparaissent. Le facilitateur observe sans intervenir — sauf si un participant est physiquement bloqué (problème de contrôles Minecraft, pas d'architecture).
■ Test des contrats d'interface
Demo Client
Test du système complet
Le facilitateur teste : mode automatique (capteur seul), mode manuel (override seul), transition entre les deux, cas de panne simulée (déconnexion d'un composant). L'équipe documente ce qui fonctionne et ce qui a dû être compromis.
Debrief
Architecture sous la loupe
Le facilitateur relie chaque décision architecturale de l'atelier à une décision réelle de l'équipe. Le blueprint papier est posé sur la table — physiquement — et comparé au système livré. Les différences sont nommées.
✅ 70% de l'apprentissage se passe ici
Debrief
Questions calibrées IT / Tech
01
"Votre blueprint initial aurait-il permis à une autre équipe de construire votre composant à votre place ?"
→ Mappe sur : documentation architecturale, bus factor, onboarding de nouveaux membres
02
"Quand l'override manuel est arrivé, combien de composants avez-vous dû modifier — et est-ce que c'était prévisible depuis votre blueprint ?"
→ Mappe sur : coût réel du couplage, principe open/closed, architecture for change
03
"Où se trouvait le couplage le plus fort dans votre architecture — et est-ce que c'était un choix délibéré ou une conséquence non anticipée ?"
→ Mappe sur : dette architecturale consciente vs accidentelle, design decisions documentation
04
"Est-ce que votre système est encore compréhensible pour quelqu'un qui n'était pas là pendant le build — en regardant les blocs, pas le blueprint ?"
→ Mappe sur : lisibilité du code, self-documenting architecture, auditabilité
05
"Si vous recommenciez avec 5 minutes de Blueprint de plus, qu'est-ce que vous auriez spécifié que vous avez laissé implicite ?"
→ Mappe sur : hypothèses implicites, précision des ADR, valeur du temps de design upfront
06
"Dans votre projet réel actuel : si un client demandait un override manuel équivalent demain, combien de temps faudrait-il ?"
→ Mappe sur : architecture réelle de l'équipe — la question qui ramène tout dans la pièce
Le défi ultime
Construire une IA dans Minecraft
Un gamer de génie a poussé la Redstone jusqu’à l’extrême: recréer une forme d’IA directement dans Minecraft, uniquement avec des circuits logiques. La preuve spectaculaire que ce jeu peut devenir un véritable laboratoire d’architecture, d’intégration et de résolution de problèmes 🔹
90 minutes
Session de decouverte CHF 750
Adapté pour :
1re prise de contact
Equipe de 6 a 12 personnes
Problematique simple