Marketing d’app pour développeurs qui détestent le marketing

Construire n’est plus le goulot d’étranglement. Avec Lovable, Bolt, Cursor, v0 ou Replit, l’app qui demandait un trimestre demande un week-end. Puis le travail change de nature : pas de compilateur, pas de tests, pas de stack trace, pas de prochain commit évident. Juste une URL que personne n’a vue et une consigne vague : « fais du marketing ».

Ce rejet ne vise presque jamais le marketing en soi. Il vise trois choses précises. Se mettre en scène — écrire dans une voix qui n’est pas la vôtre, en vidéo si possible. Se souvenir — publier tous les jours indéfiniment, avec la culpabilité du jour manqué. Deviner — ne jamais savoir si quoi que ce soit a servi, la partie que les développeurs trouvent réellement pénible.

Aucune de ces trois choses n’est du marketing. C’est un processus marketing sans système derrière. Donnez au même travail des entrées définies, un job planifié, une étape de relecture et des logs, et cela cesse d’être une performance. Vous n’êtes pas créateur de contenu. Vous exploitez un petit pipeline, et ça, vous savez déjà faire.

L’entrée, c’est votre site. Votre landing page énonce déjà l’offre, nomme l’audience et porte un ton. Amplispect lit l’URL du site et en construit un espace de travail : la voix devient une configuration enregistrée au lieu d’une improvisation à 23 h. Quand le produit change, vous modifiez le texte du site et l’entrée change avec lui. C’est tout le fichier de configuration.

La sortie, c’est une semaine de publications planifiées pour Instagram, Threads et X — chacune avec un rôle et une date déjà attribués, et non un tas d’idées sans calendrier. Le job, c’est le générateur : il tourne à la cadence que vous fixez et produit cette semaine sous forme de brouillons. C’est la partie qui remplace le problème de volonté quotidienne. Un job planifié n’a pas besoin d’être motivé le jeudi.

Les logs, c’est le reste. Chaque publication porte un statut par destination qui se lit comme la sortie d’un worker de file : en file, en cours, publié, échoué. Les commentaires arrivent en file, avec des réponses rédigées qui attendent votre relecture. La performance est la métrique qui règle la prochaine exécution — vous regardez ce qui a déclenché des réponses et des enregistrements, et la semaine générée suivante penche dans ce sens. Rien ne part sans votre validation, et c’est la seule étape manuelle qui mérite d’être conservée.

La cadence tourne et une semaine de brouillons apparaît. Vous l’ouvrez une seule fois — le lundi matin fonctionne bien, avant de toucher au code — et vous relisez le lot d’un bloc. Relire sept publications ensemble n’est pas la même tâche qu’écrire une publication sept fois : vous voyez les répétitions, repérez celle qui sonne comme un communiqué de presse et corrigez la séquence plutôt que la phrase. Vingt-cinq minutes suffisent en général.

Après validation, publier devient un job planifié et la vue des statuts devient votre log. Quand une destination échoue, elle échoue seule : la publication sur X ne dépend pas de la réussite de l’upload Instagram, et vous corrigez une destination au lieu de rejouer un lancement entier. C’est la différence entre un incident et un après-midi gâché.

Les commentaires reviennent dans le même espace de travail sous forme de file, avec des réponses rédigées. Vous éditez chacune avant l’envoi : cela prend quelques minutes et vous garde une voix humaine. Puis la vue performance ferme la boucle : quel rôle de publication a déclenché des réponses, quel format a été enregistré, quel jour n’a rien donné. Vous changez une entrée — davantage du rôle qui a marché — et la semaine générée suivante le reflète. C’est du réglage, pas de la devinette, et c’est ce qui rend l’ensemble supportable.