Arriver dans une histoire déjà commencée
Mon stage chez Laxson Solutions Inc., de mai à août 2026, m’a mise devant une différence très concrète avec les projets scolaires : l’application existait avant moi. Conexgo avait déjà ses composants, ses conventions et ses utilisateurs. Je ne pouvais pas décider seule de repartir de zéro chaque fois qu’un morceau de code me semblait difficile à suivre.
Au début, lire pouvait donner l’impression de ne pas avancer. Pourtant, retrouver l’origine d’une donnée ou comprendre pourquoi un composant est partagé fait partie du correctif. Le code présent raconte des décisions dont je ne connais pas encore les contraintes. Il faut reconstruire assez de contexte pour modifier quelque chose avec une raison précise.
Décrire le problème avant de choisir la solution
J’ai travaillé dans des interfaces Blazor et MudBlazor : formulaires, filtres, tableaux et composants réutilisables. Un défaut visible ne désigne pas forcément l’endroit à modifier. Une valeur affichée incorrectement peut aussi dépendre de la donnée reçue, d’une condition d’affichage ou d’une étape précédente. Regarder seulement le résultat limite trop vite les hypothèses.
Un exemple hypothétique : un filtre semble ne rien retourner. Avant de changer le tableau, il faudrait vérifier la valeur envoyée, les données disponibles et le rôle utilisé. Cette manière de décrire un problème permet de distinguer ce qui est observé de ce qui est supposé. Elle évite de faire disparaître un symptôme en laissant sa cause intacte.
Choisir la taille du changement
Dans une base existante, le correctif le plus court n’est pas toujours le plus clair. Ajouter une condition peut résoudre le cas immédiat tout en rendant le composant plus difficile à comprendre. À l’inverse, réorganiser une grande partie du code peut étendre inutilement la vérification. La bonne question devient : quelle responsabilité doit réellement changer ?
Les différences Git m’aident à regarder cette portée. Je peux comparer l’intention avec les fichiers et les comportements touchés. Les journaux et les builds Release apportent d’autres éléments pour comprendre le résultat. Ces outils ne remplacent pas le raisonnement ; ils lui donnent des points d’appui et rendent certaines suppositions plus faciles à examiner.
Refaire un parcours avec assez de contexte
Avec Playwright, j’ai construit des scénarios par rôle, des sessions réutilisables, des captures et des traces. L’intérêt ne se limite pas à rejouer des clics. Un scénario doit représenter une situation identifiable : qui utilise l’application, dans quel état elle se trouve et quel résultat compte. Sinon, une vérification peut réussir sans répondre à la bonne question.
Les rôles, les appareils et les tailles d’écran élargissent cette réflexion. Tout tester de la même manière n’est pas réaliste ; choisir les cas liés au changement demande de comprendre son usage. Une trace ou une capture devient alors utile pour expliquer une divergence, pas seulement pour montrer qu’un écran avait une certaine apparence à un instant donné.
Laisser un changement que l’équipe peut relire
Une autre personne doit pouvoir comprendre ce qui a motivé le travail et ce qui a été vérifié. Dire « le formulaire fonctionne » laisse beaucoup de questions ouvertes. Préciser le comportement attendu, le contexte du problème et les cas examinés donne une base plus utile pour la relecture. Cela aide aussi à retrouver le raisonnement plus tard.
Depuis août, je poursuis ce travail à temps partiel avec l’équipe. Je garde de ce premier stage une attention différente : la qualité d’un correctif se voit aussi dans la facilité à l’expliquer, à le vérifier et à continuer le travail après lui. Cette responsabilité commence bien avant la dernière ligne de code.