À Dijon, beaucoup de projets de startup qui nous arrivent n'ont pas un problème de site, ils ont une promesse encore instable. Ce qui suit décrit ce que vos premiers utilisateurs vérifient réellement, les obligations qui s'appliquent dès la première adresse email collectée, et ce qui fait qu'un même projet demande un effort très différent selon la façon dont il est cadré.
Ce que le visiteur vérifie avant de laisser son email
Un visiteur qui arrive sur le site d'une structure inconnue ne cherche pas à être séduit, il cherche à écarter un risque. Trois questions reviennent, en général dans cet ordre : est-ce que ce produit résout mon problème précis, est-ce qu'il existe vraiment ou seulement dans la tête de quelqu'un, et est-ce que la structure sera encore là quand j'en aurai besoin. Un titre qui reprend le vocabulaire technique du fondateur ne répond à aucune des trois. Un titre qui reprend la phrase exacte employée par la personne concernée pour décrire sa difficulté répond à la première. Le reste se joue avec des preuves : des captures réelles du produit plutôt qu'une illustration abstraite, un aperçu de ce qui se passe juste après l'inscription, un nom et un visage derrière le projet. En B2B, cette identification compte autant que la liste des fonctionnalités, parce que l'acheteur évalue une continuité de service en même temps qu'un produit. Enfin, une seule action doit rester possible par écran. Une page qui propose à la fois de s'inscrire, de télécharger un document et de suivre le projet sur trois réseaux ne mesure plus rien : les intentions se mélangent et aucun signal ne reste interprétable.
Landing, MVP, application : trois objets, trois critères de réussite
Confondre ces trois objets est l'erreur structurante de beaucoup de projets. Une landing de validation sert à tester une hypothèse formulée à l'avance : telle catégorie de personnes, confrontée à tel problème, accepte de donner son email contre telle promesse. Elle se juge sur un signal, pas sur son esthétique, et elle doit pouvoir être réécrite en profondeur sans toucher au code. Un MVP sert à observer un usage : dès qu'il y a des comptes, il y a des mots de passe oubliés, des données à conserver, des utilisateurs qui écrivent pour signaler un bug et une obligation implicite de continuité. Une application, elle, devient un objet à maintenir, avec des dépendances à mettre à jour et des régressions à surveiller. Passer directement à l'application parce que la promesse semble évidente revient presque toujours plus cher, non pas en développement, mais en temps perdu sur une piste que quelques échanges écrits avec de vrais utilisateurs auraient écartée. Le bon réflexe est de savoir, avant d'écrire la première ligne, quel signal ferait abandonner l'idée, et de le noter noir sur blanc pendant qu'on est encore capable d'être honnête avec soi-même.
Les erreurs qui reviennent sur presque tous les sites de jeunes structures
Elles se répètent d'un projet à l'autre. La première : décrire la technologie au lieu du problème, ce qui produit des pages compréhensibles uniquement par des gens qui connaissent déjà le sujet. La deuxième : collecter des emails sans avoir prévu ce qu'on en fait, alors qu'une liste d'attente restée silencieuse pendant des semaines vaut moins qu'une liste plus courte relancée par écrit dès les premiers jours. La troisième : ne rien instrumenter, donc être incapable de dire si l'échec vient de la promesse, du formulaire ou de la source de trafic. La quatrième : refondre le design en boucle alors que le texte, lui, n'a jamais été retravaillé. La cinquième : laisser une page d'attente en ligne saison après saison, ce qui envoie exactement le signal inverse de celui recherché. La sixième, plus discrète : confondre inscriptions et demande réelle. Des gens s'inscrivent par curiosité, par politesse ou parce que la promesse est assez floue pour que chacun y projette ce qu'il veut, ce qui fait monter un compteur sans rien valider. Le test utile consiste à demander autre chose que l'email, un usage décrit, une contrainte, une échéance, et à regarder qui répond encore.
Mentions légales, données collectées et propriété des accès
Une structure jeune n'échappe à aucune obligation d'éditeur. Le site doit porter des mentions légales identifiant la société et l'hébergeur. Dès qu'une adresse email est collectée, il s'agit de données personnelles : finalité annoncée, consentement recueilli sans case précochée, moyen simple de se désinscrire, et vigilance sur les outils branchés au formulaire, car il faut savoir où partent les données et sous quel encadrement. Les traceurs publicitaires supposent un consentement préalable ; la mesure d'audience n'en est dispensée que dans des conditions précises, à vérifier outil par outil plutôt qu'à supposer. Un produit vendu par abonnement ajoute des conditions générales, des règles de reconduction et un droit de rétractation dont les exceptions propres au numérique se regardent au cas par cas. Point souvent négligé : le nom de domaine, la zone DNS, le dépôt de code et les comptes de mesure s'enregistrent au nom de la société, jamais à celui d'un prestataire. Enfin, si votre produit touche à la santé ou à l'exercice d'une profession réglementée comme le droit, des règles déontologiques propres peuvent s'ajouter, notamment sur la présentation de l'activité et la sollicitation de clientèle : ces points se vérifient auprès de l'ordre concerné et d'un conseil compétent avant la mise en ligne, plutôt que par imitation d'un concurrent.
Ce qui fait varier l'effort, et comment le projet avance par écrit
L'effort dépend surtout de ce que le site doit faire, pas du nombre de pages. Une page unique dont le texte est déjà arbitré n'a rien à voir avec un produit qui suppose des comptes utilisateurs, des paiements, un espace d'administration, un modèle de données à concevoir et des connexions avec des outils existants. Le contenu pèse autant : textes, captures et éléments de marque prêts font gagner un temps considérable, tandis qu'une promesse encore mouvante rend chaque itération plus lourde. Une reprise depuis un outil sans code, un besoin multilingue ou un plan de mesure détaillé comptent également dans le devis. Tout se décide par écrit. Vous décrivez le projet, nous répondons sous 24 heures ouvrées avec les questions manquantes, puis avec une proposition. Les échanges suivants se font sur une adresse de préproduction, avec des retours numérotés auxquels nous répondons ligne par ligne. Aucun déplacement n'est nécessaire, ni du vôtre ni du nôtre. Robin Monteiro développe (Next.js, React), Florian Loppion cadre l'acquisition, et tout part du 9 rue Jean-Jacques Rousseau à Dijon. Des projets comme Vectosolve, Mediavocats ou LB Athletic ont avancé de cette façon, sans autre canal que l'écrit.
