7 min de lecture

La plupart des piles d’IA en entreprise sont des machines sur-ingénierées : des prompts système comptant des milliers de tokens, des pipelines RAG à plusieurs étapes, des règles métiers codées en dur et des revues manuelles de code qui constituent un goulot d’étranglement. Cela fonctionnait tant que les modèles affichaient une précision de 85 %. À chaque nouvelle génération de modèles, l’équilibre évolue – et la complexité devient un frein. Quatre points d’audit concrets montrent où les équipes IT doivent désormais simplifier.

L’essentiel

• La « Leçon amère » (« Bitter Lesson ») de Rich Sutton (2019) s’applique aussi aux piles d’IA : les dispositifs conçus par l’humain perdent face à l’intelligence du modèle dès que la mise à l’échelle prend effet (Sutton, Université de l’Alberta).
• Les fenêtres de contexte sont passées de 4 000 tokens (GPT-3, 2020) à plus d’un million de tokens (2025/26) – un facteur 250 en cinq ans. Cela transforme fondamentalement les architectures de récupération d’informations (retrieval).
• Les prompts système procéduraux de plus de 3 000 tokens peuvent souvent être raccourcis de 30 à 50 % sur des modèles plus performants – sans perte de qualité (Anthropic Prompt Engineering Guide, 2025).
• Google Big Sleep (Project Zero + DeepMind) a découvert en octobre 2024 une véritable vulnérabilité zéro-day dans SQLite – le premier cas documenté publiquement d’un agent IA ayant identifié une faille de sécurité inconnue dans un logiciel déployé en production.
• Les modèles de pointe coûtent 5 à 10 fois plus cher par token que les générations précédentes. Des prompts efficaces ne relèvent pas seulement de la qualité, mais aussi de la maîtrise des coûts.

Pourquoi la mise à l’échelle impose la simplification

En mars 2019, Rich Sutton, professeur à l’Université de l’Alberta et cofondateur de la recherche moderne sur l’apprentissage par renforcement, publiait un essai intitulé « The Bitter Lesson ». Sa thèse : sur les 70 dernières années d’histoire de l’IA, les méthodes reposant sur la puissance de calcul brute ont systématiquement surpassé celles intégrant des connaissances humaines spécifiques à un domaine. Non pas parce que ces connaissances seraient sans valeur – mais parce qu’elles ne suivent pas le rythme de la mise à l’échelle.

Six ans plus tard, ce même schéma se répète dans le travail avec les grands modèles de langage (LLM). Les équipes construisent des systèmes autour des modèles : chaînes de prompts à plusieurs étapes, arbres de décision codés en dur, pipelines de récupération d’informations soigneusement curatés à la main. Cela avait du sens lorsque GPT-3 opérait avec une fenêtre de contexte de 4 000 tokens et hallucinait sur une demande sur trois. Mais les modèles se sont améliorés plus rapidement que les systèmes qui les entourent.

Les lois de mise à l’échelle (Scaling Laws) de Kaplan et al. (2020, arXiv:2001.08361) et les résultats Chinchilla de Hoffmann et al. (2022, arXiv:2203.15556) ont montré que la performance des modèles augmente de façon prévisible avec la puissance de calcul, la quantité de données et le nombre de paramètres. En pratique, cela signifie que chaque nouvelle génération de modèles rend obsolète une partie de la complexité conçue par l’humain. Pas tout – mais suffisamment pour remettre régulièrement en question les architectures existantes.

Audit 1 : Alléger le scaffolding des prompts

La première question à poser à toute pile d’IA en production : quelle part du prompt système décrit le résultat souhaité – et quelle part décrit le chemin pour y parvenir ? Dans la plupart des systèmes en production, ce rapport est de 20 à 80. Vingt pour cent pour l’objectif, quatre-vingts pour cent pour la procédure.

Un exemple typique issu du support client : un prompt système de 3 000 tokens qui prescrit la classification d’intention en 14 catégories, définit les étapes de récupération d’informations, impose des vérifications contre les hallucinations et fixe les formats de réponse. Cette spécification procédurale était nécessaire, car les modèles antérieurs sautaient des étapes sans instruction explicite. Sur des modèles plus performants, elle devient une entrave : le modèle suit le chemin prescrit, même lorsqu’il en connaît un meilleur.

Le Prompt Engineering Guide d’Anthropic le formule clairement : n’ajouter de la complexité que si elle produit objectivement de meilleurs résultats. La documentation Codex d’OpenAI va dans le même sens : décrire l’objectif, pas la méthode.

Recommandation : passer chaque prompt ligne par ligne. Pour chaque instruction, se demander : cette ligne est-elle là parce que le modèle en a besoin – ou parce que j’ai cru qu’il en avait besoin ? Celui qui souhaite préparer son stack d’expérience développeur à la prochaine génération de modèles commence ici.

Audit 2 : Simplifier l’architecture de récupération d’informations (retrieval)

