Les temps de réponse de l'application passent de deux cents millisecondes à huit secondes. Pas d'erreur, pas de page blanche, juste huit secondes. Le serveur applicatif va bien, le réseau va bien. La base, elle, tourne à quatre-vingt-quinze pour cent de processeur depuis vingt minutes.
Dans la liste des requêtes actives, la même revient en boucle : une agrégation sur la table des commandes, onze millions de lignes, sans filtre de date, avec trois jointures. Elle ne vient d'aucune application connue. Elle vient de Metabase, installé trois semaines plus tôt, où quelqu'un du service commercial a construit un graphique « chiffre d'affaires par région », l'a posé sur un tableau de bord affiché en salle de réunion, et a réglé le rafraîchissement automatique sur cinq minutes.
Personne n'a mal agi. L'outil a fait exactement ce qu'on lui a demandé.
Pourquoi c'était écrit d'avance
Un outil décisionnel renverse la logique habituelle. Une application de gestion émet des requêtes écrites par des développeurs, revues, testées, dont le plan d'exécution est connu. Un outil décisionnel émet des requêtes composées à la souris par des gens dont ce n'est pas le métier, et c'est précisément sa valeur : il rend l'accès aux données autonome.
Le corollaire est qu'il produira, tôt ou tard, une requête catastrophique. Ce n'est pas un risque, c'est une certitude statistique. Les garde-fous se posent donc avant, pas après l'incident.
Trois protections suffisent, et aucune n'est dans l'outil lui-même.
La seule réponse qui tient : ne pas toucher à la production
Un outil décisionnel n'a rien à faire sur la base de production. Il se branche sur un réplica en lecture seule, alimenté par la réplication native du moteur.
Le décalage est de quelques secondes, ce qui est sans importance pour un tableau de bord : personne ne pilote une entreprise à la seconde près. En échange, une requête qui part en vrille sature une machine dont la chute ne fait tomber que les graphiques. La différence entre une réunion contrariée et une journée d'arrêt tient dans cette seule décision d'architecture.
La mise en place relève de la réplication classique, physique pour un miroir complet, ou logique quand on veut ne répliquer qu'un sous-ensemble des tables. Le réplica peut vivre sur une machine plus modeste, et il peut porter des index que la production n'a pas, taillés pour les agrégations plutôt que pour les écritures. C'est même son principal intérêt.
Le délai maximal, ce réglage de trois minutes
Sur le réplica, le second garde-fou est un plafond de durée par requête, posé au niveau du moteur de base pour l'utilisateur dédié à l'outil.
CREATE ROLE metabase LOGIN PASSWORD '...';
ALTER ROLE metabase SET statement_timeout = '60s';
GRANT CONNECT ON DATABASE prod_replica TO metabase;
GRANT USAGE ON SCHEMA public TO metabase;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO metabase;
Une requête qui dépasse soixante secondes est tuée. L'utilisateur voit un message d'erreur et vient demander de l'aide, ce qui est exactement le comportement souhaitable : on corrige la question plutôt que de découvrir le problème sur un graphique de supervision.
Le troisième garde-fou est un plafond de connexions simultanées, pour que dix personnes qui ouvrent le même tableau de bord n'ouvrent pas dix connexions lourdes. Un répartiteur de connexions devant le réplica fait ce travail proprement.
Ce que l'outil voit, il le montre
Voilà le sujet qui fâche, et il se traite au premier jour.
Metabase affiche ce que son utilisateur de base peut lire. Si ce compte a accès à toutes les tables, alors n'importe qui disposant d'un accès à l'outil peut construire une question sur la table des salaires, même sans savoir écrire une ligne de SQL : l'interface graphique lui propose la table dans une liste.
Deux niveaux doivent être posés, et l'un ne remplace pas l'autre. En bas, les droits du compte technique dans la base, qui définissent le maximum absolu : on n'accorde la lecture que sur les schémas et les tables qui ont vocation à être explorés. En haut, les permissions par groupe dans l'outil, qui découpent ce périmètre par métier.
Le rattachement des utilisateurs à un annuaire existant, par authentification unique, évite le comptoir de comptes locaux qui survivent aux départs. C'est aussi ce qui permet de retirer un accès en une fois plutôt qu'en sept.
Le cache, et la question qu'il faut se poser avant
Un tableau de bord consulté par quarante personnes n'a aucune raison de recalculer quarante fois la même agrégation. Le cache se règle par durée ou en fonction du temps d'exécution de la requête, et il supprime l'essentiel de la charge inutile.
Mais avant de régler le cache, il faut poser la question que personne ne pose : à quelle fréquence cette donnée change-t-elle réellement, et à quelle fréquence quelqu'un agit-il dessus ? Un chiffre d'affaires mensuel rafraîchi toutes les cinq minutes n'apporte rien à personne. Un indicateur de production consulté une fois par jour non plus. Le rafraîchissement automatique sur écran mural est le pire des cas : il tourne la nuit, le week-end, et pendant les vacances, pour personne.
Dans l'incident raconté plus haut, passer le rafraîchissement de cinq minutes à une heure aurait suffi à ce que rien ne se produise jamais.
La partie qu'on saute toujours
Metabase laisse décrire le sens des données : renommer les colonnes en français, masquer les colonnes techniques, marquer les clés étrangères, déclarer les formats monétaires, définir des métriques réutilisables.
Ce travail prend deux jours et décide de l'adoption. Sans lui, l'utilisateur métier ouvre une liste de tables aux noms cryptiques, tombe sur trois colonnes qui ressemblent à un montant, choisit la mauvaise, et publie un chiffre faux. Il ne reviendra pas, et l'outil sera jugé mauvais alors que c'est la description qui manquait.
Une règle simple aide : tout ce qui n'est pas destiné aux métiers doit être masqué. Un utilisateur qui ne voit que douze tables bien nommées se débrouille seul. Un utilisateur qui en voit deux cent quarante appelle l'informatique, ou pire, ne l'appelle pas.
La licence, avant de la proposer à un client
Metabase est en double licence. Tout ce qui se trouve hors du répertoire enterprise est sous AGPL ; le contenu de ce répertoire relève d'une licence commerciale. Les images distribuées diffèrent en conséquence : l'image standard est sous AGPL, l'image enterprise sous licence commerciale.
L'AGPL a une conséquence précise qu'il faut connaître avant de s'engager : quiconque met à disposition une version modifiée du logiciel via un réseau doit fournir le code source correspondant aux utilisateurs de ce service. Installer l'image officielle sans y toucher ne déclenche rien. Modifier le code et l'exposer à des utilisateurs, si. Pour un intégrateur, la règle pratique est simple : on déploie l'image telle quelle, on ne patche pas, et si un besoin impose de modifier le code, on traite la question de la mise à disposition des sources au lieu de l'ignorer.
La version en cours au 21 septembre 2026 est la 0.63.18, publiée le 16 septembre. Le rythme est soutenu et les montées sont généralement sans histoire, à condition de sauvegarder la base applicative de l'outil avant, puisqu'elle porte les questions, les tableaux de bord et les permissions.
Ce qu'il reste à tenir
Une fois l'outil en place, trois choses demandent une attention régulière. La base applicative de Metabase, qui contient tout le travail des utilisateurs et qui se sauvegarde comme n'importe quelle base métier. Le retard du réplica, à superviser : un réplica qui décroche affiche des chiffres faux sans le dire. Et le ménage annuel dans les questions abandonnées, parce qu'un outil décisionnel accumule les tableaux de bord morts à la vitesse où une entreprise change d'avis.
Le réplica, le plafond de soixante secondes et le compte en lecture seule ont été posés dans la semaine qui a suivi l'incident. Le graphique du service commercial tourne toujours, sur le réplica, et plus personne ne le voit passer.
Sources
- Licence de Metabase, double licence AGPL et licence commerciale pour le répertoire enterprise, distinction entre les images distribuées
- Dépôt GitHub metabase/metabase, version 0.63.18 publiée le 16 septembre 2026, 49 353 étoiles
- Documentation PostgreSQL, statement_timeout, plafond de durée par requête au niveau du rôle
- Documentation Metabase, permissions, modèle de groupes et de périmètres d'accès
