IA agentique. bla bla

 Actuellement, l’un des principaux obstacles à la réalisation du plein potentiel des

agents d’IA réside dans leur incapacité à communiquer et à collaborer efficacement entre eux.

L’intégration des différents outils et plateformes au sein de l’écosystème de l’IA reste un processus précaire, complexe et souvent artisanal, caractérisé par un manque de standardisation et d’automatisation

Orchestration et coordination

À mesure que les systèmes d'IA prennent de l'ampleur, ils intègrent souvent de nombreux agents dotés de capacités diverses. Il devient de plus en plus difficile de gérer ces interactions et de s'assurer qu'elles fonctionnent harmonieusement.

Les cadres d'agents offrent un environnement structuré qui permet d'orchestrer les activités des agents, de définir leurs rôles et responsabilités et d'améliorer la communication.

Modularité et réutilisation

Les cadres d'agents favorisent une approche modulaire du développement de l'IA, où les agents sont conçus et mis en œuvre comme des composants indépendants. Cette modularité permet une meilleure organisation du code et la réutilisation des modules d'agents dans différents projet

définitions assez bien faites :

Agentic AI vs AI Agents: Key Differences Explained

Design patterns

Hybrid GraphRAG (Standard de fait) : Évolution du RAG classique combinant bases vectorielles et Graphes de Connaissances. Indispensable pour capturer les relations complexes entre entités financières (ex: structures de holdings, liens inter-marchés) et éliminer les hallucinations structurelles.

Hierarchical Multi-Agent (Orchestrateur/Superviseur) : Un pattern "Microservices" pour l'IA. Un agent superviseur décompose une requête (ex: "Analyse ce dossier de crédit") et délègue à des agents spécialisés (Risque, Compliance, ESG). Cela permet une isolation des logs et un débogage granulaire.

Evaluator-Optimizer (Boucle de critique) : Un pattern de contrôle où un agent "Critique" valide ou rejette le travail d'un agent "Générateur" selon des règles métiers strictes avant toute sortie SI. Essentiel pour la conformité réglementaire (ex: MiFID III, AI Act).

Model Routing & SLM Distillation (Efficiency Pattern) : Optimisation des coûts (FinOps) et de la latence. Le SI route les tâches simples vers des Small Language Models (SLM) spécialisés et locaux, ne sollicitant les LLM massifs que pour le raisonnement de haut niveau.

Persistent Memory & Cognitive State : Gestion de l'état long terme. Permet à un agent de "se souvenir" des interactions passées et du contexte client sur plusieurs mois, dépassant les limites de la fenêtre de contexte éphémère.

Gateway 

"Attention"

Ne pas négliger le NLP pour des taches simples et directes 

L’ALTERNATIVE NLP :

QUAND LE PETIT BAS LE GÉANT

Si les LLM (Large Language Models) occupent tout l'espace médiatique, ils ne sont

qu'une branche d'une discipline plus vaste ; le NLP (Natural Language Processing).

Là où un LLM est un couteau suisse géant, le NLP classique regroupe des outils

chirurgicaux spécialisés. Quelle différence concrète ? Un LLM (modèle généraliste)

est "monstre" (milliards de paramètres) qui a tout appris pour savoir tout faire ;

discuter, coder, traduire, inventer. Inconvénient ; il est lourd, lent et gourmand en

VRAM. En revanc un NLP classique (modèle spécialisé) est plus compact et entraîné

pour une seule tâche (par exemple en extraire uniquement les prix dans 10 000

factures). L’avantage, il est minuscule, c’est foudre de guerre en vitesse et tourne

sur un simple processeur. Quand privilégier le NLP plutôt que le LLM ? Pour détecter

des noms propres, des lieux ou des organisations dans un texte (tâche de Named

Entity Recognition), un petit modèle NLP est souvent plus fiable et moins sujet

aux hallucinations. Mais pour le traitement de masse, par exemple si vous devez

classer 50 000 commentaires clients en "positif" ou "négatif", un modèle NLP fera

le travail en quelques secondes là où un LLM mettra des minutes et chauffera votre

GPU pour rien.

MCP

Magentic illustre ce pattern : un agent manager coordonne

un researcher (web search) et un coder (code interpreter),

agrège leurs outputs, et décide de poursuivre ou terminer.

L’agent dispose alors d’une URL REST publique (avec

authentification), metrics Azure Monitor (latence, erreurs,

tokens), logs Application Insights, et auto-scaling basé sur la

charge.

Guardrails et Responsible AI

Microsoft annonce des fonctionnalités de Responsible AI en

intégration : task adherence (vérifier que l’agent reste dans

son rôle), prompt shields (détecter les injections), PII detec-

tion (masquer données sensibles). Ces guardrails s’appli-

quent via IntelligenceOptions ou policies Azure AI Foundry.

Memory et State Management

Les agents peuvent maintenir une mémoire conversationnelle

via les threads persistants. En Python, agent.get_new_thread() crée

un contexte isolé. À l’inverse, la réutilisation d’un thread exis-

tant facilite le traitement des questions de suivi (follow-up

questions). Azure AI agents stockent ces threads côté cloud,

