Installer le relais Secure Exchanges dans votre abonnement Azure

Ce guide vous fait passer d'un abonnement Azure vide à un endpoint HTTP fonctionnel, utilisable depuis n'importe quel outil capable d'envoyer un POST JSON : un webhook, une plateforme d'automatisation, votre propre code.

Comptez une dizaine de minutes. Vous n'avez rien à installer sur votre poste : tout se fait dans le navigateur.

Ce dont vous avez besoin

1. Vos trois identifiants de licence Secure Exchanges : numéro de série, API User et API Password. Ce sont trois GUID, de la forme a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d. Si vous êtes administrateur, ou si vous avez accès à la gestion des utilisateurs, vous les récupérez vous-même : ouvrez Gestion des utilisateurs, trouvez l'utilisateur concerné et cliquez sur l'icône de clé dans la colonne Actions.
2. Un abonnement Azure, avec le rôle Contributeur pour pouvoir créer des ressources.
3. Savoir sur quel environnement vit votre licence : production ou prévisualisation. Dans le doute, essayez la production d'abord ; si le test de l'étape 7 renvoie une erreur d'autorisation, refaites l'étape 3 en choisissant la prévisualisation.

Vos identifiants restent dans la configuration de votre propre Function App. Ils ne sont jamais transmis à l'outil qui appelle le relais, ni à Secure Exchanges autrement que par le protocole chiffré habituel.

Étape 1 — Ouvrir le gabarit

Cliquez sur le bouton :

Deploy to Azure

Le portail Azure s'ouvre sur un formulaire de création. Si vous n'êtes pas déjà connecté, Azure vous demande vos identifiants.

Étape 2 — Choisir où installer

En haut du formulaire :

• Abonnement : celui qui portera les coûts.
• Groupe de ressources : cliquez sur Créer et nommez-le, par exemple rg-secure-exchanges. Un groupe dédié rend la suppression facile si vous voulez tout retirer plus tard.
• Région : choisissez la plus proche de vous. Canada East et Canada Central conviennent.

Étape 3 — Saisir vos identifiants

Le formulaire vous demande d'abord comment vous voulez fournir vos identifiants.

Option A — les taper directement

Trois champs, un GUID chacun : numéro de série, API user, API password. Les trois sont masqués à la saisie. Le formulaire vérifie le format au fur et à mesure, alors un collage incomplet ou une valeur qui n'est pas un GUID vous est signalé immédiatement, sans que vous ayez à relire.

Ces trois champs sont déclarés comme paramètres sécurisés : Azure ne les inscrit pas dans l'historique de déploiement de votre groupe de ressources, et aucune consultation ultérieure de ce déploiement ne les fait ressortir. Ils sont écrits dans la configuration de votre Function App, où ils restent lisibles par les personnes autorisées à consulter les paramètres d'application de cette ressource. Si votre politique interne exclut cela aussi, prenez l'option B : le secret ne quitte alors jamais votre coffre.

Option B — les lire dans votre Azure Key Vault

Choisissez Read them from Azure Key Vault, puis :

1. Sélectionnez votre coffre dans la liste déroulante.
2. Saisissez le nom des trois secrets. Azure n'offre pas de sélecteur pour les noms de secrets : recopiez-les exactement tels qu'ils apparaissent dans votre coffre. Les valeurs proposées — se-serial, se-api-user, se-api-password — sont de simples suggestions.

Vos secrets ne passent alors ni par le formulaire, ni par l'historique de déploiement : seule une référence y figure. L'application lit les valeurs au démarrage avec son identité managée.

Un geste supplémentaire après le déploiement : autorisez l'application à lire le coffre. Dans Cloud Shell, en remplaçant les trois noms :

az role assignment create --role "Key Vault Secrets User" --assignee-object-id $(az functionapp identity show --resource-group <votre-groupe> --name <votre-application> --query principalId -o tsv) --assignee-principal-type ServicePrincipal --scope $(az keyvault show --name <votre-coffre> --query id -o tsv)

