💻 computer science

Taming the Drift: Context-aware Repair of Dockerfile Drift during Software Evolution

Cet article présente Cadre, un cadre sensible au contexte qui exploite l'analyse statique pour construire un graphe de dépendances sensible au contexte (CDG) afin de générer des correctifs ciblés qui réparent efficacement la dérive de Dockerfile, surpassant les bases de référence existantes basées sur des règles et sur les LLM sur le nouveau benchmark $D^3$ de 1 040 instances de dérive réelles.

Auteurs originaux : Chengjie Wang, Jingzheng Wu, Xiang Ling, Tianyue Luo, Chen Zhao

Publié 2026-07-15

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Chengjie Wang, Jingzheng Wu, Xiang Ling, Tianyue Luo, Chen Zhao

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous construisez un robot dans votre garage. Vous avez écrit un manuel d'instructions parfait (le Dockerfile) qui dit exactement quelles pièces prendre, où les placer et comment les assembler. Mais ensuite, vous décidez de mettre à jour le cerveau du robot (le code source) et de remplacer quelques fils. Vous oubliez de mettre à jour le manuel pour qu'il corresponde aux nouvelles pièces.

Maintenant, quand vous essayez de construire le robot, il bégaye et s'éteint. Le manuel n'est pas « cassé » sur le plan grammatical ; les mots sont corrects. Mais le manuel est en train de dériver par rapport à la réalité. Il essaie de saisir une pièce qui n'existe plus ou d'utiliser un outil qui a été remplacé. Dans le monde du logiciel, c'est ce qu'on appelle la dérive de Dockerfile (Dockerfile drift), et cela provoque des échecs silencieux des ordinateurs, laissant les développeurs perplexes pendant des jours.

L'ancienne méthode : deviner dans l'obscurité

Les outils précédents tentaient de corriger cela en se contentant de lire le manuel et le message d'erreur. C'est comme essayer de réparer un moteur de voiture en regardant seulement le voyant « Check Engine » et le manuel du propriétaire, sans jamais ouvrir le capot pour voir les fils réels.

Certains outils utilisaient des règles rigides (comme une liste de contrôle), tandis que d'autres utilisaient une IA très intelligente (Modèles de Langage Étendus) pour deviner la solution. Mais voici le problème : ces outils d'IA étaient noyés sous l'information. On leur tendait tout le garage — chaque vis, chaque vieux manuel et chaque boîte de vieux trucs — en même temps que le message d'erreur. L'IA était tellement submergée par le bruit qu'elle abandonnait ou hallucinait une correction folle qui ne fonctionnait pas. En fait, sur environ 41 à 58 cas de problèmes sur un lot, ces outils d'IA échouaient simplement à produire une seule réponse parce que la « liste d'instructions » était trop longue pour qu'ils puissent la lire.

Le nouveau héros : Cadre (Le Détective)

Entrez en scène Cadre, un nouveau framework qui agit comme un brillant détective. Les auteurs, Chengjie Wang et son équipe, ont réalisé que le secret pour réparer le robot n'est pas de donner au détective plus de choses à lire, mais de lui donner la bonne carte.

Leur grande idée est simple : la structure importe plus que le volume. Savoir quel fil spécifique se connecte à quelle vis spécifique est bien plus important que de lire mille pages de texte non pertinent.

Cadre effectue cela en trois étapes magiques :

Le Profiler de Contexte (Le Voyageur Temporel) : Avant de tenter de réparer quoi que ce soit, Cadre simule l'intégralité du processus de construction étape par étape. Il observe exactement quels fichiers sont copiés, quelles variables sont définies et quels outils sont appelés. Il construit un modèle mental de l'« état » du projet à chaque instant précis.
Le CDG (La Carte de Dépendances) : En utilisant cette simulation, Cadre dessine un Graphe de Dépendance Sensible au Contexte (CDG). Voyez cela comme une carte de métro pour votre logiciel. Elle montre exactement comment l'instruction « FROM » (la base) se connecte à l'instruction « COPY » (les pièces) et enfin à l'instruction « RUN » (l'assemblage). Si un fichier change, la carte montre exactement quelles instructions vont trébucher à cause de cela.
La Correction en Deux Étapes (Le Filtre Intelligent) : Au lieu de jeter tout le garage sur l'IA, Cadre pose d'abord une question intelligente à l'IA : « Sur la base de cette carte et de l'erreur, de quels fichiers spécifiques as-tu réellement besoin pour voir ? »
- Étape 1 : L'IA choisit uniquement les fichiers pertinents (les « Fichiers Clés »).
- Étape 2 : L'IA lit uniquement ces fichiers et rédige la correction.

