Contrat de développement logiciel : ce qu’un fondateur non technique achète vraiment quand il signe

La première fois qu’une fondatrice avec laquelle nous travaillons nous a montré le contrat rédigé par son avocate, le document faisait trente-huit pages. Il s’ouvrait sur douze pages de définitions, traversait des clauses d’indemnisation copiées d’un accord de licence SaaS de 2012 et finissait sur un for arbitral au Delaware. Elle n’avait aucun ingénieur dans son équipe. Elle achetait une build sur mesure de six mois à un studio de quatre personnes à São Paulo. Son avocate lui avait dit que le document était “standard”. Quand nous lui avons demandé ce qui se passerait si le studio ratait un milestone, elle a dû feuilleter trois sections pour trouver la réponse, et la réponse était fausse.

Ce contrat est l’artefact le plus fréquent que nous voyons dans les deals de logiciel sur mesure early-stage. Il a l’air responsable. Il ne l’est pas. Un contrat de développement logiciel pour un fondateur non technique qui achète la première version d’un produit à un petit studio n’est pas un document de quarante pages. C’est un document de quatre à six pages qui fait cinq choses bien. Le reste, c’est du théâtre.

Voici le guide, côté fondateur, de ce que sont ces cinq choses, des trois pièges qui se cachent dans les templates standard, des cinq questions à poser avant de signer, et des trois cas étroits où la version de quarante pages est bien le bon instrument.

Ce qu’est vraiment un contrat de développement logiciel

Un contrat de développement logiciel est un accord écrit entre un client et un développeur ou un studio de développement qui définit ce qui va être construit, comment ce sera payé, qui en est propriétaire et ce qui se passe quand quelque chose tourne mal. Ce n’est pas un brief, pas un statement of work isolé, et pas un NDA, même s’il y fait normalement référence aux trois.

Pour un fondateur non technique qui achète du logiciel sur mesure, le contrat est le document qui survit à la conversation. Toute promesse faite en Zoom, tout message Slack qui dit “on peut probablement ajouter ça”, toute proposition de “on verra ça plus tard” vit en dehors du contrat. Le contrat, c’est ce qui reste quand quelqu’un est mécontent. C’est là qu’il doit être bon.

Les templates standard disponibles en ligne n’ont pas été écrits pour un fondateur dans cette situation. Remarquer pour qui ils ont été écrits est le premier mouvement qui te protège.

Pourquoi les templates standard échouent avec les fondateurs non techniques

La plupart des templates viennent d’un de deux mondes. Le premier, c’est l’achat corporate (PandaDoc, ktslaw, les filings de la SEC, les guides de cabinets juridiques). Ces templates supposent que l’acheteur est un département IT d’une Fortune 500 avec son propre service juridique et que le vendeur est un fournisseur avec une équipe commerciale. Les clauses sont longues parce que les montants sont importants. La plupart sont inadaptées à une build de six mois avec un petit studio. Elles rendent le document hostile, allongent la négociation de plusieurs semaines, et signalent que tu ne comprends pas le travail que tu t’apprêtes à acheter.

Le second, c’est le côté freelance : boilerplate Justia, contrats markdown sur GitHub, générateurs de templates gratuits. Trop minces. Ils supposent que le travail est un logo d’un mois, laissent la cession d’IP ambiguë, ne traitent pas la recette, et n’ont aucun mécanisme prévu pour ce qui se passe si la build dépasse.

Il n’existe pas de troisième monde de templates écrits pour le fondateur d’une entreprise early-stage qui achète une build sur mesure de six mois à un studio de quatre à huit personnes. Du coup, le fondateur paie cinq mille dollars à un avocat pour adapter le template corporate, signe la version mince et croise les doigts, ou signe la version du studio parce que ce sont eux qui l’ont proposée.

La solution n’est pas un meilleur template. La solution, c’est de connaître les cinq clauses qui fonctionnent vraiment dans n’importe quelle version du document, et d’exiger que ces cinq-là soient justes.

Les cinq clauses qui décident si tu vas pouvoir dormir tranquille

C’est le cœur du document. Le reste est de la finition. Si ces cinq clauses sont correctes, le contrat fonctionne. Si l’une d’elles est mauvaise, aucune autre clause ne te sauve.

Référence au périmètre, pas le périmètre complet

Les mauvais contrats mettent le périmètre complet du projet dans le corps du contrat, figé au moment de la signature. C’est l’erreur la plus chère du document. À la troisième semaine de n’importe quelle build sur mesure, le périmètre a changé : une session de discovery a fait remonter quelque chose, un entretien client a décalé les priorités, une contrainte technique a imposé un workaround. Maintenant ton contrat ne correspond plus à ce qui est en train d’être construit, et chaque changement exige un avenant.

