Trois techniques, une seule question qui compte : quel problème résout-on ? Voici une méthode de décision en 5 questions, avec seuils de coût et de volume, pour éviter les choix qui coûtent des mois de budget.
La confusion persiste en 2026 chez de nombreux comités de direction : faut-il fine-tuner un modèle, construire un pipeline RAG (Retrieval-Augmented Generation), ou simplement mieux écrire les prompts ? Selon des sondages récents, 72 % des dirigeants IA restent indécis entre RAG et fine-tuning pour leurs projets en entrant dans 2026, et cette confusion est compréhensible. Pourtant, ces trois approches ne sont pas des concurrentes : elles résolvent des problèmes différents.
Le fine-tuning change le comportement d'un modèle, le RAG change ce qu'il sait, et le prompt engineering façonne les deux sans toucher à l'infrastructure. Un cadre plus visuel le confirme : le prompt engineering mobilise les capacités inhérentes du modèle avec un minimum de besoin en connaissances externes et en adaptation ; le RAG s'apparente à fournir au modèle un manuel sur mesure pour la récupération d'informations précises ; le fine-tuning ressemble à un étudiant qui internalise la connaissance dans la durée, adapté aux cas nécessitant la reproduction de structures, de styles ou de formats spécifiques.
Or, dans les PME et ETI françaises, l'erreur la plus fréquente n'est pas technique : c'est de partir de la technologie plutôt que du problème. Trop d'entreprises démarrent leurs projets IA par la question « que peut-on faire avec cette technologie ? » au lieu de demander « quelle tâche nous coûte réellement le plus cher aujourd'hui ? », une approche qui conduit systématiquement à des échecs coûteux. Cette dérive explique une bonne part des budgets IA engloutis sans retour mesurable, un phénomène documenté à grande échelle : les analyses consolidées de McKinsey, BCG et Gartner situent le taux d'échec des projets IA entre 70 et 85 %.
Avant d'arbitrer entre les trois techniques, il faut répondre, dans l'ordre, à cinq questions concrètes. Cette séquence évite de sauter directement à la solution la plus visible médiatiquement — souvent le fine-tuning, perçu (à tort) comme la voie « la plus sérieuse ».
C'est la distinction fondamentale. Il faut utiliser le RAG pour la connaissance, et le fine-tuning pour le comportement. Si le modèle ignore une information (un tarif interne, une procédure, une clause contractuelle), aucune quantité de fine-tuning ne comblera durablement ce manque : le modèle risque de mémoriser des exemples d'entraînement sans vraiment « apprendre » la connaissance, et il ne généralisera pas bien à des questions formulées différemment. À l'inverse, si le modèle connaît la bonne réponse mais la formule mal — mauvais ton, mauvais format, raisonnement inadapté — c'est un problème de comportement : le prompt engineering échoue à le corriger, il faut alors fine-tuner.
Le volume conditionne directement la rentabilité de chaque option. Un cadre de décision opérationnel propose des seuils clairs : en dessous de 10 000 requêtes par mois, le prompt engineering ou le RAG suffisent ; entre 10 000 et 1 million, le RAG s'impose ; au-delà d'1 million de requêtes avec un besoin de cohérence de format, le fine-tuning devient rentable. Pour la grande majorité des PME et ETI françaises, dont les volumes réels restent souvent bien inférieurs au million de requêtes mensuelles, ce seuil élimine d'emblée le fine-tuning dans un premier temps.
Un fine-tuning fige une connaissance à un instant T ; il faut le refaire à chaque mise à jour substantielle. Le critère de fraîcheur des données tranche donc souvent seul : si la connaissance sous-jacente évolue quotidiennement ou chaque semaine, seul le RAG convient ; si c'est mensuel, RAG ou fine-tuning sont envisageables ; si c'est annuel, le fine-tuning devient viable. Dans une entreprise dont les procédures, tarifs ou catalogues bougent en continu — le cas le plus courant —, le RAG reste la seule option qui ne nécessite pas un nouveau cycle d'entraînement à chaque changement.
Dans les secteurs réglementés (juridique, santé, finance, secteur public) ou dès que la réponse engage l'entreprise contractuellement, la citation de la source n'est pas une option. Si le cas d'usage exige une attribution de source, le RAG est structurellement requis ; sinon, d'autres options s'ouvrent. Un fine-tuning, aussi bon soit-il, ne peut pas montrer d'où vient une information puisqu'il l'a « digérée » dans ses poids : il n'existe pas de mécanisme de citation natif.
Le coût de chaque option n'est pas seulement un montant, c'est un profil de dépense. Le choix affecte directement le coût, qui va de quasi nul pour le prompt engineering à une dépense GPU significative pour le fine-tuning. Sur le fine-tuning proprement dit : il présente les coûts de démarrage les plus élevés mais peut réduire le coût par requête ; la collecte, le nettoyage et le formatage des données peuvent prendre des semaines à des mois ; OpenAI facture environ 25 dollars par million de tokens d'entraînement pour GPT-4o-mini et environ 100 dollars par million pour GPT-4o ; les modèles open source nécessitent du calcul GPU, entre 2 et 8 dollars de l'heure. Autre contrainte souvent oubliée : on peut fine-tuner GPT-4o, GPT-4o-mini, Llama et Mistral, mais pas les modèles phares Claude ou Gemini, ce qui restreint d'emblée le choix des fournisseurs pour cette option.
Côté RAG, les budgets français observés en 2026 donnent une fourchette réaliste pour un premier déploiement en PME : comptez 10 000 à 50 000 euros de mise en place et 1 000 à 3 000 euros par mois de fonctionnement selon les baromètres français. Une autre source de conseil confirme cet ordre de grandeur : un assistant IA interne avec recherche dans la base documentaire de l'entreprise tourne entre 25 000 et 45 000 euros, et un projet plus ambitieux touchant plusieurs systèmes interconnectés peut atteindre 60 000 à 80 000 euros.
Les modèles génériques de 2026 ont considérablement réduit le besoin de personnalisation lourde. Pour la plupart des équipes en 2026, la hiérarchie de décision est claire : commencer par le prompt engineering, gratuit, rapide, et qui force à comprendre ce que le modèle sait faire nativement. Cette étape n'est pas un simple préalable cosmétique : elle sert de diagnostic gratuit avant tout investissement.
Le raisonnement se poursuit logiquement : ajouter le RAG quand le produit doit connaître des choses que le modèle ne sait pas — un pipeline RAG bien construit, avec ingestion de qualité, récupération hybride et génération ancrée, résout 80 à 90 % des besoins d'IA à forte intensité de connaissance. Le fine-tuning n'arrive qu'en dernier recours : seulement quand un écart précis et démontré persiste, que le RAG et le prompt engineering ne parviennent pas à combler, et que l'entreprise dispose des données, de l'infrastructure et de la capacité d'ingénierie pour le faire correctement.
Cette progression se retrouve dans les guides techniques les plus récents : si la qualité de sortie reste insuffisante par manque de connaissance spécifique, le RAG est ajouté ensuite, car plus rapide à mettre en place et à itérer que le fine-tuning et ne nécessitant pas de jeu de données d'entraînement organisé ; le fine-tuning est généralement mobilisé en dernier, spécifiquement quand le prompt et le RAG ensemble ne parviennent toujours pas à atteindre un style, un format ou un comportement spécialisé suffisamment cohérent.
Trois schémas d'échec reviennent avec une régularité frappante dans les retours d'expérience de terrain.
Premier schéma : sauter directement au fine-tuning pour un problème de connaissance. Une entreprise qui veut que son assistant connaisse ses tarifs, son catalogue ou ses procédures internes lance un chantier de fine-tuning coûteux, alors qu'un RAG bien conçu aurait résolu le problème en quelques semaines et à moindre coût, sans figer une connaissance vouée à évoluer chaque trimestre.
Deuxième schéma : construire un RAG sans gouvernance de la qualité documentaire. Le succès d'un RAG ne dépend pas d'abord du modèle choisi. La réussite dépend moins du modèle que de la qualité documentaire, des droits d'accès et de l'évaluation. Un retour d'expérience détaillé sur la mise en production d'un agent RAG le confirme : une application d'IA générative n'a rien de déterministe, et sa base de connaissances est vivante ; sans mesure, sa qualité peut dériver sans qu'on s'en aperçoive, et beaucoup d'entreprises butent sur la mise en production à grande échelle pour cette raison précise. Sans garde-fous — citation systématique des sources, droit de répondre « je ne sais pas », jeu de questions de référence rejoué régulièrement — le RAG dérive silencieusement, et personne ne s'en aperçoit avant qu'un client ou un auditeur pointe une réponse fausse.
Troisième schéma : développer en interne sans méthode plutôt que cadrer avec un partenaire. Les chiffres sont sans appel sur ce point précis : les entreprises qui tentent de développer en interne des solutions d'IA générative personnalisées enregistrent des taux d'échec supérieurs à 95 %, contre des taux de réussite oscillant entre 20 et 30 % pour celles qui achètent des outils prêts à l'emploi auprès de fournisseurs. Ce n'est pas un plaidoyer contre la personnalisation, mais un signal clair : sans méthode de cadrage, la technique choisie — RAG ou fine-tuning — importe moins que l'absence de processus d'évaluation continue.
Un dernier point mérite d'être souligné pour les données sensibles : dans les secteurs réglementés, le choix d'architecture a une dimension juridique directe. Pour des données sensibles ou réglementées (santé, pharma, finance, secteur public), il est préférable de privilégier un RAG souverain déployé on-premise, où les documents ne quittent pas l'infrastructure et la conformité RGPD est intégrée dès la conception ; le RAG-as-a-Service, hébergé sur le cloud du prestataire, convient surtout aux données non sensibles et au démarrage rapide.
La dichotomie « RAG contre fine-tuning » s'estompe en 2026 dans les architectures les plus matures. La plupart des entreprises en 2026 finissent avec trois ou quatre pipelines IA en production, chacun combinant différemment prompt engineering, RAG et fine-tuning ; la décision n'est plus « RAG contre fine-tuning ». Un exemple concret illustre cette combinaison : un modèle de raisonnement juridique fine-tuné pour analyser les contrats et identifier les risques, combiné à un RAG qui récupère les documents contractuels réels et la jurisprudence pertinente pour chaque requête.
Pour une PME ou une ETI qui démarre, la bonne discipline reste néanmoins de refuser la combinaison dès le premier projet. Les équipes qui livrent vite et dépensent efficacement sont celles qui résistent à la tentation de sur-ingénierer trop tôt : elles valident avec des prompts, construisent avec le RAG, et ne fine-tunent que sélectivement. C'est cette discipline — poser les cinq questions dans l'ordre, chiffrer le volume réel de requêtes, vérifier la fréquence de mise à jour des données, avant de sortir la carte bancaire — qui distingue un projet qui tient sur la durée d'un pilote impressionnant qui ne dépassera jamais la démonstration. Pour un diagnostic rapide de votre cas d'usage, notre offre de conseil et formation IA inclut un audit qui tranche cette question en amont, avant tout engagement de développement. Vous pouvez également consulter le détail de notre expertise en architectures RAG et fine-tuning pour situer votre projet dans ce cadre de décision.
Nous utilisons des cookies de mesure d'audience et de suivi publicitaire pour comprendre la fréquentation du site et l'efficacité de nos annonces. Rien n'est déposé sans votre accord. En savoir plus