Cela empêche le « cerveau » de l'IA de déborder. Alors que les autres méthodes échouaient à générer un correctif dans 41 à 58 cas parce que le prompt était trop volumineux, Cadre a produit un correctif pour chaque une de ses tentatives.

Les Résultats : Est-ce que ça fonctionne ?

L'équipe a testé Cadre sur 1 040 exemples réels extraits de l'historique de GitHub (un ensemble de données qu'ils ont appelé $D_3$ ). Ce n'étaient pas des problèmes fictifs ; c'étaient des échecs réels survenus dans de vrais projets logiciels, avec les paramètres exacts nécessaires pour les reproduire.

Voici comment Cadre s'est positionné :

Cadre a corrigé 35,22 % des problèmes.
La meilleure méthode d'IA précédente (sans cette cartographie intelligente) a corrigé 28,48 %.
L'ancienne méthode de liste de contrôle basée sur des règles n'a corrigé que 9,34 %.

Cela signifie que Cadre est 1,24 fois meilleur que son meilleur concurrent d'IA et presque 3 fois meilleur que les anciens outils basés sur des règles.

Mais la vraie magie opère lorsque le problème devient « obsolète ». Imaginez un build cassé que personne n'a réparé après cinq ou six mises à jour. Les changements de code récents semblent totalement sans rapport avec l'erreur d'origine. La plupart des outils s'embrouillent et abandonnent. Mais parce que Cadre utilise la carte CDG, il peut remonter le fil de la panne jusqu'à son origine, même si elle est enfouie profondément dans l'historique. À cinq mises à jour ou plus, Cadre a corrigé 25,9 % des problèmes, tandis que le deuxième meilleur outil n'a réussi que 19,7 %. L'écart s'est en fait élargi à mesure que les problèmes devenaient plus anciens, prouvant que la carte est un signal durable.

Ce que ce n'est PAS

Il est important de savoir ce que Cadre ne fait pas. Ce n'est pas une baguette magique qui répare tout.

Il ne peut pas réparer les problèmes causés par une coupure Internet ou un serveur manquant d'espace disque.
Il ne peut pas corriger les bugs à l'intérieur de la logique réelle du code (comme une erreur mathématique dans le programme lui-même) ; il ne répare que les instructions de construction.
Dans environ 65 % des cas où il a échoué, le problème était une contrainte complexe de l'outil de build qui ne pouvait tout simplement pas être résolue en modifiant le manuel (comme un package manquant dans un registre privé).

À retenir

Les auteurs suggèrent que pour le futur de la maintenance logicielle, nous devons cesser de simplement jeter plus de données à l'IA et commencer à lui apprendre comment comprendre la structure des dépendances. En construisant une carte de la façon dont les fichiers et les instructions se connectent, Cadre a prouvé qu'un peu de contexte intelligent va très loin. Il ne s'agit pas de lire toute la bibliothèque ; il s'agit de savoir exactement à quelle page tourner.

Tout le code et l'ensemble de données de 1 040 dérives réelles sont ouverts à tous pour vérification, garantissant que ceci n'est pas seulement une théorie, mais un outil construit sur des preuves réelles et reproductibles.

Résumé technique : Dompter la dérive : Réparation sensible au contexte de la dérive des Dockerfiles lors de l'évolution logicielle

1. Définition du problème : La dérive des Dockerfiles

Le développement logiciel moderne repose largement sur les pipelines d'intégration et de déploiement continus (CI/CD), où Docker sert de standard de facto pour garantir des environnements de construction reproductibles. Cependant, un problème critique connu sous le nom de dérive de Dockerfile (Dockerfile drift) compromet cette fiabilité. La dérive se produit lorsqu'un Dockerfile ne parvient pas à absorber les changements apportés au code source de l'application, entraînant un décalage entre le script de construction et l'état évolutif du dépôt. Contra plus qu'une simple erreur de syntaxe, la dérive est un problème de co-évolution interne où l'information de correction réside au sein du même dépôt qui a produit l'échec.

La dérive se manifeste par des chemins de fichiers incorrects, des variables d'environnement mal assorties, des spécifications de dépendances obsolètes ou des changements de plateforme. Ces échecs sont particulièrement difficiles à réparer automatiquement en raison de trois défis fondamentaux :

C1 (Extraction du contexte) : L'état de la construction (répertoire de travail, variables d'environnement, ensembles de fichiers) est déterminé par l'exécution cumulative des instructions précédentes, et non par le simple texte du Dockerfile. Les méthodes existantes, qu'elles soient basées sur des règles ou sur des LLM, traitent souvent le Dockerfile de manière isolée, échouant à modéliser ces interactions dynamiques.
C2 (Dépendances entre instructions) : Les instructions dépendent souvent d'artefacts produits par des étapes antérieures de manière non évidente (par exemple, une commande RUN opérant sur des fichiers introduits par un COPY préalable ou des variables définies par un ARG). Ces dépendances ne sont pas visibles syntaxiquement de manière isolée.
C3 (Localisation des causes racines) : Les journaux d'erreurs indiquent souvent l'instruction défaillante mais identifient rarement la cause racine, laquelle peut provenir d'un changement de code introduit dans un commit précédent.