Un contrat taillé pour un fondateur traite le contrat et le périmètre comme deux documents. Le contrat nomme la référence au périmètre : “Le Développeur livrera le travail décrit dans le Périmètre de Travail joint en Exhibit A, lequel pourra être révisé par accord écrit des deux parties sans avenant au présent Contrat”. Le périmètre vit comme document distinct, peut être révisé par écrit au fil du travail, et est gouverné par le contrat au-dessus de lui. Le périmètre change ; la gouvernance, non.

Paiement lié à la recette, pas au calendrier

La plupart des templates partent par défaut sur l’une de deux structures : prix forfaitaire payé en mensualités égales, ou régie facturée à la semaine sans cap. Les deux échouent de manière prévisible. Le prix forfaitaire avec paiements calendaires récompense le studio pour avoir envoyé des factures dans les temps, pas pour avoir livré un logiciel qui marche. Au quatrième mois, tu as payé 67 % du projet pour 30 % du produit fonctionnel. La régie sans cap supprime toute prévisibilité de coût, et nous avons vu des fondateurs sortir d’une build à trois fois le devis initial parce qu’aucune clause n’a jamais forcé le studio à s’arrêter et à expliquer pourquoi.

La structure que nous recommandons pour quasiment toute build sur mesure early-stage est détaillée dans notre comparatif forfait vs régie pour le logiciel sur mesure : régie facturée à la semaine avec un cap par sprint et des milestone gates qui débloquent le budget du sprint suivant. Le contrat impose ça en attachant chaque paiement à un événement de recette, pas à une date. Cap Sprint Un, débloqué à la recette du livrable Sprint Un selon les critères de l’Exhibit A. Cap Sprint Deux, débloqué à la recette du Sprint Deux. Et ainsi de suite.

L’événement de recette est la pièce qui porte tout. Le contrat doit définir ce qu’est la recette, qui a le droit de prononcer la recette (toi, pas eux) et combien de jours tu as pour accepter ou refuser. Si la recette n’est pas définie, le paiement n’est pas exigible, et le studio peut soutenir que le temps calendaire est le déclencheur.

Cession d’IP avec délai de grâce avant le paiement final

Presque tous les templates standard cèdent la propriété intellectuelle au client “au paiement final”. Jusqu’à ce que la dernière facture soit acquittée, le studio est propriétaire du code qu’il a écrit pour ton activité. Si un litige s’ouvre au cinquième mois d’une build de six mois, le studio est juridiquement le titulaire de l’IP et peut refuser de remettre le repository jusqu’à la résolution du litige. Nous avons vu ça deux fois. Dans les deux cas, la fondatrice a payé intégralement pour récupérer le code, puis a poursuivi pour dommages-intérêts.

La solution est une clause d’IP en deux temps. D’abord, l’IP est cédé au client de façon incrémentale au paiement de chaque facture, pas au paiement final. Tout code que tu as déjà payé est déjà à toi. Ensuite, le contrat accorde au client une licence perpétuelle, irrévocable et gratuite pour utiliser tout code livré à date, même en cas de litige. Le studio est protégé parce qu’il continue à être payé pour le travail réceptionné. Toi, tu es protégé parce qu’aucun litige ne peut t’enfermer dehors d’un code qui existe.

Source code escrow ne remplace pas cette clause. L’escrow est un instrument médié par un tiers, conçu pour le logiciel sous licence d’enterprise quand l’éditeur peut faire faillite. Pour une build sur mesure avec un petit studio, la bonne défense est l’accès au repository et la cession incrémentale d’IP.

Accès au repository dès le jour un

Une clause qui n’apparaît pas dans la plupart des templates et qui devrait : le studio accorde au client un accès en lecture au repository de code source dès le jour un de la mission. Le repository peut rester dans le GitHub ou GitLab du studio par commodité, mais le client a un accès en lecture dès le début et la possibilité de forker ou de migrer à tout moment, sans consentement ni frais.

Ce n’est pas de la défiance. C’est garantir qu’au trente et unième, au quatre-vingt-onzième ou au cent quatre-vingt-unième jour, le produit du travail est observable. Tu peux voir les commits. Si un développeur du studio s’en va et que le studio dit que la build a besoin de trois semaines de plus “à cause de la transition”, tu peux juger par toi-même. Si le studio cesse silencieusement de livrer, tu as quelque chose à confier à l’équipe suivante. Le coût pour le studio est à peu près zéro. La valeur pour le fondateur est à peu près celle de la codebase entière.

