Cas clients · Format STAR
Six histoires concrètes — situation, action, résultat.
Pas des accroches commerciales. Pas de chiffres inventés. Chaque cas part d'un problème réel, défend une décision d'architecture qui a coûté quelque chose, et termine sur des métriques publiques vérifiables.
Format STAR (Situation, Task, Action, Result) — le format de référence pour les entretiens techniques senior.
Le framework C# / C++ que Rockstar Games a racheté
5 ans en production, 250 connexions concurrentes, 15 personnes encadrées
Situation— le contexte qui rendait le projet difficile
À 19 ans, je voulais comprendre comment un serveur multijoueur tient 250+ joueurs en simultané. Personne autour de moi ne savait l'expliquer. Le marché en 2016 était cadenassé par des middlewares propriétaires payants. Aucune base ouverte pour bâtir un framework de jeu en C# avec un protocole réseau optimisé.
Task— ce que le projet exigeait précisément
Concevoir from scratch un framework multijoueur C# / C++ capable d'encaisser 30 000+ comptes, 250 connexions concurrentes en continu, avec déploiement live sans interruption. Et le maintenir 5 ans en production avec une équipe de 15 personnes.
Action— ce que j'ai fait, décision par décision
- Conçu une architecture client-serveur autoritaire avec sérialisation binaire propriétaire (protobuf-net + UDP custom via Lidgren) — réduction de la bande passante d'un facteur 4 vs JSON sur TCP
- Bâti la stack CI/CD complète (build, test, deploy, rollback) — mises à jour live sans interruption pour 250 connexions actives, opérées toutes les semaines pendant 5 ans
- Implémenté le monitoring proactif (CPU, RAM, sockets, taux de perte) avec autoscaling automatique sur les pics d'affluence
- Recruté, formé et dirigé une équipe de 15 personnes (devs, designers, QA, modérateurs) sans diplôme de management — la discipline a été imposée par la livraison hebdomadaire devant des utilisateurs réels
- Documenté l'architecture pour que le système puisse survivre à mon départ — ce qui s'est avéré décisif
Result— mesures, pas adjectifs
- 30 000+ comptes créés, 250 connexions persistantes concurrentes sans panne critique sur 5 ans
- Mon départ en 2021 a été sans impact opérationnel — l'équipe a continué d'opérer 2 ans avant la cession
- En 2023, la technologie réseau a été fusionnée avec un concurrent puis acquise par Rockstar Games (après mon départ)
- Sans diplôme d'ingénieur, sans investisseur, sans agence — juste 5 ans de production continue
Le trade-off que j'ai défendu
J'ai choisi un protocole binaire propriétaire vs HTTP/REST. Coût : la communauté open source ne pouvait pas contribuer facilement. Bénéfice : ×4 sur la bande passante et une latence sub-100 ms qui a permis le scale que le projet a atteint.
Firmware IoT déployé sur 150 000 systèmes par an
Du capteur 256 KB RAM au dashboard cloud, sans rupture
Situation— le contexte qui rendait le projet difficile
Gecko Alliance est leader mondial des systèmes de contrôle pour spas connectés — 30-40 % du marché global, 100+ OEM clients. En 2023, ils lançaient leur plateforme IoT cloud-native. Aucune équipe existante ne couvrait l'ensemble de la chaîne firmware → cloud → mobile, ce qui obligeait les sprints à se coordonner entre 3 équipes séparées et à perdre du temps sur les contrats d'interface.
Task— ce que le projet exigeait précisément
Intervenir comme dev full-stack IoT capable de prendre des décisions sur l'ensemble de la chaîne. Spécification, firmware embarqué C / FreeRTOS sur microcontrôleurs contraints (< 256 KB RAM), pipeline cloud AWS IoT Core / Lambda / DynamoDB, et applications mobiles de contrôle. Cible : 150 000+ systèmes produits/an déployés en production.
Action— ce que j'ai fait, décision par décision
- Co-conçu le firmware embarqué en C / FreeRTOS avec optimisation stricte de l'empreinte mémoire (heap profiling, suppression des malloc dynamiques sur les hot paths, watchdog hardware)
- Architecturé les pipelines de télémétrie haute fréquence MQTT → AWS IoT Core → Lambda → DynamoDB — ingestion sans perte de paquets sur des bursts d'usage en heure de pointe
- Implémenté les mises à jour OTA des firmwares avec rollback automatique sur signature corrompue ou checksum invalide
- Développé l'app mobile de contrôle qui parle au backend cloud et au spa local en Bluetooth Low Energy (fallback si pas de Wi-Fi)
- Imposé une discipline d'observabilité (Serilog → CloudWatch) qui a permis de diagnostiquer les failures de production à distance plutôt que d'envoyer un technicien chez le client
Result— mesures, pas adjectifs
- Firmware déployé sur 150 000+ systèmes IoT produits par an, en chaîne de production 24/7
- Ingestion télémétrie sans perte de paquets validée sur 6 mois de prod
- Time-to-diagnose des incidents firmware divisé par 3 grâce à l'observabilité distribuée
- Onboarding d'un nouveau dev sur la chaîne IoT réduit de 4 semaines à 1 grâce à la doc d'archi unifiée
Le trade-off que j'ai défendu
J'ai défendu le choix de DynamoDB vs un time-series DB dédié (TimescaleDB) sur la télémétrie — coût opérationnel et complexité jugés trop élevés vs le besoin réel d'agrégat. Bénéfice : 1 seul service AWS à opérer, scaling automatique. Coût accepté : si Gecko monte à 10× le volume actuel, il faudra rebasculer.
Apps terrain utilisées par 250 000+ techniciens télécoms
Offline-first, BLE bas niveau, 100 pays, 95 des 100 plus grands opérateurs
Situation— le contexte qui rendait le projet difficile
EXFO est la référence mondiale du test télécoms — 2 000+ clients, présent dans 100 pays. Leurs techniciens fibre / 5G travaillent sur le terrain, souvent sans réseau, et doivent communiquer en Bluetooth Low Energy avec des appareils de mesure propriétaires. Tolérance zéro à la perte de données terrain — un test raté = un déplacement à refaire à 200 € la visite.
Task— ce que le projet exigeait précisément
Rejoindre l'équipe mobile pour développer / maintenir les apps Flutter / C# utilisées par 250 000+ techniciens. Intégrer les nouveaux protocoles BLE bas niveau pour la prochaine génération d'appareils de mesure. Garantir l'intégrité offline et la sync bidirectionnelle au retour réseau.
Action— ce que j'ai fait, décision par décision
- Intégré les protocoles Bluetooth Low Energy + Wi-Fi bas niveau pour la communication directe avec les appareils de mesure propriétaires — reverse engineering partiel du protocole legacy
- Contribué à l'architecture offline-first avec sync bidirectionnelle au retour réseau, sans perte de mesure même sur 8 h en zone blanche
- Renforcé les tests d'intégration BLE en simulation (mock du firmware côté Dart) — pas besoin du matériel physique pour la CI
- Documenté les patterns de comm BLE pour que les futures features ne réinventent pas la roue à chaque nouveau modèle d'appareil
Result— mesures, pas adjectifs
- Apps déployées dans 100 pays, utilisées par 250 000+ techniciens en quotidien
- Aucune régression sur les patterns BLE existants pendant l'intégration de la nouvelle génération d'appareils
- Couverture des tests d'intégration BLE passée de manuelle à automatisée sur la CI
Le trade-off que j'ai défendu
J'ai poussé pour étendre l'offline-first à toutes les nouvelles features par défaut, même quand le scope initial demandait juste "online avec cache". Coût : sprint allongé de ~20 %. Bénéfice : 0 régression terrain sur la zone fibre rurale, où les techniciens ont confirmé que c'était "le seul outil qui ne les lâche jamais".
OneRP — 2 048 connexions concurrentes en sub-milliseconde
Zéro REST entre domaines, 1 150+ tests, 16 analyseurs Roslyn custom
Situation— le contexte qui rendait le projet difficile
Toutes les plateformes de jeu multijoueur classiques empilent les API REST jusqu'à ce que la latence cumulée tue l'UX. À 2 000+ joueurs, ça écroule l'infra. Je voulais prouver qu'une architecture Event-Driven pure (zéro REST entre domaines) pouvait tenir le scale sans compromettre la simplicité côté front.
Task— ce que le projet exigeait précisément
Concevoir une plateforme SaaS multi-tenant Event-Driven en .NET 9/10 supportant 2 048 connexions persistantes concurrentes en latence sub-milliseconde. La même architecture doit servir le jeu, le backoffice et 48 mini-applications React intégrées au jeu (police, économie, drogues, justice…).
Action— ce que j'ai fait, décision par décision
- Architecture lock-free avec 51 ComputeServices ActualLab.Fusion (lecture réactive) + CommandHandlers (écriture) via Fusion RPC WebSocket binaire MessagePack — zéro endpoint REST entre domaines
- Zero-allocation sur les hot paths (Span<T>, Memory<T>, pooling explicite) — le GC ne se déclenche jamais pendant les frames de synchro
- Conçu 16 analyseurs Roslyn custom (ONERP001-016) qui forcent les patterns Fusion au niveau du compilateur — un nouveau dev ne peut littéralement pas écrire de code incompatible
- Dev harness propriétaire : tester les 48 NUI React + 68 callbacks dans Chrome sans lancer le jeu — gain estimé 10 h / semaine par dev
- Génération automatique C# DTO → TypeScript pour synchroniser backend et frontend
Result— mesures, pas adjectifs
- 2 048 connexions lock-free concurrentes, latence sub-milliseconde mesurée
- 1 150+ tests cumulés (xUnit + Vitest + Playwright)
- Pattern réutilisé sur 3 SaaS depuis (SaleCast, PromptVault, Racine) — gain de temps de dev divisé par 2 sur l'archi initiale
- Onboarding d'un nouveau dev sur la stack Fusion réduit à 2 jours grâce aux analyseurs Roslyn
Le trade-off que j'ai défendu
J'ai choisi Fusion vs SignalR malgré la documentation Fusion plus rare. Coût : courbe d'apprentissage de 2-3 semaines pour un dev .NET classique. Bénéfice : invalidation réactive automatique multi-serveur que SignalR ne fournit pas — gain estimé 30 % de code en moins côté front.
PromptVault — Anonymisation PII réversible pour LLM
13 types détectés, 4 plateformes IA, 100 % en .NET
Situation— le contexte qui rendait le projet difficile
Les boîtes françaises utilisent massivement ChatGPT / Claude / Gemini en interne, et chaque jour des emails clients, IBAN, numéros CB partent vers OpenAI sans contrôle. C'est un risque RGPD qu'aucun DPO ne peut accepter. Aucun outil sur le marché en 2025 ne masquait les PII de manière réversible avec restitution dans la réponse du LLM. Et la majorité des outils GenAI sont en Python, donc impossible à plugger dans un legacy .NET.
Task— ce que le projet exigeait précisément
Concevoir une plateforme SaaS de gouvernance IA 100 % en .NET avec : pipeline d'anonymisation PII réversible (13 types), extensions Chrome + VS Code, support multi-LLM (ChatGPT, Claude, Gemini, Mistral), conformité RGPD démontrable.
Action— ce que j'ai fait, décision par décision
- Pipeline d'anonymisation : détection regex + ML.NET pour les noms propres → remplacement par tokens irréversibles côté navigateur → restitution dans la réponse via surveillance DOM
- Stack Blazor SSR + ActualLab.Fusion 9 pour l'admin, .NET 10 backend, Microsoft Semantic Kernel + MEAI pour l'orchestration LLM
- Extensions Chrome (Preact 10, Manifest V3) + VS Code (TypeScript) partageant la même librairie de détection PII via WASM
- 34 modules métier (audit, marketplace de prompts, chaînes de prompts, ROI tracking) montés sur la même architecture Event-Driven que OneRP
- Tests d'intégration sur les 4 plateformes IA pour valider que les réponses ne fuitent jamais les vraies données
Result— mesures, pas adjectifs
- 13 types PII détectés et masqués en temps réel sur 4 plateformes IA
- 100 % des données sensibles restent dans le navigateur — aucun appel sortant non anonymisé
- Architecture .NET pure — aucun service Python à opérer / monitorer / sécuriser en parallèle
- Le pattern d'extension Chrome (1 codebase, 4 sites cibles) est devenu une lib réutilisable interne
Le trade-off que j'ai défendu
J'ai défendu de garder la détection PII 100 % côté navigateur (vs serveur) malgré le coût de portage en WASM. Coût : un peu de complexité initiale de build. Bénéfice : les données ne quittent jamais l'ordinateur de l'utilisateur — pas de point de défaillance unique côté serveur, et un argument RGPD béton à présenter au DPO.
Poisson Engine — 100 000 entités à 60 FPS dans un navigateur
Publié npm, 60× plus rapide que CPU, dégradation gracieuse
Situation— le contexte qui rendait le projet difficile
Tout le monde dit que "le web est lent pour les simulations". Avec WebGPU stabilisé en 2024, c'est devenu faux — mais quasiment personne ne le sait. Je voulais publier une preuve open source : 100 000 agents autonomes simulés à 60 FPS dans un onglet Chrome, sans appel serveur, sans WASM, juste du WebGPU pur.
Task— ce que le projet exigeait précisément
Construire un moteur de simulation WebGPU + WGSL, publier en package npm réutilisable, supporter la dégradation gracieuse (WebGPU → WebGL → Canvas2D) pour la compatibilité, viser 100 000 entités à 60 FPS sur un MacBook récent.
Action— ce que j'ai fait, décision par décision
- Pipeline GPU en 8 passes séquentielles dans un seul batch — zero allocation pendant la simulation
- Recherche de voisins par partitionnement spatial parallèle à 3 niveaux (algorithme académique adapté pour compute shader)
- 5 niveaux de détail (LOD) selon la distance — rendu précis au premier plan, densité agrégée en arrière-plan
- Détection automatique du matériel : bascule WebGPU → WebGL → Canvas2D selon ce qui est dispo
- Génétique optionnelle : chaque entité a un génome (vitesse, perception, taille), évolution par sélection naturelle — tout sur GPU
Result— mesures, pas adjectifs
- 100 000 entités à 60 FPS constants validé sur MacBook M3 Pro
- 60× plus rapide que l'implémentation CPU équivalente
- 70 tests automatisés couvrant la correctness du partitionnement spatial (validation cross-renderer)
- Publié en package npm — réutilisable pour boids, écosystèmes, multi-agents, RTS
Le trade-off que j'ai défendu
J'ai choisi de publier en npm sans CDN distribué (pas de jsDelivr / unpkg manuels). Coût : adoption plus lente. Bénéfice : pas de dépendance externe au moment de l'import, le bundle reste minimal et auditable.
Votre cas ressemble à l'un des six ?
Le premier échange est gratuit et sans engagement — on regarde ensemble si l'archi a une issue propre, et si je suis le bon profil.