Pour apprendre l’Agentic AI sérieusement, je partirais sur cinq ressources gratuites, pas cinquante. L’idée c’est simple : comprendre les bases, pratiquer, garder du jugement d’ingénierie, poser les fondations théoriques, puis apprendre à évaluer avant de mettre quoi que ce soit en production.
Par où commencer l’Agentic AI ?
Je commencerais par le cours open-source AI Agents for Beginners de Microsoft. C’est, à mon avis, la meilleure porte d’entrée gratuite si vous voulez comprendre ce qu’est vraiment un agent IA avant de bricoler des démos dans tous les sens.
Le cours est disponible sur GitHub, sous licence MIT, donc vous pouvez le lire, le cloner, l’adapter, l’utiliser en interne assez librement. Il contient plus de quinze leçons, des vidéos, des exemples Python exécutables, et surtout une progression propre. On part des bases, puis on avance vers des sujets plus proches du terrain.
Les sujets couverts sont exactement ceux qu’il faut clarifier au début :
- Les bases des agents, pour comprendre la différence entre un simple appel à un LLM et un système qui observe, raisonne, agit et vérifie.
- L’utilisation d’outils, c’est-à-dire la capacité d’un agent à appeler une API, chercher dans une base, lancer une fonction ou manipuler un fichier.
- La planification, parce qu’un agent utile doit découper un objectif en étapes, pas juste répondre joliment.
- Le RAG, ou Retrieval Augmented Generation, qui consiste à donner au modèle les bons documents avant qu’il réponde.
- Les configurations multi-agent, quand plusieurs agents se répartissent les rôles au lieu de tout mettre dans un seul gros prompt fragile.
- La mémoire, pour savoir ce qu’un agent doit retenir, oublier, résumer ou réutiliser.
- Les standards comme MCP, Model Context Protocol, qui aide à connecter des agents à des outils et des sources de données de façon plus interopérable.
Ce que j’aime dans cette ressource, c’est qu’elle évite le côté “magie noire”. On voit les briques. On comprend pourquoi elles existent. Et on commence à se construire une vision propre du sujet.
Sur le terrain, je vois souvent des équipes vouloir brancher tout de suite un LLM à leurs outils internes. C’est tentant. Mais elles n’ont pas encore clarifié ce que l’agent doit décider, ce qu’il doit mémoriser, ce qu’il peut déléguer, et ce qu’il ne doit jamais faire seul. Ce cours aide justement à poser ces briques dans le bon ordre.
| Ce que la ressource apporte | Une base structurée, maintenue, avec théorie, vidéos et exemples Python concrets. |
| Pour qui elle est utile | Pour les développeurs, profils data, product builders et équipes qui veulent comprendre avant d’industrialiser. |
| Pourquoi je la mets en premier | Parce qu’elle remet les concepts dans le bon ordre avant de connecter des agents à de vrais outils. |
Comment pratiquer sans choisir trop vite un framework ?
Après avoir posé les bases avec Microsoft, je passerais aux mains dans le cambouis avec le Hugging Face AI Agents Course. Pour pratiquer sans s’enfermer trop tôt, c’est probablement l’une des meilleures portes d’entrée gratuites que je recommande aujourd’hui.
Ce que j’aime dans ce cours, c’est qu’il ne vous vend pas un framework comme si c’était la réponse magique à tous les problèmes. Il est pratique, gratuit, sans niveau payant caché, et il vous fait manipuler plusieurs approches. C’est exactement ce qu’il faut au début. Vous avez besoin de sentir les différences, pas de choisir un outil sur la base d’un thread LinkedIn.
Le cours fait notamment passer par smolagents, LlamaIndex et LangGraph. Smolagents est l’approche légère de Hugging Face pour créer des agents et comprendre les briques de base sans se noyer. LlamaIndex est souvent utilisé quand on veut connecter un modèle à des données, des documents, des index, bref quand l’agent doit aller chercher de l’information utile. LangGraph, lui, aide à représenter des workflows d’agents sous forme de graphe, avec des étapes et des transitions plus explicites.
L’intérêt n’est pas de décider lequel est “le meilleur”. Le vrai sujet, c’est de voir comment chaque approche vous force à penser différemment. Un agent qui reçoit une question, choisit un outil, récupère une information, puis produit une réponse, ça paraît simple sur le papier. En pratique, vous allez vite voir les problèmes : mauvais choix d’outil, réponse trop confiante, contexte incomplet, coûts qui montent, comportement difficile à reproduire.
Le projet final benchmarké et le certificat sont aussi intéressants. Pas parce que le certificat va changer votre vie. Honnêtement, ce n’est pas ça le point. Le point, c’est que vous devez livrer quelque chose qui se mesure. Et ça, dans l’Agentic AI, c’est précieux. Une démo qui marche une fois, j’en ai vu beaucoup chez des clients. Un système qui tient quand on change les questions, les données ou les contraintes, c’est une autre histoire.
À cette étape, je garderais quelques réflexes simples :
- Tester plusieurs approches avant de s’attacher à un framework.
- Noter les échecs, surtout ceux qui semblent bêtes.
- Comparer les sorties sur les mêmes questions.
- Regarder les coûts, pas seulement la qualité des réponses.
- Éviter de confondre une démo fluide avec un système fiable.
Quand faut-il vraiment construire un agent ?
Il faut construire un agent seulement quand un workflow prédéfini ne suffit plus. C’est le rappel le plus utile du guide Building Effective Agents d’Anthropic, et franchement, ça évite pas mal de projets trop compliqués pour rien.
La distinction est simple. Un workflow suit un chemin prévu à l’avance. On sait quelles étapes vont s’enchaîner, dans quel ordre, avec quelles règles. Un agent, lui, laisse davantage au LLM, le modèle de langage, le soin d’orchestrer son propre processus. Il peut décider quoi faire ensuite, quel outil appeler, quelle information chercher, comment corriger sa trajectoire.
C’est puissant, oui. Mais l’autonomie a un coût. Plus de variabilité. Plus de risques d’erreurs qui s’empilent. Plus de difficulté à comprendre pourquoi le système a fait tel choix. Et parfois plus de dépenses, parce qu’un agent peut multiplier les appels au modèle, aux outils, aux API. Dans beaucoup de projets business, la meilleure solution reste un workflow bien conçu. Pas un agent autonome juste parce que le mot est à la mode.
Anthropic décrit plusieurs motifs très utiles, que j’utilise souvent comme grille de lecture :
- Prompt chaining : On découpe une tâche en plusieurs prompts successifs. Par exemple, d’abord extraire les infos d’un email, puis rédiger une réponse, puis vérifier le ton.
- Routage : On envoie une demande vers le bon traitement. Une question juridique part vers un prompt juridique, une demande SAV part vers un autre flux.
- Parallélisation : On lance plusieurs traitements en même temps. Par exemple, analyser un document sous l’angle risque, conformité et synthèse commerciale.
- Orchestrateur et workers : Un modèle principal découpe le travail et délègue à plusieurs sous-tâches. C’est utile quand la tâche est complexe mais encore cadrable.
- Boucle évaluateur-optimiseur : Une réponse est produite, puis critiquée ou notée, puis améliorée. Très pratique pour gagner en qualité sans tout rendre autonome.
Sur le terrain, chez un client, je préfère souvent commencer par automatiser le processus avec des règles claires. On sécurise les entrées, les sorties, les validations. Puis on introduit un agent uniquement là où il apporte une vraie souplesse. Pas partout. Juste là où le chemin n’est pas toujours prévisible.
| Critère | Workflow | Agent |
| Contrôle | Élevé, les étapes sont définies | Plus faible, le LLM décide davantage |
| Autonomie | Limitée | Forte |
| Coût | Souvent plus prévisible | Souvent plus variable |
| Risque | Plus simple à tester et déboguer | Plus d’erreurs composées possibles |
| Cas d’usage typique | Processus métier stable | Situation ouverte, avec décisions en cours de route |
Pourquoi étudier les systèmes multi-agents ?
J’étudierais les systèmes multi-agents pour une raison assez simple : éviter de redécouvrir des problèmes déjà connus depuis longtemps. Quand on commence à brancher plusieurs agents IA ensemble, on a vite l’impression d’inventer un nouveau monde. En réalité, une bonne partie des questions existe depuis des années dans la recherche.
La ressource que je garde sous la main, c’est Multiagent Systems de Yoav Shoham et Kevin Leyton-Brown. C’est un ouvrage académique de référence, disponible en copie électronique via les auteurs. Ce n’est pas le genre de ressource qu’on lit pour trouver la dernière librairie Python à la mode. On le lit pour comprendre les fondations.
Et franchement, ça remet les idées en place. Dès qu’on met plusieurs agents ensemble, on ne gère plus seulement des prompts. On gère des comportements, des objectifs, des dépendances, des conflits possibles, et des mécanismes de coordination. C’est exactement là que la théorie multi-agent devient utile.
Les notions importantes ne sont pas si abstraites qu’elles en ont l’air. La théorie des jeux, c’est l’étude des décisions quand plusieurs acteurs influencent le résultat. La décision distribuée, c’est quand il n’y a pas un cerveau central qui décide de tout. La coordination, c’est comment éviter que tout le monde parte dans une direction différente. La négociation, c’est comment arbitrer quand les préférences ne sont pas alignées. Les incitations, c’est ce qui pousse un agent à agir d’une certaine manière. Les fondements logiques, c’est la manière propre de raisonner sur ce qu’un agent sait, croit, veut ou peut faire.
Prenez un cas très simple. Un agent doit analyser des emails, un autre doit prioriser les demandes, un troisième doit déclencher des actions dans un CRM. Si le premier classe mal une information, le second prend une mauvaise décision. Si deux agents modifient la même donnée avec des priorités différentes, vous avez un conflit. Si chaque agent optimise sa petite tâche localement, le résultat global peut devenir mauvais. J’ai déjà vu ça chez un client : chaque brique semblait correcte seule, mais l’ensemble produisait des décisions instables.
Anthropic aide à garder le système simple. Shoham et Leyton-Brown aident à comprendre ce qui se passe quand on accepte la complexité. Les deux sont utiles, juste pas au même moment.
- Coordination difficile entre plusieurs agents.
- Décisions concurrentes sur les mêmes données ou les mêmes actions.
- Négociation nécessaire entre agents avec des objectifs différents.
- Priorités contradictoires entre performance locale et résultat global.
- Résultats instables alors que chaque agent semble fonctionner correctement.
Comment évaluer un agent avant la production ?
J’évaluerais un agent avant la production avec des critères explicites, des jeux de tests, des mesures de qualité, et pas seulement avec une impression de fluidité. C’est le piège classique. Une démo propre donne vite l’impression que le système “comprend”, alors qu’il a juste bien répondu sur trois cas faciles.
La série gratuite Google et Kaggle Agents Whitepaper Series est intéressante pour ça. Elle couvre en cinq volets les sujets qui comptent vraiment quand on veut passer d’un prototype à quelque chose d’utilisable : architecture d’agents, usage des outils, interopérabilité avec MCP, ingénierie du contexte et de la mémoire, qualité, évaluation et production. MCP, pour faire simple, c’est un protocole qui aide les agents à se connecter à des outils et des sources de données de façon plus standardisée.
Le volume sur l’évaluation mérite une vraie attention. C’est souvent le point faible des projets Agentic AI que je vois passer. L’agent semble malin en atelier, puis il devient fragile dès qu’il tombe sur une demande ambiguë, une procédure incomplète, un outil qui ne répond pas, une donnée absente ou un objectif mal cadré.
L’évaluation n’est pas une formalité administrative. C’est ce qui permet de savoir si le système mérite de tourner dans un vrai contexte business. On mesure, on observe, on compare, on corrige. Et on recommence.
Prenons un agent de support interne. Son job est simple sur le papier : chercher une procédure, formuler une réponse, vérifier que la réponse est cohérente, citer une source interne si elle existe, puis escalader vers un humain si son niveau de confiance est trop bas. Là, je suivrais plusieurs métriques très concrètes :
- L’exactitude des réponses, pour savoir si l’agent dit vrai.
- La complétude, pour vérifier qu’il ne répond pas à moitié.
- Le taux d’escalade, parce qu’un bon agent doit savoir dire “je ne sais pas”.
- Les erreurs d’outil, quand une recherche, une API ou une base documentaire échoue.
- Le coût et la latence, parce qu’un agent trop cher ou trop lent ne tiendra pas en production.
- La stabilité des réponses, pour éviter qu’il change d’avis sur une même question.
| Critère | Question à poser | Risque si on ne mesure pas |
| Exactitude | La réponse est-elle correcte selon les sources internes ? | L’agent donne une réponse fausse avec assurance. |
| Complétude | La réponse couvre-t-elle tout le besoin utilisateur ? | L’utilisateur croit être aidé, mais il lui manque une étape clé. |
| Escalade | L’agent passe-t-il la main quand il n’est pas assez sûr ? | Le système invente au lieu de reconnaître ses limites. |
| Outils | Les appels aux outils fonctionnent-ils correctement ? | Une panne silencieuse produit une mauvaise décision. |
| Coût et latence | La réponse est-elle assez rapide et économique ? | Le système devient inutilisable à grande échelle. |
| Stabilité | L’agent répond-il de façon cohérente sur des cas similaires ? | La confiance utilisateur s’effondre. |
Alors, par quelle ressource vous commencez ?
Si je devais apprendre l’Agentic AI proprement, je ne commencerais pas par empiler des outils. Je prendrais Microsoft pour les bases, Hugging Face pour pratiquer sur plusieurs frameworks, Anthropic pour garder une vraie discipline d’ingénierie, Shoham et Leyton-Brown pour comprendre les systèmes multi-agents, puis Google et Kaggle pour apprendre à évaluer avant la production. Le coût, ici, c’est surtout votre temps. Mais c’est du temps bien investi. Vous évitez les agents gadgets, les démos trompeuses et les architectures impossibles à maintenir. Le bénéfice est simple : construire des agents IA plus fiables, plus mesurables, et vraiment utiles.
FAQ
- Qu’est-ce que l’Agentic AI ?
L’Agentic AI désigne des systèmes IA capables d’orchestrer des actions, d’utiliser des outils, de planifier des étapes et parfois de s’adapter en fonction du contexte. Le point important, c’est le niveau d’autonomie. Plus l’agent décide seul de son processus, plus il faut cadrer, tester et évaluer. - Quelle ressource gratuite choisir en premier pour apprendre l’Agentic AI ?
Je commencerais par AI Agents for Beginners de Microsoft. Le cours est structuré, open-source, avec des leçons, des vidéos et des exemples Python. Il couvre les bases, les outils, la planification, le RAG, les systèmes multi-agents, la mémoire et des sujets récents comme MCP. - Faut-il apprendre LangGraph, LlamaIndex ou smolagents en premier ?
Je ne choisirais pas trop vite. Le cours Hugging Face AI Agents permet justement de pratiquer avec plusieurs bibliothèques, dont smolagents, LlamaIndex et LangGraph. C’est utile pour comparer les approches avant de s’enfermer dans un écosystème. - Quelle est la différence entre un workflow IA et un agent IA ?
Un workflow suit un chemin défini à l’avance. Un agent laisse davantage au modèle le soin d’organiser les étapes, de choisir des outils ou d’ajuster son processus. Cette autonomie peut être utile, mais elle ajoute aussi du coût, de la variabilité et des risques d’erreurs composées. - Pourquoi l’évaluation est-elle si importante pour les agents IA ?
Parce qu’un agent peut très bien marcher en démo et échouer sur des cas réels. Il faut mesurer l’exactitude, la complétude, les erreurs d’outils, la latence, le coût, la stabilité et la capacité à escalader quand il ne sait pas. Sans évaluation, on pilote à l’impression.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent passer de la démo IA sympa au système fiable, mesurable et utile en production. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez structurer vos projets IA, data ou automatisation sans partir dans tous les sens, contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐
- Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
- Data Analyst & Analytics engineering : tracking avancé (GTM server, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
- Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
- Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.






