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é.
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%