Oracles et interopérabilité blockchain : relier vos systèmes à des données exploitables et vérifiables.
Une donnée extérieure ne devient pas fiable simplement parce qu'elle arrive sur une blockchain.
Sources, contrôles, transmission, conséquences : nous concevons le passage des informations entre vos systèmes, les réseaux et vos smart contracts, en définissant ce qui fait foi à chaque étape.
Illustration en six étapes. 1. Le système d'un transporteur fictif déclare l'expédition EX-118 « livrée ». 2. L'intégration contrôle l'origine : source reconnue, signature vérifiée. 3. Elle contrôle le contenu : information récente, données concordantes. 4. Un oracle publie la donnée vérifiée, avec son origine et son horodatage. 5. La donnée franchit la frontière de la chaîne : le contrat la lit et vérifie sa condition, livrée avant l'échéance. 6. La condition est constatée : l'étape de facturation peut s'ouvrir, sous réserve des règles métier. Une déclaration de livraison ne prouve pas, à elle seule, la livraison.
À retenir : une déclaration de livraison ne prouve pas, à elle seule, que la livraison a eu lieu. Les contrôles établissent d'où vient l'information et qu'elle respecte les règles prévues ; le contrat constate ce que la source affirme.
Le point de passage, en six étapes
Une blockchain ne voit que ce qu'on lui transmet, alors chaque donnée doit avoir une origine claire.
Un smart contract applique ses règles aux seules données présentes sur la chaîne. Une livraison, un cours, une mesure ou une décision prise ailleurs doivent lui être transmis, et il ne peut pas vérifier seul qu'ils sont exacts.
Ce que le contrat sait faire
- Appliquer une règle identique pour tous.
- Garder la trace de ce qu'il a reçu et décidé.
- Refuser une donnée qui ne vient pas d'une source autorisée.
Ce qu'il ne sait pas faire seul
- Consulter un système extérieur.
- Savoir si un événement a vraiment eu lieu.
- Choisir entre deux sources contradictoires.
- Attendre une donnée absente sans règle prévue.
Les règles elles-mêmes relèvent de la conception des smart contracts. Une donnée de marché, pour la finance décentralisée, ou une mesure de traçabilité, pour la santé, pose les mêmes questions d'origine.
Sources, oracles et vérifications : ce qui rend une donnée exploitable.
Un oracle est un mécanisme qui transmet une information extérieure à la blockchain. Il ne la rend pas vraie : sa valeur dépend de ce qui est vérifié avant et de ce qui est prévu après.
Avant l'envoi : la source
- La source choisie, et qui en répond.
- Sa disponibilité, et ce qui est prévu si elle se tait.
- Le contrôle de son origine : émetteur autorisé, déclaration signée lorsque le mécanisme le prévoit.
Au passage : le contenu
- La fraîcheur : un délai de validité fixé pour chaque information.
- La cohérence : plusieurs relevés concordants, des valeurs plausibles.
- Les modalités de transmission : qui publie, à quel rythme, une ou plusieurs sources.
Après la réception : les conséquences
- Le traitement des données absentes ou contradictoires.
- Les conséquences prévues dans le contrat.
- La reprise et la supervision, selon le périmètre convenu.
Ce que chaque contrôle établit
- Source reconnue
- établit que la déclaration vient d'un système autorisé ; n'établit pas, à lui seul, que son contenu est vrai.
- Signature vérifiée
- établit l'origine et l'intégrité du message ; n'établit pas, à lui seul, que l'événement a eu lieu.
- Information récente
- établit qu'elle respecte le délai de validité prévu ; n'établit pas, à lui seul, qu'elle est exacte.
- Données concordantes
- établit qu'elle correspond aux règles et aux autres relevés ; n'établit pas, à lui seul, que l'événement est réel.
Même événement, plusieurs qualités d'information : votre contrat ne décide que sur une donnée qui passe les contrôles.
Un système extérieur doit transmettre le statut de l'expédition EX-118 à un contrat qui constate, ou non, une livraison dans les délais. Choisissez une situation : la source, les contrôles, ce que reçoit le contrat et ce qu'il décide changent. Scénario fictif : aucune source, aucun oracle, aucun réseau réels.
Le point de passage · ce que vérifie l'intégration, avant tout envoi
Source reconnue
passé
Transports Ardent, émetteur autorisé
Origine contrôlée
passé
déclaration signée par son émetteur
Fraîcheur
passé
émise dans le délai de validité
Cohérence
passé
concorde avec le relevé de l'entrepôt
Ce que fournit la source
Statut « livrée », déclaré par le système du transporteur dans le délai prévu.
Ce que reçoit le contrat
Statut « livrée », avec son horodatage et son origine, publiés par le service d'intégration.
Ce que le système décide
Condition constatée : livrée dans les délais
Le contrat enregistre la constatation ; l'étape de facturation peut s'ouvrir. Aucune facture n'est émise, aucun paiement n'est fait : les règles métier et les validations prévues s'appliquent ensuite.
En attente ou à traiter
Rien à traiter. Une contestation reste possible selon le contrat : la déclaration ne prouve pas, à elle seule, la livraison.
La règle de conception
Le contrat constate ce que la source affirme, dans la limite des contrôles prévus. Il ne prouve pas la réalité de l'événement.
Les cinq situations, et ce que décide le système :
Information conforme
- Le point de passage : Source reconnue passé ; Origine contrôlée passé ; Fraîcheur passé ; Cohérence passé.
- Ce que reçoit le contrat : Statut « livrée », avec son horodatage et son origine, publiés par le service d'intégration.
- Ce que le système décide : Condition constatée : livrée dans les délais. Le contrat enregistre la constatation ; l'étape de facturation peut s'ouvrir. Aucune facture n'est émise, aucun paiement n'est fait : les règles métier et les validations prévues s'appliquent ensuite.
- En attente ou à traiter : Rien à traiter. Une contestation reste possible selon le contrat : la déclaration ne prouve pas, à elle seule, la livraison.
Information absente
- Le point de passage : Source reconnue en attente ; Origine contrôlée non atteint ; Fraîcheur non atteint ; Cohérence non atteint.
- Ce que reçoit le contrat : Rien. Le contrat ne reçoit aucune donnée.
- Ce que le système décide : Aucune décision définitive. La condition n'est ni constatée ni rejetée : l'absence de donnée ne vaut pas « non livrée ». L'étape de facturation reste fermée.
- En attente ou à traiter : Nouvelle tentative prévue ; alerte à l'équipe désignée si la source reste muette au-delà du délai convenu.
Information trop ancienne
- Le point de passage : Source reconnue passé ; Origine contrôlée passé ; Fraîcheur refusé ; Cohérence non atteint.
- Ce que reçoit le contrat : Rien. Un statut périmé n'est pas transmis comme s'il était actuel.
- Ce que le système décide : Information écartée, actualisation attendue. Le contrat ne conclut ni à une livraison, ni à un retard. L'étape de facturation reste fermée.
- En attente ou à traiter : Mise à jour demandée à la source, ou vérification complémentaire par l'équipe logistique, selon la règle définie.
Informations contradictoires
- Le point de passage : Source reconnue passé ; Origine contrôlée passé ; Fraîcheur passé ; Cohérence refusé.
- Ce que reçoit le contrat : Rien. Aucune des deux valeurs n'est transmise.
- Ce que le système décide : Conflit signalé, aucune valeur choisie au hasard. Le contrat ne tranche pas à la place des parties. L'étape de facturation reste fermée.
- En attente ou à traiter : Arbitrage selon la règle prévue au contrat : vérification humaine, source prioritaire convenue, ou attente d'un nouveau relevé.
Source inconnue
- Le point de passage : Source reconnue refusé ; Origine contrôlée non atteint ; Fraîcheur non atteint ; Cohérence non atteint.
- Ce que reçoit le contrat : Rien. L'information est rejetée avant tout envoi.
- Ce que le système décide : Information rejetée. Le contrat n'est pas sollicité ; la tentative est journalisée. L'étape de facturation reste fermée.
- En attente ou à traiter : Alerte de sécurité à l'équipe désignée ; la source autorisée reste attendue.
Faire échanger des systèmes et des réseaux, en sachant ce qui circule vraiment.
Faire échanger deux systèmes, ou deux réseaux, peut vouloir dire des choses très différentes. Nous commençons par nommer ce qui circule.
Transfert d'informations
Ce qui circule : Une donnée entre vos logiciels et la blockchain : statut, mesure, référence.
Ce qu'il faut savoir : La source reste responsable de ce qu'elle déclare. Les échanges entre logiciels relèvent des API et intégrations.
Transmission d'une preuve
Ce qui circule : Un élément vérifiable : empreinte, signature, état attesté.
Ce qu'il faut savoir : Une preuve d'origine ou d'intégrité, pas de vérité. Une preuve peut venir d'un utilisateur qui signe, comme avec des wallets et intégrations Web3.
Messages entre réseaux
Ce qui circule : Une instruction ou un état transmis d'un réseau à un autre, par un mécanisme dédié.
Ce qu'il faut savoir : Des délais, des coûts, et une confiance accordée au mécanisme de relais, à étudier avant tout choix.
Transfert d'actifs entre réseaux
Ce qui circule : Un actif, lorsqu'un mécanisme spécifique le permet : un pont.
Ce qu'il faut savoir : Un pont ne garantit pas par défaut la conservation, la sécurité ni la disponibilité des actifs : ses risques s'étudient avant tout choix.
Lire la chaîne pour vos outils : l'indexation
Un service d'indexation organise l'accès à des événements déjà enregistrés sur une blockchain, pour qu'une application, comme une application décentralisée, ou un tableau de bord les retrouve et les présente plus facilement. Il ne fait pas entrer d'information extérieure, contrairement à un oracle, et ne garantit pas la véracité de ce qu'il présente.
Il n'existe pas d'interopérabilité universelle : chaque liaison dépend des systèmes, des réseaux et des mécanismes retenus. Le choix des réseaux relève de l'architecture blockchain.
Limites, risques et erreurs : ce que nous prévoyons avant qu'ils arrivent.
Une intégration se juge à ce qu'elle fait quand quelque chose manque.
Source indisponible
Attente, nouvelle tentative, alerte : jamais de valeur inventée.
Donnée manipulée ou erronée
Sources autorisées, signatures, concordance : un oracle n'est pas inviolable, et ces contrôles réduisent le risque sans le supprimer.
Sources contradictoires
Une règle d'arbitrage écrite avant, une vérification humaine si elle est prévue.
Ponts et messages entre réseaux
Choix du mécanisme, limites de montant, procédures en cas d'incident.
Supervision
Selon le périmètre convenu, jamais incluse d'office. Les droits d'administration et les procédures relèvent de la sécurité et de la gouvernance.
Notre démarche, de l'inventaire des sources aux tests de panne.
Chaque étape répond à une question : qu'est-ce qui fait foi, et que se passe-t-il quand ce n'est pas le cas ?
Inventaire des données
Ce que le contrat doit savoir, et pourquoi.
Choix des sources
Qui fait foi, et comment le reconnaître.
Règles de contrôle
Fraîcheur, concordance, valeurs plausibles.
Intégration
Transmission, réception, conséquences.
Tests sur réseau de test
Pannes, retards, contradictions, sources inconnues.
Mise en service et suivi
Vérification et suivi, selon le périmètre convenu.
Questions fréquentes
Ce que l'on nous demande avant de relier une blockchain à des données ou à d'autres réseaux.
À quoi sert un oracle blockchain ?
À transmettre à un smart contract une information qui n'existe pas sur la chaîne : un statut, une mesure, un cours, une décision prise ailleurs. L'oracle ne rend pas l'information vraie : sa valeur dépend de la source choisie, des contrôles faits avant l'envoi et de ce que le contrat prévoit quand la donnée manque.
Une donnée transmise par un oracle est-elle forcément exacte ?
Non. Le contrat applique ses règles à ce qu'il reçoit, sans pouvoir vérifier l'événement lui-même. On réduit le risque par des sources autorisées, des déclarations signées, plusieurs relevés concordants et des délais de validité, mais une déclaration ne prouve pas, à elle seule, que l'événement a eu lieu.
Comment vérifier la provenance et la fraîcheur des données ?
Par l'identité de l'émetteur, une signature de ses déclarations, un horodatage et un délai de validité fixé pour chaque information. Une donnée trop ancienne n'est pas transmise comme si elle était actuelle ; une donnée sans origine reconnue est rejetée.
Que se passe-t-il si une source devient indisponible ?
Ce qui a été prévu à la conception : une nouvelle tentative, une source de secours, une alerte, ou une attente sans décision. L'absence de donnée n'est jamais transformée en donnée. La supervision des sources fait partie du périmètre convenu, pas d'une option implicite.
Qui est responsable d'une donnée transmise à un smart contract ?
Chacun à son étape : la source répond de ce qu'elle déclare ; l'intégration, des contrôles convenus ; le contrat, des règles écrites. Ces responsabilités se définissent au cadrage, avec vos partenaires et, si besoin, vos conseils : elles varient d'un projet à l'autre.
Que signifie l'interopérabilité entre deux blockchains ?
Faire circuler des informations, des preuves, des messages ou, avec des mécanismes spécifiques, des actifs d'un réseau à un autre. Chaque mécanisme a ses délais, ses coûts et ses risques : un pont entre réseaux ne garantit pas par défaut la sécurité ni la disponibilité des actifs. Le choix des réseaux relève de l'architecture blockchain.
Avant de connecter vos systèmes, nous définissons ce qui fait foi, et qui en répond à chaque étape.
Le dossier de cadrage
- Systèmes à relierCe qu'il faut décider : Quels logiciels, sources et réseaux échangent, et dans quel sens ?Qui en répond, à désigner : vousnous
- Données nécessairesCe qu'il faut décider : Quelle information le contrat doit-il lire, et rien de plus ?Qui en répond, à désigner : vousnous
- Sources autoriséesCe qu'il faut décider : Qui a le droit d'émettre, et comment le reconnaît-on ?Qui en répond, à désigner : vousle fournisseur de la source
- Fréquence et fraîcheurCe qu'il faut décider : À quel rythme, et jusqu'à quand une donnée reste-t-elle valable ?Qui en répond, à désigner : vousnous
- VérificationsCe qu'il faut décider : Origine, concordance, valeurs plausibles : que contrôle-t-on avant l'envoi ?Qui en répond, à désigner : nousvous, pour valider
- Traitement des erreursCe qu'il faut décider : Absence, retard, contradiction, source inconnue : que se passe-t-il ?Qui en répond, à désigner : vousnous
- Règles de déclenchementCe qu'il faut décider : Quelle condition, quelle conséquence, quel arbitrage en cas de doute ?Qui en répond, à désigner : vousvos conseils
- Exploitation et responsabilitésCe qu'il faut décider : Qui surveille, qui relance, qui répond en cas d'incident ?Qui en répond, à désigner : selon le périmètre convenu
Ces rôles illustrent le cadrage : ils se définissent projet par projet, selon les contrats et les acteurs réels.
Une intégration fiable ne repose pas sur un outil, mais sur des responsabilités définies à chaque passage.
Le cadrage fixe les sources, les contrôles, les règles et les responsables avant la première ligne de code. Il sert de base au développement, aux tests sur réseau de test et aux échanges avec vos partenaires.
Étudions votre projet d'interopérabilité blockchainUn premier échange suffit pour situer votre projet : décrivez la donnée à transmettre et ce qu'elle doit déclencher.