Bootcamp IA agentique 2026

Présentation de la formation

Matériel et environnement requis

1. Module 1 — Fondations de l'IA agentique

   0 min

   Le module 01 pose le socle conceptuel du bootcamp. Il répond à une question simple en apparence — **qu'est-ce qu'un agent, et en quoi diffère-t-il d'un chatbot ou d'un workflow ?** — puis il fournit les outils de cadrage nécessaires pour décider, en entreprise, ce qui mérite d'être agentifié et ce qui ne le mérite pas. Vous y découvrez l'anatomie complète d'un agent : perception des entrées, mémoire de travail, planification, moteur de décision, catalogue d'outils, action sur le système cible et observabilité. Le fil rouge est le cycle **perception → décision → action** exécuté en boucle, sous contrainte d'un budget de tours et d'un critère d'escalade. Chaque composant est décrit par le rôle qu'il joue et par l'artefact qu'il laisse dans les traces : sans trace, un agent n'est ni testable, ni auditable, ni améliorable. La deuxième leçon formalise les trois régimes d'automatisation (chatbot, workflow, agent) et donne une grille de choix fondée sur une seule question décisive : qui choisit la prochaine étape ? La troisième leçon traite le LLM pour ce qu'il est dans un agent : un moteur de décision probabiliste auquel on impose un contrat de sortie structuré (appel d'outil, JSON strict, score de confiance, escalade). La quatrième leçon dresse le panorama des cas d'usage professionnels — support client, développement logiciel, finance, RH, industrie, cybersécurité — et nomme sans détour les limites actuelles : hallucination, fenêtre de contexte, coût variable, non-déterminisme résiduel, injection de prompt et absence de garantie sémantique. Le module se termine par un quiz de 6 questions (seuil 5/6) et par le livrable qui sert de base au lab 01 : une note de cadrage d'une page et demie, chiffrée et opposable, sur un cas d'usage réel de votre organisation.

   • 📘 Leçon 1 — Anatomie d'un agent : la boucle perception → décision → action0 min
   • 📘 Leçon 2 — Agent, chatbot et workflow : trois régimes d'automatisation0 min
   • 📘 Leçon 3 — Le LLM comme moteur de décision : contrat, outils et incertitude0 min
   • 📘 Leçon 4 — Cas d'usage professionnels et limites actuelles des agents0 min
   • ✅ Quiz auto-corrigé : Quiz — Fondations de l'IA agentique6 questions · seuil 5/6
   • 🧪 Lab guidé : Construire et instrumenter un premier agent outillé11 étapes · 0 min
   • 📦 Livrable : Note de cadrage d'un premier agent en production6 critères de validation

2. Module 2 — Prompting et structuration des sorties

   0 min

   Un agent ne produit jamais mieux que la consigne qu'il reçoit. Ce module transforme l'écriture de prompts d'un exercice d'intuition en une discipline d'ingénierie : décomposer une consigne métier en briques RCTFC (rôle, contexte, tâche, format, contraintes), choisir le bon patron de raisonnement, puis verrouiller la sortie par un schéma JSON validé à la fois côté fournisseur et côté application. Quatre compétences s'enchaînent. D'abord l'anatomie d'un prompt professionnel : ce que chaque brique apporte, pourquoi l'ordre compte et comment fermer les zones d'ambiguïté qui coûtent des allers-retours. Ensuite les patrons few-shot et chain-of-thought, avec un critère de décision explicite plutôt qu'une préférence personnelle. Puis la structuration des sorties : JSON Schema, Structured Outputs, appels d'outils contraints, validation Pydantic ou Zod, réparation contrôlée des erreurs de parsing. Enfin l'évaluation rapide : constituer un jeu de cas, mesurer un taux d'exactitude et de conformité, comparer deux variantes et décider avec des chiffres. Le module s'appuie sur des outils réels et sur des extraits exécutables : API OpenAI (mode `json_schema` en `strict`), API Anthropic (tool use), Pydantic v2, Zod, Ajv, harnais d'évaluation `promptfoo`. Chaque leçon se termine par un exercice guidé dont le résultat attendu est décrit précisément, afin que vous puissiez vous auto-évaluer sans attendre la correction. À l'issue du module, vous savez écrire un prompt qui tient en production, le versionner, mesurer sa qualité sur un jeu d'évaluation versionné et le faire évoluer sans régression. C'est le prérequis direct du module 03, consacré aux outils et aux appels d'API : un agent ne peut appeler une fonction de manière fiable que si le modèle produit des arguments conformes à un schéma.

   • 📘 Leçon 1 — Anatomie d'un prompt efficace : rôle, contexte, tâche, format, contraintes0 min
   • 📘 Leçon 2 — Patrons few-shot et chain-of-thought : choisir et calibrer0 min
   • 📘 Leçon 3 — Sorties structurées : JSON validé par schéma0 min
   • 📘 Leçon 4 — Évaluer un prompt et itérer sans régression0 min
   • ✅ Quiz auto-corrigé : Quiz — Prompting et structuration des sorties6 questions · seuil 5/6
   • 🧪 Lab guidé : Triage de tickets : prompt versionné, JSON validé et évaluation mesurable12 étapes · 0 min
   • 📦 Livrable : Fiche de spécification de prompt et jeu d'évaluation6 critères de validation

