Product Owner
Clarifie le besoin, la valeur et les priorités. N’impose ni estimation ni surcharge.
ARIAVÉO SUITE / SIMULATION
Vivre le projet.
Comprendre ses décisions.
Une équipe virtuelle, un client, un budget et des imprévus. Une mission pour apprendre à livrer un site utile sans oublier les personnes qui le construisent.
Une partie individuelle, plusieurs rôles à incarner, un débriefing possible avec un coach.
ATELIER HORIZON · VOTRE ÉQUIPE
« Que pouvons-nous vraiment terminer avec la capacité disponible ? »
APPRENDRE PAR L’EXPÉRIENCE
Un projet concret. Des responsabilités distinctes.
Atelier Horizon veut présenter ses ateliers et faciliter les demandes de rendez-vous. L’apprenant clarifie le besoin, estime le travail, prépare un sprint, répond aux situations rencontrées et inspecte le résultat. Les fonctionnalités terminées font évoluer l’aperçu du site.
Développeurs
Estiment collectivement, organisent leur travail et évaluent ce qu’ils peuvent prendre en charge.
Scrum Master
Facilite les échanges et la résolution des désaccords. Ne décide pas à la place des autres.
Le changement de rôle sert l’apprentissage. Il ne s’agit pas d’une partie multijoueur : les collègues, le client et le sponsor sont des personnages simulés.
DU BESOIN AU RÉSULTAT
Chaque fonctionnalité met un arbitrage en pratique.
Planning Poker collectif
Des votes différents, des arguments et des clarifications sur le périmètre, les dépendances et les risques. L’équipe revote ; un désaccord peut mener à une investigation ou à un découpage.
Ce que cela implique : aucun chiffre imposé par le PO, le Scrum Master ou le lead. Les points comparent la taille des besoins ; ils ne deviennent pas des heures.
Une capacité par personne
Les tâches affichent leurs fourchettes d’heures, les compétences nécessaires et les contributions proposées. Le planning compare la charge aux disponibilités de chaque membre.
Ce que cela implique : le temps libre d’un développeur ne compense pas automatiquement une surcharge de vérification. Une investigation consomme elle aussi de la capacité.
Daily et entraide
Le joueur choisit une priorité, explique son lien avec l’objectif et peut convenir d’une reprise de tâche ou d’un binôme avec une personne disponible et compétente.
Ce que cela implique : aider mobilise deux personnes ; le travail habituel du collègue peut attendre. Le binôme ne double pas automatiquement la vitesse.
Un board qui suit le travail
Les cartes passent de « À faire » à « En cours », puis aux vérifications et à « Terminé ». Les dépendances, les heures restantes, les responsables et les blocages restent visibles.
Ce que cela implique : une carte n’est pas livrée parce qu’on la déplace ou parce que son estimation était faible. Le travail et les contrôles doivent réellement être achevés dans le modèle.
Situations et absences variables
Les nouvelles parties conservent un tirage de situations et d’absences. Une absence prévue réduit la capacité du planning ; un imprévu est annoncé au Daily concerné.
Ce que cela implique : pas de nouveau tirage au rechargement, pas d’heures supplémentaires distribuées aux autres. Le retrait d’une compétence peut retarder une dépendance.
Une nouvelle demande pendant le sprint
Dès le deuxième Daily, Léa peut proposer un besoin métier. Le joueur examine les contributions et choisit un accord d’intégration, un échange de périmètre ou un report au backlog.
Ce que cela implique : l’intégration crée de vraies tâches. Elle est refusée si la charge reste supérieure aux disponibilités. Un report conserve le travail déjà réalisé et les dépendances sont contrôlées.
Du travail technique supplémentaire
Les développeurs peuvent retenir un contrôle technique nécessaire à un élément en cours. La tâche apparaît sur le board, avec une charge et une contribution proposée.
Ce que cela implique : les vérifications attendent cette tâche. La charge augmente, sans fabriquer de points métier ; l’équipe peut devoir revoir le périmètre avec le PO.
Un budget d’équipe par sprint
L’hypothèse pédagogique est de 10 000 CHF pour un sprint de cinq jours, soit 30 000 CHF pour la mission. Le financement, les engagements et le dépensé sont distingués.
Ce que cela implique : le coût suit le temps simulé, pas les points ni les heures productives. Une absence ne réduit pas le forfait. Une demande d’extension n’accorde aucun budget automatiquement.
Burn-up, burn-down et revues
Le burn-up compare les points livrés au périmètre du sprint. Le burn-down suit les heures restantes face à un repère idéal. Les revues rapprochent livraisons, valeur et financement.
Ce que cela implique : ajouter du travail ou réévaluer une difficulté peut faire remonter la courbe. Une trajectoire idéale n’est pas une promesse. Les jours futurs restent vides.
Rétrospective et historique
À chaque cycle, le joueur retient une amélioration et peut relire ses décisions. Les résultats et les réflexions par rôle donnent une base concrète au débriefing.
Ce que cela implique : expliquer un compromis compte dans l’apprentissage. Le score fournit un repère de discussion ; il ne remplace pas l’analyse du coach.
COMPRENDRE LES CONSÉQUENCES
Un choix peut aider le client
et fragiliser l’équipe.
Les conséquences sont définies par le scénario. L’exemple ci-dessous compare plusieurs réponses au même retour client, à partir d’un état identique.
Un retour change les priorités
Les premiers essais montrent que la majorité des visiteurs vient d’un téléphone. Le client préfère un parcours simple et lisible.
La discussion aide à arbitrer ; le prochain planning pourra refléter ce retour.
Énergie de l’équipe70/100
Confiance client70/100
Qualité78/100
Dette technique0/100
Exemple tiré du scénario. Cliquer compare les réponses ; cela ne modifie aucune partie. Sans JavaScript, la première réponse et ses effets restent lisibles.
Ce que les indicateurs mesurent — et ce qu’ils ne font pas.
Énergie de l’équipe
Elle part de 70/100. La pression et les promesses excessives peuvent la réduire ; la coopération et certaines améliorations de rétrospective peuvent la soutenir.
Effet vérifié : elle entre dans l’axe « collaboration » du bilan, avec la confiance. Elle ne modifie pas directement les heures disponibles ni la vitesse du travail. Une énergie de 50 ne signifie pas « deux fois moins de production ».
Confiance client
Elle part de 65/100 et évolue selon les réponses au client ou au sponsor, la transparence et les compromis proposés.
Effet vérifié : elle contribue au bilan de collaboration. Elle ne déclenche pas automatiquement un départ du client ni une réduction de financement.
Qualité
Elle part de 75/100. Les raccourcis peuvent la dégrader ; les vérifications anticipées et les décisions favorables à la qualité peuvent l’améliorer.
Effet vérifié : elle contribue au bilan et à l’indicateur de préparation à la mise en ligne. Les tâches de vérification restent à terminer séparément : une jauge élevée ne les termine pas.
Dette technique
Elle part de 0. Certains compromis l’augmentent ; une amélioration de vérification peut la réduire.
Effet vérifié : à partir de 12, le modèle retire une heure de disponibilité à la journée simulée. La dette réduit aussi l’axe qualité du bilan. C’est une règle pédagogique, pas une loi universelle du développement logiciel.
Comment lire le score final ?
Le score combine quatre axes : valeur livrée (30 %), qualité (25 %), adaptation (20 %) et collaboration (25 %). La collaboration est la moyenne de la confiance et de l’énergie. L’axe qualité retranche la moitié de la dette technique, arrondie. L’adaptation s’appuie sur les réponses aux situations reconnues comme des pratiques d’adaptation dans le scénario.
Les explications libres, la pertinence d’un arbitrage et toutes les actions de gestion ne sont pas évaluées sémantiquement par ce score. Elles restent dans l’historique pour le débriefing. Ce score ne constitue pas une certification Scrum.
VALIDATION FONCTIONNELLE / 2 NOVEMBRE 2026
20 missions complètes.
Des résultats consultables.
Parcours automatisés sur cinq politiques et quatre tirages partagés. Ce ne sont pas des essais utilisateurs. Chaque politique a été exécutée sur quatre tirages identiques de situations et d’absences, sauf le cas témoin sans absence. Les choix des scripts suivent une règle fixe : ce ne sont ni des personnes ni des agents apprenants.
20parcours de trois sprints2 443assertions dans cette campagne30 000 CHFcoût final de chaque parcours
| Stratégie automatisée | Fonctionnalités livrées | Énergie /100 | Dette /100 | Demandes acceptées |
|---|---|---|---|---|
| Priorités et capacité | 5–8 | 94 | 0 | 0 |
| Périmètre large, dialogue | 7–10 | 94 | 0 | 0 |
| Périmètre large, pression | 7–10 | 36 | 24 | 0 |
| Demandes négociées | 7–9 | 94 | 0 | 3 |
| Dialogue, sans absence | 11–13 | 94 | 0 | 0 |
La pression ne se lit pas uniquement dans le débit.
Dans ces essais, les parcours « périmètre large, pression » terminent à 36/100 d’énergie et 24/100 de dette, contre 94 et 0 pour les parcours comparables privilégiant le dialogue. Le nombre de fonctionnalités livrées reste parfois proche.
Le débriefing doit donc regarder plusieurs dimensions, plutôt que récompenser seulement le nombre de cartes terminées.
Réduire le périmètre ne garantit pas le meilleur score.
Le script « priorités et capacité » est volontairement prudent ; il livre moins d’éléments sur certains tirages. La version sans absence dispose de davantage de capacité. Les nouvelles demandes peuvent aussi modifier le nombre et la valeur des éléments au backlog.
Ces essais vérifient le fonctionnement du modèle. Ils ne prouvent ni un gain d’apprentissage ni la supériorité d’une stratégie dans un projet réel.
Qu’avons-nous vérifié en plus des vingt parcours ?
- Accord collectif au Poker, refus d’une estimation imposée, investigation et découpage.
- Capacité individuelle, absences, entraide, dépendances et vérifications avant livraison.
- Ajout négocié, refus en surcharge, report au prochain Poker et tâche technique bloquant les vérifications.
- Budget fixe, conservation du travail, graphiques et historique des sprints.
- Sauvegarde, rechargement, double soumission, conflits de révision et séparation des accès.
- Parcours dans le navigateur, consultation du coach en lecture seule et affichages à 390, 768 et 1 440 pixels.
Les jeux de tests utilisent des bases isolées. Aucune partie d’un apprenant n’a été terminée ou réinitialisée pour cette campagne.
POUR LES ORGANISMES DE FORMATION
Préparer, observer, débriefer.
Administrateur
Active le module pour son établissement et affecte une mission à un participant ou à un groupe existant. Les sessions restent séparées entre établissements.
Apprenant
Peut ouvrir plusieurs parties du même scénario en parallèle, reprendre chacune séparément et consulter ses décisions. Les progressions et les anciens résultats restent indépendants.
Coach
Consulte les sessions autorisées en lecture seule. Les justifications, l’évolution des indicateurs et les résultats permettent de discuter des compromis concrets.
Quatre questions pour le débriefing
- Qu’avez-vous protégé lorsque la capacité a diminué ?
- Quelle promesse a eu un coût pour l’équipe ou la qualité ?
- Quelle nouvelle demande méritait de remplacer autre chose ?
- Que changeriez-vous en rejouant les mêmes situations ?
Un cadre explicite pour apprendre avec discernement.
- Temps de jeu : 60–90 minutes est une estimation pédagogique, pas une mesure issue d’essais utilisateurs. Prévoir davantage pour un débriefing animé.
- Réactions scénarisées : les personnages, votes et conséquences suivent le modèle. Il ne s’agit pas d’un dialogue libre avec des collègues humains.
- Effets distincts : certaines réponses modifient les indicateurs ; les accords explicites de périmètre et d’ajout créent ou retirent le travail sur le board.
- Financement : le forfait est une hypothèse d’exercice. Une extension peut être préparée, mais la mission reste limitée à trois sprints.
- Historique : une ancienne partie garde son scénario. Les valeurs de graphiques qui n’étaient pas enregistrées ne sont pas inventées.
- Portée : une mission prête à jouer, sans éditeur de scénario. Les constats publiés ici concernent le moteur V6 testé à la date indiquée.
Personnes, entreprise, budgets et données fictifs. Présentation et rapport de validation fonctionnelle · 2 novembre 2026.