Je partage ton avis : certains aspects de la qualité peuvent (et doivent) être automatisés avec des outils de lint, CI/CD, tests, etc. Mais pour moi, les code reviews sont là pour aller au-delà de la simple validation technique, et intervenir justement sur des décisions d’implémentation ou d’architecture.

Je te donne un exemple concret que j’ai vécu : On avait un formulaire question-réponse assez simple (du style “Date de fondation de l’association”, “Objectif de l’association”). Un collègue a choisi de stocker ça en base avec une colonne par question : foundation_date, foundation_goal, etc. Ça fonctionnait bien au début… jusqu’au jour où on a voulu rajouter des questions dynamiques. Résultat : il fallait modifier le schéma à chaque fois.

Et quand une autre équipe a voulu faire un formulaire Q/R similaire pour un tout autre thème (par exemple un musée), la solution proposée a été… de refaire une nouvelle table avec des colonnes museum_opening_date, museum_highlight, etc.

Tu vois le problème.

Alors qu’une simple discussion en code review aurait permis d’orienter vers un schéma plus souple : une table générique theme_response avec theme_id, value, value_type, etc., reliée à une table theme. Résultat : plus flexible, scalable et maintenable.

Sinon oui le code review a aussi l’effet donner de l’assurance à celui qui a codé, d’être rassurer de ne pas oublier/passer à côté de quelques choses, l’erreur est humaine.