Nous utilisons des cookies et autres technologies pour :
Vous offrir les fonctionnalités essentielles
Analyser l'audience et les performances
Si vous cliquez sur « Tout accepter », nous et nos partenaires, dont Google, utiliserons également des cookies et autres technologies, notamment pour :
Personnaliser les annonces
Mesurer et améliorer l'efficacité des annonces
Vous pouvez accepter, refuser ou personnaliser vos choix à tout moment via le lien « Gérer les cookies » disponible en bas de toutes les pages.
Les cookies nécessaires contribuent à rendre un site web utilisable en activant des fonctions de base comme la navigation de page et l'accès aux zones sécurisées du site web. Le site web ne peut pas fonctionner correctement sans ces cookies.
Fonctionnel
Les cookies et traceurs fonctionnels servent à vous rendre un service que vous demandez, sans mesurer votre navigation ni alimenter de publicité. Ils sont actifs par défaut ; les refuser désactive la messagerie d'assistance, le reste du site continue de fonctionner.
Nom : crisp-client* | crisp-loader (stockage local du navigateur, et non cookies)
Objet : Crisp fait fonctionner la messagerie d'assistance de votre demande de devis. Le traceur conserve votre conversation d'une page à l'autre et rattache vos messages à votre dossier, afin que vous n'ayez pas à tout réexpliquer.
Information complémentaire : Le chargement de la messagerie contacte client.crisp.chat et client.relay.crisp.chat. Aucune donnée n'est utilisée à des fins publicitaires.
Période de stockage : Jusqu'à effacement des données de navigation
Marketing
Les cookies marketing sont utilisés pour effectuer le suivi des visiteurs au travers des sites web. Le but est d'afficher des publicités qui sont pertinentes et intéressantes pour l'utilisateur individuel et donc plus précieuses pour les éditeurs et annonceurs tiers.
Objet : Avec Google Analytics, nous mesurons comment vous utilisez nos sites, comment vous avez trouvé notre site et si vous rencontrez des erreurs. Nous utilisons ces données pour améliorer notre site.
Information complémentaire : Google peut stocker ou utiliser une partie ou l'ensemble des cookies ou technologies similaires dans votre navigateur, appli ou appareil aux fins décrites ci-dessus. Pour gérer la manière dont les cookies sont utilisés, consultez g.co/privacytools. Vous pouvez aussi gérer les cookies dans votre navigateur.
Objet : Ces cookies gardent la trace des pages que vous consultez. Cela nous permet de vous montrer des annonces pertinentes sur Google et ses partenaires et de mesurer l'efficacité de nos campagnes.
Nom : MSCC | MUID | MUIDB | SRCHD | SRCHHPGUSR | SRCHUID | SRCHUSR | _uetsid
Objet : Ces cookies gardent la trace des pages que vous consultez. Cela nous permet de vous montrer des annonces pertinentes sur Bing et ses partenaires et de mesurer l'efficacité de nos campagnes.
Objet : Ces cookies permettent d'afficher des annonces publicitaires personnalisées (ciblage et reciblage publicitaire), de mesurer l'efficacité de nos campagnes Facebook et d'analyser le fonctionnement du site.
Créer un logiciel, une application mobile ou une plateforme SaaS représente souvent un investissement important pour une entreprise. Pourtant, les litiges sont fréquents : retard de livraison, fonctionnalités manquantes, dépassement du budget initial ou désaccord sur ce qui devait réellement être développé.
Dans la plupart des dossiers, le problème ne vient pas d'un défaut technique majeur mais d'un manque de définition du projet dès le départ. Un logiciel n'est pas un produit standardisé : il est construit progressivement à partir des besoins exprimés par le client et des choix techniques proposés par le prestataire.
Quelques précautions simples permettent pourtant d'éviter une grande partie des contentieux. Elles concernent principalement la définition du besoin, l'organisation du projet et la preuve des prestations réalisées.
Trouvez votre avocat en droit des nouvelles technologies
Gratuit et sans engagement
Continuer
I. Un cahier des charges imprécis est souvent à l'origine du conflit
La première erreur consiste à démarrer un projet sur la base de quelques échanges de courriels ou d'une simple proposition commerciale.
Lorsque les fonctionnalités attendues ne sont pas précisément décrites, chaque partie peut avoir une vision différente du résultat final. Le client estime que certaines fonctionnalités étaient incluses. Le développeur considère au contraire qu'elles n'ont jamais été demandées.
Avant le lancement du projet, il est donc recommandé de formaliser les besoins dans un document détaillé : objectifs du logiciel, fonctionnalités attendues, interfaces concernées, contraintes techniques, calendrier prévisionnel ou encore livrables attendus.
Cette phase de définition protège les deux parties. Elle permet également au prestataire informatique de remplir son obligation de conseil, reconnue de longue date par la jurisprudence. La Cour de cassation rappelle ainsi que le professionnel de l'informatique doit informer et conseiller son client sur l'adéquation des solutions proposées aux besoins exprimés (Cass. com., 25 octobre 1994, n° 93-10.184).
En pratique, plus le besoin est défini précisément au départ, moins le risque de désaccord est important lors de la livraison.
II. Le projet doit être validé étape par étape
Beaucoup de litiges apparaissent lorsque le client découvre le logiciel uniquement à la fin du développement.
Une méthode plus sécurisée consiste à organiser le projet en plusieurs phases : conception, développement, démonstration, corrections puis recette finale.
À chaque étape, le client doit pouvoir vérifier le travail réalisé et formuler ses observations. Ces validations intermédiaires permettent d'identifier rapidement les difficultés et d'éviter l'accumulation de désaccords pendant plusieurs mois.
Le contrat peut également prévoir une procédure de recette. Cette phase permet au client de tester le logiciel avant son acceptation définitive et de signaler d'éventuelles réserves. Les anomalies constatées sont alors corrigées avant la validation finale.
Cette organisation présente un avantage majeur : elle facilite ensuite la preuve des prestations réellement exécutées en cas de contestation.
III. Que faire si le logiciel livré ne correspond pas aux attentes ?
Lorsqu'un désaccord apparaît, la première question est souvent de savoir ce qui avait réellement été convenu entre les parties.
Le contrat, le cahier des charges, les comptes-rendus de réunion, les courriels et les validations intermédiaires deviennent alors essentiels. Ils permettent de déterminer si le prestataire a exécuté les prestations commandées et si le client a respecté son obligation de collaboration.
En effet, un projet informatique ne repose pas uniquement sur le développeur. Le client doit également fournir les informations nécessaires, répondre aux demandes du prestataire et participer aux phases de validation. Son absence de collaboration peut parfois expliquer les retards ou certaines difficultés d'exécution.
En cas de litige sur le paiement, la charge de la preuve pèse principalement sur celui qui réclame l'exécution d'une obligation. La Cour de cassation rappelle ainsi qu'un prestataire informatique doit être en mesure de démontrer les prestations effectivement réalisées (Cass. com., 8 mars 2023, n° 21-12.244). Elle a également précisé que la seule émission de factures ne suffit pas à établir la réalité des prestations invoquées (Cass. com., 10 mars 2021, n° 19-14.888).
Avant toute procédure judiciaire, une expertise amiable ou une négociation permettent souvent d'identifier précisément les points de désaccord et d'éviter un contentieux long et coûteux.
Fiche pratique rédigée par
Maître Nathan BENZACKEN
Avocat au barreau de PARIS (droit bancaire, droit commercial, droit de l'environnement)
