Le composant probabiliste
Pendant toute votre carrière, vos composants étaient déterministes : même entrée, même sortie. Un LLM casse cette promesse. C'est un composant probabiliste, faillible et sensible au phrasé — et l'intégrer demande un nouveau réflexe d'ingénierie.
Un grand modèle de langage (LLM) ne « comprend » pas votre intention et n'exécute pas une spécification. Il prédit la suite la plus plausible d'une séquence de texte, token après token, conditionnée par tout ce que vous lui avez mis sous les yeux. Cette unique mécanique explique presque tous ses comportements : sa fluidité, sa créativité… et ses hallucinations.
La conséquence pratique est immense : la seule chose que vous contrôlez vraiment, c'est ce qui entre dans sa fenêtre de contexte. D'où le déplacement du métier — du code qui dicte chaque étape vers l'ingénierie du contexte et des prompts qui oriente un système intrinsèquement flou.
Un LLM n'est pas une base de données (il invente), ni un moteur de règles (il varie). Il excelle là où l'ambiguïté, le langage et le « presque-juste » sont acceptables — et il faut l'encadrer dès qu'on exige de l'exactitude. Tout l'art consiste à placer le déterminisme (code, validation, outils) là où il faut, et à laisser le modèle faire ce qu'il fait de mieux.
Ce guide suit une progression d'ingénieur : comprendre le modèle, le piloter par le prompt, lui donner le bon contexte, l'autonomiser en agent, puis le mesurer et le durcir pour la production.
Comment « pense » un LLM
Pas besoin d'un cours de deep learning — juste d'un modèle mental assez juste pour prédire le comportement et déboguer.
Tokens, contexte, génération
Le texte est découpé en tokens (morceaux de mots ; ~4 caractères en moyenne). Le modèle lit une séquence de tokens — le prompt — et génère la suite un token à la fois, chaque nouveau token étant rajouté à l'entrée pour produire le suivant (autoregressif). Tout ce qui est visible à un instant T tient dans la fenêtre de contexte, une limite dure exprimée en tokens (entrée + sortie).
Coût, latence et limites se comptent en tokens. La verbosité du prompt et du format (JSON très indenté, répétitions) se paie. Garder le contexte pertinent et compact est une optimisation directe — de prix comme de qualité.
L'échantillonnage (sampling)
À chaque étape, le modèle produit une distribution de probabilités sur le prochain token, puis en tire un. C'est là que naît le non-déterminisme — et que vous reprenez la main via quelques réglages :
| temperature | 0 ≈ déterministe et factuel ; plus haut = plus varié et « créatif » (et plus risqué). Pour de l'extraction ou du code, visez bas. |
| top_p | Échantillonnage par noyau : ne garde que les tokens les plus probables. Ajustez temperature OU top_p, pas les deux. |
| max_tokens | Plafond de longueur de la sortie. Un garde-fou de coût autant qu'un cadrage. |
| stop | Séquences qui interrompent la génération (utile pour délimiter une réponse). |
| seed | Reproductibilité approchée quand le fournisseur le supporte. N'élimine jamais totalement la variance. |
Ce qu'il faut garder en tête
- Hallucination — le modèle produit du plausible, pas du vrai. Sans source dans le contexte, traitez toute affirmation factuelle comme potentiellement inventée.
- Pas de mémoire — chaque appel est sans état. La « mémoire » d'un chatbot, c'est l'historique qu'on lui renvoie à chaque tour.
- Date de coupure — ses connaissances s'arrêtent à sa date d'entraînement ; pour l'actualité, il faut lui fournir l'information (outils, RAG).
- Sensibilité au phrasé — un même besoin formulé différemment donne des résultats différents. D'où l'itération.
- Dégradation en contexte long — au-delà d'un certain remplissage, la qualité baisse et le modèle « perd » des éléments noyés au milieu.
Anatomie d'un prompt
Le principe — Un bon prompt n'est pas une question, c'est une spécification : rôle, tâche, contexte, contraintes, format et exemples.
Les trois rôles d'une conversation
La plupart des API structurent l'échange en messages typés. Comprendre ces rôles, c'est comprendre où mettre quoi :
Qui est le modèle, ses règles durables, le ton, le format attendu. C'est le cadre stable de toute la session.
La demande concrète et le contexte de la tâche (données, documents, exemples). Ce qui varie d'un appel à l'autre.
La réponse du modèle. On peut pré-remplir son début pour forcer un format (par ex. commencer par { pour du JSON).
Les noms varient selon les fournisseurs (system / developer / user), mais l'idée — règles durables vs requête ponctuelle — est universelle.
Les six ingrédients
Un prompt robuste combine, dans cet esprit : un rôle (qui parle et pour qui), une tâche claire, le contexte nécessaire (et délimité), des contraintes explicites, le format de sortie voulu, et si besoin des exemples. Comparez :
Encadrez toujours les données injectées (balises <texte>, triple backticks, etc.). Cela sépare nettement vos instructions du contenu à traiter — meilleure fiabilité, et première barrière contre l'injection de prompt (voir §13).
Techniques qui marchent
Une poignée de techniques expliquent l'essentiel des gains. Toutes découlent du même principe : réduire l'ambiguïté et donner de la matière à raisonner.
Le socle
- Être spécifique — dites le public, le ton, la longueur, le format. Le non-dit sera comblé au hasard.
- Préférer le positif — « réponds en une phrase » est plus efficace que « ne sois pas long ». Dites quoi faire, pas seulement quoi éviter.
- Décomposer — une tâche complexe en sous-étapes (ou en plusieurs appels) bat un méga-prompt fourre-tout.
- Donner une sortie de secours — « si tu ne sais pas, réponds
INCONNU» réduit drastiquement les inventions.
Few-shot : montrer plutôt que décrire
Glisser 2 à 5 exemples d'entrées→sorties idéales vaut souvent mieux qu'un paragraphe d'explications. Le modèle imite le motif : format, ton, niveau de détail. Soignez la cohérence et la diversité des exemples — ils définissent implicitement la tâche.
Chain-of-thought : laisser le modèle réfléchir
Pour les tâches de raisonnement (logique, maths, analyse), demander de raisonner étape par étape avant de conclure améliore nettement la justesse. Le raisonnement intermédiaire occupe des tokens « de réflexion » qui conditionnent une meilleure réponse finale.
Faites écrire le raisonnement dans une zone dédiée (balise <reflexion>) puis la réponse finale séparément. Vous gardez le bénéfice du raisonnement tout en pouvant n'exploiter que la conclusion. Variante puissante : générer plusieurs raisonnements et garder la réponse majoritaire (self-consistency).
Instructions contradictoires ; tout demander en un seul appel ; sur-charger de contexte inutile ; négations en cascade ; politesses et préambules qui diluent la consigne. Et le plus coûteux : ne pas itérer — le premier prompt est rarement le bon.
Sorties structurées
Le principe — Dès qu'une sortie LLM alimente du code, elle doit être structurée et validée — typiquement du JSON conforme à un schéma.
Du texte libre est ingérable par une machine. Demandez un format strict, fournissez le schéma, et — point clé — validez la réponse côté code (puis réparez ou réessayez si elle ne valide pas). Ne faites jamais aveuglément confiance au format.
Côté prompt, soyez explicite : « Réponds uniquement avec un objet JSON conforme au schéma, sans texte autour. » Plusieurs API offrent un mode JSON ou un tool/function calling qui contraint la sortie au schéma — préférez-les quand ils existent.
Si vous contrôlez le message assistant, pré-remplissez-le avec { (ou ```` ```json ````). Le modèle est alors forcé de continuer en JSON dès le premier token — fini les « Bien sûr, voici… » qui cassent le parsing.
Context engineering
Le principe — Au-delà d'un prompt isolé, la vraie discipline est de gérer ce qui occupe la fenêtre de contexte à chaque appel. La pertinence prime sur le volume.
La fenêtre de contexte est une ressource budgétée, pas un sac sans fond. Chaque appel, vous décidez d'y allouer : les instructions système, les définitions d'outils, des connaissances récupérées, l'historique de conversation, et la tâche elle-même.
Mémoire : courte et longue
La mémoire courte, c'est l'historique de conversation qu'on renvoie. Mais il grossit sans fin : on le compacte (résumés glissants, on ne garde que l'essentiel). La mémoire longue vit hors du contexte, dans un magasin externe (base, vecteurs), et on n'en réinjecte que les fragments pertinents au moment voulu — ce qui mène naturellement au RAG.
Mettez dans le contexte le strict nécessaire, au bon moment. Un contexte court et ciblé bat presque toujours un contexte massif « au cas où » — en coût, en latence et en justesse.
RAG — ancrer le modèle dans vos données
Le principe — La génération augmentée par récupération (RAG) récupère les passages pertinents de vos données et les injecte dans le prompt, pour que le modèle réponde sur du factuel à jour et sourcé.
En amont, vos documents sont découpés en passages, transformés en embeddings (vecteurs de sens) et stockés dans un index. À la requête, on encode la question, on récupère les k passages les plus proches, et on les colle au prompt en demandant au modèle de répondre uniquement à partir d'eux et de citer ses sources.
RAG, long contexte ou fine-tuning ?
RAG — connaissances volumineuses, changeantes, qui doivent être sourçables (docs internes, base de connaissances). Le défaut le plus polyvalent.
Tout mettre en contexte — corpus petit et stable qui tient dans la fenêtre. Simple, mais coûteux et sensible au « context rot » s'il grossit.
Fine-tuning — pour ancrer un comportement, un format ou un style, pas pour injecter des faits frais. Coûteux à maintenir ; rarement le premier réflexe.
Si la récupération ramène des passages hors sujet, le modèle répondra quand même — parfois faux, avec aplomb. La qualité d'un RAG, c'est d'abord la qualité de la récupération (découpe, embeddings, filtrage), pas la taille du modèle.
Qu'est-ce qu'un agent
Le principe — Un agent, c'est un LLM dans une boucle : il raisonne, appelle des outils, observe le résultat, et décide de la suite — jusqu'à atteindre son objectif.
Le point de départ est le LLM augmenté : le modèle, plus la capacité d'utiliser des outils, de garder une mémoire et de récupérer de l'information. À partir de là, on peut soit orchestrer ces capacités par du code (un workflow), soit laisser le modèle décider lui-même de l'enchaînement (un agent).
« Agent » n'est pas un objectif en soi. La plupart des besoins se règlent avec un workflow simple et prévisible. Ne passez à un vrai agent autonome que quand le nombre d'étapes est imprévisible et qu'on ne peut pas coder le parcours à l'avance. Commencez toujours par le plus simple qui marche.
Outils & function calling
Le principe — Les outils donnent des mains au modèle : il émet un appel structuré, votre code l'exécute, et vous lui renvoyez le résultat. Le modèle décide quand et comment, vous gardez le contrôle de l'exécution.
Vous décrivez chaque outil par un nom, une description et un schéma de paramètres typé. Le modèle, voyant la demande, peut répondre « j'appelle get_weather(city=…) » au lieu de texte. Vous exécutez la fonction réelle et renvoyez sa sortie comme une observation. Point crucial : le modèle choisit l'outil à partir de sa description — c'est du prompt, soignez-le.
Concevoir de bons outils
- Noms et descriptions sans ambiguïté — précisez le quand utiliser et le quand ne pas. C'est ce qui guide le choix du modèle.
- Paramètres typés et contraints (enums, formats) — moins de liberté = moins d'erreurs.
- Erreurs lisibles en retour — renvoyez un message clair (« ville inconnue, vérifie l'orthographe ») : le modèle s'en sert pour se corriger au tour suivant.
- Granularité juste — peu d'outils nets valent mieux qu'une nuée d'outils qui se chevauchent.
- Idempotence et moindre privilège — surtout pour les outils qui écrivent ou agissent sur le monde (voir §13).
Plutôt que de recâbler chaque intégration, le MCP standardise la façon dont on expose outils et données à un modèle, façon « port USB-C » des capacités. Un serveur MCP (fichiers, base, API interne…) devient utilisable par tout client compatible — pratique pour outiller un agent ou un assistant de code sans tout réécrire.
Workflows vs agents
Le principe — La plupart des systèmes fiables sont des workflows : des chemins orchestrés par du code, où le LLM remplit des cases précises. Les agents autonomes sont l'exception, réservée à l'imprévisible.
Avant d'écrire « un agent », demandez-vous si une composition de briques connues suffirait. Cinq motifs couvrent l'immense majorité des cas :
Systèmes multi-agents
Le principe — Plusieurs agents spécialisés, coordonnés par un orchestrateur, peuvent explorer en parallèle ce qu'un seul ferait en série — au prix d'une complexité et d'un coût bien réels.
Le schéma courant : un orchestrateur découpe un objectif et délègue à des sous-agents (chacun avec son propre contexte, ses outils, son rôle), puis synthétise leurs retours. Cela brille pour des tâches larges et parallélisables — recherche tous azimuts, exploration de pistes indépendantes.
Multi-agents = beaucoup plus de tokens (chaque agent a son contexte), une coordination délicate, des erreurs qui se propagent et une observabilité plus dure. C'est rarement le premier choix. Tant qu'un agent unique bien outillé — ou un workflow — fait l'affaire, restez-y.
Faire tenir un agent en production
- Budgets stricts — nombre maximal d'étapes, de tokens, de temps. Un agent sans limite peut boucler ou exploser la facture.
- Critère d'arrêt clair — comment l'agent sait qu'il a « fini » ? Définissez-le explicitement.
- Observabilité — tracez chaque étape (pensée, appel d'outil, observation). Sans trace, un agent est indéboguable.
- Humain dans la boucle — pour les actions à fort enjeu (paiement, suppression, envoi), exigez une validation.
- Reprise sur erreur — un outil échoue ? Renvoyez l'erreur et laissez l'agent réessayer, plutôt que de tout planter.
Les assistants de codage agentiques (type Claude Code) sont l'exemple le plus abouti aujourd'hui : le terrain est vérifiable (les tests passent ou non, le code compile ou non), ce qui donne à l'agent un signal de feedback solide pour boucler efficacement. Là où l'on peut vérifier automatiquement le résultat, l'agentique devient nettement plus fiable.
Évaluation
Le principe — Sans évaluation, vous pilotez à l'aveugle. Le non-déterminisme rend le « test au feeling » trompeur : il faut mesurer, sur un jeu de cas, de façon répétable.
Un changement de prompt « qui a l'air mieux » peut casser dix autres cas. La parade est la même qu'en dev classique : un jeu d'évaluation (cas représentatifs + résultats attendus + cas limites) qu'on rejoue à chaque modification de prompt, de modèle ou de pipeline.
Comment noter une sortie
| Exact / règles | Quand la réponse est vérifiable mécaniquement (valeur attendue, JSON conforme, regex). Le plus fiable — privilégiez-le. |
| LLM-as-judge | Un modèle note la sortie selon un critère. Puissant pour le qualitatif, mais à calibrer (et à challenger) — un juge faillible évalue un système faillible. |
| Comparaison par paires | « A ou B est meilleure ? » est souvent plus fiable qu'une note absolue, pour comparer deux versions. |
| Revue humaine | L'étalon-or, sur un échantillon. Indispensable pour calibrer les juges automatiques. |
Un prompt de juge efficace est strict et structuré : un critère unique, une sortie binaire, et le doute qui penche vers l'échec —
Versionnez vos prompts, écrivez les évals avant d'optimiser, faites tourner la suite en intégration continue, suivez aussi latence et coût, et tracez les exécutions (observabilité). Un prompt non testé est une régression qui s'ignore.
Coût, latence, fiabilité
Un prototype qui marche une fois n'est pas un système. En production, trois axes décident : le prix, la vitesse, et la robustesse face aux pannes.
Coût & latence
- Dimensionner le modèle — un petit modèle rapide pour le routage, la classification, l'extraction simple ; un gros modèle réservé au raisonnement difficile. Ne payez pas le haut de gamme pour trier des e-mails.
- Cache de prompt — quand un grand préfixe (instructions, contexte) est réutilisé, le mettre en cache réduit fortement coût et latence.
- Streaming — diffuser les tokens au fil de l'eau améliore la latence perçue côté utilisateur.
- Traitement par lot — pour le hors-ligne non urgent, les API batch coûtent moins cher.
Robustesse
- Réessais & repli — gérez timeouts et erreurs ; prévoyez un modèle ou un chemin de secours.
- Valider la sortie — schéma JSON, garde-fous métier, et réparation/relance si la sortie est non conforme. Ne faites jamais confiance aveuglément.
- Déterminisme là où il faut —
temperature 0(et seed) pour les tâches qui doivent être stables ; laissez de la chaleur seulement là où la variété aide. - Épingler les versions — un changement silencieux de version de modèle peut décaler vos sorties. Versionnez modèle et prompts, et rejouez vos évals avant de migrer.
Entourez-le de code déterministe : validation des entrées et sorties, outils fiables, files d'attente, journalisation, repli. Le modèle apporte la souplesse ; votre ingénierie apporte les garanties.
Sécurité
Le principe — Un LLM ne distingue pas vos instructions du contenu qu'il lit. Tout texte entrant — page web, e-mail, document, sortie d'outil — peut contenir des instructions malveillantes : c'est l'injection de prompt.
Contrairement à l'injection SQL, il n'existe pas d'échappement fiable : le « code » et les « données » partagent le même canal, le langage naturel. Le risque devient critique quand un agent a des outils : un document piégé peut lui faire exfiltrer des données ou déclencher des actions.
Réduire la surface d'attaque
- Moindre privilège — l'agent n'a que les outils strictement nécessaires, avec des permissions minimales (lecture seule par défaut).
- Séparer données et instructions — délimitez le contenu non fiable et rappelez au modèle de ne jamais traiter son contenu comme des ordres.
- Valider les sorties d'outils — listes blanches d'actions/domaines, confirmation humaine pour tout ce qui est irréversible ou sortant.
- Sandboxer l'exécution — un outil qui lance du code tourne isolé, sans accès au réseau ni aux secrets.
- Protéger les données — PII : minimisez, masquez, filtrez en entrée comme en sortie.
Considérez toute sortie de LLM — surtout après lecture de contenu externe — comme potentiellement hostile, exactement comme une entrée utilisateur sur le web. La défense ne tient pas dans un « bon prompt » : elle tient dans l'architecture (privilèges, isolation, validation, humain dans la boucle).
Le playbook du tech lead
Sept principes à garder en tête quand votre équipe construit avec des LLM.
Commencer par le plus simple
Un seul prompt avant un workflow ; un workflow avant un agent. N'ajoutez de la complexité que contrainte par le besoin.
Traiter les prompts comme du code
Versionnés, relus, testés. Un prompt en production sans éval est une dette silencieuse.
Construire les évals tôt
Vous ne pouvez pas améliorer ce que vous ne mesurez pas. Le jeu d'éval est votre filet de sécurité.
Dimensionner les modèles
Petit et rapide pour le simple, gros pour le difficile. Le bon modèle au bon endroit.
Concevoir pour l'échec
Le modèle hallucine, varie, peut être manipulé. Encadrez-le de validation, de garde-fous et d'humain quand l'enjeu est fort.
Soigner le contexte
Le bon contenu, au bon moment, en quantité juste. La pertinence bat le volume.
Itérer empiriquement
Ce domaine ne se raisonne pas en théorie : on teste, on mesure, on ajuste. La boucle est la méthode.
Checklists
Avant d'expédier un prompt
Agent ou workflow ?
Antisèche & lectures
Le vocabulaire à épingler — et par où continuer.
| Modèle & prompt | |
| Token | Unité de texte ; tout (coût, contexte, limites) s'y compte. |
| Fenêtre de contexte | Tout ce que le modèle « voit » en un appel (entrée + sortie). |
| Temperature | Aléa de l'échantillonnage : bas = stable, haut = varié. |
| Hallucination | Sortie plausible mais fausse, faute de source. |
| Few-shot | Donner des exemples pour cadrer la tâche par l'imitation. |
| Chain-of-thought | Faire raisonner étape par étape avant de conclure. |
| Contexte & agents | |
| RAG | Récupérer des passages pertinents et les injecter au prompt. |
| Embedding | Vecteur de sens d'un texte, pour la recherche par similarité. |
| Function calling | Le modèle émet un appel d'outil structuré ; le code l'exécute. |
| Agent | LLM en boucle qui raisonne, agit via des outils, observe. |
| Workflow | Enchaînement orchestré par du code, plus prévisible qu'un agent. |
| MCP | Protocole standard pour exposer outils et données à un modèle. |
| Qualité & sécurité | |
| LLM-as-judge | Utiliser un modèle pour évaluer des sorties selon un critère. |
| Injection de prompt | Instructions malveillantes cachées dans le contenu lu par le modèle. |
| Fine-tuning | Ré-entraîner pour un comportement/format — pas pour des faits frais. |
Pour aller plus loin
- La documentation de prompt engineering des fournisseurs de modèles (Anthropic, OpenAI…) — concrète et tenue à jour.
- « Building effective agents » (Anthropic) — la référence sur workflows vs agents et les cinq motifs.
- Les écrits de Simon Willison sur l'injection de prompt et la « triade dangereuse ».
- Côté outillage : explorez le MCP, un framework d'agents, et une brique d'observabilité/évals pour LLM.
Construire avec des LLM, ce n'est pas chercher le prompt magique : c'est de l'ingénierie de système autour d'un composant flou. Commencez simple, mettez le déterminisme là où il compte, mesurez sans relâche, et durcissez avant de passer à l'échelle. Le modèle fournit la souplesse — vous fournissez les garanties. 🧭