Co-développement logiciel : bâtir en partenariat

Le co-développement, c'est bâtir un produit avec un partenaire technique qui partage le risque plutôt que de facturer des heures. Bien structuré, c'est le modèle le plus aligné qui existe. Mal structuré, c'est un divorce à retardement.

De quoi on parle exactement

Le terme couvre trois arrangements très différents, et la confusion coûte cher :

Le développement conjoint. Deux entreprises mettent chacune des équipes sur un produit commun, avec un partage de la propriété intellectuelle défini au contrat. Fréquent en industriel et en logiciel embarqué.
Le partenariat technique. Un client détient le marché, la connaissance métier et la clientèle ; un partenaire technique détient la capacité de construction. Chacun apporte ce qu'il a et partage le résultat, souvent en participation.
Le développement d'équipe étendue. Un fournisseur fournit des ingénieurs qui s'intègrent à votre équipe. C'est utile, mais ce n'est pas du co-développement : personne ne partage le risque, seulement le travail.

Quand quelqu'un vous propose du « co-développement », la première question à poser est : qui porte le risque si le produit ne se vend pas ? La réponse vous dit dans quelle catégorie vous êtes vraiment.

Pourquoi le modèle est plus aligné

Dans un mandat facturé à l'heure, l'intérêt du fournisseur est que le projet dure. Personne ne triche consciemment, mais l'incitatif pousse dans une direction : plus de fonctionnalités, plus de réunions, plus de temps.

En co-développement, l'incitatif s'inverse. Le partenaire gagne si le produit gagne. Il devient donc rationnel pour lui de dire « cette fonctionnalité ne servira à rien, ne la construisons pas », ce qu'un fournisseur à l'heure ne dira jamais spontanément.

C'est le seul modèle où la facture n'est pas la mesure de l'intérêt du partenaire.

Ce qui doit être écrit avant la première ligne de code

C'est ici que les partenariats se jouent. Six points, sans exception :

La propriété intellectuelle. Qui possède quoi, précisément ? Le code produit pour ce projet, les composants réutilisables du partenaire, les données générées par les utilisateurs. Ces trois catégories doivent être distinguées explicitement.
Les apports respectifs, chiffrés. Combien d'heures d'ingénierie, quel capital, quels actifs, quel accès au marché. Sans chiffres, le partage devient une négociation permanente.
Le partage du résultat. Participation au capital, redevance sur les revenus, ou combinaison. Avec un calendrier d'acquisition progressive : personne ne devrait détenir une part définitive après trois mois de travail.
Les décisions. Qui tranche sur les priorités produit, sur les choix techniques, sur le prix de vente. Une répartition à parts strictement égales sans mécanisme de déblocage est une paralysie programmée.
La sortie. Que se passe-t-il si l'un veut arrêter ? Si l'un ne livre pas ses apports ? Si une offre d'achat arrive ? La clause de sortie s'écrit quand tout le monde s'entend, jamais quand ça va mal.
Les jalons et les critères d'arrêt. Quel résultat, à quelle date, fait continuer ou arrêter. Décidé d'avance, ce seuil ne se déplace pas pour justifier de continuer.

Les pièges habituels

Le partenaire technique qui devient un fournisseur. Au bout de six mois, l'un des deux prend toutes les décisions et l'autre exécute. Le partage de résultat n'a plus de sens, et le ressentiment s'installe.
Les apports non techniques jamais mesurés. « J'apporte le réseau et les ventes » est un apport réel, mais s'il n'est jamais chiffré, il devient invérifiable et contesté.
La propriété intellectuelle enchevêtrée. Le partenaire réutilise ses propres composants. Sans licence claire, séparer les deux entreprises devient impossible.
Aucun financement pour la suite. Le produit marche, il faut du service client, de l'infrastructure, du marketing. Si personne n'a prévu qui paie cette phase, le succès crée la crise.

Comment on procède

Le co-développement est un de nos trois services, et le plus sélectif : quelques partenaires par année, pas plus. On met du capital et du code dans le produit, à parts définies, et on partage le risque, l'effort et le résultat.

Ce qu'on regarde avant de dire oui :

Il y a un marché réel devant le produit, pas seulement une bonne idée.
Vous apportez quelque chose qu'on n'a pas : la connaissance du métier, l'accès aux clients, la distribution.
Vous cherchez un partenaire technique, pas un fournisseur à facturer.
L'entente sur les parts peut être signée avant la première ligne de code — pas « on verra plus tard ».

Si ces quatre conditions ne sont pas réunies, notre service de développement sur mesure est probablement le bon choix, et on vous le dira franchement plutôt que de forcer un partenariat qui ne tiendrait pas.

Questions fréquentes

Qu'est-ce que le co-développement logiciel ?

C'est un arrangement où deux parties bâtissent un produit ensemble en partageant le risque et le résultat, plutôt qu'une relation client-fournisseur facturée à l'heure. Chacune apporte ce qu'elle a — capital, ingénierie, connaissance du marché, accès aux clients — et le partage est défini au contrat.

Quelle est la différence entre co-développement et sous-traitance ?

En sous-traitance, le fournisseur est payé pour son temps et ne porte aucun risque commercial. En co-développement, le partenaire est rémunéré par le succès du produit. La question qui tranche : qui perd de l'argent si le produit ne se vend pas ?

