Onbo

Le problème

Une fois le devis signé, une agence web doit récupérer beaucoup de choses auprès de son client : logo, textes, accès à l'hébergement, informations de facturation. Cela se fait en pièces jointes, en messages et en relances écrites à la main. Personne ne voit clairement ce qui manque ni qui doit faire quoi.

La solution

Onbo donne un seul endroit aux deux côtés. Le client suit une checklist guidée et dépose ses fichiers. L'agence valide ou rejette chaque étape, avec un motif que le client reçoit. Un projet avance une étape validée à la fois.

Ce que fait le produit

• Une checklist par projet, avec un dépôt de fichiers rattaché à chaque étape.
• Validation ou rejet motivé, étape par étape, côté agence.
• Relances programmées pour les étapes bloquées, à J+0, J+3 et J+6.
• Modèles réutilisables (site vitrine, e-commerce, refonte SEO) pour rejouer une méthode sur un nouveau projet.
• Notes internes invisibles pour le client.
• Une marque à soi : logo, couleurs et domaine propre selon la formule.
• Un coffre d'accès pour les identifiants, chiffré, avec des secrets masqués et un journal des consultations.

Choix techniques

Le produit repose sur Next.js, avec PostgreSQL pour les données, S3 pour les fichiers déposés et Cloudflare devant l'ensemble. Les identifiants du coffre sont chiffrés en AES-256-GCM, et la clé de chiffrement est conservée séparément de la base. Les données sont cloisonnées par agence : un projet n'est accessible qu'à celle qui le possède et à ses clients invités.

Mon rôle

Je co-fonde Rinku Studio et je développe Onbo en binôme, côté TypeScript. Produit, interface, code, hébergement et support sont portés à deux, sans intermédiaire.

Où en est le projet

Onbo est en développement. Seule la page de présentation est ouverte au public pour le moment. Je n'affiche donc aucun chiffre d'usage : il n'y en a pas encore.