Développements spécifiques logiciel: guide juridique complet

Par Joseph David Atias, avocat au Barreau de Paris · LinkedIn · Avril 2026 · Lecture : 14 min

Presque toutes les entreprises utilisent aujourd’hui des logiciels standards — ERP, CRM, SaaS métier. Cependant, ces solutions ne couvrent jamais 100 % des besoins. C’est pourquoi les développements spécifiques sont omniprésents : ils permettent d’adapter un logiciel standard aux particularités de chaque organisation. Par exemple, un module sur mesure greffé sur un ERP SAP, une extension développée sur Salesforce, ou une fonctionnalité custom intégrée dans un SaaS métier.

Pourtant, ces développements soulèvent des questions juridiques complexes, souvent mal traitées dans les contrats standards. Qui est propriétaire du code ? Quelle est la garantie applicable ? Que se passe-t-il en cas de mise à jour du logiciel standard ? Ce guide répond à toutes ces questions. Il vous aidera à sécuriser vos projets de développements spécifiques, que vous soyez client ou prestataire.

Sommaire

Qu’est-ce qu’un développement spécifique ?
Les différents types de développements spécifiques
Développement spécifique vs paramétrage vs sur mesure complet
Nature juridique du développement spécifique
La propriété intellectuelle : le point critique
Développements spécifiques et ERP (SAP, Oracle, Microsoft Dynamics)
Développements spécifiques et SaaS
Garanties et responsabilité
Maintenance et mises à jour du socle standard
Réversibilité et portabilité
Les pièges contractuels les plus fréquents
Les bonnes pratiques contractuelles
FAQ — Développements spécifiques

1. Qu’est-ce qu’un développement spécifique ?

Un développement spécifique est une adaptation, une extension ou un module complémentaire réalisé sur un logiciel standard existant pour répondre aux besoins particuliers d’un client. Autrement dit, il ne s’agit pas de créer un logiciel depuis zéro. En effet, le développement spécifique vient compléter, enrichir ou modifier une solution existante.

Les développements spécifiques sont particulièrement répandus dans trois contextes :

Les ERP (Enterprise Resource Planning) comme SAP, Oracle ou Microsoft Dynamics
Les CRM (Customer Relationship Management) comme Salesforce ou Microsoft Dynamics 365
Les plateformes SaaS métier qui proposent des possibilités d’extension ou de personnalisation

Par ailleurs, les développements spécifiques peuvent également concerner des solutions open source ou des logiciels propriétaires déployés en interne. Dans tous les cas, ils partagent une caractéristique commune : ils viennent se greffer sur un socle logiciel préexistant.

2. Les différents types de développements spécifiques

Les développements spécifiques ne sont pas tous équivalents. En effet, leur nature technique influence directement leur régime juridique. Voici les principales catégories.

Les extensions (add-ons)

Une extension est un module complémentaire qui s’ajoute au logiciel standard sans en modifier le cœur. Par exemple, un plugin développé pour Salesforce via l’AppExchange, ou une extension fonctionnelle sur un ERP. L’extension reste logiquement séparable du socle.

Les modifications du code standard

Certains développements impliquent de modifier directement le code standard du logiciel. Ce type d’intervention est généralement encadré strictement par l’éditeur, voire interdit. En effet, il peut faire perdre au client la garantie de l’éditeur et compliquer les mises à jour futures. On parle alors de customizations intrusives.

Les intégrations (connecteurs, APIs)

Les intégrations consistent à connecter le logiciel standard à d’autres systèmes (bases de données, logiciels tiers, services externes). Elles impliquent souvent le développement d’APIs, de connecteurs ou de scripts d’intégration. Ce type de développement est crucial dans les écosystèmes complexes.

Les rapports et tableaux de bord personnalisés

Il s’agit de créations de reportings sur mesure, utilisant les données du logiciel standard mais présentées de façon adaptée aux besoins du client. Ces développements sont généralement moins intrusifs et moins risqués juridiquement.

Les workflows et automatisations métier

