Et si l'ajout d'un store locator prenait 5 minutes au lieu de 5 sprints ?

Marine - Reading time : 10 min

Sommaire

How AI coding tools like Claude Code are changing the way teams prototype location features, and why Woos-map's clean API design makes it work.

Voici un scénario que les équipes produit et marketing connaissent bien. Vous avez besoin d'une carte sur votre site. Pas n'importe laquelle : afficher vos points de vente, permettre aux utilisateurs de rechercher une adresse et faire réagir la carte en conséquence. L'expérience classique d'un Store Locator.

Simple en théorie. En pratique ? Ça finit dans le backlog. En attente d'un slot sprint. Un développeur s'en empare, lit la documentation, débat du fournisseur cartographique, écrit l'intégration, la teste, itère. Des semaines passent. La fonctionnalité « simple » sort un trimestre après les prévisions initiales.

Et si cette première étape — le prototype fonctionnel — pouvait se concrétiser en quelques minutes plutôt qu'en semaines ?

AI doesn't replace developers. It removes the wait.

Let's be clear about what we're not saying. AI coding tools don't eliminate the need for engineering. A production-grade store locator still needs a developer's attention: performance tuning, design system integration, edge case handling, accessibility.

But there's an enormous gap between "I have an idea" and "I have something I can show." That gap is where projects stall, where stakeholders lose context, and where good ideas quietly die in a backlog.

