Jour 1
Prendre en main Studio et le catalogue de modèles
La console Studio : espaces, clés d'API, cloisonnement des environnements, suivi de consommation
Le playground : éprouver une intention avant d'écrire la moindre ligne de code
Le catalogue de modèles : familles généralistes, code, vision, audio, reconnaissance de documents
Arbitrer un choix de modèle : coût au jeton, latence, fenêtre de contexte, licence
Premier appel depuis le SDK et depuis un client HTTP brutTravaux pratiquesObjectif :Savoir configurer un espace Studio et émettre un premier appel authentifié depuis son code.
Description :Chaque participant crée son espace, génère une clé dédiée à la formation et l'isole dans une variable d'environnement plutôt que dans le dépôt. Il émet ensuite la même requête par trois voies : le playground, le SDK et un appel HTTP brut ; et compare les réponses obtenues. Que révèle l'appel HTTP brut sur la structure de la réponse que le SDK masquait ? Le formateur fait ensuite rejouer la requête sur trois modèles distincts pour mesurer l'écart de latence et de coût. La validation repose sur un tableau comparatif renseigné par le participant et sur l'absence de toute clé en clair dans son dépôt.Maîtriser la complétion conversationnelle
Structure d'une requête : rôles système, utilisateur et assistant, historique transmis
Les paramètres qui comptent : température, nombre de jetons maximal, pénalités, graine aléatoire
Restitution en flux continu et intégration dans une interface
Gérer la fenêtre de contexte : troncature, résumé, fenêtre glissante
Compter les jetons et estimer le coût d'une requête avant de l'envoyerTravaux pratiquesObjectif :Être capable de construire un échange multi-tours à coût maîtrisé et restitué en flux continu.
Description :Les participants développent un module d'échange conservant l'historique de conversation sur plusieurs tours, puis y ajoutent la restitution en flux continu dans une interface minimale. Ils instrumentent ensuite le module pour journaliser le nombre de jetons consommés et le coût estimé à chaque appel. À partir de combien de tours l'historique transmis coûte-t-il plus cher que la réponse elle-même ? Le formateur impose une contrainte de budget par conversation, obligeant à implémenter une stratégie de troncature ou de résumé. Les acquis sont validés par un module qui respecte le budget imposé sur une conversation de vingt tours.Jour 2Garantir des sorties exploitables par le code
Les limites du texte libre : pourquoi une analyse de la réponse par expression régulière finit toujours par casser
Les sorties structurées : imposer un schéma et obtenir une réponse conforme
Concevoir un schéma robuste : champs optionnels, énumérations, valeurs manquantes
Valider côté application malgré la garantie du modèle, et traiter les cas non conformes
Capitaliser ses invites sous forme de briques réutilisables dans StudioTravaux pratiquesObjectif :Savoir obtenir du modèle une sortie directement consommable par le code appelant, sans analyse fragile.
Description :Les participants partent d'une extraction de données réalisée en texte libre et constatent son taux d'échec sur un jeu de vingt documents hétérogènes. Ils la réécrivent avec un schéma de sortie structurée, puis mesurent le nouveau taux d'échec sur le même jeu. Quels cas continuent d'échouer malgré un schéma imposé, et pourquoi le schéma ne suffit-il pas à les couvrir ? Le formateur injecte alors trois documents volontairement dégradés (incomplets, mal numérisés, hors sujet) pour éprouver la robustesse du dispositif. La validation repose sur un module qui traite les vingt-trois documents sans jamais lever d'exception non gérée.Étendre le modèle par l'appel d'outils
Le principe de l'appel d'outils : le modèle demande, l'application exécute
Déclarer un outil : nom, description, schéma de paramètres, et l'importance de la description
La boucle d'exécution : réception de la demande, appel, restitution du résultat, poursuite
Sécuriser la boucle : validation des paramètres, limitation du nombre d'itérations, outils en lecture seule
Diagnostiquer un outil que le modèle n'appelle jamais, ou appelle à contretempsTravaux pratiquesObjectif :Être capable d'exposer des outils au modèle et de sécuriser la boucle d'appel qui en résulte.
Description :Chaque participant expose deux outils à son application, l'un consultant une source de données locale et l'autre effectuant un calcul métier. Il implémente la boucle complète, puis observe dans ses journaux quels outils le modèle sollicite réellement et dans quel ordre. Pourquoi une simple reformulation de la description d'un outil change-t-elle radicalement la fréquence à laquelle le modèle y recourt ? Le formateur introduit ensuite un outil dont l'exécution échoue systématiquement, afin de faire implémenter une sortie de boucle propre. La validation repose sur une boucle qui se termine toujours, y compris face à un outil défaillant.Jour 3Traiter du volume et filtrer les contenus
Le traitement par lots : quand l'asynchrone coûte moins cher que le temps réel
Téléverser et gérer les fichiers exploités par les traitements
Les limites de débit : les reconnaître, les respecter, implémenter une reprise avec attente progressive
Modération des entrées et des sorties : où placer le filtre et que faire d'un contenu rejeté
Idempotence et reprise sur incident dans un traitement de masseTravaux pratiquesObjectif :Savoir traiter un volume important de requêtes en respectant les limites de débit et en filtrant les contenus.
Description :Les participants soumettent un lot de plusieurs centaines de documents en traitement asynchrone et comparent le coût et la durée obtenus à ceux d'un traitement séquentiel en temps réel. Ils implémentent une reprise avec attente progressive, puis interposent une étape de modération sur les entrées et les sorties. Comment reprendre un traitement de masse interrompu à mi-parcours sans retraiter, ni facturer deux fois, ce qui l'avait déjà été ? Le formateur interrompt volontairement un lot en cours d'exécution pour éprouver le mécanisme de reprise. La validation repose sur un traitement relancé qui produit exactement le même résultat final, sans doublon.Industrialiser et mettre en production
Observabilité : tracer les appels, corréler une réponse à sa requête, conserver ce qui sert au diagnostic
Suivre le coût par fonctionnalité et non globalement, pour savoir quoi optimiser
Gérer les clés et les environnements : rotation, cloisonnement, révocation
Les points d'entrée régionaux européens et les fonctionnalités auxquelles ils font renoncer
Faire évoluer un modèle en production : versions, dépréciations, tests de non-régressionTravaux pratiquesObjectif :Savoir instrumenter une application et arbitrer son architecture au regard d'une contrainte de résidence des données.
Description :Les participants instrumentent l'application construite pendant les trois jours afin d'en suivre la latence, le coût et le taux d'erreur par fonctionnalité. Ils rédigent ensuite un test de non-régression capable de détecter qu'un changement de version de modèle a dégradé le résultat métier. Que faut-il revoir dans cette application pour qu'elle s'exécute sur un point d'entrée régional européen, et qu'y perd-on ? La discussion finale confronte les architectures obtenues et fait apparaître les compromis retenus par chacun. La validation repose sur un tableau de bord fonctionnel et sur une note d'architecture d'une page justifiant les choix de déploiement.