Bonjour, je suis Edouard.
Développeur web full-stack, en Wallonie. Je travaille seul sur chaque projet : c’est un choix, et il a ses limites autant que ses avantages.
J’ai appris le web par le serveur — PHP et MySQL — avant de passer à JavaScript, puis à TypeScript. Ce détour a laissé une habitude tenace : je commence par les données. Tant que le modèle ne tient pas debout, il est trop tôt pour dessiner un écran.
Aujourd’hui je construis des API en Node.js, je les adosse à des bases MariaDB et je monte les interfaces en SvelteKit. Autour, ce qu’il faut pour que le tout tourne ailleurs que sur ma machine : conteneurs, serveur frontal, déploiement automatisé.
Le reste du métier n’est pas technique. Traduire un besoin exprimé en langage courant, dire quand une idée coûtera plus qu’elle ne rapportera, livrer quelque chose qui reste reprenable sans moi : c’est là que se joue la différence entre un projet livré et un projet utile.
Ce que j’aime développer
Trois choses qui me tiennent
La question du langage vient assez loin derrière.
Les applications qui gèrent de vraies données
Des utilisateurs, des rôles, des relations entre les tables, des cas limites. C’est la partie du travail que je préfère, et de loin.
Les API qu’on peut lire
Des ressources nommées sans détour, des codes de statut qui disent la vérité, une validation en entrée de route. Rien d’héroïque, mais six mois plus tard on s’y retrouve encore.
Les environnements reproductibles
Un dépôt cloné, une commande, et le projet tourne — base comprise. Le temps passé à conteneuriser se rattrape dès la deuxième machine.
Ma philosophie
Quatre règles que je m’applique
Elles ne sont pas décoratives : ce site les respecte toutes.
01
Le schéma avant le composant
Les contraintes vivent dans la base : clés étrangères, unicité, valeurs obligatoires. Ce que la base refuse, aucune couche au-dessus n’a besoin de le vérifier deux fois.
02
Une dépendance doit se mériter
Je mesure avant d’ajouter. Sur ce portfolio, une bibliothèque de dialogue coûtait 18 ko compressés pour ce que l’élément <dialog> natif fait sans un octet : elle a sauté.
03
L’accessibilité n’est pas une finition
Contrastes calculés plutôt qu’appréciés à l’œil, navigation clavier complète, mouvement désactivable. Ce sont des décisions à prendre au début du projet.
04
Ce qui n’est pas vérifié n’est pas terminé
Types stricts, lint et build en échec bloquant. Sur ce site, un lien mort ou une ancre absente suffit à faire échouer la compilation.
Le plus parlant reste ce qui a été construit.
Chaque réalisation détaille le besoin de départ et les décisions prises pour y répondre.