teresaI92/Audit-de-Préparation-pour-Agents

Audit de préparation pour agents

Auditez le dépôt actuel selon la liste de contrôle ci-dessous et signalez les lacunes. Il s'agit d'un audit EN LECTURE SEULE : ne jamais modifier, créer ou supprimer des fichiers du dépôt.

Étape 1 : Découvrir la pile

Avant de juger quoi que ce soit, identifiez :

• Langages, frameworks, gestionnaire de paquets, structure monorepo
• Linter, formateur et vérificateur de types utilisés
• Lanceur de tests
• Gestionnaire de hooks (husky, lefthook, pre-commit, simple-git-hooks, plain .git/hooks)
• Système CI et sa configuration
• Fichiers d'instructions pour agents (AGENTS.md, CLAUDE.md, .cursorrules, copilot-instructions, etc.)
• Répertoires contenant des compétences, runbooks, prompts ou documents de workflow

Évaluez en utilisant les outils que ce dépôt utilise réellement. Ne recommandez pas de changer d'outils à moins que les outils actuels ne puissent pas faire le travail.

Budget

• Commencez par les listes de répertoires, fichiers de configuration et fichiers d'instructions. Utilisez grep, des comptages et des listes de fichiers au lieu de lire les fichiers source en entier.
• Échantillonnez au plus 3 fichiers représentatifs par package majeur.
• Si le dépôt est trop volumineux pour être couvert, dites quelles parties n'ont pas été examinées.

Étape 2 : Évaluer chaque élément de la liste de contrôle

Attribuez un statut par élément :

• PASS : clairement en place et fonctionnel
• PARTIEL : existe mais incomplet, obsolète, non appliqué ou incohérent
• MANQUANT : vous avez vérifié et il n'est pas présent
• N/A : ne s'applique pas à cette pile (dites pourquoi)
• INCERTAIN : vous n'avez pas pu le vérifier (indiquez ce qui vous a bloqué, par exemple CI externe ou parties du dépôt non examinées)

Étayez chaque statut avec des preuves : chemins de fichiers, clés de configuration ou courts extraits cités (moins de 15 mots chacun). Ne devinez jamais : si vous avez vérifié et n'avez rien trouvé, marquez MANQUANT ; si vous n'avez pas pu vérifier, marquez INCERTAIN.

Liste de contrôle

1. Instructions partagées pour agents
   • Fichier d'instructions unique à la racine lu par tous les agents et nouveaux ingénieurs
   • Couvre les règles de style de code (style d'export, structure d'import, organisation des fichiers, anti-patrons)
   • Exige la validation des données externes aux limites de confiance
   • Indique quels tests méritent d'être écrits
   • Définit une porte de complétion : lint, vérification de type et tests pertinents doivent réussir avant le commit
   • Est actuel et spécifique. Vérifiez 3 à 5 règles sur le code réel et rapportez si le code les suit.
2. Compétences de workflow dans le dépôt
   • Flux de travail récurrents documentés comme compétences pas à pas ou runbooks à côté du code
   • Couverture : commits, ouverture/empilement de PR, revue de code, passage d'une PR à travers la CI, modifications de dépendances, localisation
   • Flux de travail spécifiques à la pile couverts (couche de données, routeur, système de design, codegen, etc.)
   • Chaque compétence a un déclencheur, des étapes ordonnées et une définition de complétion
   • Les compétences sont la source de vérité unique, non dupliquées ou contradictoires
3. Conventions appliquées comme règles de lint
   • Les conventions documentées ont des règles de lint correspondantes
   • Des règles de lint personnalisées ou des plugins couvrent les usages spécifiques au projet (récupération de données, style, tests, traductions)
   • Des règles anti-patron existent pour les erreurs courantes des agents : assertions de type enchaînées ou inutiles, paramètres faiblement typés (unknown/any), spreads conditionnels d'objets vides, ainsi que tout modèle de basse qualité récurrent trouvé dans cette base de code
   • Les règles sont des erreurs, pas des avertissements, sans désactivations généralisées
4. Portes automatisées
   • Le hook pre-commit formate, lint et vérifie les types du code modifié
   • Le hook pre-push lint ou teste les packages affectés, y compris les dépendants
   • La CI relance les mêmes vérifications pour que les hooks ne puissent pas être contournés
   • Les hooks sont raisonnablement rapides
   • Les hooks sont câblés : la configuration du hook est commitée, une étape d'installation existe (script prepare, documentation de configuration, ou core.hooksPath), et les commandes qu'il appelle existent. Vérifiez en lisant les fichiers ; n'exécutez jamais les hooks.
5. Supervision et structure
   • Décisions d'architecture documentées
   • Revue de PR requise avant la fusion (vérifiez la protection de branche ou CODEOWNERS si visible)
   • Les limites des packages et des modules sont claires et appliquées

Étape 3 : Trouver les conventions non documentées

Échantillonnez le code pour trouver des motifs appliqués de manière cohérente mais écrits nulle part, et pour des motifs que les agents comprennent souvent mal (typage lâche, données externes non validées, exports incohérents, logique dupliquée). Listez les 5 meilleurs candidats à ajouter au fichier d'instructions ou à transformer en règles de lint.

Étape 4 : Rapport

Produisez :

1. Un tableau récapitulatif : élément, statut, preuve en une ligne
2. Une section « lacunes » : chaque élément PARTIEL, MANQUANT ou INCERTAIN, ce qui ne va pas, et pourquoi c'est important pour la fiabilité des agents
3. Une liste de recommandations priorisées (la plus impactante en premier), chacune avec une prochaine étape concrète et un effort approximatif (petit/moyen/grand), formulée en termes des outils existants de ce dépôt
4. Les 5 meilleures conventions candidates de l'Étape 3

Soyez direct. N'ajoutez pas de compliments superflus. Si quelque chose va bien, dites PASS et passez à autre chose.

Après le rapport, proposez de structurer les éléments manquants (fichier d'instructions de démarrage, modèles de compétences, ébauches de règles de lint), mais ne créez rien avant d'y être invité.