sem : comprendre les changements de code par entités plutôt que par lignes

https://ataraxy-labs.github.io/sem/

https://github.com/Ataraxy-Labs/sem

📌 sem remplace la lecture fatigante des diffs ligne par ligne par une vue orientée entités de code. Au lieu de parcourir des blocs de texte pour deviner l’impact d’un commit, l’outil affiche directement ce qui a été ajouté, modifié, supprimé, renommé ou déplacé au niveau fonctions, classes, types, propriétés et sections structurées. Le résultat est plus rapide à relire, plus clair à partager, et surtout plus exploitable dans un flux quotidien où les changements s’enchaînent vite.

Le premier bénéfice concret apparaît dès la commande sem diff. Dans un dépôt classique, un diff Git peut devenir verbeux sur des fichiers longs, des refactors ou des changements de formatage. sem réduit ce bruit et expose la nature métier de la modification: une fonction d’authentification change, une propriété de configuration passe de 5 à 20, une section du fichier de config est déplacée. Cette granularité évite de surinterpréter des changements cosmétiques et aide à prioriser les revues qui méritent une vraie attention.

Au quotidien, ce fonctionnement simplifie trois scénarios fréquents. Le premier est la revue de PR: au lieu d’ouvrir chaque fichier et de scroller, on identifie immédiatement les zones réellement touchées. Le deuxième est l’analyse d’incident: lorsqu’un bug apparaît après plusieurs commits, la vue entité permet de remonter plus vite vers les changements potentiellement responsables. Le troisième est la coordination entre plusieurs personnes: il devient plus simple d’expliquer “ce qui a changé” en termes compréhensibles, sans exposer tout le patch brut.

sem fonctionne dans n’importe quel dépôt Git sans phase de configuration initiale. On peut l’utiliser sur les changements en cours, sur le staging, sur un commit précis ou sur une plage de commits. Il propose aussi une sortie JSON adaptée à l’automatisation, ce qui ouvre la porte à des intégrations CI et à des agents qui doivent raisonner sur des changements structurés. Cette sortie est utile pour déclencher des contrôles ciblés, produire des rapports de changement, ou alimenter des outils internes de suivi qualité.

points cles

• ⚡ Lecture accélérée des changements: diff orienté fonctions, classes, propriétés et sections.
• 🧠 Moins de bruit: distinction plus nette entre logique modifiée et simple formatage.
• 🔁 Détection de renommages et déplacements: utile pour les refactors réels.
• 🤖 Sortie JSON: intégration directe dans CI, pipelines internes et agents IA.
• 🌍 Couverture large: langages de code + formats structurés comme JSON/YAML/TOML/CSV/Markdown.
• 🛠️ Démarrage simple: exécutable en local dans un repo Git, sans configuration lourde.

La compatibilité fait partie des points forts du projet. sem extrait des entités sur treize langages de programmation via tree-sitter, avec un fallback sur les formats non pris en charge. En pratique, cela couvre TypeScript, JavaScript, Python, Go, Rust, Java, C, C++, C#, Ruby, PHP et Fortran, puis des formats de données comme JSON, YAML, TOML, CSV et Markdown. Cette diversité en fait un outil transversal pour des dépôts polyglottes, où les changements ne se limitent pas au code applicatif.

Le moteur de correspondance en trois phases renforce la pertinence de la sortie. Une correspondance exacte d’identifiant détecte les entités inchangées ou modifiées. Un hash structurel identifie des renommages et déplacements quand la structure logique reste similaire. Une similarité floue complète l’analyse lorsque le code évolue davantage. Ce mécanisme évite de classer à tort un refactor comme une suppression puis recréation, et améliore la lisibilité historique d’un projet.

Côté exécution, l’usage principal est local en CLI. L’installation peut se faire par compilation Rust (cargo install --path sem-cli) ou via binaire depuis les releases. Il n’y a pas d’offre cloud imposée ni de service distant obligatoire pour traiter les diffs de base. Cette approche locale est un avantage net pour la confidentialité: le code reste dans l’environnement de travail, ce qui facilite l’adoption dans des contextes où les données ne doivent pas sortir du poste ou de l’infrastructure interne.

Sur le plan technique, le projet s’appuie notamment sur tree-sitter pour l’analyse syntaxique, git2 pour les opérations Git, rayon pour le traitement parallèle des fichiers et xxhash pour le hachage structurel. Cette architecture vise un bon compromis entre précision sémantique et performance, y compris sur des historiques volumineux. Pour des bases de code importantes, la possibilité de filtrer par extensions ou d’analyser une plage de commits aide à garder des temps de traitement raisonnables.

Pour démarrer rapidement, le parcours est direct: cloner le dépôt, installer l’outil, se placer dans un repo et lancer sem diff. Ensuite, ajouter --staged, --commit ou --from/--to selon le besoin. Pour des workflows automatiques, activer --format json et brancher la sortie sur les étapes de pipeline. Les commandes sem graph, sem impact et sem blame complètent la boîte à outils pour explorer les dépendances, anticiper les effets d’un changement et attribuer l’historique d’une entité.

Au final, sem est particulièrement pertinent pour les projets où le volume de changements rend les diffs textuels difficiles à exploiter. Le positionnement “semantic version control” n’est pas un slogan cosmétique: il modifie réellement la façon de lire, discuter et automatiser les évolutions du code, avec une approche locale compatible avec les exigences de confidentialité et les workflows d’ingénierie modernes.