J'ai vu une facture de 200 $ apparaître sur un compte AWS du jour au lendemain.
Pas à cause d'un crash système.
Un agent a tourné en boucle pendant six heures sans condition d'arrêt, appelant l'API OpenAI à chaque itération.
Tous les tableaux de bord indiquaient qu'il était en bonne santé.
Personne n'a rien remarqué jusqu'à ce que la facture tombe le matin.
Voilà ce qui arrive quand on construit des systèmes d'IA sans comprendre comment ils fonctionnent réellement.
La plupart des gens apprennent l'ingénierie de l'IA à l'envers.
Installer une bibliothèque. Suivre un tutoriel. Appeler une API. Obtenir un résultat. Se sentir en progrès.
Puis quelque chose casse d'une manière incompréhensible.
Ils changent des nombres au hasard jusqu'à ce que ça s'arrête.
Ce n'est pas de l'ingénierie. C'est de l'espoir avec un clavier.
Voici les 6 concepts qui résolvent ce problème.
La phrase qui explique tout
Chaque système d'IA, aussi complexe soit-il, n'est que :
Mémoire (RAG) + Réflexion (LLM + jetons) + Actions (Agents) + Mesure (Évaluations)
…assemblés via l'ingénierie du contexte.
C'est tout le domaine.
Tout ce qui suit ne fait que détailler ce que chaque partie signifie réellement.
1. Les jetons et la fenêtre de contexte
Les LLM ne lisent pas des mots. Ils lisent des morceaux appelés jetons.
« ingénierie » → 1 jeton
« incroyable » → 2 jetons. Les espaces et la ponctuation comptent aussi.
Chaque modèle a une fenêtre de contexte — une limite stricte du nombre de jetons qu'il peut contenir à la fois.
→ Claude : 200 000 jetons
→ GPT-5 : 400 000 jetons
Considérez-la comme un tableau blanc dans une salle de réunion.
Le modèle ne travaille qu'avec ce qui est actuellement sur le tableau.
Quand le tableau est plein, les anciennes notes sont effacées pour faire de la place.
Le modèle ne perd pas sa capacité à réfléchir.
Il perd l'accès aux informations antérieures.
Pourquoi cela casse les systèmes en production :
→ Les jetons coûtent de l'argent — chaque appel API facture par jeton d'entrée et de sortie
→ Les longs historiques de discussion remplissent rapidement la fenêtre
→ Quand le contexte est saturé, les instructions précédentes sont silencieusement ignorées
→ Ce qui entre dans le contexte est une décision d'ingénierie, pas une valeur par défaut
L'échec qui le prouve :
Une équipe a construit un agent de support client avec l'historique complet de 12 mois de chat comme contexte à chaque requête.
Cela fonctionnait parfaitement en test avec 5 interactions.
En production, après 50 interactions, l'agent a commencé à ignorer ses propres instructions système.
Les instructions étaient toujours là.
Elles étaient enterrées sous 80 000 jetons d'historique de conversation.
Le modèle avait effectivement cessé d'y prêter attention.
La solution n'était pas un meilleur modèle.
C'était de résumer l'historique plus ancien pour garder la fenêtre ciblée.
La vérité inconfortable :
La plupart des « échecs d'ingénierie de prompt » sont en fait des échecs de jetons et de fenêtre de contexte déguisés.
Les ingénieurs blâment le prompt alors que le vrai problème est que l'instruction critique se trouve à la ligne 3 d'un contexte de 500 lignes, et que le modèle a cessé de la pondérer.
2. Les plongements et la recherche vectorielle
Les plongements transforment le sens en nombres, afin que la « similarité » puisse être calculée mathématiquement.
Le problème qu'ils résolvent :
Vous avez 50 000 documents. Un utilisateur pose une question. Vous avez besoin des 3 plus pertinents — sans lire les 50 000 à chaque fois.
La recherche par mots-clés échoue ici.
Si le document dit « automobile » et que l'utilisateur demande « voitures », la recherche par mots-clés ne trouve rien.
Non pas parce que la réponse n'est pas là. Mais parce que les mots ne correspondent pas.
Les plongements résolvent cela différemment.
Un modèle de plongement convertit le texte en un vecteur — une liste de nombres représentant le sens dans un espace mathématique.
Texte sémantiquement similaire → vecteurs numériquement similaires.
« voiture » et « automobile » → proches l'un de l'autre
« voiture » et « photosynthèse » → éloignés
Comment la recherche vectorielle fonctionne réellement :
- Chaque document est converti en vecteur et stocké
- La question de l'utilisateur devient également un vecteur
- Le système trouve les vecteurs stockés les plus proches du vecteur de la question
- Ce sont vos documents les plus pertinents
Ce n'est pas une magie approximative. C'est de la géométrie.
La similarité est une propriété mathématique réelle que vous pouvez calculer.
Où cela apparaît en production :
→ Recherche sémantique dans tout système documentaire
→ Trouver des produits, articles, profils utilisateurs similaires
→ L'étape d'extraction dans le RAG (concept suivant)
→ Mémoire dans les agents d'IA
3. RAG (Génération augmentée par extraction)
Au lieu d'entraîner un modèle sur vos données, vous extrayez les données pertinentes au moment de la requête et les fournissez au modèle comme contexte.
Le problème que RAG résout :
Les LLM en savent beaucoup. Ils ne connaissent pas vos données.
Vos documents internes d'entreprise. Votre base de données produits. Votre historique de support client.
Rien de tout cela n'était dans l'ensemble d'entraînement.
Deux options : entraîner un modèle sur vos données (coûteux, lent, obsolète instantanément) ou donner vos données au modèle exactement quand il en a besoin.
RAG est la deuxième option, réalisée systématiquement.
Le pipeline en 3 étapes :
→ EXTRAIRE :
la question devient un vecteur → la base de données vectorielle trouve les documents stockés les plus similaires → les 3 à 5 meilleurs fragments sont extraits
→ AUGMENTER :
les documents extraits sont ajoutés au contexte du modèle → le prompt devient « en utilisant ce contexte, répondez à cette question »
→ GÉNÉRER :
le modèle répond en se basant sur vos données réelles — pas d'hallucination
Où RAG échoue :
→ Mauvaise extraction = mauvaise réponse. Le modèle ne peut travailler qu'avec ce qu'il reçoit
→ Un mauvais découpage sépare la réponse de son contexte
→ Le modèle peut encore halluciner si l'extraction ne trouve rien d'utile
Un véritable échec de RAG :
Une équipe a construit un assistant de connaissances interne pour un manuel technique de 500 pages.
Cela fonctionnait parfaitement lors des démos. En production, les réponses étaient vagues et parfois erronées.
Le problème : la taille des fragments.
Ils avaient divisé le manuel en fragments de 1 000 jetons par nombre brut de caractères.
Les tableaux étaient coupés au milieu d'une ligne. Les instructions étape par étape étaient coupées au milieu d'une étape.
L'extraction trouvait la bonne zone générale — mais manquait la réponse réelle.
Diviser la taille des fragments par deux et ajouter un chevauchement a résolu 80 % des problèmes du jour au lendemain.
L'opinion tranchée :
RAG est surestimé quand votre extraction est mauvaise.
Le LLM ne peut pas réparer une mauvaise extraction. Il ne peut qu'halluciner autour.
Si vous obtenez des réponses erronées, arrêtez de modifier votre prompt.
Commencez à mesurer la précision de votre extraction.
C'est là que se trouve la réponse.
4. La boucle agentique
Les agents fonctionnent en choisissant répétitivement une action, en l'exécutant, en observant le résultat et en décidant quoi faire ensuite — jusqu'à ce que la tâche soit terminée.
Un appel LLM standard est sans état. Vous demandez, il répond, terminé.
Un agent a un état. Il agit, observe, décide, répète.
La boucle en termes simples :
- Recevoir un objectif
- Décider de la prochaine action
- L'exécuter — recherche, code, lecture d'un fichier
- Observer le résultat
- Décider de la prochaine action en fonction de ce qui a été appris
- Répéter jusqu'à ce que l'objectif soit atteint
- Retourner la réponse finale
Les outils sont ce qui donne aux agents leur puissance.
Sans outils, un LLM ne répond qu'avec du texte.
Avec des outils, il peut rechercher sur le web, lire des fichiers, écrire du code, appeler des API, déclencher toute action que vous définissez.
Trois choses que les débutants font toujours mal :
→ Les agents sans conditions d'arrêt tournent indéfiniment. Vous devez définir quand arrêter — limite d'étapes, limite de temps, ou condition d'objectif
→ Plus d'outils ≠ meilleure performance. Trop d'outils perturbent le modèle sur lequel utiliser
→ Les erreurs d'outils nécessitent une gestion explicite. Un échec silencieux fait produire des déchets avec confiance par l'agent
L'échec de 200 $ du jour au lendemain, en détail :
L'agent n'avait pas de nombre maximum d'étapes. Son objectif : rechercher un sujet et produire un résumé.
L'un de ses outils de recherche web a retourné un résultat vide.
L'agent ne savait pas comment s'arrêter.
Il a continué à chercher, réessayer, générer des résumés intermédiaires — chacun déclenchant une autre recherche.
Six heures plus tard : 847 appels LLM. 2,1 millions de jetons consommés. Un résumé cohérent en apparence mais complètement circulaire. Une facture de 200 $.
La solution tenait en trois lignes : un compteur maximum d'étapes, un gestionnaire explicite pour les résultats vides, un chemin d'escalade en cas de faible confiance.
Le même agent se termine maintenant en moins de 12 appels en moyenne.
L'opinion que vous devez entendre :
La plupart des agents échouent non pas parce que le modèle est mauvais — mais parce que les ingénieurs traitent la boucle comme si elle se gérait d'elle-même.
Ce n'est pas le cas.
Garde-fous, conditions d'arrêt, gestionnaires d'erreurs — construits dès le départ, pas ajoutés après le premier incident.
5. Les évaluations
Les évaluations sont comment vous savez si votre système d'IA fonctionne réellement — et si un changement l'a amélioré ou dégradé.
C'est le concept que la plupart des tutoriels ignorent parce qu'il n'est pas glamour.
C'est aussi ce qui sépare les ingénieurs qui construisent des démos des ingénieurs qui construisent des systèmes de production.
Le problème sans évaluations :
Vous modifiez votre prompt. Mettez à jour votre logique d'extraction. Passez à un modèle plus récent.
Est-ce que ça s'est amélioré ?
Vous ne savez pas. Vous pourriez vérifier manuellement quelques exemples — mais c'est une impression, pas une preuve.
À quoi ressemblent réellement les évaluations :
→ Un dataset de référence : 25 à 50 entrées réelles avec des sorties correctes connues, couvrant les cas d'utilisation principaux plus 5 cas limites difficiles connus
→ Des métriques binaires si possible :
— Le système RAG a-t-il extrait le bon document ? Oui/Non
— L'agent s'est-il terminé sans erreur ? Oui/Non
— La réponse contenait-elle l'information requise ? Oui/Non
→ Des scores agrégés suivis dans le temps :
— Précision de l'extraction : 89 % → changement effectué → 84 %. Régression trouvée.
— Taux d'achèvement des tâches : 76 % → nouvelle version de l'agent → 81 %. Amélioration confirmée.
Le cycle d'évaluation :
Déployer → Mesurer avec des évaluations → Trouver les échecs → Ajouter les échecs au dataset de référence → Corriger → Relancer les évaluations → Comparer les scores → Mettre en production uniquement si les chiffres se sont améliorés
La vérité honnête :
« Utilité : 3,7/5 » ne vous dit rien d'actionnable.
« A extrait le bon document : 84 % du temps » vous dit exactement où se trouve le problème et à quel point une correction l'a amélioré.
Un système d'IA sans évaluations n'est pas un produit.
C'est une démo que vous ne pouvez pas modifier en toute confiance.
6. L'ingénierie du contexte
La discipline qui consiste à décider exactement quelles informations entrent dans la fenêtre de contexte du modèle, comment elles sont structurées, et ce qui est laissé de côté.
Voici l'opinion qui met les gens mal à l'aise :
L'ingénierie du contexte importe plus que l'ingénierie de prompt.
Un prompt médiocre dans un contexte bien conçu surpasse un prompt brillant noyé dans le bruit — à chaque fois.
La plupart des équipes consacrent 80 % de leurs efforts d'optimisation au prompt et presque rien au contexte.
Les résultats reflètent cela.
L'approche naïve échoue :
Tout inclure. Tout l'historique. Tous les documents extraits. Chaque description d'outil. Le prompt système. Le message utilisateur. Tout.
Cela échoue pour une raison constante : le modèle devient confus sur ce qui importe le plus.
Il existe un effet documenté appelé « perdu au milieu » — les informations enfouies profondément dans un long contexte sont moins susceptibles d'être utilisées.
Ce qu'implique réellement l'ingénierie du contexte :
→ Sélection : quels documents, faits ou historique cette décision spécifique nécessite-t-elle ?
→ Compression : les parties plus anciennes de la conversation peuvent-elles être résumées pour économiser des jetons ?
→ Ordre : les instructions critiques doivent être placées au début et à la fin — pas au milieu
→ Élagage : que peut-on retirer sans affecter la qualité de la sortie ?
→ Structure : les en-têtes, séparateurs, sections étiquetées affectent la fiabilité avec laquelle le modèle utilise les informations
Un exemple pratique :
Un agent fonctionne depuis 45 minutes. Il a accumulé 80 000 jetons d'historique de conversation. Sa fenêtre est de 128 000.
Vous ne voulez pas perdre l'objectif et les contraintes d'origine, même lorsque l'historique remplit la fenêtre.
Ingénierie du contexte : compresser les sorties d'outils plus anciennes, résumer le raisonnement antérieur, garder la définition de la tâche bien visible tout au long de la session.
L'ingénierie de prompt consiste à écrire de bonnes instructions.
L'ingénierie du contexte consiste à construire l'environnement dans lequel ces instructions sont réellement suivies.
Comment ces 6 concepts forment un seul système
MÉMOIRE → RAG + Plongements (ce que le système sait)
RÉFLEXION → LLM + Jetons + Fenêtre de contexte (comment il raisonne avec ce qu'il sait)
ACTIONS → Boucle agentique + Outils (ce qu'il peut faire dans le monde)
MESURE → Évaluations (comment vous savez qu'il fonctionne)
COLLE → Ingénierie du contexte (ce qui décide de ce qui circule entre tout cela)
Un simple chatbot n'est que Réflexion.
Un agent de support client est Mémoire + Réflexion + Actions.
Un système de production fiable ajoute Mesure.
La sophistication réside dans la qualité de la connexion des pièces.
Le flux pour une seule requête :
Question utilisateur
→ L'ingénierie du contexte décide quoi inclure
→ Les plongements extraient la Mémoire pertinente (RAG)
→ Les jetons déterminent combien peut tenir dans la fenêtre
→ Le LLM raisonne sur le contexte assemblé
→ La boucle agentique décide si plus d'informations sont nécessaires
→ Les évaluations mesurent si la sortie était réellement correcte
Par où commencer
Vous n'avez pas besoin de maîtriser les six à la fois.
→ Commencez par les jetons et les fenêtres de contexte — ils affectent tout ce que vous construisez → Ajoutez les plongements quand vous avez besoin de recherche sémantique ou de mémoire
→ Apprenez le RAG quand vous devez ancrer un modèle dans vos propres données
→ Apprenez la boucle agentique quand vous avez besoin d'automatisation
→ Ajoutez des évaluations avant de mettre quoi que ce soit en production
→ Appliquez l'ingénierie du contexte quand tout le reste devient intuitif
Cette séquence n'est pas arbitraire.
Chaque concept rend le suivant plus facile à apprendre.
Le dernier mot honnête
La plupart des équipes qui luttent avec l'IA en production ne luttent pas avec le mauvais modèle ou la mauvaise bibliothèque.
Elles luttent parce qu'elles ont sauté un de ces six concepts.
Les boucles d'agent tournent indéfiniment parce que personne n'a pensé aux conditions d'arrêt.
Les réponses RAG sont erronées parce que personne n'a mesuré l'extraction.
Le prompt cesse de fonctionner sur de longues sessions parce que personne n'a compris comment la fenêtre de contexte se remplit.
Ce ne sont pas des problèmes sophistiqués.
Ce sont des problèmes basiques, habillés en vocabulaire technique.
Les outils changent tous les six mois.
Ces six concepts sont comment les outils fonctionnent.
Apprenez les concepts, et vous ne serez jamais confus par un nouvel outil.
Plus important encore — vous ne passerez jamais une nuit à regarder un agent tourner en boucle pour 200 $, en vous demandant ce qui a mal tourné.
Si cela vous a été utile :
→ Repartagez-le avec tous les ingénieurs IA que vous connaissez
→ Suivez @sairahul1 pour plus de systèmes et d'analyses comme celle-ci
→ Mettez-le en favori — vous y ferez référence la prochaine fois que quelque chose cassera en production
J'écris sur l'IA, la construction de produits et les systèmes qui fonctionnent pendant que vous dormez.
