SaaS Agent-Native : Construire votre app pour l'ère des agents

Le chatbot greffé est une impasse

En 2024-2025, des centaines de SaaS ont ajouté "l'IA" en collant une chatbox sur le côté. Résultat : une interface qui fait son travail, et un assistant qui refait le même travail dans son coin. Les deux dérivent au fil des releases.

Une feature ship dans l'UI que l'agent ne voit jamais. L'agent apprend un nouveau capability qu'aucun bouton n'expose. Vous construisez chaque fonctionnalité deux fois — une pour l'humain, une pour le modèle — et passez le reste de la vie du produit à empêcher les deux copies de diverger.

Pour une équipe déjà noyée sous les PRs générées par l'IA, ajouter une surface agent parallèle sur un codebase UI-first double la surface de review au pire moment possible.

Le constat est clair : le chatbot-on-the-side est un portage, pas une architecture native. Comme les apps mobiles qui étaient des sites responsive déguisés, ça marche au début, puis ça coûte cher.

L'architecture actions : le pattern qui change tout

La solution est architecturale et tient en une abstraction : les actions.

Définissez votre application comme un ensemble d'actions métier. Pas de routes, pas de controllers, pas de endpoints — des actions. Des blocs discrets de logique comme "créer une facture", "ajouter un collaborateur", "exporter les données".

// actions/invoice.ts — une seule définition, deux surfaces
export const createInvoice = defineAction({
  input: z.object({
    clientId: z.string(),
    items: z.array(invoiceItemSchema),
    dueDate: z.date(),
  }),
  execute: async ({ clientId, items, dueDate }) => {
    // Validation, calcul TVA, persistence...
    const invoice = await db.invoice.create({ clientId, items, dueDate });
    await sendNotification(invoice.id);
    return invoice;
  },
});

Le frontend appelle ces actions :

"use server";
import { createInvoice } from "@/actions/invoice";

export default function InvoiceForm() {
  return (
    <form action={createInvoice}>
      {/* ...form fields... */}
      <button type="submit">Créer la facture</button>
    </form>
  );
}

L'agent appelle les mêmes actions comme ses tools :

// agent/tools.ts
import { createInvoice } from "@/actions/invoice";
import { tool } from "ai";

export const invoiceTools = {
  createInvoice: tool({
    description: "Crée une nouvelle facture pour un client",
    parameters: createInvoice.input,
    execute: createInvoice.execute,
  }),
};

Construisez une feature une fois, et vous obtenez le bouton ET la capacité agent ensemble.

Ce que ça change concrètement

Plus de dérive UI vs agent

Si chaque capability est une action, et que les deux surfaces (UI et agent) s'exécutent sur les mêmes actions, elles restent verrouillées ensemble. Il n'y a qu'une seule source de vérité pour ce que l'app peut faire. Construisez une feature dans le frontend, et l'agent peut l'utiliser immédiatement.

Zéro duplication

Plus besoin de réécrire la logique métier dans un format compréhensible par l'agent, puis de la maintenir. Une action = une implémentation. Les mises à jour de règles métier, de validation, ou de calcul sont automatiquement propagées.

Review simplifiée

L'agent propose une modification, vous la voyez s'appliquer dans l'interface réelle, et vous l'approuvez — ou pas. Pas de double review (une pour le code, une pour l'agent). Les actions sont typées, documentées, et testables comme le reste du code.

L'apprentissage collectif

Quand un marketeur corrige le headline d'une landing page générée par l'agent, il peut aussi corriger le processus qui a produit cette page. Le savoir reste dans l'application, pas dans un historique de chat. La prochaine campagne part de ce workflow amélioré.

Comment passer à l'action dès aujourd'hui

Étape 1 : Audit de vos actions métier

Listez toutes les opérations que votre application permet : CRUD, workflows, exports, notifications, calculs. Chaque item de cette liste est une action candidate.

Étape 2 : Extraction de la couche actions

Séparez la logique métier de l'interface. Créez un dossier actions/ ou use-cases/ avec une action par fichier. Chaque action reçoit des inputs typés, exécute la logique, et retourne un résultat.

Étape 3 : Exposition aux deux surfaces

• Frontend : appelez les actions via Server Actions (Next.js), tRPC mutations, ou un bus d'actions dédié.
• Agent : exposez les mêmes actions comme des tools MCP (Model Context Protocol) ou des endpoints API compatibles avec le framework agent de votre choix (Vercel AI SDK, LangChain, etc.).

Étape 4 : Déploiement continu

À chaque nouvelle feature, l'action est définie une fois. Le bouton et la capacité agent arrivent ensemble. Fini le "on ajoutera l'IA plus tard" — l'IA est un citoyen de première classe du système.

Le moment est venu

La vague mobile-native a enterré les apps qui n'étaient que des sites responsive. La vague agent-native va enterrer les SaaS qui ne sont que des UI avec un chatbot greffé.

Construisez agent-native dès aujourd'hui, ou reconstruisez dans 18 mois.

Conclusion

L'architecture agent-native n'est pas un concept futuriste — c'est une décision technique que vous pouvez prendre dès le premier commit. Le pattern des actions unifiées est simple, testable, et s'intègre nativement avec les frameworks modernes (Next.js Server Actions, tRPC, MCP).

Chez Kody, on accompagne les équipes SaaS à concevoir cette architecture dès le jour 1. Pas de chatbot greffé, pas de logique dupliquée — une vraie application où l'humain et l'agent sont des citoyens égaux.

Prêt à construire votre SaaS agent-native ? On en parle.