Mon expérience chez Nexence

« Si on ne sort pas Club Med, on coule. »

Avant Nexence : Poser les bases solides

Avant de rejoindre Nexence, j’ai consacré plusieurs semaines à renforcer mes compétences en développement Front-end.

Animé par l’envie de progresser, j’ai étudié en profondeur la documentation officielle de Vue.js 2, Vuex et Vue Router, et réalisé plusieurs projets expérimentaux pour mettre en pratique mes connaissances.

Cette période intense d’apprentissage m’a permis de consolider mes bases techniques et de cultiver la rigueur nécessaire pour relever mon premier grand défi professionnel.

👉 Pour en savoir plus sur mon parcours initial, c’est par ici : Découvrir mon profil complet

Une entreprise en pleine transformation… et une confiance totale dès le premier jour

J’ai intégré Nexence à un moment clé de son histoire. En pleine mutation, l’entreprise passait de la conception d’événements à celle d’expériences digitales sur mesure, à travers des casiers intelligents et des bornes interactives. Un virage stratégique audacieux, sans retour en arrière.

J’ai été recruté comme développeur Front-end en plein cœur de cette transition.

Dès mes premiers jours, la confiance que m’ont accordée les fondateurs a été totale. Je me souviens encore très bien de Vincent, l’un des deux dirigeants, me disant :

"Si on ne sort pas le projet Club Med, on coule."

Pas de pression, hein ?

Mais loin de m’effrayer, cette phrase m’a motivé. On ne m’avait pas engagé pour exécuter. On m’avait recruté pour construire. J’avais carte blanche pour apprendre vite, faire les bons choix, prendre mes responsabilités. Et je me suis donné à fond pour être à la hauteur de cette confiance.

Mon premier défi ? Justement : le projet Club Med. Une borne tactile interactive installée dans les resorts, permettant aux voyageurs de découvrir les lieux, réserver des activités ou des restaurants via leur bracelet RFID.

🎯 Un projet complexe, visible, stratégique… et mon tout premier projet avec de l’IoT.

Le choix des casiers connectés et l’itération comme moteur

Très vite, il est devenu clair que les casiers connectés n’étaient pas un simple produit ponctuel, mais un véritable axe stratégique pour Nexence. Ce choix technique et commercial s’est accompagné d’une philosophie que j’ai adorée : l’amélioration continue par l’itération.

Chaque projet que nous livrions — pour un centre commercial, une entreprise ou une marque — devenait la base du suivant. Nous apprenions de nos erreurs, identifions les points faibles, et améliorions l’architecture, l’interface ou les fonctionnalités. On ne repartait jamais de zéro.

Très vite, on est passé du copier-coller à la création d’un submodule pour centraliser les briques communes : gestion des connexions, manager de modales, navigation, règles d’authentification... Ce sous-ensemble devenait notre fondation technique.

Et au fil des projets, on a raffiné notre approche : adoption de l’Atomic Design, migration vers Vue 3, meilleure séparation des responsabilités, traduction multilingue avec i18n, et respect strict des guidelines Vue.js et javaScript. À chaque nouvelle interface, on gagnait en robustesse et en vitesse de développement.

🔁 À chaque déploiement, une occasion de mieux faire : plus propre, plus rapide, plus robuste.

Le SaaS en marque blanche — une synthèse de toutes nos itérations

Après plusieurs projets, une évidence s’est imposée : il nous fallait un outil unique, capable de centraliser et d’unifier tous les parcours clients. C’est ainsi qu’est née notre application SaaS en marque blanche, conçue pour intégrer tous les cas d’usage de manière modulaire.

Ce SaaS a été un tournant technique et organisationnel. On y a concentré toutes nos meilleures pratiques : composants dynamiques, configuration dynamique appliquée côté client, injection de contenus (textes, images, couleurs, règles) à l’initialisation, gestion multilingue, et intégration complète de WebSocket pour remonter les actions physiques en temps réel.

Le système permettait à chaque casier de se réinitialiser chaque matin à 4h, récupérer le flow du client, les contenus à jour, et appliquer les mises à jour sans rupture de service. Un vrai produit stable, robuste et scalable.

Pour moi, ce SaaS a été le point culminant de mon passage chez Nexence. Il condensait tout ce que j’avais appris : organisation du code, vision produit, transmission aux alternants, documentation… et surtout : Qune vraie fierté de voir un produit complet et vivant, toujours en production aujourd’hui.

