Des voyages qui suivent le cycle de vie de vos collaborateurs.
Provisionnement automatique SCIM depuis votre IdP. SSO avec Okta, Azure AD, Google Workspace. Des accès basés sur les rôles qui reflètent votre organigramme. Un offboarding maîtrisé qui révoque l'accès à la plateforme et récupère les soldes de crédits. Un onboarding voyage qui se compte en minutes, pas en semaines.
L'onboarding voyage ne devrait pas ralentir votre pipeline de recrutement.
La plupart des plateformes de voyage d'entreprise exigent encore un onboarding manuel. Les RH ajoutent le nouvel embauché au SIRH. Le travel manager crée son profil dans la plateforme de voyage. La finance lui attribue une carte. Trois systèmes, trois formulaires, trois validations. Les nouvelles recrues attendent 5 à 10 jours avant de pouvoir réserver un déplacement, bien après leur premier jour.
L'offboarding est pire encore. Quand un collaborateur part, qui récupère ses crédits de vol inutilisés ? Qui supprime ses accès ? Qui annule les réservations en cours ? La plupart des entreprises n'ont aucun processus défini. Les crédits restent inutilisés et expirent. Les collaborateurs sortants conservent leur accès à la plateforme pendant des semaines.
Travel Code gère le provisionnement et le déprovisionnement via SCIM 2.0 avec votre IdP. Un nouvel embauché apparaît dans votre SIRH : son accès voyage est prêt en quelques secondes, pas en quelques jours. Un collaborateur sortant : crédits récupérés, accès révoqués, réservations en cours signalées pour vérification. Les opérations voyage suivent les opérations RH, automatiquement.
Délai typique d'onboarding voyage entre la date d'arrivée du collaborateur et sa première réservation sur les plateformes traditionnelles.
Valeur moyenne des crédits de vol inutilisés à l'offboarding lorsque la récupération n'est pas automatisée.
Durée moyenne de conservation de l'accès à la plateforme par les collaborateurs sortants sans SCIM.
Des voyages à l'image de votre organisation.
Provisioning auto SCIM 2.0.
Synchronisation SCIM 2.0 en temps réel avec Okta, Azure AD, Google Workspace, JumpCloud, OneLogin et tout endpoint SCIM standard. Les nouveaux utilisateurs sont provisionnés automatiquement avec mappage des rôles. L'appartenance aux groupes détermine l'attribution des politiques. Latence moyenne de provisionnement : 3,6 s au p95.
SSO avec votre IdP.
SAML 2.0 et OIDC pris en charge. Authentification unique depuis votre IdP, avec la même expérience de connexion que le reste de votre environnement. Politiques d'accès conditionnel (MFA, appareil, réseau) appliquées au niveau de l'IdP. Aucun mot de passe Travel Code distinct à gérer ou à oublier pour vos utilisateurs.
Contrôle d'accès par rôle.
Cinq niveaux de rôles par défaut (Voyageur / Manager / Admin / Finance / Propriétaire) et des rôles personnalisés. Associez automatiquement les groupes IdP → rôle + politique + codification comptable. Changements de service, promotions, mutations : tout est pris en compte. Aucune mise à jour manuelle des rôles.
Un offboarding maîtrisé.
Le flux d'offboarding s'exécute automatiquement dès que l'IdP marque l'utilisateur comme inactif : accès à la plateforme révoqué, réservations en cours signalées au manager, notes de frais finalisées automatiquement, soldes de crédits récupérés et réaffectés à l'entreprise. Journal d'audit conservé selon votre politique de rétention.
Du premier au dernier jour, sans intervention des RH.
Quand un nouveau collaborateur arrive, son accès voyage est prêt avant son premier stand-up. Quand quelqu'un change de poste, la politique suit. Quand il part, l'accès se ferme et les crédits reviennent. Le tout depuis votre IdP, sans aucune étape manuelle.
Activé en un instant.
Le SIRH ajoute le nouvel embauché → l'IdP propage → l'événement SCIM déclenche le provisionnement dans Travel Code. Profil créé avec rôle, service, manager et codification comptable hérités des attributs de l'IdP.
Rôles ajustés aux promotions.
Lorsqu'un collaborateur change de rôle ou de service, l'appartenance aux groupes de l'IdP est mise à jour → la politique Travel Code l'est en quelques secondes. Nouvel approbateur attribué. Nouveaux seuils hors politique appliqués. Aucune reconfiguration manuelle.
Accès révoqués, crédits récupérés.
L'IdP marque l'utilisateur comme inactif → Travel Code : révoque l'accès à la plateforme, signale les réservations en cours pour vérification par le manager, finalise les notes de frais en attente, récupère les crédits de vol inutilisés.
Piste d'audit conservée.
Le journal d'audit est conservé selon votre politique de conservation des données (par défaut : 7 ans). Configurable par région pour répondre au RGPD ou aux exigences de conformité sectorielles. Historique complet des événements exportable par utilisateur, par réservation et par transaction.
Questions fréquentes des RH et des Ops.
Quels IdP sont gérés ?
Connecteurs SCIM 2.0 natifs pour Okta, Azure AD (Microsoft Entra ID), Google Workspace, JumpCloud et OneLogin. Point de terminaison SCIM 2.0 générique disponible pour les IdP personnalisés. SAML 2.0 et OIDC pris en charge pour le SSO. Configuration généralement en 30 à 60 minutes avec votre équipe IT.
Comment fonctionne l'association des rôles entre les groupes de l'IdP et Travel Code ?
Vous associez les groupes de votre IdP aux rôles et politiques de Travel Code dans les paramètres d'administration. Cas d'usage courants : groupes par service → attribution de la politique ; groupes par ancienneté → seuil de frais hors politique ; attributs de centre de coûts → codification comptable. Les associations peuvent être modifiées sans aucun développement.
Que deviennent les réservations en cours lorsqu'un collaborateur quitte l'entreprise ?
Les réservations dont le départ a lieu dans moins de 30 jours sont signalées au manager, avec trois options : annuler et rembourser, transférer à un autre collaborateur (lorsque les règles du transporteur le permettent) ou convertir en avoir. Les réservations au-delà de 30 jours suivent la politique définie par l'entreprise. Le journal d'audit enregistre chaque décision prise.
Comment les avoirs sont-ils récupérés lors d'un départ ?
Les avoirs de vol inutilisés au nom du collaborateur sortant sont signalés. Lorsque les règles du transporteur autorisent le transfert (la plupart des compagnies aériennes intérieures américaines, certains tarifs Lufthansa), les avoirs sont réattribués au pool de l'entreprise. Lorsque le transfert n'est pas autorisé, les avoirs sont suivis et utilisés pour la prochaine réservation au nom du même collaborateur, dans la limite de leur période de validité.
Découvrez le provisioning piloté par votre IdP.
Démo de 30 min avec votre équipe IT : venez avec votre IdP et nous configurerons SCIM en direct pendant l'appel.