Personne ne valide sa propre merge request

Dans les conventions Git que je mets en place avec les équipes, une ligne pèse plus que toutes les autres: personne ne valide sa propre merge request.

Le reste des conventions la prépare. La branche partagée est protégée: aucun push direct. Tout changement passe par une merge request, y compris quand on contribue à la branche d’un collègue. Une demande est acceptée quand le build passe, que les messages de commit respectent le format convenu et que les remarques du relecteur ont été traitées. Ensuite, quelqu’un d’autre que l’auteur la valide; sinon, elle est refusée.

Une merge request validée par son auteur est une formalité, pas une relecture

L’auteur est le plus mal placé pour relire son propre changement. Il sait ce que le code est censé faire, alors il lit l’intention plutôt que les lignes. Le second lecteur n’a que les lignes, exactement comme le prochain mainteneur.

La règle change aussi l’échange. Celui qui valide doit comprendre le changement suffisamment bien pour le défendre: la connaissance de cette partie du code existe désormais dans deux têtes. Et l’auteur écrit dès le départ pour un lecteur: des demandes plus petites, des messages plus clairs, une description qui dit pourquoi.

Le pipeline ne remplace pas ce regard. Il vérifie ce qui se vérifie: le build, les tests, la quality gate. Il ne dit pas si le changement est le bon, s’il répond à la user story ou s’il se contente de passer ses propres tests.

À mon avis, cette ligne a plus d’importance en 2025 que lorsque je l’ai écrite pour la première fois. Plus un assistant écrit de code, plus le second lecteur humain compte. Quand le premier jet vient d’un outil, le développeur qui ouvre la demande est déjà le premier lecteur d’un code qu’il n’a pas tapé. La valider lui-même reviendrait à laisser le changement sans aucun relecteur.

La règle coûte quelques minutes à une personne. S’en passer prive l’équipe de la seule lecture qui n’était pas celle de l’auteur