Aller au contenu
Développement medium

Formation IA Générative : LLM, RAG et Agents

10 min de lecture

logo python

Cette section est une formation à l'IA générative avec Python, mais avec un angle assumé : celui d'un ingénieur infrastructure et sécurité. L'objectif n'est pas seulement d'appeler une API, c'est de comprendre, servir, sécuriser et exploiter des applications IA — du modèle de langage jusqu'au déploiement en production, en open source et auto-hébergeable. La section rassemble une trentaine de guides pratiques, chacun testé en lab. Que vous débutiez sur les LLM ou que vous cherchiez à les mettre en production, vous trouverez votre point d'entrée parmi les quatre parcours ci-dessous.

  • Expliquer comment fonctionne un LLM : tokens, attention, inférence, quantification.
  • Faire tourner un modèle en local et le servir via une API, sur CPU comme sur GPU.
  • Choisir un backend d'inférence selon votre matériel et votre charge.
  • Construire un RAG complet, de l'ingestion des documents à la restitution.
  • Industrialiser : proxy, observabilité, sécurité, agents et coûts.

La section s'organise en quatre parcours. Ils se suivent dans l'ordre pour un apprentissage progressif, mais chacun se lit aussi indépendamment selon votre besoin.

Avant de manipuler un outil, il faut un modèle mental correct. Ce parcours pose les fondations : ce qu'est un LLM, comment il génère du texte, ce que coûte l'inférence, et comment un modèle se compresse.

Comprendre ne suffit pas : il faut faire tourner un modèle. Ce parcours couvre l'appel d'un LLM depuis Python, l'exécution locale et le serving GPU de production.

Un LLM ne connaît que ses données d'entraînement. Le RAG (Retrieval-Augmented Generation) lui donne accès à vos documents. Ce parcours suit la chaîne complète : un RAG raté vient presque toujours de l'ingestion ou du découpage, rarement du choix de la base vectorielle.

Un prototype qui marche sur votre poste n'est pas une application exploitable. Ce parcours traite le passage à l'échelle : routage multi-modèles, interface, et — sujets en cours d'enrichissement — observabilité, évaluation, sécurité et agents.

Inutile d'être expert. Quelques bases suffisent pour suivre les exemples et réaliser les labs.

  • Python : variables, boucles, conditions, fonctions. Tout est couvert dans la section Python du site.
  • Ligne de commande : les commandes de basecd, ls, mkdir, navigation dans un terminal.
  • Environnements virtuels : savoir isoler des dépendances avec venv et pip.

Côté outils, prévoyez Python 3.12, un éditeur (VSCode convient bien) et Docker pour les services self-hosted. Toute la section reste utilisable hors ligne, sur CPU ou GPU, et sans cloud commercial.

Le contenu sert trois profils, à des profondeurs différentes.

  • Débutant : commencez par le parcours « Comprendre », puis « Exécuter ». L'objectif est de faire tourner votre premier LLM et de saisir ce qui se passe.
  • Intermédiaire : vous savez appeler un LLM. Visez « Construire un RAG » et le comparatif des backends pour passer du script jouet à une application structurée.
  • Avancé : votre enjeu est la production. Le parcours « Industrialiser », le serving GPU et la quantification sont pour vous.

Mon parti pris : l'IA générative vue côté infra

Section intitulée « Mon parti pris : l'IA générative vue côté infra »

La plupart des formations IA s'arrêtent à « comment appeler OpenAI ». C'est le début, pas la fin. Ce qui m'intéresse — et ce que je pratique — c'est ce qui vient après : faire tenir un modèle sur le bon matériel, mesurer son débit réel, le sécuriser, le mettre en production sans se ruiner ni exposer ses secrets.

C'est pourquoi cette section privilégie l'open source self-hostable. Non par dogmatisme, mais parce qu'un ingénieur infra a besoin de comprendre et contrôler sa pile — pas de la louer en boîte noire. Tous les outils présentés tournent sur votre machine ou votre serveur.

  • Comprendre avant d'outiller. Choisir entre vLLM et llama.cpp sans savoir ce qu'est le prefill ou le KV cache, c'est choisir au hasard. Les parcours commencent toujours par les concepts.
  • Mesurer, pas croire. Les chiffres de débit et de qualité de ces guides sont relevés en lab, pas recopiés d'une plaquette commerciale. Un bench reproductible vaut mille promesses.
  • L'ingestion fait le RAG. Un RAG décevant se répare presque toujours en amont — extraction, nettoyage, découpage — pas en changeant de base vectorielle.
  • La sécurité dès le départ. Prompt injection, fuite de secrets dans les prompts, agent trop permissif : ces risques se traitent à la conception, pas après l'incident.
  • Le coût est une métrique d'ingénierie. Tokens, cache, choix du modèle : une application LLM se pilote au budget comme n'importe quel système.
  • Coller du code LLM sans le comprendre. Un exemple trouvé en ligne qui « marche » cache souvent un coût, une latence ou une faille que vous découvrirez en production.
  • Mettre un agent en production sans garde-fous. Un agent qui exécute des actions doit avoir des permissions limitées, une validation humaine sur les opérations sensibles et un périmètre clair. Un agent DevOps n'est jamais un script root avec un LLM au volant.
  • Croire qu'un gros modèle résout tout. Un modèle plus gros est plus lent et plus cher. Souvent, un modèle moyen bien outillé (RAG, bons prompts) fait mieux qu'un géant lâché seul.
  • Envoyer n'importe quoi dans un prompt. Secrets, données personnelles, code propriétaire : ce qui entre dans un prompt peut ressortir, être journalisé, ou servir ailleurs. Traitez le prompt comme une frontière de confiance.

Faut-il un GPU pour suivre cette formation ? Non. Toute la partie « Comprendre » et une grande part d'« Exécuter » tournent sur CPU (Ollama, llama.cpp). Le GPU ne devient nécessaire que pour le serving haute performance.

Faut-il connaître le machine learning ? Non. Cette section porte sur l'usage des modèles génératifs, pas sur leur entraînement. Des bases de Python suffisent.

RAG ou fine-tuning pour mes données ? Dans la grande majorité des cas, RAG : plus simple, moins cher, et les données restent à jour. Le fine-tuning vise surtout le style ou un format de sortie, pas l'apport de connaissances.

Quel modèle local choisir pour commencer ? Un modèle 7B à 14B quantifié (Qwen, Llama) via Ollama est un excellent point de départ : il tient sur un poste correct et suffit pour apprendre.

Ce site vous est utile ?

Sachez que moins de 1% des lecteurs soutiennent ce site.

Je maintiens +700 guides gratuits, sans pub ni tracing. Aujourd'hui, ce site ne couvre même pas mes frais d'hébergement, d'électricité, de matériel, de logiciels, mais surtout de cafés.

Un soutien régulier, même symbolique, m'aide à garder ces ressources gratuites et à continuer de produire des guides de qualité. Merci pour votre appui.

Abonnez-vous et suivez mon actualité DevSecOps sur LinkedIn