Ritchie Dagonia, 19 ans, développeur web front-end à Lyon
Je suis Ritchie Dagonia, 19 ans, développeur web front-end à Lyon. Je débute ma vie professionnelle, et je la débute ici, entre un éditeur de code, un navigateur ouvert sur ses outils de développement et les quais de la ville. Ce site est mon coin à moi : j'y raconte comment je travaille, ce que j'aime dans ce métier et ce que j'apprends en ce moment, c'est-à-dire beaucoup.
Mon quotidien de développeur front-end
Du HTML, du CSS, du JavaScript, et beaucoup de navigateur.
Mon quotidien, c'est du HTML, du CSS et du JavaScript, le plus souvent en TypeScript et avec React. Je suis jeune dans le métier, mais on me confie déjà des composants complets, de la maquette jusqu'à la mise en ligne, et c'est exactement ce que je voulais. Une journée type commence par un café et la lecture des retours de la veille : une revue de code à traiter, une remarque d'accessibilité, une animation qui saccade sur mobile. Ensuite j'ouvre l'éditeur et j'avance composant par composant.
L'intégration de maquettes occupe une bonne partie de mon temps. Je reçois un design, je le découpe en composants, je définis les espacements et les tailles de texte en variables, puis je construis la mise en page en flexbox ou en grille. Je vérifie le responsive au fur et à mesure, du plus petit écran au plus grand, plutôt que d'empiler des media queries à la fin.
Le reste de la journée se partage entre l'écriture de tests, la revue du code des autres et les petites optimisations de performance : une image trop lourde, un script chargé trop tôt, un rendu qui se déclenche pour rien. Ce sont des tâches modestes, prises une par une, mais mises bout à bout elles font la différence entre une interface agréable et une interface qu'on subit.
Comment je travaille
À 19 ans, je n'ai pas encore des années de recul, alors je compense par la méthode.
Ma façon de travailler tient en quelques habitudes. D'abord, je lis la maquette en entier avant d'écrire une ligne, pour repérer ce qui se répète et ce qui va poser problème. Ensuite je commence par la structure HTML, la plus sémantique possible : des titres dans l'ordre, des listes quand ce sont des listes, des boutons quand ce sont des boutons. Le CSS vient après, et le JavaScript en dernier, seulement là où il apporte vraiment quelque chose.
Mes outils sont simples : un éditeur de code, Git pour versionner et relire mes changements, et le navigateur avec ses outils de développement ouverts en permanence. L'inspecteur, l'onglet performance et l'arbre d'accessibilité m'apprennent plus que n'importe quelle extension. Je fais des commits petits et fréquents, avec des messages qui expliquent le pourquoi, parce que c'est ce que j'aimerais lire en revue de code six mois plus tard.
Avant de considérer qu'une fonctionnalité est terminée, je passe une liste de contrôle : navigation au clavier, contrastes, textes alternatifs, comportement à 400 pixels de large, zoom à 200 %, aucune erreur dans la console. Ce n'est pas glamour, mais ça m'évite beaucoup de retours, et quand on débute, chaque retour évité est une petite victoire.
- lire toute la maquette avant de coder
- HTML sémantique d'abord
- CSS ensuite, JS seulement si besoin
- commits petits, messages clairs
- clavier, contrastes, zoom, console
- demander une relecture, toujours
Mes compétences
Une estimation honnête, revue au fil des mois. Les barres montent, c'est le but.
-
HTML sémantique solide
Structure, balises justes, formulaires accessibles, microdonnées.
-
CSS moderne solide
Grille, flexbox, variables, animations, container queries, responsive.
-
JavaScript / TypeScript à l'aise
Modules, asynchrone, manipulation du DOM, typage progressif.
-
React à l'aise
Composants, hooks, gestion d'état légère, rendu conditionnel propre.
-
Accessibilité en progression
ARIA avec parcimonie, navigation clavier, tests au lecteur d'écran.
-
Performance en progression
Core Web Vitals, poids des images, chargement différé, rendu critique.
-
Tests en progression
Tests unitaires, tests de composants, quelques tests de bout en bout.
-
Outils du quotidien
Ce que j'ouvre chaque jour, sans exception.
Ce que j'aime dans le front-end
J'aime le front-end parce que c'est la partie du code qu'on peut toucher. Un changement de CSS, un rafraîchissement, et le résultat est là, sous les yeux. J'aime aussi que ce soit un métier à la frontière : entre le design et la technique, entre ce que veut la personne qui utilise le site et ce que permet le navigateur.
Ce qui me plaît le plus, c'est le moment où une interface devient évidente. Quand les espacements sont justes, que les transitions sont douces, que le focus est visible et qu'on ne se demande plus où cliquer. Et j'ai un faible pour les animations CSS bien dosées : une transition de deux cents millisecondes sur un bouton, un léger décalage à l'apparition d'une carte, rien de plus.
Le front-end, c'est aussi un domaine qui bouge sans arrêt. Ça peut faire peur quand on commence, mais j'ai fini par le voir autrement : c'est la garantie de ne jamais m'ennuyer, et c'est plutôt un avantage d'arriver dans le métier avec l'envie d'apprendre tout le temps.
Ce que j'apprends en ce moment
Trois sujets à la fois, pas plus, sinon je n'avance sur rien.
Le premier, ce sont les nouveautés CSS : les container queries, l'imbrication native, les propriétés logiques et les animations pilotées par le défilement. Je refais de vieux composants avec ces outils pour voir ce qu'ils simplifient vraiment, et la réponse est souvent « beaucoup ».
Le deuxième, c'est Vue. Je travaille surtout avec React, mais je trouve utile de comprendre une autre manière de penser les composants et la réactivité. Cela m'aide à distinguer ce qui relève du framework de ce qui relève du web lui-même, et c'est cette base que je veux solide.
Le troisième, ce sont les tests. J'écris de plus en plus de tests de composants qui imitent une vraie personne : cliquer, taper, naviguer au clavier. Ils sont plus longs à écrire, mais ils attrapent des bugs que les tests unitaires ne voient pas, et ils me rassurent avant chaque mise en ligne.
Ma vie à Lyon
Une ville à taille de vélo, avec des pentes pour se réveiller.
J'ai choisi Lyon pour commencer ma vie d'adulte et de développeur, et je ne le regrette pas. La ville est assez grande pour offrir de vrais projets web, et assez compacte pour tout faire à vélo. Le matin, je descends les pentes en roue libre ; le soir, je les remonte en soufflant, ce qui remplace avantageusement une salle de sport.
Je travaille souvent en télétravail depuis un café, avec le casque sur les oreilles et l'ordinateur branché sur une prise repérée d'avance. Quand j'ai besoin de bouger, je prends le métro pour changer de coin, ou je m'installe sur les quais avec un carnet pour dessiner des composants avant de les coder. Le fleuve aide à réfléchir, surtout quand un bug résiste.
Les bouchons lyonnais font partie du décor : une bonne assiette le vendredi midi, et l'après-midi devient un peu plus lent. Lyon, c'est aussi une ville où l'on croise beaucoup de gens qui font le même métier, ce qui rend les discussions techniques faciles à trouver quand on débute et qu'on a des questions. Je n'ai pas prévu de changer de ville.
- les pentes à vélo, dans les deux sens
- un café avec une prise et une bonne connexion
- les quais pour réfléchir sans écran
- le métro quand il pleut
- un bouchon le vendredi midi
Mes conseils pour débuter en front-end
Je débute moi-même, alors ce sont simplement les conseils qui m'ont le plus servi ces derniers mois.
- Commencez par le HTML, vraiment. Apprenez les balises et leur sens avant de toucher à un framework. Une page bien structurée est déjà à moitié accessible.
- Apprenez le CSS comme un langage. Pas comme une liste de propriétés : comprenez le flux, le modèle de boîte, flexbox et grid, et le reste vient tout seul.
- Ouvrez les outils de développement tous les jours. Inspectez les sites que vous aimez, modifiez leur CSS en direct, regardez ce qui se charge et dans quel ordre.
- Construisez de petits projets que vous finissez. Un projet terminé et modeste vaut mieux que dix projets ambitieux abandonnés. Ce sont eux qui m'ont ouvert des portes.
- Testez au clavier et avec un lecteur d'écran. Vous découvrirez des problèmes que vous n'auriez jamais vus à la souris, et vous les corrigerez tôt.
- Faites relire votre code. La revue de code est la meilleure école que je connaisse : on y apprend plus vite qu'en lisant seul dans son coin.
J'ai grandi face à l'océan, entre Landes et Pays basque, et j'y retourne surfer dès que je peux : mon carnet de surf.
