Bilan des projets développés
et note de passation technique

Contexte

XFood répond à un besoin concret des restaurants et résidences hôtelières partenaires : remplacer la prise de commande papier et les allers-retours entre salle, cuisine et caisse par un flux numérique unique, consultable en temps réel par chaque poste. Le client final scanne un QR code sur sa table (ou dans sa villa), commande depuis son téléphone sans rien installer, et l'établissement suit la commande de bout en bout depuis un panneau d'administration unique. La même base de code sert aussi bien un restaurant qu'une résidence avec hébergement, ce qui explique la présence des deux univers — restauration et hôtellerie — dans un seul produit.

Acteurs et rôles

Sept profils utilisent le système, un côté client et six côté personnel de l'établissement — chacun avec un écran taillé pour son poste plutôt qu'un panneau générique unique :

Architecture

L'application est structurée en trois zones : un panneau d'administration (admin/) en PHP procédural où chaque rôle du personnel (serveur, cuisine, caissier, réceptionniste, admin) a son propre écran ; une API REST (api/, une vingtaine de points d'entrée JSON) qui sert de pont entre la base de données et le reste ; et une interface client (user/) en HTML/CSS/JS pur, installable comme une application (PWA), avec un Service Worker qui met en cache les pages statiques mais exclut volontairement toutes les routes d'API pour ne jamais servir de données périmées hors ligne. La synchronisation entre la cuisine, la salle et la caisse se fait par Server-Sent Events — un flux serveur→navigateur qui pousse les nouvelles commandes en direct, avec un système de sondage (polling) en secours si la connexion se coupe.

Chaque déploiement client est une copie de cette même base, avec sa propre base de données et ses propres réglages (menu, tarifs, villas le cas échéant). Il n'y a pas aujourd'hui de mécanisme central qui propage un correctif à tous les clients à la fois — une évolution du cœur de produit demande de la répercuter manuellement sur chaque déploiement, un point important pour la suite (voir plus bas).

Fonctionnalités livrées

Déploiement et accompagnement client

Au-delà du code, ce projet a représenté une part importante de travail terrain : installation et configuration chez chaque client (écrans, QR codes, accès réseau), formation des équipes (serveurs, cuisine, caisse, réception), assistance en cas d'incident de connexion, et suivi de campagnes ponctuelles — par exemple le suivi des scans QR pour Dolce Vita. Le produit est aujourd'hui déployé et actif chez :

Contexte

MediNova est une plateforme de gestion médicale complète, née comme projet de fin d'études puis reprise et développée comme solution XNOVA à part entière, déployée en production. L'objectif est de donner à un centre médical un outil unique qui couvre tout le parcours de soin — de la prise de rendez-vous jusqu'au compte-rendu de consultation — pour tous les métiers présents dans une clinique : patients, médecins, personnel d'accueil, centre d'appels et administration. Chaque catégorie d'utilisateur a son propre espace, avec ses propres écrans et ses propres droits.

Acteurs et rôles

Le système distingue nettement qui peut faire quoi. Sept profils sont définis en base de données, dont deux niveaux d'administration :

Architecture

L'application est un back-end PHP natif (aucun framework, une seule dépendance externe : la librairie minishlink/web-push pour les notifications) qui expose 36 points d'API JSON, consommés par les cinq portails ci-dessus. Chacun est une PWA installable, avec son propre écran de connexion. La base de données centralise aussi les réglages d'identité visuelle (app_settings) : nom de l'application, logo, couleur principale — modifiables depuis l'espace super-administrateur sans toucher au code, et appliqués côté client via un composant JS qui remplace les textes au chargement de chaque page.

Deux intégrations tierces étendent l'application au-delà du web classique : Vapi, un service d'assistant vocal IA, permet à un patient de prendre ou annuler un rendez-vous en parlant simplement à voix haute ; Twilio gère un serveur vocal interactif (IVR) pour la prise de rendez-vous par téléphone classique, pour les patients sans smartphone. Ces deux services sont appelés depuis des points d'API dédiés (api/vapi/, api/twilio_*) plutôt qu'intégrés au cœur de l'application, ce qui limite l'impact si l'un des deux services tiers change ou doit être remplacé.

Fonctionnalités livrées

Le module Urgences mérite une explication à part : il a été conçu spécifiquement parce que le fonctionnement normal de MediNova repose sur un rendez-vous planifié à l'avance, ce qui n'a pas de sens pour un patient qui arrive sans prévenir. Le service dispose donc de son propre circuit — admission express par la réception (avec prise en charge des cas anonymes ou non identifiés grâce à des champs facultatifs et un calcul automatique d'âge approximatif), file d'attente triée par gravité clinique plutôt que par ordre d'arrivée, et un tableau dédié pour le médecin de garde qui n'a pas besoin d'un planning horaire pour être considéré disponible : être connecté suffit.

Comptes de démonstration

Chaque acteur dispose d'un compte de test dédié pour accéder directement à son espace.

Contexte

InterUrbain vise à digitaliser la réservation de trajets en bus entre villes, sur le modèle d'une place de marché : un voyageur compare et réserve un trajet auprès de la compagnie de son choix, chaque compagnie de transport gère ses propres lignes et gares depuis son espace, et la plateforme XNOVA supervise l'ensemble (compagnies, trajets, réservations). C'est le projet le plus large en diversité technique de la mission : il réunit une API back-end, une application mobile grand public, et deux interfaces web de gestion distinctes, développées en autonomie sur les quatre dépôts.

Acteurs et rôles

Trois acteurs se partagent la plateforme, chacun avec sa propre application dédiée — c'est la raison pour laquelle le projet compte quatre dépôts distincts plutôt qu'une seule application avec des permissions internes :

Architecture

Le back-end est une API Spring Boot classique en couches (entités, dépôts, services, contrôleurs), avec une authentification par jeton JWT qui distingue les trois rôles ci-dessus. Le modèle de données couvre les compagnies, les trajets, les gares, les réservations, les paiements, les avis et le programme de fidélité. L'API est documentée via Swagger, ce qui permet à n'importe quel front (mobile ou web) de découvrir les points d'entrée disponibles sans lire le code source du back-end. Les trois applications front — mobile voyageur, dashboard transporteur, dashboard admin — consomment cette même API, chacune filtrée selon son rôle.

Fonctionnalités livrées

Contexte

XGescom (nom de code interne : SYGESCO) répond à un besoin de PME et TPE organisées en réseau d'agences : suivre les ventes, le stock et la caisse de chaque agence individuellement, tout en donnant à l'entreprise mère une vue consolidée sur l'ensemble de son réseau. C'est une base de code existante qui a été reprise, sécurisée et modernisée durant la mission — le travail a porté autant sur l'ajout de fonctionnalités que sur la remise à niveau de la sécurité et de l'interface.

Acteurs et rôles

L'application repose sur une hiérarchie claire, chaque acteur ayant son propre espace de connexion et son propre périmètre de données — un Admin Agence ne voit jamais les chiffres d'une autre agence, et un Admin Entreprise ne voit que les agences qui lui appartiennent. Le Super Administrateur représente l'éditeur de la solution ; l'Admin Entreprise représente la direction générale du client ; l'Admin Agence est le responsable opérationnel du point de vente. Trois métiers viennent ensuite compléter l'équipe d'agence avec des accès spécifiques à leur activité : Commercial, Gestionnaire de stock et Comptable/Financier.

Architecture

L'application n'utilise pas de framework MVC : c'est une architecture « par page », où chaque fichier PHP gère sa propre session, sa configuration et sa vue, et où les formulaires soumettent leurs données en AJAX vers des scripts de traitement dédiés (traitements/*.php) qui renvoient un simple indicateur succès/échec. La base de données compte une trentaine de tables, migrées durant la mission du moteur MyISAM vers InnoDB pour de meilleures garanties d'intégrité.

Fonctionnalités livrées

Audit et sécurisation

Un audit de sécurité complet a été mené et corrigé de bout en bout, validé par des requêtes HTTP réelles sur les trois espaces : migration de l'authentification SHA1 vers bcrypt avec rehachage transparent à la connexion, protection CSRF sur tous les formulaires, passage à 100% en requêtes préparées PDO contre les injections SQL, échappement systématique des sorties contre les failles XSS, et validation réelle du type de fichier à l'upload (pas seulement l'extension). Un bug critique a été identifié et corrigé pendant cette phase : le fichier de configuration ne démarrait jamais la session PHP, ce qui rendait toutes les vérifications CSRF du projet silencieusement inopérantes sans qu'aucune erreur ne soit visible.

Environnement de démonstration

La plateforme est accessible en ligne à sygesco.xnova-ci.com, avec un jeu de données réaliste (75 ventes, 35 bons de livraison, 18 devis, 20 produits, 12 clients grands comptes) permettant de tester chaque profil dans des conditions proches de l'exploitation réelle. Chaque acteur dispose de son propre compte de test :

Contexte

XCRM Terrain digitalise le travail des commerciaux qui visitent des prospects sur le terrain. Avant l'outil, une visite se traduisait par des notes éparses difficiles à centraliser et à transformer en devis, puis en facture. L'objectif du produit est de faire tenir tout le cycle de vente — de la première visite jusqu'au paiement — dans un seul outil, accessible depuis un téléphone en visite comme depuis un poste au bureau.

Acteurs et rôles

Trois profils cloisonnés se partagent l'application, avec une étanchéité stricte des données entre commerciaux :

Architecture

Contrairement à XGescom, ce projet est construit en MVC classique — contrôleurs, modèles et vues nettement séparés, avec des migrations de schéma automatiques gérées dans Database.php.

Le cœur du produit est un enchaînement métier explicite, pensé pour refléter le déroulement réel d'une vente : le commercial remplit une fiche terrain après une visite ; s'il y a un rendez-vous, il le qualifie ensuite (effectué, reporté, gagné, perdu) et peut demander un devis en un clic — ce qui déclenche une alerte visuelle immédiate côté admin ; l'admin rédige le devis, le prospect l'accepte, et une facture peut alors être émise directement à partir du devis accepté. Si le commercial marque le rendez-vous « Gagné », le devis correspondant passe automatiquement à l'état « Accepté » — une automatisation qui évite une étape de ressaisie manuelle.

Fonctionnalités livrées

Comptes de démonstration