Contrats de développement logiciel : ce qu'il faut vérifier avant de signer

La plupart des contrats de développement logiciel sont signés dans un état d'optimisme. Les deux parties sont enthousiastes à propos du projet, la relation est cordiale et l'avenir paraît simple. Personne ne lit attentivement la clause de résolution des litiges lorsqu'on est convaincu qu'il n'y en aura jamais. Personne ne scrute la cession de propriété intellectuelle lorsqu'on part du principe que le prestataire agira correctement.

Le problème est que les contrats ne sont pas rédigés pour les beaux jours. Ils constituent le seul document qui régit ce qui se passe lorsque les choses tournent mal — quand le périmètre s'emballe, quand le prestataire ne respecte pas les délais, quand vous devez mettre fin à la collaboration, quand vous découvrez que le code a été construit sur une bibliothèque dont la licence est incompatible. Au moment où vous avez besoin du contrat, vous vous trouvez déjà dans une situation difficile. Si vous ne l'avez pas lu correctement avant de signer, vous êtes sur le point de découvrir exactement à quel point vous manquez de leviers.

Nous avons eu des clients qui ont perdu des droits de propriété intellectuelle qu'ils croyaient posséder, qui n'ont pas pu mettre fin à une collaboration défaillante sans payer des dizaines de milliers d'euros en préavis, et qui ont découvert en cours de projet que les accords de non-divulgation qu'ils avaient signés ne couvraient pas réellement leur concept commercial. Chacun d'eux aurait repéré le problème s'il avait su quoi chercher avant de signer.

Ce guide couvre les clauses importantes, celles qui sont fréquemment négligées, et les dispositions que vous devriez refuser d'accepter. Il est destiné aux fondateurs, aux chefs de produit et aux responsables des achats — et non aux juristes — et il est conçu pour vous donner suffisamment de maîtrise pour examiner un contrat de manière éclairée, même si vous faites appel à un avocat pour la vérification finale.

---

Propriété intellectuelle

Il s'agit de la clause la plus importante de tout contrat de développement logiciel, et c'est celle qui est le plus souvent mal comprise.

Le standard que vous devez attendre est la cession complète des droits de propriété intellectuelle dès le paiement intégral. Cela signifie que, une fois que vous avez payé, le code, la documentation, les ressources graphiques et toutes les œuvres dérivées vous appartiennent de manière absolue. Pas au prestataire. Pas sous licence. À vous.

Ce que cette clause doit stipuler, en termes simples : le prestataire vous cède irrévocablement tous les droits de propriété intellectuelle sur les livrables, y compris le droit d'auteur, à réception du paiement final. Il ne doit y avoir aucune exception, aucun droit conservé et aucun langage de licence se faisant passer pour une cession de propriété.

Points de vigilance :

• Formulation de « licence d'utilisation » à la place d'une cession. Si le contrat stipule que le prestataire « vous accorde une licence » pour utiliser le logiciel, vous n'en êtes pas propriétaire. Vous le louez. Le prestataire en conserve la propriété et peut, en théorie, révoquer ou modifier les conditions. Cette formulation est parfois présentée de manière à ressembler à une propriété. Lisez chaque mot attentivement.
• Droits conservés sur la « propriété intellectuelle préexistante ». Les prestataires conservent légitimement la propriété des outils, frameworks, bibliothèques et codes standards qu'ils apportent à un projet. C'est équitable. Ce qui n'est pas acceptable, c'est une propriété intellectuelle préexistante définie de façon si large qu'elle englobe les fonctionnalités principales de ce que vous avez commandé. Demandez-leur de lister spécifiquement quelle propriété intellectuelle préexistante est conservée et assurez-vous de disposer d'une licence irrévocable et libre de redevance pour l'utiliser dans votre produit.
• Cession de propriété intellectuelle conditionnelle. Certains contrats incluent des clauses par lesquelles la propriété intellectuelle « revient » au prestataire si vous manquez un paiement ou enfreignez une condition. Nous abordons ce point dans la section sur les clauses à risque. Ne l'acceptez jamais.
• Œuvre de commande versus cession. Dans certaines juridictions, un logiciel créé par un prestataire ne se qualifie pas automatiquement comme « œuvre de commande ». Une clause de cession explicite contourne entièrement cette ambiguïté. Assurez-vous que le contrat utilise un langage de cession explicite quelle que soit la juridiction.

