Comment quatre équipes ont cessé de repousser la refactorisation dont elles savaient avoir besoin

Par JetBrains

Comment quatre équipes ont cessé de repousser la refactorisation dont elles savaient avoir besoin, par JetBrains

En programmation informatique et en conception de logiciels, la refactorisation du code désigne le processus consistant à restructurer le code source existant — en modifiant son organisation — sans en altérer le comportement externe. La refactorisation vise à améliorer la conception, la structure ou la mise en œuvre du logiciel (ses attributs non fonctionnels), tout en préservant ses fonctionnalités. Les avantages potentiels de la refactorisation peuvent inclure une meilleure lisibilité du code et une complexité réduite ; cela peut améliorer la maintenabilité du code source et créer une architecture interne ou un modèle d'objets plus simple, plus propre ou plus expressif afin d'améliorer l'extensibilité. Un autre objectif potentiel de la refactorisation est l'amélioration des performances ; les ingénieurs logiciels sont confrontés à un défi permanent : écrire des programmes plus rapides ou utilisant moins de mémoire.

En général, la refactorisation consiste à appliquer une série de micro-refactorisations de base standardisées, chacune d'entre elles étant (généralement) une modification minime du code source d'un programme informatique qui préserve le comportement du logiciel, ou du moins ne modifie pas sa conformité aux exigences fonctionnelles. De nombreux environnements de développement offrent une prise en charge automatisée pour effectuer les aspects mécaniques de ces refactorisations de base. Si elle est bien menée, la refactorisation du code peut aider les développeurs de logiciels à découvrir et à corriger des bogues ou des vulnérabilités cachés ou latents dans le système en simplifiant la logique sous-jacente et en éliminant les niveaux de complexité inutiles. Si elle est mal menée, elle peut ne pas respecter l'exigence de ne pas modifier les fonctionnalités externes et peut ainsi introduire de nouveaux bogues.

En tant que responsable technique, vous n’avez pas besoin qu’on vous dise que votre base de code nécessite une attention particulière. Le problème ne réside pas dans la prise de conscience, mais dans l’évaluation rationnelle des risques qui s’ensuit. Pour quatre équipes, cette évaluation aboutissait systématiquement à la même conclusion : reporter. Elles ont trouvé une issue non pas en évitant cette évaluation, mais en modifiant les éléments qui la composaient.


Refactoriser ou non : le coût d’une décision rationnelle

Le risque de régression est une préoccupation constante pour les développeurs qui envisagent une refactorisation. Une étude réalisée en 2014 auprès de 328 ingénieurs professionnels chez Microsoft a révélé que 76 % d’entre eux estimaient probable que la refactorisation introduise des bugs subtils ou des régressions. Dans une enquête CMU/SEI de 2022, 71 % des 107 professionnels chevronnés du secteur ont déclaré vouloir entreprendre une refactorisation à grande échelle, mais ne pas pouvoir le faire – principalement en raison du coût anticipé et des priorités concurrentes en matière de fonctionnalités. Seuls 6 % ont déclaré que la valeur attendue de la refactorisation était trop faible.

Cela signifie que le report de la refactorisation a traditionnellement été le choix par défaut à court terme.

La douleur liée à une refactorisation qui perturbe la livraison est immédiate et concrète. Les engagements de sprint prennent du retard, les délais vis-à-vis des clients sont repoussés, et c'est votre équipe qui en fait les frais. La douleur architecturale liée au report d'une amélioration est également réelle, mais elle se manifeste plus tard, répartie en dizaines de petits ralentissements qui, pris individuellement, ne nécessitent jamais de réaction.

Douleur immédiate contre douleur différée : la refactorisation est toujours perdante. Le calcul ne change que lorsque le coût de la modification elle-même diminue. Cela se produit notamment lorsque les développeurs peuvent :

- Visualiser l’impact complet d’une opération de refactorisation sur l’ensemble du codebase avant de s’y engager.
- Annuler l’ensemble en une seule opération si quelque chose tourne mal.

À ce stade, le risque de perturbation à court terme diminue et les avantages à long terme commencent à l’emporter plus souvent. Voici à quoi ressemblait ce tournant pour quatre équipes.


Wiz : maintenir la flexibilité d’un monorepo d’un million de lignes

