Un projet d'alternance

L’histoire commence en 2013, alors que je suis développeur en alternance chez Projects Partners. Un électricien a besoin d’une solution de contrôle d’accès par badge afin de pouvoir répondre à un important marché public. Le besoin est inhabituel pour son entreprise : il connaît l’électricité, mais pas le développement logiciel.

Le projet est confié à Projects Partners. Je le développe seul, accompagné par mon responsable, avec un objectif simple : proposer une solution fiable et peu coûteuse pour de petits bâtiments comportant quelques portes, lecteurs et badges.

La solution repose alors sur des Raspberry Pi, .NET via Mono et des lecteurs communiquant en RS485. Le Raspberry Pi offre suffisamment de puissance pour les petits sites tout en conservant un coût matériel très faible.

Les choix matériels et logiciels sont alors dictés autant par les contraintes techniques que par la nécessité de conserver une solution peu coûteuse. Après plusieurs essais, la solution est déployée sur plusieurs petits sites où elle fonctionne pendant plusieurs années avec très peu d’interventions.

Cinq ans plus tard, le changement d’échelle

Je quitte le projet en 2015 à la fin de mes études. Il continue ensuite à évoluer avec un autre développeur.

En 2020, je reviens comme indépendant. Le client vient de décrocher un chantier d’une toute autre dimension : 83 portes, 95 lecteurs et plus de 400 badges. Une architecture conçue pour quelques portes et quelques lecteurs doit désormais gérer un site d’une ampleur sans commune mesure avec les premiers déploiements.

Le retour sur le projet est aussi un retour sur mon propre code. Entre-temps, quatre années et demie d’expérience en ESN m’ont permis de voir suffisamment de systèmes complexes pour mesurer les limites de mes choix d’étudiant.

Je retrouve un code dont la conception métier reste étonnamment familière : les portes, les lecteurs, les règles d’accès et les différents états du système sont toujours organisés selon la même logique. En revanche, certains choix techniques ont mal vieilli.

Refondre sans perdre le métier

La couche d’accès aux données repose sur des antipatterns et un orienté-objet trop intégriste, tandis que Mono est progressivement remplacé par .NET natif sous Linux. Je profite de cette migration pour nettoyer le code, supprimer les abstractions devenues inutiles et revoir en profondeur l’architecture.

L’évolution majeure consiste à séparer le moteur des règles d’accès de la gestion du matériel. Les Raspberry Pi ne portent plus l’ensemble de la logique applicative : ils deviennent des contrôleurs capables d’interroger une grappe de lecteurs et d’exécuter les décisions qui leur sont transmises.

Le même logiciel peut néanmoins toujours être utilisé sur un petit bâtiment, avec un Raspberry Pi capable de tout gérer seul. L’architecture évolue donc sans abandonner le cas d’usage initial.

La migration vers .NET Core, puis .NET 6 et aujourd’hui .NET 8, accompagne cette refonte sans réécriture fonctionnelle massive. Le comportement métier est conservé autant que possible pendant que le socle technique est profondément assaini.

Corriger aussi ses propres erreurs

Le projet comporte environ 400 tests unitaires hérités de sa première version. Ils traduisent une conviction que j’avais alors : les tests unitaires suffiraient à sécuriser le logiciel.

Avec le recul, je constate leurs limites. Ils ne couvrent pas l’ensemble de la chaîne et aucun test end-to-end ou d’acceptation ne protège réellement le fonctionnement global du système.

La reprise permet donc d’introduire progressivement une autre approche. Le nouveau code est développé avec les tests comme outil de conception et de validation, tandis que le code historique est progressivement renforcé par des tests adaptés.

L’objectif n’est pas de réécrire le passé pour le rendre conforme aux pratiques actuelles, mais de construire suffisamment de sécurité autour de l’existant pour pouvoir continuer à le faire évoluer.

Un système qui finit par se faire oublier

La première année d’exploitation du nouveau système est consacrée au déverminage. Chaque défaillance donne lieu à une analyse des causes racines et à une remédiation, afin d’éviter de simplement corriger le symptôme.

La stabilisation porte ses fruits : les interventions d'exploitation sont désormais exceptionnelles.

OxaControle est aujourd’hui utilisé sur des installations allant du petit bâtiment au grand centre aquatique. Le même code source peut être déployé selon la taille du site, depuis un Raspberry Pi autonome jusqu’à une architecture répartissant le traitement sur plusieurs contrôleurs.

Le projet continue d’évoluer à la demande des clients, avec notamment de nouvelles fonctionnalités développées selon les pratiques de test actuelles.

Dix ans plus tard

OxaControle est probablement le projet qui m’a le plus appris sur le legacy.

J’ai pu revenir sur un logiciel que j’avais conçu étudiant, retrouver intacte la connaissance du métier et constater directement quelles décisions avaient bien vieilli et lesquelles méritaient d’être abandonnées.

Le code a changé, l’architecture a changé, les technologies ont changé. Mais le métier est resté. C’est cette continuité qui permet de moderniser un système sans perdre ce qu’il a accumulé au fil des années.

Mon intérêt pour le legacy et la maintenance à long terme vient en grande partie de là : un logiciel n’a pas besoin d’être remplacé simplement parce qu’il vieillit. Il faut parfois plusieurs années pour apprendre comment le faire durer.