Je travaille sur trois domaines, sans hiérarchie entre eux : le front-end (web et mobile), le back-end et l'infrastructure, la conception les traversant tous les trois. Côté serveur, deux écosystèmes plutôt qu'un : TypeScript et PHP, sans que l'un soit mon choix par défaut. Cette page détaille chaque compétence, avec la prestation associée et les articles où je la documente, parce qu'une liste de technologies ne prouve rien toute seule.
Ce que je sais faire
- Architecture
Cadrage technique, découpage en domaines, choix de stack argumentés et décisions documentées. L'objectif est qu'une équipe puisse reprendre le système sans moi.
- Systèmes distribués
Découpage en services, messagerie asynchrone (Kafka, RabbitMQ, NATS, Messenger), CQRS et architecture hexagonale, contrats inter-services versionnés, tracing distribué. Savoir découper n'oblige pas à découper : le monolithe modulaire reste souvent le bon choix.
- API REST & GraphQL
Conception de contrats explicites : versionnement, pagination, gestion des erreurs, documentation OpenAPI. Côté serveur comme côté client.
- Front-end
TypeScript avec React, Angular ou Vue, sites Astro, design systems, accessibilité WCAG 2.2 AA et Core Web Vitals tenus.
- Mobile
Applications React Native pour iOS et Android à partir d’une seule base TypeScript, et progressive web apps installables avec fonctionnement hors connexion et synchronisation différée.
- Back-end TypeScript
NestJS pour les architectures modulaires et distribuées, AdonisJS pour les monolithes structurés, Next.js côté serveur. Runtimes Node et Bun, typage strict de bout en bout, tests Vitest.
- Back-end PHP
PHP 8.4 avec Laravel et Symfony : domaine métier, jobs asynchrones, performance sous Octane ou FrankenPHP, tests Pest et PHPUnit.
- DevOps & CI/CD
Conteneurisation Docker multi-stage, pipelines GitLab CI et GitHub Actions, infrastructure décrite en code avec OpenTofu et Ansible.
- Kubernetes
Clusters Kubernetes ou k3s, packaging Helm, déploiement GitOps avec Argo CD, et self-hosting maîtrisé sur Proxmox.
- Observabilité
Instrumentation OpenTelemetry, SLO et error budgets, alerting utile, métriques DORA et postmortems blameless.
- Lead technique
Référent technique en équipe : arbitrage des choix d'architecture, revues de code, mentorat et diffusion des bonnes pratiques.
Outils du quotidien
Les technologies que j'utilise réellement en mission, regroupées par couche. Rien de déclaratif : chacune est présente dans un projet livré ou dans un article du blog.
/Front-end
/Back-end TypeScript
/Back-end PHP
/Données & messagerie
/Infra & DevOps
/Outils
Le parcours derrière
Ces compétences ne sont pas arrivées en même temps : développeur front-end pendant quatre ans, puis full-stack, puis architecte de solutions, et aujourd'hui Software Engineer Laravel chez Yield Studio en parallèle de mon activité indépendante. Le détail est sur la page à propos.
Travailler ensemble
Les douze prestations cadrées sont détaillées depuis la page d'accueil. Pour une mission, le plus rapide reste un message sur Malt ou sur LinkedIn.
/faq
On me demande souvent
Êtes-vous plutôt back-end, front-end ou DevOps ?
+
Les trois, et c'est le point. Quinze ans de développement web m'ont fait passer du front-end à l'architecture en passant par le back-end et l'exploitation. Côté serveur, je travaille sur deux écosystèmes : TypeScript avec NestJS ou AdonisJS, et PHP avec Laravel ou Symfony. Aucun n'est mon choix par défaut. Concrètement, je peux tenir une fonctionnalité du composant d'interface jusqu'à son déploiement, sans passer le relais trois fois.
N'est-ce pas trop large pour être crédible ?
+
C'est une question légitime. La réponse est dans le blog : plus de cinquante articles techniques répartis entre back-end, DevOps et front-end, écrits sur des sujets que je pratique en mission. Chaque compétence listée ici renvoie aux articles qui la documentent.
Comment choisissez-vous une technologie sur un projet ?
+
En fonction de votre équipe et de votre existant, pas de mes préférences. Une équipe déjà en TypeScript côté front n'a pas besoin qu'on lui impose PHP côté serveur, et une équipe dont la culture et les recrutements sont en PHP n'a rien à gagner à migrer vers Node. Comme je travaille sur les deux écosystèmes, l'arbitrage n'est pas biaisé par ce que je sais faire. Le rôle d'architecte consiste souvent à écarter la techno la plus séduisante au profit de celle que l'équipe saura maintenir.
Faut-il partir sur des microservices ?
+
Le plus souvent, non. Le découpage en services a un coût réel : latence réseau, cohérence des données, outillage, charge d'exploitation. Beaucoup d'équipes le paient sans en tirer le bénéfice. Je commence par un monolithe modulaire dont les frontières internes sont nettes, ce qui laisse la porte ouverte. On extrait un service quand une contrainte concrète le justifie : un cycle de déploiement indépendant, une montée en charge isolée, une équipe séparée. Quand c'est le cas, je sais le faire proprement : messagerie asynchrone, contrats versionnés et tracing distribué.
Travaillez-vous sur des stacks que vous ne connaissez pas encore ?
+
Oui, et je le dis franchement quand c'est le cas. Une veille permanente et quinze ans de pratique rendent la montée en compétence rapide sur une stack inconnue. C'est d'ailleurs comme ça que la plupart des technologies de cette page sont arrivées dans mon quotidien.