Les systèmes généralistes savent rédiger, classer, extraire et raisonner sur de nombreux sujets. Cela ne signifie pas qu’ils connaissent les règles internes d’une entreprise, son vocabulaire, ses exceptions contractuelles ou le niveau de prudence attendu par ses équipes. La réponse peut paraître convaincante et pourtant rester inutilisable dans un contexte réglementé.
La tentation consiste alors à demander un « modèle propriétaire ». L’expression rassure. Elle mélange pourtant quatre actifs très différents : un modèle entraîné, des données détenues par l’entreprise, une méthode d’évaluation et un système applicatif. Dans beaucoup de projets, la valeur durable se trouve moins dans les poids du modèle que dans le corpus nettoyé, les exemples annotés, les règles de décision et la boucle de retour métier.
Le bon objectif n’est donc pas de posséder le plus gros modèle. C’est de construire le plus petit système capable de prendre la bonne décision, au bon coût, avec un niveau d’erreur connu.
1. Les chiffres à garder en tête
L’AI Index 2026 de Stanford rappelle à quel point la couche modèle reste concentrée : plus de 90 % des modèles d’IA considérés comme notables en 2025 provenaient de l’industrie. Une PME ou une ETI rivalise rarement de façon raisonnable sur l’entraînement fondationnel. La spécialisation, l’orchestration et la donnée métier offrent un terrain beaucoup plus accessible.
Le prix des capacités, lui, évolue très vite. L’AI Index 2025 estimait que le coût d’inférence d’un système atteignant un niveau comparable à GPT‑3.5 avait chuté de plus de 280 fois entre novembre 2022 et octobre 2024. Cette baisse change le calcul économique : une architecture figée autour d’un modèle coûteux peut devenir obsolète avant même d’être amortie.
Les benchmarks d’inférence montrent la même accélération. MLCommons a reçu 17 457 résultats de 23 organisations pour MLPerf Inference v5.0. Six mois plus tard, la version v5.1 réunissait 27 participants et les meilleurs systèmes progressaient jusqu’à 50 % sur certains scénarios par rapport à v5.0. Acheter une performance théorique sans mécanisme de routage ou de remplacement crée donc une dépendance coûteuse.
Les évaluations internes doivent aussi rester modestes. Un retour d’expérience publié sur Hugging Face a comparé plusieurs variantes de RAG sur seulement 156 requêtes : le système naïf atteignait 70,5 % sur la métrique retenue, contre 63,8 % pour une variante dite contextuelle ; la recherche dense atteignait 69,2 %, contre 63,5 % pour l’hybride. Ce résultat ne condamne aucune technique. Il montre qu’une méthode réputée supérieure peut dégrader un cas réel si les données, les paramètres ou la mesure ne sont pas adaptés.
Enfin, une note moyenne ne suffit pas. Le benchmark RTEB impose au minimum 1 000 documents et 50 requêtes par dataset, avec une couverture de 20 langues. Cette échelle donne un ordre de grandeur : valider une recherche documentaire sur dix questions choisies par l’équipe projet produit une démonstration, pas une preuve.
2. Le bilan de données : l’actif avant le modèle
Avant de parler d’architecture, Logiks recommande de dresser un bilan de données. Il tient sur une page et répond à neuf questions.
| Dimension | Question de décision | Preuve attendue |
|---|---|---|
| Cas d’usage | Quelle décision ou production doit être améliorée ? | processus actuel et résultat cible |
| Population | Quels documents, objets ou utilisateurs sont concernés ? | volumétrie et segmentation |
| Signal | Quelle information permet de produire la bonne réponse ? | exemples positifs et contre-exemples |
| Vérité terrain | Qui sait dire qu’un résultat est correct ? | règle, expert ou issue observée |
| Couverture | Les cas rares et coûteux sont-ils présents ? | distribution par scénario |
| Fraîcheur | À quelle vitesse les connaissances changent-elles ? | fréquence de mise à jour |
| Droits | Peut-on utiliser les données pour cet objectif ? | base légale, licence, contrat |
| Sensibilité | Quelles données ne doivent pas sortir d’un périmètre ? | classification et localisation |
| Réversibilité | Peut-on exporter le corpus, les labels et les tests ? | formats, versions et documentation |
Ce bilan évite une erreur fréquente : entraîner un modèle pour compenser un problème documentaire. Si les procédures se contredisent, si les réponses de référence n’existent pas ou si les experts ne s’accordent pas, le modèle reproduira l’incertitude. Il pourra même la rendre plus difficile à voir grâce à une formulation fluide.
Le dataset utile n’est pas nécessairement massif. Il doit surtout représenter les décisions qui comptent. Mille exemples redondants d’un cas simple valent parfois moins que cinquante contre-exemples couvrant les frontières de la règle.
3. L’arbre de décision : du standard à l’entraînement
La personnalisation se choisit par paliers. On ne passe au palier suivant que lorsque le précédent ne peut pas satisfaire une exigence mesurée.
3.1. Palier 1 — Utiliser un modèle standard
Cette option convient lorsque la tâche est générique, que le contexte tient dans la requête et que l’erreur est facilement vérifiable. Reformuler un texte, proposer des variantes de titre ou transformer des notes en compte rendu ne justifie généralement pas un entraînement.
La vraie question porte sur le contrôle : quelles données sont envoyées, combien de temps sont-elles conservées, et le fournisseur les utilise-t-il pour améliorer ses services ? Ces réponses relèvent du contrat et de la configuration, pas d’une promesse commerciale.
3.2. Palier 2 — Structurer le prompt et les outils
Un prompt robuste décrit le rôle, l’entrée, la sortie, les contraintes et les critères de refus. Il ne se limite pas à une longue consigne. Les validateurs, calculateurs, moteurs de règles et appels API doivent prendre en charge ce qui exige une exactitude déterministe.
Exemple : pour établir une proposition commerciale, le modèle peut rédiger l’argumentaire. Le calcul de marge, la disponibilité des ressources et l’éligibilité à une remise restent confiés à des services contrôlés. Le langage est probabiliste. La règle financière ne doit pas l’être.
3.3. Palier 3 — Ajouter une recherche documentaire, ou RAG
Le RAG fournit au modèle des extraits récupérés dans un corpus. Il convient lorsque la connaissance change souvent, doit être citée ou ne peut pas être intégrée de façon fiable dans les poids. Une politique RH, un catalogue technique ou une base de contrats appartiennent à cette catégorie.
Le système complet comprend toutefois bien plus qu’une base vectorielle : ingestion, découpage, métadonnées, droits d’accès, recherche lexicale et sémantique, reranking, citations, versionnement et mesure. Une réponse fausse peut venir du modèle, mais aussi d’un document absent, d’une mauvaise extraction, d’un filtre d’autorisation ou d’un passage mal classé.
3.4. Palier 4 — Adapter le modèle
Le fine-tuning devient pertinent lorsque le défaut est stable et répétitif : format spécifique, terminologie, style de classification, séquence d’actions ou comportement attendu. Il peut réduire la longueur des prompts et améliorer la régularité. Il ne constitue pas une bonne base de connaissances pour des faits qui changent chaque semaine.
On distingue notamment l’ajustement supervisé à partir d’exemples entrée-sortie, l’adaptation légère de type LoRA et l’entraînement par préférences. Le choix dépend du fournisseur, du modèle ouvert ou fermé, du volume d’exemples et de la possibilité de réentraîner. Dans tous les cas, le dataset d’évaluation doit rester séparé du dataset d’entraînement.
3.5. Palier 5 — Entraîner un modèle spécialisé
Ce palier se défend lorsque le domaine possèd'un signal inaccessible aux modèles existants, que le volume d’usage justifie l’investissement, ou que des contraintes de latence, d’embarqué et de souveraineté l’imposent. Il concerne plus naturellement la vision industrielle, les séries temporelles, la détection sur capteurs ou certains vocabulaires scientifiques qu’un simple assistant rédactionnel.
Il faut alors financer la recherche de données, l’entraînement, l’infrastructure, les évaluations, la sécurité, la maintenance et le remplacement futur. Un prototype performant ne constitue que le premier actif. La capacité à le reproduire en est un autre.
4. Concevoir un dataset qui résiste au réel
Un bon dataset reflète le terrain, y compris ses zones inconfortables. Sa construction peut suivre six couches.
La population. On définit d’abord l’univers visé : pays, langues, types de clients, versions de produits, canaux et périodes. Sans cette frontière, une précision de 95 % ne dit rien.
L’échantillonnage. Les cas fréquents assurent le volume. Les cas rares assurent la sécurité. Dans un contrôle documentaire, le corpus doit inclure les pièces incomplètes, les scans dégradés, les changements de mise en page et les exceptions juridiques, même s’ils représentent peu de documents.
La consigne d’annotation. Deux experts doivent pouvoir lire la même règle et produire le même label. On ajoute des exemples, des exclusions et une procédure d’escalade. Le taux d’accord entre annotateurs révèle les ambiguïtés de la tâche ; un désaccord élevé ne se corrige pas avec davantage de GPU.
La provenance. Chaque élément conserve sa source, sa date, sa licence, sa transformation et sa version. Cette traçabilité facilite une suppression, une correction ou une analyse d’incident. Elle devient essentielle lorsque des données personnelles ou des contenus sous droits sont concernés.
La séparation. Les jeux d’entraînement, de validation et de test ne doivent pas partager des doublons ni des variantes presque identiques. Pour des données temporelles, le test se situe après l’entraînement. Pour des clients, on peut séparer par compte afin de mesurer la généralisation.
Le jeu rouge. Il réunit les entrées hostiles, ambiguës ou hors périmètre : injection de prompt, document contradictoire, langue inattendue, données manquantes, instruction interdite. On n’attend pas la production pour découvrir ces scénarios.
5. L’évaluation à trois étages
Une IA métier ne se valide pas avec une seule note. Elle se mesure à trois niveaux.
Le premier concerne le composant : précision d’extraction, rappel de recherche, calibration d’un score, respect d’un schéma JSON, latence et coût. Ces métriques aident l’équipe technique à localiser un défaut.
Le deuxième concerne la tâche. Une réponse est-elle utile, complète, sourcée et conforme aux règles ? Un panel d’experts note des cas masqués. Les critères doivent être observables. « Bonne qualité » n’est pas un critère ; « identifie les trois clauses incompatibles et cite leur emplacement » en est un.
Le troisième concerne le résultat métier : temps de traitement, taux de reprise, revenu, risque évité ou satisfaction. Gagner cinq points de précision ne crée aucune valeur si l’utilisateur doit toujours relire chaque sortie. À l’inverse, un système moins spectaculaire peut supprimer une saisie et réduire le délai d’une journée.
Les seuils dépendent du coût des erreurs. Pour un outil d’inspiration, un faux positif est peu grave. Pour bloquer un paiement ou orienter un patient, la tolérance change radicalement. On documente donc séparément les faux positifs, les faux négatifs, les abstentions et les cas transmis à un humain.
6. Cas pratique : spécialiser un assistant d’avant-vente
Une entreprise B2B souhaite répondre plus vite à ses appels d’offres. Elle possède 8 000 documents, mais seulement 1 200 sont encore valides. Les réponses historiques contiennent des engagements parfois dépassés.
Le premier réflexe serait de fine-tuner un modèle sur les dossiers gagnés. Ce serait dangereux : les formulations anciennes pourraient être mémorisées sans respecter le catalogue actuel.
L’architecture retenue commence plutôt par une base documentaire versionnée. Les documents sont segmentés par produit, pays, date d’effet et niveau de confidentialité. Une recherche hybride récupère les passages, puis un modèle produit une réponse avec citations. Un moteur de règles interdit les promesses sur les SLA, prix et certifications absentes du référentiel.
Après plusieurs semaines, les évaluations montrent un défaut stable : le modèle respecte les faits, mais structure mal les matrices de conformité. Un ajustement léger est alors entraîné sur 600 exemples relus. Le contenu reste dans le RAG ; le fine-tuning apprend le format et la séquence de raisonnement.
Le projet crée quatre actifs réutilisables : un corpus propre, un jeu de 350 questions de test, une taxonomie de risques et un historique d’erreurs. Le modèle pourra changer. Ces actifs restent.
7. Coûts : raisonner en coût total par décision
Le prix d’un token ne résume pas l’économie du système. Le coût total inclut au moins :
- la collecte, le nettoyage et les droits sur les données ;
- l’annotation et l’arbitrage des désaccords ;
- l’expérimentation, l’entraînement et le stockage ;
- l’inférence, la recherche, les outils et les journaux ;
- l’évaluation à chaque version ;
- la supervision humaine et le traitement des erreurs ;
- la sécurité, la conformité et la réponse aux incidents ;
- la migration vers un autre modèle ou fournisseur.
On ramène ensuite cette somme au nombre de décisions effectivement utiles. Une option bon marché qui oblige à reprendre 40 % des sorties coûte plus cher qu’un service premium bien routé. À l’inverse, utiliser la capacité maximale pour toutes les requêtes gaspille du budget si 70 % peuvent être traitées par une option légère.
Une architecture mature pratique le routage : modèle léger pour les tâches simples, modèle plus capable pour les cas complexes, règles déterministes pour les calculs et humain pour les exceptions. Elle fixe aussi un budget par dossier. Sans plafond, la qualité apparente peut masquer une dérive silencieuse.
8. Propriété, confidentialité et réversibilité
« Vos données restent vos données » ne répond pas à toutes les questions. Il faut distinguer les données sources, les annotations, les embeddings, les prompts, les poids adaptés, les journaux et les sorties.
Le contrat précise qui peut les utiliser, où ils sont hébergés, combien de temps ils sont conservés, comment ils sont supprimés et ce qui est exportable. Pour un modèle fermé, l’accès au service n’équivaut pas à la propriété des poids. Pour un modèle ouvert, la licence peut imposer des conditions sur l’usage ou la redistribution.
Le RGPD s’applique dès que des données personnelles entrent dans le cycle. Minimisation, finalité, durée de conservation, droits des personnes et sécurité doivent être intégrés. Une pseudonymisation réduit certains risques sans rendre automatiquement les données anonymes.
La réversibilité se teste. Une fois par an, l’équipe devrait pouvoir exporter le corpus, les métadonnées, le jeu d’évaluation, les configurations et les traces nécessaires, puis exécuter un échantillon sur une solution de remplacement. Un plan de sortie jamais exercé reste une hypothèse.
9. Les signaux qu’un entraînement est prématuré
Plusieurs symptômes invitent à revenir en arrière :
- l’équipe ne sait pas formuler la métrique métier ;
- les experts ne s’accordent pas sur les réponses de référence ;
- le corpus contient plusieurs versions non datées ;
- la démonstration repose sur moins de cinquante cas choisis ;
- le problème principal vient de la recherche ou des droits d’accès ;
- les connaissances changent plus vite que le cycle de réentraînement ;
- le coût d’une erreur n’a pas été estimé ;
- aucun propriétaire n’est désigné pour maintenir le dataset.
Dans ce contexte, entraîner ajoute une couche d’opacité. Le travail prioritaire consiste à clarifier la décision, nettoyer les connaissances et bâtir l’évaluation.
10. Feuille de route en douze semaines
Semaines 1 et 2 : cadrage. L’équipe définit la décision, le processus actuel, le coût des erreurs et les données autorisées. Elle sélectionne cinquante cas représentatifs.
Semaines 3 et 4 : référence simple. La baseline repose sur une capacité standard et une architecture minimale. On mesure qualité, latence, coût et taux d’abstention.
Semaines 5 et 6 : données. Le corpus est nettoyé, versionné et documenté. Le jeu d’évaluation atteint plusieurs centaines de cas, avec les exceptions critiques.
Semaines 7 et 8 : comparaison. Prompt, RAG, outils et éventuel fine-tuning sont testés sur le même jeu. Les résultats sont analysés par segment, pas seulement en moyenne.
Semaines 9 et 10 : pilote. Des utilisateurs réels travaillent dans un périmètre limité. Les corrections, contournements et refus sont enregistrés.
Semaines 11 et 12 : décision. Le comité compare valeur, risque, coût total et réversibilité. Il décide de déployer, d’adapter, de suspendre ou de réorienter.
Le livrable principal n’est pas un modèle. C’est une preuve reproductible que le système améliore une décision sans déplacer le risque ailleurs.
11. Le contrôle de réalité avant investissement
Quatre verdicts suffisent. Standard. La capacité disponible répond au besoin. Enrichi. La connaissance doit être retrouvée dans un corpus. Adapté. Un comportement stable mérite un ajustement. Spécialisé. Le signal, le volume et les contraintes justifient un entraînement propre.
Rien n’oblige à monter. Le choix doit rester réversible. Une équipe mature sait aussi redescendre vers une solution plus simple lorsque le marché progresse, que les coûts baissent ou que le besoin se révèle moins différenciant qu’annoncé.
La comparaison finale tient sur le même jeu de cas, dans les mêmes conditions, avec le coût complet et la revue humaine incluse. Elle mentionne les échecs. Elle montre les segments fragiles. Elle conserve les sorties. Le comité peut alors décider sans se laisser impressionner par la seule fluidité de la démonstration, car la décision repose sur une frontière mesurée entre ce que le système accomplit, ce qu’il refuse et ce qu’un opérateur doit encore sécuriser.
12. Questions fréquentes
12.1. Combien d’exemples faut-il pour un fine-tuning ?
Il n’existe pas de nombre universel. Quelques centaines d’exemples cohérents peuvent améliorer un format étroit ; plusieurs milliers restent insuffisants si les labels se contredisent. Une courbe d’apprentissage, construite à 100, 300, 1 000 exemples puis davantage, montre si le gain justifie la collecte.
12.2. Un RAG évite-t-il les hallucinations ?
Non. Il peut réduire les erreurs factuelles et apporter des citations, mais le modèle peut ignorer un passage, mal l’interpréter ou combiner des sources incompatibles. Le système doit mesurer la récupération, vérifier les citations et savoir s’abstenir.
12.3. Un modèle open source garantit-il la souveraineté ?
Non. La souveraineté dépend aussi de l’hébergement, des composants, des compétences, des licences, du matériel et de la capacité à maintenir le système. Des poids téléchargeables améliorent la maîtrise, sans supprimer toutes les dépendances.
12.4. Faut-il conserver toutes les interactions pour améliorer le modèle ?
Non. La conservation doit répondre à une finalité, une durée et un niveau de sensibilité. Un échantillonnage de cas nettoyés et annotés vaut souvent mieux qu’un lac de journaux contenant des données inutiles.
12.5. Quelle est la meilleure protection contre l’obsolescence ?
Séparer les actifs. Le corpus, les règles, les tests et la couche d’orchestration doivent pouvoir survivre au remplacement du modèle. On réduit ainsi le coût d’une migration et on conserve la connaissance acquise.
13. Ce que Logiks recommande
Commencez par constituer le jeu d’évaluation avant de choisir le modèle. Testez le système le plus simple. Spécialisez seulement lorsqu’un défaut stable, important et mesuré le justifie. Protégez surtout le dataset métier, les règles et les cas de test : ce sont eux qui transforment une technologie disponible sur le marché en avantage opérationnel.
14. Sources principales
- Stanford Institute for Human-Centered AI, AI Index Report 2026, chapitres Research & Development et Economy : https://hai.stanford.edu/ai-index/2026-ai-index-report
- Stanford Institute for Human-Centered AI, AI Index Report 2025 : https://hai.stanford.edu/ai-index/2025-ai-index-report
- MLCommons, MLPerf Inference v5.0 Results : https://mlcommons.org/2025/04/mlperf-inference-v5-0-results/
- MLCommons, MLPerf Inference v5.1 Results : https://mlcommons.org/2025/09/mlperf-inference-v5-1-results/
- Hugging Face, Charles Azam, retour d’expérience RAG : https://huggingface.co/blog/charles-azam/rag
- Hugging Face, Retrieval Embedding Benchmark (RTEB) : https://huggingface.co/blog/rteb
- NIST, AI Risk Management Framework, fonction Measure : https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
- CNIL, recommandations pour le développement des systèmes d’IA : https://www.cnil.fr/fr/developpement-des-systemes-dia-les-recommandations-de-la-cnil-pour-respecter-le-rgpd