Mission de Staff Engineer pour structurer les standards et industrialiser le développement
Believe est un acteur majeur de la distribution musicale digitale, qui accompagne artistes et labels dans la diffusion de leurs contenus sur les principales plateformes de streaming et de vente.
Staff Engineer
Le contexte de la mission de modernisation applicative
L’équipe intervient sur des applications internes anciennes, parfois développées il y a plus de dix ans, avec des standards techniques devenus difficiles à maintenir et à faire évoluer. L’enjeu n’était pas uniquement technique, mais aussi organisationnel. Les équipes passaient une grande partie de leur temps sur du run, avec une bande passante très limitée à l’amélioration continue et à l’exploration d’outils et de pratiques nouvelles.
En parallèle, Believe avait déjà structuré une plateforme d’ingénierie moderne, avec des outils pour standardiser le développement, automatiser les déploiements et améliorer la qualité globale des applications. L’objectif était donc clair. Faire en sorte que l’équipe s’approprie les outils mit à disposition par les SRE et les équipes en charge de l’excellence opérationnelle (OPEX), pour engager la transformation progressive de la plateforme legacy vers des standards modernes, en améliorant de ce fait, la résilience, l’observabilité et l’automatisation.
La mission a consisté à trouver un équilibre entre modernisation technique et adoption progressive. Il ne s’agissait pas de remplacer brutalement l’existant, mais de proposer une trajectoire réaliste, en partant d’un projet pilote capable de démontrer concrètement la valeur de la nouvelle stack.
Les enjeux d’adoption d’une architecture logicielle moderne
Le principal défi n’était pas tant de définir la bonne architecture que de la faire adopter. La stack mise en place introduisait des exigences plus élevées en termes de qualité, de structuration du code et de pratiques d’ingénierie, notamment avec l’introduction de principes de Clean Architecture. Celle-ci consiste à remettre au centre de l’application, les exigences métiers, en les isolant des détails techniques que sont les couches d’exposition des données et le code propre à l’infrastructure.
Les équipes ont dû changer leurs habitudes de travail. Passer d’un environnement relativement permissif à un cadre beaucoup plus structuré, avec des contraintes directement intégrées dans le code et dans les outils. Cela a généré de la friction au départ, notamment avec des outils comme PHPStan, configuré avec un niveau d’exigences élevé, accompagné de l’extension PHPAt, qui permet de définir des règles d’architectures auxquelles le développeur doit se conformer.
Il a fallu accompagner cette transition de manière progressive. Introduire les outils, parfois permettre aux développeurs de désactiver temporairement les contrôles pour répondre rapidement à des impératifs de production, et les encourager à matérialiser la dette technique ainsi souscrite dans leur backlog pour permettre à l’équipe d’en assurer le suivi et d’organiser son remboursement. Le travail a aussi consisté à justifier chaque choix technique, notamment via des Architectural Decision Records (ADR), afin de permettre aux parties prenantes de comprendre les choix techniques adoptés par l’équipe et au besoin de les remettre en question.
L’autre enjeu était de permettre à l’équipe de prendre de la distance sur le run, d’accorder de l’importance à l’amélioration continue et à l’expérimentation d’outils et de pratiques avec pour horizon l’amélioration de l’expérience de développement et la qualité du projet.
“Le but, ce n’était pas juste d’imposer une nouvelle stack. C’était de trouver un équilibre entre ce qui existait déjà et ce qu’on voulait mettre en place. Au début, il y a eu pas mal de frictions, les devs avaient l’impression de se battre contre les outils. Mais en une ou deux semaines, ils ont commencé à voir les bénéfices. Le vrai sujet, c’était de les accompagner pour qu’ils s’approprient les solutions et qu’ils puissent les faire évoluer eux-mêmes.”
Les missions réalisées pour structurer et faire adopter la plateforme d’ingénierie
La mission s’est déroulée sur une période de 9 mois, avec un objectif clair : poser les bases d’une plateforme d’ingénierie moderne tout en accompagnant les équipes dans l’adoption de nouvelles pratiques.
Les résultats de la transformation technique de Believe
- Réduction des tâches manuelles grâce à l’automatisation des processus de delivery
- Réintroduction d’une dynamique d’amélioration continue au sein de l’équipe
- Meilleure capacité à lancer de nouveaux projets rapidement avec un socle technique solide
