Cas pratique • Nettoyage industriel
Créer automatiquement un tableau de bord hebdomadaire pour le dirigeant
Une entreprise de nettoyage industriel consolide chaque semaine ses contrats signés, ses heures planifiées, ses absences, sa facturation et les incidents signalés sur les sites clients. Le dirigeant reçoit une vue commune avant la réunion du lundi, sans demander à chaque responsable de reconstruire ses chiffres dans un tableur différent.
Avant l’automatisation
Avant : le reporting du lundi était préparé à partir de cinq sources qui ne racontaient pas toujours la même histoire
Chaque vendredi, l’assistante de direction exportait les contrats et opportunités depuis Sellsy, demandait les heures planifiées aux responsables de secteur, récupérait les absences dans Kelio et sollicitait la comptabilité pour connaître les factures émises et les retards de paiement.
Les incidents qualité et demandes clients étaient suivis dans un tableau Excel partagé. Un même site pouvait apparaître sous plusieurs noms, les périodes n’étaient pas toujours alignées et certaines absences étaient connues après l’extraction du planning. Le chiffre d’affaires prévisionnel semblait donc cohérent jusqu’au moment où quelqu’un demandait comment il avait été calculé.
La préparation mobilisait plusieurs heures et le fichier final arrivait parfois le lundi matin, quelques minutes avant la réunion. Les responsables passaient alors davantage de temps à discuter de la fiabilité des données qu’à décider où renforcer une équipe, traiter un incident ou relancer une facture.
Système mis en place
Après : les données sont collectées le dimanche soir et contrôlées avant publication
Chaque dimanche à 20 h, le workflow récupère les opportunités et contrats dans Sellsy, les heures prévues et réalisées dans Kelio, les factures et règlements dans Sage 100 ainsi que les incidents enregistrés dans le tableau opérationnel.
Les sites clients sont rapprochés à partir d’un identifiant commun. Les indicateurs sont calculés selon des définitions validées : chiffre d’affaires signé, taux de couverture des heures, absentéisme, écart entre heures prévues et réalisées, factures à échéance et incidents ouverts depuis plus de sept jours.
Avant la publication, le système contrôle les sources non actualisées, les écarts inhabituels et les sites sans planning ou sans facturation attendue. Les anomalies sont envoyées au responsable concerné. Le tableau Power BI n’est diffusé que lorsque les données critiques sont disponibles, ou il affiche explicitement la source manquante au lieu d’inventer un zéro très propre et totalement faux.
Déroulement du workflow
Le workflow produit chaque semaine une version datée du reporting et conserve la source ainsi que l’heure de mise à jour de chaque indicateur.
- Déclencher la collecte chaque dimanche à 20 h
- Récupérer les ventes dans Sellsy et la facturation dans Sage 100
- Importer les heures, plannings et absences depuis Kelio
- Rattacher les incidents Excel au bon site client
- Calculer les indicateurs selon les règles validées
- Signaler les données manquantes et variations anormales
- Actualiser Power BI et envoyer la synthèse du lundi
- Archiver la version hebdomadaire et la fraîcheur des sources
Ce qui reste sous contrôle humain
- Validation des définitions et seuils d’alerte
- Commentaire des événements exceptionnels sur les sites
- Décision de renforcer une équipe ou réorganiser un planning
- Correction des données dans Sellsy, Kelio ou Sage 100
Effets opérationnels possibles
- Moins de compilation manuelle avant la réunion
- Indicateurs calculés de manière identique chaque semaine
- Détection rapide des sites sous-staffés ou non facturés
- Réunion davantage centrée sur les décisions opérationnelles
Exemple d’alerte hebdomadaire
Le site client « Logistique Atlantique » prévoit 186 heures de prestation pour la semaine, mais Kelio ne contient que 154 heures affectées après deux absences confirmées. Dans le même temps, un incident qualité reste ouvert depuis neuf jours.
Couverture 82,8 % → 32 heures non affectées → 2 absences → 1 incident ouvert → alerte responsable de secteur
Le tableau de bord ne décide pas quelle personne déplacer ni comment traiter l’incident. Il montre simplement que le site cumule plusieurs signaux qui nécessitent une décision avant le début de la semaine.
Points de vigilance
- 1. Chaque site doit posséder un identifiant commun dans les différents outils.
- 2. Les indicateurs doivent être reliés à des décisions concrètes, pas ajoutés pour décorer Power BI.
- 3. Une donnée non actualisée doit être signalée, pas remplacée silencieusement.
- 4. Les données sociales et financières doivent être limitées aux personnes autorisées.
- 5. Toute correction doit être réalisée dans le système source pour éviter les écarts au prochain calcul.
Les droits d’accès, la confidentialité, le RGPD, la journalisation des erreurs et les mécanismes de reprise doivent être adaptés à la sensibilité des données consolidées.
Conclusion du cas
Le reporting hebdomadaire devient une chaîne de données contrôlée, pas un fichier reconstruit chaque vendredi
Dans ce scénario, le dirigeant reçoit chaque lundi une vision commune des ventes, de la charge, des absences, de la facturation et des incidents. Les responsables conservent l’analyse et les décisions, tandis que la collecte, les calculs et les contrôles sont reproduits de manière identique chaque semaine.
Architecture retenue pour ce cas
Sellsy reste la source de vérité pour les opportunités et contrats commerciaux. Kelio porte les plannings, les heures réalisées et les absences. Sage 100 fournit les factures, règlements et échéances clients.
Un workflow n8n collecte les données chaque dimanche, rapproche les sites à partir de leur identifiant commun et charge les indicateurs consolidés dans une base PostgreSQL dédiée au reporting. Le tableau Excel des incidents est importé dans le même flux jusqu’à son remplacement par un outil métier.
Power BI lit uniquement la base de reporting et publie le tableau de bord. Les anomalies de collecte sont envoyées aux responsables concernés avant diffusion, ce qui évite de corriger manuellement les chiffres directement dans le tableau final.
Approfondir le sujet
Ressources complémentaires dans le blog
Ces articles détaillent les méthodes et règles métier utilisées dans ce cas pratique.
Autres cas pratiques
Voir les 8 cas →Définir une source de vérité et fiabiliser les échanges entre applications.
Qualifier les demandes, identifier les urgences et affecter le bon technicien.
Extraire les données, rapprocher les commandes et isoler les anomalies avant comptabilisation.
Votre reporting hebdomadaire dépend-il encore de plusieurs exports manuels ?
Un diagnostic permet d’identifier les sources disponibles, les définitions d’indicateurs, les contrôles nécessaires et les données qui peuvent être consolidées automatiquement.
Réserver un diagnostic de 20 minutes