Les workflows automatisent des processus métier spécifiques à l’entreprise. Ils peuvent être développés via des outils low-code intégrés au logiciel standard ou via du code custom. Leur nature juridique dépend fortement de la technologie utilisée.

3. Développement spécifique vs paramétrage vs sur mesure complet

Il est essentiel de bien distinguer le développement spécifique de deux notions voisines. En effet, ces trois concepts obéissent à des régimes juridiques différents.

Le paramétrage

Le paramétrage consiste à configurer le logiciel standard via les options prévues par l’éditeur, sans écrire de code. Par exemple, définir des règles métier via l’interface d’administration, créer des champs personnalisés, configurer des flux d’approbation. Le paramétrage ne soulève pas les mêmes enjeux juridiques que le développement, car il reste dans le cadre prévu par l’éditeur. Ainsi, il n’emporte aucun transfert de propriété intellectuelle et ne remet pas en cause la garantie de l’éditeur.

Le développement spécifique

Le développement spécifique implique, lui, l’écriture de code. Il modifie ou étend les fonctionnalités du logiciel standard au-delà de ce que permet le paramétrage. De ce fait, il soulève des questions de propriété intellectuelle, de garantie et de maintenance que le paramétrage ne pose pas.

Le développement sur mesure complet

À l’autre extrême, le développement sur mesure complet consiste à créer un logiciel entièrement à partir de zéro, sans s’appuyer sur un socle préexistant. C’est le domaine classique du contrat de développement logiciel. Ses enjeux contractuels sont plus larges mais aussi mieux couverts par les pratiques du marché.

En pratique, un même projet peut combiner ces trois dimensions : paramétrage de base, développement spécifique pour certaines fonctions, et éventuellement un module entièrement sur mesure pour les besoins très particuliers. Le contrat doit alors distinguer clairement les régimes applicables à chaque volet.

4. Nature juridique du développement spécifique

Sur le plan juridique, le développement spécifique est généralement qualifié de contrat d’entreprise, au sens des articles 1710 et suivants du Code civil. Le prestataire s’engage à concevoir et livrer un développement conforme au besoin exprimé par le client.

Toutefois, cette qualification est souvent imbriquée avec d’autres contrats. En effet, le développement spécifique s’intègre dans un écosystème contractuel plus large :

Le contrat de licence ou d’abonnement au logiciel standard
Le contrat de maintenance de ce logiciel standard
Le contrat d’intégration ou de déploiement initial

C’est pourquoi la rédaction contractuelle doit articuler précisément ces différents niveaux. Par exemple, une clause de garantie applicable au développement spécifique peut interférer avec la garantie de l’éditeur du logiciel standard. De même, la maintenance des développements spécifiques soulève des questions d’articulation avec la maintenance du socle.

Obligation de moyens ou obligation de résultat ?

Comme pour tout contrat d’entreprise, la nature de l’obligation du prestataire est cruciale. Par défaut, les prestataires cherchent à qualifier leur engagement en obligation de moyens. Cependant, lorsque le développement spécifique répond à des spécifications précises et bien définies, l’obligation de résultat peut être retenue par les juges. La rédaction doit donc être précise pour éviter toute ambiguïté.

5. La propriété intellectuelle du développement spécifique : le point critique

C’est la question la plus sensible et la plus mal traitée dans la pratique. Beaucoup de clients pensent naïvement que, parce qu’ils financent un développement spécifique, ils en deviennent automatiquement propriétaires. C’est faux. Le principe est exactement inverse.

Le principe : le prestataire reste propriétaire

En droit français, le code source d’un développement spécifique reste par défaut la propriété du prestataire qui l’a réalisé, en application de l’article L.113-9 du Code de la propriété intellectuelle. Ainsi, même si le client a intégralement payé le développement, il ne dispose que d’un droit d’utilisation — dont l’étendue est souvent limitée et parfois très restrictive.

Cette règle est d’autant plus importante que les développements spécifiques comportent souvent des savoir-faire stratégiques pour le client : processus métier sur mesure, algorithmes propriétaires, logique commerciale spécifique. Perdre la propriété de ces développements expose à plusieurs risques. Par exemple, le prestataire peut réutiliser le code chez un concurrent direct. De même, le client peut être contraint de revenir vers le même prestataire pour toute évolution future.