Wiz, racheté par Google pour 32 milliards de dollars en mars 2026, est une plateforme de sécurité cloud à laquelle plus de la moitié des entreprises du classement Fortune 100 font confiance pour identifier et éliminer les risques critiques dans les principaux environnements cloud. Wiz a adopté GoLand, l’EDI spécifique à Go de JetBrains, pour son équipe d’ingénieurs travaillant sur un monorepo gigantesque contenant des millions de lignes de code écrites principalement en Go.

Dans un monorepo de cette envergure, le problème de répercussion des refactorisations est structurel. Toute modification peut affecter des dizaines de services, de paquets et de dépendances à travers les équipes. Lorsque les outils peinent à suivre le rythme de la taille du référentiel – lorsque l'indexation prend des heures et provoque encore des blocages –, les développeurs se montrent prudents. Ils interviennent moins et reportent davantage. La base de code devient plus difficile à modifier à mesure que les équipes chargées de la faire évoluer ralentissent.

GoLand était le seul outil qui permettait aux développeurs de rester productifs à cette échelle, sans alourdir leur charge de travail. Les opérations de refactorisation se déroulaient toutes correctement sur l’ensemble de la base de code. La navigation à l’échelle du projet réduisait la charge cognitive liée au travail dans un système trop vaste pour qu’un seul développeur puisse le garder en tête.

Roy Reznik, cofondateur de Wiz : « La refactorisation est facile. Déplacer des paquets, renommer, supprimer, ajouter, extraire : toutes ces opérations fonctionnent très bien, rapidement et presque toujours sans faille, quelle que soit l’ampleur de la refactorisation ou de la modification. »

Le résultat n’était pas une simple initiative de nettoyage. Il s’agissait d’une capacité durable à continuer de modifier un système qui, selon toute mesure conventionnelle, aurait dû devenir de plus en plus difficile à modifier.


IT Manufactory : de la vérification manuelle à des modifications inter-stacks en toute confiance

IT Manufactory développe Digital Automotive, une plateforme dédiée à la stratégie, à l’acquisition, à la finance et à la gestion du changement dans l’industrie automobile. Avec une équipe de neuf développeurs travaillant à la fois sur des modules backend Java et des composants frontend React, l’entreprise était en phase de développement actif de ses produits. Des changements importants devaient être apportés fréquemment à de nombreux endroits.

Le risque spécifique était l’impact inter-stacks. Les modifications radicales touchant simultanément les modules Java et les composants React nécessitaient une vérification manuelle sur l’ensemble de la chaîne de dépendances. Il n’existait aucun moyen fiable de savoir à l’avance ce qu’une modification allait affecter. En pratique, cela conduisait les ingénieurs soit à éviter les changements architecturaux majeurs, soit à assumer la charge de travail liée à des vérifications manuelles approfondies avant de s’y engager.

La standardisation sur IntelliJ IDEA et WebStorm a directement modifié ce calcul de charge. Supprimer un fichier, renommer une fonction ou une variable, extraire des méthodes – des opérations qui nécessitaient auparavant de rechercher manuellement chaque référence dans l’ensemble du code – sont devenues des actions uniques et confirmées que l’IDE gérait entièrement.

Varij Kapil, développeur logiciel, IT Manufactory : « Des modifications radicales et des refactorisations doivent être effectuées dans plusieurs modules Java et composants React. Réaliser des changements d’une telle ampleur n’aurait pas été possible sans les produits JetBrains. »

L'équipe n'a pas cessé d'apporter des modifications importantes. Elle a simplement cessé de payer le prix de la vérification manuelle pour chacune d'entre elles.


NutriAdmin : maintenir une équipe réduite en capacité de livraison pendant la migration de framework

NutriAdmin est une plateforme SaaS destinée aux diététiciens et aux nutritionnistes. L'équipe de développement, de taille réduite, avait initialement développé l'interface utilisateur avec AngularJS, ce qui a posé un problème spécifique et temporaire lorsque Google a décidé de réorienter son support vers Angular. Continuer à livrer sur AngularJS revenait à accumuler une dette de migration en plus de la dette fonctionnelle. Repousser la migration signifiait que le coût final ne cessait d'augmenter.

Pour une équipe axée sur la livraison continue, une refactorisation à grande échelle sans outils fiables est à la fois risquée et impraticable sur le plan opérationnel. Déplacer, renommer, diviser et restructurer manuellement des fichiers dans une base de code en pleine expansion est le genre de travail qui interrompt complètement la livraison de fonctionnalités pendant qu’il est en cours.

