Bases de données et IA — vos pipelines de logs sont vides

Un manifeste récent affirme que nos bases de données ne sont pas prêtes pour les agents IA. La thèse fait son chemin sur LinkedIn, recueille des partages, des commentaires admiratifs. Et elle a raison sur un point — un seul. Mais sa solution est fausse, et je vais le démontrer en cinq sources et neuf commits. Pas avec un slide deck. Avec des INSERT et des git log.

Ce matin, j'ai poussé neuf décisions d'agents IA dans une nouvelle table ps_ac_decisions sur une stack PrestaShop + MariaDB standard. Chaque décision contient le qui, le quoi, le pourquoi, les preuves, la validation et le résultat. Mon orchestrateur peut désormais répondre à la question « qu'est-ce qui s'est passé sur l'item 121 ce matin ? » en agrégeant cinq sources hétérogènes en une seule commande Python. Aucun nouveau type de SGBD. Aucune « reasoning database ». Juste de la discipline d'écriture sur ce que vous avez déjà.

Cet article fait partie de notre dossier stratégie › intelligence-artificielle.

Les problématiques courantes du raisonnement absent en base

Cet article fait partie de notre dossier Stratégie › intelligence-artificielle.

Problématique	Cause principale	Impact métier
Agent IA produit des recommandations génériques	La base stocke des conclusions sans la causalité qui y a mené	Agent hallucine des plans d'action plausibles mais creux, perte de confiance utilisateur
Impossible de répondre à « pourquoi cette valeur ? »	Pas de provenance, pas d'historique de décision dans la donnée	L'humain doit refaire l'enquête manuellement à chaque fois
Apprentissage cumulatif inexistant	Aucune trace des erreurs passées et de leur résolution	Le système répète les mêmes erreurs, dette technique invisible qui s'accumule
Audits de conformité impossibles	Aucun lien entre une mutation de donnée et la décision qui l'a causée	RGPD, AI Act, ISO 27001 deviennent des cases à cocher au lieu de vraies preuves

Ce que le manifeste a raison de pointer

Soyons honnêtes : il y a un vrai problème. Une table relationnelle classique stocke des conclusions (score = 87) sans documenter le raisonnement qui y a mené, sans la provenance, sans l'historique décisionnel. Quand un agent IA lit cette ligne, il sait quoi, mais pas pourquoi, ni quand ça a changé, ni qui l'a décidé. Conséquence directe : l'agent hallucine des recommandations plausibles mais creuses, parce qu'il extrapole des patterns sans accéder à la causalité.

Sur une boutique e-commerce ou un CRM, cette limite produit des situations absurdes. L'agent IA voit qu'une campagne SEA a un coût par clic à 12 €, mais ne peut pas remonter au choix de mots-clés trop larges qui en est la cause — parce que le choix n'a jamais été écrit nulle part. La conversation s'arrête à « le CPC est élevé, baissez l'enchère », conseil générique qui peut aggraver le problème au lieu de le résoudre.

Cette limite est réelle. Mais elle n'est pas un problème de SGBD.

Le piège du « nouveau type de base de données »

La tentation, quand on découvre cette limite, c'est de chercher une nouvelle techno qui la résoudrait nativement. « Il nous faut une reasoning database. » Le terme est marketable, il sonne comme une rupture. Sauf que les briques techniques qu'il sous-entend existent depuis dix à quinze ans, et qu'elles sont déjà dans votre stack ou à un CREATE TABLE près.

• JSONB Postgres (disponible depuis 2014) : stockage de provenance, preuves, métadonnées arbitraires sans schéma rigide
• Datomic (2012) : base immutable, temporelle, fact-based — sait répondre à « et avant ? » par construction
• Event sourcing + CQRS (≈2010, architecturalement éprouvé) : toute mutation devient un événement gardé pour toujours
• Knowledge graphs (Neo4j, RDF, depuis 2007) : représentation explicite des relations causales

Et le Model Context Protocol (MCP) d'Anthropic, souvent cité dans le débat, n'est pas une « reasoning database ». C'est un protocole de transport — il standardise la façon dont un agent accède à des ressources externes. Confondre les deux relève d'une lecture trop rapide. MCP transporte la donnée vers l'agent, il ne la pense pas pour vous.

La vraie cause de l'inadaptation, ce n'est donc pas la technologie. C'est l'absence d'une discipline d'écriture qui transforme chaque mutation en trace causale. Vous pouvez ajouter cette discipline à PostgreSQL, à MariaDB, à SQLite. Vous pouvez la rater sur Datomic. C'est une question d'éthique d'ingénieur, pas d'architecture.

