Détecteur de Dette IA

Aperçu

Les agents IA génèrent du code qui fonctionne sur le chemin heureux mais cache de la dette : gestion d'erreurs manquante, ressources orphelines, modes de défaillance ignorés, packages hallucés, dérive architecturale silencieuse. Cette compétence force un audit ciblé pour les patterns exacts que les agents IA ratent.

Quand l'utiliser

• Après toute session de génération de code IA (20+ lignes produites)
• Avant de fusionner des PR générées par IA
• Quand le code fonctionne mais quelque chose semble bizarre
• Après des sprints de vibe-coding où la dette s'accumule le plus vite
• Quand l'agent prétend avoir terminé sans montrer de vérification

Processus

Après la génération de code, scannez ces patterns de dette spécifiques à l'IA :

1. MODES DE DÉFAILLANCE - Que se passe-t-il quand ça échoue ?

   • Timeout réseau ? Disque plein ? Permission refusée ? Entrée null ?
   • Y a-t-il un try/catch ? Attrape-t-il les erreurs SPÉCIFIQUES ou les avale-t-il toutes ?
   • Les ressources sont-elles nettoyées en cas d'échec ? (streams fermés, connexions restituées, fichiers temporaires supprimés)

2. ORPHELINES - Qu'est-ce qui est créé mais jamais nettoyé ?

   • Fichiers temporaires, event listeners, intervals, subscriptions, connexions
   • Y a-t-il des appels de nettoyage/dispose/close correspondants pour chaque open/create ?
   • En React : chaque addEventListener a-t-il un removeEventListener en cleanup ?

3. CAS LIMITES - Quelles entrées cassent ça ?

   • Tableau/chaîne vide ? null/undefined ? Entrée multi-MB ? Unicode ? Appels concurrents ?
   • Le code suppose-t-il le chemin heureux ? (L'IA le fait presque toujours)

4. DÉPENDANCES HALLUCÉES - Toutes les imports existent-elles réellement ?

   • Chaque package est-il dans package.json/requirements.txt ?
   • Les méthodes API sont-elles réelles ? (L'IA invente des méthodes plausibles qui n'existent pas)
   • La dernière version de cette bibliothèque exporte-t-elle toujours cette fonction ?

5. DÉRIVE ARCHITECTURALE - Ça correspond-il aux patterns du projet ?

   • Même style de gestion d'erreurs que le code existant ?
   • Utilise les utilitaires établis du projet (pas de réinvention) ?
   • Suit la convention de structure de fichiers ?

Signaux d'alerte (arrêtez et corrigez immédiatement)

• catch (e) {} ou catch (e) { console.log(e) } - erreur avalée
• Pas de bloc finally quand des ressources ont été ouvertes
• // TODO: handle error - la façon de l'IA de laisser tomber
• Import depuis un chemin qui n'existe pas dans le projet
• Timeout défini mais pas d'abort/nettoyage au timeout
• Connexion base de données ouverte mais jamais restituée au pool

Erreurs courantes

• Faire confiance à la compilation pour vérifier la correction (la compilation vérifie la syntaxe, pas la logique)
• Examiner seulement le diff sans vérifier ce que l'IA N'a PAS généré (chemins d'erreur manquants)
• Supposer que l'IA a utilisé la bonne version de la bibliothèque (elle utilise souvent des APIs dépréciées)
• Sauter le check orphelin parce que la collecte de mémoire s'en charge (pas pour les connexions, listeners, timers)

Pourquoi ça existe

Les agents IA optimisent systématiquement pour « semble correct » et « passe le chemin heureux ». Ils ratent les modes de défaillance, orphelinent les ressources et hallucinent les dépendances à des taux significativement plus élevés que le code manuel. Cette compétence force un audit pour ces angles morts spécifiques.