Qu'est-ce qu'un agent IA ?

Un agent IA est un système piloté par un LLM qui poursuit un objectif en boucle : il raisonne, appelle un outil, observe le résultat et recommence. Un simple appel de LLM répond et s’arrête ; un agent enveloppe cet appel dans une boucle de contrôle avec des outils (des fonctions qu’il peut invoquer), de la mémoire (de l’état d’une étape à l’autre) et assez d’autonomie pour choisir sa propre séquence d’actions. Le basculement décisif pour un développeur backend est le fait le plus simple et le moins dit sur les agents : les « outils » d’un agent sont vos endpoints backend — quand un agent « utilise un outil », il appelle une API que vous avez écrite, ce qui fait de votre backend, et non du prompt, l’endroit où la sécurité se joue réellement.

Points clés

Comment fonctionne la boucle de raisonnement (ReAct) d’un agent IA

OBJECTIF : "Remboursez ma dernière commande et envoyez-moi la confirmation"

  ┌──────────────────────────────────────────────────────────┐
  │ 1 REASON   modèle : "il me faut la dernière commande"    │
  │ 2 ACT      appelle outil : find_orders(user, last=1)     │
  │ 3 OBSERVE  résultat : commande #1187, 42 $, livrée       │
  │ 4 REASON   "éligible — on rembourse"                     │
  │ 5 ACT      appelle outil : refund_order(1187)            │◄─ chaque ACT atteint
  │ 6 OBSERVE  résultat : remboursée                         │   VOTRE backend
  │ 7 REASON   "maintenant, envoyer l'email à l'utilisateur" │
  │ 8 ACT      appelle outil : send_email(...)               │
  │ 9 REASON   "terminé" → réponse finale                    │
  └──────────────────────────────────────────────────────────┘

Le modèle n'exécute jamais un outil. Il en DEMANDE un (nom + arguments) ;
votre code l'exécute et renvoie le résultat pour l'étape de raisonnement suivante.

Les outils de cette boucle, côté backend — à portée restreinte, soumis aux permissions, exécutés sous l’identité de l’utilisateur :

// JavaScript — Cloud Code (cloud/main.js)
// An agent's "tool" is a backend function — scoped, permissioned, auditable
Parse.Cloud.define('refundOrder', async (req) => {
  // Runs under the CALLING USER's session — ACLs gate everything.
  // A hijacked agent can't exceed what this user may already do.
  const asUser = { sessionToken: req.user.getSessionToken() };
  const order = await new Parse.Query('Order').get(req.params.orderId, asUser);
  // ACLs apply via the session token: not your order → this throws, agent or not
  if (order.get('amount') > 100) throw 'Refunds over $100 need human approval';
  order.set('status', 'refunded');
  await order.save(null, asUser);
  return { refunded: order.id }; // the tool result the model reasons over next
});
// The backend, not the prompt, is the security boundary.

// Flutter / Dart — Back4app Flutter SDK
// The agent loop runs server-side; the tools it may call are YOUR functions
final result = await ParseCloudFunction('runAgent')
    .execute(parameters: {'goal': 'Refund my last order and email me'});
print(result.result);
// The agent reasoned, chose the refundOrder tool, and called it —
// but the ACLs on Order decided whether it was ALLOWED to succeed.

// iOS / Swift — Back4app Swift SDK
// The agent loop runs server-side; the tools it may call are YOUR functions
let result: [String: Any] = try await Cloud.run(
    name: "runAgent",
    parameters: ["goal": "Refund my last order and email me"])
print(result)
// The agent reasoned, chose the refundOrder tool, and called it —
// but the ACLs on Order decided whether it was ALLOWED to succeed.

// Android / Kotlin — Back4app Android SDK
// The agent loop runs server-side; the tools it may call are YOUR functions
val params = mapOf("goal" to "Refund my last order and email me")
val result = ParseCloud.callFunction<Map<String, Any>>("runAgent", params)
println(result)
// The agent reasoned, chose the refundOrder tool, and called it —
// but the ACLs on Order decided whether it was ALLOWED to succeed.

Les quatre composants essentiels d’un agent IA

La décomposition canonique est modèle + planification + mémoire + usage d’outils, mais la version opérationnelle est plus simple : un modèle raisonne, des outils agissent (et ce sont des fonctions backend), la mémoire conserve l’état — à court terme dans la fenêtre de contexte, à long terme dans une base de données ou un vector store — et la boucle d’orchestration relie le tout, sur le modèle du pattern ReAct qui entrelace raisonnement et action.

Agent vs. chatbot vs. appel de LLM vs. workflow

La distinction qui compte le plus, et que presque aucun glossaire ne trace : un workflow est une orchestration par des chemins de code prédéfinis ; un agent laisse le modèle diriger son propre chemin. Les recommandations d’Anthropic sont sans détour sur la conséquence — la plupart des tâches qui semblent exiger un agent sont mieux servies par un workflow déterministe, et vous n’ajoutez de l’agentivité que lorsque le chemin ne peut vraiment pas être scripté.

Fiabilité : les erreurs se cumulent à la baisse

La section honnête que les pages des éditeurs évitent. Les agents sont impressionnants à l’étape et fragiles à la chaîne, parce que le succès se multiplie : si chaque étape réussit avec une probabilité p, une tâche de n étapes réussit avec une probabilité d’environ pⁿ.

