Le RETEX qui améliore vraiment vos playbooks

Prenez au hasard les cinq derniers incidents traités dans votre équipe. Combien ont donné lieu à un RETEX écrit ? Combien de ces RETEX ont produit une modification vérifiable, une règle changée, un critère ajouté, un actif re-priorisé ? La deuxième réponse est presque toujours plus petite que la première, et souvent d'un ordre de grandeur.

Ce n'est pas une question de sérieux. Les équipes que nous accompagnons écrivent des RETEX honnêtes, souvent longs, souvent lucides. Le problème se situe ailleurs. Entre le document produit et la modification effective de la méthode, il n'y a personne. Le RETEX arrive comme un livrable au lieu d'être conçu comme un mécanisme.

La réaction naturelle, quand un RETEX n'a servi à rien, est de vouloir le rendre plus complet la fois suivante. On rajoute des sections, on demande une chronologie minute par minute, un tableau des impacts, une analyse des causes racines à cinq niveaux. Le document gagne en volume et perd en effet.

• Un document long est lu par une personne, rarement deux, et ne circule pas.
• Une chronologie exhaustive écrase les moments où une décision a été prise, et on ne voit plus où l'incident s'est joué.
• Une analyse des causes racines qui remonte à « manque de culture sécurité » ou « sous-effectif chronique » désigne un problème vrai, mais inactionnable à l'échelle du SOC, donc rangé.

Avant d'entrer dans les questions, le mécanisme se lit mieux en un coup d'œil. Un incident produit une timeline tracée pendant l'investigation, qui alimente un RETEX court en trois questions, qui produit trois modifications concrètes, qui reviennent nourrir le prochain incident.

Ce que nous demandons à un RETEX ARTEFACT tient sur une page et se construit autour de trois questions posées à chaque décision de la timeline.

• ✓Où avons-nous perdu du temps ? La question ne vise pas « qui a été lent ». Elle vise l'endroit précis où l'information manquait, la requête a été refaite, le contexte reconstitué. Chaque minute perdue devient un candidat à automatiser ou à pré-collecter.
• ✓Où avons-nous décidé sans critère explicite ? Toute décision prise à l'intuition (confiner, escalader, notifier, clore) porte un critère implicite qui gagne à devenir explicite dans le playbook. Sinon, la prochaine personne le réinventera.
• ✓Qu'est-ce que nous verrions différemment aujourd'hui ? À la lumière de la clôture, quel signal aurions-nous dû prendre au sérieux plus tôt ? C'est là que naissent les règles de détection utiles, celles qui viennent d'incidents réels plutôt que d'un catalogue.

Chaque question doit produire une sortie obligatoire : une action nommée, une personne responsable, une date. Sans ça, la question a été posée pour rien. C'est la différence structurelle avec un post-mortem classique : le but glisse de la compréhension à la modification.

Le débat n'est pas Word contre Notion, c'est l'objet du RETEX. Documenter et modifier n'appellent pas la même longueur. Vingt pages passent pour documenter, cinq lignes suffisent à modifier, et un document qui prétend faire les deux à la fois ne fait ni l'un ni l'autre.

Une règle qui simplifie la vie des équipes que nous accompagnons : un RETEX produit au plus trois modifications. Pas quatre, pas dix. Trois. Et chacune tombe dans l'un des trois seaux suivants.

Le chiffre trois n'est pas symbolique. Quinze modifications produisent zéro modification effective, parce que personne ne les porte, personne ne les priorise, et elles disparaissent au troisième incident suivant. Trois modifications, portées et datées, ont une chance d'exister dans le système un mois plus tard. La logique rejoint celle du tri par risk_score : la priorisation produit la valeur, et l'exhaustivité la dilue.

Cette contrainte de trois oblige à trancher pendant le RETEX. Si l'équipe se dispute pour choisir les trois, tant mieux, la conversation est exactement celle qu'il fallait avoir. Si elle en produit trente sans discuter, aucune ne verra le jour.

La formule « post-mortem sans blâme » (blameless post-mortem) est bien connue et souvent mal comprise. « Sans blâme » ne signifie pas « sans imputation ». L'imputation reste posée, mais elle porte sur le système au lieu de la personne.

Ce basculement n'est pas un exercice de politesse. Il produit des sorties différentes. La première colonne débouche sur « faire attention la prochaine fois », autrement dit rien. La deuxième débouche sur une modification concrète du système (file d'attente, critère, playbook, garde-fou). Seule la deuxième produit un effet à trois mois.

Le principal coût caché d'un RETEX classique se cache dans la reconstitution, pas dans l'analyse. Retrouver qui a fait quoi, à quelle heure, sur quel critère, en croisant Slack, mail, terminal, ticket et mémoire. Cette phase absorbe la moitié du temps d'un post-mortem sérieux, et c'est aussi la phase où l'on perd le plus de précision, parce que les décisions les moins tracées sont souvent les plus intéressantes.

Le point de bascule dans ARTEFACT est structurel. La timeline s'écrit pendant l'investigation, pas après. Chaque étape du smart playbook date sa décision, cite son critère, enregistre les pivots. Quand le RETEX s'ouvre, la reconstitution est déjà faite. Les faits ne sont plus discutés, seulement les décisions. Le temps gagné se convertit en modifications réelles, parce que l'équipe n'est plus épuisée par la reconstitution au moment de trancher.

Vous pouvez appliquer cette discipline dès votre prochain incident, sans changer d'outil.

1. Écrivez la timeline de l'incident au fil de l'investigation, pas après. Un canal dédié, un pad partagé, peu importe le support. Ce qui compte est que chaque décision soit datée et attribuée au moment où elle est prise.
2. Au RETEX, jetez la chronologie exhaustive. Extrayez les cinq à dix décisions qui ont structuré l'incident et posez sur chacune les trois questions.
3. Sortez du RETEX avec trois modifications au plus, chacune avec un responsable et une date. Fermez-les en revue mensuelle.
4. Trois mois plus tard, vérifiez que les trois modifications ont produit un effet. Sinon, c'est le mécanisme de RETEX lui-même qu'il faut modifier, avant les gens qui l'ont appliqué.

C'est la même mécanique que nous appliquons dans notre labo pour améliorer les playbooks ARTEFACT. Chaque incident réel accompagné nous apprend quelque chose, et cette leçon modifie la trame avant l'incident suivant. La boucle est simple à décrire (incident, RETEX court, modification tracée, incident suivant qui n'est plus le même), et c'est elle qui sépare une méthode vivante d'une procédure musée.