Pourquoi l'architecture de paiement actuelle est fragile
Dans la majorité des systèmes actuels, la condition est externe, la validation est fragmentée, la preuve est reconstruite a posteriori et la décision transactionnelle reste implicite. Axokey® comble structurellement ce vide.
- Condition externe au paiement — non encapsulée
- Décision transactionnelle dispersée entre acteurs
- Preuve reconstruite a posteriori depuis des logs
- Exécution possible sans cohérence native
- Litige impossible à résoudre sans reconstruction
- Aucune norme ne définit la preuve de consommation d'une offre prépayée
- Phase intermédiaire entre décision et exécution : non structurée
- Structuration ex-ante du paiement dès la proposition d'offre
- Lien natif entre événement réel et exécution financière
- Code rattaché à la transaction gouvernée
- Preuve intégrée à la logique transactionnelle — native
- Réversion gouvernée, horodatée, opposable
- Dossier probatoire non monétaire encapsulé — aucune antériorité identifiée
- État intermédiaire gouverné : cœur fonctionnel du brevet
De l'intention à la preuve — en une séquence gouvernée
Quatre phases structurent chaque transaction. Les détails d'implémentation restent encapsulés dans le moteur propriétaire.
La transaction est définie et sécurisée avant tout effet irréversible. Les parties, le montant, les conditions et la fenêtre temporelle sont encapsulés dans un objet gouverné non modifiable.
Le paiement existe mais ne peut être libéré que par un événement réel vérifiable. Un signal unique est émis, lié à la transaction. Il ne peut être réutilisé ni transféré hors contexte.
L'événement est reçu, horodaté et vérifié avant toute exécution. Si toutes les conditions sont remplies, l'effet transactionnel est autorisé. Sinon, la transaction est réversée automatiquement.
Un dossier de preuve natif est généré automatiquement à la clôture. Il est opposable immédiatement en contexte d'audit, de litige ou de supervision réglementaire. La preuve n'est jamais reconstruite a posteriori.
Des extensions techniques complémentaires — déposées à l'international en 2025 — élargissent la portée du procédé. Détails confidentiels jusqu'à publication.
Trois garanties natives pour chaque transaction
Les fonds sont réservés et la transaction est définie avant tout effet irréversible.
Chaque effet transactionnel est conditionné à un événement réel vérifiable. Exécution ou réversion — jamais d'ambiguïté.
Un dossier natif est généré à la clôture, disponible immédiatement pour audit réglementaire ou résolution de litige.
Chaque bloc Axokey® répond à une exigence précise
Axokey® répond directement aux exigences des principales réglementations européennes sur les paiements, la donnée et la conformité.
| Réglementation | Lacune identifiée | Bloc Axokey · Mécanisme de satisfaction |
|---|---|---|
| ACPR Autorité de Contrôle Prudentiel et de Résolution — Superviseur bancaire et assurantiel français Art. L521-1 · L522-17 CMF |
Traçabilité opération à reconstruire Séparation des fonds non normalisée |
Dossier probatoire Enregistrement natif complet Réservation conditionnelle Séquestre normatif avant transfert |
| DSP2 / DSP3 Directive sur les Services de Paiement — Cadre européen régissant les paiements électroniques |
Pas de gouvernance entre initiation et exécution Absence d'état intermédiaire défini Preuve de consommation non standardisée |
Phase intermédiaire gouvernée Phase intermédiaire gouvernée Réservation conditionnelle Réservation conditionnelle Dossier probatoire Preuve native opposable |
| AML / LCB-FT Anti-Money Laundering / Lutte Contre le Blanchiment — Prévention du blanchiment et financement du terrorisme AMLD · CMF |
Traçabilité de la chaîne des flux à reconstruire Identification des parties non encapsulée |
Identification des parties Anonymisation dès l'engagement Dossier probatoire Conservation 5 ans — dossier natif Vérification ex-ante Anomalies journalisées |
| eIDAS 2.0 Electronic IDentification Authentication and trust Services — Identité numérique européenne et signatures électroniques |
Identité non liée à un processus transactionnel Pas de preuve opposable intégrée au cycle |
Identification des parties Identité anonymisée dès l'engagement Horodatage sécurisé Horodatage opposable Dossier probatoire Non-répudiation complète |
| DORA Digital Operational Resilience Act — Résilience opérationnelle numérique du secteur financier (en vigueur jan. 2025) En vigueur jan. 2025 |
Gouvernance transactionnelle en environnement contraint non couverte Continuité et intégrité transactionnelle en contexte dégradé non définie |
Résilience transactionnelle Maintien de la cohérence transactionnelle dans différents contextes opérationnels Intégrité du dossier Non altérable lors de toute transition d'état |
| RGPD Règlement Général sur la Protection des Données — Protection des données personnelles des citoyens européens |
Données transactionnelles non minimisées Finalité diffuse entre acteurs |
Dossier probatoire Minimisation par conception Horodatage sécurisé Durée de vie délimitée Identification des parties Accès contrôlé par partie |
| MiCA Markets in Crypto-Assets — Cadre réglementaire européen pour les actifs numériques |
Pas de validation conditionnelle d'usage des actifs Traçabilité de consommation non définie |
Réservation conditionnelle Conservation conditionnelle structurée Dossier probatoire Preuve d'usage effectif de l'actif |
| AI Act Règlement européen sur l'Intelligence Artificielle — Gouvernance des systèmes d'IA dans les processus décisionnels |
Décisions automatisées sans gouvernance transactionnelle Pas de preuve opposable des décisions exécutées |
Phase intermédiaire gouvernée Supervision avant exécution Dossier probatoire Traçabilité native des mécanismes d'analyse et de validation encadrés Décision conditionnelle Blocage si conditions non remplies |
| FIDA Financial Data Access — Accès aux données financières dans le cadre de l'Open Finance européen (Règl. UE 2023/2225) Financial Data Access · Règl. UE 2023/2225 |
Accès aux données financières sans gouvernance transactionnelle associée Absence de preuve opposable des interactions Pas de conditionnalité sur l'usage des données partagées |
Dossier probatoire Traçabilité native des flux liés aux échanges de données Identification des parties Routage et identification des parties Réservation conditionnelle Conditionnalité sur l'usage des données Horodatage sécurisé Horodatage opposable de chaque interaction |
| ISO 20022 Standard international de messagerie financière — Format structuré pour les transactions bancaires |
Messages standardisés mais pas d'états transactionnels Pas de logique conditionnelle d'exécution |
Phase intermédiaire gouvernée Couche gouvernance complémentaire Décision conditionnelle Validation conditionnelle normalisée |
L'architecture Axokey® assure la cohérence transactionnelle dans différents contextes opérationnels, sans modification de l'infrastructure existante.
10 cas d'usage directement applicables
Chaque use case est une application directe de FR3055722 ou de son extension internationale. Le flux complet est applicable à chaque cas sans modification de l'architecture.
Paiement à l'ouverture
Le déclenchement du paiement est conditionné à un événement physique vérifiable — ouverture d'un casier, d'une serrure connectée, d'un véhicule ou d'un espace. Les fonds sont réservés à la réservation et libérés uniquement à l'accès effectif.
- Fonds réservés dès la réservation — non transférés
- Code ou signal NFC/QR/BLE généré et lié à la transaction
- Vérification ex-ante à l'ouverture ou à l'accès
- Paiement déclenché à l'événement physique confirmé
- Timeout ou non-accès → restitution automatique
de validation
L'exécution du paiement est conditionnée à la saisie d'un code secret remis à la livraison ou réalisation de la prestation. Cas générique du brevet.
- Code généré, rattaché à la transaction, transmis à l'acheteur
- Saisie du code = événement déclencheur (DT)
- Vérification : code valide ? dans la fenêtre ? identité ?
- Paiement exécuté sur confirmation
- Code incorrect ou délai expiré → réversion
confirmée
Le vendeur n'est payé qu'à la confirmation de livraison effective. Fonds réservés dès la commande — transférés à la preuve physique de remise.
- Fonds réservés dès la commande
- Scan livreur ou API transporteur = événement de confirmation
- Vérification : livraison dans les délais ?
- Vendeur payé · Preuve de livraison archivée
- Non livré → réversion auto, client remboursé
Commande groupée
Une seule transaction orchestre plusieurs vendeurs. Chaque vendeur est payé séparément selon ses propres conditions. Réversion partielle possible.
- Transaction unique · Réservation par vendeur
- Conditions indépendantes par section
- Vendeur A payé à sa livraison — B toujours en attente
- Déclenchement partiel supporté nativement
- Réversion partielle si vendeur B en défaut
Bon d'intervention
L'artisan ou freelance est payé immédiatement à la signature du bon d'intervention numérique. Fonds réservés dès la commande.
- Montant réservé à la commande
- Fin d'intervention → client signe le bon numérique
- Signature = déclencheur (DT)
- Artisan payé instantanément
- Non réalisé dans le délai → remboursement client
Origine du brevet
Cas fondateur de FR3055722. Le paiement d'une activité est conditionné à la participation effective — scan QR de présence.
- Réservation → fonds réservés, code de présence généré
- Jour J : participant présent → scan QR
- Vérification : présence dans la fenêtre horaire ?
- Organisateur payé · Preuve de présence archivée
- Absent → réversion selon conditions définies
Caution conditionnelle
La caution est réservée et gérée de façon conditionnelle. Restituée automatiquement à la restitution en bon état — encaissée avec preuve si sinistre constaté.
- Caution réservée — non encaissée
- Retour → état vérifié (photos, scan, agent)
- Bon état → caution restituée au locataire
- Sinistre → caution déclenchée · Preuve archivée
- Retard → pénalité proportionnelle calculée
conditionnel à l'usage
Le prélèvement n'intervient que si le service a été utilisé au-delà d'un seuil défini. Protection native contre les prélèvements abusifs.
- Montant réservé pour la période
- Bilan d'usage transmis en fin de période
- Vérification : seuil atteint ? usage conforme ?
- Prélèvement déclenché si seuil validé
- Sous le seuil → pas de prélèvement ou remboursement
Établissement bancaire
Chaque remboursement conditionné à la vérification des conditions d'éligibilité. Dossier de preuve natif pour audit ACPR sans reconstruction.
- Règles de remboursement formalisées dans la transaction
- Client envoie preuve → événement de confirmation
- Vérification : conditions remplies ? délais ? fraude ?
- Remboursement exécuté · Dossier natif pour audit
- Conditions non remplies → blocage motivé · Preuve du refus
sécurisée
Le système Axokey® applique une logique de contrôle transactionnel dans différents contextes opérationnels. Les conditions sont vérifiées avant validation et maintenues tout au long du cycle.
- Transaction structurée en amont — indépendante du canal
- Conditions de validation maintenues dynamiquement
- Vérification préalable à l'exécution
- Intégrité des données garantie
- En cas d'anomalie → gestion automatisée de l'état transactionnel
Valeur ajoutée Axokey® par rapport aux solutions existantes
Les solutions actuelles gèrent le paiement après la décision. Axokey® structure la décision elle-même.
| Capacité | PSP classique | Escrow / Tiers | Axokey® |
|---|---|---|---|
| Condition liée au paiement | ✗ | ~ | ✓ |
| Vérification avant exécution | ✗ | ✗ | ✓ |
| Preuve native (non reconstruite) | ✗ | ~ | ✓ |
| Réversion automatique gouvernée | ✗ | ~ | ✓ |
| Multi-acteurs natif | ✗ | ✗ | ✓ |
| Opposabilité immédiate | ✗ | ~ | ✓ |
| Sans modification d'infrastructure | ✓ | ✗ | ✓ |
| Brevet délivré | ✗ | ✗ | ✓ FR3055722 |
Pourquoi le paiement conditionné change tout
Des millions de transactions chaque jour sans gouvernance entre la décision et l’exécution. Axokey® y répond directement.
Accès avancé sur demande
Un accès encadré à un scénario Axokey adapté à votre cas d'usage, sans exposition du moteur propriétaire ni des mécanismes internes.
Testez l'effet Axokey sur votre propre cas d'usage.
L'accès avancé permet à un acteur qualifié de découvrir une démonstration adaptée à son contexte métier : paiement conditionnel, validation de prestation, livraison, marketplace, remboursement ou consigne.
Nous identifions le contexte, les acteurs, l'événement déclencheur et le résultat attendu.
Un parcours limité est configuré pour illustrer la condition, la décision, le déclenchement ou le blocage.
Une lecture métier est fournie : bénéfices, limites, potentiel d'intégration et suite possible.
- ✓Échange préalable de qualification
- ✓Scénario métier adapté
- ✓Démonstration guidée
- ✓Résultat conditionnel : validation ou blocage
- ✓Preuve simplifiée non technique
- ✓Orientation vers un Pilot personnalisé
- ✗Accès au moteur Axokey
- ✗Accès au code source
- ✗Remise des règles internes
- ✗Documentation technique complète
- ✗Spécifications d'intégration API
- ✗Licence d'exploitation
Demande d'accès avancé
L'accès avancé est réservé aux acteurs souhaitant explorer un cas d'usage concret.
Licences
Tarification sur mesure selon le périmètre d'usage, le volume transactionnel et le contexte d'intégration.
FR3055722 · Brevet 2 déposé à l'international · Extensions techniques confidentielles.