Structurer la revue humaine

Qui valide quoi

Une revue efficace sépare deux rôles, même s'ils sont parfois tenus par la même personne :

• La priorisation — un Tech Lead ou un responsable sécurité juge si le périmètre était le bon et si la sévérité retenue est cohérente avec le contexte réel du projet.
• La revue technique — un reviewer vérifie que le correctif proposé corrige effectivement le problème identifié, sans introduire de régression, et que les tests couvrent le changement.

Confondre les deux rôles dans une seule vérification rapide est une source fréquente d'erreurs : on valide "ça a l'air bon" sans avoir réellement vérifié ni la pertinence métier, ni la correction technique.

Une checklist de revue minimale

• Le correctif corrige-t-il le chemin de code identifié comme vulnérable au module 6, spécifiquement ?
• Les tests existants passent-ils, et un test couvre-t-il le cas corrigé ?
• Y a-t-il un risque de régression sur une fonctionnalité qui dépend du paquet mis à jour ?
• Le changement respecte-t-il les interdictions posées dans le brief initial (module 2) ?

Garder une trace

La décision — verdict d'exposition, correctif retenu, justification du choix — doit rester consultable après coup : dans la description de la PR, ou dans un changelog de sécurité dédié. Ça a l'air anecdotique, jusqu'au jour où quelqu'un demande, six mois plus tard, pourquoi cette version a été choisie plutôt qu'une autre.

Cette trace, c'est aussi ce qui permet d'affiner le brief de la prochaine mission — et donc d'améliorer la méthode elle-même, pas seulement le correctif du jour.