Fedi Dayeg, développeur full-stack en France

Je commence par comprendre la contrainte qui compte vraiment : l'échéance, le système historique que personne ne veut toucher, le pic de trafic qui casse tout. Les choix d'architecture en découlent, et non d'une préférence pour tel ou tel framework.

Concrètement, j'écris du code que le développeur suivant peut lire, je garde le modèle de données honnête, et je rends les modes de défaillance visibles au lieu de les masquer dans un bloc catch. Sur un projet long, l'essentiel de la valeur se joue dans la seconde moitié — quand le code doit continuer d'évoluer sans casser.

Next.js et React avec TypeScript sont ma stack par défaut, et j'ai également livré des interfaces en production en Angular et en Vue.js. Ce qui m'intéresse, c'est ce que l'utilisateur ressent : la vitesse d'affichage du premier écran, la réactivité de l'interface pendant le chargement des données, et l'utilisabilité au clavier comme au lecteur d'écran.

NestJS et Spring Boot pour les services, MongoDB et MySQL pour le stockage, REST ou GraphQL selon les besoins réels des clients de l'API. J'utilise des files de messages comme RabbitMQ quand un traitement gagne à être découplé plutôt que rendu synchrone et fragile.

Je conteneurise avec Docker, je déploie sur Kubernetes et j'automatise les releases avec GitHub Actions pour que la mise en production devienne un non-événement. Sentry et Datadog sont branchés tôt, parce qu'une erreur qu'on ne voit jamais est une erreur qu'on ne corrige jamais.

Un site rapide et un site trouvable sont le même problème d'ingénierie vu sous deux angles : du vrai rendu serveur, des ressources maîtrisées, un balisage sémantique propre et des données structurées. Je traite les Core Web Vitals comme une contrainte de développement, pas comme un nettoyage post-lancement.