La plupart des équipes vivent la conformité comme une saison. Elle arrive, tout le monde abandonne sa feuille de route, un tableau circule, des captures d'écran sont collectées, et quelques semaines plus tard, elle disparaît jusqu'à la prochaine fois. Le travail est réel, mais la forme est incorrecte.
Les événements créent la panique ; les vérifications créent des habitudes
Tout ce qui se produit deux fois par an est un événement, et les événements génèrent de la panique, car l'intervalle entre eux est exactement assez long pour oublier tout ce que vous avez appris la dernière fois. L'audit devient une session de révision intensive face à des mois de dérive accumulée que personne ne surveillait.
Tout ce qui s'exécute à chaque pull request est une vérification. Les vérifications ne génèrent pas de panique. Elles génèrent de petites corrections constantes, de la même manière qu'un test échoué. Vous n'organisez pas d'exercice d'urgence trimestriel pour les tests ; les tests s'exécutent à chaque modification, donc le code reste proche de la correction en permanence. La conformité peut fonctionner de la même manière.
La taxe de l'exercice d'urgence est payée dans la pire monnaie : la concentration
Le vrai coût de la saison d'audit n'est pas le nombre d'heures. C'est le changement de contexte. Une équipe en pleine résolution d'un problème complexe est détournée pour collecter des preuves de modifications effectuées des mois plus tôt, puis doit se replonger dans le problème ensuite. Cette taxe est invisible dans tout budget et énorme en pratique.
Une vérification qui s'exécute en continu répartit ce coût en incréments si petits qu'ils disparaissent. Une observation sur une PR est lue dans le même état d'esprit que la revue de code dans laquelle elle se trouve. Pas de saison, pas de révision intensive, pas de changement de contexte.
Rendez-la ennuyeuse
L'objectif n'est pas de rendre la conformité passionnante. C'est de la rendre ennuyeuse : une vérification d'état qui est généralement verte, signale occasionnellement quelque chose de spécifique, et laisse bien moins à découvrir lors de la saison d'audit, car la plupart des problèmes ont été traités au niveau du diff.
heygrc publie un statut de vérification GitHub sur chaque pull request, basé sur les cadres que vous avez sélectionnés, que vous pouvez éventuellement exiger dans la protection de branche. L'objectif d'une vérification est d'être anodine. Cet état stable et ennuyeux est ce pour quoi heygrc a été conçu.