Les bonnes pratiques pour le CI/CD d’agents IA ne sont pas les mêmes que celles du CI/CD traditionnel pour les logiciels. Après avoir fait fonctionner des agents IA en production pendant huit mois, voici les pratiques qui comptent vraiment — testées par des déploiements réels, et non par des exercices théoriques.
Pratique 1 : Versionnez Tout, Y Compris les Prompts
Votre prompt système est tout aussi crucial que votre code source. Un changement d’un mot dans le prompt peut modifier chaque réponse produite par l’agent. Pourtant, la plupart des équipes traitent les prompts comme une configuration informelle — modifiés à la volée, non versionnés, non examinés.
Mettez vos prompts sous contrôle de version. Examinez les changements de prompts dans les pull requests. Taggez les versions de prompts aux côtés des versions de code. Lorsque quelque chose va mal en production, vous devez savoir quelle version du prompt était en cours d’exécution.
Je stocke les prompts en tant que fichiers markdown dans le même dépôt que le code de l’agent. Chaque changement de prompt obtient une PR, une révision et un test de comportement exécuté.
Pratique 2 : Les Tests Comportementaux Sont Non-Négociables
Les tests de code vérifient la logique. Les tests comportementaux vérifient que l’IA agit correctement. Vous avez besoin des deux.
Ma suite de tests comportementaux comprend 15 cas de test couvrant : les limites de rôle (l’agent reste-t-il dans son périmètre ?), l’exactitude factuelle (cite-t-il des informations correctes ?), le traitement des erreurs (gère-t-il les données manquantes avec aisance ?), et le ton (est-il approprié pour le contexte ?).
Chaque test s’exécute sur chaque PR. Le pipeline bloque la fusion si plus de 2 tests échouent. Cela a permis de détecter 12 régressions au cours des 4 derniers mois que les tests de code auraient manqués.
Pratique 3 : Séparer Déploiement et Publication
Déployez le code mais n’activez pas le nouveau comportement tant que vous ne l’avez pas vérifié en production. Les drapeaux de fonctionnalité rendent cela possible. Déployez le lundi, activez pour les utilisateurs internes le mardi, activez pour tout le monde le mercredi.
C’est particulièrement important pour les agents IA car les changements de comportement (dus aux mises à jour de prompt ou de modèle) sont plus difficiles à prédire que les changements de code. Séparer le déploiement de la publication vous donne un tampon pour gérer les surprises.
Pratique 4 : Surveillez le Comportement, Pas Juste le Temps de Disponibilité
Surveillance traditionnelle : le service est-il opérationnel ? Le temps de réponse est-il acceptable ? Le taux d’erreur est-il bas ?
La surveillance IA ajoute : la qualité des réponses est-elle cohérente ? Le taux de hallucinations est-il stable ? Les utilisateurs sont-ils satisfaits ? Les coûts sont-ils prévisibles ?
Je suis un « score de qualité » qui est calculé en échantillonnant 10 % des réponses et en les évaluant selon des critères. Une baisse du score de qualité déclenche une alerte même si le service est techniquement sain.
Pratique 5 : Automatisez le Rétablissement
Lorsque quelque chose va mal lors d’un déploiement, chaque minute compte. Le rétablissement manuel signifie : constater le problème, se connecter au serveur par SSH, se souvenir de la commande de rétablissement, l’exécuter. Cela prend de 5 à 15 minutes dans le meilleur des cas.
Le rétablissement automatisé signifie : que le système de surveillance détecte le problème (pic du taux d’erreur, chute de qualité), revient automatiquement à la version précédente et vous alerte qu’un rétablissement a eu lieu.
Mon rétablissement automatisé se déclenche lorsque : le taux d’erreur dépasse 10 % pendant 3 minutes, ou que le score de qualité tombe en dessous de 3/5 pendant 5 minutes. Les faux positifs sont rares (environ une fois tous les 2 mois) et le coût d’un faux positif (un rétablissement et une redeployment inutiles) est bien inférieur au coût d’un vrai positif non géré.
Pratique 6 : Gardez le Pipeline Rapide
Si le pipeline CI/CD prend 30 minutes, les gens trouveront des moyens de l’ignorer. Gardez-le sous 15 minutes pour le pipeline complet (tests de code + tests comportementaux + déploiement de staging). Mon pipeline s’exécute en environ 12 minutes.
Les tests comportementaux sont le goulet d’étranglement — chacun nécessite un appel API IA. Parallelisez-les (exécutez tous les 15 tests simultanément au lieu de séquentiellement) et définissez des délais raisonnables (si un test n’a pas été complété en 60 secondes, il échoue).
Le Pipeline Minimum Viable
Si vous partez de rien, implémentez ceci dans l’ordre :
1. Contrôle de version pour le code et les prompts (jour 1)
2. Tests de code en CI (semaine 1)
3. Déploiement bleu-vert (semaine 1)
4. 5 tests comportementaux en CI (semaine 2)
5. Surveillance post-déploiement (semaine 2)
6. Rétablissement automatisé (semaine 3)
Chaque étape ajoute de la sécurité. Vous pouvez expédier avec seulement les étapes 1-3 et ajouter le reste de manière incrémentale. N’attendez pas d’avoir le « pipeline parfait » — commencez à déployer en toute sécurité aujourd’hui et améliorez-vous en continu.
🕒 Published: