Spécialisez un modèle lorsqu’une tâche stable reste mal exécutée malgré de bonnes instructions et les bonnes informations, que des exemples fiables existent et qu’un test indépendant démontre un avantage économique. Dans les autres cas, améliorer le contexte, la recherche documentaire ou le workflow est souvent le meilleur investissement.
Commencer par le travail, pas par l’entraînement
« Notre IA doit comprendre notre métier. » Cette demande peut désigner trois problèmes différents : elle ignore une procédure récente, elle classe mal les urgences ou elle produit des comptes rendus trop longs. Acheter le même entraînement pour ces trois défauts reviendrait à financer une formation sans savoir quel travail doit changer.
Notre position chez Amplify : le dirigeant doit d’abord acheter une preuve de progrès sur une tâche identifiable. Définir cette tâche, réunir des exemples jugés corrects, réserver un test indépendant, puis comparer les solutions. Cet ordre évite qu’une démonstration séduisante dicte le budget.
Le prompt donne les instructions et quelques exemples au moment de la demande. Le contexte apporte les informations nécessaires. Le retrieval, ou recherche documentaire, retrouve les passages pertinents ; le RAG les fournit au modèle pour préparer sa réponse. Le fine-tuning modifie des paramètres du modèle à partir d’exemples d’apprentissage, pour adapter certains comportements. Ces leviers peuvent se combiner, mais ne réparent pas les mêmes défauts.
Une PME, deux erreurs et deux investissements différents
Prenons un exemple entièrement fictif : une PME de maintenance veut trier les demandes d’intervention et préparer leur réponse. Son équipe distingue panne bloquante, intervention planifiable et demande d’information. L’IA confond parfois une gêne mineure avec un arrêt de production. Elle cite aussi une ancienne condition contractuelle.
La seconde erreur appelle d’abord une correction documentaire : retrouver le contrat applicable, vérifier sa date et citer la bonne clause. Entraîner le modèle sur les anciens contrats risquerait de figer le problème. Notre guide sur les données vivantes et le choix entre fine-tuning et RAG approfondit cette séparation.
La première erreur peut justifier un autre examen. Si les responsables s’accordent sur les catégories, que les informations utiles sont présentes et que des instructions illustrées échouent encore, leur jugement peut devenir une cible d’apprentissage. Mais si deux responsables classent différemment le même incident, il faut d’abord arbitrer la règle : l’entraînement ne crée pas un consensus métier.
Transformer le jugement en exemples vérifiables
Pour chaque demande, la PME rassemble le message, les éléments de contexte autorisés, la catégorie attendue et une justification courte. Elle conserve aussi les exceptions : description incomplète, incident ambigu, demande hors périmètre. Un expert valide les cas litigieux au lieu de laisser une annotation approximative devenir la vérité d’apprentissage.
Les corrections ont ici plus de valeur qu’une pile de conversations. « Mauvaise réponse » n’enseigne rien de précis. « Classer en urgence parce que la ligne est arrêtée, et non parce que le client écrit en majuscules » rend le critère exploitable.
Une partie des dossiers reste hors de toute optimisation : c’est le jeu de test indépendant, ou held-out. Les variantes d’un même incident ne doivent pas se retrouver des deux côtés. Séparer aussi par période ou par origine aide à vérifier que le système généralise, plutôt qu’il ne reconnaît les exemples déjà vus. Aucun nombre universel de dossiers ne garantit un test probant : le dimensionnement dépend notamment des erreurs rares que l’entreprise doit détecter.
La grille de décision : quel défaut corriger en premier ?
Utilisez ces quatre situations comme une grille, puis exigez la preuve correspondante.
- L’IA répond avec des faits périmés ou introuvables. Réunir questions, documents datés et passages justificatifs. Tester exactitude, citations et capacité à signaler une information absente. Choisir contexte direct ou recherche documentaire avant l’entraînement ; vérifier les droits d’accès aux sources.
- L’IA applique mal un jugement métier stable. Réunir cas classés, justifications et désaccords arbitrés. Tester séparément chaque catégorie, surtout les urgences oubliées. Commencer par des instructions avec exemples ; envisager un fine-tuning supervisé si un écart récurrent subsiste.
- L’IA respecte mal un format ou un ton constant. Réunir briefs, livrables acceptés et corrections. Mesurer conformité et réécriture humaine sur de nouveaux briefs. Essayer d’abord gabarit et contrôles automatiques ; spécialiser si le volume et le gain démontré justifient l’entretien du modèle.
- L’IA échoue à terminer une action avec ses outils. Réunir parcours, erreurs et conditions de reprise. Tester résultat final, doublons et actions interdites. Corriger orchestration et permissions avant d’entraîner un comportement ; conserver les autorisations hors du modèle.
Cette grille permet aussi une réponse mixte : un modèle adapté au tri peut continuer à rechercher les clauses dans une base actualisée. Spécialiser un comportement n’oblige pas à lui confier la mémoire de l’entreprise.
Comparer sur les mêmes dossiers, sans déplacer l’objectif
Pour notre PME fictive, comparons un modèle généraliste correctement instruit, un modèle plus petit non entraîné et, si les prérequis sont réunis, un candidat spécialisé. Tous reçoivent les mêmes informations autorisées et sont évalués dans des conditions comparables. Documentons les différences d’outils ou de ressources plutôt que de les attribuer aux seuls poids.
Avant les essais, le responsable métier fixe les critères : urgences manquées, fausses alertes, temps de correction et coût par dossier accepté. Une moyenne flatteuse ne compense pas une dégradation sur les pannes critiques. La recette d’un projet IA complète ce test du modèle par les contrôles nécessaires avant production.
Si le résultat reste incertain, on élargit le test ou on suspend la décision. Modifier les critères après avoir vu le classement transformerait une comparaison en justification d’achat.
Calculer le coût d’un dossier accepté
Un tarif d’entraînement bas ne rend pas automatiquement le projet rentable. Il faut ajouter annotation, arbitrages experts, préparation des données, évaluations, intégration, hébergement et maintenance. L’apprentissage par renforcement, qui optimise un comportement à partir d’un signal de récompense, ajoute des essais et exige une récompense fiable : ce n’est pas l’étape suivante obligatoire.
Le bon dénominateur est le travail accepté, pas le nombre de réponses produites. Un modèle moins cher à interroger peut coûter davantage si un responsable doit reprendre ses erreurs. Notre analyse du coût du contrôle humain aide à intégrer cette charge au calcul.
Le dirigeant doit comparer l’investissement initial et les coûts récurrents au volume réaliste de tâches et aux gains attendus. Il n’existe ni seuil de volume ni pourcentage d’amélioration valable pour toutes les PME. Une activité peu fréquente peut être critique ; une activité volumineuse peut déjà être correctement traitée sans entraînement.
Vérifier les données et la sortie avant de signer
Détenir des dossiers ne suffit pas à autoriser leur transmission ou leur utilisation pour entraîner un modèle. Vérifiez droits, finalités, données sensibles, lieux de traitement, sous-traitants, conservation et suppression. Une promesse de non-réutilisation par le fournisseur ne signifie ni absence de traitement ni conservation nulle.
La réversibilité doit être démontrable : quels exemples, configurations et paramètres adaptés pourrez-vous récupérer ? Dans quel format ? Avec quelle licence sur le modèle de base et quel moteur d’hébergement compatible ? Exporter un adaptateur, c’est-à-dire une modification compacte du modèle, ne garantit pas qu’il fonctionnera ailleurs sans adaptation. Changer de modèle peut imposer un nouvel entraînement et de nouveaux tests.
La décision du dirigeant : un pilote borné, ou pas d’entraînement
Autorisez le pilote si la tâche est stable, les exemples fiables, le test réservé, le budget complet et la sortie vérifiable. Passez en production seulement si les critères convenus sont atteints sans régression critique. Conservez la solution de référence et un retour arrière praticable.
Sinon, décidez explicitement de ne pas entraîner. Vous aurez peut-être identifié une procédure contradictoire, une recherche défaillante ou un contrôle trop coûteux. Résoudre ce défaut constitue un meilleur investissement que posséder un modèle spécialisé sans avantage démontré.
Vous hésitez sur le premier cas à tester ? Partageons une tâche concrète lors d’un échange discovery : ce qu’elle doit produire, les exemples disponibles et la preuve qui justifierait — ou éviterait — un entraînement.