Publier du contenu en équipe : pourquoi on a construit notre propre outil

Le problème : on publiait beaucoup, chacun dans son coin

On a passé deux ans à publier presque tous les jours. Et pourtant, personne chez Figue n'était capable de répondre à une question simple : qui a publié cette semaine ?

Chez Figue, on construit en public. C'est un choix assumé, pas une posture marketing. La newsletter dépasse les 1 000 abonnés. Le podcast rassemble environ 500 abonnés sur YouTube, et un public équivalent sur les réseaux. On publie sur LinkedIn, sur YouTube, sur X. Chaque fondateur a son compte, son ton, son rythme.

Le contenu est notre premier canal d'acquisition. Mais dès qu'on est plusieurs à l'alimenter, il devient invisible pour l'équipe elle-même. Personne ne voit l'effort collectif. Personne ne voit le trou quand quelqu'un décroche pendant trois semaines. Groowth est né de cette frustration, exactement comme nos autres produits : un besoin qu'on vivait nous-mêmes, tous les jours.

Ce qui casse dès qu'on est plus d'un à publier

Publier seul, c'est un problème de discipline. Publier à cinq, c'est un problème d'organisation. Les deux n'ont rien à voir, et la plupart des outils du marché ne traitent que le premier. Voici les trois fuites qu'on a identifiées chez nous, en regardant honnêtement pourquoi nos mois de contenu étaient si irréguliers.

Ces trois fuites ont un point commun : aucune ne se règle avec plus de discipline. Elles se règlent avec de la visibilité. C'est ce constat qui a défini le périmètre du produit.

Ce qu'on a construit : un seul tableau pour tous les comptes

Groowth part d'une idée volontairement simple : brancher tous les comptes de l'équipe au même endroit, et compter.

Chaque personne connecte ses comptes TikTok, Instagram, YouTube et LinkedIn. L'outil récupère les publications et l'audience, puis les remet dans une vue globale : combien de posts cette semaine, quelle audience cumulée, qui est à jour, qui a décroché. Personne n'installe d'extension, personne ne remplit de tableur, personne ne déclare quoi que ce soit. Si l'équipe doit saisir des données à la main, l'outil est mort avant d'avoir servi.

Le produit est accessible sur groowth.io, avec trois comptes gratuits à vie. C'est assez pour qu'une petite équipe teste la mécanique pendant un mois avant de payer quoi que ce soit. On a gardé cette limite haute exprès : si la mécanique ne tient pas sur un mois complet, elle ne tiendra pas non plus après un paiement.

La vraie mécanique : une course, pas un tableau de bord

Un tableau de bord, on le regarde une fois, puis on l'oublie. On en a construit assez pour le savoir. Ce qui nous a fait tenir en interne, c'est le côté jeu, et c'est la seule partie du produit qui n'était pas évidente à concevoir.

Trois briques. Une ligne par personne, pour que l'effort de chacun soit lisible sans classement humiliant. Une série à ne pas casser, parce que personne n'aime être celui qui casse une série de 21 jours devant toute l'équipe. Une cible commune, pour que le collectif prime sur la performance individuelle et que le meilleur du mois n'ait aucun intérêt à garder ses méthodes pour lui.

“La régularité ne vient pas de la discipline. Elle vient du fait que quelqu'un remarque le jour où tu t'arrêtes.”

Ces règles ne sortent pas d'un atelier de design. Elles sortent de six mois d'usage interne, pendant lesquels on a retiré tout ce que l'équipe n'ouvrait pas. Le produit qui reste est plus petit que celui qu'on avait imaginé au départ, et il est utilisé tous les jours.

Pour qui c'est fait

On a construit Groowth pour nous. En le montrant autour de nous, trois profils sont remontés avec exactement le même problème, pour des raisons différentes.

Le cas des agences nous a surpris. On pensait viser des équipes internes, et on a vu arriver des agences marketing qui gèrent les comptes de plusieurs clients et passent une journée par mois à reconstruire des rapports. Le besoin est le même, l'échelle est différente.

Le pattern : un outil interne qui finit produit

Groowth n'est pas notre premier outil né d'un besoin interne. ReactIn a suivi exactement le même chemin : un problème qu'on vivait, un outil bricolé pour nous, puis des gens autour de nous qui demandent l'accès. La différence entre un outil interne et un produit, ce n'est pas la qualité du code, c'est le moment où quelqu'un d'extérieur insiste pour l'utiliser.

L'avantage de ce chemin est simple : on ne peut pas se mentir sur la qualité. On est le premier utilisateur, tous les jours, et chaque friction qu'on laisse passer, on la subit le lendemain. Ça rend le cadrage beaucoup plus honnête qu'un backlog rempli d'hypothèses.

Son inconvénient est réel aussi : un outil taillé pour une équipe de trois fondateurs qui publient beaucoup n'est pas automatiquement adapté à une agence de quinze personnes. C'est le travail en cours, et il se fait avec les premiers utilisateurs, pas contre eux.

Pour aller plus loin, on a détaillé comment on construit un plan go-to-market SaaS, ce que contient notre stack d'outils au quotidien, et où placer la frontière entre un MVP et une V1.