Bati : optimiser la performance (DB, cache, assets) — checklist

Bati : optimiser la performance (DB, cache, assets) — checklist

Quand Bati « rame », le problème vient rarement d’un seul endroit. La perf est un empilement : base de données, cache, réseau, front, et capacité serveur à encaisser les pics.

Dans ce guide, je te propose une checklist pragmatique (priorités + méthodes de vérification) pour gagner en stabilité, en vitesse, et en sérénité.

Si tu veux éviter la gestion d’infra et garder une marge confortable sur les pics : tu peux aussi déployer Bati en 1 clic sur adgents.cloud (scaling CPU/RAM à la demande, backups automatiques, start/stop).

1) Diagnostiquer vite : 5 signaux qui disent où chercher

Avant d’optimiser, il faut éviter le piège classique : « on touche à tout » sans mesurer.

• Temps de réponse serveur qui grimpe (TTFB) : souvent DB, cache, ou saturation CPU.
• Pics CPU côté app : endpoints lourds, rendu côté serveur, jobs, manque de cache.
• I/O disque élevés (ou stockage lent) : DB, logs, exports, thumbnails.
• RAM qui se remplit et swap : quasi-sûr que ça va dégrader la perf.
• Erreurs 5xx / timeouts : pool DB, limite reverse proxy, ou montée en charge.

Pour une base « propre » (HTTPS, persistance, reverse proxy), garde ce socle sous la main : Bati : déployer en production sur adgents.cloud (guide 2026).

2) Base de données : là où se gagnent (ou se perdent) des secondes

A) Vérifier les requêtes lentes

• Active les logs de requêtes lentes (ou l’outil de stats de la DB si dispo).
• Identifie les 5 requêtes qui coûtent le plus (durée * fréquence).
• Contrôle que les requêtes critiques utilisent bien des index.

Astuce : beaucoup d’applis “métier” souffrent de filtres/tri sur des colonnes non indexées (dates, statut, client, chantier).

B) Index : les bons, pas « tous »

• Indexe les colonnes filtrées et jointes.
• Ajoute des index composites quand les requêtes filtrent souvent sur 2 champs.
• Supprime les index inutilisés (ils ralentissent les écritures).

C) Pool de connexions : éviter l’embolie

Les timeouts viennent parfois juste d’un pool trop petit (ou d’un nombre de connexions trop grand qui épuise la DB).

• Dimensionne le pool côté app.
• Mets un pooler si nécessaire.
• Surveille connexions actives / en attente.

Pour le volet durcissement (exposition DB, accès, etc.), complète avec : Bati : sécuriser l’accès (SSO, 2FA, rôles) — bonnes pratiques.

3) Cache : trois couches à activer proprement

Le cache ne sert pas qu’à « aller plus vite » : il sert à éviter de refaire du travail.

A) Cache HTTP (reverse proxy / CDN)

Idéal pour les pages et fichiers statiques qui changent peu.

• Mets des headers cache cohérents pour les assets.
• Évite de fragmenter le cache (trop de variations selon headers/cookies).

B) Cache applicatif (résultats / pages / fragments)

• Cache les écrans “liste” coûteux (ex : tableaux, historiques) avec une durée courte.
• Invalide quand une donnée clé change (sinon tu affiches des infos obsolètes).

C) Cache de données (in-memory)

• Pour les lectures répétitives (droits, référentiels, paramètres), un cache in-memory peut réduire drastiquement la charge DB.

Si tu relies Bati à des automatisations, surveille aussi la perf des webhooks : un mauvais débit d’entrée peut faire “tomber” le reste. Exemple de logique côté automatisation : Connecter NocoDB à n8n : automatisations (leads → relances → reporting).

4) Assets (front) : gagner sans toucher au code métier

Souvent, 30–60% du ressenti utilisateur se joue sur les assets.

A) Images

• Convertis en formats modernes quand possible.
• Charge en différé hors écran.
• Fixe largeur/hauteur pour éviter les sauts de mise en page.

B) JS/CSS

• Réduis le JS “global”.
• Découpe ce qui n’est utilisé que sur quelques pages.
• Minifie et compresse.

C) Polices

• Limite le nombre de variantes.
• Précharge les polices essentielles.

Si tu gères des pages publiques, les Core Web Vitals sont un bon garde-fou : La checklist ultime des Core Web Vitals (2026).

5) Jobs, exports, emails : la perf « invisible » qui casse la prod

Beaucoup d’applis métier ont des tâches lourdes : génération PDF, exports, synchros, envoi d’emails.

• Isole les tâches longues dans une file.
• Mets des limites (taille d’export, pagination).
• Loggue durée + volume (pour repérer les dérives).

Pour des automatisations, un outil comme n8n aide à orchestrer sans alourdir l’app : Installer n8n avec Docker Compose (HTTPS + persist + queues).

6) Monitoring : ce que tu dois voir avant que tes utilisateurs ne le sentent

Une perf stable, c’est d’abord une perf observable.

À minima :

• latence (p50/p95)
• taux d’erreurs (4xx/5xx)
• CPU/RAM
• saturation DB (connexions, lenteurs)
• I/O disque

Si ton trafic est irrégulier (soldes, campagnes, nouveaux clients), pense à l’élasticité : sur adgents.cloud, tu peux ajuster CPU/RAM rapidement et éviter les “serveurs à l’agonie”.

Lancez-vous avec Bati.

Envie de vous lancer avec Bati ? Créez votre site web en quelques clics.

Bati

La solution pour les constructeurs

Déployer Bati

7) La checklist opérationnelle (ordre de priorité)

1. Mesurer : latence, erreurs, CPU/RAM, DB
2. Couper le swap / corriger la RAM (priorité absolue)
3. Traiter les requêtes lentes + index manquants
4. Stabiliser le pool de connexions DB
5. Mettre en place un cache (HTTP puis app puis données)
6. Optimiser les images et le chargement des assets
7. Mettre au propre les tâches lourdes (exports, PDF, synchros)
8. Mettre des alertes simples (latence p95, erreurs 5xx, DB)

Déployer Bati sans gestion d’infra

Si tu veux te concentrer sur Bati et ton métier, sans passer tes semaines à maintenir l’infrastructure : adgents.cloud permet de déployer Bati rapidement, avec backups automatiques, start/stop et scaling CPU/RAM.