Pour une start-up issue du campus de la Doua, un bon premier produit fait une seule chose pour un seul type d’utilisateur, sur un code et des comptes qui appartiennent à la société. Choisissez le no-code ou le code selon ce qui devra durer, posez un modèle de données simple et testez avec de vrais utilisateurs avant d’ajouter des fonctions. Décidez dès le départ de ce que vous jetterez ensuite.
Sur le campus LyonTech-la Doua, beaucoup de projets naissent d’un démonstrateur : un algorithme, un capteur, une méthode mise au point en laboratoire. Passer au produit est un autre métier : ce qui suffisait pour une soutenance doit maintenant servir des clients, tous les jours.
Le vrai risque n’est pas d’aller trop lentement. C’est de construire vite quelque chose dont on ne pourra plus sortir : un code que personne ne maîtrise, des comptes au nom d’un stagiaire parti, des données mal rangées. Voici la méthode que nous suivons pour l’éviter.
D’où partent les projets nés sur le campus ?
À Villeurbanne, le campus réunit notamment l’INSA Lyon et plusieurs composantes de l’université Claude Bernard Lyon 1, dont la faculté des sciences et technologies, l’IUT et Polytech Lyon. Pulsalys, l’incubateur et accélérateur deeptech de Lyon et Saint-Étienne, créé en décembre 2013 sous le statut de SATT, aide chercheurs et entrepreneurs à passer de la découverte à la start-up.
Ce contexte a des conséquences pratiques. Les fondateurs sont souvent des scientifiques, l’équipe technique change au rythme des stages et des thèses, et le premier code a été écrit pour démontrer, pas pour durer. Nous accompagnons ces projets depuis la région et venons sur place pour les ateliers : notre page Villeurbanne présente notre façon de travailler.
Que doit faire le premier produit, et rien d’autre ?
Écrivez une phrase : pour qui, quel problème, quel résultat. Par exemple : « l’ingénieur qualité charge ses mesures et reçoit un diagnostic lisible ». Tout ce qui ne sert pas cette phrase va dans une liste « plus tard », visible de toute l’équipe.
Mieux vaut un parcours complet, même modeste, que plusieurs écrans à moitié finis.
- Un seul type d’utilisateur au départ.
- Un parcours de bout en bout, de l’inscription au résultat.
- Une action à mesurer, celle qui prouve que le produit sert.
- Une liste « plus tard » écrite, pour dire non sans perdre les idées.
No-code ou code : sur quels critères trancher ?
Les outils sans code permettent de tester vite un parcours, un formulaire ou un tableau de bord interne. Ils montrent leurs limites quand le cœur du produit est un calcul propre au projet, quand les données sont sensibles ou quand il faut dialoguer avec un instrument ou un modèle maison.
La bonne question n’est pas « qu’est-ce qui va le plus vite ? » mais « qu’est-ce qui devra encore exister dans quelques années ? ». Ce qui doit durer mérite un code que vous maîtrisez. L’inscription, l’administration ou les e-mails automatiques peuvent rester sur des outils du marché, tant qu’on peut en exporter les données.
À qui appartiennent le code, les comptes et les données ?
Un logiciel est protégé par le droit d’auteur dès sa création, sans formalité. Quand un prestataire, un indépendant ou un stagiaire code pour la start-up, la cession de ses droits doit donc être écrite dans un contrat, en termes précis. Pour dater une version, l’INPI propose notamment le service e-Soleau.
Même logique pour les comptes. Nom de domaine, hébergement, dépôt de code, magasins d’applications, outils sans code, paiement : tout s’ouvre au nom de la société, avec au moins deux administrateurs. Si la technologie vient d’un laboratoire, clarifiez tôt avec la structure de valorisation ce que la start-up a le droit d’exploiter.
Comment poser un modèle de données qui ne bloquera pas la suite ?
Le modèle de données, c’est la façon dont le produit range ses informations : utilisateurs, organisations, mesures, résultats, factures. Il se modifie bien plus difficilement que les écrans. Dessinez-le à plusieurs, avec des noms clairs et un identifiant stable pour chaque objet.
Collectez le minimum de données personnelles et prévoyez dès le départ l’export et la suppression. Pour les tests, la CNIL demande de ne pas utiliser les données réelles de production et recommande un jeu de données fictives qui leur ressemble.
Comment tester avec de vrais utilisateurs sans se raconter d’histoires ?
Montrez le produit à des personnes qui ressemblent à vos futurs clients, pas à vos collègues de laboratoire. Donnez-leur une tâche, puis taisez-vous et regardez où elles hésitent. Une hésitation observée vaut plus qu’un compliment poli.
- Une tâche précise par séance, formulée comme dans la vraie vie.
- Des notes sur ce que la personne fait, pas sur ce qu’elle dit.
- Une seule modification entre deux séries de tests.
- Un accord écrit avant d’enregistrer l’écran ou la voix.
Que jeter, et que garder, après les premiers retours ?
Un premier produit réussi est en partie jetable. Les écrans d’administration bricolés, les scripts lancés à la main et les contournements prévus pour la démonstration peuvent disparaître sans regret. Inscrivez cette remise à plat dans le calendrier plutôt que de la subir.
Gardez ce qui a demandé de la réflexion : le modèle de données, les comptes, les tests automatiques et une documentation courte. Pour la suite, notre comparatif application mobile ou web app aide à choisir la forme du produit.
- Le premier produit sert un seul type d’utilisateur, sur un parcours complet.
- Le choix entre no-code et code dépend de ce qui devra durer.
- Code, comptes et données appartiennent à la société, contrats et accès à l’appui.
- Un modèle de données simple et des données de test fictives évitent bien des blocages.
- Des tests observés décident de la suite, et une partie du produit est faite pour être jetée.
Questions fréquentes
Faut-il un associé technique pour lancer le premier produit ?
Ce n’est pas obligatoire, mais quelqu’un doit comprendre les choix techniques et en répondre au nom de la société. Sans associé technique, un prestataire peut construire la première version, à condition que le code, les comptes et la documentation vous reviennent.
Quel budget prévoir pour une première version ?
Cela dépend du périmètre : un parcours simple sur des outils du marché ne demande pas le même travail qu’un produit qui embarque un calcul maison. Nous chiffrons le développement de l’application sur devis, après avoir écrit avec vous la phrase qui définit le produit.
Le premier produit a-t-il besoin d’une marque ?
Un nom provisoire suffit pour les tests, mais réservez tôt le domaine et les comptes. Le nom définitif, l’identité et le site viennent quand l’offre se précise : notre article sur le lancement d’une start-up à Savoie Technolac détaille ces étapes.
Nous écrivons avec vous le périmètre de la première version, puis nous la concevons et la développons sur des comptes à votre nom. Prenons un premier rendez-vous, en visio ou sur place.
- Lyon 1 Université Claude Bernard, Campus LyonTech-la Doua
- INSA Lyon, Plan d’accès
- Pulsalys, Qui sommes-nous ?
- INPI, Le droit d’auteur
- CNIL, Guide RGPD du développeur : tester vos applications
Pages consultées le 13 octobre 2026. Les marques citées appartiennent à leurs propriétaires.
