🔀 La transition
Pendant plusieurs mois, l'ancien dépôt et celui-ci vont vivre côte à côte. C'est normal et c'est sain : on ne remplace pas un site en production d'un seul coup. Mais sans règles claires, cette cohabitation se transforme vite en travail de recopie permanent, où personne ne sait plus quelle version fait foi.
🤝 Les quatre règles de cohabitation
Elles tiennent en quelques lignes et évitent l'essentiel des ennuis.
1Un artefact, un seul propriétaire
Jamais deux dépôts qui peuvent modifier légitimement la même chose. Dès qu'il y en a deux, il n'y a plus de synchronisation : il y a des fusions à la main, indéfiniment.
2Préférer la référence à la copie
Une règle recopiée devient fausse dès que sa source bouge. Une règle qui pointe vers sa source ne peut pas mentir. Ce qui reste après ce filtre est le vrai périmètre à synchroniser.
3Le miroir est en lecture seule
Ce qui remonte de soliguide vit dans une zone régénérée par script, jamais éditée à la main. Sans cette règle, quelqu'un patche le miroir un jour de rush et la resynchronisation suivante l'écrase.
4Toujours tirer, jamais pousser
soliguide-neo n'écrit jamais dans soliguide. Chaque dépôt décide quand il se met à jour — techniquement plus sûr, et politiquement acceptable dans un dépôt open source à plusieurs contributeurs.
🔧 Ce qu'on appelle le back-office
Le mot revient souvent, alors autant préciser ce qu'il recouvre. Ce n'est pas une application, mais un périmètre : tout ce qui sert à faire vivre la base sans jamais être vu par une personne qui cherche de l'aide.
Ce qu'il contient
- 🗂️ La gestion des fiches, dans l'application Angular : le formulaire par lequel une structure décrit son lieu, la modération par l'équipe, les comptes, les traductions, l'historique des modifications.
- 🔗 SoliHub, le hub des intégrations, qui rapproche les bases publiques des fiches existantes pour repérer ce qui manque. Il vit encore dans
soliguide-tools, à côté de projets sans rapport avec lui, et rejoindra ce périmètre.
Pourquoi il ne migre pas
Le back-office ne remonte pas dans les moteurs de recherche, et personne ne le découvre par hasard : il s'adresse à des professionnels qui s'y connectent, souvent tous les jours, et qui le connaissent par cœur. Le réécrire coûterait cher, ferait perdre des repères à ceux qui s'en servent, et n'apporterait rien à personne. 🎯
C'est aussi ce qui rend le chantier tenable : en laissant de côté ce périmètre, on concentre l'effort sur les pages qui doivent être trouvées.
🏁 Et à la fin ?
L'objectif est de tout rapatrier ici, pour que l'ancien dépôt puisse être mis au rebut. On y va progressivement : d'abord le site public, puis la web-app, puis le widget. Le back-office restera dans l'ancien dépôt jusqu'à ce qu'on décide quoi en faire — et cette décision-là n'est pas urgente, parce qu'il fonctionne très bien.
Une seule technologie pour tout ce qui est public, c'est le point clé. Une équipe de notre taille ne peut pas entretenir Angular, Svelte et Astro en même temps : chaque technologie supplémentaire, c'est un savoir-faire à maintenir, des mises à jour à suivre et des composants à écrire trois fois.