Sur la même page a été dressée une liste des conditions d'accès aux comptes en ligne par les banques sur cette liste collaborative suivie de proposition d'actions à court terme ici pour les personnes qui se sentent concernées.
Une proposition plus à moyen terme est aussi proposée dans cette section.
Je comprend qu'une pétition sur mobilizon aurait eu plus de public mais les personnes qui ne souhaiteraient pas signer sur change.org pourront trouver dans le wiki plus haut des idées d'actions simples, ou plus ambitieuses selon leur motivation.
Sur la page indiquée par Anubis, il a aussi une liste collaborative des banques qui imposent une appli et les liens associés (pour vérifier si c'est tjs valable).
Il y a aussi une liste des moyens possibles de se plaindre.
À noter que dans le dernier rapport de l'observatoire de la sécurité des moyens de paiement, entité de la Banque de France (2024, sorti en septembre 2025), la recommandation de proposer une alternative gratuite à l'application a été retirée. :(
Il est sans doute possible d'obtenir une correction de cet « oubli » si suffisamment de personnes se plaignent…
Dans Mercurial (Hg), chaque nouvelle version est associé à un identifiant de modification (le changeset) qui est calculé en hachant des métadonnées et les données elles-même.
Il me semble qu'un moyen élégant et fonctionnel serait que les systèmes de gestion de version utilisent, en lieu est place de l'identification de l'auteur, une clé GPG. Elle resterait unique mais ne permettrait plus de remonter à l'auteur.
Néanmoins, cela complexifie le système…
Oui, je comprend que le problème se pose pour tout dépôt Git, ainsi que les forges sociales qui les utilisent, donc Github, Tuleap, Bitbucket quand il est utilisé avec des dépôts git, etc.
ça ne suffira malheureusement pas : l'utilisateur peut choisir de récupérer ou pas les infos originelles avec l'option --no-replace-objects
Cette option ne fonctionne donc que si le client le décide, ce qui n'est pas suffisant à mon sens.
# obligation d'alternative et actions possibles
Posté par FilG . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 5 (+5/-0). Dernière modification le 27 avril 2026 à 15:45.
Bonjour,
ça pose pas mal de question.
Pour répondre à l'« obligation » de mettre à dispo une alternative à l'appli, le sujet est précisé ici : https://wiki.april.org/w/Atelier-directive-dsp2#Ce_que_disent_les_textes
Sur la même page a été dressée une liste des conditions d'accès aux comptes en ligne par les banques sur cette liste collaborative suivie de proposition d'actions à court terme ici pour les personnes qui se sentent concernées.
Une proposition plus à moyen terme est aussi proposée dans cette section.
Je comprend qu'une pétition sur mobilizon aurait eu plus de public mais les personnes qui ne souhaiteraient pas signer sur change.org pourront trouver dans le wiki plus haut des idées d'actions simples, ou plus ambitieuses selon leur motivation.
[^] # Re: Action politique
Posté par FilG . En réponse au journal Boursorama semble dorénavant imposer l'usage d'un smartphone pour utiliser ses services. Évalué à 2.
Sur la page indiquée par Anubis, il a aussi une liste collaborative des banques qui imposent une appli et les liens associés (pour vérifier si c'est tjs valable).
Il y a aussi une liste des moyens possibles de se plaindre.
À noter que dans le dernier rapport de l'observatoire de la sécurité des moyens de paiement, entité de la Banque de France (2024, sorti en septembre 2025), la recommandation de proposer une alternative gratuite à l'application a été retirée. :(
Il est sans doute possible d'obtenir une correction de cet « oubli » si suffisamment de personnes se plaignent…
# intégration de Hg
Posté par FilG . En réponse à la dépêche Hébergez votre projet open source sur la nouvelle plate‐forme Agile et libre : Tuleap.net. Évalué à 3.
Bonjour,
j'ai cru comprendre sur votre site que Git et SVN sont intégrés, prévoyez-vous d'intégrer Mercurial (Hg) ? :)
Merci.
[^] # Re: Github et tout les autres....
Posté par FilG . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 1.
Dans Mercurial (Hg), chaque nouvelle version est associé à un identifiant de modification (le changeset) qui est calculé en hachant des métadonnées et les données elles-même.
Ces métadonnées peuvent contenir des infos personnelles (https://www.mercurial-scm.org/wiki/FrenchChangeSet).
Il me semble qu'un moyen élégant et fonctionnel serait que les systèmes de gestion de version utilisent, en lieu est place de l'identification de l'auteur, une clé GPG. Elle resterait unique mais ne permettrait plus de remonter à l'auteur.
Néanmoins, cela complexifie le système…
[^] # Re: Git
Posté par FilG . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 0.
Oui, je comprend que le problème se pose pour tout dépôt Git, ainsi que les forges sociales qui les utilisent, donc Github, Tuleap, Bitbucket quand il est utilisé avec des dépôts git, etc.
[^] # Re: git-replace(1)
Posté par FilG . En réponse au journal Gitlab.com interdit de supprimer ou modifier ses informations personnelles. Évalué à 0.
ça ne suffira malheureusement pas : l'utilisateur peut choisir de récupérer ou pas les infos originelles avec l'option --no-replace-objects
Cette option ne fonctionne donc que si le client le décide, ce qui n'est pas suffisant à mon sens.