On peut faire le parallèle avec la PSD2 qui a introduit l'obligation pour les banques de fournir des API modernes pour l'accès en lecture aux comptes de paiement et la réalisation de virements.
Premier problème : ces API ne sont utilisables que par des tiers de confiances (Third Party Providers) qui doivent être agréés par l'autorité de régulation nationale (l'ACPR en France). Powens (ex Budget Insight) en fait parti. Par contre, toi en tant que particulier, tu ne peux pas les utiliser, tu es obligé de passer par un TPP qui lui va (probablement) te facturer l'accès au service. Et pour obtenir l'agrément, il est nécessaire d'être une entreprise avec un minimum de capitaux propres et un département de conformité.
Deuxième problème : les banques n'avaient aucun intérêt à mettre ça en place, et ont traîné des pieds. La réglementation a été adoptée en 2017, la date limite de mise à disposition des API était en 2019, il a fallu trois années supplémentaires de collaboration avec les banques pour les aider à résoudre leurs problèmes. Aujourd'hui c'est bien plus stable, mais il y a toujours des fonctionnalités qui manquent dans les API (typiquement les virements groupés).
Troisième problème : même si on peut se féliciter du fait que spontanément des standards ont émergé (Berlin Group ou STET en France), évidement l'implémentation des banques ne les respecte pas, et il est malgré tout nécessaire d'écrire du code spécifique pour chaque banque.
Quatrième problème : la PSD2 ne concerne que les comptes de paiement, ce qui signifie que l'on a accès qu'aux comptes courants et CB. Par contre tout ce qui est épargne, crédit, comptes titres, etc., ne sont pas exposés. Tu n'as donc accès qu'à des informations partielles de tes données.
Cinquième problème : à ce sujet, les informations obligatoires varient d'un pays à l'autre. En France, Powens et d'autres TPPs ont fait un lobbying très actif pour accéder au maximum de données possibles (coordonnées de l'utilisateur, cartes bancaires, etc.), et j'ai moi-même contribué à l'élaboration du standard STET. Par contre impossible de récupérer les relevés PDF qui sont pourtant dans le scope de la PSD2. En revanche, dans d'autres pays où il n'existe pas ou peu de TPP, et donc où il n'a pas été fait un effort de lobbying, les banques ont réalisé leurs API par dessus la jambe et le régulateur est peu attentif.
Bref, quand je vois comment est foutu la réglementation sur l'émission des factures électroniques, beaucoup plus floue que la PSD2, je suis d'avis que ce sera bien de la merde.
[^] # Re: facturation électronique
Posté par moules . En réponse au journal Une API normée pour accéder aux factures (1ere étape). Évalué à 10. Dernière modification le 07 janvier 2023 à 19:04.
On peut faire le parallèle avec la PSD2 qui a introduit l'obligation pour les banques de fournir des API modernes pour l'accès en lecture aux comptes de paiement et la réalisation de virements.
Premier problème : ces API ne sont utilisables que par des tiers de confiances (Third Party Providers) qui doivent être agréés par l'autorité de régulation nationale (l'ACPR en France). Powens (ex Budget Insight) en fait parti. Par contre, toi en tant que particulier, tu ne peux pas les utiliser, tu es obligé de passer par un TPP qui lui va (probablement) te facturer l'accès au service. Et pour obtenir l'agrément, il est nécessaire d'être une entreprise avec un minimum de capitaux propres et un département de conformité.
Deuxième problème : les banques n'avaient aucun intérêt à mettre ça en place, et ont traîné des pieds. La réglementation a été adoptée en 2017, la date limite de mise à disposition des API était en 2019, il a fallu trois années supplémentaires de collaboration avec les banques pour les aider à résoudre leurs problèmes. Aujourd'hui c'est bien plus stable, mais il y a toujours des fonctionnalités qui manquent dans les API (typiquement les virements groupés).
Troisième problème : même si on peut se féliciter du fait que spontanément des standards ont émergé (Berlin Group ou STET en France), évidement l'implémentation des banques ne les respecte pas, et il est malgré tout nécessaire d'écrire du code spécifique pour chaque banque.
Quatrième problème : la PSD2 ne concerne que les comptes de paiement, ce qui signifie que l'on a accès qu'aux comptes courants et CB. Par contre tout ce qui est épargne, crédit, comptes titres, etc., ne sont pas exposés. Tu n'as donc accès qu'à des informations partielles de tes données.
Cinquième problème : à ce sujet, les informations obligatoires varient d'un pays à l'autre. En France, Powens et d'autres TPPs ont fait un lobbying très actif pour accéder au maximum de données possibles (coordonnées de l'utilisateur, cartes bancaires, etc.), et j'ai moi-même contribué à l'élaboration du standard STET. Par contre impossible de récupérer les relevés PDF qui sont pourtant dans le scope de la PSD2. En revanche, dans d'autres pays où il n'existe pas ou peu de TPP, et donc où il n'a pas été fait un effort de lobbying, les banques ont réalisé leurs API par dessus la jambe et le régulateur est peu attentif.
Bref, quand je vois comment est foutu la réglementation sur l'émission des factures électroniques, beaucoup plus floue que la PSD2, je suis d'avis que ce sera bien de la merde.