Développeur fullstack senior adaptabilité · pragmatisme · ownership

Produit

• Analyse de la concurrence, positionnement différenciant et réflexion marketing
• Conception produit et UX de bout en bout : parcours d’onboarding, tutoriels contextuels in-app, gamification (challenges, défis d’épargne)
• Modèle freemium à trois plans (Solo / Duo / Familio) : partage de foyer, permissions fines par classeur, gestion des droits entre membres
• 6 langues (FR, EN, ES, DE, IT, PT-BR)
• Animation de communauté : Discord structuré (FAQ, forums de support, annonces de versions) et présence Bluesky

Développement & architecture

• Une seule codebase Vue 3 / Quasar / TypeScript pour trois cibles (web, Android & iOS via Capacitor)
  • Le web est servi en SPA sur Netlify, les applications natives sont empaquetées par Capacitor depuis le même build. Chaque fonctionnalité est donc écrite, testée et corrigée une seule fois, au prix d’une couche d’abstraction là où les plateformes divergent réellement : achats in-app, notation in-app, identifiant d’appareil.
• Historique de transactions en fenêtre glissante : pagination par curseur, cache en mémoire indexé par enveloppe et par classeur, écoute temps réel bornée à la fenêtre chargée
  • La première page charge les N transactions les plus récentes ; l’application retient le curseur Firestore du dernier document et la date de la plus ancienne affichée. L’écoute temps réel n’est pas posée sur toute la collection mais bornée à cette date, et rebranchée à chaque page supplémentaire. Sans cette borne, un compte de plusieurs années paierait en lectures et en mémoire l’intégralité de son historique pour afficher vingt lignes.
• Statistiques pré-calculées côté serveur par des Cloud Functions transactionnelles
  • Les agrégats par enveloppe, par période et par utilisateur sont maintenus à l’écriture par des Cloud Functions, dans des transactions Firestore idempotentes. Les écrans de statistiques lisent un document déjà agrégé : le coût de lecture reste constant quelle que soit la profondeur d’historique, au prix d’une dénormalisation qu’il faut garder cohérente lors des suppressions en cascade.
• Tests automatisés sur les règles de sécurité
  • Les règles Firestore portent les rôles et permissions par classeur, avec un invariant de membre unique qui empêche de se verrouiller hors de son propre contenu. Une suite Vitest de 68 tests sur les permissions et 12 sur le Storage est jouée sur émulateur Firebase, et importe la matrice de droits du code de production pour rester alignée avec elle.
• Migrations de données sur comptes actifs
  • Une trentaine de scripts d’administration et de backfill, tous bâtis sur le même squelette : documentation d’usage, --dry-run qui écrit ce qui changerait sans rien changer, confirmation interactive, --force pour les exécutions automatisées. Ils permettent de faire évoluer les données de comptes en service sans interruption ni perte.
• Monitoring des erreurs en production avec Sentry
  • Chaque version publie ses sourcemaps, ce qui rend une erreur de production lisible dans le code source plutôt que dans du bundle minifié, sur les trois plateformes. Sans support à qui déléguer, c’est ce qui évite de découvrir un incident par un avis sur les stores.

Workflow IA-first

• Utilisation de Windsurf fin 2025 puis adoption de Claude Code en février 2026
• CLAUDE.md comme référentiel vivant d’architecture et de règles de codage
• Travail découpé en specs, mode plan pour les décisions structurantes, agents parallèles sur chantiers disjoints, revue à chaque étape
• Skills et commandes custom pour standardiser les tâches récurrentes
  • Cinq commandes couvrent les gestes que je répétais à chaque livraison : ajouter une clé i18n dans les six fichiers de langue d’un coup, préparer le changelog d’une version, en dériver les notes de version du Play Store, ne mettre en zone d’index que les modifications du chantier en cours, et charger une fiche de chantier depuis Notion pour lancer l’analyse. Chacune encode une procédure que j’exécutais à la main, avec le risque d’oubli que ça suppose.
• Hooks pour poser des garde-fous
  • Les hooks s’exécutent autour des actions de l’agent, indépendamment de ce qu’il décide : préfixer chaque message de commit par l’identifiant du chantier en cours, refuser une édition qui sortirait du périmètre du dépôt, nommer la session d’après le chantier. L’intérêt est qu’une règle appliquée par le harnais ne dépend pas de la bonne volonté du modèle.