La preuve par cinq sources

Pour défendre ce point, je vais m'appuyer sur ma propre stack — PrestaShop 8 headless + MariaDB + Nuxt 3 + une trentaine d'automates Python orchestrés par des agents IA. Rien d'exotique. Rien que vous ne puissiez reproduire en quelques heures sur une stack équivalente.

Ce matin, mon agent orchestrateur a clos huit items de dette technique en parallèle. Ces opérations ont été tracées dans cinq silos distincts, qui sont les cinq dimensions d'une véritable mémoire causale.

Source 1 — L'état courant

C'est la seule dimension que la majorité des stacks possèdent. Le tableau ps_ac_backlog contient un item, son statut, ses notes timestampées qui décrivent ce qui a été fait. Lecture brute. Aucune causalité. C'est le minimum vital. Indispensable, insuffisant.

Source 2 — Les décisions explicites

C'est la table que j'ai créée ce matin, en réaction directe au manifeste cité plus haut. Schéma minimal, du MariaDB 10 standard :

Une décision contient l'agent qui a recommandé l'action, l'action elle-même, le sujet sur lequel elle porte, la raison (au moins 30 caractères, pour interdire les raisons creuses), les preuves (références à d'autres tables, commits, requêtes), un statut de validation, qui a validé, le résultat constaté, et trois clés de pont : un commit Git lié, un item de backlog lié, une cicatrice liée.

Aucune extension. Aucun connecteur exotique. Ce qui rend cette table utile, ce ne sont pas ses colonnes — c'est le contrat d'écriture imposé à tous les agents qui mutent les autres tables. Chaque opération significative doit créer une décision avant la mutation, ou immédiatement après dans la même transaction logique. Sinon, l'opération est considérée comme une dette de log à colmater.

J'ai gravé neuf décisions ce matin. La règle de validation impose une raison de 30 caractères minimum, un sujet non vide, et exige un validateur pour les statuts approuvés ou rejetés. Une cinquantaine de lignes de Python suffisent à enforcer cette discipline via une couche Active Record.

Source 3 — Les commits Git

Vos commits Git sont déjà une reasoning database. Si vous n'aviez gardé qu'une seule chose, ce serait celle-là. Chaque commit a un auteur, une date, un message, un hash, et un pont vers le code modifié. C'est immuable, c'est requêtable, c'est gratuit. Une commande git log --grep suffit à retrouver l'historique d'une décision technique.

La condition pour que ça fonctionne : discipline de message. Mentionner le numéro d'item, expliquer le pourquoi, pas seulement le quoi. Si vos commits ressemblent à « fix bug » ou « update », vous écrivez dans une reasoning database avec un crayon vide.

Source 4 — Les cicatrices

C'est le journal des erreurs passées. Chaque fois qu'un agent IA s'est trompé, qu'un humain l'a corrigé, et qu'on en a tiré une règle nouvelle, on grave une cicatrice : type d'erreur, gravité, description, agent concerné, check ajouté pour éviter la récidive. Quand un agent prépare une nouvelle action, son orchestrateur lui présente les cicatrices ouvertes les plus pertinentes — c'est ce qui empêche le système de répéter ses propres erreurs.

Quatre-vingt-sept cicatrices gravées à ce jour sur cette stack. Aucune n'a nécessité une nouvelle techno DB. Elles vivent dans une table standard de neuf colonnes.

Source 5 — Les logs structurés des automates

Chaque script Python passe par un wrapper de logging qui capture, étape par étape, ce qui s'est passé : début, étapes nommées, durées, erreurs, compteurs métier. Les logs sont écrits en JSON Lines dans un dossier dédié par automate. Un automate qui ne logge pas est considéré comme aveugle et n'a pas le droit d'entrer en cron.

C'est du Python with standard, écrivant en JSONL. Aucune base spécialisée. Et pourtant, vous pouvez répondre à « combien de temps dure habituellement l'étape de génération IA, et quand a-t-elle dérivé ? » en deux lignes de pandas.

Les solutions pour bâtir une mémoire causale sans nouveau SGBD

