Nommer les photos de chantier dans Azure Blob Storage

Dans une entreprise du bâtiment, une photo appelée IMG_4821.jpg ne suffit pas au moment du dossier de fin de chantier. Le numéro de projet est sur l’ardoise, la phase est dans un message, et le client demande les photos avant/après d’une zone précise. Si Azure Blob Storage reçoit les fichiers sans règle de nommage ni tags, l’équipe perd du temps à chercher. La première action est de contrôler cent photos récentes.

Key Points

Ne laisse pas le nom de caméra porter tout le contexte.
Sépare projet, phase, zone, statut, date et numéro.
Utilise Blob index tags pour rechercher et metadata pour l’historique d’import.
Claude Code prépare la règle, le CSV et la liste des risques.
Les humains gardent la décision sur les visages, adresses, contrats et publication.

Workflow: Photo Ledger Before Upload

La bonne entrée est la liste de photos, pas le portail Azure. On aligne dossier, nom actuel, date, phase, zone, destinataire et autorisation de publication. Ensuite Claude Code propose un chemin Blob, des tags obligatoires et un CSV que le conducteur de travaux peut relire.

Field	Example	Review point
Blob name	`2026/07/site-042/waterproof/20260719_roof_before_001.jpg`	readable path without customer details
Blob index tags	`projectId`, `phase`, `location`, `status`, `publicOk`	searchable keys with stable spelling
Metadata	`source=line`, `shotBy=staff-01`	import support, not sensitive identity
Ledger CSV	URL, phase, destination, approval	human review before submission

Primary sources checked: Azure Blob Storage introduction, naming rules, Blob index tags, lifecycle management, soft delete, and SAS overview.

What Claude Code Does And What Humans Decide

Claude Code can draft naming rules, required tags, missing-field checks, CSV columns, shared-link checks, and retention notes from a sample folder. Humans decide customer names, addresses, faces, license plates, neighboring homes, accident photos, contracts, publication approval, and deletion requests.

3 Use Cases

Use case 1: Create a naming rule for site photos

Input: existing folders, photo names, project ID, phase, location, shot date, destination.
Output: blob-name template, sequence rule, banned labels, CSV columns.
Human review: customer names, addresses, and site labels that should not appear in URLs.

Start with one recent site and one hundred photos. Ask Claude Code to turn the list into a naming rule. The human reviewer removes sensitive labels before upload.

Use case 2: Search with Blob index tags

Input: projectId, phase, location, status, shotDate, submittedTo, publicOk.
Output: required tags, search examples, empty-field rule, spelling dictionary.
Human review: no personal data, customer names, addresses, phone numbers, or license plates in tags.

Tags make later search practical. A query by project and phase is easier than scanning camera filenames. Keep tag values short and internal.

Use case 3: Review shared URLs

Input: photos to share, recipient, expiry, permission, email text, submission deadline.
Output: SAS checklist, expiry warning, share list, send-before review.
Human review: recipient, read-only permission, expiry, people in photos, contract details.

Shared URLs reduce back-and-forth, but wide links create risk. Claude Code prepares the table. Humans approve the scope.

Copy-Paste Prompt

Act as a construction photo ledger reviewer.
Goal: make Azure Blob Storage photos searchable without exposing customer or site-sensitive data.

Check:
1. blob names include project, date, phase, location, status, and sequence
2. customer names, addresses, people, and license plates are not placed in URLs or tags
3. Blob index tags and metadata have separate purposes
4. shared URLs are read-only, short-lived, and narrow in scope
5. soft delete, versioning, and lifecycle notes exist
6. a ledger CSV lets humans approve publication

Return a naming rule, required tag table, CSV columns, risky file-name examples, and a 100-photo first review plan.

Working Check Code

