CLEM: A Behavior-Centric Software Quality Measurement Framework for Structural Change Monitoring

Imaginez que vous regardiez une ville grandir. Vous pourriez compter combien de briques sont posées chaque jour, ou vous pourriez vérifier si le conseil municipal a respecté les règles. Mais il existe une troisième façon, plus intéressante, d'observer une ville : regarder comment les bâtiments changent. Les gens abattent-ils de vieux murs pour ajouter une nouvelle pièce ? Construisent-ils une nouvelle aile qui se rattache au côté sans toucher à la maison principale ? Se contentent-ils de basculer un interrupteur pour changer l'éclairage ? Ou ne font-ils que réorganiser les meubles ? Dans le monde du logiciel informatique, c'est exactement la question que se posent les chercheurs. Un logiciel n'est pas seulement du code ; c'est un système vivant qui doit constamment changer pour rester utile. Si un système ne change qu'en abattant ses propres murs, il devient finalement un ensemble instable et dangereux. Mais s'il change en ajoutant de nouvelles ailes ou en basculant des interrupteurs, il reste solide et flexible. C'est le cœur de la « qualité logicielle » : ce n'est pas seulement savoir si le code fonctionne aujourd'hui, mais s'il peut continuer à croître sans s'effondrer demain.

Ce document présente un nouvel outil appelé CLEM (Change Localization and Externalization Measurement) pour répondre à cette question. Au lieu de simplement compter la quantité de code modifié, CLEM agit comme un détective qui observe comment les développeurs réparent ou mettent à jour un système. Il classe chaque changement dans l'une des quatre « personas » suivantes :

1. Modification (M) : L'approche « Abattre les murs ». Modifier directement le code central. C'est rapide mais risqué, comme creuser un trou dans un mur pour ajouter une porte.
2. Extension (E) : L'approche « Ajout ». Construire de nouvelles fonctionnalités qui se branchent dans le système sans toucher au cœur, comme ajouter une nouvelle pièce à une maison.
3. Low-code (L) : L'approche « Organigramme ». Utiliser des outils visuels ou des règles pour changer le comportement, comme un gestionnaire d'entreprise réorganisant un flux de travail sans écrire de code.
4. Configuration (C) : L'approche « Interrupteur ». Simplement changer les paramètres ou les variables, comme tourner un bouton pour changer le volume.

Les chercheurs ont testé cette idée sur trois projets logiciels différents : deux projets publics issus d'un grand écosystème technologique et une application de santé privée. Ils ont découvert que CLEM peut clairement faire la distinction entre un système qui est « sain » (utilisant principalement des ajouts et des commutateurs) et un système « malade » (modifiant constamment son propre cœur). Cependant, ils ont également découvert quelque chose de surprenant : savoir comment un système change ne permet pas automatiquement de prédire s'il aura plus de bugs le mois prochain. C'est un excellent outil pour comprendre la structure d'un système, mais ce n'est pas une boule de cristal pour prédire les erreurs futures.

Le nouveau carnet du détective : Comment fonctionne CLEM

Considérez le développement de logiciels comme une cuisine très occupée. Pendant des années, les chefs (développeurs) ont été mesurés par le nombre de plats qu'ils cuisinent (volume d'activité) ou par la propreté de la cuisine à la fin de la nuit (vérifications statiques du code). Mais que se passe-t-il si la cuisine tombe en ruine parce que chaque fois qu'ils ont besoin d'une nouvelle épice, ils doivent abattre un mur pour accéder au garde-manger ? C'est le problème que CLEM résout. Il ne se contente pas de compter les plats ; il observe la méthode utilisée par les chefs pour obtenir les ingrédients.

Le document propose que chaque fois qu'un système logiciel est mis à jour, le changement se produit de l'une des quatre manières suivantes, et le mélange de ces manières révèle tout sur la santé du système.

• La Modification (M) est la méthode de la « Force brute ». C'est comme si un chef saisissait une masse pour briser un mur parce qu'il a besoin d'une nouvelle étagère. Cela permet de faire le travail rapidement, mais si vous le faites trop souvent, tout le bâtiment devient instable.
• L'Extension (E) est la méthode « Modulaire ». C'est comme construire un nouveau chariot détachable qui roule dans la cuisine. Le chef ne touche pas aux murs ; il ajoute simplement un nouvel outil. C'est plus sûr et cela préserve la structure centrale.
• Le Low-code (L) est la méthode du « Plan ». Imaginez un gestionnaire dessinant un nouveau flux sur un tableau blanc pour dire aux robots quoi faire, sans que les robots aient besoin d'être reprogrammés. C'est une façon de changer les choses à un niveau supérieur.
• La Configuration (C) est la méthode du « Bouton ». Il s'agit simplement de tourner un bouton pour rendre le four plus chaud ou les lumières plus brillantes. Aucune construction n'est nécessaire.

Les auteurs soutiennent qu'un système logiciel sain et durable devrait s'appuyer davantage sur l'Extension, le Low-code et la Configuration, et moins sur la Modification. Si un système « Modifie » constamment son cœur, il accumule probablement une « dette technique » — une façon élégante de dire qu'il emprunte de la stabilité au futur et qu'il devra la rembourser avec des intérêts plus tard.

L'expérience : Observer trois cuisines

Pour voir si cette idée fonctionne, les chercheurs ont fait une sortie sur le terrain dans trois « cuisines » (référentiels logiciels) différentes. Ils n'ont pas seulement regardé les plats finaux ; ils ont observé les mains des chefs pendant des mois.

