Alara

Alara était un SaaS de planification de contenu LinkedIn : piliers éditoriaux, créneaux de publication récurrents, planning visuel, publication automatique via l'API LinkedIn. Construit à deux avec une ancienne collègue, sur environ un an, jusqu'à un passage devant la French Tech et une vingtaine de betatesteurs conquis. Le produit fonctionnait et plaisait. Il a quand même été arrêté, par application d'une kill rule chiffrée : cette page en documente le parcours complet, le même contrat de transparence que sur /traction.

Le problème : tenir une stratégie de contenu LinkedIn dans la durée

Publier régulièrement sur LinkedIn est l'un des leviers de visibilité les plus accessibles pour un indépendant ou un développeur, et c'est pourtant ce que presque personne ne tient dans la durée. Pas par manque d'idées, par manque de système : on publie trois semaines, on en rate une, on abandonne. L'idée d'Alara est née à la fin d'un stage de six mois en conseil informatique, entre la montée de l'IA générative et le constat, en observant les réseaux, du rôle déjà central de la stratégie de contenu dans le personal branding. Une collègue était arrivée aux mêmes conclusions de son côté, avec son propre prototype ; plutôt que de dupliquer l'effort, on a construit ensemble.

Le marché n'était pas vide : Taplio s'était imposé comme le spécialiste LinkedIn, Hootsuite et Buffer couvraient le généraliste multi-réseaux. Le pari a été de se concentrer sur LinkedIn plutôt que de s'éparpiller.

La solution : un SaaS de planification LinkedIn, construit à deux

Alara n'automatisait pas la publication, il installait la discipline éditoriale qui manque : des piliers de contenu définis une fois, des créneaux récurrents plutôt qu'une bonne résolution, un planning qui rend la régularité visible et donc tenable. Le modèle de revenu visé était un freemium classique : plan gratuit limité en volume de posts, abonnement à quelques dizaines d'euros par mois pour débloquer le reste.

La chronologie a été dense. Développement démarré en juillet, première beta dès octobre, site vitrine en décembre, mise en production en janvier, campagnes de beta à partir de février, décision d'arrêter en octobre suivant. Douze mois qui n'ont rien eu de linéaire : persona, pricing, design et fonctionnalités clés ont été revus plusieurs fois, au fil des retours, jusqu'à un rendez-vous avec la French Tech, un signal qui a compté sans jamais remplacer un vrai canal d'acquisition.

Les fonctionnalités

• Les piliers de contenu : les 2-3 thèmes qu'on veut incarner, définis une fois, qui cadrent tout le reste.
• Le planning hebdomadaire/mensuel, avec l'aperçu visuel de chaque post et une barre de progression sur la page d'accueil, pour rendre la discipline éditoriale visible.
• Un onboarding stratégique, qui structure les piliers et les fréquences de publication avant la première publication.
• La publication automatique vers LinkedIn, un batch qui tourne toutes les cinq minutes pour envoyer les posts programmés via l'API.

Ce que ça a donné

Une vingtaine de betatesteurs sont passés par l'outil, trouvés via l'entourage, LinkedIn, et surtout un post Facebook dans un groupe d'auto-entrepreneurs qui a généré plus de cent réponses pour une vingtaine de places, au point qu'il a fallu s'organiser dans l'urgence pour trier les accès. Les retours étaient bons : solution jugée très complète, plusieurs testeurs réellement enthousiastes, le sentiment de répondre à un vrai besoin. Le problème n'était pas l'usage. Le problème, c'est que ces mêmes personnes ne passaient pas à l'achat.

Sous le capot : la stack Next.js, Prisma et Postgres

Techniquement, Alara était un monolithe fullstack TypeScript : Next.js (App Router) pour le front et les API routes, Prisma comme ORM, Postgres en base, déployé sur Vercel. Autour de ce cœur, NextAuth pour l'authentification, Stripe pour les paiements et la gestion des abonnements, Brevo pour les emails transactionnels, shadcn/ui pour l'interface. Un choix assumé de simplicité : pour un produit à deux en phase de validation, séparer front et back aurait ajouté de la surface de maintenance sans rien apporter.

┌──────────────────────────────────────────────────────┐
│                       Next.js                        │
│  ┌──────────────┐   ┌───────────────────────────────┐│
│  │  App Router  │   │         API routes            ││
│  │  (UI, RSC)   │──▶│ auth (NextAuth) · posts        ││
│  └──────────────┘   │ abonnements (Stripe) · emails  ││
│                      │ (Brevo) · publication LinkedIn ││
│                      └───────────────┬────────────────┘│
│                                      │ Prisma          │
└──────────────────────────────────────┼──────────────────┘
                                       ▼
                                 ┌──────────┐
                                 │ Postgres │
                                 └──────────┘
                                       ▲
                         ┌─────────────┴─────────────┐
                         │  batch cron (5 min)        │
                         │  → publication LinkedIn API │
                         └─────────────────────────────┘

Le modèle de données tournait autour de deux entités centrales, l'utilisateur et le post, avec autour un cortège d'entités connexes : les médias attachés à un post, le compte LinkedIn lié, les données de performance récupérées après publication, et l'abonnement. La logique de planning, faire se rencontrer des créneaux de publication récurrents et des posts concrets dans un calendrier visuel, n'existait dans aucun outil natif de LinkedIn : c'est le morceau qui a demandé le plus d'itérations. La version retenue affichait un planning hebdomadaire ou mensuel avec l'aperçu visuel de chaque post, complété sur la page d'accueil par une barre de progression hebdomadaire qui rendait la discipline éditoriale visible, et donc tenable. Un onboarding structurait en amont toute la stratégie de contenu avant la première publication. Côté exécution, un batch tournait toutes les cinq minutes pour envoyer les posts programmés vers l'API LinkedIn.

