Direction
Une direction qui voit
Le CEO suit l'avancement du produit et de la tech sans entrer dans le détail technique.
Tech · 15 à 20 personnes · 28 septembre 2026
Hush
Une équipe produit et tech qui livrait bien, mais que la direction ne pouvait pas suivre : produit et tech vivaient séparément, dans une base Notion unique que chacun lisait à sa façon. Avec quatre arrivées prévues, le système ne passait pas à l'échelle.
- 7 bases reliées, pilotables par rôle
- 4 arrivées absorbées sans friction
- 100% de l'entreprise sur le même socle
Chez Hush, la direction n'arrivait plus à voir ce que faisait la tech : produit et tech vivaient chacun de leur côté, et trois développeurs et un designer allaient arriver. Plutôt que d'acheter un outil de tickets de plus, l'entreprise a structuré Notion en profondeur, avec une IA qui rédige les tickets à partir des retours du service client. Les quatre arrivées se sont passées sans accroc, et le reste de l'entreprise a suivi.
L'entreprise
Hush édite une application mobile. Une quinzaine à une vingtaine de personnes, avec un noyau produit et tech au centre de l'activité : product management, développement, QA, design. Le genre d'entreprise où la vitesse de l'équipe technique fixe le rythme de croissance du produit.
Taille de l'équipe : 15 à 20 personnes
Secteur : Tech, application mobile
Localisation : France
01PourquoiUne direction qui ne voyait plus ce que faisait la tech
Le déclencheur
Le CEO avait du mal à voir ce qui se passait côté produit et côté tech. Impossible d'avoir une vraie vision d'ensemble dans Notion : le produit suivait ses sujets, la tech les siens, et rien ne reliait les deux. Au même moment, trois développeurs et un designer devaient rejoindre l'équipe. Ce qui tenait encore à effectif constant n'allait pas survivre à quatre personnes de plus.
Avant Rama Logic
- Produit et tech suivis séparément. Aucun lien entre une intention produit et le travail des développeurs. Suivre ce que faisait la tech demandait d'aller poser la question.
- Une seule base de données pour tout piloter. Pas de hiérarchie entre un objectif, un chantier et une tâche, donc aucune façon de répondre à « où en est ce sujet » autrement qu'à la main.
- Aucune compréhension partagée. Chacun s'était fait sa lecture de l'outil. Deux personnes devant le même écran n'en tiraient pas la même information.
- Un lien manuel entre les tickets et le code. Rattacher un ticket à sa merge request relevait de la discipline individuelle, donc ça se perdait.
- Rien pour les dirigeants. Aucune vue pour suivre l'avancement sans entrer dans le détail technique.
Avant : le produit suit ses sujets, la tech les siens, sans aucun lien. Une seule base Notion, que chacun lit à sa façon. Les tickets sont reliés aux merge requests à la main. La direction n'a aucune vue d'ensemble.
Après : un retour du service client devient un ticket rédigé par l'IA, rattaché à une Epic, une Story et des Tasks, jusqu'à la merge request GitHub dont le statut est synchronisé. La progression remonte automatiquement jusqu'à une vue dirigeants centrée sur les objectifs.
Pourquoi ne pas simplement acheter un outil de gestion de tickets ? Parce que l'objectif n'était pas d'équiper la tech, mais de mettre toute l'entreprise sur un même socle. Un outil dédié au développement aurait réglé le problème de l'équipe produit en créant une frontière de plus avec le reste de la boîte.
02QuoiUn vrai processus de sprint, relié du besoin client jusqu'au code
Deux missions successives, en octobre puis novembre 2025. La première sur le produit et la tech, la seconde pour étendre le socle à toute l'entreprise. Le travail a démarré par deux ateliers de co-construction avec l'équipe, pas par une livraison clé en main.
- 01 Octobre 2025 Deux ateliers de co-construction Le cycle de vie réel d'un ticket, tracé avec l'équipe, puis l'architecture cible décidée ensemble.
- 02 Le système produit et tech Sept bases reliées, tickets rédigés par l'IA, synchronisation avec GitHub, une vue par rôle.
- 03 Novembre 2025 Mission 2 : toute l'entreprise Réunions, stratégie, marketing et équipe commerciale passent sur le même socle.
- Puis Quatre arrivées absorbées Trois développeurs et un designer intégrés : chacun sait quoi faire dès le premier jour.
1. Décomposer avant de construire
L'atelier d'ouverture commence par une demande simple : montrez-nous votre Notion, et créez un ticket devant nous. Le reste de la session sert à tracer le cycle de vie réel d'un ticket, étape par étape, et à décider ensemble de l'architecture cible.
2. Sept bases reliées, une par niveau de pilotage
La base unique a été éclatée en un système hiérarchisé :
- Objectifs et KPI, pour rattacher le travail à une intention business.
- Epics, Stories et Tasks, reliées entre elles, avec une progression qui remonte automatiquement d'un niveau à l'autre.
- Sprints, avec capacité, charge planifiée et taux de complétion.
- Time tracking et Team, pour la charge et la disponibilité réelles.
La base Notion unique devient sept bases reliées : Objectifs et KPI, Epics, Stories, Tasks, Sprints, Time tracking et Team. La progression des Tasks remonte aux Stories, aux Epics et aux objectifs.
pilotage travail rythme et charge
3. L'IA rédige les tickets depuis le service client
Un retour utilisateur remonté par le service client devient un ticket rédigé et structuré par l'IA, prêt à être priorisé par le produit. Le besoin client entre dans le processus de sprint sans ressaisie ni perte en route.
4. Une vue par rôle, pas une vue pour tout le monde
Le même système, lu différemment selon qui regarde : vue product management sur l'avancement des chantiers, vue tech lead sur les blocages et les revues qui traînent, vue développeur limitée à ses propres tâches, vue sprint planning, et vue dirigeants centrée sur les objectifs, sans détail technique. Un nouvel arrivant sait quoi faire dès son premier jour.
Objectifs & KPIEpicsStoriesTasksSprintsTime trackingTeam
Direction Les objectifs et leur avancement, sans détail technique.
Objectifs & KPIEpicsStoriesTasksSprintsTime trackingTeam
Product management L'avancement des chantiers, chantier par chantier.
Objectifs & KPIEpicsStoriesTasksSprintsTime trackingTeam
Tech lead Les blocages et les revues qui traînent.
Objectifs & KPIEpicsStoriesTasksSprintsTime trackingTeam
Développeur Ses propres tâches, rien d'autre.
Objectifs & KPIEpicsStoriesTasksSprintsTime trackingTeam
Sprint planning Capacité, charge planifiée et taux de complétion du sprint.
5. Les tickets connectés au code
Synchronisation automatique entre les tâches Notion et GitHub : l'état d'un ticket suit le cycle de vie de sa merge request, sans ressaisie. C'est la partie qui supprime le plus de charge invisible au quotidien.
6. Puis toute l'entreprise
La deuxième mission a étendu le socle au-delà du produit : réunions, stratégie, marketing, équipe commerciale. Toute l'entreprise travaille dans le même environnement, ce qui supprime la traduction permanente entre ce que fait la tech et ce que suivent les autres pôles.
03RésultatsCe qu'on a gagné
Sprint
Des développeurs plus productifs
Un processus de sprint clair : chacun sait quoi faire, et sur quoi.
Adoption
Le recrutement absorbé, puis l'extension
Trois développeurs et un designer intégrés, puis toute l'entreprise, commercial compris. La deuxième mission est la meilleure preuve d'adoption.
Le produit et la tech ne sont plus deux mondes. Du retour client au code livré, tout se lit dans le même système.
Ce qui n'a pas pris
Le suivi du temps passé par statut a bien été mis en place, mais il est peu utilisé dans les faits. C'est un classique des équipes de développement : la fonctionnalité est techniquement là, l'usage ne suit pas. Elle reste disponible si l'équipe en a besoin un jour, elle ne conditionne rien du reste du système.
Et chez toi ?
On construit le même genre de système chez toi ?
30 minutes pour cadrer ton contexte, tes process et un premier cas d'usage concret.