Trois agents d'IA pour SQL, la connaissance et ce site, avec les décisions clés de sécurité, de coût et de fiabilité.

La plupart du contenu des « agents IA » est une démo : un enregistrement fluide, un seul chemin heureux, pas de gestion des erreurs, pas de plafond de coût, pas de plan pour les cas où le modèle est erroné. Ce n’est pas ça. Vous trouverez ci-dessous trois systèmes d’agents IA que j’utilise en production, chaque jour, sur des données réelles, avec de véritables rails de sécurité. Chacun remplace le travail qu’une personne effectuait à la main.

Le but n’est pas « regarde, AI ». Le point est le modèle d’ingénierie qui transforme un modèle en un système sur lequel vous pouvez réellement compter : il s’appuie sur vos données, limite ce qu’il est autorisé à faire, échoue gracieusement et reste bon marché.

Les trois systèmes

Système	Remplace	Interfaces	Pile
agent-sql	”Hé, peux-tu sortir ce rapport ?” demandes à un développeur	CLI + Télégramme	TypeScript, base de données SQL, OpenRouter
md-agent	Fouiller des documents dispersés pour trouver une réponse	Télégramme	TypeScript, SQLite FTS5, OpenRouter
/api/ai (ce site)	E-mails génériques « poser des questions sur mon travail »	Web (côté serveur)	IA des travailleurs Cloudflare

1. sql-agent — langage naturel vers SQL en lecture seule

GARDERXYZ0XYZGARDER

Le problème. Les données commerciales résident dans une base de données SQL. Les personnes qui ont besoin de réponses (propriétaires, analystes, comptables) n’écrivent pas en SQL. Ainsi, chaque question devient un ticket : “Combien de commandes proviennent de clients réguliers le mois dernier ?” Un développeur arrête ce qu’il fait, écrit un SELECT et recolle un tableau. C’est répétitif, lent et bloque les deux côtés.

Ce qu’il fait. sql-agent répond à une question en anglais simple ou en russe, génère un SELECT en lecture seule, l’exécute sur la base de données et renvoie les lignes, ainsi qu’un résumé facultatif en langage clair.

"How many orders from repeat customers last month?"
        ↓  (LLM: schema-aware SELECT generation)
   SELECT count(*) FROM orders WHERE ...
        ↓  (read-only execution + row cap)
   rows → "412 orders, 38% from repeat customers"

Le plus difficile n’est pas le SQL, c’est la sécurité. Un agent de base de données en langage naturel capable d’écrire des requêtes arbitraires est un handicap. Les décisions qui ont rendu suffisamment sûr le fonctionnement sans surveillance :

• Lecture seule par construction. L’agent produit uniquement SELECT. Les écritures et les modifications de schéma sont refusées avant l’exécution.
• Journalisation des requêtes. Chaque requête générée est enregistrée avec la question d’origine, donc tout ce qui est douteux peut être audité après coup.
• Limites de lignes et délais d’attente. Une requête générée qui analyse 40 millions de lignes ne peut pas mettre hors service la base de données : les résultats sont plafonnés et abandonnés.
• Le modèle est échangeable ; la sécurité ne l’est pas. Il fonctionne sur OpenRouter (Claude Sonnet 4 par défaut, GLM comme solution de secours), mais la garde en lecture seule réside dans mon code, pas dans la bonne volonté du modèle.

Analogue commercial. C’est exactement le système dont un propriétaire de boutique Shopify ou un responsable des opérations a besoin : posez une question avec vos propres mots, obtenez un numéro, n’attendez plus jamais un développeur pour un rapport de routine.

2. md-agent — un LLM fondé sur une base de connaissances markdown

GARDERXYZ1XYZGARDER

Le problème. Les connaissances sont dispersées (notes de réunion, documents de processus, décisions, runbooks) dans des dizaines de fichiers de démarques. La recherche par mot-clé trouve des mots, pas des réponses. Ainsi, soit les gens reposent des questions auxquelles on a déjà répondu, soit ils abandonnent et prennent des décisions sans contexte.

Ce qu’il fait. md-agent est un robot Telegram qui répond aux questions fondées sur votre base de connaissances markdown : il récupère d’abord les morceaux pertinents (recherche en texte intégral SQLite FTS5), puis les transmet au LLM pour qu’il y réponde. Il s’agit d’une récupération puis d’une réponse, pas d’une génération gratuite.

question → FTS5 retrieve top-k MD chunks → LLM answers FROM those chunks
                                              ↓
                              "no relevant chunks" → honest "I don't know"

Les décisions qui l’ont rendu de qualité production :