La prise en charge de l’analyse statique d’AngularJS par WebStorm était la fonctionnalité spécifique qui a rendu la modernisation viable parallèlement au développement continu. L'IDE résout les références et les dépendances au sein du code AngularJS – un framework dont la prise en charge par les outils diminue ailleurs – tout en couvrant également Node.js et React dans le même environnement. Les opérations de refactorisation qui auraient autrement nécessité une coordination manuelle minutieuse sur l'ensemble de la base de code sont devenues des opérations gérées par l'IDE.

Diego Oliveira Sanchez, cofondateur, NutriAdmin : « C'est un vrai plaisir de refactoriser du code avec WebStorm. J’ai pu déplacer, renommer, diviser et restructurer simultanément plus d’une centaine de fichiers tout en refactorisant mon projet avec confiance et efficacité. Une opération de refactorisation de grande envergure pourrait être un cauchemar dans un IDE moins avancé, et de nombreux développeurs pourraient parfois hésiter à entretenir et améliorer périodiquement leur base de code, ce qui entraînerait une accumulation de dette technique et une dégradation de la base de code. »

La migration ne s’est pas déroulée comme une initiative distincte. Elle s’est déroulée en continu parallèlement à la livraison des fonctionnalités, car les outils rendaient cela possible.


SEOBUK PRESENT : Maintenir la flexibilité d’une plateforme matériel-logiciel à mesure qu’elle évolue

SEOBUK PRESENT exploite une franchise mondiale de studios photo en libre-service depuis son siège en Corée du Sud. La plateforme couvre le contrôle du matériel, les services backend, les applications Unity et la communication entre serveurs pour les appareils photo, les imprimantes, les terminaux de paiement et les workflows orientés client. L'équipe d'ingénieurs travaille en C# sous Windows dans un domaine où le logiciel et le matériel sont étroitement couplés.

Dans cet environnement, l'impact d'une modification du code ne se limite pas aux autres services. La plateforme intègre des SDK matériels, des pilotes de périphériques, des spoolers et une synchronisation asynchrone sur l'ensemble de la pile. Même un simple changement de nom comporte un risque élevé de perturber les fonctionnalités existantes au sein de systèmes étroitement couplés. Le coût opérationnel d'une erreur est immédiat et visible.

La standardisation sur IntelliJ IDEA pour les services backend et sur Rider pour le développement C# et Unity a permis à l’équipe de disposer d’aperçus de refactorisation à l’échelle du projet avant que tout changement ne soit validé. Tout ce qui serait affecté dans l’ensemble de la solution était visible avant l’opération. L’intégration de Git avec la visibilité de l’historique au niveau des lignes a permis aux ingénieurs de retracer ce qui avait changé et pourquoi, réduisant ainsi la charge de travail liée à l’investigation lorsqu’il fallait comprendre ou annuler quelque chose.

Won, chef d'équipe de développement, SEOBUK PRESENT : « Lorsque l'équipe a adopté Rider, la réaction a été immédiate. La vitesse d'intégration, les délais de révision et la gestion des régressions se sont nettement améliorés, et une culture de changements petits et fréquents s'est installée. »

Le changement n'est pas passé de changements importants et risqués à l'absence de changements. Il est passé de changements importants, reportés jusqu'à ce qu'ils deviennent inévitables, à de petits changements continus que l'équipe pouvait effectuer en toute confiance.

Le calcul de la refactorisation prend une autre dimension

Ces quatre équipes n’ont en commun ni la pile technologique, ni la taille, ni le type de problème. Ce qu’elles partagent, ce sont les facteurs qui ont changé la donne : la capacité de visualiser l’impact d’une opération de refactorisation sur l’ensemble du codebase avant de la valider, et la possibilité de tout annuler en une seule opération si quelque chose tournait mal.

Pour chaque langage majeur représenté ici – Go, Java, React, AngularJS, C# et Unity – un EDI JetBrains a permis de mettre en œuvre ces capacités. Il en existe également un pour chaque langage majeur utilisé par votre équipe. Le pack « All Products » les regroupe tous sous une seule licence, de sorte que le coût d’accès reste fixe tandis que la valeur d’une refactorisation cohérente s’accroît au fil du temps.

En savoir plus sur les solutions de JetBrains pour les entreprises