Construire des applications alimentées par des agents avec Next.js, Supabase et Cron en 2026
J'ai passé les six derniers mois à construire des applications alimentées par des agents
J'ai passé les six derniers mois immergé dans la construction de trois applications alimentées par des agents pour des clients. Deux sont entièrement en direct, traitant autonomement des milliers de tâches chaque jour. Alors, qu'alimente ces projets ? C'est la combinaison formidable de Next.js déployé sur Vercel, Supabase pour la persistance et les besoins en temps réel, et une bonne vieille orchestration basée sur cron pour garder les agents alignés et éviter des frais API excessifs. Ce n'est pas seulement de la théorie--je vais vous expliquer ce qui fonctionne, les pièges, et tous les enseignements que j'aurais aimé avoir avant de me lancer.
À quoi ressemblent vraiment les applications alimentées par des agents en 2026
Quand je parle d'« applications alimentées par des agents », je ne discute pas seulement d'un chatbot répétant un message système. Pensez à un logiciel qui gère autonomement des tâches multi-étapes, prend des décisions basées sur des données en temps réel, et fonctionne selon un calendrier, tout sans intervention humaine.
Voici un aperçu de ce qui est en production :
- Des pipelines de contenu qui analysent les flux RSS, génèrent des résumés, rédigent des messages sociaux, et les mettent en file d'attente pour révision. Ce cycle se répète toutes les 30 minutes comme une horloge.
- Des agents de réconciliation de données qui se connectent à plusieurs API chaque nuit, détectent les incohérences, tentent des corrections automatiques, et font remonter les problèmes qu'ils ne peuvent pas résoudre.
- Des agents d'intégration client déclenchés par des webhooks de nouvelles inscriptions. Ces agents provisionnent les ressources, envoient des séquences personnalisées, et s'adaptent en apprenant les comportements des utilisateurs.
Le fil conducteur ? Ils ont besoin de persistance d'état, d'exécution programmée, d'accès aux outils, et d'un moyen pour les humains d'observer et d'intervenir si nécessaire. C'est le point idéal pour la pile sur laquelle nous nous plongeons.
Pourquoi cette pile fonctionne
J'ai essayé d'autres configurations. Il y a LangChain associé à un backend Python, Temporal pour l'orchestration, et des systèmes de files d'attente AWS personnalisés. Bien qu'ils font tous le travail, ils viennent avec une montagne de complexité opérationnelle que la plupart des équipes ne peuvent tout simplement pas gérer en 2026.
Voici ma comparaison simple et directe :
| Stack | Temps de configuration | Surcharge opérationnelle | Coût à 10K tâches/jour | Meilleur pour |
|---|---|---|---|---|
| Next.js + Supabase + Vercel Cron | 1-2 jours | Faible | ~$85-150/mo | Plupart des applications agent |
| Python + Celery + Redis + AWS | 3-5 jours | Élevée | ~$200-400/mo | Tâches de calcul lourd |
| Temporal + Custom Workers | 5-10 jours | Très élevée | ~$300-600/mo | Flux de travail complexes |
| Inngest + Next.js | 1-2 jours | Faible-Moyen | ~$100-200/mo | Agents événementiels |
La combinaison Next.js gagne haut la main en rapidité. Vous obtenez des fonctions serverless, une interface de tableau de bord, des bases de données, une authentification, des mises à jour en temps réel, et une exécution programmée sans vous soucier de l'infrastructure. Pour la grande majorité d'entre nous construisant des applications agent, c'est plus que suffisant.
Aperçu de l'architecture
Peignons un tableau de l'architecture qui a été un succès dans les projets :
┌─────────────────┐ ┌──────────────────┐
│ Vercel Cron │────▶│ Next.js API Route │
│ (Scheduler) │ │ (Agent Runner) │
└─────────────────┘ └────────┬───────────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
┌──────────┐ ┌─────────┐ ┌───────────┐
│ Supabase │ │ LLM API │ │ External │
│ (State + │ │ (OpenAI/│ │ Tools & │
│ Queue) │ │ Claude) │ │ APIs │
└──────────┘ └─────────┘ └───────────┘
│
▼
┌──────────┐
│ Supabase │
│ Realtime │──▶ Dashboard UI
└──────────┘
Les tâches cron contactent une route API Next.js, qui récupère ensuite les tâches depuis Supabase, exécute la logique de l'agent, écrit les résultats, et se termine. Pendant ce temps, votre tableau de bord observe l'action avec Supabase Realtime délivrant les mises à jour en direct.
Ouais, suffisamment simple, mais le diable prospère dans les détails.
Mettre en place les fondations avec Next.js et Vercel
Quand vous construisez des applications agent en 2026, Next.js 15 avec l'App Router est un incontournable. Cela vous donne les modèles d'exécution les plus propres grâce à ses Server Actions et Route Handlers. Chez Social Animal, nous avons affiné cette compétence Next.js, et laissez-moi vous dire que l'App Router a mûri splendidement pour les projets backend-intensifs.
Démarrer un projet est simple :
pnpx create-next-app@latest agent-app --typescript --tailwind --app
cd agent-app
pnpm add @supabase/supabase-js ai @ai-sdk/openai
J'utilise le Vercel AI SDK grâce à son interface unifiée entre les différents fournisseurs LLM. En 2026, la version 4.x du paquet ai supporte les sorties structurées, les appels d'outils, et le streaming directement d'emblée – LangChain qui ?
Maintenant votre vercel.json doit ressembler à ceci pour la configuration cron :
{
"crons": [
{
"path": "/api/agents/run",
"schedule": "*/15 * * * *"
},
{
"path": "/api/agents/cleanup",
"schedule": "0 2 * * *"
}
]
}
Le premier cron exécute l'agent toutes les 15 minutes. Le second nettoie chaque nuit. N'oubliez pas, Vercel Pro ($20/mois) supporte les tâches cron avec une fréquence jusqu'à 1 minute. Mais si vous êtes sur le plan Hobby, vous êtes limité aux crons quotidiens, ce qui ne suffira tout simplement pas pour la plupart des besoins des applications agent.
Configuration des fonctions Vercel
Les tâches d'agent peuvent être plus longues qu'un blockbuster d'été (OK, pas vraiment), mais elles ont besoin de plus de 10 secondes pour s'exécuter par défaut. Configurez votre route comme ceci :
// app/api/agents/run/route.ts
export const maxDuration = 300; // 5 minutes on Pro plan
export const dynamic = 'force-dynamic';
export async function GET(request: Request) {
// Verify cron secret to prevent unauthorized access
const authHeader = request.headers.get('authorization');
if (authHeader !== `Bearer ${process.env.CRON_SECRET}`) {
return new Response('Unauthorized', { status: 401 });
}
// Agent logic goes here
return Response.json({ success: true });
}
Ce maxDuration ? C'est crucial. Jusqu'à 300 secondes sur Pro, et 900 secondes si vous êtes dans les eaux Enterprise. Une tâche qui dépasse régulièrement 5 minutes ? Il est temps de la fragmenter ou de repenser votre modèle d'exécution.
Supabase comme le cerveau de votre agent
Supabase--une puissance ici. Elle se tient comme votre file d'attente de tâches, stockage d'état, journal d'audit, et votre notifieur pour les mises à jour en temps réel. Voici le schéma que j'ai affiné au fil du temps :
-- Agent task queue
CREATE TABLE agent_tasks (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
agent_type TEXT NOT NULL,
status TEXT NOT NULL DEFAULT 'pending'
CHECK (status IN ('pending', 'running', 'completed', 'failed', 'cancelled')),
priority INTEGER DEFAULT 0,
payload JSONB NOT NULL DEFAULT '{}',
result JSONB,
error TEXT,
attempts INTEGER DEFAULT 0,
max_attempts INTEGER DEFAULT 3,
locked_until TIMESTAMPTZ,
scheduled_for TIMESTAMPTZ DEFAULT NOW(),
started_at TIMESTAMPTZ,
completed_at TIMESTAMPTZ,
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW()
);
-- Index for the queue polling query
CREATE INDEX idx_agent_tasks_queue ON agent_tasks (
agent_type, status, priority DESC, scheduled_for
) WHERE status = 'pending';
-- Agent execution logs for observability
CREATE TABLE agent_logs (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
task_id UUID REFERENCES agent_tasks(id),
level TEXT NOT NULL DEFAULT 'info',
message TEXT NOT NULL,
metadata JSONB DEFAULT '{}',
created_at TIMESTAMPTZ DEFAULT NOW()
);
-- Agent state persistence (for multi-step agents)
CREATE TABLE agent_state (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
agent_type TEXT NOT NULL,
agent_instance_id TEXT NOT NULL,
state JSONB NOT NULL DEFAULT '{}',
updated_at TIMESTAMPTZ DEFAULT NOW(),
UNIQUE(agent_type, agent_instance_id)
);
Cette colonne locked_until ? C'est la clé. Elle imite un verrou distribué improvisé. Cela signifie quand une tâche cron récupère une tâche, elle définit locked_until en avant de 5 minutes. Si le processus plante, le verrou expire, et un autre cycle peut lui donner une autre chance.
La requête de saisie de tâche
Le chef-d'œuvre. C'est votre billet d'or pour saisir des tâches sans retraitement :
import { createClient } from '@supabase/supabase-js';
const supabase = createClient(
process.env.SUPABASE_URL!,
process.env.SUPABASE_SERVICE_ROLE_KEY!
);
async function claimTasks(agentType: string, limit: number = 5) {
const { data: tasks, error } = await supabase
.rpc('claim_agent_tasks', {
p_agent_type: agentType,
p_limit: limit,
p_lock_duration: '5 minutes'
});
if (error) throw error;
return tasks;
}
Et la fonction Postgres correspondante :
CREATE OR REPLACE FUNCTION claim_agent_tasks(
p_agent_type TEXT,
p_limit INTEGER,
p_lock_duration INTERVAL
)
RETURNS SETOF agent_tasks AS $$
BEGIN
RETURN QUERY
UPDATE agent_tasks
SET
status = 'running',
locked_until = NOW() + p_lock_duration,
started_at = NOW(),
attempts = attempts + 1,
updated_at = NOW()
WHERE id IN (
SELECT id FROM agent_tasks
WHERE agent_type = p_agent_type
AND status = 'pending'
AND scheduled_for <= NOW()
AND (locked_until IS NULL OR locked_until < NOW())
AND attempts < max_attempts
ORDER BY priority DESC, scheduled_for ASC
LIMIT p_limit
FOR UPDATE SKIP LOCKED
)
RETURNING *;
END;
$$ LANGUAGE plpgsql;
Le FOR UPDATE SKIP LOCKED est le héros méconnu ici. Il assure qu'aucun de deux appels concurrents ne marche sur les pieds les uns des autres. Croyez-moi, découvrir et corriger le double traitement n'était pas une partie de plaisir.
Orchestration des agents basée sur Cron
Vercel Cron est le battement régulier de toute cette opération. Toutes les 15 minutes, votre agent runner s'active, saisit les tâches, les traite, puis dort jusqu'à l'appel suivant.
Voici comment la route complète du agent runner se dessine :
// app/api/agents/run/route.ts
import { claimTasks, completeTask, failTask, logAgent } from '@/lib/agents';
import { runContentAgent } from '@/lib/agents/content';
import { runReconciliationAgent } from '@/lib/agents/reconciliation';
export const maxDuration = 300;
const AGENT_RUNNERS: Record<string, (task: AgentTask) => Promise<any>> = {
'content-pipeline': runContentAgent,
'data-reconciliation': runReconciliationAgent,
};
export async function GET(request: Request) {
const authHeader = request.headers.get('authorization');
if (authHeader !== `Bearer ${process.env.CRON_SECRET}`) {
return new Response('Unauthorized', { status: 401 });
}
const results = { processed: 0, failed: 0, skipped: 0 };
for (const [agentType, runner] of Object.entries(AGENT_RUNNERS)) {
const tasks = await claimTasks(agentType, 5);
for (const task of tasks) {
try {
await logAgent(task.id, 'info', `Starting ${agentType} task`);
const result = await runner(task);
await completeTask(task.id, result);
results.processed++;
} catch (error) {
const message = error instanceof Error ? error.message : 'Unknown error';
await failTask(task.id, message);
await logAgent(task.id, 'error', message);
results.failed++;
}
}
}
return Response.json(results);
}
Remarquez le traitement séquentiel par type d'agent, avec un plafond de 5 tâches par type par exécution. Cela aide à garder les temps d'exécution des fonctions en échec. Avez-vous une pile de 50 tâches en attente ? Divisez-les sur plusieurs cycles cron. Pas de précipitation, pas de problème.
Quand Cron ne suffit pas
Parfois, la vie vous frappe plus fort, et cron ne suffit tout simplement pas. Dans ces cas, j'intègre cron avec les Webhooks de base de données Supabase ou les Edge Functions--ils se déclenchent par les changements de base de données :
-- Trigger an edge function when a high-priority task is created
CREATE OR REPLACE FUNCTION notify_urgent_task()
RETURNS TRIGGER AS $$
BEGIN
IF NEW.priority > 5 THEN
PERFORM net.http_post(
url := 'https://your-app.vercel.app/api/agents/urgent',
headers := jsonb_build_object(
'Authorization', 'Bearer ' || current_setting('app.webhook_secret')
),
body := jsonb_build_object('task_id', NEW.id)
);
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
Cette configuration vous permet de mélanger le traitement prévisible basé sur cron avec une réaction rapide pour les tâches urgentes.
Construire la boucle de l'agent
C'est ici que la magie opère. Un exemple d'implémentation d'agent utilisant l'appel d'outils du Vercel AI SDK :
// lib/agents/content.ts
import { generateText, tool } from 'ai';
import { openai } from '@ai-sdk/openai';
import { z } from 'zod';
import { supabase } from '@/lib/supabase';
export async function runContentAgent(task: AgentTask) {
const { sourceUrl, targetPlatform } = task.payload;
const { text, toolCalls, usage } = await generateText({
model: openai('gpt-4o-mini'),
system: `You are a content processing agent. Fetch the source content,
analyze it, and generate appropriate social media content for ${targetPlatform}.
Use the provided tools to complete your task.`,
prompt: `Process this source: ${sourceUrl}`,
tools: {
fetchContent: tool({
description: 'Fetch content from a URL',
parameters: z.object({ url: z.string().url() }),
execute: async ({ url }) => {
const res = await fetch(url);
const html = await res.text();
// Strip HTML, extract main content
return extractMainContent(html);
},
}),
saveContent: tool({
description: 'Save generated content for review',
parameters: z.object({
title: z.string(),
body: z.string(),
platform: z.string(),
suggestedPostTime: z.string(),
}),
execute: async (content) => {
const { data, error } = await supabase
.from('generated_content')
.insert({
...content,
task_id: task.id,
status: 'pending_review',
})
.select()
.single();
if (error) throw error;
return { saved: true, id: data.id };
},
}),
},
maxSteps: 5, // Allow up to 5 tool-calling rounds
});
return {
summary: text,
toolCallCount: toolCalls.length,
tokensUsed: usage.totalTokens,
};
}
Définir maxSteps à 5 permet au LLM d'appeler des outils, d'évaluer les résultats, et de traiter en conséquence--juste comme une petite abeille travailleuse faisant son travail. La plupart des tâches de contenu se terminent en 3–4 de ces appels.
Surveillance des agents en temps réel avec Supabase Realtime
Les agents autonomes sont formidables, mais garder un œil sur eux est primordial. Supabase Realtime alimente un tableau de bord qui se met à jour en temps réel au fur et à mesure que les agents accomplissent les choses :
// components/AgentDashboard.tsx
'use client';
import { useEffect, useState } from 'react';
import { createClient } from '@supabase/supabase-js';
const supabase = createClient(
process.env.NEXT_PUBLIC_SUPABASE_URL!,
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
);
export function AgentDashboard() {
const [tasks, setTasks] = useState<AgentTask[]>([]);
const [logs, setLogs] = useState<AgentLog[]>([]);
useEffect(() => {
// Subscribe to task changes
const taskChannel = supabase
.channel('agent-tasks')
.on(
'postgres_changes',
{ event: '*', schema: 'public', table: 'agent_tasks' },
(payload) => {
setTasks(prev => {
const updated = [...prev];
const idx = updated.findIndex(t => t.id === payload.new.id);
if (idx >= 0) updated[idx] = payload.new as AgentTask;
else updated.unshift(payload.new as AgentTask);
return updated.slice(0, 50);
});
}
)
.subscribe();
// Subscribe to log stream
const logChannel = supabase
.channel('agent-logs')
.on(
'postgres_changes',
{ event: 'INSERT', schema: 'public', table: 'agent_logs' },
(payload) => {
setLogs(prev => [payload.new as AgentLog, ...prev].slice(0, 100));
}
)
.subscribe();
return () => {
supabase.removeChannel(taskChannel);
supabase.removeChannel(logChannel);
};
}, []);
// Render your dashboard UI...
}
Cela fournit un flux en direct de l'activité de l'agent. Généralement, j'ajouterais des indicateurs, des comptes de tâches, des visuels de taux d'erreur, et même un bouton "exécuter maintenant" pour les tests. Supabase Realtime est inclus dans le niveau gratuit--aucun coût supplémentaire nécessaire.
Gérer les défaillances et les cas limites
Préparez-vous--quelque chose explosera. Les API disparaissent, les limites de débit vous frappent en pleine face, ou les services renvoient juste des absurdités. Voici ce que j'ai appris sur la fabrication de systèmes qui survivent.
Réessai avec backoff exponentiel
Les colonnes attempts et max_attempts que nous avons incorporées gèrent les retries. Si une tâche échoue, elle attend dans le statut 'failed' mais peut être définie pour se réessayer manuellement ou automatiquement plus tard :
async function failTask(taskId: string, error: string) {
const { data } = await supabase
.from('agent_tasks')
.select('attempts, max_attempts')
.eq('id', taskId)
.single();
const shouldRetry = data && data.attempts < data.max_attempts;
await supabase
.from('agent_tasks')
.update({
status: shouldRetry ? 'pending' : 'failed',
error,
locked_until: null,
// Exponential backoff: 1min, 4min, 9min...
scheduled_for: shouldRetry
? new Date(Date.now() + Math.pow(data.attempts, 2) * 60000).toISOString()
: undefined,
updated_at: new Date().toISOString(),
})
.eq('id', taskId);
}
Disjoncteurs pour les API externes
Quand les API externes chancellent, les retries immédiats gobent les retries rapidement. Gardez une trace des taux d'échec dans Supabase, et vous pouvez arrêter les agents si les choses semblent sombres :
async function checkCircuitBreaker(service: string): Promise<boolean> {
const fiveMinutesAgo = new Date(Date.now() - 300000).toISOString();
const { count } = await supabase
.from('agent_logs')
.select('*', { count: 'exact', head: true })
.eq('level', 'error')
.ilike('message', `%${service}%`)
.gte('created_at', fiveMinutesAgo);
return (count ?? 0) < 10; // Trip if more than 10 errors in 5 min
}
Analyse des coûts et optimisation
C'est ici que nous parlons franchement. Quel est le coût d'une application agent de production en 2026 ?
| Composant | Niveau gratuit | Production typique | Utilisation intensive |
|---|---|---|---|
| Vercel Pro | - | $20/mo | $20/mo + usage |
| Supabase Pro | - | $25/mo | $25/mo + usage |
| OpenAI (GPT-4o-mini) | - | $30-80/mo | $200+/mo |
| Anthropic (Claude 3.5 Haiku) | - | $20-50/mo | $150+/mo |
| Total | ~$0 (dev) | $95-175/mo | $395+/mo |
Ces frais LLM ? Ils dirigent le spectacle. Voici comment vous gardez un contrôle sur eux :
- Utilisez des modèles plus petits quand c'est possible. GPT-4o-mini et Claude 3.5 Haiku gèrent la plupart des tâches à une fraction du coût de leurs plus grands cousins.
- Mettez en cache avant de vous tourner vers l'API. Supabase peut stocker les réponses du LLM, réduisant les nouveaux appels API.
- Batch, batch, batch. Au lieu d'un appel API par tâche, regroupez les tâches similaires et envoyez-les ensemble.
- Limites de tokens ? Oui, s'il vous plaît. Définissez toujours
maxTokenslors de vos appels AI SDK--prévenez la génération effrénée.
Modèles de déploiement en production
Une fois que vous vous préparez au déploiement, plusieurs choses sont critiques :
Séparation des environnements. Profitez de la création de branches Supabase (Pro nécessaire) pour maintenir des bases de données distinctes pour le staging et la production. Associez les déploiements d'aperçu Vercel avec les branches Supabase pour l'isolation complète.
Surveillance. L'observabilité de Vercel fournit l'historique d'exécution des crons et les journaux des fonctions. Associez ceci avec une vérification d'intégrité Supabase :
SELECT
agent_type,
status,
COUNT(*) as count,
AVG(EXTRACT(EPOCH FROM (completed_at - started_at))) as avg_duration_seconds
FROM agent_tasks
WHERE created_at > NOW() - INTERVAL '24 hours'
GROUP BY agent_type, status
ORDER BY agent_type, status;
Gestion des secrets. Protégez vos clés API avec les variables d'environnement Vercel, ne les codez jamais en dur. Utilisez la clé de rôle de service uniquement côté serveur avec Supabase, tout en gardant la clé anon côté client.
Si vous avez besoin d'aide pour mettre en place des systèmes comme celui-ci, notre équipe a livré plusieurs applications alimentées par des agents utilisant exactement cette pile. Consultez nos capacités headless CMS development et Next.js development, ou contactez-nous pour discuter de votre projet.
FAQ
Vercel Cron peut-il gérer les tâches d'agent haute fréquence ?
Vercel Cron peut gérer des intervalles aussi courts que 1 minute sur le plan Pro. La plupart des tâches d'agent conviennent aux cycles de 5-15 minutes. Vous avez besoin de plus vite ? Considérez les Webhooks de base de données Supabase ou passez à Inngest pour les actions événementielles.
Comment puis-je empêcher le traitement dupliqué des tâches avec cron ?
C'est là que PostgreSQL's FOR UPDATE SKIP LOCKED brille dans votre requête de saisie de tâche. C'est votre filet de sécurité même si les timings cron se chevauchent, assurant que chaque tâche est uniquement réclamée. locked_until ajoute une couche de sécurité si des catastrophes en cours d'exécution surviennent.
Supabase est-il fiable pour les charges de travail d'agent en production ?
Absolument. Supabase Pro fonctionne sur des instances Postgres dédiées avec sauvegardes automatisées et un SLA de 99,9% de disponibilité. En fait, pour ce système de file d'attente de tâches, Postgres est plus que qualifié--capable de gérer l'accès concurrent et les requêtes complexes facilement.
Quel est le coût pour exécuter les agents IA en production ?
Généralement, le traitement de 5 000 à 10 000 tâches quotidiennement vous coûtera entre $95-175/mois (Vercel Pro + Supabase Pro) plus $30-80/mois pour les appels API LLM utilisant des modèles comme GPT-4o-mini. La couche variable est votre coût LLM--en dépendance de la complexité des tâches et de l'utilisation des tokens.
Dois-je utiliser LangChain ou le Vercel AI SDK pour la logique de l'agent ?
En 2026, le SDK IA de Vercel (v4.x) couvre la plupart des besoins des agents nativement--utilisation d'outils, raisonnement multi-étapes, sorties structurées, et streaming. LangChain devient utile quand vous plongez dans les modèles avancés de chaîne de pensée, les configurations RAG, ou les intégrations d'outils spécialisés. Pour cette pile, moins de complexité avec le SDK IA règne suprêmement.
Puis-je utiliser Astro au lieu de Next.js pour ce modèle ?
Astro peut gérer les routes API déclenchées par cron, mais vous manquez les optimisations de Vercel, y compris la configuration cron et les délais d'expiration plus longs. Si votre tableau de bord préfère le contenu lourd, faible interactivité, Astro convient au frontend. Restez avec Next.js pour votre backend d'agent.
Comment puis-je surveiller les performances et les défaillances des agents ?
Mélangez trois couches : les journaux de Vercel pour l'insight au niveau de l'exécution, la table agent_logs dans Supabase pour le suivi des journaux au niveau de l'application, et Supabase Realtime pour la surveillance du tableau de bord dynamique. Établissez des vérifications d'intégrité pour les défaillances, les temps d'exécution, et la longueur de la file d'attente. Vercel se synchronise de façon transparente avec les services d'alerte comme PagerDuty et Slack.
Que se passe-t-il quand mes tâches d'agent dépassent le délai d'expiration de la fonction Vercel ?
Sur Vercel Pro, vous avez un plafond de 300 secondes. Si les tâches dépassent souvent cela, envisagez de les diviser en sous-tâches réduites sur plusieurs cycles cron. Par exemple, divisez un processus de contenu en tâches "fetch", "analyze", et "generate". Ou, explorez les Edge Functions Supabase pour les exécutions prolongées--elles ont une limite de 150 secondes et peuvent être déclenchées selon les besoins.