Au cours de l'année écoulée, presque tous les opérateurs d'entrepôt à qui j'ai parlé m'ont posé la même question : nous voulons transformer nos SOP, nos manuels d'équipement et nos ordres de travail historiques en une base de connaissances interne avec un bot de questions-réponses — faut-il opter pour le RAG ou faire un fine-tuning d'un grand modèle de langage ? On dirait un choix technologique, mais en dessous il y a trois grands livres : à quelle vitesse vos connaissances changent, combien coûte une mauvaise réponse, et quelle approche votre équipe peut réellement maintenir.
Regardons d'abord le tableau d'ensemble : d'après mon examen des rapports publics du secteur et des études de cas des fournisseurs, parmi les projets d'entreprise de questions-réponses sur bases de connaissances réellement mis en production entre 2024 et 2026, le RAG (génération augmentée par récupération) est devenu l'architecture dominante de facto. La technique a été introduite par Meta en 2020 (Lewis et al.), et l'idée centrale est simple : au lieu de bourrer les connaissances dans les paramètres du modèle, le modèle récupère d'abord les documents pertinents, puis génère des réponses fondées sur ce qu'il a récupéré. Le fine-tuning prend l'autre voie : continuer à entraîner le modèle sur vos propres données de questions-réponses pour que les connaissances soient « pressées » dans les paramètres. Les deux voies fonctionnent, mais leurs structures de coûts, leurs profils de risque et leurs limites sont entièrement différents — et le prix d'un mauvais choix n'apparaît qu'environ six mois après le lancement.
À quoi ressemble vraiment le RAG dans un entrepôt : la traçabilité est son sang
Début 2025, un entrepôt 3PL dans l'Inland Empire californien m'a montré son projet. Le site fait environ 120,000 pieds carrés, sert plus de 40 marques e-commerce et avait accumulé des dizaines de milliers d'ordres de travail historiques et de dossiers d'exceptions dans son WMS, plus plusieurs centaines de pages de SOP. Son approche était du RAG de manuel : découper les documents en chunks, les vectoriser, puis à chaque requête récupérer les 5–8 passages les plus pertinents pour que le LLM compose une réponse à partir de ces passages — avec chaque réponse portant ses sources, jusqu'à la section de la SOP ou au numéro d'ordre de travail précis.
Ce design à « sources citées » est tout le propos. Un entrepôt est un environnement fortement piloté par la conformité et l'audit : quand un inspecteur qualité demande « quel est le ratio d'échantillonnage pour ce lot entrant ? », il ne veut pas une jolie réponse — il veut une réponse qu'il peut inscrire au dossier et retracer en cas de problème. Les réponses RAG portent leur provenance par construction ; quand l'une est fausse, on peut identifier quel document est devenu obsolète et corriger le document, pas le modèle. Six mois après le lancement, le cycle d'intégration des nouveaux embauchés de ce 3PL était passé d'environ trois semaines à environ dix jours. Une mise en garde : c'est leur indicateur interne, et le processus de formation lui-même a été optimisé en parallèle, donc tout le mérite ne revient pas au RAG — mais la direction est claire : les connaissances sont devenues trouvables et vérifiables.
Le RAG a un autre avantage qui compte énormément en entrepôt : les mises à jour de connaissances signifient « échanger des documents », pas « réentraîner ». Quand une SOP est révisée, on re-chunke et on re-indexe ; c'est effectif en quelques minutes. Pour les entrepôts dont les connaissances changent constamment, c'est presque décisif.
Le cas d'échec du fine-tuning : il a mémorisé la spec et perdu la source
Le fine-tuning a aussi ses adeptes — et ses vrais cas d'échec. Mi-2025, un centre de distribution dans l'est de la Chine a voulu « enseigner » à un modèle ses manuels de maintenance d'équipements et a rassemblé plusieurs milliers de paires questions-réponses pour le fine-tuning. Pendant les tests, quelqu'un a demandé la charge nominale d'un gerbeur particulier, et le modèle a répondu en toute confiance — et le chiffre était faux. La capacité réelle était de 1.5 tonnes ; il a dit 2 tonnes. L'analyse post-mortem a révélé qu'une révision obsolète du manuel s'était glissée dans les données d'entraînement, et que le modèle avait « mémorisé » l'erreur sans savoir qu'elle en était une.
C'est le défaut structurel du fine-tuning pour les bases de connaissances : une fois les connaissances compressées dans les paramètres, elles ne sont ni traçables ni corrigeables localement. Quand on trouve une erreur, on ne peut pas simplement éditer un document comme le RAG le permet — il faut re-préparer les données, réentraîner et re-valider le tout. Pire, un modèle fine-tuné exprime ses erreurs exactement avec la même confiance que ses réponses correctes. Dans un entrepôt, où une mauvaise réponse peut blesser des gens, endommager des marchandises ou rompre la conformité, cette confiance inexplicable est la propriété la plus dangereuse de toutes.
Pour être juste, le fine-tuning a une place légitime — simplement pas dans la mémorisation des faits. Il excelle à changer le comportement du modèle : fixer les formats de sortie, unifier le ton de voix, apprendre un schéma de raisonnement spécifique. Si votre besoin est « faites parler le modèle comme le manuel de service de notre entreprise », le fine-tuning est un bon choix. Si votre besoin est « faites mémoriser au modèle trois mille pages de manuels », vous utilisez le mauvais outil.
RAG vs fine-tuning : une matrice de décision
Pour résumer, voici une matrice de décision que j'utilise. Mappez votre propre situation sur ces quatre dimensions et la réponse émerge généralement d'elle-même :
| Dimension | Penchez pour le RAG | Penchez pour le fine-tuning |
|---|---|---|
| Fréquence de mise à jour des connaissances | Élevée — changements hebdomadaires voire quotidiens (SOP, règles promo) | Faible — connaissances stables pendant des années (principes d'équipements, réglementations) |
| Besoins de précision et de traçabilité | Élevés — les mauvaises réponses coûtent cher, les sources doivent être citées (qualité, sécurité) | Moyens à faibles — le style compte plus que la précision factuelle |
| Volume de données | Beaucoup de documents mais peu de paires questions-réponses (le RAG mange directement des documents) | Des dizaines de milliers de paires questions-réponses de haute qualité disponibles pour l'entraînement |
| Coût et équipe | Démarrage léger, on paie par récupération, la maintenance c'est juste échanger des documents | Coût GPU de l'entraînement initial plus des réentraînements répétés, plus les frais de gestion de versions |
La dimension du coût mérite son propre calcul. En prenant les prix publics du cloud comme référence, un fine-tuning complet d'un modèle ouvert de classe 7B tourne généralement entre quelques centaines et quelques milliers de dollars de location GPU (vérifiez le site officiel de chaque fournisseur cloud pour les tarifs actuels) — mais c'est seulement pour une passe d'entraînement. Le vrai coût vient après : chaque cycle de rafraîchissement des connaissances exige théoriquement de réentraîner, re-tester et re-déployer une nouvelle version du modèle, ce qui devient une dépense annuelle récurrente. La courbe de coûts du RAG est inversée : construire le pipeline de récupération demande un effort d'ingénierie initial, mais la maintenance quotidienne, c'est juste « échanger des documents », avec un coût marginal très faible. Une courbe est chargée au début, l'autre à la fin — la comparaison qui compte, c'est le total sur trois ans, pas la facture du premier mois.
Le constat contre-intuitif : pour les entrepôts qui changent vite, le fine-tuning est un actif qui se déprécie
Voici un jugement contre-intuitif qui mérite d'être énoncé clairement : pour les entrepôts dont les connaissances sont mises à jour fréquemment, le fine-tuning n'est pas un « investissement unique » — c'est un actif qui se déprécie. Chaque révision de SOP et chaque changement d'équipement rend obsolète une partie de la « mémoire » du modèle fine-tuné précédent, et on ne peut pas dire laquelle. On se retrouve donc forcé dans une boucle réentraîner–retester–redéployer, dépensant de plus en plus pendant que le modèle poursuit éternellement une cible mouvante. Le RAG se comporte à l'inverse dans exactement ce scénario : plus les connaissances sont nouvelles, fragmentées et dispersées, plus l'avantage de l'architecture de récupération est grand.
Ma lecture de la tendance, donc : dans les deux à trois prochaines années, la forme par défaut des bases de connaissances d'entrepôt sera hybride — le RAG pour le quoi (faits, traçabilité, mises à jour en temps réel) et un fine-tuning léger pour le comment (format, ton, phraséologie du secteur). Les deux approches n'ont jamais été un choix binaire ; c'est une division du travail.
Une question mérite toutefois une observation plus longue : quel que soit le chemin choisi, la qualité de la base de connaissances elle-même est le plafond. Des SOP vagues, des dossiers d'ordres de travail avec des champs manquants, des manuels d'équipements aux révisions enchevêtrées — aucun pipeline RAG ni aucune passe de fine-tuning ne peut réparer les problèmes de « gouvernance des connaissances ». Derrière le débat d'architecture, la vraie ligne de démarcation pourrait être celle-ci : votre entrepôt a-t-il vraiment des connaissances qu'une IA vaille la peine d'apprendre ? C'est une question que chaque entreprise construisant une base de connaissances devra se répondre à elle-même.
Par Dr. Chen, chercheur en supply chain
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
