Dronisos — Système de Reporting Sécurité

Contexte

Dronisos conçoit des spectacles de drones lumineux pour des parcs d’attractions (Disneyland Paris, Puy du Fou, Dollywood) et des événements premium. L’exploitation repose sur un écosystème logiciel interne. Symphony pour la chorégraphie 3D, Orion comme base RTK, la DCC (Drone Control Center) comme poste de pilotage des essaims. Chaque vol est encadré par la DGAC : la traçabilité des données de mission est une obligation réglementaire, pas un confort documentaire. J’ai rejoint l’équipe comme Product Designer et très vite, la rédaction de la PRD du projet m’a été confiée, ce qui m’a amené à porter à la fois la vision produit et la direction design.

Problème

À l’issue d’un vol, la DCC générait automatiquement un rapport PDF tabulaire, interne et peu lisible. En pratique, personne ne l’ouvrait. Le directeur de vol rédigeait à la place un message Slack récapitulant la vitesse du vent, l’état des batteries, les incidents ; un opérateur recopiait ensuite ces informations dans un Google Sheet non standardisé. Résultat : environ 20 minutes de travail manuel par mission, trois sources de vérité contradictoires, et une analyse post-vol structurellement impossible à industrialiser. Pour une entreprise dont la sécurité est le premier argument commercial, ce trou d’outillage devenait un risque.

Challenge 01 — Comprendre pourquoi le rapport n’était pas lu

Le défi : avant de redessiner l’interface, comprendre pourquoi un artefact déjà automatisé avait été abandonné par ses propres utilisateurs.

Mon approche : en Sprint 1, j’ai mené des entretiens avec les directeurs de vol, les opérateurs terrain et l’équipe analyse. Le rapport existant mélangeait sans hiérarchie des données brutes de télémétrie, des champs techniques à destination des développeurs et les indicateurs réellement utiles au débrief. Le format tabulaire ne permettait pas d’isoler rapidement l’information critique, notamment le dépassement du seuil vent à 35 km/h, qui conditionne la décision de décoller.

Résultat : une cartographie des besoins en trois couches (décision immédiate terrain, débrief opérationnel, archivage réglementaire) qui a servi de grille à toute la suite.

Challenge 02 — Concevoir un rapport éditorial tenant en deux pages

Le défi : restituer la télémétrie d’un vol dans un document scannable en moins d’une minute par un directeur de vol, tout en restant conforme aux attentes DGAC.

Mon approche : j’ai traité le rapport comme un document éditorial, pas comme une vue d’administration. Page 1 : un bloc Operator Feedback ouvert à la saisie libre du directeur de vol, un Quick Summary à quatre indicateurs (Flight Score, Pyrotechnic Firing, Hotswaps Used, Detected Issues), les Flight Details et le Wind Summary. Page 2 : le System Versions et la table Issues & Errors qualifiée par gravité. J’ai construit un design system dédié dans Figma (fondations, composants Vuetify 3, workflows et états) documenté sur sept itérations versionnées avec les développeurs.

Résultat : un livrable unique qui remplace simultanément le PDF abandonné, le message Slack manuel et la recopie Sheet.

Challenge 03 — Raccorder l’interface au pipeline de données

Le défi : le rapport n’a de valeur que si sa génération est fiable, automatisée, et son archivage traçable.

Mon approche : j’ai piloté avec le PM la conception du pipeline : ingestion des logs .ulog et .bin, corrélation avec les données anémomètres, génération du PDF depuis la page Analysis de la DCC, dépôt automatique dans l’arborescence Google Drive conforme DGAC, notification Slack au directeur de vol avec lien direct. Côté UX, l’enjeu était de conserver un point de contrôle humain : le directeur de vol peut éditer le rapport avant archivage, mais le chemin par défaut ne demande aucune action.

Résultat : centralisation des flux contractuels de bout en bout, de la donnée brute à l’archive réglementaire.

Les entretiens comme source de vérité

Lors des entretiens menés en Sprint 1, les directeurs de vol ont exprimé un constat partagé : après chaque vol, ils passaient plus de temps à compiler manuellement les informations qu’à les analyser. La double saisie Slack puis Google Sheet ne relevait pas d’une préférence, mais d’un symptôme : le rapport automatique existant ne répondait à aucun cas d’usage réel.

Synthèse des entretiens Sprint 1 (directeurs de vol, opérateurs terrain)

Itérations et décisions de design

La V0 proposait un rapport d’une seule page dense, proche d’un tableau de bord. Les tests internes ont montré qu’elle reconduisait le défaut du rapport d’origine : trop de signaux, aucune hiérarchie. La V3 a introduit la rupture éditoriale (Operator Feedback en ouverture, Quick Summary visuel, Issues & Errors en fin de document) et le passage à deux pages. La décision de conserver deux pages plutôt qu’une a été défendue auprès du PM : une pagination explicite permet l’impression terrain et améliore la lecture linéaire, deux besoins remontés des opérateurs. Les V4 à V6 ont affiné la typographie et la qualification des incidents par gravité ; la V7, livrée en handover Sprint 3, est celle qui tourne aujourd’hui en production.

Résultats et impact

• ~20 minutes gagnées par mission sur l’analyse post-vol.
• Centralisation à 100 % des flux contractuels, de la télémétrie à l’archivage DGAC.
• Seuil critique vent (35 km/h) rendu immédiatement lisible sur le rapport et dans la notification Slack.
• Conformité réglementaire assurée par l’archivage automatisé sur Google Drive.
• Design system versionné (sept itérations documentées) transmis aux équipes dev en Sprint 3.

Apprentissages

Ce projet m’a confirmé qu’un livrable abandonné n’est pas toujours un problème de design : il peut être un problème de cadrage produit. Porter la PRD en parallèle du design m’a permis d’aligner le périmètre technique sur les besoins métier réels, sans filtre intermédiaire.

La contrainte réglementaire (DGAC, traçabilité, archivage) s’est révélée un accélérateur de décision plutôt qu’un frein : elle a forcé l’équipe à choisir une seule source de vérité, ce qui a simplifié l’architecture.

Si je devais refaire le projet, j’investirais plus tôt dans les tests auprès des opérateurs terrain. Les directeurs de vol ont été consultés dès le Sprint 1 ; les opérateurs qui utilisent le rapport en mobilité sur tablette n’ont été associés qu’au Sprint 2. Le volet tablette a été rattrapé, mais il aurait gagné à être posé en amont.