Ce que les LLM changent dans l'architecture de données

Les LLM ne changent pas que le code. Ils changent l'architecture de données. Voici les 5 transformations que les LLM imposent à votre stack data.

1. La base vectorielle comme nouvelle couche

Avant les LLM, votre stack data était : base relationnelle (SQL Server/PostgreSQL) + cache (Redis) + data warehouse (Snowflake). Après les LLM, il faut ajouter une base vectorielle (Pinecone/Qdrant/pgvector).

Cette base vectorielle stocke les embeddings — les représentations vectorielles de vos textes, images, et données. Elle est interrogée par similarité sémantique, pas par clé exacte. C'est un nouveau paradigme qui coexiste avec le relationnel.

2. Le RAG comme pattern dominant

Le Retrieval-Augmented Generation est l'architecture derrière la plupart des applications LLM d'entreprise. Au lieu de fine-tuner un LLM sur vos données (coûteux, risqué), vous lui donnez du contexte à chaque requête.

L'architecture RAG :

1. L'utilisateur pose une question.
2. La question est convertie en vecteur par un modèle d'embedding.
3. La base vectorielle trouve les documents les plus pertinents.
4. Ces documents + la question sont envoyés au LLM.
5. Le LLM répond en se basant sur le contexte fourni.

Cette architecture change votre façon de stocker les données. Chaque document doit avoir son embedding stocké. Chaque modification de document doit mettre à jour l'embedding. C'est un nouveau pipeline de données.

3. Le semantic caching

Le cache traditionnel utilise une clé exacte. Si la question est "Comment réinitialiser mon mot de passe ?", le cache stocke la réponse sous cette clé exacte. Si l'utilisateur demande "Comment faire un reset de password ?", le cache ne trouve rien — même si la réponse est la même.

Le semantic caching utilise les embeddings. La question est convertie en vecteur. On cherche dans le cache des questions similaires. Si une question similaire a déjà été posée, on retourne sa réponse. Le cache hit rate passe de 20% à 60% sur des questions utilisateurs.

Le semantic caching réduit les coûts LLM de 50% et la latence de 80%. C'est un game-changer pour les applications LLM à grande échelle.

4. Les agentic workflows

Un LLM seul répond à une question. Un agent LLM prend des actions : il interroge une base de données, appelle une API, modifie un fichier, puis répond. Les agentic workflows nécessitent une architecture de données différente.

L'agent a besoin de :

• Un état persistant (mémoire de la conversation).
• Un accès aux outils (bases de données, APIs).
• Un historique des actions (audit trail).

Ces données sont stockées différemment des données transactionnelles classiques. L'état de l'agent est souvent un document JSON. L'historique est un log append-only. L'accès aux outils nécessite un système de permissions.

5. La gouvernance des embeddings

Les embeddings sont des données dérivées. Mais elles posent des questions de gouvernance :

• Qui peut accéder aux embeddings ?
• Les embeddings contiennent-ils des informations sensibles ? (Oui — un embedding peut révéler le contenu du texte source.)
• Combien de temps conserve-t-on les embeddings ?
• Comment supprime-t-on les embeddings quand l'utilisateur demande l'effacement de ses données ?

Ces questions n'ont pas de réponse évidente. La gouvernance des embeddings est un nouveau domaine que les DPO et les architectes data doivent maîtriser.

Conclusion

Les LLM ne sont pas qu'un nouveau type d'API. Ils sont un nouveau paradigme qui transforme l'architecture de données. Les entreprises qui ignorent cette transformation perdent leur avantage. Celles qui l'embrassent gagnent une longueur d'avance.