Un portail de collectivité peut publier des informations pratiques sans devenir pour autant un outil d’attractivité. Pour rendre l’économie locale réellement visible, il faut relier un territoire à ses entreprises, donner à chacune un espace suffisamment riche, permettre aux habitants de chercher un professionnel ou un emploi et garder une administration exploitable par plusieurs rôles. La carte n’est alors qu’une étape du parcours, pas le produit entier.
Attractivité-locale.fr a été construit autour de cette continuité. Une collectivité possède sa page et son identité visuelle. Elle référence des entreprises dans son propre périmètre. Chaque entreprise dispose d’une fiche publique avec son adresse, sa présentation, ses services, produits, références, réalisations, partenaires, témoignages et offres d’emploi. Son adresse peut être transformée en point sur une carte OpenStreetMap au moment de la consultation.
Le socle ne se limite pas à l’interface. Des commandes alimentent les régions, départements, EPCI et communes depuis geo.api.gouv.fr. Une API de lecture protégée par jeton expose collectivités et contenus d’entreprise. Un back-office sépare enfin les responsabilités des administrateurs de collectivité et d’entreprise. Cette articulation entre référentiel public, modèle métier et restitution illustre un véritable projet d’intégration d’API publiques et open data.
L’intérêt du projet tient aussi à ses limites explicites. Le SIRET est géré comme une donnée de la fiche entreprise, sans alimentation automatique depuis Sirene dans cette version. Nominatim est interrogé depuis le navigateur pour afficher une adresse, sans chaîne serveur de géocodage ni score de confiance. La solution montre donc une base fonctionnelle concrète et les prochains seuils d’industrialisation, sans attribuer au produit des mécanismes qu’il ne possède pas.
1. Attractivité-locale.fr, un produit territorial à plusieurs visages
Une même plateforme pour la collectivité, l’entreprise locale et l’habitant
Attractivité-locale.fr est pensé comme un point de rencontre entre trois besoins. La collectivité doit disposer d’une présence locale identifiable et pouvoir administrer son périmètre. L’entreprise doit présenter son activité autrement qu’avec un nom et une adresse. L’usager, lui, doit pouvoir entrer par une commune, rechercher une entreprise, parcourir une fiche ou consulter une offre d’emploi.
Le modèle traduit cette organisation sans tout mélanger. Une collectivité possède son nom, son slug, ses coordonnées, ses horaires, son site, une URL applicative et plusieurs médias de personnalisation. Une entreprise est rattachée à une collectivité et possède son propre slug, son SIRET, son statut, ses coordonnées, sa description, ses réseaux sociaux et ses visuels. Les URLs publiques conservent le slug de la collectivité avant celui de l’entreprise ou de l’offre d’emploi.
Cette portée territoriale ne repose pas sur une carte générale chargée de résoudre tous les usages. La page de collectivité oriente vers deux parcours concrets : trouver des professionnels et trouver un emploi. La liste d’entreprises reste bornée à la collectivité consultée ; la fiche entreprise rassemble ensuite les contenus qui donnent de la profondeur à cette présence locale.
Le produit porte ainsi une ambition plus précise qu’un simple annuaire. Il organise la contribution de plusieurs acteurs autour d’un référentiel partagé, puis rend cette information accessible sur le web et par API. C’est cette architecture fonctionnelle — territoire, organisation, contenu, emploi et diffusion — qui donne sa cohérence à l’ensemble.
2. Du socle territorial aux parcours publics en 33 jours
Une construction par chaînes fonctionnelles du 16 décembre 2024 au 17 janvier 2025
La construction s’étend du 16 décembre 2024 au 17 janvier 2025 inclus. Les premiers jours posent Symfony 6.4, l’authentification, les utilisateurs et le modèle de collectivité. Le périmètre s’élargit ensuite aux entreprises et à leurs sous-contenus : services, produits, projets, références, partenaires, témoignages et offres d’emploi.
Une deuxième séquence ouvre les données à d’autres consommateurs. Les premières routes API arrivent le 19 décembre, avec sérialisation différenciée entre listes et détails, pagination et authentification par jeton. En janvier, les parcours publics de collectivité, d’entreprise et d’emploi prennent forme en parallèle des commandes d’import du découpage administratif français et de la personnalisation des médias.
La fin de la période ajoute les candidatures, les recherches par région ou département, l’espace utilisateur, les favoris, les contacts et les premiers objets éditoriaux. Tous ces chantiers ne possèdent pas le même niveau d’achèvement dans l’interface. La présentation distingue donc le cœur utilisable — collectivités, entreprises, contenus, emplois, carte et API de lecture — des extensions encore en cours de raccordement.
La livraison technique prévoit des cibles séparées pour la démonstration et la production, avec des images PHP et Nginx construites par l’intégration continue. Le 17 janvier marque le dernier jalon de développement de cette version. Cette date raconte donc la construction du produit, sans lui attribuer une ouverture publique qui n’est pas documentée.
3. Donner une profondeur économique à la page d’une collectivité
Relier le territoire, ses organisations et les actions possibles
Le problème traité par le produit n’est pas seulement “où se trouve cette entreprise ?”. Une adresse répond à une question de localisation, mais elle n’explique ni l’activité, ni les services proposés, ni les références, ni les recrutements en cours. À l’inverse, une fiche riche mais détachée de son territoire perd une partie de son utilité pour un habitant ou une collectivité.
Le socle organise donc l’information autour de la collectivité. Le slug territorial est présent dans les parcours publics d’annuaire, de fiche entreprise et d’offre d’emploi. Avant d’afficher une ressource, l’application retrouve d’abord la collectivité concernée ; l’entreprise est ensuite recherchée avec ce contexte. Cette règle évite qu’un même slug d’entreprise devienne une identité globale ambiguë.
La base protège cette logique par deux contraintes d’unicité au niveau de l’entreprise : le couple collectivité–SIRET et le couple collectivité–slug. Deux collectivités peuvent ainsi représenter leurs propres périmètres, tandis qu’une même collectivité ne peut pas enregistrer deux fois le même SIRET ni publier deux URLs identiques pour ses entreprises.
Ce choix produit une séparation utile. La collectivité conserve son identité, ses utilisateurs et sa configuration. L’entreprise garde ses informations et ses contenus. Le visiteur voit un parcours cohérent, tandis que les équipes disposent d’objets distincts à administrer plutôt que d’une page monolithique impossible à faire évoluer.
La collectivité porte son nom, son slug, ses coordonnées et son habillage.
La recherche sélectionne les entreprises rattachées à cette collectivité.
Adresse, description, contenus, partenaires et offres donnent de la profondeur.
Nominatim localise l’adresse et Leaflet restitue le point sur OpenStreetMap.
L’usager contacte l’entreprise, consulte une offre ou dépose une candidature.
4. Un modèle territorial plus fin qu’un simple code postal
Région, département, EPCI, commune et collectivité gardent leur rôle
La géographie administrative est modélisée en plusieurs niveaux. La région conserve un code, un nom et un slug. Le département est relié à sa région. L’EPCI peut couvrir plusieurs régions et plusieurs départements, avec son code, sa population et son slug. La commune rassemble enfin son code, ses codes postaux, sa population, son SIREN et ses rattachements.
La collectivité utilisée par le portail reste un objet distinct de la commune de référence. Cette distinction évite de réduire l’organisation cliente à une ligne d’open data. Elle peut disposer de ses propres informations de contact, de ses horaires, de son URL d’application et de son identité visuelle tout en étant reliée au découpage administratif utile.
Ce découpage permet aussi d’ouvrir des recherches plus larges. Les écrans apparus en fin de construction proposent une entrée par région et par département, tandis que le parcours principal reste centré sur la collectivité. Le produit peut ainsi passer d’une navigation locale à une découverte territoriale plus large sans dupliquer les entreprises.
L’arbitrage important consiste à ne pas confondre référentiel géographique et contenu éditorial. Les codes et relations viennent structurer le territoire ; les descriptions, médias, offres et informations d’entreprise restent administrés dans les objets métier du portail.
5. Quatre référentiels administratifs alimentés par geo.api.gouv.fr
Importer des codes stables avant de construire la navigation territoriale
Cinq commandes Symfony couvrent quatre familles de données publiques : régions, départements, EPCI et communes. Elles interrogent directement les routes correspondantes de geo.api.gouv.fr, demandent du JSON, contrôlent le statut HTTP et transforment chaque réponse en objet Doctrine.
L’import des régions et des départements fonctionne par code. Une ressource existante est mise à jour ; sinon elle est créée avec un identifiant UUID et un slug dérivé de son nom. Les départements sont rattachés à leur région. Le chargement des EPCI relie de la même façon leurs codes aux régions et départements déjà présents.
Le chargement des communes est plus exigeant parce qu’il doit résoudre plusieurs dépendances. La version la plus récente récupère toutes les communes, retrouve ou crée la région et le département nécessaires, cherche l’EPCI lorsqu’un code est fourni, puis enregistre nom, code, codes postaux, population et SIREN. Une commune déjà connue par son code n’est pas recréée.
Cette intégration apporte un vocabulaire géographique cohérent au produit. Elle ne fournit pas les fiches d’entreprise et ne doit pas être présentée comme un import Sirene. Pour un projet territorial similaire, la page intégrateur geo.gouv.fr détaille précisément le travail de raccordement aux référentiels publics.
Une dépendance à traiter explicitement
Les relations imposent un ordre de chargement. L’EPCI doit pouvoir retrouver les régions et départements qu’il référence ; une commune portant un code EPCI attend que cet EPCI existe. Le système préfère alors interrompre le chargement avec un message explicite plutôt que de fabriquer une relation incomplète.
Ce comportement est un choix de cohérence. Il rend le défaut visible, mais appelle aussi une orchestration plus formelle si les imports doivent devenir récurrents et totalement autonomes.
6. Un annuaire qui respecte d’abord le périmètre de la collectivité
Chercher par nom sans mélanger les territoires
L’entrée publique /{collectivitySlug}/entreprises commence par vérifier l’existence de la collectivité. Elle transmet ensuite son identifiant au service de recherche d’entreprises. La requête Doctrine applique ce filtre et ajoute, lorsque l’usager saisit un terme, une recherche sur le nom de l’entreprise.
Les résultats sont ordonnés par nom par défaut et présentés sous forme de cartes. Chaque carte réutilise le slug de la collectivité et celui de l’entreprise pour produire une URL stable. L’adresse affichée reste attachée aux données de la fiche, ce qui évite de dépendre du service cartographique pour lister les professionnels.
Le produit prévoit des catégories, métiers, secteurs et rayons géographiques dans l’interface. Dans cette version, ces contrôles ne sont pas tous reliés à la requête serveur. Le parcours disponible repose donc sur une recherche textuelle par nom, une pagination dans la couche de données et une isolation par collectivité.
Cette sobriété évite de transformer une maquette de filtre en promesse fonctionnelle. Elle donne aussi un ordre clair pour la suite : connecter les secteurs et métiers déjà modélisés, puis ajouter la recherche géographique seulement lorsque les coordonnées auront été fiabilisées en amont.
7. Une fiche entreprise complète, localisée à la demande
Assembler l’adresse, Nominatim, Leaflet et les tuiles OpenStreetMap
La fiche publique est résolue avec deux clés : le slug de la collectivité et le slug de l’entreprise. Une fois l’entreprise retrouvée dans le bon périmètre, le contrôleur charge ses services, produits, références, témoignages, partenaires, offres d’emploi, projets et types de contact. L’écran peut ainsi restituer une organisation au-delà de son identité administrative.
La cartographie repose sur une chaîne courte et lisible. Le navigateur assemble rue, code postal et ville, envoie cette adresse au service de recherche Nominatim, puis récupère latitude et longitude du premier résultat. Leaflet centre une carte au niveau de zoom 13, charge les tuiles OpenStreetMap et ajoute un marqueur avec le nom et l’adresse.
Ce choix accélère l’apparition d’une carte sans introduire de stockage de coordonnées. Il évite aussi de bloquer l’enregistrement d’une entreprise sur une étape de géocodage. En revanche, l’affichage dépend de la disponibilité et de la qualité de Nominatim à chaque consultation ; aucun résultat ne laisse simplement aucune carte localisée.
Le prochain seuil de robustesse est donc connu : géocoder côté serveur lors de la création ou de la modification de l’adresse, conserver le résultat accepté, gérer plusieurs candidats et mettre en cache les coordonnées. Notre expertise d’intégration Nominatim couvre précisément ce passage d’un appel front direct à une chaîne de géocodage gouvernée.
Ce que signifie réellement le SIRET dans cette version
Le SIRET sert d’identifiant métier dans la fiche ; il n’est pas alimenté automatiquement par Sirene dans cette version. Son unicité est contrôlée à l’intérieur d’une collectivité, mais son statut ou sa fraîcheur ne sont pas vérifiés auprès d’une source externe.
Cette frontière compte : elle permet de parler d’une fiche structurée sans promettre un référentiel d’entreprises automatiquement réconcilié, dédoublonné et mis à jour.
8. Faire de chaque entreprise une petite vitrine administrable
Services, produits, projets, références, partenaires et témoignages dans le même profil
Le modèle d’entreprise possède huit familles de contenus complémentaires : configuration, services, produits, projets, références, partenaires, témoignages et offres d’emploi. La fiche publique interroge séparément chacune de ces collections, ce qui permet d’afficher seulement les blocs réellement renseignés et de faire évoluer un contenu sans réécrire toute la présentation.
Chaque ressource importante dispose d’un cycle de lecture et d’écriture. Les services de domaine contrôlent les demandes, la couche Doctrine assure recherche et persistance, puis des contrôleurs dédiés gèrent ajout, modification, suppression ou consultation. Produits, projets, références, partenaires, témoignages et services possèdent également leur gestion de média.
Cette granularité résout un problème concret de publication. Une entreprise peut modifier un produit sans toucher à ses références ; ajouter une réalisation sans rééditer son identité ; publier une offre d’emploi sans demander une modification globale de sa page. La collectivité conserve néanmoins le lien qui permet de replacer tous ces contenus dans le bon territoire.
Le résultat observable est une information plus actionnable qu’une ligne d’annuaire. L’usager peut comprendre ce que fait l’entreprise, ce qu’elle propose et comment elle s’inscrit localement. L’équipe d’administration travaille sur des objets ciblés, avec des formulaires et des écrans correspondant à leur responsabilité.
9. Relier la visibilité économique à un parcours de candidature
Publier une offre dans son contexte puis conserver la réponse du candidat
L’emploi constitue le second parcours mis en avant dès la page de collectivité. Une offre appartient à une entreprise et porte notamment un identifiant, un slug, un type de poste, une localisation, une durée hebdomadaire, un secteur, une description, une référence, une date de publication, des responsabilités et les compétences, qualifications ou expériences attendues.
Les offres peuvent être parcourues au niveau d’une collectivité, mais aussi depuis une recherche globale enrichie par la liste des régions. La vue détaillée garde le contexte territorial dans son URL. Depuis cette page, le visiteur peut transmettre prénom, nom, email, téléphone et message pour l’offre concernée.
La candidature devient un objet métier relié à l’offre et, lorsqu’il est authentifié, à l’utilisateur candidat. Le service d’écriture contrôle la demande avant enregistrement. Une confirmation visuelle informe ensuite l’usager du résultat. L’entreprise retrouve de son côté les offres et candidatures dans le back-office.
Ce parcours donne une conséquence concrète à l’attractivité : la fiche locale ne s’arrête pas à la découverte d’un acteur économique, elle peut conduire à une action. Aucun volume de candidatures ni gain de recrutement n’étant disponible, le bénéfice publié reste celui qui est directement observable dans le produit : l’offre et sa réponse partagent le même contexte d’entreprise et de territoire.
10. Treize routes API pour diffuser le référentiel sans dupliquer sa logique
Listes paginées, vues détaillées et accès protégé par jeton
La couche API expose treize routes GET spécialisées. Deux couvrent la liste et le détail des collectivités. Une liste les entreprises d’une collectivité ; une autre retrouve une entreprise par son slug et son identifiant de collectivité. Les neuf routes restantes servent les contenus d’entreprise : offres d’emploi, partenaires, produits, projets, références, services et témoignages, avec un détail supplémentaire pour les offres et les projets.
Les listes partagent un contrat de pagination avec page, limite, ordre et sens de tri. La recherche d’entreprises accepte en plus un terme textuel. Les réponses JSON séparent les groupes de sérialisation “list” et “details”, ce qui limite les champs exposés selon le besoin au lieu de retourner systématiquement tout le graphe Doctrine.
L’accès aux routes sous /api est sans session serveur. Le jeton reçu est recherché sur l’utilisateur, puis transformé en identité Symfony ; un jeton absent ou inconnu est rejeté. L’ensemble des routes exige ensuite le rôle utilisateur. La documentation OpenAPI est générée avec Nelmio pour rendre les paramètres, réponses et exigences de sécurité consultables.
Cette API crée une possibilité importante : alimenter une autre interface, une application mobile ou un site de collectivité sans recopier les règles de recherche. Elle demeure volontairement une API de lecture dans ce périmètre. Les écritures passent par les cas d’usage du back-office, ce qui conserve un seul chemin d’administration. C’est l’un des arbitrages que nous mettons au centre d’une API métier sur mesure.
Les rôles autorisés créent et modifient collectivités, entreprises et contenus.
Les mêmes services de recherche et règles métier organisent les données.
Twig produit les pages territoriales, annuaires, fiches et offres.
Les contrôleurs GET sérialisent listes et détails paginés en JSON.
11. Un back-office séparé selon les responsabilités
Administrateurs de collectivité, administrateurs d’entreprise et utilisateurs associés
La sécurité distingue les utilisateurs de collectivité et les utilisateurs d’entreprise. Les rôles administrateur héritent des droits utilisateur correspondants, tandis qu’un super-administrateur réunit les rôles d’administration. L’espace public reste accessible sans compte, l’espace client exige une authentification et le back-office demande un rôle rattaché à une collectivité ou à une entreprise.
Côté collectivité, les écrans couvrent la fiche, l’équipe, les utilisateurs, les entreprises, les offres d’emploi, les pages, les activités, les réglages et la personnalisation graphique. Côté entreprise, le menu donne accès à la fiche, aux utilisateurs, aux offres, partenaires, produits, projets, références, services, témoignages, médias et paramètres.
L’invitation d’un utilisateur possède son propre cycle : création, jeton de confirmation, email et validation. Cette mécanique évite de transmettre un mot de passe initial et permet de relier le compte à la bonne organisation. Les formulaires métier s’appuient ensuite sur ce contexte pour limiter les ressources manipulées.
Les médias sont gérés comme des objets distincts et peuvent être associés aux bannières, logos ou contenus. Cette décision rend l’identité visuelle d’une collectivité et les éléments d’une entreprise administrables sans changement de template. Elle rapproche le projet d’un back-office métier sur mesure, où les droits et les objets suivent le travail réel des équipes.
12. Une base largement testée, prête à renforcer son automatisation CI
Distinguer couverture fonctionnelle, packaging et déploiement effectif
Le projet contient 149 fichiers de tests PHPUnit. Ils couvrent les générateurs de requêtes, les lectures et écritures du domaine, les cas d’erreur et les parcours autour des collectivités, entreprises, services, produits, projets, références, partenaires, témoignages, utilisateurs, offres et candidatures. Cette profondeur accompagne la séparation entre entités, requêtes, réponses, présentateurs et accès aux données.
La chaîne d’intégration continue construit des images Docker PHP et Nginx différentes pour la démonstration et la production. Les images de démonstration sont produites depuis la ligne de développement ; les images de production depuis la ligne principale. Chaque construction publie son résultat dans le registre d’images et prévoit une nouvelle tentative en cas d’échec du job.
La chaîne de l’époque ne lance toutefois pas automatiquement ces 149 tests avant de publier les images : l’étape de test est désactivée dans la configuration. La couverture existe donc comme socle de non-régression exécutable, pas comme barrière CI garantie. L’amélioration prioritaire consiste à remettre cette suite dans le chemin de publication et à corriger tout test devenu obsolète avant d’autoriser l’image suivante.
Les configurations Nginx distinguent le domaine de démonstration du domaine principal, et les compositions d’environnement prévoient PHP, Nginx, MySQL, Redis et RabbitMQ. Elles prouvent un packaging ciblé ; elles ne suffisent pas à établir seules une date de recette, un niveau de disponibilité ou une exploitation continue.
13. Ce que le socle change concrètement pour chaque acteur
Des bénéfices observables sans inventer de KPI
Pour la collectivité : un périmètre économique administrable
La collectivité ne publie plus seulement une page générique. Elle possède son identité, ses médias, ses utilisateurs, son annuaire, ses entreprises et leurs offres. Le couple collectivité–SIRET protège l’unicité locale et les URLs territoriales conservent le contexte jusqu’à la fiche détaillée.
Pour l’entreprise : une présence qui peut évoluer par blocs
L’entreprise enrichit son profil avec des objets indépendants : service, produit, projet, référence, partenaire, témoignage ou offre d’emploi. Elle peut faire vivre une partie de sa vitrine sans réécrire toute sa fiche ni dépendre d’un développement spécifique pour chaque contenu.
Pour l’habitant : passer de la découverte à l’action
Le visiteur cherche un professionnel par nom dans sa collectivité, consulte son activité, situe son adresse, parcourt ses contenus et peut répondre à une offre. La carte complète la fiche ; elle ne remplace ni l’information métier ni le parcours de candidature.
Pour le système d’information : une donnée réutilisable
Treize routes GET rendent collectivités, entreprises et contenus accessibles en JSON avec pagination, groupes de sérialisation et jeton d’accès. Le portail web n’est donc pas l’unique sortie possible du référentiel.
Ces gains décrivent des capacités vérifiables du produit. Aucun chiffre de trafic, de temps gagné, de nombre d’entreprises actives, de candidatures reçues ou de satisfaction n’est disponible ; aucun pourcentage ne leur est donc attribué.
14. Les frontières qui rendent le projet crédible
Savoir ce qui fonctionne, ce qui reste direct et ce qui doit être industrialisé
La première frontière concerne les entreprises. Leur SIRET, leur adresse et leurs contenus sont gérés dans l’application. Aucune intégration Sirene ou INPI n’apparaît dans le périmètre : le produit ne vérifie donc pas automatiquement l’existence, le statut ou la fraîcheur d’un établissement auprès de ces référentiels.
La deuxième concerne la carte. L’adresse textuelle est envoyée à Nominatim lorsque la fiche est ouverte, puis le premier résultat sert au marqueur Leaflet. Il n’existe ni validation humaine du candidat géographique, ni score de confiance, ni cache de coordonnées. Une réponse ambiguë ou absente doit être traitée avant de faire de la carte une information de référence.
Cette référence constitue une preuve publique directe de l’usage d’OSM, mais ne prouve pas une extraction par Overpass. Pour concevoir cette collecte séparément, la page intégrateur OpenStreetMap et Overpass API porte les contrats de requête, quotas, cache, géométries et reprises.
La troisième concerne l’interface de recherche. Le filtre texte et le périmètre de collectivité sont reliés au serveur. Plusieurs choix de catégories, métiers, secteurs, distance ou tri sont encore présentés dans les écrans sans être tous exécutés par la requête. Ils constituent une direction de produit, pas des filtres achevés.
La quatrième concerne la vie du logiciel. Les tests sont nombreux mais ne sont pas une condition automatique de publication dans la chaîne de cette version. Les images de démonstration et de production sont construites, sans que cette configuration prouve à elle seule la bascule client. Ces limites n’effacent pas le socle ; elles identifient précisément les travaux nécessaires pour passer d’une plateforme fonctionnelle à un service pleinement industrialisé.
15. Trois prolongements naturels pour une plateforme territoriale
Fiabiliser la géographie, enrichir la donnée entreprise et ouvrir de nouveaux usages
Le premier chantier consiste à déplacer le géocodage dans un traitement serveur. À chaque modification d’adresse, le système pourrait interroger Nominatim ou un autre fournisseur, conserver les candidats, faire valider le bon point et servir ensuite la coordonnée stockée. La carte deviendrait plus rapide, contrôlable et moins dépendante d’un appel public à chaque visite.
Le deuxième concerne le référentiel d’entreprise. Si le besoin est confirmé, une connexion à Sirene, à l’API Entreprise ou au Registre national des entreprises pourrait compléter la saisie, contrôler certains champs et historiser leur provenance. Cette extension demanderait des règles explicites : quelles données restent éditoriales, lesquelles viennent de la source officielle et comment résoudre un désaccord.
Le troisième porte sur la diffusion. L’API de lecture fournit déjà les objets principaux. Elle peut être prolongée par des permissions plus fines, des webhooks, des écritures ciblées ou un contrat destiné à des sites municipaux. La page authentification et sécurité API devient alors centrale pour gouverner jetons, rôles et consommateurs.
Ces prolongements gardent la même ligne directrice : ne pas ajouter une intégration parce qu’elle existe, mais parce qu’elle résout une décision concrète du territoire, de l’entreprise ou de l’usager. C’est aussi ce qui distingue une application métier durable d’un assemblage de services externes.
16. L’attractivité locale se construit dans les liens entre les informations
Faire d’une adresse le début d’un parcours, pas la fin d’une fiche
La leçon d’Attractivité-locale.fr est simple : une carte isolée ne crée pas un service territorial. La valeur apparaît lorsque l’adresse renvoie à une entreprise bien rattachée à sa collectivité, lorsque cette entreprise peut expliquer son activité, publier une offre et recevoir une candidature, et lorsque les mêmes informations peuvent être relues par une autre application.
Dawap a construit cette continuité avec un modèle multi-collectivité, des profils d’entreprise riches, une couche géographique publique, une carte Leaflet/OpenStreetMap, treize routes API et des espaces d’administration séparés. Les choix structurants sont visibles jusque dans les clés d’unicité, les URLs territoriales, les groupes de sérialisation et les droits d’accès.
Le projet montre également où placer la prochaine exigence : fiabiliser le géocodage en amont, mettre les tests dans la barrière CI, achever les filtres avancés et décider quelles données d’entreprise doivent provenir d’un référentiel officiel. Pour concevoir une plateforme comparable, Dawap réunit l’intégration de données publiques, la création d’API métier et le développement d’application web sur mesure dans une même trajectoire.
