Le terme CI/CD évoque des pipelines d’intégration continue et de déploiement continu, et il est le plus souvent pensé pour du code classique : on pousse, on teste, on déploie. Un projet IA ajoute une difficulté que ce schéma ne prévoit pas. Le comportement d’un système IA ne dépend pas seulement du code, il dépend aussi du modèle, des prompts et des données. Un changement sur l’un de ces éléments peut casser la sortie sans qu’aucun test unitaire classique ne le détecte.
C’est pour cela que beaucoup d’équipes déploient leur IA à la main, en copiant des fichiers et en espérant. Elles savent que le déploiement automatisé leur échapperait, alors elles le contournent. Le résultat est le même que dans tout projet sans filet : la peur de déployer s’installe, les changements s’accumulent, et les incidents se multiplient.
Cet article décrit par où commencer pour mettre en place une chaîne de déploiement adaptée à l’IA, sans viser d’emblée une usine logicielle. L’objectif est un premier filet, pas une architecture complète.
Commencer par les tests qui comptent
Dans un projet IA, les tests classiques ne suffisent pas. Tester que la fonction d’appel retourne bien une réponse ne dit rien de la qualité de cette réponse. Les tests qui comptent sont ceux qui vérifient le comportement attendu sur des exemples représentatifs : la sortie est au bon format, elle contient les bons champs, elle respecte les contraintes métier.
La première étape d’une chaîne de déploiement consiste donc à transformer le jeu d’évaluation en tests automatisés. Chaque exemple devient une assertion : pour cette entrée, la sortie doit valider ces conditions. Promptfoo, qui décrit les cas dans un simple fichier de configuration, ou DeepEval, qui s’écrit comme des tests pytest, s’exécutent tels quels dans GitHub Actions ou GitLab CI. C’est ce qui permet de détecter qu’un nouveau prompt ou un nouveau modèle dégrade le système, avant que la version ne parte en production. Sans ce filet, aucune automatisation n’est possible. Si vous partez de zéro sur ce sujet, on détaille la construction de ces cas dans les evals expliquées.
L’évaluation comme porte de validation
Une fois le jeu d’évaluation automatisé, il devient la porte d’entrée du pipeline. À chaque changement, on relance l’évaluation, et on compare le résultat à la version précédente. Si le score baisse, le déploiement s’arrête. C’est l’équivalent, pour l’IA, des tests de non-régression du code classique.
Cette porte a une exigence : le jeu d’évaluation doit être représentatif. S’il ne contient que des cas faciles, il laissera passer des régressions. Il faut l’alimenter en continu avec les cas réels qui échouent en production. C’est une boucle : la production nourrit l’évaluation, l’évaluation protège la production. Sans cet apport continu, le filet se relâche en quelques semaines. La mettre en place dès le départ évite le piège classique d’un jeu d’évaluation figé qui ne teste plus rien.
Séparer les déploiements de code, de prompts et de modèles
Un changement de prompt n’a pas le même risque qu’un changement de code, et un changement de modèle encore moins. Les traiter de la même façon, c’est soit ralentir les petits changements, soit banaliser les gros. Un prompt peut être ajusté et redéployé plusieurs fois par jour sans risque majeur, par exemple via la gestion de prompts versionnés de Langfuse ou LangSmith, tandis qu’un changement de modèle mérite une validation bien plus large. La bonne approche consiste à séparer les chemins de déploiement, chacun avec son niveau de validation.
Un changement de prompt se valide par une évaluation rapide sur le jeu de test, et peut partir fréquemment. Un changement de modèle exige une évaluation plus large, parfois une comparaison en parallèle sur du trafic réel, avant de basculer. Un changement de code passe par les tests classiques plus l’évaluation. Cette séparation rend le déploiement proportionné au risque, et c’est elle qui rend la chaîne vivable au quotidien.
Le déploiement progressif et la bascule
Déployer une nouvelle version d’un système IA d’un seul coup expose tous les utilisateurs à la fois à un éventuel défaut. Le déploiement progressif réduit cette exposition : on envoie une petite fraction du trafic vers la nouvelle version, on mesure, puis on élargit (c’est le principe du déploiement canary appliqué à l’IA). Si la nouvelle version dégrade, on revient en arrière sans que l’ensemble du service soit touché.
Cette pratique suppose de pouvoir faire tourner deux versions en parallèle et de comparer leurs sorties. C’est un investissement en architecture, mais il est décisif pour les systèmes dont la sortie a un coût en cas d’erreur. Le déploiement progressif transforme une bascule risquée en une décision mesurée, et c’est exactement ce qu’attend un produit en production.
Observer après le déploiement
Le déploiement ne s’arrête pas quand la version est en ligne. Un système IA peut dériver dans le temps : les données d’entrée changent, les utilisateurs formulent différemment, le modèle se comporte autrement sous charge. Il faut donc observer ce qui se passe après le déploiement, pas seulement au moment de le faire.
Les traces de chaque appel, relevées en production avec Langfuse, LangSmith ou un collecteur OpenTelemetry, donnent cette visibilité. Elles permettent de repérer une dégradation lente, de détecter une anomalie dans les sorties, et de nourrir le jeu d’évaluation. La chaîne de déploiement ne se limite pas au pipeline : elle inclut cette boucle d’observation qui fait du déploiement continu un apprentissage continu.
Par où commencer pour mettre en place un CI/CD adapté à l’IA
Mettre en place un CI/CD pour un projet IA ne consiste pas à brancher un outil générique, mais à construire le filet qui manque : des évaluations automatisées, des chemins de déploiement proportionnés au risque, et une observation après la mise en ligne. Inutile de viser l’usine logicielle dès le premier jour : un jeu d’évaluation branché sur chaque merge change déjà la donne.
Concrètement, on commence par regarder l’existant, puis on transforme le jeu d’évaluation en tests automatisés, on sépare les chemins de déploiement et on branche la bascule progressive. C’est le socle de notre méthode de mise en production : evals, CI/CD et garde-fous, posés avant d’empiler les fonctionnalités.
Le cas le plus fréquent qu’on rencontre : un produit monté vite avec Lovable, Bolt, Cursor ou Claude Code, qui a trouvé ses utilisateurs mais que personne n’ose plus déployer le vendredi. Si c’est votre situation, la reprise de produits construits avec l’IA commence justement par ce filet : un pipeline GitHub Actions, des environnements de prévisualisation sur Vercel, une base Supabase de recette séparée de la production. L’objectif reste le même dans tous les cas : que déployer redevienne un geste ordinaire, et que chaque incident finisse en test qui l’empêche de revenir.
