Pourquoi Python ?

Durée indicative : environ 12 min.

Le problème que ce module résout

Ouvrez une offre de mission « agents IA », un livre récent sur le sujet ou un tutoriel populaire : le code est très souvent en Python. Pour un développeur .NET, le message implicite est clair — l'IA se passe ailleurs, et il faudra changer de langage, d'outillage et d'écosystème pour en être.

Ce module examine ce réflexe avant d'écrire la moindre ligne de code. Pas pour dire que Python est un mauvais choix, mais pour distinguer deux métiers que l'on confond sous le même mot « IA » — et montrer que celui qui consiste à construire un agent est un métier que vous pratiquez déjà.

Deux métiers derrière le mot « IA »

Entraîner un modèle, c'est le travail des équipes de recherche et de data science : préparer des jeux de données massifs, calculer sur GPU, ajuster des milliards de paramètres. C'est là que Python s'est imposé, avec des bibliothèques comme NumPy et PyTorch et les notebooks Jupyter. Sur ce terrain, Python est le choix raisonnable.

Construire un agent, c'est autre chose. Le modèle existe déjà, hébergé chez un fournisseur ou sur une machine que vous contrôlez. Vous ne le modifiez pas : vous l'appelez. Le travail consiste à :

envoyer une requête HTTP contenant la conversation et la liste des outils disponibles ;
lire une réponse JSON ;
décider quoi faire de cette réponse : afficher un texte, ou exécuter un outil ;
renvoyer le résultat au modèle, et recommencer jusqu'à obtenir une réponse finale ;
gérer tout ce qui peut mal tourner en chemin.

Requêtes HTTP, désérialisation JSON, appels à du code métier, gestion d'erreurs : c'est le quotidien d'un développeur d'applications .NET. Aucune de ces étapes ne dépend d'une bibliothèque de calcul scientifique.

À quoi ressemble réellement un échange avec un LLM

Voici, sous une forme simplifiée et indépendante du fournisseur, ce qu'un agent envoie au modèle :

{
  "messages": [
    { "role": "user", "content": "Où en est ma commande 4512 ?" }
  ],
  "tools": [
    {
      "name": "getOrder",
      "description": "Récupère le statut d'une commande à partir de son numéro",
      "parameters": { "orderId": "integer" }
    }
  ]
}

Et ce que le modèle peut répondre :

{
  "type": "tool_call",
  "name": "getOrder",
  "arguments": { "orderId": 4512 }
}

Le modèle n'a pas accès à votre base de commandes : il demande que l'outil soit appelé. C'est votre programme qui exécute getOrder 4512, ajoute le résultat à la conversation et renvoie le tout au modèle ; le modèle formule alors sa réponse finale au client.

Retenez cette répartition, elle structure tout le cours :

Étape	Qui la fait ?
Décider qu'un outil est nécessaire, choisir ses arguments	le modèle
Exécuter l'outil	votre code
Renvoyer le résultat au modèle	votre code
Rédiger la réponse finale à partir de ce résultat	le modèle
Décider quand s'arrêter, et quoi faire si quelque chose cloche	votre code

Toute l'« intelligence » est derrière l'API. Tout le reste — le cycle demande, exécution, réponse — est du code applicatif ordinaire.

Le coût caché de la bascule vers Python

Pour une équipe .NET, adopter Python pour ce travail d'orchestration n'est pas gratuit :

un second environnement à maîtriser (versions de Python, environnements virtuels, gestionnaire de paquets) ;
une seconde chaîne de build, de tests et de déploiement à maintenir ;
un pont à construire vers le code métier existant, qui reste en .NET ;
une compétence à recruter ou à former, pour un gain qui ne porte pas sur le cœur du problème.

Et l'outillage nécessaire existe côté .NET. Vous utiliserez dans ce cours trois briques, toutes disponibles sur NuGet : l'abstraction Microsoft.Extensions.AI de Microsoft, conçue pour que votre code ne dépende pas d'un fournisseur de modèle en particulier ; la bibliothèque OllamaSharp, qui la branche sur un modèle local ; et le SDK C# officiel du protocole MCP, que vous utiliserez au module 9.

Et pourquoi F# plutôt que C# ?

