À 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, 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.

Devant une lenteur ou un comportement inexplicable, j'écris d'abord comment je vais chercher : ce que j'instrumente, ce que je compare, et ce qui validerait ou invaliderait l'hypothèse. Ça coûte dix minutes, et ça évite de partir sur la première piste plausible. Une hypothèse n'est pas un résultat.

Deux semaines après mon arrivée, de ma propre initiative : sur les quarante-quatre secondes d'un export, plus de 42 étaient consommées côté application, avant même l'appel au service qui, lui, prenait un peu plus d'une seconde. Requêtes en cascade corrigées.

Plus tard, sur une lenteur des plus gros comptes reprise de zéro : instrumentation des deux côtés, puis isolation du goulot en comparant trois tailles de compte. L'arbitrage : corriger les requêtes en cascade plutôt que poser du cache par-dessus. Le correctif backend est parti en production, avec le recensement des autres points d'entrée exposés au même défaut.

Le meilleur résultat de ce travail n'est pas un correctif, c'est un déplacement de sujet : un défaut d'affichage s'est révélé être un contournement de règle métier, et l'argument décisif tenait en une phrase : aucune vue de l'application ne permet de créer cet état à la main. La décision est remontée d'un niveau. Et quand je creuse et que j'avais tort, je corrige mon hypothèse là où je l'avais publiée : c'est ce qui permet de séparer ce qui relève du produit de ce qui relève de la configuration.

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. Sur deux cent trois fils analysés, j'en retiens 9,4 % : l'essentiel du travail, c'est ce que je jette.

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 relecture contradictoire 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 par petits lots, 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 rapporte : 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.