L’exigence d’une cession de droits écrite et précise

Pour que le client devienne propriétaire du développement spécifique, une cession de droits expresse doit être prévue au contrat. L’article L.131-3 du CPI impose des exigences strictes. La clause de cession doit préciser :

Les droits cédés : reproduction, représentation, adaptation, traduction
L’étendue : exclusive ou non, totale ou partielle
La destination : usage interne, commercialisation, sous-licence
Le territoire et la durée : généralement monde entier et durée légale

Une clause de cession vague ou incomplète sera interprétée restrictivement par les juges, au détriment du client. C’est pourquoi la rédaction doit être exhaustive.

Les trois régimes à négocier

Trois options sont généralement envisageables :

Cession exclusive au client : le client devient seul propriétaire. Le prestataire ne peut réutiliser ni vendre le développement. Cette option est la plus protectrice mais aussi la plus coûteuse.
Licence exclusive au client : le prestataire reste propriétaire, mais le client est le seul autorisé à utiliser le développement. Bon compromis pour les développements stratégiques.
Licence non exclusive : le prestataire peut réutiliser le développement chez d’autres clients. C’est l’option par défaut dans la plupart des contrats d’intégrateurs.

L’enjeu particulier des innovations

Les développements spécifiques les plus intéressants pour un prestataire sont ceux qui apportent une innovation. En effet, une fonctionnalité développée à la demande d’un client peut ensuite être intégrée au socle standard et commercialisée à grande échelle. C’est pourquoi les intégrateurs et éditeurs sont particulièrement réticents à céder leurs droits. Pour des développements stratégiques, la négociation sur ce point est essentielle.

6. Développements spécifiques et ERP (SAP, Oracle, Microsoft Dynamics)

Les ERP sont le terrain classique des développements spécifiques. En effet, chaque entreprise a ses processus propres, ses règles métier particulières, ses circuits de validation spécifiques. Un ERP standard ne couvre jamais 100 % des besoins.

Les technologies spécifiques aux ERP

Chaque grand éditeur propose ses propres langages et environnements de développement :

SAP : ABAP, puis désormais CAP, SAP UI5 et Fiori
Oracle : PL/SQL, Oracle Forms, APEX, puis désormais Oracle Integration Cloud
Microsoft Dynamics : X++ (Dynamics AX), C# pour Dynamics 365, Power Platform

Ces technologies sont propriétaires. Autrement dit, le code développé dans ces environnements ne peut fonctionner que sur la plateforme de l’éditeur. Cela crée une dépendance forte — le code est étroitement lié au socle standard.

Les enjeux spécifiques aux projets ERP

Trois enjeux contractuels sont particulièrement critiques dans les projets ERP :

La portabilité : le code ABAP ne peut s’exécuter que sur SAP. Si l’entreprise change d’ERP, les développements sont perdus.
La compatibilité avec les montées de version : les mises à jour majeures (par exemple la migration vers SAP S/4HANA) cassent souvent une partie des développements spécifiques.
La dépendance à l’intégrateur : les développements spécifiques sont souvent réalisés par un intégrateur (Capgemini, Accenture, Deloitte, etc.) qui détient le savoir-faire sur ces développements.

C’est pourquoi, pour un projet ERP, le contrat doit impérativement prévoir la remise du code source commenté, la documentation technique complète et la formation des équipes du client ou d’un autre intégrateur.

7. Développements spécifiques et SaaS

Les éditeurs SaaS proposent de plus en plus de capacités de personnalisation et d’extension. Cependant, ces développements spécifiques dans un contexte SaaS soulèvent des questions juridiques particulières.

Les différents modes de customization SaaS

Paramétrage avancé : configuration via l’interface (workflows, champs, vues)
No-code / low-code : création d’applications ou d’automatisations via les outils de l’éditeur (Power Apps, Salesforce Flow)
Extensions codées : développement de modules en code propriétaire (Apex pour Salesforce)
Intégrations via API : connexion à d’autres systèmes via les API proposées

