Il ne faut pas utiliser l’intelligence artificielle lorsque sa part d’incertitude n’apporte aucune valeur que ne fournirait une solution plus simple. Une règle métier stable, une recherche classique, un formulaire bien conçu, une automatisation déterministe ou une décision humaine sont souvent de meilleurs choix. Le bon réflexe n’est donc pas « où ajouter de l’IA ? », mais « quelle capacité manque réellement au processus ? ».
Cette distinction évite deux erreurs symétriques : refuser l’IA par principe, ou l’installer là où elle augmente les coûts, le besoin de contrôle et le risque sans améliorer la décision. L’objectif de cet article est de rendre le non-recours aussi explicite et testable que le recours.
Partir du problème, pas de la technologie
Un système d’IA est pertinent lorsqu’il traite utilement une variabilité difficile à formaliser : langage naturel, images, classement de cas ambigus, détection de motifs ou génération sous contraintes. Il ne devient pas pertinent simplement parce qu’un modèle sait produire une réponse plausible.
Avant de choisir un modèle, décrivez l’entrée, la sortie attendue, la personne responsable, la gravité d’une erreur et la manière de vérifier le résultat. Cette discipline rejoint le cadre de gestion des risques du NIST : la confiance dans un système dépend notamment de sa validité, de sa fiabilité, de sa sûreté, de sa résilience, de sa transparence, de son explicabilité et de la protection de la vie privée. Ces qualités doivent être appréciées ensemble et dans le contexte d’usage.
Le premier critère de non-recours est simple : si vous ne savez pas décrire la décision attendue et son contrôle, l’IA ne réparera pas ce flou.
L’arbre de non-recours à l’IA
Parcourez ces questions dans l’ordre. Une réponse négative ne condamne pas forcément le projet entier ; elle indique que le périmètre actuel ne doit pas recevoir d’IA en production.
1. Une règle stable suffit-elle ?
Si le résultat peut être calculé avec une règle courte, testable et compréhensible, utilisez cette règle. Un plafond contractuel, une date d’échéance, une remise définie par un barème ou le contrôle de présence d’un champ ne nécessitent pas un modèle probabiliste.
Une règle déterministe présente trois avantages décisifs : elle produit le même résultat pour la même entrée, elle se teste exhaustivement sur ses cas limites et elle explique directement pourquoi une décision a été prise. Ajouter un modèle à cet endroit crée une nouvelle classe d’erreurs sans résoudre un problème réel.
Alternative : moteur de règles, validation de schéma, formule, requête ou automate à états.
2. Le besoin porte-t-il sur une référence exacte ?
Retrouver un numéro de commande, une clause précise, un statut de dossier ou un montant enregistré relève d’abord de la recherche et de l’accès aux données. Une IA générative peut reformuler ou orienter, mais elle ne doit pas devenir la source d’une valeur qui existe déjà dans un système de référence.
Dans ce cas, commencez par améliorer l’indexation, les filtres, les identifiants et les droits d’accès. Si une interface conversationnelle est ensuite utile, elle doit citer la donnée retrouvée et refuser de répondre lorsque la source n’est pas disponible.
Alternative : recherche plein texte, requête structurée, index documentaire ou interface de consultation.
3. Pouvez-vous vérifier la sortie avant qu’elle produise un effet ?
Un modèle peut rédiger une proposition ou classer un dossier, mais il faut pouvoir évaluer cette sortie avec une référence, une grille ou une revue compétente. Sans vérité de contrôle ni critère d’acceptation, un bon résultat apparent peut masquer une dérive durable.
La question n’est pas seulement « un humain relira-t-il ? ». Il faut préciser ce que cette personne vérifie, avec quelles informations, dans quel délai et avec quel pouvoir de refus. Notre guide sur l’évaluation des sorties textuelles d’une IA générative détaille cette construction d’un paquet de test.
Alternative : conserver le traitement humain, instrumenter les décisions et constituer d’abord un jeu de cas évaluables.
4. Une erreur est-elle réversible à un coût acceptable ?
Une proposition de brouillon que l’on peut corriger n’a pas le même profil qu’un refus, un paiement, une suppression, une modification de droits ou un message envoyé à grande échelle. Plus l’effet est difficile à annuler, plus la décision doit rester bornée, expliquée et contrôlée.
Le NIST rappelle que la tolérance au risque dépend du contexte et que l’usage d’un système doit pouvoir cesser de manière sûre lorsque les risques ne sont pas suffisamment maîtrisés. En pratique, si vous ne disposez ni d’arrêt, ni de journal, ni de reprise manuelle, ne reliez pas la sortie du modèle directement à l’action irréversible.
Alternative : recommandation sans exécution, double validation, bac à sable ou automatisation limitée aux opérations annulables.
5. Les données sont-elles légitimes, suffisantes et maîtrisées ?
Un système ne doit pas être alimenté avec des données « disponibles » sans examiner leur finalité, leur provenance, leur sensibilité, leur durée de conservation et les droits des personnes. Les fiches pratiques de la CNIL sur l’IA demandent notamment de déterminer le régime applicable, définir la finalité, examiner la base légale, réaliser une analyse d’impact lorsque nécessaire, intégrer la protection des données dès la conception, informer les personnes et sécuriser le développement.
Si ces questions ne sont pas résolues, la prochaine étape n’est pas de choisir un modèle. Il faut réduire ou clarifier le traitement. Une IA entraînée ou sollicitée sur des données mal gouvernées accélère surtout la diffusion du problème.
Alternative : minimisation, pseudonymisation, données synthétiques pour le prototype, ou report du projet jusqu’à clarification.
6. Le volume ou la variété justifient-ils le coût d’exploitation ?
Une tâche rare, courte et correctement traitée manuellement ne mérite pas toujours une nouvelle dépendance. Le coût réel comprend l’intégration, les appels au modèle, la surveillance, les évaluations, le traitement des exceptions, la sécurité et les changements futurs de fournisseur ou de modèle.
À l’inverse, un volume élevé ne suffit pas : une règle classique peut être beaucoup moins chère et plus fiable. L’IA devient intéressante lorsque la variabilité utile résiste aux règles simples et que le gain attendu couvre durablement le contrôle nécessaire.
Alternative : procédure manuelle assistée, modèle de document, raccourci d’interface ou automatisation classique.
7. L’IA bat-elle une solution de référence plus simple ?
Ne comparez pas une démonstration d’IA à l’absence totale d’outil. Comparez-la au meilleur socle raisonnable : une recherche, une règle, une liste de contrôle, un formulaire, une macro ou une personne équipée d’une bonne interface.
Le test doit utiliser les mêmes cas et mesurer au minimum la qualité, la gravité des erreurs, le temps total avec revue, le coût par dossier et le taux d’exception. Si le modèle ne produit pas une amélioration nette et répétable, gardez la solution simple. Le guide pour choisir un premier cas d’usage IA permet d’organiser cette comparaison.
Alternative : conserver la référence, corriger le processus, puis retester seulement si une limite mesurée subsiste.
8. Pouvez-vous exploiter le système après le pilote ?
Un prototype peut fonctionner avec quelques exemples choisis et une surveillance informelle. La production exige des responsables, des seuils, des journaux, une gestion des incidents, des versions, une procédure de retour arrière et un budget. Elle doit également rendre visible ce que le système ne sait pas faire.
Les principes de l’OCDE sur l’IA relient une IA digne de confiance à la transparence et l’explicabilité, à la robustesse, la sûreté et la sécurité, ainsi qu’à la responsabilité des acteurs. Si personne ne porte ces obligations dans la durée, le pilote ne doit pas devenir une fonction métier silencieuse.
Alternative : limiter l’outil à l’exploration, désigner un propriétaire et construire l’exploitation avant l’ouverture.
Quelle alternative choisir à la place ?
| Nature du besoin | Solution à privilégier | Pourquoi |
|---|---|---|
| Calcul ou décision stable | Règle déterministe | Résultat reproductible et testable |
| Retrouver un fait enregistré | Recherche ou requête | La source reste identifiable |
| Faire respecter un parcours | Workflow à états | Transitions, droits et exceptions explicites |
| Recueillir une information | Formulaire avec validation | Structure et contraintes connues à l’entrée |
| Décision rare et lourde de conséquences | Expert humain outillé | Responsabilité et contexte conservés |
| Variabilité complexe mais effet contrôlable | IA sous supervision | Le modèle traite l’ambiguïté sans posséder l’action finale |
Ces options peuvent se combiner. Un système robuste utilise souvent une recherche pour retrouver les faits, un modèle pour interpréter une demande, des règles pour appliquer les limites et un humain pour les décisions sensibles. Le rôle de l’IA reste alors précis au lieu d’absorber tout le processus.
Trois exemples pour éviter une fausse évidence
Calculer une remise contractuelle
Scénario pédagogique : le montant dépend d’un barème, d’une date et d’un statut client. Un modèle de langage n’apporte rien au calcul. Une fonction testée, accompagnée d’un journal, est plus fiable. L’IA pourrait éventuellement expliquer la règle en langage naturel, mais elle ne devrait pas fixer le montant.
Répondre à une question de support
Scénario pédagogique : la réponse dépend d’une documentation changeante. Une simple recherche peut suffire si l’utilisateur sait formuler sa requête. Une interface IA peut devenir utile pour reformuler et synthétiser, à condition de citer la version consultée, signaler l’incertitude et orienter les cas non couverts vers une personne.
Autoriser une action sensible
Scénario pédagogique : une demande contient du texte libre, mais l’action modifie un droit ou déclenche un paiement. Un modèle peut extraire les éléments et relever une anomalie ; l’autorisation finale doit suivre des règles explicites et les validations prévues. La méthode décrite pour automatiser une validation sans perdre la responsabilité s’applique directement.
Tester sans s’engager trop tôt
Le non-recours n’est pas toujours définitif. Il peut signifier « pas encore » ou « pas à cet endroit ». Un test utile tient dans une comparaison limitée :
- constituer un échantillon comprenant les cas normaux, les ambiguïtés et les exceptions ;
- mesurer la solution actuelle avant de la modifier ;
- construire une référence simple sans IA ;
- tester le modèle sur exactement les mêmes cas ;
- ajouter le temps de revue et de correction au coût total ;
- classer les erreurs par gravité, pas seulement par nombre ;
- définir avant le test le seuil qui autorise, limite ou arrête le projet.
Cette comparaison protège contre l’effet de démonstration : une réponse impressionnante ne prouve ni la fiabilité, ni l’économie, ni la capacité d’exploitation.
La fiche de décision avant tout projet IA
- Problème : quelle limite mesurée voulons-nous supprimer ?
- Variabilité : pourquoi des règles ou une recherche ne suffisent-elles pas ?
- Référence : comment saurons-nous qu’une sortie est correcte ?
- Effet : que se passe-t-il si la sortie est fausse ?
- Retour arrière : l’action peut-elle être annulée et par qui ?
- Données : leur finalité, leur provenance, leur accès et leur conservation sont-ils maîtrisés ?
- Comparaison : quelle solution simple sert de point de référence ?
- Exploitation : qui surveille, corrige, arrête et finance le système ?
Si une réponse essentielle manque, conservez le projet en exploration. Si une règle suffit, choisissez-la. Si l’erreur est grave et invérifiable, gardez la décision humaine. Si l’IA apporte une capacité distincte, mesurable et exploitable, donnez-lui un rôle borné.
La bonne architecture n’est pas celle qui utilise le plus d’intelligence artificielle. C’est celle qui réserve l’IA aux endroits où son incertitude produit une valeur contrôlable.
Sources
- NIST — AI Risk Management Framework, cadre volontaire de gestion des risques liés à l’IA.
- NIST AI 100-1 — Artificial Intelligence Risk Management Framework 1.0.
- CNIL — Les fiches pratiques IA, recommandations sur le développement de systèmes impliquant des données personnelles.
- OCDE — Principes sur l’intelligence artificielle.