Responsable développement web — RCF Link to heading

Lyon | Depuis 2024

Lead technique d’une équipe de 3 développeurs, responsable de l’architecture d’une plateforme média multi-supports : site public (Nuxt), back-office éditorial (Drupal), application mobile, API, infrastructure AWS.

Ordres de grandeur : 65 radios locales diffusées, 460 000 sessions mensuelles, 150 journalistes sur le back-office, une dizaine de microservices. Déploiement en production toutes les deux semaines depuis quatre ans.

Mon rôle traverse toutes les couches du système : diagnostic et arbitrages d’architecture, optimisation des performances (base de données, API, front), conception d’intégrations, migration de données. J’interviens sur un système existant en production : je cherche à le comprendre avant de le modifier et je mesure l’impact de chaque changement. Les réalisations ci-dessous en détaillent quelques-unes — contexte, décision, résultat.

Rôle dans l’équipe. Deux développeurs aux profils purement dev appliquent les concepts et développent ; je porte l’architecture et les arbitrages techniques. Nous travaillons en équipe sur ~90 % des projets — sprint planning, stand-up bi-hebdomadaire, revues de code, documentation. Certaines briques transverses ou à risque (infrastructure serverless, migration de données) sont prises seul, délibérément : cela libère l’équipe sur les projets directement liés aux métiers de la structure. L’accompagnement technique — revues, montée en compétence, décisions d’architecture partagées — fait partie du rôle au même titre que le code.

Optimisation de la base de données — AWS RDS / MariaDB Link to heading

La base subissait 3 à 4 pics de CPU à 100 % par semaine, imprévisibles, de 30 à 90 minutes : erreurs 500 et 504 sur le back-office. Le réflexe standard aurait été d’agrandir l’instance. L’analyse (RDS Performance Insights, CloudWatch) a montré qu’elle était déjà surdimensionnée et que le rebuild du cache Drupal saturait la base — l’upscale aurait coûté plus cher sans rien résoudre. Trois semaines d’optimisation ciblée : index, réécriture des requêtes les plus coûteuses, correction des patterns d’accès.

Résultat, mesuré sur un mois avant / un mois après : charge CPU réduite de 54 %, pics résiduels à 50 sessions actives moyennes contre 400, erreurs 504 en forte baisse. La baisse de charge rend désormais possible un downsizing de l’instance — analyse de dimensionnement en cours.

→ Étude de cas détaillée

Passerelle de dons serverless — AWS Link to heading

Deux prestataires externes — tunnel de don et CRM — incapables de faire communiquer leurs systèmes, pour un flux représentant plus de 50 % du financement de la radio. Conception et développement seul, en deux mois, d’une passerelle serverless décrite en AWS CDK (infrastructure as code) et conçue pour la défaillance plutôt que pour le cas nominal :

  • API Gateway : point d’entrée (webhook émis à chaque don).
  • Lambda : transformation des données entre les deux formats.
  • DynamoDB : déduplication par identifiant de transaction.
  • SQS : découplage et rejeu (3 tentatives), file morte avec alerte e-mail pour traitement manuel.
  • Secrets Manager et policies IAM dédiées pour l’isolation des tokens des deux prestataires.

En production depuis début 2026 : ~10 000 dons traités, aucun incident, aucun doublon, 4 € de coût mensuel.

→ Étude de cas détaillée

Migration de données — fusion 2025 Link to heading

Lors de la fusion avec une autre radio, l’intégralité de ses données éditoriales devait rejoindre notre plateforme — sans export exploitable côté source, avec des modèles de données incompatibles. Extraction complète via leur API (Python, pagination, retry), transformation en format pivot JSON, chargement via le module Drupal Feeds existant plutôt qu’un importeur sur mesure, migration par lots rejouables validés avec les équipes métier.

Résultat : 4 000 épisodes, 1 500 articles et plusieurs centaines de Go de médias migrés, seul — aucune perte de données, deadline anticipée, bascule finale avec redirections SEO. Plateforme source décommissionnée.

→ Étude de cas détaillée

Refonte de l’application mobile — React Native Link to heading

Application en fin de vie, refonte nécessaire, sans expertise mobile approfondie en interne. Plutôt que de l’improviser : un prestataire React Native expérimenté pour poser les fondations, l’équipe interne développant à son contact, et la prise en charge personnelle des ressources API consommées par l’application. Livrée en mai 2026 sur Android et iOS — 4/5 sur Android.

Également sur la période Link to heading

  • Migration du front Nuxt 2 → Nuxt 3 → Nuxt 4 et passage complet du projet à TypeScript — fin de support, socle réaligné sur les versions maintenues.
  • Backend : réduction du temps de réponse jusqu’à 75 % sur les endpoints d’API les plus lents (requêtes SQL, stratégie de cache).
  • Exploitation : gestion des DNS, des certificats TLS et des nginx locaux. L’infrastructure cloud (Kubernetes sur AWS, Redis, RDS, EC2) est gérée par un prestataire DevOps.

LLM dans le workflow Link to heading

Les LLM sont intégrés au quotidien comme accélérateurs, sous un cadre strict, avec Claude Code notamment. Usages concrets : réflexion sur l’infrastructure, optimisation de code, génération de tests, investigation de problèmes. Le modèle analyse, génère et critique des hypothèses, produit un plan découpé en lots ; la validation des solutions et les arbitrages techniques restent humains. Ce workflow a été appliqué tel quel sur l’investigation RDS ci-dessus.

Développeur Fullstack — RCF Link to heading

Lyon | 2022 – 2024

  • Refonte SEO technique menée avec un prestataire expert : +30 % de visites SEO en un an.
  • Stabilisation de l’application mobile React Native, sous contrainte de deadline store (API Android 35) : ~50 % de crashs en moins (Crashlytics) ; mise en place d’un service d’authentification avec AWS Cognito.
  • CI/CD : mise en place du pipeline à l’origine du rythme de déploiement bi-mensuel toujours en place quatre ans plus tard.
  • Refonte de l’architecture backend PHP : migration du legacy procédural vers des classes d’entité, factorisation des appels et uniformisation des retours d’API — lisibilité et maintenabilité nettement améliorées pour l’équipe.