Une application métier supervise un parc d'équipements connectés dont le volume varie. J'ai conçu et développé seul sa couche cartographique : trois états lisibles d'un regard, et des groupes colorés par le pire état qu'ils contiennent.
- Cadre
- Alternance
- Période
- oct. 2024 - sept. 2025
- Structure
- Wit, Nice
- Rôle
- Couche cartographique, conçue et développée seul
- Outils et technologies
- JavaScript
- Leaflet
- Regroupement de marqueurs
- Luxon
- SCSS
Une application métier de supervision d'un parc d'équipements connectés répartis sur le territoire. Le volume affiché varie selon le nombre d'équipements raccordés, ce qui interdisait toute solution calibrée sur un jeu de données figé.
Une contrainte à assumer
La carte n'est pas un composant d'un projet front-end classique. Elle vit dans l'atelier de composition d'applications de l'éditeur, un outil qui décrit l'interface de façon déclarative et la rend via un moteur générique.
Tout le comportement tient dans un unique point d'extension de cycle de vie, en JavaScript écrit à la main : pas de framework, pas de bundler, pas de gestionnaire de paquets, pas de tests unitaires, un seul point d'entrée exécuté après le montage de la vue. De l'ordre de 600 lignes.
Cette alternance a été précédée d'un stage d'intégrateur web dans la même entreprise, de janvier à mars 2024.
Le pire avant le reste
La couleur d'un groupe de marqueurs reflète le pire état qu'il contient, et non le nombre de points qu'il rassemble. Un parc de plusieurs centaines d'équipements se lit alors au premier coup d'œil, même entièrement replié.
C'est la décision de conception dont je suis le plus satisfait sur ce projet.
Ce que fait la carte
- Trois états métier, nominal, en alarme et injoignable, avec une couleur et une icône par état. L'état injoignable n'est pas remonté tel quel par le système : il est déduit du dépassement de l'échéance de communication annoncée par l'équipement.
- Au survol d'un point, une fiche synthétique : nom, identifiant, état courant et lien direct vers la page de configuration de l'unité. La carte devient le point d'entrée de l'administration du parc.
- Sur un équipement injoignable, la fiche indique depuis combien de temps le dernier échange remonte, en temps relatif localisé (« il y a 3 jours ») plutôt qu'en horodatage brut.
- Le lien vers l'interface embarquée de l'équipement transmet la session de l'utilisateur déjà authentifié quand la version du micrologiciel le permet, avec un repli sur un lien simple sinon.
- La fiche reste affichée quand le curseur passe du marqueur vers elle, avec une temporisation avant fermeture : le lien reste atteignable, conformément au critère WCAG 1.4.13 sur les contenus au survol.
- Un regroupement automatique des marqueurs proches, pour éviter les superpositions illisibles et rester performant quel que soit le volume, avec des groupes stylisés fidèles à la maquette.
- Un fond de carte volontairement sans libellés, choisi en cohérence avec la direction artistique du designer, pour que les pastilles d'état soient le seul élément coloré de l'écran.
- Un cadrage adaptatif à trois niveaux de repli : l'ensemble des équipements géolocalisés, à défaut la vue nationale, à défaut la vue par défaut. L'écran n'affiche jamais un globe vide.
- Quand des équipements n'ont pas de coordonnées, un message le dit, avec deux niveaux de gravité selon qu'il s'agit d'une partie du parc ou de sa totalité. Il peut être mis en sourdine pour la session : informer sans harceler.
- Un clic sur un marqueur ouvre la vue de détail avec le filtre déjà positionné sur l'équipement choisi : la carte est une porte d'entrée, pas un cul-de-sac.
Ce que je peux détailler en entretien
Détourner la bibliothèque de regroupement
Elle colore les groupes selon le nombre de marqueurs. J'ai réécrit sa fonction de rendu d'icône pour qu'elle parcoure les marqueurs contenus, retienne le plus critique et rende le groupe dans la couleur correspondante, l'état injoignable l'emportant sur l'alarme.
Rafraîchir les groupes après un changement d'état
Les icônes de groupe ne se recalculent pas seules : il faut le déclencher explicitement. Un piège classique de cette bibliothèque.
La continuité du survol
Temporisation à la sortie, vérification de l'élément réellement survolé, et réécoute des événements sur la fiche elle-même. Sans cela, la fiche clignote dès que le curseur traverse le vide qui la sépare du marqueur, et son lien devient inatteignable.
Les cas limites du cadrage
Un parc vide et un parc réduit à un seul point demandent chacun un traitement à part, sans quoi l'ajustement automatique échoue ou produit un zoom inutilisable.
Deux mécanismes de navigation
Écriture dans l'état partagé du moteur de rendu pour rester dans l'application, message inter-fenêtres vers l'application hôte pour en sortir : la vue s'exécute dans un cadre embarqué.
Autour de la carte
Sur ce poste, j'ai aussi ajouté des composants à la bibliothèque interne (Svelte, shadcn, TypeScript), maintenue par une équipe de trois à cinq développeurs, dans le respect de ses conventions et de son processus de revue de code.
J'ai exploré la visualisation de graphes avec D3.js et Sigma.js, et fait mes premières expérimentations 3D avec Three.js : une exploration, pas une maîtrise.
Aucune capture ni extrait de code : l'application affiche le parc et les alarmes réels de clients, et le code appartient à l'employeur. J'ai voulu refaire proprement, et seul, ce que j'avais construit en entreprise : une démo publique, sur des données générées, est en cours de développement.