• Mémoire projet versionnée : décisions d’architecture et retours de revue capitalisés dans le dépôt

Résultats

• Près de 2 500 comptes créés, 4,6/5 sur Android
• 59 versions livrées en onze mois, soit une tous les six jours en moyenne, sur trois plateformes maintenues seul
• Rythme de livraison comparable à celui d’une petite équipe

Produit

• Vision produit, roadmap, priorisation des fonctionnalités
• Périmètre du MVP : annuaire des acteurs pros, catalogue de jeux et d’événements, volet réseau social et statistiques d’activité
  • Une trentaine de tables couvrent les jeux et leurs relations, les crédits et récompenses, les organisations et leurs adresses, les événements, les collections, les publications et leurs commentaires. Le pari du produit était que ces données de référence, aujourd’hui éparpillées, valent surtout par les liens entre elles, d’où le catalogue relationnel plutôt qu’un simple annuaire.
• Supervision d’une étude de marché externalisée, analyse concurrence, business plan
• Confrontation terrain : salon professionnel, canal Discord d’une communauté de prospects

Développement & architecture

• MVP fullstack développé à deux : SvelteKit (SSR), TypeScript strict, TailwindCSS, Supabase
  • Rendu serveur déployé sur Vercel, deux projets Supabase distincts pour la préproduction et la production. Les types TypeScript sont générés depuis le schéma Postgres, ce qui fait qu’un changement de colonne casse la compilation avant d’atteindre une page.
• Un fil d’actualité unique piloté par un modèle de filtres composables
  • Chaque dimension de filtrage (jeu, événement, organisation, pertinence, tri) est une classe qui sait contribuer sa clause à la requête Supabase en cours. Un objet de filtre se construit à partir du chemin et des paramètres de navigation, puis compose les clauses correspondantes. Conséquence : le même composant de fil sert les pages jeu, événement, organisation et le tableau de bord, au lieu d’une variante de feed par page à maintenir en parallèle.
• Recommandations calculées en base : jeux proches par tags, par gamme de produits ou par personnes créditées
  • Quatre fonctions PL/pgSQL portent le rapprochement, une par critère de proximité. Le calcul reste au plus près des données et revient en une requête, là où l’équivalent côté client supposerait de rapatrier le catalogue puis de le filtrer. Le coût est de garder cette logique versionnée dans les migrations, et donc testable moins facilement que du TypeScript.
• Compteurs et notifications maintenus par triggers Postgres
  • Les votes sur les publications et sur les événements, ainsi que la génération des notifications de commentaire, sont maintenus par des triggers sur insertion, mise à jour et suppression. La cohérence ne dépend donc pas du client qui écrit et reste vraie si une écriture arrivait un jour d’ailleurs que de l’application (par exemple d’un script d’administration ou d’une future API).
• Conventions outillées
  • Une convention de nommage documentée associe un suffixe de fichier à une nature de code, et des templates génèrent un service, un composant ou une route déjà conformes, fichier de test compris. husky et commitlint refusent les commits qui ne suivent pas la convention.

Résultats

• MVP livré, déployé et testable par de vrais prospects
• Boucle de feedback terrain mise en place avec des professionnels du secteur
• Projet arrêté faute de traction B2B suffisante : décision assumée et rapide

Management humain

• Animation quotidienne de l’équipe (points d’avancement, arbitrage des priorités)
• Communication et écoute, en interne comme avec les équipes clientes, pour concilier leurs sollicitations avec la capacité réelle de l’équipe
• Suivi individuel, entretiens annuels, montée en compétence et autonomisation
• Interface avec les autres équipes et le comité de direction

Pilotage de projets & réalisations techniques