3. Module 3 — Outils, fonctions et appels d'API

   0 min

   Un modèle de langage seul ne peut ni lire un fichier, ni interroger une base de données, ni créer un ticket dans un outil de support : il ne produit que du texte. Lui donner des outils, c'est transformer cette capacité de rédaction en capacité d'action. Ce module traite le mécanisme central de l'IA agentique : le *tool calling*, c'est-à-dire la capacité d'un modèle à demander l'exécution d'une fonction dont il ne connaît que le contrat — nom, description, paramètres typés — et dont votre application garde entièrement le contrôle. Nous partons du principe pour aller jusqu'à l'exploitation, en quatre temps. La leçon 1 pose le cycle de vie complet d'un appel d'outil et la logique de délégation. La leçon 2 montre comment écrire un schéma de fonction réellement exploitable : JSON Schema, types, champs obligatoires, énumérations, contraintes de format et budget de contexte. La leçon 3 construit la boucle d'exécution robuste, avec validation des arguments, isolation des erreurs, reprise sur erreur et délais d'attente. La leçon 4 ferme le sujet par les propriétés de production : idempotence, périmètres de permission, approbation humaine et journal d'audit. Le fil conducteur est un agent de support client de la boutique en ligne fictive *NovaShop*, capable de lire une commande, de rechercher dans la documentation interne, de proposer un remboursement et d'ouvrir un ticket. Cet exemple est volontairement trivial sur le métier et exigeant sur la mécanique : chaque outil est un contrat versionné, chaque appel est validé, tracé et réessayé selon une politique explicite. À l'issue du module, vous aurez produit un **dossier d'intégration d'outils** directement réutilisable dans le lab 03 et dans le capstone : registre des outils, schémas, matrice de permissions, politique de reprise et journal d'appels. C'est l'artefact que l'on demande à un ingénieur agentique avant toute mise en production, parce qu'il conditionne à la fois la fiabilité, la sécurité et l'auditabilité du système.

   • 📘 Leçon 1 — Principe du tool calling : déléguer l'action, garder le contrôle0 min
   • 📘 Leçon 2 — Définir un schéma d'outil exploitable0 min
   • 📘 Leçon 3 — Boucle d'exécution, délais d'attente et reprise sur erreur0 min
   • 📘 Leçon 4 — Idempotence, permissions et journalisation des appels0 min
   • ✅ Quiz auto-corrigé : Quiz — Outils, fonctions et appels d'API6 questions · seuil 5/6
   • 🧪 Lab guidé : Outiller l'agent support NovaShop : schémas, boucle d'exécution et audit12 étapes · 0 min
   • 📦 Livrable : Dossier d'intégration d'outils (registre, schémas, permissions, reprise, audit)6 critères de validation

