Contrat de développement logiciel en Suisse : livrables, recette, bugs et propriété du code pour éviter le conflit à la mise en production
Beaucoup de projets IT dérapent au moment le plus sensible, la recette. Le client estime que ce n’est pas conforme, et l’équipe de développement répond que c’est hors périmètre. Voici une structure de contrat orientée exécution, pensée pour les start-up et PME en Suisse romande, avec des critères d’acceptation clairs, une gestion du changement cadrée, et des preuves de validation qui tiennent.
Objectif
Une mise en production validée, sans discussion de dernière minute.
Temps
45 à 75 min pour poser les bases et réduire le risque de litige.
Résultat
Un contrat qui décrit quoi livrer, comment accepter, et quoi corriger.
Ce guide est une trame pratique basée sur des principes courants du droit suisse des contrats. Selon votre modèle (forfait, régie, agile), votre secteur, et votre canton, des ajustements sont souvent nécessaires. En cas d’enjeu important, de blocage de recette, ou de discussion sur la propriété du code, un avis personnalisé d’un juriste numérique est recommandé.
1 Livrables et périmètre (ce qui doit être “livrable” et testable)
Ce que vous voulez voir dans le contrat
- Une liste des livrables, par exemple application web, API, documentation technique, scripts de déploiement, et guide utilisateur.
- Un périmètre fonctionnel explicite, souvent matérialisé par un backlog ou des spécifications versionnées.
- Une définition partagée du “terminé”, avec critères mesurables et tests attendus.
Dans la plupart des conflits, le problème n’est pas la qualité du code, c’est une définition floue de ce qui était inclus. Un périmètre testable réduit fortement les discussions “c’était évident” contre “ce n’était pas demandé”.
À trancher dès le départ (forfait, régie, agile)
- Au forfait, précisez ce qui est inclus, ce qui est exclu, et comment une demande hors périmètre devient un changement accepté.
- En régie, la clé est la gouvernance, qui décide, qui priorise, et comment vous validez au fil de l’eau.
- En agile, formalisez ce qui est “figé” au démarrage, et ce qui est itératif, avec une règle claire d’acceptation des user stories.
Si votre contrat hésite entre “obligation de moyens” et “obligation de résultat”, clarifiez le niveau d’engagement attendu. Sinon, le débat se déplacera sur la recette, avec une discussion difficile à trancher sans texte.
2 Recette, acceptance criteria et validation (la mécanique qui évite “pas conforme”)
L’objectif est simple, rendre la conformité vérifiable, puis garder une trace exploitable.
Définissez les critères d’acceptation par livrable
Pour chaque fonctionnalité clé, décrivez ce qui doit être observé pour dire “accepté”. Exemple, un parcours utilisateur, une règle métier, un rapport exporté, ou un niveau de performance acceptable pour votre contexte.
- Scénarios de test simples, compréhensibles par le métier.
- Données de test et jeux d’essai si nécessaire.
- Ce qui est explicitement hors recette, par exemple l’optimisation future, le refactoring non requis, ou des intégrations non prévues.
Organisez une recette en deux temps, pré-production puis production
Beaucoup de projets échouent parce que la première vraie utilisation arrive en production. Un contrat efficace prévoit une recette sur un environnement de test, puis une validation de mise en production, avec une fenêtre de stabilisation.
Pour éviter les “bugs fantômes”, définissez le canal unique de remontée, par exemple un outil de tickets. Cela permet de figer ce qui est signalé, quand, et avec quel impact.
Prévoyez un “sign-off” simple et daté
La recette n’est utile juridiquement que si elle se voit. Un email de confirmation, un procès-verbal de recette, ou une validation dans l’outil de projet suffit souvent, tant que la règle est prévue et que les personnes habilitées sont identifiées.
Bon réflexe
- Identifier qui a le pouvoir de valider au nom du client.
- Définir ce qui vaut acceptation, par exemple acceptation expresse ou acceptation tacite après une période de test, si cela correspond à votre organisation.
- Distinguer acceptation “avec réserves” et acceptation “sans réserves”.
Piège classique
- Valider oralement puis contester deux semaines plus tard.
- Dire “ok pour mise en prod” sans cadrer la liste de réserves.
- Mélanger des demandes d’amélioration avec des défauts bloquants.
Documentez le “go live” et la stabilisation
La mise en production est un évènement contractuel. Vous gagnez en sécurité si le contrat prévoit un plan de déploiement, un plan de rollback, une liste de prérequis, et une période de stabilisation où les bugs bloquants sont traités en priorité.
Conseil simple, après le déploiement, envoyez un récapitulatif écrit. Date et heure de mise en production, version livrée, liens vers les notes de version, et liste des réserves restantes avec leur priorité.
Prévoyez une règle de sortie si la recette bloque
Quand la recette devient un bras de fer, la meilleure protection est une clause de gouvernance. Qui tranche si un point est un défaut ou une évolution, et comment la décision est documentée. Cela évite que le projet reste figé.
Cadence
Un point recette planifié, avec décisions consignées.
Traçabilité
Tickets, captures, logs, et décisions rattachés à une version.
Décision
Une règle claire, défaut à corriger ou change request à chiffrer.
3 Bugs, défauts et correction (éviter la confusion entre garantie et évolution)
Le terme “bug” n’a de valeur contractuelle que si vous le définissez. Le plus efficace est de lier la notion de défaut aux critères d’acceptation et à la documentation convenue.
Correction et délais
Plutôt que d’annoncer des délais rigides, prévoyez un mécanisme. Priorisation selon la gravité, engagement de prise en charge, et transparence sur la date de mise à disposition d’un correctif.
Garanties et limites
En droit suisse, la logique de garantie dépend notamment de la qualification du contrat et de ce qui est convenu. Un juriste numérique peut vous aider à choisir des clauses cohérentes avec votre modèle, et à éviter les promesses intenables.
D’un point de vue contractuel, un projet logiciel ressemble souvent à un contrat d’entreprise quand un résultat est attendu, et à un contrat de mandat quand l’engagement porte davantage sur les efforts. Le bon cadrage influence la recette, la gestion des défauts et la discussion sur la conformité.
4 Change requests et preuves (le “pare-feu” contre le hors périmètre)
Une change request n’est pas un obstacle, c’est une méthode. Vous évitez surtout la situation où une demande se glisse dans la recette sans discussion de coût, de délai, ou de priorité.
| Élément | Contenu attendu | Preuve à garder | Décision | Statut |
|---|---|---|---|---|
| Demande | Description, objectif métier, valeur attendue | Ticket ou email daté | Accepter ou refuser | À qualifier |
| Impact | Périmètre, budget, planning, risques et dépendances | Estimation documentée | Arbitrage et priorité | À valider |
| Accord | Texte court, prix ou budget, dates, critères d’acceptation | Annexe signée ou approbation écrite | Lancement ou report | Accepté |
Si votre projet ressemble à un chantier, la logique est la même. Tant que les changements ne sont pas formalisés, le risque est de se disputer sur ce qui était inclus. Cette mécanique est proche de ce que l’on voit aussi dans les litiges de construction, par exemple quand la coordination se dégrade ou que la fin de chantier bloque.
Pour comprendre l’importance de garder la main et préserver les preuves, vous pouvez aussi lire notre article sur la situation où l’architecte ou le directeur de travaux ne répond plus. Et si votre conflit se cristallise sur un paiement final avant correction, l’analogie est très proche de la retenue de garantie et le solde après levée des défauts.
5 Propriété intellectuelle du code et accès (ce qui doit être écrit avant de payer le solde)
Ce que vous devez sécuriser côté client
- Qui détient quoi, le code spécifique, les bibliothèques internes, les templates, et les composants open source.
- Ce que vous obtenez exactement, une cession, une licence, et sur quels usages, durée et territoire, selon la négociation.
- L’accès aux dépôts, aux environnements, et aux secrets, avec une méthode de transfert contrôlée.
- La documentation minimale nécessaire pour que le projet reste maintenable.
Le conflit typique est simple. Vous pensez acheter “le logiciel”, et l’autre partie pense vendre “un accès et un service”, ou une licence limitée. Sans clause écrite, vous êtes exposé au moment de changer d’équipe ou de prestataire.
Côté équipe de développement, ce qui protège aussi
- Une clause claire sur ce qui est réutilisable et reste la propriété de l’équipe, notamment les briques génériques.
- Un inventaire open source, avec licences et obligations de notice.
- Une limitation raisonnable des engagements sur la performance si l’infrastructure n’est pas sous contrôle.
L’équilibre est souvent la bonne stratégie. Le client obtient une sécurité d’exploitation, et l’équipe de développement protège ses outils. Un juriste numérique aide à écrire des clauses cohérentes, et à éviter les formulations trop vagues qui se retournent contre l’un ou l’autre à la mise en production.
Confidentialité et données
Si votre logiciel traite des données personnelles, prévoyez une clause de confidentialité, une répartition des rôles, et des exigences de sécurité proportionnées. En Suisse, ce point est très souvent lié à votre organisation et à vos flux, donc il doit être adapté au cas par cas.
Si vous avez un doute sur la rédaction d’une clause de confidentialité ou sur la gestion des accès, faites valider le contrat avant de donner les identifiants de production.
Quand une discussion se durcit, un mécanisme d’écrit clair fait toute la différence. Dans d’autres domaines, on observe la même logique, par exemple quand il faut contester une décision sans perdre en crédibilité. Vous pouvez voir notre approche sur une indemnisation “valeur vénale” jugée trop basse ou sur un refus de remboursement pour “préexistence”. Le réflexe est identique, documenter, répondre par écrit, et garder des preuves.
Vous voulez un contrat qui passe la recette sans drama ?
Décrivez votre projet et votre mode de collaboration. JuriUp vous met en relation gratuitement avec un expert juridique orienté numérique en Suisse romande, pour adapter vos clauses de livrables, recette, bugs, change requests et propriété du code.
6 FAQ: contrat développement logiciel en Suisse
Cliquez pour ouvrir.
Est-ce que la recette peut être “tacite” si le client ne répond pas ?
Souvent oui, si le mécanisme est prévu au contrat et si la procédure de recette est claire. Dans la pratique, ce qui compte est la transparence, une période de test réaliste, un canal de remontée des défauts, et une preuve de mise à disposition. Pour un modèle adapté à votre projet, un juriste numérique sur JuriUp peut cadrer les formulations.
Comment éviter que tout devienne “bug” au moment de la mise en production ?
En liant la notion de défaut aux critères d’acceptation. Si un comportement n’était pas exigé ou décrit, c’est généralement une évolution, pas un défaut. Le contrat doit aussi prévoir une procédure de change request, avec décision écrite, impact et priorité. C’est le moyen le plus simple d’éviter une recette impossible.
Qui est propriétaire du code en Suisse si le contrat ne dit rien ?
C’est précisément une zone à risque. Les droits sur le logiciel et la portée de l’usage accordé peuvent devenir très discutés si rien n’est écrit. Pour éviter une dépendance, le contrat devrait indiquer clairement si vous obtenez une cession ou une licence, ce qui est inclus, et l’accès aux dépôts et à la documentation. Si la propriété du code est stratégique pour votre start-up ou votre PME, faites valider cette partie via JuriUp.
Que faire si un conflit éclate déjà pendant la recette ?
Commencez par sécuriser les preuves, tickets, versions, captures, et messages de validation. Ensuite, séparez défauts et évolutions, et proposez une décision écrite point par point. Si l’enjeu financier devient important, une mise en demeure bien rédigée peut parfois remettre le projet sur des rails, mais elle doit être calibrée à votre dossier. Dans une situation tendue, passez par JuriUp pour obtenir une stratégie adaptée.
Si votre dossier implique une pression pour signer un document défavorable, gardez en tête que la signature sous pression est un sujet sensible. Notre article sur la reconnaissance de dette signée sous pression illustre bien l’importance de réagir vite et de documenter.
