Raphaël Daumas
Ingénieur Logiciel
C#
Unity
SwiftUI
Python
31 ans
Permis de conduire
Situation professionnelle
En poste
En recherche active
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é.
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é.
Développeur Fullstack & Co-fondateur
Headcrab
Depuis février 2020
- 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
- Co-fondateur et président : management jusqu'à 4 développeurs en simultané
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
-
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
-
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
- Conception complète : cahier des charges, design (Sketch), architecture, développement, déploiement
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
- 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
-
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
- API REST sur AWS : 9 Lambdas, API Gateway, EventBridge, 8 tables DynamoDB
-
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
-
Système de matching :
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
- 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)
- 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
- Architecture AWS serverless : Lambda, API Gateway, DynamoDB, FastAPI — déploiement via AWS SAM
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
- Implémentation du workflow 2FA complet côté mobile (React Native) : TOTP, OTP par mail, OTP par SMS
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
- 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
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
- Conception et développement du parcours de formation : déplacement guidé dans un environnement hospitalier virtuel reproduisant les protocoles de soin Covid
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- Menus début de visite, pause, tutoriel ; gestion des inputs et du chargement
