Conditions d'entrée à l'étranger pour les salariés en mission : ce qu'un check manuel ne voit pas

Un salarié part en mission mardi. Son passeport expire dans cinq mois. Le vol fait escale à Singapour. Personne dans l'équipe mobilité n'a vérifié si ces trois faits, mis ensemble, posent un problème — et c'est exactement le genre de combinaison qu'un contrôle fait à la main ne remonte pas.

Ce qu'est une condition d'entrée

Une « condition d'entrée » n'est pas une seule règle, ce sont plusieurs règles indépendantes qui s'appliquent en même temps à un même déplacement :

• Le régime de visa : le salarié peut-il entrer sans visa, avec un visa à l'arrivée, un e-visa, une autorisation électronique de voyage (ETA), ou a-t-il besoin d'un visa complet demandé à l'avance ? Et pour combien de jours ce régime l'autorise-t-il à rester ?
• La validité du passeport : beaucoup de pays n'appliquent pas la règle « valide à la date d'entrée » mais une marge — souvent trois ou six mois de validité restante au-delà du séjour prévu. Un passeport valide pour le voyage peut être refusé à l'embarquement pour cette seule raison.
• La règle de transit : une escale, même sans sortir de la zone internationale, peut exiger un visa de transit selon l'aéroport et la nationalité — une règle distincte de la condition d'entrée du pays de destination final.

Ce sont trois questions différentes, avec trois sources différentes, et une mission peut échouer sur n'importe laquelle des trois sans que les deux autres posent problème.

Pourquoi la vérification manuelle ne tient pas à l'échelle

Vérifier une mission à la main — consulter le site du ministère des Affaires étrangères, celui de l'ambassade, un forum de voyageurs — fonctionne pour un départ isolé. Cela cesse de fonctionner dès que l'un de ces facteurs entre en jeu :

• Le volume. Dix salariés qui partent dans le mois, ce sont potentiellement dix couples passeport/destination différents, chacun avec sa propre règle de validité de passeport, son propre régime de visa, sa propre règle de transit si l'itinéraire comporte une escale.
• La diversité des nationalités. Une équipe mobilité qui gère des expatriés, des sous-traitants ou des équipages de nationalités différentes doit refaire la vérification pour chaque nationalité et chaque destination — la règle qui s'applique à un passeport français n'est pas celle qui s'applique à un passeport marocain pour la même destination.
• Le changement de la règle elle-même. Une condition d'entrée n'est pas figée : elle peut changer entre le moment où la mission est planifiée et le moment où le salarié embarque. Une vérification faite trois semaines avant le départ ne garantit rien à la date du départ.
• L'angle mort du contrôle « pays par pays ». Un salarié qui enchaîne plusieurs séjours dans le même pays sur une période courte peut dépasser un quota de jours cumulés que personne n'a calculé parce que chaque étape, prise séparément, semblait conforme.

Un contrôle manuel qui fonctionne pour un départ ne se répète pas fidèlement pour cinquante, et une règle vérifiée une fois n'est pas une règle vérifiée à la date du vol.

Ce qu'il faut vérifier, par passeport et par destination

Pour une mission donnée, la liste minimale à vérifier est :

