Lab JRi / produit

Cas – Mishka (Lab JRi)

Mishka est un SaaS de gestion éditoriale développé au sein du Lab JRi : un outil pensé pour les agences et freelances, qui centralise clients, missions, tâches et calendrier éditorial.

D’où vient Mishka ?

En accompagnant des agences de communication et des indépendants, j’ai souvent vu le même problème :

• des contenus éparpillés entre tableurs, outils de tâches, mails,
• une difficulté à avoir une vue claire sur « qui fait quoi, pour quel client, sur quel canal et pour quand »,
• des outils généralistes (Notion, Trello, Monday, etc.) utilisés, mais souvent trop lourds ou trop libres pour des équipes qui veulent simplement « savoir où elles en sont ».

Mishka est né de ce constat.

Le problème à résoudre

Les équipes éditoriales avaient besoin :

• d’un outil assez structuré pour gérer clients, missions et contenus,
• mais assez simple pour être réellement utilisé au quotidien, sans formation lourde ni sur-paramétrage.

Les outils existants étaient soit :

• trop généralistes, nécessitant beaucoup de configuration,
• soit trop rigides, peu adaptés aux réalités d’une petite équipe éditoriale.

Objectifs produit

Avec Mishka, je me suis fixé quelques objectifs simples :

• Centraliser clients, missions, tâches, contenus et planning dans un seul outil.
• Offrir des vues adaptées : calendrier éditorial, vue Kanban / pipeline, listes par client ou par canal.
• Rendre les responsabilités visibles : qui porte quoi, et pour quand.
• Rester suffisamment léger pour tenir dans le quotidien d’une agence ou d’un freelance.

Approche & solution

1. Modèle de données centré sur le métier

• entités principales : Clients, Projets/Missions, Contenus, Canaux, Utilisateurs, Deadlines ;
• liens pensés pour refléter la réalité d’une production éditoriale (un contenu peut être lié à plusieurs canaux, un client à plusieurs projets…).

2. Scénarios d’usage prioritaires

Je me suis concentré sur quelques scénarios :

• planifier un calendrier éditorial par client,
• suivre l’avancement d’une mission,
• voir en un coup d’œil ce qui est en retard, ce qui arrive, et qui en est responsable.

3. Interface sobre

• calendrier, Kanban, listes, plutôt que 15 vues différentes ;
• peu d’options au départ, pour rester utilisable et apprendre des vrais usages avant d’ajouter des couches.

4. Stack technique moderne

• stack de type Next.js + Supabase + TypeScript (ou équivalent),
• attention portée à la structure du code pour pouvoir itérer sans tout casser.

Découvrir le produit : usemishka.com.

Ce que Mishka m’a appris (et ce que ça apporte à mes clients)

Au-delà du produit lui-même, Mishka m’a permis de :

Approfondir la vision produit

Passer du rôle de prestataire à celui de « propriétaire de produit » change la manière de penser la roadmap, les arbitrages, la dette technique.

Tester des patterns d’architecture en conditions réelles

Organisation du code, séparation front/back, gestion des permissions, conception de la base de données… tout ce qui sert ensuite sur des projets clients.

Éprouver une stack SaaS moderne

Voir ce que cela implique concrètement en termes de migrations, de performance, de coûts d’infrastructure.

Ces apprentissages, je les réutilise ensuite quand j’accompagne des fondateurs sur leurs propres produits.

Ce que Mishka révèle sur mon approche SaaS

Mishka illustre :

• ma préférence pour des produits simples mais solides, plutôt que pour des plateformes sur-complexes ;
• ma façon de partir de cas d’usage métiers concrets, pas d’une liste de fonctionnalités abstraites ;
• mon intérêt pour les équipes éditoriales et les outils métiers « intermédiaires » (ni purement grand public, ni uniquement internes).

Quand je travaille sur un SaaS client, j’applique la même logique : clarifier le problème, choisir un périmètre réaliste, construire un socle technique propre, itérer à partir des retours d’usage réels.

Construire votre SaaS sur cette expérience

Si vous souhaitez :

• créer un nouveau SaaS,
• reprendre un MVP fragile,
• ou transformer un outil interne en produit,

nous pouvons utiliser ce retour d’expérience comme base de discussion : ce qu’il faut garder, éviter, simplifier, industrialiser.