Tests de non-régression d'une IA : prompt ou modèle

Un test de non-régression vérifie qu'une modification (nouvelles consignes, nouveau modèle, nouveaux documents) n'a rien cassé de ce qui marchait. Pour une application d'IA, il prend la forme d'un jeu de questions dont les bonnes réponses sont connues, relancé automatiquement à chaque changement, avec une règle simple : presque tout doit passer, et chaque échec se lit avant de livrer.

Pourquoi c'est indispensable avec l'IA

Avec un logiciel classique, on sait souvent quelle partie une modification touche. Avec un modèle de langage, une phrase ajoutée aux consignes pour régler un cas peut en dérégler dix autres, et un changement de version du modèle peut modifier le ton, la longueur ou le format de toutes les réponses. Google cite d'ailleurs la migration d'un modèle à l'autre comme premier usage de son service d'évaluation : comparer les versions pour repérer les différences de comportement, puis ajuster prompts et paramètres. Le chantier complet d'un changement de modèle est décrit sur changer de LLM sans tout refaire.

Deux jeux, deux rôles

L'article d'Anthropic sur l'évaluation des agents distingue :

Quand une question du jeu de capacité passe de façon stable, elle rejoint le jeu de non-régression. Anthropic parle de saturation quand un jeu ne laisse plus de marge de progrès : c'est le signe qu'il faut écrire de nouvelles questions de capacité, pas que l'application est parfaite.

Ce que contient le jeu de non-régression

• Les questions les plus fréquentes, celles dont une erreur toucherait beaucoup d'utilisateurs.
• Chaque échec corrigé en production : une fois réglé, il ne doit pas revenir.
• Les règles strictes : ne jamais donner un prix qui n'est pas dans les documents, toujours passer la main sur une réclamation, toujours répondre en français.
• Les formats attendus par un autre logiciel : un JSON valide, un champ obligatoire.

Privilégiez les contrôles par code (présence d'une mention, format, refus attendu) : ils donnent le même résultat à chaque passage. Gardez le juge automatique pour ce qui ne se vérifie pas autrement.

Le lancer automatiquement

La documentation de promptfoo donne un modèle d'intégration continue (le lancement automatique des tests à chaque modification du dépôt de code) : un flux GitHub Actions qui se déclenche quand un fichier de prompts change, lance l'évaluation et refuse la modification s'il y a un seul échec. Extrait, avec une clé Anthropic passée par les secrets du dépôt :

on:
  pull_request:
    paths:
      - 'prompts/**'
      - 'promptfooconfig.yaml'
jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '24'
      - name: Run eval
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: npx promptfoo@latest eval -c promptfooconfig.yaml -o results.json
      - name: Check quality gate
        run: |
          FAILURES=$(jq '.results.stats.failures' results.json)
          if [ "$FAILURES" -gt 0 ]; then exit 1; fi

La même documentation montre une variante qui tolère un taux d'échec, en calculant le taux de réussite dans results.json et en refusant la modification sous 95 %. Choisissez le seuil avant la première exécution, pas après avoir vu le résultat.

Les pièges

• Le cache. promptfoo garde les réponses en cache 14 jours par défaut. C'est utile pour ne pas repayer des appels identiques, mais un changement de version du modèle derrière un même nom ne serait pas vu. Après un changement de modèle, relancez avec --no-cache.
• La variabilité. Un modèle ne répond pas deux fois exactement pareil. Une question qui échoue une fois sur cinq n'est pas forcément une régression de la nouvelle version : relancez-la plusieurs fois avant de conclure, et notez-la comme instable.
• Le jeu qui vieillit. Quand vos documents changent, une réponse attendue devient fausse. Mettez à jour la référence en même temps que le document, sinon le test échoue pour une bonne réponse.
• Le seuil qu'on abaisse. Si un test échoue, on corrige l'application ou la référence, jamais le seuil pour faire passer la livraison.

Après la livraison

Les tests de non-régression protègent ce que vous savez déjà tester. Ce que vous ne savez pas encore tester se découvre en production, puis rejoint le jeu : voir évaluer en production et constituer un jeu de test.