Startup studio IA — Co-fondation tech, MVP 8 semaines, levée seed

#Startup studio IA — co-fonder la tech plutôt que la sous-traiter

Un porteur de projet IA qui n'est pas développeur arrive presque toujours au même point de blocage. L'intuition marché est solide, nourrie par dix ou quinze ans dans un secteur vertical. Les premiers interlocuteurs sont identifiés, parfois prêts à signer une lettre d'intention. Et puis il faut construire le produit. Trois portes s'ouvrent : recruter un CTO, commander le développement à une agence, ou s'associer à un studio qui apporte la capacité technique contre une part du capital.

Cette page traite les trois options sans militer pour la nôtre. Un studio n'est pas une agence déguisée, et ce n'est pas non plus une solution universelle : dans une bonne partie des situations que nous voyons passer, le bon conseil consiste à recruter, à financer une prestation classique, ou à ne rien construire encore.

Suivent : ce qu'un studio apporte pendant les huit premières semaines, comment se pose l'arbitrage entre equity et cash, ce qu'un CTO à temps partagé peut porter, les signaux de product-market fit à surveiller, les choix d'architecture qui permettent de servir cent utilisateurs sans se condamner à dix mille, la différence entre dette technique assumée et subie, et ce que regarde un investisseur en due diligence technique. Pour notre périmètre global, l'entrée est l'offre Agence IA Nehos.

#Ce qu'est un startup studio, et ce qu'il n'est pas

Le modèle a une histoire lisible. Idealab, fondé par Bill Gross en 1996, en est l'ancêtre le plus documenté : une structure qui génère ses propres idées, les dote d'une équipe et les sort en sociétés distinctes. Le modèle a essaimé — Rocket Internet en Allemagne, Betaworks aux États-Unis, et en France Hexa (anciennement eFounders), qui a bâti sa réputation sur le SaaS B2B en associant des fondateurs métier à une capacité produit interne.

Le point commun de ces modèles n'est pas le financement, c'est l'apport d'exécution en échange de capital. Un studio ne vous vend pas des jours-homme ; il investit du travail dans une société dont il devient actionnaire, ce qui aligne son intérêt sur la valeur créée à moyen terme plutôt que sur le volume facturé à court terme.

Cette distinction sépare le studio de trois voisins souvent confondus.

L'incubateur et l'accélérateur fournissent un cadre : hébergement, mentorat, mise en réseau, dynamique de promotion, accès investisseurs, parfois un premier chèque. Ils ne construisent pas votre produit. Ils optimisent la trajectoire d'une équipe déjà constituée ; ils ne constituent pas l'équipe. Pour un fondateur métier sans co-fondateur développeur, le problème central reste entier : personne ne code.

Le fonds d'amorçage apporte du capital et un accompagnement stratégique. Le capital permet de recruter — encore faut-il savoir évaluer un profil technique quand on n'est pas soi-même technique, et accepter que le premier recrutement senior prenne plusieurs mois entre définition du poste, sourcing, entretiens et préavis.

Un studio se place exactement dans ce trou : il met une équipe technique en production avant que le tour de table n'existe, et il assume le risque de ne pas être payé en cash pour ça. Ce modèle n'a de sens que si le studio sait dire non souvent. Un studio qui accepte tous les projets qu'on lui présente est une agence qui se fait payer en actions — et c'est un mauvais marché pour le fondateur, qui dilue son capital pour un service qu'il aurait pu acheter.

#Recruter un CTO, prendre une agence ou s'associer à un studio

Il n'existe pas de réponse générale, seulement une réponse par situation. Elle dépend de quatre variables : votre trésorerie, votre capacité à évaluer un profil technique, l'horizon auquel vous devez montrer quelque chose, et la nature du risque principal du projet.

