Guide
Documentation
Toutes vos applications. Une seule vue. Un seul cerveau. Coreora est conçu comme le médecin et le centre de commandement d’un portefeuille d’applications. Une rubrique = une source. Si une page n’a rien de spécifique, elle n’existe pas.
Guide de connexion
Le premier parcours est volontairement court : créer un compte avec e-mail et mot de passe, puis ajouter une application. Free reste à 0 €, une seule application, sans carte bancaire et sans compte à rebours. Rien ne bascule vers un abonnement tant que vous n’ajoutez pas d’apps ou de puissance.
L’URL publique suffit pour ouvrir le monitoring de surface. Coreora sonde cette adresse, rien d’autre. Sans URL, la fiche existe mais le score publié reste non évalué — pas un 0/100 déguisé.
Les intégrations viennent ensuite, facultatives. Vous collez une clé GitHub, Railway, Stripe, Resend, OpenAI ou un DSN Sentry : Coreora interroge le fournisseur tout de suite. Si l’API refuse, la valeur n’est pas enregistrée et le motif HTTP ou de format s’affiche. « Clé sauvée » n’existe plus sans preuve.
Quand le test réussit, Coreora liste ce que le compte autorise (dépôts, projets, produits, domaines) et tente les rapprochements uniques vers vos fiches. Les cas ambigus restent à confirmer sur la page Découverte.
Niveau 1
URL seulement
disponible
disponibilité · temps de réponse · HTTPS / SSL · erreurs HTTP · redirections · pages essentielles · performance publique · SEO de surface · accessibilité de base · éléments visibles
Niveau 2 · facultatif
SDK Coreora
à venir
utilisateurs · sessions · événements · erreurs internes · performance applicative · features utilisées
Niveau 3 · facultatif
Intégrations
partiel — chaque connecteur est facultatif
GitHub · Stripe · hébergeurs · Sentry · e-mails · bases · analytics
Niveau 4 · facultatif
Contrôle avancé
coupé — jamais en silence
préparer un correctif · branche / pull request · déploiement contrôlé · rollback · réparations autorisées
SDK
Le SDK Coreora n’est pas publié. Les paquets prévus sont @coreora/sdk, @coreora/node, @coreora/next et coreora-python. En attendant, le contrat d’événements est déjà figé pour ne pas inventer des utilisateurs.
Installation cible : npm i @coreora/sdk puis initialiser avec l’identifiant d’application et une clé d’ingestion émise depuis la fiche. Alternative : POST /api/ingest/errors pour les erreurs techniques seules.
Événements prévus : session started, session ended, user signed up, subscription changed, feature used, error occurred, request duration, application version. Charge utile : identifiant, version, environnement, agrégats — pas de PII nominative.
Sans SDK, Coreora n’affiche aucun « connectés maintenant », aucun taux d’abandon d’onboarding, aucun DAU. Ces cases restent « Non connecté ». Un ping URL ne remplace pas une session applicative.
API
L’identité publique est GET /api/public/identity : Coreora · coreora.novacore-fr.com. La santé machine est GET /api/public/health (200 ou 503) et GET /api/public/status. Ces routes sont limitées à 60 requêtes / minute / IP.
Les routes authentifiées lisent la session (cookie httpOnly). GET /api/export ?kind=apps|audits&format=json|csv|pdf sort le portefeuille de l’espace courant, jamais celui d’un voisin. POST /api/webhooks/inbound exige HMAC, horodatage ±5 min et nonce anti-rejeu (WEBHOOK_SECRET).
Formats d’erreur : 400 corps invalide, 401 session absente, 403 permission, 422 clé fournisseur refusée après test, 429 quota. Le corps JSON porte { error } en français, sans stack et sans secret.
Deux comptes Stripe existent : celui de Coreora (formules, plus tard) et celui du client (produits de son app). Relier le second ne fabrique pas un MRR. Resend et OpenAI, s’ils répondent, boostent l’e-mail et l’explication — le monitoring URL continue s’ils tombent.
GitHub
La cible produit est une GitHub App (« Connecter GitHub »), pas un jeton collé dans un champ anonyme. En MVP, un GITHUB_TOKEN du coffre est testé contre GET /user/repos : Coreora ne déclare la connexion que si la liste revient.
Lecture et réparation sont séparées. Aujourd’hui : repo:read — code, commits, branches, pull requests. Écrire (branche, commit, PR) exige un consentement distinct. Aucun push sur main, aucun merge silencieux.
Le flux healing prévu : constat → correctif → branche → pull request → GitHub Actions → résultat annoncé → Observation / Assisté / Autopilot. Le coupe-circuit kill.github arrête toute écriture sans redéployer.
Un dépôt déclaré à la main sur la fiche n’est pas une preuve d’accès. Le ✅ n’apparaît que si l’API a listé owner/nom. Les dépôts orphelins restent visibles dans Découverte.
Monitoring
La sonde de surface interroge l’URL officielle d’abord, puis l’URL de repli. Elle note HTTPS, chaîne TLS, code HTTP, redirections et latence. Ce n’est pas un APM : une page 200 lente n’invente pas une requête SQL.
L’uptime 24 h n’est calculé qu’à partir de trois échantillons réels. S’il est à 75 %, la santé affichée ne peut pas être « Excellent 100 % » : le plafond suit l’uptime observé.
Un incident d’indisponibilité s’ouvre quand la sonde échoue, se clôt quand elle réussit à nouveau. Pause : plus de contrôles périodiques. Maintenance déclarée : pas de fausse urgence P0.
Fréquence : file Job portfolio_checks selon la formule, pas un ping chaque seconde. Apps sans URL : état inconnu, tiret /100, jamais un zéro punitif.
Sécurité
Les secrets du coffre sont chiffrés au repos (ciphertext + lastFour). Après enregistrement, la valeur n’est plus renvoyée. Un secret n’est écrit que si le test fournisseur a réussi : une mauvaise clé n’écrase pas une bonne.
L’isolation est l’espace de travail. Une requête authentifiée charge le membership ; les lectures Prisma filtrent workspaceId. Un export, un audit ou une alerte d’un espace A n’apparaît pas dans B.
Rate limiting : auth 8 / 15 min, signup 5 / h, API publique 60 / min, webhooks 30 / min, réparations 8 / h (3 en production). Les webhooks refusent signature fausse, horloge dépassée et nonce rejoué.
Le journal d’activité horodate connexions d’intégration, audits, invitations. Les coupe-circuits (kill.github, feature.healing) se basculent sans rebuild. Coreora n’écrit pas les jetons dans les logs.
Permissions
Les rôles d’espace sont Owner, Admin, Developer, Analyst, Viewer, Billing. Le créateur d’un espace personnel a les droits d’admin sur ce portefeuille. INTERNAL_OWNER (saasnovacore@gmail.com) n’est pas une offre : il est provisionné serveur.
Matrice : write_apps / secrets / invite = Owner, Admin, USER. Incidents et technique = + Developer. Rapports = + Analyst. Facturation = Billing. Viewer lit seulement. Analyst ne voit pas le coffre et n’applique pas de réparation.
Avoir le droit de tout voir ne complète pas les fiches. La découverte exploite les clés ; les permissions décident seulement qui peut tester une clé ou lancer « Compléter automatiquement ».
Le moindre privilège s’applique aux fournisseurs : lire GitHub ≠ écrire une PR. Une action Autopilot exigerait un consentement séparé, journalisé, révocable.
Self-Healing
Trois modes, jamais silencieux. Observation : Coreora décrit et s’arrête. Assisté : il prépare, l’humain approuve. Autopilot : il exécute dans le périmètre autorisé, puis vérifie et journalise.
Toute réparation passe d’abord par le bac à sable (succès, échec, timeout, rollback, refus, déjà fait, doublon). Production réelle : coupe-circuit. feature.healing est off par défaut. Autopilot s’ouvre à Studio, pas à Free ni Solo.
Le rollback est une condition de lancement, pas un bonus. Si on ne peut pas revenir en arrière, l’action n’est pas proposée. Les tests GitHub Actions doivent parler avant un merge.
Limites : pas de push sur main, pas d’action hors playbook, pas d’écriture si kill.github ou kill.healing est actif. Une réparation refusée reste visible dans le journal des interventions.
OpenTelemetry
OpenTelemetry est le standard ouvert : métriques (CPU, mémoire, latence, débit), journaux (événements, erreurs), traces (parcours d’une requête entre services). Coreora vise la compatibilité, pas un agent propriétaire.
L’ingest prévu est POST /api/ingest/otel. Statut : prévu. Sans exportateur, l’onglet reste « Non connecté ». Un exemple pédagogique — GET /checkout 2800 ms dont 1900 ms en base — n’est jamais collé comme donnée d’un client.
Le SDK Coreora, une fois publié, devra émettre ces trois signaux. Une sonde URL 200 ne dit pas qu’une requête SQL prend 1,9 s. C’est précisément le trou que les traces ferment.
Branchement cible : exporter OTLP vers Coreora ou un collecteur déjà en place. Coreora lira les spans ; il n’inventera pas une répartition DB / Stripe / serveur sans trace reçue.
Architecture
Aujourd’hui : application Next.js (web + API) sur le port 3011 en local, table Job PostgreSQL comme file, workers dans le même processus (processJobs). Cible Railway : séparer web, api, workers monitoring / audit / healing, Redis devant la file.
PostgreSQL est la mémoire (espaces, apps, audits, secrets chiffrés, e-mails). Local : 127.0.0.1:5442. Redis viendra pour le cache et la file ; il n’est pas encore le cœur. Perdre OpenAI, Resend ou Stripe ne doit pas arrêter les sondes.
Types de tâches : checks_all, portfolio_checks, audits_due, audit, notify, analyze, report, repair (bloquée), sync, backup, email, discover. Trois tentatives puis dead-letter, jamais une boucle infinie.
Watchdog : processus externe, hors Railway, qui alerte si Coreora lui-même ne répond plus. Coreora est aussi un patient (isSelf) dans le portefeuille OWNER.
Philosophie
Coreora est le médecin d’un portefeuille, pas un voyant. Observer, détecter, comprendre, prioriser, recommander, corriger, tester, vérifier, mémoriser, prévenir. Chaque étape exige une preuve ou un « Non connecté ».
Interdit : inventer un MRR, un DAU, un pourcentage d’utilisateurs, un euro d’impact. Interdit : « plus que X jours gratuits », carte obligatoire pour rester Free, bascule automatique vers un abonnement.
Ce produit n’est pas un ping monitor, ni un chatbot générique, ni un outil qui agit sans permission. Self-Healing public bloqué tant que rollback, journaux, permissions ou risque d’action non autorisée restent ouverts.
Une correction du moteur — score, cartes, GitHub, sécurité, découverte — vit dans le noyau partagé. OWNER et clients exécutent le même code ; seuls les secrets et les droits diffèrent. On préfère huit pages utiles à trente-cinq copies.