4. Module 4 — Mémoire, contexte et RAG

   0 min

   Un agent ne raisonne bien que sur ce qu'il a sous les yeux. Ce module traite le carburant de l'agent : le **contexte**. Vous apprendrez à mesurer un budget de tokens, à le répartir entre consignes système, schémas d'outils, historique et documents récupérés, puis à organiser la **mémoire** de l'agent en trois étages : mémoire de travail (la fenêtre), mémoire épisodique (résumés de session) et mémoire sémantique (faits durables réutilisables). La seconde moitié du module construit une chaîne de **RAG** (*Retrieval-Augmented Generation*) de bout en bout : découpage des documents, calcul d'embeddings, index vectoriel, recherche hybride lexicale + sémantique, fusion par *Reciprocal Rank Fusion* et reranking. Nous nous appuyons sur des outils que vous pouvez installer immédiatement (`tiktoken`, `gpt-tokenizer`, `langchain-text-splitters`, `pgvector`, `Qdrant`, `Cohere Rerank`). Enfin, nous traitons le point qui sépare une démonstration d'un système exploitable : l'**ancrage** des réponses. Chaque affirmation doit renvoyer à un extrait identifiable, et l'agent doit savoir refuser quand la base ne contient pas la réponse. Les livrables du module s'inscrivent dans la suite logique du module 03 (outils et appels d'API) et préparent le module 05 (orchestration multi-agents), où la mémoire devient une ressource partagée entre plusieurs agents. Le module représente 6 heures, soit 4 leçons de 45 minutes, un quiz noté et un livrable professionnel : une **note de cadrage d'architecture mémoire et RAG**, directement réutilisable dans le capstone de fin de parcours.

   • 📘 Leçon 1 — Fenêtre de contexte et budget de tokens0 min
   • 📘 Leçon 2 — Mémoire courte et mémoire longue : résumés et faits durables0 min
   • 📘 Leçon 3 — Découpage, embeddings et recherche hybride0 min
   • 📘 Leçon 4 — Citations et anti-hallucination0 min
   • ✅ Quiz auto-corrigé : Quiz — Mémoire, contexte et RAG6 questions · seuil 5/6
   • 🧪 Lab guidé : Pipeline RAG cité : contexte borné, mémoire durable et réponses sourcées12 étapes · 0 min
   • 📦 Livrable : Note de cadrage — architecture de mémoire et de RAG6 critères de validation

5. Module 5 — Orchestration multi-agents

   0 min

   Un agent seul, même correctement outillé, sature vite dès que la tâche exige **plusieurs compétences distinctes**, des **points de contrôle qualité** ou un **volume de travail parallélisable**. L'orchestration multi-agents consiste précisément à découper une mission en unités de travail confiables, à les confier à des agents spécialisés (planificateur, exécutant, critique) et à garantir qu'aucune délégation ne part sans contrat ni garde-fou. Ce module quitte la logique du « prompt qui marche » pour entrer dans celle du **système** : topologie explicite, rôles bornés, boucles contrôlées. Le fil conducteur est architectural : **l'état appartient à l'orchestrateur, pas aux agents**. Un agent reçoit une unité de travail, un contexte minimal suffisant, une liste d'outils autorisés et un critère d'acceptation ; il renvoie un résultat typé. Le handoff devient alors une transaction observable — appel d'outil nommé, entrée validée par schéma, sortie vérifiable — et non un échange de messages informel impossible à déboguer en production. Nous étudions les deux topologies qui couvrent la quasi-totalité des cas réels : la **supervision** (un orchestrateur en étoile qui dispatche vers des spécialistes) et le **réseau pair à pair** (agents qui se passent le relais directement). Vous implémenterez des boucles de délégation avec plafond de profondeur, budget d'appels et clés d'idempotence, puis une mémoire partagée de type Redis ou PostgreSQL avec verrouillage des écritures concurrentes. Le tout est instrumenté : chaque handoff produit une ligne de trace exploitable. La dernière leçon est un contre-pied volontaire : **quand un seul agent suffit**. La majorité des échecs de projets « multi-agents » viennent d'une orchestration prématurée — coûts multipliés, latence dégradée, bugs de coordination — alors qu'un agent unique avec trois bons outils et un contexte propre aurait livré le résultat en une fraction du temps. Vous saurez chiffrer ce choix avec une grille de décision mesurable, et non par préférence technologique.

   • 📘 Leçon 1 — Les rôles spécialisés : planificateur, exécutant, critique0 min
   • 📘 Leçon 2 — Boucles de délégation et handoffs0 min
   • 📘 Leçon 3 — Coordination et état partagé0 min
   • 📘 Leçon 4 — Quand un seul agent suffit : anti-patterns d'orchestration0 min
   • ✅ Quiz auto-corrigé : Quiz — Orchestration multi-agents6 questions · seuil 5/6
   • 🧪 Lab guidé : Orchestrer une équipe supervisée planificateur / exécutant / critique11 étapes · 0 min
   • 📦 Livrable : Dossier d'architecture — orchestration multi-agents6 critères de validation

