Quinze modules, tous développés. Les équipements de cour sont testés sans matériel réel. Ce qui manque figure sous Technique, pas ici.
Les contrôles s'effectuent dans cet ordre. Le premier contrôle qui échoue fournit le texte affiché au transporteur. Une liste vide génère un appel, un motif conduit à réserver un autre créneau.
Répond à une seule question : quels créneaux ce transporteur peut-il réserver ce jour-là ? Le type de véhicule, la zone de température et les matières dangereuses déterminent le quai admissible.
Réservation et annulation : sur le portail, dans le formulaire et via l'interface. Chaque rendez-vous ajoute une ligne à l'historique. Pour éviter les doubles réservations, le contrôle s'exécute dans la même transaction que la création.
L'accès dédié aux tiers, séparé des interfaces internes. Inscription autonome, validation par la planification, vue d'ensemble de leurs réservations.
Enregistrement par immatriculation. Suivi unidirectionnel : enregistré, dans la cour, appelé, à quai, terminé, sorti.
La vue du jour pour la planification. Indicateurs clés, ruban d'occupation par quai avec une ligne indiquant l'heure actuelle, véhicules sur le site et leur statut.
Une page pour le smartphone du chauffeur, accessible via un lien dans le SMS. Ni compte ni mot de passe. Conçue comme Progressive Web App, elle fonctionne même sans réseau.
Envoi de SMS pour cinq événements clés. Création et envoi sont découplés afin qu'aucun message ne soit perdu en cas d'indisponibilité de la passerelle.
Un service dédié cadencé à 15 minutes. Clôture les non-présentations et prépare les rappels 24 heures avant le créneau.
Quais, transporteurs, flotte, horaires d'ouverture. La désignation du quai dans l'interface se règle par site dans les données de base : quai, porte ou rampe.
Quatre vues, toutes calculées à partir des réservations et des horodatages des rendez-vous dans la cour. Export au format CSV, préparé pour Excel configuré en allemand.
Documents liés au dossier, dix types. Le point d'entrée est le dossier, pas le fichier. Pièces requises définies par type, les manquantes sont signalées.
REST avec description lisible par machine. Un refus n'est pas une erreur, mais une réponse réussie et motivée. L'import d'ordres est répétable. Chaque système connecté reçoit sa propre clé : la lecture suffit pour la synchronisation, réserver ou annuler requiert un droit explicite.
Le lecteur de plaques, la barrière, le panneau d'affichage, le pont-bascule et la borne se connectent via une interface dédiée. Le lecteur indique ce qu'il lit et reçoit une décision motivée : autoriser l'entrée, faire patienter ou refuser. Sans réservation, la barrière reste fermée. L'interface n'a pas encore été testée avec du matériel physique.
Couleurs, polices et logo réunis dans une charte graphique ; la grille reste distincte, sans aucune couleur codée en dur. Un nouveau client reçoit sa charte, sans créer une seconde interface.
Le portail, la connexion, la page chauffeur et les SMS gèrent onze langues, du polonais au suédois. Ce choix reflète le transport longue distance vers l'Allemagne ; le français et le suédois se sont ajoutés avec les premiers pays cibles. Sur le portail, l'utilisateur choisit via un sélecteur dans l'en-tête ; pour le chauffeur, la langue dépend du rendez-vous : le transporteur la définit lors de la réservation. Les interfaces internes sont disponibles en allemand, anglais, français et suédois.
Toutes sont calculées à partir des réservations et des horodatages des rendez-vous dans la cour. Aucun tableau agrégé parallèle ne risque de diverger de sa source.
Nous présentons le fonctionnement sur notre environnement de test, avec vos quais, vos horaires et vos contraintes, ainsi que l'avancement, la feuille de route et l'offre pilote.