Publier sa carte d'embarquement coûte un compte : ce que nos mesures disent du masquage de QR code
Ce qu'un simple talon de billet livre
Commençons par un cas documenté, pas par une hypothèse.
Le journaliste spécialisé Brian Krebs l'a raconté en 2015. Un lecteur nommé Cory a vu la carte d'embarquement d'un ami publiée sur Facebook, en a fait une capture, agrandi le code-barres, puis l'a passé dans un décodeur en ligne gratuit. Quelques secondes plus tard, il détenait les données du compte de fidélité de son ami.
La suite est le vrai sujet. Cory pouvait consulter tous les vols futurs de ce compte, modifier les sièges de passagers déjà enregistrés et annuler n'importe quel vol à venir. Les informations exposées suffisaient en outre à franchir la première moitié de la procédure de réinitialisation du code PIN de la compagnie.
L'ami avait simplement publié une photo de voyage.
Un point échappe à presque tout le monde : les codes-barres et QR codes ne sont pas décoratifs, ce sont des conteneurs de données lisibles par machine. Vous voyez des carrés noirs et blancs ; un scanner voit une référence de réservation, un nom, un vol, une date, un siège. Cet écart constitue tout le risque.
Masquer à moitié ne fonctionne pas — et j'ai mesuré à quel point
C'est la section que je tenais le plus à écrire, car une mauvaise méthode est plus dangereuse que l'absence de méthode : vous vous croyez protégé et vous publiez quand même.
Les QR codes intègrent par conception une correction d'erreur considérable. La spécification permet à un scanner de reconstruire la charge utile complète même lorsqu'une part significative du symbole est endommagée, salie ou occultée. Dans le monde physique, c'est utile : un billet plié ou une impression baveuse restent lisibles. Appliqué au raisonnement « je couvre la moitié, ça ira », cela devient une faille.
J'ai donc mesuré.
Quelle surface faut-il réellement couvrir ?
La méthode est reproductible. Avec la bibliothèque Python qrcode, j'ai produit un QR code de bon fictif — la charge utile est une URL d'échange contenant une référence de réservation et un code de validation — dans les niveaux de correction M (15 %), Q (25 %) et H (30 %). Chacun a subi quatre méthodes de masquage sur sept proportions de surface, puis un décodage via le QRCodeDetector d'OpenCV. Seule la restitution complète de l'URL d'origine comptait comme « encore lisible ».
Le résultat est pire que ce que j'anticipais.
| Méthode de masquage | Échec à partir de (M, 15 %) | Échec à partir de (Q, 25 %) | Échec à partir de (H, 30 %) |
|---|---|---|---|
| Aplat opaque, centré | 15 % de la surface | 20 % de la surface | 25 % de la surface |
| Aplat opaque, coin inférieur droit | 20 % de la surface | 25 % de la surface | 25 % de la surface |
| Barre horizontale | 10 % de la surface | 20 % de la surface | 20 % de la surface |
| Pixellisation, centrée | 15 % de la surface | 20 % de la surface | 25 % de la surface |
À lire ainsi : ce pourcentage marque le début de l'échec de décodage. En dessous, tout reste lisible.
Trois constats méritent d'être retenus.
Premièrement, un billet à correction élevée reste lisible avec un cinquième de sa surface couvert. En niveau H avec 20 % masqué, l'aplat centré, l'aplat d'angle et la pixellisation ont tous restitué la charge utile. Ce rectangle d'apparence conséquente que vous avez tracé sur le code n'a rien bloqué.
Deuxièmement, la pixellisation s'est comportée exactement comme un aplat opaque — seuils d'échec identiques sur les trois niveaux. Cela invalide l'intuition selon laquelle le flou vaudrait mieux que rien. Ce n'est pas plus sûr, cela donne seulement l'impression d'avoir agi.
Troisièmement, la barre horizontale s'est révélée la plus efficace des quatre. En niveau M, une barre couvrant 10 % de la hauteur suffisait. Une barre traverse toute la largeur du symbole, si bien que les dégâts se répartissent sur plusieurs blocs de mots de code, alors qu'un carré compact tombe précisément là où la correction d'erreur est la plus robuste.
Franchement, ce troisième constat contredit la conclusion que je m'apprêtais à écrire. Les alertes affirmant que « barrer un billet ne l'annule pas » sont exactes — elles parlent de validité et de lisibilité. Mais si la question devient « quelle façon de barrer arrête le mieux un scanner », ces données répondent que la barre bat l'aplat. On ne l'apprend qu'en mesurant.
L'endroit compte plus que la quantité
Le résultat le plus utile est venu en dernier.
Les trois grands carrés situés dans les angles d'un QR code sont les motifs de repérage : le scanner s'en sert pour établir l'orientation et les limites. J'ai couvert celui en haut à gauche, et les trois niveaux de correction ont échoué au décodage — alors que cette zone n'occupe que 2,0 à 3,6 % de la surface totale.
Autrement dit : couvrir 2 % au bon endroit vaut mieux que couvrir 20 % au mauvais.
Les limites du test font partie du résultat. J'ai utilisé le décodeur d'OpenCV, une charge utile unique et une seule version de QR code. Les scanners commerciaux et les appareils photo de téléphone implémentent la reconstruction différemment et peuvent se montrer plus performants. Traitez ces seuils comme un plancher, pas une garantie : le décodeur d'un attaquant réel est probablement plus tolérant que mon environnement de test.
En pratique, une seule règle : couvrez tout le symbole d'un aplat opaque débordant les bords. Pas un coin, pas quelques traits, pas une pixellisation. Si votre outil ne le permet pas, assurez-vous au minimum qu'un des trois motifs de repérage soit entièrement recouvert.
Mal couvert équivaut à non couvert.
Trois niveaux d'exposition dans les captures de voyage
Les captures de voyage se répartissent en trois niveaux aux profils de risque réellement distincts.
| Niveau | Source typique | Ce qui fuit | Pire scénario |
|---|---|---|---|
| 1 : titre scannable | Bons GetYourGuide/Klook, billets de spectacle, cartes d'embarquement | Le titre lui-même, le PNR, des pistes vers le compte fidélité | Billet utilisé par un tiers, prise de contrôle du compte |
| 2 : identifiants textuels | Confirmations Booking.com/Agoda, références, numéro de chambre | Nom, dates de séjour, adresse de l'établissement | Appels frauduleux à l'établissement, ingénierie sociale |
| 3 : données embarquées | Écran photographié avec un second appareil | GPS des EXIF, heure de prise de vue, appareil | Déduction de votre position ou de votre domicile |
Le niveau un est le plus urgent. La valeur d'un bon électronique réside dans le code lui-même ; s'il est scanné avant vous, vous le découvrez à l'entrée. Des cas documentés montrent des malfaiteurs récupérant des billets publiés, les modifiant et escroquant des acheteurs — la victime n'est alors pas seulement l'auteur de la publication.
Le niveau deux paraît anodin et alimente l'ingénierie sociale. Nom, dates et établissement suffisent pour se présenter à la réception à votre place, ou inversement pour vous appeler au nom de l'établissement afin de « reconfirmer votre carte ». Ce type de fraude grimpe en haute saison.
Le niveau trois passe le plus souvent inaperçu. Une capture d'écran de téléphone ne contient normalement pas de GPS, mais photographier un écran avec un second appareil inscrit dans l'image l'endroit où vous vous trouviez. C'est plus fréquent qu'on ne le croit quand on transmet un écran d'ordinateur.
Quand vos compagnons ont vraiment besoin des détails
C'est la contrainte réelle : organiser un voyage impose de partager. Heures de rendez-vous, contenu des billets, adresse de l'hôtel.
Par ordre de préférence :
D'abord la fonction de partage native de la plateforme. GetYourGuide, Klook, Booking.com et la plupart des autres permettent de partager ou transférer une réservation à un compagnon de voyage. Par la voie officielle, la validité reste sous contrôle de la plateforme et aucune capture ne se met à circuler.
Deuxième choix : envoyer du texte, pas une image. « 26/09, 9 h, entrée principale, j'ai les billets » transporte tout le nécessaire pour un risque nul.
Troisième choix : une image avec contrôle d'accès. Pour du contenu réellement visuel — un tableau d'itinéraire complexe, une carte — passez par un support à accès contrôlé plutôt qu'une publication ouverte.
Chez lpic.cc, vous pouvez définir un mot de passe de consultation à l'envoi : le lien court résiste alors aux transferts. Les mots de passe sont stockés hachés en bcrypt, pas comparés en clair. Pour un itinéraire destiné à « ces cinq personnes seulement », c'est nettement plus maîtrisé que de le laisser circuler dans une conversation de groupe.
Les limites d'emblée : images plafonnées à 8 Mo, fichiers conservés 30 jours après la dernière consultation, envois automatiquement optimisés donc originaux non conservés. Et surtout — un mot de passe arrête ceux qui ne doivent pas voir, pas une personne autorisée qui fait une capture et la transfère. Tout mécanisme de partage bute sur ce plafond. Ne le prenez pas pour absolu.
La dernière ligne de défense reste la même : un titre réellement sensible ne devrait jamais devenir un fichier image.
Questions fréquentes
Q1 : J'ai publié une carte d'embarquement il y a longtemps. Supprimer sert-il encore ?
Supprimer limite l'exposition future mais ne prouve pas que personne ne l'a capturée. Deux actions comptent davantage : changer immédiatement le mot de passe et les questions de sécurité du compte de la compagnie, et vérifier que les réservations à venir n'ont pas été modifiées. Dans le cas Krebs, l'attaquant pouvait d'abord changer les sièges et annuler des vols.
Q2 : Quelqu'un a scanné mon bon Klook. Puis-je quand même entrer ?
Cela dépend du type de billet. Un bon à usage unique déjà utilisé s'affiche comme tel à l'entrée. Contactez immédiatement le support de la plateforme, sachant que l'issue n'est pas garantie et que les délais s'allongent en haute saison. La prévention l'emporte largement sur la réparation dans ce domaine.
Q3 : Pixelliser le QR code suffit-il ?
Non, et je l'ai mesuré. Sur les trois niveaux de correction, pixellisation et aplat opaque présentaient des seuils d'échec identiques : un billet en niveau élevé exigeait 25 % de surface couverte avant de cesser d'être lisible. Utilisez un aplat opaque sur toute la zone du code, ou mieux, bloquez-le physiquement avant la prise de vue.
Q4 : Ma confirmation ne montre qu'une référence et un nom. Risqué quand même ?
Oui. Nom et référence suffisent à interroger l'état d'une réservation sur certaines plateformes, et les dates de séjour complètent la panoplie d'ingénierie sociale. Le schéma récurrent des cas réels : l'attaquant n'a jamais besoin de votre mot de passe, seulement d'assez de fragments pour convaincre un conseiller.
Q5 : Et les photos de voyage elles-mêmes ?
Risque de nature différente. Là, l'enjeu principal reste le GPS des EXIF. La plupart des réseaux sociaux les suppriment à l'envoi, mais les espaces cloud et l'envoi « en fichier original » les conservent généralement intacts. Le comportement de chaque service figure dans notre test EXIF champ par champ sur 8 hébergeurs.