Sécurisation — publication brain Quartz
Rôle de cette page
Documenter la cause réelle des désynchronisations observées entre le brain de travail Tastiie et la version Quartz publiée, puis fixer les garde-fous à appliquer pour réduire durablement ce risque.
Diagnostic clair
Le problème constaté ne vient pas du moteur Quartz lui-même.
Le problème vient du fait que :
- le brain de travail et la source live ne sont pas synchronisés automatiquement,
- la publication repose encore sur une routine de copie ciblée,
- une publication partielle peut donc laisser le live dans un état intermédiaire,
- le même Quartz peut ainsi servir une navigation correcte tout en exposant un contenu incomplet.
Pourquoi cela peut arriver alors que c’est le même Quartz
Quartz est le moteur de rendu.
Mais le rendu dépend du contenu présent dans la source live au moment du build.
Si :
- la note a été écrite dans le brain de travail,
- mais qu’une page liée, un index de section ou un document maître n’a pas été recopié côté live,
alors le site publié reste cohérent techniquement, mais il n’est plus aligné fonctionnellement avec la source de travail.
Autrement dit : même moteur, mais pas forcément même contenu source.
Cause racine retenue
La cause racine retenue est : une chaîne de publication manuelle, partielle et non verrouillée entre la source de travail et la source live.
Risques concrets observés
- une note existe en travail mais pas en live,
- l’index de section ne remonte pas une nouvelle page,
- une URL semble répondre alors que le contenu attendu n’est pas celui réellement publié,
- le live peut dériver progressivement si plusieurs sections évoluent sans routine de contrôle globale.
Règles de fonctionnement retenues
1. Source de vérité
La source de travail Tastiie est la référence éditoriale.
La version live est une surface publiée, pas la source canonique de rédaction.
2. Règle de fin de tâche
Une note demandée n’est pas considérée comme terminée tant que :
- elle n’a pas été publiée,
- l’index utile a été mis à jour,
- la lecture publique a été vérifiée,
- le lien a été transmis.
3. Règle de publication
Toute publication doit inclure au minimum :
- la note modifiée,
- l’index de section concerné,
- toute page transversale rendue visible depuis la navigation,
- une vérification publique réelle.
4. Règle de contrôle
Un contrôle régulier de dérive doit comparer :
- la source de travail,
- la source live,
- et signaler toute divergence durable.
Garde-fous mis en place
Garde-fou 1 — contrôle de dérive
Un contrôle de dérive compare désormais le contenu de travail et le contenu live, afin de faire remonter :
- les pages présentes seulement d’un côté,
- les pages présentes des deux côtés mais différentes.
Garde-fou 2 — preuve publique obligatoire
Un simple chargement d’URL n’est pas une preuve suffisante.
La validation doit confirmer :
- le bon titre,
- la bonne page,
- la présence dans la navigation publique,
- et les marqueurs métier attendus.
Garde-fou 3 — gouvernance explicite
Le brain doit distinguer clairement :
- ce qui est rédigé,
- ce qui est publié,
- ce qui a été vérifié publiquement.
Limite restante à traiter ensuite
La réduction de risque est immédiate, mais l’élimination complète du risque passera idéalement par une chaîne de publication encore plus unifiée, avec moins de dépendance à la copie manuelle section par section.
Décision opératoire
Jusqu’à mise en place d’une chaîne encore plus intégrée, la discipline à appliquer est : source de travail → copie complète utile → build → contrôle de dérive → preuve publique.