Le produit en détail

Décrire un produit sans le montrer n'engage à rien. Cette page donne le code réel, les états réellement affichés, et ce que le journal contient. Rien d'ici n'est une maquette.

1. Ce que vous insérez dans votre application

Une balise de script, configurée par deux attributs. C'est l'intégralité de l'intégration côté éditeur :

<!-- dans la page où votre client valide sa facture -->
<script src="https://app.factiflow.fr/widget.js"
        data-worker-url="https://app.factiflow.fr"
        data-partner-id="votre-identifiant-editeur"></script>

Le composant s'insère à l'endroit de la balise. Il pèse moins de 5 Ko transférés (compression Brotli) et ne contient aucun secret : la clé qui signe les accusés reste côté serveur, le composant ne détient que la clé publique qui lui permet de vérifier une signature.

2. Le contexte que votre logiciel fournit

Pour transmettre une facture, une plateforme agréée a besoin de savoir qui émet et à qui. Votre logiciel possède déjà ces données : il les expose dans une variable, relue à chaque envoi — ce qui vous permet de la changer d'une facture à l'autre.

window.Relaiflow = {
  contexte: {
    seller_reg_no: "123456789",        // SIREN/SIRET de l'entreprise émettrice
    client: {
      name:            "Entreprise Cliente SAS",
      reg_no:          "987654321",
      vat_number:      "FR12987654321",
      billing_address: { /* adresse de facturation */ },
      emails:          ["compta@exemple.fr"]
    }
  }
};

Nous ne fabriquons aucune donnée client. Ce que vous fournissez est transmis tel quel. Si une information manque et qu'elle est requise par la plateforme, la transmission est refusée avec un motif explicite — plutôt que de deviner une valeur et de produire une facture fausse dans la comptabilité de votre client.

3. Ce que votre utilisateur final voit

Le composant affiche un état, et un seul à la fois. Voici les libellés réels, dans l'ordre du cycle de vie :

4. Le journal d'audit

Chaque facture produit une trace : identifiant, horodatage de chaque transition, nombre de tentatives, code d'erreur éventuel avec le message de la plateforme, et l'identifiant que la plateforme lui a attribué.

L'accusé est un jeton signé (JWT, algorithme ES256). Concrètement : la signature est produite par une clé privée que seul notre serveur détient, et n'importe qui peut la vérifier avec la clé publique. Un accusé ne peut donc pas être fabriqué après coup — ni par vous, ni par nous.

// Ce qu'un accusé contient (charge utile du jeton)
{
  "invoice_id": "a3f9…",       // identifiant de la facture
  "status":     "transmitted", // l'état attesté
  "tenant":     "votre-identifiant",
  "iat": 1760000000, "exp": 1760086400
}

5. Ce que vous voyez, vous, éditeur

Une interface de consultation donne l'état du parc : vos clients raccordés, leurs factures récentes avec statut et nombre de tentatives, les erreurs avec leur motif, et les connexions aux plateformes qui demandent une réautorisation.

Deux partis pris, assumés :

• Consultation seule. Aucune action destructrice n'est possible depuis cette interface — on n'y supprime ni facture, ni licence.
• Aucun jeton n'y transite. Les jetons d'accès des plateformes ne sont jamais renvoyés par l'interface, même partiellement. C'est vérifié automatiquement à chaque mise en production.

6. Ce qui se passe quand ça se passe mal

7. L'état réel du produit

Diagnostic en 5 questions ou calculer ce que vous coûte votre solution actuelle →