Accueil / Articles / Changement d’architecture backend : des API fixes vers les systèmes d’agents IA

Changement d’architecture backend : des API fixes vers les systèmes d’agents IA

Découvrez comment la conception backend évolue lorsque des agents IA remplacent les routes API fixes, à travers des exemples de code concrets, des cas d’usage et des compromis pratiques à prendre en compte.

1026 mots

Pendant longtemps, l’ingénierie backend a suivi un modèle simple : on définit des routes, le client les consulte, et le serveur renvoie une réponse.

POST /create-order
GET /user/123

C’est ordonné, facile à comprendre et s’échelle bien en production.

Cependant, il y a un problème :

Toute voie possible à travers l’application doit être planifiée à l’avance.

Lorsqu’un utilisateur tente quelque chose en dehors de ce schéma, la solution reste toujours la même : écrire plus de code, ajouter davantage de routes, multiplier les conditions.

Imaginons maintenant un type de requête différent. Un utilisateur tape simplement :

« Trouvez-moi le vol le moins cher pour demain et réservez-le. »

Il n’existe pas d’endpoint unique capable de gérer cette tâche. C’est là que le modèle traditionnel commence à montrer ses limites.

Comment nous construisons les backends aujourd’hui (APIs)

Examinons un scénario concret.

Flux d’e-commerce (basé sur API)

// Step 1: Get product
GET /products/:id
// Step 2: Add to cart
POST /cart// Step 3: Create order
POST /order// Step 4: Payment
POST /payment

Chacune de ces étapes est :

  • définie à l’avance
  • contrôlée explicitement
  • incorporée directement dans le flux

Même la logique derrière ces routes a tendance à ressembler à ceci :

if (user.isLoggedIn) {
  createOrder()
} else {
  throw new Error("Unauthorized")
}

Cette approche fonctionne bien, mais elle repose sur une hypothèse implicite : il faut déjà connaître tous les chemins que l’utilisateur pourrait emprunter au sein du système.

Création de la même fonctionnalité avec un agent

Au lieu de décrire chaque étape, on décrit le résultat souhaité.

"Commander l’iPhone le moins cher sous 70 000 ₹"

Avec ce changement, le backend prend une forme différente.

Étape 1 : Définir les outils (vos APIs)

const tools = [
  {
    name: "search_products",
    description: "Search products by name and filters",
  },
  {
    name: "create_order",
    description: "Create order for a product",
  },
  {
    name: "make_payment",
    description: "Process payment",
  }
]

Examinez de près ce qui a changé.

Les mêmes API sous-jacentes sont toujours présentes — elles sont simplement exposées en tant qu’outils appelables.

Étape 2 : Laisser l’agent décider

Avec une configuration comme Ollama associée à Gemma 4 :

const userGoal = "Buy the cheapest iPhone under 70000"
const response = await agent.run({
  goal: userGoal,
  tools
})

En réalité, l’agent résout le problème par lui-même :

  1. Appelle search_products
  2. Filtre selon le prix
  3. Sélectionne la meilleure option
  4. Appelle create_order
  5. Déclenche make_payment

Aucune séquence fixe n’a été écrite manuellement.

La différence fondamentale, expliquée simplement

Voici la distinction résumée :

APIs :

Vous écrivez :

Step 1 → Step 2 → Step 3

Agents :

Vous écrivez :

Goal → System figures out steps

C’est l’essence de ce changement.

Où cela apporte réellement des avantages

Examinons des scénarios concrets plutôt que des abstractions.

1. Automatisation du service client

Au lieu d’interfaces distinctes telles que :

  • /get-order
  • /cancel-order
  • /refund

on laisse le système gérer une seule requête comme par exemple :

User: "My order is late, cancel it and refund"

L’agent procède alors comme suit :

  • vérifie l’état de la commande
  • la annule
  • déclenche le remboursement

2. Outils de développement internes

Par exemple :

"Vérifier pourquoi la latence de l’API a augmenté au cours de la dernière heure"

L’agent est capable de :

  • interroger les journaux
  • vérifier les métriques
  • suggérer le problème probable

3. Plateforme de recherche de personnes disparues

Ce cas mérite d’être mis en évidence.

">Vérifier si cette personne a été déclarée disparue"

  • appeler un service de correspondance d’images
  • vérifier une base de données
  • retourner toute correspondance trouvée

Aucune de ces étapes ne nécessite une séquence API rigide et prédéfinie.

À quoi ressemble l’architecture

À un niveau général, c’est simple :

User → Agent → Tools → Your Existing Backend

Vos APIs existantes ne disparaissent pas — vous les enveloppez simplement afin qu’un agent puisse les appeler selon les besoins.

Une implémentation de exemple (style Node.js)

app.post("/tools/create_order", async (req, res) => {
  const { productId } = req.body
  const order = await createOrder(productId)
  res.json(order)
})

L’agent invoque simplement cet endpoint en tant qu’un de ses outils disponibles.

Les véritables défis auxquels vous serez confronté

Cette approche n’est pas sans difficultés.

1. Le débogage devient plus difficile

Avec les APIs traditionnelles, vous déboguez votre propre code.

Avec les agents, vous devez souvent déterminer pourquoi le modèle a choisi une action particulière.

2. Le comportement n’est pas toujours cohérent

La même entrée peut produire un résultat différent à chaque fois.

3. Les dépenses peuvent augmenter rapidement

4. La sécurité nécessite plus d’attention

Que cela signifie pour vous en tant que développeur backend

N’allez pas compliquer les choses inutilement.

Continuez à développer des API

Celles-ci restent la base sur laquelle tout le reste repose.

Concevez vos API comme des outils appelables

Pensez en termes de définition d’outil :

{
  "name": "get_user_orders",
  "description": "Fetch all orders for a user"
}

Créez un petit projet d’agent

Choisissez quelque chose de gérable, comme un assistant pour les commandes, un analyseur de logs ou un chatbot interne. Des outils tels que Ollama ou Gemma 4 constituent un bon point de départ.

Changement de perspective vers des objectifs, et non vers des flux fixes

Ce changement de mentalité est plus important que le choix d’un outil spécifique.

Pensée finale

Les API donnent de la structure aux systèmes backend. Les agents leur confèrent de la flexibilité. L’avenir ne réside pas dans l’opposition API contre agent — il s’agit d’API associées à des agents. Si vous savez déjà comment créer des API solides, vous êtes déjà à moitié du chemin. Commencez par vous demander : et si votre backend pouvait déterminer lui-même les étapes à suivre ?

Lectures complémentaires

  • Que signifient les avertissements sur la sécurité de l’IA de anciens chercheurs d’Anthropic pour les développeurs — Cet article explique pourquoi les avertissements des chercheurs concernant les risques liés à l’IA sont importants pour les développeurs du quotidien, et comment l’autonomie des agents ainsi que les écarts d’alignement devraient influencer les habitudes de sécurité pratiques.