Tutoriel IA : lancer un audit read-only avant de laisser coder un agent

[CrdaN]

Tutoriel IA : lancer un audit read-only avant de laisser coder un agent
Avant de demander à Cursor, Claude Code ou Codex de modifier un projet, faites-lui d’abord analyser le repo en lecture seule. C’est simple, mais ça évite beaucoup de dégâts.​

Les agents IA savent maintenant lire un projet, proposer des changements, lancer des commandes, créer des PR et parfois modifier plusieurs fichiers très vite. C’est puissant, mais il y a un piège classique : on leur donne directement une mission de dev alors qu’ils n’ont pas encore compris le projet.

Résultat : modifications trop larges, fichiers inutiles touchés, correction qui casse un autre module, ou agent qui part dans une direction “logique” mais pas adaptée à votre code.

Mon conseil : avant l’action, imposez une phase audit read-only. L’agent peut lire, chercher, résumer, poser des hypothèses, mais il ne modifie rien. C’est une étape très rentable pour un bot Discord, un outil forum, un script marketplace, un plugin web ou un projet communautaire.

Pourquoi commencer en lecture seule ?

Un bon développeur ne modifie pas un projet inconnu après 30 secondes. Il lit l’arborescence, repère les points d’entrée, comprend les conventions, regarde les tests, puis seulement il propose un plan.

Avec un agent IA, c’est pareil. La différence, c’est qu’il peut aller trop vite et toucher trop large si la consigne n’est pas cadrée.

Le mode read-only sert à obtenir :

• une carte rapide du projet ;
• les fichiers probablement concernés ;
• les risques avant modification ;
• les commandes de vérification disponibles ;
• un plan court avant écriture ;
• une limite claire sur ce que l’agent ne doit pas toucher.

Ce n’est pas une perte de temps. C’est souvent l’étape qui évite le rollback.

Ce que l’agent peut faire en audit

Pendant l’audit, autorisez uniquement les actions non destructrices : lire des fichiers, chercher du texte, inspecter le package manager, regarder les scripts, parcourir la documentation interne, analyser les erreurs déjà présentes.

Exemples utiles :

• lister les dossiers importants ;
• identifier où se trouve la logique métier ;
• retrouver les fichiers liés à une commande Discord ;
• comprendre comment les variables d’environnement sont chargées ;
• repérer les tests ou l’absence de tests ;
• chercher les TODO, FIXME, erreurs connues ;
• résumer les risques avant patch.

Ce qu’il ne doit pas faire pendant cette phase :

• modifier un fichier ;
• installer une dépendance ;
• lancer une migration ;
• supprimer un cache ;
• exécuter une commande qui écrit dans le projet ;
• appeler une API externe avec vos clés ;
• pousser une branche ou ouvrir une PR.

Une fois l’audit terminé, vous décidez si vous passez en mode modification.

Le prompt simple qui marche bien

Il ne faut pas un roman. Il faut surtout être explicite sur l’interdiction d’écrire.

Pour voir le contenu, vous devez réagir aux messages avec l'une de ces réactions :

Réagir, Love, Haha, Oula, Triste, Colère

Ce prompt force l’agent à produire une carte avant de sortir les outils lourds. Il évite aussi le classique “j’ai corrigé 12 fichiers” alors que vous demandiez juste une analyse.

Comment passer ensuite en mode modification

Après l’audit, ne donnez pas un feu vert global du style “vas-y corrige”. C’est trop large.

Donnez plutôt une autorisation limitée :

• un objectif précis ;
• une liste de fichiers autorisés ;
• les fichiers interdits ;
• la commande de test attendue ;
• la règle de rollback ;
• une demande de diff final.

Exemple : “Tu peux modifier uniquement `src/commands/help.ts` et `src/lib/faq.ts`. Ne touche pas au système d’auth, au fichier `.env`, ni au déploiement. Lance le test FAQ si disponible, puis montre le diff.”

C’est beaucoup plus propre qu’un accès total.

Les fichiers à protéger par défaut

Même sur un petit projet, certains fichiers ne doivent pas être touchés sans validation explicite.

• `.env`, `.env.local`, fichiers de secrets ;
• scripts de déploiement ;
• migrations base de données ;
• fichiers de paiement ou facturation ;
• permissions Discord, OAuth, tokens ;
• configuration CI/CD ;
• fichiers de production ;
• gros refactors de structure.

Un agent peut être très bon et quand même faire une modification trop ambitieuse. Votre rôle est de réduire la surface d’erreur.

Pour voir le contenu, vous devez réagir aux messages avec l'une de ces réactions :

Réagir, Love, Haha, Oula, Triste, Colère

Cas pratique : bot Discord communautaire

Imaginez un bot Discord qui répond aux questions d’un serveur. Vous voulez ajouter une commande `/faq`.

Mauvaise approche : “Ajoute une commande FAQ au bot.”

Bonne approche :

1. Audit read-only : trouve la structure des commandes, le framework utilisé, les conventions et les tests.
2. Plan : l’agent propose les fichiers à modifier.
3. Autorisation limitée : seulement les fichiers de commande et la table de FAQ.
4. Test : lancer le lint ou un test ciblé.
5. Diff : relire avant merge.

Vous gardez le contrôle, et l’agent travaille mieux parce qu’il a un cadre.

Conclusion

Le mode audit read-only est l’un des meilleurs réflexes à prendre avec les agents IA. Il ne demande aucun outil compliqué : juste une consigne claire, une phase d’observation, puis une autorisation d’écriture limitée.

Pour les projets Cheat-Gam3 — bots, scripts, sites, outils de modération, automatisations — c’est une règle simple : d’abord comprendre, ensuite modifier. Les agents deviennent beaucoup plus utiles quand on les ralentit au bon moment.