Construire avec les LLMs
Livrez du code prêt pour la production : pipelines RAG, intégrations d’API, agents autonomes.
La démo est la partie facile, et c’est là le piège. Un week-end suffit pour un chatbot sur vos PDF qui impressionne toute la salle ; six mois plus tard il n’est toujours pas en production, parce que la démo n’a jamais eu à répondre à une question que les documents ne couvrent pas, ni à encaisser une panne de fournisseur, ni à justifier une facture. Ce module porte sur les quatre-vingt-dix pour cent restants. On construit comme si la chose devait tourner sans que vous la regardiez. Cela veut dire traiter le modèle comme un appel réseau peu fiable au prix variable, pas comme une fonction magique : il va timeouter, il va refuser, il va rendre quelque chose qui viole le schéma demandé, et c’est votre code qui décide de la suite. Cela veut dire accepter que la plupart des échecs RAG sont des échecs de récupération : on n’a jamais donné la réponse au modèle, aucun prompt ne pouvait le sauver. Cela veut dire des agents volontairement ennuyeux, avec une limite d’étapes dure et un plafond de dépense, parce qu’une boucle autonome avec budget est un produit et que sans budget c’est un incident. Et cela veut dire le fine-tuning en dernier, après avoir prouvé preuves à l’appui que le prompting et la récupération n’y arrivent vraiment pas — car la plupart des équipes commencent par là et paient des mois pour apprendre ce qu’un jeu de test leur aurait dit en un jour.
Prérequis
- À l’aise en Python — ce module est destiné aux ingénieurs
- Avoir déjà appelé une API REST et géré ses erreurs
- Git, la ligne de commande, et avoir déjà déployé quelque chose
- Le module 02 ou une expérience équivalente en prompting
Ce que vous saurez faire après
- Intégrer des API de modèles hébergés et open-source derrière une interface interchangeable
- Gérer timeouts, limites de débit, refus et violations de schéma sans se réveiller à 3 h du matin
- Construire un pipeline RAG et le déboguer au niveau de la récupération, là où est le bug
- Livrer un agent outillé, avec une limite d’étapes et un plafond de dépense réellement appliqués
- Décider preuves à l’appui si le fine-tuning se justifie — et conclure le plus souvent que non
- Tenir un budget coût, latence et qualité pour une fonctionnalité IA en production
Séances
API de modèles et couche fournisseur
Vous intégrerez des fournisseurs hébergés et des modèles open-source derrière une interface unique que vous contrôlez, parce que dépendre d’un seul vendeur doit être une décision assumée, pas une découverte en pleine panne. Chaque appel est un appel réseau peu fiable au prix variable — on construit donc le retry, le timeout, le fallback et le compteur de coût dès le premier jour, pas après le premier incident.
Au programme
Des pipelines RAG qui survivent aux vrais documents
Les vrais documents sont scannés, mal formatés, moitié en français moitié en arabe, et pleins de tableaux que le chunking détruit. Construire le pipeline prend un après-midi ; lui faire récupérer le bon passage prend tout le reste du module. L’habitude que vous emporterez : quand la réponse est fausse, regardez ce qui a été récupéré avant de toucher au prompt.
Au programme
Agents et usage d’outils
Un agent est une boucle qui décide quelle fonction appeler ensuite : c’est toute l’idée et tout le danger. Vous donnerez de vrais outils à un modèle, puis passerez l’essentiel de votre énergie sur l’échafaudage ennuyeux : limites d’étapes, plafonds de dépense, idempotence, et un contrôle humain devant tout ce qui est destructeur. Une boucle sans borne avec vos clés d’API, ce n’est pas de l’autonomie, c’est un incident à retardement.
Au programme
Fine-tuning et personnalisation de modèles
Le fine-tuning est la chose la plus demandée et la moins justifiée de cette liste. Il apprend une forme à un modèle, pas un fait — donc si votre problème est un manque de connaissance, c’est la récupération qui répond, et le fine-tuning vous donnera un modèle qui se trompe avec assurance dans votre style maison. Vous le ferez proprement une fois, et apprendrez surtout à reconnaître les cas où c’est le mauvais outil.
Au programme
Mettre en production, évaluer et vivre avec
La fonctionnalité n’est pas finie quand elle marche ; elle est finie quand quelqu’un peut être réveillé pour elle et savoir quoi faire. Vous construirez l’éval hors-ligne qui conditionne un déploiement, le tracing qui permet de rejouer une mauvaise réponse des mois plus tard, et les garde-fous qui empêchent un champ de formulaire de réécrire votre prompt système. C’est la différence entre une pièce de portfolio et un produit.
Au programme
Livrer un produit IA prêt pour la production : une application déployée combinant récupération et au moins un agent outillé, avec une suite d’évals hors-ligne conditionnant les déploiements, un budget coût et latence documenté, du tracing sur chaque appel, et une analyse honnête des modes de défaillance que vous avez choisi d’assumer.
Proposé dans
Questions
Pourquoi ce module est-il réservé aux ingénieurs ? Un bon builder no-code peut-il suivre ?
Honnêtement, non — et on préfère le dire que prendre votre argent. Ce module, c’est huit semaines à écrire du Python, lire des stack traces et déployer des services ; sa valeur est précisément dans ce qu’une plateforme no-code vous cache, c’est-à-dire ce qui casse en production. Si votre objectif est d’automatiser du travail plutôt que de construire du logiciel, le module d’automatisation vous ira mieux et vous en sortirez avec quelque chose qui tourne. Si votre objectif est de construire le produit lui-même, c’est celui-ci.
Dois-je fine-tuner un modèle sur les données de mon entreprise ?
Presque certainement non, et ce module vous montrera pourquoi avec des chiffres plutôt qu’un avis. Le fine-tuning apprend une forme à un modèle — un ton, un format, une manière de répondre — pas des faits. Si vous voulez qu’il connaisse vos procédures ou votre catalogue, c’est de la récupération : moins cher, mis à jour dès que le document change, et capable de citer sa source. Les équipes se ruent sur le fine-tuning parce que ça fait sérieux, puis passent des mois à découvrir qu’un bon prompt et une couche de récupération correcte avaient déjà réglé le problème. On le traite sérieusement et vous le ferez une fois — surtout pour savoir reconnaître les cas où c’est vraiment la réponse.
Mon chatbot RAG marche sur mes PDF de test mais s’effondre sur les vrais documents. Qu’est-ce que ce module va changer ?
Il va changer l’endroit où vous regardez. Presque tout le monde dans votre situation règle le prompt alors que le problème est en amont : le bon passage n’a jamais été récupéré, donc on a demandé au modèle de répondre à partir de rien et il a fait ce qu’il fait toujours — inventer du plausible. Les vrais documents sont scannés, multilingues, pleins de tableaux et se découpent mal, et la recherche vectorielle pure rate discrètement les termes exacts comme un numéro de référence. Vous apprendrez à inspecter ce qui a été récupéré avant de toucher au reste, à combiner recherche par mots-clés et vectorielle, à reranker, et à faire dire au système qu’il ne sait pas plutôt que de deviner. C’est généralement ce dernier point qui le rend déployable.
Autres modules
Prêt à suivre ce module ?