Pourquoi ne pas utiliser des fichiers JSON pour stocker les données d'agents IA ?

Les fichiers JSON n'offrent ni requêtabilité, ni transactions, ni gestion de concurrence. Deux processus qui écrivent simultanément corrompent le fichier. En base de données, les transactions ACID garantissent l'intégrité.

Combien de fichiers avez-vous remplacés en une session ?

23 fichiers JSON supprimés, dont 392 fichiers d'articles. 22 000 lignes de JSON remplacées par 607 lignes structurées dans 9 tables SQL.

Est-ce que la base de données ralentit les agents IA ?

Non. Un SELECT sur une table de 96 lignes prend moins d'une milliseconde — le même temps que lire un fichier JSON de 2 Ko. La différence est invisible, mais la fiabilité est incomparable.

Pourquoi pas Redis ou un cache en mémoire ?

Redis est excellent pour le cache éphémère, mais les données persistantes (backlog, cicatrices, emails) ont besoin de durabilité. MariaDB offre les deux : performance et persistance.

Comment gérer le multi-tenant avec une base de données ?

Chaque client a sa propre base de données sur un VPS isolé. Une clause WHERE suffit pour filtrer. Pas de fichiers dupliqués entre environnements.

Est-ce que Cursor ou Copilot peuvent se connecter à une base de données ?

Non. Ces outils lisent les fichiers du projet. Ils n'ont pas d'accès runtime à Docker, SSH ou MariaDB. C'est la différence fondamentale avec une architecture comme la nôtre.

Comment migrer progressivement sans tout casser ?

On crée la table DB, on migre les données existantes, on met à jour l'API pour lire la DB, puis on supprime le fichier. En gardant un fallback temporaire si nécessaire.

Qu'est-ce qu'une cicatrice d'apprentissage pour un agent IA ?

C'est le registre d'une erreur corrigée : quel agent, quel type d'erreur, quelle correction, quelle root cause. Stockée en base, chaque agent consulte ses cicatrices pour ne jamais refaire la même erreur.

Pourquoi stocker le backlog en base plutôt qu'en fichier mémoire ?

Un fichier mémoire est chargé à chaque interaction, qu'il soit pertinent ou non. Le backlog en base n'est requêté que quand on en a besoin, économisant des tokens de contexte.

Comment garantir la souveraineté des données clients ?

Chaque client possède son VPS, sa base de données, ses modules. Aucune donnée client ne transite par notre infrastructure. C'est le principe du PaaS souverain.

Est-ce que ChatGPT peut faire la même chose avec des plugins ?

Les plugins ChatGPT sont sandboxés. Ils ne peuvent pas exécuter de commandes sur vos serveurs, ni se connecter à votre base de données de production en SSH.

Combien de tables SQL faut-il pour un système multi-agents ?

Dans notre cas, 9 tables couvrent l'essentiel : agents, activité, emails, backlog, cicatrices, automates, expertise, mentors et briefing. Le nombre dépend de votre périmètre fonctionnel.

Comment les automates Python écrivent-ils dans la base ?

Via pymysql, une bibliothèque Python légère. Chaque automate utilise une fonction utilitaire qui fait un INSERT avec gestion de doublons via ON DUPLICATE KEY UPDATE.

Est-ce que la migration casse le site pendant la transition ?

Non. On crée d'abord la table, on migre les données, puis on bascule l'API. Le site continue de fonctionner pendant toute l'opération grâce au zero-downtime deployment via PM2.

Pourquoi PrestaShop comme backend plutôt qu'un framework custom ?

PrestaShop fournit un système de modules avec installation, désinstallation et controllers AJAX intégrés. Chaque fonctionnalité est un module autonome déployable sans rebuild du frontend Nuxt.

strategie

Agents IA et base de données : pourquoi les fichiers ne suffisent plus

En une session, nous avons migré 23 fichiers JSON vers 9 tables SQL. Retour d'expérience concret sur l'architecture DB-first pour agents IA.

Publié le 2 avril 2026 Mis à jour le 2 avril 2026 5 min de lecture Alexandre Carette

Partager LinkedIn Facebook

Nous exploitons un système de 30 agents IA et 96 automates Python en production depuis janvier 2026. Pendant six mois, toutes les données de nos agents — emails clients, backlog, activité, cicatrices d'apprentissage — étaient stockées dans des fichiers JSON et Markdown. Le système fonctionnait. Jusqu'au jour où un agent a servi des données périmées depuis un fichier fallback pendant trois heures sans que personne ne s'en aperçoive. Ce jour-là, nous avons décidé de tout migrer en base de données. En une seule session de travail, nous avons supprimé 23 fichiers JSON, créé 9 tables SQL et 5 modules PrestaShop. 22 000 lignes de fichiers statiques remplacées par 607 lignes structurées en base. Voici pourquoi cette migration change tout pour les architectures multi-agents, et pourquoi aucun outil IA du marché ne propose cette approche.

