Refonte d'une base analytique temps réel

Écrivez en majuscules à un agent IA « Ne modifie JAMAIS la base de données », et il essaiera quand même. Les miens l’ont fait à plusieurs reprises, en pleine refonte d’une base analytique. Voici ce chantier : ce que les agents m’ont apporté, ce qu’ils ont tenté, le cadre qui m’a permis de leur confier une base sans jamais leur en donner les clés, et ce que la refonte a révélé.

Le point de départ : une base qui avait grandi par couches

Le projet est un indexeur blockchain : il ingère en continu l’activité des échanges décentralisés, un bloc par seconde, et alimente une API d’analyse. Les données vivent dans ClickHouse, une base taillée pour l’analytique.

L’architecture avait grandi au rythme des besoins. Chaque famille de pools d’échange avait ses propres tables, les métadonnées étaient recollées par jointure à chaque calcul, et l’ensemble comptait plus de 117 vues matérialisées.

Mais une migration vers une autre blockchain se profilait, avec des volumes environ 100 fois supérieurs : sur 28 mois de rétention, 2,25 milliards de swaps et 11 milliards de transferts de tokens, soit 3,6 To pour cette seule table avant compression.

Le cahier des charges tenait en trois lignes :

• Accélérer : chaque requête de l’API sous 200 ms.
• Ne rien changer en sortie : la nouvelle API doit renvoyer exactement la même chose que l’ancienne.
• Simplifier : refondre le schéma de la base et tout l’enchaînement des vues.

Les agents comme assistants d’analyse

Avant de réécrire quoi que ce soit, il fallait comprendre l’existant. J’ai confié cette enquête à plusieurs agents IA créés pour l’occasion, avec un accès en lecture seule à l’environnement de préproduction, bloqué au niveau de la clé d’accès.

Ils m’ont aidé à dresser l’inventaire : chaque table, chaque vue, chaque dépendance, jusqu’à une cartographie qui relie chaque vue aux requêtes de l’API qu’elle sert. Puis tout a été mesuré, avec une règle simple : profiler avant d’expliquer.

Les mesures ont vite contredit l’intuition. Une table de 18,3 Go répondait en 21 ms, quand une autre de 1,4 Go mettait 139 ms. La plus grosse était six fois plus rapide, simplement parce que ses données étaient triées selon la question qu’on lui pose. Toute la conception est partie de là.

L’incident

Au fil d’un diagnostic, un agent tentait parfois de créer, supprimer ou modifier un objet de la base, malgré les règles inscrites dans ses consignes. Un agent qui veut résoudre un problème prend le chemin le plus court, et ce chemin passe parfois par une action interdite.

Chaque tentative a été bloquée, et j’ai reçu une alerte : l’interdiction était technique, pas seulement écrite.

Le cadre : des garde-fous indépendants

• Les clés : le serveur a une clé en lecture et une en lecture-écriture. Les agents ne connaissent que la première.
• Le passage obligé : les agents n’accèdent à la base qu’au travers d’un intermédiaire qui refuse tout ordre d’écriture et m’alerte.
• Le bac à sable : une base locale jetable, reconstruite en une commande, où l’agent a tous les droits, avec une batterie de tests hors de sa portée.
• Pas de raccourci vers le vert : en test, une erreur arrête tout et remonte telle quelle ; l’agent ne peut pas retoucher le code pour faire passer les tests.
• « Terminé » se vérifie en réel : un script déterministe compare l’ancienne et la nouvelle API, champ par champ.

La reconstruction

Les premières optimisations, requête par requête, ont apporté de 10 à 75 % de gain. Mais sans toucher au schéma, on ne faisait que réécrire proprement des requêtes : il fallait reprendre la donnée à la source, en tandem avec l’équipe qui reprenait le code de l’indexeur.

• Une table par nature d’événement : les swaps de toutes les familles de pools tiennent désormais dans une seule table.
• Les métadonnées écrites dès l’ingestion : plus aucune jointure à faire dans les vues.
• Des types au plus juste : sur l’état des pools, le stockage a été divisé par deux.
• Une source au lieu de trois pour les graphiques de prix, et une table fourre-tout supprimée avec 66 % de lignes en moins.

Au total : 9 domaines, 65 vues matérialisées et 40 tables, chacune documentée et reconstructible de zéro.

Ce que la refonte a donné

Une base plus fiable. La comparaison systématique entre ancienne et nouvelle sortie a révélé des erreurs invisibles : des statistiques qui ignoraient dans certains cas 38 à 65 % des données de la période, et des agrégats gonflés d’environ 50 %.

Une base plus rapide :

• Statistiques d’un token : de 2 977 ms à 117 ms, 25 fois plus rapide.
• Pools actifs : de 249 ms à 2 à 5 ms grâce à une table dédiée.
• Graphique de prix : 75 % de temps en moins, stable autour de 70 ms.
• Fiche token : de 800 à 170 ms.
• Détenteurs d’un token : de 638 à 180 ms.

Les arbitrages

Une table dédiée faisait passer une requête de 21 à 10 ms : deux fois plus rapide, mais pas assez pour justifier le stockage et la maintenance supplémentaires. Pour les statistiques sur 24 heures, des tranches de 15 minutes plutôt que d’une minute lisaient 83 % de lignes en moins. La règle retenue avec l’équipe produit : une tranche jamais plus grande qu’un vingtième de la période, soit 5 % d’écart au maximum.

Ce que j’en retiens

En analytique, c’est la question qui décide de l’ordre des données. Et un agent IA ne respecte pas toujours une consigne : sa rigueur vient de l’architecture que l’on construit autour.