Ce que le pipeline temps réel m'a appris sur la fiabilité des données
Retour d'expérience sur la construction d'un pipeline Kafka pour classifier des commentaires en direct, et sur les décisions qui ont le plus pesé sur la précision finale.
Quand j'ai commencé le projet de classification de sentiment en temps réel, mon premier réflexe a été de me concentrer sur le modèle : quel algorithme, quels hyperparamètres, quelle métrique optimiser. Après quelques semaines, j'ai compris que la partie la plus fragile n'était pas le modèle, mais tout ce qui se passait avant lui.
Le vrai goulot d'étranglement : la donnée en mouvement
Un modèle entraîné sur un dataset propre donne toujours de bons résultats en local. Le problème arrive quand les données changent de forme en production : un commentaire vide, un encodage inattendu, un pic de volume. Kafka a résolu la question du débit, mais pas celle de la qualité. J'ai dû ajouter une couche de validation avant même que les messages n'atteignent le modèle.
Un pipeline temps réel n'est pas un modèle qu'on connecte à un flux, c'est un flux qu'on protège avant de le confier à un modèle.
Concrètement, j'ai isolé trois points de friction récurrents et j'ai construit le pipeline autour d'eux plutôt qu'autour de l'algorithme.
- Normalisation systématique avant tout traitement, y compris sur les champs qu'on pense toujours propres
- Files d'attente séparées pour isoler les messages invalides sans bloquer le flux principal
- Métriques de dérive suivies en continu, pas seulement au moment de l'entraînement
Le résultat final (83,5 % de précision) doit autant à ces trois décisions qu'au choix de XGBoost comme modèle. C'est la leçon que je retiens le plus de ce projet : en production, la donnée compte plus que l'algorithme.