Comment auditer le code généré par IA dans un projet open source : 7 étapes

En 2026, plus de 55 % du code poussé en production est généré ou assisté par des outils d'IA — GitHub Copilot, Claude Code, Cursor, Windsurf. Pour les projets open source, où la transparence et la fiabilité sont des valeurs fondamentales, cette réalité pose un défi inédit : comment s'assurer que le code IA respecte les standards de qualité, de sécurité et d'architecture du projet ? Ce guide détaille une méthode en 7 étapes, testée sur des projets réels, avec des exemples de code et des outils open source à chaque étape.

Étape 1 : Identifier et taguer le code généré par IA

Avant de pouvoir auditer le code IA, il faut d'abord pouvoir le distinguer du code humain. C'est moins évident qu'il n'y paraît : un développeur qui utilise Copilot en mode autocomplete ne tag pas explicitement chaque ligne générée. La première étape consiste à mettre en place des conventions de traçabilité.

La méthode la plus efficace est d'imposer un trailer Git dans les messages de commit. Quand un développeur a utilisé un assistant IA pour générer ou modifier significativement du code, il ajoute un trailer standardisé. Voici comment l'implémenter via un hook Git :

# .git/hooks/prepare-commit-msg
#!/bin/bash

# Demander au développeur si le code contient du code IA
if [ -z "$AI_ASSISTED" ]; then
  echo ""
  read -p "Ce commit contient-il du code généré par IA ? (o/n) " -n 1 -r
  echo ""
  if [[ $REPLY =~ ^[Oo]$ ]]; then
    # Ajouter le trailer AI-Assisted
    sed -i '' -e '/^$/a\
AI-Assisted-By: copilot|claude|cursor' "$1"
  fi
fi

Pour les projets qui utilisent GitHub Actions, vous pouvez également détecter automatiquement les PRs probablement générées par IA en analysant les patterns de commit — commits très rapides, modifications massives d'un seul coup, ou présence de commentaires typiques des LLM.

# .github/workflows/detect-ai-code.yml
name: Detect AI-Generated Code
on: [pull_request]

jobs:
  detect:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Check for AI patterns
        run: |
          # Patterns courants dans le code généré par IA
          PATTERNS=(
            "TODO: implement"
            "// This function"
            "# Generated by"
            "placeholder"
          )

          DIFF=$(git diff origin/main...HEAD)
          AI_SCORE=0

          for pattern in "${PATTERNS[@]}"; do
            COUNT=$(echo "$DIFF" | grep -ci "$pattern" || true)
            AI_SCORE=$((AI_SCORE + COUNT))
          done

          if [ $AI_SCORE -gt 5 ]; then
            echo "⚠️ Score IA élevé ($AI_SCORE) - revue approfondie recommandée"
            echo "ai_detected=true" >> $GITHUB_OUTPUT
          fi

Cette étape peut sembler administrative, mais elle est fondamentale. Sans traçabilité, vous ne pouvez pas mesurer l'impact du code IA sur la qualité globale de votre projet. Les données collectées ici alimenteront les métriques de l'étape 6.

Étape 2 : Analyse statique augmentée (au-delà du linter)

Le linting classique (ESLint, Pylint, Clippy) reste nécessaire mais insuffisant pour le code IA. Les LLM produisent du code syntaxiquement correct qui passe tous les linters — c'est justement leur force. Le problème se situe à un niveau plus profond : logique redondante, patterns non idiomatiques, dépendances inutiles, ou abstractions mal placées.

Pour aller au-delà du linter, configurez une analyse AST (Abstract Syntax Tree) personnalisée qui détecte les patterns typiques du code IA. Voici un exemple de règle Semgrep pour détecter les try/catch trop larges — un pattern extrêmement courant dans le code généré par IA :