2. Méthodologie : Le cadre Cadre

Les auteurs proposent Cadre, un framework sensible au contexte conçu pour réparer la dérive des Dockerfiles en modélisant explicitement le contexte de construction. L'idée centrale de la conception est que la structure du contexte détermine la qualité de la réparation plus que le volume du contexte. Cadre répond aux trois défis à travers quatre phases intégrées :

2.1 Extracteur de dérive de Dockerfile (DodeX)

Pour pallier l'absence de benchmarks réalistes, les auteurs ont développé DodeX, un pipeline qui extrait des instances de dérive réelles à partir des journaux de CI de GitHub Actions. Contrairement aux jeux de données de snapshots statiques, DodeX capture la configuration complète de la construction, incluant les arguments de construction dynamiques, les plateformes cibles et les diffs exacts de changements de code ayant déclenché l'échec. Cela garantit que chaque instance extraite est localement reproductible.

2.2 Profileur de contexte au niveau de l'instruction

Pour résoudre C1, Cadre effectue une simulation d'état du processus de construction Docker. Il parcourt le Dockerfile instruction par instruction, maintenant un État de Contexte ( $\sigma$ ) qui suit :

Le répertoire de travail actuel ( $\delta$ ).
Les variables d'environnement résolues ( $\varepsilon$ ).
L'ensemble des fichiers présents dans le conteneur ( $\Phi$ ).

Crucialement, le profileur utilise des analyseurs sensibles au système de construction pour 11 écosystèmes majeurs (ex: Go, Python, npm, Maven). Au lieu de traiter les commandes RUN comme des chaînes de caractères opaques, ces analyseurs infèrent les dépendances de fichiers implicites (ex: inférer que go build dépend de go.mod et de tous les fichiers *.go dans le répertoire). Cela produit une Carte de Contexte d'Instruction (ICM) reliant chaque instruction à son état précis au moment de la construction.

2.3 Graphe de dépendance sensible au contexte (CDG)

Pour résoudre C2, l'ICM est convertie en un Graphe de Dépendance Sensible au Contexte (CDG), un graphe orienté acyclique ( $G = (V, E)$ ) qui rend explicites les dépendances entre les instructions :

Sommets : Incluent des nœuds d'instruction ( $V_I$ ) et des nœuds de fichiers ( $V_F$ ).
Arêtes : Incluent des arêtes séquentielles ( $E_S$ ) représentant le flux de contrôle et des arêtes de flux de données ( $E_D$ ) représentant les dépendances de type "lecture depuis" entre les fichiers et les instructions.
Ce graphe permet au système de tracer les chemins de propagation des échecs à travers les frontières des instructions, identifiant comment un changement dans un fichier source (ex: go.mod) invalide une instruction RUN spécifique via des étapes intermédiaires de COPY ou ARG.