Le RAG n’est pas mort. Mais la question de savoir qui contrôle la logique de récupération évolue. Avec une fenêtre de contexte de 4 000 tokens, le découpage précis (chunking), le réordonnancement (re-ranking) et le filtrage étaient vitaux. Avec une fenêtre d’un million de tokens, le calcul change.

Si un modèle peut traiter simultanément 500 pages de texte, la question « Quels 5 fragments sont pertinents ? » perd de son importance. À la place, la question décisive devient : « Quel référentiel ou quelle collection de documents le modèle reçoit-il ? ». L’intelligence de la récupération se déplace du code de la pipeline vers le modèle lui-même.

L’évolution des fenêtres de contexte illustre ce phénomène : GPT-3 démarra en 2020 avec 4 096 tokens. GPT-4 arriva en 2023 avec 128 000 tokens. Gemini de Google atteignit un million de tokens en 2024. Au début de 2026, plusieurs modèles opèrent avec des fenêtres de contexte dépassant le million. Il ne s’agit pas d’une croissance linéaire – mais d’un facteur 250 en cinq ans. Chaque multiplication par dix de la taille de la fenêtre de contexte rend obsolète une partie de la pipeline de récupération, car le modèle peut désormais traiter directement davantage de données brutes.

Cela ne signifie pas que les bases de données vectorielles disparaissent. Pour des corpus dépassant la fenêtre de contexte, la récupération reste indispensable. Mais la logique se simplifie : au lieu de pipelines complexes de réordonnancement à plusieurs étapes, avec des seuils ajustés manuellement, il suffit de plus en plus de présenter au modèle un référentiel bien organisé et consultable, et de laisser la sélection au modèle. L’effort se déplace de la pipeline vers la structure des documents.

Pour les équipes d’ingénierie de plateforme qui équipent leurs plateformes internes de développeurs d’assistants IA, cela a une conséquence pratique : investissez dans la qualité et la structure de votre documentation plutôt que dans la complexité de votre pipeline de récupération. Un wiki Confluence bien organisé ou un dépôt Git structuré apporte plus qu’un modèle sophistiqué de réordonnancement.

Audit 3 : Connaissances métier codées en dur vs. inférence par le modèle

Combien de règles métiers avez-vous codées en dur dans vos prompts système ? Comptez-les. Puis, pour chacune, demandez-vous : le modèle peut-il déduire cette règle à partir du contexte, s’il a accès aux documents pertinents ?

Exemple : un système de reporting qui définit le style maison pour les rapports clients sous forme d’une instruction de 15 lignes dans le prompt – style, structure, règles de formulation, formatage. Un modèle performant déduit tout cela à partir d’un seul exemple de rapport, avec une fiabilité supérieure à celle obtenue à partir d’une description abstraite de la règle. C’est exactement le mécanisme décrit par Sutton : les lois de mise à l’échelle ne rendent pas les connaissances codées par l’humain sans valeur, mais de plus en plus redondantes, car le modèle peut les déduire lui-même.

« Celui qui avait besoin en 2024 d’un prompt système de 3 000 tokens obtiendra en 2026 de meilleurs résultats avec 800 tokens – à condition de décrire l’objectif plutôt que la méthode, et de donner accès au modèle plutôt que des prescriptions. »
– Évaluation rédactionnelle de cloudmagazin

Ce qui doit rester codé en dur : les règles de conformité qui ne doivent en aucun cas être violées (politiques de restitution, exigences réglementaires), les limites de sécurité dont la violation serait inacceptable. Tout le reste mérite un test : prompt avec la règle vs. prompt sans la règle. Si les résultats sont aussi bons, la règle peut être supprimée.

Audit 4 : Une porte d’évaluation (Eval-Gate) unique au lieu de nombreux points de contrôle

Les étapes intermédiaires d’évaluation dans les pipelines IA étaient une réaction aux modèles peu fiables : après chaque étape, vérifier si le résultat intermédiaire est correct avant de lancer l’étape suivante. Intention classifiée ? Vérifié. Récupération pertinente ? Vérifié. Réponse exempte d’hallucinations ? Vérifié.

Sur des modèles qui fonctionnent correctement dans 99 % des cas, le rapport coût-efficacité change. Chaque vérification intermédiaire coûte en latence, en tokens et en complexité. Si le résultat final est correct dans la grande majorité des cas, une seule porte d’évaluation globale à la fin est plus efficace que cinq vérifications partielles en cours de route.

Cela est particulièrement pertinent pour le développement logiciel. Google Big Sleep (une collaboration entre Project Zero et DeepMind) a découvert en octobre 2024 une vulnérabilité de type stack buffer underflow jusqu’alors inconnue dans SQLite – le premier cas documenté publiquement d’un agent IA ayant identifié une véritable vulnérabilité zéro-day dans un logiciel open source largement répandu. Si les modèles IA peuvent identifier des failles que des chercheurs en sécurité expérimentés ont manquées, ils peuvent aussi assumer les revues de code et les tests de régression.

