À quoi ressemblera mon quotidien dans votre équipe.

Les premiers jours sur une base inconnue, je ne lis pas le code au hasard. Je pars d'une fonctionnalité que je peux exécuter et je la suis de bout en bout : la route, le contrôleur, le modèle, la requête, le rendu. Une traversée complète apprend plus que dix fichiers survolés.

Ensuite je cherche où le code fait mal, en regardant l'historique plutôt que le code. Les fichiers les plus modifiés sont ceux que l'équipe redoute : ce sont eux qu'il faut comprendre en premier, et ceux où il faut avancer lentement.

Ma première contribution est volontairement petite. Pas par prudence excessive, mais parce qu'une petite pull request valide tout le reste : que j'ai compris les conventions, que je sais faire tourner les tests, que le déploiement passe. Après seulement, je prends des sujets larges.

Et je ne réécris pas ce que je ne comprends pas encore. Une ligne étrange a souvent une raison qui n'est plus dans le code mais dans la tête de quelqu'un. Je demande avant de supprimer.

J'utilise les outils d'assistance au quotidien, et j'en ai construit. Le plus abouti est un agent de veille en lecture seule : il croise des discussions techniques avec une carte de compétences dérivée de mon propre historique git, va chercher la réponse dans le code, et produit un brouillon sourcé que je valide ou rejette.

Ce qui m'intéresse dans ces outils, ce n'est pas le gain de vitesse, c'est la façon de les contenir. Sur cet agent : une liste blanche de douze outils de lecture contre une liste noire de quinze outils d'écriture, appliquée au lancement du processus - il ne peut physiquement pas envoyer un message ni écrire un fichier. Une section anti-injection dans le prompt. Une passe adversariale obligatoire avant chaque sortie.

Sur un autre outil, un générateur de supports de revue, la règle est qu'aucun bloc de code ne peut sortir s'il ne provient pas du diff réel, et un validateur bloque le rendu tant qu'il ne passe pas.

Le principe est le même que pour une dépendance tierce : on ne fait pas confiance, on encadre. C'est ce qui permet d'aller vite sans ramener dans le dépôt du code que personne n'a lu.

Je livre petit et souvent : mes pull requests font deux à cinq fichiers en médiane. Une PR qui touche trois sujets ne se relit pas, elle s'approuve par fatigue. Je préfère en ouvrir trois.

Je découpe un gros chantier en étapes lisibles : le helper, puis l'interface, puis le branchement aux données, puis les tests.

La description dit ce que ça change et pourquoi, pas ce que le diff montre déjà. S'il y a une décision discutable, je l'écris dans la PR plutôt que d'attendre qu'on la trouve.

D'une revue, j'attends qu'on discute les décisions, pas la syntaxe : le formatage est un travail d'outil, pas de relecteur.

Je teste systématiquement la logique pure et les zones à risque : mes helpers, mes hooks et mes transformations arrivent avec leur fichier de test à côté. Côté back, je couvre les contrôleurs, les jobs et les exportateurs.

Je mets l'effort là où il paie : les cas limites et les chemins critiques sont couverts. Sur les composants purement visuels, je m'appuie sur la documentation interactive, qui attrape une régression d'interface mieux qu'un test figé sur la maquette du mois dernier.

Et je me cale sur la stratégie de test de l'équipe que je rejoins : sa définition de « fini » devient la mienne dès la première pull request.

Avant d'écrire du code, je vérifie que je sais décrire le résultat attendu en une phrase. Si je n'y arrive pas, ce n'est pas prêt à être codé, c'est prêt à être discuté.

Ça ne veut pas dire tout spécifier. Ça veut dire ne pas commencer par la partie facile en espérant que le reste s'éclaircira en chemin.

Dev, recette, production, et aucun passage sans pull request. La CI tourne sur chaque PR : si elle est rouge, rien n'avance.

Après une mise en production, je regarde. Les erreurs, les temps de réponse, le parcours que je viens de toucher. Un déploiement n'est pas fini quand le pipeline est vert, il est fini quand rien n'a bougé dans les métriques.

Je signale un blocage tôt et par écrit, pas au point de bascule. Une estimation qui dérape se dit le jour où je le vois, pas le jour de l'échéance.

Quand une spécification est floue, je ne devine pas et je n'attends pas non plus : j'écris l'interprétation que je vais suivre, et je la fais valider en une ligne. Ça coûte deux minutes et ça évite de refaire une semaine.

Et quand un sujet s'éteint faute d'être posé au bon endroit, je le reporte. J'ai posé une fois publiquement un problème que beaucoup subissaient en silence ; un lead a répondu qu'il fallait l'avis du design. Plutôt que de laisser le fil mourir, j'ai reformulé le sujet dans le canal produit avec un message adapté à cette audience. Le même jour, un autre développeur ouvrait la pull request.