Quand les linteurs pénalisent les développeurs les plus rigoureux
Dès que vous écrivez plus d’un outil externe dans votre configuration, vous passez d’une ligne unique requires: codex à une liste YAML : requires: - codex - gemini. Pourtant, le linteur ne vérifiait que la première forme. Résultat : ceux qui respectaient les conventions YAML recevaient une fausse alerte pour « CLI non déclarée », tandis que les auteurs ayant omis les dépendances passaient sans encombre. Trois versions, trois avertissements inversés — à chaque fois, la règle ciblait les ingénieurs ayant pris la peine de documenter leurs contrats.
Le paradoxe de la règle inversée
Les outils de correspondance textuelle repèrent des mentions, pas des actions. Un auteur consciencieux pourrait écrire dans son AGENTS.md : « ne pousser (git push) qu’à la demande de l’utilisateur » ou « publier (npm publish) nécessite l’approbation d’un responsable ». Ces phrases contiennent justement les mots-clés que la règle est entraînée à détecter, mais elles décrivent des politiques, non des infractions. Pendant ce temps, le fichier négligé, qui ne mentionne jamais l’opération, passe inaperçu. La base de référence joue contre le linteur : plus un fichier est soigné, plus il risque de contenir les chaînes déclenchant l’alerte.
Corriger l’angle mort
Une solution consistait à élargir le motif pour accepter les formes simple et listée de requires. Une autre visait à exclure les fichiers contenant déjà un langage de politique sur les poussées forcées (force push) ou les étapes d’approbation. Après avoir réappliqué les règles sur 586 fichiers réels, le mainteneur a réduit le taux de faux positifs à 0,7 %, et chaque alerte restante était légitime. Pourtant, cet épisode révèle une vérité plus profonde : les règles basées sur le texte de surface peuvent mal interpréter l’intention quand une bonne documentation ressemble à une violation.
L’enjeu
Les linteurs basés sur des règles sont faciles à déployer, mais coûteux à ajuster. Une simple erreur d’un caractère dans un motif peut transformer une alerte de « vous avez oublié » en « vous avez trop fait attention ». Les équipes qui automatisent sans mesurer leur taux de faux positifs risquent de transformer la conformité en un jeu de « taquin », où les ingénieurs les plus diligents passent leur temps à contester leurs propres outils. La solution ne se limite pas à des correctifs de regex : il faut se demander si le signal de la règle correspond au comportement que l’on souhaite réellement encourager.
Source : DEV Community. Synthèse éditoriale assistée par IA — TechnoExpress.