Audit de code
Audit de code source automatisé par IA.
Un agent qui lit chaque fichier de votre dépôt, identifie les bugs, les failles de sécurité, la dette technique et les zones à risque, puis livre un rapport Markdown avec preuve sur chaque constat.
Pourquoi auditer son code source
Trois situations rendent l'audit nécessaire avant que les symptômes ne se déclarent en production.
- Dette technique invisible. Les linters classiques (PHPStan, ESLint, Pylint, SpotBugs) attrapent les anti-patterns connus. Ils ne voient pas la sur-ingénierie, la duplication sémantique cross-fichiers, ni les modules dont personne ne se sert plus.
- Failles de sécurité contextuelles. Les vulnérabilités du top 10 OWASP sont détectables par règle. Les chaînes d'attaque qui combinent trois fonctions réparties sur deux modules, non. Un audit LLM lit ces chaînes.
- Onboarding ralenti. Reprendre une base de code existante sans documentation coûte des semaines à chaque nouveau développeur. Un rapport d'audit structuré accélère cette prise en main de quelques jours.
Comment fonctionne Anatoly
Anatoly est un agent open source (AGPL-3.0) qui s'exécute en CLI sur votre poste ou en CI. Il ne touche pas votre code (l'audit est en lecture seule) et produit un rapport structuré.
- Analyse sémantique, pas un linter. Chaque fichier passe par sept axes d'évaluation indépendants (utilité, duplication, correction, sur-ingénierie, tests, bonnes pratiques, documentation). Chaque axe est un appel LLM séparé qui raisonne sur le contexte complet du fichier et de ses dépendances.
- Contexte full-repo via RAG. Un index vectoriel local permet à chaque constat de remonter à d'autres fichiers liés sémantiquement, pas seulement au fichier en cours.
- Modèles locaux ou cloud. Compatible avec tout endpoint OpenAI-compatible : Ollama, LM Studio, vLLM pour le local, ou Claude, GPT, Gemini en BYOK pour le cloud.
- Chaîne de preuves. Chaque constat pointe vers un fichier, une ligne et une justification. Le rapport survit à une contre-expertise.
- Cache incrémental. Le premier run audite tout. Tous les suivants ne ré-auditent que les fichiers modifiés (SHA-256 sur le contenu).
Ce que vous obtenez
Le livrable est un dossier .anatoly/runs/<date>/ contenant :
report.md: rapport Markdown unique, verdict global, santé par axe, constats avec fichier + ligne + preuve.findings_*.json: un fichier JSON par axe d'audit, pour intégration en CI ou dashboard interne.- Scoreboard par axe (correction, utilité, duplication, sur-ingénierie, tests, bonnes pratiques, documentation) avec score 0–10 et constats agrégés.
- Sévérité explicite par constat :
NEEDS_FIX,OVER,DUPLICATE,DEAD,WEAK, etc. - Recommandations actionnables, attachées au symbole concerné (fonction, classe, module).
Un exemple public, rapport complet et non édité, est disponible sur anatoly-bench.
Langages et frameworks supportés
L'audit fonctionne sur toute base de code, avec des calibrations affinées sur les langages les plus courants.
- PHP : Laravel, Symfony, WordPress, Drupal. Voir audit de code PHP.
- Java : Spring (Boot, Security), Jakarta EE, Quarkus, Micronaut. Voir audit de code Java.
- Python : Django, FastAPI, Flask, Pyramid.
- JavaScript / TypeScript : Next.js, Express, NestJS, React, Vue.
- Go : standard library, Gin, Echo, Fiber.
- Rust, C#, Ruby : supportés via les axes génériques.
Comparaison rapide avec les outils établis
| Outil | Catégorie | Limite face à un audit complet |
|---|---|---|
| SonarQube | Analyse statique par règles | Pas de raisonnement LLM. Ne détecte ni sur-ingénierie ni duplication sémantique. |
| Snyk Code | Sécurité (SAST + IA) | Sécurité uniquement. Ne couvre pas dette technique ni qualité. |
| CodeRabbit | Revue de pull request | Voit un diff. Ne peut pas auditer la base de code existante. |
| Anatoly | Audit codebase par IA | Couvre les sept axes. Local ou cloud. Rapport Markdown défendable. |
Pour le comparatif détaillé des 14 outils du marché, voir audit de code IA vs revue de code IA en 2026.
Questions fréquentes
- Combien de temps prend un audit de code source ?
- Le premier audit prend entre quelques minutes (petit projet de quelques milliers de lignes) et environ une heure (dépôt de 50 000 lignes). Les audits suivants sur les fichiers inchangés sont quasi instantanés grâce au cache SHA-256 : seuls les fichiers modifiés sont ré-analysés.
- Mon code source quitte-t-il mon infrastructure ?
- Pas obligatoirement. Anatoly fonctionne en CLI locale et supporte les modèles locaux via Ollama, LM Studio ou vLLM, avec embeddings RAG locaux. En configuration air-gapped, aucun octet de code source ne sort de votre réseau. Pour les organisations en BYOK, le code transite uniquement vers le fournisseur LLM choisi (Anthropic, OpenAI, Azure, etc.).
- Quels langages sont supportés ?
- PHP, Java, Python, JavaScript, TypeScript, Go, Rust, C#. Les frameworks principaux sont reconnus : Laravel, Symfony, Spring, Django, FastAPI, Express, Next.js, .NET. Si un langage n'est pas listé, l'audit fonctionne quand même via les axes génériques, avec une calibration moins fine.
- En quoi Anatoly diffère de SonarQube ?
- SonarQube applique des règles AST prédéfinies (analyse statique basée sur des règles). Anatoly utilise un LLM qui comprend la sémantique cross-fichiers et produit un jugement contextuel. Conséquence pratique : SonarQube détecte les patterns connus (code smells, vulnérabilités cataloguées), Anatoly détecte les jugements qu'une règle ne peut pas encoder (sur-ingénierie, duplication sémantique, tests faibles d'une classe précise).
- Quel est le prix d'un audit ?
- Anatoly est open source (AGPL-3.0). Le coût correspond aux tokens LLM consommés. Pour un dépôt TypeScript de 10 000 à 50 000 lignes, le premier run coûte de quelques dollars à quelques dizaines de dollars selon le modèle. Les ré-audits sur fichiers inchangés sont à 0 $. Une licence commerciale est disponible pour les organisations qui ne peuvent pas s'aligner sur l'AGPL.