Un agent IA est un programme qui confie à un modèle de langage non plus seulement la rédaction d'un texte, mais le choix des actions : appeler un outil, lire un résultat, recommencer. Ce parcours vous fait construire des agents du plus simple au plus outillé — la boucle écrite à la main, puis le function calling, puis deux frameworks de référence, et enfin une interface web. Tout tourne sur un modèle local servi par Ollama : aucune API payante. Public visé : développeur Python qui veut comprendre les agents de l'intérieur avant d'utiliser un framework, pas l'inverse. À la fin, vous saurez choisir le bon niveau d'outillage pour un besoin donné.
Aller droit au but
Section intitulée « Aller droit au but »Au terme de ce parcours, vous saurez
Section intitulée « Au terme de ce parcours, vous saurez »- Expliquer ce qu'est un agent et le distinguer d'un simple appel de modèle.
- Écrire une boucle d'agent à la main — et donc comprendre ce qu'un framework automatise.
- Décrire un outil par un schéma et le faire appeler de façon fiable.
- Choisir entre PydanticAI et LangGraph selon le besoin, et les mettre en œuvre.
- Mettre un agent en pause pour une validation humaine sur les actions sensibles.
- Exposer un agent derrière une interface web avec authentification.
Mon retour d'expérience — pour ceux qui veulent comprendre
Section intitulée « Mon retour d'expérience — pour ceux qui veulent comprendre »La partie ci-dessus suffit pour démarrer. La suite explique pourquoi ce parcours est construit ainsi, et les pièges que je vois revenir le plus souvent.
Je conçois des contenus techniques DevOps et j'automatise au quotidien ; je travaille aujourd'hui chez Outscale. Sur le sujet des agents IA, un constat domine : la plupart des développeurs commencent par un framework — ils assemblent des briques sans savoir ce qu'elles font. Ça marche en démonstration, et ça s'effondre dès le premier comportement inattendu. Ce parcours prend le chemin inverse, et c'est un choix assumé.
Pourquoi les agents IA changent la donne en 2026
Section intitulée « Pourquoi les agents IA changent la donne en 2026 »Un modèle de langage seul produit du texte. Un agent agit : il décide d'appeler une API, de lire un fichier, de relancer une recherche. Cette bascule ouvre des usages concrets — trier des tickets, résumer des releases, interroger une base — mais elle déplace aussi le risque : un programme qui agit peut agir mal.
| Sans la compréhension des agents | Avec ce parcours |
|---|---|
| On assemble un framework sans savoir ce qu'il fait | On sait ce que chaque couche automatise |
| La sortie du modèle est du texte à parser, fragile | La sortie est typée, validée, testable |
| Un agent peut exécuter une action destructive seul | Une validation humaine garde les actions sensibles |
| Les bugs sont mystérieux — « le LLM est bizarre » | On sait isoler la boucle, l'outil, le modèle |
| Les démos ne se reproduisent pas | Les versions sont épinglées, les labs rejouables |
Ce que ce parcours défend
Section intitulée « Ce que ce parcours défend »Comprendre la boucle avant le framework. Le premier guide écrit un agent en Python pur — aucune dépendance. C'est volontaire : un framework qui « marche par magie » est un framework qu'on ne sait pas déboguer. On n'adopte PydanticAI ou LangGraph qu'après avoir écrit à la main la boucle qu'ils remplacent.
La sortie typée n'est pas un confort, c'est une frontière. Tant qu'un agent renvoie du texte libre, il reste un script de démonstration. Dès qu'il renvoie une structure validée — un modèle Pydantic —, il devient un composant qu'on peut brancher, tester, surveiller. Je considère cette bascule comme la vraie ligne entre un prototype et du code de production.
Un modèle local suffit pour apprendre. Tout le parcours tourne sur Ollama, avec des modèles comme qwen2.5. Pas de clé d'API, pas de facture, pas de données qui partent chez un tiers. La compétence acquise reste valable quel que soit le modèle visé ensuite.
Le human-in-the-loop n'est pas une option. Dès qu'un agent peut supprimer, envoyer ou payer, une étape de validation humaine devient obligatoire. LangGraph en fait un mécanisme de premier plan ; ce parcours le traite comme tel, pas comme un raffinement avancé.
L'agent et son interface sont deux choses. La logique d'un agent — boucle, outils, état — se teste sans interface. L'interface — Chainlit — se développe sans toucher à l'agent. Mélanger les deux produit un code que personne n'ose modifier. Le parcours les sépare nettement, et la dernière étape montre le point de jonction unique entre eux.
Ce que je vous interdis
Section intitulée « Ce que je vous interdis »Démarrer par un framework. Le réflexe « j'installe LangChain et je vois » produit un agent que vous ne saurez pas réparer. Faites le premier guide d'abord — la boucle à la main —, même si elle vous semble rudimentaire.
Laisser un agent agir sans garde-fou. J'ai vu un agent de « nettoyage » bien intentionné fermer des tickets encore ouverts parce que son prompt était ambigu. Toute action irréversible passe par une validation : c'est le rôle de interrupt() dans le guide LangGraph.
Faire confiance au texte libre. Parser la réponse d'un modèle avec des expressions régulières en espérant la bonne forme, c'est accumuler une dette qui explose en production. Typez la sortie : un appel qui réussit a produit une structure valide, point.
Mélanger logique et interface. Écrire les appels au modèle directement dans les fonctions Chainlit fige tout. La logique d'agent doit vivre dans ses propres modules, testée seule ; Chainlit ne fait que l'appeler.
Livrer un lab non reproductible. Un exemple sans versions épinglées ne se rejoue pas six mois plus tard. Les paquets Python sont épinglés en ==X.Y.Z, les images de conteneur par empreinte — c'est une règle, pas une préférence.
Tester un agent uniquement via le modèle. Un test qui dépend d'un appel LLM est instable par nature. Isolez la logique déterministe — le routage, les règles de sécurité — et testez-la sans modèle ; gardez un ou deux tests d'intégration, pas davantage.
Sécurité non négociable
Section intitulée « Sécurité non négociable »Un agent est un programme qui agit pour vous : sa sécurité n'est pas un sujet annexe. Trois principes traversent tout le parcours.
Le moindre privilège d'abord : un outil ne reçoit que l'accès strictement nécessaire à sa tâche. Un outil de lecture ne doit pas pouvoir écrire ; un outil qui interroge une API publique n'a pas besoin de vos secrets internes.
La validation humaine ensuite, sur toute action irréversible — c'est le interrupt() de LangGraph. Le coût d'un clic de confirmation est négligeable face à celui d'une suppression non voulue.
La gestion des secrets enfin : aucune clé, aucun mot de passe en clair dans le code. Ils vivent dans des variables d'environnement ou un coffre, jamais dans un fichier suivi par Git.
Le bon niveau d'outillage selon le besoin
Section intitulée « Le bon niveau d'outillage selon le besoin »Ce parcours n'impose pas un outil unique : il vous apprend à choisir. Trois niveaux, du plus léger au plus complet.
La boucle écrite à la main convient à un agent simple, à un prototype, ou pour comprendre le mécanisme. Aucune dépendance, tout est visible — mais tout est aussi à votre charge.
PydanticAI s'impose dès qu'on veut une sortie typée, de l'injection de dépendances et des retries sans réécrire cette plomberie. C'est le bon défaut pour un agent qui produit un résultat structuré.
LangGraph devient pertinent quand le parcours se ramifie : plusieurs étapes, des branchements conditionnels, de la persistance d'état, une validation humaine. Le modèle « graphe d'états » paie son coût d'apprentissage dès que la boucle linéaire ne suffit plus.
Ce parcours prépare à quoi
Section intitulée « Ce parcours prépare à quoi »À la fin, vous êtes autonome pour concevoir, tester et exposer un agent IA sur une infrastructure que vous maîtrisez. C'est le socle direct des sujets plus avancés de la formation : les systèmes multi-agents, les patterns de raisonnement, la mémoire persistante et la connexion au protocole MCP.