Faut-il une troisième page pour la distribution, le growth et le paid ?

Audit lu dans le code le 2026-09-20, à la demande : « logiquement avec ce que nous avons conçu dans le nouveau cockpit nous n'avons plus besoin des anciennes pages qui dispersent tout, mais plutôt réunir et modeler proprement ».

Correction du même jour, après relecture. La première version de cet audit concluait « la dispersion a déjà été fermée ». C'était faux, et la faute n'est pas dans le raisonnement : elle est dans le PÉRIMÈTRE mesuré. Je n'avais regardé que /ops, alors que deux maillons de la chaîne qu'il décrit — la veille et l'analyse — vivent entièrement ailleurs. La section « ce qui est déjà réuni » reste exacte pour /ops ; elle ne dit rien de ce qui comptait le plus. La conclusion corrigée est en fin de document.

Réponse courte : non à un second index, oui à tout faire vivre dans /studio. Ce sont deux phrases différentes, et les confondre est ce qui a rendu la première version de cet audit trompeuse. Ce qui reste n'est pas un problème de rangement : c'est un moteur entier que le cockpit ne lit nulle part, une poignée de gestes qui obligent à sortir, et deux piliers sans aucune ligne de code.

1. Ce qui est DÉJÀ réuni, et qu'il ne faut pas refaire

/ops déclare douze surfaces (ops-routes.ts) et le cockpit en lit onze comme sections (OPS_SECTION_IDS) — la douzième, /ops/docs, n'en a délibérément pas : son corpus est l'Academy, qui était déjà dans le rail, et lui donner un board aurait fait deux portes pour une pièce.

L'index de treize cartes qui vivait à la racine /ops est parti le 2026-09-19, avec son rail : le rail du Studio porte les mêmes surfaces, dérivées du même registre et filtrées par les mêmes permissions.

Donc la consolidation a eu lieu. Un troisième écran qui rassemblerait « distribution, growth, creative, social, paid » recréerait exactement l'index qu'on vient de supprimer, sous un autre nom.

La règle qui tient l'ensemble, et qui explique pourquoi les pages /ops répondent toujours : un board est une LECTURE, la page porte le GESTE. Rediriger les pages aurait supprimé l'action pour n'en garder que la photographie.

2. Ce qui oblige encore à sortir du cockpit

C'est ici qu'est le vrai travail, et il est petit comparé à une page neuve. Trois gestes vivent sur une page /ops alors qu'ils ont leur place dans le module :

Ce ne sont pas trois pages à fondre : ce sont trois gestures à étendre, dans le mécanisme qui existe déjà.

3. Ce qui n'existe pas du tout, et qu'aucune page ne créera

Deux des piliers nommés dans la demande n'ont aucun code :

• Paid. Rien. Pas de compte publicitaire, pas de campagne, pas de dépense, pas de ROAS. Les connecteurs Meta et Google existent, mais pour le tracking et les pixels : ils ne lisent aucun budget. Une page « paid » rendrait donc une surface vide sous un titre qui promet un pilotage — le défaut exact que src/components/CLAUDE.md interdit sous « il n'y a plus de données de démo ».
• Social organique mesuré. ContentRender.channel est une chaîne libre, dont six valeurs sont documentées en commentaire (email | article | linkedin | x | instagram | facebook). Postiz sait déposer un brouillon ; rien ne relit une portée, un engagement ou un abonné. Et AttributionEvent n'a volontairement pas de type impression : rien dans le dépôt ne sait en observer une.

Un écran ne comble pas ça. C'est de la donnée à aller chercher, donc des connecteurs, un modèle, une rétention — pas un rangement.

Recommandation

1. Ne pas ouvrir de troisième page. Le cockpit a déjà la forme, et la racine /ops a déjà payé une fois le prix d'un second index.
2. Étendre trois gestes (composition, brouillon Postiz au-delà de la vidéo, relecture de la file) pour que le cockpit cesse d'obliger à sortir. C'est le travail qui rapproche le plus l'écran de la promesse, et il tient dans le mécanisme existant.
3. Traiter paid et social mesuré comme des CONSTRUCTIONS, pas comme un déménagement : un modèle, un connecteur, une rétention, et seulement ensuite une surface. Tant qu'ils n'existent pas, ils restent visibles et inertes (ADR 0024 §3) plutôt que rendus vides.

Ce que la première version avait manqué

Posé la vraie question : pourquoi tout ne vivrait pas dans /studio, en modules par pilier, sur la chaîne contexte → veille → génération → distribution → analyse ?

Relu sur ce périmètre-là, et non sur /ops seul :

La veille est vraisemblablement la partie la plus puissante du produit, et le cockpit ne la lit nulle part : elle vit dans /intelligence (public), sept pages /admin/ai/intelligence/*, et des crons. C'est là qu'est la dispersion, pas dans /ops que la première version mesurait.

Et le rangement actuel du rail le cache : il groupe par TYPE D'OBJET (Create / Library / Developers / Account), donc un maillon absent ne laisse aucun trou visible. Groupé par ÉTAPE, l'absence se voit.

Conclusion corrigée

1. Pas de second index — la racine /ops a déjà payé ce prix une fois. Cette partie tient.
2. Ranger le rail sur la chaîne, pas sur le type d'objet. Même mécanisme (une section est un rendu, pas une navigation), rangé sur ce qu'on fait.
3. Brancher la veille dans le cockpit : c'est le plus gros gain du lot, et rien n'est à construire — tout est déjà en base.
4. Les trois gestes (design-system/2919) et les deux constructions (growth-web/2920) restent, inchangés.

Ce que cet audit ne dit toujours pas

Il ne mesure pas la QUALITÉ des onze boards : il établit qu'ils existent et que le registre les couvre. Un board qui compte mal reste un board présent, et c'est une autre lecture.