APIs, intégrations, automatisation, systèmes observables.
Aucune donnée simulée, aucun projet jouet.
J'ai commencé tôt en m'attaquant à des systèmes trop gros pour mon niveau d'alors. Pendant que beaucoup autour de moi écrivaient des CRUD basiques, j'étais obsédé par ce qui se passe vraiment derrière un produit réel : files, caches, concurrence, déploiements, sockets, infrastructure. Le tournant, ça a été le jour où j'ai arrêté de voir le backend comme «faire des APIs» et où j'ai commencé à le voir comme concevoir des systèmes qui ne s'écroulent pas quand les gens les utilisent réellement. C'est là que je me suis accroché.
Ce que je sais vient pour l'essentiel de choses cassées. Des déploiements qui ont fait tomber des services entiers, des proxies mal configurés, des bugs de concurrence impossibles à reproduire, des migrations PostgreSQL faites trop vite, des middlewares lançant des redirections absurdes en production. C'est exactement là que j'ai le plus appris. J'ai compris que je préfère largement déboguer des systèmes complexes et chasser les vrais goulots d'étranglement plutôt que construire des interfaces jolies. Comprendre pourquoi une chose échoue à bas niveau et la réparer avec élégance, c'est ce qui se rapproche le plus du flow pour moi.
Avec le temps mes projets se sont orientés vers du travail d'architecture réel : pipelines automatisés, SSE en temps réel, stacks Docker multi-services, reverse proxies nginx, scraping et systèmes de tendances, automatisation de contenu, outils internes. Les «apps génériques» ne m'ont jamais beaucoup intéressé. Je veux construire de l'infrastructure utile, rapide et stable pour des produits qui bougent vraiment.
Cette liste, c'est ce vers quoi je vais d'abord, pas ce que je tolère. Choisi par des années d'usure en production, pas en lisant des annonces.
Un petit nombre de systèmes réels, chacun en production pour des utilisateurs réels. Pas un portfolio de démos à moitié finies.
Plateforme éditoriale multi-tenant qui suit 11 sources de tendances, évalue les opportunités, génère et révise les articles, et les publie sur 13 sites de niche en 12 langues. Postgres, workers pg-boss, intégration Claude, pipelines QA maison, et un dashboard avec tail en direct de chaque file.
kramaru.esQuatre stratégies polyvps tournant 24/7 avec smart take-profit, hourly gates et circuit breakers. Argent réel, pas un backtest. Dashboard de métriques quotidien, kill-switch, audit log de chaque entrée.
Moteur de settlement de pronostics football sur OpenFootball plus enrichissement Sofascore, branché à un stack Dockerisé avec durcissement par conteneur. NGINX, Postfix, clés de chiffrement Server Actions fixées pour prévenir les attaques de replay d'en-tête après un incident passé.
POS Flutter Desktop, backend Node, MySQL, impression thermique, intégration WhatsApp. Vrais clients, offline-first.
Démo publique sur mkir.es : un seul process .NET 8 diffuse les événements de changement de base de données vers de nombreux navigateurs via Server-Sent Events. Zéro dépendance côté client, HTML brut rendant les triggers Postgres au fil de l'eau.
mkir.esLa version complète d'un projet que je résume d'habitude en une phrase. Les décisions difficiles, ce que j'ai cassé, et ce qui tourne vraiment.
TopSec existe pour agréger, synchroniser et visualiser des données en temps réel sans s'appuyer sur de l'infra géante ni des stacks trop lourds pour le produit. Le brief était simple à dire et dur à livrer : garder la donnée vivante, rapide et cohérente pendant que plusieurs services se parlent en même temps.
Tracer une ligne nette entre ce qui vit dans le backend .NET 8 et ce qui se résout depuis Next.js. Un cas subtil a rendu la ligne évidente : les routes /api plus le middleware next-intl produisaient des redirections 307 vers /es/api/*. Techniquement valide, pratiquement cassé. Endpoints temps réel et stats échouaient silencieusement selon le locale.
Le patch que personne ne te demande d'écrire est celui qui justifie le tarif de l'ingénieur : au lieu de corriger les règles de redirection une par une, j'ai réécrit le matcher du middleware pour exclure /api entièrement. Petit changement visuel, gros changement architectural.
Optimiser trop tôt est mauvais. Ignorer la performance dès le départ est pire. Principe de travail
L'autre décision : garder PostgreSQL comme source de vérité unique. Pour ce produit, la cohérence et la capacité d'écrire des requêtes complexes valaient plus que les gains de vitesse qu'on pouvait gratter avec du NoSQL. L'ennuyeux est bien quand l'ennuyeux est correct.
La production est tombée une fois parce que j'ai supposé qu'une image Docker avait vraiment été reconstruite. Le code «neuf» se comportait comme l'ancien. Le vrai coupable : npm ci échouait silencieusement parce que package-lock manquait, laissant la build incohérente. J'ai passé des heures à déboguer la logique applicative pour un problème de pipeline.
Prises de position fortes gagnées par des incidents de prod, pas sur Twitter. Si l'une te crispe, on va probablement bien s'entendre.
Savoir dire non rend le oui plus fiable. Voici les projets pour lesquels je ne serais pas le bon recrutement.
Freelance et contracting depuis 2022. Ouvert aux postes remote-first ou hybrides à Málaga et la Costa del Sol quand le projet le mérite. Pas intéressé par les environnements très corporate où l'ingénierie disparaît sous le process.
L'email reçoit la réponse la plus rapide. LinkedIn pour les introductions, GitHub pour le code.