Puis redémarrez l'application. Tant que l'autorisation n'est pas accordée, elle ne peut pas résoudre les références et l'appel de test de l'étape 7 répond 500 Relay is not configured : c'est une permission manquante, pas une erreur de saisie.

Cette option demande d'être Owner ou User Access Administrator sur le coffre. Un simple rôle Contributeur ne permet pas de créer une attribution de rôle.

Les autres champs

L'onglet Sizing contient la mémoire et le plafond d'instances. Les valeurs par défaut conviennent à quelques centaines d'appels par mois.

Les ressources sont créées dans la région du groupe de ressources choisi à l'étape 2.

Étape 4 — Créer

Cliquez sur Vérifier + créer, puis sur Créer. Azure met environ deux minutes à provisionner :

• un compte de stockage,
• un plan Flex Consumption, facturé à l'usage,
• la Function App elle-même, avec vos identifiants déjà en place.

Étape 5 — Installer le code

L'infrastructure est prête, mais l'application est encore vide. Une commande suffit à l'installer.

1. Quand le déploiement est terminé, vous êtes déjà sur sa page. Dans le menu de gauche, sous Settings, cliquez sur Sorties. (Si vous avez fermé cette page : groupe de ressources → Settings → Déploiements → le déploiement listé → Sorties.)
2. Copiez la valeur de step1_installationCommand.
3. En haut du portail, cliquez sur l'icône Cloud Shell (>_). Choisissez Bash si l'on vous demande. À la première utilisation, Azure propose de créer un petit stockage : acceptez.

4. Si votre compte a plusieurs abonnements, sélectionnez d'abord le bon :

   az account set --subscription "<nom ou identifiant de votre abonnement>"

   Pour afficher tous les abonnements veuillez faire :

   az account list --output table

5. Collez la commande et appuyez sur Entrée.

L'installation prend une minute. Attendez le message Deployment was successful.

Étape 6 — Récupérer votre URL

Toujours dans les Sorties du déploiement, copiez step2_relayUrlWithKey. Elle ressemble à :

https://se-relay-xxxxx.canadaeast-01.azurewebsites.net/api/enveloppe?code=<clé>

Cette URL contient déjà la clé d'accès. Traitez-la comme un mot de passe : qui la possède peut créer des enveloppes et envoyer des messages sur votre licence.

La sortie step4_accessKey donne la clé seule. Elle sert à composer les autres routes : la même clé fonctionne pour /api/enveloppe, /api/message et /api/version.

La sortie step3_testCommand est un curl déjà prêt sur /api/version, clé incluse : c'est le moyen le plus court de confirmer que le relais répond.

Étape 7 — Vérifier que tout fonctionne

Dans le même Cloud Shell, en remplaçant l'URL et l'adresse de destination :

curl -s -X POST "<votre URL de l'étape 6>" -H "Content-Type: application/json" -d '{"subject":"Test","destination":"vous@votreentreprise.com"}'

Réponse attendue :

{"status":200,"url":"https://www.secure-exchanges.com/...","repId":"...","error":null}

Le champ url est le lien d'enveloppe. Vous pouvez l'ouvrir dans votre navigateur pour voir ce que verra votre destinataire.

Si vous obtenez autre chose :

Référence des opérations

Les trois opérations partagent la même URL et la même clé : seule la fin du chemin change.

Toutes attendent Content-Type: application/json. Le code HTTP de la réponse est toujours égal au champ status du corps : vous pouvez vous fier à l'un ou à l'autre.

POST /api/enveloppe

Crée un lien que vous envoyez à quelqu'un pour recevoir des documents de sa part, en toute sécurité, sans qu'il ait à s'abonner ni à installer quoi que ce soit.

Obligatoires : subject et destination.