Solution	Complexité	Gain estimé
Créer une table décisions à 9 colonnes dans votre SGBD existant	Faible	80% de la promesse « reasoning DB » en un après-midi
Imposer un wrapper de log structuré JSONL par automate	Faible	Visibilité totale sur les exécutions, debug 5× plus rapide
Discipline de commits Git avec référence d'items	Très faible	Historique requêtable gratuit, audit RGPD facilité
Table cicatrices pour les erreurs résolues + checks ajoutés	Moyenne	Le système ne répète plus jamais ses propres erreurs
Index transverse Python qui croise les 5 sources sur un sujet	Moyenne	Réponse en une commande à « qu'est-ce qui s'est passé sur X »

Le pont sémantique : agréger les cinq sources en une seule réponse

Avoir cinq sources, c'est avoir cinq silos. Le saut qualitatif vient quand on les agrège dans une vue unique, pour qu'un agent puisse demander « qu'est-ce qui s'est passé sur X » sans avoir à connaître la topologie de votre infra.

J'ai construit ce matin un module Python d'environ 300 lignes qui croise les cinq sources pour un sujet donné. L'API tient en une ligne : un appel à ReasoningView().about_backlog_item(121) retourne l'état courant en base, les décisions explicites, les commits Git pertinents, les cicatrices liées et les derniers événements de logs si le sujet est un automate. Une seule commande, cinq sources, zéro déplacement de données.

Pas une vue SQL, parce que les sources sont hétérogènes (DB + git + filesystem) et que dispatcher en Python est plus simple à maintenir. C'est ce que la communauté appelle parfois « reasoning layer ». Mais ce n'est pas une couche de stockage, c'est une couche d'indexation transverse. La distinction est cruciale.

Pour aller plus loin sur le rôle des agents IA dans une stack sans le confort d'un nouveau type de base, lisez aussi notre article Agents IA : pourquoi ils doivent vivre dans une base de données, pas dans des fichiers, et notre analyse du cocon Donner une méthode de pensée à chaque agent IA.

« L'écriture en partie double n'est pas une technique comptable, c'est une discipline de pensée : tout mouvement laisse deux traces, sinon il n'a pas eu lieu. »

Pourquoi ce n'est pas trivial — et pourquoi c'est faisable

J'entends d'avance l'objection : « Tout ça suppose une discipline qu'aucune équipe ne tient. » C'est en partie vrai. La discipline d'écriture coûte cher en début de projet. Personne n'aime ajouter cinq lignes de log à un script qui marche déjà. Personne n'aime expliquer le pourquoi dans un message de commit alors que le diff parle de lui-même.

Mais le coût de l'absence est beaucoup plus élevé, et il devient visible exactement au moment où vous essayez d'introduire des agents IA. Vous découvrez alors que votre base de données est un cimetière de conclusions, et vous croyez à tort que c'est la base qui est en cause. Vous commencez à chercher Datomic, des graphes, MCP, des LLM avec contextes infinis. Vous reportez le vrai problème, qui est culturel.

La bonne nouvelle : vous pouvez démarrer petit. Une seule table de décisions à neuf colonnes. Une seule règle : « toute mutation significative crée une décision dans la même transaction logique. » Un seul helper Python d'une cinquantaine de lignes pour enforcer la discipline. Vous gagnez la majeure partie de la promesse « reasoning database » en un après-midi. Le reste viendra avec l'usage.

Conclusion

Le débat « nos bases de données sont-elles prêtes pour l'IA ? » est mal posé. Votre base de données est probablement déjà capable de tout ce dont vous avez besoin — il lui manque simplement les colonnes que vous n'avez pas encore créées et les INSERT que vous n'avez pas encore écrits.

Le futur de l'IA d'entreprise ne tient pas dans une nouvelle technologie de stockage. Il tient dans ce que vos pipelines acceptent d'écrire dans les bases que vous avez déjà. Une table de décisions. Un wrapper de log structuré. Une discipline de message Git. Un journal des cicatrices. Un index transverse en Python.

Pacioli a inventé la comptabilité en partie double en 1494. Cinq cents ans plus tard, sa règle est toujours la même : toute mutation laisse une trace causale, sinon elle n'a pas eu lieu. Les agents IA d'aujourd'hui n'attendent pas une révolution technologique. Ils attendent que les ingénieurs d'aujourd'hui appliquent un principe d'il y a cinq siècles.

Et la bonne nouvelle, c'est que ça commence par un CREATE TABLE.

Vous souhaitez auditer votre stack contre cette grille en cinq sources et identifier les colonnes manquantes pour passer une équipe d'agents IA de prototype à production fiable ? Discutons de votre projet : contact@alexandrecarette.fr