Azure Functions pour cabinets: revue du formulaire de consultation

Un cabinet peut perdre la confiance avec une petite automatisation: le formulaire envoie succession, travail ou contrat par e-mail, logge tout le texte et manque les échecs. Cet article relit Azure Functions avec Claude Code avant usage réel.

Key Points

La revue commence par données personnelles, consentement, texte confidentiel, échec d’e-mail, doublons et prise de rendez-vous. HTTP trigger aide, mais anonymous, raw logs et secrets en clair sont risqués.

Workflow From Form to Booking

Le flux va du formulaire au rendez-vous ou rappel. Claude Code relit function.json, app settings, logs, Key Vault references et gestion d’échec. Le cabinet décide des consultations acceptées.

Flow	Azure Functions review	Human review
Form receive	HTTP trigger, method, auth, CORS	consent text and accepted case types
Notice	masked subject, request id, mail failure	confidential content and staff owner
Secret	app settings, Key Vault references	mail API key and access policy
Failure	retry record, alert, request id	callback and client communication
Booking	completion page and booking URL	whether the case can be booked

What Claude Code Does and What Humans Decide

Claude Code drafts the Function shape, validation fields, logging policy, Key Vault note, failure checklist, and booking path. Humans decide legal, tax, labor, license, privacy, advertising, confidentiality, and whether to accept the consultation.

3 Use Cases

Use case 1: Split form fields and logs

• Input: form fields, case types, privacy consent, booking URL.
• Output: required fields, optional fields, mail fields, no-log fields.
• Human review: consultation text, personal data, advertising wording, urgent cases.

Use case 2: Review HTTP trigger settings

• Input: function.json, methods, authLevel, App Service auth note, form origin.
• Output: POST-only rule, CORS note, auth warning, and test commands.
• Human review: public exposure, bot protection, stopped services, and phone-first cases.

Use case 3: Handle mail failure and booking path

• Input: mail provider, failure log, retry owner, booking URL, completion page.
• Output: failed notice record, retry rule, staff alert, and booking button rule.
• Human review: which cases can book automatically and which need a call.

Copy-Paste Prompt

Act as a French professional services Azure Functions consultation-form reviewer.
Goal: prevent missed notices, personal-data logs, plain secrets, and missing booking paths.

Review:
- form fields and case types
- privacy consent
- function.json
- app settings draft
- mail provider note
- completion page and booking URL

Return:
1. HTTP trigger method and auth review
2. raw-body log warning
3. secret and Key Vault reference note
4. failed-notice retry checklist
5. booking path and staff owner
6. five settings a beginner should inspect today

Working Check Code

// verify-azure-function-consultation-form.mjs
// No dependencies. Run with: node verify-azure-function-consultation-form.mjs
const functionJson = {
  bindings: [
    {
      authLevel: "anonymous",
      type: "httpTrigger",
      direction: "in",
      name: "req",
      methods: ["post"]
    },
    {
      type: "http",
      direction: "out",
      name: "res"
    }
  ]
};

const source = [
  "module.exports = async function (context, req) {",
  "  console.log(req.body);",
  "  const apiKey = 'SENDGRID_API_KEY_plain_text';",
  "  await sendMail(req.body.email, req.body.message, apiKey);",
  "  context.res = { status: 200, body: 'ok' };",
  "};"
].join("\n");

const formPolicy = {
  fields: ["name", "email", "caseType", "message"],
  required: ["name", "email", "caseType", "message", "privacyConsent"],
  hasIdempotencyKey: false,
  hasRetryQueue: false,
  hasReservationLink: false
};

const problems = [];
const trigger = functionJson.bindings.find((binding) => binding.type === "httpTrigger");

if (!trigger || trigger.authLevel === "anonymous") {
  problems.push({ item: "authLevel", fix: "avoid anonymous public posting unless another protection layer exists" });
}
if (/console\.log\(req\.body\)/.test(source)) {
  problems.push({ item: "raw body log", fix: "log request id and case type, not the consultation details" });
}
if (/SENDGRID_API_KEY|API_KEY_plain_text/.test(source)) {
  problems.push({ item: "plain secret", fix: "use Key Vault references or approved app settings" });
}
if (!formPolicy.required.includes("privacyConsent")) {
  problems.push({ item: "privacy consent", fix: "require consent before sending the consultation form" });
}
if (!formPolicy.hasIdempotencyKey) {
  problems.push({ item: "duplicate submit", fix: "store an idempotency key from email, timestamp bucket, and message hash" });
}
if (!formPolicy.hasRetryQueue) {
  problems.push({ item: "mail failure", fix: "record failed notices and retry or alert a staff member" });
}
if (!formPolicy.hasReservationLink) {
  problems.push({ item: "booking path", fix: "include a reservation or callback path after the notice" });
}

if (problems.length > 0) {
  console.table(problems);
  process.exitCode = 1;
} else {
  console.log("Azure Functions consultation form checklist passed.");
}

Pitfall: Common Failure Cases

L’erreur est de vérifier seulement un e-mail de test. Il faut savoir si chaque demande est enregistrée, protégée et transmise.

The first failure is calling the project done when email arrives once. A professional office needs traceability for missed notices, duplicate submissions, and booking handoff.

The second failure is logging the whole consultation text. Store request id, case type, time, and result instead.

The third failure is using a plain API key in source code or notes. Move secrets to an approved settings flow and consider Key Vault references.

FAQ

Q. Le texte complet doit-il aller dans l’e-mail ?\n\nR. Selon la politique du cabinet. Si les e-mails circulent largement, mieux vaut masquer et stocker le détail ailleurs.

Q. Are Azure Functions too much for a small office?

A. Sometimes. If a form service already handles consent, notice, and booking, use it. Functions help when the office needs custom routing, retry records, and integration with booking or internal tools.

Q. Is a Function key enough?

A. It depends on exposure. Public forms may need bot protection, CORS review, rate limits, App Service authentication, or another gateway.

Q. Where should teams go next?

A. Offices that need forms, Azure Functions, Key Vault, logging policy, and booking flow reviewed together can start from ClaudeCodeLab training.

What I Verified

La version française garde formulaire, confidentialité, échecs de notification, rendez-vous et consultation. I checked Azure Functions HTTP trigger, triggers and bindings, Key Vault references, App Service authentication, and Azure Functions security. I also checked the CTA, internal link, executable JavaScript, and locale coverage.