// verify-construction-photo-ledger.mjs
// No dependencies. Run with: node verify-construction-photo-ledger.mjs
const photos = [
  {
    blobName: "IMG_4821.jpg",
    tags: { projectId: "site-042", phase: "waterproof" },
    metadata: { source: "line" },
    share: { permission: "read", expiresInHours: 240 }
  },
  {
    blobName: "2026/07/site-042/waterproof/20260719_roof_before_001.jpg",
    tags: {
      projectId: "site-042",
      phase: "waterproof",
      location: "roof",
      status: "before",
      publicOk: "review"
    },
    metadata: { source: "camera", shotBy: "staff-01" },
    share: { permission: "read", expiresInHours: 24 }
  },
  {
    blobName: "sato-home-address-kyoto-crack-after.jpg",
    tags: { projectId: "sato-home", phase: "repair", publicOk: "yes" },
    metadata: { customerName: "Sato" },
    share: { permission: "write", expiresInHours: 72 }
  }
];

const requiredTags = ["projectId", "phase", "location", "status", "publicOk"];
const blobNamePattern = /^\d{4}\/\d{2}\/[a-z0-9-]+\/[a-z0-9-]+\/\d{8}_[a-z0-9-]+_(before|after|progress)_\d{3}\.(jpg|jpeg|png)$/i;
const sensitiveWords = /(address|customer|home|name|phone|car|license|住所|氏名|電話|車番)/i;
const problems = [];

for (const photo of photos) {
  if (!blobNamePattern.test(photo.blobName)) {
    problems.push({ blobName: photo.blobName, item: "blob name", fix: "use yyyy/mm/project/phase/date_location_status_seq.ext" });
  }
  for (const tag of requiredTags) {
    if (!photo.tags[tag]) {
      problems.push({ blobName: photo.blobName, item: `missing tag: ${tag}`, fix: "fill required Blob index tags before upload" });
    }
  }
  if (sensitiveWords.test(photo.blobName) || sensitiveWords.test(JSON.stringify(photo.tags)) || sensitiveWords.test(JSON.stringify(photo.metadata))) {
    problems.push({ blobName: photo.blobName, item: "sensitive label", fix: "remove customer names, addresses, phone numbers, and car identifiers" });
  }
  if (photo.share.permission !== "read") {
    problems.push({ blobName: photo.blobName, item: "share permission", fix: "use read-only sharing for external photo review" });
  }
  if (photo.share.expiresInHours > 48) {
    problems.push({ blobName: photo.blobName, item: "share expiry", fix: "shorten SAS expiry for temporary construction photo review" });
  }
}

if (problems.length > 0) {
  console.table(problems);
  process.exitCode = 1;
} else {
  console.log("Construction photo ledger checklist passed.");
}

Pitfall: Common Failure Cases

The first failure is forcing every detail into the filename. Split the blob name, tags, metadata, and CSV. The second failure is putting private labels into tags. Use internal project IDs. The third failure is a long-lived broad shared URL. Use read-only, short expiry, and narrow scope. The fourth failure is using one retention rule for handover photos, warranty photos, accident photos, and temporary chat imports.

FAQ

Q. Can all photos live in one container?

A. Often yes at the beginning. Compare containers or prefixes when permissions and retention diverge.

Q. What belongs in Blob index tags?

A. Search keys: projectId, phase, location, status, and publicOk. Use metadata for support notes.

Q. Are SAS URLs safe?

A. They are useful for temporary review when read-only, short-lived, and narrow in scope.

Q. What should the team do today?

A. Pick one recent site and check one hundred photos for blob name, projectId, phase, location, status, and publicOk.

Training And Consultation Signal

Measure search time, resend requests, empty CSV fields, photos stopped before submission, expired shared links, and inquiry rate. If those numbers hurt, photo-ledger design and Blob Storage permissions are a fit for formation ClaudeCodeLab.

What I Verified

I checked Microsoft Learn references for Blob Storage, naming, Blob index tags, lifecycle management, soft delete, and SAS. I also checked the CTA, executable JavaScript, internal link, external links, locale coverage, and queue removal.