Résumé technique : Vers une analyse d'impact à ensemencement sémantique et à propagation par graphe à travers les artefacts logiciels

Énoncé du problème

Les ingénieurs logiciels sont confrontés à des défis importants en matière d'Analyse d'Impact de Changement (CIA - Change Impact Analysis) lorsqu'un artefact unique (par exemple, une exigence, une configuration ou une fonction) est modifié. Les outils existants reposent généralement sur l'un des deux signaux isolés suivants, chacun possédant un « angle mort » caractéristique :

1. Approches de Sémantique / Recherche d'Information (IR) : Elles reposent sur la similitude textuelle (ex: plongements de mots/embeddings, modèles d'espace vectoriel) pour lier les artefacts. Bien qu'elles traversent librement les types d'artefacts, elles échouent à détecter les impacts là où le texte ne partage aucun vocabulaire avec le changement (ex: un changement d'exigence concernant un « timeout » qui impacte une fonction nommée completeOrder sans mentionner de « timeout »).
2. Approches Structurelles / de Dépendance : Elles suivent des arêtes explicites (graphes d'appels, flux de données, invocation de tests). Bien qu'elles soient précises là où les arêtes existent, elles manquent les relations de niveau sémantique non encodées sous forme d'arêtes et échouent souvent à couvrir la chaîne complète de l'Exigence → Config → Service → Test, particulièrement pour les artefacts opérationnels comme les images de conteneurs, les métriques et les schémas de bases de données.

L'article soutient qu'une analyse purement structurelle manque les impacts sur les artefacts opérationnels (ex: une mise à jour d'image de base cassant des services, un renommage de métrique désactivant des alertes) car aucune arête au niveau du code ne les connecte au changement. Inversement, une analyse purement sémantique manque les impacts qui sont structurellement dépendants mais lexicalement distincts.

Méthodologie

Les auteurs proposent un analyseur interprétable et sans entraînement qui fusionne les signaux sémantiques et structurels sur un graphe d'artefacts hétérogène. L'innovation centrale réside dans l'utilisation du concept de « mêmes embeddings, couche de raisonnement différente ».

1. Graphe d'artefacts hétérogène

Le système modélise l'écosystème logiciel comme un graphe typé comprenant des types de nœuds tels que les Exigences (R), les Configurations (C), les Services/Fonctions (S), les Tests (T) et les artefacts opérationnels (Images, Métriques, Alertes, Schémas de Données).

• Arêtes : Récupérées automatiquement via l'analyse statique (ex: AST Python) ou l'analyse de manifestes.
  • Arêtes sources : R→C, C→S, S→S, T→S.
  • Arêtes opérationnelles : Image→Service, Service→Métrique, Métrique→Alerte, Service→Données.
• Direction de propagation : Les arêtes sont inversées pour la propagation de l'impact (ex: un changement dans un appelé impacte ses appelants ; un changement de service impacte ses tests).

2. Double couche de scoring

Le score d'impact pour tout artefact est un mélange pondéré de deux couches :

• Couche 1 : Priorité Sémantique ($s$)

  • Calcule la similitude cosinus entre le texte de chaque artefact et l'artefact modifié.
  • Prend en charge des backends interchangeables : TF-IDF ou embeddings denses (ex: Sentence-BERT).
  • Capture les relations de niveau de sens même sans arêtes structurelles.

• Couche 2 : Propagation Structurelle ($p$)

  • Calcule la propagation de l'impact sur le graphe typé en utilisant une matrice de propagation normalisée par ligne $M$.
  • Utilise un mécanisme de décroissance multi-sauts (inspiré de la centralité de Katz et de PageRank) :
    $$p = \sum_{k=1}^{K} \gamma^k (e_c M^k)$$
    Où $e_c$ est l'artefact modifié, $\gamma$ est le facteur de décroissance, et $K$ est l'horizon.
  • Capture les chaînes de dépendances explicites.

3. Fusion

Le score d'impact final est une combinaison linéaire contrôlée par un seul poids ajustable $\lambda$ :
$$\text{impact} = \lambda s + (1 - \lambda) p$$

• $\lambda=1$ : Baseline sémantique pure.
• $\lambda=0$ : Analyseur structurel pur.
• $\lambda \in (0,1)$ : Un mélange qui contrôle explicitement le compromis précision/rappel.
• Interprétabilité : Chaque artefact signalé inclut une explication explicite : son score sémantique, son score structurel et le chemin de propagation spécifique emprunté.

Évaluation de la Preuve de Concept

Les auteurs ont évalué l'approche sur un petit sous-système de paiement complet composé de 13 artefacts (3 exigences, 3 configurations, 4 services, 3 tests) et 14 arêtes typées, à travers 5 scénarios de changement étiquetés.

Principales conclusions :

1. Couverture des angles morts : La fusion est la seule configuration qui couvre les deux angles morts.
   • Angle mort sémantique : Les artefacts ayant une superposition textuelle nulle (ex: completeOrder vs une exigence de « timeout ») ont été récupérés uniquement par la propagation structurelle.
   • Angle mort structurel : Les fonctions auxiliaires (ex: loadConfig) qui ne sont pas en aval dans le graphe d'appels mais qui sont sémantiquement liées ont été récupérées uniquement par la couche sémantique.
2. Performance :
   • Structurel pur ($\lambda=0$) : A atteint une haute précision (0,927) mais a manqué environ 21 % des impacts réels (Rappel 0,786) en raison des fonctions auxiliaires manquantes.
   • Sémantique pur ($\lambda=1$) : A atteint un haut rappel (0,873) mais une faible précision (0,417) en raison des faux positifs.
   • Le mélange proposé ($\lambda=0,5$) : A atteint un rappel parfait (1,000) sur tous les scénarios, capturant tous les artefacts impactés de vérité terrain, avec un score F1 légèrement amélioré (0,589) par rapport à la baseline sémantique.
3. Limites du benchmark : Les auteurs notent que le F1 élevé de l'approche purement structurelle est un artefact de ce petit graphe synthétique où la plupart des impacts réels sont atteignables par des arêtes. La contribution principale est la couverture au niveau du mécanisme, et non une affirmation de généralisation de l'exactitude.

Signification et Revendications

Le papier positionne ce travail comme un point spécifique et sous-occupé dans l'espace de conception de l'analyse d'impact :

• Sans entraînement et déterministe : Contrairement aux réseaux de neurones sur graphes (GNN) ou aux approches GraphRAG qui nécessitent des données d'entraînement ou des appels de LLM coûteux et non déterministes, cette approche utilise des règles de propagation fixes et des embeddings explicites.
• Explicable : Elle émet un chemin de propagation vérifiable pour chaque artefact signalé, ce qui la rend adaptée aux contextes d'audit et de sécurité critique.
• Portée opérationnelle : Elle étend l'analyse d'impact au-delà du code source vers les artefacts opérationnels (images, métriques, schémas) où l'analyse de code seule échoue, traitant des modes de défaillance réels comme les mises à jour d'images de base et les renommages de métriques.

Les auteurs déclarent explicitement que les chiffres du prototype sont illustratifs du mécanisme, et non une revendication de généralisation. La contribution est la conception d'une architecture de fusion qui récupère des artefacts invisibles pour un seul signal, fournissant une base pour des travaux futurs sur la propagation apprise, la vérification par LLM et le déploiement à grande échelle entre services.