Tout ce cours pourrait s'écrire en C#. Mais trois propriétés de F# collent particulièrement bien au travail d'un agent :

La légèreté du script. Un fichier .fsx lancé avec dotnet fsi charge un package NuGet en une ligne, sans projet ni Main. C'est l'expérience « je teste une idée en dix lignes » qui fait le succès de Python, sans quitter .NET.
Des types qui décrivent les cas possibles. À chaque tour, la réponse du modèle est soit un texte final, soit une ou plusieurs demandes d'outil, soit quelque chose d'inutilisable. Les unions discriminées expriment exactement ce « soit… soit… », et le compilateur vous signale le cas que vous avez oublié de traiter.
Des erreurs qui font partie du type. Un LLM peut se tromper : demander un outil qui n'existe pas, oublier un argument, envoyer un JSON tronqué. Option et Result transforment ces échecs en valeurs que le code doit traiter, plutôt qu'en exceptions découvertes en production.

Pour vous donner une idée de la direction, voici le type que vous rencontrerez au module 7 — inutile de le comprendre en détail maintenant :

type AgentStep =
    | FinalAnswer of text: string
    | CallTools of calls: (string * Result<ToolCall, ToolError>) list
    | InvalidResponse of reason: string

Trois cas, et le compilateur vous avertira de toute fonction qui en oublie un.

Ce que Python garde

Ce cours ne prétend pas que F# remplace Python partout. Si votre travail consiste à entraîner ou affiner un modèle, à faire de l'analyse de données exploratoire lourde, ou à réutiliser une bibliothèque de recherche publiée uniquement en Python, restez sur Python : c'est son terrain.

La question à se poser est simple : est-ce que je fabrique le modèle, ou est-ce que je l'utilise ? Dans le second cas — celui de la plupart des projets d'application qui « ajoutent de l'IA » — votre stack .NET est déjà prête.

Exercice — classer les tâches

Pour chacune des tâches suivantes, décidez si elle relève de l'entraînement d'un modèle (où Python est pertinent) ou de la construction d'un agent (où .NET suffit), et notez la raison décisive : est-ce que les poids du modèle sont modifiés, ou est-ce que le modèle est seulement consommé ?

Affiner un modèle open source sur 200 000 tickets de support historiques.
Brancher un LLM hébergé sur l'API de suivi de commandes existante.
Exposer le catalogue produits à un assistant IA via un serveur MCP.
Mesurer la qualité des réponses d'un assistant sur un jeu de 50 questions de référence.
Comparer trois architectures de réseaux de neurones sur un jeu de données d'images.

Écrivez vos cinq réponses avant de lire la suite.

Réponses

Entraînement — on modifie les poids du modèle : outillage Python.
Agent — le modèle est appelé ; le reste est HTTP et code métier existant.
Agent — c'est précisément l'objet du module 9.
Agent — c'est la tâche piège : le mot « qualité » évoque la data science, mais le modèle n'est pas modifié. Envoyer 50 requêtes et comparer les réponses à des attentes est un test automatisé comme un autre.
Entraînement — recherche sur les modèles eux-mêmes.

Si vous vous êtes trompé sur la tâche 4, retenez le critère plutôt que le vocabulaire : ce n'est pas le sujet (« qualité », « IA », « données ») qui décide, c'est la question « les poids changent-ils ? ».

Le fil rouge de ce cours

Tout au long des modules suivants, vous allez construire un assistant de support e-commerce capable de répondre à « où en est ma commande ? ». Il appellera un LLM, décidera quand consulter les commandes, traitera proprement les réponses aberrantes du modèle, ajoutera des garde-fous contre les pannes, puis exposera son outil via MCP.

Ce que vous venez de faire

Vous avez distingué l'entraînement d'un modèle de la construction d'un agent, vu qu'un échange avec un LLM se résume à des requêtes HTTP et du JSON où le modèle demande et votre code exécute, et identifié ce qui rend F# adapté à ce travail : des scripts légers, des types qui énumèrent les cas possibles, et des erreurs traitées comme des valeurs.

Au module suivant, vous passez à la pratique : vous installez un modèle local avec Ollama, puis un script .fsx de quelques lignes envoie votre première question à ce LLM, sans projet, sans Main — et sans Python.