succès par étape   10 étapes   20 étapes
     95 %            ~60 %       ~36 %
     90 %            ~35 %       ~12 %
     85 %            ~20 %        ~4 %

Une démo qui réussit une étape impressionnante n'est pas un système qui en réussit vingt.
En conditions réelles, un agent multi-étapes et multi-systèmes réussit souvent 20–40 %.

Ce calcul dicte le playbook de production : gardez les chaînes courtes, vérifiez les résultats entre les étapes plutôt que de leur faire confiance, placez les actions irréversibles (envoyer, supprimer, débiter, publier) derrière une validation humaine, et plafonnez la boucle avec des limites d’étapes et de coût, pour qu’un agent désorienté échoue à bas prix plutôt qu’à prix d’or. La fiabilité n’est pas une propriété du modèle dont vous attendez l’amélioration ; c’est une architecture que vous imposez.

La surface de sécurité

Un agent qui peut agir peut être manipulé pour agir, ce qui en fait une surface d’attaque réellement nouvelle. La prompt injection transforme des instructions présentes dans l’entrée du modèle en actions réelles — et la variante dangereuse est indirecte : une page web, un e-mail ou un ticket de support empoisonnés que l’agent lit peuvent porter des instructions qu’il exécute ensuite avec vos identifiants. L’adjoint confus (confused deputy) est la forme que prennent les dégâts : un agent doté de permissions larges, manipulé pour en abuser au profit d’un attaquant. Les parades relèvent d’une vieille discipline de sécurité, braquée sur un nouvel acteur — des identifiants à moindre privilège, limités à l’utilisateur (ne donnez jamais à l’agent plus que ce dont dispose déjà l’utilisateur de la tâche), des outils refusés par défaut et à portée étroite, du sandboxing et une validation humaine sur tout ce qui est irréversible. Le cadrage le plus important de tous : c’est le backend, et non le prompt, qui constitue la frontière de sécurité. Un prompt peut être injecté ; une vérification de permissions côté serveur ne se laisse pas convaincre de cesser de s’appliquer.

Concevoir des outils qu’un agent ne peut pas détourner

Parce que les outils sont votre backend, la conception d’outils est de la sécurité backend avec le volume à fond. Rendez chaque outil idempotent quand c’est possible (un remboursement retenté ne doit pas rembourser deux fois), à portée étroite (une action claire, pas un accès brut à la base de données), soumis aux permissions (il s’exécute sous l’identité de l’utilisateur et ses ACL s’appliquent) et clair dans son schéma — les descriptions que le modèle lit pour décider s’il doit appeler un outil et comment méritent autant de soin que vos prompts, car une description d’outil vague est un bug que le modèle finira par trouver. Exposez des actions, pas des tables : refund_order(id) avec ses propres vérifications, jamais run_sql(query).

Cas d’usage courants

• Opérations client — un agent qui résout une demande de support de bout en bout via des outils soumis aux permissions, avec validation humaine sur les remboursements et les annulations.
• Assistants de code — lire un dépôt, lancer des outils, itérer vers une modification soumise à revue.
• Recherche et synthèse — récupération et résumé en plusieurs étapes, quand le chemin n’est pas connu à l’avance.
• Workflows de données avec discernement — des étapes qui exigent du raisonnement entre elles, pas seulement un pipeline figé.
• Planification et coordination — des objectifs qui traversent plusieurs systèmes, chacun atteint par un outil à portée restreinte.

Devriez-vous construire un agent ? Matrice de décision

Limites et trade-offs

• L’autonomie échange de la fiabilité contre de la capacité. La liberté qui permet à un agent de traiter des objectifs ouverts est celle-là même qui fait se cumuler les erreurs — bornez-la délibérément.
• Les boucles coûtent de l’argent et du temps. Chaque itération, ce sont des appels de modèle en plus ; les agents sont par conception plus lents et plus chers qu’un appel unique — plafonnez et surveillez les deux.
• Le non-déterminisme résiste aux tests. Un workflow se teste unitairement ; un agent s’évalue statistiquement, sur de nombreuses exécutions, parce qu’une même entrée peut emprunter des chemins différents.
• Le rayon d’impact, ce sont vos identifiants. Un agent n’est jamais plus sûr que la permission la plus étroite accordée à ses outils ; un accès trop large est l’incident qui attend son heure.
• Impressionnant ≠ fiable. Une démo convaincante est une chaîne chanceuse ; la production, c’est le travail ingrat des garde-fous, des validations et des chemins courts.

Les agents IA sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. La thèse « les outils sont des fonctions backend » constitue toute l’intégration : les outils d’un agent sont des fonctions Cloud Code, et comme elles s’exécutent sous la session de l’utilisateur appelant, les ACL et les permissions au niveau de la classe de la plateforme filtrent chaque lecture et chaque écriture que l’agent tente — comme le montrent les onglets de code, un agent détourné ou victime de prompt injection ne peut pas dépasser les permissions de l’utilisateur lui-même, parce que le rayon d’impact de l’adjoint confus est plafonné par le contrôle d’accès plutôt que par la bonne conduite du modèle. Le reste en découle : exposez des actions à portée restreinte (refundOrder), pas des données brutes ; gardez la clé du modèle côté serveur ; standardisez la surface d’outils avec MCP quand plusieurs agents la partagent ; et laissez le backend dire non. L’agent propose ; le backend dispose — et c’est exactement là que doit résider la sécurité d’un système autonome.