← Networkit Tutos
Capsule sonore — résumé audio de l'article sur image fixe.

Sem : Nouvelle primitive pour la compréhension du code par entités Git

Ce nouvel approche par les entités Git vise à améliorer la compréhension sémantique du code, offrant une alternative aux Language Server Protocols (LSPs) traditionnels pour les outils d'IA et d'analyse. Cet article décrypte cette évolution technique et ses implications pour les architectes et développeurs.

En bref

Contexte

L'augmentation exponentielle de la complexité des dépôts de code (monorepos, projets multi-langages) pose un défi majeur aux outils d'aide à la décision, notamment ceux basés sur l'Intelligence Artificielle (IA). Les Language Server Protocols (LSPs) ont longtemps été la norme pour fournir une compréhension contextuelle fine du code lors de l'édition. Cependant, les LSPs se concentrent principalement sur la structure syntaxique et la typographie locale.

L'émergence de modèles de langage (LLMs) nécessite une compréhension plus large et contextuelle, allant au-delà de la simple syntaxe. Il faut comprendre comment les morceaux de code interagissent au sein d'un système de contrôle de version. L'approche présentée par Sem propose une rupture en se focalisant sur les entités du dépôt Git. Il ne s'agit plus seulement de savoir ce que signifie une ligne de code isolée, mais de comprendre le contexte de l'entité (commit, fichier, branche, dépendance) dans l'historique du projet.

Cette évolution est cruciale pour les entreprises qui intègrent l'IA dans leur cycle de développement (DevOps/DevSecOps). Les acteurs comme GitHub, GitLab et les fournisseurs de solutions d'analyse de code cherchent des moyens d'alimenter leurs modèles avec des informations structurelles riches et historisées, ce que l'approche basée sur les entités Git promet de fournir de manière plus robuste que les méthodes traditionnelles.

Détails techniques

Le cœur de la proposition de Sem réside dans le changement de paradigme de l'analyse du code. Au lieu de dépendre uniquement des informations fournies par un LSP (qui se concentre sur l'API du langage), Sem modélise le code comme un ensemble d'entités structurées au sein de l'historique Git.

De la syntaxe à l'entité Git

L'approche se déplace de la compréhension locale (syntaxe, portée) vers la compréhension globale et historique (relations entre fichiers, commits, branches). Les entités clés analysées incluent :

  1. Fichiers et chemins : Identification des modules ou composants.
  2. Commits : Analyse du diff et du contexte de modification associé à un commit spécifique.
  3. Branches et Merges : Compréhension des flux de travail et des dépendances temporelles.
  4. Dépendances (par analyse du graphe de dépendance) : Identification des appels entre différentes entités.

Cette modélisation permet à un modèle d'IA de construire un graphe de connaissance du projet (Project Knowledge Graph) où les nœuds sont des entités Git et les arêtes représentent les relations (ex: "le commit X a modifié le fichier Y, qui dépend du module Z").

Implémentation conceptuelle

Bien que l'article décrive la primitive conceptuelle, l'implémentation concrète nécessite une couche d'extraction et de transformation des données Git brutes (commits, diffs, métadonnées).

Considérons une tâche typique d'analyse : identifier l'impact d'une modification sur un composant critique.

Approche traditionnelle (LSP-centrée) :

Un LSP analyse le fichier actuel et fournit des informations sur les fonctions et les variables.

Approche Sem (Entité-centrée) :

L'outil interroge le dépôt Git pour récupérer l'historique des modifications affectant une certaine fonction.


# Pseudo-code conceptuel pour l'extraction d'entités
def extract_code_entities(repo_path: str, target_function: str) -> list[Entity]:
    # 1. Récupérer tous les commits qui ont touché le fichier contenant target_function
    commits = git_api.get_commits_by_file(repo_path)

    entities = []
    for commit in commits:
        # 2. Analyser le diff de ce commit pour identifier les changements pertinents
        diff = git_api.get_diff(commit.sha)
        
        if target_function in diff:
            # 3. Créer une entité liée au commit et à la modification
            entity = Entity(
                type="CodeChange",
                commit_sha=commit.sha,
                description=f"Modification de {target_function} dans commit {commit.sha[:7]}"
            )
            entities.append(entity)
            
    return entities

# Utilisation : Le LLM reçoit la liste des entités plutôt que le code brut.

Cette sortie structurée (liste d'entités liées à l'historique) est beaucoup plus riche pour entraîner ou guider un LLM, car elle fournit le pourquoi (le contexte historique) en plus du quoi (le code actuel).

Implications pour les consultants IT

L'adoption de primitives basées sur les entités Git modifie fondamentalement la manière dont les équipes IT conçoivent et déploient des solutions d'IA pour le code.

Architecture des outils d'IA

Les consultants doivent désormais évaluer si leurs solutions d'IA sont limitées à l'analyse statique (LSP) ou si elles bénéficient d'une architecture capable d'ingérer et de modéliser l'historique Git. Cela implique de concevoir des pipelines d'ingestion de données qui extraient, normalisent et graphent les métadonnées Git avant de les présenter au modèle. Cela nécessite des compétences en Data Engineering appliquées au code source.

Sécurité et Auditabilité

Pour la sécurité (DevSecOps), cette approche est un atout majeur. La capacité à tracer précisément qui a modifié quoi et quand (via les métadonnées Git) permet d'effectuer des analyses de vulnérabilités beaucoup plus fines. Au lieu de scanner le code statiquement, on peut corréler une vulnérabilité découverte avec les commits spécifiques qui l'ont introduite, facilitant le root cause analysis (RCA) et la conformité réglementaire.

Stratégie de migration technique

Les équipes doivent planifier la migration des outils d'analyse existants. Si une solution d'IA repose actuellement sur une intégration LSP, il faudra évaluer si cette intégration peut être augmentée ou remplacée par un système d'extraction d'entités Git. Cela impacte les choix technologiques, notamment l'intégration des APIs Git et l'utilisation de bases de données orientées graphe (comme Neo4j) pour stocker les relations entre les entités.

Pour aller plus loin