🧩 Un projet-pivot, pensé pour durer, où chaque décision technique avait du sens.

Des cas clients concrets et parlants

Travailler chez Nexence, c’était aussi plonger dans des cas d’usage très concrets, avec de vrais enjeux de terrain. Chaque client venait avec ses propres besoins, contraintes, contextes d’utilisation. Et c’était à nous d’y répondre, parfois dans l’urgence, souvent avec beaucoup d’adaptation.

Pour Club Med, nous avons développé une borne tactile interactive installée dans les resorts. Grâce à un bracelet RFID, les vacanciers pouvaient se connecter, explorer une carte interactive du resort, réserver des restaurants ou des activités. Le tout, sans login ni clavier. Tout passait par le scan et des visuels immersifs.

Avec Westfield, nous avons installé des casiers en libre-service avec TPE intégré. Particularité : chaque soir, à la fermeture des boutiques, les casiers non vidés s’ouvraient automatiquement pour permettre aux agents de sécurité de vider le contenu et le placer en objets trouvés. En pleine période Covid, nous avons aussi ajouté un module de Click & Collect dans des délais très serrés.

Pour une grande maison de maroquinerie de luxe, nous avons conçu une gestion de vestiaires connectés pour les salariés d’usine. Chaque employé avec son badge, se connecter, et un casier attribué selon son contrat. Les casiers des personnes en fin de contrat étaient automatiquement désactivés après 17h. Et il fallait aussi gérer des règles spécifiques pour les PMR, avec priorité d’attribution et fallback intelligent.

Ces projets nous ont poussés à repousser les limites de notre architecture, à affiner notre logique métier, et surtout à garder toujours en tête l’usage réel des utilisateurs finaux.

🧠 Une diversité de clients, une seule exigence : l’excellence du service terrain.

La fin d’un cycle, et la fierté du chemin parcouru

Au bout de deux ans et demi chez Nexence, quelque chose en moi a commencé à changer. Le SaaS fonctionnait. Il était stable, déployé, utilisé. Les projets se ressemblaient de plus en plus. Les alternants étaient devenus autonomes. Et moi, je commençais à tourner en rond.

J’avais appris énormément — en technique, en rigueur, en coordination, en écoute aussi. Mais j’avais cette petite voix qui me disait :

“Si tu restes maintenant, tu risques de stagner.”

Alors j’ai pris une décision difficile mais nécessaire : partir. Non pas parce que je n’aimais plus ce que je faisais. Mais parce que je sentais que je ne progressais plus. Et ça, pour moi, c’est le signal d’alarme.

Je suis parti avec le sentiment du devoir accompli. J’ai laissé derrière moi une base de code robuste, des outils structurés, des collègues en confiance. Et surtout :

Des casiers, des bornes, des applications qui tournent encore aujourd’hui, dans des lieux publics ou privés, avec du code que j’ai écrit, testé, peaufiné. Et ça, franchement, c’est une vraie fierté.

🙌 Un cycle accompli, une trace durable, et l’envie de continuer à apprendre ailleurs.

Environnement technique

Frameworks & langages : Vue.js 2 & 3, JavaScript ES6, Composition API, Vuex, Pinia
Architecture & composants : SaaS embarqué, submodules, flows dynamiques, i18n multilingue
Temps réel & matériel : WebSocket, QR code, RFID, TPE (Ingenico)
Qualité & tests : Mocha, Chai, revues de PR
Outils & CI/CD : Docker, Webpack, VSCode
Communication & pilotage : Slack, livraisons en cycles courts

🛠️ Une stack front pensée pour durer, embarquée dans du matériel industriel.

L'équipe projet

👤 1 Lead développeur Front-end (moi)
🎓 2 alternants Front-end
🛠️ 1 Lead développeur Back-end
💾 1 Développeur Back-end
📋 1 cheffe de projet

👥 Une équipe réduite mais soudée, capable de livrer des produits complexes dans des délais serrés.

Après Nexence : viser plus loin, viser plus grand

Nexence m'avait donné des bases solides : rigueur, modularité, exigence du terrain.

Mais je ne voulais pas m'arrêter là. J’avais besoin de repousser mes limites, d'explorer d'autres univers, d'affiner mon impact.

👉 Avec CheckMyGuest, j’ai plongé dans la refonte d'un ERP complexe, orchestré plusieurs projets en parallèle, et structuré un écosystème produit de A à Z.

