Faber DART Engine — La plateforme de données qui diagnostique ses propres pannes comme un système vivant

22 juin 2026 · Dream #3 (8.3/10) · Faber Foundry DART Observability

Toute plateforme de données tombe en panne. La question, c'est ce qu'elle en fait.

Faber Foundry a une ontologie, une couche d'ingestion, des pipelines Bronze→Silver→Gold, une gouvernance des données et une API. C'est une architecture propre, documentée, testée. Mais comme toute plateforme de données qui tourne en production, elle tombe en panne.

Un connecteur Kafka qui se déconnecte à 3h du matin. Un chunker sémantique qui découpe mal les tableaux Markdown complexes. Une règle de qualité qui rejette silencieusement 12% des données valides. Un goulot d'étranglement qui apparaît uniquement le mardi entre 14h et 14h30 — allez comprendre.

Aujourd'hui, ces pannes sont diagnostiquées manuellement. Un ingénieur reçoit une alerte, lit les logs, émet des hypothèses, teste des correctifs. C'est lent, coûteux, et surtout non capitalisé : la connaissance acquise pendant le diagnostic reste dans la tête de l'ingénieur. La panne suivante — même identique — repart de zéro.

Le Faber DART Engine change ce paradigme. Il applique la pensée systémique (Cynefin + DART) à l'introspection de la plateforme.

Le protocole DART : Deconstruct → Analyze → Recognize → Test

Quand un pipeline Faber échoue, le DART Engine ne se contente pas de logger une stack trace. Il exécute un protocole en quatre phases :

1. Deconstruct — isoler le composant défaillant. Est-ce le connecteur Kafka ? Le chunker ? La règle de qualité ? Le scheduler ? L'isolation est chirurgicale : on désactive le composant fautif, on snapshot l'état, et on laisse le reste de la plateforme tourner.
2. Analyze — déterminer le lien cause→effet. Pas de corrélation vague. Une chaîne causale traçable : « Le chunker a produit des chunks de taille 0 sur les tableaux à 4+ colonnes → la règle de qualité a rejeté ces chunks → 12% des données manquent en Silver. »
3. Recognize — matcher avec un pattern de panne connu. C'est la mémoire institutionnelle de la plateforme. Si ce pattern a déjà été résolu, on applique la solution documentée. Si c'est nouveau, on crée un ticket avec le diagnostic complet.
4. Test — appliquer le plus petit correctif possible et valider. Pas de « déploiement complet » pour un problème de chunking. On ajuste le paramètre de chunking size sur les tableaux, on rejoue le pipeline sur les données affectées, et on vérifie que le taux de rejet revient à la normale.

Classification Cynefin : toutes les pannes ne se valent pas

Le DART Engine classifie chaque panne dans un quadrant Cynefin avant d'appliquer DART :

• Clair — « Le connecteur Kafka est down. » → Webhook Slack avec la checklist de redémarrage. Pas besoin de mobiliser un expert.
• Compliqué — « Le chunking découpe mal les tableaux Markdown. » → Ticket Linear avec diagnostic + suggestion d'expert à solliciter (le crate faber-ingestion).
• Complexe — « La qualité des données se dégrade lentement sur 3 semaines, aucune métrique n'a franchi de seuil. » → Une hypothèse Arbor est créée automatiquement. Des expériences sont lancées : changer le chunking size, ajuster le score threshold, rerouter le pipeline par un chemin alternatif. Les résultats alimentent l'hypothèse.
• Chaotique — « Corruption de la DB SQLite de la couche Bronze. » → Le pipeline est mis en pause immédiatement, l'état est snapshoté, une alerte critique est envoyée. On stabilise d'abord, on débat ensuite.

La boucle d'apprentissage : ne jamais faire deux fois la même erreur

La véritable innovation du DART Engine n'est pas le diagnostic — c'est la capitalisation. Chaque résolution réussie est sauvegardée comme pattern dans une bibliothèque de pannes. Le « R » de DART — Recognize — s'enrichit à chaque incident. Après 6 mois de fonctionnement, 80% des pannes sont classifiées automatiquement sans intervention humaine.

C'est le Principe TRIZ #34 — Rejet/régénération — appliqué aux opérations : on « rejette » le mode de debug manuel (lire des logs, deviner, corriger) et on « régénère » un diagnostic automatisé qui apprend. La plateforme ne refait jamais deux fois la même erreur de diagnostic parce que chaque erreur est transformée en connaissance persistante dans le Memory-Graph BMAM.

Le DART Engine est un agent spécialisé du mesh HERMYTHOS V2.0. Il écoute les événements de la plateforme (logs, métriques, health checks) via le même bus que les autres agents. Il publie ses diagnostics dans le même format. Et il enrichit les runbooks du Co-Manager IA avec les patterns de résolution qu'il découvre — transformant l'incident d'hier en procédure d'aujourd'hui.

C'est ça, une plateforme de données qui se comporte comme un système vivant : elle détecte, elle diagnostique, elle apprend, elle s'adapte. Sans ticket. Sans escalade. Sans l'ingénieur réveillé à 3h du matin.

Vos pipelines de données tombent en panne et personne ne capitalise sur les résolutions ?
Automatisons vos diagnostics →