La plupart des démonstrations d’IA échouent trop poliment. L’exemple d’entrée est propre. Les données sont à jour. L’outil fonctionne. L’utilisateur pose une question ordinaire. Le modèle fournit une bonne réponse. Tout le monde acquiesce.
La production est moins conciliante. Les utilisateurs collent des entrées confuses. Les documents sources sont obsolètes. Les API expirent. Les consignes dérivent. Le modèle suit la mauvaise instruction. Un client pose une question légèrement en dehors du corpus. Un appel d’outil réussit, mais met à jour le mauvais enregistrement. Le processus produit un résultat suffisamment fluide pour que personne ne remarque l’erreur avant qu’il ne soit trop tard.
Cet article propose un registre des modes de défaillance des systèmes d’IA en production. Utilisez-le avant le lancement, et non après le premier incident.
Une revue d’un système d’IA destiné à la production doit demander « comment ce système échoue-t-il ? » avant de s’interroger sur le caractère impressionnant du scénario idéal. Chaque mode de défaillance exige un contrôle, un test, un responsable et une condition d’arrêt.
Mode de défaillance 1 : sortie plausible mais fausse
Le système génère une réponse qui paraît correcte, mais qui n’est étayée par aucune source ou qui est erronée.
Déclencheurs courants :
- Faits précis sans source à l’appui.
- Questions juridiques, médicales, financières ou politiques.
- Événements récents.
- Recherche documentaire de faible qualité.
- Résumés de documents longs où les preuves pertinentes sont enfouies.
Contrôles :
- Exiger des citations ou des extraits de source pour les affirmations factuelles.
- Refuser les requêtes en dehors de l’ensemble de sources disponible.
- Ajouter aux évaluations des cas correspondant aux schémas connus de réponses erronées.
- Soumettre les résultats à fort impact à une revue humaine.
- Enregistrer les identifiants de source utilisés dans la réponse.
Ne tentez pas de maîtriser ce risque avec une formule comme « soyez précis ». Utilisez des sources, des tests et des étapes de validation.
Mode de défaillance 2 : contexte obsolète
La réponse est bien étayée, mais par des informations anciennes.
Exemples :
- Page de tarification ancienne.
- Politique remplacée.
- Version précédente du contrat.
- Documentation produit obsolète.
- Statut client en cache.
Contrôles :
- Stocker la date, la version, le propriétaire et la règle de fraîcheur des sources.
- Préférer les sources faisant autorité aux résumés.
- Signaler les sources obsolètes dans les résultats de la recherche documentaire.
- Ajouter des tests de fraîcheur.
- Avertir un responsable lorsque des sources essentielles dépassent leur délai de révision.
Les systèmes RAG peuvent répondre avec assurance à partir de documents obsolètes. La couche de recherche doit savoir ce que signifie « à jour ».
Mode de défaillance 3 : complaisance et accord excessif
Le modèle reprend l’hypothèse de l’utilisateur au lieu de la remettre en question.
Ce comportement est important dans la stratégie, l’analyse, la planification et l’aide à la décision. Un utilisateur demande : « Ce plan de lancement paraît solide, n’est-ce pas ? » et reçoit une approbation plutôt qu’une analyse des risques.
Contrôles :
- Demander explicitement des contre-arguments et l’expression des incertitudes.
- Utiliser des grilles de décision plutôt qu’une demande ouverte d’approbation.
- Exiger une réponse à la question « Qu’est-ce qui pourrait invalider cette conclusion ? »
- Séparer la génération d’idées de la revue.
- Inclure dans les évaluations des exemples où la prémisse de l’utilisateur est erronée.
Le système doit aider l’utilisateur à mieux réfléchir, et pas seulement à présenter plus élégamment son opinion actuelle.
Mode de défaillance 4 : injection de consignes
Le modèle traite le contenu non fiable comme une instruction.
Exemples :
- Une page web indique « Ignorez les instructions précédentes ».
- Un e-mail de support inclut des instructions malveillantes.
- Un document dans un corpus RAG dit à l’assistant de révéler des données cachées.
- Un résultat d’outil contient du texte qui tente de modifier le processus.
Contrôles :
- Étiqueter clairement le contenu non fiable.
- Ne jamais placer le contenu récupéré au même niveau d’autorité que les instructions système ou développeur.
- Restreindre les permissions des outils.
- Établir des listes d’autorisation pour les actions sortantes.
- Tester des exemples d’injection dans les évaluations.
- Exclure les secrets du contexte transmis au modèle.
Une consigne système ingénieuse ne suffit pas à résoudre l’injection de consignes. Ce risque est réduit par l’architecture : périmètres de données, autorisations des outils et validation des résultats.
Mode de défaillance 5 : usage non sûr des outils
Le modèle appelle le mauvais outil, appelle le bon outil avec les mauvais arguments, ou prend une action avant que suffisamment de contexte n’existe.
Exemples :
- Mettre à jour le mauvais contact CRM.
- Envoyer un e-mail au mauvais destinataire.
- Créer des enregistrements en double.
- Réserver un rendez-vous sans confirmer le fuseau horaire.
- Supprimer ou écraser des données.
Contrôles :
- Commencer en lecture seule.
- Utiliser des outils spécialisés dotés de schémas explicites.
- Valider les arguments d’outil en dehors du modèle.
- Exiger une confirmation pour les écritures.
- Ajouter des clés d’idempotence.
- Enregistrer les appels d’outils et les résultats.
- Ajouter un interrupteur d’arrêt.
L’utilisation des outils doit être contrainte par le processus, et non confiée au seul jugement du modèle.
Mode de défaillance 6 : dérive de schéma et de contrat
Le format de sortie du modèle ou l’API en aval évolue, et le processus cesse silencieusement de fonctionner.
Contrôles :
- Utiliser des sorties structurées autant que possible.
- Valider chaque sortie du modèle avant utilisation.
- Traiter les sorties malformées comme des défaillances récupérables.
- Versionner ensemble les consignes et les schémas.
- Ajouter des tests de contrat pour les API en aval.
- Surveiller les erreurs d’analyse syntaxique.
Si un nœud en aval suppose que le JSON est valide, le processus doit le vérifier.
Mode de défaillance 7 : mécanisme de repli insuffisant
Le système remarque un problème mais ne se rétablit pas en toute sécurité.
Mauvais mécanismes de repli :
- Réponse vide.
- Échec silencieux.
- Excuse générique sans action.
- Boucle de réessai répétée.
- Escalade humaine sans contexte.
Bons mécanismes de repli :
- Message clair à l’utilisateur.
- File d’attente humaine avec l’entrée, la source, l’erreur et l’action tentée.
- Nouvelle tentative avec temporisation uniquement lorsqu’elle est sûre.
- Procédure manuelle pour les cas urgents.
- Condition d’arrêt pour les défaillances répétées.
Le mécanisme de repli fait partie du produit. S’il n’est pas conçu à l’avance, la gestion de l’échec sera improvisée.
Mode de défaillance 8 : lacune d’observabilité
Un incident survient et personne ne peut en reconstituer la cause.
Contrôles :
- Enregistrer le modèle de consigne et sa version.
- Enregistrer le modèle et les paramètres.
- Enregistrer les identifiants de source, pas seulement le texte de la réponse.
- Enregistrer les appels d’outils, leurs arguments et leurs résultats en masquant les données sensibles.
- Enregistrer les erreurs de validation.
- Suivre la latence, le coût et le taux de repli.
- Limiter la durée de conservation, sauf exigence réglementaire contraire.
Ne stockez pas la chaîne de raisonnement privée. Conservez des résumés de décision, des références aux sources, les entrées et résultats des outils ainsi que les résultats de validation.
Un registre des modes de défaillance en production
Créez une ligne par mode de défaillance :
| Mode de défaillance | Exemple | Contrôle | Test | Métrique | Propriétaire | Condition d’arrêt |
|---|---|---|---|---|---|---|
| Source obsolète | Ancien prix renvoyé | Vérification de la date de la source | Interroger le prix ancien/nouveau | Taux de réponse à source obsolète | Propriétaire des documents | Tout prix obsolète visible par le client |
| Usage non sûr des outils | Mise à jour CRM incorrecte | Validation des arguments + confirmation | Cas de contact en double ou erroné | Taux d’action erronée | RevOps | Une écriture incorrecte |
Le registre compagnon lié à cet article vous donne le modèle.
Ne faites pas encore cela
Ne lancez pas d’IA orientée client sans un registre des modes de défaillance.
Ne laissez pas les outils capables d’écriture contourner la validation.
Ne vous appuyez pas uniquement sur des contrôles manuels ponctuels après le lancement.
Ne mesurez pas uniquement la qualité moyenne. Les défaillances rares peuvent concentrer la totalité du risque.
N’acceptez pas l’affirmation « nous pouvons revenir en arrière » si personne ne peut décrire concrètement la procédure de retour arrière.
À retenir
Les systèmes d’IA en production échouent de manière récurrente. Hallucinations, contexte obsolète, complaisance, injection de consignes, usage non sûr des outils, dérive de schéma, mécanismes de repli insuffisants et lacunes d’observabilité ne sont pas des cas limites. Leur gestion fait partie du travail normal de mise en production de l’IA.
L’approche mature consiste à nommer les modes de défaillance, à ajouter des contrôles, à les tester et les surveiller, puis à attribuer les responsabilités. Une démonstration montre ce qui fonctionne une fois. Un registre des modes de défaillance indique si le système peut résister à un usage réel.