Une sortie qui ne prend pas 90 jours

La dernière clause porteuse du contrat est celle de résiliation. Presque tous les templates utilisent un préavis de 60 ou 90 jours pour une résiliation sans cause. C’est raisonnable pour une relation d’enterprise avec un master agreement de cinq ans. C’est hostile pour une build de six mois.

Une clause de résiliation taillée pour un fondateur fait trois choses. Elle permet à chaque partie de résilier avec 14 jours de préavis écrit, sans cause, après un cliff désigné (en général après la recette du Sprint Deux, pour qu’aucune des deux ne se débine au premier mois). Elle définit la résiliation pour cause (manquement à livrer un sprint réceptionné, rupture de confidentialité, détournement d’IP) avec un droit de cure de 7 jours. Et elle précise ce qui se passe à la résiliation : tout l’IP déjà cédé reste au client, le studio est payé pour le travail réceptionné à la date de la résiliation, sans kill fee, avec une obligation de handover de 5 jours ouvrés et un livrable défini.

La forme de cette clause déplace le pouvoir, du présupposé que la relation va continuer, à la réalité que toute build sur mesure peut s’arrêter plus tôt pour de bonnes raisons.

Trois pièges des templates standard

Les cinq clauses te permettent aussi de repérer les trois manières les plus fréquentes dont les templates standard échouent en silence.

Le premier piège, c’est la régie sans cap. Les templates de régie standard contiennent un langage du type “Le Développeur facturera aux taux horaires convenus pour le temps consacré au Projet”. Aucune contrainte sur le coût total. Toute clause de régie doit être couplée à un cap par sprint ou par phase que le studio ne peut pas dépasser sans ton accord écrit. Si le cap est atteint et que le sprint n’est pas livré, c’est une conversation, pas une facture par défaut.

Le deuxième piège, c’est la livraison définie par date plutôt que par recette. Les templates du monde enterprise disent “Le Logiciel sera livré au plus tard le 31 décembre”. C’est satisfait dès que le studio publie un release tagué dans le repository, indépendamment de son fonctionnement. Remplace chaque livraison basée sur une date par “Le Logiciel sera réputé livré lorsqu’il aura été réceptionné par le Client selon les critères de l’Exhibit A”. Le calendrier est une cible. La recette est le déclencheur.

Le troisième piège, c’est l’IP qui est cédé “au paiement final” sans délai de grâce. La plupart des fondateurs survolent la clause d’IP et supposent que “on reçoit le code quand on le paie” suffit. “Au paiement final” fait le même travail qu’un otage. Toute version de la clause d’IP qui ne transfère pas les droits de façon incrémentale, facture payée par facture payée, en crée un. Lis la clause attentivement, ou fais-la lire.

Cinq questions à poser au contrat avant de signer

Une fois le document devant toi, la manière la plus rapide de l’évaluer est de lui poser ces cinq questions à voix haute.

Première : si je signe ça et que le studio rate la recette du Sprint Deux, qu’est-ce qui se passe précisément. Le contrat doit répondre en une ou deux phrases. S’il faut feuilleter trois sections, le contrat est trop long et trop vague.

Deuxième : si un litige s’ouvre au quatrième mois d’une build de six mois, qui est propriétaire du code écrit jusqu’à ce moment-là. La réponse doit être “le client est propriétaire de tout ce qui a été payé”. Si la réponse est “le studio, jusqu’au paiement final”, la clause d’IP est mauvaise.

Troisième : est-ce que je peux voir le repository aujourd’hui. Si la réponse est “après qu’on aura monté le scaffolding initial le mois prochain”, la clause d’accès au repository est mauvaise.

Quatrième : si je veux sortir après le Sprint Trois, combien ça me coûte, combien de temps ça prend, avec quoi je repars. La réponse doit être 14 jours, sans kill fee, tout le travail réceptionné, un handover de 5 jours. Si c’est 60 à 90 jours plus un kill fee, la clause de sortie est mauvaise.

Cinquième : quel document prévaut si l’Exhibit A et le contrat se contredisent. La réponse doit être que l’Exhibit A est la source opérationnelle de vérité et que le contrat est la gouvernance au-dessus de lui. Si le contrat l’emporte sur l’Exhibit A, la clause de référence au périmètre est mauvaise.

Un contrat qui donne des réponses nettes et rapides à ces cinq questions va fonctionner. Un contrat qui ne le fait pas a besoin d’être réécrit avant signature, indépendamment du nombre de pages de définitions placées à l’avant.

Quand la version de 40 pages est bien le bon instrument

Il existe trois situations dans lesquelles un contrat plus épais et plus formel est l’instrument correct.