Le morceau le plus difficile à construire n'a pas été le planning, c'est la logique d'abonnement : chaque état (essai, actif, expiré, changement de plan, échec de paiement) ouvrait des scénarios à couvrir pour garder un parcours fluide, avec des workflows de test qui grossissaient vite. L'API LinkedIn, elle, était intégrée dès l'inscription, mais restrictive : publication sur profil personnel uniquement, pas de posts d'organisation, et aucune donnée de performance renvoyée. Une extension Chrome a été développée en cours de route pour récupérer et réafficher aux utilisateurs les statistiques de leurs propres posts.

Les stratégies mises en place

Trois paris avaient été posés, avec la lucidité, a posteriori, qu'aucun ne constituait un vrai canal de distribution validé :

• La spécialisation LinkedIn. Plutôt que de concurrencer Hootsuite ou Buffer sur leur terrain généraliste, concentrer tout l'effort produit sur un seul réseau. Un positionnement clair, qui a rendu le produit plus complet sur son créneau, mais qui n'a jamais réglé la question de savoir comment atteindre les gens qui en avaient besoin.
• La beta communautaire. Le post Facebook dans un groupe d'auto-entrepreneurs a généré plus de cent réponses pour une vingtaine de places, une preuve d'intérêt indéniable. Mais un pic d'intérêt organique dans un groupe n'est pas un canal d'acquisition reproductible : impossible d'en tirer un coût d'acquisition, ni de savoir si ça se répéterait une deuxième fois.
• Le freemium. Un plan gratuit limité pour réduire la friction d'entrée, un abonnement à quelques dizaines d'euros par mois pour monétiser. Sauf qu'un tunnel freemium sans flux d'acquisition payant en haut du tunnel ne convertit que les gens déjà là, jamais les suivants.

Le point commun de ces trois paris : ils supposaient tous que le trafic finirait par arriver de lui-même.

Les chiffres, en clair

La transparence vaut aussi pour les projets arrêtés. Voici le bilan d'Alara :

Métrique	Valeur
Durée de développement	~12 mois (2024 – 2025)
Betatesteurs	une vingtaine (entourage, LinkedIn, un post Facebook à 100+ réponses)
Clients payants	0
Revenus	0 €
Coût réel (hors temps)	~130 € (nom de domaine ~10 €/an + Vercel ~20 €/mois pendant 6 mois)
Canal d'acquisition validé	aucun
Verdict	arrêté (kill rule appliquée)

Un an très intensif à deux, un produit que les testeurs jugeaient complet, et zéro revenu : c'est le coût réel de construire dans le mauvais ordre.

Ce qui a marché

La preuve produit est faite : un SaaS complet, livré à deux en un an, avec une logique de planning inédite sur LinkedIn (aucun outil natif n'affiche un calendrier visuel de posts), une gestion d'abonnement bout en bout, et l'API LinkedIn intégrée jusqu'à la publication automatique. Les retours des betatesteurs le confirment : le produit répondait à un vrai besoin, jugé complet par des gens qui n'avaient aucune raison de faire semblant.

Ce qui a raté

La distribution. Aucun canal d'acquisition validé, un tunnel freemium sans rien en haut pour l'alimenter, et une friction d'inscription auto-infligée : demander dès l'inscription l'autorisation de publier sur LinkedIn, avant même d'avoir gagné la confiance des utilisateurs, a coûté plus de conversions que ça n'en a rapporté.

Pourquoi j'ai arrêté Alara

Le produit était construit, et globalement validé par ceux qui l'ont testé. Continuer aurait été du développement de confort : améliorer un produit que presque personne ne découvrait, parce qu'écrire du code est plus agréable que d'affronter le problème d'acquisition.

La kill rule est tombée : un produit sans canal de distribution validé ne mérite pas un mois de développement supplémentaire. Arrêter un produit fonctionnel et plutôt bien reçu, dans lequel on a mis un an à deux, est contre-intuitif, c'est exactement pour ça qu'il faut une règle écrite à l'avance, et pas une décision au ressenti.

Les leçons (transférables)

1. On part du canal, et on remonte vers le produit, jamais l'inverse. Le site de référencement de restaurants m'avait prouvé que je savais créer du trafic (sans savoir le monétiser). Alara m'a prouvé qu'un bon produit, validé par ses utilisateurs, ne vaut rien sans canal pour les atteindre.
2. Ne jamais imposer la friction la plus lourde avant d'avoir gagné la confiance. Demander l'autorisation de publier sur le compte LinkedIn de quelqu'un dès l'inscription a cassé plus de conversions que ça n'en a fait gagner.
3. Poser des patterns solides avant la première fonctionnalité, ne jamais dupliquer de code, entrer par le besoin métier plutôt que par la technique.

La suite

L'app Calcul Salaire Brut Net applique la synthèse de ces leçons : une verticale choisie pour sa demande de recherche existante, un produit réellement utile, et la distribution (l'ASO sur le Play Store) pensée comme le vrai chantier, pas le code. Le domaine alarapp.com reste actif, avec la landing page et un outil gratuit encore en ligne ; l'application elle-même ne fonctionne plus, mais le lien reste.