Dashboard
Sauron — Ligne 27

Présentation

Contexte du stage

Stage de 1ère année réalisé du 26 mai au 23 juin 2026 chez Aspen Notre Dame de Bondeville (Aspen NDB), site industriel pharmaceutique produisant des principes actifs et des seringues préremplies. J'ai intégré le service Applications de la DSI, en charge des outils IT et OT (systèmes industriels) du site.

Ma mission principale a porté sur Sauron, une solution interne développée pour centraliser et analyser les données de performance industrielle, en remplacement d'un ancien système basé sur des fichiers Excel devenu coûteux, rigide et obsolète.

Architecture

De la collecte à la visualisation

Le projet repose sur une chaîne complète, de la donnée brute au tableau de bord :

Un flux Node-RED que j'ai conçu s'exécute automatiquement chaque jour à 5h : il extrait les données de production, les transforme en JavaScript, génère dynamiquement les requêtes SQL, puis les insère dans la base PostgreSQL (OEE_Ligne27) via un mécanisme d'UPSERT évitant les doublons.

Mission principale

Tableau de bord Grafana — Ligne 27

La Ligne 27 conditionne des seringues préremplies. J'ai développé le dashboard Grafana de suivi en temps réel : production journalière, taux de rejet, état des équipements (THERMO, ASS, ETUY, VIGNET), OEE sur l'heure glissante, production par shift et production hebdomadaire.

J'ai écrit l'ensemble des requêtes SQL du dashboard en m'appuyant sur les lignes déjà en production, corrigé plusieurs bugs (valeurs nulles mal gérées, erreurs de format sur les données horaires, erreurs de calcul des totaux), puis optimisé les requêtes pour réduire le temps de réponse.

Extrait de code

Requête Production J-1

Récupère les trois périodes de la veille (matin, après-midi, soir) avec nombre de seringues et efficacité.

-- Production de la veille, triée par intervalle
SELECT intervalle, nb_seringues, efficacite
FROM l27_totaux_jour
WHERE date_jour = CURRENT_DATE - 1
ORDER BY intervalle;

Optimisation — État des équipements

La première version imbriquait une sous-requête ORDER BY ... LIMIT 1 dans un COALESCE, forçant PostgreSQL à exécuter deux étapes. Je l'ai restructurée pour intégrer directement le tri dans la requête principale.

-- AVANT : sous-requête imbriquée dans un COALESCE
SELECT COALESCE(
  (SELECT valeur FROM ip21_tags
   WHERE tag = 'THERMO'
   ORDER BY timestamp DESC LIMIT 1), 0
);

-- APRÈS : tri intégré directement dans la requête principale
SELECT valeur
FROM ip21_tags
WHERE tag = 'THERMO'
ORDER BY timestamp DESC
LIMIT 1;

Problème résolu

Le décalage horaire de production (5h → 5h)

J'ai mis en place un décalage horaire de 5 heures directement dans le script Node-RED : les données entre 00h et 05h sont automatiquement rattachées à la journée précédente, ce qui a aligné les calculs de cumul journalier et les agrégations hebdomadaires sur la réalité terrain.

Résultats

Optimisations et gains obtenus

Le plus gros levier de performance a été la création d'index sur les colonnes les plus utilisées en filtre et en tri :

CREATE INDEX idx_marche_timestamp ON "table_marche"(timestamp DESC);
CREATE INDEX idx_libelle_timestamp ON "l27_autre_valeurs"(libelle, timestamp DESC);
CREATE INDEX idx_date_intervalle ON l27_totaux_jour(date_jour, intervalle);

• Performance — requêtes plus rapides, accès direct aux données via les index
• Stabilité — requêtes simplifiées, moins de risques d'erreur, meilleure compatibilité Grafana
• Maintenance — code plus lisible et plus facile à reprendre

Organisation

Méthode Agile & outils de suivi

L'équipe fonctionnait en Agile : points journaliers chaque matin, suivi des tâches sur Fabriq, tableau de gestion de projet sur Planificator et communication via Microsoft Teams. Ce découpage en petites itérations m'a permis d'avancer progressivement et de m'appuyer sur les retours de l'équipe.