Journal EBCDIC n'est pas compatible avec la RGPD

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
42
25
oct.
2021

Le 9 octobre 2019, la court d'appel de Bruxelles a maintenu la décision de la Chambre Contentieuse du 15 mai de la même année qui indique que la banque de Mr André Dupont se doit d'épeler son nom correctement, y compris la casse et l'accent. L'argument de la banque en appel étant que leur système informatique date de 1995, utilise EBCDIC sur AS/400 et n'est pas capable de représenter les caractères accentués ou minuscules. La court d'appel ne considère pas qu'utiliser un système obsolète soit une excuse suffisante pour refuser à ses clients d'exercer leur droit de rectification de leur données personnelles (article 16 de la RGPD).

Le jugement de la court d'appel.
Un résumé sur gdprhub.
Un article de blog sur le sujet.

  • # droit de rectification de leur données personnelles

    Posté par  . Évalué à 10.

    utf-8

  • # Pendant ce temps là en France

    Posté par  . Évalué à 10.

    Les administrations tardent réellement. Voir l'excellente ressource http://accentuez.mon.nom.free.fr/index.php

    On trouvera donc sur http://accentuez.mon.nom.free.fr/Proces.php :

    La Banque postale a justifié de l'impossibilité technique de porter les signes diacritiques sur les noms patronymiques mentionnés en majuscules dans les documents automatisés générés informatiquement ; qu'ayant ainsi caractérisé l'obstacle objectif à la correction demandée, les juges du fond ont pu en déduire que, dans cette limite, la banque se trouvait déchargée de son obligation de faire, justifiant dès lors légalement leur décision

    Je dis ça, je dis rien :)

  • # arroseur arrosé ?

    Posté par  (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 26 octobre 2021 à 05:55.

    Nous avons souvent déploré les législateurs qui ne pigent rien à la technique, en tout cas moi je suis souvent effaré devant certaines décisions… Il semble que cette banque a cru se baser sur cette incurie notoire, ou alors c'est son ignorance crasse qu'elle a cru universelle, après tout les imbéciles ça ose tout…

    Un petit tour sur Wikippedia nous dit que EBCDIC est :

    • bien vieux (ça remonte aux cartes perforées dont son inventeur, IBM, était un leader…) et on apprend qu'il « existe au moins 6 versions différentes bien documentées… » ;
    • effectivement « encore utilisé dans les systèmes AS/400 d’IBM ainsi que sur les mainframes sous MVS (aujourd'hui z/OS), VM ou DOS/VSE. »
    • codé sur un octet (tient, comme l'ASCII étendu…) et on lit surtout que « les bits de poids fort sont apparus après et ont permis de coder dans une colonne supplémentaire de perforation les distinctions entre chiffres et lettres, ou entre minuscules et majuscules.  »

    CQFD !

    Mais ce n'est pas tout… Il est fait mention de l'UTF-EBCDIC dont l'apparition rend inutile toute évolution de ce codage et surtout caduques les variantes nationalisées (et des pages de codes). Une section de la page de ce dernier mentionne : « Généralement, cet encodage est rarement utilisé, même sur les mainframes basé sur l’EBCDIC et pour lesquels cet encodage a été conçu. Les systèmes de mainframes IBM basés sur l’EBCDIC, comme z/OS ou MVS, utilisent aujourd’hui généralement l’UTF-16 pour un support complet d’Unicode : par exemple, DB2 UDB, COBOL, PL/I, Java et la boîte d’outils IBM pour XML supportent tous l’UTF-16 sur les systèmes IBM. »
    Le Consortium Unicode ayant été fondé en janvier 1991 et fait sa première publication en octobre 1991, ce n'était plus une nouveauté en 1995… Mais même en supposant que les équipes de développements et les outils n'étaient prêts, l'ancien système savait quand même gérer les caractères accentués… et les minuscules… en tout cas pour les caractères latins. Je ne m'explique pas l'inertie de ces institutions.

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: arroseur arrosé ?

      Posté par  . Évalué à 4. Dernière modification le 26 octobre 2021 à 06:57.

      En théorie, c'est possible, oui.

      Et comme tout le monde le sait, il n'y a pas de différence entre la théorie et la pratique. En théorie…

      Je ne m'explique pas l'inertie de ces institutions.

      Comme pour le bug de l'an 2000 ?

      Matricule 23415

      • [^] # Re: arroseur arrosé ?

        Posté par  (site web personnel) . Évalué à 10.

        J'ai longtemps bossé sur AS/400, dans différentes entreprises, et les accents sont très bien gérés en EBCDIC.

        Dans cette affaire, la banque a évidemment tort, car il est facile de gérer les accents sur AS/400. C'est facile, mais bien sûr pas instantané : il y a du boulot de recompilation, mais rien d'infaisable. La banque a simplement limité ses coûts en ne faisant pas évoluer son soft au regard de la législation.

        "La court d'appel ne considère pas qu'utiliser un système obsolète soit une excuse suffisante…" : ici système = soft de la banque, car j'espère que cette phrase ne donne pas à penser que les AS/400 sont des machines obsolètes en général, mais que c'est le soft de la banque qui est obsolète. Ces machines sont super-fiables, l'OS est d'une stabilité à toute épreuve, beaucoup d'entreprises (y compris des très grosses) ont leur business dessus, la saisie de données sans souris est redoutable de rapidité. Mais c'est bien entendu plus cher qu'un serveur x86, et moins à la mode que les clicodromes windowsiens.

        • [^] # Re: arroseur arrosé ?

          Posté par  . Évalué à 5.

          J'ai eu l'occasion d'utiliser un AS400 pour apprendre le langage GAP (1997). Cette histoire de stabilité m'avait semblé largement surfaite.
          En effet, après avoir lancé un petit programme bugué, le système est devenu inutilisable pour tous les utilisateurs. Dans l'impossibilité de reprendre la main, le formateur a redémarré électriquement la machine.
          Bref, une stabilité au niveau d'un Windows 3.1

          • [^] # Re: arroseur arrosé ?

            Posté par  (site web personnel) . Évalué à 10.

            Ca veut simplement dire que la machine n'avait pas un bon administrateur (qui, il est vrai, sont rares et coûtent cher aussi). Sur une machine de formation, ce n'est pas vraiment étonnant.
            Normalement les programmes sont exécutés dans des files d'exécutions (genre QBATCH, QINTER…) et ne peuvent pas prendre plus de ressources que ce qui est alloué à la file. Par exemple certains admins limitent la compilation dans une file batch (dont impossible d'interférer avec les sessions interactives) et encore en limitant l'utilisation CPU, donc ne peuvent pas impacter tout le système.
            Même les fichiers de base de données ont des limites du nombre d'enregistrements fixés dès la création, donc un programme qui part en quenouille et qui boucle en écriture ne peut en principe pas saturer le disque.
            Après, c'est comme tout système, si c'est administré comme un pied, que ce soit du windows, de l'unix ou autre, ça ne peut que mal tourner.

            • [^] # Re: arroseur arrosé ?

              Posté par  . Évalué à 2.

              Il ne faut pas exagérer, on parle d'un d'un tout petit programme niveau débutant qui faisait des appels de sous programmes, avec un bug style de boucle sans fin.
              Heureusement que sous Windows ou Linux, on n'a pas besoin d'experts rares et hautement qualifiés pour supporter ce genre de problème sans planter un serveur.

              • [^] # Re: arroseur arrosé ?

                Posté par  (site web personnel, Mastodon) . Évalué à 3.

                Ça c'est de la grosse mauvaise foi.
                J'ai déjà vu des gens avoir affaire à ce genre de petit programme de niveau débutant qui leur faisait perdre la main de leur Windows : il fallait bel et bien redémarrer la machine (j'ai souvenir de l'avoir encore vu avec XP et Vista où même du Ctrl-Alt-Suppr n'a pas permis au système de reprendre la main et afficher le gestionnaire de tâches, mais je suppose que les choses se sont améliorées depuis ?)
                Maintenant, dans une formation avec un serveur Windows NT4 (je prend ce cas précis pour l'avoir vécu), si chaque apprenant n'a pas sa session isolée tu auras facilement le même souci ; tandis qu'avec cette simple isolation non (pour l'avoir vu à l'œuvre, une session administrateur permettait de tuer la/les session/s fautive/s.) Même remarque sous Linux (bien que les rares fois où j'ai pu perdre entièrement la main c'est avec l'assembleur ou des techniques de piratage visant à s'extraire vraiment du contrôle du système d'exploitation.)
                Et c'est justement ce que souligne le commentaire auquel tu réponds. Il y a toujours un petit travail de préparation à faire ; et tu ne peux pas comparer des systèmes qui demandes à être adapté aux besoins (ceci est valable pour les Unix aussi) avec des systèmes qui régissent ce que les utilisateurs peuvent faire (c'est le cas de Windows sur le poste de travail.)

                “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: arroseur arrosé ?

            Posté par  (site web personnel, Mastodon) . Évalué à 3.

            xulops m'a devancé : la stabilité n'est pas automagique ; c'est une possibilité native (un genre de mix limits-quotas-conteneurs) avec des outils pour simplifier la vie.
            Mais ça n'empêche pas de faire n'importe quoi, comme avec un Linux où tout le monde utiliserait le même compte de formation qui aurait tous les droits (ou limite serait root comme j'ai vu une fois) et qu'un certain nombre de règles et bonnes pratiques sont bypass

            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: arroseur arrosé ?

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Mon but n'était pas de dire qu'il n'y a pas de différence entre la théorie et la pratique, mais de déplorer le mépris des bonnes pratiques. J'ai fait le parallèle avec l'ASCII étendu et les codes pages DOS pour qu'on voit que la problématique existe aussi ailleurs et que pourtant ça fait longtemps qu'on accentue et minuscule.

        Oui, il y a une forte analogie avec le dit bogue de l'an deux milles. L'histoire des DSI est une perpétuelle répétition ?

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: arroseur arrosé ?

          Posté par  . Évalué à -2.

          Oui, il y a une forte analogie avec le dit bogue de l'an deux milles.

          Sauf qu'en laissant le bug de l'an 2000 sans le corriger, les banques risquaient de perdre de l'argent, et ont mis le paquet.

          Dans le cas présent, c'est l'inverse : effectuer une correction risque d'engendrer des problèmes (alors que le seul "problème" relevé me semble de l'ordre esthétique).

          Le passage à l'UTF8 n'est pas simple dans des outils complexes. Un faux pas, et ça peut avoir des conséquences désastreuses, malgré de la bonne volonté, des tests, des phases d'homologation…

          Certes, vous avez raison, justifier la vétusté des outils est faux. Mais ça reste une opération bien risquée pour la banque et ses clients.

          Matricule 23415

          • [^] # Re: arroseur arrosé ?

            Posté par  (site web personnel, Mastodon) . Évalué à 10.

            Dans le cas présent, c'est l'inverse : effectuer une correction risque d'engendrer des problèmes (alors que le seul "problème" relevé me semble de l'ordre esthétique).

            La mauvaise graphie des noms, un problème d'ordre esthétique ? Et bé…

            « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

            • [^] # Re: arroseur arrosé ?

              Posté par  . Évalué à 3.

              Les noms, ce ne sont que des problèmes, comme les dates.

              Bien les traiter, ce n'est pas uniquement gérer l'UTF-8 ;)

              Matricule 23415

          • [^] # Re: arroseur arrosé ?

            Posté par  (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 27 octobre 2021 à 02:25.

            Non ! Pour les dates, les banques ont fait le raisonnement que tu as fait : « effectuer une correction risque d'engendrer des problèmes (alors que le seul "problème" relevé me semble de l'ordre esthétique). » et « Le passage à 4 chiffres n'est pas simple dans des outils complexes. Un faux pas, et ça peut avoir des conséquences désastreuses, malgré de la bonne volonté, des tests, des phases d'homologation… » Il a fallu attendre d'être au pied du mur pour se bouger ; avant ça, chaque décideur au courant mettait le problème sous le tapis et refilait le bébé aux successeurs.

            Pour info, de la même façon qu'on pouvait croire que des client-e-s de 102 ans n'en avaient que 2, de la même façon on peut confondre LEO et LÉO, sans compter toutes les personnes dont l'accueil laisse à désirer en écorchant leur nom. Mais bon, ça coûte rien de ne pas respecter la clientèle.

            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

            • [^] # Re: arroseur arrosé ?

              Posté par  . Évalué à 2. Dernière modification le 27 octobre 2021 à 06:15.

              Pour info, de la même façon qu'on pouvait croire que des client-e-s de 102 ans n'en avaient que 2

              Un coup d’œil rapide à l'historique du client permet de facilement distinguer les deux cas sans engendrer de grosse fatigue, non ?

              Mais pour ce qui est des graphies, oui. Là, il y a un problème humain, je suis d'accord. Pour autant, la banque ne confond pas LEO et LÉO, ni le compte A de LÉO avec son compte B (pourtant le nom du propriétaire est strictement le même, UTF-8 ou pas). C'est en cela que je dis que c'est un problème d'esthétique (ne pas me méprendre, ça a son importance à mon avis).

              Très honnêtement, j’attends de pied ferme ceux qui souhaitent que les diacritiques soient aussi dans les adresses mail. Pour l'instant, ça ne marche pas partout, et ça va être une sacré joyeuseté pour donner son mail… rien qu'un - dans mon mail déclenche un régulièrement un : "le tiret du 6 ?". On vous l'a jamais fait ? Pire, essayez avec un + si vous voulez vous convaincre de la joyeuseté du problème : il est d'abord humain, avant d'être informatique.

              Un Veuillez me pardonner, je ne suis pas certain de prononcer correctement votre nom, pouvez-vous me corriger ? en début de discussion, ça ne tue personne, ça humanise probablement, même, tout en conservant une certaine facilité pour l'échange numérique. Mais le problème dépasse largement l'accentuation et autre.

              Quelqu'un qui se marie et décider de changer de nom pour marquer ce rapprochement, ça pose des problèmes plus importants. Quelqu'un qui change de prénom pour raison personnelle aussi. En traitant ce problème plus général, on peut aussi traiter le problème de l'UTF-8 car le nom devient ce qu'il doit être : un identifiant non unique qui peut évoluer dans le temps, à destination des traitements humains.

              Matricule 23415

              • [^] # Re: arroseur arrosé ?

                Posté par  (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 27 octobre 2021 à 06:51.

                Bien d'accord que l'accentuation n'est qu'une partie du problème. J'ai toujours dit que les systèmes en plus d'enregistrer la bonne graphie devraient aussi enregistrer, dans un champ lié, la prononciation correspondante car les règles ne sont pas les mêmes d'une langue à une autre et que je n'aime pas jouer au loto ni froisser les gens (fort heureusement pour moi, mon carnet d'adresse le permet, le format vcard ne me perd pas cette info) et apprécie moyennement d'être mal nommé ou désigné.

                J'ai déjà entendu des gens parler du « tiret du six » sans avoir jamais compris le truc. Si quelqu'un peut me passer la référence, j'en suis preneur. Ça doit être typiquement français non ?

                Attention que changer d'état civil légalement est une chose, certes avec des répercutions pas toujours simples, mais que votre banque (ou tout autre entreprise) vous forge une fausse identité est une autre chose…

                “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                • [^] # Re: arroseur arrosé ?

                  Posté par  . Évalué à 0. Dernière modification le 27 octobre 2021 à 07:08.

                  Ça doit être typiquement français non ?

                  Aucune idée. Pas plus que je ne sais pas pourquoi il y a une hésitation entre / et \. Pas plus qu'un accent grave puisse être confondu avec un accent aigu quand dit oralement… Ah, si, là ça commence (pour moi) : je n'ai jamais réussi à m'y faire. C'est l'inverse qui me vient naturellement ;)

                  que votre banque (ou tout autre entreprise) vous forge une fausse identité est une autre chose…

                  Les problèmes d'identité (et leur usurpation) inhérent à l'UTF-8 viennent vite… :)

                  Matricule 23415

                  • [^] # Re: arroseur arrosé ?

                    Posté par  . Évalué à 2.

                    Complément : ça s'appelle les attaques punycode (je ne sais pas si c'est comme ça en français, désolé… pour l'informatique, moi, c'est l'anglais qui fait foi :p)

                    Matricule 23415

                • [^] # Re: arroseur arrosé ?

                  Posté par  . Évalué à 2.

                  J'ai déjà entendu des gens parler du « tiret du six » sans avoir jamais compris le truc. Si quelqu'un peut me passer la référence, j'en suis preneur. Ça doit être typiquement français non ?

                  Oui, c'est lié au clavier AZERTY de France. Sur la touche « 6 » accessible en majuscule, il y a le « - ». Et sur le « 8 », il y a le « _ ». C'est pour lever l'ambiguïté sur les deux que les gens parlent de « tiret-du-6 ». Pour les typographes, ça n'a aucune espèce d'ambiguïté, mais… c'est comme ça.

                  • [^] # Re: arroseur arrosé ?

                    Posté par  (site web personnel, Mastodon) . Évalué à 1.

                    Ah d'accord… n'utilisant pas azerty_fr je ne risquais pas de comprendre tout seul.
                    C'est comme « tiret du bas » que j'ai déjà entendu aussi sans piger (pourtant je suis soit en qwerty soit en dvorak mais bon.)

                    Je trouve que ça rajoute quand même de la confusion vu que tout le monde n'utilise pas la même disposition et surtout que c'est pourtant clair le « tiret (moins/trait d'union) » et le « blanc souligné (underscore) » Sacrés français.

                    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                    • [^] # Re: arroseur arrosé ?

                      Posté par  (site web personnel, Mastodon) . Évalué à 6.

                      ah non, "tiret du bas", ça ne fait pas référence au clavier mais au fait que c'est le "trait qui est en bas : a_b par opposition au tiret du milieu a-b".
                      Sur un clavier azerty_fr, le "tiret du bas", c'est le "tiret du 8" :D :D
                      (perso, je dis "moins" et pas "tiret du 6")

    • [^] # Re: arroseur arrosé ?

      Posté par  . Évalué à 8.

      « - Mais enfin M. le Juge, si je ne paye plus mes mes impôts depuis 2002, c'est que j'en suis encore au Franc !
      - Cher Monsieur, malheureusement pour vous, vu l'arrêt de la Cour de Cassation n° 42-7134 en date du 1er avril 1987, les excuses bidons n'ont de valeur juridique que lorsqu'elles sont invoquées par les grandes entreprises, les politiciens ou les policiers. »

  • # Moi aussi j'ai perdu mon accent

    Posté par  (Mastodon) . Évalué à 6. Dernière modification le 26 octobre 2021 à 08:14.

    Moi aussi j'ai un peu ce souci. J'ai un É dans mon nom de famille, mais étant né en 1975 sous la machine à écrire (qui manifestement ne l'avait pas ? Ou c'est simplement mon père qui n'a pas été assez vigilent ?), ce n'est pas écrit comme ça sur mon acte de naissance (j'en ai justement demandé une copie récemment pour vérifier).

    Si je veux récupérer mon accent, je devrait pouvoir le faire en récupérant celui de mon père et en lançant une démarche administrative…

    Il me semble que parmi mes frangins certains l'ont, d'autre pas… c'est un peu la foire cette histoire, alors que au niveau de l'orthographe la règle est claire : l'accent fait partie intégrante de l'orthographe c'est donc une faute au même titre que doubler ou pas une consonne.

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Moi aussi j'ai perdu mon accent

      Posté par  . Évalué à 3.

      D'après le site donné dans le commentaire: https://linuxfr.org/users/krunch/journaux/ebcdic-n-est-pas-compatible-avec-la-rgpd#comment-1870095 cela ne serait pas si compliqué juste pour le nom de famille avec un problème d'accent.

      Et gratuit aussi, ça peut aider. Je serais toi je tenterais

      Je regardais parce que mon prénom n'a pas été accepté comme mes parents l'avaient choisi, donc mon prénom d'usage n'est pas tout à fait le même que le prénom écrit sur mes documents officiels (à une lettre près!)
      J'ai envie de le faire corriger pour éviter des problèmes éventuels, mais c'est pas la même !

      • [^] # Re: Moi aussi j'ai perdu mon accent

        Posté par  (Mastodon) . Évalué à 3.

        Oui en effet je pensais que ce serait bcp plus compliqué. Première étape : récupérer l'acte de naissance du paternel…

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Moi aussi j'ai perdu mon accent

      Posté par  (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 26 octobre 2021 à 16:49.

      J'ai un É dans mon nom de famille, mais étant né en 1975 sous la machine à écrire (qui manifestement ne l'avait pas ? Ou c'est simplement mon père qui n'a pas été assez vigilent ?),

      L'absence des accents sur les machines à écrire est une légende urbaine qui a la peau dure. Le vrai problème, qui demeure encore aujourd'hui avec la disposition azerty en tout cas sous Windows, est les caractères accentués se faisaient par composition (principe de la touche morte sur nos claviers d'ordinateur) et que ce n'était pas simple/évident.
      Pas évident parce-qu'il fallait savoir que c'est possible et comment ça se fait, connaissance/culture que n'avait pas forcément toute personne amenée à utiliser une machine à écrire et dont ce n'est pas le métier (les dactylos sont normalement formé-e-s à ces subtilités.) Dans ce cas les accents sont absents indépendamment de la bonne volonté de la personne qui fait la saisie.
      Pas simple parce-que même quand on sait, il y a la manipulation à faire qui n'est pas triviale (un peu comme retenir puis taper les codes Alt-xxx sous Windows) et ralenti. Du coup, par fainéantise ou parce-qu'on est pressé, on laisse passer et on essaye même de justifier et normaliser à postériori : c'est pour ça qu'on entend que les majuscules ne prennent pas d'accent alors qu'il a toujours été clairement établi que l'absence des accents est bien une faute orthographique d'une part, et qu'on a toujours su les mettre d'autre part.
      Dans le pire des cas (oui, il y avait des machines sans les touches grave et aigu –ou les deux apostrophes courbes– mais avaient des minuscules accentuées et pas les majuscules comme sur l'azerty actuel), il fallait apporter toutes les corrections à la main… Donc pas simple, et on a vite fait de vous envoyer promener avec l'excuse des accents non obligatoires en majuscules.

      De l'autre côté, dans ce contexte administratif, on ne se dit pas que le document contient certaines erreurs et surtout on ne va pas traquer les fautes d'orthographe (et les accents qui font défaut.) Du coup, il est normal que tes parents aient manqué de vigilance.
      Mais quand ça arrive, comme je l'ai déjà mentionné, on a une fin de non recevoir avec la fausse excuse des accents facultatifs sur les majuscules (ça c'est une vraie légende urbaine.) Du coup, la rectification (manuelle) n'est pas faite (dans le délai imparti) sur le document qui servira de référence.
      Ça n'a pas beaucoup changé malheureusement. (je crois qu'il y a eu un journal récemment dans ce sens incitant à bien relire les documents à réception.)

      Ma vie maintenant : je suis de la même période, avec un É dans mon nom, et c'est bien acté. J'ai cependant failli le perdre une fois, au moment de faire ma carte d'identité ; mais la relecture attentive m'a permis d'éviter cela.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: Moi aussi j'ai perdu mon accent

      Posté par  (site web personnel) . Évalué à 5.

      Je suis dans le même cas, et je sais qu'il a déjà eu des problèmes. Je n'ai plus le contexte exacte, mais il me semble que c'est une banque, qui a refusé l'ouverture d'un compte à mon oncle, le soupçonnant d'usurpation d'identité. En effet, il utilisait son nom de famille accentué sur ses documents d'identité, mais les traces administratives de son existence étaient sans accent.

      C'est allez assez loin, je crois avant qu'il puisse prouver sa bonne foi.

  • # Si il n'y avait que la perte d'accent...

    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 26 octobre 2021 à 08:53.

    Il y en a qui étaient motivés… Et c'est très bien!
    Perso pas le courage, mais l'envie ne m'en manque pas, le manque d'accent est encore gérable mais quand on se retrouve avec é ou carrément les lettres accentuées disparues en 2021…

    Dans l'autre sens, l'année dernière j'ai reçu ma première carte bancaire un peu (mon prénom et nom ne sont pas en majuscules sur mon acte de naissance) corrects avec accents (majuscules du coup) et même le "Mr" enlevé (mon genre n'a rien à faire sur une CB), lentement mais ça avance.
    A ma connaissance il n'y a que Apple qui est plus correct sur la casse (minuscules la où il faut) mais pas vu de confirmation sur les accents.

  • # ascii vaincra !

    Posté par  (site web personnel) . Évalué à 3.

    Je suis d'accord avec la banque, il faut arrêter la folie de l'unicode.

    Et si je décide de m'appeler mon fils Ḑ̶̧̡̡̻͚̻̤̞̥̟̮̟̪̖̻̲̠̙̩͍̪̮͔̱̗̣͚̱̣̟̼̖̝̙͕̭̟͉̦̝͇̼̩̑͆͆̆́͜͜͜ͅā̷̞͓͙̥̜̖̹̠̼̮̫͖͐̎̑̐̓̌͑̏̐̈̂͗̽̽́́̏̈́̓̎̂̃͑̎̕͠͝ͅv̷̳̪̬̳̭͂̈̐̌̾̅̓̀̌̏̌̆̅̎̋͑̂͆̾̌̅̍̂̈́̽͋̓͗̽̌̇̀͂̂̀̈́͊̄̈͑̈́̃̕͘̕̚̕̚͠ͅè̷̡̢̢̢̢̨̡̯̻̜̦̰̯̥͙̮̱̖̪͕̥͚̬̝͚̰̺̳̱̄́̀̾͛̈̊̉̓̈́͋́̔̿̄͘͠͝͝ ̷̢̭̜͍̙́͐́͂͊̈́̂Ņ̷̧̧̢̡̪̤̬̺̳̗̗̝̗̮̦̻̼̳̹̣͉̥̲̖̞̤̘͔̲̼̲̻̬̗̙̝̗̼̬̰̫̪͔͓͍͉͊̀̎̏̈́͆̑̊̈́̈́͋̂́͌̈́͋̌̃̽͑̂̃̓͑̄̋͌͋̉̍̈́͌̒̉̌͌̒̅̓̄̍̚̚͜͝͝͝͝͝ę̷̢̡̧̩̙̟͎͉͔̘̤̝͈͖͓͈̻͉̘͕̱̤̲̳̝̮͕̥̬̭̳̺̻̬̳̳̯̰̭͓̭̝̍͆̏̅́̍̐̇͘̕w̶̨͍̟̘̣̝͕̻̭͚̗̟͖͓͐͐̑͋͐̎̏̐͆͐̔̔̅́̾͝͠t̵̨̛̻̜̣͇͎̱͔̱̑̽͆͒͋̐̇̃̅̂̌̄̓͒̉̒̒̎͋̎͐̀̔̍͋̊̐̿̇͑̆̾̚͘̕̕̚͠o̴̢̢̢̢̡͚̬͙̹̤͓̬̞̜̥̬̖̰̣͎̲̝̮̖̯̟͍͙̦̳̲̩͈̪͚̖̟̤̰̭͓̮̯̘͖̮͖̮̐̅͗̂̃̽̃̋̿͑͜͝ͅn̶̦̲̬̩̬̦̅͑̔̇̋͑̊̃̃͐̑͑̆́̈̎̕̚̚͠͝͝͠J̷̨̡̢̛̛̮̘̯̪͎̗̰̗̼͓͇̪̩̙̫̮̺̬̼̯̣̠̤̳̝̝͈̰͙͎̫̱͎͎̤̦͆̿̈́̀̂̑͜͠͠͝ͅͅͅừ̵͕̙̘͉̱͎͉̪̭͕̲̝̖̻̳̗̘̲͕͈̪̙̻̼͎͐͆̉͑́̋̀̈͗̔̚͘͜͝͠͠ͅṋ̷̡̡̧̛̛͔͉̞͎̖͇̝͙̠̼̝̳̟͓̤̜̩͍̦͐̀͊̏̇̓͒͋͌͊̍̐͋͑͋̉̈̃̓͛̅̐̒̓͊̔̏̌̑̎̃͋́̏͑̅̕̚̚̕̚͝͠͝͝͠͝͠i̸̧̡̨̨̧̢̧̘̟̩̺̳͉͙͙̖͚͕͓̩̠͚̼̬̮͇̜̫̙̯͍̭͍̮͍͔̜͔̹͙̳̠̱̼̮̲̰͕̙͑̊̓͗̓͌̌̌̔͂̏̇́̔̋̿̅̒͒̈́͒̄̔̃̒̋͂̕͘͘ͅơ̸̡̨̨̧̪̻̗̭̞̯̬͇̜͓̙͙̺̻͎̝̘͔̤̩̱̫̮͍͎̖̬͚̝̙̹̞͕͙̱̯̜̙͇̪̯̠̗̈́̿̓͋̾̀͒̅̓̈́̓͊͗̽̆̏͂̉̒̿́̌͑̅̀͒̊́̀̈́̍͊̈̑͑̏̈̈́̌̍̕̕̚͜͝͝͝͠ͅr̵̡̧̧̛͕̭͚͙̻̘̥̯̘̹̝͖̗̱͉̫͙̫̲͉̞͚̼̺͈̞͚͉̤̪̈́̄̽̍̑̈͒͛̅̿̑̓̑̈̐̆͗̇̊̋̋̊̇̀͑̏̏͂͗͒̚͝͝ͅ ?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # ...

    Posté par  . Évalué à 4.

    L'informatique bancaire, c'est :
    1/ de vieux systèmes
    2/ base de code toujours actif et très vieux avec perte de la connaissance dessus
    3/ compétences très médiocres (reconversions, pas sexy, technologie "dépassée")
    4/ des performances de malade mental. Mais vous n'avez même pas idée. Surtout quand le codeur est bon.
    5/ une grande robustesse de code face aux attaques.

    4 et 5 justifient 1 2 et 3, sans compter les coups de la migration.

    Il est techniquement très compliqué d'utiliser l'utf-8. C'est pas l'ebcdic le problème mais les performances de traitement.

    • [^] # Re: ...

      Posté par  (site web personnel) . Évalué à 8.

      4/ des performances de malade mental. Mais vous n'avez même pas idée. Surtout quand le codeur est bon.
      5/ une grande robustesse de code face aux attaques.

      {{référence nécessaire}}

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: ...

        Posté par  . Évalué à -2.

        Rien que pour le cas qui nous intéresse ici.

        Bah pour le 5.

        Moins de risque qu'un petit malin n'emploie des caractères exotiques pour faire de l'usurpation d'identité. Moins de problèmes avec les saisies utilisateur (pour un pète-couille accent-sur-mon-nom gnagnagna, combien t'auras de coquilles ?) :-°

        Pour le 4.

        Aucune conversion pour passer d'un encodage numérique à un encodage texte.

        Format fixe. Donc n'importe quelle "entrée" d'un fichier accessible sans avoir à parcourir les précédentes.

        • [^] # Re: ...

          Posté par  . Évalué à 5.

          Moins de risque qu'un petit malin n'emploie des caractères exotiques pour faire de l'usurpation d'identité. Moins de problèmes avec les saisies utilisateur (pour un pète-couille accent-sur-mon-nom gnagnagna, combien t'auras de coquilles ?) :

          Dans ce cas, autant fournir un uuid à tout le monde. C'est beaucoup plus sécurisé.

          Aucune conversion pour passer d'un encodage numérique à un encodage texte.

          Tu parlais de "performances de malade mental. Mais vous n'avez même pas idée. Surtout quand le codeur est bon.", la conversion dont tu parle ne rentre pas dans la catégorie "malade mental". Et si c'est le seul problème, c'est l'adressage dans le fichier, tu peux coder en utf-32.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: ...

            Posté par  . Évalué à -4.

            Bah écoutez faites donc puisque vous vous croyez si malin. IBM se fait un fric monstre encore là-dessus. Vous serez milliardaire en 3 ans puisque c'est si facile de les concurrencer…

            Moi je le vois régulièrement au taf' quand il y a des échanges de données entre des techno mainframe et autres. C'était qu'un exemple (que vous avez encore filtré comme ça vous arrangez par derrière). Ce qui est frappant c'est la méconnaissance du monde mainframe (excusable) et plus généralement des conséquences de l'empilement de couche et autres abstractions dans les performances déplorables de l'informatique moderne, par rapport à une informatique bas niveau (inexcusable pour un informaticien… moi qui me plains de l'incompétence de certains collègues…).

            utf-32 : sérieux ? Nan mais tu crois qu'on manipule de pauv' fichiers texte de 10ko là ?

            Tiens, le diplo a sorti un excellent article ce mois-ci sur la conso de l'informatique et les problèmes écologiques que ça pose. Pour la plupart des informaticiens c'est open bar le stockage et le cpu… même si ce n'est certes pas ce qui motive les banques !

          • [^] # Re: ...

            Posté par  . Évalué à 0.

            Dans ce cas, autant fournir un uuid à tout le monde. C'est beaucoup plus sécurisé.

            Ça s'appelle le NIR. Ils en pensent quoi à la quadrature ?

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 2.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: ...

                Posté par  . Évalué à 1.

                De ce que j'en sais. C'est devenu un peu plus large. Par contre c'était pas dans la banque.

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 2.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: ...

                    Posté par  . Évalué à 0.

                    On appelle ça l'argument BFM maintenant.

                    Probablement que ça a été justifié par l'intérêt public keuf keuf (c'est pas comme si le dit traitement se faisait en cachette).

                    • [^] # Commentaire supprimé

                      Posté par  . Évalué à 3.

                      Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: ...

              Posté par  . Évalué à 2.

              ou, il y a aussi le NIF.

    • [^] # Re: ...

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      Il est techniquement très compliqué d'utiliser l'utf-8. C'est pas l'ebcdic le problème mais les performances de traitement.

      Comme mentionné dans le commentaire initiant le fil « arroseur arrosé » sur ces systèmes on préfère UTF-EBCDIC (qui fonctionne de la même façon que l'UTF-8 mais en s'appuyant plutôt sur EBCDIC) ou directement UTF-16 ! Mais ce commentaire est surtout pour indiquer que sans aller jusque là, on sait gérer les accentuations en EBCDIC… (et qu'un programme écrit en 1995, et non en 1960, n'avait pas vraiment d'excuse valable…)

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: ...

        Posté par  . Évalué à -1.

        Entre la page wikipedia, le commentaire qui cite la page wikipedia, toi qui cite le commentaire qui cite…

        T'as réussi à passer d'une affirmation à son exact contraire.

        Bravo \o/

  • # Commentaire supprimé

    Posté par  . Évalué à 5.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Recherche d'antériorité

      Posté par  . Évalué à 6.

      En gros, les caractères diacritiques ne sont pas affichable, sauf l'apostrophe et le tiret. Et lors d'une recherche patient, il ne faut tenir compte ni de l'un, ni de l'autre.

      Pour des recherches efficaces de personnes, il faut donc avoir l'identité sans ces caractères. Pour un affichage avec ces caractères, il faudrait donc persister la variante avec caractères diacritiques, soit, grosso modo, stocker 2x le nom et le prénom des personnes, l'une à la forme normalisée et l'autre à des fins d'affichage. Ceci, afin de limiter les doublons.

      Je répondrais : LC_COLLATE. Et en Javascript : localeCompare. C'est aussi possible en Java, et même en C++

      Donc : on stocke la forme officielle. Et quand on fait une recherche, on utilise la comparaison qui sait comparer des noms dans la langue.

      L'identité de quelqu'un, c'est important. C'est l'outil qui doit s'adapter à l'humain, et pas l'inverse.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 3.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Recherche d'antériorité

          Posté par  . Évalué à 4.

          OK, je découvre des problèmes non anticipés, merci pour le retour d'expertise. Il se peut que ça me serve un jour.

          Du coup… j'ai envie de suggérer quelque chose : stocker l'identité en deux champs distincts.
          1. L'identité réelle, pour affichage, pour les humains, l'État Civil.
          2. L'identité normalisée pour une machine, permettant de faire des recherches.

          Exemple avec Marie-Stéphanie d’Alembert:
          1. Marie-Stéphanie d’Alembert
          2. marie stephanie d alembert

          J'y ai même mis l'apostrophe typographique dans le 1. Cette étape est faite lors du stockage. Lors de la requête, le client transforme le champ de requête en forme normalisée, envoie la requête au serveur qui n'a qu'à faire un WHERE prenom_norm LIKE '%request%';.

          Les index marchent, c'est au client de se payer le coût de la transformation.

          Alors… qu'est-ce que j'ai pu oublier qui viendrait contredire une efficacité de ce modèle ? ;)

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 4. Dernière modification le 30 octobre 2021 à 16:39.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Recherche d'antériorité

              Posté par  . Évalué à 4.

              Si vous utilisez PostgreSQL, je vous recommande sa fonctionnalité de recherche fulltext:
              https://www.postgresql.org/docs/current/textsearch.html

              • [^] # Commentaire supprimé

                Posté par  . Évalué à 3.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: Recherche d'antériorité

                  Posté par  . Évalué à 2.

                  Au contraire, c'est très adapté puisque ça va permettre de retrouver des mots qui ressemblent (de façon configurable) aux mots qu'on a donné.
                  Ton exemple avec un LIKE, c'est au contraire quand on veut trouver exactement le terme indiqué, et pas quelque chose qui ressemble.
                  Ce qui est important avec ce genre de recherche, c'est qu'elle trouve ce qu'on veut, avec pas trop de faux positifs, pour ensuite pouvoir choisir le bon résultat. C'est le boulot du programmeur (ou de l'administrateur système) de l'avoir configurée de façon adaptée aux données considérées.

                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à 7.

                    Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.