Choisir une IA générative en partant des tâches et du niveau de risque
Un projet d’IA générative réussit rarement parce que le modèle est « plus gros ». Il a davantage de chances de réussir lorsque l’équipe a clarifié la tâche, le niveau d’exigence et le risque métier acceptable. Une réponse approximative sur une FAQ interne n’a pas le même impact qu’un brouillon de clause contractuelle ou qu’un compte rendu médical. Le même outil peut être acceptable dans le premier cas et inacceptable dans le second, même si la technologie sous-jacente est identique.
Commencez par décrire vos tâches de manière opérationnelle, sans jargon. Exemples : « résumer un ticket support en 5 lignes », « proposer une réponse au client avec les références de la base de connaissances », « extraire des champs structurés d’un PDF », « rédiger un e-mail commercial », « proposer une procédure de dépannage ». Chaque tâche implique des critères différents : exactitude factuelle, ton, traçabilité des sources, délai de réponse, confidentialité et besoin de contrôle humain.
Un bon réflexe (souvent négligé) consiste à préciser le « contrat de sortie » : que doit contenir la réponse et, surtout, ce qu’elle n’a pas le droit de faire. Par exemple :
- Ne jamais citer un tarif ou une pénalité si la source n’est pas explicitement fournie.
- Ne pas produire de conseil médical : seulement reformuler une information déjà présente dans un protocole interne validé.
- Ne pas « deviner » un champ manquant lors d’une extraction (champ vide et signalement).
Ensuite, associez chaque tâche à un niveau de risque. Une pratique simple consiste à noter : (1) la gravité d’une erreur (faible à critique), (2) la fréquence d’usage (occasionnelle à massive), (3) la sensibilité des données (publiques, internes, confidentielles, données personnelles, données de santé), (4) le degré d’autonomie (suggestion, action automatique, action irréversible). Cette grille peut guider les choix d’architecture (RAG ou fine-tuning), les exigences de journalisation, les tests et les garde-fous.
Pour rendre la discussion plus objective, vous pouvez utiliser un scoring simple (de 1 à 4 par critère) et définir des exigences minimales. Le seuil proposé ci-dessous est indicatif : adaptez-le à votre contexte et ne le considérez pas comme une règle universelle.
| Critère | 1 (bas) | 2 | 3 | 4 (haut) |
|---|---|---|---|---|
| Gravité d’erreur | gêne mineure | erreur coûteuse | incident client | impact légal, santé ou sécurité |
| Fréquence | < 10/mois | hebdomadaire | quotidienne | massive / automatisée |
| Sensibilité des données | publique | interne | confidentielle | données personnelles / santé |
| Autonomie | suggestion | assistance | action automatique | action irréversible |
Lecture pratique : un total ≥ 12 peut servir de seuil interne pour envisager (a) une traçabilité renforcée, (b) une revue humaine, (c) des tests de non-régression formalisés, (d) un filtrage et un contrôle d’accès par document en cas de RAG. Ces mesures doivent toutefois être déterminées en fonction des risques réels de la tâche.
Pour cadrer l’ensemble du programme, la démarche décrite dans IA d’entreprise : méthodologie du diagnostic au déploiement sécurisé propose un enchaînement du besoin jusqu’au déploiement.
Méthodes disponibles : du cadrage des prompts au fine-tuning (et pourquoi l’entraînement n’est pas toujours la réponse)
Le premier levier est souvent le plus sous-estimé : le cadrage des demandes, aussi appelé prompt engineering. Il s’agit d’écrire des instructions précises (rôle, périmètre, format attendu, contraintes, exemples) et de définir des règles de sortie (citations obligatoires, « je ne sais pas » quand la source manque, JSON strict). C’est rapide à tester, peu coûteux et souvent efficace pour des tâches de style ou de mise en forme.
Un format de prompt « prêt à auditer » (et plus facile à maintenir) ressemble souvent à ceci :
- Contexte : « Tu assistes l’équipe support pour répondre à des tickets B2B en français. »
- Périmètre : « Tu ne réponds que sur la base des extraits fournis. »
- Sortie : « Réponds en 6 lignes maximum et ajoute une liste de sources. »
- Règles : « Si aucune source ne couvre la question, réponds “Information non disponible dans la base”. »
- Exemples : 2 ou 3 paires question/réponse au format cible.
Limite : si le modèle n’a pas accès à vos connaissances internes, il restera générique ou risque d’inventer. Cette limite apparaît vite sur des sujets « locaux » au sens organisationnel (procédures internes, catalogue spécifique, exceptions contractuelles) — et c’est précisément ce qui peut pousser à introduire de la recherche documentaire.
Le second levier, souvent un bon compromis en entreprise, est le RAG (Retrieval-Augmented Generation). Le principe : avant de générer une réponse, le système recherche des passages pertinents dans vos documents, puis demande au modèle de répondre en s’appuyant sur ces extraits. La brique clé est l’embedding (représentation vectorielle d’un texte), qui permet une recherche sémantique dans une base vectorielle.
Un RAG bien conçu peut réduire les hallucinations, améliorer la traçabilité (sources citées) et limiter la nécessité d’entraîner le modèle. Il ne garantit toutefois ni l’exactitude des réponses ni la pertinence des sources. En contrepartie, il faut soigner l’ingestion documentaire (nettoyage, découpage, métadonnées, droits d’accès) et l’observabilité. Concrètement, les points qui font souvent la différence en production :
- Découpage (chunking) : des segments trop gros peuvent diluer les réponses ; des segments trop petits peuvent faire perdre le contexte.
- Métadonnées : version, date de validité, service propriétaire, niveau de confidentialité, langue (utile si vous avez des documents en français et en anglais).
- Contrôle d’accès : filtrer avant la génération (le modèle ne doit pas recevoir un document auquel l’utilisateur n’a pas droit).
- Stratégie de recherche hybride : combiner recherche lexicale (mots-clés) et sémantique pour les acronymes, références et numéros de produit.
Pour aller plus loin sur l’architecture et les arbitrages de sécurité et de ROI : RAG et recherche documentaire : architecture, sécurité et ROI pour organisations.
Le troisième levier est le fine-tuning (ajustement supervisé d’un modèle existant à partir d’exemples). Il peut servir à stabiliser un style, un format, un vocabulaire ou certains comportements, par exemple une classification ou une extraction. Les variantes LoRA (Low-Rank Adaptation) et QLoRA (LoRA avec quantification) réduisent les ressources nécessaires en entraînant un nombre limité de paramètres et, dans le cas de QLoRA, en quantifiant le modèle de base.
Mais le fine-tuning n’ajoute pas magiquement la connaissance de vos documents récents. Si votre besoin principal est de « répondre avec la dernière procédure interne », un RAG est souvent plus adapté. Autre point pratique : des exemples d’entraînement peu représentatifs, notamment s’ils contiennent des cas rares (exceptions, urgences, incidents historiques), peuvent nuire à la généralisation ou accentuer l’instabilité des réponses.
Un mémo utile pour trancher rapidement :
| Besoin dominant | Approche de départ possible | Risque principal à surveiller |
|---|---|---|
| Format strict, extraction stable | Prompt contraint, puis fine-tuning léger si nécessaire | sur-ajustement, régression silencieuse |
| Connaissance interne à jour | RAG | fuite d’information par mauvais filtrage, injection de prompt via des documents |
| Style rédactionnel homogène | Fine-tuning ou templates | confiance excessive, perte de prudence |
| Brainstorming, reformulation | Prompting | réponses génériques, manque de contexte |
Pour choisir entre RAG, LoRA et QLoRA selon l’usage : Fine-tuning LLM : choisir RAG, LoRA ou QLoRA selon l’usage et, si vous devez comprendre la chaîne complète d’entraînement : Entraînement LLM : étapes clés du prétraining au post-training.
Critères de choix par tâche : qualité mesurable, coût, latence, sécurité et maintien en condition
Pour une tâche donnée, fixez d’abord des critères de qualité testables. Pour de l’extraction structurée (par exemple : numéro de contrat, date, montant), mesurez précision et rappel, et vérifiez la robustesse aux scans de mauvaise qualité. Pour du résumé, utilisez un mélange de métriques automatiques (ROUGE, BERTScore) et de notation humaine sur une grille simple (exactitude, exhaustivité, clarté, conformité). Pour un assistant de questions-réponses interne, mesurez le taux de réponses sourcées (pourcentage de réponses avec citations), le taux de refus correct (le modèle doit signaler qu’il ne sait pas quand la base ne contient pas l’information) et le taux d’erreurs critiques.
Pour éviter des discussions abstraites (« c’est pas mal »), formalisez ce qu’est une erreur critique par tâche. Exemples :
- Support : donner une manipulation qui peut provoquer une perte de données client.
- Juridique : affirmer l’existence d’une clause inexistante.
- RH : divulguer une information personnelle ou un motif disciplinaire.
- Santé : proposer une action thérapeutique au lieu de renvoyer vers un protocole.
Le coût doit être ramené à l’usage. Deux postes dominent : le coût d’inférence (tokens consommés par requête, auxquels s’ajoute le coût de la recherche documentaire en RAG) et le coût de préparation (nettoyage des données, annotation, gouvernance, sécurité). À titre indicatif, un POC de prompting ou de RAG peut prendre de 2 à 6 semaines si les documents sont accessibles et correctement classés. Un fine-tuning peut plutôt demander de 4 à 12 semaines, notamment parce qu’il faut constituer un jeu d’exemples représentatifs, définir une stratégie d’évaluation, itérer et documenter. Ces délais varient fortement selon le périmètre, les ressources disponibles et l’état des données.
Un calcul simple aide à « dé-romantiser » le budget : si votre assistant consomme en moyenne 2 000 tokens par interaction (question, contexte RAG et réponse) et que vous visez 20 000 interactions par mois, vous devez dimensionner :
- la facture d’inférence (variable selon l’infrastructure et le modèle),
- la latence (temps de recherche et de génération),
- et la capacité (pics d’utilisation, par exemple pendant les heures ouvrées pour des équipes front-office).
Côté volumes, un fine-tuning comportemental peut démarrer avec quelques centaines à quelques milliers d’exemples de haute qualité, mais le nombre nécessaire dépend fortement de la tâche et du modèle. Un jeu trop petit ou peu représentatif risque de ne pas couvrir suffisamment les cas d’usage et de favoriser le sur-ajustement.
La latence et la disponibilité pèsent beaucoup sur l’acceptation. Un assistant utilisé en front-office support doit répondre vite et de façon stable, sinon les équipes risquent de revenir à leurs macros. Le RAG ajoute une étape de recherche ; il faut donc optimiser le découpage des documents, le cache et parfois utiliser une architecture hybride (recherche lexicale et vectorielle). En production, suivez des métriques simples mais parlantes : latence p50/p95, taux d’erreur, taux de timeout et — si vous avez un RAG — taux de « zéro résultat » (quand la recherche ne remonte rien).
Côté sécurité, une règle pragmatique : plus la donnée est sensible, plus vous devez réduire la surface d’exposition (minimisation, chiffrement, segmentation réseau, contrôle d’accès fin) et augmenter la traçabilité. Dans un contexte européen, cela peut aussi impliquer des contraintes de localisation des traitements et une attention particulière aux transferts et accès transfrontaliers (prestataires, sous-traitants, support).
Trois exemples d’arbitrage montrent pourquoi les critères varient par tâche. (1) Service client : objectif principal = cohérence et gain de temps, avec citations d’articles de la base de connaissances. Le RAG est souvent une option prioritaire, avec une politique de « réponse suggérée » validée par un humain. (2) Juridique : objectif principal = traçabilité, contrôle humain et interdiction d’inventer. Ici, il peut être préférable de privilégier RAG, gabarits de rédaction et interdiction de conclure sans sources, plutôt qu’un fine-tuning qui risquerait de privilégier le style au détriment de la prudence. (3) Maintenance industrielle : si le vocabulaire et les codes panne internes sont très spécifiques, un fine-tuning léger (LoRA) sur des exemples d’étiquetage ou de diagnostic, combiné à un RAG sur la documentation, peut contribuer à stabiliser les résultats.
Enfin, n’oubliez pas le maintien en condition opérationnelle (MCO) : qui met à jour la base documentaire, qui valide les nouvelles versions, comment vous détectez une dérive (nouveaux produits, changement réglementaire, nouvelle politique interne) et comment vous vérifiez que la version N+1 ne régresse pas sur les cas critiques.
Exigences réglementaires : ce qui change selon le contexte (RGPD, AI Act, sectoriel) et comment l’intégrer au choix technique
Lorsque le RGPD s’applique et que vous traitez des données personnelles, cela impacte directement la conception : minimisation des données envoyées au modèle, base légale, durées de conservation, droits des personnes et sécurité. Une citation utile à garder en tête, parce qu’elle traduit une exigence opérationnelle (pas seulement juridique) :
« Les données à caractère personnel doivent être […] traitées de manière licite, loyale et transparente au regard de la personne concernée. » (RGPD, art. 5.1.a) Consulter le règlement général sur la protection des données
En pratique, cela se traduit par des décisions techniques et organisationnelles — et par une clarification des rôles : responsable du traitement et sous-traitant, selon les rôles effectivement exercés par votre organisation et le prestataire ou l’éditeur, avec des exigences contractuelles (instructions documentées, sécurité, assistance, sous-traitance ultérieure).
Exemple : journaliser les prompts peut être indispensable pour déboguer et auditer, mais ces logs constituent eux aussi un traitement de données s’ils contiennent des données personnelles. Ils doivent être filtrés (suppression ou masquage des identifiants), protégés et conservés pendant une durée définie. Avant tout entraînement ou fine-tuning, appliquez une hygiène stricte : suppression des données non nécessaires, pseudonymisation quand possible, exclusion explicite des données particulièrement sensibles et revue de conformité. Pour les environnements de santé, la question ne se limite pas au RGPD : cartographier les flux, les accès et la conservation devient central. Référence utile : Protection des données de santé IA : cartographier flux, accès et conservation.
L’AI Act européen (règlement sur l’IA) ajoute une logique par niveaux de risque et s’applique progressivement. Pour choisir une IA générative, il faut notamment distinguer les obligations qui peuvent concerner les modèles d’IA à usage général (GPAI) de celles qui s’appliquent aux systèmes selon leur usage. Ces catégories ne s’excluent pas : un modèle GPAI peut être intégré à un système relevant d’une catégorie à haut risque. Certains usages liés à l’emploi, à l’éducation ou aux services essentiels peuvent être classés à haut risque selon les critères et exceptions prévus par le règlement. Les obligations concrètes dépendent donc du rôle de l’organisation, du système et de son usage ; elles peuvent inclure documentation, gestion des risques, transparence, exigences relatives aux données et surveillance humaine. Pour une lecture officielle : consulter le règlement européen sur l’intelligence artificielle.
Une manière utile d’intégrer ces exigences au choix technique est de les traduire en objets concrets d’ingénierie :
| Exigence (typique) | Traduction technique / projet |
|---|---|
| Transparence et information | mention de l’assistance par IA, messages sur les limites, conservation des versions de prompt |
| Gestion des risques | registre des risques par tâche et mesures de mitigation testées |
| Traçabilité et auditabilité | logs filtrés, horodatés, versionnés (modèle, prompt, base documentaire) |
| Surveillance humaine | modes « suggestion » par défaut, escalade, seuils de confiance, revue des cas sensibles |
| Qualité en production | monitoring et campagnes de retests sur les cas critiques |
Enfin, les exigences sectorielles et cyber s’ajoutent souvent : NIS2 (cybersécurité), DORA (résilience numérique pour la finance), obligations d’hébergement et de sécurité (par exemple en santé), secret des affaires et règles internes d’archivage. Le choix technique doit donc intégrer, selon le contexte, la localisation des traitements, le cloisonnement et l’auditabilité. Une démarche efficace consiste à commencer par classer vos données et vos flux, puis à choisir l’architecture qui respecte ces frontières. Sur ce point, l’article Classification des données : cartographier flux sensibles par application et réseau peut servir de base.
Prouver que ça marche et que c’est maîtrisé : évaluation, gouvernance, audit fournisseur et sécurité applicative
Une IA générative « conforme » n’est pas seulement une IA qui respecte des règles sur le papier. C’est une IA dont vous pouvez évaluer le comportement attendu, vérifier les non-régressions et corriger les problèmes. Le NIST résume l’esprit d’un cadre opérationnel :
« The AI RMF is intended to help organizations manage risks associated with AI and to promote trustworthy and responsible development and use of AI systems. » (NIST, AI Risk Management Framework 1.0, 2023) Consulter le cadre de gestion des risques liés à l’IA du NIST
Concrètement, mettez en place un protocole d’évaluation avant de parler d’entraînement.
- Constituez un jeu de tests représentatif des vrais cas. Idéalement : cas « standards », cas limites et cas « pièges » (ambiguïtés, documents incomplets, demandes hors périmètre).
- Définissez des critères d’acceptation par tâche (par exemple : aucune erreur critique sur 200 cas, 95 % de réponses avec sources, format JSON valide dans 99 % des cas). Ces valeurs sont des exemples à adapter ; un résultat satisfaisant sur un échantillon limité ne garantit pas l’absence d’erreurs en production.
- Testez les scénarios d’abus : prompts adverses, tentatives d’exfiltration d’informations, injection d’instructions dans des documents, demandes hors périmètre.
Ces tests sont essentiels pour un RAG, car les documents peuvent contenir des instructions malveillantes. Inspirez-vous des bonnes pratiques de sécurité applicative pour LLM sans attendre un incident, par exemple le référentiel OWASP dédié à la sécurité des applications utilisant de grands modèles de langage.
Quelques garde-fous qui peuvent améliorer la sécurité sans alourdir à l’excès :
- Séparation stricte des rôles : « le modèle propose », « le système décide » (ex. envoi d’e-mail, création de ticket, modification d’un référentiel).
- Filtrage des entrées : détection et masquage d’identifiants, rejet des pièces non autorisées.
- Filtrage des sorties : contrôle des risques de divulgation de données personnelles, règles de non-divulgation, validation de schéma (JSON).
- Protection RAG : traiter les documents comme des sources non fiables, ne pas exécuter les instructions qu’ils contiennent et mettre en place des contrôles complémentaires. Une consigne au modèle ne suffit pas, à elle seule, à prévenir les injections de prompt.
La gouvernance vous évite de « bricoler en production ». Elle couvre le registre des modèles et des prompts, les jeux de données, les versions, les évaluations, les exceptions et la gestion du cycle de vie. Le but n’est pas la lourdeur, mais la répétabilité : pouvoir répondre à « qui a changé quoi, quand, pourquoi, avec quel impact ». Pour structurer cela : Gouvernance de l’IA : registre de modèles, audits et cycle de vie.
Enfin, si vous externalisez une partie (API, hébergement, intégrateur), l’audit fournisseur devient une composante du choix. Exigez au minimum des informations sur : la politique d’usage des données (entraînement ou non), l’isolation des clients, la localisation, le chiffrement, la gestion des incidents, les sous-traitants et les modalités de réversibilité. Une check-list structurée aide à ne rien oublier : Audit fournisseurs : check-list en 8 étapes pour sécuriser la conformité. Sans cet effort, vous pouvez avoir un modèle techniquement bon mais juridiquement inutilisable.
Une matrice simple pour décider (prompt, RAG, fine-tuning) et lancer le projet sans brûler le budget
Pour décider, utilisez une matrice à deux axes : (1) « la réponse dépend-elle de connaissances internes changeantes ? » et (2) « le format ou le comportement doit-il être extrêmement stable ? ». Si la réponse dépend surtout de documents internes et doit rester à jour, commencez par le RAG. Si la stabilité du format prime (extraction, classification, style de réponse homogène), envisagez un fine-tuning léger, mais seulement après avoir vérifié que le prompt et les contraintes de sortie ne suffisent pas. Si ni l’un ni l’autre n’est vrai (rédaction générique, brainstorming), le prompting peut suffire.
Voici une lecture rapide sous forme de matrice (à adapter à votre scoring de risque) :
| Connaissances internes changeantes ? | Format très stable requis ? | Point de départ possible |
|---|---|---|
| Non | Non | Prompting cadré |
| Oui | Non | RAG (avec citations et refus) |
| Non | Oui | Prompt contraint, puis fine-tuning léger si besoin |
| Oui | Oui | RAG et contraintes de sortie, puis fine-tuning si la stabilité reste insuffisante |
Ajoutez ensuite vos contraintes réglementaires et de données. Si vous manipulez des données sensibles, privilégiez les approches qui minimisent l’exposition : RAG avec filtrage d’accès par document, anonymisation en amont et politiques de logs strictes. Soyez prudent avec le fine-tuning sur des tickets, e-mails ou comptes rendus : même après nettoyage, le risque de réintroduire des informations sensibles et de compliquer leur effacement est réel. Si vous devez malgré tout entraîner, faites valider le périmètre des données, documentez la base légale et définissez une stratégie de purge et de traçabilité.
Pour transformer cette matrice en plan d’action, organisez un atelier court (90 minutes) avec un représentant métier, une personne de l’équipe data/IA, un RSSI et un référent conformité. Travaillez sur 10 cas réels, pas sur des exemples idéalisés. Livrables attendus à la fin :
- Une fiche par tâche : entrée, sortie attendue, données utilisées, niveau de risque, validation humaine.
- Trois métriques de succès par tâche (qualité, délai, sécurité ou conformité).
- Une décision provisoire : prompt seul, RAG, fine-tuning ou combinaison.
- La liste des données interdites et le plan de traitement (masquage, anonymisation, accès).
Première étape concrète à réaliser : sélectionnez 20 interactions réelles (tickets, e-mails, pages de procédures) représentatives d’une seule tâche prioritaire, anonymisez-les, puis testez en une demi-journée trois variantes (prompt cadré, prompt avec format contraint, RAG minimal) en mesurant un indicateur simple (taux de réponses exploitables).
Pour rendre ce test « décidable », ajoutez deux mesures faciles :
- Taux de réponses correctement sourcées (au moins une source pertinente quand une source est requise).
- Taux de refus appropriés (le système n’invente pas quand la base ne couvre pas la demande).
Cette comparaison rapide peut aider à déterminer si l’entraînement est nécessaire ou si l’accès aux bons documents suffit — et à éviter le piège classique : lancer un fine-tuning coûteux alors que le vrai problème était une base documentaire mal découpée, mal versionnée ou inaccessible au bon périmètre.
