Cette page décrit toutes les briques du produit : ce que chacune fait, à qui elle s'adresse, et ce qui va changer pour elle. Une architecture qu'on ne peut pas lire d'un coup d'œil est une architecture que chacun se raconte différemment — et c'est là que les malentendus commencent.
Un point important pour bien lire ce qui suit : l'application Angular actuelle fait deux métiers à la fois. Elle porte le site public, celui que voient les personnes qui cherchent de l'aide, et le back-office, celui où les structures tiennent leurs fiches à jour. Seule la partie publique est reprise ici.
L'existant, dans le dépôt historique. Une mention « à retirer » n'est pas un jugement sur la qualité du code : c'est simplement la trajectoire qu'on a décidée ensemble.
Ce que voient les personnes qui cherchent de l'aide, et les structures qui tiennent les fiches à jour.
Une seule application Angular porte DEUX choses : le site public soliguide.fr, et le back-office où les structures tiennent leurs fiches à jour. Le contenu n'existe qu'une fois le JavaScript exécuté — les robots des moteurs génératifs n'en exécutent pas et voient une page vide.
➡️ Seule la partie publique migre vers Astro. Le back-office reste en Angular : aucun enjeu de référencement, et le réécrire n'apporterait rien.
soliguide.fr ↗ · Espagne et Catalogne ↗ · Andorre ↗
À retirerapp.soliguide.fr. Couvre déjà une partie du public en rendu serveur, mais dans une technologie qu'on abandonne : une équipe réduite ne peut pas entretenir Angular, Svelte et Astro en même temps.
➡️ Reprise en Astro dans soliguide-neo. Adieu Svelte.
En serviceL'intégration embarquée chez les partenaires, configurée par les paramètres de son iframe.
En serviceLe back-office : données, recherche, géolocalisation.
Elle fait deux métiers : servir les données aux applications qui les affichent, et porter la logique du back-office (comptes, droits, validation des fiches). Tout est en Node.js, sans exception.
En serviceEn construction. Versionnement par date à la manière de Stripe, specs OpenAPI générées et servies, schémas TypeScript produits automatiquement. Elle s'authentifie par clé : chaque intégrateur reçoit la sienne, ce qui permet de savoir qui appelle quoi et de couper un accès sans toucher aux autres.
➡️ Devient la source unique de données pour les applications publiques.
🔌 Suivi par Ulrich
CibleCe qui propose des besoins et des lieux pendant que la personne tape sa recherche. C'est souvent le premier contact avec le produit : si les suggestions sont mauvaises, la recherche l'est aussi.
🧭 Suivi par Yassine
En serviceGéocodage et résolution des territoires.
🧭 Suivi par Yassine
En serviceCe qui sert à alimenter et vérifier la base, sans jamais être vu par le public. Ces outils ne remontent pas dans les moteurs de recherche, et c'est très bien ainsi.
Le hub des intégrations. Il rapproche des bases publiques — aujourd'hui le répertoire FINESS des établissements de santé, soit environ 60 000 lieux — avec les fiches Soliguide existantes, pour repérer ce qui manque et ce qui pourrait être enrichi. Un serveur pour le traitement, un tableau de bord pour lire les résultats.
➡️ Il vit aujourd'hui dans soliguide-tools, à côté de projets qui n'ont rien à voir avec lui. Il rejoindra le périmètre back-office.
En serviceCe qui circule entre les paquets — et ce qui diverge.
Le modèle de données : lieux, structures, catégories, traductions, recherche. 188 commits sur douze mois, dont plus de la moitié coordonnés avec l'API ou une application.
➡️ Reste propriété de soliguide. Consommé par contrat, pas copié.
En serviceLa taxonomie des catégories et la police d'icônes générée depuis les SVG sources.
➡️ Va être réordonnée. Seuls ses produits sont consommés.
En serviceL'ancien système de composants. Abandonné au profit de Tailwind et DaisyUI.
➡️ Remplacé par les tokens Figma et le paquet ui.
À retirerLa cible, dans ce dépôt-ci. Tout ce qui est public passe à Astro — le site, la web-app et le widget. Le back-office, lui, ne bouge pas.
Une application = un déploiement qui vit sa vie, avec sa propre adresse.
Le HTML porte le contenu sans JavaScript — c'est le critère qui justifie tout le chantier. Les parties interactives deviennent des îlots chargés à la demande.
🧩 Suivi par Younes
CibleLe point d'entrée du dépôt et la page que tu lis : architecture, migration, design system, développement, skills. Le design system y a sa branche — tous les composants y sont visibles, et aucun ne peut exister sans y figurer.
En serviceL'intégration que les partenaires embarquent dans leur propre site : une vitrine de Soliguide chez les autres, qui mérite le même soin que nos propres pages.
➡️ En attente depuis le 27 août 2026 : sa conception va être entièrement revue, on ne reprend pas l'existant. L'emplacement apps/widget reste vivant, rien n'y est décidé.
🧩 Suivi par Younes
Cibleapp.soliguide.fr, reprise dans la même technologie que le site public. Une seule pile pour tout ce qui est public : une équipe réduite ne peut pas entretenir deux savoir-faire en parallèle.
🧩 Suivi par Younes
CibleDes paquets jamais publiés sur un registry, consommés par workspace.
La nomenclature des adresses — la langue en tête, puis la page — reprise à l'identique de l'ancien site et suivie par les trois apps. C'est elle qui redirige une adresse sans langue et qui renvoie un vrai 404 sur une langue inconnue.
CibleLes textes légaux — mentions, CGU, confidentialité, cookies, accord de protection des données — en une version par pays, dans sa langue officielle. Le site public et la web-app affichent les mêmes ; le widget n'en a pas.
CibleTout ce qui se voit à l'écran, en un seul endroit : les couleurs venues de Figma, les images rangées par pays, la police d'icônes, la feuille de style unique et le registre des composants. Une app qui ajoute son propre CSS fait échouer la vérification.
CibleSavoir de façon fiable qui se connecte. L'exigence monte nettement par rapport à aujourd'hui : le jeton fabriqué maison ne suffira plus. On veut aussi pouvoir se connecter avec son compte Google, et rester reconnu d'une application à l'autre.
➡️ Une authentification par pays : pas de session à partager entre soliguide.fr, soliguia.cat et soliguia.ad. Rien n'est arrêté pour autant — ni le fournisseur, ni le protocole, ni le niveau d'exigence. C'est le sujet d'Ulrich.
🔌 Suivi par Ulrich
CibleLa gestion des fiches et la modération, qui restent telles quelles. Elles se détachent simplement du site public et prennent leur propre adresse, ce qui permet aux deux d'évoluer chacun à son rythme.
CibleCe qui vérifie, compile et met en ligne à chaque modification : les contrôles de qualité, les tests, les budgets de performance et le déploiement. C'est elle qui fait respecter nos règles sans que personne ait à y penser.
🧭 Suivi par Yassine
CibleLe client typé, produit depuis la spec versionnée de l'API publique. Régénérable en une commande, jamais retouché à la main.
🔌 Suivi par Ulrich
CibleCette page montre les briques. Les quatre suivantes expliquent comment on travaille avec.
Comment on construit les pages, concrètement ?
Qu'est-ce qu'on récupère de l'existant, et comment ?
Qu'est-ce qu'on attend de la nouvelle API ?
Comment on reconnaît les personnes et les machines ?
Comment les deux dépôts cohabitent, et jusqu'à quand ?