Botpress : déployer plusieurs bots (multi-env) + CI/CD (guide 2026)

Botpress : déployer plusieurs bots (multi-env) + CI/CD (guide 2026)

Quand on passe de “un chatbot de test” à plusieurs bots en production, les problèmes arrivent vite : collisions de configuration, secrets mélangés, environnements impossibles à maintenir, mises à jour risquées.

Dans ce guide, on voit une approche simple et robuste pour :

• isoler vos bots (et vos environnements dev/staging/prod)
• standardiser la configuration (secrets, domaines, stockage)
• automatiser les déploiements avec un pipeline CI/CD

Si vous n’avez pas encore un déploiement de base propre, commencez par : Installer Botpress avec Docker (prod) + reverse proxy HTTPS.

1) Clarifier votre besoin : “plusieurs bots” veut dire quoi ?

Il y a 3 cas fréquents :

1. Un bot, plusieurs environnements : dev → staging → prod (le plus courant)
2. Plusieurs bots pour la même entreprise : ex. un bot Support + un bot Commercial + un bot RH
3. Plusieurs bots pour plusieurs marques / filiales : séparation stricte, contraintes RGPD

Dans les 3 cas, vous gagnez à poser une règle : un bot = un périmètre d’exploitation (domaine, secrets, données, logs, sauvegardes). Pour cadrer la production côté sécurité/observabilité : Sécuriser et monitorer Botpress en production.

2) Le pattern le plus fiable : une instance par environnement (et souvent par bot)

En pratique, le modèle “qui tient dans le temps” ressemble à ça :

• support-dev, support-staging, support-prod
• sales-dev, sales-prod

Chaque instance a :

• son domaine (ou sous-domaine)
• ses volumes persistants
• ses identifiants (tokens, webhooks, clés)
• sa politique de sauvegardes et sa rétention

C’est plus simple à opérer qu’une grosse instance partagée, et surtout plus simple à sécuriser (isolation des accès et des secrets).

Pour l’expo web (widget) et éviter les mauvaises surprises côté tracking : Brancher Botpress à votre site : widget + tracking + analytics.

3) Domaines, routing et accès : éviter les collisions

Recommandation : un sous-domaine par instance. Exemple :

• support-dev.votre-domaine.fr
• support.votre-domaine.fr
• sales.votre-domaine.fr

Avec un reverse proxy (Nginx/Traefik), vous :

• forcez HTTPS
• appliquez des limites (rate limit)
• restreignez l’admin (VPN / IP allowlist / authentification au proxy)

Si vous connectez des canaux externes (Messenger, WhatsApp, etc.), ce découpage évite les confusions de webhooks entre bots.

Sur adgents.cloud, vous pouvez gérer des instances séparées facilement, avec stop/start (pour maîtriser les coûts), scaling CPU/RAM à la demande, et backups automatiques. Voir : Botpress sur adgents.cloud.

4) Données et persistance : 1 bot = 1 stockage = 1 politique de sauvegarde

Les erreurs classiques quand on multiplie les bots :

• partager un même volume “par facilité”
• recycler des identifiants entre dev et prod
• ne jamais tester une restauration

Ce qu’on recommande :

• un répertoire/volume par instance (ex. botpress_support_prod_data)
• des secrets distincts par environnement
• une restauration testée en staging (au moins à chaque gros changement)

Si vos bots manipulent des données sensibles (support, commandes, SAV), c’est aussi ce qui rend la conformité plus simple : vous savez où sont les données et combien de temps vous les gardez.

5) Organisation Git : monorepo ou repo par bot ?

Deux approches fonctionnent :

• Repo par bot : simple à lire, permissions claires, pipeline plus direct
• Monorepo : utile si vous partagez beaucoup de composants (intégrations, scripts, tests)

Quel que soit le choix, standardisez :

• un fichier de variables par environnement (dev/staging/prod)
• une convention de noms pour les secrets
• un numéro de version (tag Git) associé à chaque déploiement prod

Pour industrialiser vos conversations, vous pouvez aussi pousser une partie des définitions “as code” (selon votre manière de travailler et votre version de Botpress).

6) CI/CD : un pipeline simple (build → test → déployer)

Un pipeline “propre” peut ressembler à :

1. Build d’une image Docker versionnée (tag = commit SHA ou tag Git)
2. Exécution de checks (lint, tests, validation de configuration)
3. Déploiement automatique sur staging
4. Déploiement prod sur validation (approval)

Pour un exemple concret côté Botpress (Docker + déploiement), ce dépôt peut servir de base : botpress/botpress-cicd-example.

Pour éviter une mise en prod “à l’aveugle”, gardez une règle simple :

• staging reçoit tout automatiquement
• prod reçoit uniquement des versions taggées, avec un rollback possible

7) Observabilité : logs, métriques et alertes par instance

Dès que vous avez plusieurs bots, vous devez pouvoir répondre vite à :

• “Quel bot est en erreur ?”
• “Depuis quand ?”
• “Est-ce un problème de charge, de canal, ou d’intégration ?”

Le minimum utile par instance :

• erreurs (taux, traces)
• latence (p95/p99)
• CPU/RAM
• disponibilité (healthcheck)

Pour une checklist production sécurité + monitoring, ce guide complète bien : Sécuriser et monitorer Botpress en production (logs, RGPD, perf).

8) Vidéo (FR) : prendre Botpress en main

Pour un pas-à-pas en français (création + publication), vous pouvez suivre : .

Conclusion

Déployer plusieurs bots Botpress sans stress, c’est surtout :

• isoler vos instances (au minimum par environnement)
• standardiser domaines, secrets, volumes et sauvegardes
• automatiser les déploiements avec une validation staging → prod

Si vous voulez un socle simple à opérer (déploiement rapide, backups automatiques, scaling, stop/start), vous pouvez lancer vos instances : hébergement Botpress sur adgents.cloud.