Ce projet est une application de gestion des passerelles. Elle permet entre autres de visualiser les passerelles sur une carte, ainsi que dans un tableau représentant les bâœtiments dans lesquels elles se trouvent. L'application permet également d'ajouter des passerelles, de les modifier et de les supprimer. Elle est utilisée par les techniciens de maintenance pour gérer les passerelles et planifier les interventions de maintenance.
Avant d'aborder l'application Genesis en elle-même, il convient de poser le contexte entourant les activités de l'entreprise Qowisio. Le coeur de métier de Qowisio repose sur la conception de compteurs connectés dédiés à l'Internet des Objets (IoT). Néanmoins, ces capteurs ne disposent pas de la portée nécessaire pour expédier leurs relevés directement aux serveurs centraux. C'est pourquoi l'infrastructure s'appuie sur des passerelles : des boîtiers physiques chargés de collecter les flux de données émis par l'ensemble des capteurs environnants pour les centraliser et les acheminer vers le cloud.
Cette mécanique technique est essentielle, car elle constitue le socle fonctionnel de Genesis, qui s'impose comme une application métier d'aide à la pose de passerelles. L'intérêt d'un tel outil est stratégique. En effet, la majeure partie du parc immobilier géré par Ocea Smart Building comprend des bâtiments résidentiels ou tertiaires regroupant de quelques dizaines à plusieurs milliers de capteurs. Les passerelles doivent donc être positionnées de manière optimale et stratégique dans les immeubles afin de maximiser le taux de captation des données, tout en évitant le déploiement superflu et coûteux d'un boîtier dans chaque logement.
De plus, il est primordial qu'Ocea conserve une traçabilité rigoureuse de l'ensemble de son parc de passerelles opérationnelles. L'application doit permettre d'enregistrer l'emplacement géographique précis de chaque équipement, son historique d'installation, des clichés photographiques de l'infrastructure sur le terrain ainsi qu'un ensemble de métadonnées d'exploitation essentielles.
Pour répondre à ces enjeux, Genesis articule son fonctionnement autour de deux fonctionnalités principales. Le premier volet s'adresse directement aux techniciens de maintenance terrain : il leur permet de visualiser cartographiquement les passerelles existantes, d'évaluer l'indice de couverture radio d'un bâtiment et de simuler l'ajout d'un nouveau boîtier afin d'analyser instantanément son impact sur la qualité du réseau.
Le second volet cible les gestionnaires et superviseurs basés en bureau. Ces derniers disposent d'une vue d'ensemble leur permettant de planifier et de déclencher les ordres d'intervention des techniciens sur le terrain, notamment lorsqu'ils détectent des zones de rupture de couverture ou des passerelles obsolètes nécessitant une maintenance préventive.
Avant de se pencher sur l'architecture de Genesis, il est essentiel de comprendre l'historique des outils de l'entreprise.
Initialement, le suivi du parc s'effectuait manuellement sur des supports papier. Les agents administratifs en bureau saisissaient ensuite ces données terrain dans des tableurs Microsoft Excel. Pour moderniser ce flux, le groupe Ocea a développé Zeus, une application lourde sous Windows. Elle permettait enfin aux techniciens de déclarer directement l'emplacement des passerelles installées.
Cependant, cette application Windows présentait une limite majeure : elle était exploitée par des équipes intrinsèquement nomades. Pour pallier ce manque de mobilité, l'entreprise a dû investir dans des tablettes Windows dédiées, onéreuses et peu ergonomiques sur le terrain. Les techniciens ne disposant pas de ce matériel devaient manipuler un ordinateur portable traditionnel au milieu des halls d'immeubles, une logistique particulièrement inconfortable lors des phases de pose.
Face à ces contraintes, la direction a souhaité remplacer Zeus. L'intégration de Qowisio au sein du groupe a offert l'opportunité idéale : confier à notre pôle d'experts informatiques la refonte intégrale de cette solution métier.
Le cahier des charges exigeait une application à l'ergonomie irréprochable pour les opérateurs terrain, tout en garantissant un périmètre fonctionnel au moins équivalent à celui de l'ancien système Windows. La complexité de cet enjeu résidait dans l'hétérogénéité des utilisateurs, dont l'appétence pour l'outil informatique variait grandement. L'application se devait d'être hautement technique pour afficher des indicateurs réseaux denses, sans pour autant saturer l'espace visuel au détriment de l'expérience utilisateur (UX), un problème fréquent sur les logiciels industriels.
Éviter une interface surchargée était capital, d'autant plus que Genesis représentait un enjeu stratégique majeur : c'était la première fois que Qowisio concevait une application complète pour le compte d'Ocea. Ce projet faisait office de galop d'essai et de test de confiance quant à notre capacité à livrer un produit fini, performant, stable et aligné sur des délais de production particulièrement stricts.
Le défi consistait également à concilier deux usages distincts au sein d'une même application : l'utilisation nomade des techniciens (axée sur la saisie rapide et la cartographie) et l'utilisation sédentaire des managers en bureau (centrée sur l'analyse de données globales et la planification). Enfin, l'abandon de l'environnement Windows au profit d'une approche mobile imposait d'assurer une compatibilité multi-plateforme stricte, une minorité de collaborateurs exploitant des appareils Apple iOS (iPhone) face à une majorité de terminaux Android.
L'équipe de réalisation logicielle était dimensionnée à taille humaine. Elle se composait d'un premier développeur mobile (n'ayant jamais pratiqué le framework Flutter), de moi-même en tant que second développeur et référent architectural, ainsi que d'un troisième ingénieur. Ce dernier s'est focalisé sur l'intégration du module d'authentification centralisé et a orchestré toute la partie DevOps (automatisation des numéros de version, pipelines CI/CD et préparation des déploiements).
Mon maître d'apprentissage assurait la direction générale du projet. Sans intervenir directement dans les lignes de code, il occupait le rôle indispensable de passerelle organisationnelle entre Ocea et notre équipe technique, en négociant les jalons de livraison et en nous protégeant des dérives de périmètre.
Notre première phase de travail a consisté à réaliser un audit complet de l'application Zeus afin d'en cartographier l'ensemble des règles de gestion indispensables. Sur le plan technique, l'ancienne infrastructure comprenait un client lourd Windows et une API connectée à une base de données dédiée.
Afin d'optimiser les délais de livraison, nous avons fait le choix stratégique de ne pas réécrire immédiatement la base de données sous-jacente. Nous avons conçu notre propre architecture d'API et notre interface frontend, mais notre backend fonctionne en mode proxy réseau, en interrogeant directement l'API historique de Zeus pour consommer et mettre à jour les données.
En complément de cette analyse technique, nous avons mené une immersion sur le terrain aux côtés d'un technicien afin d'auditer ses processus métiers réels. Cette phase d'observation a permis de lister les forces et les faiblesses ergonomiques de Zeus, isolant ainsi les fonctionnalités indispensables à conserver et les irritants majeurs à supprimer au sein de la nouvelle application.
L'analyse des flux de données de Zeus a révélé des formats d'objets complexes et limités, que nous souhaitions restructurer pour notre application. Nous avons donc mis au point un système de mapping de données pour convertir le formalisme rigide de l'ancienne API vers un modèle de données interne moderne, beaucoup plus agile à manipuler.
Pour le développement du backend en NodeJS, j'ai mis en place une architecture orientée fonctionnalités (feature-based). C'est une structure que je maîtrise parfaitement pour l'avoir éprouvée sur mes projets personnels FlorAccess et Econoris, garantissant une excellente modularité. Comme détaillé dans la documentation de FlorAccess, chaque module encapsule sa logique au travers de 7 couches de fichiers aux responsabilités strictes :
*.schema.ts : Centralise les schémas de validation Zod pour sécuriser les flux entrants et sortants.*.types.ts : Héberge les types TypeScript générés par inférence depuis Zod.*.swagger.ts : Expose la configuration OpenAPI pour l'interface de documentation interactive Swagger.*.routes.ts : Déclare les routes HTTP auprès d' Express et injecte les validateurs de requêtes sous forme de middlewares.*.controller.ts : Réceptionne les données validées et formate la réponse HTTP finale renvoyée au client.*.service.ts : Encapsule la pure logique métier et les règles de gestion calculées, indépendamment de la couche réseau.*.repository.ts : Gère l'accès aux données. Dans Genesis, le repository effectue des requêtes HTTP directes vers l'ancienne API de Zeus. À terme, cette couche permettra de migrer de manière transparente vers notre propre base de données PostgreSQL sans modifier la logique métier des services.Pour l'interface graphique, le choix s'est porté sur le framework open-source Flutter développé par Google. Ce choix répondait à une volonté d'homogénéité technique, Ocea exploitant déjà cette technologie. De plus, Flutter résolvait notre problématique de multi-déploiement en nous permettant de compiler une unique base de code vers Android, iOS et le Web, offrant ainsi une version accessible sur ordinateur pour les équipes de bureau.
Le processus créatif du frontend s'est orchestré par itérations successives, une démarche empirique menée en parallèle avec le développement de mon application de gestion budgétaire Econoris. L'absence de maîtrise initiale de Flutter par mon collègue et moi-même nous a imposé une phase de montée en compétences rapide. J'ai pu maximiser mes heures d'apprentissage personnelles pour assimiler en profondeur le framework.
Initialement, une première version de Genesis a été générée en s'appuyant sur des outils d'Intelligence Artificielle afin de délivrer rapidement un Proof of Concept (PoC) visuel à la direction. Cependant, nous nous sommes heurtés aux mêmes limites que j'avais identifiées sur la V2 d'Econoris : un code manquant de structure, instable et impossible à maintenir. Si cette dette technique était indolore sur un projet de petite taille, elle s'est avérée critique sur Genesis qui manipule des volumes de données industriels, générant des blocages de l'interface et des temps de latence réseau supérieurs à une minute.
Face à ce constat, nous avons optimisé notre organisation : mon collègue a stabilisé le PoC fonctionnel tandis que je passais une semaine à auditer les documentations officielles de Flutter et l'état de l'art architectural pour concevoir une structure de gestion d'état hautement performante. J'ai d'abord implémenté et validé cette architecture propre sur mon application Econoris, l'utilisant comme un laboratoire d'expérimentation isolé pour en éprouver les limites.
Une fois cette architecture validée en pratique, j'ai partagé ces connaissances avec mon collègue. Nous avons alors collaboré pour réécrire près de 75 % du frontend de Genesis. Ce travail d'équipe a permis de lier mes recherches théoriques à l'expérience en développement mobile de mon binôme. En trois semaines d'efforts, nous avons éliminé la totalité des bugs graphiques et divisé les temps de chargement par deux, les abaissant sous la barre des 30 secondes.
Pour parfaire l'application, nous avons réalisé une phase d'optimisation majeure concernant la gestion des rendus graphiques. Initialement, chaque composant de l'interface exécutait ses propres algorithmes de tri et de calcul de données lors des rafraîchissements de l'écran, ce qui surchargeait le thread d'affichage. Nous avons résolu ce problème en externalisant ces traitements dans des contrôleurs de calcul isolés, déclenchés uniquement lors de la réception de nouveaux flux réseaux. Les composants de l'interface se contentent désormais de consommer passivement ces données pré-calculées.
Cette optimisation de la gestion d'état a transformé l'expérience utilisateur : le temps de chargement initial de l'application est passé sous la barre des 10 secondes, et la latence d'ouverture des menus contextuels est tombée de 10 secondes à moins d'une seconde, offrant une réactivité immédiate.
Une fois l'application stabilisée et optimisée, nous avons initié la phase de mise en production multi-plateforme. Cela a impliqué la compilation des livrables natifs Android (Google Play Console) et iOS (Apple App Store Connect), ainsi que la conteneurisation de la déclinaison web via une image Docker, prête à être déployée sur l'infrastructure orchestrée par Kubernetes du groupe.
Genesis est exploitée en production depuis le mois de mars, et les retours de la part des techniciens de maintenance sont extrêmement positifs. L'adoption de l'outil a été telle que l'effet de bouche-à-oreille a poussé de nombreux opérateurs tiers à solliciter spontanément leur intégration au programme de déploiement pour abandonner l'ancien système Zeus.
Depuis le mois de juin, nous enrichissons la plateforme avec des fonctionnalités inédites, impossibles à concevoir sur l'ancienne architecture. S'agissant d'une application métier interne déployée sur des stores d'entreprise privés, le retour sur investissement ne se mesure pas en gains financiers directs, mais en efficacité opérationnelle et en confort de travail. Les techniciens manipulant l'application près de 4 heures par jour, le gain de temps obtenu représente une augmentation significative de la productivité globale.
Ce succès technique a consolidé la relation de confiance entre Ocea et Qowisio. Notre capacité à livrer un produit industriel fini, performant et dans les temps a convaincu le groupe de nous confier la refonte complète d'une seconde application majeure de leur parc réseau : Athéna, l'outil dédié à la configuration logicielle des passerelles.
La feuille de route à court terme de Genesis intègre le développement d'un algorithme d'analyse décisionnelle capable d'identifier et de planifier la suppression des passerelles redondantes. Si un ensemble de capteurs IoT est entièrement couvert par des boîtiers limitrophes, l'algorithme isolera la passerelle superflue pour permettre son retrait du parc. La logique mathématique lourde a déjà été intégrée et éprouvée sur notre API backend avec des données de production réelles. Il ne reste plus qu'à concevoir son interface de visualisation sous Flutter.
À plus long terme, le projet ambitionne d'intégrer un algorithme d'optimisation topologique et radio. L'objectif sera de simuler les déplacements idéaux des équipements afin de cartographier l'implantation théorique parfaite, permettant de couvrir l'intégralité d'un bâtiment avec un nombre minimal de passerelles. L'application ayant atteint ses objectifs de stabilité, ses évolutions futures dépendront exclusivement des retours d'usage des techniciens et des mutations du matériel IoT.
Une phase de retour d'expérience (Retrospective) menée avec mon maître d'apprentissage et mes collaborateurs a permis d'isoler nos axes d'amélioration pour nos futurs projets d'ingénierie.
Il en ressort d'abord que la génération intégrale d'une application d'envergure par Intelligence Artificielle (souvent perçue comme un levier de productivité à court terme) s'avère être une stratégie contre-productive sur le long terme en raison de la dette technique massive qu'elle engendre.
Sur le plan personnel, ma culture de la rigueur et mon exigence de qualité logicielle m'ont poussé à exiger un niveau de perfection architectural très élevé dès le lancement du projet, un positionnement qui a failli nous mettre en surrégime face aux délais imposés.
J'ai réalisé qu'il est souvent plus judicieux de privilégier une approche de type Minimum Viable Product (MVP) : livrer plus rapidement une première version au code propre mais au périmètre fonctionnel resserré. Cette stratégie permet de confronter l'application aux utilisateurs réels beaucoup plus tôt, afin de récolter des données d'usage concrètes et d'ajuster les développements futurs de manière itérative, plutôt que de retarder un déploiement pour atteindre une perfection théorique en isolation. Ce recul témoigne de ma maturité technique et de ma volonté d'allier excellence technique et agilité de livraison.