Sept clauses indispensables dans un contrat de développement

La plupart des litiges en développement logiciel remontent à quelque chose qui n'a jamais été écrit, pas à quelque chose qui a été violé. Le contrat ne disait pas à qui appartient le code après une séparation en cours de projet, donc techniquement personne n'a tort - et tout le monde est bloqué.

Voici les sept clauses qui l'évitent.

La réponse courte

Sept clauses, et la formulation exacte de chacune compte plus que le simple fait d'avoir une clause portant ce titre.

Propriété du code et de la PI, avec date de déclenchement

La clause la plus importante, et celle qui est le plus souvent rédigée de façon vague, délibérément ou par accident.

« Le client détient l'ensemble des livrables » semble protecteur. Sans déclencheur, ça ne l'est pas : les détient à partir de quand ? Certains contrats ne transfèrent la propriété qu'« à l'issue de la mission » - ce qui devient un vrai problème si la relation s'arrête au deuxième mois d'un développement de quatre mois, puisque rien n'a techniquement abouti.

Ce qu'il faut chercher à la place : une propriété transférée à chaque paiement de jalon, ou immédiatement à la création avec une licence de retour au développeur pour son portfolio. Les deux fonctionnent. Un calendrier flou, non.

Exclusions de périmètre explicites

Nous avons déjà écrit sur la raison pour laquelle un document de cadrage a besoin d'une section d'exclusions, et le contrat doit porter cette même précision, pas simplement y renvoyer vaguement.

« Développement du MVP tel que décrit dans le périmètre annexé » est plus faible qu'il n'y paraît si le périmètre annexé lui-même ne liste pas ce qui est exclu - coûts d'API tierces, contenu, migration de données, support au-delà d'une fenêtre définie. Sans cette liste, chaque partie retombe sur ses propres hypothèses, et les hypothèses coïncident rarement.

Un paiement par jalons, pas par calendrier

Un échéancier lié à des dates - à 30 jours, puis 30 jours plus tard, puis encore 30 jours - paie que quelque chose ait été livré ou non. Cela vous prive du seul véritable levier si le projet prend du retard.

Un échéancier lié à des jalons - flux de connexion fonctionnel, transaction principale de bout en bout, panneau d'administration opérationnel - ne libère le paiement que contre quelque chose que vous pouvez réellement vérifier. Ce seul changement protège un client plus que presque toute autre clause du contrat.

Un processus de demande de changement défini

Le périmètre changera. Un contrat qui ne dit pas comment dit implicitement « on verra le moment venu », ce qui favorise celui qui a le plus de levier à cet instant - généralement pas vous, en plein projet, quand changer de partenaire coûte cher.

La clause doit énoncer clairement : une demande de changement hors du périmètre défini est estimée et chiffrée séparément, par écrit, avant que le travail ne commence dessus. Cela protège les deux parties - le développeur n'absorbe pas de dérive gratuite, et vous ne découvrez pas une facture surprise pour ce que vous pensiez inclus.

Une fenêtre de support définie et explicitement bornée

« Support post-lancement inclus » n'est pas une clause, c'est une formule. Bornée comment - pendant combien de jours, couvrant quel type de problème, avec quel délai de réponse ?

Trente jours de correction de bugs sur les fonctionnalités existantes constituent une base raisonnable et courante. Tout ce qui va au-delà - nouvelles fonctionnalités, maintenance continue, délais de réponse prioritaires - doit faire l'objet d'un forfait distinct et chiffré, mentionné dans le contrat ou un accord lié, et non d'une hypothèse que chaque partie fait en silence.

Conditions de résiliation et de sortie

Tout contrat devrait répondre par écrit, avant que ce soit nécessaire : que se passe-t-il si l'une des parties veut sortir avant la fin du projet ?

Au minimum : préavis, ce qui est dû pour le travail accompli à ce stade, et confirmation que les conditions de propriété (voir clause un) s'appliquent proprement aussi en cas de résiliation anticipée, pas seulement à une fin réussie. Un contrat qui ne décrit que le déroulement d'une fin propre n'a pas anticipé le scénario le plus susceptible de provoquer un litige.

Confidentialité et non-réutilisation

Standard dans la plupart des contrats professionnels, mais il vaut la peine de vérifier ce point précis que les fondateurs croient couvert et qui souvent ne l'est pas : une clause interdisant au développeur de réutiliser votre logique métier spécifique, vos données ou votre approche propriétaire dans le projet d'un autre client - pas simplement une confidentialité générale sur le fait de ne pas parler publiquement de votre activité.

Les NDA génériques couvrent le secret. Cette clause couvre la réutilisation, et c'est la version qui compte réellement si la valeur de votre produit tient à la façon dont quelque chose fonctionne, pas seulement au fait qu'il existe.

Que faire s'il manque ces clauses

La plupart sont des ajouts, pas des réécritures. Un partenaire qui résiste fermement à l'ajout de dates de propriété claires, de paiements par jalons ou d'une liste d'exclusions vous donne une information qu'il vaut mieux avoir avant de signer, pas après - les questions à poser avant de signer couvrent la version conversationnelle de cette même vérification.

Aucune de ces sept clauses n'est inhabituelle ni agressive à demander. Elles font la différence entre un contrat qui décrit une relation et un contrat qui vous protège réellement si la relation tourne mal.

Vous relisez un contrat pour un MVP et souhaitez un second avis sur les conditions ? Envoyez-nous les détails - nous vous dirons ce qui manque. Notre propre structure contractuelle, y compris les conditions de PI et les jalons de paiement, est expliquée dans nos tarifs.