Données sur les voyageurs : la Place Beauvau accepte le « format EXCEL »

Données sur les voyageurs : la Place Beauvau accepte le « format EXCEL »

La formule Exc'ailes

Avatar de l'auteur
Xavier Berne

Publié dans

Droit

01/09/2014 3 minutes
30

Données sur les voyageurs : la Place Beauvau accepte le « format EXCEL »

D’ici au 1er janvier 2015, les compagnies aériennes pourront transmettre aux autorités, dans des « formats de message XML, CSV ou EXCEL », différentes données personnelles concernant leurs passagers. Un petit pas en faveur de l’interopérabilité, alors qu’une seule norme était jusqu’ici autorisée. 

En vertu de l’article L232-4 du Code de la sécurité intérieure, les compagnies aériennes sont aujourd’hui tenues de collecter puis de transmettre au ministère de l’Intérieur les données personnelles de leurs clients arrivant ou partant d’un pays qui n’appartient pas à l'Union européenne. Au nom de la lutte contre l’immigration clandestine, la prévention du terrorisme et des éventuelles atteintes aux « intérêts fondamentaux de la nation », les transporteurs doivent ainsi envoyer, dès la clôture d'un vol, une copie des informations issues de leurs systèmes de réservation et de contrôle des départs. Plus concrètement, sont concernées : la nationalité, le nom complet, la date de naissance, les heures de départ et d'arrivée, le point d’embarquement initial, etc. Et ce pour chaque passager.

 

Hier, la Place Beauvau a publié au Journal Officiel un décret venant modifier les conditions de transmission de ces précieuses données abreuvant le fichier SETRADER. Désormais, au lieu de transmettre ces données selon la norme EDIFACT/ONU/PAXLST, les compagnies pourront opter pour d’autres formats, en l’occurrence : « XML, CSV ou EXCEL » - dixit le nouvel article R. 232-1 du Code de la sécurité intérieure. Les transporteurs ont jusqu’au 1er janvier 2015 pour se préparer à ce changement et procéder aux éventuels modifications techniques qu’il pourrait occasionner.

 

Si l’exécutif dit vouloir faciliter « techniquement le respect des obligations mises à la charge des transporteurs aériens », certains n’auront pas manqué de remarquer que le format EXCEL n’existe pas à proprement parler... Les fichiers édités grâce au célèbre logiciel du même nom sont généralement des classeurs dont l'extension est en « .xls ». Quant aux deux autres formats, XML et CSV, ce sont deux standards qui ont l’avantage d’être ouverts.

 

Manifestement, cela faisait un sacré moment que le gouvernement envisageait de publier ce décret. L’avis de la Commission nationale de l’informatique et de libertés (CNIL) sur ce texte date en effet du 26 septembre 2013. L’institution ne tiquait guère sur le fameux « format EXCEL », mais appelait en revanche la Place Beauvau à la vigilance quant à la transmission des données du fichier SETRADER. Elle doit en effet se faire « par envoi électronique sécurisé », ce qui a poussé la CNIL à insister sur le fait que « la transmission d'un message par simple courriel n'assure pas la confidentialité des données qu'il contient ». Elle ajoutait : « Par la référence explicite à un envoi électronique sécurisé, la Commission considère que ces dispositions imposent que toutes les mesures nécessaires soient prises pour garantir la confidentialité et la fiabilité des données transmises ainsi que la disponibilité du canal de transmission. » Le décret paru hier ne contient toutefois aucune mention laissant à penser que cet avertissement a été suivi.

Écrit par Xavier Berne

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Commentaires (30)


Bientôt le format WINDOWS?


Ne vous inquiétez pas, tout est fait pour votre bien et vous protéger … comme disait le sage; du moment que vous n’avez rien à vous reprocher <img data-src=" />


De toute façon aucun des 3 formats ne veut dire quoi que ce soit en l’absence d’une spécification plus complète (j’imagine qu’elle existe).



Mais l’idéal reste quand même le XML avec un schéma associé. Après passer des autres formats à celui-ci n’est qu’une transformation basique, que le gouvernement la fasse ou que les compagnies la fasse a peu d’importance… sauf que là c’est nos finances publiques qui vont payer ces divers formats…








