La stratégie comme document — Le septième chapitre

Chapitre 6 — La stratégie comme document, et non comme code

Nous arrivons à l'idée directrice qui, plus que toute autre dans le récit de ceux qui ont construit RAG depuis 2023, revient comme "la chose que j'aurais voulu comprendre dès le premier jour".

Les frameworks traditionnels traitent la stratégie de recherche comme du code Python. Pour les catalogues techniques, voulez-vous rechercher d'abord par code produit, puis par mots-clés, puis par vecteurs sémantiques, et seulement en dernier recours générer la réponse ? Écrivez une fonction. Pour les albums photos, voulez-vous ignorer complètement la recherche sémantique traditionnelle et vous fier à un reranker spécialisé pour les images ? Écrivez une autre fonction. Pour les vidéos d'entreprise, voulez-vous séparer l'audio de la piste visuelle, les transcrire séparément, les traiter comme des sources distinctes, puis les recomposer dans la réponse finale ? Encore une autre fonction. Chaque type de contenu, chaque domaine, chaque client finit par générer une branche de code qui diverge des autres, jusqu'au point où la modification d'une stratégie nécessite une publication logicielle, une revue de code, un cycle de test, un déploiement. Le temps entre "j'ai une idée pour améliorer la recherche dans les manuels techniques" et "l'idée est en production" se mesure en semaines. Pour chaque idée.

L'idée alternative est simple à exprimer et profonde dans ses conséquences : la stratégie de recherche n'est pas du code. C'est un document. Un JSON – un format de texte structuré qu'un éditeur, avec une demi-heure de formation, peut lire – qui dit : "d'abord, essayez ceci, puis cela, si la première tentative échoue, passez à la troisième, réorganisez ainsi, répondez avec ce modèle." Ce document vit dans une base de données, pas dans un dépôt. Il est modifié via une interface, et non par une pull request. Il est versionné, copié, spécialisé par domaine. Une stratégie pour les catalogues techniques, une pour les albums photos, une pour les manuels d'installation, une pour les vidéos, une pour l'audio, une pour les contrats légaux, une pour les états financiers. Toutes coexistent dans le même système. Toutes sont modifiables en temps réel.

Ceux qui ont travaillé avec cette approche – appelons-la, sans trop d'imagination, Meta-RAG – racontent un changement de vitesse qui va au-delà de l'ingénierie. Une demande typique du client comme "ajouter une recherche spécifique pour les codes produits qui contiennent des acronymes tels que CMP40M ou RH1M" n'est plus un ticket de développement de deux semaines. C'est une nouvelle étape ajoutée à une procédure JSON, testée à chaud sur un environnement de staging, promue en production en un après-midi. La question "que se passe-t-il si nous utilisons un reranker différent pour les photos, tout en conservant l'actuel pour le texte ?" se résout en modifiant une ligne de configuration. L'expérimentation ne coûte rien, le rollback ne coûte rien (il suffit de restaurer la version précédente du document), et les connaissances accumulées – ce qui fonctionne bien pour un certain type de contenu – deviennent un actif versionné et transférable, et non le savoir tacite de celui qui a écrit cette branche de code particulière et qui est aujourd'hui en vacances.

Il y a aussi un effet social intéressant qui émerge dans les organisations qui adoptent cette approche. Avec les stratégies comme document, la frontière entre "développeur" et "utilisateur expert" se déplace. Un bibliothécaire numérique, un archiviste d'entreprise, un expert du domaine — le chef du bureau technique, la responsable de la documentation, le chef de produit qui connaît comme personne les véritables questions des clients — peut lire une stratégie, comprendre ce qu'elle fait, suggérer des modifications, parfois même les écrire directement. Il n'a pas besoin de passer par le funnel du ticket de développement, il n'a pas besoin d'expliquer à un développeur des choses que le développeur ne sait pas (car cela ne relève pas de son métier). Le RAG cesse d'être un produit que vous consommez et devient un outil que vous modelez sur votre savoir organisationnel. Cela, dans l'expérience de ceux qui l'ont essayé, change le moral du projet avant même les chiffres des métriques.

