Bati : scalabilité multi-sites / multi-agences + monitoring (guide 2026)

Bati : scalabilité multi-sites / multi-agences + monitoring (guide 2026)

Quand Bati commence à bien tourner, la question n’est plus "comment on installe" — c’est "comment on tient la croissance" : plus d’utilisateurs, plusieurs agences, plusieurs chantiers en parallèle, et des attentes plus fortes côté disponibilité.

Ce guide vous donne une approche concrète pour :

• structurer Bati pour un usage multi-sites / multi-agences
• éviter les pièges de performance (et de données)
• mettre en place un monitoring utile (métriques + alertes)

Si vous voulez gagner du temps côté infra, vous pouvez déployer Bati sur adgents.cloud : déploiement en 1 clic, facturation à l’heure, start/stop, backups automatiques et scaling CPU/RAM à la demande.

1) Multi-sites / multi-agences : clarifier le modèle (avant de scaler)

Avant de parler CPU et RAM, il faut poser 3 décisions :

1. Qu’est-ce qu’un site ? (agence, établissement, dépôt, région…)
2. Qu’est-ce qu’une agence ? (entité juridique, équipe opérationnelle, marque…)
3. Quelles données sont partagées ? (catalogue articles, modèles de devis, référentiels, clients, règles de prix…)

Un modèle simple et robuste, très courant en SaaS :

• une organisation (votre entreprise)
• des sites (vos agences / établissements)
• des utilisateurs rattachés à un ou plusieurs sites
• des objets métier (devis, factures, chantiers) scopés par site

Objectif : éviter qu’un utilisateur d’une agence A voie ou modifie des données de l’agence B, sauf si vous l’autorisez explicitement.

Pour une mise en production propre (HTTPS, sauvegardes, bonnes pratiques), vous pouvez aussi relire : Bati : déployer sur adgents.cloud (guide 2026).

2) Permissions : RBAC + règles simples, testables

En multi-agences, les droits deviennent vite le premier sujet de tickets. Une règle qui fonctionne bien :

• RBAC (rôles) pour le 80% : Admin, Manager, Comptabilité, Commercial, Lecture
• des scopes pour le 20% : "mon site", "tous les sites", "site X + site Y"

Bonnes pratiques :

• un utilisateur peut avoir plusieurs rôles (ex : Manager + Compta)
• les actions sensibles (suppression, export massif, changement de prix) doivent être loggées
• un "super-admin" est utile, mais doit être rare

Pour cadrer l’accès (SSO, 2FA, rôles), ce guide complète bien la démarche : Bati : sécuriser l’accès (SSO, 2FA, rôles).

3) Performance : scaler au bon endroit (et pas au hasard)

Les ralentissements viennent rarement "de l’application" en général. Ils viennent de 2–3 points chauds. À surveiller en priorité :

• la base de données (requêtes, index, verrous)
• le stockage (uploads, documents, pièces jointes)
• les tâches asynchrones (imports, emails, génération PDF)

Ce qui marche très bien en multi-sites

• isoler les écritures : chaque site génère ses propres devis/factures, donc vos écritures DB sont naturellement réparties
• mettre du cache sur les référentiels partagés (catalogue, modèles)
• externaliser les traitements lourds : génération de documents et imports dans des jobs

Si vous cherchez des optimisations pragmatiques (DB, cache, assets), vous pouvez réutiliser la logique de : Bati : optimiser la performance (checklist).

4) Monitoring : le minimum viable qui évite les surprises

Le monitoring doit répondre à des questions simples :

• Est-ce que les utilisateurs peuvent se connecter ?
• Est-ce que les pages clés répondent vite ?
• Est-ce qu’il y a des erreurs en hausse ?
• Est-ce que la base de données tient la charge ?

Une approche efficace combine :

• monitoring externe (synthétique) : simule une connexion et une action clé
• métriques internes : latence, erreurs, saturation CPU/RAM
• alertes : uniquement sur ce qui demande une action

Dotcom-Monitor souligne bien les briques à surveiller dans une app SaaS : domaine/SSL, serveurs applicatifs, CDN, base de données, etc. (idée : couvrir la chaîne complète, pas un seul composant).

Métriques utiles (exemples)

• Disponibilité : taux de succès des parcours (login, création devis)
• Latence : p95/p99 sur les endpoints critiques
• Erreurs : 4xx/5xx et erreurs métier (ex : génération PDF)
• Base de données : temps de requêtes, connexions, verrous
• Jobs : taille de file, temps d’exécution, retries

5) Alertes : moins, mais mieux

Des alertes trop bruyantes finissent ignorées. Préférez :

• 3 alertes de disponibilité (parcours utilisateur)
• 3 alertes de performance (latence p95, DB lente, file qui grossit)
• 2 alertes de saturation (CPU/RAM, stockage)

Ajoutez un seuil "pré-alerte" (warning) et un seuil "incident" (critical). Et gardez un canal d’escalade clair.

6) Backups + PRA : ce qui rassure en multi-agences

En multi-sites, l’enjeu est double :

• ne pas perdre de données (RPO)
• remettre en route vite (RTO)

Concrètement :

• une sauvegarde régulière (au moins quotidienne ; plus si vous avez beaucoup d’écritures)
• des tests de restauration planifiés
• une procédure de reprise simple (qui fait quoi, où sont les accès, combien de temps)

Pour cadrer sans stress : Bati : sauvegardes, restauration et PRA (guide opérationnel).

Vidéo (YouTube, FR)

Pour aller plus loin sur l’observabilité avec Prometheus et Grafana : Playlist Prometheus / Grafana (FR) — Xavki

Déployer Bati sur adgents.cloud (et scaler proprement)

Si votre objectif est d’avoir une infra qui suit la croissance sans complexité :

• déploiement en 1 clic
• facturation à l’heure
• start/stop (compute non facturé à l’arrêt ; stockage facturé tant que l’instance existe)
• backups automatiques (jusqu’à 1/h) + rétention longue
• scaling CPU/RAM à la demande

→ Voir Bati sur adgents.cloud.