Il vaut le coup si vous savez déjà coder en Python et appeler une API LLM. Ce cours va droit sur les vrais sujets des agents IA : outils, mémoire, évaluation, déploiement. Le genre de contenu qui évite de rester coincé au stade du joli notebook.
À quoi sert vraiment ce cours ?
Ce cours sert à passer d’une compréhension générale de l’IA générative à une pratique plus sérieuse des agents IA.
Le programme 5-Day AI Agents Intensive a été organisé par Google et Kaggle. Il a été suivi en live en novembre 2025, puis rendu disponible en auto-apprentissage. Et vu les chiffres, on voit bien que le sujet n’est plus un petit délire de niche : plus d’1,5 million d’inscrits et 11 000 soumissions de projets finaux.
Ce n’est pas un cours pour découvrir ChatGPT ou apprendre à générer un texte propre. Ça, c’était plutôt la première vague. Ici, le recentrage est clair : on parle de systèmes qui font quelque chose. Des agents capables d’utiliser des outils, de garder du contexte, de suivre des règles, de collaborer avec d’autres agents et surtout d’être évalués avant d’être envoyés en production.
Pour le dire simplement, un agent IA, ce n’est pas juste un modèle qui répond. C’est un modèle placé dans une boucle d’action. Il reçoit une demande, il raisonne, il choisit un outil, il agit, il observe le résultat, puis il ajuste. Ça peut être une recherche web, une requête SQL, un appel API, une mise à jour dans un CRM, ou une vérification métier.
🚀 Développez vos compétences avec nos formations expertes en Analytics, Data, IA et automatisation No Code !
Les données sont partout, mais encore faut-il savoir les exploiter. Nos formations vous donnent les clés pour maîtriser Google Analytics, Google Tag Manager, Looker Studio, BigQuery, Prompt Engineering, ChatGPT, Make ou n8n pour créer des agents IA et bien d’autres outils essentiels. Conçues pour les professionnels, elles allient théorie et pratique pour vous rendre rapidement opérationnel.🔍📊
Le lien avec le GenAI Intensive 2024 est assez logique. Google et Kaggle reprennent l’idée d’un apprentissage court, dense, très orienté pratique. Mais cette fois, le sujet n’est plus la génération de contenu au sens large. Le centre de gravité, ce sont les agents. Le cours existe aussi sous forme de guide Kaggle Learn, ce qui permet de le suivre à son rythme, et une réédition thématique est prévue en juin 2026.
Quand j’accompagne des équipes sur l’IA ou l’automatisation, je vois toujours la même chose. Le vrai saut de maturité arrive rarement au moment où elles testent un modèle. Il arrive quand elles comprennent comment brancher ce modèle à des outils, à de la mémoire, à des règles métier et à de la mesure. C’est exactement là que ce cours devient intéressant.
Que couvre le programme en cinq jours ?
Le programme couvre tout le cycle de construction d’un agent IA, du premier prototype jusqu’au déploiement. Chaque jour mélange un article technique et deux codelabs pratiques, avec Gemini et l’Agent Development Kit de Google, souvent appelé ADK. Et à la fin, il y a un capstone, donc un mini-projet final, pour prouver qu’on sait assembler les briques.
Le jour 1 pose les bases : c’est quoi un agent, comment il raisonne, comment il décide d’utiliser un outil, comment il boucle sur une tâche. J’aime bien ce point parce qu’il force à distinguer un vrai agent d’un workflow simple. Un workflow, c’est une suite d’étapes prévues à l’avance. Un agent, lui, choisit une partie du chemin selon le contexte. Cette différence évite de mettre de l’agentique partout juste parce que c’est à la mode. On construit aussi un premier agent, puis un système multi-agent, où plusieurs agents collaborent avec des rôles séparés.
Le jour 2 attaque les outils et l’interopérabilité avec MCP, le Model Context Protocol. En clair, MCP sert de mécanisme standard pour faire communiquer un agent avec des systèmes externes. Un agent devient vraiment utile quand il peut lire une base, appeler une API, créer un ticket, manipuler un fichier ou déclencher une action. Le cours aborde aussi l’approbation humaine, surtout pour les opérations longues, coûteuses ou sensibles. Et ça, en entreprise, c’est rarement optionnel.
Le jour 3 parle de context engineering, de sessions et de mémoire. Le context engineering, c’est l’art de donner au modèle les bonnes informations, au bon moment, sans le noyer. On passe aux agents stateful, donc des agents qui gardent un état, et à la mémoire longue durée persistante entre sessions. C’est souvent là que la démo sympa devient un assistant exploitable. J’ai vu ça chez un client : sans mémoire, l’agent impressionnait cinq minutes, mais il fallait tout lui répéter.
Le jour 4 est plus terre à terre, et c’est une bonne chose. On parle journalisation, traçage, métriques, évaluation des réponses et évaluation de l’usage des outils. Sans mesure, on ne sait pas si l’agent aide vraiment ou s’il improvise bien avec aplomb.
Le jour 5 traite du passage en production. On voit les protocoles agent-à-agent, donc la façon dont des agents peuvent échanger proprement entre eux, puis le déploiement dans un runtime géré. Vertex AI Agent Engine est cité comme exemple côté Google.
| Jour | Sujet | Ce que j’apprends | Pourquoi c’est utile en production |
| Jour 1 | Introduction aux agents | Construire un agent simple et un système multi-agent | Éviter de complexifier un projet qui n’a besoin que d’un workflow |
| Jour 2 | Outils et MCP | Connecter l’agent à des systèmes externes | Créer des agents capables d’agir, avec validation humaine si besoin |
| Jour 3 | Contexte et mémoire | Gérer les sessions et la mémoire persistante | Faire un assistant qui garde le fil dans le temps |
| Jour 4 | Qualité et évaluation | Tracer, mesurer et évaluer les comportements | Savoir si l’agent est fiable ou juste convaincant |
| Jour 5 | Déploiement | Passer du prototype à un runtime géré | Industrialiser avec des briques comme Vertex AI Agent Engine |
Pourquoi les agents IA demandent plus qu’un prompt ?
Un agent IA fiable demande une architecture, des outils, du contexte, de la mémoire et de l’évaluation, pas juste un bon prompt.
C’est souvent là que les projets IA coincent. Le prototype répond bien une fois, dans une démo propre, avec un cas bien cadré. Puis on le met face à un vrai contexte métier, avec des données incomplètes, des exceptions, des droits d’accès, des validations, et là ça se dégrade vite.
Un prompt peut aider à formuler une bonne réponse. Mais un agent doit surtout agir correctement. Il doit savoir quoi faire, quand le faire, avec quelles données, jusqu’où aller seul, et quand demander à un humain. Ce n’est plus juste “réponds-moi”. C’est “travaille dans un environnement réel sans casser la baraque”.
La différence avec un workflow simple est importante.
- Un workflow suit une séquence prévue. Étape 1, étape 2, étape 3. Si le chemin est stable, c’est souvent le meilleur choix.
- Un agent peut choisir l’action à lancer, l’outil à utiliser, l’ordre des étapes, et parfois collaborer avec d’autres agents.
- Un agent devient utile quand le chemin dépend du contexte. Sinon, on fabrique juste une usine à gaz.
Les outils personnalisés changent beaucoup de choses. Un agent isolé dans une fenêtre de chat reste limité. Un agent connecté au système d’information peut récupérer une donnée externe, lancer une action contrôlée, préparer une mise à jour, ou demander une validation humaine avant une opération longue.
MCP, pour Model Context Protocol, va dans ce sens. L’idée est de faciliter l’interopérabilité entre l’agent et les outils autour de lui. En clair, éviter que chaque intégration ressemble à du bricolage fragile. Je reste prudent sur le sujet, parce que la valeur ne vient pas du sigle. Elle vient de la capacité à connecter proprement l’agent aux bonnes sources, avec les bons garde-fous.
Le context engineering est tout aussi central. Ça veut dire organiser le contexte donné à l’agent : les règles, les données utiles, l’historique, les limites, les consignes métier. Les sessions et la mémoire longue durée donnent une continuité. L’agent peut reprendre un dossier, tenir compte d’un échange précédent, éviter de redemander la même chose.
Mais cette mémoire est aussi un risque. Il faut décider ce qui doit être mémorisé, oublié, tracé ou vérifié. Sinon l’agent accumule du bruit, réutilise une vieille information, ou garde des données qu’il ne devrait pas garder.
Sur des projets d’automatisation, j’ai souvent vu des équipes vouloir brancher l’IA trop vite partout. Le meilleur réflexe, c’est plus simple : identifier les décisions répétables, les validations nécessaires, et les moments où l’humain doit rester dans la boucle.
Qui devrait suivre ce cours ?
Ce cours s’adresse surtout aux praticiens intermédiaires qui savent programmer en Python et ont déjà appelé une API LLM.
Si vous partez de zéro, ce n’est pas le meilleur point d’entrée. Vous risquez de passer plus de temps à comprendre pourquoi votre notebook plante, comment gérer une clé API, ou ce qu’est un appel HTTP, plutôt qu’à comprendre le vrai sujet : comment construire un agent qui raisonne, utilise des outils, garde du contexte et s’évalue correctement.
En revanche, si vous êtes développeur, data analyst technique, automation builder, consultant IA, ou simplement à l’aise avec les notebooks et les APIs, là oui, le cours peut être très rentable. J’ai vu ce cas chez un client : les profils déjà bons en Python ont vite transformé les codelabs en prototypes utiles, alors que les débutants complets étaient bloqués sur des détails d’environnement.
Les prérequis sont assez simples, mais ils comptent vraiment :
- Comprendre Python sans devoir chercher chaque ligne sur Google.
- Savoir lancer du code dans un notebook ou un environnement local.
- Être à l’aise avec les bases des modèles de langage, donc savoir ce qu’est un prompt, un contexte, une sortie générée.
- Avoir déjà manipulé une API LLM, même juste avec OpenAI, Gemini, Claude ou un autre provider.
Pour en tirer le maximum, je ne traiterais pas ce cours comme une suite de copier-coller. Les articles techniques sont importants, même s’ils demandent un peu plus d’effort. Les codelabs aussi, mais il faut les tordre. Changez le cas d’usage. Remplacez l’exemple par un problème de votre métier. Ajoutez un outil. Cassez le truc, puis réparez-le.
Je passerais aussi plus de temps que prévu sur deux sujets : le context engineering et l’évaluation. Le context engineering, c’est l’art de donner au modèle les bonnes informations au bon moment. L’évaluation, c’est vérifier si l’agent fait vraiment ce qu’on attend, pas juste s’il donne une réponse qui a l’air intelligente. C’est là que les agents deviennent solides, ou restent des démos fragiles.
Le capstone final a une vraie valeur. Ce n’est pas juste un exercice de fin. C’est une preuve de compétence, parce qu’il oblige à assembler plusieurs briques : architecture agentique, outils, mémoire, évaluation, et parfois logique de déploiement.
| Profil | Intérêt du cours | Point de vigilance |
| Débutant complet | Faible au départ | Risque de bloquer sur Python, les APIs et les notebooks |
| Développeur Python | Très bon | Ne pas rester au niveau démo, travailler l’évaluation |
| Data analyst technique | Très bon | Relier les agents à des cas data concrets |
| Profil no-code avancé | Bon si vous acceptez de coder un peu | Ne pas sous-estimer les prérequis techniques |
| Équipe produit ou business | Utile pour cadrer un projet agentique | À suivre avec un profil technique dans la boucle |
Comment passer du cours à un vrai projet ?
Il faut transformer les apprentissages du cours en petit cas d’usage mesurable, pas essayer de construire un agent universel. Je vois souvent l’erreur chez des clients : ils sortent d’un cours IA, ils veulent brancher l’agent à tout le système d’information, CRM, emails, fichiers, ERP, Slack… Et deux semaines après, plus personne ne sait ce qu’on teste vraiment.
Le passage à un vrai projet commence par un périmètre clair. Une tâche utile. Des données accessibles. Des outils identifiés. Des critères de réussite. Des limites acceptées. Par exemple : “L’agent aide un commercial à préparer un compte rendu client à partir du CRM et des notes d’appel.” C’est beaucoup plus solide que “L’agent assiste toute l’équipe commerciale”.
Les cinq jours du cours peuvent servir de grille de travail très concrète :
- Jour 1 : Je décide si un agent est vraiment nécessaire. Si une simple automatisation suffit, je ne force pas l’agentique.
- Jour 2 : Je liste les outils appelés par l’agent, comme une API, une base de données ou un moteur de recherche interne, et je définis où l’humain doit valider.
- Jour 3 : Je choisis ce qui doit être conservé en mémoire. Une mémoire, c’est ce que l’agent garde d’une interaction à l’autre. Trop de mémoire peut créer du bruit ou des risques.
- Jour 4 : Je mesure la qualité. Pas au feeling. Avec des cas de test, des réponses attendues, des erreurs connues.
- Jour 5 : Je réfléchis au runtime, c’est-à-dire l’environnement où l’agent tourne vraiment, à l’accès utilisateur et au déploiement.
Le point le plus important, c’est l’évaluation avant production. Un agent qui répond bien en démo n’est pas forcément fiable. Il faut tracer ses actions, vérifier ses réponses, mesurer l’usage des outils, repérer les erreurs répétées, et garder un contrôle humain sur les étapes sensibles. Dès qu’il touche à un paiement, une donnée client, une décision RH ou une action irréversible, je mets une validation humaine.
Le déploiement, lui, n’a rien de magique. Passer d’un notebook à un service accessible demande des choix d’infrastructure, de sécurité, de monitoring et de gouvernance. Le cours aborde ce passage avec les protocoles agent-à-agent et un runtime géré comme Vertex AI Agent Engine. C’est utile pour comprendre la direction. Mais chaque entreprise aura ses contraintes, ses règles, ses outils déjà en place.
- Cas d’usage : Une tâche précise et utile.
- Outils : Les API, bases ou services que l’agent peut appeler.
- Mémoire : Ce qui doit être conservé, et pourquoi.
- Validation humaine : Les étapes sensibles à contrôler.
- Métriques : Qualité, temps gagné, taux d’erreur.
- Logs : Actions, réponses, outils utilisés.
- Environnement de déploiement : Notebook, service interne, Vertex AI Agent Engine ou autre runtime.
- Capstone ou preuve de compétence : Un mini-projet terminé, démontrable et mesurable.
Et maintenant vous en faites quoi ?
Ce cours Kaggle et Google est intéressant parce qu’il ne vend pas les agents IA comme de la magie. Il remet les pieds sur terre : architecture, outils, MCP, mémoire, évaluation, déploiement. Si vous savez déjà coder un minimum en Python et appeler une API LLM, vous avez de quoi progresser vite. Le capstone ajoute une vraie valeur, parce qu’il force à assembler les briques au lieu de juste suivre des exercices. Mon conseil : prenez ce cours comme une base pour cadrer un vrai cas d’usage. Vous gagnerez du temps, vous éviterez les agents gadget, et vous saurez mieux construire des systèmes IA utiles pour votre business.
FAQ
- Le cours IA agentique Kaggle Google est-il gratuit ?
Oui, le cours est présenté comme gratuit. Il a d’abord été organisé en live, puis rendu disponible en auto-apprentissage sous forme de guide Kaggle Learn. - Quel niveau faut-il avoir pour suivre ce cours ?
Le bon niveau, c’est intermédiaire. Il vaut mieux savoir programmer en Python et avoir déjà appelé une API LLM. Sinon, vous risquez de bloquer sur la technique de base au lieu de comprendre les agents. - Qu’est-ce qu’on apprend concrètement dans ce cours ?
Vous apprenez les architectures d’agents, l’usage des outils, le Model Context Protocol, la mémoire entre sessions, l’évaluation des agents, le traçage, les métriques et le passage d’un prototype vers un service déployable. - Pourquoi le context engineering est-il important pour les agents IA ?
Parce qu’un agent utile doit garder une continuité. Les sessions et la mémoire longue durée permettent de construire des comportements plus robustes, mais seulement si on structure bien ce qui doit être conservé, vérifié ou oublié. - Le capstone final a-t-il une vraie valeur ?
Oui, parce qu’il oblige à assembler les concepts du cours dans un projet complet. C’est une preuve plus solide qu’une simple attestation suivie passivement, surtout si vous voulez montrer que vous savez construire un agent exploitable.
A propos de l’auteur
Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA dans les process métier et le SEO/GEO. 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. Si vous voulez cadrer, prototyper ou industrialiser des automatisations IA utiles pour votre business, 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é (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, 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.