Commencez par les erreurs coûteuses
Un linter peut contrôler des milliers de phrases en quelques secondes, ce qui donne envie d’encoder chaque préférence éditoriale. Résistez. Commencez par les mauvais noms de produit, la terminologie incohérente, les formulations risquées, les avertissements ambigus et les erreurs de format répétitives.
Si le premier passage produit des centaines d’avertissements mineurs, l’équipe apprendra à ignorer l’outil.
Traitez les règles comme du code
Stockez la configuration Vale et les vocabulaires dans le dépôt, faites relire leurs changements et nommez les règles selon leur intention. ApprovedProductNames est plus facile à discuter que RegexRule17.
Conservez quelques fixtures qui doivent passer ou échouer afin d’éviter les régressions.
Séparez erreurs et conseils
Bloquez le build seulement pour les problèmes que l’équipe considère réellement obligatoires à corriger. Utilisez des warnings quand un jugement éditorial est nécessaire. Le CI reste ainsi prévisible.
Soignez la terminologie
C’est souvent là que le retour est le plus rapide. Centralisez noms approuvés, capitalisation et remplacements. Ajoutez des exceptions explicites plutôt que de désactiver des règles utiles globalement.
Les faux positifs sont eux aussi des signaux : parfois la règle est mauvaise, parfois le modèle de contenu rend la cohérence difficile.
L’édition humaine reste humaine
Vale ne sait pas si une explication répond à la bonne question ni si un exemple enseigne le bon modèle mental. Automatisez les défauts répétitifs et réservez l’attention humaine à la structure, aux preuves et à la clarté.
Un bon quality gate est presque ennuyeux : il détecte toujours les mêmes problèmes importants et surprend rarement l’auteur.
Exemple pratique
Traitez « Utiliser Vale comme quality gate, pas comme police de la ponctuation » comme une petite évaluation et non comme une comparaison de listes de fonctions. Choisissez trois contenus réels : une page simple, une page avec code ou données structurées et une page difficile avec navigation, réutilisation ou localisation. Testez-les et notez ce qui devient plus simple ainsi que le nouveau coût de maintenance.
Évaluez le travail répété de l’équipe :
- la source est-elle compréhensible pour l’auteur ;
- le relecteur voit-il un diff significatif ;
- un échec de build indique-t-il un problème corrigeable ;
- le contenu peut-il être déplacé, localisé ou réutilisé sans nettoyage manuel.
Un bon outil réduit l’incertitude lors de l’écriture, de la revue et de la publication. Si la complexité se déplace simplement vers une configuration fragile, des plugins ou la mémoire d’une seule personne, ce coût fait partie du choix.
Checklist éditorial rapide
- Commencez par les erreurs coûteuses. Un linter peut contrôler des milliers de phrases en quelques secondes, ce qui donne envie d’encoder chaque préférence éditoriale.
- Traitez les règles comme du code. Stockez la configuration Vale et les vocabulaires dans le dépôt, faites relire leurs changements et nommez les règles selon leur intention.
- Séparez erreurs et conseils. Bloquez le build seulement pour les problèmes que l’équipe considère réellement obligatoires à corriger.
- Soignez la terminologie. C’est souvent là que le retour est le plus rapide.
