Un passeport n’est pas une pièce jointe ordinaire. Il rassemble identité, nationalité, numéro, date de naissance, photographie et signature dans un fichier facile à recopier et difficile à rappeler. Notre architecture part donc d’un principe simple : ne pas collecter ce qui n’est pas encore nécessaire.
Deux étapes, deux niveaux de données
La première étape identifie le parcours avec des données non identifiantes : pays du passeport, résidence, motif, dates, entrées, voyageurs, transport et hébergement. Ces informations restent dans le navigateur pour produire le résultat du calculateur.
La seconde étape n’existe que pour une prestation clairement définie. Une invitation ou une revue complète peut nécessiter les données exactes du passeport. Avant leur collecte, le client doit connaître l’opérateur, le but, la durée de conservation, le destinataire éventuel et la méthode de suppression.
Frontière technique du formulaire
Le calculateur public travaille dans le navigateur sans transmettre d’identité. Une demande de devis non sensible peut rejoindre la boîte professionnelle ou le webhook prévu. Un dossier touristique ou e‑visa complet n’est accepté qu’après confirmation d’une admission HTTPS privée authentifiée : l’e-mail ordinaire et le résumé à copier vers un chat sont interdits pour ce contenu. Si le canal privé est indisponible, la demande est refusée.
Le formulaire recueille uniquement les données biographiques saisies nécessaires à la prestation choisie. Il n’accepte ni scan, ni fichier, ni données de carte. Le paiement s’effectue sur la page hébergée du prestataire nommé, après confirmation du montant et de la devise. Pour l’e‑visa, le voyageur garde le compte officiel, le mot de passe, les codes temporaires et l’envoi final sous son contrôle.
Contrôles de production
Le déploiement doit maintenir :
- chiffrement du transport sur l’ensemble du domaine ;
- stockage privé et chiffré lorsque des fichiers sont nécessaires ;
- accès limité aux personnes qui traitent réellement la commande ;
- authentification forte des comptes administratifs ;
- journalisation des accès sensibles sans exposer les documents dans les logs ;
- suppression selon la durée annoncée dans la politique de confidentialité ;
- sauvegardes chiffrées et cycle de suppression cohérent ;
- prestataire de paiement hébergé, sans conservation des données de carte par le site ;
- procédure de réponse et de notification en cas d’incident.
Ces contrôles doivent être vérifiés sur l’environnement réellement publié. Un cadenas décoratif ou la présence d’un formulaire ne constitue pas une preuve de sécurité.
Ce qu’un client peut faire
Vérifiez le domaine caractère par caractère. N’envoyez jamais un mot de passe, un code à usage unique, un numéro complet de carte ou un code PIN. Méfiez-vous d’un interlocuteur qui déplace immédiatement l’échange vers un compte personnel de messagerie et demande toutes les pages du passeport sans devis défini.
Lorsque seule une erreur de nom doit être démontrée, un extrait limité peut parfois suffire. Lorsque le document complet est réellement nécessaire, ne le découpez pas au point de rendre le service impossible : utilisez le canal convenu et demandez la durée de conservation.
Signaler un incident
Un message de sécurité doit décrire le domaine ou l’adresse concernée, l’heure, le comportement observé et un moyen de réponse. Ne joignez pas davantage de données sensibles pour prouver qu’elles sont déjà exposées.
Une sécurité sérieuse ne promet pas l’impossibilité de tout incident. Elle réduit la surface, détecte vite, limite l’accès et dit clairement ce qui arrive ensuite.