Mon verdict d'abord : si vous voulez que vos équipes d'entrepôt et de service client posent des questions à une IA sur votre montagne de SOP, manuels d'équipement et journaux d'exceptions, construisez une base de connaissances RAG dans neuf cas sur dix. Ne faites pas de fine-tuning d'un modèle. Le fine-tuning, c'est nourrir et entretenir un modèle. RAG, c'est remettre au modèle un manuel vivant qu'il peut feuilleter à tout moment. Les documents d'entrepôt changent sans cesse : le temps qu'un cycle de fine-tuning se termine, une configuration RAG a déjà absorbé des dizaines de mises à jour.
Un client 3PL est venu me voir l'an dernier. Il exploite une installation de 120 000 pieds carrés à l'est de Los Angeles, plus de vingt mille emplacements de palettes, avec des SOP éparpillés sur des disques partagés, des pièces jointes d'e-mails et la tête de quelques superviseurs vétérans. Les nouvelles recrues terminaient deux semaines de formation et ne travaillaient toujours pas un poste sans supervision. Les exceptions de l'équipe de nuit signifiaient réveiller le superviseur. La demande du propriétaire était simple : « Nos gens peuvent-ils simplement demander à l'IA au lieu d'appeler quelqu'un ? » Deux fournisseurs ont proposé deux approches — faire le fine-tuning d'un modèle privé, ou construire une base de connaissances RAG — avec des prix plusieurs fois différents. Le client m'a demandé laquelle choisir. Je lui ai renvoyé trois questions : à quelle fréquence vos SOP changent-ils ? Êtes-vous prêt à transformer vos journaux d'exceptions en vrai texte ? Et qui entretient ce modèle sur le long terme ? Après la troisième question, il avait sa réponse.
Que règle vraiment le fine-tuning ?
Dissipons d'abord la plus grande méconception : le fine-tuning n'est pas « donner des documents au modèle pour qu'il les mémorise ». Ce que le fine-tuning change vraiment, c'est le comportement du modèle — son ton, la structure de ses réponses, la façon dont il formule une réponse avec la voix de votre entreprise. Mais sa mémoire des faits précis reste floue. Changez aujourd'hui votre heure limite de commande, et le modèle ajusté hier peut encore citer l'ancienne demain, en toute confiance. L'industrie appelle cela l'hallucination, et le fine-tuning ne la guérit pas. Au contraire, l'étiquette « c'est notre propre modèle fine-tuné » inspire davantage confiance, donc les erreurs frappent plus fort.
Vient ensuite le problème de la taille de l'échantillon, qui frappe l'entreposage particulièrement fort. Combien de paires de questions-réponses de haute qualité avez-vous réellement ? Quelques centaines de documents SOP ne suffiront pas à un cycle sérieux de fine-tuning. Forcez avec des données maigres et vous obtiendrez un modèle qui répond moins bien qu'un modèle généraliste. Et le tapis roulant ne s'arrête jamais : ouvrir un nouvel entrepôt, installer une nouvelle ligne de tri, décrocher un client avec des exigences d'étiquetage spéciales — et vous voilà reparti à préparer des données, réentraîner et revalider. Des dizaines de milliers de dollars par cycle vous achètent un modèle qui « parle comme votre entreprise » mais improvise encore dès qu'on l'interroge sur des termes précis.
Voici la facture que presque personne ne mentionne : le fine-tuning vous enferme chez un seul fournisseur de modèles. Les modèles de base changent tous les quelques mois, et votre version ajustée ne suit pas gratuitement. La plupart des équipes IT d'entrepôt sont déjà réduites. Ajouter la « maintenance du modèle » comme poste permanent, c'est plus que la plupart des opérations ne peuvent porter.
Et concrètement, préparer les données de fine-tuning est un projet à part entière. Les paires de questions-réponses ne sont pas des SOP copiés-collés : quelqu'un doit écrire comment les employés posent vraiment leurs questions, quelle est la bonne réponse, et quelles formulations sont fausses. Pour un 3PL de taille moyenne, rassembler assez d'échantillons de qualité peut engloutir des mois du temps de vos meilleurs opérationnels. Consacrez ces mois à nettoyer une base de connaissances et RAG rapporte immédiatement. Consacrez-les à préparer des données de fine-tuning et vous pourrez — pourrez — voir un résultat incertain des mois plus tard. Les dirigeants devraient faire ce calcul de temps avant de signer quoi que ce soit.
Comment fonctionne vraiment RAG ?
L'idée derrière RAG est d'une simplicité presque embarrassante, et elle convient remarquablement bien aux entrepôts. Quand quelqu'un pose une question, le système récupère d'abord les passages les plus pertinents de votre base de connaissances, puis les remet au modèle avec la question — pour que le modèle réponde « à partir du matériel sous ses yeux ». Quand le matériel change, vous mettez à jour la base de connaissances. Le modèle lui-même ne bouge pas. SOP révisé aujourd'hui, les employés reçoivent la nouvelle version demain. Cette propriété « le modèle reste immobile, le matériel reste frais » correspond exactement au comportement de la documentation d'entrepôt dans la vraie vie.
Il y a une belle ironie ici : l'étape de récupération n'est au fond que classification et indexation — le même métier que les gens d'entrepôt pratiquent chaque jour. SOP classés par processus, manuels d'équipement par modèle de machine, journaux d'exceptions par code de motif, exigences spécifiques aux clients par numéro de client. Quiconque a vécu une sélection de WMS connaît la règle : la qualité de récupération, c'est soixante-dix pour cent de bonne indexation, trente pour cent de modèle. Ce client 3PL a ensuite mesuré sa répartition de tickets et découvert que le service client répondait encore et encore aux mêmes quelques dizaines de questions : heures limites, adresses de retour, les règles d'étiquetage spéciales d'un grand client. RAG les traite vite et avec précision, parce que les réponses vivent déjà dans les documents. Le modèle n'a besoin de « se souvenir » de rien.
RAG a ses propres casse-tête, et ils sont bien réels. D'abord : garbage in, garbage out s'applique à RAG plus qu'ailleurs. Beaucoup de SOP d'entrepôt sont « pour référence uniquement » alors que la vraie procédure vit dans la tête des vétérans. Si vous ne nettoyez pas cela d'abord, RAG n'est que décoration. J'ai vu le contre-exemple près de Dallas, dans une installation e-commerce de 80 000 pieds carrés avec trois versions contradictoires de la procédure de retours réparties dans trois dossiers différents. La première semaine de RAG, quelqu'un a demandé comment les retours étaient traités, le système a récupéré les trois versions, et le modèle a fidèlement résumé la contradiction — une réponse plus confuse que n'importe quel document seul. Ils ont passé deux semaines à tout fusionner en une seule source de vérité, et le problème a disparu. La leçon est concrète : avant de lancer RAG, demandez-vous combien de réponses vos documents donnent à la même question. Si c'est plus d'une, fusionnez les documents avant de parler d'IA.
Deuxième casse-tête : le contrôle d'accès. Les tarifs et exigences de manutention du Client A ne doivent jamais être récupérables par l'équipe au service du Client B. La conception des permissions appartient au jour un de la base de connaissances, pas à une rénovation ultérieure. Troisièmement : n'attendez pas de RAG qu'il réfléchisse à votre place. « Les retours sont élevés ce mois-ci, quelle est la cause racine ? » Ce type de raisonnement croisé entre documents dépasse la récupération. RAG trouve le matériel. Les conclusions, ce sont toujours les gens qui les tirent.
Alors, quand le fine-tuning vaut-il le coup ?
Je ne dis pas que le fine-tuning est inutile — il vient simplement plus tard dans la séquence. Une fois que RAG tourne et que les réponses sont justes, mais que la saveur n'y est pas — les scripts de support ont besoin d'une seule voix cohérente, les rapports d'exceptions d'un format fixe, les sites multilingues des mêmes arguments — c'est là qu'un léger fine-tuning sur un petit échantillon de haute qualité justifie son existence. Il améliore RAG ; il ne le remplace pas. Inversez l'ordre et vous polissez le ton avant d'avoir la précision.
L'autre cas légitime concerne les environnements à conformité extrême ou hors ligne : les données ne peuvent pas quitter le bâtiment, la récupération et le modèle tournent tous deux sur site. De tels projets exigent des budgets et des équipes que la plupart des entrepôts n'ont pas, donc ils relèvent d'une autre conversation. Pour presque tous les entrepôts et 3PL, RAG est le point de départ — et la ligne d'arrivée pour longtemps. Et voici le point clé : une fois que votre base de connaissances RAG accumule des milliers de paires de questions-réponses vérifiées par des humains, vous possédez enfin la seule chose dont le fine-tuning a vraiment besoin — des données de qualité. Alors, et seulement alors, la conversation du fine-tuning devient intéressante.
Une dernière chose. La prochaine fois qu'un fournisseur vous vante le « fine-tuning de votre propre LLM », posez trois questions : qui prépare les données d'entraînement, à quelle fréquence le modèle est-il réentraîné, et que se passe-t-il quand les SOP changent. S'il ne peut pas répondre aux trois, il vend des licences, pas des solutions.
La seule chose à faire demain : ne lancez pas encore un projet. Prenez les 50 questions que votre personnel de terrain et vos agents de service client reçoivent le plus souvent, nettoyez les passages SOP correspondants en texte brut, et lancez un pilote RAG minimal pendant deux semaines. Jugez-le sur deux critères seulement : les réponses sont-elles justes, et les gens l'utilisent-ils vraiment. Le pilote ne coûte presque rien, mais il répond à la question la plus importante : votre base de connaissances contient-elle vraiment quelque chose qui vaille la peine d'être demandé.
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
