Un LLM s'attaque au refactoring C++ d'OpenBMC : async mono-thread, D-Bus et rustines

Un seul thread, une seule boucle d'événements, un seul bus D-Bus et du code legacy que personne n'ose toucher. C'est sur ce terrain qu'un auteur de Habr a testé la façon dont un assistant IA gère le refactoring de code enterprise réel en C++, dans l'écosystème OpenBMC. L'annonce ne mentionne ni le nom du modèle, ni le volume de code, ni le pourcentage de modifications réussies. En revanche, la mise en situation est plus intéressante que la plupart des démos qui génèrent une application de todo : ici, pas d'exemples pédagogiques, mais du code écrit pendant des années par des personnes différentes.

Qu'est-ce qu'OpenBMC, et pourquoi y a-t-il du sport ?

Un BMC (baseboard management controller) est un petit ordinateur indépendant, installé sur la carte mère d'un serveur. Il surveille l'alimentation, les ventilateurs et les capteurs de température, fournit une console distante et peut reflasher l'hôte même lorsque le système principal est à l'arrêt. OpenBMC est une distribution Linux ouverte pour ces contrôleurs. Le projet est né chez Facebook et, depuis 2018, il se développe sous l'égide de la Linux Foundation, avec la participation de grands fournisseurs de serveurs et de cloud.

Sur le plan architectural, c'est un ensemble de petits démons. Chacun gère sa partie : capteurs, inventaire, journaux, gestion de l'alimentation. Ils communiquent via D-Bus ; ce sont donc, en substance, des microservices, mais sur un SoC à mémoire limitée et au processeur faible. Le langage principal est le C++, généralement avec sdbusplus et Boost.Asio.

Async mono-thread : pratique, mais risqué

Le modèle async single-threaded repose sur un seul thread et une seule boucle d'événements. Toute opération, qu'il s'agisse d'une requête D-Bus, de la lecture d'un capteur ou d'un timer, prend la forme d'un appel asynchrone avec un gestionnaire. L'avantage est évident : pas de data races classiques, pas besoin de saupoudrer le code de mutex. L'inconvénient est tout aussi connu. La logique se transforme en chaînes de lambdas imbriquées, la durée de vie des objets doit être suivie à la main via shared_ptr et captures, et l'ordre d'exécution ne se lit qu'avec un débogueur à la main.

C'est précisément ce type de code que l'on a demandé à l'IA de remettre en ordre. Le test de résistance est pertinent. Un modèle de langage repère très bien les motifs locaux, mais la correction dépend ici souvent d'éléments implicites : qui possède l'objet, quand le callback se déclenche, ce qui se passe si le service redémarre au milieu d'une requête.

Ce qui est réellement testé

L'auteur pose deux questions : l'IA est-elle capable de mener un refactoring, et sur quels points est-elle, pour l'instant, sans appel inférieure à l'humain ? L'annonce permet de reconstituer le cadre de l'expérience :

• Plateforme : OpenBMC, systèmes embarqués, contrôleurs de gestion de serveurs.
• Langage : C++ dans un vrai projet enterprise, avec un code surchargé et confus.
• Modèle d'exécution : asynchrone, mono-thread, sur boucle d'événements.
• Transport entre services : D-Bus.
• Tâche confiée à l'IA : refactoring d'un fragment de code choisi.
• Non précisé dans l'annonce : le modèle, l'outil, le volume de code, les métriques chiffrées et les résultats des tests.

Le dernier point est important. Tant que le texte complet n'est pas disponible, on ne peut tirer aucune conclusion sur la force ou la faiblesse de l'IA. La « douleur » et les « rustines » évoqués laissent plutôt penser que le résultat sera mitigé.

Comment mettre cette expérience en pratique

Si vous comptez confier à une IA le refactoring de code embarqué ou asynchrone, quelques règles valent quel que soit le modèle choisi.

1. Les tests d'abord, les modifications ensuite. Sans batterie de vérifications, impossible de distinguer un refactoring propre d'un changement de comportement silencieux.

2. Découpez la tâche. Un démon ou une classe à la fois est plus fiable qu'une demande du type « nettoie le module ».

3. Expliquez le contexte au modèle. Précisez que le code tourne dans un seul thread sur une boucle d'événements, quels objets possèdent quelles ressources et quelles interfaces D-Bus ne doivent pas être modifiées.

4. Vérifiez à la main la durée de vie des objets. C'est l'endroit où un code vraisemblable a le plus de chances d'être faux.

5. Branchez de l'automatisation : clang-tidy, sanitizers, analyse statique et exécution sur une carte cible ou émulée. 6.

Gardez une relecture humaine pour chaque modification. L'IA accélère le travail routinier, mais la responsabilité du comportement du firmware reste la vôtre.

Pour les équipes qui maintiennent de grandes bases de code C++, une telle expérience a de la valeur quel que soit son résultat. Elle montre à partir de quel niveau de complexité l'assistant cesse d'aider et se met à casser. Les conclusions complètes de l'auteur figurent dans l'article original sur Habr.