Qui détient la propriété intellectuelle en co-développement ?

Cela dépend entièrement du contrat, et c'est le point qu'il faut régler avant de commencer. Il faut distinguer explicitement trois catégories : le code écrit pour le projet, les composants préexistants réutilisés par le partenaire, et les données générées par les utilisateurs.

Comment répartir les parts dans un partenariat de co-développement ?

En chiffrant les apports de chacun — heures d'ingénierie, capital, actifs, accès au marché — et en prévoyant un calendrier d'acquisition progressive plutôt qu'une attribution définitive dès le départ. Il faut aussi un mécanisme de déblocage en cas de désaccord, sans quoi un partage strictement égal produit la paralysie.

Parlons de votre projet

Vous lancez un produit avec un vrai marché devant lui et vous cherchez un partenaire technique plutôt qu'un fournisseur ? Parlez-nous-en — on prend quelques partenaires par année.

Co-development means building a product with a technical partner who shares the risk instead of billing hours. Structured well, it is the most aligned model there is. Structured badly, it is a slow-motion divorce.

What we are actually talking about

The term covers three very different arrangements, and the confusion is expensive:

Joint development. Two companies each put teams on a shared product, with intellectual property split defined by contract. Common in industrial and embedded software.
Technical partnership. One side holds the market, the domain knowledge and the customers; a technical partner holds the ability to build. Each contributes what they have and shares the outcome, often in equity.
Extended team development. A vendor supplies engineers who embed in your team. Useful, but not co-development: nobody shares risk, only work.

When someone proposes "co-development", the first question to ask is: who carries the risk if the product does not sell? The answer tells you which category you are really in.

Why the model is more aligned

On an hourly engagement, the vendor's interest is that the project lasts. Nobody cheats consciously, but the incentive pushes one way: more features, more meetings, more time.

In co-development the incentive inverts. The partner wins if the product wins. It therefore becomes rational for them to say "this feature will not be used, let us not build it" — something an hourly vendor will never volunteer.

It is the only model where the invoice is not the measure of the partner's interest.

What must be written before the first line of code

This is where partnerships are decided. Six points, no exceptions:

Intellectual property. Who owns what, precisely? Code produced for this project, the partner's reusable components, data generated by users. Those three categories must be distinguished explicitly.
Each side's contribution, quantified. How many engineering hours, what capital, which assets, what market access. Without numbers, the split becomes a permanent negotiation.
How the outcome is shared. Equity, revenue share, or a combination. With a vesting schedule: nobody should hold a permanent stake after three months of work.
Decision rights. Who decides on product priorities, technical choices, pricing. A strict fifty-fifty split with no tie-break mechanism is scheduled paralysis.
The exit. What happens if one side wants out? If one side does not deliver its contribution? If an acquisition offer arrives? The exit clause is written while everyone agrees, never once things go badly.
Milestones and stopping criteria. What result, by what date, means continue or stop. Decided in advance, that threshold does not move to justify continuing.

The usual traps

The technical partner who becomes a vendor. Six months in, one side makes every decision and the other executes. The outcome share stops making sense, and resentment sets in.
Non-technical contributions never measured. "I bring the network and the sales" is a real contribution, but if it is never quantified it becomes unverifiable and contested.
Entangled intellectual property. The partner reuses their own components. Without a clear licence, separating the two companies becomes impossible.
No funding for what comes next. The product works, and now it needs customer support, infrastructure, marketing. If nobody planned who pays for that phase, success creates the crisis.

How we work

Co-development is one of our three services, and the most selective: a handful of partners per year, no more. We put capital and code into the product on defined terms, and we share the risk, the effort and the outcome.

What we look at before saying yes:

There is a real market in front of the product, not just a good idea.
You bring something we do not have: domain knowledge, customer access, distribution.
You want a technical partner, not a vendor to invoice.
The equity agreement can be signed before the first line of code — not "we will sort it out later".

If those four conditions are not met, our custom development service is probably the right choice, and we will say so plainly rather than force a partnership that would not hold.

Frequently asked questions

What is co-development in software?

An arrangement where two parties build a product together, sharing risk and outcome, rather than a client-vendor relationship billed by the hour. Each contributes what they have — capital, engineering, market knowledge, customer access — and the split is defined by contract.

What is the difference between co-development and outsourcing?

In outsourcing, the vendor is paid for time and carries no commercial risk. In co-development, the partner is compensated by the product's success. The deciding question: who loses money if the product does not sell?

Who owns the intellectual property in co-development?

Entirely dependent on the contract, and it is the point to settle before starting. Three categories must be distinguished explicitly: code written for the project, pre-existing components reused by the partner, and data generated by users.

How should equity be split in a co-development partnership?

By quantifying each side's contribution — engineering hours, capital, assets, market access — and using a vesting schedule rather than granting a permanent stake at the start. A tie-break mechanism is also needed, otherwise a strict fifty-fifty split produces paralysis.

Let's talk about your project

Launching a product with a real market in front of it and looking for a technical partner rather than a vendor? Tell us about it — we take a handful of partners per year.

Co-développement
logiciel.