Les spécificités juridiques du SaaS

Dans un contexte SaaS, le développement spécifique pose des questions uniques :

Les développements sont hébergés chez l’éditeur, pas chez le client
Ils fonctionnent dans l’environnement technique de l’éditeur, avec toutes ses contraintes
Ils dépendent de la continuité du service SaaS : si l’éditeur disparaît, les développements aussi
La propriété intellectuelle est souvent revendiquée par l’éditeur SaaS dans les CGU standard

Par ailleurs, les CGU des éditeurs SaaS prévoient fréquemment que les développements spécifiques réalisés pour un client peuvent être intégrés au socle standard sans compensation. Cette clause doit être systématiquement identifiée et négociée, surtout pour les fonctionnalités innovantes.

La réversibilité des développements SaaS

La réversibilité est un enjeu majeur pour les développements spécifiques en environnement SaaS. En effet, à la fin du contrat, que reste-t-il des développements réalisés ? Le contrat doit prévoir a minima la possibilité d’exporter la logique métier, la documentation, et idéalement le code source des extensions.

8. Garanties et responsabilité des développements spécifiques

Les garanties applicables aux développements spécifiques sont souvent sous-négociées. Or, elles conditionnent la capacité du client à obtenir réparation en cas de dysfonctionnement.

L’exclusion fréquente par l’éditeur du socle

Premier point essentiel : les éditeurs de logiciels standards excluent quasi systématiquement les développements spécifiques de leur garantie. Autrement dit, si un bug provient d’un développement spécifique — même réalisé par l’éditeur lui-même via ses équipes de services — la garantie du contrat de licence ne s’applique pas. Cette exclusion doit donc être compensée par une garantie distincte, dédiée aux développements spécifiques.

La garantie du prestataire réalisateur

Le prestataire qui réalise le développement spécifique doit garantir son travail. Plusieurs garanties sont classiques :

Garantie de conformité : le développement est conforme au cahier des charges
Garantie de parfait achèvement : correction des bugs apparents pendant 6 à 12 mois
Garantie d’éviction : absence d’atteinte aux droits des tiers (propriété intellectuelle)
Garantie de compatibilité : fonctionnement avec la version contractuelle du logiciel standard

Le délicat partage des responsabilités

En cas de dysfonctionnement, il est souvent difficile de déterminer l’origine exacte du problème. Est-ce un bug du développement spécifique ? Du logiciel standard ? Ou une incompatibilité entre les deux ? C’est pourquoi il est judicieux de prévoir contractuellement une procédure de diagnostic commun, impliquant l’éditeur du socle et le prestataire du développement.

9. Maintenance et mises à jour du socle standard

C’est un enjeu majeur, souvent ignoré lors de la signature du contrat. Les mises à jour du logiciel standard peuvent casser les développements spécifiques — c’est-à-dire les rendre partiellement ou totalement inopérants.

Pourquoi les mises à jour cassent les développements spécifiques

Plusieurs phénomènes expliquent ces régressions :

Modification des API : les nouvelles versions du logiciel standard modifient les points d’intégration
Changement des structures de données : les bases de données sous-jacentes évoluent
Refactorisation du code standard : les modifications intrusives peuvent devenir incompatibles
Obsolescence de technologies : certains langages ou frameworks utilisés peuvent être dépréciés

Les clauses à prévoir au contrat

Pour se protéger contre ces risques, plusieurs clauses doivent figurer au contrat :

Obligation d’information préalable de l’éditeur sur les mises à jour susceptibles d’impacter les développements spécifiques
Droit de refuser temporairement une mise à jour problématique (dans certaines limites techniques)
Obligation de documentation des changements techniques par l’éditeur
Prise en charge totale ou partielle des coûts d’adaptation par l’éditeur (à négocier)
Délai raisonnable pour l’adaptation des développements avant imposition de la mise à jour

Dans le contexte SaaS, ces clauses sont particulièrement difficiles à négocier, car l’éditeur impose souvent des mises à jour automatiques. C’est pourquoi il faut anticiper et, si possible, négocier une planification des releases et des environnements de test.