# .semgrep/ai-code-patterns.yml
rules:
  - id: overly-broad-catch
    patterns:
      - pattern: |
          try {
            ...
          } catch ($ERR) {
            console.log($ERR)
          }
    message: >
      Catch trop large - le code IA génère souvent des blocs
      try/catch qui avalent les erreurs silencieusement.
      Spécifiez le type d'erreur et gérez-la explicitement.
    severity: WARNING
    languages: [typescript, javascript]

  - id: unused-async
    patterns:
      - pattern: |
          async function $FUNC(...) {
            ...
          }
      - pattern-not: |
          async function $FUNC(...) {
            ...
            await ...
            ...
          }
    message: >
      Fonction async sans await - pattern typique du code IA
      qui ajoute async par défaut "au cas où".
    severity: WARNING
    languages: [typescript, javascript]

  - id: hardcoded-credentials-ai
    patterns:
      - pattern: |
          $KEY = "sk-..."
      - pattern: |
          $KEY = "api_..."
    message: >
      Credential potentiellement hardcodée. Les LLM génèrent
      parfois des clés d'exemple qui ressemblent à de vraies clés.
    severity: ERROR
    languages: [python, typescript, javascript]

Intégrez ces règles dans votre CI/CD pour qu'elles s'exécutent automatiquement sur chaque PR. Semgrep est open source et peut être auto-hébergé, ce qui garantit que votre code ne quitte jamais votre infrastructure — un point critique pour les projets soumis au RGPD ou travaillant avec des données sensibles.

Étape 3 : Vérification de sécurité ciblée

Le code généré par IA a des vulnérabilités prévisibles. Les LLM sont entraînés sur du code existant — y compris du code vulnérable. Ils reproduisent donc des patterns non sécurisés avec une régularité statistique. Les problèmes les plus courants : injection SQL via concaténation de chaînes, absence de validation d'entrées, utilisation de fonctions cryptographiques obsolètes (MD5, SHA1 pour du hashing de mots de passe), et désérialisation non sécurisée.

Voici un pipeline de vérification sécurité adapté au code IA :

# security-audit.sh - À exécuter sur chaque PR taguée AI
#!/bin/bash
set -euo pipefail

echo "🔒 Audit sécurité du code IA - $(date)"
echo "==========================================="

# 1. Semgrep avec règles OWASP
echo "▸ Semgrep OWASP Top 10..."
semgrep --config p/owasp-top-ten \
        --config p/security-audit \
        --error \
        --json > /tmp/semgrep-results.json

# 2. Vérification des dépendances (supply chain)
echo "▸ Audit dépendances..."
if [ -f "package.json" ]; then
  npm audit --production --audit-level=high
fi
if [ -f "requirements.txt" ]; then
  pip-audit -r requirements.txt --fix --dry-run
fi

# 3. Détection de secrets
echo "▸ Scan secrets..."
trufflehog filesystem . --only-verified --fail

# 4. Vérification spécifique code IA
echo "▸ Patterns IA non sécurisés..."
grep -rn "eval(" --include="*.py" --include="*.js" && \
  echo "⚠️ eval() détecté - vérifier manuellement" || true
grep -rn "dangerouslySetInnerHTML" --include="*.tsx" && \
  echo "⚠️ dangerouslySetInnerHTML - vérifier XSS" || true
grep -rn "subprocess.call.*shell=True" --include="*.py" && \
  echo "⚠️ shell=True dans subprocess - injection possible" || true

echo "✅ Audit terminé"

Pour les projets Python, ajoutez bandit avec un profil strict. Pour Rust, cargo-audit et cargo-deny. Pour Go, gosec. L'idée est de superposer plusieurs couches de détection car aucun outil seul ne couvre tous les cas. Le code IA a tendance à utiliser des patterns qui passent sous le radar d'un outil unique mais sont détectés par la combinaison.

Étape 4 : Tests de régression et mutation testing

Le code IA passe souvent les tests existants — parce que les LLM sont capables de lire les tests et de générer du code qui les satisfait sans réellement implémenter la logique attendue. C'est le problème du « teaching to the test ». Pour contrer cela, vous devez aller au-delà de la simple couverture de tests avec le mutation testing.