curl -s -X POST "<votre URL>/api/enveloppe?code=<clé>" -H "Content-Type: application/json" -d '{"subject":"Documents demandés","destination":"client@exemple.com","replyExpirationHours":72,"authorizedExtensions":[".pdf"]}'

{
  "status": 200,
  "url": "https://www.secure-exchanges.com/...&enveloppe=true",
  "repId": "1b2c3d4e-....",
  "error": null
}

url est le lien à transmettre. repId identifie la réponse attendue : conservez-le si vous utilisez le callback API, il vous permettra de rapprocher la réponse du bon dossier.

POST /api/message

Envoie un message sécurisé. Chaque destinataire reçoit son propre lien, tous partagent le mot de passe. C'est Secure Exchanges qui expédie le courriel : vous n'avez aucun serveur d'envoi à fournir.

Obligatoires : subject, message, et au moins une entrée dans recipients.

Un destinataire que le relais ne peut pas joindre fait échouer l'appel avec son indice, par exemple recipients[1]: email is required. Rien n'est écarté en silence : soit tout le lot part, soit vous recevez une erreur qui nomme la ligne à corriger.

| notifyWhenRead | booléen | Vous êtes averti à l'ouverture. Défaut : true |

| clearTextNotification | booléen | Notification d'ouverture en clair plutôt que chiffrée. Défaut : false |

| maximumOpenTime | entier | Nombre d'ouvertures avant destruction, de 1 à 99. Défaut : 5 |

| expirationMinutes | entier | Durée de vie du message. Défaut : 50400 |

| senderName | texte | Nom affiché comme expéditeur |

| callBackParameters | texte | Contenu libre restitué à la lecture. Rien de confidentiel ici |

curl -s -X POST "<votre URL>/api/message?code=<clé>" -H "Content-Type: application/json" -d '{"subject":"Vos documents","message":"<p>Bonjour</p>","recipients":[{"email":"client@exemple.com"}],"password":"un-secret-partage"}'

{
  "status": 200,
  "recipients": [
    {
      "email": "client@exemple.com",
      "status": 200,
      "url": "https://www.secure-exchanges.com/...",
      "messageId": "xH25g0f2...",
      "trackingId": "4ea4a752-1972-4c76-9d82-63dda214a32f",
      "openingCode": null
    }
  ],
  "error": null
}

Le status de premier niveau vaut 200 quand l'appel a abouti ; vérifiez aussi le status de chaque destinataire, l'un d'eux peut être refusé alors que les autres passent. trackingId sert au suivi et à la suppression du message.

Les pièces jointes ne sont pas exposées par cette route : le transfert de fichiers binaires ne tient pas dans un simple POST JSON. Contactez-nous si vous en avez besoin.

GET /api/version

Aucun corps, aucun paramètre. Répond ce qui tourne chez vous et si une mise à jour existe.

curl -s "<votre URL>/api/version?code=<clé>"

{
  "status": 200,
  "version": "1.1.0",
  "publishedVersion": "1.2.0",
  "updateAvailable": true,
  "operations": ["POST /api/enveloppe", "POST /api/message", "GET /api/version"],
  "error": null
}

C'est aussi le test le plus sûr après une installation : il ne crée rien et n'envoie rien.

Codes de retour, communs aux trois routes

Étape 8 — Vous êtes prêt

Votre relais est en service. Vous disposez maintenant d'URLs HTTP ordinaires, utilisables partout où vous pouvez envoyer un POST JSON : un webhook, une plateforme d'automatisation, un CRM, un script, votre propre application.

Partout, la recette est la même : méthode POST (sauf /api/version, en GET), en-tête Content-Type: application/json, et le corps JSON décrit à l'étape précédente. La réponse arrive en JSON : le lien se trouve dans le champ url pour une enveloppe, dans recipients[0].url pour un message.

Si votre outil demande de choisir un type de requête, prenez celui qui vous laisse écrire le corps vous-même — souvent nommé Custom Request ou HTTP. Évitez les modes qui recopient automatiquement les champs du déclencheur : le corps doit être exactement le JSON attendu.