• Gestion de projets avec un souci constant de visibilité au plus tôt et de pragmatisme dans les arbitrages
• Gestion budgétaire de l’équipe : suivi des dépenses, projections et anticipation des besoins (recrutement, outillage, formation)
• Recentrage de l’équipe Link sur son cœur de mission, avec passation organisée des activités périphériques à d’autres équipes
  • L’équipe était devenue le recours par défaut pour toute demande d’outillage, au point de se disperser. Le recentrage a consisté à trancher ce qui relevait réellement de Link, à organiser la passation du reste plutôt que de l’abandonner, et à ouvrir en parallèle un canal de communication et des retours d’expérience réguliers auprès des équipes clientes, ainsi qu’un lien avec les DevOps rattachés aux autres équipes.
• La Forge : documentation, provisioning d’environnements dev/test et suivi du dépôt de sources, utilisée par les équipes dev, produit et test
  • Le provisioning à la carte visait à remplacer les environnements de développement existants et à servir tous les publics : démonstration, avant-vente, développement et recette. L’étape suivante portait sur l’outillage de gestion du parc lui-même (création et suppression, supervision, suivi des coûts) pour que la mise à disposition ne crée pas une dette d’exploitation.
• Pipeline CI/CD (Jenkins) et infrastructure AWS câblés pour l’ensemble des équipes de développement
• Mise en place d’un VPN pour le travail à distance des développeurs et de la MOA
• Refonte de la gestion documentaire de l’entreprise autour de Notion
  • Le sujet dépassait la R&D pour concerner l’ensemble des départements : interlocuteur des équipes Notion pour organiser les formations et gérer le volet contractuel et la facturation, définition des process d’usage, migration de l’existant, puis accompagnement des utilisateurs. Déployer un outil transverse tient moins de la migration technique que de l’adoption : sans process ni accompagnement, chacun recrée ses anciennes habitudes dans le nouvel outil.
• Contribution à un projet de refonte complète de l’applicatif principal, arrêté lors du rachat de l’entreprise
  • Le projet a été mené hors du périmètre officiel jusqu’à être démontrable, pour présenter à la direction une proposition mature plutôt qu’une intention — et, en attendant, offrir aux équipes un sujet de fond sur lequel se réengager. J’ai participé aux travaux de définition, côté architecture comme côté produit : ce que le nouvel applicatif devait offrir, et sur quelles fondations le construire. Une acquisition puis l’entrée d’un fonds d’investissement au capital ont redistribué les priorités.

Résultats

• Provisioning d’environnement dev/test : d’une installation manuelle poste par poste à quelques minutes, en libre-service
• La Forge adoptée transversalement : 3 applications principales, plusieurs projets internes et POC
• Travail à distance débloqué pour les développeurs et la MOA

Mon rôle

• Veille technologique et choix techniques structurants
• Mise en œuvre d’outils et de méthodes
• Revue de code, industrialisation des processus
• Formation et transmission
• Recrutement : conduite de l’ensemble des phases d’entretien (parcours, technique, adéquation à l’équipe)

Réalisations

• Outillage qualité et automatisation : Jenkins, SonarQube, Azure DevOps, tests E2E Ranorex, site documentaire, Notion
  • La normalisation des processus du service s’est faite outil par outil sur plusieurs années : gestion de sources, site documentaire, analyse statique du code. Chaque brique n’avait d’intérêt qu’adoptée, ce qui a demandé autant de pédagogie que de mise en œuvre.
• Migration des plateformes historiques vers AWS et automatisation de la génération d’une version
  • Le parc de plateformes de développement et de test était hébergé en interne. La migration vers AWS, menée sur plusieurs exercices, a permis de libérer la salle serveur, et l’automatisation de la génération d’une version a supprimé une opération manuelle jusque-là répétée à chaque livraison.
• Industrialisation des processus : génération de plateformes, pipelines CI/CD
• Accompagnement de l’adoption de TypeScript par les équipes de développement
• Méthodes : adaptation de Scrum, process de revue et de validation de code, SDLC
• Café Techs (rituel hebdomadaire de veille), formations Git et présentations techniques
• Étude et sélection d’un framework JS (choix structurant pour les équipes)
• Recrutement de bout en bout (alternants et CDI) : entretien de parcours, évaluation du cultural fit, analyse du kata rendu et débrief en questions ciblées sur les choix de conception

Résultats

