Expériences — Raphaël Daumas

Présentation

Développeur backend senior avec 7 ans d'expérience, spécialisé en C# / .NET et Swift / SwiftUI.

J'ai travaillé sur des systèmes critiques (aviation, industrie) et co-fondé un studio de développement où j'ai conçu et livré des produits de bout en bout — backend AWS serverless, applications iOS, architectures distribuées. Cette double expérience — rigueur technique sur des projets à forte contrainte et autonomie complète sur des produits from scratch — définit la façon dont j'aborde chaque projet.

Ce que je fais bien :
· Reprendre et stabiliser du legacy sans tout jeter (characterization tests, refactoring progressif)
· Concevoir des architectures distribuées adaptées au contexte (microservices, CQRS, messaging, serverless)
· Passer du code à la coordination sans quitter le code — revue de MR, guidelines, accompagnement de profils juniors
Ce que je cherche :
Un rôle de lead technique dans une équipe produit à taille humaine, avec un vrai esprit produit. Je veux être proche des décisions techniques, pas juste exécutant. Télétravail privilégié.

CV réalisé sur DoYouBuzz

Expériences

Mission : Bosch Rexroth — Configurateur HMI
Période : Juillet 2026 – présent
Rôle : Développeur senior
Client : Bosch Rexroth (filiale de Bosch, spécialisée dans les joysticks, valves hydrauliques et pédaliers pour engins industriels — grues, tractopelles, tracteurs, ...)

Contexte :
Le configurateur HMI est un outil interne permettant aux vendeurs de composer des configurations produit à partir de composants validés par le Bureau d'Études. Mission initiale de maintenance et d'évolution, après une passation de 6 jours avec le développeur sortant. Application monolithique Blazor / .NET Core 7 sans documentation ni tests.

