Bug, panne, urgence :
ici, on s'y entraîne.
Le parcours Agona injecte ce que le métier fait vivre : un bug qu'on n'a pas écrit, une lenteur à prouver, un incident en production, un besoin qui change en plein sprint. Des situations scriptées, préparées à l'avance, débriefées à chaque fois.
4 scénarios
Écrits avant la promotion, injectés au moment prévu du parcours
5 verbes
Hériter, développer, diagnostiquer, exploiter, défendre
La démarche
Hypothèses, méthode, communication
Un débrief
Chaque épreuve se conclut par un débrief collectif
Le fil
5 verbes, tout le métier.
3 verbes sont dans la structure même du parcours. Les épreuves fabriquent les 2 autres : diagnostiquer et exploiter.
Hériter
À chaque sprint, une seule base de code continue et les 5 équipes repartent de celle-là. L'épreuve permanente.
Développer
Le quotidien : concevoir, coder, tester, livrer en équipe sur un cas réel.
Diagnostiquer
Comprendre pourquoi un système existant ne fonctionne plus, et le prouver.
Exploiter
Observer une application qui tourne, investiguer un incident, décider.
Défendre
À chaque revue : quelles alternatives, pourquoi ce choix, à quelles conditions le revoir.
Le calendrier
Chaque chose en son temps.
Une épreuve par sprint, du sprint 2 au sprint 5. La difficulté monte avec la promotion.
Aucune épreuve
Intégration, première boucle complète, rituels en place. On apprend d'abord à courir la boucle.
E1 · Le bug injecté
La base héritée contient un défaut scripté. Diagnostiquer commence ici.
E2 · Le diagnostic de performance
Des données réalistes arrivent, et avec elles les lenteurs. Prouver avant de corriger.
E3 · L'incident de production
Un jour non annoncé, le service casse. Exploiter, c'est maintenant.
E4 · Le changement de besoin
Le besoin métier se précise en plein sprint. L'architecture encaisse, ou pas.
Les épreuves
4 situations, 4 réflexes.
Le bug injecté
Sprint 2« Je sais comprendre pourquoi un système existant ne fonctionne plus. »
Un défaut plausible est introduit par le formateur dans la base commune que toutes les équipes héritent : logique métier subtile, cas limite, erreur masquée. Le symptôme est signalé, la cause est à trouver.
- Ce qu'on attend : reproduire le problème, formuler des hypothèses avant d'agir, instrumenter (logs, debugger, requêtes), isoler la cause racine.
- Ce qui reste : la correction, le test de non-régression qui l'ancre, et le récit du diagnostic dans la pull request.
- Le débrief : les 5 chemins de diagnostic comparés en collectif.
Le diagnostic de performance
Sprint 3« Pourquoi c'est lent, et comment le prouvez-vous ? »
Un jeu de données volumineux rejoint l'application, et ce qui semblait rapide ne l'est plus : requête N+1, index manquant, pagination absente, sur-fetch. La consigne : « prouvez ».
- Ce qu'on attend : mesurer au lieu de deviner, prouver avec EXPLAIN ANALYZE et des chronométrages, corriger, re-mesurer.
- Ce qui reste : un avant/après chiffré présenté à la revue, et le réflexe de tester sur des données réalistes.
L'incident de production
Sprint 4 · jour non annoncé« Quand un système en production casse, on l'assume. »
L'application vit en production réelle sur l'infrastructure du programme, déployée à chaque sprint. Un jour non annoncé, elle casse : service indisponible, erreurs 500, données incohérentes. C'est l'épreuve de l'ownership.
- Ce qu'on attend : trier (corriger ou rollback ?), répartir l'investigation, communiquer l'état par écrit pendant l'incident, restaurer le service.
- Ce qui reste : un post-mortem court et factuel : chronologie, cause, remédiation, prévention.
Le changement de besoin
Sprint 5 · mi-sprint« Le métier vient de préciser que la règle n'était pas exactement celle-ci. »
En milieu de sprint, le formateur, porteur du besoin, précise une règle métier centrale. Le test porte sur l'architecture, et sur la réaction de l'équipe.
- Ce qu'on attend : poser des questions avant de coder, écrire l'analyse d'impact, arbitrer (adapter ou refactorer ?), implémenter sans casser ce qui tient.
- Ce qui reste : au débrief, on compare ce que le changement a coûté à chacune des 5 bases, ce qui démontre la valeur d'une bonne architecture.
Le calendrier des épreuves est publié, sprint par sprint, avant même de candidater.
La suite
Des réflexes de senior,
en une promotion.
Les épreuves s'inscrivent dans un parcours complet : objectifs, compétences, évaluation, cadre. Tout est publié.
Voir le programme complet La grille de revue · L'accueil