Journal Une API normée pour accéder aux factures (1ere étape)

Posté par  . Licence CC By‑SA.
31
5
jan.
2023

Hello les amis,
ça fait un bail que je tourne autour de la question alors je me lance …

Il y a quelques années nous recevions nos factures par la poste, le traitement était donc j'ouvre l'enveloppe et je pose le papier dans la pile/le classeur/la poubelle.

Ce journal ne s'adresse donc PAS à la catégorie "facture -> poubelle" qui a beaucoup gagné au passage au numérique, il suffit de ne pas lire le mail d'information comme quoi la facture est disponible sur votre compte client.

Par contre pour tous les autres humains qui classaient leurs factures (perso ou pro peu importe) au fil de l'eau et qui aujourd'hui perdent en moyenne 2 à 10 minutes pour chaque facture qu'il faut aller télécharger sur le portail client (différent de chaque fournisseur) j'ai une proposition à vous faire.

Après avoir passé des heures à écrire des web scrappers, à devoir les réécrire chaque fois qu'un fournisseur change de "look" ou ajoute une "nouvelle pub" sur son portail client etc.

Je me dis qu'il est temps de proposer un truc propre en normalisant un chemin d'api qui serait donc systématique et qu'il suffirait ensuite d'implémenter une seule fois dans un logiciel "collecteur de factures" pour que ça tourne tout seul.

J'ai cherché mais je n'ai pas trouvé de RFC ou de norme à ce sujet, si vous avez connaissance d'une telle chose merci de me l'indiquer sans tarder !

Je propose donc de lancer l'idée OpenBusinessAPI résumée en obapi.org (je fais cadeau du moyen mnémo technique pour s'en souvenir "ho bapi ho bapi bapi blue ho bapi blue").

On normerait donc un chemin d'api, et une suite super basique de commandes auth/key/list/get qui permettrait de télécharger les factures.

Votre fournisseur indique qu'il est compatible obapi -> hop en 2 secondes vous entrez votre login/pass d'accès au "portail client" et votre appli obapi client fait le reste.

Oui c'est dingue mais vous n'avez pas envie d'y croire ?

