Ne pas mélanger toutes les données dans les mêmes tables
Une application qui utilise l’IA manipule plusieurs catégories de données très différentes : données métier transactionnelles, documents, embeddings, conversations, prompts, résultats de modèles, traces techniques et données d’audit.
Les réunir sans séparation claire crée rapidement des problèmes de performance, de gouvernance et de sécurité. Une bonne architecture commence par identifier les responsabilités de chaque zone de stockage.
PostgreSQL peut parfaitement rester le cœur du système, mais les schémas et tables doivent être organisés par usage plutôt que par facilité de développement.
Le cœur transactionnel reste relationnel
Les entités métier critiques doivent rester modélisées avec des relations, contraintes, clés étrangères, index et transactions. L’IA ne remplace pas la cohérence relationnelle.
Clients, utilisateurs, contrats, interventions, commandes ou droits d’accès doivent garder des identifiants stables et des règles d’intégrité fortes.
Cette couche constitue la source de vérité. Les traitements IA viennent l’enrichir, mais ne doivent pas devenir la seule représentation de l’état métier.
Séparer documents, chunks et embeddings
Dans une architecture RAG, il est utile de distinguer le document source, ses versions, les chunks produits et les embeddings associés.
Un chunk doit conserver une référence vers son document, son numéro de version, sa position, ses métadonnées métier et éventuellement son hash. Cela permet de reconstruire la provenance d’une réponse.
Avec pgvector, l’embedding peut être stocké dans PostgreSQL, mais il faut prévoir les index vectoriels, la stratégie de filtrage et la suppression cohérente lors d’une nouvelle version de document.
Journaliser les appels IA sans stocker n’importe quoi
Pour diagnostiquer un système IA, il faut pouvoir retrouver le modèle utilisé, la latence, le statut, le coût approximatif, la version du prompt et les erreurs.
En revanche, conserver systématiquement le prompt complet et toutes les données envoyées peut créer une copie durable d’informations sensibles.
La bonne approche consiste à séparer les métadonnées techniques des contenus, à masquer les champs sensibles et à définir une durée de rétention adaptée.
Prévoir le multi-tenant et la sécurité dès le modèle de données
Dans un SaaS IA multi-entreprises, chaque donnée métier, document, chunk, conversation et trace doit être rattaché explicitement à une organisation ou un tenant.
Les filtres de tenant ne doivent pas être ajoutés seulement dans l’interface. Ils doivent être imposés côté backend et, lorsque cela est pertinent, renforcés avec Row Level Security PostgreSQL.
Cette discipline devient encore plus importante avec des agents IA capables d’enchaîner plusieurs outils et plusieurs sources de données.
Une structure de référence
Une structure simple peut séparer les schémas logical_business, ai_knowledge, ai_runtime et audit. Les noms importent moins que la séparation des responsabilités.
Le schéma métier contient les entités transactionnelles. Le schéma connaissance contient documents, chunks et embeddings. Le runtime contient conversations, exécutions d’agents et résultats. L’audit contient les événements nécessaires à la traçabilité.
Cette organisation rend les migrations, politiques de rétention, permissions et analyses beaucoup plus faciles à maîtriser lorsque l’application grandit.