Critère	Recruter un CTO	Agence au forfait	Studio co-fondateur
Trésorerie nécessaire au démarrage	Élevée (salaire senior + charges, dès le mois 1)	Élevée mais bornée (forfait connu)	Faible à modérée selon le montage
Délai avant première ligne de code	2 à 5 mois (sourcing, entretiens, préavis)	3 à 6 semaines (cadrage, contractualisation)	2 à 4 semaines
Dilution du capital	Modérée (BSPCE, package d'association)	Nulle	Réelle et immédiate
Alignement sur la valeur long terme	Fort si le package est bien construit	Faible (le contrat s'arrête à la livraison)	Fort, mais à contractualiser
Capacité à absorber un pivot	Forte	Faible (le pivot est un avenant)	Forte
Risque principal	Erreur de casting peu réversible	Produit conforme au cahier des charges mais sans marché	Mésentente entre associés, cap table figée trop tôt

Recruter un CTO est le meilleur choix quand vous êtes financé et que vous savez évaluer. Rien ne remplace un associé technique à temps plein qui vit le produit tous les jours. La difficulté n'est pas le principe, c'est l'exécution : un fondateur non technique qui recrute son premier CTO n'a souvent aucun moyen de juger la qualité des réponses en entretien. Cette erreur de casting est l'une des plus coûteuses qui soient, parce qu'elle se découvre tard — au moment où il faut modifier le produit, pas au moment où il faut le construire — et parce qu'elle s'accompagne d'un capital déjà attribué.

L'agence au forfait est le meilleur choix quand le périmètre est stable et connu. Si vous savez précisément ce que le produit doit faire, si le besoin est validé par des clients qui attendent, si vous n'anticipez pas de pivot majeur, payer une prestation cadrée est plus rationnel que céder du capital. Nous faisons ce métier-là aussi et nous le recommandons quand c'est le bon outil : voir notre développement sur mesure et les plateformes SaaS.

La limite de l'agence n'est pas la qualité technique, c'est la structure de l'incitation. Un contrat au forfait rémunère la conformité au cahier des charges. Or au stade zéro, le cahier des charges est précisément l'hypothèse la plus fragile du projet : vous obtiendrez un produit fidèle à une spécification que personne, dans la boucle contractuelle, n'a intérêt à contester.

Le studio est le bon choix dans un cas précis : un fondateur avec une connaissance métier profonde d'un marché vertical, une trésorerie insuffisante pour porter à la fois le produit et sa propre subsistance pendant douze mois, et une incertitude produit qui exige de modifier le plan tous les quinze jours sans renégocier un contrat. L'alignement capitalistique fait alors un travail que ni le salaire ni le forfait ne font : il rend le studio directement pénalisé si le produit ne rencontre pas son marché.

#Le CTO à temps partagé : une quatrième voie, avec un périmètre à écrire

Entre le recrutement et la co-fondation existe une option intermédiaire souvent mal cadrée : le CTO à temps partagé, deux à trois jours par semaine, sur une durée déterminée. Bien utilisée, elle couvre quatre besoins : arbitrer les choix d'architecture structurants, recruter et évaluer les premiers développeurs, instaurer les pratiques d'ingénierie (revue de code, tests, intégration continue, environnements), servir d'interlocuteur crédible en due diligence.

Ce qu'un CTO à temps partagé ne peut pas porter, il faut le dire : la production quotidienne de fonctionnalités, l'astreinte, le management continu d'une équipe de plus de trois ou quatre personnes, la relation client au jour le jour. Un temps partagé qui glisse vers la production est mal cadré — le fondateur paie un tarif de direction technique pour du développement, et la direction technique n'est plus assurée.

La bonne pratique est d'écrire dès le départ la condition de sortie : à quel jalon le CTO à temps partagé est remplacé par un CTO interne, et qui recrute ce CTO interne. Un accompagnement qui se prolonge indéfiniment devient une dépendance, et cette dépendance se voit en due diligence.

#Le MVP en 8 semaines : ce que ça veut dire, ce que ça ne veut pas dire

Huit semaines n'est pas un argument commercial, c'est une contrainte de méthode : assez long pour construire quelque chose de vrai, assez court pour que l'hypothèse de départ n'ait pas le temps de se périmer. Au-delà de trois mois sans confrontation au marché, un MVP cesse d'être un instrument d'apprentissage pour devenir un pari. Le découpage que nous appliquons est stable d'un projet à l'autre, même si le contenu change.

Semaines 1 à 2 — cadrage et réduction. L'essentiel du travail consiste à retirer, pas à ajouter. On identifie l'hypothèse critique : la seule affirmation qui, si elle est fausse, rend le reste du produit sans objet. Tout ce qui ne sert pas à la tester sort du périmètre. Trois livrables : le parcours utilisateur minimal de bout en bout, la liste explicite de ce qui est reporté avec la raison de chaque report, et le protocole de mesure — quels événements sont instrumentés, quel seuil déclenche une décision.

Semaines 3 à 6 — construction. Incréments hebdomadaires, avec un environnement de recette accessible au fondateur en permanence. Il teste chaque semaine, pas à la fin. C'est là qu'un studio se distingue le plus nettement d'un forfait : ses retours modifient le plan de la semaine suivante, sans avenant ni négociation.

Semaines 7 à 8 — mise en marché. Production réelle, pas démonstration : nom de domaine, authentification, conditions d'utilisation, registre de traitement, journalisation, sauvegardes, supervision des erreurs. Premiers utilisateurs invités, avec entretiens individuels systématiques.

Ce qui n'entre jamais dans un MVP : les fonctions d'administration confortables, la personnalisation fine, les intégrations tierces non demandées par un utilisateur réel, l'internationalisation, l'optimisation de performance sur des volumes que vous n'avez pas.

Ce qui n'en sort jamais : l'authentification correcte, le chiffrement au repos et en transit, la conformité RGPD de base avec un registre des traitements tenu dès le premier jour, la traçabilité, l'instrumentation analytique. Ces éléments coûtent peu au démarrage et très cher à rattraper. Un MVP IA ajoute une exigence : la classification au regard de l'AI Act, à poser dès le cadrage, parce qu'elle détermine la documentation à produire et parfois la faisabilité même du cas d'usage — voir notre méthode AI Act et l'offre conformité.

Un mot sur le vocabulaire : le terme MVP est devenu un alibi pour livrer un produit médiocre. Ce n'est pas cela. Un MVP est restreint en périmètre et complet en qualité sur ce périmètre. Trois écrans qui fonctionnent parfaitement valent mieux que quinze écrans à moitié faits — surtout, ils produisent un signal exploitable là où quinze écrans bancals produisent du bruit.

#Equity, cash, ou les deux : comment se pose l'arbitrage

Nous ne publions pas de barème et nous ne donnons pas de conseil juridique ou financier : un montage d'association engage votre société pour des années et se construit avec votre avocat et votre expert-comptable. Ce que nous pouvons faire ici, c'est expliciter les principes qui rendent un arbitrage sain ou toxique.

Premier principe : l'equity rémunère un risque, pas un travail. Un studio payé intégralement en cash fournit une prestation et n'a aucune raison de prendre du capital. S'il en prend, c'est qu'il renonce à une part de facturation et accepte de perdre cette valeur si la société échoue. Un montage où le studio touche à la fois le plein tarif et une part significative du capital est déséquilibré. Inversement, un studio qui ne perçoit rien pendant douze mois porte un risque de trésorerie réel qui doit se refléter quelque part.

Deuxième principe : la part doit être proportionnée à la contribution et bornée dans le temps. La question utile n'est pas « combien de pourcents », c'est « en échange de quoi, sur quelle durée, et que se passe-t-il si l'un des deux s'arrête ». Un mécanisme d'acquisition progressive — le vesting, avec une période de carence initiale — est la convention de marché parce qu'il répond à cette question : les titres s'acquièrent au fil du temps travaillé, et un départ prématuré ne laisse pas un actionnaire inactif sur la table de capitalisation. Cela protège autant le fondateur que le studio.

Troisième principe : la table de capitalisation doit rester finançable. C'est le point que les fondateurs sous-estiment le plus. Un investisseur en amorçage refuse les configurations où les fondateurs opérationnels sont trop dilués avant même le premier tour, parce que la question devient : ces gens seront-ils encore motivés dans quatre ans, après deux tours supplémentaires ? Une part de studio confortable aujourd'hui peut rendre votre société non finançable demain.

Quatrième principe : la sortie doit être écrite avant l'entrée. Que se passe-t-il quand le studio a fini son travail ? Reste-t-il actionnaire passif ? Existe-t-il un mécanisme de rachat ? Comment le transfert de compétence vers l'équipe interne est-il organisé, et à quelle échéance ? Un montage sans clause de sortie fabrique un conflit à dix-huit mois.

En pratique, les configurations se répartissent sur un continuum. À une extrémité, un fondateur sans trésorerie ni financement : le montage penche vers l'apport en industrie contre capital, avec un engagement de durée réciproque. À l'autre, un fondateur déjà financé qui veut de la vitesse sans céder de contrôle : le montage penche vers une prestation majoritairement en cash, avec une participation résiduelle qui maintient l'alignement au-delà de la livraison. Le bon calibrage est celui dont les deux parties peuvent expliquer la logique à un investisseur sans se contredire.

Les instruments, eux, existent et sont documentés : bons de souscription de parts de créateur d'entreprise pour les équipes, obligations convertibles ou instruments à valorisation différée pour les apports d'amorçage, pactes d'associés pour la gouvernance et la liquidité. Le choix entre eux relève de votre conseil, pas du nôtre.

#Product-market fit : les signaux qu'on regarde avant d'accélérer

L'analyse post-mortem de startups publiée par CB Insights place invariablement l'absence de besoin marché en tête des causes d'échec, devant le manque de trésorerie. La donnée provient d'échecs auto-déclarés, donc à manier avec prudence, mais elle recoupe ce que voit quiconque a accompagné plusieurs produits : la cause de mort dominante n'est pas technique.

Le product-market fit est une notion popularisée par Marc Andreessen, qui le définissait en 2007 comme le fait d'être sur un bon marché avec un produit capable de le satisfaire — définition volontairement qualitative, parce que le PMF se ressent avant de se mesurer. Deux instruments permettent tout de même de l'objectiver.

Le test de Sean Ellis. On demande aux utilisateurs actifs : « Quelle serait votre réaction si vous ne pouviez plus utiliser ce produit ? ». La proportion de réponses « très déçu » sert d'indicateur, avec un seuil de référence de 40 % popularisé par Ellis et repris par Rahul Vohra chez Superhuman. Ce seuil est une heuristique, pas une loi : il suppose un échantillon d'utilisateurs réellement actifs, pas de simples inscrits. Sa vraie valeur est ailleurs — la question suivante, « qu'est-ce qui vous manquerait le plus ? », vous dit quoi construire ensuite.

La courbe de rétention. C'est le signal le moins manipulable. On trace, par cohorte de premier usage, la proportion d'utilisateurs encore actifs à J+7, J+30, J+90. Si la courbe descend jusqu'à zéro, il n'y a pas de PMF, quel que soit le volume d'acquisition. Si elle s'aplatit à un niveau non nul, il existe un segment pour lequel le produit est nécessaire — et le travail devient de l'identifier. Une courbe qui s'aplatit sur un petit nombre d'utilisateurs vaut mieux qu'une courbe qui décroît sur un grand nombre.

Nous ajoutons trois observations qualitatives qui précèdent souvent les chiffres : l'utilisateur revient-il sans qu'on le sollicite ; demande-t-il des fonctionnalités précises plutôt que de commenter l'interface ; parle-t-il du produit à un collègue. Le troisième signal est le plus prédictif et le moins instrumenté.

Un piège est spécifique aux produits IA. La démonstration impressionne presque toujours, parce qu'un modèle de langage produit un résultat plausible en quelques secondes. L'usage répété ne pardonne rien : dès que l'utilisateur doit vérifier chaque sortie, le gain de temps disparaît et l'outil est abandonné. Nous mesurons donc dès le MVP le taux de sorties acceptées sans correction et le temps réellement économisé sur la tâche, plutôt que le nombre de requêtes. Un produit IA qui fait beaucoup de requêtes et peu de tâches terminées est un produit sans PMF qui s'ignore. Ces principes structurent notre méthode ROI-First IA.

Avant d'accélérer — embaucher, investir en acquisition, lever — nous cherchons trois choses réunies : une courbe de rétention qui s'aplatit sur un segment identifiable, un coût d'acquisition dont on comprend le mécanisme même s'il est encore élevé, et un motif de récurrence explicable en une phrase. Le délai de récupération du coût d'acquisition et l'ARR viennent après, pas avant.

#Choix d'architecture : construire pour 100 utilisateurs sans se condamner à 10 000

La plupart des débats d'architecture en amorçage sont mal posés, parce qu'ils opposent une solution rapide à une solution scalable comme s'il fallait choisir un camp. La bonne formulation est autre : quelles décisions sont réversibles à faible coût, et lesquelles ne le sont pas ? On peut être expéditif sur les premières ; il faut être rigoureux sur les secondes.

Décisions difficilement réversibles. Le modèle de données et sa granularité. L'isolation des données entre clients dans un produit multi-tenant — cloisonnement par ligne, par schéma ou par base : la migrer plus tard signifie réécrire l'accès aux données et rejouer l'existant. La localisation de l'hébergement dès lors que vos clients sont dans un secteur régulé. Le modèle d'authentification et de permissions. La journalisation et l'audit, qui conditionnent votre capacité à répondre à une demande RGPD ou à un audit client.

Décisions largement réversibles. Le fournisseur de modèle de langage, à condition d'avoir isolé les appels derrière une couche d'abstraction dès le premier jour. Les tâches asynchrones. Les fournisseurs d'e-mail, de paiement, de stockage. Le découpage en services : un monolithe modulaire bien structuré se scinde le moment venu ; l'inverse est douloureux.

Notre position par défaut est explicite : monolithe modulaire d'abord. Les microservices résolvent un problème d'organisation — permettre à plusieurs équipes de déployer indépendamment — qu'une startup de trois personnes n'a pas. Elle en hérite en revanche tous les coûts : latence réseau, cohérence distribuée, observabilité éclatée, environnements de développement pénibles. Découper trop tôt est l'une des erreurs les plus coûteuses que nous voyons en reprise de code.

La stack que nous déployons par défaut reflète ces arbitrages. Next.js en TypeScript, parce que le rendu serveur couvre aussi bien l'application authentifiée que les pages publiques qui porteront votre acquisition organique. Payload CMS sur PostgreSQL pour le back-office, ce qui évite d'écrire une administration sur mesure à maintenir. Mistral comme modèle par défaut, derrière une couche d'abstraction qui rend le changement de fournisseur possible sans réécriture. Qdrant ou pgvector pour la recherche vectorielle quand une architecture RAG est nécessaire — pgvector suffit tant que le corpus reste modeste. Hébergement OVHcloud en France, avec la qualification SecNumCloud quand le secteur l'exige. Détail dans notre stack souveraine.

La souveraineté passe souvent pour une contrainte idéologique en amorçage. C'est en réalité un argument commercial dès que vous vendez à un hôpital, une banque, une collectivité ou un industriel : ces acheteurs posent la question de la localisation des données au premier rendez-vous, et une réponse floue coûte l'affaire. Construire dès le MVP sur une infrastructure européenne évite une migration au pire moment — celui où vous avez enfin un gros client.

Deux points spécifiques aux produits IA, enfin. L'évaluation : sans jeu de test de référence constitué dès le MVP, vous ne saurez pas si un changement de prompt ou de modèle améliore ou dégrade le produit — c'est la dette la plus insidieuse d'une startup IA. Et le coût unitaire par appel, à suivre dès le premier utilisateur, parce qu'un abonnement forfaitaire adossé à un coût variable non maîtrisé se retourne à l'échelle. L'observabilité LLM n'est pas un luxe de scale-up, c'est une instrumentation d'amorçage — voir nos offres Agents IA et Data & LLMOps.

#Dette technique assumée vs dette technique subie

La métaphore de la dette technique vient de Ward Cunningham, qui l'employait en 1992 pour expliquer à des non-techniciens pourquoi il est parfois rationnel de livrer un code imparfait : on emprunte du temps, on paie des intérêts sous forme de ralentissement futur, on rembourse en refactorisant. Martin Fowler a ensuite proposé un quadrant croisant deux axes : la dette est-elle délibérée ou par inadvertance, prudente ou imprudente.

Ce quadrant est l'outil le plus utile qu'un fondateur non technique puisse s'approprier : il transforme une question technique en question de gestion.

La dette délibérée et prudente est la bonne dette. On sait que l'on prend un raccourci, pourquoi, ce qu'il coûtera, et ce qu'il faudra faire pour le rembourser. Exemples typiques : traiter manuellement une étape qui sera automatisée quand le volume le justifiera ; ignorer les cas de bord d'un import tant que trois clients l'utilisent ; coder en dur une règle métier qui sera paramétrable plus tard. Ces choix accélèrent réellement et ne compromettent rien.

La dette par inadvertance est celle qui tue. Personne ne savait qu'il fallait faire autrement. Elle se manifeste toujours de la même façon : au moment de brancher le deuxième gros client, on découvre que l'architecture ne permet pas de faire ce qu'il demande sans réécriture. C'est le risque qu'un accompagnement technique senior réduit — non pas en évitant toute dette, mais en la déplaçant du quadrant « inadvertance » vers le quadrant « délibéré ».

La pratique que nous imposons tient en trois règles. Un registre de dette tenu dès la première semaine : chaque raccourci y figure avec sa raison, son coût de remboursement estimé et l'événement déclencheur (« au-delà de cinquante clients », « avant la première intégration ERP »). Une part de capacité réservée au remboursement à chaque itération, plutôt qu'un grand chantier annuel qui n'arrive jamais. Une liste de dettes interdites posée d'emblée : sécurité, données personnelles, sauvegardes et restauration, traçabilité. On n'emprunte jamais sur ces quatre postes, parce que les intérêts s'y paient en incident réglementaire ou en perte de données, pas en ralentissement.

Pour objectiver le sujet avec une équipe ou un investisseur, le glossaire de la dette technique et le calculateur de coût de dette technique donnent un cadre chiffrable. Sur un produit plus ancien repris en cours de route, l'approche par strangler fig et le refactoring progressif permettent de rembourser sans arrêter la production — c'est le cœur de notre offre de modernisation legacy.

#Préparer une levée seed : la due diligence technique vue de l'intérieur

Un fondateur prépare généralement sa levée par le récit et les chiffres, et découvre la due diligence technique quand elle arrive. Elle est plus courte et plus mécanique qu'on ne l'imagine, mais elle est éliminatoire sur quelques points précis.

• La propriété intellectuelle du code. Qui a écrit quoi, sous quel contrat, et la société détient-elle les droits ? Un prestataire sans clause de cession, un stagiaire sans convention, un associé parti sans formalisation : ce sont les blocages les plus fréquents, et ils se corrigent mal après coup.
• Les dépendances et licences. Un composant open source sous licence copyleft forte intégré au cœur du produit peut compromettre un modèle propriétaire. L'inventaire doit exister.
• La dépendance à un fournisseur unique. Pour une startup IA, la question tombe toujours : que se passe-t-il si votre fournisseur de modèle triple ses prix ou ferme votre accès ? Une couche d'abstraction et un modèle alternatif déjà testé constituent une réponse en trente secondes ; l'absence de réponse crée un doute qui se paie dans la valorisation.
• La conformité. Registre des traitements, base légale, sous-traitants et localisation des données, analyse d'impact quand le traitement le requiert, classification au regard de l'AI Act européen. Pour un produit vendu à la santé, à la banque ou au secteur public, ce chapitre conditionne l'accès au marché.
• L'état réel du produit. Environnements séparés, intégration continue, tests sur les parcours critiques, restauration testée, supervision des erreurs. Personne n'attend l'excellence à ce stade ; on attend que l'équipe sache décrire précisément où elle en est.
• La capacité à internaliser. Si toute la compétence technique est portée par un prestataire externe, l'investisseur voudra savoir quand elle passe en interne. C'est pourquoi un studio doit organiser sa propre sortie.

Préparer ce chapitre demande deux à trois semaines de travail réel, et il vaut mieux les passer avant le premier rendez-vous investisseur qu'après la lettre d'intention. Ce que nous fournissons : une salle de données technique tenue à jour, la documentation d'architecture, le registre de dette et son plan de remboursement, l'inventaire des dépendances, le dossier de conformité, et une préparation aux questions techniques — y compris celles auxquelles il faut répondre « nous ne l'avons pas encore fait, voici quand ».

Un mot sur l'honnêteté. Sur-vendre la maturité technique en levée est systématiquement perdant : les experts mandatés par les fonds détectent l'écart en une demi-journée d'entretien, et la confiance ne se reconstitue pas. « Notre couverture de tests est faible sur ces deux modules, c'est délibéré, voici le plan » inspire davantage confiance que « tout est prêt ». Sur les dispositifs de financement français, les ressources de Bpifrance sur la stratégie nationale IA sont un point de départ utile.

#Notre méthode studio, phase par phase

Nous appliquons une séquence en quatre temps, avec un point de sortie explicite à chaque étape : vous devez pouvoir vous arrêter sans pénalité si la suite ne se justifie pas.

#Phase 0 — Qualification mutuelle (1 à 2 semaines)

Deux ou trois rendez-vous, sans engagement. Nous cherchons à comprendre le marché visé, l'origine de votre conviction, ce qui vous rend légitime sur ce sujet, votre situation financière et l'hypothèse critique du projet. Vous cherchez à savoir avec qui vous vous associeriez : demandez à parler aux personnes qui travailleront réellement sur le produit, pas seulement au dirigeant. L'issue est une recommandation franche — construire, reformuler, ou ne pas construire maintenant. Le diagnostic de maturité IA sert de support à cet échange.

#Phase 1 — Cadrage et contractualisation (2 semaines)

Périmètre du MVP écrit et signé, protocole de mesure défini, architecture cible arbitrée, montage juridique finalisé avec vos conseils. C'est ici, et pas plus tard, que se règlent gouvernance, propriété intellectuelle, durée d'engagement et conditions de sortie.

#Phase 2 — Construction et mise en marché (8 semaines)

Le MVP décrit plus haut, livré en production. Jalon 30 jours : parcours principal fonctionnel de bout en bout en recette, instrumentation en place. Jalon 60 jours : produit en production, premiers utilisateurs réels, premiers entretiens qualitatifs. Chaque semaine, une démonstration et une décision.

#Phase 3 — Traction et préparation du tour (3 à 9 mois)

Itérations guidées par les signaux de rétention, structuration de l'acquisition, constitution du dossier de levée et de la salle de données technique. Jalon 90 jours : première lecture de la courbe de rétention sur cohortes réelles et arbitrage explicite — accélérer, corriger la proposition de valeur, ou changer de segment. C'est le moment où l'on pivote si l'on doit pivoter ; plus tard, c'est plus cher.

#Phase 4 — Internalisation et transfert

Recrutement et intégration de l'équipe technique interne, transfert documenté, réduction progressive de notre implication opérationnelle. L'objectif d'un studio est de devenir inutile au bon moment. Si nous restons indispensables à dix-huit mois, nous avons échoué. Nous pouvons ensuite continuer en TMA sur les briques stabilisées : c'est un rôle différent, et assumé comme tel.

#Pourquoi Nehos comme co-fondateur technique — et quand nous disons non

Ce que nous apportons tient en quatre points, sans effets de manche.

Une équipe qui livre en production, pas en démonstration. L'écart entre un prototype impressionnant et un produit que des utilisateurs non techniques emploient tous les jours est l'essentiel du travail. Authentification, permissions, gestion des erreurs, sauvegardes, supervision, support : c'est là que se joue la crédibilité d'une jeune société face à son premier client sérieux.

Une stack souveraine par défaut, sans dogmatisme. Next.js, Payload, PostgreSQL, Mistral, Qdrant, OVHcloud, avec SecNumCloud quand le secteur l'exige. Nous intégrons d'autres modèles quand le besoin le justifie, avec les accords de traitement adaptés — sujet traité dans notre offre souveraineté numérique.

Une culture du non. Un studio qui accepte tout dilue son attention et vend une association qui n'a pas de sens. Nous refusons les projets sur lesquels nous n'apportons pas de valeur différenciante, et nous le disons au premier rendez-vous, pas au troisième.

Un alignement contractualisé et une sortie écrite. Durée d'engagement, jalons, conditions de sortie et transfert de compétence figurent dans le contrat initial, parce que les associations qui se passent mal sont presque toujours celles dont on n'a pas écrit la fin.

Voici, en toute franchise, les cas où nous vous orientons ailleurs.

• Votre périmètre est stable et vous êtes financé. Prenez une prestation cadrée, gardez votre capital : c'est le cas le plus fréquent, et nous le faisons en développement sur mesure.
• Vous cherchez d'abord de l'argent. Un studio n'est pas un fonds. Si votre besoin principal est du capital, adressez-vous à des investisseurs.
• Le projet est un à-côté. La dynamique d'un studio suppose un fondateur à plein temps. Sans cela, le rythme hebdomadaire ne tient pas et l'association devient un contentieux.
• Il n'y a pas d'IA différenciante. Beaucoup d'excellents produits n'ont pas besoin d'IA. Un développement classique est alors plus rapide et moins cher — voir notre offre SaaS et le secteur SaaS & startup.
• Vous n'avez pas encore parlé à dix clients potentiels. C'est notre recommandation la plus fréquente et la moins commerciale : allez leur parler d'abord. Aucune ligne de code n'est plus rentable que dix entretiens sérieux.

Notre positionnement global figure sur la page Agence IA, et nos principes de tarification sur la page tarifs.

#FAQ — questions fréquentes sur le startup studio

Quelle différence concrète entre un startup studio et une agence de développement ? L'agence est rémunérée pour livrer un produit conforme à une spécification ; le studio l'est, en partie ou en totalité, par la valeur future de la société. La conséquence pratique se voit en cas de doute : une agence exécute la spécification, un studio vous dit qu'elle est probablement fausse et propose de la tester autrement. Si votre spécification est solide, l'agence est le meilleur choix — c'est moins cher et vous ne diluez pas.

Faut-il un co-fondateur technique pour lever en amorçage ? Ce n'est pas une obligation formelle, mais l'absence de compétence technique dans la société est systématiquement examinée, en particulier sur les produits IA. Ce qui compte n'est pas le titre : c'est la capacité de la société à faire évoluer son produit sans dépendre entièrement d'un tiers. Un accompagnement studio doit donc s'accompagner d'un plan d'internalisation daté.

Huit semaines, c'est réaliste pour un vrai produit ? Pour un périmètre correctement réduit, oui. Pour un produit complet avec toutes les fonctionnalités imaginées au départ, non — et c'est précisément le travail des deux premières semaines que de réduire le périmètre à l'hypothèse critique. Les projets qui débordent sont ceux où le fondateur refuse de couper. Les secteurs très régulés ajoutent du délai sur la conformité et la recette.

Le studio garde-t-il ses parts indéfiniment ? Cela dépend du montage, et c'est à écrire avant de commencer. Les configurations saines prévoient une acquisition progressive des titres, une durée d'engagement explicite et un mécanisme de sortie ou de réduction de participation. Une participation acquise d'un bloc au premier jour sans contrepartie de durée est un signal d'alerte, quel que soit le studio en face.

Que se passe-t-il si le produit ne trouve pas son marché ? C'est une issue possible et il faut la prévoir. L'intérêt du séquencement en phases est de la rendre peu coûteuse : arrêter au bout de trois mois avec un produit en production, des données d'usage et une conclusion claire vaut mieux que découvrir la même chose après dix-huit mois. Un studio aligné en capital perd aussi dans ce scénario, ce qui l'incite à poser honnêtement la question de l'arrêt.

Peut-on commencer par un CTO à temps partagé et décider ensuite ? Oui, et c'est souvent la voie la plus raisonnable quand la relation n'est pas établie. Quelques semaines de travail commun sur l'architecture et le cadrage en apprennent davantage sur une future association que n'importe quelle négociation. La condition est de fixer d'emblée une date de décision.

Qui est propriétaire du code ? La société. C'est non négociable et cela doit figurer noir sur blanc dans le contrat, avec cession explicite des droits patrimoniaux pour toute personne ayant contribué. Un studio qui conserve la propriété du code rend la société non finançable.

Travaillez-vous avec des porteurs hors de France ? Nous intervenons en France, en Belgique, en Suisse, au Luxembourg et en Andorre. Le montage juridique dépend du pays d'immatriculation et se construit avec vos conseils locaux ; nos pratiques d'ingénierie et notre exigence de conformité européenne ne changent pas. Point d'entrée : le formulaire de contact ou la page équipe.