Refonte d'architecture d'une toolbox RF/Télécoms
Migration d'une toolbox monolithique Python vers une architecture modulaire de packages indépendants pour améliorer la maintenabilité et l'adoption.
Le contexte du projet
J'ai eu l'opportunité de travailler au sein d'une équipe R&D qui développait depuis plusieurs années une toolbox Python dédiée aux calculs dans le domaine des télécommunications et radiofréquences. Cette équipe avait pour mission ambitieuse de remplacer Matlab et ses différentes toolbox par une solution Python moderne, avec trois objectifs principaux :
- Réduire les coûts en éliminant les licences Matlab onéreuses
- Faciliter le déploiement et la distribution de leurs travaux
- Maîtriser l'intégralité de la chaîne de développement
Une architecture monolithique complexe
Le logiciel existant était conçu comme une solution monolithique regroupant plusieurs domaines fonctionnels distincts :
Modules principaux
- Gestion des antennes : antennes réseau, équations de propagation
- Algorithmes de localisation : DoA (Direction of Arrival), ToA (Time of Arrival)
- Module beamlayout : gestion des zones d'émission des satellites
- Module géométrie : calculs de distance, angles, quaternions
Les défis de la solution monolithique
Malgré sa richesse fonctionnelle, cette architecture présentait des limitations importantes qui freinaient l'évolution et l'adoption du projet :
Maintenance et développement
La séparation floue entre les différentes parties du code rendait difficile l'ajout de nouvelles fonctionnalités. Chaque modification dans une section risquait d'entraîner des régressions dans d'autres parties, créant un effet de bord permanent qui ralentissait considérablement le développement.
Qualité et couverture de tests
La couverture de tests et de documentation était bloquée à environ 40%. Au vu de la taille de la codebase, l'améliorer aurait représenté un effort colossal. Il était donc impossible d'imposer via CI/CD une couverture à un niveau acceptable, compromettant la fiabilité du produit.
Performance des pipelines CI/CD
À chaque développement dans un module, l'intégralité des tests était exécutée sur toute la codebase. Cette approche rallongeait considérablement les cycles de code review et de release, freinant l'agilité de l'équipe.
Problèmes de distribution et d'adoption
L'utilisation de la librairie nécessitait son inclusion complète dans les projets, même pour n'exploiter que 10% des fonctionnalités. Cette contrainte augmentait inutilement la taille des livrables et décourageait l'adoption par d'autres équipes qui trouvaient la solution trop lourde à appréhender dans son ensemble.
La solution : une architecture modulaire
Face à ces problématiques, nous avons décidé d'engager une refonte complète de l'architecture, en migrant vers un système de packages Python indépendants. Cette approche modulaire devait permettre de résoudre l'ensemble des limitations identifiées.
Avant : Monolithique
Tout dans un seul package
Après : Modulaire
Packages indépendants
Mise en œuvre de la refonte
La transformation s'est articulée autour de plusieurs axes stratégiques, chacun apportant des bénéfices spécifiques à l'écosystème de développement.
Pipelines CI/CD dédiées
Chaque sous-librairie dispose désormais de sa propre pipeline, permettant d'éviter l'exécution de tests sur les autres fonctionnalités lors des modifications. Cette approche a considérablement accéléré les cycles de développement et de validation.
Amélioration de la qualité
Dès la création de chaque nouvelle librairie, nous avons pu imposer une couverture de tests et de documentation à 100%. Cette exigence, impossible à atteindre sur la codebase monolithique, a rendu les librairies plus robustes et plus facilement utilisables par des équipes tierces.
Séparation et réutilisabilité
La contrainte de séparer le code en repositories différents nous a forcés à mieux structurer nos modules et à concevoir du code véritablement réutilisable. Cette discipline architecturale a considérablement amélioré la qualité technique du projet.
Distribution ciblée
Les équipes peuvent désormais choisir uniquement les librairies qui les intéressent, réduisant la complexité d'adoption et la taille des dépendances. Cette approche a favorisé l'adoption par d'autres équipes au sein de l'organisation.
Optimisation ciblée
La taille réduite de chaque librairie a facilité les phases de test, benchmark et optimisation des fonctions. Par exemple, nous avons pu nous concentrer spécifiquement sur l'optimisation des algorithmes MUSIC dans le module de localisation.
Découvrez les détails techniques des optimisations BLAS appliquées aux algorithmes MUSIC dans notre projet d'optimisation dédiée .
Préservation de la compatibilité
Pour assurer une transition en douceur, nous avons maintenu la librairie principale en y intégrant les sous-librairies comme dépendances. Cette approche a permis de :
- Assurer la rétrocompatibilité avec l'existant
- Maintenir le support de l'ancienne API monolithique
- Permettre une migration progressive des utilisateurs
Un projet de refonte d'architecture vous intéresse ?
Discutons de vos besoins en modernisation et optimisation de vos systèmes logiciels.