Bylon a écrit :



De toute façon aucun des 3 formats ne veut dire quoi que ce soit en l’absence d’une spécification plus complète (j’imagine qu’elle existe).



Mais l’idéal reste quand même le XML avec un schéma associé. Après passer des autres formats à celui-ci n’est qu’une transformation basique, que le gouvernement la fasse ou que les compagnies la fasse a peu d’importance… sauf que là c’est nos finances publiques qui vont payer ces divers formats…





De ce que j’ai compris, ce sont des données tabulaires. XML n’est pas vraiment le format le plus idéal, de par sa verbosité et sa structure en arbre.



[A supprimer… les balises xml ne passent pas !]








gokudomatic a écrit :



De ce que j’ai compris, ce sont des données tabulaires. XML n’est pas vraiment le format le plus idéal, de par sa verbosité et sa structure en arbre.



Pas grave, on sait pertinemment que les ministères utilisent un tableur classique (excel ou libre) pour le traitement des données. Ils ont donc tolérés les formats compatibles avec l’import.









Bylon a écrit :



[A supprimer… les balises xml ne passent pas !]







Sûrement dans la V6 <img data-src=" />



Je ne comprend pas le but de cet article ??? C’est pour dénoncé la possibilité d’envoyer dans un format créé par microsoft mais utilisable avec libreoffice/openoffice? ou juste à cause du “ format EXCEL” qui devrait s’appeler “je ne sais pas quoi c’est pas écrit dans l’article” ?


Ca aurait été trop simple avec de l’ .ods <img data-src=" />








Bylon a écrit :



De toute façon aucun des 3 formats ne veut dire quoi que ce soit en l’absence d’une spécification plus complète (j’imagine qu’elle existe).



Mais l’idéal reste quand même le XML avec un schéma associé. Après passer des autres formats à celui-ci n’est qu’une transformation basique, que le gouvernement la fasse ou que les compagnies la fasse a peu d’importance… sauf que là c’est nos finances publiques qui vont payer ces divers formats…







Le CSV semble approprié pour ça, données tabulaires etc. Une ptite moulinette et ça devrait passer tranquille.



Je connais pas trop le XML mais ça me parait un peu “lourd” pour ça.









Bylon a écrit :



De toute façon aucun des 3 formats ne veut dire quoi que ce soit en l’absence d’une spécification plus complète (j’imagine qu’elle existe).





Le CSV et le XML (le XLS je ne sais pas ^^’ ) veulent bien dire quelque chose même sans schéma. Ce dernier ne sert qu’à s’assurer que le récepteur comprend bien le message de la même manière, il n’est pas nécessaire.

Après, je suis d’accord que dans ce cas précis, ne pas fournir de schéma cible serait une mauvaise idée. Traiter 27 formes différentes de retour… vive les surcouts <img data-src=" />



Place Beauvau … Place Beauvau … c’est quoi ca deja ,hmmm

ah oui hadopi !

ah non je confonds ca c’est Rue du Pixel heu non du Teckel ou un truc comme ca.





Même si ca fait “chic” abusez pas des métonymies.

Si demain le ministère de l’intérieur déménage vous aurez l ‘air bien malin avec votre “Place Beauvau”.



“Ministère de l’intérieur” : cité 1 fois

“Place Beauvau” : cité 3 fois



Pour la clarté de l article ca devrait plutôt être l’inverse

surtout dans le titre


XML définit juste la grammaire.



Ton fichier peut tout à fait être “well formed” au sens XML sans pour autant être d’aucune utilité pour le transport aérien parce qu’il contiendra les information sur ton dernier virement SEPA qui est bel et bien du XML.



Ce sera donc bien “du XML” sans pour autant être utile.



C’est comme si tu disais : il faut me donner des informations en Français. Tu as juste défini une norme de langage, mais pas le fond des phrases. Je peux très bien te parler de la pluie et du beau temps en respectant la spécification “en français”, sans pour autant que cela te soit utile pour le transport aérien.



CSV c’est bien sûr encore pire… le pire de tous probablement parce qu’on ne transporte même pas la signification des colonnes, et en plus il n’y a aucune normalisation.



XL c’est aussi ridicule en plus d’être propriétaire, on tombe sur la même chose : j’envoie n’importe quelle tableur ?








