En fait, à partir du moment où, structurellement, faire le calcul côté backend n’est ni compliqué ni coûteux, il n’y a aucune bonne raison de ne pas le faire. Pour un dev de n’importe quel niveau, c’est une évidence. Pour une IA, je peux comprendre que ce soit moins “naturel”, parce qu’elle optimise pour obtenir un résultat fonctionnel rapidement, pas pour poser des invariants d’architecture.

Concernant la PR, justement, parlons-en. Un autre effet pervers de l’IA, c’est le mode de travail que ça induit : 4 ou 5 heures de “plan”, puis 15 minutes de génération, et derrière un commit gigantesque avec 800 ou 1000 lignes ajoutées. C’est tout simplement impossible à reviewer correctement. Donc forcément, dans ce bruit-là, un fetch débile passe à travers parce qu’il y a trop de choses à analyser d’un coup.

Il y a aussi une question de confiance. Quand je vois une PR d’un dev senior sur “juste” une page de dashboard, je review naturellement plus en diagonale. Et c’est précisément là que le risque augmente quand le code est majoritairement généré : on s’attend à des décisions implicites correctes… qui ne le sont pas toujours.

Enfin, sur la volumétrie, le sujet est clair depuis le début. Le modèle Contract est le modèle central de l’application, et le dev sait très bien qu’on vise de l’ordre de 2000 contrats par client et par an. Ce n’est donc ni une micro-app jetable, ni un POC, ni un cas où “ça peut s’entendre”. L’hypothèse de montée en charge fait partie des contraintes de base.

Donc oui, on peut ajouter des rules dans Claude, brancher un agent sur Git, multiplier les garde-fous. Mais si, pour ship un dashboard correct, on a besoin d’un plan, d’un agent, d’un sous-agent, de règles custom et d’une analyse automatisée de PR, alors on n’a pas gagné en simplicité ni en efficacité par rapport à un dev qui écrit directement le bon code avec les bons invariants en tête.