• Baisse observée du nombre de régressions après la mise en place des process de revue et de l’outillage qualité
• Salle serveur libérée à l’issue de la migration des plateformes historiques
• Café Techs suivis par plus de la moitié de l’équipe de développement

• Collaboration quotidienne avec les équipes en Inde
• Amélioration de la qualité du code par la promotion de bonnes pratiques et l’outillage
• Coordination transverse (architectes, DBA, exploitation, projets connexes)
• Rédaction du process de mise en production
• Participation aux comités techniques transverses

Architecte applicatif (11/2015 - 01/2017)

• Refonte du SI vers une architecture modulaire et multi-canaux (mobile, desktop), avec l’introduction d’AngularJS, Spring Boot et Scrum
  • Le SI reposait sur un socle Java/J2EE et un framework propriétaire maison. La cible visait un système plus modulaire et adaptatif, développé en agile. Je suis monté en compétence sur les technologies retenues, puis défini la nouvelle plate-forme de développement (outillage, machines virtuelles) par une phase d’étude et de tests, avant d’accompagner les développeurs vers ces méthodes de travail.
• Démarche d’amélioration de la qualité du code, déployée à l’échelle de la DSI
  • Rédaction des guides de développement et d’un wiki, présentation de la démarche adaptée à chaque type d’acteur, nomination de référents qualité dans les équipes, formation à SonarQube, puis suivi dans la durée. Le pari était qu’une démarche qualité ne tient que si elle a des relais dans chaque équipe : c’est la nomination des référents qui a fait la différence, pas l’outil.
• Étude comparative des solutions de test mobile, émulateur contre terminal réel
  • Étude et rapport de recommandation pour arbitrer les futurs développements mobiles, suivis de la mise en œuvre d’une solution de test Android.

Lead Developer (07/2014 - 11/2015)

• Simulateur de la Prime d’activité, équipe de 6 personnes
  • Simulateur public permettant d’estimer le montant d’une prestation nationale nouvellement créée, avec la visibilité et la criticité que ça suppose. J’ai porté les choix techniques et le design de l’architecture logicielle, conçu un moteur d’affichage progressif du formulaire piloté par les règles de gestion (l’utilisateur ne voit que les questions rendues pertinentes par ses réponses précédentes) et participé aux comités de suivi.
• Reprise et refonte du webservice de commande de documents, équipe de 2 personnes
  • Le composant agrège des données issues de sources multiples et compose un document dont l’édition est déléguée à différents canaux : SMS, PDF, courrier. En reprise d’un existant, j’ai assuré le chiffrage, la planification et le suivi, le dialogue avec les projets clients, et défini les pistes d’amélioration technique en plus de l’architecture.

Référent technique (07/2009 - 07/2014)

• Création de la fonction de support aux développeurs, jusque-là inexistante dans l’organisation
  • Le poste a été construit en même temps qu’occupé : trouver les sujets sur lesquels intervenir, se faire connaître des équipes, et établir la légitimité d’une fonction transverse sans autorité hiérarchique. Trois axes se sont dégagés : les études techniques, le renfort sur les projets à forte criticité, et le conseil au quotidien.
• Assistance aux équipes sur l’architecture logicielle et l’outillage
  • Interventions en début de projet et lors des refactorings, sur l’architecture applicative, les API Java/J2EE, Maven, Jenkins, le paramétrage de Websphere et le framework propriétaire de la CNAF.
• Participation aux groupes de travail nationaux, accompagnement au changement et formations
  • Choix et mise en œuvre des nouvelles technologies de développement, et surtout accompagnement des migrations successives de gestion de configuration logicielle : de Synergy vers Subversion, puis vers Jazz RTC et Maven. Changer d’outil de gestion de sources pour des dizaines de développeurs tient moins de la technique que de la conduite du changement.
• Veille technologique entretenue par la pratique
  • Projets personnels menés dans différentes technologies, suivi de l’actualité, lecture systématique de documentation. C’est ce qui m’a permis d’être crédible sur les choix que je recommandais.

• Solutec chez BNP Paribas (09/2008 - 07/2009) : Maintenance et évolution d’une application bancaire : SSO (Site Minder), AJAX, Java
• Sopra Group chez AFPA (10/2007 - 09/2008) : Maintenance évolutive d’applications métier