AI anomaly detection sur événements de traçabilité : de la détection au yield optimization

TL;DR — “AI anomaly detection” sonne comme du deep learning sophistiqué. Dans la pratique, les modèles qui font bouger l’aiguille en production alimentaire sont simples, interprétables et connectés directement au processus opérationnel. Nous racontons comment chez Darwin nous sommes passés de “nous détectons des anomalies” à “nous optimisons le yield” — et pourquoi le gap entre les deux est plus grand qu’il n’y paraît.

Le problème : anomalies détectées ≠ valeur capturée

Beaucoup de plateformes promettent de “détecter des anomalies dans le supply chain avec de l’AI”. Le ML détecte des outliers — facile. Mais un outlier détecté n’est pas de la valeur tant que :

L’opérateur le comprend (ce n’est pas une boîte noire qui dit “anomalie”)
Ça arrive à temps (une alerte 4 heures plus tard ne sert à rien)
Ça se traduit en action concrète (pas seulement “dashboard avec graphique rouge”)
L’impact est mesuré (combien avez-vous économisé ? combien de yield gagné ?)

La plupart des projets s’arrêtent à l’étape 1 — ils détectent des choses mais ne bouclent pas la loop. Chez Darwin nous avons construit le système end-to-end. Voici comment.

Ce que nous détectons (et ce que non)

✅ Anomalies que nous détectons

Type	Exemple	Modèle
Déviations de process	Température de cadena de frío hors plage	Règles + rolling statistics
Incohérences de lot	Poids déclaré vs. poids réel à l’expédition	Régression simple par produit
Fraude potentielle	Fournisseur reportant plus de volume que sa capacité productive historique	Isolation forest sur features de fournisseur
Qualité dégradée	Retours client corrélés à un lot spécifique	Corrélation + analyse causale basique
Patterns temporels	Rendement baisse systématiquement les lundis après arrêts	Seasonal decomposition

❌ Ce que nous ne faisons PAS (encore)

Prédiction de demande — ce n’est pas de la traçabilité, on ne va pas là
Computer vision de produit — exige du hardware spécifique ; hors scope
Deep learning end-to-end — l’overhead vs. valeur ne le justifie pas dans ce domaine

Notre règle : un modèle interprétable que l’opérateur comprend > un modèle complexe qui est “meilleur” sur les métriques. Si un client ne peut pas expliquer à son auditeur comment une anomalie a été détectée, ça ne nous sert pas.

Le stack

Data pipeline :

Événements CTE/KDE entrant via Captia → Pub/Sub → PostgreSQL (raw) + data warehouse (features)
Feature engineering programmé (tous les N événements ou toutes les X minutes)

Models :

Python (scikit-learn, statsmodels) — modèles simples, interprétables
Prophet — pour les patterns temporels
Isolation Forest — pour les outliers multivariés sur features de fournisseur

Serving :

Modèles entraînés offline, scoring en temps réel sur un service dédié
Scoring typique : <100ms par événement
Rule-based alerts par-dessus (nous combinons ML + règles métier)

Delivery :

Alertes aux opérateurs via WhatsApp + email + dashboard
Chaque alerte inclut : ce qui a été détecté, pourquoi, quelles features ont contribué, action suggérée

De l’outlier au yield : l’étape que personne ne raconte

C’est ici qu’est le vrai travail. Détecter un outlier est facile. Le convertir en valeur pour le client exige :

1. Alertes actionnables, pas informatives

Mauvais :

“Anomalie détectée dans le lot #12345”

Bon :

“Le lot #12345 a un poids 7 % inférieur à l’attendu (basé sur 200 lots similaires sur les 90 derniers jours). Cause possible : perte d’humidité par ventilation excessive. Vérifier : compresseur #3 (dernière maintenance il y a 6 mois) ou porte de chambre (joint).”

L’alerte inclut : quoi, pourquoi, quoi vérifier en premier. L’opérateur agit en minutes, pas en heures.

2. Feedback loop avec l’opérateur

Quand l’opérateur résout une alerte, l’app demande :

Était-ce une vraie anomalie ? (feedback au modèle)
Quelle était la root cause ?
Quelle action avez-vous prise ?