tandis que Semantic Kernel s’appuyait sur des threads locaux.

Avec Agent Framework, le comportement est désormais uni-

formisé : les threads locaux sont utilisés par défaut, avec une

option de stockage cloud disponible via AzureAIAgentThread.

Observabilité avec OpenTelemetry

Agent Framework se base sur des traces OpenTelemetry à

chaque appel d’agent, tool call et workflow step. Les dévelop-

peurs connectent Azure Monitor ou Grafana pour visualiser

latence, tokens consommés, erreurs. Exemple minimal :

await foreach (WorkflowEvent evt in run.WatchStreamAsync())

{

if (evt is AgentRunUpdateEvent e)

Console.WriteLine($”{e.Update.AuthorName}: {e.Update.Text}”);

}

Déploiement sur Azure AI Foundry

Le workflow typique : développer localement avec OpenAI/Azure

OpenAI, tester avec uv run python my_agent.py, puis déployer sur

Azure AI Foundry. Les agents deviennent des ressources

cloud avec endpoints REST, gestion des versions, scaling

automatique. Les samples AzureAIFoundry/Step01_Basics démon-

trent la création d’agents cloud via PersistentAgentsClient.

Le support OpenAPI permet d’enregistrer des API tierces

comme outils : spécification OpenAPI génération automa-

tique de fonctions typées appel transparent par l’agent. Le

sample openai_assistant/02_code_interpreter montre l’intégration de

code interpreter hosted (exécution Python cloud-side).

Pour déployer un agent local vers Azure :

var azureClient = AzureAIAgent.CreateAgentsClient(

azureEndpoint,

new AzureCliCredential()

);

PersistentAgent definition = await azureClient.Administration.CreateAgentAsync(

deploymentName: “gpt-4o”,

name: “CustomerSupport”,

instructions: “Vous êtes un assistant de support client”,

tools: toolDefinitions

);

AzureAIAgent cloudAgent = new(definition, azureClient);

80

Bonnes pratiques et patterns de développement

L’expérience cumulée de Semantic Kernel et AutoGen a cris-

tallisé des patterns reproductibles. Microsoft documente ces

best practices dans le guide utilisateur.

Principe de responsabilité unique : un agent = une tâche.

Éviter les agents “couteau suisse” avec 20 outils. Préférer

composer des workflows d’agents spécialisés. Exemple :

séparer SentimentAnalyzer, ContentModerator, ResponseGenerator plutôt

qu’un SocialMediaAgent monolithique.

Instructions claires et testables : les instructions sont le

contrat de l’agent. Spécifier format, contraintes, ton.

Exemple : “Vous êtes un assistant juridique. Répondez uni-

quement aux questions sur le droit français. Si autre pays,

répondez ‘Je ne traite que le droit français’. Max 200 mots.

Citez toujours l’article de loi.”

Gestion d’erreurs explicite : les tool calls peuvent échouer.

Envelopper les outils dans try/catch avec messages structurés :

@ai_function(name=”check_stock”, description=”Vérifier disponibilité produit”)

async def check_stock(product_id: str) -> str:

try:

result = await inventory_api.get(product_id)

return f”Stock disponible: {result.quantity} unités”

except APITimeout:

return “Service indisponible, réessayez dans 30 secondes”

except ProductNotFound:

return f”Produit {product_id} introuvable”

Observabilité dès le début : intégrer OpenTelemetry traces

dès le développement local avec custom spans pour les

étapes critiques.

Testing multi-niveaux : unit tests pour outils (mocks des API),

integration tests pour agents, end-to-end tests pour workflows

validant handoffs et événements.

Versioning des agents : Azure AI Foundry supporte le versio-

ning. Créer CustomerSupport_v2, tester en parallèle de v1, basculer

progressivement (canary deployment).

Sécurité et conformité : appliquer le principe du moindre pri-

vilège, utiliser Managed Identity Azure, chiffrer secrets avec

Key Vault. Les guardrails PII detection (preview) masquent

automatiquement emails/numéros de carte dans les logs.

Ces patterns, hérités de 3 ans de Semantic Kernel en produc-

tion et 2 ans d’AutoGen en recherche, donnent à Agent

Framework une maturité opérationnelle.

Cas d’usage et adoption :

de la théorie à la pratique

Les exemples d’Arafat Tehsin illustrent la polyvalence du fra-

mework. Invoice status checking : un agent répond à

“Where is my invoice #12345?” en appelant une

fonction check_invoice_status(invoice_id) et retournant le

statut. Payment approval workflow : un workflow séquentiel

avec agent validator approver notifier, chacun avec outils

dédiés (database query, email send).

Des définitions

• embeddings : les nuances ( chien, berger allemand)
• Context lenght : mémoire vive le nombre de token dont le modèle se souvient dans une seule phrase ou taille d'un document.

• LangChain a été conçu pour enchaîner des étapes les unes après les autres. C'est ce qu'on appelle un DAG (Graphe Acyclique Dirigé).

Warning

https://thenewstack.io/agentic-ai-connectivity-platform/

evaluation des agents

https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents