J'ai piloté le run d'un hub de données avec un objectif qui n'a jamais bougé : faire baisser le nombre d'incidents récurrents, en cartographier les causes, capitaliser les corrections pour réduire ce qu'ils coûtaient, en temps, en ressources humaines, en impact pour les clients finaux. Chaque incident ouvert était corrigé, chaque ticket fermé, le rythme donnait l'impression d'avancer.

Ce qui a changé, ce n'est pas cet objectif, c'est ma certitude qu'un ticket fermé ne dit rien sur la question qui compte vraiment : est-ce qu'on progresse encore vers lui, ou est-ce qu'on referme en boucle le même problème sans le savoir ?

Ce que la routine ne montrait pas

Vu de l'extérieur, tout fonctionnait : les incidents arrivaient, étaient analysés, corrigés, fermés. Le rythme donnait l'impression d'une équipe qui avance.

C'est exactement le genre de routine où personne ne se pose la question de la redondance, parce que chaque incident, pris isolément, ressemble à un problème nouveau qu'on vient de résoudre, pas à la répétition d'un problème déjà résolu la semaine d'avant, par quelqu'un d'autre, d'une façon légèrement différente.

Le signal n'est pas venu d'un audit

Ce n'est pas un tableau de bord qui m'a mis la puce à l'oreille. En tant que proxy data owner, en quelques semaines sur le projet, j'avais déjà repéré que les mêmes incidents revenaient, trimestre après trimestre, chacun ré-analysé depuis zéro. Le problème, ce n'était pas de le voir : c'était de trouver l'occasion de changer un fonctionnement qui, sur le papier, faisait le travail.

Cette occasion est venue de l'arrivée d'un nouveau membre dans l'équipe. Il fallait le monter en compétences sur le périmètre, lui expliquer pourquoi telle correction se fait de telle façon. Et c'est en cherchant à transmettre cette connaissance qu'est devenu visible, pour toute l'équipe cette fois, ce que je portais seule depuis mon arrivée : il n'existait aucune trace écrite de ce qui avait déjà été analysé, chaque personne portant sa propre mémoire des incidents passés, remobilisée à chaque nouvelle occurrence, sans jamais être comparée à celle des autres.

La décision : documenter, puis automatiser ce qui pouvait l'être

La réponse n'a pas été "il faut plus de vigilance". Ça ne se corrige pas par de la bonne volonté. La décision a été de documenter systématiquement les actions de correction, chaque compte rendu archivé avec des liens vers les ressources et diagnostics déjà produits sur le sujet, pour que le temps d'analyse d'un incident déjà vu chute nettement la fois suivante : de 30-60 minutes en moyenne à moins de 15 minutes.

Et pour la part des incidents qui suivait un schéma récurrent identifiable, la correction elle-même a été structurée en une planification hebdomadaire, un batch de correction automatisé, plutôt qu'une intervention manuelle reprise depuis zéro à chaque occurrence..

La règle : l'OKR dit où, le suivi dit si

Un objectif, au sens OKR, répond à une seule question : où est-ce qu'on veut arriver. "Réduire les incidents récurrents et leurs coûts" ne dit jamais, seul, si l'équipe est en train de progresser vers ça ou de tourner en rond en fermant des tickets. C'est le rôle d'un système de suivi, ici la documentation des incidents et leur récurrence, de répondre à cette seconde question.

Et parfois, ce système n'existe pas encore sous forme d'outil : voir le problème ne suffit pas, il faut aussi une occasion pour le rendre visible à toute l'équipe, comme la nécessité de former quelqu'un de nouveau.

Ce que ça change dans la façon de documenter

La conséquence pratique n'est pas "il faut un wiki d'entreprise". C'est : documenter un incident au moment où il se répète pour la deuxième fois, pas la dixième. La redondance ne se voit pas dans l'instant, elle se voit seulement quand quelqu'un compare ce qui vient d'arriver à ce qui est déjà arrivé. Sans trace, il n'y a rien à comparer, et chaque répétition ressemble à un événement isolé. Former quelqu'un de nouveau n'a rien changé à l'objectif de l'équipe. Ça a changé le moment où la redondance est devenue visible.

La vraie question n'est pas "mon équipe atteint-elle ses objectifs". C'est : est-ce que quelqu'un, dans mon équipe, pourrait aujourd'hui expliquer par écrit pourquoi on corrige les choses comme on les corrige, et si la réponse est non, ce n'est pas l'objectif qu'il faut revoir en premier, c'est ce qui reste seulement dans la mémoire de l'équipe.

Si tu repères un problème récurrent en quelques semaines, la vraie question n'est pas de le voir. C'est de trouver l'occasion de le corriger.

Localisation

Le Mans, France

Contacts

ashlyne@qiveo.co

Qiveo
Je vois ce que les équipes ont normalisé. Je le questionne. J'écris ce que ça donne.

© 2026 Qiveo