Recommandation pratique : un script d’évaluation à la fin de la pipeline, qui vérifie de façon exhaustive les exigences fonctionnelles, non fonctionnelles et les cas limites (edge cases). Si tous les tests sont validés, le résultat est publié. Sinon, il est renvoyé au modèle. Aucune étape intermédiaire manuelle, aucune revue humaine comme goulot d’étranglement.

Coûts et routage multi-modèle

Les modèles de pointe sont coûteux. La plateforme GB200 de NVIDIA (architecture Blackwell, présentée à la GTC en mars 2024) et ses successeurs GB300 (Blackwell Ultra, GTC mars 2025) font exploser les coûts d’entraînement à des centaines de millions d’euros par modèle. Cela se répercute sur les coûts d’inférence : les modèles de pointe coûtent 5 à 10 fois plus cher par token que la génération précédente. Celui qui dirige l’intégralité de son trafic vers un modèle de pointe brûle son budget. Celui qui délègue tout au modèle le moins coûteux sacrifie la qualité sur les tâches complexes.

La solution est le routage multi-modèle : déléguer les tâches simples (classification, extraction, formatage) à des modèles économiques, et transférer les tâches complexes (raisonnement, génération de code, audits de sécurité) aux modèles de pointe. La capacité à router correctement les problèmes deviendra en 2026 l’une des compétences les plus importantes dans les architectures API-First.

La simplification des prompts n’est donc pas seulement une question de qualité, mais aussi de maîtrise des coûts. Un prompt système de 3 000 tokens réduit à 800 tokens permet d’économiser, sur mille appels API par jour, 2,2 millions de tokens. À des tarifs de pointe de 15 euros par million de tokens en entrée, cela représente 33 euros par jour – soit près de 1 000 euros par mois. Simplification et efficacité économique vont de pair.

Fazit

La « Leçon amère » ne concerne pas uniquement les chercheurs en IA. Elle concerne chaque équipe qui met en production des modèles d’IA. Quatre audits – le scaffolding des prompts, l’architecture de récupération d’informations, les connaissances métier codées en dur et les pipelines d’évaluation – montrent concrètement où la complexité devient un frein. Les modèles s’améliorent plus vite que la plupart des systèmes qui les entourent ne sont adaptés. Celui qui simplifie aujourd’hui sera prêt à l’arrivée de la prochaine génération. Celui qui s’accroche à son prompt de 5 000 tokens, accumulé au fil des années, constatera qu’une simple ligne de prompt fournit de meilleurs résultats.

Questions fréquentes

Que dit exactement la « Leçon amère » de Rich Sutton ?

Rich Sutton a argumenté en 2019 que, sur les 70 dernières années d’histoire de l’IA, les méthodes reposant sur la mise à l’échelle de la puissance de calcul ont systématiquement surpassé celles intégrant des connaissances humaines spécifiques à un domaine. Pour les piles d’IA, cela signifie : plutôt que d’ajouter toujours plus de règles et de dispositifs, il faut accorder davantage de liberté au modèle et mesurer les résultats.

Dois-je supprimer intégralement mon prompt système ?

Non. Les règles de conformité, les limites de sécurité et la logique métier non négociable restent dans le prompt. Ce qui peut être supprimé : les séquences procédurales qui prescrivent au modèle la méthode de résolution, plutôt que de définir l’objectif. Le test est simple : comparer la qualité des résultats avec et sans la règle. Aucune différence de qualité ? Supprimez la règle.

Le RAG devient-il obsolète avec de grandes fenêtres de contexte ?

Pas fondamentalement. Pour des corpus dépassant la fenêtre de contexte, la récupération reste indispensable. Mais la logique de récupération se simplifie : au lieu de pipelines complexes de réordonnancement à plusieurs étapes, il suffit de plus en plus de fournir au modèle un référentiel bien structuré et de laisser la sélection au modèle. L’investissement se déplace de la complexité de la pipeline vers la qualité des documents.

Comment Google Big Sleep a-t-il découvert la vulnérabilité SQLite ?

Big Sleep est une collaboration entre Google Project Zero et Google DeepMind. En octobre 2024, l’agent IA a identifié un stack buffer underflow dans SQLite – une vulnérabilité existant dans une branche de développement et détectée avant une version officielle. Il s’agissait du premier cas documenté publiquement où un agent IA découvrait une faille de sécurité inconnue dans un logiciel largement répandu.

Comment démarrer un audit des prompts sur ma pile d’IA existante ?

Trois étapes : Premièrement, passer chaque prompt système ligne par ligne et marquer chaque instruction comme « objectif » ou « processus ». Deuxièmement, supprimer individuellement toutes les instructions de type « processus » et mesurer la qualité des résultats à l’aide d’un jeu d’évaluation (Eval-Set). Troisièmement, ne réintégrer que les instructions dont la suppression entraîne une dégradation mesurable des résultats. La plupart des équipes constatent que 30 à 50 % des instructions de type « processus » n’ont plus d’impact mesurable.

Source de l’image : générée par IA (mai 2026), certificat C2PA intégré à l’image