6. Module 6 — Évaluation et tests des agents

   0 min

   Un agent qui « marche » sur trois exemples choisis à la main ne marche pas : il donne l'illusion de fonctionner. Ce module installe la discipline qui sépare une démonstration d'un système exploitable — **mesurer avant de livrer**. Vous construirez un jeu d'évaluation représentatif, vous définirez des métriques qui ne pardonnent pas (exactitude, fidélité, respect du format, coût par tâche), puis vous brancherez le tout dans une chaîne d'intégration continue qui refuse toute régression. Le module s'appuie sur l'héritage des modules précédents : les agents outillés du Module 03, la mémoire et le RAG du Module 04, l'orchestration multi-agents du Module 05. Évaluer un agent, c'est mesurer la qualité de sa **réponse finale** mais aussi la qualité de sa **trajectoire** : bons outils appelés, nombre d'étapes raisonnable, appels d'API inutiles évités. Un score global qui ne distingue pas ces deux niveaux ne permet jamais de localiser une régression. Vous verrez ensuite l'évaluation automatique par **LLM-as-judge** : une pratique puissante, bon marché et piégeuse. Un juge non calibré dérive, favorise les réponses longues, se laisse influencer par l'ordre des candidats. Nous verrons comment construire une grille de notation explicite, mesurer l'accord juge/humain (kappa de Cohen), neutraliser les biais de position et de verbosité, et poser des garde-fous budgétaires. Enfin, vous transformerez ces mesures en **tests de non-régression exécutés en CI** : seuils bloquants, comparaison à une baseline versionnée, journalisation des sorties pour le débogage, politique claire en cas d'échec (corriger le prompt, corriger le jeu de données, ou assumer la régression par décision documentée).

   • 📘 Leçon 1 — Construire un jeu d'évaluation représentatif0 min
   • 📘 Leçon 2 — Métriques : exactitude, fidélité, format, coût0 min
   • 📘 Leçon 3 — LLM-as-judge et garde-fous0 min
   • 📘 Leçon 4 — Tests de non-régression en intégration continue0 min
   • ✅ Quiz auto-corrigé : Quiz — Évaluation et tests des agents6 questions · seuil 5/6
   • 🧪 Lab guidé : Harnais d'évaluation et tests de non-régression d'un agent12 étapes · 0 min
   • 📦 Livrable : Dossier d'évaluation et plan de tests de non-régression6 critères de validation

7. Module 7 — Observabilité, coûts et performance

   0 min

   Le module 07 répond à la question qui décide de la survie d'un agent en production : **que s'est-il passé, combien cela a-t-il coûté, et était-ce assez rapide ?** Jusqu'ici, vous avez construit des agents outillés (module 03), dotés de mémoire et de RAG (module 04), orchestrés en équipes (module 05) et validés par un jeu d'évaluation (module 06). Aucun de ces dispositifs ne tient dans la durée sans instrumentation : un agent non tracé n'est ni diagnosticable, ni facturable, ni optimisable. Ce module installe les trois piliers de l'exploitation — traces corrélées, maîtrise de la latence, maîtrise du coût — et les relie à une même source de vérité : la télémétrie par exécution. La première leçon instrumente l'agent avec les conventions sémantiques **OpenTelemetry GenAI** (`gen_ai.operation.name`, `gen_ai.request.model`, `gen_ai.usage.input_tokens`, `gen_ai.tool.name`) et propage un `trace_id` de bout en bout, y compris à travers les files d'attente, les workers et les appels d'outils sortants. La deuxième leçon décompose la latence en étapes mesurables (file d'attente, récupération documentaire, premier token, génération, outils, post-traitement), remplace la moyenne par des percentiles p50/p95/p99 et montre quand la parallélisation fait gagner un facteur 3 et quand elle ne fait que multiplier les erreurs 429. La troisième leçon traite les trois niveaux de cache — cache exact de réponses, cache de prompt côté fournisseur, cache sémantique sur embeddings — avec leurs clés, leurs durées de vie, leurs invalidations et surtout leur risque propre : servir une réponse plausible à une question qui n'est pas la même. La quatrième leçon construit un budget de tokens opposable : comptage avant envoi, plafonds par tâche et par tenant, routage vers un petit modèle avec escalade, compression de contexte, distillation des traces, et arbitrages coût/qualité validés par le jeu d'évaluation du module 06 plutôt que par intuition. Le module se conclut par un quiz de 6 questions (seuil 5/6) et par un livrable directement réutilisable en entreprise : un **dossier d'observabilité et de maîtrise des coûts** d'une dizaine de pages, contenant les SLO de latence, le plan d'instrumentation, la stratégie de cache, le budget de tokens et les arbitrages coût/qualité. Ce dossier sera repris tel quel dans le capstone et sert de base de discussion avec un comité de pilotage ; il prépare également le module 08 (traces et journaux comme sources de données à protéger) et le module 09 (déploiement, alerting, FinOps).

   • 📘 Leçon 1 — Traces distribuées : instrumenter et corréler les appels0 min
   • 📘 Leçon 2 — Latence : décomposer, mesurer, paralléliser0 min
   • 📘 Leçon 3 — Cache exact, cache de prompt et cache sémantique0 min
   • 📘 Leçon 4 — Budget de tokens et arbitrages coût/qualité0 min
   • ✅ Quiz auto-corrigé : Quiz — Observabilité, coûts et performance6 questions · seuil 5/6
   • 🧪 Lab guidé : Instrumenter, accélérer et budgéter un agent de support11 étapes · 0 min
   • 📦 Livrable : Dossier d'observabilité et de maîtrise des coûts7 critères de validation

