OpenAI a déprécié ChatGPT Search en avril 2026 sans annonce officielle, juste un petit changelog technique. Le grand projet « le moteur de recherche tueur de Google » lancé fin 2024 est rebasculé en sous-fonction de l’agent Operator. C’est probablement le signal le plus important pour l’avenir du RAG en entreprise.
Pourquoi OpenAI tue son propre produit, et ce que ça change pour votre stack de recherche interne.
Le rêve qui s’effondre
Fin 2024, OpenAI vendait ChatGPT Search comme l’alternative naturelle à Google : « pose ta question, on synthétise les meilleures sources du web pour toi ». Le pitch a séduit. Les analystes ont prédit la chute de Google. La réalité économique a été plus dure : la qualité des résultats restait inférieure à Google sur 60 % des requêtes complexes, le coût d’inférence par recherche était 30-50x supérieur, et les éditeurs de contenu ont commencé à bloquer ou facturer l’accès à leurs données.
Conclusion d’OpenAI 18 mois plus tard : le grand RAG public à la demande, ça ne marche pas. Ni techniquement, ni économiquement, ni juridiquement.
Pourquoi c’est important pour votre entreprise
Si OpenAI, avec 100 milliards de valorisation et une équipe d’élite, n’arrive pas à faire marcher un RAG sur un corpus aussi structuré que le web public, qu’est-ce que ça dit du RAG sur votre corpus interne (potentiellement plus complexe, plus hétérogène, moins maintenu) ?
Le signal n’est pas que le RAG est mort. C’est que le RAG généraliste à la demande est mort. Le RAG spécialisé, encadré, sur corpus défini reste pertinent et même indispensable. Mais avec une discipline d’ingénierie que beaucoup d’entreprises sous-estiment encore.
Les 4 conditions pour qu’un RAG d’entreprise marche
1. Un corpus défini et maintenu. Vous savez exactement ce qui est dedans, comment c’est mis à jour, qui en est responsable. Pas de « on prend tout ce qui est sur Sharepoint ». Choisir 200 documents pertinents et bien curatés vaut mieux qu’avaler 10 000 documents bruts.
2. Un chunking adapté au contenu. Pas de stratégie unique « 500 tokens overlap 50 ». Les contrats se chunkent par clause, les rapports par section, le code par fonction. L’investissement en data engineering paye 5-10x.
3. Un système d’embeddings de qualité. Les modèles d’embeddings 2026 (text-embedding-3-large d’OpenAI, voyage-3 d’Anthropic, Mistral embed v3) ont fait un bond. Si vous tournez encore sur des embeddings 2023, vous perdez 20-30 % de qualité de retrieval.
4. Un re-ranker. Une étape de re-classement post-retrieval (Cohere Rerank 3, Voyage Rerank, ou un Haiku 4.5 en mode classificateur) améliore la précision finale de 15 à 30 %. Trop souvent négligée.
L’option qui monte : le contexte massif au lieu du RAG
Avec Gemini 3 Pro à 1,5 M de tokens de contexte, certains cas qui demandaient un RAG complet peuvent être traités en brute force : on envoie tout le corpus directement dans le contexte. Plus simple, plus fiable, plus auditable.
Avantages : pas de pipeline d’ingestion à maintenir, pas de problème de retrieval qui rate les passages clés, transparence totale sur ce que voit le modèle. Inconvénient : coût d’inférence multiplié par 5-10. Économique uniquement si vos cas d’usage sont rares mais à fort enjeu (audits trimestriels, due diligence, analyse exceptionnelle).
L’option hybride qui gagne
Le pattern le plus performant en 2026 combine les deux : un RAG retrieval pour récupérer 30-50 chunks pertinents (au lieu de 5-10 comme avant), puis envoi dans un modèle à grand contexte qui fait sa propre sélection finale.
Cette approche bénéficie à la fois de la précision du retrieval ciblé et de la latitude du contexte massif. Sur les audits qu’on a réalisés, elle améliore le rappel de 20-35 % par rapport au RAG classique, avec un surcoût acceptable.
Le piège du « RAG comme produit miracle »
Beaucoup d’éditeurs vendent encore en 2026 du « RAG enterprise turnkey » qui promet de répondre à toutes vos questions internes en plug-and-play. Méfiez-vous. La qualité d’un RAG dépend à 70 % de votre data engineering, pas à 30 % du logiciel choisi.
Si vous achetez un RAG packagé sans investir en parallèle dans la curation de votre corpus et la définition de votre stratégie de chunking, vous aurez 6-12 mois plus tard un système qui livre 60 % de réponses correctes. Acceptable nulle part en B2B sérieux.
Ce qu’il faut retenir de la dépréciation
ChatGPT Search a échoué pour des raisons structurelles : trop vaste, trop ouvert, économie cassée. Votre RAG interne peut éviter ces écueils en étant limité, curaté, maintenu. C’est plus de travail, mais c’est viable.
Si vous n’avez pas le budget ou l’équipe pour cette discipline, demandez-vous si vous avez besoin d’un RAG. Souvent, un agent qui interroge 3-4 SaaS bien identifiés (via MCP) répond à votre besoin sans la complexité d’un système RAG complet.
Le signal stratégique d’OpenAI
En tuant ChatGPT Search au profit d’Operator, OpenAI parie sur les agents avec accès web ciblé, pas sur le RAG universel. C’est probablement le bon pari : un agent qui sait quand chercher, quoi chercher, et comment évaluer la fiabilité des sources, c’est ce dont l’utilisateur a vraiment besoin.
Pour votre stratégie 2026 : investissez moins dans des stacks RAG monolithiques, plus dans des agents capables d’interroger vos sources avec discernement. Le RAG devient une primitive parmi d’autres dans l’outillage d’un agent, plus un produit en soi.
Pour approfondir
- Le RAG expliqué à ma grand-mère (sans parler de vecteurs)
- Pourquoi les agents autonomes ne marchent pas (encore) en production
- Votre data est sale, et l’IA ne la lavera pas
Les trois murs qui ont tué le RAG public
La dépréciation de ChatGPT Search n’est pas un accident de parcours : c’est la rencontre de trois murs structurels qu’aucune quantité de talent ou de capital ne pouvait faire tomber. Les comprendre vous évite de les reconstruire dans votre propre entreprise.
Le mur technique. Le web public est un corpus immense, hétérogène, contradictoire et non daté. Deux sources disent le contraire ; laquelle le modèle doit-il croire ? Sur une requête factuelle simple, le retrieval fonctionne. Sur une requête complexe qui demande d’arbitrer entre des sources de fiabilité inégale, la qualité s’effondre. On n’indexe pas la vérité, on indexe du texte ; et le texte du web ne porte pas son niveau de confiance en étiquette.
Le mur économique. Chaque recherche synthétisée coûte des dizaines de fois plus cher qu’une requête Google classique. Google rentabilise par la publicité et une infrastructure optimisée depuis vingt ans. Un RAG public à la demande paie l’inférence à chaque question, sans modèle de revenu comparable. L’équation ne tient pas à l’échelle de centaines de millions de requêtes quotidiennes.
Le mur juridique. Les éditeurs de contenu ont compris que leurs données alimentaient un produit concurrent et ont commencé à bloquer, limiter ou facturer l’accès. Un moteur de synthèse privé de ses meilleures sources n’est plus qu’un moteur de synthèse médiocre. La matière première s’est raréfiée au moment précis où le produit en dépendait le plus.
Ce que l’échec d’OpenAI dit de votre corpus interne
Voici le raisonnement qui devrait vous arrêter net : si une équipe d’élite, adossée à des moyens quasi illimités, échoue sur un corpus aussi riche et structuré que le web public, que croyez-vous qu’il va se passer sur votre corpus interne ? Car votre corpus est souvent pire : documents en doublon, versions contradictoires, fichiers jamais mis à jour, nomenclatures incohérentes d’un service à l’autre, PDF scannés illisibles par la machine.
Le signal n’est pas « le RAG est mort ». C’est « le RAG généraliste à la demande est mort ». La nuance est capitale. Le RAG spécialisé, encadré, sur corpus défini reste non seulement pertinent mais indispensable. Ce qui meurt, c’est l’illusion qu’on peut déverser tout son contenu dans un système et obtenir des réponses fiables par magie. Ce qui survit, c’est la discipline d’ingénierie qui transforme un corpus maîtrisé en source de réponses fiables.
La curation du corpus : le travail que personne ne veut faire
Si je ne devais retenir qu’une condition sur les quatre, ce serait celle-ci : un corpus défini et maintenu. C’est la moins technique et pourtant la plus décisive. La tentation, toujours la même, est de pointer le RAG vers l’intégralité d’un SharePoint ou d’un Drive en se disant « plus il y a de données, mieux c’est ». C’est exactement l’inverse.
Deux cents documents pertinents, à jour et bien identifiés battent systématiquement dix mille documents bruts. Pourquoi ? Parce que chaque document obsolète, chaque doublon, chaque brouillon jamais finalisé est une occasion pour le système de récupérer et de servir une mauvaise réponse. La taille du corpus augmente le bruit plus vite qu’elle n’augmente le signal. Un RAG n’est pas meilleur parce qu’il contient plus ; il est meilleur parce qu’il contient juste.
La curation impose de répondre à des questions désagréables : quel document fait foi quand deux se contredisent ? Qui est responsable de la mise à jour ? Quelle est la date de péremption d’une procédure ? Ces questions sont organisationnelles avant d’être techniques. C’est d’ailleurs pour ça qu’elles sont esquivées : elles obligent à faire du ménage dans la gouvernance documentaire, un chantier que personne ne réclame mais dont tout dépend.
Le chunking : là où se joue la moitié de la qualité
Le chunking — la façon de découper les documents en morceaux indexables — est l’étape la plus sous-estimée. La stratégie paresseuse, « 500 tokens avec 50 de chevauchement pour tout », est un désastre silencieux. Elle coupe une clause contractuelle en plein milieu, sépare un tableau de son titre, isole une conclusion de ses prémisses. Le système récupère alors des fragments mutilés qui perdent leur sens.
La bonne approche épouse la structure du contenu : on découpe les contrats par clause, les rapports par section, le code par fonction, les FAQ par question. Chaque chunk doit être une unité de sens autonome, compréhensible hors contexte. C’est un travail de data engineering, pas un paramètre à régler. Et c’est un investissement qui se rentabilise cinq à dix fois : un bon chunking fait plus pour la qualité finale que le changement de modèle le plus coûteux.
Ce point illustre une vérité générale sur les projets IA : votre data est sale, et l’IA ne la lavera pas. Le chunking est l’étape où cette saleté se paie ou se corrige. Ignorer la préparation des données, c’est bâtir une cathédrale sur du sable, aussi sophistiqué soit le modèle posé au sommet.
Embeddings et re-ranker : les deux maillons qu’on oublie
Deux composants techniques font une différence disproportionnée, et pourtant beaucoup de projets les négligent. Le premier, ce sont les embeddings : la représentation vectorielle qui permet de retrouver les passages sémantiquement proches d’une question. Les modèles d’embeddings ont fait un bond considérable ; tourner encore sur des embeddings d’il y a trois ans, c’est accepter de perdre une part substantielle de la qualité de retrieval sans même le savoir. C’est le genre de dette technique invisible qui plombe un système sans jamais déclencher d’alerte.
Le second, c’est le re-ranker : une étape de reclassement qui intervient après le retrieval initial. Le retrieval récupère un lot de candidats ; le re-ranker les réordonne finement selon leur pertinence réelle pour la question posée. Cette étape, souvent considérée comme optionnelle, améliore nettement la précision finale. L’omettre, c’est servir au modèle un lot de passages mal priorisés et espérer qu’il fasse le tri lui-même — ce qu’il fait mal et cher.
Ces deux maillons partagent une caractéristique : ils sont peu visibles, peu « vendables », et pourtant déterminants. C’est exactement le genre de détail d’ingénierie qui sépare un RAG de démonstration d’un RAG de production. Un système qui impressionne en démo sur trois questions choisies et qui s’effondre sur les vraies questions des utilisateurs a presque toujours négligé l’un de ces maillons.
Contexte massif, RAG, hybride : choisir selon le cas, pas selon la mode
L’arrivée de fenêtres de contexte d’un million de tokens et plus a rouvert un débat : faut-il encore faire du RAG, ou peut-on tout envoyer en « brute force » dans le contexte ? La réponse honnête est : ça dépend de la fréquence et de l’enjeu de vos requêtes, et surtout pas d’un dogme.
Le contexte massif a des vertus réelles : aucun pipeline d’ingestion à maintenir, aucun passage clé raté par un retrieval défaillant, une transparence totale sur ce que voit le modèle. Mais il coûte cher en inférence. Il n’est économiquement défendable que sur des cas rares et à fort enjeu : une due diligence, un audit trimestriel, une analyse exceptionnelle où l’on peut se permettre de tout charger parce qu’on ne le fera que quelques fois.
Pour les cas fréquents, le RAG reste indispensable : on ne charge pas tout un corpus à chaque requête d’un chatbot interne consulté mille fois par jour. Et c’est l’approche hybride qui tire le meilleur des deux mondes : un retrieval ciblé récupère un lot large de passages pertinents, puis un modèle à grand contexte fait sa propre sélection finale parmi eux. On gagne la précision du ciblage et la latitude du contexte étendu, pour un surcoût maîtrisé. C’est, à ce jour, le pattern le plus performant pour les corpus exigeants.
Avez-vous vraiment besoin d’un RAG ?
C’est la question que personne ne pose, parce qu’elle remet en cause un budget déjà voté. Pourtant, dans beaucoup de cas, la réponse est non. Un RAG complet — ingestion, chunking, embeddings, index vectoriel, re-ranker, maintenance — est un système lourd. Si votre besoin réel est d’interroger trois ou quatre applications métier bien identifiées, un agent qui les consulte directement répond mieux, pour une fraction de la complexité.
C’est tout le sens du pari d’OpenAI avec Operator : miser sur des agents à accès ciblé plutôt que sur le RAG universel. Un agent qui sait quand chercher, quoi chercher et comment évaluer la fiabilité d’une source apporte souvent plus de valeur qu’un gros index figé. Le RAG devient alors une primitive parmi d’autres dans la boîte à outils d’un agent, et non plus un produit en soi.
Cette bascule a une conséquence stratégique concrète pour votre feuille de route : investissez moins dans des stacks RAG monolithiques, plus dans des agents capables d’interroger vos sources avec discernement. Les systèmes figés vieillissent mal ; les agents orchestrant plusieurs sources via des interfaces standardisées évoluent avec vos besoins. C’est une question d’architecture autant que de budget.
Le piège du « RAG enterprise turnkey »
Des éditeurs continuent de vendre du RAG « clé en main » promettant de répondre à toutes vos questions internes en plug-and-play. Méfiance absolue. La qualité d’un RAG dépend très majoritairement de votre préparation des données, pas du logiciel acheté. Un excellent logiciel posé sur un corpus sale produit des réponses sales. Il n’existe pas d’exception à cette règle.
Le scénario classique : on achète la solution packagée, on branche le corpus brut, la démo impressionne sur quelques questions, puis les utilisateurs posent leurs vraies questions et obtiennent une majorité de réponses médiocres ou fausses. Six à douze mois plus tard, le projet est abandonné, le budget consommé, et la confiance interne envers l’IA entamée pour longtemps. Le logiciel n’était pas en cause ; l’absence d’investissement dans la curation et le chunking l’était.
C’est précisément ce travail d’ingénierie et d’architecture que nous enseignons dans notre formation IA architecte et notre parcours développement logiciel IA : non pas brancher un outil, mais concevoir un système de recherche qui tient en production. Cette exigence rejoint une conviction que nous défendons autour de la gouvernance de la data : sans discipline sur les sources, aucun assistant IA ne devient fiable, quel que soit le modèle.
Checklist : votre projet RAG est-il viable ?
Avant de lancer ou de poursuivre un projet RAG, passez-le au crible de ces questions. Si vous répondez non à plusieurs d’entre elles, revoyez le périmètre avant d’investir davantage.
- Savez-vous exactement quels documents sont dans le corpus ? Et qui est responsable de leur mise à jour ?
- Avez-vous une stratégie de chunking adaptée au type de contenu ? Ou appliquez-vous un découpage uniforme par défaut ?
- Vos embeddings sont-ils récents ? Un modèle d’embeddings dépassé plombe silencieusement la qualité.
- Avez-vous une étape de re-ranking ? Sans elle, vous servez des passages mal priorisés.
- Avez-vous mesuré la qualité sur de vraies questions d’utilisateurs ? Pas sur une démo de trois questions choisies.
- Un agent interrogeant quelques sources ciblées ne suffirait-il pas ? Avant d’assumer la lourdeur d’un RAG complet.
FAQ
Le RAG est-il mort ?
Non. Ce qui est mort, c’est le RAG généraliste à la demande sur corpus ouvert, comme ChatGPT Search. Le RAG spécialisé, sur un corpus défini, curaté et maintenu, reste indispensable pour de nombreux cas d’entreprise. La distinction est tout : un corpus maîtrisé change radicalement la faisabilité.
Faut-il préférer le contexte massif au RAG ?
Seulement pour des cas rares et à fort enjeu, où le coût d’inférence élevé est absorbable : audits, due diligence, analyses exceptionnelles. Pour les usages fréquents, le RAG ou l’approche hybride restent bien plus économiques. Le choix dépend de la fréquence et de l’enjeu, jamais de la mode du moment.
Un logiciel RAG clé en main peut-il régler mon besoin ?
Pas à lui seul. La qualité dépend très majoritairement de votre préparation des données : curation du corpus et stratégie de chunking. Un logiciel packagé branché sur un corpus brut livre des réponses médiocres. Investissez d’abord dans la donnée, le logiciel ensuite.
Par où commencer un projet de recherche interne ?
Par la définition stricte du corpus et des cas d’usage réels, pas par le choix de l’outil. Identifiez vingt à deux cents documents vraiment pertinents, définissez qui les maintient, puis évaluez si un agent ciblé suffit avant d’engager un RAG complet. La discipline amont détermine tout le reste.
Construisez un système de recherche qui tient
La dépréciation de ChatGPT Search est une leçon offerte : le grand RAG ouvert ne marche pas, mais le RAG discipliné sur corpus maîtrisé, oui. La différence se joue dans l’ingénierie des données et l’architecture, pas dans le choix du modèle. Pour acquérir cette discipline avec vos équipes, découvrez nos certifications préparées, explorez nos réalisations, consultez notre FAQ ou déposez votre candidature pour une session adaptée à votre corpus.
Le vrai enseignement : la discipline bat l’ambition
Il y a quelque chose de rassurant dans cette histoire. OpenAI a échoué sur l’ambition maximale — tout indexer, tout synthétiser — mais une PME peut réussir sur l’ambition modeste : un corpus bien tenu, quelques cas d’usage précis, une ingénierie soignée. Le succès en RAG n’appartient pas à ceux qui ont le plus de moyens, mais à ceux qui ont le plus de discipline sur un périmètre réduit. C’est une bonne nouvelle pour qui accepte de renoncer au rêve du système universel.
