Nous avons créé un linter de conventions de code basé sur les LLM.
(github.com/DevSymphony)Bonjour ! Nous sommes Symphony, une équipe d’étudiants universitaires qui développe sym-cli.
Utilisez-vous souvent ces derniers temps des outils comme Cursor ou Claude Code pour faire du vibe coding ? Notre équipe aussi exploite activement les LLM dans le processus de développement. Mais à l’usage, un point nous a déçus.
Le code généré par l’IA fonctionne bien sur le plan fonctionnel, mais il ignore sans cesse les conventions propres à notre équipe (nomenclature des variables, style des commentaires, règles d’utilisation de certaines bibliothèques, etc.). Écrire les règles dans le prompt à chaque fois est fastidieux, et à force on finit aussi par oublier progressivement les conventions elles-mêmes.
C’est ainsi qu’en nous demandant : « Ne pourrait-on pas faire en sorte que le LLM vérifie lui-même les conventions avant d’écrire le code, ou pendant qu’il l’écrit ? », nous avons commencé à créer sym-cli.
[sym-cli, qu’est-ce que c’est ?]
sym-cli est un linter de conventions de code basé sur des politiques pour les outils de codage IA. Son point clé est qu’il communique directement avec le LLM en s’appuyant sur MCP.
Voici ce qui le différencie des linters existants.
- (Configuration en langage naturel) Au lieu d’un fichier de configuration complexe, vous définissez des règles en langage naturel, comme « n’écris jamais de log avec
print», et le LLM les comprend puis les suit. - (Optimisation du contexte) Le LLM ne lit pas toutes les règles du projet : via les outils MCP, il ne récupère intelligemment que les règles nécessaires à la tâche en cours.
- (Vérification proactive) Grâce à l’outil
validate_code, le LLM peut vérifier lui-même, juste après avoir généré le code, s’il respecte bien les règles.
[Comment cela fonctionne-t-il ?]
Après avoir téléchargé la commande sym, exécutez la commande sym init : la configuration du serveur MCP est alors mise en place automatiquement, et les IDE compatibles MCP (comme Cursor) ou les outils LLM commencent immédiatement à se référer à ces règles.
[Nous aimerions avoir vos retours !]
Nous sommes encore une équipe d’étudiants, et le projet n’en est qu’à ses débuts, à un stade très initial où l’ossature vient tout juste d’être posée. Il nous manque encore beaucoup de choses et il peut y avoir des bugs. Mais nous avons vraiment besoin du soutien et des retours de développeurs en activité ou de personnes très intéressées par les outils LLM.
Que ce soit « ce serait bien d’avoir cette fonctionnalité », « cette partie semble poser un problème structurel », « dans un vrai contexte métier, on l’utilise plutôt comme ça », nous accueillerons avec reconnaissance tous les avis. Comme c’est un projet open source, toute contribution ou GitHub Star représente un immense soutien pour notre équipe !
GitHub Repository: https://github.com/DevSymphony/sym-cli
npm: npm install -g @dev-symphony/sym
Merci de nous avoir lus.
7 commentaires
Si vous utilisez opencode, vous pouvez même intégrer la fonctionnalité de lint dans votre workflow.
https://fr.news.hada.io/topic?id=21883
https://opencode.ai/docs/formatters/
Je suis d’accord. Pour les éléments qu’on peut détecter immédiatement, comme les erreurs de syntaxe ou de typage, l’étape LSP ou de compilation est la plus efficace, et je pense aussi que c’est la bonne approche en termes de consommation de tokens. De notre côté, nous voyons moins le LLM comme un remplacement que comme un moyen de connecter automatiquement des règles rédigées en langage naturel aux workflows existants de lint/test.
Moi aussi, comme t7vonn, je pense qu’il est préférable d’appliquer les conventions avec des outils d’automatisation.
En revanche, la fonction LSP fait une vraie différence : comme elle permet de repérer immédiatement des erreurs de syntaxe qu’il faudrait autrement détecter en lançant des tests ou une compilation, la consommation de tokens diminue.
Je donne déjà au PR review agent la documentation des conventions et le diff pour qu’il repère ce qui manque… et je pense que je n’irai pas plus loin que ça.
Je joins un article de quelqu’un qui a un avis proche du mien.
Je pense que la manière d’utilisation que vous avez mentionnée est, pour l’instant, l’approche la plus réaliste. Le problème que nous voulons résoudre consiste à réduire le processus qui consiste à fournir le document de conventions à chaque PR, et à transformer à l’avance les règles définies en langage naturel en règles de linting et de validation afin qu’elles s’exécutent automatiquement à l’étape PR/CI.
Hum... on dirait qu’on pourrait aussi faire ça avec une fonctionnalité du genre hooks/subagents/skills de Claude...
Techniquement, cela semble aussi possible avec des hooks ou un subagent, mais nous avons choisi de placer une couche légère au-dessus de MCP et du workflow de linting existant afin de ne pas dépendre d’un LLM spécifique. Nous nous concentrons donc moins sur les fonctions d’agent que sur la transformation des conventions en une infrastructure réutilisable.