Niveaux de risque pour l'auto-réparation

Le système de niveaux de risque est un cadre pour décider quels échecs de pipeline peuvent s’auto-réparer automatiquement, lesquels nécessitent une approbation humaine avant l’application d’un correctif, et lesquels doivent rester à la main des humains. Tous les échecs ne doivent pas s’auto-réparer : un fichier dont le délimiteur a changé et qui est auto-corrigé a un rayon d’explosion contenu ; un calcul financier qui commence à retourner des résultats différents parce qu’un LLM a « corrigé » un changement de schéma n’en a pas.

Trois niveaux

Risque faible : appliquer automatiquement

Ces échecs ont des correctifs prévisibles, un rayon d’explosion contenu et une validation facile. Le pipeline peut appliquer le correctif et continuer sans intervention humaine.

• Corrections de délimiteur sur les fichiers ingérés
• Problèmes d’encodage de caractères (UTF-8 vs Latin-1, gestion du BOM)
• Relances sur les erreurs transitoires (timeouts API, limites de débit, coupures réseau)
• Ajustements de format de date sur les imports de fichiers
• Détection de ligne d’en-tête (ignorer 0 vs ignorer 1)

Le fil conducteur : le correctif est mécanique, la validation est simple (le fichier a-t-il été parsé ? les comptages de lignes correspondent-ils ?), et se tromper produit une erreur évidente plutôt que des données subtilement incorrectes. Un fichier parsé avec le mauvais délimiteur produit des données indéchiffrables qui échouent à la validation aval. Un fichier parsé avec une règle métier légèrement incorrecte produit des chiffres qui semblent plausibles mais sont incorrects. La première catégorie est à faible risque. La seconde ne l’est pas.

Pour les correctifs à faible risque, le pattern Try-Heal-Retry fonctionne bien. Laissez le LLM diagnostiquer le problème, appliquer le correctif structuré et valider la sortie. Enregistrez tout afin que quelqu’un puisse revoir les correctifs auto-appliqués lors d’un audit quotidien ou hebdomadaire.

Risque moyen : notifier et attendre

Ces échecs nécessitent un correctif, et l’automatisation peut en suggérer un, mais un humain doit l’approuver avant qu’il soit appliqué.

• Adaptation de schéma (nouvelles colonnes, changements de type dans les tables source)
• Modifications SQL de la logique de transformation
• Changements de paramètres de backfill (ajustement des fenêtres de lookback, modification des plages de partitions)
• Changements de connexion au système source (URLs d’endpoints, paramètres d’authentification)

Le pattern : le pipeline capture le contexte de l’échec, l’envoie au LLM pour diagnostic, formate le correctif suggéré dans un message Slack (ou une PR), et attend une approbation explicite. L’automatisation réalise l’investigation et rédige la solution. L’humain confirme qu’elle est pertinente.

🔧 Correctif suggéré pour la tâche `load_vendor_invoices` :
Le fichier source a changé le délimiteur de virgule à pipe.
Recommandation : mettre à jour la config du délimiteur à `|`
Confiance : haute (4 lignes parsées avec succès avec le nouveau délimiteur)

Réagissez ✅ pour appliquer, ❌ pour ignorer

Le pattern d’approbation via Slack fonctionne pour les équipes avec des temps de réponse rapides. Pour les équipes où l’approbation peut prendre des heures, envisagez de faire continuer le pipeline en mode dégradé (sauter la source problématique, traiter les autres sources normalement) plutôt que de tout bloquer en attendant un pouce levé.

Risque élevé : humain uniquement

Ces échecs ne doivent jamais être auto-remédiés, quelle que soit la confiance du LLM dans son diagnostic.

• Migrations de schéma en production
• Tout ce qui touche aux données financières, de conformité ou aux rapports réglementaires
• Opérations de suppression ou de correction de données
• Changements de logique de clé primaire ou changements de grain
• Ajustements de réconciliation cross-système

Le raisonnement : le rayon d’explosion est trop large, la validation est trop complexe, et les conséquences d’un mauvais correctif sont trop graves. Un LLM qui « corrige » un calcul de revenus en changeant une condition de jointure peut produire des chiffres qui passent la validation des comptages de lignes et des vérifications de schéma tout en étant fondamentalement erronés. L’erreur ne remonterait pas avant que quelqu’un compare la sortie à une source de référence connue, ce qui peut prendre des semaines.

