Le DevOps a résolu ce problème pour le logiciel il y a des années. Vous ne poussez pas le code directement en production. Vous développez localement, testez en staging, promouvez à travers des portes et déployez avec des revues. Le schéma fonctionne parce qu’il attrape les erreurs avant qu’elles n’atteignent les utilisateurs.
Les workflows IA méritent la même discipline. Un changement de prompt, un changement de modèle, une nouvelle intégration d’outil — ceux-ci affectent la qualité de la sortie en production autant qu’un changement de code affecte le comportement d’une application. Mais la plupart des plateformes IA traitent chaque changement comme un changement de production. Modifiez un workflow et c’est en direct. Pas de revue. Pas de staging. Pas de filet de sécurité.
La gestion d’environnements de JieGou apporte le pipeline dev-staging-prod aux workflows IA.
Trois environnements
Chaque workflow existe indépendamment dans trois environnements. Chacun a sa propre configuration, ses propres exigences d’approbation et son propre historique de déploiement.
| Environnement | Approbation requise | Rôle minimum de promotion |
|---|---|---|
| Développement | Non | Membre |
| Staging | Oui | Responsable de département |
| Production | Oui | Admin |
Développement est le sandbox. N’importe qui dans l’équipe peut déployer ici sans approbation. Testez de nouveaux prompts, changez de modèles, ajoutez des étapes — itérez librement sans risque.
Staging reflète la production mais avec des limites sûres. La promotion de dev à staging nécessite qu’un responsable de département examine et approuve les changements. C’est là que vous validez qu’un workflow se comporte correctement avant qu’il ne gère de vraies charges de travail.
Production est l’environnement en direct. La promotion de staging à production nécessite l’approbation d’un Admin. Les changements ici affectent de vrais utilisateurs, de vraies données, de vraies sorties.
Paramètres indépendants par environnement
Les environnements ne sont pas seulement des niveaux de permission. Chacun porte sa propre configuration opérationnelle :
- Instances de serveur MCP — Slack sandbox en dev, Slack de production en prod. Testez contre des intégrations simulées sans déclencher de vrais effets de bord.
- Fournisseur et modèle LLM par défaut — Utilisez un modèle moins cher et plus rapide en dev pour l’itération rapide. Utilisez le meilleur modèle en prod pour la qualité de sortie.
- Portes d’approbation — Différentes exigences de rôle par environnement, correspondant à la tolérance au risque de votre organisation à chaque niveau.
- Webhooks de déploiement — Notifiez différents canaux Slack ou systèmes CI/CD par environnement. Les déploiements dev pingent
#eng-dev, les déploiements production pingent#ops-alerts. - Variables d’environnement — Paires clé-valeur non secrètes injectées dans les modèles d’étapes. Pointez
API_BASE_URLvers votre serveur de test en staging et votre serveur de production en prod.
Le pipeline de promotion
La promotion suit une séquence stricte. Pas de raccourcis.
- Un développeur fait des changements et déploie en dev. Pas d’approbation nécessaire — déployez autant de fois que vous voulez.
- Le développeur demande une promotion de dev à staging. Le système calcule un diff de version — une comparaison structurelle de ce qui a changé entre la version staging actuelle et la version proposée.
- Un responsable de département examine le diff et approuve ou rejette la promotion.
- Sur approbation, la version du workflow se déploie automatiquement en staging. C’est atomique — approbation et déploiement se font en une seule étape.
- Le même processus se répète de staging à production, nécessitant l’approbation Admin.
Prévention de l’auto-approbation : la personne qui demande une promotion ne peut pas l’approuver. Cela force une seconde paire d’yeux sur chaque changement qui progresse vers la production.
Moteur de diff de version
Les réviseurs n’approuvent pas à l’aveugle. Ils voient exactement ce qui a changé.
Le moteur de diff compare les étapes par ID entre les versions et compare plus de 15 propriétés :
- Type d’étape, libellé, modèle et fournisseur
- Attribution de recette et description de tâche
- Contenu du prompt système
- Logique de condition (configuration si/alors/sinon)
- Configuration de boucle (limites d’itération, conditions de sortie)
- Critères d’évaluation et seuils de qualité
- Dépendances d’étapes
- Étapes imbriquées dans les conditionnels et boucles
Les changements sont rendus sous forme de descriptions lisibles par l’humain :
- « Modèle changé de ‘claude-sonnet’ à ‘claude-opus’ »
- « Seuil de qualité changé de 0.7 à 0.9 »
- « Prompt système modifié »
- « Étape ‘Résumer’ ajoutée »
- « Itérations max de la boucle changées de 3 à 5 »
Suivi des déploiements
Chaque déploiement crée un enregistrement :
- Statut —
active,supersededourolled_back - Déployeur — Qui a déclenché le déploiement
- Info d’approbation — Qui a approuvé la promotion, quand et le demandeur original
- Résumé du diff — Ce qui a changé dans ce déploiement par rapport au précédent
- Horodatage — Quand le déploiement est passé en direct
Rollback
Un clic. Instantané.
Le rollback ne réexécute rien. Il inverse les statuts de déploiement : le déploiement active actuel est marqué rolled_back et le déploiement superseded précédent redevient active.
C’est un changement de statut, pas un redéploiement. La version précédente est déjà là — elle doit juste être réactivée. Pas d’étape de build, pas de pipeline de promotion, pas d’attente d’approbation. Quand la production casse, vous la réparez en secondes, puis vous enquêtez sur la cause racine avec le temps de votre côté.
Piste d’audit
Chaque opération est journalisée :
- Changements de configuration des paramètres d’environnement
- Déploiements dans n’importe quel environnement
- Demandes de promotion (qui a demandé, depuis quel environnement, vers lequel)
- Approbations, rejets et annulations de promotion
- Opérations de rollback
Chaque entrée de journal inclut des instantanés complets avant/après. Vous pouvez reconstruire l’état exact de n’importe quel environnement à n’importe quel moment. Ce n’est pas seulement de l’hygiène opérationnelle — c’est une exigence de conformité pour les organisations dans les industries réglementées.
Disponibilité
La gestion des environnements est disponible sur les plans Enterprise. Inclut les pipelines de promotion à trois environnements, le diff de versions, les portes d’approbation, le suivi des déploiements, le rollback et les pistes d’audit. En savoir plus sur les fonctionnalités entreprise ou commencez votre essai gratuit.