Caira peut examiner votre contrat en 3 clics :
Obtenez des modifications suggérées et des commentaires ajoutés directement dans votre fichier
Générez un résumé par e-mail à envoyer à l'autre partie
L'inscription à un essai gratuit prend moins de 30 secondes. Aucune carte bancaire requise : Commencez votre essai gratuit
« Ça marche sur ma machine » : pourquoi les développeurs web ont besoin de meilleurs contrats
Le monde du développement web est rongé par le « fossé des attentes ».
Vous livrez un code conforme au cahier des charges. Le client l'ouvre sur un iPhone 6 de 2014 et crie « C'est cassé ! »
Vous développez le CMS qu'ils ont demandé. Ils vous appellent six mois plus tard en exigeant que vous corrigiez un bug causé par un plugin qu'ils ont installé.
Le développement est logique. Les clients sont émotionnels. Votre contrat est le seul pont entre les deux. Sans lui, vous vous engagez pour un support technique non rémunéré à vie.
Voici les failles juridiques que vous devez corriger dans vos conditions générales de prestation.
1. Le trou noir de la compatibilité navigateur
Le scénario : Vous construisez un site React élégant. Il fonctionne parfaitement sur Chrome et Safari. Le PDG du client l'ouvre sur Internet Explorer 11 au bureau. La grille se casse. Ils retiennent le paiement jusqu'à ce que « tout fonctionne partout ».
La réalité juridique :
« Fonctionne partout » est techniquement impossible. Sans liste précise, un tribunal pourrait interpréter « site web fonctionnel » comme « fonctionnement sur des outils professionnels standard », ce qui pourrait inclure d'anciens navigateurs.
La solution :
Une clause relative aux navigateurs pris en charge.
Soyez précis. « Le site web est conçu pour fonctionner sur les deux dernières versions de Chrome, Safari, Firefox et Edge. La compatibilité avec les navigateurs anciens (par exemple IE11) est exclue, sauf accord exprès dans le cahier des charges. »
2. Tests de réception (le déclencheur de « lancement »)
Le scénario : Vous terminez le site. Vous envoyez le lien. « Dites-moi ce que vous en pensez. »
Silence pendant 3 semaines.
Puis : « Peut-on changer la police ? »
Puis silence pendant 2 semaines.
Puis : « En fait, peut-on déplacer le logo ? »
Vous avez dépassé la date limite de 3 mois et vous n'avez pas été payé pour les 50 % restants.
La réalité juridique :
Sans « période d'acceptation » définie, le projet est en mode zombie. Il n'est ni terminé ni inachevé.
La solution :
Une clause d'« acceptation réputée ».
« Le client dispose de 7 jours à compter de la livraison pour tester le logiciel. Si aucune « erreur » spécifique (définie comme un plantage / une défaillance critique) n'est signalée par écrit dans les 7 jours, le logiciel est réputé accepté et le solde final est dû. »
Cela les oblige à le vérifier, ou à vous payer.
3. Dérive du périmètre (« Juste un petit changement »)
Le scénario : Vous établissez un devis pour 5 pages. À mi-parcours, le client envoie le contenu. Il y a 12 pages. « J'ai juste découpé la page À propos, ce n'est pas un gros problème, non ? »
C'en est un. Cela touche à la logique de navigation, à l'impact sur le menu mobile et au temps de saisie du contenu.
La solution :
Arrêtez de chiffrer « un site web ». Chiffrez « un périmètre de mission ».
Livrables stricts : « 5 pages statiques. 1 formulaire de contact. »
La clause de variation : « Toute demande spécifique hors de ce périmètre sera facturée à notre tarif horaire standard de £[X]. Le développement sera suspendu jusqu'à l'approbation de la variation. »*
4. À qui appartient le code ? (droits de PI)
Le scénario : Vous utilisez votre « Starter Theme » standard ou une bibliothèque de fonctions utilitaires que vous avez écrite il y a des années. Le client se brouille avec vous. Il exige la cession intégrale des droits d'auteur sur tout le code.
Si vous cédez tout, vous ne pouvez légalement plus utiliser votre propre Starter Theme pour le client suivant. Vous avez vendu les « outils », pas seulement la « maison ».
La solution :
Faites la distinction entre le « code sur mesure » et la « PI préexistante ».
« Le développeur cède au client les droits d'auteur sur le design sur mesure et la mise en page du texte dès le paiement intégral. »*
« Le développeur conserve la propriété de toute « PI préexistante » (bibliothèques/frameworks réutilisables) et accorde au client une licence perpétuelle, non exclusive, pour les utiliser sur ce site web. »*
5. Corrections de bugs à vie
Le scénario : Le site est lancé. Deux ans plus tard, WordPress se met à jour. Le site casse. Le client appelle : « C'est vous qui l'avez construit, c'est à vous de le réparer. »
La solution :
Une période de garantie.
« Nous fournissons une période de garantie de 30 jours après le lancement pour corriger les bugs présents au lancement. Tout problème survenant après 30 jours, ou causé par des mises à jour tierces (plugins / modifications des navigateurs), relève d'une maintenance facturable. »
Pourquoi la revue de contrat est votre documentation
Vous commentez votre code. Vous devriez commenter votre relation commerciale.
La revue de contrat par IA analyse votre contrat de développement. Elle vérifie si vous avez accidentellement promis une « aptitude à l'usage » (un seuil juridique élevé) plutôt qu'une « compétence et diligence raisonnables ». Elle s'assure que votre flux d'« acceptation » est étanche. Elle vous aide à livrer le projet et à être payé, sans dette technique héritée.
Avertissement : les informations contenues dans cet article sont fournies à titre indicatif uniquement et ne sont pas destinées à constituer des conseils professionnels juridiques, financiers, fiscaux ou médicaux.
