Applications LLM
Combler l’écart entre la démo qui impressionne et le produit qui tient.
Une démo LLM qui marche se construit en un après-midi. Un produit LLM qui marche prend des mois, et c’est dans cet écart que la plupart des équipes s’enlisent. Ce parcours porte précisément sur cet écart. Vous commencez par la surface d’API, sérieusement : pas seulement l’appel de chat, mais la sortie structurée, le function calling, le streaming et les sémantiques de retry qui maintiennent une requête en vie quand un fournisseur hoquette. Vient ensuite la récupération, où la leçon honnête est que le RAG est un problème de recherche d’information déguisé en machine learning : votre découpage, vos métadonnées et votre ranking décident de la qualité des réponses, tandis que la base vectorielle sur laquelle vous avez agonisé ne décide presque rien. Vous construirez l’évaluation avant les fonctionnalités, car une application LLM sans jeu de test se dégrade en silence et personne ne s’en aperçoit avant un client. Et vous traiterez le coût et la latence comme des contraintes de conception dès le premier jour, pas comme un nettoyage final : ils déterminent quelles architectures sont seulement possibles — un pattern élégant à dix requêtes par jour est une faillite à dix mille. Ce que vous n’aurez pas : une visite guidée des frameworks. Ils changent tous les trimestres et masquent exactement ce qu’il faut voir quand ça casse. Savoir pourquoi un appel a échoué, ce qu’on peut mettre en cache et quand cesser de réessayer, ça ne périme pas.
Ce que vous allez apprendre
Prérequis
- À l’aise en Python ou TypeScript
- Bases des APIs HTTP et du JSON
- Git et un vrai éditeur de code
- Fondamentaux du prompt engineering
Débouchés
- Ingénieur applications LLM
- Ingénieur produit IA
- Ingénieur RAG / recherche
- Développeur full-stack spécialisé IA
Phases
Phase 1 — La surface d’API
Cesser de voir le modèle comme un chatbot. Le traiter comme une fonction distante peu fiable qu’il faut encadrer.
Durée estimée · 6-8 semainesAppeler le modèle en ingénieur
Chaque appel LLM est une requête réseau vers un service lent, limité en débit, parfois faux, et facturé au token. Une fois cela intégré, la moitié de vos décisions d’architecture se prennent d’elles-mêmes. Vous verrez l’anatomie d’une requête, la comptabilité des tokens, un backoff qui n’amplifie pas une panne, et les timeouts qui empêchent un appel lent d’emporter toute une page.
Sujets couverts
Ce que vous allez construire
- Écrire un wrapper client avec timeout, backoff avec jitter et plafond de retries — le prouver par un test d’injection de fautes
- Instrumenter chaque appel avec tokens entrants, sortants et latence, puis produire un rapport de coût d’une page sur une semaine de trafic
- Couper volontairement un endpoint et montrer que l’app dégrade vers un message utile plutôt qu’une stack trace
Sortie structurée et function calling
Dès que votre app doit faire quelque chose de la réponse, la prose devient un handicap. La sortie structurée transforme le modèle en composant composable. La subtilité : un schéma est un prompt — noms de champs, enums et descriptions changent la sortie autant qu’une instruction, et un modèle qui choisit le mauvais outil lit généralement une mauvaise description, il ne raisonne pas mal.
Sujets couverts
Ce que vous allez construire
- Convertir une fonctionnalité en texte libre vers un schéma validé et en piloter un vrai composant d’UI
- Construire une couche de validation qui journalise chaque payload rejeté, puis corriger l’échec dominant en modifiant le schéma, pas le prompt
- Donner au modèle quatre outils aux noms volontairement flous, mesurer le taux de mauvais outil, les renommer et remesurer
Phase 2 — Récupération & contexte
Faire répondre le modèle depuis vos données — et le faire dire quand il ne peut pas.
Durée estimée · 8-10 semainesUn RAG qui récupère vraiment
Presque tout RAG médiocre est médiocre en récupération, pas en génération — et presque toutes les équipes déboguent la génération. Évaluez le retriever séparément : si le bon passage n’est pas dans les premiers résultats, aucun prompt ne sauvera la réponse. La recherche hybride et un reranker battent le prompting malin quasiment à chaque fois, pour une fraction de l’effort.
Sujets couverts
Ce que vous allez construire
- Construire un jeu de test de 50 requêtes avec passages corrects connus et rapporter le recall@5 avant de toucher au moindre prompt
- Livrer une recherche hybride sur un corpus et montrer l’écart de recall face au vectoriel seul
- Casser votre propre chunker : trouver trois documents où il coupe en plein raisonnement, corriger la stratégie et remesurer
Ancrage, citations et refus
Une réponse fausse et assurée coûte plus cher que pas de réponse. L’objectif d’ingénierie : un système qui pointe la phrase utilisée et décline quand le contexte n’étaye pas l’affirmation. Le refus est une fonctionnalité — celle que les product managers refusent et que les utilisateurs finissent par saluer. Vous traiterez aussi le cas que personne n’anticipe : deux documents qui se contredisent.
Sujets couverts
Ce que vous allez construire
- Livrer une UI de réponse où chaque phrase renvoie au span source exact qui l’étaye
- Ajouter 15 questions sans réponse au jeu d’évaluation et obtenir un refus sur toutes, sans devenir inutile sur les autres
- Appliquer les permissions par utilisateur au moment de la récupération et écrire le test qui prouve qu’un utilisateur ne peut pas faire remonter un document qui ne lui appartient pas
Phase 3 — Le produit
Livrer un produit que les gens utilisent, puis le garder bon et abordable pendant qu’ils l’utilisent.
Durée estimée · 8-10 semainesStreaming, latence et sensation d’usage
Les utilisateurs ne vivent pas la latence totale, ils vivent l’attente. Le streaming est une décision produit déguisée en détail de transport : il rend un système lent agréable, et il fait arriver une mauvaise réponse plus vite. Sachez quand ne pas streamer — personne ne veut regarder une écriture en base apparaître token par token.
Sujets couverts
Ce que vous allez construire
- Diviser par deux le time-to-first-token de votre écran le plus lent et le prouver par des percentiles avant/après, pas des moyennes
- Streamer un objet structuré et afficher chaque champ dès qu’il est complet, sans casser sur un flux tronqué
- Implémenter l’annulation de bout en bout et mesurer les tokens que vous cessez de payer sur une semaine
Évaluation, coût et mise en production
C’est l’étape qui décide si votre app est encore vivante dans un an. Une suite d’évaluation en CI est la seule chose entre vous et une régression silencieuse livrée un vendredi. Le coût par tâche réussie — pas par appel — est la métrique qui dit la vérité : un modèle bon marché qui exige trois tentatives n’est pas bon marché.
Sujets couverts
Ce que vous allez construire
- Brancher une suite d’évaluation en CI pour qu’une pull request faisant chuter la qualité sous un seuil ne puisse pas être mergée
- Réduire de 40 % le coût par tâche réussie via cache et routage, à score d’évaluation constant — publier les deux chiffres
- Faire un vrai rollback : livrer derrière un flag une version volontairement moins bonne, la détecter depuis vos dashboards, revenir en moins de cinq minutes
Questions
Ai-je besoin d’une base de données vectorielle ?
Presque certainement pas dès le premier jour. Une extension vectorielle sur la base que vous exploitez déjà vous mènera plus loin que la plupart ne l’imaginent, et garder vos documents et leurs permissions au même endroit élimine toute une famille de bugs de synchronisation. Le store vectoriel est rarement le goulot : le chunking, les métadonnées et le ranking le sont. Les équipes qui migrent vers un store dédié avant d’avoir mesuré leur recall découvrent en général que la qualité n’a pas bougé — parce que le problème n’était pas l’index. Ajoutez-en un quand vos propres mesures — volume, latence, ou un filtrage que vous ne savez pas exprimer — vous le demandent.
Le RAG est-il obsolète maintenant que les fenêtres de contexte sont énormes ?
Non, et l’argument confond « ça rentre » avec « ça marche ». Enfourner tout un corpus dans le contexte est plus lent, bien plus cher par requête, et moins précis : la justesse se dégrade quand le passage pertinent est noyé parmi des milliers d’autres. Cela casse aussi ce dont un vrai produit a besoin : permissions par utilisateur, fraîcheur, capacité à dire de quel document vient une réponse. Les grandes fenêtres sont réellement utiles, mais elles changent surtout la forme du problème : vous récupérez moins de chunks, plus gros, plutôt que beaucoup de petits. Le contexte long masque un mauvais retriever, il ne le répare pas.
Quel framework apprendre en premier ?
Aucun. Construisez votre première application avec de simples appels HTTP et vos cent lignes de colle. Ce n’est honnêtement pas difficile, et ça vous montre où sont les coutures : ce que coûte un retry, ce que le modèle reçoit vraiment, où part la latence. Les développeurs qui démarrent dans un framework livrent une démo en un jour, puis ne savent pas expliquer un bug en production, parce que la partie intéressante est derrière une abstraction qu’ils n’ont jamais ouverte. Une fois l’avoir fait à la main, adoptez un framework en connaissance de cause : vous le jugerez sur ce qu’il masque, pas sur ce qu’il promet, et vous garderez la liberté de le quitter quand il cessera de convenir.
Parcours liés
Envie de suivre ce parcours avec un coach et une cohorte ?
Découvrir la 212AY Academy →