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

Capteur thermique

Détection d'environnement

Daylight sensor configuré en mode inversé : signal actif quand l'intensité lumineuse dépasse un seuil, simulant une surcharge thermique. Produit un signal Redstone binaire : surchauffe / nominal.

Output → Interface I₁
signal: ON (surchauffe) | OFF (nominal)

Composant B

Ventilateurs

Système d'actuation

Réseau de pistons qui s'activent en séquence à la réception du signal de surchauffe. La mécanique d'activation détermine si un override manuel peut être ajouté sans reconstruire l'ensemble.

Input ← Interface I₁ | Output → Interface I₂

in: signal activation | out: état ventilation

Composant C

Tour de monitoring

Feedback visuel

Lampes Redstone colorées indiquant l'état global du système : vert (nominal), orange (surchauffe détectée), rouge (alerte). Visible depuis l'extérieur du bâtiment — c'est le dashboard opérationnel.

Input ← Interface I₂

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.

Protocol de validation — 20 minutes, non négociablesGate de démarrage

Dessin du système — sur papier millimétré fourni physiquement

L'équipe dessine les 3 composants, leurs connexions, et les 2 points d'interface. Chaque composant doit être nommé. Les inputs et outputs doivent être indiqués. Les dépendances doivent être tracées avec une flèche.

Durée : 10 minutes maximum. Si l'équipe bascule en débat architectural, c'est le signe que la phase de design est utile. Le facilitateur laisse le débat se tenir.

Attribution des composants — qui construit quoi

L'équipe se divise en 2 à 3 sous-groupes, chacun responsable d'un composant. La règle : chaque sous-groupe doit pouvoir expliquer les inputs et outputs de son composant sans regarder le blueprint. Si quelqu'un ne peut pas, le composant n'est pas encore assez spécifié.

Revue d'architecture — le facilitateur joue le rôle du CTO

Le facilitateur pose 4 questions précises avant de valider.

(a) "Si je déconnecte le Composant A, est-ce que B et C restent opérationnels ?"
(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 ?"

Validation — ou renvoi en conception

Le facilitateur valide le blueprint ou renvoie l'équipe en phase de conception avec un commentaire précis. La validation n'est pas un tampon — c'est un acte délibéré. Le facilitateur dit "je valide parce que..." et note ce qu'il n'a pas validé mais laisse passer.

Si l'équipe dépasse 20 minutes en phase Blueprint, le facilitateur interrompt et valide le plan en l'état, en signalant ce qui n'est pas encore spécifié. Les lacunes de spécification deviennent alors des éléments à observer pendant le build et à nommer pendant le debrief.

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

Workshop ciruit break IT/Dev Serious Craft Gad Lab AMI Digital

Debrief

Questions calibrées IT / Tech

"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

"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

"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

"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é

"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

"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

Inscrire son équipe

The

Blueprint

Ancrage Serious Gaming