Pourquoi les fichiers JSON ne suffisent plus pour les données d'agents IA en production ?

Les fichiers JSON sont pratiques au démarrage, mais en production multi-agents, ils créent des fenêtres de stale data : quand deux agents lisent le même fichier simultanément ou modifient sans coordonnée, vous n'avez aucune garantie de cohérence. Après 6 mois et 96 automates, une donnée périmée peut circuler 3 heures sans alerte.

Qu'est-ce qu'une donnée stale en système multi-agent ?

Une donnée stale est une information obsolète qu'un agent sert parce qu'il a lu un fichier avant sa dernière mise à jour, ou parce que le fallback JSON n'a pas été synchronisé après un changement. C'est invisible : l'agent ne sait pas qu'il est dépassé et l'utilisateur ne voit aucun warning.

Quel est le risque principal d'une base de données manquante pour 30 agents en production ?

Sans source unique, chaque agent a sa propre vérité : ticket backlog dans un fichier JSON, status dans un autre, raison d'une décision dans un Markdown. Quand une anomalie passe entre deux agents, personne ne peut tracer qui a fait quoi et quand. Les investigations post-incident deviennent impossibles.

Combien de fichiers une équipe doit fusionner en base de données au minimum ?

Dès que trois ou plus fichiers se chevauchent (agent A relit ce que agent B a écrit), migrer vers la DB. Notre point de basculement a été 23 fichiers JSON simultanés avec des écritures concurrentes. Un automate qui attend dix fichiers locaux à la fois = signal d'alarme.

Quel type de base de données convient pour des agents IA en production ?

MariaDB ou PostgreSQL : vous avez besoin de transactions ACID (pas juste du stockage). Évitez MongoDB ou DynamoDB si vous avez des joins fréquents (agents qui fusionnent des données de 3+ sources). La cohérence transactionnelle vaut mieux que la scalabilité horizontale jusqu'à 1M lignes.

Peut-on garder des fichiers JSON en parallèle comme fallback ?

Techniquement oui, mais c'est une dette qui s'accumule. Le fallback JSON devient un piège : les agents apprennent à s'en servir quand la DB est lente, et la DB se désynchronise. La règle simple : une donnée, un seul chemin d'accès. Pas de fallback JSON.

Comment éviter les goulots d'étranglement quand 96 automates interrogent la même table ?

Index bien pensés (par date, client, status). Les requêtes sur une table de 50 000 lignes prennent 1ms si la clé est indexée. Évitez les requêtes full-table en boucle : par lot (batch SELECT) plutôt que ligne par ligne. Un `WHERE status='pending' LIMIT 100` avec index vaut mieux que 100 requêtes individuelles.

Quel impact sur la performance quand on migre 23 fichiers vers la DB ?

Si structuré correctement, la DB est plus rapide : SELECT sur une table indexée est 10x plus vite qu'un parse JSON sur disque. Les gains de latence dépassent le coût réseau Docker (1-2ms). Le vrai coût : les transactions qui maintiennent la cohérence, nécessaire mais acceptable.

Peut-on auditer qui a modifié quoi dans un système fichiers par rapport à la DB ?

Presque impossible en fichiers : quand 10 agents écrivent dans le même JSON, aucune trace de qui a changé quoi et quand. Une table avec `created_at`, `updated_at`, `created_by`, `updated_by` offre un audit complet. Après incident, vous pouvez retracer les 3 heures d'anomalie en 2 minutes.

Comment gérer les transactions dans un système 30 agents si l'un crash au milieu d'une écriture ?

Les fichiers JSON laissent votre donnée corrompue. Les transactions DB roulent tout en arrière (ROLLBACK) si quelque chose échoue. BEGIN → 5 INSERTs → COMMIT : soit tous passent, soit aucun. Zéro état intermédiaire cassé. Les agents peuvent donc relancer une transaction échouée sans risque.

Faut-il une base de données pour chaque client en mode multi-tenant ?

Oui, si vous visez la souveraineté (chaque client possède ses données). Une DB centralisée multilocataire avec `client_id` = perte de contrôle client + risque de fuite. Un VPS par client avec sa propre DB = chaque client blindé, pas d'exposition à un autre.

Combien de tables SQL minimal pour 30 agents + 96 automates ?

Au minimum 9 : agents, automates, backlog, décisions, emails, sessions, logs, cicatrices, artefacts. Chaque table sert 1-2 entités métier. Notre migration était 23 fichiers JSON → 9 tables, ce qui veut dire qu'on a aussi consolidé (certains fichiers doublonnaient les infos).

Peut-on migrer les données sans downtime pour les agents ?

Oui en deux phases : (1) créer les tables en parallèle, laisser les agents lire JSON, (2) batch copier les données JSON en tables, vérifier l'intégrité, puis basculer les agents en lecture DB. Si un agent plante entre deux, il redécouvre la DB intact. Zéro downtime si vous avez une migration script solide.

Comment synchroniser 96 automates avec une seule base de données après un changement de configuration ?

Au lieu que chaque automate relise un fichier config, un seul lit la DB et publie le changement (via webhook, Redis pub/sub ou polling de status). Les 95 autres automates continuent, se mettent à jour au tick suivant. La DB devient votre système nerveux central.

Quel est le coût d'une base de données pour une PME qui utilise 30 agents IA ?