Réalisations techniques :
- Mise en place (assisté par l'IA) de characterization tests sur l'existant : capturer le comportement actuel de la production avant tout refactoring, pour s'assurer que les évolutions ne dégradent pas ce qui tourne en l'absence de documentation et de spécifications
- Montée de version vers .NET Core 9
- Développement de nouvelles fonctionnalités attendues par les développeurs
- Initiative personnelle : proposition de refonte architecturale soumise à validation Bosch
  - Scission en deux produits distincts : configurateur composants (Bureau d'Études) / configurateur HMI (vendeurs)
  - APIs REST dédiées avec principe de moindre privilège par application
  - Pattern CQRS, avec moteur de recherche pour les composants type Elasticsearch
  - 3 bases de données indépendantes (composants / configurations HMI / workflow (historique et états de validation))
Environnement technique :
Langages :C#
Frameworks : .NET Core 7 -> 9, Blazor, NUnit
Outils : Visual Studio, Git, Azure Dashboard, SSMS
Base de données : MS SQL Server
Mission : Navblue (Airbus) — N-OC Ops & Crew
Période : Avril 2023 – Juin 2026 (3 ans 2 mois)
Rôle : Développeur C# senior / Lead technique informel
Client : Navblue, filiale d'Airbus spécialisée dans les solutions logicielles pour compagnies aériennes. Déployé auprès de plus de 600 clients dans le monde, releases trimestrielles. Client direct : équipe Canada (anglophone).

Contexte :
N-OC (Ops & Crew) est un outil de planification des opérations et de gestion du personnel à destination des compagnies aériennes. Le projet couvre le développement et la maintenance de 3 APIs (2 SOAP, 1 REST). Équipe distribuée de 5 développeurs : 2 en France (dont moi), 3 en Inde. Réunions techniques avec le client 3× par semaine en anglais + réunions internes également en anglais.

Base de code d'une quinzaine d'années, solution .NET Framework 4.8 composée d'une solution Visual Studio de ~90 projets fortement couplés.

Rôle technique informel de lead (progressif, à partir de ~1 an de mission) :
Le rôle s'est construit graduellement. Le PM, développeur senior C++ côté client a commencé à solliciter mon avis sur les choix techniques et les implémentations, d'abord sur l'aspect C#, puis sur des questionnements plus généraux.
- Référent technique : questions d'architecture, revue des choix d'implémentation côté client
- Première revue des merge requests, approbation et retours structurés
- Réunions inter-équipes avec le client (Canada), restitution et priorisation côté équipe France/Inde
- Mise en place de guidelines de code communes et configuration d'éditeur partagée
- Affectation des tickets et suivi de charge
Knowledge Transfer — derniers 2 mois du projet :
Passation complète à une nouvelle équipe (développeurs canadiens et polonais). Appels quotidiens d'une heure minimum en anglais couvrant :
- Explication de l'architecture globale du projet
- Reverse shadowing : observation de la prise en main pour identifier les incompréhensions
- Explication des déploiements via TeamCity
- Réponses aux questions techniques au fil de la montée en compétences de la nouvelle équipe
Réalisations techniques :
- Migration des APIs SOAP vers REST : co-conception de l'architecture avec le tech lead client, séparation couche métier / logique, création d'une couche d'abstraction et de modèles propres
  ・Contrainte principale : l'API SOAP dispose de son propre projet, mais ses dépendances sont réparties dans ~20 autres projets (utilitaires, modèles métier, modèles API, objets Entity Framework, DataHolder…). Les projets utilisant des APIs spécifiques à .NET Framework (non compatibles .NET Standard) ne peuvent pas être consommés par un projet .NET Core — migrer l'API aurait imposé de passer l'ensemble de la chaîne de dépendances par .NET Standard en amont, rendant l'opération impraticable à cette échelle
- Distributed tracing : instrumentation avec Zipkin puis migration vers Datadog (déjà en place chez le client sur d'autres projets) — a mis en évidence des temps d'exécution bien trop longs pour un projet web standard, jusqu'alors invisibles
- Proposition de traitement asynchrone pour les requêtes longues (plusieurs minutes d'exécution) : réponse 202 Accepted, mise en queue, traitement asynchrone et notification à completion — pour découpler le temps de réponse HTTP du temps de traitement métier (non retenue, contexte organisationnel)
- Intégration RabbitMQ : mise en place d'un serveur local de test, connexion applicative aux workers, avec gestion des reconnexions et traitement des queues
- Identification d'une problématique de performance sur la pagination : SELECT complet côté serveur puis offset/skip côté client, impliquant de recharger l'intégralité du dataset à chaque page — contrainte documentée (filtres couplés aux Stored Procedures empêchant une pagination serveur)
- Documentation API via Swagger, utilisée pour les tests et validations internes- Automatisation des builds et des tests en local (Bash / hooks git), couverture de tests entre 40 et 60%
Environnement technique :**
Langages** : C#
Frameworks : .NET Framework 4.8, NUnit, MSTests
Protocoles : SOAP, REST, RabbitMQ
Outils : Visual Studio, Git, GitLab, Agility, Postman, SoapUI, Docker, Datadog, Zipkin, Swagger, TeamCity
Base de données : MS SQL Server
Méthodologie : Agile / Scrum (sprints 2 semaines)

Headcrab est un studio de développement de 2 à 7 collaborateurs réalisant des prestations B2B : applications mobiles, serious games, et projets sur mesure pour des TPE de 1 à 20 salariés.

Rôle direction :
- Co-fondateur et président : management jusqu'à 4 développeurs en simultané
- Relation client sur une trentaine de clients : avant-vente, cadrage, suivi
- Recrutement, tutorat de stagiaires et alternants
- Gestion administrative complète : fiscal, contrats, recrutement RH
Projet interne : Coming Soon
Période : 2021 – présent
Rôle : Développeur full-stack, seul
Téléchargements : ~4 000 depuis 2022, sans marketing

À l'origine, un problème concret : évaluer si un abonnement cinéma en valait la peine impliquait de savoir combien de films intéressants sortaient chaque mois — information étonnamment difficile à rassembler en un seul endroit. Coming Soon part de là : suivre d'un simple geste les sorties des films à venir et recevoir un rappel le jour J. Suite à ça, les séries et jeux vidéo ont été ajoutés à l'application. Application publiée sur l'App Store depuis 2022 ; Headcrab est devenu partenaire Twitch / IGDB dans le cadre de ce projet.

Réalisations :
- Conception complète : cahier des charges, design (Sketch), architecture, développement, déploiement
- Backend en deux services distincts — un service sert, l'autre collecte :
  - FastAPI (Python) sur GCP Cloud Run : API REST qui sert les données à l'application mobile. Déployé via un script de conteneurisation vers GCP Artifact Registry puis Cloud Run
  - Scraper/normalizer : initialement développé en C#/.NET 6 sur AWS Lambda au démarrage du projet. Migré ensuite en Python après l'arrêt du support .NET 6 sur Lambda. Il récupère les données des APIs tierces (TMDB pour les films et séries, IGDB via GraphQL pour les jeux vidéo ; TicketMaster et Eventtime pour les événements physiques, en cours de réintégration) et les normalise vers les modèles internes
  - Les deux services communiquent de façon asynchrone : EventBridge déclenche périodiquement le scraper, qui envoie les données traitées dans une queue SQS, consommée par le normalizer
- MongoDB : les entités (films, séries, jeux, événements, sorties musicales) partagent une structure commune mais ont des attributs propres à chaque catégorie (les séries ont des providers, les événements des lieux, les jeux des consoles, ...). Un schéma documentaire flexible évite de multiplier les tables ou de recourir à une hiérarchie de classes rigide. Certaines catégories (événements, musique) ont été implémentées puis temporairement rollbackées pour consolider les 3 catégories principales
- Déploiement iOS via Xcode Cloud ; backend AWS déployé via script SAM (exécution manuelle)
- Gestion des calendriers, onboarding, notifications push
Environnement technique :
Langages : Swift, Python, C#
Frameworks : SwiftUI, Swift Testing, FastAPI, .NET Core 6
Cloud AWS : Lambda, SQS, EventBridge, AWS SAM
Cloud GCP : Cloud Run, Artifact Registry
Protocoles : REST, GraphQL (consommation IGDB)
Outils : Xcode, Xcode Cloud, Git, Sketch, Postman
Base de données : MongoDB
Projet interne : Echo
Période : 2026 – présent
Rôle : Développeur full-stack, seul

Echo est une application de discussion éphémère basée sur les affinités musicales. Le parti pris : supprimer tout ce qui définit une app de rencontre classique (photo, bio, informations personnelles) pour ne garder que la musique comme signal de connexion. Les conversations sont volontairement limitées à 24 heures — une contrainte pensée pour encourager des échanges sans pression de suivi ni d'engagement. Le projet part de la conviction que partager les mêmes goûts musicaux est un lien plus sincère que de parcourir un profil.

Réalisations :
- Système de matching :
  - Signal principal : signature de playlist — représentation de l'utilisateur calculée à partir de ses 100 morceaux Apple Music (MusicKit). Initialement une signature chaînée ordonnée (pour retrouver les utilisateurs partageant les mêmes premiers morceaux) ; évoluée vers un fingerprint non ordonné pour augmenter le nombre de matchs — trop peu de correspondances exactes avec l'ordre strict
  - Identifiant canonique (`canonicalId`) calculé par morceau pour identifier un titre quel que soit le provider musical — architecture pensée pour l'ajout futur de Spotify sans refonte du matching
  - Signaux faibles comportementaux (horaires de connexion, vitesse de réponse) — prévus, non encore implémentés
- Architecture hybride :
  - API REST sur AWS : 9 Lambdas, API Gateway, EventBridge, 8 tables DynamoDB
  - Serveur WebSocket dédié sur VPS Python pour les connexions persistantes — Lambda a un timeout maximum de 15 minutes et ne maintient aucun état entre invocations ; une connexion de messagerie peut durer plusieurs heures. Un VPS déjà en place était la solution la plus simple et économique, sans la surcharge d'un EC2
- Authentification : Passkeys (WebAuthn) pour l'identité + JWT pour la gestion de session (génération, refresh, révocation, expiration, droits d'accès)
- Notifications push via AWS SNS
- Privacy first : fingerprints de playlist hachés avec poivre côté serveur — les données musicales brutes ne sont jamais stockées
- Tests unitaires sur la logique de matching et de génération de signature
- Gestion des secrets via SSM Parameter Store et variables d'environnement Lambda
Environnement technique :
Langages : Swift, Python
Frameworks : SwiftUI, Swift Testing, FastAPI
Cloud : AWS Lambda, DynamoDB, API Gateway, EventBridge, SSM Parameter Store, AWS SAM, SNS
Protocoles : REST, WebSocket, WebAuthn, JWT
Intégrations : MusicKit (Apple Music API), AWS SNS
Outils : Xcode, Git, Postman
Base de données : DynamoDB
Projet interne : DropWaste
Période : 2025 – présent
Rôle : Développeur full-stack principal (associé responsable de la partie administrative et porteur du projet)

De nombreuses communes suppriment progressivement la collecte des ordures ménagères au porte-à-porte. Pour les personnes âgées, handicapées ou sans véhicule, c'est une contrainte réelle sans solution simple. DropWaste répond à ce problème en mettant en relation ces personnes avec des collecteurs indépendants à proximité — qui se déplacent en vélo ou vélo cargo, se font un complément de revenu, et réduisent l'empreinte carbone de la collecte. Le modèle est celui d'Uber : un déposant publie une demande géolocalisée, un collecteur disponible l'accepte, effectue la collecte et fournit une preuve photo.

Réalisations :
- Architecture AWS serverless : Lambda, API Gateway, DynamoDB, FastAPI — déploiement via AWS SAM
- Recherche géospatiale via Uber H3 :
  - DynamoDB ne supportant pas les requêtes géospatiales natives (contrairement à l'index 2dsphere MongoDB), utilisation de la grille hexagonale H3 (ID de cellule stable = indexable en DynamoDB)
  - Gestion des effets de bord : stockage de la cellule parente en base, recherche sur la cellule fine de l'utilisateur + voisines de sa parente — uniformise la zone de visibilité indépendamment de la position dans la cellule
- Intégration Stripe pour les paiements entre particuliers et collecteurs
- Authentification via Passkeys (WebAuthn), JWT
- Profils distincts collecteur / déposant, géolocalisation, preuve de collecte
- Panel admin SwiftUI en parallèle de l'application mobile
Environnement technique :
Langages : Swift, Python
Frameworks : SwiftUI, Swift Testing, FastAPI
Cloud : AWS Lambda, DynamoDB, API Gateway, SSM Parameter Store, AWS SAM
Protocoles : REST, WebAuthn, JWT
Intégrations : Stripe, Uber H3, MapKit
Outils : Xcode, Git, Postman
Base de données : DynamoDB
Mission client : TalkTo (Talk Sàrl)
Période : 2022 (durée approximative : 4 mois)
Rôle : Développeur mobile & backend, en renfort
Client : Talk Sàrl, entreprise suisse de 15 personnes spécialisée dans la formation et l'IA appliquée à la formation. Partenariat avec le pôle emploi de Neuchâtel (plusieurs milliers d'utilisateurs).

TalkTo aide des personnes à améliorer leur communication orale au travers d'un programme de plusieurs semaines, avec des coaches spécialisés et un accompagnement par IA. Le partenariat avec le pôle emploi de Neuchâtel lui donnait une base d'utilisateurs réelle. Je suis intervenu en renfort sur l'équipe de développement, en contact direct avec un développeur et un ingénieur cloud.

Réalisations :
- Implémentation du workflow 2FA complet côté mobile (React Native) : TOTP, OTP par mail, OTP par SMS
- Gestion des utilisateurs et profils (étudiant / formateur) dans l'API REST Python
- Migration base de données MongoDB → Firebase Firestore : Firebase déjà utilisé pour l'authentification OTP, migration décidée pour centraliser la gestion des données utilisateur et éviter au client de maintenir une infrastructure MongoDB séparée
- Développement des endpoints API Python liés aux tâches front
Environnement technique :
Langages : JavaScript, Python
Frameworks : React Native, FastAPI
Protocoles : REST, TOTP, OTP
Outils : Postman, VS Code, Git
Base de données : MongoDB (initial), Firebase Firestore (migration)
Auth : Firebase Authentication, TOTP, OTP SMS/email
Méthodologie : Agile
Mission client : Fizzer
Période : 2021-2022 (durée approximative : 4 mois) <br />
Rôle : Développeur iOS, en renfort
Client : Fizzer, application de création de cartes postales, albums photos et faire-part personnalisés envoyés par courrier — 2 millions d'utilisateurs, équipe de 10 à 20 personnes.

Fizzer se distingue par son modèle : l'utilisateur compose un objet imprimé personnalisé depuis son téléphone, et Fizzer se charge de l'impression et de l'envoi postal. Je suis intervenu en renfort sur l'équipe iOS (binôme avec un autre développeur) pour le développement d'une nouvelle fonctionnalité d'abonnement.

Réalisations :
- Développement de la Gazette Fizzer : nouvelle offre d'abonnement mensuel permettant aux utilisateurs de faire composer et envoyer automatiquement un journal photo personnalisé chaque mois — intégration côté iOS du système d'abonnement (connexion au backend Fizzer + gestion des états d'abonnement) et de l'UI associée
- Intégration Stripe : souscription à l'abonnement, gestion des états (actif, suspendu, résilié), webhooks
- Correction de bugs sur l'application principale
- Déploiement de versions aux bêta-testeurs via TestFlight
Environnement technique :
Langages : Swift
Frameworks : UIKit, Stripe iOS SDK
Outils : Xcode, Git, TestFlight
Méthodologie : Agile
Mission client : Pôle Formation Santé
Période : 2020-2021 (durée approximative : 4 mois)
Rôle : Développeur Unreal Engine, seul développeur
Client : Pôle Formation Santé, association de 20 à 50 salariés spécialisée dans la formation sanitaire et médico-sociale. Collaboration avec un infographiste 3D et une cheffe de projet.

Serious game VR de formation pour aides-soignants, développé en période Covid-19 pour simuler des protocoles de soin en environnement virtuel (Oculus Quest).

Réalisations :
- Conception et développement du parcours de formation : déplacement guidé dans un environnement hospitalier virtuel reproduisant les protocoles de soin Covid
- Interactions VR avec les éléments de décor (matériel médical, équipements de protection)
- Système de détection d'erreurs de protocole, score final, animations de feedback
- Menus début / pause / fin, gestion des inputs VR (Oculus Quest controllers)
- Intégration des assets 3D livrés par l'infographiste
- Gestion des contraintes de déploiement et de performance sur Oculus Quest (optimisation pour standalone, sans PC)
Environnement technique :
Langages | C++, Blueprint
Outils | Unreal Engine, Oculus Quest
Mission client : Jolly Studio
Période : 2021 (durée approximative : 4 mois)
Rôle : Développeur Unreal Engine, seul développeur
Client : Jolly Studio, jeune entreprise spécialisée dans les simulations virtuelles. Collaboration avec un infographiste 2D/3D et un ingénieur immobilier.

Visite virtuelle immobilière interactive pour de l'immobilier d'entreprise. L'application permettait aux prospects de visiter un espace en 3D et de visualiser différentes configurations de mobilier et matériaux en temps réel.

Réalisations :
- Menus début de visite, pause, tutoriel ; gestion des inputs et du chargement
- Système de configurateur : changement de matériaux et couleurs des éléments de décor en temps réel (murs, sols, mobilier)
- Module photo maison : mode photo in-app avec filtres et effets Bokeh, développé en remplacement de plugins existants insuffisants
- Module d'export : upload via API REST des photos prises et de la configuration finale vers un drive partagé avec le client
- Implémentation et fix de divers plugins (météo, réseau, photo…)
- Pixel Streaming : évaluation d'une solution de streaming 3D via GCP (rendu serveur, flux vidéo interactif sans GPU côté visiteur). Identification des contraintes de rendu réaliste : éclairage dynamique et occlusion partielle (verre) — remontées au client, hors périmètre Headcrab. Proposition d'un dashboard de gestion tout-en-un (mise à jour de version, configuration min/max d'instances) — refusée pour des raisons de coût. Par la suite, intégration côté Unreal Engine avec les différents prestataires retenus par le client : écran de chargement pendant le provisionnement de la machine, envoi de signal de fin de session, réception de contenu depuis le site web via events JS
Environnement technique :
Langages : C++, Blueprint
Protocoles : REST (export photos + configuration)
Cloud : GCP (évaluation Pixel Streaming, non retenu)
Outils : Unreal Engine

TDF, studio de jeux mobiles et automobiles, 20 personnes, bureaux Lyon & Montréal. Équipe projet : 10 personnes (5 développeurs, 2 graphistes, 2 game & level designers, 1 cheffe de projet).
GT Manager — Red Bull
Jeu de gestion d'écurie automobile commandé par Red Bull, iOS / Android / PC.

Réalisations :
- Mise en place du workflow Git
- Développement de features gameplay
- Intégration UI
- Système de notifications in-game
- Système d'animation
Environnement technique :
Langages : C#
Outils : Unity, Git, Jira
Méthodologie : Agile / Scrum
F1 Delta Time — Animoca Brands
Jeu de gambling sous licence Formula 1® avec échange de NFT, commandé par Animoca Brands (société hongkongaise, CA >900M$).

Réalisations :
- Développement de features gameplay
- Intégration UI
- Automatisation des builds (Bash)
Environnement technique :
Langages : C#, Bash
Frameworks : WebGL
Outils : Unity, Git, Jira
Méthodologie : Agile / Scrum

Alternance 3 jours / semaine + vacances scolaire

Développement d'applications mobiles cross-platform en Xamarin C#, formation des nouveaux arrivants, réunions client et étude de besoin.

Environnement technique :
Langages : C#
Frameworks : Xamarin.Forms
Outils : Visual Studio, Git

PoC de modules de formation en réalité augmentée (Microsoft HoloLens) et virtuelle (HTC Vive) — Unity C#.

Environnement technique :
Langages : C#
Outils : Unity, Microsoft HoloLens, HTC Vive

GearHelper — ~400 000 téléchargements
Addon d'aide à l'optimisation d'équipement pour World of Warcraft.
RaidLogs — ~100 000 téléchargements
Outil d'analyse de performance de raid pour World of Warcraft : affiche le score d'évitement de dégâts de n'importe quel joueur directement dans les tooltips in-game, sans quitter le jeu. Initialement afficheur des données WarcraftLogs, aujourd'hui avec son propre moteur de parsing et système de scoring.

Réalisations :
- Parser CombatLog maison (Swift) : analyse single-pass du fichier `WoWCombatLog.txt` directement dans l'uploader macOS — le score est calculé localement, seul le résultat est envoyé à l'API
- Système de scoring : binaire par mécanique (pass / fail / ?) — 7 types de mécaniques configurables (avoidable, soak, proximity, mustDispel, mustInterrupt, noDispel, targeted), avec gestion des rôles requis et des poids. Score affiché = meilleur score all-time par boss / difficulté
- Pipeline de publication automatisé : soumission → Lambda (stockage MongoDB) → EventBridge (déclenchement quotidien à 4h UTC) → DBGenerator Lambda (lecture MongoDB, génération des fichiers Lua DB pour 5 régions en chaîne via SQS) → git push → CurseForge auto-release sur tag
- Déduplication par fight hash : timestamp bucket + GUIDs joueurs triés — plusieurs membres d'un même raid peuvent uploader le même combat sans doublon
- Interface admin intégrée à l'uploader macOS : gestion de la base de sorts par boss (types de mécanique, rôles, poids), sans outil séparé
Stack complète :
Addon : Lua (World of Warcraft)
Client macOS : Swift / SwiftUI + interface admin intégrée
Client Windows : Flutter
Backend : Python / FastAPI, AWS Lambda, API Gateway, SQS, EventBridge, MongoDB

Votre navigateur est obsolète !

Raphaël Daumas

Ingénieur Logiciel

Ingénieur Logiciel Senior

Développeur Fullstack & Co-fondateur

Développeur Gameplay

Développeur C#

Développeur Unity AR / VR

Projets personnels