Le mutation testing modifie aléatoirement le code (mutations) et vérifie que vos tests détectent ces modifications. Si une mutation passe sans être détectée, cela signifie que vos tests ne couvrent pas réellement ce cas. C'est particulièrement révélateur pour le code IA qui a tendance à produire des implémentations « correctes en surface ».

// stryker.config.mjs - Configuration Stryker pour mutation testing
/** @type {import('@stryker-mutator/api/core').PartialStrykerOptions} */
export default {
  mutate: [
    // Cibler spécifiquement les fichiers modifiés par IA
    'src/**/*.ts',
    '!src/**/*.test.ts',
    '!src/**/*.spec.ts',
  ],
  testRunner: 'vitest',
  reporters: ['html', 'clear-text', 'progress'],
  thresholds: {
    high: 80,
    low: 60,
    break: 50, // Fail si < 50% des mutations détectées
  },
  // Focus sur les mutations les plus pertinentes pour le code IA
  mutator: {
    excludedMutations: [
      'StringLiteral', // Ignore les changements de strings
    ],
  },
};

En pratique, exécutez le mutation testing sur les fichiers modifiés par IA dans la PR. Si le score de mutation est inférieur à 60 %, c'est un red flag : le code passe les tests mais n'est pas réellement testé en profondeur. Demandez des tests supplémentaires avant le merge.

Étape 5 : Revue architecturale et détection de code dupliqué

Les LLM ont une tendance bien documentée à ré-implémenter des fonctionnalités qui existent déjà dans le projet. Ils ne « connaissent » pas votre base de code dans sa globalité (même avec un contexte étendu) et produisent souvent des fonctions utilitaires, des helpers, ou des abstractions qui dupliquent du code existant. C'est un problème majeur pour la maintenabilité.

Utilisez un outil de détection de clones de code pour identifier ces duplications. jscpd (open source) est efficace pour JavaScript/TypeScript, tandis que PMD CPD couvre Java, Python, Go et d'autres langages.

# Détecter les duplications dans les fichiers modifiés par la PR
npx jscpd \
  --pattern "src/**/*.{ts,tsx}" \
  --min-lines 5 \
  --min-tokens 50 \
  --threshold 5 \
  --reporters "json" \
  --output /tmp/cpd-report

# Vérifier le résultat
DUPLICATES=$(cat /tmp/cpd-report/jscpd-report.json | jq '.statistics.total.duplicatedLines')
if [ "$DUPLICATES" -gt 0 ]; then
  echo "⚠️ $DUPLICATES lignes dupliquées détectées"
  echo "Le code IA a probablement ré-implémenté une fonctionnalité existante."
  echo "Vérifiez si un helper/util existant couvre ce cas."
fi