8. Module 8 — Sécurité, garde-fous et conformité

   0 min

   Un agent qui agit possède des clés, des accès et une mémoire : il devient une surface d'attaque à part entière. Le **module 08** traite la sécurité comme une propriété d'architecture, pas comme un filtre ajouté à la fin. Vous y apprendrez à raisonner en **défense en profondeur** : chaque couche (entrée, modèle, outils, sortie, journalisation) doit rester sûre même si la précédente est contournée. Le module s'ouvre sur l'**injection de prompt** et l'**exfiltration de données**, les deux risques les plus fréquents des applications agentiques (OWASP LLM01, LLM02, LLM06). Nous y construisons des garde-fous concrets : séparation stricte entre consignes et données, validation de schéma, filtrage des sorties, moindre privilège des outils et confirmation humaine sur les actions irréversibles. Les deux dernières leçons basculent vers la **conformité**. D'un côté le **RGPD** : minimisation, base légale, durée de conservation, droit à l'effacement et contrat de sous-traitance avec le fournisseur de modèle. De l'autre l'**AI Act** (règlement UE 2024/1689) : classification par les risques, transparence de l'article 50, documentation technique, journalisation et supervision humaine de l'article 14. Livrable : un **dossier de conformité et de sécurité d'agent**, structuré comme un artefact réellement exploitable en entreprise (registre des traitements, analyse de risques, plan de garde-fous, preuves de tests adversariaux). Ce dossier alimente directement le capstone « Plateforme d'agents en production ».

   • 📘 Leçon 1 — Injection de prompt et exfiltration de données0 min
   • 📘 Leçon 2 — Filtrage des entrées/sorties et moindre privilège des outils0 min
   • 📘 Leçon 3 — Données personnelles et RGPD : minimisation et durée de conservation0 min
   • 📘 Leçon 4 — AI Act : transparence, documentation et supervision humaine0 min
   • ✅ Quiz auto-corrigé : Quiz — Sécurité, garde-fous et conformité6 questions · seuil 5/6
   • 🧪 Lab guidé : Durcir un agent de support contre l'injection et documenter sa conformité12 étapes · 0 min
   • 📦 Livrable : Dossier de conformité et de sécurité de l'agent6 critères de validation