Tools like Claude Code (Anthropic's AI coding assistant that works directly in the terminal) are closing that gap. You describe what you want in plain English. The AI writes the code. You see the result immediately. And when the API you're working with is well-designed, the result isn't just a rough sketch: it actually works.

The experiment: 3 prompts to a working store locator

We ran a simple test. Starting from nothing (no code, no boilerplate), we asked Claude Code to build a store locator page using Woosmap's Map JS API. Three prompts. Here's exactly what happened.

Prompt 1:

"Build me an HTML page with a Woosmap map centered on London."

The first prompt is deliberately simple. We're asking for the foundation: a full-screen map, centered on London, using the Woosmap Map JS API.Claude Code generates a clean HTML file. The key lines:

<div id="map"></div>
<script>
  function initMap() {
    const map = new woosmap.map.Map(document.getElementById("map"), {
      center: { lat: 51.5074, lng: -0.1278 },
      zoom: 13,
    });
  }
  window.initMap = initMap;
</script>
<script src="https://sdk.woosmap.com/map/map.js?key=YOUR_API_KEY&callback=initMap" defer></script>

Ce que remarquera un non-développeur : pas de système de build complexe, pas de gestionnaire de paquets, pas de dépendance à un framework. Un seul fichier HTML. Cette simplicité est précisément ce que les outils IA gèrent bien — et ce qui rend Woosmap aussi facile à prototyper.

Prompt 2:

"Add 5 store markers on the map with info windows showing the store name."

Now we're adding real content. We give Claude Code a list of five fictional stores with their names and coordinates. It adds markers using woosmap.map.Marker and attaches a single info window that is reused on every click:

const stores = [
  { name: "Woosmap Store - Covent Garden",  lat: 51.5117, lng: -0.1240 },
  { name: "Woosmap Store - Shoreditch",     lat: 51.5265, lng: -0.0798 },
  { name: "Woosmap Store - Notting Hill",   lat: 51.5093, lng: -0.1964 },
  { name: "Woosmap Store - Camden Town",    lat: 51.5392, lng: -0.1426 },
  { name: "Woosmap Store - South Bank",     lat: 51.5055, lng: -0.1066 },
];

let activeInfoWindow = null;

stores.forEach((store) => {
  const marker = new woosmap.map.Marker({
    position: { lat: store.lat, lng: store.lng },
    icon: {
      url: storeMarkerSvg,
      scaledSize: { width: 28, height: 40 },
    },
    map: map,
  });

  marker.addListener("click", () => {
    if (activeInfoWindow) activeInfoWindow.close();
    const infoWindow = new woosmap.map.InfoWindow({});
    infoWindow.setOffset(new woosmap.map.Point(0, -40));
    infoWindow.setContent(`<strong>${store.name}</strong>`);
    infoWindow.open(map, marker.getPosition());
    activeInfoWindow = infoWindow;
  });
});

Cinq marqueurs apparaissent sur la carte. Un clic sur l'un d'eux affiche le nom du point de vente. Le schéma est familier pour quiconque a déjà utilisé une bibliothèque cartographique JavaScript — mais l'essentiel est ailleurs : vous n'avez pas eu à l'écrire. Vous avez décrit ce que vous vouliez, le code a suivi.

Ce que remarquera un non-développeur : les données se résument à une liste de noms et de coordonnées. Dans un projet réel, cette liste provient de votre projet Woosmap via la Stores API. La structure est identique ; seule la source change.

Prompt 3:

"Add an address search field that recenters the map when the user picks a result."

C'est la fonctionnalité qui prend généralement le plus de temps à développer from scratch : un champ de recherche avec suggestions en autocomplétion, connecté à un service de géocodage, qui recentre la carte sur la localisation sélectionnée.

Claude Code s'appuie sur le LocalitiesService intégré à Woosmap pour gérer tout cela :

const localitiesService = new woosmap.map.LocalitiesService();
let searchMarker = null;

input.addEventListener("input", (e) => {
  localitiesService
    .autocomplete({
      input: e.target.value,
      types: ["locality", "postal_code", "address"],
      components: { country: ["GB"] },
      location: { lat: 51.5074, lng: -0.1278 },
      radius: 50000,
    })
    .then((response) => {
      displaySuggestions(response.localities);
    });
});

// Lorsque l'utilisateur sélectionne une suggestion
localitiesService
  .getDetails({ publicId: selectedLocality.public_id })
  .then((details) => {
    const location = details.result.geometry.location;
    map.setCenter({ lat: location.lat, lng: location.lng });
    map.setZoom(14);

    // Remplace l'éventuel marqueur de recherche précédent
    if (searchMarker) searchMarker.setMap(null);
    searchMarker = new woosmap.map.Marker({
      position: { lat: location.lat, lng: location.lng },
      icon: {
        url: searchMarkerSvg,
        scaledSize: { width: 32, height: 46 },
      },
      map: map,
    });
  });

L'autocomplétion Localities retourne des suggestions d'adresses au fil de la saisie. Lorsque l'utilisateur en sélectionne une, getDetails() récupère les coordonnées et la carte se recentre. L'ensemble repose sur le même SDK Woosmap, sans bibliothèque tierce.

Ce que remarquera un non-développeur : la recherche d'adresse et la carte font partie de la même API. Il n'y a pas de « colle » pour connecter deux services distincts, donc moins de points de défaillance potentiels et un chemin plus court du prototype à la production.

See it in action

Here's the actual result, running live. This is the exact code Claude Code generated from those three prompts. Try typing an address in the search bar, or click on a marker.

Three prompts later: what do we have?

A single HTML file, ~100 lines, that delivers:

A full-screen interactive map
Five store locations with clickable markers
An address search bar with real-time autocomplete
Map recentering when the user picks an address

It works. Not as a mockup, not as a wireframe: as actual running code you can open in a browser. The entire process took under five minutes.

What this means for product and marketing teams

This isn't about replacing your developers. It's about changing the sequence.

BEFORE

You write a brief. You pitch it in sprint planning. Engineering estimates the effort. It gets prioritized (or not). Weeks later, you see the first version and realize it's not quite what you had in mind.

NOW

You describe what you want to an AI tool. You see a working prototype in minutes. You iterate until it matches your vision. Then you hand engineering real code that already works.

For the Product Manager

Faster validation. Test an idea with stakeholders before it ever enters the backlog.

For the Marketing LeadAutonomy.

Prototype a store locator, see how the address search feels, give engineering informed feedback.

For the Developer

A head start. The basic integration is done. Focus on what actually requires your expertise.

Why This Works with Woosmap

Not all APIs are equal when it comes to AI-assisted development. Claude Code (and tools like it) are good at reading documentation, understanding API patterns, and generating working integrations. But they're only as good as the API they're working with.

One SDK, everything included: Map rendering, markers, address autocomplete, store display: all in one library, loaded with a single script tag.
Clean, predictable API surface: Classes like woosmap.map.Map and woosmap.map.Marker follow consistent patterns. AI tools infer how they work after one example.
Zero setup friction: One API key, one script tag, and you're running. No build step, no project configuration.
Docs built for humans and machines: Well-organized reference docs with clear code examples aren't just good for developers. They're what AI tools need to generate accurate code.

From prototype to production

What we've built here is a working prototype. It proves the concept, it demonstrates the API, and it gives your team something concrete to react to. But taking it to production means connecting real store data, matching your design system, handling edge cases, and making sure it performs at scale.

If you need help taking it further, get in touch with us or work with one of our integration partners like Nocode Factory, who specialise in deploying Woosmap-powered location features into production. See their work on the Neoness gym finder for a great example of what a polished store locator looks like.