Développeur Node.js freelance à Strasbourg

Je suis Arnaud, développeur back-end Node.js freelance basé à Strasbourg. Je conçois des API et des services TypeScript qui restent lisibles quand l’équipe grandit : typés strictement, testés, instrumentés, et déployés par les mêmes mains qui les ont écrits.

Quinze ans de développement web m’ont appris que la qualité d’un back-end ne tient pas au runtime choisi, mais à la netteté de ses frontières : contrats d’API explicites, domaine métier isolé, effets de bord identifiés.

Mes prestations back-end Node.js

API NestJS modulaires : injection de dépendances, DTO validés, documentation OpenAPI générée.
Services distribués avec @nestjs/microservices : Kafka, RabbitMQ, NATS ou gRPC selon le transport pertinent.
Monolithes AdonisJS structurés, pour les équipes qui veulent la productivité Laravel en TypeScript.
Back-end Next.js : route handlers, rendu serveur, frontière client/serveur maîtrisée.
Migration JavaScript → TypeScript strict, avec tests Vitest et typage de bout en bout.

Choisir Node ou PHP selon votre contexte

Je travaille sur les deux écosystèmes back-end, et c’est précisément ce qui rend l’arbitrage honnête. Une équipe déjà en TypeScript côté front gagne à garder le même langage côté serveur : un seul modèle de données partagé, une seule chaîne d’outillage, pas de traduction mentale à chaque aller-retour. Une équipe dont la culture, les recrutements et l’existant sont en PHP n’a rien à gagner à migrer. La modernisation passe alors par Laravel ou Symfony.

Le mauvais critère, c’est ma préférence. Le bon, c’est ce que votre équipe saura faire évoluer dans trois ans. Ce raisonnement fait partie de mon travail d’architecte de solutions.

Le même TypeScript des deux côtés

Comme j’interviens aussi comme développeur front-end, je conçois le contrat d’interface des deux côtés à la fois. Les types du back deviennent ceux du front, les erreurs d’intégration se voient à la compilation plutôt qu’en recette, et il n’y a plus de partie adverse à qui renvoyer le bug.

Pourquoi un développeur Node.js à Strasbourg

Strasbourg et le Grand Est comptent des éditeurs SaaS et des équipes produit dont le front est déjà en TypeScript, mais dont le back-end est resté un assemblage de scripts Node non typés. Être sur place simplifie les ateliers de cadrage et les revues d’architecture. Et comme le développement back-end se pilote très bien à distance, j’interviens tout aussi sereinement en full remote partout en France.

Ressources et articles utiles

Questions fréquentes

NestJS ou AdonisJS, lequel choisir ?

Deux cultures, pas un classement. NestJS vise les architectures structurées et distribuées : modules, injection de dépendances, CQRS, microservices. AdonisJS applique la logique « convention plutôt que configuration » et convient aux monolithes SaaS ou back-office portés par une petite équipe. Le choix se fait sur la culture de votre équipe, pas sur un benchmark.

Faites-vous des architectures microservices en Node ?

Oui, avec `@nestjs/microservices` et les transports adaptés : Kafka, RabbitMQ, NATS ou gRPC. Mais découper est une décision coûteuse : je commence par un monolithe modulaire dont les frontières sont nettes, et je n'extrais un service que quand une contrainte réelle le justifie (cycle de déploiement, montée en charge isolée, équipe séparée).

Next.js peut-il servir de back-end ?

Pour un produit dont le front est déjà en Next, oui : route handlers, server actions et rendu serveur suffisent souvent à porter le domaine métier. Dès que la logique métier dépasse le périmètre de l'interface, ou qu'un second client la consomme, une API dédiée en NestJS devient le bon découpage.

Pouvez-vous reprendre une codebase JavaScript existante ?

Oui, et c'est le cas le plus fréquent. Migration progressive vers TypeScript strict, typage des frontières d'abord (API, base de données, entrées utilisateur), couverture Vitest au fur et à mesure. La réécriture complète reste un dernier recours, rarement le bon.

Déployez-vous aussi les applications Node que vous développez ?

Oui. Images Docker multi-stage, pipelines GitLab CI ou GitHub Actions, déploiement sur Kubernetes et instrumentation OpenTelemetry. Le service livré est un service qui tourne en production et qu'on peut observer, pas un dépôt Git.