> ## Documentation Index
> Fetch the complete documentation index at: https://supastack.dev/llms.txt
> Use this file to discover all available pages before exploring further.
> For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt

# Fonctionnalités IA

Chat, tâches, politique de modèles et bring-your-own-key.

## Essayez une fausse IA, puis choisissez un vrai fournisseur

Pour votre premier résultat, suivez la tâche /dashboard du didacticiel Web : démarrez le flux local, mettez une invite en file d'attente, exécutez-la et affichez le résultat. AI_PROVIDER=fake renvoie une réponse de démonstration reproductible sans envoyer de données à un modèle externe ni utiliser une clé API payante.

Pour une génération réelle, configurez d'abord les comptes persistants, choisissez un fournisseur d'IA et suivez la configuration de l'IA ci-dessous. Ajoutez un modèle et son prix au catalogue de la base de données, choisissez les modèles autorisés pour chaque alias et accordez à l'espace de travail l'accès requis. Un alias tel que fast est un choix convivial présenté à l'utilisateur ; il ne s'agit pas en soi de l'ID de modèle d'un fournisseur externe.

Un AI task en arrière-plan nécessite également le service de tâches configuré. Si aucun choix de modèle n’est affiché, inspectez la stratégie de catalogue et d’alias avant de réessayer. Si l’accès est refusé, inspectez les droits de l’espace de travail actif. Conservez toutes les clés du fournisseur API dans la configuration du serveur Web, et non dans la fenêtre du navigateur, de l'application mobile ou du bureau.

[Essayez la démonstration d'IA sans identifiants](https://supastack.dev/fr/docs/web/ship-in-5-minutes.md)

[Configurer la véritable génération d'IA](https://supastack.dev/fr/docs/modules/ai-configuration.md)

[Ajouter les modèles et les prix autorisés](https://supastack.dev/fr/docs/web/setup-ai.md)

[Configurer l'exécution des tâches en arrière-plan](https://supastack.dev/fr/docs/modules/jobs.md)


## Suivre le cycle de vie d’une tâche

L’API de tâches de production valide l’espace de travail authentifié et son droit d’accès avant d’enregistrer une tâche et de distribuer le workflow Trigger.dev ai.generate. Le routeur applique les capacités requises et la politique de modèles configurée.

```
POST /api/ai/tasks
  → authenticated workspace + entitlement
  → durable task record
  → Trigger.dev ai.generate
  → model routing + generation
  → usage record + result
  → transactional completion delivery
```


## Configurer les alias et les budgets

L’utilisateur choisit un alias activé : cheap, fast ou smart. Le serveur contrôle les identifiants des modèles sous-jacents, les identifiants des fournisseurs, la politique de l’espace de travail et le budget. Le chiffrement des clés personnelles des utilisateurs doit respecter la même frontière réservée au serveur.


## Garder explicites les garanties du workflow

JobRunner garantit uniquement la mise en file, l’état et l’annulation. Les garanties du workflow Trigger.dev sont explicites, y compris l’exécution durable. Ne déduisez pas de garanties de nouvelle tentative ou de planification du contrat générique.

Le chemin de soumission de production utilise l’idempotence et la reprise d’une tâche enregistrée pour traiter une distribution incertaine. La fin de la génération est indépendante de la livraison de l’e-mail de fin.


## Configuration et paramètres

AI_PROVIDER=fake garde le développement déterministe. Les fournisseurs de production se configurent côté serveur (OpenAI, Anthropic ou un endpoint compatible OpenAI) avec des clés qui n'entrent jamais dans les bundles client. AI_MODEL_POLICY mappe les alias côté utilisateur — cheap, fast, smart — vers des ids de modèles du catalogue ; un alias vide retire le choix de l'interface.

Le catalogue de modèles (ai-model-catalog) porte des métadonnées de capacité et des prix immuables pour que les enregistrements d'usage restent explicables après un changement de prix.

```
POST /api/ai/tasks          → durable task + Trigger.dev dispatch
GET  /api/ai/tasks/{taskId}  → status + result
/chat                        → streaming assistant surface
```


## Processus d’implémentation

La surface de chat garde des threads par membre du workspace et streame les tokens via chat-stream-runtime. Les générations plus longues tournent en tâches : autorisées à la frontière API, exécutées par le workflow ai.generate, et récupérables via le store de soumission idempotent.

Le mode bring-your-own-key stocke les clés fournisseur en enveloppes AES-GCM (CREDENTIAL_ENCRYPTION_KEY, byok-key-vault.ts) ; le déchiffrement n'a lieu que dans le chemin d'exécution serveur. Usage et coût estimé sont enregistrés par requête pour les budgets du workspace.


## Vérification et dépannage

Vérifiez qu'un alias désactivé est absent de l'interface, que les refus d'entitlement et de budget surviennent avant le dispatch, qu'une soumission retentée réutilise sa tâche, et qu'une clé BYOK stockée n'est jamais renvoyée au client. Gardez l'acceptation sur modèle réel sur le chemin smoke fournisseur documenté.


## Suivant

[Tâches en arrière-plan](https://supastack.dev/fr/docs/web/jobs.md)