Faire « connaître » vos process à une IA passe surtout par deux familles de méthodes : lui faire lire vos documents au moment de la question (RAG) ou adapter ses poids (fine-tuning / LoRA). Ce guide explique quoi choisir, avec coûts conceptuels et exemples PME/collectivité/asso. IAHDF n’invente pas de devis.
Définitions utiles
RAG (Retrieval-Augmented Generation) : on cherche des extraits pertinents dans une base, on les fournit au modèle comme contexte, il répond. Fine-tuning : on poursuit l’entraînement ou un adaptateur type LoRA sur des exemples pour modifier le comportement du modèle. Ces définitions suffisent pour décider en comité ; le jargon supplémentaire peut attendre l’équipe technique. Geste : écrire sur un tableau « documents qui changent » versus « comportement stable à ancrer ». À Boulogne, ce simple partage de vocabulaire a évité trois semaines de malentendu entre métier et prestataire.
À Lille, une PME a confondu « entraîner » et « brancher un dossier » : le piège était le vocabulaire magique. Clarifiez aussi ce que vous n’allez pas faire — par exemple, ne pas forcer un grand modèle là où une classification classique suffit. Reliez le canal d’hébergement à local ou cloud dès le cadrage, car RAG cloud et RAG local n’ont pas les mêmes implications données.
Comparaison pratique
Mise à jour des connaissances : le RAG gagne souvent, car on met à jour les documents. Style et format : le fine-tuning peut gagner. Traçabilité : le RAG peut s’appuyer sur des passages explicites. Complexité opérationnelle : les deux exigent de l’ingénierie ; le fine-tuning ajoute données d’entraînement, versioning et risque de régression. Aucune méthode n’excuse un corpus sale ou des droits d’accès flous.
À Amiens, une collectivité a voulu un fine-tuning « pour être sérieuse » alors que ses guides citoyens changeaient chaque mois. Geste : chronométrer le rythme de mise à jour de votre base. Si elle bouge souvent, commencez RAG. Piège : cumuler un fine-tuning médiocre et un RAG médiocre — système cher et confiant dans l’erreur. Exigez un jeu de questions dorées avant tout chantier lourd.
| Besoin | Piste première | Pourquoi |
|---|---|---|
| Docs qui changent | RAG | Actualisation sans réentraîner |
| Citations / sources | RAG | Contexte explicite |
| Ton de marque stable | FT après RAG | Comportement |
| Peu d’exemples labellisés | RAG | FT exige des données |
| Équipe sans ML | RAG | Courbe plus accessible |
Cas d’usage
FAQ interne, guides procédés, base documentaire publique : RAG en première intention. Assistant qui doit toujours répondre dans un format métier strict : fine-tuning ou prompting fort avec validations, parfois combinaison. Classification de tickets : envisagez d’abord des approches spécialisées selon le cas — ne forcez pas un grand modèle partout. À Roubaix, une association a limité le besoin à une petite base de procédures bénévoles et des prompts soignés, sans fine-tuning.
À Valenciennes, une ETI industrielle a indexé des PDF techniques avec contrôle d’accès par rôle — voir sécurité. Geste : lister dix questions que le système doit réussir avant de parler d’architecture. Piège : indexer « tout le partage » faute de tri, puis découvrir des fuites. Le cas d’usage clair bat la stack impressionnante.
Coûts à prévoir (sans montants)
RAG : ingestion, embeddings, stockage vectoriel, évaluation, maintenance des documents, sécurité d’accès. Fine-tuning : collecte d’exemples, nettoyage, ressources d’entraînement, évaluation, versioning, risque de régression. Reliez ces postes à coûts et remplissez avec vos chiffres. IAHDF n’invente aucun devis. Le temps humain d’évaluation est souvent le poste sous-estimé des deux côtés.
À Arras, une équipe a cru à un fine-tuning « gratuit » via des crédits, puis a découvert des semaines d’ingénierie. Geste : une ligne « heures d’évaluation » dans le tableur avant le go. Piège : comparer uniquement l’inférence cloud au serveur local sans compter la préparation corpus. Un RAG « simple » coûte cher si personne ne met à jour les documents.
Combiner
Souvent : RAG pour la connaissance, instructions système solides, parfois un petit adaptateur plus tard. Évitez le fine-tuning « pour faire savant » sur un corpus qui bouge chaque semaine. À Lens, une PME a stabilisé d’abord la recherche d’extraits, puis seulement discuté d’un adaptateur de format. Geste : prouver le plafond du RAG avant d’ouvrir le chantier fine-tuning.
Piège : empiler des adaptateurs opaques sans métriques. Documentez datasets, versions, critères. La combinaison réussie est une boucle d’évaluation, pas une addition de modules. Reliez aussi à votre banc de test : sans banc, vous ne saurez pas si la combinaison aide ou nuit.
Arbre de décision
1) La connaissance est-elle documentaire et changeante ? Orientiez-vous vers le RAG. 2) Avez-vous de nombreux exemples de paires entrée/sortie stables ? Sinon, pas de fine-tuning. 3) Avez-vous une équipe pour évaluer les régressions ? Sinon, pas de fine-tuning. 4) Besoin de citations ? RAG. 5) Relire local/cloud pour l’hébergement. Écrivez les réponses datées. Sans écrit, l’arbre n’a pas été parcouru.
À Dunkerque, une direction a sauté à l’étape fine-tuning sous effet démo. Le retour arrière a coûté plus cher que le cadrage initial. Geste : atelier d’une heure avec le tableau ci-dessus imprimé. Piège : traiter LoRA comme obligatoire — ce n’est qu’une technique d’adaptation parmi d’autres, inutile sans évaluation. Pour la plupart des PME régionales, la priorité reste la qualité documentaire et les droits d’accès.
Exemples Hauts-de-France
PME industrielle près de Douai : RAG sur documentation technique PDF, accès par rôle, questions dorées mensuelles. Collectivité à Saint-Quentin : RAG sur contenus publics d’abord ; fine-tuning hors sujet au début. Association à Beauvais : pas de fine-tuning ; prompts et petite base documentaire bénévole. ESN à Lille : RAG client isolé, fine-tuning uniquement sur jeux d’exemples non personnels et validés juridiquement.
À Compiègne, une équipe a reporté le fine-tuning faute d’exemples labellisés suffisants — décision mature. À Boulogne, une structure a découvert que le vrai problème était le désordre documentaire, pas le modèle. Geste commun : nettoyer le corpus avant d’acheter de la complexité. Piège commun : promettre « l’IA qui connaît toute l’entreprise » pour le mois suivant.
Évaluer avant d’industrialiser
Construisez un jeu de questions dorées, des critères (exactitude, invention, citation, ton), et un rythme de rejeu. À Arras, le rejeu mensuel a évité une mise en prod aveugle après une mise à jour de modèle. Geste : un propriétaire nommé du jeu doré. Piège : évaluer seulement le « feeling » en démo. Sans évaluation, RAG et fine-tuning ne sont que des histoires. Croisez avec sécurité avant l’ouverture aux utilisateurs.
Préparer le corpus avant la stack
Avant embeddings et adaptateurs, triez : documents à jour, doublons, droits, formats. À Lille, une PME a gagné plus en nettoyant son partage qu’en changeant de modèle. Geste : atelier de tri d’une demi-journée avec propriétaires documentaires. Piège : indexer d’abord, classer ensuite — vous gravez le désordre dans la base vectorielle. Un corpus propre est déjà une spécialisation.
À Lens, une collectivité a commencé par les guides citoyens publics pour prouver la valeur sans exposer les dossiers internes. Reliez ce démarrage à sécurité et à données. Le piège politique est de promettre « toute la GED » pour le trimestre : promettez plutôt dix questions réussies, puis élargissez. La stack suit le corpus, rarement l’inverse. À Arras, ce contrat de dix questions a calmé une demande de fine-tuning prématurée. Mesurez d’abord ; complexifiez ensuite, jamais l’inverse.
Ce que « ops » veut dire ici
Même sans fine-tuning, un RAG exige des opérations : rejouer le jeu doré après mise à jour, surveiller les échecs de retrieve, gérer les versions de documents, alerter quand une source critique disparaît. À Valenciennes, l’absence de propriétaire ops a laissé un guide obsolète répondre pendant des semaines. Geste : runbook d’une page. Piège : traiter le RAG comme un projet livré une fois. Si vous ajoutez du fine-tuning, le runbook double — datasets, régressions, rollback.
Budgétez ces opérations dans le TCO. Un système « gratuit » qui consomme une demi-journée par semaine n’est pas gratuit. Nommez le propriétaire avant le go-live. Sans ops, vous n’avez pas spécialisé l’IA : vous avez installé une dette. À Saint-Quentin, le propriétaire ops a obtenu un créneau hebdomadaire protégé : sans ce temps, le runbook restait purement décoratif. Si la direction refuse ce créneau, diminuez le périmètre du système plutôt que de prétendre industrialiser à temps zéro. Un petit RAG tenu bat un grand RAG orphelin, y compris sur le plan de la confiance usagers. Annoncez ce choix de sobriété dès le cadrage pour éviter la déception politique plus tard. La feuille de route élargie peut attendre la preuve.
Pour aller plus loin
Tutoriels RAG du catalogue · Sécurité · Coûts · Agenda · Inscription.
Questions fréquentes
Quelle méthode pour que l’IA connaisse nos process ?
Dans la majorité des cas documentaires, un RAG bien conçu sur des procédures à jour est le point de départ le plus raisonnable. Il permet d’actualiser la connaissance sans cycle d’entraînement, et d’exiger des réponses ancrées dans des extraits. Le fine-tuning intervient plus tard si vous devez stabiliser un comportement ou un format difficile à obtenir autrement, et seulement si vous disposez d’exemples de qualité et d’une capacité d’évaluation. Beaucoup d’échecs viennent d’un fine-tuning prématuré sur un corpus vivant. Écrivez d’abord les questions métier que vous voulez réussir, mesurez un RAG minimal, puis seulement discutez fine-tuning. Articulez aussi droits d’accès et classification des documents dès le début.
Le fine-tuning est-il plus « puissant » que le RAG ?
Pas dans l’absolu. Fine-tuning et RAG optimisent des choses différentes. Le fine-tuning peut ancrer un style ou une tâche répétitive ; il mémorise mal une base documentaire changeante et peut halluciner avec assurance. Le RAG apporte du contexte frais mais dépend de la qualité de la recherche d’extraits. Un fine-tuning médiocre plus un RAG médiocre donne un système cher et confiant dans l’erreur. Choisissez selon le besoin, mesurez avec un jeu de questions dorées, et refusez le vocabulaire magique en comité de direction. La puissance réelle, c’est la boucle d’évaluation et la discipline données.
Peut-on faire du RAG sans GPU ?
Souvent oui pour des volumes modestes, selon modèles d’embedding et de génération choisis (API cloud ou petit modèle local). Le GPU devient plus pertinent quand la charge, la taille de modèle ou la latence l’exigent. Ne commencez pas par l’achat matériel : commencez par le corpus, le découpage, les droits, et dix questions d’évaluation. Reliez ensuite à matériel et local/cloud. Un RAG cloud bien borné peut être une étape intermédiaire honnête avant tout investissement serveur. Lisez les pages tarifaires officielles si vous utilisez des API ; n’inventez pas de coûts ici.
LoRA est-il obligatoire ?
Non. LoRA est une technique d’adaptation plus légère que certains fine-tunings complets, utile dans des contextes avancés. Elle n’est ni magique ni obligatoire. Si votre équipe ne maîtrise pas l’évaluation, LoRA n’arrange rien. Traitez-la comme une option après un RAG solide et un besoin de comportement prouvé. Documentez datasets, versions, métriques. Sans cela, vous accumulez des adaptateurs opaques. Pour la plupart des PME régionales, la priorité reste la qualité documentaire et la sécurité d’accès. Résistez au jargon qui impressionne le comité sans réduire le risque.
Combien ça coûte ?
Aucun montant ici. Listez les postes : temps de préparation corpus, infrastructure, embeddings, inférence, évaluation humaine, maintenance. Remplissez avec vos chiffres via la méthode de calcul. Comparez au coût de ne rien faire (temps perdu, erreurs). Un fine-tuning « gratuit » en crédit de calcul peut coûter cher en semaines ingénieur. Un RAG « simple » peut coûter cher si personne ne met à jour les documents. Le budget honnête inclut les humains — toujours. Présentez des fourchettes et une date de revue plutôt qu’un faux précis théâtral.