9. Module 9 — Déploiement et industrialisation

   0 min

   Un agent qui fonctionne sur votre poste n'est pas un agent en production. Ce module franchit la dernière marche : transformer un prototype validé en **service exploitable**, avec un contrat d'interface stable, une image reproductible, une chaîne d'intégration continue qui refuse les régressions et une architecture capable d'absorber la charge. Nous partons du contrat d'API : chemins, schémas d'entrée et de sortie, codes d'erreur normalisés, streaming des jetons, idempotence et journalisation des coûts. Nous voyons ensuite la conteneurisation et la séparation stricte des environnements (`dev`, `staging`, `prod`), puis la mise en place d'un pipeline CI/CD où les **tests d'évaluation** deviennent des tests bloquants au même titre que les tests unitaires. La dernière partie traite du passage à l'échelle : files d'attente, workers asynchrones, reprises sur erreur, files de rebut, quotas par locataire et tests de charge. L'objectif n'est jamais de « déployer plus vite », mais de **déployer en sachant revenir en arrière** : chaque mise en production doit être réversible en moins de cinq minutes. Le livrable du module est un **dossier de déploiement et d'industrialisation** : cartographie des environnements, contrat d'API, manifeste de conteneur, pipeline commenté, stratégie de montée en charge, procédure de retour arrière et inventaire des risques. C'est exactement le document qu'un comité de mise en production attend avant d'autoriser un service d'IA à traiter des données réelles.

   • 📘 Leçon 1 — Exposer un agent en API : contrats, erreurs et streaming0 min
   • 📘 Leçon 2 — Conteneurisation et environnements : dev, staging, prod0 min
   • 📘 Leçon 3 — Intégration et livraison continues avec tests d'évaluation0 min
   • 📘 Leçon 4 — Files d'attente, workers asynchrones et montée en charge0 min
   • ✅ Quiz auto-corrigé : Quiz — Déploiement et industrialisation6 questions · seuil 5/6
   • 🧪 Lab guidé : Industrialiser un agent : API, conteneur, CI/CD et workers asynchrones10 étapes · 0 min
   • 📦 Livrable : Dossier de déploiement et d'industrialisation6 critères de validation

10. Module 10 — Mise en production et gouvernance

    0 min

    Ce dernier module referme la boucle du bootcamp : tout ce qui a été construit dans les modules 01 à 09 doit maintenant **tenir en production**, sous contrainte de qualité, de coût et de conformité. Nous partons d'un constat simple : la mise en production d'un agent n'est pas un événement, c'est un **régime de fonctionnement permanent**. Il faut surveiller, alerter, répondre aux incidents, faire évoluer les modèles et les prompts sans casser la confiance des utilisateurs, et rendre des comptes à une organisation qui exige de la traçabilité. La première moitié du module installe les réflexes d'exploitation : définir des **indicateurs de niveau de service** (SLI) mesurables, fixer des objectifs (SLO) et un budget d'erreur, construire un tableau de bord à quatre zones et une politique d'alertes qui ne réveille personne pour rien. Puis vient la gestion des incidents : playbooks par classe de panne, plan de repli testé, mode dégradé, communication de crise et post-mortem sans blâme. Le critère de maturité n'est pas de ne jamais tomber, c'est de **savoir exactement quoi faire quand on tombe**, et de l'avoir déjà répété. La seconde moitié traite la **gouvernance**, qui est le plus souvent le point faible des projets d'IA agentique : registre des modèles et des prompts, versionnement sémantique, empreintes de reproductibilité, revue de changement avec approbation, politique de données et de rétention, procédure de dépréciation planifiée. Vous verrez aussi les compensations à arbitrer entre souveraineté, coût, latence et qualité des modèles, et la notion de chemin de repli fournisseur. Le module se termine par une **feuille de route d'industrialisation** à 90 jours, chiffrée et priorisée (impact sur l'utilisateur, risque, effort), accompagnée de son mode de suivi. C'est aussi le moment du retour d'expérience du bootcamp : les 40 leçons, les 10 labs, le capstone et la certification /100 sont mis en perspective pour transformer dix semaines d'apprentissage en trajectoire professionnelle — avec un plan d'action personnel à 30, 60 et 90 jours.

    • 📘 Leçon 1 — Supervision en production et politique d'alertes0 min
    • 📘 Leçon 2 — Gestion des incidents et plans de repli0 min
    • 📘 Leçon 3 — Gouvernance du cycle de vie des modèles et des prompts0 min
    • 📘 Leçon 4 — Feuille de route d'industrialisation et retour d'expérience du bootcamp0 min
    • ✅ Quiz auto-corrigé : Quiz — Mise en production et gouvernance6 questions · seuil 5/6
    • 🧪 Lab guidé : Superviser, gouverner et industrialiser un agent en production12 étapes · 0 min
    • 📦 Livrable : Dossier de mise en production et de gouvernance de l'agent6 critères de validation