Le vrai problème des fichiers comme mémoire IA

Problématique	Avec des fichiers	Avec une base de données
Source de vérité	Multiple (core + docker + backup)	Unique
Requêtabilité	Impossible (grep dans du JSON)	SQL natif
Persistance inter-sessions	Rechargement complet	On-demand
Multi-tenant	Un fichier par client, sync manuelle	Une table, clause WHERE
Concurrence d'écriture	Corruption si 2 process écrivent	Transactions ACID
Contexte IA	Chargé à chaque message (tokens gaspillés)	Requêté uniquement quand nécessaire
Audit / traçabilité	git blame sur du JSON	Colonnes date_add, updated_by

Pourquoi les fichiers ne tiennent pas en production

La plupart des outils IA — Cursor, GitHub Copilot, ChatGPT, même Claude Projets — utilisent des fichiers comme contexte. Des .md dans un dossier, des .json dans server/data/, des YAML de configuration. Ça fonctionne pour un prototype. Ça ne tient pas en production.

Trois raisons fondamentales :

Les fichiers dérivent silencieusement. Un fichier modules.json existait en deux copies (source et Docker). Quand nous avons migré les modules en base de données, le fichier Docker n'a pas été mis à jour. Pendant des heures, la preprod servait des données obsolètes via un fallback que personne n'avait vérifié.
Les fichiers polluent le contexte. Notre fichier MEMORY.md faisait 227 lignes et 30 Ko — tronqué à chaque session. Des items « à faire lundi » côtoyaient des règles permanentes. Tout était chargé systématiquement, qu'il soit pertinent ou non. Après migration du backlog en base (ps_ac_backlog), le fichier est tombé à 120 lignes. Les TODO sont requêtés uniquement quand c'est nécessaire.
Les fichiers ne sont pas requêtables. « Quels emails clients sont non traités ? » Avec un JSON, il faut charger le fichier, parser, filtrer. Avec la base : SELECT * FROM ps_ac_inbox_emails WHERE status = 'new'. Une ligne contre quinze.

Ce que nous avons migré en une session

Neuf tables créées, chacune remplaçant un ou plusieurs fichiers JSON :

ps_ac_inbox_emails — emails clients avec statuts (new, seen, resolved)
ps_ac_daily_meet — briefing de session (49 items migrés)
ps_ac_agent_activity + ps_ac_agent_heartbeat — activité temps réel des agents
ps_ac_expertise — 194 articles techniques (12 000 lignes de JSON supprimées)
ps_ac_academy_mentor — 15 mentors historiques de l'Academy
ps_ac_automates — 96 automates Python classifiés en 6 castes
ps_ac_backlog — roadmap et TODO (remplace 13 fichiers mémoire)
ps_ac_cicatrices — registre des erreurs corrigées par agent

Pourquoi aucun outil IA ne fait ça

Les outils IA actuels (Cursor, Windsurf, Copilot, Devin) lisent le code. Ils ne se connectent pas à votre base de données de production. Ils ne font pas de docker exec sur vos containers. Ils ne scannent pas vos VPS en SSH pour inventorier les modules installés.

Notre architecture — Claude Code avec accès direct à MariaDB, Docker et SSH sur 7 VPS — permet à l'agent de requêter ses propres données au lieu de les charger en contexte. La différence est fondamentale : un SELECT ciblé consomme zéro token de contexte. Un fichier .md chargé à chaque message en consomme des milliers, qu'il soit utile ou non.

Les résultats concrets

Donnée	Avant (fichier)	Après (DB)	Gain
Emails clients	inbox-alerts.json (8 Ko, 100 max)	ps_ac_inbox_emails	Historique illimité + statuts
Briefing session	daily-meet.json (65 Ko)	ps_ac_daily_meet	Requêtable par sévérité
Activité agents	agent-activity.json (146 Ko)	2 tables (heartbeat + activity)	Temps réel, pas de cap
Articles expertise	392 fichiers JSON (22 000 lignes)	ps_ac_expertise (194 rows)	-99% de fichiers
Modules installés	JSON + hardcodé	ps_ac_moduleslist	MAJ sans rebuild
Backlog/TODO	13 fichiers .md en mémoire	ps_ac_backlog	Requêté on-demand
Registre VPS	clients.json (readFileSync)	ps_ac_client_vps	La Flotte, scan SSH auto

L'approche « database as source of truth » pour les systèmes multi-agents est documentée par les équipes de recherche d'Anthropic dans leurs recommandations d'architecture pour les agents persistants. Le principe ACID (Atomicité, Cohérence, Isolation, Durabilité) des bases relationnelles garantit une intégrité que les fichiers ne peuvent offrir — un fondement que la documentation officielle des systèmes agentiques souligne comme critique pour les déploiements en production.