👉 Avec Prométhée Earth Intelligence, j’ai découvert l’univers fascinant de la donnée spatiale et des enjeux stratégiques globaux, en renforçant encore mes compétences en Front avancé et en expérience utilisateur.

Deux aventures très différentes. Un même objectif : construire du solide, utile, durable — et continuer à grandir.

Liens utiles

Questions fréquentes

Quel a été ton plus gros défi technique ou organisationnel chez Nexence ?

Je dirais sans hésiter : la standardisation d’un système… non-standard. Chez Nexence, chaque client avait des attentes très spécifiques : un branding personnalisé, des règles de connexion différentes, des flux utilisateur sur mesure. Et pourtant, il fallait que notre produit reste maintenable, scalable, et surtout unifié dans sa logique.

Le vrai défi, c’était donc de transformer une suite de projets one-shot en une architecture commune et configurable. J’ai travaillé à créer une base de code modulable, où chaque projet ne nécessitait qu’un fichier de configuration (textes, images, règles, langues, etc.) sans impacter les autres. Le tout, en conservant une UX fluide et une cohérence technique sur l’ensemble.

On a notamment conçu un SaaS en marque blanche capable de gérer dynamiquement ces flux et contenus depuis une requête d’initialisation. Le backend nous renvoyait la configuration complète, que le Front injectait à la volée. Ce système permettait de mettre à jour les bornes chaque matin, sans rupture de service, et sans réécriture de code.

C’était un vrai casse-tête, mais aussi un plaisir intellectuel : comment concevoir une structure générique qui n’écrase pas la richesse métier des projets ? Pour moi, c’est ce que j’ai préféré : transformer du spécifique en générique, sans jamais perdre la finesse des besoins réels. C’est aussi ce que je referais avec plaisir sur d’autres projets.

Comment gérais-tu la maintenance et les mises à jour des bornes sur le terrain ?

Chez Nexence, la maintenance ne reposait pas sur des interventions manuelles, mais sur un système de mise à jour automatique, pensé dès l’architecture. Chaque borne et chaque casier se réinitialisait chaque jour à 4h du matin. À ce moment-là, une requête d’initialisation était envoyée pour charger les dernières configurations à jour.

Cette requête récupérait plusieurs éléments clés : le flow utilisateur (conciergerie, vestiaire, click & collect…), les textes, images, couleurs spécifiques au branding du client, et les règles d’authentification (QR code, RFID, email, mobile). Tout était pensé pour être injecté dynamiquement dans le Front.

Le vrai atout, c’est que si l’on corrigeait un bug ou ajoutait une fonctionnalité, il suffisait que la nouvelle version soit prête côté serveur. À la prochaine initialisation, la borne récupérait automatiquement cette nouvelle version, sans aucune intervention humaine ni redéploiement manuel. Résultat : un parc de bornes toujours à jour, même en conditions dégradées.

Ce système nous a permis de maintenir la qualité de service sans multiplier les opérations de support, tout en gardant une logique 100 % customisable pour chaque client.

Comment gérais-tu la qualité du code, notamment celui des alternants ?

J’ai très vite compris qu’il fallait poser un cadre clair si on voulait que la base de code reste saine et évolutive, même avec des profils juniors. Alors j’ai défini quelques règles simples mais efficaces : pas de fonctions de plus de 50 lignes, pas de composants de plus de 400 lignes, un nommage explicite (verbe pour les fonctions, nom clair pour les variables), et une logique stricte de séparation des responsabilités.

Tout ce qui pouvait être réutilisé devenait un composant à part entière ou une fonction partagée dans notre submodule ou une mixin. J’encourageais systématiquement les alternants à factoriser leur code et à penser en composants dès le début.

En parallèle, je faisais beaucoup de pair programming avec eux, surtout sur les premières semaines. On analysait leur logique ensemble, on comparait plusieurs approches possibles, et on écrivait à deux pour prendre de meilleures habitudes.

Après chaque fonctionnalité, on prenait un moment pour faire un débrief : ce qui avait bien marché, ce qui aurait pu être mieux structuré, et pourquoi. C’était une approche très terrain, très pragmatique. Le but n’était pas de faire du “code parfait”, mais du code compréhensible, stable, maintenable. Et sur la durée, cette exigence collective a beaucoup fait progresser l’équipe.

Tu parles d’un SaaS embarqué, tu peux détailler ?

Bien sûr. L’idée du SaaS embarqué, c’était de permettre à une même base applicative de s’adapter dynamiquement aux besoins spécifiques de chaque client, sans avoir à maintenir une version différente pour chacun. Le cœur de cette approche : une requête d’initialisation déclenchée chaque jour à l’allumage de la borne.