La première, c’est quand l’acheteur est une entité régulée (une banque, un assureur, un acteur santé, un acheteur du secteur public) et que le contrat doit inclure des termes de conformité non optionnels : langage HIPAA, références SOC 2, avenants RGPD de traitement de données, boilerplate de commande publique. Le contrat fait alors deux jobs, gouverner la build et acquitter des obligations réglementaires. C’est le second qui le rend long.

La deuxième, c’est quand la mission est un master agreement pluriannuel sous lequel plusieurs statements of work seront émis. Là, le contrat gouverne une relation, pas un projet. La plupart des fondateurs non techniques qui signent leur premier contrat de logiciel sur mesure ne sont pas dans cette catégorie. Ils achètent un projet.

La troisième, c’est quand la build elle-même implique de l’IP licencié significatif du développeur (une plateforme existante, un modèle existant, un framework propriétaire) que le contrat doit licencier au client à des conditions précises. Cet hybride a besoin de la structure supplémentaire. Les builds sur mesure from scratch, en général, non.

Si ta situation ne relève d’aucun de ces trois cas, le document de quarante pages ne te rend pas service. La version taillée pour un fondateur, de quatre à six pages, avec les cinq clauses bien posées, te protégera mieux que celle de trente-huit pages dont ton avocat non plus ne comprend pas entièrement les termes.

Contrat de développement logiciel : FAQ

Qu’est-ce qu’un contrat de développement logiciel ? Un contrat de développement logiciel est un accord écrit entre un client et un développeur ou studio de développement qui définit ce qui sera construit, comment ce sera payé, qui est propriétaire de l’IP résultant et ce qui se passe quand quelque chose ne va pas comme prévu. Pour un fondateur non technique, c’est le document qui survit à la conversation quand la conversation devient compliquée.

Quelles sont les quatre formes de contrat de développement logiciel qu’on va te présenter ? Les templates standard se présentent à peu près sous quatre formes. Les contrats de projet au forfait (un prix, une date de livraison, un document). Les contrats de régie (taux horaire, factures hebdomadaires, en général sans cap). Les master service agreements avec des statements of work attachés (relations sur la durée, plusieurs projets sous un même parapluie). Et les contrats d’équipe dédiée (tu paies pour la capacité d’une équipe, pas pour un livrable). La plupart des builds sur mesure early-stage fonctionnent mieux comme un hybride du deuxième avec une structure de cap par milestone. Vois notre comparatif forfait vs régie pour savoir quelle forme convient à ta situation.

Contrat de développement logiciel vs SOW vs MSA : quelle est la différence ? Le MSA (master service agreement) gouverne la façon dont tout le travail entre deux parties sera traité sur plusieurs projets. Le SOW (statement of work) est le document spécifique au projet, joint au MSA ou référencé par lui, qui définit ce qui est construit, sur quel timeline, pour quel budget. “Contrat de développement logiciel” est le terme parapluie qui, selon le contexte, désigne le MSA, le SOW, ou un document combiné de projet unique qui fait les deux. Pour une build initiale isolée, la version combinée est généralement la bonne forme, mais elle doit garder séparés, à l’intérieur de sa propre structure, le périmètre (équivalent SOW) et la gouvernance (équivalent MSA).

Est-ce que j’ai aussi besoin d’un NDA ? En général oui, mais pas en tant que document séparé. Une clause de confidentialité mutuelle dans le contrat suffit pour quasiment toute build early-stage. Un NDA autonome est le bon instrument quand tu échanges de l’information sensible avant d’avoir accepté de travailler ensemble : une conversation commerciale, une évaluation, une semaine de discovery. Une fois le contrat de développement signé, la clause de confidentialité qu’il contient fait le même travail.

Est-ce que je peux rédiger ce contrat moi-même ? Tu peux rédiger la structure, les priorités, les clauses que tu veux inclure, et le langage des cinq clauses porteuses. Tu ne dois pas signer le document final sans qu’un avocat le revoie. Un contrat taillé pour un fondateur, de quatre à six pages, prend une à deux heures de revue à un avocat, pas une semaine. Un document plus court est aussi un document moins cher à faire revoir. C’est une raison de plus pour laquelle la version taillée pour un fondateur se paie d’elle-même.

Avant de commencer à rédiger, assure-toi d’avoir déjà fait le travail décrit dans l’article sur le RFP sur l’écriture d’un partner brief, l’évaluation de studio du guide software house, et la décision de structure de paiement dans le comparatif forfait vs régie. Le contrat est l’artefact qui capture des décisions que tu as déjà prises. Ce n’est pas l’endroit où on les prend.