Ces labels deviennent training data pour la prochaine itération du modèle. Les modèles apprennent des décisions humaines, pas seulement des données historiques.

3. Métriques métier, pas seulement de ML

Les dashboards que nous montrons au client NE montrent PAS “precision: 0.94 / recall: 0.87”. Ils montrent :

Yield préservé — tonnes récupérées parce que l’alerte est arrivée à temps
Temps de réponse amélioré — de X heures à Y minutes
Recalls évités — incidents détectés avant d’arriver au consommateur

Ce sont les chiffres qui font que le client renouvelle le contrat, pas la matrice de confusion.

4. Causal analysis, pas seulement correlation

Détecter que “le yield baisse les lundis” est facile. Ce qui est utile, c’est : pourquoi.

Nous combinons :

Event sequence analysis — quels événements précèdent le drop de yield
Operator feedback — la connaissance locale du plant manager
LLM-assisted root cause — le LLM propose des hypothèses que l’expert confirme

Résultat : nous n’alertons pas seulement, nous expliquons des patterns. Ça transforme “détection” en “optimisation”.

Un cas réel : perte de yield en transformation de fruits

Un client notait que le rendement de transformation (kg de matière première → kg de produit fini) baissait sans explication claire. Varie entre 72 % et 78 %, sans pattern évident.

Avec Captia + Tracium nous avions déjà tous les événements détaillés. Nous avons appliqué :

Feature engineering — température ambiante, fournisseur, lot d’origine, poste, opérateur, temps entre récolte et transformation
Modèle de régression simple — prédit le yield attendu étant donné les features connues
Analysis de résidus — cas où le yield réel diffère de >3 % de l’attendu

Découverte : le temps entre récolte et transformation était le prédicteur le plus fort. Les lots qui entraient en transformation >48h après la récolte avaient un yield 5-8 % plus bas.

Action du client : ils ont réorganisé le flux logistique pour prioriser les lots plus anciens. En 3 mois :

Yield moyen +3,2 % → 180 k $ /an en économies pour cette seule usine
Alertes actionnables quand un lot dépasse le threshold de “risque”
Meilleure négociation avec fournisseurs — data pour exiger des livraisons plus rapides

Ce n’est pas du deep learning sophistiqué. C’est régression + feature engineering + distribution disciplinée de l’alerte. La valeur est dans le fait de boucler la loop, pas dans la complexité du modèle.

Ce qui n’a pas marché

V0 : deep learning end-to-end — nous avons testé des LSTMs sur des séries temporelles d’événements. Précision similaire à la régression simple, mais non interprétable. Les opérateurs ne faisaient pas confiance à des alertes qu’ils ne pouvaient pas expliquer. Abandonné.

Dashboards comme canal principal — beaucoup d’anomalies restaient dans le dashboard sans action. Migration vers push notifications (WhatsApp) avec call-to-action explicite.

Modèles globaux par industrie — un modèle pour “tous les fruits” donnait une précision pire que des modèles spécifiques produit-usine-fournisseur. Maintenant nous entraînons des spécifiques et donnons un versioning clair.

Lessons learned

Le gap entre détection et valeur est 80 % du projet — pas le modèle
Interprétabilité > précision dans des domaines avec opérateurs humains
Feedback loop dès le jour 0 — sans labels des opérateurs, le modèle stagne
Métriques métier, pas de ML dans les rapports au client
Modèles simples + domain knowledge > modèles complexes sans contexte

Et maintenant ?

Nous explorons la causal AI avec des outils comme DoWhy — non seulement détecter des corrélations mais inférer la causalité réelle des événements. Combiné avec des LLMs pour formuler des hypothèses, ça peut accélérer beaucoup la root cause analysis.

Si vous construisez de l’anomaly detection dans le supply chain et que votre modèle détecte bien mais personne n’agit sur les alertes, le problème n’est pas votre modèle — c’est la loop d’action. Commencez par là.

Vous avez un problème de yield, waste ou perte de qualité en production ? Parlons-en — nous pouvons vous montrer des cas réels avec un impact mesurable.