Créer des agents d’IA à partir de vos services et API .NET existants
Les équipes C# peuvent exposer des services .NET existants en tant qu’outils gérés pour les agents d’IA par le biais d’appels de fonction, avec les règles de contexte, de sécurité et d’observabilité nécessaires.
Sources: AI Agents Are Changing C# Development: 10 Things Every .NET Developer Should Know
La plupart des équipes .NET maîtrisent déjà les aspects complexes d’un agent IA : services typés, API HTTP, authentification, bases de données et tâches en arrière-plan. Ce qui est nouveau, c’est un modèle de langage capable de choisir quelles de ces fonctionnalités invoquer et dans quel ordre, afin d’atteindre l’objectif décrit par l’utilisateur en langage simple. Ce guide présente les concepts dont un développeur C# a besoin pour intégrer un agent dans une application existante sans perdre le contrôle sur ce que fait réellement cette application.
De la réponse aux questions à l’exécution de tâches
Un chatbot classique fonctionne en une seule interaction : l’utilisateur pose une question et le modèle répond par du texte. Un agent, quant à lui, vise un objectif précis. Il analyse ce que cet objectif exige, utilise des outils pour obtenir des informations ou effectuer des actions, examine les résultats, puis ne renvoie une réponse qu’après cela.
Imaginons un utilisateur qui souhaite savoir combien de commandes sont arrivées aujourd’hui. Un chatbot ne peut que deviner ou expliquer comment on pourrait le découvrir. Un agent disposant des bons outils peut accéder aux données des commandes, effectuer une recherche pour la journée, interpréter les chiffres, rédiger un bref résumé et le présenter sous forme de rapport. La distinction pratique est simple : les chatbots produisent des réponses, tandis que les agents effectuent du travail.
Les outils transforment un modèle en quelque chose d’utile
Un modèle de langage, à lui seul, n’a aucune idée du fonctionnement de votre application. Il ne peut pas lire votre tableau des clients ni passer une commande. Les outils constituent le pont : ce sont des opérations spécifiques que le modèle est autorisé à demander. Un ensemble typique pour un backend de commerce pourrait ressembler à ceci :
GetCustomer()
CreateOrder()
SearchProducts()
GetWeather()
SendEmail()
QueryDatabase()
Le modèle décide quand l’un d’eux est nécessaire ; votre code détermine comment il s’exécute. En C#, un outil n’a pas besoin d’être quelque chose d’exotique. Il peut s’agir d’une méthode asynchrone ordinaire dans un service que vous possédez déjà, par exemple celle qui charge un client par ID à l’aide d’un service injecté :
public async Task<Customer> GetCustomer(int id)
{
return await customerService.GetByIdAsync(id);
}
Une fois cette méthode enregistrée comme outil, l’agent peut utiliser cette capacité, tandis que son implémentation reste dans votre couche de service habituelle, bénéficiant de la même injection de dépendances, des mêmes tests et du même système d’audit que le reste du codebase. C’est ici que se rencontrent le développement d’applications courantes et le développement de l’IA.
Comment fonctionne la mise en appel de fonctions en pratique
La mise en appel de fonctions est le mécanisme qui sous-tend les outils. Le modèle ne met rien en exécution lui-même ; il émet une demande structurée pour appeler une fonction avec des arguments spécifiques, et votre application effectue l’appel.
Supposons qu’un utilisateur demande le statut de la commande 12345. En interne, le modèle en conclut qu’il manque d’informations :
I need order information.
Il demande donc à l’application hôte d’appeler une fonction en utilisant le numéro de commande comme argument :
GetOrderStatus(12345)
Votre code exécute cette demande, renvoie le résultat au modèle, qui transforme ensuite les données brutes en une réponse lisible. Pour un développeur C#, cela doit sembler familier : vous exposez une petite partie de votre application, un peu comme une API publique dont l’utilisateur est un modèle. Des noms clairs, des types de paramètres précis et de bonnes descriptions rendent les appels corrects bien plus probables.
Réutiliser les APIs que vous possédez déjà
Adopter des agents ne nécessite pas de réécrire le backend. Si votre application expose déjà des points d’entrée, ceux-ci peuvent devenir les outils de l’agent. Un service peut déjà publier une fonction de recherche de clients :
GET /api/customers/{id}
En plus des points d’entrée pour lire une commande, créer des commandes et lister les produits (la liste ci-dessous exécute les trois routes en même temps sur une seule ligne ; considérez-les comme des points d’entrée distincts) :
GET /api/orders/{id}POST /api/ordersGET /api/products
Avec cela en place, une demande telle que trouver le client qui a passé le plus de commandes ce mois-ci devient une séquence que l’agent peut planifier seul : récupérer les données du client, obtenir les informations sur les commandes, comparer les chiffres et indiquer le gagnant. L’agent n’est rien de plus qu’un autre client s’appuyant sur les fonctionnalités que vous avez déjà développées et sécurisées.
Contexte : fournir au modèle ce dont il a besoin, et non tout ce que vous possédez
Imaginez une session de travail d’une demi-heure avec un agent qui aborde votre application, son schéma de base de données, les conventions de codage de l’équipe, les règles métier, les bogues non résolus ainsi que les décisions prises au cours de la conversation. Pour rester utile, l’agent doit garder un suivi des éléments pertinents de tout cela. C’est pourquoi l’historique des conversations, la gestion du contexte, la mémoire, le retrait d’informations, les embeddings et les bases de données vectorielles reviennent constamment dans la conception des agents.
Il existe un piège facile à manquer : plus de contexte ne signifie pas automatiquement mieux. Chaque token supplémentaire entraîne des coûts et une latence plus élevés, et les informations irrelevantes affaiblissent le signal, rendant les réponses moins fiables. Une bonne conception d’agent consiste à fournir le contexte adéquat au moment où il est nécessaire, par exemple en ne récupérant que les documents correspondant à l’étape actuelle plutôt qu’en intégrant toute la base de connaissances dans chaque demande. Pour en savoir davantage sur les différences entre ces mécanismes de mémorisation, consultez notre article expliquant la mémoire, les embeddings et le RAG en IA.
Permettre aux agents de consulter les données en toute sécurité
L’accès aux données est ce qui rend les agents particulièrement attrayants pour les entreprises utilisant .NET. Un utilisateur d’entreprise peut se demander quels produits ont connu la plus forte baisse de ventes le mois dernier. Plutôt que de créer un rapport dédié à chaque question de ce type, un système basé sur des agents peut interpréter la question, déterminer quels données sont pertinentes, les consulter, analyser les résultats et expliquer ce qui a été trouvé.
L’avertissement associé à cela est sans équivoque : ne donnez jamais à un modèle un accès illimité à votre base de données. Lui permettre de générer et d’exécuter des requêtes SQL arbitraires peut entraîner des instructions destructrices, des fuites de données entre différents utilisateurs et des requêtes qui verrouillent les tables. Préférez plutôt exposer des opérations spécifiquement conçues pour un but précis, avec des paramètres validés et leurs propres contrôles d’autorisation :
GetSalesReport()
GetProductSales()
GetCustomerOrders()
Chacune de ces approches peut assurer la sécurité au niveau des lignes, limiter la taille des résultats et utiliser une connexion en lecture seule, sacrifiant un peu de flexibilité au profit d’une grande prévisibilité.
Les agents ne remplacent pas l’architecture
Une idée reçue courante est que l’ajout d’un modèle permet de relâcher les principes fondamentaux. C’est tout le contraire qui est vrai. L’injection de dépendances, la conception SOLID, le journalisation, les tests, l’authentification, l’autorisation, la gestion des erreurs, l’observabilité et une structure en couches claire sont d’autant plus importants lorsque c’est un composant non déterministe qui choisit ce qu’il faut appeler.
Le modèle mental utile consiste en une séparation des rôles : l’agent peut proposer une action, mais c’est votre application qui décide si cette action est autorisée. En bref, l’IA prend la décision, votre application en assure le contrôle. Les vérifications d’autorisation doivent se trouver dans les implémentations des outils et les services qui les soutiennent, jamais dans la requête, car une requête n’est qu’une suggestion adressée au modèle et non une règle impérative.
Les risques de sécurité se multiplient avec chaque outil
Chaque outil que vous autorisez augmente les risques d’erreurs. Un agent peut être capable de réaliser des actions telles que celles-ci :
Read customer data
Send emails
Create orders
Delete records
Call external APIs
Trois questions suivent. Que se passe-t-il lorsque le modèle commet simplement une erreur, comme la suppression du mauvais enregistrement ? Que se passe-t-il lorsque un utilisateur malveillant tente de pousser l’agent à utiliser un outil de manière abusive ? Et que se passe-t-il lorsque le contenu externe lu par l’agent, comme un e-mail ou une page web, contient des instructions cachées ? Ce dernier scénario, généralement appelé injection indirecte de prompt, constitue une catégorie d’attaques réelle et bien documentée, et non un simple exercice de pensée.
Les défenses sont principalement celles que vous connaissez déjà, appliquées de manière intentionnelle :
- Authentification et autorisation pour chaque appel à un outil, ciblées sur l’utilisateur final plutôt que sur l’agent.
- Vérification de la validité des entrées pour tous les arguments fournis par le modèle.
Pour toute action à fort impact, telle que les remboursements, les suppressions ou les messages envoyés aux clients, une étape de confirmation où une personne approuve l’action constitue souvent la meilleure assurance disponible.
Observabilité pour des flux de requêtes non linéaires
Le traitement conventionnel des requêtes est facile à tracer car il suit une ligne droite :
Request → Service → Database → Response
Un agent en exécution peut alterner entre le modèle, plusieurs outils et plusieurs backends avant de parvenir à une réponse :
User
↓
AI Model
↓
Tool
↓
API
↓
Database
↓
AI Model
↓
Another Tool
↓
Final Response
Ce type de structure est bien plus difficile à déboguer. Lorsqu’un problème survient, il faut savoir quels outils ont été appelés, pourquoi le modèle les a choisis, combien de temps chaque appel a duré, ce qui a échoué, combien d’appels au modèle étaient nécessaires pour l’exécution et quel a été le coût total de l’opération. Il convient de traiter chaque exécution comme un suivi contenant des segments pour les appels au modèle et aux outils, en enregistrant les arguments et le nombre de tokens ainsi que les temps d’exécution ; sinon, il est presque impossible de reproduire une réponse incorrecte.
Pourquoi les développeurs C# partent avec un avantage
Les développeurs familiers avec C# et .NET ne partent pas de zéro. Les interfaces et les classes, les API HTTP, les conteneurs DI, le code asynchrone, les bases de données, l’authentification, les services en arrière-plan hébergés et le déploiement cloud constituent précisément les éléments sur lesquels sont construits les systèmes d’agents. Il ne reste qu’une courte liste de nouveaux concepts, qui s’enchaînent plus ou moins dans cet ordre :
LLMs
↓
Prompting
↓
Function Calling
↓
Tools
↓
RAG
↓
Agents
↓
Multi-Agent Systems
Il n’est pas nécessaire de tout absorber d’un coup ; commencez petit.
Une architecture de référence
Un design minimal place l’agent au centre, avec quelques outils qui se connectent à vos propres services, à la base de données et à une API de recherche externe, les résultats revenant ensuite via l’agent jusqu’à l’utilisateur :
User
↓
AI Agent
↓
┌───────┼────────┐
↓ ↓ ↓
API Tool DB Tool Search Tool
↓ ↓ ↓
.NET Database External API
└───────┼────────┘
↓
Agent Result
↓
User
La propriété clé de cette configuration est que l’agent ne touche jamais directement vos systèmes. Chaque chemin passe par un outil géré par votre application .NET, ce qui permet de centraliser le contrôle d’accès, la validation et l’journalisation dans un endroit que vous savez déjà comment maintenir.
Un parcours d’apprentissage pratique
Pour un développeur C# qui souhaite se lancer dans le domaine de l’IA, une progression logique serait la suivante :
- Comprendre les LLM. Apprenez comment se comportent les grands modèles de langage, en quoi ils sont performants et où ils échouent, comme avec des réponses convaincantes mais fausses.
Un agent de support client constitue un premier projet concret idéal, car il met en œuvre tous les aspects nécessaires. Il peut rechercher l’information du client, examiner la commande, vérifier l’état de livraison, ouvrir un ticket et y répondre :
Search customer
↓
Check order
↓
Check delivery status
↓
Create support ticket
↓
Respond to customer
Chaque étape correspond à un outil spécifique, et les étapes ayant des effets secondaires sont des candidats évidents pour des règles d’approbation.
Points clés
- Un agent est un système logiciel : un modèle associé à des outils, des données, une logique d’application, des mesures de sécurité et un suivi, et non un remplaçant pour l’un d’eux.
- Exposez les fonctionnalités sous forme d’outils ciblés et validés ; ne donnez jamais un accès direct à la base de données ou une API sans restrictions.
- Gérez l’autorisation dans le code, afin que l’application contrôle ce que propose l’agent.
- Préservez un contexte adapté à chaque étape plutôt que de le maximiser.
- Tracez chaque exécution du début à la fin afin que les échecs et les coûts puissent être expliqués.