Un lien pour l'instant: https://obapi.org … et un 2° sur le forum dolibarr où j'ai commencé à en parler : https://www.dolibarr.fr/forum/t/lancement-dune-idee-un-peu-folle-obapi/41931

  • # Force à toi

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 05 janvier 2023 à 12:40.

    Je n'ai aucune énergie à donner dans cet effort, mais je soutiens moralement cette idée. C'est en effet une tâche de gestion absolument rébarbative et j'ai déjà souhaité qu'une telle solution existe.

    Il y a un problème similaire que j'aimerais voir traité, mais avec des considérations de sécurités qui le rendent encore plus difficile. Je parle bien entendu d'une API normée pour accéder à des comptes bancaires.

    Force à toi

    • [^] # Re: Force à toi

      Posté par  . Évalué à 5.

      Puisqu'on en est à parler du bancaire : à quand la portabilité de l'IBAN ?

      On dit souvent que les Français sont attachés à leur banque, mais c'est surtout qu'ils sont démoralisés à l'idée de se farcir les whatmille démarches pour signaler leur changement de compte à tous les organismes concernés.
      Même si la situation s'est un peu amélioré ces dernières années (la nouvelle banque se chargeant d'interroger la banque qu'on quitte, pour connaître les destinataires des prélèvements réguliers), ça ne marche jamais à 100% (y en a toujours qui ne prennent pas en compte la demande automatisée), et il faut souvent ensuite confirmer par courrier qu'on autorise le prélèvement.

      • [^] # Re: Force à toi

        Posté par  . Évalué à 2. Dernière modification le 05 janvier 2023 à 20:05.

        L’IBAN n’est pas rattaché à une personne (juridiquement parlant).

        Mort aux cons !

      • [^] # Re: Force à toi

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

        Les prélèvements c'est pénible, mais l'organisation qui veut prélever a intérêt à prendre en compte rapidement le changement.

        Pour les versements par contre, tu peux parfaitement tomber sur un service mollasson qui s'en fiche que tu reçoives ton argent 2 ans plus tard.

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

    • [^] # Re: Force à toi

      Posté par  . Évalué à 10.

      Il y a un problème similaire que j'aimerais voir traité, mais avec des considérations de sécurités qui le rendent encore plus difficile. Je parle bien entendu d'une API normée pour accéder à des comptes bancaires.

      Mais ça existe ! En Grande-Bretagne, c'est OpenBanking, pour le reste de l'Europe c'est PSD2. En général, les banques proposent au moins 2 APIs :

      • une pour permettre les paiements : PISP (Payment Initiation Service Providers)
      • une pour consulter la balance des comptes et la liste des transactions: AISP (Account Information Service Providers)

      La réglementation n'est pas venue avec une spécification d'API, mais il y a un standard de fait : STET. Tu peux aller voir là : https://www.stet.eu/en/psd2/.

  • # Woob

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

    C'est pas ce que fait déjà woob? (Web out of browser)

    • [^] # Re: Woob

      Posté par  . Évalué à 6.

      C'est aussi le fer de lance de CozyCloud

      • [^] # Re: Woob

        Posté par  . Évalué à 5.

        C'est justement en pensant à eux que je me dis qu'on pourrait grandement leur simplifier la vie si - par exemple - tous les logiciels libres de facturations respectaient la même norme (pour commencer) …

        Je vois bien proposer à cozy d'implémenter le client obapi et "voir" le résultat sur 5 ou 10 entreprises (fournisseurs) qui utilisent dolibarr par exemple :)

        eric.linuxfr@sud-ouest.org

        • [^] # Re: Woob

          Posté par  . Évalué à 3.

          Standards

          Ça, ce sont les sources. Le mouton que tu veux est dedans.

          • [^] # Re: Woob

            Posté par  . Évalué à 3.

            Liorel, je suis 100% d'accord mais je cherche toujours ne serait-ce que le 1er "compétiteur" sur ce standard auquel j'aimerais me conformer et pour lequel j'aimerais faire la promotion …

            eric.linuxfr@sud-ouest.org

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 10.

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

      • [^] # Re: Woob

        Posté par  . Évalué à 4.

        Les pannes, c'est la version technique qu'un problème plus profond: l'accès au site via un système comme Woob est interdit par les conditions générales d'utilisation. Quand c'est un truc où tu es le produit, comme Twitter, tu ne risques que l'exclusion, pas de préjudice majeur. Quand c'est ta banque, j'imagine qu'ils peuvent te couper ton accès web (en tout cas, c'est ce que je ferais si j'étais la banque).

        Même si les applications et sites bancaires ne sont pas pratiques, ils sont un élément majeur de la sécurité de l'accès aux données et aux autorisations bancaires. Un bug dans Woob, et paf, un virement n'est pas fait, ou est fait 5000 fois, toutes les cartes sont mises en opposition, bref, ça peut rapidement être l'horreur, et je ne vois pas comment on peut rattraper ça, puisque l'utilisation de ces logiciels est interdite.

        • [^] # Re: Woob

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

          Bon, mais la proposition d'API discutée ici est en lecture seule donc il n'y a pas du tout les mêmes problèmes de sécurité. Il s'agit de voir ses factures, pas de les régler.

        • [^] # Re: Woob

          Posté par  . Évalué à 5.

          Faut nuancer beaucoup quand même: je tombe régulièrement sur des gros services, dont mes 2 banques, qui utilisent Budget Insight (la version pro de Woob). En lecture, comme ce qui est proposé par obapi.

        • [^] # Re: Woob

          Posté par  . Évalué à 5.

          l'accès au site via un système comme Woob est interdit par les conditions générales d'utilisation

          C'est un sujet d'interprétation, woob peut être perçu comme un navigateur qui effectue automatiquement les opérations que tu aurais faites, mais c'est bien toi qui te connecte, il n'y a pas de violation des CGU.

          Par contre je suis d'accord avec toi que réaliser des opérations sensibles comme l'émission d'une transaction bancaire est dangereux (même si il est implémenté dans woob de manière à ce que tu confirmes avec le récapitulatif issu du site).

        • [^] # Re: Woob

          Posté par  . Évalué à 3. Dernière modification le 14 janvier 2023 à 14:30.

          l'utilisation de ces logiciels est interdite.

          Pas totalement en réalité, car il y a bien un service que des banques proposent : l'agrégation de comptes (via Budget Insight). Et ça nécessite de leur fournir tes id/mdp des concurrents.
          Idem pour Digiposte.

  • # Et le Mail

    Posté par  (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 05 janvier 2023 à 14:02.

    J'approuve tout a fait dans le sens ou il est scandaleux de devoir se connecter à un serveur pour récupérer sa facture, son bulletin de salaire… C'est une tâche lourde qui n'est, selon moi, pas RGPD dans le sens ou de ce fait mon fournisseur sait si je regarde ma facture, quand et même de quel endroit (avec mon IP), il peut la changer sans me prévenir discrêtement…

    Cependant plus qu'une couche supplémentaire, je voudrais militer pour un envoi par mail. C'est un protocole ouvert, standard, qui fonctionne extrêment bien et qui est le pendant numérique naturel du courrier. Alors pour simplifier le traitement on pourrait peut-être imaginer un standard d'envois. On pourrait même imaginer activer l'option pour l'envoyer en crypter si on transmet sa clé publique…

    Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

    • [^] # Re: Et le Mail

      Posté par  . Évalué à 10.

      Depuis peu j'ai intégré un point important par rapport à ce point de vue.

      Vous avez entendu parler des arnaques aux faux RIB sur les factures ? voici un truc qui arrive souvent : mr x se fait piquer son login/pass à sa boite mail. Le (méchant pirate) lui détourne les factures, remplace le rib du fournisseur par son rib de pirate et collecte le pognon. L'arnaque n'est découverte souvent que de longues semaines plus tard lorsque l'entreprise fait la relance des impayés.

      Ça arrive bien plus souvent que vous ne croyez.

      Solution alternative: indiquer au client qu'une facture est disponible sur votre serveur via son portail client … il vient télécharger l'original et vous êtes "sûr" que le document n'a pas été altéré par un tiers.

      Il y a d'autres solutions pour éviter ça comme par exemple sceller le document mais ça demande à ce que l'utilisateur final fasse l'usage d'un lecteur de document compatible (au pif en pdf la visionneuse js ne le fait pas) … et sache détecter un document dont le certificat aurait été altéré … sauf que si le pirate est pas con au lieu de "casser" le scellement il va tout simplement livrer un pdf sans certificat et donc le client aura un pdf non scellé sans savoir que l'original l'était !

      Une autre serait d'envoyer un deep-link dans le mail, mais là encore ça me dérange car les outlook/gmail et autres pré-téléchargent le document et donc aucune confidentialité dans l'affaire. Et ça rejoint un autre contre-argument pour la réception par mail : à moins d'avoir son serveur mail perso la réception des factures par mail est une catastrophe au niveau confidentialité des données … le facteur peut tout savoir.

      Perso je continue d'envoyer mes factures (scellées) par mail à mes clients … mais … j'avoue que j'hésite de plus en plus à conserver cette approche.

      eric.linuxfr@sud-ouest.org

      • [^] # Re: Et le Mail

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

        C'est 2 choses différentes. Les factures, c'est juste pour te demander de payer, pas pour recevoir de l'argent. Pour changer ton RIB en général la démarche est autrement plus complexe. Si tu parles d'un mail qui te demande un prélèvement automatique, c'est totalement autre chose, l'un n'entraine pas l'autre. Ou alors je n'ai pas compris l'explication.

        Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

    • [^] # Re: Et le Mail

      Posté par  . Évalué à 7.

      Le mail est ouvert, oui. Et tellement facile à pirater.

      Mes factures ne concernent que moi, j'ai pas envie que n'importe quel hacker bien outillé puisse se les procurer.

      D'ailleurs, même les mails qui sont sous la forme "vous avez reçu une facture, cliquez ici pour la récupérer" sont déjà la source de sueurs froides de tous les experts en sécurité. Ca habitue l'utilisateur lambda à cliquer sur des liens dans ses mails. Alors que la bonne pratique, encore plus pénible pour l'utilisateur, c'est "vous avez reçu une facture, allez sur notre site web dont vous avez déjà l'adresse pour la récupérer".

      Tant qu'à rêver, moi j'ai un autre rêve. Avoir la possibilité de demander l'envoi des factures (et autres documents) sur un espace de stockage sécurisé. Si je suis motivé, j'auto-herberge ce service. Sinon, je peux faire appel à des prestataires; type "ma banque", ou "mon assurreur", ou "mon fourniseur de cloud"…

      Avec une API standard qui permet de gérer liste blanche/liste noire, l'envoi de documents, la consultation des documents, la définition de la durée de rétention, des règles de classement automatique, etc…

      Et pour passer du rêve à l'utopie délirante, ce type de service pourrait être fourni par l'état pour les plus démunis qui ne peuvent pas se payer ce type de service (critère du genre "non imposable").

      • [^] # Re: Et le Mail

        Posté par  . Évalué à 4. Dernière modification le 05 janvier 2023 à 20:18.

        Ça s’appelle digiposte. Mais ce sera privé, parce qu’un service aussi indispensable permettra de prendre en otage les utilisateurs pour se faire un max de flouze.

        PS : le problème fondamental du mail, c’est qu’il ne garantit pas la réception. En plus faut le sécuriser avec du chiffrement.

        Mort aux cons !

        • [^] # Re: Et le Mail

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

          "Ça s’appelle digiposte. Mais ce sera privé" tu veux dire GMail… C'est la même chose : login/mdp et si c'est piraté… Aujourd'hui les boites mails sont les plus sécurisé (authentification double facteur et plus (lieu, terminal habituel…))

          Et alors La Poste ne garanti pas la réception non plus (sauf recommendé pas utilisé pour les factures)… sauf qu'en pratique, si tu n'a pas reçu une facture ce n'est pas trop difficile de se connecter au site pour une réclamation… et cela n'arrive à peu près jamais.

          Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

          • [^] # Re: Et le Mail

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

            La Poste ne garanti pas la réception non plus

            Avec Digiposte celui qui dépose une facture dedans reçoit une confirmation.

            Après rien ne dit que le propriétaire va consulter son coffre :-)

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

          • [^] # Re: Et le Mail

            Posté par  . Évalué à 3. Dernière modification le 06 janvier 2023 à 17:02.

            L’authentification double facteur n’est pas une garantie de sécurité.
            Les youtubeurs en savent quelque chose. Pourtant c’est aussi du google.

            PS : C’est d’ailleurs ma dernière étape de sécurisation de ma machine, trouver un moyen d’isoler correctement une session firefox anonyme, et une autre qui prend le bancaire, papiers importants (avec chiffrement sur disque des données privées).

            Mort aux cons !

            • [^] # Re: Et le Mail

              Posté par  (site web personnel, Mastodon) . Évalué à 0. Dernière modification le 07 janvier 2023 à 22:31.

              Qu'est ce qu'à de plus ton coffre-fort par rapport à ta boite mail? Pour moi c'est une petite entreprise aux compétences douteuses closed-source. C'est aussi une porte ouverte. J'ai plus confiance en GMail ou Protonmail…

              Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

        • [^] # Re: Et le Mail

          Posté par  . Évalué à 2.

          C'est pas du tout mon rêve ! Gâcheur de rêve !

          Moi, je vise avant tout une norme, avec plusieurs implémentations possibles.

        • [^] # Re: Et le Mail

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

          PS : le problème fondamental du mail, c’est qu’il ne garantit pas la réception.

          Quand le serveur en face répond "250 OK", ça signifie qu'il a accepté l'email.

          Le problème, c'est quand Gmail, Outlook, etc… répondent ainsi, mais jettent silencieusement l'email…

          C'est la faute et la responsabilité du destinataire d'avoir choisi un prestataire email qui choisi de délivrer certains emails, et même de faire croire que l'email sera distribué.

          Bonne journée
          G

          Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

  • # facturation électronique

    Posté par  . Évalué à 9.

    Quel lien avec la dématérialisation des factures à partir du 1er juillet 2024 ?
    Quelques liens :
    https://entreprendre.service-public.fr/actualites/A16076 (dont la section sur les formats de facture)
    https://entreprendre.service-public.fr/actualites/A15683
    La FAQ "Facture électronique" (version du 30/12/2021) (PDF) du ministère des finances

    • [^] # Re: facturation électronique

      Posté par  . Évalué à 1.

      En tout cas cette réforme apportera la solution quant à l'envoi et l'obtention des factures sur une plateforme unique et publique, selon un format normé, disponible via un portail Web, une API ou en EDI.

      Après la réforme ne concerne que les relations B2B, dans des relations franco-françaises.

      Mais on peut imaginer qu'un fournisseur qui émettra des factures dans le cadre de cette réforme à ses clients professionnels émettra ses factures destinées à ses clients particuliers sous le même format (et peut-être même via la plateforme publique, mais je ne crois pas, en l'état de la réforme, que des particuliers pourront se brancher sur cette plateforme pour récupérer les factures).

    • [^] # Re: facturation électronique

      Posté par  . É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.

  • # ticket de caisse électronique

    Posté par  . Évalué à 2.

    quid d'un standard pour recevoir, sans laisser son adresse mail à un tiers, à tous les tiers marchands, une version électronique d'un ticket de caisse, de préférence au format JSON.

    J'ai commencé a faire des specs, moi aussi. Ca doit être sur github.

  • # Cela existe depuis longtemps ...

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

    Bonjour à tous et bonne année 2023, je vous souhaite santé et bonheur ainsi que plein d'énergie pour vos projets.

    Alors il me semble que c'est le but de EDIFACT : https://fr.wikipedia.org/wiki/%C3%89change_de_donn%C3%A9es_informatis%C3%A9es_pour_l%27administration,_le_commerce_et_le_transport

    je ne sais pas si cela fonctionne encore mais dans les années 90 il y avait le principe d'une BAL => boite aux lettres dans lequel des messages pouvait être lu et déposé.

    Pour la sécurité, une carte gérant le protocole X25 et faisant modem plus une couche de sécurité (certainement un cryptage quelconque) devait être ajouté sur le PC qui lui avait un traducteur EDIFAC ou EDIFACT et au final on se retrouvait avec un fichier ASCII importable facilement.

    Alors les communications étaient payantes, les messages aussi mais cela valait le cout pour une entreprise

    Par contre si je me souviens bien, il n'était plus possible d'écrire soi même un traducteur et forcement en acheter un ou devenir 'Tiers de confiance' vis a vis de la norme EDIFACT ce qui devait couter des sous

    J'ai du le mettre en place au moins 1 fois (peut etre plus) et après cela fonctionnait sans problème, c'est d'ailleurs le genre de truc que l'on oublie tellement il marche bien.

    par contre le format interne était du style : (exemple piqué sur wikipedia)

    UNA:+.? '
    UNB+IATB:1+6XPPC:ZZ+LHPPC:ZZ+940101:0950+1'
    UNH+1+PAORES:93:1:IA'
    MSG+1:45'
    IFT+3+XYZCOMPANY AVAILABILITY'
    ERC+A7V:1:AMD'
    IFT+3+NO MORE FLIGHTS'
    ODI'
    TVL+240493:1000::1220+FRA+JFK+DL+400+C'
    PDI++C:3+Y::3+F::1'
    APD+74C:0:::6++++++6X'
    TVL+240493:1740::2030+JFK+MIA+DL+081+C'
    PDI++C:4'
    APD+EM2:0:1630::6+++++++DA'
    UNT+13+1'
    UNZ+1+1'

    bref du xml avant l'heure avec des + au lieu des '<'
    mais comme cela devait gérer différents messages pays devises etc … le format était assez indigeste et surtout sujet a interprétations diverses.

    Mais le principe était pas mal, enfin des BAL pas du reste, il suffit peut être de rajouter une couche "signature" avec du PGP par exemple, lié au document.

    Ce genre de techno devient vite complexe et cela dérape très vite pour devenir du n'importe quoi surtout si tout le monde y met son grain de sable.

    Imaginez le noyau Linux sans Linus Torvalds …

    • [^] # Re: Cela existe depuis longtemps ...

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

      Les normes et standards EDI …que de souvenirs.

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

      • [^] # Re: Cela existe depuis longtemps ...

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

        Oh que oui

        certaines technologies enfouies comme l'EDI ou CFT font certainement tourner une partie de l'économie et cela fonctionne avec des logiciels plus vieux que moi :)

        Ce que je retient surtout c'est l'entraide à l'époque

        pour EDI c'est le directeur info de FRANS BONHOMME de l'époque, j'espère qu'il profite de sa retraite bien méritée, il dirigeait chaque projet de mise en place. Mais quand je dis diriger, il transmettait son expérience et t'apprenais a utiliser et les bases d'EDI, son but que cela fonctionne. J'ai beaucoup appris sur EDI avec lui.

        Pareil pour CFT, quelques personnes m'ont appris les tenants et aboutissants de ce logiciel et je les en remercie.

        On est loin, très loin des pseudos informaticiens qui cherchent des coupables sans proposer de solutions.
        D'ailleurs cela devient tellement courant que même leur mettre le nez dans leur m….. n'est plus rigolo

        Bon j'arrête avant de ficher le bourdon a tout le monde ;)

        • [^] # Re: Cela existe depuis longtemps ...

          Posté par  . Évalué à 2.

          Je confirme, EDIFACT fait encore fonctionner des infrastructures assez critiques ;-)

          Et c'est toujours autant une tannée à lire :D

  • # En suisse...

    Posté par  . Évalué à 10. Dernière modification le 06 janvier 2023 à 09:40.

    En Suisse, on a le système "e-bill" présent chez (presque) toutes les banques: une fois que tu ajoutes le fournisseur (telecom, énergie, whatever) au système "e-bill" dans ton e-banking, le fournisseur envoi la facture électronique directement dans ton e-banking ! Donc tu ne te connecte qu'à un seul endroit (ta banque) et tu vois/valides toutes tes factures.

    https://www.ebill.ch/fr/clients-prives.html

    et y'a meme un side de démo : https://ebill.ch/ebill-portal/ui/payments/by-due-date

    • [^] # Re: En suisse...

      Posté par  . Évalué à 4.

      C'est intéressant comme manière de faire … ainsi le banquier qui savait que j'avais dépensé 19,99€ chez mon opérateur de téléphone "avant" sait maintenant aussi à qui j'ai téléphoné grâce à la partie détaillée de ma facture qu'il absorbe au vol.

      Alors non, pour moi ce n'est pas du tout le modèle de société que je souhaite avoir.

      Je veux pouvoir avoir mes factures chez moi (et d'une manière générale "mes documents" chez "moi") …

      Par contre peut-être que e-bill est lié au fait que tous les fournisseurs respectent une API permettant aux banque de ne pas avoir à développer autant de "connecteurs" que de "fournisseurs" (ce qui semblerait assez évident vu que les banques n'aiment pas perdre du temps et donc de l'argent pour rien).

      Je vais aller voir tout ça : Merci pour l'info

      eric.linuxfr@sud-ouest.org

      • [^] # Re: En suisse...

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

        grâce à la partie détaillée de ma facture qu'il absorbe au vol.

        Tu flingues une solution sous excuse qu'un de tes fournisseur fait des conneries (une facturer c'est pour facturer, la partie détaillée n'a rien à faire la). Plouf. Même sans ce truc c'est juste pourri de mélanger 2 choses comme ça.

        Je veux pouvoir avoir mes factures chez moi (et d'une manière générale "mes documents" chez "moi") …

        Libre à toi de faire comme avant, c'est n'est (pour le moment du moins) interdit, ça ne change pas le sujet ici qui s’intéresse à d'autres choses (être pratique pour la masse qui n'a pas ces "contraintes").

        L'idée est pas mal, mais comme d'hab chaque pays fait dans son coin… un jour on réfléchira à ne pas démultiplier les solutions… Genre un truc européen déjà pour commencer, vu que Suisse ou UE on a la même culture (on a déjà l'IBAN et SEPA ensemble, on sait qu'on peut y arriver :) ) la dessus (les US c'est encore autre chose, mais aussi si on peut…)

        • [^] # Re: En suisse...

          Posté par  . Évalué à 1.

          D'ailleur, je confirme pour mon cas (mon opérateur télécom / ma banque) : pas de facture détaillée (ni communication, ni data).

          Je veux pouvoir avoir mes factures chez moi (et d'une manière générale "mes documents" chez "moi") …

          Conernant les factures, tu peux les télécharger. J'ai fait ça pendant longtemps. Je ne le fait plus. Si demain je veux changer de banque, je téléchargerai les factures passées, en attendant elles sont là (sans compter que la plupart du temps elles sont bien évidement aussi dispo sur le site du fournisseur de service).

          bref, je ne dis pas que c'est parfait. Je dis que c'est super pratique.

        • [^] # Re: En suisse...

          Posté par  . Évalué à 9.

          Heu Zenitram, tu peux regarder tes factures ?

          Parceque-moi toutes les factures fournisseurs que je vois passer listent précisément tous les trucs qui sont achetés … oui j'ai pris une facture de tel comme exemple mais regarde une facture de ton magasin de matériel de bricolage, de fournitures etc.

          Moi je veux bien que la banque sache que j'ai dépensé 2000€ chez le roi du merlin mais je n'ai pas forcément envie qu'il sache précisément ce que j'ai acheté, tu vois la fuite de données au passage et les conséquences ?

          Allez, une facture d'un hébergeur de serveurs en trois lettres, je n'ai pas forcément envie que mon banquier ait la liste de toutes les IP des serveurs que je loue …

          Et je reste super soft, le contenu des factures c'est très très révélateur de beaucoup de choses, que ça soit au niveau pro ou au niveau perso.

          (Je ne veux pas détourner le sujet mais j'ai la même réaction par rapport à la fin des tickets papiers et qu'on te propose d'envoyer par mail, allez hop le facteur sait maintenant ce qu'il y a dans ton caddie.)

          Donc pardon d'avoir "flingué une solution sous excuse qu'un de tes fournisseur fait des conneries" mais mon exemple était pourris et tu t'es pris dedans :)

          eric.linuxfr@sud-ouest.org

          • [^] # Re: En suisse...

            Posté par  (site web personnel) . Évalué à 5. Dernière modification le 06 janvier 2023 à 12:17.

            Parceque-moi toutes les factures fournisseurs que je vois passer listent précisément tous les trucs qui sont achetés

            J'ai réagi sur "sait maintenant aussi à qui j'ai téléphoné", certains font ça mais d'autres font surtout "X appels nationaux, Y SMS" car on se fout de à qui pour facturer.

            Moi je veux bien que la banque sache que j'ai dépensé 2000€ chez le roi du merlin mais je n'ai pas forcément envie qu'il sache précisément ce que j'ai acheté, tu vois la fuite de données au passage et les conséquences ?

            L'argument devient plus valable, et on va vers le RGPD (oui, il faut alors faire "confiance"), là on peut débattre (et la je suis votre conversation passivement, parce que bon, si par mail l'hébergeur mail peut aussi lire, je ne suis pas sûr que ce soit mieux pour la masse qui n'a pas d'auto-hébergement) sur ça (et pas "mais il peut techniquement", plutôt sur le légal SVP…).

            (Je ne veux pas détourner le sujet mais j'ai la même réaction par rapport à la fin des tickets papiers et qu'on te propose d'envoyer par mail, allez hop le facteur sait maintenant ce qu'il y a dans ton caddie.)

            Allez, je m'enfonce, par exemple :-p.

      • [^] # Re: En suisse...

        Posté par  . Évalué à 4.

        C'est intéressant comme manière de faire … ainsi le banquier qui savait que j'avais dépensé 19,99€ chez mon opérateur de téléphone "avant" sait maintenant aussi à qui j'ai téléphoné grâce à la partie détaillée de ma facture qu'il absorbe au vol.

        Alors en pratique, la banque chez moi affiche seulement un menu avec une liste de factures a approuver ou non. Si je veux en savoir plus, je suis redirige vers une page contenant une iframe qui tape chez ebill.ch.

        Donc en pratique le banquier ne sait pas forcement grand chose, par contre l’intermédiaire eBill, s'il s'amuse a faire de l'OCR sur les pdfs, peut effectivement recuperer des informations.

        Apres, il faudrait lire le contrat de confidentialité, mais dans la FAQ, on trouve déjà ceci:

        Toutes les banques ainsi que SIX sont tenues d’assurer la confidentialité des données enregistrées et de les utiliser uniquement pour fournir le service eBill.

    • [^] # Re: En suisse...

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

      C'est pareil en Belgique avec Zoomit https://www.zoomit.be/fr/

      Je reçoit mes factures d’énergie, télécom, taxe poubelle etc

      • [^] # Re: En suisse...

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

        Je sais que le coq gaulois est le seul animal à chanter les pieds dans la m…..
        et
        que l'on a tendance a se prendre pour le centre du monde, mais chaque fois qu'il y a de bonnes idées c'est déjà en place chez nos voisins Suisses et/ou Belges.

        C'est Dredi !

        • [^] # Re: En suisse...

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

          En l'occurrence, ce n'est pas du tout une bonne idée (pour les raisons de vie privée déjà exposées) et il est tout à fait justifié de la critiquer.

          • [^] # Re: En suisse...

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

            Toute bonne idée a son coté sombre …

            C'est juste que certains font et réfléchisse après, d'autres réfléchisse et ne font pas

            d'où l'intérêt de voir ce que font les copains, de critiquer et éventuellement de faire :)

  • # Après avoir consulter le site

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

    Bonjour,

    j'aime beaucoup ton initiative et après avoir lu le site obapi.org j'aurais quelques suggestions basiques d'ordre général

    entête / ligne / total : tout fichier véhiculant des données importantes devrait être munis de ceci, cela a plusieurs avantages

    d'abord même si on ne transmets rien, il y a au moins une entête et un total
    ainsi même le "rien" existe quand tu fais du transfert de fichier c'est important.
    Si je ne dois "rien" recevoir cela doit être formalisé, sinon l'absence de fichier est une erreur.

    L’entête rappelle le destinataire et d'autres informations
    le total rappelle le nombre de lignes et quelque chose pour valider le contenu
    cela permet de rejeter un fichier incorrect ou incomplet, ou de le traiter différemment

    Ensuite chaque fichier devrait pouvoir être signé par l'émetteur, comme avec PGP par exemple, les signatures de ce style sont intéressantes car les clés peuvent être de PROD de TEST etc …

    Bon courage

  • # contacte Akretion

    Posté par  . Évalué à 4.

    Il me semble que l'équipe d'Akretion, qui travaille sur Odoo, a commencé un projet similaire (avec Alexis de Lattre) pour récupérer ses factures. Ça pourrait les intéresser.

    Très bonne idée en tout cas.

  • # Un grand oui

    Posté par  . Évalué à 4. Dernière modification le 06 janvier 2023 à 16:11.

    C'est à mon sens une excellente idée, qui me trotte également dans la tête depuis quelques temps. Et en tant que dev, je serai ravi de pouvoir participer.

    Simple suggestion : je vois qu'il existe deux ressources distinctes pour les représentations JSON des factures et le téléchargement du PDF. Il s'agit pourtant conceptuellement de la même ressource. Ne serait-il pas plus simple de pouvoir préciser dans le header accept le format souhaité ?

    # Liste des factures en JSON
    GET {apiRoot}/invoices
    Accept "application/json"
    
    # Détail d'une facture en JSON
    GET {apiRoot}/invoices/{idFacture}
    Accept "application/json"
    
    # Détail d'une facture en PDF
    GET {apiRoot}/invoices/{idFacture}
    Accept "application/pdf"
    

    La norme Obapi pourrait dans ce cas préciser que proposer une représentation PDF de la facture est obligatoire.

  • # Quelques remarques

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

    Excellente idée globalement. Quelques remarques toutefois.

    "endpoint /obapi/v1" C'est toujours une mauvaise idée d'avoir un préfixe de chemin en dur dans une norme. Le RFC 9205 explique pourquoi.

    "errors attributes" Pourquoi ne pas s'appuyer sur le RFC 7807 plutôt que de re-développer une convention ?

    La partie sur l'authentification me parait casse-gueule car elle réinvente un protocole de sécurité, ce qui est toujours dangereux. Je préférerai qu'on dise simplement qu'on mette la clé d'EPI dans l'en-tête. Et que l'obtention de la clé d'API dépend du fournisseur.

  • # Actualisation du 7 janvier

    Posté par  . Évalué à 3.

    Alors,
    suite à vos remarques et mails reçus échangés, j'ai un peu chamboulé le site obapi.org pour rester à l'expression de l'idée et une sorte de "démonstration" pour ne pas m'enliser dans une sorte d'implémentation qui nuirait à l'objectif du projet.

    J'ai pris contact avec https://www.openapis.org/ pour voir s'ils ont un groupe de travail sur le sujet en espérant que si oui il soit plus avancé que https://github.com/OAI/sig-finance

    eric.linuxfr@sud-ouest.org

  • # remarques

    Posté par  . Évalué à 2.

    Au sujet d'un éventuel logiciel collecteur de facture, ce qui serait pas mal serait de pouvoir ajouter les informations de paiement au delà du statut "payé".

    Je dirais que c'est l'intérêt que je vois a un logiciel de ce genre la: si je suis relancé a propos d'une facture, je peux de suite sortir un numéro de virement.

    Autre petit truc aussi, gérer les relances, notamment celles qui sont avec 10 balles en plus ?

  • # publique visé?

    Posté par  . Évalué à 1. Dernière modification le 09 janvier 2023 à 22:44.

    Une interrogation qui me vient à l’esprit, le public visé est personel ou professionnel ?

    Personnellement, ce que je cherche est effectivement quelque chose comme CozyCloud/Woob mais qui fonctionne en permanence (liste facture seul) ou un Kresus/Woob (liste des opérations sur mon compte en lecture seule) mais qui utiliserait un chiffrement à jours pour se connecter à ma Banque.
    Impossible de retrouver rapidement, la modification que j’ai dû faire à mon « YunohostBanque » ( il n’y a qu’une application : Kresus) mais de mémoire j’ai dû accepter de baisser les paramètres SSL pour que ca fonctionne …

    Pour les professionnels je dirais que l’on pourrait aussi relancer les impayés, autoriser le paiement ou non etc. Il me semble qu’il existe déjà des outils qui ont ces fonctionnalités, il me semble en avoir vu des publicités, mais je ne sais pas du tout comment ils fonctionnent.

  • # EDF : un mail, un clic

    Posté par  . Évalué à 2.

    je viens de recevoir un mail de la part de mon fournisseur d'électricité ; il s'agit d'EDF.

    en lisant rapidement le message, je vois que je peux acceder à ma dernière facture avec un lien de la forme :

    https://espace-securise.edf.fr/services/rest/tunnel/facture-electronique?token=big-token

    et la formulation :

    Bonjour Madame, Monsieur ...,
    
    Votre nouvelle facture et votre bilan personnalisé « MA CONSO & MOI » 
    sont disponibles , téléchargez les en cliquant sur ce "lien" . 
    

    il y a donc un service REST ; mais j'imagine que l'API n'est pas publique. A surveiller.

Suivre le flux des commentaires

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