Lors de cette requête, la borne s’identifie et reçoit un JSON complet contenant : le flow utilisateur à charger (conciergerie, vestiaire, click & collect…), les règles d’authentification à appliquer (QR code, RFID, email…), ainsi que l’ensemble des éléments visuels personnalisés du client (textes, images, couleurs de marque, etc).

Le Front, conçu pour être modulaire, injectait cette configuration à la volée et adaptait automatiquement l’interface et le comportement de l’application. Une seule base de code, mais un rendu sur mesure pour chaque client — du branding à la logique métier.

Ce fonctionnement permettait à la fois de garantir une grande flexibilité pour les clients, tout en assurant une maintenance simplifiée pour notre équipe. C’était le meilleur des deux mondes : personnalisation sans duplication.

Comment avez-vous géré les cas d’erreurs ou de fonctionnement hors-ligne ?

C’était un point critique, surtout dans des environnements comme les centres commerciaux ou les usines, où la connexion réseau n’est pas toujours fiable. Les casiers et bornes devaient impérativement rester fonctionnels même en cas de coupure internet.

Pour ça, on a mis en place un système de cache local intelligent. À chaque initialisation, la borne téléchargeait et stockait en local un ensemble de données minimales : textes clés, visuels de secours, branding épuré, configuration essentielle. Ce qui permettait à l’interface de rester utilisable, même sans connexion.

En parallèle, un système de WebSocket restait à l’écoute des actions utilisateur (fermeture de porte, scan QR/RFID, paiements…). Et à chaque redémarrage, un check hardware complet était effectué pour s’assurer que tous les composants du casier étaient bien opérationnels (lecteur, moteur, TPE, etc).

En cas de défaillance matérielle ou logicielle, un message utilisateur clair s’affichait pour éviter toute frustration, et une alerte technique automatisée était envoyée à notre Back-office pour prise en charge rapide. Cette combinaison nous a permis d’assurer un très haut niveau de disponibilité, même dans des contextes contraints.

Comment as-tu aidé les alternants à monter en compétence ?

Dès mon arrivée, j’ai mis en place une approche basée sur le pair programming intensif. Plutôt que de leur montrer comment faire, je les faisais coder eux-mêmes. Je posais des questions, les guidais étape par étape, et les amenais à formuler leurs propres solutions. L’objectif n’était pas qu’ils recopient mon code, mais qu’ils comprennent les choix techniques et les enjeux fonctionnels derrière chaque ligne.

Après chaque tâche, on prenait un moment pour faire un débrief constructif : ce qui avait bien fonctionné, ce qui pouvait être amélioré, les éventuelles pistes à creuser pour la suite. Ce feedback régulier a permis d’installer une vraie dynamique d’apprentissage.

J’ai aussi lancé des “mini challenges” techniques pour les pousser à explorer certaines notions par eux-mêmes. Par exemple : comparer Vuex et Pinia, utiliser Composition API, intégrer un WebSocket sans aide… Ces petits défis leur ont permis de gagner en autonomie tout en se confrontant à des problématiques concrètes.

Résultat : au bout de quelques mois, chaque alternant était capable de prendre en charge un projet de A à Z, du flowchart initial à l’intégration finale.

Quel impact ce poste a-t-il eu sur ta façon de coder aujourd’hui ?

Ce poste a complètement transformé ma manière de penser le code. Avant, je développais des interfaces Front-end pour un besoin ponctuel, dans un cadre précis. Chez Nexence, j’ai appris à raisonner autrement : chaque fonctionnalité devait pouvoir être réutilisée, configurée, maintenue dans le temps. C’était une école de la modularité et de l’anticipation.

J’ai pris l’habitude de me poser des questions à chaque ligne de code : est-ce que ce composant pourra être réutilisé ailleurs ? Est-ce qu’il est suffisamment découplé ? Est-ce que je le rends trop rigide ou au contraire trop générique ? Cette rigueur m’a beaucoup aidé à structurer mon code et à concevoir des architectures Front plus propres et évolutives.

J’ai aussi beaucoup gagné en compréhension des autres métiers. J’ai appris à collaborer avec les Back-end, à prendre en compte les contraintes d’ops, à mieux documenter mon travail pour que les autres puissent s’y retrouver. Au final, c’est un poste qui m’a rendu plus technique, mais aussi plus collaboratif et plus pragmatique.