Comment choisir entre règles, modèles prédictifs et IA générative : guide de décision

Un cadre qui part de la décision, pas de la technologie

Choisir une solution d’intelligence artificielle commence par définir la décision ou la tâche à améliorer. La question n’est pas de savoir quelle technologie est à la mode, mais quel résultat le processus doit produire, de quelles données on dispose, quelles seraient les conséquences d’une erreur et quelles ressources sont disponibles pour développer et exploiter la solution. Dans bien des cas, une règle explicite ou un processus manuel amélioré convient mieux qu’un modèle d’apprentissage automatique.

Ce guide propose une méthode opérationnelle pour comparer trois familles de solutions : les règles déterministes, les modèles prédictifs et les systèmes génératifs. Il ne s’agit ni d’une classification réglementaire ni d’une échelle validée par des études comparatives. C’est un modèle de travail que chaque organisation doit adapter et tester avec ses propres données, contraintes et obligations. Les scénarios de la finance, de la logistique et des ressources humaines présentés plus loin sont hypothétiques : ils montrent comment utiliser la méthode, mais ne sont ni des cas réels ni des preuves d’efficacité.

Classer la tâche et les données avant de choisir

Une tâche structurée comporte des entrées, des états et des résultats qui peuvent être décrits par des champs, des catégories ou des conditions définies. Par exemple, vérifier si une facture dépasse un montant autorisé ou si un colis enfreint une restriction de poids. Lorsque la logique est stable et connue, des règles peuvent assurer la traçabilité et le contrôle sans entraînement d’un modèle.

Une tâche non structurée nécessite généralement d’interpréter du texte libre, des images, de l’audio ou d’autres signaux dont la variabilité ne peut être couverte par une petite liste de conditions. Classer une réclamation écrite ou résumer une conversation en sont des exemples. La distinction n’est pas absolue : une organisation peut convertir une partie du contenu non structuré en champs et combiner règles et modèles. Le type de données ne détermine pas à lui seul la technologie à choisir. La qualité, le volume, la variabilité, la possibilité d’étiqueter des exemples et le coût des erreurs comptent également.

Arbre de décision : écarter les options inadaptées

Un arbre de décision représente une succession de questions et leurs résultats possibles. Chaque nœud pose une condition et chaque branche mène à la question suivante ou à une option finale. Les arbres de décision sont aussi une famille de modèles prédictifs ; ici, toutefois, le terme désigne un diagramme de triage organisationnel, et non un algorithme entraîné. Cette structure aide à expliciter les raisons d’un choix, mais ne garantit ni la justesse des réponses ni la prise en compte de toutes les conséquences.

Commencez par demander si le processus peut être exprimé à l’aide de conditions stables. Si oui, évaluez d’abord des règles déterministes. Sinon, déterminez si l’objectif est d’attribuer une catégorie, d’estimer une probabilité ou une valeur, ou de produire du contenu nouveau. La classification ou la prédiction à partir d’exemples historiques peut justifier l’essai d’un modèle prédictif. La rédaction, le résumé ou la transformation de contenu peuvent justifier l’évaluation d’un système génératif, avec des limites claires et une validation des résultats. Il est aussi possible de combiner les méthodes : un modèle propose une réponse et des règles en limitent les possibilités.

Notation indicative : comparer les options sans feindre la précision

Une grille peut aider à comparer plusieurs propositions plausibles. Attribuez à chaque option une note de 1 à 5 pour l’adéquation à la tâche, la pertinence des données, les risques et les contrôles, la viabilité économique et la capacité d’exploitation. Sur cette échelle, une note élevée doit toujours représenter une situation plus favorable : par exemple, une meilleure adéquation, des données mieux préparées, des risques résiduels mieux maîtrisés et des coûts plus soutenables. Pour les risques, notez la capacité démontrée à les atténuer, et non leur gravité intrinsèque.

Les sources consultées ne proposent aucune pondération validée combinant type de données, risque réglementaire et budget pour choisir entre règles, modèles prédictifs et IA générative. Les pondérations ci-dessous sont donc un point de départ explicitement provisoire. Le budget ne doit pas favoriser automatiquement l’option la moins chère : tenez compte du coût total de possession, notamment de l’intégration, des tests, des licences ou de la puissance de calcul, de la supervision, des audits, des mises à jour, de la sécurité et de la sortie du fournisseur. Avant de décider, répétez la comparaison avec différentes pondérations et vérifiez si le résultat change.

Risques : évaluer l’impact et l’exposition, pas seulement un chiffre

Un score de risque unique peut masquer des différences importantes entre sécurité, vie privée, discrimination, fiabilité, conformité et continuité opérationnelle. Il est préférable de tenir un registre par dimension : quel préjudice est envisagé, qui pourrait être touché, à quelle fréquence il pourrait se produire, quelle en serait la gravité, quels contrôles existent et qui les vérifie. Des échelles qualitatives peuvent aider à établir les priorités de discussion, mais ne doivent pas être présentées comme des métriques réglementaires officielles.

