1000 warnings supprimés par des agents IA, que faut-il vérifier ?
Supprimer les warnings Dart avec unawaited() ne corrige pas les bugs. Comment cadrer les agents IA et vérifier les appels asynchrones lors de la revue de code.
1000 warnings unawaited_futures supprimés en une après-midi par des agents IA : le compteur donne une bonne impression du travail accompli. Pourtant, certaines corrections peuvent laisser le comportement du code intact, y compris ses bugs.
Le risque apparaît quand la consigne se limite à « corrige tous les warnings ». Pour chaque appel, l'agent doit aussi déterminer si la suite du traitement dépend du résultat et comment un éventuel échec sera pris en charge.
Ce que change unawaited()
La règle unawaited_futures signale notamment les appels asynchrones non attendus dans une fonction async. Ajouter unawaited() permet de rendre ce choix explicite et de faire disparaître le warning :
// Avant : le lint signale un appel non attendu.
repository.save(order);
// Après : le lint ne signale plus cet appel.
unawaited(repository.save(order));
Le comportement à l'exécution reste identique. Selon la documentation Dart, unawaited() ne gère pas les erreurs : si la Future échoue sans gestion ailleurs, l'erreur reste non gérée. Il ne supprime donc ni les exceptions ni les traces d'erreur.
Si la suite du code suppose que la commande est déjà enregistrée, le problème existe toujours. Le warning qui incitait à examiner cet appel a simplement disparu.
Choisir selon le contexte
Quand la suite dépend de la sauvegarde, il faut attendre son résultat :
await repository.save(order);
L'erreur peut alors être traitée à cet endroit ou propagée à l'appelant. Ajouter await impose l'ordre des opérations, mais ne remplace pas la décision sur la gestion des échecs.
Une opération indépendante peut continuer en arrière-plan, à condition que son échec soit pris en charge. Par exemple, pour une méthode log qui retourne une Future<void> :
unawaited(analytics.log('order_created').catchError((Object error) {
reportError(error);
}));
Un simple unawaited(cache.warmUp()) ne suffit pas à gérer un échec du préchargement. Même si l'absence de cache est acceptable, il faut vérifier ce qu'il advient de l'erreur.
La règle discarded_futures concerne quant à elle les appels retournant une Future dans des fonctions synchrones. Elle mérite aussi une lecture du contexte : rendre la fonction asynchrone peut nécessiter d'adapter ses appelants.
Cadrer le travail des agents
Je commence par une passe en lecture seule pour identifier les appels à attendre et ceux qui peuvent continuer en arrière-plan. Pour chacun, l'agent doit expliquer les dépendances avec la suite du traitement et la gestion des erreurs prévue. S'il ne peut pas justifier son choix, le site reste à examiner.
La revue porte ensuite en priorité sur les écritures en base, les paiements et les opérations dont dépend une confirmation à l'utilisateur. Un échantillon des autres changements permet de repérer une correction mécanique récurrente, sans garantir la qualité de l'ensemble.
Le nombre de warnings aide à suivre l'avancement. Pour valider la PR, il faut vérifier que chaque modification correspond à une décision adaptée au code.