La question n’est pas de savoir s’il faut automatiser, mais quelle partie a besoin d’intelligence
Le traitement de documents, le classement de demandes et l’extraction de données sont autant de tâches qui incitent à introduire un grand modèle de langage (LLM). Celui-ci peut interpréter des textes variés et produire une réponse structurée, mais cela ne signifie pas qu’il convienne à chaque étape du processus. Dans un flux opérationnel, une décision erronée peut déclencher des paiements, des refus, des modifications de compte ou des manquements aux obligations. Le choix doit donc partir du coût de l’erreur et des garanties exigées par le processus, et non de l’attrait de l’outil.
Il est utile de distinguer trois familles. Les règles déterministes appliquent des conditions explicites et produisent le même résultat pour une même entrée. Les modèles prédictifs spécialisés apprennent à attribuer des catégories ou des scores à partir de données et sont évalués pour une tâche précise. L’IA générative s’appuie sur des instructions et du contexte pour produire du contenu ou interpréter des entrées souples ; son résultat peut varier selon la formulation de la requête ou le modèle. Ces approches peuvent être combinées dans un même flux, chacune étant réservée aux tâches qu’elle traite le mieux.
La documentation technique de Google distingue les modèles de fondation, conçus pour des usages larges, des modèles prédictifs, conçus pour des tâches spécifiques. Elle recommande aussi de prendre en compte la qualité, la latence, le coût et la conformité lors de l’évaluation d’un modèle pour un cas d’usage. Elle ne fournit pas de seuils universels et ne démontre pas qu’une famille est toujours plus rapide ou moins chère qu’une autre : il faut mesurer la configuration réelle, avec les données, le volume et l’infrastructure prévus.
1. Traçabilité et audit : pouvoir expliquer chaque résultat
Lorsqu’une décision doit pouvoir être justifiée à la suite d’un audit ou auprès d’une personne concernée, conserver uniquement la réponse finale ne suffit pas. Le système devrait garder l’entrée pertinente, la version des règles ou du modèle, les données consultées, le résultat, les validations appliquées et toute intervention humaine. Pour un système génératif, il peut également être nécessaire de conserver le modèle d’instructions, l’identifiant du modèle, les documents récupérés et la réponse initiale, sous réserve des contrôles de confidentialité et de conservation.
Les règles sont généralement plus faciles à examiner : une condition explicite peut être associée à une raison précise, par exemple « si le numéro de facture est absent, envoyer le dossier en vérification ». Mais la lisibilité d’une règle ne garantit ni la légalité ni la justesse du processus. Il faut vérifier que la politique est à jour, qu’elle est appliquée de façon cohérente et que sa version est enregistrée. Les modèles prédictifs exigent d’autres contrôles, tels que le suivi des versions, des données d’évaluation, des métriques et des évolutions de performance. Les LLM ajoutent une difficulté : une réponse plausible ne constitue pas, à elle seule, une explication vérifiable de la manière dont une décision a été prise.
Il ne faut pas déduire une obligation juridique précise d’une recommandation d’ingénierie. Les sources disponibles ici ne définissent pas les obligations concrètes imposées par le règlement européen sur l’IA à chaque système opérationnel, ni si un processus particulier relève d’une catégorie réglementée. La classification dépend de l’objectif, du contexte d’utilisation et de la configuration du système ; elle exige une évaluation juridique adaptée au cas. En pratique de conception, il est raisonnable de prévoir des journaux reproductibles, des contrôles d’accès, une révision humaine et des moyens de corriger les résultats, sans présenter cette liste comme un inventaire juridique complet.
Journal minimal utile pour une décision automatisée
- 01Conserver les entrées nécessaires et leur provenance, en appliquant les principes de minimisation et les contrôles d’accès.
- 02Enregistrer la version de la règle et du modèle ainsi que, le cas échéant, la version du modèle d’instructions et les sources consultées.
- 03Sauvegarder la sortie du système, les validations effectuées et l’issue du dossier : accepté, refusé ou soumis à vérification.
- 04Permettre de reconstituer la décision et de corriger les données ou le résultat lorsqu’une erreur est détectée.
2. Latence : mesurer l’ensemble du flux, pas seulement l’inférence
Dans un système soumis à des contraintes strictes de temps réel, une réponse qui arrive après l’échéance peut équivaloir à un échec. Avant de comparer les technologies, définissez le budget de latence de bout en bout et le point de mesure : de l’arrivée de la demande jusqu’à l’exécution ou à la confirmation de l’action par le système. Un appel à un LLM peut inclure l’attente réseau, la préparation du contexte, la récupération de documents, la génération et la validation. Mesurer uniquement le temps de génération masque des éléments importants du délai total.
Les règles conviennent souvent aux vérifications courtes et prévisibles ; un modèle prédictif léger peut classer une entrée dans un budget défini. Il n’est toutefois pas possible d’affirmer que n’importe quel classificateur sera plus rapide que n’importe quel LLM : tout dépend du matériel, de la taille du modèle, de la longueur de l’entrée, du service, de la charge et de l’architecture. La documentation de Google recommande d’évaluer la latence et le débit pour le cas d’usage considéré. Elle distingue, par exemple, les besoins d’une interaction conversationnelle de ceux d’un résumé traité par lots, mais ne fournit pas de chiffres permettant de comparer les modèles.
Pour comparer les options, testez-les avec une charge représentative et mesurez des percentiles, pas seulement des moyennes. Enregistrez au minimum p50, p95 et p99, le taux d’erreur, le nombre de requêtes par seconde, le temps d’attente en file et la latence de chaque étape. Répétez les tests à charge normale et lors des pics prévus, en précisant si les appels externes sont inclus. Si l’application a une limite stricte, prévoyez une solution de repli capable de répondre dans le délai : appliquer des règles connues, renvoyer un statut « en attente » ou transmettre la demande, plutôt que d’attendre indéfiniment une réponse générative.
Que mesurer avant de choisir
Pour que la comparaison soit interprétable, les métriques doivent être recueillies avec la même configuration et le même ensemble de cas.
| Mesure | Utilisation | Risque révélé |
|---|---|---|
| Latence p95 et p99 | Mesurer de bout en bout, sous une charge représentative | Files d’attente et cas lents masqués par la moyenne |
| Coût par cas traité jusqu’au bout | Inclure l’inférence, les nouvelles tentatives, la récupération et la vérification humaine | Une option peu coûteuse par appel peut coûter cher par résultat valide |
| Taux d’erreur et nouvelles tentatives | Enregistrer les échecs techniques, les sorties invalides et les tentatives supplémentaires | Allongement des délais et coûts supplémentaires |
| Qualité de la décision | Évaluer la précision, la couverture et les erreurs par catégorie | Une réponse rapide mais incorrecte ne remplit pas l’objectif |
| Disponibilité de la solution de repli | Simuler une panne du modèle ou le dépassement du budget de temps | Dépendance à un service sans voie de sortie maîtrisée |
3. Cohérence : quand la variabilité aide et quand elle gêne
Dans les règles métier, un même cas devrait produire la même conséquence : un montant supérieur au plafond est bloqué ; un champ obligatoire manquant entraîne une vérification ; un compte suspendu ne passe pas à l’étape suivante. Si une variation de formulation change la décision, le système devient difficile à tester et à maintenir. Les règles explicites sont adaptées aux conditions connues, modifiées de manière contrôlée et nécessitant des résultats prévisibles.
La variabilité d’un modèle n’est pas toujours un défaut. Elle peut être utile lorsque les entrées sont en texte libre, que les documents ont des formats variés ou que les descriptions sont incomplètes et résistent aux règles rigides. Un modèle prédictif peut convenir lorsque l’objectif consiste à attribuer une étiquette parmi des catégories connues et qu’un ensemble d’exemples évaluables est disponible. Un LLM peut aider à normaliser ou à résumer une entrée avant que des règles ou des systèmes ultérieurs vérifient les données décisives. Quelle que soit la famille du modèle, sa sortie doit être considérée comme une proposition tant qu’elle n’a pas satisfait aux contrôles adaptés au risque.
Les modèles de fondation peuvent être sensibles aux changements d’instructions et d’entrées. Leur évaluation doit tenir compte de l’application concernée, y compris de ses modèles d’instructions et de ses composants connectés. Un test ponctuel ne suffit donc pas à garantir un comportement identique après une modification du modèle, des instructions, des données ou de la chaîne. Maintenez un jeu de tests représentatif, consignez les versions et comparez les résultats avant le déploiement des changements. Pour les processus critiques, définissez des seuils de confiance ou des conditions de révision, sans supposer qu’un score prouve à lui seul l’exactitude de la réponse.
Une matrice pour choisir le composant principal
La décision finale peut être prise étape par étape, sans choisir nécessairement une seule technologie pour tout le flux. Pour chaque étape, décrivez les données reçues, la décision attendue, les erreurs tolérables et le délai à respecter. Sélectionnez ensuite le composant le plus simple qui satisfait ces exigences lors de tests représentatifs. Si les cas changent souvent ou contiennent un langage très variable, un modèle peut se justifier ; si la condition est explicite et stable, une règle est souvent plus facile à vérifier.
Les flux hybrides constituent souvent une option raisonnable : des règles pour les limites et les validations, des modèles prédictifs pour les classifications bien circonscrites, l’IA générative pour interpréter, extraire ou résumer des entrées ambiguës, et une vérification humaine pour les exceptions ou les actions à fort impact. L’orchestration doit enregistrer les étapes et permettre de tester les changements comme un ensemble. La documentation de Google met précisément l’accent sur l’évaluation continue, la gestion des artefacts et la surveillance des applications génératives, sans imposer une architecture unique.
Ce cadre ne remplace pas une évaluation de la sécurité, de la confidentialité, de la conformité ou de l’impact. Il ne permet pas non plus de déterminer à l’avance quel système sera le moins cher ou le plus rapide : ces résultats dépendent du volume, de l’infrastructure, de la maintenance et de la proportion de cas nécessitant une vérification. Consignez les hypothèses et les incertitudes, puis mesurez à nouveau lorsque les données, les règles, les modèles ou les exigences opérationnelles changent. Pour explorer les options, comparer les solutions et approfondir les notions, consultez les parcours internes d’Inferama : [découvrir](route:discover.index), [comparer](route:compare.index) et [apprendre](route:learn.index).
Matrice de décision selon le type de flux
Ce tableau oriente le choix initial ; la validation doit s’effectuer avec les données et les exigences du processus concerné.
| Besoin dominant | Option de départ | Quand ajouter une autre option | Contrôle indispensable |
|---|---|---|---|
| Condition explicite et auditable | Règles déterministes | Si l’entrée est ambiguë, ajouter une étape d’extraction ou de classification | Version de la politique, tests des cas limites et journalisation |
| Classification parmi des catégories connues | Modèle prédictif spécialisé | Si le texte est ouvert ou le contexte incomplet, ajouter une étape d’interprétation | Métriques par classe, seuils et vérification des erreurs |
| Interprétation de documents ou de textes variés | LLM ou extraction assistée par LLM | Si l’action est encadrée par des limites fixes, appliquer ensuite des règles de validation | Journalisation de l’entrée, de la version, de la sortie, des sources et des validations |
| Délai strict et sortie prévisible | Règles ou modèle léger évalué localement | Si le cas sort du périmètre connu, le mettre en file d’attente ou le transmettre | Mesures p95/p99, solution de repli et limite de temps |
| Exception coûteuse ou à fort impact | Flux hybride avec vérification humaine | Étendre l’automatisation uniquement après l’évaluation des risques et des erreurs | Traçabilité, autorisation et mécanisme de correction |
Processus succinct de sélection et de déploiement
- 01Décomposer le flux en décisions et actions, en repérant les étapes où une erreur peut causer un préjudice ou un coût.
- 02Définir des exigences mesurables de qualité, de latence, de traçabilité et de coût par cas valide.
- 03Comparer règles, modèle spécialisé et LLM sur le même échantillon de cas et avec une charge représentative.
- 04Prévoir les validations, la vérification humaine et une solution de repli pour les entrées douteuses ou les défaillances.
- 05Enregistrer les versions et les résultats ; déployer progressivement et surveiller les erreurs, la latence, le coût et l’évolution des données.
Conclusion : automatiser avec le degré de flexibilité nécessaire
L’IA générative ne remplace pas universellement les règles ni les modèles prédictifs. Elle est utile pour traiter des entrées variées et produire des interprétations ou du contenu ; ses limites deviennent importantes lorsqu’une réponse reproductible, un délai strict ou une explication vérifiable sont exigés. Une conception robuste confie chaque décision au composant capable de la résoudre de manière vérifiable et évite qu’une sortie plausible déclenche automatiquement une action irréversible.
Commencez par le coût des erreurs, les obligations applicables et le budget de temps. Utilisez des règles pour les politiques explicites, des modèles prédictifs pour les tâches bien circonscrites disposant de données d’évaluation, et des LLM pour les ambiguïtés qui justifient leur flexibilité. Dans tous les cas, mesurez le flux réel, enregistrez ce qui est nécessaire pour reconstituer les décisions et conservez une solution de repli sûre. Si les données du pilote ne permettent pas de comparer la qualité, le coût et la latence, il n’existe pas encore de base suffisante pour choisir à l’intuition.
Questions ouvertes
- Les sources disponibles ne contiennent pas de benchmarks comparables de latence ou de coût d’inférence entre LLM et modèles prédictifs ; les résultats dépendent de la tâche, de l’infrastructure, de la charge et de la configuration.
- La documentation disponible ne précise pas les obligations juridiques de traçabilité imposées par le règlement européen sur l’IA à un flux particulier ; il faut analyser son objectif, son contexte et sa classification applicable.
- Les exemples techniques concernant les factures, l’acheminement des demandes et les remboursements illustrent des principes de conception ; ils ne constituent ni des résultats d’études empiriques ni des tests de performance documentés.
- Les volumes, les tolérances d’erreur, l’infrastructure et la juridiction du cas d’usage ne sont pas précisés. La matrice est donc un guide initial, et non une recommandation d’architecture définitive.
Poursuivre l’exploration
Sources consultées
Corrections et transparence
Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.
Proposer une correction