Pour les situations à haut risque, le rôle de l’automatisation est le diagnostic, pas la remédiation. Envoyez le contexte de l’erreur au LLM, obtenez une analyse structurée de ce qui s’est passé et des causes possibles, livrez cette analyse à l’ingénieur d’astreinte, et arrêtez. L’ingénieur enquête, confirme la cause racine, met en œuvre le correctif manuellement et examine la sortie. Voir la discussion sur les raisons pour lesquelles l’IA a encore besoin des humains en ingénierie des données pour l’argument plus large.

Risques qui traversent les niveaux

Quelques risques spécifiques méritent attention quel que soit le niveau auquel un échec appartient.

L’auto-réparation masquant des bugs dans le code

Si votre pipeline échoue chaque mardi et que le pattern de rattrapage le récupère silencieusement chaque mercredi, vous pourriez ne pas remarquer le problème sous-jacent pendant des semaines. L’auto-réparation a parfaitement fonctionné au sens étroit (les lacunes de données ont été comblées) tout en cachant un problème systématique (quelque chose dans les données ou le planning de traitement du mardi est cassé).

Le correctif : journaliser et alerter sur les échecs auto-réparés, pas seulement sur les non-résolus. Un résumé hebdomadaire des « échecs qui se sont auto-réparés » fait remonter les patterns qui méritent investigation même s’ils n’ont pas causé d’impact en aval. Si le même échec apparaît cinq semaines de suite et s’auto-répare à chaque fois, c’est un bug, pas un problème transitoire.

Hallucination de données valides par le LLM

Les LLMs peuvent générer une sortie vraisemblable à partir d’une entrée corrompue. Si un fichier est vraiment corrompu, la bonne réponse est d’échouer, pas de générer quelque chose qui semble correct. Votre schéma de sortie structurée doit inclure une option cannot_fix qui arrête la boucle de relance plutôt que de forcer le LLM à toujours suggérer un correctif.

Sans cette porte de sortie, le LLM essaiera. Face à un fichier binaire et invité à proposer un correctif de délimiteur, il pourrait suggérer une tabulation, un pipe ou un autre caractère qui produit une sortie parseable mais sans signification. Le pipeline aval voit des données correctement formées et continue. Les données sont erronées, et rien ne le détecte jusqu’à ce qu’un humain remarque que les rapports ont l’air bizarres.

Exposition de données personnelles lors du diagnostic

Même envoyer quatre lignes d’un fichier à un LLM externe peut inclure des données personnelles. L’avertissement de Benjamin Nweke mérite d’être répété : « N’envoyez pas des données de patients à GPT-4 juste pour corriger une erreur de virgule. »

Les options pour atténuer ce risque :

• Réduire les données d’échantillon aux informations de schéma uniquement. Envoyez les noms de colonnes et les types, pas les valeurs. Le LLM peut souvent diagnostiquer les problèmes de délimiteur et d’encodage à partir du pattern structurel seul.
• Utiliser des modèles locaux. Faites passer le diagnostic par Ollama ou un autre moteur d’inférence local pour tout pipeline qui traite des données personnelles. La précision est moindre, mais les données ne quittent jamais votre infrastructure.
• Anonymiser avant d’envoyer. Remplacez les valeurs par des espaces réservés appropriés au type (les dates deviennent « 2026-01-01 », les noms deviennent « REDACTED », les nombres restent tels quels). Le pattern structurel est préservé tandis que les données personnelles sont supprimées.

La bonne approche dépend de votre classification des données. Les données d’événements marketing sans données personnelles peuvent aller vers une API. Les données de santé avec des dossiers de patients restent en local. Les données financières avec des numéros de compte sont anonymisées. Rendez la classification explicite dans votre configuration de pipeline plutôt que de laisser le jugement au cas par cas.

Contexte de maturité

L’Enterprise AI Maturity Index 2025 de ServiceNow a trouvé que moins de 1 % des organisations scoraient au-dessus de 50 sur 100. Gartner a rapporté que 30 % des initiatives IA avaient été abandonnées, principalement en raison de problèmes de qualité des données. L’auto-réparation fonctionne pour des types d’échecs spécifiques et bien délimités — principalement le niveau à faible risque — pas comme solution universelle.

Une approche pratique de démarrage : classifiez les échecs de pipeline par niveau de risque, implémentez d’abord le niveau à faible risque en utilisant le pattern Try-Heal-Retry, mesurez les résultats, et étendez au risque moyen avec approbation humaine dans la boucle uniquement après que le comportement du niveau à faible risque est validé.