Conclusion

La migration fichiers vers base de données n'est pas une optimisation technique. C'est un changement d'architecture qui transforme vos agents IA de scripts stateless en systèmes persistants capables d'apprendre, de se souvenir et de se coordonner.

Chez CodeMyShop, chaque client dispose de sa propre base de données sur un VPS souverain. Ses agents, ses données, ses cicatrices d'apprentissage — tout lui appartient. Pas de fichiers partagés qui dérivent. Pas de JSON fantôme qui sert des données périmées. Une seule source de vérité.

Vous exploitez des agents IA en production et vos données sont encore dans des fichiers ? Prenez 30 minutes pour en discuter — on vous montre comment structurer ça proprement.

Sources

Documentation Anthropic — Building Agentic Systems (2025)
Martin Fowler — Patterns of Enterprise Application Architecture, « Single Source of Truth »
Session de migration réelle — Alexandre Carette, 2 avril 2026 (23 JSON → 9 tables, 607 rows)

Articles dans le même univers

Questions fréquentes

Tout ce que vous devez savoir sur ce sujet.

: Les fichiers JSON n'offrent ni requêtabilité, ni transactions, ni gestion de concurrence. Deux processus qui écrivent simultanément corrompent le fichier. En base de données, les transactions ACID garantissent l'intégrité.
: 23 fichiers JSON supprimés, dont 392 fichiers d'articles. 22 000 lignes de JSON remplacées par 607 lignes structurées dans 9 tables SQL.
: Non. Un SELECT sur une table de 96 lignes prend moins d'une milliseconde — le même temps que lire un fichier JSON de 2 Ko. La différence est invisible, mais la fiabilité est incomparable.
: Redis est excellent pour le cache éphémère, mais les données persistantes (backlog, cicatrices, emails) ont besoin de durabilité. MariaDB offre les deux : performance et persistance.
: Chaque client a sa propre base de données sur un VPS isolé. Une clause WHERE suffit pour filtrer. Pas de fichiers dupliqués entre environnements.
: Non. Ces outils lisent les fichiers du projet. Ils n'ont pas d'accès runtime à Docker, SSH ou MariaDB. C'est la différence fondamentale avec une architecture comme la nôtre.
: On crée la table DB, on migre les données existantes, on met à jour l'API pour lire la DB, puis on supprime le fichier. En gardant un fallback temporaire si nécessaire.
: C'est le registre d'une erreur corrigée : quel agent, quel type d'erreur, quelle correction, quelle root cause. Stockée en base, chaque agent consulte ses cicatrices pour ne jamais refaire la même erreur.
: Un fichier mémoire est chargé à chaque interaction, qu'il soit pertinent ou non. Le backlog en base n'est requêté que quand on en a besoin, économisant des tokens de contexte.
: Chaque client possède son VPS, sa base de données, ses modules. Aucune donnée client ne transite par notre infrastructure. C'est le principe du PaaS souverain.
: Les plugins ChatGPT sont sandboxés. Ils ne peuvent pas exécuter de commandes sur vos serveurs, ni se connecter à votre base de données de production en SSH.
: Dans notre cas, 9 tables couvrent l'essentiel : agents, activité, emails, backlog, cicatrices, automates, expertise, mentors et briefing. Le nombre dépend de votre périmètre fonctionnel.
: Via pymysql, une bibliothèque Python légère. Chaque automate utilise une fonction utilitaire qui fait un INSERT avec gestion de doublons via ON DUPLICATE KEY UPDATE.
: Non. On crée d'abord la table, on migre les données, puis on bascule l'API. Le site continue de fonctionner pendant toute l'opération grâce au zero-downtime deployment via PM2.
: PrestaShop fournit un système de modules avec installation, désinstallation et controllers AJAX intégrés. Chaque fonctionnalité est un module autonome déployable sans rebuild du frontend Nuxt.

Un projet PrestaShop ?

Discutons-en directement.

★★★★★

193 projets livrés

Alexandre Carette

Expert PrestaShop & Architecture E-commerce

Développeur PrestaShop freelance avec 10 ans d'expérience et 193 projets livrés. Je conçois des architectures headless Nuxt + PrestaShop, des pipelines DevOps Docker/CI-CD et des outils d'automatisation IA pour mes clients e-commerce.

contact@alexandrecarette.fr ← Tous les articles

Discussion

Cluster Sémantique

Voir tous les articles

strategie

Ouroboros destructeur vs informationnel : éviter le model collapse IA

Le model collapse menace toute IA qui se nourrit de son propre contenu. L'Ouroboros informationnel transforme cette boucle en spirale ascendante. Comparaison technique, garde-fous, architecture.