SQL Server 2025 comme Base de Données Prête pour les Agents : Sécurité, Backup et MCP dans un Seul Moteur

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

J’ai suivi la série Polyglot Tax d’Aditya Badramraju avec beaucoup d’intérêt. La partie 4 clôt la série avec les parties qui déterminent vraiment si vous feriez confiance à cette architecture en production.

Un Modèle de Sécurité pour Tous les Modèles de Données

Une seule politique Row-Level Security couvre toutes les tables — relationnelles, JSON, graphes, vecteurs. Une politique, une preuve pour l’auditeur.

Backup Unifié = Récupération Atomique

Dans un stack polyglottes, la récupération point-in-time sur cinq bases de données est un cauchemar de cohérence. Avec une seule base de données, c’est atomique par définition.

Intégration MCP : Agents Sans Middleware

SQL Server 2025 supporte directement le SQL MCP Server. Les agents appellent des outils, le moteur impose l’isolation tenant et le masquage des colonnes automatiquement.

Conclusion

Pour les développeurs .NET qui construisent des applications agent-first sur Azure SQL, cette architecture mérite une sérieuse considération. Post original d’Aditya Badramraju : The Polyglot Tax – Part 4.

68 Minutes par Jour à Ré-Expliquer Son Code ? Il Y a une Solution

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Vous connaissez ce moment où votre session Copilot atteint /compact et que l’agent oublie complètement ce sur quoi vous travailliez ? Vous passez les cinq minutes suivantes à ré-expliquer la structure des fichiers, le test qui échoue, les trois approches déjà essayées. Puis ça recommence.

Desi Villanueva l’a chronométré : 68 minutes par jour — juste pour la réorientation. Pas à écrire du code. Pas à revoir des PRs. Juste à remettre l’IA au courant de choses qu’elle savait déjà.

Il s’avère qu’il y a une raison concrète à cela — et une solution concrète.

Le Mensonge de la Fenêtre de Contexte

Votre agent arrive avec un grand nombre sur la boîte. 200K tokens. Ça semble massif. En pratique c’est un plafond, pas une garantie.

Voici le calcul réel :

200K contexte total
Moins ~65K pour les outils MCP chargés au démarrage (~33%)
Moins ~10K pour les fichiers d’instructions comme AGENTS.md

Cela vous laisse environ 125K avant d’avoir tapé un seul mot. Et ça empire — les LLMs ne se dégradent pas gracieusement. Ils atteignent un mur vers 60% d’utilisation. Le modèle commence à perdre des éléments mentionnés 30 tours plus tôt.

Limite effective : 45K tokens avant que la qualité se dégrade.

La Taxe de Compactage

Chaque /compact vous coûte votre état de flow. Vous êtes profondément dans une session de débogage. Contexte partagé construit sur 30 minutes. Puis l’avertissement arrive.

La partie cruelle : La mémoire existe déjà. Copilot CLI écrit chaque session dans une base de données SQLite locale à ~/.copilot/session-store.db. L’agent ne peut tout simplement pas la lire.

auto-memory : Une Couche de Rappel, Pas un Système de Mémoire

pip install auto-memory

~1 900 lignes de Python. Zéro dépendances. Installé en 30 secondes.

Au lieu d’inonder le contexte avec des résultats grep, vous donnez à l’agent un accès chirurgical à ce qui compte vraiment — 50 tokens au lieu de 10 000.

En Conclusion

Le context rot est une contrainte architecturale réelle. auto-memory le contourne en donnant à votre agent un mécanisme de rappel bon marché et précis.

Consultez-le : auto-memory sur GitHub. Post original de Desi Villanueva : I Wasted 68 Minutes a Day.

AI Apps | The .NET Blog