Console + site public

Deux endroits où Letaido place ce qu'il construit : un pour votre équipe, un pour tous les autres.

1. La Console (interne)

La Console est une application web réservée aux membres où Letaido dépose des outils internes. Considérez-la comme la surface de tableau de bord privée de votre équipe.

Accessible uniquement aux membres de l'espace de travail. Les visiteurs anonymes rencontrent un mur de connexion.
L'application lit l'identité depuis les en-têtes d'authentification, donc chaque page sait qui la consulte (propriétaire, administrateur, membre, observateur).
Accès à la base de données : lecture/écriture complète sur console_db et console_site_db. Ne peut pas accéder à site_db.

Créer une page Console lorsque :

Le résultat est destiné uniquement à votre équipe.
Il doit interroger des données internes, appeler des connecteurs ou afficher des contrôles.
Les clients ne doivent jamais le voir.

Rapports, Applications, Artefacts

Tout ce que Letaido construit dans la Console se classe dans l'une des trois catégories. La page d'accueil de la Console comporte un onglet pour chacune (Reports, Applications, Artifacts) ainsi qu'un onglet Accueil qui répertorie tout ensemble, du plus récent au plus ancien, avec la catégorie sous forme d'étiquette à côté du titre.

Catégorie	Ce que c'est	Ce que votre équipe en fait	Exemples
Reports	Graphiques, tableaux et vues de données filtrées	Ouvrez-le, lisez les chiffres, filtrez, quittez	Ahrefs Brand Authority, AI Visibility, Rank Monitor
Applications	Outils multi-pages et flux de travail complexes	Collez une entrée, lancez un pipeline, obtenez une sortie, revenez aux exécutions passées	Battlecard Generator, AI Visibility Dashboard, Paid Ads Campaign Builder
Artifacts	Éléments ponctuels : un graphique, un tableau, un extrait de texte	Jetez-y un coup d'œil, copiez-le, partagez-le, passez à autre chose	Aperçu d'e-mail, bloc de page d'accueil, section AEO 101, Ahrefs Feature Library

Rapports

Un rapport est quelque chose que vous ouvrez pour consulter l'état de quelque chose. La valeur réside dans les données affichées ; l'interaction principale consiste à lire ou filtrer. Les rapports se rafraîchissent à partir de leurs sources de données selon un calendrier ou à la demande. Ils se trouvent à /reports/<slug>/.

Demandez un rapport lorsque la réponse à « pourquoi cela existe-t-il » est « pour que nous puissions voir X en un coup d'œil » (l'état de nos classements, la part de voix cette semaine, le delta d'autorité de marque de ce mois-ci).

Applications

Une Application est quelque chose que vous utilisez pour travailler. La valeur réside dans le flux de travail ; l'interaction principale consiste à créer, modifier ou produire. Les Applications prennent des entrées, exécutent des pipelines en plusieurs étapes, stockent les résultats et permettent à votre équipe de revenir aux exécutions passées. Elles se trouvent à /applications/<slug>/.

Demandez une Application lorsque la réponse à « pourquoi cela existe-t-il » est « pour que nous puissions faire X de manière répétée sans reconstruire le workflow à chaque fois » (générer une fiche de bataille, exécuter un brief de campagne, produire un texte).

Artefacts

Un Artifact est un élément de sortie unique que vous déposez une fois et référencez plus tard. Il est petit, autonome et ne mérite pas d'être intégré dans une application ou un rapport complet. Les Artifacts se trouvent dans /artifacts/<slug>/.

Demandez un Artefact lorsque la réponse à « pourquoi cela existe-t-il » est « pour que l'équipe ait un endroit où le consulter » (un aperçu de bloc de page d'accueil, l'e-mail de cette semaine, une bibliothèque de fonctionnalités, une fiche récapitulative pour les ventes).

Vous ne savez pas lequel choisir ?

Décrivez le résultat et l'agent choisit le bon compartiment.

« Montrez-moi l'autorité de marque hebdomadaire par concurrent. » → Rapport.
« Créez-moi un outil où je colle l'URL d'un concurrent et j'obtiens une fiche de comparaison en retour. » → Application.
« Générez un aperçu de la newsletter de la semaine prochaine. » → Artefact.

2. Le site public (externe)

Le site public est la partie de votre Workspace accessible depuis l'internet ouvert, complètement isolée de la Console que votre équipe utilise. Il existe pour diffuser du contenu aux personnes extérieures à votre Workspace.

Modèle d'URL : /<route> pour tout. Modèles conventionnels : /u/<token> pour les rapports partagés ponctuels, /r2s/<token> pour les exécutions examinées, /docs/<slug> pour cette documentation.
La visibilité est contrôlée par un bouton bascule au niveau de l'espace de travail (voir Modes ci-dessous).
Accès à la base de données : lecture/écriture site_db (il en est propriétaire). Lecture/écriture console_site_db. Ne peut pas accéder à console_db.

Créez une page de site public lorsque : - Un client, un prospect ou un visiteur anonyme doit voir quelque chose. - Vous souhaitez une URL partageable en dehors des e-mails ou de Slack. - Les données ont déjà été générées (dans Console ou par une tâche) et vous ne faites que les servir.

Trois modes pour le site public

Le site public a trois états, basculés par un propriétaire ou un administrateur depuis l'interface de l'espace de travail. L'agent lui-même ne peut pas les modifier.

off : nginx renvoie une erreur 403 à tout le monde. Le processus Flask continue de fonctionner ; aucun trafic ne l'atteint.
authorized : les membres de l'espace de travail et les invités explicitement invités peuvent le consulter. Idéal pour une révision avant un lancement.
open : toute personne disposant de l'URL peut le consulter. Traitez chaque visiteur comme non fiable.

Lorsque le mode est open, l'agent applique des paramètres par défaut supplémentaires : validation Pydantic sur chaque entrée de visiteur, aucun appel de connecteur par visiteur (mise en cache dans site_db à la place), approbations de connecteur séparées pour la surface du site, et la sortie visible est nettoyée avant la persistance.

Communication inter-surfaces

La Console et le site public fonctionnent dans des processus distincts. Ils peuvent toujours coopérer, mais uniquement via un canal explicite : la base de données console_site_db.

La Console écrit des données (un rapport, un résumé, un artefact) dans une table.
Le site public lit cette table et l'affiche à une URL protégée par jeton.
Le site peut renvoyer des signaux d'interaction (par exemple « le visiteur a cliqué ») que la Console lit.

L'agent n'essaie PAS de transmettre une requête Console via une route publique. Le REVOKE se situe au niveau de la base de données ; cela échouerait de toute façon, et ce serait également une mauvaise conception.