MariaDB managé (OVH, AWS) coûte ~10-30€/mois pour 50 GB de stockage agent + log. Les fichiers semblent gratuits mais la complexité opérationnelle (script de sync, incidents de cohérence) coûte plus cher en temps. À partir de 1 000€/mois d'opérations, la DB paye ses frais.

Comment savoir si mon système fichiers est sur le point de s'effondrer ?

Trois signaux : (1) deux automates écrivent dans le même JSON, (2) vous avez besoin d'un fallback JSON parce que quelque chose s'est désynchronisé, (3) déboguer un incident prend plus d'une heure parce que vous ne savez pas quel fichier est la source de vérité. À ce stade, la migration est inévitable.

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.

5 min de lecture

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 sont pratiques au démarrage, mais en production multi-agents, ils créent des fenêtres de stale data : quand deux agents lisent le même fichier simultanément ou modifient sans coordonnée, vous n'avez aucune garantie de cohérence. Après 6 mois et 96 automates, une donnée périmée peut circuler 3 heures sans alerte.
: Une donnée stale est une information obsolète qu'un agent sert parce qu'il a lu un fichier avant sa dernière mise à jour, ou parce que le fallback JSON n'a pas été synchronisé après un changement. C'est invisible : l'agent ne sait pas qu'il est dépassé et l'utilisateur ne voit aucun warning.
: Sans source unique, chaque agent a sa propre vérité : ticket backlog dans un fichier JSON, status dans un autre, raison d'une décision dans un Markdown. Quand une anomalie passe entre deux agents, personne ne peut tracer qui a fait quoi et quand. Les investigations post-incident deviennent impossibles.
: Dès que trois ou plus fichiers se chevauchent (agent A relit ce que agent B a écrit), migrer vers la DB. Notre point de basculement a été 23 fichiers JSON simultanés avec des écritures concurrentes. Un automate qui attend dix fichiers locaux à la fois = signal d'alarme.
: MariaDB ou PostgreSQL : vous avez besoin de transactions ACID (pas juste du stockage). Évitez MongoDB ou DynamoDB si vous avez des joins fréquents (agents qui fusionnent des données de 3+ sources). La cohérence transactionnelle vaut mieux que la scalabilité horizontale jusqu'à 1M lignes.
: Techniquement oui, mais c'est une dette qui s'accumule. Le fallback JSON devient un piège : les agents apprennent à s'en servir quand la DB est lente, et la DB se désynchronise. La règle simple : une donnée, un seul chemin d'accès. Pas de fallback JSON.
: Index bien pensés (par date, client, status). Les requêtes sur une table de 50 000 lignes prennent 1ms si la clé est indexée. Évitez les requêtes full-table en boucle : par lot (batch SELECT) plutôt que ligne par ligne. Un `WHERE status='pending' LIMIT 100` avec index vaut mieux que 100 requêtes individuelles.
: Si structuré correctement, la DB est plus rapide : SELECT sur une table indexée est 10x plus vite qu'un parse JSON sur disque. Les gains de latence dépassent le coût réseau Docker (1-2ms). Le vrai coût : les transactions qui maintiennent la cohérence, nécessaire mais acceptable.
: Presque impossible en fichiers : quand 10 agents écrivent dans le même JSON, aucune trace de qui a changé quoi et quand. Une table avec `created_at`, `updated_at`, `created_by`, `updated_by` offre un audit complet. Après incident, vous pouvez retracer les 3 heures d'anomalie en 2 minutes.
: Les fichiers JSON laissent votre donnée corrompue. Les transactions DB roulent tout en arrière (ROLLBACK) si quelque chose échoue. BEGIN → 5 INSERTs → COMMIT : soit tous passent, soit aucun. Zéro état intermédiaire cassé. Les agents peuvent donc relancer une transaction échouée sans risque.
: Oui, si vous visez la souveraineté (chaque client possède ses données). Une DB centralisée multilocataire avec `client_id` = perte de contrôle client + risque de fuite. Un VPS par client avec sa propre DB = chaque client blindé, pas d'exposition à un autre.
: Au minimum 9 : agents, automates, backlog, décisions, emails, sessions, logs, cicatrices, artefacts. Chaque table sert 1-2 entités métier. Notre migration était 23 fichiers JSON → 9 tables, ce qui veut dire qu'on a aussi consolidé (certains fichiers doublonnaient les infos).
: Oui en deux phases : (1) créer les tables en parallèle, laisser les agents lire JSON, (2) batch copier les données JSON en tables, vérifier l'intégrité, puis basculer les agents en lecture DB. Si un agent plante entre deux, il redécouvre la DB intact. Zéro downtime si vous avez une migration script solide.
: Au lieu que chaque automate relise un fichier config, un seul lit la DB et publie le changement (via webhook, Redis pub/sub ou polling de status). Les 95 autres automates continuent, se mettent à jour au tick suivant. La DB devient votre système nerveux central.
: MariaDB managé (OVH, AWS) coûte ~10-30€/mois pour 50 GB de stockage agent + log. Les fichiers semblent gratuits mais la complexité opérationnelle (script de sync, incidents de cohérence) coûte plus cher en temps. À partir de 1 000€/mois d'opérations, la DB paye ses frais.
: Trois signaux : (1) deux automates écrivent dans le même JSON, (2) vous avez besoin d'un fallback JSON parce que quelque chose s'est désynchronisé, (3) déboguer un incident prend plus d'une heure parce que vous ne savez pas quel fichier est la source de vérité. À ce stade, la migration est inévitable.