Plugin SonarQube pour assembleur industriel propriétaire

Contexte

Le système cible utilise un assembleur propriétaire bas niveau, spécifique à son architecture matérielle. La compilation de ce code peut durer plusieurs heures sur des projets volumineux : une erreur de syntaxe ou un défaut de codage détecté seulement à cette étape coûte donc un temps de cycle important. L’objectif de ce plugin Sonarqube est de déplacer cette détection en amont, dans SonarQube, avant compilation.

Contraintes techniques

Le moteur hérité (sonar-cxx) est pensé pour un langage aussi riche que le C++, avec préprocesseur, macros et templates — l’assembleur cible est nettement plus contraint, avec son propre jeu d’instructions et sa propre grammaire, ce qui interdit une simple réutilisation telle quelle.

Le plugin doit distinguer, dans le cycle de vie réel des fichiers du projet analysé, les fichiers sources des sorties de compilation, et exclure explicitement les artefacts binaires compilés, non pertinents pour une analyse statique. Il doit aussi rester rapide y compris sur des projets volumineux, pour ne pas ralentir le pipeline CI/CD dans lequel il s’intègre.

Démarche

Plutôt que reconstruire un moteur d’analyse statique à partir de zéro, le plugin s’appuie sur sonar-cxx, plugin open-source mature et reconnu pour l’analyse de langages compilés bas niveau (C/C++), utilisé comme base architecturale. J’ai étudié ce qui devait être conservé, adapté, ou supprimé, sur une architecture Maven multi-module avec séparation claire des responsabilités : règles de qualité, sensors d’analyse et d’import de rapports, infrastructure d’analyse lexicale et syntaxique, module d’assemblage du plugin.

L’adaptation au langage cible a consisté à simplifier le moteur hérité pour correspondre à l’assembleur cible : lexer, grammaire et jeu d’instructions propres au langage cible, ensemble de règles Sonar dédiées en remplacement des règles C/C++ d’origine.

La démarche s’est appuyée sur une matrice d’exigence reliant chaque exigence fonctionnelle, technique et qualité à son état d’implémentation réel et aux preuves associées (fichiers, tests), et sur une roadmap technique par phases, vérifiable par des jalons explicites, plutôt qu’un développement non structuré.

Le cœur de cette adaptation touche les trois étages classiques d’un analyseur statique : l’analyse lexicale, l’analyse syntaxique, puis la construction d’un arbre exploité par les règles Sonar. À titre d’illustration générique — pas la syntaxe réelle, propriétaire, de l’assembleur cible — sur une instruction du type MOV R1, #5 (déplacer la valeur immédiate 5 dans le registre R1) :

Le lexer découpe le texte source en tokens typés (mnémonique, registre, séparateur, valeur immédiate), sans encore en interpréter la structure.

Le parser organise ensuite ce flux selon la grammaire du langage cible, en un arbre de dérivation qui reflète fidèlement chaque règle grammaticale — y compris les éléments purement syntaxiques, comme la virgule séparant les deux opérandes.

Les règles Sonar, elles, n’exploitent pas cet arbre de dérivation directement : elles parcourent un arbre syntaxique abstrait (AST), simplifié pour ne garder que la structure sémantique — la virgule a disparu, remplacée par une distinction explicite entre opérande de destination et opérande source.

Réalisations

• Analyse statique dédiée

  Détection de bugs, de vulnérabilités et de problèmes de qualité via des règles spécifiques à l’assembleur cible.

• Cycle de vie réel des fichiers

  Distinction sources / sorties de compilation, exclusion explicite des artefacts binaires compilés.

• Intégration SonarQube CE complète

  Déclaration du langage, remontée des issues et métriques, profil de qualité dédié.

• Performance en CI/CD

  Conçu pour rester rapide y compris sur des projets volumineux, sans ralentir le pipeline.