Ce n'est pas de la magie, et cela a un coût. Il faut un moteur qui exécute ces stratégies-comme-documents de manière efficace et sécurisée. Il faut un langage de description suffisamment riche pour couvrir les cas réels et suffisamment simple pour ne pas devenir un autre système complet de Turing déguisé. Il faut des outils de gestion des versions, de test et de restauration. Mais tout cela est le problème de ceux qui construisent le moteur – une seule fois, et pour tous les utilisateurs. Le client final ne voit qu'une chose : la possibilité de faire évoluer sa stratégie de recherche à la vitesse de la pensée, et non à la vitesse du cycle de publication des logiciels. Et pour ceux qui y sont, c'est une révolution silencieuse qui n'a pas encore trouvé son nom dans les magazines spécialisés.

Conclusion — Le septième chapitre, dans quelques mois

Au début de l'année 2026, en additionnant les leçons des chapitres précédents — les tableaux qui se perdaient, les rerankers menteurs, les hallucinations héritées, les factures cloud qui croissaient plus vite que la valeur, les frameworks prometteurs mais rigides — quelqu'un, en Italie, a commencé à construire un serveur RAG différent. Écrit en Python, conçu pour fonctionner sur du matériel accessible, capable de communiquer avec des modèles cloud quand c'est pertinent et avec des modèles locaux lorsque la confidentialité l'exige ou que le coût n'est pas viable. Un serveur dans lequel les stratégies de recherche sont des documents modifiables, le reranker est un processus local sur GPU, les tableaux ne se perdent pas car ils sont traités comme des citoyens de première classe, les photos n'héritent pas d'objets d'archives poussiéreuses d'autres époques, et le coût par requête — en argent et en données exfiltrées vers des tiers — est connaissable et contrôlable au centime.

Nous ne nommerons pas le projet. Ce n'est pas l'article pour le faire, et nous ne voulons pas transformer une enquête en une publicité. Mais si les chapitres précédents vous ont permis de reconnaître une situation que vous vivez – un chatbot d'entreprise qui répond avec assurance à des questions erronées, un projet RAG qui ne décolle pas depuis des mois, une facture cloud qui croît plus vite que l'utilité qu'elle produit, un doute croissant sur le fait que vos documents confidentiels voyagent vers des endroits que vous ne connaissez pas – alors il vaut la peine de savoir qu'il existe une autre voie, qui a été empruntée par quelqu'un en Italie, et qui en 2026 a commencé à donner les premières réponses que l'on attendait en 2023.

La bonne nouvelle est que l'IA d'entreprise sort enfin de la phase de démonstration. La moins bonne est qu'elle en sort en traînant avec elle toutes les cicatrices du parcours : des frameworks gonflés, des dépendances vis-à-vis des fournisseurs, des architectures monolithiques, des données sales, des bugs silencieux et une certaine tendance du secteur à vendre des solutions avant même d'avoir compris le problème. Nous les avons racontées en six chapitres. Le septième – l'histoire de ce qui se passe quand quelqu'un fait enfin les choses bien, avec patience, en italien et en open source – nous l'écrirons bientôt, avec moins de prudence sur les noms et plus de chiffres sur la table.

En attendant, si vous êtes arrivé jusqu'ici, vous avez déjà fait plus d'autopsie que 90 % des décideurs qui, en ce moment, signent un contrat pour un chatbot d'entreprise sans se poser aucune des questions que vous vous êtes posées en lisant ces chapitres. C'est un meilleur point de départ que celui dont ils sont partis. Et dans les mois à venir, la différence entre ceux qui se sont posées ces questions et ceux qui ne l'ont pas fait, deviendra très visible sur les factures — et sur les réponses que votre IA donnera à vos clients.

Cette enquête a été rédigée en avril 2026, sur la base de dix-huit mois d'expérience dans la conception, la construction et l'optimisation de systèmes RAG d'entreprise entre la fin de 2024 et le début de 2026.