10. Réversibilité et portabilité

La fin du contrat pose des questions spécifiques pour les développements spécifiques. Que devient le code ? Comment l’entreprise peut-elle continuer à l’utiliser ou à l’adapter ?

La remise du code source et de la documentation

Même en cas de cession de droits au client, la remise effective du code source n’est pas automatique. Le contrat doit explicitement prévoir :

La remise du code source complet et commenté
La documentation technique et fonctionnelle
Les environnements de développement et de test nécessaires
Les dépendances (bibliothèques tierces, outils)

La formation des équipes

La remise du code ne suffit pas si personne ne sait le maintenir. C’est pourquoi il est utile de prévoir une phase de formation ou de transfert de connaissances — que ce soit vers les équipes internes du client ou vers un autre prestataire. Cette phase doit être tarifée et planifiée dans le contrat.

La clause d’escrow pour les développements critiques

Pour les développements stratégiques réalisés par un prestataire tiers, une clause d’escrow est recommandée. Le code source est déposé auprès d’un tiers séquestre. En cas de défaillance du prestataire, le code est remis au client. Cette garantie est particulièrement utile pour les intégrateurs ERP, dont la disparition peut mettre en péril tout un système d’information.

11. Les pièges contractuels les plus fréquents

Certaines erreurs reviennent systématiquement dans les contrats de développement spécifique. Les connaître permet de les anticiper.

Absence de cession de droits explicite — Le client n’obtient pas la propriété du code qu’il a pourtant financé
Clause de licence non exclusive — Le prestataire peut revendre le développement à un concurrent
Exclusion de garantie par l’éditeur du socle — Aucun recours en cas de dysfonctionnement lié à l’intégration
Absence de clause sur les mises à jour — Le client finance les adaptations lors de chaque montée de version
Cahier des charges flou — Les écarts d’interprétation débouchent sur des litiges ou des surcoûts
Absence de recette formalisée — Le client ne peut contester les défauts découverts après la livraison
Maintenance non distincte — Confusion entre correction de bugs et évolutions facturées
Absence de clause d’escrow — Dépendance totale au prestataire en cas de défaillance
Absence de remise documentaire — Code source sans documentation = code inutilisable
Clause RGPD manquante — Si le développement traite des données personnelles, les obligations RGPD s’appliquent

12. Les bonnes pratiques contractuelles

Pour sécuriser vos projets de développements spécifiques, quelques règles simples méritent d’être systématiquement appliquées.

Distinguer clairement le socle du développement spécifique

Le contrat doit identifier précisément ce qui relève du logiciel standard (régime classique de licence ou SaaS) et ce qui relève du développement spécifique (régime d’entreprise). Cette distinction conditionne l’ensemble des obligations applicables : propriété, garantie, maintenance, responsabilité.

Négocier systématiquement la propriété du développement

Pour tout développement spécifique stratégique, la cession exclusive des droits doit être la cible. À défaut, a minima une licence exclusive. La licence non exclusive ne doit être acceptée que pour des développements génériques, sans valeur concurrentielle.

Anticiper les mises à jour dès la signature

La clause relative aux mises à jour du socle standard doit être rédigée dès la signature du contrat initial. Il est beaucoup plus difficile de la négocier plusieurs années après, lorsque l’éditeur annonce une migration majeure.

Faire appel à un avocat spécialisé

Les contrats de développement spécifique combinent plusieurs régimes juridiques complexes. L’intervention d’un avocat spécialisé en droit des contrats IT est hautement rentable — l’économie réalisée dépasse largement le coût de l’intervention. Atias Avocats accompagne clients et prestataires dans la négociation de ce type de contrats. Découvrez nos services en droit des contrats IT.

Atias Avocats : votre partenaire pour vos développements spécifiques

Atias Avocats accompagne startups, scale-ups et grands comptes dans la rédaction, la négociation et l’audit de leurs contrats de développement spécifique. Le cabinet intervient aussi bien côté client que côté prestataire, avec une expertise particulière sur les projets ERP (SAP, Oracle, Microsoft Dynamics), les customizations SaaS (Salesforce, ServiceNow) et les clauses de propriété intellectuelle complexes.

