Référentiel Burdee

Ce critère évalue si le code est organisé en couches distinctes avec des responsabilités claires. Une bonne séparation des responsabilités est le premier signe qu'un humain a guidé l'architecture plutôt que de laisser l'IA empiler du code dans un seul fichier. C'est le critère le plus lourd du référentiel car il conditionne la maintenabilité de tout le projet.

Ce critère mesure le niveau de couplage entre les composants du système. L'injection de dépendances et l'inversion de contrôle sont des piliers de la Clean Architecture. Un code fortement couplé est un code qui ne peut pas être testé en isolation — et c'est souvent le résultat d'une génération IA non supervisée, où chaque classe instancie directement ses dépendances.

La qualité de la modélisation du domaine révèle si le développeur a réfléchi au métier avant de coder. L'IA a tendance à produire des modèles anémiques (de simples conteneurs de données avec des getters/setters) car c'est le pattern le plus fréquent dans ses données d'entraînement. Un domaine riche, avec des entités qui portent leur logique métier, des Value Objects immuables et des agrégats bien définis, est la marque d'un développeur qui a orchestré l'IA avec une vision DDD.

Un code bien architecturé est un code testable. Ce critère évalue non seulement la présence de tests, mais surtout la capacité du code à être testé en isolation. L'IA génère souvent du code difficile à tester car fortement couplé à l'infrastructure (base de données, APIs externes). Un bon orchestrateur structure le code pour que le domaine puisse être testé sans aucune dépendance externe.

Ce critère évalue si le projet est découpé en modules autonomes avec des frontières claires. L'IA ne connaît pas les bounded contexts de votre projet — c'est au développeur de les définir et de s'assurer que chaque module a une responsabilité claire, des contrats bien définis avec les autres modules, et un minimum de dépendances croisées.

Peut-on identifier, pour chaque portion du code, si elle a été générée par IA ou écrite manuellement ? La traçabilité est essentielle pour la maintenance : quand un bug survient dans du code généré, il faut pouvoir retrouver le contexte de génération, le prompt utilisé, et les décisions prises. Sans traçabilité, le code IA devient une boîte noire impossible à débugger efficacement.

Le code généré par IA a-t-il été systématiquement relu, compris et validé par un humain avant d'être intégré ? La validation humaine est la clé de voûte de l'orchestration. Un développeur qui copie-colle du code IA sans le comprendre n'orchestre pas — il délègue aveuglément. La validation implique la compréhension, la revue critique et l'approbation explicite de chaque génération.

Les résultats de l'IA sont-ils reproductibles ? Si on relançait le même prompt dans le même contexte, obtiendrait-on un résultat similaire ? La reproductibilité passe par la documentation des prompts, du contexte fourni à l'IA, et des paramètres utilisés. C'est un principe fondamental de la démarche scientifique appliqué à l'ingénierie logicielle assistée par IA.

Le développeur a-t-il clairement défini ce que l'IA peut et ne peut pas faire dans le projet ? Un bon orchestrateur sait quand utiliser l'IA et quand s'en passer. Il définit les contraintes, les conventions et les limites avant de lancer une génération. Les décisions architecturales, la modélisation du domaine et les choix de sécurité ne doivent jamais être délégués à l'IA sans supervision.

Le code est-il auto-documenté ? Les noms de variables, fonctions et classes expriment-ils clairement leur intention ? L'IA génère souvent des noms génériques (data, result, temp) ou reproduit des conventions d'exemples de documentation. Un bon orchestrateur impose un nommage intentionnel et cohérent qui reflète le langage du domaine métier.

Les fonctions sont-elles courtes et focalisées ? La complexité cyclomatique est-elle maîtrisée ? L'IA a tendance à générer des fonctions longues avec de nombreux branchements conditionnels, car elle optimise pour la complétude plutôt que pour la simplicité. Un orchestrateur veille à ce que chaque fonction opère à un seul niveau d'abstraction et reste compréhensible d'un seul regard.

Le même problème est-il résolu de la même manière partout dans le projet ? L'un des défauts les plus fréquents du code généré par IA est l'incohérence stylistique : chaque génération peut proposer un pattern différent pour le même type de problème. Un bon orchestrateur impose des conventions et vérifie que l'IA les respecte systématiquement.

Le projet contient-il du code mort, des TODO orphelins, des dépendances inutilisées ou des hacks non documentés ? L'IA génère parfois du code "au cas où" — des classes jamais utilisées, des méthodes redondantes, des imports superflus. Un projet bien orchestré est un projet propre où chaque ligne de code a une raison d'exister et où chaque compromis technique est documenté.

Les accès aux données sont-ils optimisés ? L'un des pièges les plus fréquents du code IA est le problème N+1 : une boucle qui exécute une requête par itération au lieu d'un seul chargement. L'IA ne "voit" pas les implications de performance de ses choix — c'est au développeur de vérifier que les requêtes sont efficaces, indexées et paginées.

Chaque dépendance du projet est-elle justifiée ? L'IA suggère fréquemment des bibliothèques tierces pour des tâches simples, créant un bloat de dépendances qui alourdit le projet, augmente la surface d'attaque et complique les mises à jour. Un bon orchestrateur challenge chaque composer require et préfère le code natif quand c'est raisonnable.

Le code gère-t-il correctement les ressources système ? Fichiers, connexions, mémoire — chaque ressource ouverte doit être fermée, chaque allocation doit être libérée. L'IA oublie souvent ces détails car ils ne sont pas nécessaires pour que le code "fonctionne" en apparence, mais ils causent des problèmes insidieux en production.

Le projet intègre-t-il des considérations de sobriété numérique ? À l'heure où le numérique représente 4 % des émissions mondiales de gaz à effet de serre, l'éco-conception est un devoir professionnel. Un orchestrateur responsable minimise l'empreinte de son code : payloads légers, compression, cache HTTP, images optimisées, pas de requêtes superflues.

Le code est-il protégé contre les 10 vulnérabilités web les plus courantes ? Le référentiel OWASP est le standard mondial en matière de sécurité applicative. Les failles les plus fréquentes dans le code généré par IA sont les injections (SQL, XSS, commandes), l'absence de CSRF, la mauvaise gestion de l'authentification et l'exposition de données sensibles dans les réponses API.

Les secrets (mots de passe, clés API, tokens) sont-ils correctement externalisés et protégés ? C'est l'une des erreurs les plus graves et les plus fréquentes dans le code généré par IA : des credentials en dur dans le code source, un fichier .env commité par mégarde, des clés API visibles dans l'historique git. Un seul secret fuité peut compromettre tout un système.

Les données personnelles des utilisateurs sont-elles protégées conformément au RGPD et aux bonnes pratiques de sécurité ? L'IA n'a aucune notion de conformité réglementaire. Elle peut logger des données personnelles, stocker des mots de passe en clair, ou exposer des informations sensibles dans les réponses API. C'est au développeur de s'assurer que chaque donnée personnelle est traitée avec le respect qu'elle mérite.