Au-delà de la duplication pure, vérifiez que le code IA respecte les patterns architecturaux du projet. Les LLM mélangent fréquemment les couches (logique métier dans un composant UI, appels API dans un handler d'événement, etc.). Définissez des règles architecturales explicites dans un fichier .architecture-rules que Qodo Merge ou votre outil de review peut utiliser comme référence.

Si vous utilisez un framework comme Next.js, vérifiez aussi que le code IA ne mélange pas les server components et client components de manière incorrecte — un problème très courant avec le code généré par IA pour l'App Router.

Étape 6 : Métriques de couverture et seuils qualité

La couverture de tests classique (line coverage) est un indicateur insuffisant pour le code IA. Vous avez besoin de métriques plus fines : branch coverage (chaque branche if/else est-elle testée ?), mutation score (étape 4), et complexity index (le code IA est-il plus complexe que nécessaire ?).

Définissez des seuils différenciés pour le code humain et le code IA. Le code IA, parce qu'il est généré rapidement et sans la compréhension contextuelle d'un humain, doit répondre à des critères plus stricts :

# quality-gates.yml - Seuils qualité différenciés
quality_gates:
  # Code humain - seuils standard
  human_code:
    line_coverage: 70
    branch_coverage: 60
    mutation_score: 50
    max_complexity: 15
    max_function_length: 80

  # Code IA - seuils plus stricts
  ai_generated_code:
    line_coverage: 85       # +15% vs humain
    branch_coverage: 80     # +20% vs humain
    mutation_score: 70      # +20% vs humain
    max_complexity: 10      # Plus strict
    max_function_length: 50 # Plus court
    max_duplicated_lines: 0 # Zéro duplication
    required_reviewers: 1   # Au moins 1 reviewer humain

Ces seuils plus stricts pour le code IA se justifient par le coût marginal quasi nul de la génération. Si un LLM peut produire du code en 30 secondes, il peut aussi produire les tests associés. La barrière « c'est trop long d'écrire des tests » n'existe plus — donc exigez-les systématiquement.

Intégrez ces vérifications dans votre outil de review automatique. Qodo Merge permet de définir des policies personnalisées qui bloquent le merge si les seuils ne sont pas atteints. C'est la différence entre un guideline qu'on oublie et une règle appliquée automatiquement.

Étape 7 : Documenter les décisions et maintenir l'ADR

La dernière étape est souvent négligée mais critique pour les projets open source : documenter pourquoi le code a été généré par IA et quelles décisions architecturales ont été prises. Un contributeur futur qui lit du code IA sans contexte ne saura pas si les choix sont intentionnels ou simplement le résultat d'un prompt mal formulé.

Utilisez le format ADR (Architecture Decision Records) pour documenter les décisions liées au code IA :

# docs/adr/0015-ai-generated-auth-module.md

# ADR-0015: Module d'authentification généré par Claude Code

## Statut
Accepté (après audit étape 1-6)

## Contexte
Le module d'authentification OAuth2 a été généré par Claude Code
le 2026-07-03. Il implémente le flow PKCE pour notre SPA React.

## Décision
Nous acceptons le code IA après les modifications suivantes :
- Remplacement de crypto.randomBytes par Web Crypto API
- Ajout de la validation CSRF sur le callback
- Suppression du fallback SHA256 (nous exigeons SHA512)
- Ajout de 12 tests unitaires couvrant les edge cases

## Risques identifiés
- Le code utilise un pattern de retry non standard (corrigé)
- La gestion des tokens expirés est simpliste (TODO: améliorer)

## Métriques post-audit
- Line coverage: 92%
- Branch coverage: 85%
- Mutation score: 74%
- Semgrep: 0 findings
- Complexité max: 8 (seuil: 10)

Pour les projets open source, ces ADR sont doublement importants. Ils permettent aux contributeurs externes de comprendre le contexte des décisions, et ils démontrent une gouvernance transparente du code IA — ce qui renforce la confiance de la communauté et des utilisateurs enterprise.

En complément, maintenez un fichier AI_POLICY.md à la racine du projet qui explicite votre politique vis-à-vis du code IA : est-il accepté ? Sous quelles conditions ? Quels outils sont autorisés ? Quelles étapes d'audit sont obligatoires ? Cela facilite l'onboarding des nouveaux contributeurs et évite les débats répétitifs dans les PRs.

Récapitulatif : checklist d'audit en une page

Voici la checklist complète à imprimer et afficher près de votre écran. Chaque PR contenant du code IA devrait passer par ces vérifications :

1. Traçabilité — Le commit est-il tagué AI-Assisted-By ? L'outil utilisé est-il identifié ?
2. Analyse statique — Semgrep + linter + règles personnalisées : 0 findings critiques ?
3. Sécurité — Scan OWASP + secrets + dépendances : aucune vulnérabilité introduite ?
4. Tests — Couverture + mutation score au-dessus des seuils IA ?
5. Architecture — Pas de duplication ? Respect des patterns du projet ?
6. Métriques — Complexité et longueur des fonctions dans les limites ?
7. Documentation — ADR créé pour les changements significatifs ?

Si une seule de ces vérifications échoue, la PR doit être retournée pour correction. Avec des outils comme Qodo Merge, la plupart de ces étapes sont automatisées et ne prennent que quelques minutes par PR. L'investissement initial en configuration est rentabilisé dès la première semaine.

Questions fréquentes