Demandez au prestataire de confirmer par écrit, avant votre signature, que vous serez propriétaire de la propriété intellectuelle à part entière dès le paiement. Toute hésitation est un signal qui mérite d'être approfondi.

---

Périmètre des travaux

Un périmètre des travaux vague est une fuite budgétaire qui attend d'éclater. Le Cahier des charges (CDC) est le document qui définit exactement ce que le prestataire construit pour vous, et s'il manque de précision, chaque désaccord sur ce qui est « inclus » sera résolu dans le sens d'un coût supplémentaire.

Ce qu'un CDC bien défini comprend :

• Une liste spécifique de fonctionnalités, et non une description générale du produit
• Des critères d'acceptation pour chaque livrable — comment les deux parties sauront-elles qu'une tâche est terminée ?
• Les choix de plateforme et de pile technologique
• Les intégrations tierces avec les systèmes nommés
• Les attentes en matière de performances le cas échéant (temps de chargement des pages, seuils d'utilisateurs simultanés)
• Ce qui est explicitement hors périmètre

Le processus de gestion des modifications est aussi important que le CDC lui-même. Aucun projet ne survit à la réalité sans changements. La question est de savoir si les modifications sont gérées de manière transparente ou utilisées comme mécanisme pour extraire des revenus supplémentaires sans votre pleine compréhension. Un bon contrat prévoit un processus formel de demande de modification : le client soumet une demande de modification par écrit, le prestataire fournit une évaluation écrite de l'impact en termes de délais et de coûts, et les travaux sur la modification ne commencent qu'après votre approbation écrite.

Méfiez-vous de tout contrat qui ne définit pas comment les modifications sont gérées. « Nous intégrerons les modifications raisonnables sans frais supplémentaires » n'est pas un processus — c'est une promesse vague qui s'évapore au moment où vous et le prestataire ne vous accordez pas sur la définition de « raisonnable ».

Le CDC doit être une annexe ou un addendum joint au contrat, et non intégré dans un e-mail commercial. S'il ne figure que dans une chaîne d'e-mails, faites-le formaliser avant de signer le contrat principal.

---

Conditions de paiement

La structure de paiement est là où s'établissent les rapports de force d'un projet. La façon dont vous payez, et quand, détermine le niveau de contrôle que vous conservez tout au long de la collaboration.

Les trois structures principales :

• Basée sur des jalons. Le paiement est lié à des livrables définis. Vous payez lorsqu'un élément spécifique est achevé et accepté. Il s'agit du modèle le plus favorable au client pour les projets à prix fixe, car votre argent est toujours en retard sur la valeur reçue.
• Régie (temps et matériaux). Vous payez les heures travaillées, généralement à terme échu, hebdomadairement ou mensuellement. C'est le standard pour les contrats récurrents et le développement itératif. Le risque est un coût non plafonné si le périmètre n'est pas géré rigoureusement.
• Livrable payé d'avance. Vous payez un prix fixe pour un résultat défini. C'est raisonnable pour de petites missions bien délimitées.

Les règles que nous recommandons :

Ne payez jamais plus de 30 à 40 % de la valeur totale du contrat d'avance. Un acompte initial de 20 à 30 % est standard et raisonnable — il couvre les frais de démarrage du prestataire et lui donne la confiance que vous êtes sérieux. Tout montant supérieur à 40 % d'avance fait pencher les leviers en leur faveur. Si un projet échoue ou n'est pas livré, récupérer un paiement de 60 % d'avance par voie judiciaire est coûteux, lent et incertain.

Les paiements par jalons doivent être liés à l'acceptation, et non au passage du temps. « Nous facturerons le dernier vendredi de chaque mois » n'est pas une facturation par jalons — c'est une facturation temporelle présentée comme des jalons. Les critères d'acceptation du CDC constituent la condition préalable au paiement.

Les clauses de retenue méritent d'être demandées pour les collaborations importantes. Une retenue de 5 à 10 % du paiement final, conservée pendant 30 à 60 jours après la mise en production, incite le prestataire à corriger rapidement les bogues post-lancement. Tous les prestataires n'accepteront pas cette condition, mais elle mérite d'être négociée.

---

Confidentialité et accord de non-divulgation

La plupart des contrats de développement logiciel incluent une clause de confidentialité. La question est de savoir si elle couvre ce que vous avez réellement besoin de protéger.

Ce qui doit être couvert : votre concept commercial, vos données, votre architecture technique, tout secret commercial que vous divulguez lors de la phase de découverte, vos données clients, et l'existence même de la collaboration si elle est commercialement sensible.

Accord de non-divulgation mutuel ou unilatéral : Dans la plupart des cas, un accord mutuel est approprié. Le prestataire peut partager avec vous des informations sur ses méthodes, ses structures tarifaires ou ses outils au cours de la collaboration — un accord unilatéral qui ne vous protège que vous peut créer des frictions. Les accords mutuels sont standard et ne devraient pas être un point de litige.

Durée : Les obligations de confidentialité doivent survivre au contrat. Une clause stipulant que la confidentialité s'applique « pendant la durée du présent accord » ne vous protège pas une fois la collaboration terminée. Le standard est de deux à cinq ans après la résiliation pour les informations confidentielles générales, sans limite de temps pour les secrets commerciaux.

Sous-traitants : Si le prestataire fait appel à des sous-traitants ou à des développeurs externalisés pour votre projet, assurez-vous que la clause de confidentialité exige explicitement que le prestataire lie ces parties à des obligations équivalentes. Une clause de confidentialité qui ne couvre que les propres employés du prestataire est une lacune.

---

Garanties et responsabilité

Les contrats de développement logiciel contiennent fréquemment des garanties qui semblent complètes mais offrent peu de protection concrète, et des clauses de responsabilité soit totalement absentes, soit fortement déséquilibrées au détriment du client.

À quoi doit ressembler une garantie logicielle : Une disposition de garantie raisonnable engage le prestataire à corriger les défauts du logiciel signalés dans un délai défini après la mise en production — généralement 30 à 90 jours. Elle doit couvrir les défauts qui empêchent le logiciel de fonctionner conformément aux spécifications du CDC. Elle ne doit pas vous obliger à prouver que le bogue existait au moment du lancement, mais seulement qu'il existe dans la période de garantie.

Ce qu'une garantie n'est pas : Aucun prestataire sérieux ne garantira ni ne devrait garantir que le logiciel ne contient aucun bogue. Les logiciels sont complexes. Ce qu'ils peuvent raisonnablement garantir, c'est qu'ils corrigeront les bogues dans le délai spécifié sans frais supplémentaires. Méfiez-vous des garanties générales promettant la perfection — elles sont soit inexécutables, soit utilisées pour argumenter que chaque problème est hors périmètre.

Plafonds de responsabilité : La plupart des contrats incluent un plafond sur la responsabilité totale du prestataire, généralement égal aux honoraires versés dans le cadre du contrat. C'est standard et globalement acceptable. Ce qui n'est pas acceptable, c'est un plafond de responsabilité d'un montant dérisoire (par exemple, 500 £ ou 1 000 £) pour une mission à 50 000 £, ou un plafond combiné à une exclusion générale des pertes indirectes qui vous empêcherait d'obtenir une compensation significative pour une livraison défaillante.

Indemnisation : Le contrat doit inclure une clause d'indemnisation mutuelle couvrant les réclamations de tiers en matière de propriété intellectuelle. Plus précisément, le prestataire doit vous indemniser si le logiciel qu'il livre enfreint les droits de propriété intellectuelle d'un tiers. Vous devez également vérifier si vous indemnisez le prestataire pour toute propriété intellectuelle que vous fournissez — c'est raisonnable, mais assurez-vous que le périmètre est limité aux ressources que vous apportez effectivement.

---

Résiliation

Votre droit de mettre fin à une collaboration qui ne fonctionne pas est l'une des protections les plus importantes de tout contrat de service, et c'est une disposition que les clients ne parviennent fréquemment pas à négocier avant de signer.

Droit de résiliation pour convenance : Vous devez avoir le droit de résilier le contrat sans motif, avec un préavis raisonnable. En règle générale, 30 jours est la norme. Certains contrats ne prévoient que la résiliation pour faute — ce qui signifie que vous ne pouvez partir que si le prestataire a manqué matériellement à ses obligations. Cela vous piège dans une relation défaillante à moins que vous ne puissiez prouver la faute, ce qui est souvent difficile et long à établir.

Ce que vous recevez à la résiliation : Le contrat doit clairement stipuler qu'à la résiliation, vous recevez : tout le code développé à ce jour, dans un état livrable ; toute la documentation ; les identifiants d'accès à tous les environnements, référentiels ou services créés en votre nom ; et un plan de transition clair. Un prestataire qui conserve le code jusqu'à ce qu'un litige soit résolu dispose d'un levier considérable sur vous. N'acceptez pas cela.

Préavis et paiement à la résiliation : Si vous résiliez pour convenance, vous devez vous attendre à payer pour les travaux achevés jusqu'à la date de résiliation. Ce que vous ne devez pas accepter, c'est une obligation de payer pour des travaux non encore commencés, ou des « frais d'annulation » représentant un pourcentage significatif de la valeur restante du contrat. Certains contrats incluent des dommages et intérêts forfaitaires à la résiliation — examinez-les attentivement.

Résiliation pour faute : Vous devez également avoir le droit de résilier immédiatement, sans préavis, si le prestataire commet une faute grave qui n'est pas corrigée dans un délai raisonnable (généralement 14 à 21 jours après notification écrite).

---

Résolution des litiges

Les litiges dans le développement logiciel sont courants — concernant le périmètre, la qualité, les délais, le paiement et la propriété intellectuelle. La façon dont un litige est résolu, où il est résolu et à quel coût peut avoir autant d'importance que son issue.

Juridiction : Pour les collaborations nationales, assurez-vous que le droit applicable et la juridiction compétente sont ceux de votre pays. Pour les collaborations internationales, il s'agit d'un point de négociation important. Un prestataire basé en Europe de l'Est ou en Asie du Sud peut proposer sa juridiction locale. L'implication concrète est que si vous devez faire exécuter un jugement, vous devez le faire dans leur pays — ce qui peut être coûteux, lent ou pratiquement impossible.

Processus d'escalade : Les bons contrats incluent un processus d'escalade par étapes : discussion informelle entre les responsables de projet, puis escalade vers la direction générale, puis médiation formelle, puis arbitrage ou contentieux. C'est à la fois sensé et rentable — la plupart des litiges peuvent être résolus sans procédure formelle s'il existe un processus structuré.

Arbitrage versus contentieux : L'arbitrage est généralement plus rapide, moins coûteux et plus confidentiel que le contentieux judiciaire. Pour les litiges en deçà d'un certain seuil (souvent 50 000 à 100 000 £), le coût de l'arbitrage est proportionné. Assurez-vous que toute clause d'arbitrage spécifie un organe d'arbitrage reconnu et un siège d'arbitrage dans votre juridiction.

Note internationale : Si vous contractez avec un prestataire hors de votre juridiction, envisagez d'exiger que le contrat soit régi par le droit anglais et gallois ou par une autre juridiction de common law internationalement neutre. Cela vous donne accès à un droit commercial bien développé et à un régime d'exécution prévisible.

---

Accord de traitement des données (RGPD)

Si le logiciel en développement traitera des données personnelles — de vos clients, de votre personnel ou de toute personne dans l'EEE ou au Royaume-Uni — vous êtes légalement tenu de disposer d'un Accord de traitement des données (ATD) avec toute partie qui traite ces données en votre nom.

Ce n'est pas facultatif. C'est une exigence du UK GDPR et du RGPD européen, et l'absence d'un ATD vous expose à un risque réglementaire en cas de violation de données ou d'audit par une autorité de contrôle.

Qui est qui : Dans presque toutes les relations de développement logiciel, vous êtes le responsable du traitement — vous déterminez la finalité et les moyens du traitement. Le prestataire est le sous-traitant — il traite les données selon vos instructions. L'ATD doit refléter cela clairement.

Ce que l'ATD doit couvrir :

• Les catégories de données personnelles traitées et les finalités du traitement
• Les obligations du prestataire de traiter les données uniquement sur la base de vos instructions documentées
• Les mesures de sécurité techniques et organisationnelles appropriées
• Les restrictions relatives à la sous-traitance (le prestataire ne peut pas transmettre vos données à un tiers sans votre autorisation)
• L'assistance pour les demandes des personnes concernées et la notification des violations
• La suppression ou la restitution des données personnelles à la fin de la collaboration
• Les droits d'audit

Si un prestataire refuse de signer un ATD ou prétend qu'il est inutile dans le cadre d'une mission de développement, considérez cela comme un signal d'alarme sérieux. Même dans un contexte de développement, des données personnelles sont souvent chargées dans des environnements de test — et ces données doivent être protégées.

---

Clauses à risque à rejeter

Certaines clauses contractuelles ne sont pas seulement défavorables — ce sont des dispositions que les clients expérimentés apprennent à identifier et à refuser. Ce sont les clauses qui semblent anodines pendant la phase optimiste de la signature et qui deviennent préjudiciables lorsque les choses tournent mal.

La propriété intellectuelle qui revient en cas de paiement manqué. Toute clause qui transfère la propriété intellectuelle au prestataire si vous manquez un paiement, même temporairement, donne au prestataire une option nucléaire sur votre produit. Un litige de paiement — qui peut survenir pour des raisons légitimes — doit être résolu par des mécanismes de recouvrement de créances, et non en récupérant la propriété intellectuelle de quelque chose que vous avez déjà largement payé.

Responsabilité illimitée du client. Certains contrats incluent des clauses par lesquelles le client indemnise le prestataire de manière générale pour toutes les pertes découlant du projet. Cela peut inclure des pertes causées par les propres erreurs du prestataire. Aucun client ne devrait accepter une responsabilité illimitée ou des indemnités qui vont au-delà des ressources et informations qu'il apporte directement.

Absence de droit de résiliation sans motif. Si vous ne pouvez pas sortir du contrat sans prouver que le prestataire l'a enfreint, vous avez renoncé à votre capacité de réagir à une collaboration défaillante sans entrer dans un litige. Insistez toujours sur un droit de résiliation pour convenance.

Absence d'accès à un environnement de préproduction. Il s'agit d'un signal d'alarme pratique plutôt que juridique. Si le contrat ne vous garantit pas l'accès à un environnement de préproduction tout au long du développement, vous n'avez aucune visibilité indépendante sur ce qui est construit jusqu'à ce que le prestataire décide de vous le montrer. Insistez pour un accès continu.

Reconduction automatique avec de longs délais de résiliation. Les contrats récurrents qui se renouvellent automatiquement pour des périodes de 12 mois avec des fenêtres de résiliation de 90 jours sont conçus pour piéger les clients dans des arrangements qu'ils souhaitent quitter. Un préavis mensuel de 30 jours pour un contrat récurrent mensuel est la norme.

Clauses de non-sollicitation larges. De nombreux prestataires incluent des clauses vous empêchant d'embaucher leurs développeurs pendant une période suivant la collaboration. Une clause de non-sollicitation étroite couvrant les développeurs directement affectés à votre projet pour une durée de 12 mois est raisonnable. Une clause générale couvrant tous les employés du prestataire pour 24 mois est une tentative de protéger leur vivier de talents à vos dépens.

---

Comment nos contrats sont structurés chez Cyberbeak

Nous ne sommes pas neutres sur ce sujet — nous sommes un prestataire de développement logiciel, et nous avons une vision de la façon dont les contrats doivent fonctionner. Nous estimons qu'il vaut la peine d'être transparents sur notre approche.

Nos accords standard prévoient la cession complète de la propriété intellectuelle au client dès réception du paiement final. Il n'existe aucun droit conservé au-delà des bibliothèques et outils préexistants standard, qui sont listés et couverts par une licence irrévocable. Nous utilisons des structures de paiement par jalons pour les projets à prix fixe, avec des jalons liés aux critères d'acceptation convenus dans le CDC. Nous ne demandons pas plus de 30 % d'avance.

Toute collaboration impliquant le traitement de données personnelles inclut un ATD par défaut. La confidentialité est mutuelle. Notre plafond de responsabilité est fixé aux honoraires versés dans le cadre du contrat, avec des exclusions standard pour la fraude et la faute intentionnelle. Les clients disposent d'un droit de résiliation pour convenance de 30 jours. À la résiliation, tout le code, la documentation et les identifiants d'accès sont transférés dans un délai de cinq jours ouvrés.

Nous incluons une garantie de correction des défauts de 60 jours après le lancement sur tous les projets à prix fixe.

Nous pensons que ces conditions sont équitables pour les deux parties, et nous acceptons que les clients les fassent examiner par un avocat. Si un prestataire potentiel s'oppose à l'une de ces dispositions, il vaut la peine de demander pourquoi.

---

Foire aux questions

Ai-je besoin d'un avocat pour examiner un contrat de développement logiciel ?

Pour toute mission supérieure à 15 000–20 000 £, nous le recommandons vivement. Un avocat spécialisé en droit commercial des technologies peut examiner un accord de développement logiciel standard en une à deux heures. Le coût est généralement de 300 à 600 £. Compte tenu des enjeux — votre propriété intellectuelle, votre capacité à sortir du contrat, vos obligations en matière de données — c'est l'un des investissements à plus fort retour que vous puissiez réaliser. Pour les missions plus modestes, lire ce guide et l'appliquer vous-même peut être suffisant, mais un examen professionnel n'est jamais du temps perdu.

Que faire si le prestataire refuse de négocier les termes du contrat ?

La plupart des prestataires sérieux négocieront sur les points importants. Si un prestataire refuse de discuter de la cession de propriété intellectuelle, de la responsabilité ou des droits de résiliation, cela vous dit quelque chose d'important sur la façon dont il aborde les relations clients en général. Une résistance stylistique mineure est normale — un refus catégorique de négocier des protections substantielles est un signal d'alarme. S'ils ont vraiment un formulaire standard non négociable, demandez-leur d'expliquer par écrit chaque clause dont vous n'êtes pas sûr. Leurs explications vous en apprendront beaucoup.

Qu'en est-il des accords verbaux et des échanges par e-mail ?

Les accords verbaux ont force obligatoire dans la plupart des juridictions, mais ils sont extrêmement difficiles à faire exécuter car il n'existe aucun enregistrement clair de ce qui a été convenu. Les échanges par e-mail ont plus de poids et peuvent constituer un accord contraignant dans certaines circonstances, mais ils créent une ambiguïté quant au périmètre et aux conditions. La seule position sûre est de s'assurer que chaque condition importante — périmètre, paiement, propriété intellectuelle, résiliation — est consignée dans un accord écrit signé avant le début des travaux. Si un prestataire commence à travailler sur la base d'un accord verbal et que les choses tournent mal, vous pourriez disposer de très peu de recours.

Puis-je utiliser un contrat type plutôt que les conditions du prestataire ?

Oui, et dans de nombreux cas c'est préférable. Si vous commandez régulièrement des logiciels, disposer de vos propres conditions standard rédigées une fois par un avocat et utilisées systématiquement dans toutes les collaborations vous donne une base connue. Le prestataire peut demander des modifications, ce qui constitue une négociation — mais partir de votre propre modèle signifie que vous partez de conditions structurées en votre faveur. Des modèles sont également disponibles auprès d'organisations telles que TechUK et la Law Society, bien qu'ils doivent être examinés par un avocat pour s'assurer qu'ils correspondent à votre situation spécifique.

---

Bien rédiger un contrat n'est pas une question de méfiance. Il s'agit de s'assurer que les deux parties ont la même compréhension de ce sur quoi elles se sont engagées, et qu'il existe un processus clair et équitable pour gérer les choses qui, inévitablement, se déroulent différemment de ce qui était prévu.

Si vous évaluez une mission de développement logiciel et souhaitez comprendre comment nos accords sont structurés, ou si vous avez des questions sur la signification concrète de clauses contractuelles spécifiques, nous sommes heureux d'en discuter. Contactez-nous — sans engagement, sans argumentaire commercial, juste une discussion franche sur ce à quoi ressemblent des conditions équitables.