GPAC
App mobile et pipeline de livraison
3+
ans sur son architecture et sa CI/CD
Contexte
GPAC est une plateforme de recrutement américaine. Ses recruteurs travaillaient sur le web et, avec une devise comme « work from everywhere », il fallait une app mobile. Je suis arrivé pour la construire de zéro, grâce à mon expérience des apps publiées et de la CI/CD, et on a conçu l’architecture avec l’UX et le Produit.
Décision
J’ai étudié plusieurs options de gestion d’état et d’architecture, et j’ai retenu MVVM avec des services, une structure feature-first et Riverpod. On ne savait pas jusqu’où l’app allait grandir, et le feature-first lui a permis de grandir avec ordre. On a aussi fait un seul écran de détail pour toutes les entités et des composants réutilisables, ce qui nous évite de refaire ce qui existe déjà et raccourcit les livraisons. La CI/CD tourne sur Azure DevOps et Bitrise, et l’app intègre analytics, Remote Config, feature flags, notifications push et tests A/B pour déployer progressivement et décider avec des données.
Description textuelle: Sur le cycle des quintes, chaque tonalité partage presque toutes ses notes avec sa voisine, c’est pour ça qu’avancer dessus sonne stable et naturel. Le pipeline de GPAC fonctionne pareil. Chaque changement part d’une pull request (C) et avance toujours dans le même ordre, par l’analyse (G), les tests (D), les builds Android et iOS (A) et la publication (E). C’est une version simplifiée du vrai pipeline.
Ce que j’ai fait
J’ai décidé de l’architecture, des bonnes pratiques et de la mise en place d’un design system, qui n’existait ni sur le web ni sur mobile. J’ai construit la CI/CD, le détail partagé des entités et l’intégration de Remote Config, des feature flags et de l’analytics. Aujourd’hui, je pilote la documentation technique, des process et des tickets, ainsi que l’usage encadré d’agents IA comme Codex et Kiro, pour lesquels j’ai défini les skills, ce qu’ils ne doivent pas toucher dans le repo et les commandes qu’ils peuvent lancer.
Ce que je ferais autrement
Dès le début, je prenais déjà les décisions techniques, comme l’architecture, le state management et la façon d’implémenter chaque feature. Ce que je changerais, c’est de prendre l’initiative dès le premier jour sur les process aussi, là où a commencé mon chemin vers le rôle de tech lead, en demandant pourquoi chaque feature avait été choisie et en les mettant en place dès le début plutôt que de les ajouter une fois l’app lancée. Le projet a aussi changé ma façon de penser, parce que j’ai commencé très technique et qu’aujourd’hui je pense d’abord à l’utilisateur et à ce qu’on lui livre vraiment.