Alexis Hassler

En tant que lead developer mon rôle est de mettre l’équipe dans le bon sens. Comme la complexité fonctionnelle est importante et les contraintes de qualité strictes, il a fallu rompre avec certaines habitudes, casser une certaine inertie intellectuelle et faire passer l’ambition dans l’esprit des membres de l’équipe.

Pour ce projet, l’équipe est totalement internationale, avec un client basé aux États-Unis et des développeur répartis entre l’Inde, le Pakistan, l’Europe de l’ouest et le Magrheb. Surtout, l’équipe est constituée de développeurs peu expérimentés et ayant une faible culture technique.

Par ailleurs, j’ai développé un bon nombre de composants techniques, en particulier dans le domaine des ACL qui a des règles complexes et un gros enjeu de performance, et du broker AMQP central dans l’architecture.

Après une première phase réussie en 2021, le projet est passé à une nouvelle étape avec l’intégration de nouveaux appareils spécialisés dans la détection de sons spécifiques (arme à feu, véhicule). Ces nouveaux appareils ont imposé des modifications dans le protocole de communication, mais aussi dans les écrans et les règles de gestion.

Bien que l’équipe ait un peu changé, la rigueur est restée la même autour de la démarche agile, de la qualité du code et des livrables.

L’objet du projet était de mettre en place une application pour la gestion de capteurs de bruit et pour la consultation publique de leurs métriques.

J’ai intégré l’équipe de projet de Rtone, avec qui je travaille depuis de nombreuses années, pour participer aux premiers sprints avec ce nouveau client. L’organisation de l’équipe autour de critères de qualité ambitieux a été efficace puisque nous avons eu des félicitations répétées du sponsor du projet.

Ce gros projet avait pour but de développer une application de commercialisation de certificats numériques. Malgré une apparence assez sobre, les règles de gestion et de présentation des produits était particulièrement complexes.

Les client a sous-traité le développement de l’application à une SSII, sur un contrat au forfait. Dans un premier temps, la SSII avait sous-estimé la complexité du métier et les exigences du client. Après quelques mois de développement, elle a acté l’échec de l’équipe initiale et mis en place une nouvelle équipe, plus expérimentée et organisée de façon plus rigoureuse.

J’ai fait partie de cette nouvelle équipe qui, malgré un contexte tendu et une ambiance de défiance, a réussi à livrer l’application dans un délai raisonnable et en répondant aux éxigences de qualité. Mon rôle était limité au back-end, avec un rôle de lead developer. Je devais apporter mon expérience et pousser mes collègues à adopter les démarches de qualité, comme le développement systématique de tests automatisés (unitaires et intégration), la revue systématique de code sur pull request ou la rédaction de documentation.

Après avoir travaillé sur la version initiale de cette application de gestion d’éclairage public entre 2012 et 2014, on m’a confié le développement d’évolutions et de nouvelles fonctionnalités.

L’architecture de l’application n’avait pas fondamentalement changé avec du Java à tous les étages, GWT pour le front-end et Spring Framework pour le back-end.