• À la terre, pas halluciné. La réponse est limitée au contexte récupéré. Si la base de connaissances ne contient rien de pertinent, elle le dit au lieu d’inventer – la propriété la plus importante d’un agent de connaissances digne de confiance.
• Hébergement Lean. Il fonctionne sur un VPS de 1 CPU / 2 Go de RAM. Un assistant de base de connaissances n’a pas besoin d’un GPU ou d’un gros serveur.
• Modèles de niveau gratuit. La valeur par défaut est un point de terminaison OpenRouter gratuit (DeepSeek V3). L’architecture ne dépend d’aucun modèle ni d’aucune facture.
• Filet de sécurité Git. La base de connaissances est contrôlée en version, les modifications sont donc récupérables.

Analogue métier. Recherche de connaissances internes et détournement du support : le même schéma qui empêche une équipe d’assistance de répondre indéfiniment aux mêmes cinq questions.

3. L’agent sur ce site

Ce site a son propre petit agent chez /api/ai. C’est le plus léger des trois, et il existe pour montrer le motif à un coût minime :

• Côté serveur uniquement. Aucune clé API dans le navigateur. Le navigateur appelle une route ; la route appelle le modèle.
• Entrée limitée. Les invites sont plafonnées ; les charges utiles sont limitées en taille.
• Taux limité. Une fenêtre coulissante par IP arrête les abus.
• Dégradation gracieuse. Si la liaison du modèle est absente (par exemple un déploiement statique), elle l’indique au lieu de planter.
• Modèle bon marché. Il fonctionne sur un petit modèle Workers AI (Llama 3.1 8B) — non pas parce que les petits modèles sont meilleurs, mais parce qu’un assistant de portefeuille n’a pas besoin d’un modèle frontière et que la discipline des coûts fait partie du problème.

Le modèle derrière les trois

Supprimez les différences et les cinq mêmes décisions apparaissent dans chaque agent de production que j’expédie :

1. Mettez-le à la terre. Les réponses proviennent de vos données (schéma SQL récupéré, documents récupérés, invite système organisée) — et non de l’imagination du modèle.
2. Lié. Lecture seule. Lignes plafonnées. Jetons plafonnés. Refus des demandes hors champ.
3. Journal et audit. Chaque action est traçable après coup.
4. Échouez gracieusement. Modèle réduit, liaison manquante, entrée abusive : le système se dégrade, il ne plante pas et ne fuit pas les composants internes.
5. Gardez-le à bas prix. Adaptez la taille du modèle à la tâche. Un robot de connaissances n’a pas besoin d’un modèle de jeton à 20 $/M ; une tâche de raisonnement difficile ne devrait pas s’exécuter sur la moins chère.

Une démo ignore les cinq. La production nécessite les cinq.

Où cela apparaît-il dans mon travail

Ce ne sont pas des expériences isolées. Les mêmes modèles se retrouvent dans tout ce que je construis : ak-payload (une plateforme de commerce Payload CMS + Next.js), ak-blog (ce site) et les études de cas clients. Partout où il y a un travail répétitif lié aux données, un agent ancré avec une portée limitée est généralement le bon outil. Des pages dédiées à ces projets arrivent sur le site.

Avantages et inconvénients de la création ou de l’achat d’un SaaS

Construisez lorsque le flux de travail est essentiel, que les données sont sensibles ou que la facture SaaS évolue de manière douloureuse avec l’utilisation (le piège Zapier classique). Achetez lorsqu’il s’agit d’une intégration de produits sur laquelle vous ne ferez jamais de différence.

Les trois agents ci-dessus sont tous « construits » : parce qu’ils touchent à des données commerciales réelles, le modèle de sécurité est important et le coût par demande d’un équivalent SaaS s’additionne rapidement.

TL;DR

Système	Ce que cela prouve	Décision clé en matière de sécurité
agent-sql	NL → SQL en production	Lecture seule par construction
md-agent	Questions et réponses sur la base de connaissances sur un VPS de 2 Go	Récupérez puis répondez ; honnête “Je ne sais pas”
/api/ai	Agent côté serveur à coût minimal	Entrée limitée + dégradation gracieuse

Un agent IA est un système autour d’un modèle, pas le modèle lui-même. Le modèle est la partie la plus facile. La mise à la terre, les rails de sécurité, le plafond de coût et la panne progressive — voilà le travail, et c’est ce qui le rend suffisamment fiable pour fonctionner tous les jours.Si vous avez un flux de travail répétitif et lié aux données qu’une personne gère manuellement aujourd’hui, c’est exactement là où un agent de production s’intègre — parlez-m’en.