Combien ça coûte

Trois postes, tous facturés à l'usage. Sans appel, le relais ne coûte pratiquement rien.

Comment l'estimer pour votre volume. Un appel dure une à trois secondes : le relais établit un échange chiffré avec Secure Exchanges, puis attend sa réponse. À 512 Mo par instance, la valeur par défaut, cela représente environ 0,5 à 1,5 Go-seconde par appel.

Pour 1 000 enveloppes par mois : de l'ordre de 500 à 1 500 Go-secondes et 1 000 exécutions. Pour 10 000 appels, multipliez par dix. On reste, dans les deux cas, très loin des montants qui justifient une surveillance de budget.

Pour un chiffre exact, utilisez le calculateur de prix Azure : les tarifs varient selon la région, et Microsoft applique une franchise mensuelle sur les plans de consommation dont le montant évolue. Cherchez Azure Functions, choisissez le plan Flex Consumption, puis saisissez les Go-secondes et le nombre d'exécutions estimés ci-dessus.

Ce qui ferait monter la facture, si jamais : augmenter la mémoire par instance sans en avoir besoin — le relais n'exploite pas plus de 512 Mo — ou activer les instances toujours prêtes, que notre gabarit laisse désactivées. Le plafond d'instances ne coûte rien en soi : il limite la montée en charge, il ne réserve aucune capacité.

Renforcer l'accès (facultatif)

La clé contenue dans l'URL protège déjà l'endpoint et se révoque en un clic : Function App → Fonctions → CreateEnveloppe → Clés de fonction. Si vous voulez une seconde clé, indépendante de celle d'Azure :

1. Function App → Paramètres → Variables d'environnement → ajouter RELAY_EXTRA_API_KEY avec une valeur longue et aléatoire.
2. Dans votre outil, ajouter le header x-relay-key avec cette même valeur.

Tout appel sans ce header est alors refusé.

Étape 9 — Savoir si vous êtes à jour, et mettre à jour

Secure Exchanges publie des versions du relais : corrections, nouvelles opérations. Votre installation ne se met pas à jour toute seule, mais elle sait vous dire où elle en est.

Vérifier votre version

Reprenez l'URL de l'étape 6, remplacez la fin du chemin par /api/version, et ouvrez-la dans votre navigateur ou dans Cloud Shell :

curl -s "https://<votre-application>.azurewebsites.net/api/version?code=<votre-clé>"

{
  "status": 200,
  "version": "1.1.0",
  "publishedVersion": "1.2.0",
  "updateAvailable": true,
  "operations": ["POST /api/enveloppe", "POST /api/message", "GET /api/version"],
  "error": null
}

Si publishedVersion et updateAvailable sont à null, votre application n'a pas pu joindre le fichier de version publié. Ce n'est pas une panne : le reste fonctionne normalement, seule la comparaison est indisponible.

Faire la mise à jour

Une seule commande, la même qu'à l'étape 5. Vous la retrouvez dans le portail : votre groupe de ressources → Settings → Déploiements → votre déploiement → Sorties → step1_installationCommand.

Collez-la dans Cloud Shell et attendez Deployment was successful.

Rien d'autre à faire : vos identifiants, vos réglages, vos clés et votre URL sont conservés. Il n'y a ni bouton à recliquer, ni formulaire à remplir de nouveau — seul le code est remplacé.

Rappelez /api/version après coup : version doit maintenant égaler publishedVersion.

Si la mise à jour apporte une nouvelle opération, elle est joignable aussitôt avec la même clé. Gardez votre URL et changez seulement la fin du chemin.

Tout retirer

Supprimez le groupe de ressources créé à l'étape 2 : cela efface la Function App et le stockage d'un coup. Aucune trace ne subsiste côté Azure, et votre licence Secure Exchanges n'est pas affectée.