CI/CD pour agents IA : tester avant de déployer

Le déploiement d’un logiciel classique repose sur une certitude confortable : le code qui passe les tests aujourd’hui se comportera demain exactement comme il l’a fait. Avec un agent IA, cette certitude n’existe pas. Un prompt reformulé, un modèle mis à jour, un outil légèrement modifié, et c’est tout un comportement qui peut changer, parfois pour le meilleur, souvent pour le pire, sans qu’aucun test classique ne s’en aperçoive.

Cette différence est la raison pour laquelle les agents IA, souvent développés comme des scripts, finissent par se déployer à la main, sur un espoir, avec une vérification de fortune. Or c’est précisément l’inverse de ce qu’exige leur nature imprévisible : plus un système est incertain, plus son déploiement doit être encadré. C’est tout l’enjeu d’appliquer la logique du CI/CD aux agents IA.

Cet article explique comment construire un pipeline de déploiement pour un agent : automatiser les evals, poser des portes de qualité qui bloquent les régressions, et déployer de façon progressive pour limiter l’impact des changements qui passent quand même à travers les mailles.

Ce qu’un pipeline d’agent doit vérifier

Un pipeline classique vérifie que le code compile et que les tests passent. Un pipeline d’agent doit vérifier bien plus, parce que la source de la régression n’est pas seulement dans le code mais dans tout ce qui entoure le modèle. Il y a d’abord le prompt : toute modification de consigne doit être confrontée au jeu de cas de référence. Il y a ensuite le modèle : changer de version ou de fournisseur modifie la qualité des réponses, et doit être validé de la même façon.

Il y a encore les outils et les données : un changement de schéma de base, de format d’API, de contenu des documents consultés, peut faire dérailler un agent sans toucher au code. Le pipeline doit donc exécuter l’agent sur des cas réels, avec les vraies données et les vrais outils, ou au plus près de leur version de test. C’est une exécution de bout en bout, pas une vérification de composants isolés.

Enfin, le pipeline doit mesurer les coûts, pas seulement la qualité. Un changement qui améliore légèrement les réponses mais double la consommation de tokens n’est pas neutre : il fait grimper la facture d’exploitation. Un bon pipeline vérifie donc à la fois le score de qualité et le coût moyen par requête, et bloque les changements qui dégradent l’un comme l’autre.

Automatiser les evals dans le pipeline

Le cœur du pipeline est l’exécution automatique des evals à chaque modification. Une eval confronte les sorties de l’agent à des critères sur un jeu de cas représentatif (le principe est détaillé dans Comment évaluer un agent IA : les evals expliquées). Branchée dans un pipeline, elle devient une étape automatique qui rend un verdict chiffré : le score est-il stable, meilleur ou moins bon que la référence. C’est ce verdict qui autorise ou bloque le déploiement. Concrètement, un job GitHub Actions ou GitLab CI lance Promptfoo ou DeepEval (qui s’intègre à pytest) sur le jeu de cas, et fait échouer la build sous le seuil fixé.

L’automatisation repose sur la répétabilité. Le jeu de cas doit être versionné, les critères doivent être codés de façon déterministe, et l’exécution doit produire un rapport comparable d’une fois sur l’autre. Le modèle-juge (LLM-as-a-judge), lorsqu’il est utilisé, doit être figé dans une version datée précise, car changer de juge à chaque exécution rendrait les scores incomparables. La reproductibilité est la condition de tout le reste.

Cette automatisation change le rapport au changement. Au lieu de déployer un prompt modifié et d’espérer, on soumet ce prompt au pipeline et on lit le score. Une baisse nette bloque la modification et pointe les cas qui ont régressé. C’est la même boucle que celle du test unitaire en développement classique, appliquée à la qualité floue d’un agent.

Poser des portes de qualité qui bloquent vraiment

Une porte de qualité est un seuil en deçà duquel le déploiement est refusé. Pour un agent, ce seuil se définit sur le score global de l’eval, mais aussi sur des seuils par cas critique. On accepte qu’un cas secondaire régresse légèrement si le gain global est net ; on refuse en revanche qu’un cas critique, celui qui touche aux données ou à l’argent, régresse d’un point. La porte doit donc distinguer les cas qui ont le droit de bouger de ceux qui n’en ont pas.

Cette distinction se construit à partir du coût de l’échec. Les cas critiques sont ceux dont l’échec coûte cher : une réponse fausse à un client, une action non autorisée, une donnée mal traitée. Sur ces cas, la porte est stricte, et toute régression bloque. Sur les cas secondaires, la porte tolère une marge, pour ne pas paralyser le développement. C’est ce réglage fin qui rend le pipeline à la fois protecteur et utilisable.

Il faut aussi une porte sur les coûts. Un changement qui fait exploser la consommation de tokens ne doit pas passer, même si le score de qualité s’améliore. On pose donc un plafond sur le coût moyen par requête, mesuré par le pipeline lui-même à partir des tokens consommés (Promptfoo et Langfuse les remontent), et on le traite comme n’importe quel autre critère bloquant. La qualité sans la maîtrise des coûts n’est pas une qualité soutenable.

Déployer de façon progressive, pas d’un bloc

Même un pipeline rigoureux laisse passer des changements que les evals ne détectent pas, car le jeu de cas ne couvre jamais tout le trafic réel. C’est pourquoi le déploiement d’un agent ne doit jamais se faire d’un bloc. Il se fait par paliers : un sous-ensemble du trafic d’abord, une observation attentive, puis l’élargissement progressif si les indicateurs tiennent.

Ce déploiement progressif prend des formes concrètes. Le déploiement canari consiste à envoyer une petite fraction du trafic vers la nouvelle version pendant que le reste continue sur l’ancienne, et à comparer les deux en production réelle. Le basculement se fait sur des indicateurs observés : taux d’erreur, taux de validation humaine, coût par requête, retours utilisateurs. Si l’un de ces indicateurs dérive, on revient en arrière, ce qui doit être un geste trivial et non une opération de crise. Nous détaillons la mise en place dans Déploiement canary pour l’IA : réduire le risque.

La condition de cette réversibilité est de versionner tout ce qui change : le prompt, le modèle, les outils, la configuration. Le code et la configuration vont dans Git et dans une image Docker ; les prompts peuvent y rester ou passer par la gestion de prompts de Langfuse ou LangSmith, qui attribue une version à chaque modification. Un agent dont on ne peut pas reconstituer l’état exact à un instant donné est un agent qu’on ne peut pas déployer ni reculer proprement. La version fait partie du pipeline, au même titre que les tests, car c’est elle qui rend le déploiement progressif possible.

Par quoi commencer si vous n’avez rien

Inutile de tout construire d’un coup. La première marche, et de loin la plus rentable, est un jeu d’une cinquantaine de cas réels versionné avec le code, exécuté automatiquement à chaque modification de prompt ou de modèle, avec un rapport comparé à la version précédente. Les portes de qualité, le suivi du coût et le déploiement canari viennent ensuite, quand ce socle tourne sans intervention.

Ce pipeline fait partie de notre méthode de mise en production sur chaque projet : evals automatisées, seuils bloquants définis avec vous selon le coût de l’échec, déploiement par paliers et retour arrière immédiat. C’est ce qui permet aux agents IA que nous construisons d’évoluer sans casser en production.