J’ai rejoint une équipe en charge d’un produit digital critique dans les services financiers. L’organisation fonctionne en sprints d'une semaine, avec des déploiements fréquents et un backlog priorisé. L’équipe corrigeait régulièrement des incidents, mais le système demeurait instable, et entrainait le ralentissement du flux de production.
Introduction
J’ai rejoint une équipe en charge d’un produit digital critique dans les services financiers.
L’organisation fonctionne en sprints d'une semaine, avec des déploiements fréquents et un backlog priorisé.
L’équipe corrigeait régulièrement des incidents, mais le système demeurait instable, et entrainait le ralentissement du flux de production.
Redéfinir ce qu’est un incident
Un incident n’est pas un bug, c’est une rupture de flux
En Lean, un incident, ou défaut, correspond à un écart à un standard.
Dans notre contexte, une demande de financement suit une succession d’étapes définies, avec un lead time cible de deux heures. Ce délai constitue le standard. Un dossier qui dépasse ce temps ou qui s’arrête en cours de traitement crée du leadtime supplémentaire, c'est-à-dire du temps en plus dans le traitement de la demande.
Prenons un exemple simple.
Lors du scoring, une valeur null non gérée déclenche une exception :
if (!customer || customer.income == null) {
throw new Error("MISSING_VAL");
}
Le dossier passe en erreur et le processus s’interrompt.
Nous utilisons un orchestrateur qui permet de matérialiser ce flux. Chaque dossier progresse étape par étape. En cas d’erreur, la tâche se fige et le dossier reste bloqué.
Rendre les incidents visibles
Obeya : rendre la stratégie visible
J’ai découvert le mot Obeya (en japonais “grande salle”) en lisant Learning to Scale at Theodo. Le livre y décrit les grandes salles utilisées chez Toyota, référence historique du Lean et de l’amélioration continue, pour rendre visibles les objectifs, les indicateurs et les plans d’action.
Le concept a pris une dimension concrète lorsque mon CTO m'a présenté l'Obeya de Theodo Fintech : un board centralisant les KPI et les priorités de l'entreprise.
L’Obeya est un espace, physique ou virtuel, qui rend la stratégie visible à court, moyen et long terme.
On y affiche les objectifs, les indicateurs et les actions en cours.
Cette visibilité crée un alignement. Chacun comprend la direction et la contribution attendue.
Un système sans visibilité
Lorsque nous avons commencé à travailler sur la gestion des incidents, un constat s’est imposé : l’absence de management visuel.
Les incidents étaient dispersés entre tableaux, tickets et discussions. Aucun point central.Ni l’équipe produit ni l’équipe tech ne percevaient réellement le volume réel d’incidents.
Or, l’Obeya repose sur le management visuel : rendre les informations clés visibles et partagées.Sans cette visibilité commune, la priorisation reste floue.
Dans ce contexte, arbitrer entre résolution d’incidents et delivery de nouvelles fonctionnalités devenait difficile.
Notre Obeya des incidents
De ce constat d’absence de management visuel s’en est découlé un board d’incidents inspiré de l’Obeya. Il centralise les incidents et répond à des questions simples :
- Combien sont en cours ?
- Où sont-ils bloqués ?
- Depuis combien de temps ?
- Qui agit ?
Le board structure la priorisation et reflète l’état réel du système.
Il centralise les incidents et répond à des questions simples. Pour notre équipe, nous avons identifié les questions qui revenaient le plus souvent, pour les matérialiser en colonnes :
- Combien sont en cours ?
- Où sont-ils bloqués ?
- Depuis combien de temps ?
- Qui agit ?
Le board structure la priorisation et reflète l’état réel du système. Chaque board est unique : il dépend de l’équipe et des problèmes régulièrement rencontrés.
Ce tableau permet de forcer une décision collective sur ce qui compte vraiment.Ça donne une réelle vision globale à l'équipe (tech et produit) sur les incidents, et ça permet à tous de s'apercevoir à quel point notre flux est constamment pollué par ces défauts.
Mettre la stabilité au centre du daily
Avant, le daily était centré sur le delivery. Les incidents passaient après, et ils étaient traités selon le temps disponible ou par la personne la moins sollicitée.
Aujourd’hui, chaque daily débute par le board d’incidents.Avant d’aborder les features, l’équipe examine l’état du système. Chacun partage les incidents résolus ou en cours, afin de garantir une vision commune et actualisée.
En inversant l’ordre des sujets du daily, on a inversé les priorités de l’équipe : petit geste, grand impact.
Créer un rôle pour protéger le flux : le Dungeon Keeper
Quand tout le monde est responsable, personne ne l’est
Malgré la mise en place d’un board d’incidents, leur nombre ne diminuait pas. La responsabilité du flux restait diffuse : chacun les traitait entre deux tâches du sprint.
Les développeurs jonglaient entre features et urgences. Les interruptions se multipliaient. Les incidents s’éternisaient.
On a là une chaîne causale : l’absence de responsabilité empêchait la priorisation. Les incidents passaient après, entraînant une interruption intempestive du flux.
Le Dungeon Keeper : un gardien du flux
Malgré le board, les incidents diminuaient peu. La responsabilité restait diffuse. Les développeurs les traitaient entre deux tâches, au prix de changements de contexte permanents.
Nous avons donc créé un rôle dédié : le Dungeon Keeper (DK).
Le DK est responsable du flux d’incidents pendant sa période de garde. Toutes les alertes et sollicitations urgentes passent par lui. Il traite les incidents un par un, tandis que le reste de l’équipe reste concentré sur le delivery.
Cette organisation réduit le context switching et protège le focus collectif.
Au départ, la rotation était quotidienne. Nous sommes ensuite passés à une rotation hebdomadaire. Cette évolution a renforcé la responsabilisation du DK, limité les transmissions et permis un suivi plus structuré des sujets sur la durée.
.png)
Traiter la cause par la racine du problème
Du gardien du flux à l’agent de transformation
Changeons de perspective.
Jusqu’ici, nous parlions du flux et de son organisation. Place maintenant aux causes profondes. L’objectif consiste à transformer le système.
À ce stade, le Dungeon Keeper devient un moteur d’amélioration continue.
Face à un incident, la réaction instinctive consiste à aller vite : redémarrer un serveur, vider un cache, relancer un job. Le service repart, le ticket est fermé, le delivery continue.
Cette logique entretient pourtant le problème. Le symptôme disparaît, la cause reste. L’incident finit par revenir, souvent dans un contexte plus tendu.
Chaque correctif rapide non analysé alimente une dette invisible. Le problème s’installe, réapparaît, génère du context switching et érode progressivement la performance de l’équipe.
Le Dungeon Keeper vise un autre objectif : éliminer les causes pour éviter les répétitions. Le board ne sert pas à afficher zéro incident. Il sert à renforcer durablement le système.
Résoudre la cause, pas le symptôme
C’est ici qu’intervient la Résolution de Problème (RDP).
Un problème correspond à un écart à un standard. Sans standard explicite, aucun écart ne peut être identifié. La première étape consiste donc à formuler clairement ce qui était attendu : quel flux, quel livrable, quel comportement du système.
Ensuite, l’équipe décrit la situation réelle, uniquement à partir de faits : logs, délais, étapes manquées, comportements observés. La comparaison entre attendu et réel rend l’écart visible.
La RDP modifie aussi la posture collective. L’objectif consiste à identifier une cause racine. La question devient : pourquoi le système a-t-il permis cet écart ? Standard flou, contrôle absent, alerte manquante, dépendance mal gérée, formation insuffisante. Tant que l’analyse s’arrête à un individu, le système reste inchangé.
L’investigation se poursuit jusqu’à atteindre une cause sur laquelle une action structurelle peut agir. S’arrêter trop tôt laisse le problème intact.
Les actions définies doivent directement répondre aux causes identifiées. Certaines stabilisent immédiatement le flux. D’autres transforment durablement le système : renforcer un test, clarifier un standard, automatiser un contrôle, améliorer une alerte.
Une RDP inclut également un résultat attendu : diminution mesurable des occurrences, absence d’incident sur une période donnée, réduction d’un délai. Un indicateur valide l’efficacité des actions engagées.
Chaque incident doit produire une amélioration : évolution du code, meilleure détection, documentation clarifiée, automatisation supplémentaire, partage de connaissance au sein de l’équipe.
Sans cela, aucun apprentissage n’a lieu.
Faire de chaque incident un apprentissage
L’analyse d’incident ne doit jamais être optionnelle.
Ce n’est pas une activité à faire “quand on aura le temps”. Le manque de temps rend cette analyse nécessaire.
Sous pression, l’équipe corrige, puis retourne immédiatement au sprint. Les tickets avancent, la roadmap progresse.
Ne pas analyser un incident, c’est accepter sa répétition. Le coût augmente à chaque réapparition : plus d’utilisateurs impactés, plus d’interruptions, plus de stress.
L’analyse constitue une mémoire partagée. Sans formalisation, les mêmes questions reviennent, les mêmes décisions se répètent, les mêmes oublis persistent.
Documenter un incident permet de clarifier :
- ce qui s’est passé,
- pourquoi,
- ce qui change,
- comment vérifier l’efficacité des actions.
Le temps consacré à comprendre une cause réduit les interruptions futures. Chaque analyse solide diminue le gaspillage, le context switching et les urgences répétées.
Ainsi, il est parfois essentiel de s’arrêter pour avancer plus vite.
L’Andon : arrêter pour mieux avancer
Lorsque la cause d’un incident reste floue ou que son impact devient critique, le Dungeon Keeper déclenche un Andon.
Issu du Lean, l’Andon consiste à arrêter le flux pour traiter un problème collectivement. L’équipe – ou les personnes les plus expertes – se mobilise immédiatement pour comprendre et corriger la cause.
Le delivery peut être mis en pause le temps nécessaire. L’objectif est de rétablir un système sain avant de reprendre.
L’Andon repose sur un principe simple :Un problème complexe appelle une expertise adaptée.
Cette escalade vers les bons niveaux de compétence permet une résolution plus rapide et diffuse la connaissance dans l’équipe. Chaque Andon renforce la capacité collective à traiter les incidents futurs.
.png)
Les résultats après 6 mois de mise en place
La mise en place du rôle de Dungeon Keeper a produit des effets très concrets. Le premier a été spectaculaire : nous avons divisé par trois le nombre d’incidents. En traitant systématiquement les causes racines plutôt que les simples symptômes, nous avons supprimé des problèmes récurrents au lieu de les subir encore et encore. Moins de “déjà-vu”, moins de crises inutiles, et un système globalement plus stable.
.png)
Le niveau de stress a lui aussi fortement diminué. Les interruptions ne sont plus permanentes ni imprévisibles. Le reste de l’équipe peut se concentrer sans craindre qu’une alerte surgisse à tout moment. Même pour le Dungeon Keeper, la pression est plus saine : elle est claire, assumée, temporaire. On est passé d’un stress diffus et constant à une responsabilité cadrée et maîtrisée.
Contrairement à ce que l’on pourrait penser, le delivery n’est pas devenu plus lent. Il est devenu plus fiable. En protégeant l’équipe du context switching, on rend les sprints plus prévisibles et les engagements plus solides. On ne va pas moins vite ; on évite simplement les ralentissements invisibles causés par les interruptions permanentes.
Enfin, le système entre dans une logique d’amélioration continue. Chaque incident traité sérieusement renforce la plateforme. Chaque semaine de Dungeon Keeper réduit un peu plus la fragilité du système. On ne cherche plus seulement à tenir, mais à progresser. Le système n’est jamais parfait, mais il devient, semaine après semaine, plus robuste qu’il ne l’était hier.
Un produit progresse lorsque chaque défaut devient une amélioration.
