Accès aux données par les intégrations

Deux voies, et rien d’autre

Une intégration ne peut lire ou modifier un de vos objets métier que dans deux situations :

1. Dans le cadre d'un processus, sur un objet que vous lui avez transmis en câblant votre processus, ou sur un type d'objet dont vous avez explicitement autorisé l'accès.
2. Par une correspondance déjà établie, pour relire l'objet Ormuz exactement associé à l'un de ses propres objets — la commande Ormuz derrière la commande Mondu, par exemple.

Une extension ne reçoit donc jamais une capacité générique de recherche dans le modèle métier. Le contexte d’exécution, les permissions et les correspondances délimitent chacun un accès concret et vérifiable.

Voie 1 — dans un processus

Quand vous reliez la sortie d'un node à l'entrée d'un node d'intégration, ce câblage est lui-même votre autorisation : il est visible dans le graphe, vous l'avez dessiné, et l'objet est simplement remis au node. Aucune permission supplémentaire n'est demandée, et c'est le cas de la grande majorité des nodes.

Certains nodes ont en revanche besoin de consulter ou de modifier un objet sans que cela apparaisse dans leurs entrées et sorties — un node qui accorde du crédit vérifie et met à jour l'exposition de l’entreprise dans son propre comportement. Cet accès est opaque pour vous : il exige une permission explicite, déclarée par le node dans son contrat platform_access et accordée par vous.

Voir Permissions des nodes pour le mécanisme de consentement, sa portée et sa révocation.

Voie 2 — une correspondance établie

Une intégration travaille avec ses propres objets, chez le fournisseur. Pour relier durablement ces objets aux vôtres, Ormuz enregistre des correspondances d'objets : « cette commande Mondu correspond à cette commande Ormuz ».

Une correspondance permet ensuite de relire l'objet Ormuz exactement ciblé — rien d'autre. C'est ce qui permet à un événement provider entrant d'exposer directement votre objet métier, sans que l'intégration ait besoin de chercher quoi que ce soit dans vos données.

Le point essentiel : une correspondance ne crée jamais un accès nouveau. Elle ne peut être établie que vers un objet que l'intégration détenait déjà légitimement, par l'une des deux voies. Elle fige un accès existant, elle n'en ouvre pas.

Liens d’objets explicites

Les Object Links ne sont pas une troisième voie d’accès implicite. Ils sont des relations créées explicitement par un processus entre des objets déjà disponibles dans son contexte. Une relation peut relier deux objets plateforme, un objet plateforme à un objet d’extension, ou deux objets d’extension.

Une fois le lien créé, les nodes Core peuvent retrouver l’extrémité plateforme liée ou, lorsque l’objet d’extension cible est déclaré comme récupérable par son extension, demander explicitement son rechargement au provider. Cette opération reste visible dans le graphe et ne transforme jamais un simple identifiant en droit d’accès général.

Ne confondez pas ce mécanisme avec une correspondance d’objets : la correspondance exprime l’identité entre un objet provider et son représentant Ormuz ; le lien exprime une relation fonctionnelle entre deux objets qui restent distincts.

Ce qui n’est jamais possible

Quelles que soient les permissions accordées et les correspondances enregistrées, une intégration ne peut pas :

• parcourir ou rechercher vos données — il n'existe aucun moyen pour une intégration de lister vos entreprises, vos factures ou vos commandes ;
• lire un objet à partir d'une référence externe — recevoir ou deviner l'identifiant d'un de vos objets ne donne aucun droit de le lire ;
• remonter d'un objet vers les objets liés — accéder à un contact n'ouvre pas l'accès à l’entreprise à laquelle il appartient, ni l'inverse ; chaque objet exige sa propre autorisation ;
• modifier un objet du seul fait qu'il lui est associé — une correspondance n'autorise qu'une lecture ; écrire exige une permission d'écriture accordée dans un processus ;
• franchir la frontière d'un marchand — un objet hors du périmètre de la configuration utilisée est traité comme inexistant, sans distinction observable entre « existe ailleurs » et « n'existe pas ».

Les intégrations qui reçoivent des événements du fournisseur — webhooks entrants, synchronisations périodiques — sont en outre les plus restreintes : elles s'exécutent hors de tout processus, ne disposent donc d'aucune permission, ne peuvent créer aucune correspondance et ne peuvent modifier aucun objet métier. Elles peuvent seulement relire une correspondance déjà établie et proposer des données à un processus, qui décidera.

Quand l’autorisation est vérifiée

L'autorisation n'est pas contrôlée une fois pour toutes à la conception : elle est revérifiée jusqu'au moment où l'accès a effectivement lieu.

• À l'enregistrement du processus — impossible d'enregistrer un processus utilisant un node dont l'accès n'a pas été autorisé.
• Avant chaque exécution du node — l'état du consentement est réévalué à chaque passage.
• Au moment de l'accès lui-même — la plateforme revérifie que le node qui demande l'objet est bien celui du processus en cours, qu'il a déclaré cet accès, que la permission est toujours accordée, et que l'objet appartient au bon périmètre.

Conséquence pratique : retirer une permission prend effet immédiatement, y compris pour un processus déjà en cours d'exécution. Le prochain accès concerné échoue, définitivement et sans nouvelle tentative automatique.

Ce que vous pouvez contrôler et observer

Les surfaces publiques permettent de consulter les permissions actuellement en vigueur pour un processus (voir Permissions des nodes) et les correspondances enregistrées pour une configuration d’extension (voir Correspondances d’objets).

Si un node tente un accès qui n’est plus autorisé, l’étape échoue et l’erreur est visible dans l’instance. Révoquer une permission agit donc sur les accès futurs sans effacer les effets déjà produits ni les correspondances créées légitimement auparavant.