Review de code avec IA
OpenClaw comme ton Senior Engineer —— 24h/24, chaque ligne est regardée sérieusement
La réalité de la review de code
Tu soumet une PR, le Senior est occupé sur un autre projet. Deux jours après il fait enfin la review et laisse juste un « LGTM ». Soit tu attends un éternité, soit ça n'a pas vraiment été regardé de près —— à quoi sert cette review franchement ?
Et c'est encore pire quand dans l'équipe tout le monde a des standards différents. Untel trouve qu'une approche passe, l'autre dit qu'il faut la changer. Tu écoutes qui ? Fixer une norme ? Trois réunions plus tard, vous vous mettez toujours pas d'accord.
Balance ton code à OpenClaw, il va faire une revue ligne par ligne suivant les meilleures pratiques du secteur : failles de sécu, goulots perfs, maintenabilité, edge cases, tout est couvert.
Pas de liste d'attente, pas besoin de faire plaisir, pas d'excuse du genre « c'est la rushé donc LGTM ». Et en plus, chaque review suit le même standard —— fini de se disputer sur Slack « est-ce que c'est vraiment un problème ».
3 Prompts de review, copy-paste
Du check sécu spécialisé à la vérif des principes de design, utilise ce dont tu as besoin.
Review ce diff de code (changements PR), mets l'accent sur :
1. Failles de sécu : injections SQL, XSS, CSRF, révélation infos sensibles, désérialisation non-sécurisée
2. Problèmes perfs : requêtes N+1, allocations mémoire inutiles, requêtes sans index, opérations bloquantes
3. Edge cases : valeurs nulles, conditions de courses, énormes volumes de data
Pour chaque problème donne :
- Niveau de sévérité (Critique / Alerte / Suggestion)
- Position exacte (nom fichier + numéro ligne)
- Conseil de fix avec du code d'exemple
Et finis avec une éval globale et si tu recommandes un merge.
Vérifie si ce code suit les principes SOLID :
- S (responsabilité simple) : Cette classe/fonction fait trop de trucs ?
- O (ouvert/fermé) : Faut modifier le code existant pour ajouter des features ?
- L (substitution Liskov) : La classe fille peut remplacer le parent sans problème ?
- I (ségrégation interface) : L'interface est pas trop grosse ?
- D (inversion dépendances) : Un module haut niveau dépend directement d'une implementation bas niveau ?
Pour chaque violation du principe :
1. Explique c'est quoi la violation exacte, où
2. Pourquoi c'est un souci
3. Donne un plan de refonte + du code d'exemple
Analyse les requêtes de la base dans ce code :
1. Déniche tous les problèmes de requêtes N+1 :
- Signale les requêtes que tu déclenches dans une boucle
- Calcule le pire scénario de nombre de requêtes
2. Donne les plans d'optim :
- Lesquels tu peux fusionner avec JOIN
- Lesquels peuvent utiliser eager loading / preload
- Lesquels ont besoin de cache
3. Écris le code optimisé
4. Estime la diff de perf avant/après
Le framework ORM c'est [ton framework, par exemple SQLAlchemy / Prisma / ActiveRecord].
Review de code : OpenClaw vs GitHub Copilot
Les deux peuvent faire de la review, mais l'approche est complètement différente.
- Voit tous les fichiers du projet, comprend la logique métier cross-file
- Les Prompts sont totalement customisables, tu reviews suivant tes règles d'équipe
- Tu peux changer les modèles : review simple avec GPT-4o, architecture complexe avec Opus 4.6
- Les résultats peuvent être exportés, archivés, servir comme base de connaissance d'équipe
- Intégré à l'interface GitHub PR, super facile à déclencher
- La review se limite au contenu du diff, compréhension cross-file limitée
- Le modèle est fixe, impossible de customiser les règles de review
- Parfois il se vautre sur les commentaires chinois et les noms de variables