1. La cuisine « Fit » (fit-framework) : C'était un projet public conçu pour être un système de plugins. Ils s'attendaient à ce qu'il soit rempli d'« Extensions » (E).
2. La cuisine « App » (app-platform) : C'était un autre projet public, mais il était conçu pour la conception visuelle low-code. Ils s'attendaient à ce qu'il soit rempli de « Low-code » (L) et de « Configuration » (C).
3. La cuisine « Antisuger » : Il s'agissait d'une application de santé privée pour la gestion de la glycémie. Elle a été construite par une équipe différente avec des outils différents. Ils s'attendaient à ce qu'elle soit dans une phase précoce et chaotique, probablement pleine de « Modifications » (M).

Les chercheurs ont analysé 607 mises à jour spécifiques (commits) à travers ces projets. Ils ont utilisé un ensemble de règles transparentes pour examiner les fichiers modifiés. Si un fichier se trouvait dans un dossier « plugin », ils le comptaient comme une Extension. S'il s'agissait d'un fichier de « flux », ils le comptaient comme du Low-code. S'il s'agissait d'un fichier de code central, c'était une Modification.

Ce qu'ils ont trouvé : Les systèmes étaient différents

Les résultats ont confirmé exactement la théorie de la « cuisine saine ».

• L'App-platform était effectivement très « externalisée ». Environ 69,5 % de ses changements étaient des Extensions, avec très peu de piratage direct du cœur. Son score « CLEM-ES » (une mesure de la part du changement repoussée loin du cœur) était un solide +0,685.
• Le Fit-framework était un mélange. Il avait beaucoup d'Extensions (33,4 %), mais aussi une part significative de Modifications (29,1 %). Son score était de +0,418, montant qu'il était plus sain qu'un pur désordre, mais pas aussi « externalisé » que l'App platform.
• La cuisine de santé Antisuger était l'opposée. Elle était presque entièrement dominée par la « Modification », avec 83,0 % de ses changements étant des éditions directes du cœur. Son score était de -0,659, indiquant qu'elle était encore dans une phase fragile de « piratage des murs ».

Cela a prouvé que CLEM peut identifier avec succès la différence entre un système qui grandit en ajoutant des ailes et un système qui grandit en abattant des murs. Les chercheurs ont même vérifié si leurs règles étaient équitables en demandant à deux humains d'examiner 160 mises à jour aléatoires. Ils étaient d'accord 100 % du temps sur la catégorie principale, ce qui suggère que les règles sont solides et reproductibles.

Le rebondissement : La structure ne prédit pas les bugs (encore)

C'est ici que le papier devient très prudent. Vous pourriez penser : « Si un système pirate ses propres murs (haute Modification), il devrait se casser plus souvent, n'est-ce pas ? » Les chercheurs ont testé cela. Ils ont cherché à savoir si les scores CLEM pouvaient prédire si le système aurait plus de « corrections de bugs » le mois suivant.

La réponse ? Aucun lien clair.
Dans leurs données, le score de « Modification » ne prédisait pas de manière fiable si le mois suivant serait rempli de corrections de bugs. Le score « CLEM-ES » (à quel point les changements étaient externalisés) n'avait presque aucune corrélation avec les futures corrections de bugs dans cet échantillon spécifique.

C'est une conclusion cruciale. Les auteurs précisent explicitement que CLEM n'est pas une boule de cristal magique pour prédire les défauts. Il ne remplace pas les anciennes méthodes de comptage des bugs ou du changement de code (code churn). Au lieu de cela, il offre un autre type d'aperçu. Il renseigne sur la posture structurelle du système. Un système avec un score de Modification élevé n'aura peut-être pas plus de bugs aujourd'hui, mais il construit une structure qui est plus difficile à maintenir et plus susceptible de devenir fragile avec le temps. C'est comme un bâtiment qui est structurellement instable ; il ne s'effondrera peut-être pas aujourd'hui, mais le plan est mauvais.

Pourquoi cela importe

Le document conclut que CLEM est un nouvel outil puissant pour les gestionnaires de logiciels. Il déplace la conversation de « Combien de code avons-nous écrit ? » vers « Comment modifions-nous notre système ? ».

• Si vous voyez une équipe faire constamment des Modifications, c'est un signal pour faire une pause et demander : « Pourquoi cassons-nous nos propres murs ? Pouvons-nous plutôt créer un plugin ? »
• Si vous voyez une équipe faire principalement des Extensions et des Configurations, cela suggère que le système mûrit et devient plus stable.

Les auteurs sont honnêtes quant aux limites de leur travail. Ils admettent que leur échantillon était petit (seulement quelques mois de données provenant de trois projets) et que la partie « prédiction de bugs » n'a pas fonctionné comme espéré. Ils suggèrent que CLEM est mieux utilisé comme un outil complémentaire — une façon de garder un œil sur la santé structurelle d'un système parallèlement aux mesures traditionnelles. Ce n'est pas un verdict final sur la qualité, mais une façon très claire et auditable de voir si un système logiciel apprend à grandir ou s'il est coincé dans l'habitude de briser ses propres fondations.

En résumé, CLEM nous donne un vocabulaire pour parler de la forme du changement. Il nous aide à voir si notre logiciel construit un gratte-ciel ou s'il empile simplement des briques sur une pile instable, et cette distinction est peut-être la chose la plus importante que nous puissions mesurer pour la survie à long terme de tout système numérique.