Dans l’Union européenne, la classification juridique dépend de l’usage prévu et de l’inclusion du système dans les catégories et conditions pertinentes ; elle ne se déduit pas simplement d’un niveau de risque « élevé », « moyen » ou « faible » pour l’entreprise. La Commission européenne a publié un projet de lignes directrices pour aider à déterminer si certains systèmes doivent être classés à haut risque. Puisqu’il s’agit d’un projet, il ne faut pas le présenter comme une orientation définitive ni comme un substitut au règlement applicable. De son côté, la fondation Cotec décrit une démarche pratique de gouvernance qui prévoit notamment d’identifier les cas d’usage et les rôles, d’analyser les risques et d’intégrer les contrôles tout au long du cycle de vie.

Budget et coût total : raisonner à l’échelle de l’exploitation

Attribuer une pondération au budget ne revient pas à donner automatiquement l’avantage à l’option la moins chère. Définissez d’abord un horizon d’évaluation commun — par exemple, la période budgétaire de l’organisation — et estimez les coûts initiaux et récurrents : préparation des données, intégration, tests, calcul, licences, vérification humaine, suivi, sécurité, formation et maintenance. Incluez aussi les coûts de sortie, de remplacement ou de réversibilité si le fournisseur modifie ses conditions ou si la solution n’est plus adaptée.

Comparez ces coûts à un avantage défini à l’avance, comme la réduction du temps de traitement, la diminution des erreurs ou une meilleure couverture de la tâche. Ne supposez pas que l’automatisation produit des économies nettes : si une vérification manuelle fréquente reste nécessaire, le coût peut être déplacé plutôt que supprimé. Commencez par un projet pilote limité, avec des critères de réussite et d’arrêt. Si le budget est restreint, testez une solution plus simple avant de réduire les contrôles qui protègent les personnes ou l’exploitation.

Trois scénarios d’application de la méthode

Les scénarios suivants sont illustratifs et ne décrivent ni des déploiements réels ni des résultats mesurés. Ils montrent comment l’analyse varie selon la tâche, les données, l’impact et les possibilités de supervision. Dans aucun secteur, son seul nom ne suffit à déterminer la catégorie réglementaire : la finalité prévue, le contexte et la configuration précise comptent.

Chaque scénario présente une option initiale raisonnable, une solution de remplacement qui pourrait être testée et les contrôles à envisager. Le choix final dépend des données et des tests réalisés localement. Un projet pilote doit comparer la solution proposée à une référence et évaluer non seulement la précision moyenne, mais aussi les erreurs importantes, les coûts, les effets sur les personnes et les performances dans des conditions différentes de celles utilisées pour développer le système.

Validation, supervision et critères d’arrêt

Avant le déploiement, convenez de ce qui constitue un bon fonctionnement. L’évaluation doit s’appuyer sur des données distinctes de celles utilisées pour ajuster le système et représenter raisonnablement son utilisation prévue. Pour la classification, consignez les types d’erreurs et les résultats pour les segments pertinents ; pour la prédiction, comparez le modèle à une référence et mesurez les erreurs dans les conditions d’exploitation ; pour la génération, vérifiez l’exactitude, les omissions, la cohérence, la confidentialité et les réponses non autorisées. La métrique doit correspondre aux conséquences des erreurs, et pas seulement à la facilité de la mesurer.

Définissez qui vérifie les résultats, quelles décisions le système peut prendre, dans quels cas il doit s’abstenir et comment les erreurs sont corrigées. Consignez les versions, les modifications, les incidents, les approbations et les motifs des mises à jour. Fixez des critères d’arrêt : par exemple, une dégradation au-delà d’une limite convenue, des incidents de sécurité, des résultats inégaux non atténués ou l’impossibilité de maintenir une supervision effective. Le guide institutionnel de Cotec recommande d’intégrer la gouvernance dans le cycle de vie et de définir des rôles ainsi qu’un inventaire des systèmes. Le projet de lignes directrices de la Commission européenne aide à comprendre la classification des systèmes à haut risque, mais ne valide pas cette grille de notation.

Conclusion : une décision défendable vaut mieux qu’un score séduisant

L’arbre de triage aide à distinguer les tâches relevant de règles, de la prédiction ou de la génération ; la grille fait ressortir les compromis entre données, adéquation, risques, coûts et capacité opérationnelle. Aucun des deux ne détermine automatiquement la bonne solution. Les notes ne sont utiles que si elles sont expliquées, testées au regard d’autres hypothèses et actualisées lorsque le contexte change.

La méthode pratique consiste à partir d’une tâche précise, à évaluer d’abord des règles et des références simples, puis à tester des modèles uniquement si un besoin clair et des données adaptées le justifient. Pour les tâches à impact significatif, la supervision doit réellement influer sur la décision, et ne pas se réduire à une formalité. Les sources disponibles étayent l’utilité générale des arbres de décision, l’importance de la gouvernance et la nécessité de classer les systèmes selon leur usage ; elles ne démontrent pas l’efficacité de cette grille et ne définissent aucune pondération universelle. La décision finale doit s’appuyer sur des tests locaux et, le cas échéant, sur un examen juridique.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.