V_E_B a écrit :



Le CSV et le XML (le XLS je ne sais pas ^^’ ) veulent bien dire quelque chose même sans schéma. Ce dernier ne sert qu’à s’assurer que le récepteur comprend bien le message de la même manière, il n’est pas nécessaire.

Après, je suis d’accord que dans ce cas précis, ne pas fournir de schéma cible serait une mauvaise idée. Traiter 27 formes différentes de retour… vive les surcouts <img data-src=" />







-1

Non ce sont juste des sérialisations, tu ne peux rien en faire sans plus de specs.







Bylon a écrit :



XML définit juste la grammaire.



Ton fichier peut tout à fait être “well formed” au sens XML sans pour autant être d’aucune utilité pour le transport aérien parce qu’il contiendra les information sur ton dernier virement SEPA qui est bel et bien du XML.



Ce sera donc bien “du XML” sans pour autant être utile.



C’est comme si tu disais : il faut me donner des informations en Français. Tu as juste défini une norme de langage, mais pas le fond des phrases. Je peux très bien te parler de la pluie et du beau temps en respectant la spécification “en français”, sans pour autant que cela te soit utile pour le transport aérien.



CSV c’est bien sûr encore pire… le pire de tous probablement parce qu’on ne transporte même pas la signification des colonnes, et en plus il n’y a aucune normalisation.



XL c’est aussi ridicule en plus d’être propriétaire, on tombe sur la même chose : j’envoie n’importe quelle tableur ?







+1



ça me rappelle un commit strip ça <img data-src=" />








Yangzebul a écrit :



-1

Non ce sont juste des sérialisations, tu ne peux rien en faire sans plus de specs.





Un XML n’a pas besoin de schéma pour être valide et traité. C’est juste plus compliqué sans.

La norme XML définit bien le XSD comme optionnel, bien que recommandé.









cyri11e a écrit :



“Ministère de l’intérieur” : cité 1 fois

“Place Beauvau” : cité 3 fois







C’est la métonymie habituelle.



Tu sais ce que sont les “sceaux” que garde le/la Garde des Sceaux ?



<img data-src=" />









V_E_B a écrit :



Le CSV et le XML (le XLS je ne sais pas ^^’ ) veulent bien dire quelque chose même sans schéma. Ce dernier ne sert qu’à s’assurer que le récepteur comprend bien le message de la même manière, il n’est pas nécessaire.

Après, je suis d’accord que dans ce cas précis, ne pas fournir de schéma cible serait une mauvaise idée. Traiter 27 formes différentes de retour… vive les surcouts <img data-src=" />





Pour en ajouter une couche (même si les précédentes me semblent très bien, mais j’ai envie de mettre la mienne aussi !), tu dis dans ton message que les fournisseurs utilisent un schéma. Eh oui, en parlant de “traiter 27 formes différentes de retour”, ça veut dire qu’il y a 27 schémas.