1. Le régime de visa pour ce couple passeport/destination (visa-free, e-visa, visa à l'arrivée, ETA, ou visa requis).
2. Le nombre de jours de séjour autorisé sous ce régime.
3. La validité de passeport minimale exigée à l'entrée (en mois), rapprochée de la date d'expiration réelle du document.
4. La règle de transit pour chaque escale de l'itinéraire, distincte de la destination finale.
5. Les documents à produire (billet retour, preuve de fonds, formulaire d'entrée) et, le cas échéant, les vaccinations exigées.

C'est un travail répétitif, structuré, qui porte sur des données qui changent — exactement le type de tâche qu'une vérification humaine fait mal à volume constant, et qu'une source de données structurée peut répondre de façon identique à chaque appel.

Ce que répond l'API Visa d'Orizn

L'API Visa d'Orizn expose ces informations par requête, pour un couple passeport/destination donné. Un appel GET sur l'endpoint principal :

GET https://visa.orizn.app/api/v1/visa?passport=FRA&destination=JPN&lang=fr
x-api-key: VOTRE_CLE

Pour un passeport français vers le Japon, la réponse (documentée dans la référence API) renvoie notamment :

{
  "data": {
    "passport": "FRA",
    "destination": "JPN",
    "requirement": "visa_free",
    "visa_free_days": 90,
    "visa_required": false,
    "description": "French citizens can enter Japan visa-free for up to 90 days.",
    "documents_required": ["Valid passport (3 months)", "Return or onward ticket"],
    "passport_validity_months": 3,
    "transit_visa": {
      "hubs": [{ "airport": "NRT", "city": "Tokyo", "transit_visa_required": false, "transit_free_hours": 24 }]
    },
    "overstay_penalty": { "fine_per_day": "Variable + deportation", "ban_days": 365, "criminal": true },
    "embassy": {
      "your_embassy_at_destination": { "name": "Ambassade de France au Japon", "city": "Tokyo" }
    }
  },
  "meta": { "lang": "fr", "api_version": "1.1", "coverage": "199 passeports x 250 destinations" }
}

En un seul appel : le régime de visa, la durée de séjour autorisée, la validité de passeport exigée, la règle de transit pour le hub concerné, la pénalité en cas de dépassement, et l'ambassade à contacter sur place. Chaque champ non pertinent pour une paire donnée revient null, vide, ou absent — la documentation le précise explicitement : il faut se fier à la forme de la réponse, pas supposer qu'un champ est toujours renseigné.

Ce que l'API ne couvre pas, et le dit. Selon la documentation, une règle de transit n'existe que pour 44 des 250 destinations couvertes, et même là elle est enregistrée par pays traversé et non par nationalité — elle ne dit donc jamais explicitement si ce passeport a besoin d'un visa de transit à cette escale ; la documentation recommande de confirmer avec la compagnie aérienne dans tous les cas. Par ailleurs, seuls 56 des 199 pays de passeport ont aujourd'hui une source officielle citée (source_url et last_verified_at renseignés) ; pour les autres, ces deux champs sont null et la donnée vient du jeu de données consolidé sans citation — un null ne veut pas dire que la réponse est fausse, mais elle n'est pas sourcée, et toute réponse qui informe une décision opérationnelle devrait être traitée en conséquence.

Pour une mission avec plusieurs étapes ou plusieurs séjours dans le même pays, l'endpoint POST /api/v1/visa/decision prend l'itinéraire complet — passeport, étapes datées, transits, date d'expiration du passeport — et renvoie un verdict par étape, y compris les jours cumulés sur des séjours répétés dans un même pays et la validité du passeport rapprochée de chaque date d'arrivée. Le verdict est no_blocker_found ou blocked ; la documentation précise que cela signifie que les vérifications possibles n'ont rien trouvé, pas que le déplacement est garanti conforme.

Accès et volumes

L'API est accessible par la clé transmise dans l'en-tête x-api-key. Selon la documentation tarifaire :

• Évaluation (gratuit) : 100 requêtes par mois, usage non commercial, sans SLA.
• Commercial : 49 $/mois pour 30 000 requêtes, droits d'usage commercial, les 15 langues, champs étendus.
• Production : 199 $/mois pour 250 000 requêtes, SLA de disponibilité, contact nommé, support sous un jour ouvré.

Au-delà du quota mensuel, l'API renvoie un code HTTP 429 avec un en-tête X-RateLimit-Reset indiquant la date de réinitialisation. Seuls les cinq endpoints de données (/visa, /visa/check, /visa/bulk, /visa/group, /visa/decision) sont décomptés du quota.

Ce que ça change concrètement

Une équipe qui gère une dizaine de départs par mois sur une poignée de destinations reste dans le tarif gratuit. Une équipe qui gère plusieurs centaines de couples passeport/destination par mois — multi-nationalités, multi-destinations, avec des escales à vérifier systématiquement — dépasse rapidement les 100 requêtes gratuites et se situe dans la fourchette Commercial ou Production selon le volume.

Ce que l'API remplace, ce n'est pas le jugement de l'équipe mobilité sur un dossier complexe — la documentation elle-même est explicite sur ses angles morts (transit non garanti par nationalité, résidence non modélisée, pays en zone légale incertaine signalés par un champ requirement_status: "uncertain" dédié). Ce qu'elle remplace, c'est la vérification répétitive d'un fait vérifiable — régime de visa, jours autorisés, validité de passeport minimale — pour chaque salarié, chaque destination, à la date du départ plutôt qu'à la date où quelqu'un a eu le temps de regarder.

---

Note : ce texte a été rédigé par l'équipe growth d'Orizn à partir de la documentation technique publique de l'API Visa. Il ne constitue pas un conseil juridique et n'engage aucun collaborateur nommément.