Demander un audit · Mission freelance sur Malt · LinkedIn

13. FAQ — Développements spécifiques

Qu’est-ce qu’un développement spécifique ?

Un développement spécifique est une adaptation, extension ou module complémentaire réalisé sur un logiciel standard existant (ERP, CRM, SaaS) pour répondre aux besoins particuliers d’un client. Il se distingue du développement sur mesure complet car il s’appuie sur un socle logiciel préexistant. Il se distingue également du simple paramétrage car il implique une modification ou un ajout de code.

Qui est propriétaire d’un développement spécifique ?

Par défaut, le développement spécifique reste la propriété du prestataire ou de l’éditeur qui l’a réalisé, même si le client l’a intégralement financé. Pour que le client devienne propriétaire, une cession de droits expresse et précise doit être prévue au contrat, conformément à l’article L.131-3 du Code de la propriété intellectuelle. À défaut, le client ne dispose que d’un droit d’utilisation dont l’étendue peut être limitée.

Un éditeur SaaS peut-il réutiliser un développement spécifique financé par un client ?

Cela dépend du contrat. Par défaut, l’éditeur SaaS peut réutiliser le développement spécifique dans sa solution standard ou chez d’autres clients, car il en reste propriétaire. Le client ne peut s’y opposer que si le contrat prévoit expressément une exclusivité ou une cession de droits en sa faveur. Cette question est stratégique pour les fonctionnalités innovantes développées à la demande du client.

Les développements spécifiques sont-ils garantis par l’éditeur du logiciel standard ?

Non, les éditeurs refusent généralement de garantir les développements spécifiques, qu’ils soient réalisés par eux-mêmes ou par un tiers. Les clauses de garantie du contrat principal sont souvent limitées au socle standard et excluent explicitement les développements spécifiques. C’est pourquoi il est essentiel de négocier une garantie distincte pour ces développements.

Les mises à jour d’un logiciel standard peuvent-elles casser les développements spécifiques ?

Oui, c’est un risque majeur. Les mises à jour du socle standard peuvent rendre incompatibles ou inopérants les développements spécifiques, obligeant le client à les faire adapter à ses frais. Le contrat doit donc prévoir une obligation d’information préalable de l’éditeur sur les mises à jour impactantes, et idéalement une prise en charge des adaptations nécessaires.

Quelle est la différence entre un développement spécifique et un paramétrage ?

Le paramétrage consiste à configurer le logiciel standard via les options prévues par l’éditeur, sans écrire de code. Le développement spécifique implique, lui, l’écriture de code pour modifier ou étendre les fonctionnalités. Cette distinction est importante car les régimes juridiques diffèrent : le paramétrage n’emporte pas de cession de propriété intellectuelle, contrairement au développement spécifique.

Combien coûte la rédaction d’un contrat de développement spécifique par un avocat ?

Les honoraires varient selon la complexité du projet. Pour la rédaction ou l’audit d’un contrat de développement spécifique, comptez entre 2 000 € et 6 000 € HT en forfait. Pour un projet complexe impliquant plusieurs prestataires, des enjeux IP stratégiques ou un socle SaaS spécifique (Salesforce, SAP), le budget peut atteindre 10 000 € HT.

Pour aller plus loin

Joseph David Atias, avocat en droit des contrats IT à Paris

Fondateur d’Atias Avocats, cabinet numérique spécialisé en droit du numérique, contrats IT, RGPD et AI Act. Inscrit au Barreau de Paris (CNBF : 118810). Intervenant régulier sur les contrats de développement spécifique en environnement ERP (SAP, Oracle, Microsoft Dynamics), CRM (Salesforce, Dynamics 365) et SaaS métier. Accompagnement d’éditeurs, d’intégrateurs et de directions juridiques de grands comptes sur les enjeux de propriété intellectuelle et de cession de droits. Disponible en mission d’avocat conseil externe ou en accompagnement intégré.

Développements spécifiques logiciel : le guide juridique complet (2026)