En terme de format, le seul crédible dans la liste resterait le XML, qui permet de ne pas être embêté avec des caractères spéciaux (marqueur de fin de champ…?), de transporter de l’Unicode sans problème (pratique pour les noms des voyageurs chinois ou arabes… à condition que l’infrastructure du ministère soit pensée pour les gérer, ce qui n’est pas certain <img data-src=" />). À noter tout de même : depuis Office 2007 le format par défaut d’Excel est un format XML (tout comme celui d’OpenOffice). Donc pour la difficulté de représenter des données tabulaires en XML, on repassera. Mais sans précision supplémentaire, “format Excel” ne veut effectivement pas dire grand chose, il faudrait au minimum préciser le niveau de compatibilité…









John Shaft a écrit :



C’est la métonymie habituelle.



Tu sais ce que sont les “sceaux” que garde le/la Garde des Sceaux ?



<img data-src=" />







Le sceau de la république qui permettent de sceller les lois constits :p







cyri11e a écrit :



Place Beauvau … Place Beauvau … c’est quoi ca deja ,hmmm

a

Même si ca fait “chic” abusez pas des métonymies.

Si demain le ministère de l’intérieur déménage vous aurez l ‘air bien malin avec votre “Place Beauvau”.







Mouais… ça doit bien faire 150 ans que c’est place beauvau et c’est dans tout les livres d’éducation civique <img data-src=" />









V_E_B a écrit :



Un XML n’a pas besoin de schéma pour être valide et traité. C’est juste plus compliqué sans.

La norme XML définit bien le XSD comme optionnel, bien que recommandé.







Ce qu’il veut dire, à juste titre, c’est que si chaque compagnie envoie son XML selon une structure différente, il est difficile de savoir à quoi correspond chaque balise.



C’est du même acabit que ne pas se mettre d’accord sur les en-têtes de colonnes pour un CSV.









V_E_B a écrit :



Un XML n’a pas besoin de schéma pour être valide et traité. C’est juste plus compliqué sans.

La norme XML définit bien le XSD comme optionnel, bien que recommandé.







Oui tu peux valider que les données sont correctement sérialisées.

Mais tu ne peux pas valider les données.



D’un point de vue transport : c’est un format de donnée

D’un point de vue applicatif : ce n’est pas à proprement parler un format, juste une sérialisation.









anagrys a écrit :



Pour en ajouter une couche (même si les précédentes me semblent très bien, mais j’ai envie de mettre la mienne aussi !), tu dis dans ton message que les fournisseurs utilisent un schéma. Eh oui, en parlant de “traiter 27 formes différentes de retour”, ça veut dire qu’il y a 27 schémas.





Là j’utilise un langage (le français, modulo les fautes :P ). Pourtant je n’ai pas définit le langage utilisé. Plus tard je pourrais parler anglais plutôt que français. Si quelqu’un s’attend à du français, il ne comprendra pas, quand bien même c’est un message valide.

De même, on peut extraire un schéma de tout fichier XML, mais si il n’est pas explicité ça n’apporte aucune information de traitement. Si une entreprise utilise 27 formats différents, même si ils peuvent êtres validés via un schéma, si le schéma n’est pas fixé et transmis à l’organisme récepteur, il n’y a pas fonctionnellement de schéma. Basiquement : “je respecte des règles, mais je suis le seul à les connaître !”.







supercolino a écrit :



Ce qu’il veut dire, à juste titre, c’est que si chaque compagnie envoie son XML selon une structure différente, il est difficile de savoir à quoi correspond chaque balise.



C’est du même acabit que ne pas se mettre d’accord sur les en-têtes de colonnes pour un CSV.





Oui et non. Comme il l’a été fait remarqué, le XML est une sérialisation de données. Son schéma est censé respecter celui de la source. Si on connait le format de la source, on peut se passer de XSD. Ça rend de plus le traitement moins sensible aux évolution des données sources.

Maintenant, je trouve ça aussi plus propre et sûr de transmettre un schéma explicite (je disais dans mon commentaire initial que ne pas le faire serais une mauvaise idée <img data-src=" /> ).







Yangzebul a écrit :



Oui tu peux valider que les données sont correctement sérialisées.

Mais tu ne peux pas valider les données.



D’un point de vue transport : c’est un format de donnée

D’un point de vue applicatif : ce n’est pas à proprement parler un format, juste une sérialisation.





Valider les données n’est pas le rôle du XML, même si il en est capable. Se baser sur le seul XSD pour s’assurer de l’intégrité des données est très risqué.



Après, mon commentaire initial voulais simplement rappeler que l’absence de schéma n’est pas invalide en soit. Pas “bien” ni “pratique”, mais valide (j’ai dû travailler avec du XML sans schéma, ça se fait. C’est relou, mais ça se fait). Simple détail technique sans importance vis-à-vis de la news <img data-src=" />









tifounon a écrit :



Le CSV semble approprié pour ça, données tabulaires etc. Une ptite moulinette et ça devrait passer tranquille.

Je connais pas trop le XML mais ça me parait un peu “lourd” pour ça.









Bylon a écrit :



CSV c’est bien sûr encore pire… le pire de tous probablement parce qu’on ne transporte même pas la signification des colonnes, et en plus il n’y a aucune normalisation.









anagrys a écrit :



En terme de format, le seul crédible dans la liste resterait le XML, qui permet de ne pas être embêté avec des caractères spéciaux (marqueur de fin de champ…?), de transporter de l’Unicode sans problème (pratique pour les noms des voyageurs chinois ou arabes… à condition que l’infrastructure du ministère soit pensée pour les gérer, ce qui n’est pas certain <img data-src=" />).





J’ai tendance à penser que le XML est un peu lourd aussi, même s’il permet de passer tous les caractères en effet.

Un CSV avec de l’Unicode dedans (pour certains noms étrangers), si on définit les colonnes à avoir, c’est propre en fait. Dans certains fichiers CSV on a la première ligne qui définit les noms des colonnes, c’est une spec “dynamique”.

On pourrait aussi imaginer ce qui devient à la mode et est plus léger à traiter pour un humain comme par un ordinateur, le JSON.







kaskounet a écrit :



ça me rappelle un commit strip ça <img data-src=" />





<img data-src=" /> et <img data-src=" /> à la fois, j’ai presque déjà vu ça.



Ah, c’est pas passé LibreOffice à la Place Beauvau ?



<img data-src=" />



<img data-src=" />








Ricard a écrit :



Ca aurait été trop simple avec de l’ .ods le format LibreOffice <img data-src=" />







Quitte à mal nommer les formats, autant aller jusqu’au bout <img data-src=" />









pruv3750 a écrit :



Je ne comprend pas le but de cet article ??? C’est pour dénoncé la possibilité d’envoyer dans un format créé par microsoft mais utilisable avec libreoffice/openoffice? ou juste à cause du “ format EXCEL” qui devrait s’appeler “je ne sais pas quoi c’est pas écrit dans l’article” ?







+1. Sérieusement, employer “au format ” pour parler du format du dit logiciel, ca choque?

Ben dites donc, vous n’êtes pas sortit de l’auberge <img data-src=" />



Selon vous, comment faudrait l’il appeler le format des fichiers XLS?

Je vous le demande <img data-src=" />



En plus, que l’on ne dise pas que c’est un article pour dénoncer l’emprise de MS, car le même article évoque XML et CSV



Je suis décontenancé là. Cet article brasse un peut du vent.

Je l’aurais vu en brève <img data-src=" />



ODS et XLSX sont tous deux des formats XML compressés.

De là à ne pas citer clairement un format libre tout en citant un logiciel propriétaire inutile, ça me fait penser à ces gens incapables d’utiliser les termes de “traitement de texte”, “tableur” ou “logiciel de présentation” dans la vie courante…

Par paresse ou par stupidité, le français adore la boue.








Jarodd a écrit :



Quitte à mal nommer les formats, autant aller jusqu’au bout <img data-src=" />





Cépafo.<img data-src=" />









RaoulC a écrit :



Selon vous, comment faudrait l’il appeler le format des fichiers XLS?

Je vous le demande <img data-src=" />







  • Classeur Excel (*.xlsx)

  • Classeur Excel binaire (*.xlsb)

  • Classeur Excel 97-2003 (*.xls)

  • Feuille de calcul XML 2003 (*.xml)



    Ce ne sont que quelques exemples parmi la liste proposé par Excel 2010.

    Le premier correspond à priori au format ISO/IEC DIS 29500 Office Open XML proposé par MS depuis Office 2007.

    Du coup, une petit précision suffirait à être parfaitement explicite sur le format attendu (même si j’ai une préférence pour Open Document Format ISO 26300).









papinse a écrit :





  • Classeur Excel (*.xlsx)

  • Classeur Excel binaire (*.xlsb)

  • Classeur Excel 97-2003 (*.xls)

  • Feuille de calcul XML 2003 (*.xml)



    Ce ne sont que quelques exemples parmi la liste proposé par Excel 2010.

    Le premier correspond à priori au format ISO/IEC DIS 29500 Office Open XML proposé par MS depuis Office 2007.

    Du coup, une petit précision suffirait à être parfaitement explicite sur le format attendu (même si j’ai une préférence pour Open Document Format ISO 26300).





    Vu comme cela , d’accord.

    Reste que tu t’adresses aux gens, “format excel” ca veut dire xls dans dison l’immense majorité des cas…et pour longtemps encore <img data-src=" />



    Si tout ces gens pouvaient au minimum faire du xlsx….<img data-src=" />