Quand je rejoins une équipe, je veux voir comment elle livre une modification. Une petite suffit : un client demande quelque chose, les développeurs modifient le logiciel, puis le changement arrive en production. Suivre ce parcours m’indique où regarder ensuite.
Je voudrais aussi savoir ce que le fondateur souhaite voir changer dans les trois prochains mois. Ces deux échanges donnent un objectif à la revue technique. Voici ce que j’examinerais pendant le premier mois.
Que faut-il livrer ?
« Il faut aller plus vite » reste trop vague. Un contrat dépend-il d’une fonctionnalité ? Des clients partent-ils à cause d’un problème de fiabilité ? Le support occupe-t-il toute la semaine ? Chaque situation demande un travail différent.
Je poserais la question séparément au fondateur, au responsable produit et aux développeurs. S’ils citent des priorités différentes, il faut en parler avant d’ajouter des tâches. Une courte liste de priorités communes suffit pour démarrer.
Suivre une modification de bout en bout
Prenez un ticket récent et asseyez-vous avec les personnes qui l’ont traité. Regardez la demande initiale, la pull request, les tests et la mise en production. Demandez où le travail a attendu et pourquoi.
Une journée de développement a peut-être été suivie d’une semaine d’attente pour une décision. Chaque livraison dépend peut-être de l’ordinateur d’un développeur. Ces détails expliquent souvent mieux les retards qu’un schéma d’architecture général.
Vérifier ce qui pourrait bloquer l’activité
Je vérifierais rapidement les accès à la production, les déploiements et la restauration des données. Une sauvegarde jamais testée m’inquiète davantage qu’un framework que l’équipe aimerait remplacer.
Pour le reste, je demanderais un scénario précis : qu’est-ce qui tombe en panne, qui s’en aperçoit et comment repart-on ? « Le code est ancien » mérite une explication. « Une seule personne peut déployer et elle part le mois prochain » permet d’agir.
Terminer une amélioration avec l’équipe
Je choisirais un problème récurrent que l’équipe peut résoudre dans le mois. Automatiser une étape de déploiement, supprimer une validation inutile ou corriger une alerte trop bruyante peut déjà aider. L’équipe doit participer au choix.
Travailler ensemble sur ce changement me permet aussi de mieux connaître le code. Je peux relire l’implémentation et comprendre les contraintes avant de recommander un chantier plus important.
Écrire les prochaines décisions
Au bout d’un mois, je voudrais un document court, utilisable en réunion : les priorités, les risques, les prochaines décisions et leurs responsables. Toute proposition de refonte ou de recrutement devrait préciser le problème à résoudre et son coût.
J’y noterais les questions encore ouvertes. Certains systèmes demandent plus de temps. Ce document doit aider à décider du travail de la semaine suivante, sans prétendre que l’examen est terminé.