developer.wordpress.org rappelle qu’un hook mal utilisé peut introduire une faille de sécurité sans qu’aucun symptôme visible n’apparaisse immédiatement. C’est en partant de ce principe qu’un pipeline de conformité avait été mis en place, avec des contrôles automatiques bloquant toute fusion de code jugée à risque : appels de fonctions dépréciées, requêtes SQL non préparées, absence d’échappement sur les sorties. Sur le papier, une bonne pratique. Dans les faits, ce pipeline a fini par être contourné systématiquement par l’équipe elle-même, l’effet exactement inverse de celui recherché au départ.
Ce texte reprend les antipatterns identifiés dans la conception de ce pipeline, pourquoi ils ont progressivement sapé la confiance de l’équipe, et ce qui a été reconstruit pour retrouver un contrôle réellement suivi plutôt que systématiquement ignoré.
Ce qu’on voit : un taux de faux positifs qui dépasse celui des vrais problèmes
Sur une période de trois mois, une analyse rétrospective des échecs du pipeline a montré que 73 % des blocages correspondaient à des faux positifs : des motifs de code légitimes mal interprétés par les règles d’analyse statique, plutôt que de réelles failles de sécurité. Un exemple récurrent : une règle bloquait systématiquement toute concaténation de chaîne dans une requête SQL, y compris quand cette concaténation portait uniquement sur un nom de table validé en amont par une liste blanche, un cas légitime que la règle ne savait pas distinguer d’une injection réelle.
Pourquoi c’est un problème : quand la majorité des blocages ne correspond à aucun risque réel, l’équipe apprend rapidement à ne plus faire confiance au signal envoyé par le pipeline, quel que soit le blocage rencontré.
Ce qu’on voit : un contournement devenu réflexe plutôt qu’exception
Face à la fréquence des faux positifs, plusieurs développeurs avaient pris l’habitude d’ajouter un commentaire d’exclusion générique au-dessus de la ligne bloquée, sans analyser si le blocage était réellement injustifié ou s’il signalait un vrai problème. Ce réflexe, compréhensible individuellement face à un contrôle jugé peu fiable, a fini par vider le pipeline de sa fonction protectrice : sur un audit du code source, plus d’une centaine de ces exclusions étaient présentes, dont plusieurs masquaient effectivement des requêtes non préparées légitimement problématiques.
Pourquoi c’est un problème : un contrôle contourné silencieusement, sans processus de validation, ne protège plus rien tout en donnant l’illusion rassurante qu’une protection existe toujours.
Ce qu’on voit : aucune distinction entre gravité des blocages
Le pipeline traitait chaque type de blocage de la même façon : un appel à une fonction dépréciée bloquait la fusion exactement comme une requête SQL potentiellement vulnérable à une injection, alors que ces deux problèmes n’appellent ni la même urgence ni le même niveau de rigueur.
Pourquoi c’est un problème : mélanger tous les niveaux de gravité dans un seul mécanisme de blocage binaire encourage l’équipe à traiter les alertes sérieuses avec la même désinvolture que les alertes mineures, faute de pouvoir les distinguer rapidement.
Quoi faire : ce qui a été reconstruit
- Distinction explicite entre blocages critiques (fusion impossible sans validation manuelle) et avertissements informatifs (visibles, non bloquants)
- Revue trimestrielle des règles d’analyse statique pour ajuster celles générant le plus de faux positifs
- Suppression des exclusions génériques au profit de justifications explicites, revues en pull request par un second développeur
- Mesure continue du taux de faux positifs comme indicateur de santé du pipeline lui-même
Ce que cette reconstruction a changé concrètement
Trois mois après la refonte, le taux de faux positifs mesuré est redescendu sous la barre des 15 %, et le nombre d’exclusions génériques présentes dans le code source a été divisé par plus de dix, chaque exclusion restante étant désormais accompagnée d’une justification explicite relue par un pair. L’équipe a recommencé à traiter les blocages du pipeline comme des signaux dignes de confiance plutôt que comme un obstacle systématique à contourner.
Un contrôle de conformité que personne ne respecte n’est pas un contrôle trop strict, c’est un contrôle mal calibré qu’il faut revoir.
En résumé
Un pipeline de conformité conçu sans distinction de gravité ni tolérance aux faux positifs finit presque toujours par être contourné par l’équipe qu’il est censé protéger, silencieusement et sans alerte. Rétablir la confiance a demandé de réduire le bruit, de hiérarchiser les blocages et d’accepter que certaines règles initialement jugées indiscutables devaient être révisées.