2.4 Flux de travail de réparation affiné par le contexte

Pour résoudre C3 et gérer les limites de tokens, Cadre emploie un flux de travail agentique en deux étapes plutôt qu'un prompt unique :

Enquête de contexte : Le LLM est présenté avec le journal d'erreur, le diff de code et une version élaguée du CDG. Il lui est demandé de sélectionner l'ensemble minimal de fichiers pertinents et de mots-clés grep nécessaires à la réparation. Cette étape filtre le contexte non pertinent avant le chargement du contenu des fichiers.
Génération de la réparation : Le système récupère uniquement les fichiers sélectionnés et génère un patch ciblé.
Cette approche empênis l'overflow de prompt (un mode de défaillance courant des méthodes LLM concurrentes) et garantit que le modèle se concentre sur les preuves causalement pertinentes.

3. Contributions clés

Framework Cadre : Un nouveau framework de réparation fondé sur l'idée que la structure du contexte est plus précieuse que son volume. Il intègre un profileur de contexte d'état, un graphe de dépendance et un flux de travail LLM en deux étapes.
DodeX et Benchmark $D^3$ : La création de DodeX, un pipeline pour extraire des instances de dérive avec des configurations de construction complètes, et de $D^3$ , le premier benchmark de dérive de Dockerfile où les 1 040 instances sont localement reproductibles grâce aux paramètres exacts des exécutions CI originales.
Évaluation empirique : Une évaluation complète comparant Cadre aux baselines basées sur des règles (Parfum), aux baselines basées sur la récupération (FlakiDock) et aux LLM classiques (Vanilla LLM).

4. Résultats expérimentaux

Le framework a été évalué sur le benchmark $D^3$ (653 instances exécutables après filtrage des timeouts réseau).

Efficacité de la réparation : Cadre a atteint un taux de réparation de 35,22 %, surpassant la baseline basée sur des règles (Parfum, 9,34 %) de 2,78 $\times$ et la meilleure baseline basée sur LLM (Vanilla-LLM, 28,48 %) de 1,24 $\times$ .
Efficacité des tokens et robustesse : Cadre a totalement éliminé les échecs d'overflow de prompt ( $|F_r| = 0$ ), maintenant 95,25 % des prompts sous la barre des 30k tokens. En comparaison, les méthodes LLM concurrentes n'ont pas pu générer de patches dans 41 à 58 cas en raison du dépassement des limites de contexte.
Robustesse à la dérive ancienne (Stale Drift) : À mesure que les instances de dérive devenaient "anciennes" (persistant à travers plusieurs commits), les performances des approches basées uniquement sur le diff se dégradaient significativement. À une distance de 5+ commits, Cadre maintenait un taux de succès de 25,9 % contre 19,7 % pour la meilleure baseline, démontant que le CDG fournit un signal structurel robuste à la distance des commits.
Études d'ablation : Supprimer le CDG réduisait le taux de réparation de 4,29 points de pourcentage, tandis que supprimer le flux de travail en deux étapes le réduisait de 3,67 points et réintroduisait les échecs d'overflow de prompt. Les composants se sont révélés mutuellement renforçants.

5. Signification et affirmations

L'article affirme que la modélisation explicite des dépendances est un signal de réparation durable. Les auteurs soutiennent que l'avantage des approches sensibles au contexte par rapport aux méthodes basées uniquement sur le diff ou la récupération s'élargit à mesure que la dérive vieillit à travers les commits. L'étude suggère que la maintenance de l'Infrastructure as Code (IaC) sensible au contexte est une direction productive pour le développement futur d'outils.

Les auteurs notent modestement certaines limites : le CDG est basé sur l'analyse statique et ne peut pas capturer pleinement les facteurs d'exécution comme l'état des registres de paquets ou les conditions réseau, ce qui explique certains échecs non résolus. De plus, le benchmark est limité aux dépôts publics GitHub. Cependant, ce travail établit que la modélisation explicite du contexte de construction — spécifiquement le flux de données et de contrôle à travers les instructions — est cruciale pour automatiser la réparation des configurations logicielles évolutives.