3. Construire et prouver, plutôt que supposer
Un changement de qualité est lisible : une personne qui ne l'a pas écrit peut relier l'intention, la décision et le comportement obtenu. Découpez le travail de sorte que chaque étape puisse être revue, testée et, idéalement, livrée indépendamment.
Le test est une preuve, pas une décoration
Un test utile échoue si le comportement important est cassé. Pour choisir le bon test, partez du risque :
- une règle de décision appelle souvent un test proche du domaine ;
- une intégration partagée appelle un test de contrat ;
- un parcours critique appelle une vérification de bout en bout ;
- une migration appelle des comptes, des échantillons et une réconciliation ;
- une qualité perçue appelle une mesure de performance, d'accessibilité ou d'erreur réelle.
La couverture de code n'est qu'un indice. Un chiffre élevé peut laisser intact le scénario qui coûte le plus cher à rater.
Ce qu'une bonne revue apporte
La revue vérifie moins la ponctuation du code que la qualité du raisonnement : avons-nous compris la règle ? l'interface reste-t-elle compatible ? le changement est-il lisible ? le rollback est-il crédible ? la production fournira-t-elle les signaux nécessaires ?
L'IA peut accélérer l'exploration ou la rédaction, mais ne remplace ni la compréhension du contexte ni une preuve indépendante. Ce qu'elle propose est une hypothèse à vérifier.
Approfondir : découper les changements, revue de code, tests comme preuves et portefeuille de tests.