Lorsqu'une entreprise finance le développement d'un logiciel sur mesure, la question de la propriété du code source arrive souvent tard dans les discussions, parfois après la signature. Pourtant, c'est elle qui détermine ce que vous pourrez faire de votre propre système le jour où vous changerez de prestataire ou que vous déciderez de reprendre le développement en interne.
Trois termes différents se confondent dans cette question : le code source, le modèle de données, et les données elles-mêmes. Chacun obéit à des règles juridiques distinctes, et chacun appelle une clause de cession spécifique. Ce qui complique les choses, c'est que le contrat standard de prestation ne règle souvent qu'une seule de ces trois dimensions, parce que les deux autres semblent évidentes. Elles ne le sont pas.
Cet article ne traite pas de ce qu'il faut demander dans une clause de cession en général : il traite de ce qu'il faut recevoir, concrètement, le jour de la sortie. Une liste de livrables datés, transmissibles à votre conseil juridique, donc vérifiable avant la clôture.
Trois choses différentes qu'on confond : le code, le modèle de données, les données
Le code source est l'ensemble des fichiers qui composent le logiciel : modules, bibliothèques, scripts de déploiement, configurations. C'est ce que les tribunaux appellent une œuvre de l'esprit, donc protégée par le droit d'auteur. Sans cession explicite, l'auteur reste propriétaire, même si le client a payé le développement.
Le modèle de données est la structure de la base : les tables, leurs relations, les contraintes, les index. Il est distinct du code source parce qu'il peut être réutilisé avec un autre logiciel, ou migré vers une autre plateforme, et parce que sa modification entraîne souvent des impacts opérationnels que la modification du code seul ne produit pas. Un contrat qui cède le code mais reste muet sur le schéma de base laisse un actif essentiel hors de votre périmètre.
Les données elles-mêmes, c'est le contenu de vos tables : vos clients, vos transactions, vos référentiels métier. Elles vous appartiennent toujours, parce que vous en êtes le responsable de traitement au sens du RGPD et de la loi 09-08 marocaine. Mais les posséder en droit ne garantit pas que vous puissiez les extraire en pratique : il faut un format exploitable, une documentation du modèle, et des outils d'export qui fonctionnent sans assistance du prestataire.
Les trois objets doivent être cédés dans le contrat. L'oubli d'un seul d'entre eux suffit à bloquer la réversibilité.
Ce qui s'applique par défaut quand le contrat est muet sur la cession
En droit marocain, le contrat de prestation de services suit les articles 723 et suivants du DOC (Dahir des Obligations et des Contrats). Le louage d'ouvrage stipule que l'ouvrier ou l'entrepreneur conserve la propriété de ce qu'il fabrique, sauf convention contraire. En d'autres termes, si le contrat ne prévoit rien, le code reste chez le prestataire, même si vous avez financé l'intégralité du développement.
Le droit français applique le même principe via l'article L. 131-3 du Code de la propriété intellectuelle : les droits d'auteur ne se transfèrent pas automatiquement, même en cas de commande rémunérée. Une cession doit être écrite, détaillée, et délimitée par objet (usage, territoire, durée). Un silence du contrat équivaut à une non-cession.
Dans les deux cas, le prestataire conserve un droit d'usage personnel sur son propre code, sauf clause d'exclusivité. Cela signifie qu'un composant développé pour vous peut réapparaître, sous une forme réutilisable, dans un projet concurrent. La parade est une clause d'œuvre dédiée, qui stipule que le développement est réalisé exclusivement pour votre besoin métier et ne peut être commercialisé ailleurs.
Enfin, le droit d'usage que le client obtient par défaut est un droit d'exploitation limité au périmètre contractuel. Vous pouvez utiliser le logiciel pour l'usage prévu, mais pas le modifier, le redistribuer, ni le faire évoluer vous-même. Pour tout cela, il faut une cession complète des droits patrimoniaux.
La clause de cession : périmètre, moment du transfert, livrables intermédiaires
Une clause de cession correctement rédigée précise trois choses : ce qui est cédé, quand le transfert a lieu, et ce qui est livré à chaque étape.
Le périmètre de la cession doit énumérer les droits transférés : reproduction, modification, adaptation, intégration dans un système tiers, distribution. Il doit aussi couvrir les œuvres dérivées, parce qu'une cession qui ne porte que sur le code initial ne vous autorise pas à en créer une version améliorée sans retourner négocier avec l'auteur. Enfin, il doit mentionner le modèle de données et les schémas de base, explicitement, parce que leur statut juridique reste flou dans la jurisprudence marocaine et qu'un silence du contrat peut être interprété comme une non-cession.
Le moment du transfert est souvent la recette définitive, c'est-à-dire le procès-verbal qui acte la conformité du livrable. Mais cette logique pose un problème : si la recette intervient trois mois après la mise en production, et que vous changez de prestataire entre-temps, vous n'êtes pas encore propriétaire du code qui tourne sur vos serveurs. Une alternative plus sûre est le transfert à la livraison de chaque lot, conditionné au paiement de la tranche correspondante. Cela vous donne un contrôle progressif, lot par lot, et cela permet au prestataire de conserver une garantie sur ce qui n'a pas encore été payé.
Les livrables intermédiaires doivent être définis dans le contrat, donc documentés dans un planning de réversibilité. Un livrable complet comprend le code source versionné (avec l'historique Git si vous en avez demandé la conservation), la documentation technique (architecture, API, procédures de déploiement), les scripts de migration de base, et les jeux de données de test. Ces éléments doivent être remis à chaque jalon, pas uniquement en fin de projet, car une documentation écrite six mois après la livraison du code n'a souvent plus la même valeur qu'une documentation contemporaine du développement.
Réversibilité : la liste exacte de ce que vous recevez le jour de la sortie
La réversibilité, c'est l'ensemble des opérations qui permettent de transférer le système à un autre prestataire, ou de le reprendre en interne, sans perte de service ni dégradation des données. Elle ne se limite pas à une copie du code source : elle inclut tout ce qui est nécessaire pour que le nouveau prestataire puisse comprendre, exécuter et faire évoluer le système sans l'assistance de l'équipe sortante.
Voici la liste de réversibilité standard, celle qu'un conseil juridique ou un DSI peut vérifier avant la clôture du contrat :
- Code source complet et versionné : tous les modules, bibliothèques internes, scripts de déploiement, fichiers de configuration, avec l'historique Git si le dépôt a été maintenu tout au long du projet. Le format de livraison doit être précisé (archive .zip, accès à un dépôt Git privé, ou transfert de propriété d'un dépôt GitHub).
- Documentation technique à jour : schéma d'architecture (diagrammes de composants, flux de données), documentation des API (spécifications OpenAPI ou équivalent), guide de déploiement (prérequis système, procédure d'installation, variables d'environnement), guide d'exploitation (procédures de sauvegarde, de restauration, de montée de version).
- Export complet des données en format exploitable : dump SQL pour les bases relationnelles, export JSON ou CSV pour les bases NoSQL, avec un schéma documenté qui indique le rôle de chaque table et de chaque colonne. Si les données contiennent des informations sensibles (données personnelles, secrets d'entreprise), l'export doit être chiffré et accompagné d'une procédure de déchiffrement.
- Scripts de migration et de test : scripts SQL ou équivalent pour reconstruire le schéma de base, jeux de données de test anonymisés pour valider que le système fonctionne après le transfert, procédures de vérification de l'intégrité référentielle.
- Transfert des accès et des secrets : clés API, certificats SSL, identifiants de connexion aux services tiers (serveurs de messagerie, passerelles de paiement, services cloud), avec une procédure de rotation des secrets après le transfert pour éviter que l'ancien prestataire conserve un accès résiduel.
- Formation de l'équipe de reprise : ateliers de passation avec le nouveau prestataire ou l'équipe interne, documentation des choix techniques et des arbitrages métier, réponses aux questions techniques pendant une période de transition (typiquement 30 jours après la clôture).
Chaque élément de cette liste doit être daté dans le planning de réversibilité, parce qu'une livraison incomplète le jour de la sortie bloque la reprise et vous laisse dépendant de l'ancien prestataire pour terminer le transfert. Si le contrat ne précise pas les délais, la jurisprudence applique le délai raisonnable, qui est souvent trop long pour un besoin opérationnel.
Séquestre de code : quand il protège vraiment, quand c'est un alibi
Le séquestre de code (ou escrow) est un dépôt du code source chez un tiers de confiance, qui le remet au client si certaines conditions se réalisent : faillite du prestataire, arrêt du support, non-respect des obligations contractuelles. Il est souvent présenté comme une garantie de continuité, car mais il ne l'est que si trois conditions sont réunies.
Premièrement, le dépôt doit être mis à jour régulièrement, idéalement à chaque livraison de version. Un séquestre qui contient le code de la version initiale, alors que le système en production est à la version 12, ne protège personne. Le contrat doit donc préciser la fréquence des dépôts et les pénalités en cas de retard.
Deuxièmement, le code séquestré doit être complet : modules, bibliothèques, scripts, documentation, données de test. Un dépôt qui ne contient que le code applicatif, sans les dépendances ni la documentation technique, ne suffit pas pour redémarrer le système sur une autre infrastructure. La clause de séquestre doit donc renvoyer à la liste de réversibilité complète, et le tiers séquestre doit vérifier, lors de chaque dépôt, que tous les éléments sont présents.
Troisièmement, les conditions de levée du séquestre doivent être vérifiables sans négociation. Une clause qui stipule que le code est remis "en cas de défaillance grave du prestataire" laisse place à l'interprétation, donc au contentieux. Une clause qui stipule que le code est remis "si le prestataire ne répond pas à trois demandes de support espacées de 15 jours" est vérifiable par tout tiers, donc opposable sans recours au juge.
En pratique, le séquestre est surtout utile dans les contrats de longue durée (trois ans ou plus) où le risque de faillite du prestataire est réel, ou dans les projets critiques où un arrêt du système entraînerait des pertes financières immédiates. Pour les projets courts ou pour les prestataires de taille moyenne bien établis, la clause de cession complète, avec livraison progressive du code et de la documentation, offre souvent une protection équivalente à moindre coût.
Pourquoi le coût de sortie doit être chiffré dans le contrat d'entrée
La réversibilité a un coût, parce qu'elle impose au prestataire de maintenir une documentation à jour, de structurer le code pour qu'il soit lisible par une équipe extérieure, et de prévoir des ateliers de passation en fin de projet. Ce coût est souvent invisible dans les offres commerciales, car il est dilué dans le prix global, mais il devient visible le jour de la sortie si le contrat n'a rien prévu.
Un contrat qui ne chiffre pas la réversibilité laisse le prestataire libre de facturer la passation au tarif qu'il juge raisonnable. Dans les faits, cela signifie souvent un tarif de régie élevé (1 200 à 1 800 MAD par jour-homme pour un profil senior), facturé sur une durée qui dépend de la qualité de la documentation existante. Si la documentation n'a pas été maintenue pendant le projet, la passation peut prendre plusieurs semaines.
La parade est de chiffrer la réversibilité dans le contrat initial, sous la forme d'un forfait de passation inclus dans le prix global, ou d'un nombre de jours de support post-livraison compris dans le tarif. Ce forfait doit couvrir la formation de l'équipe de reprise, la réponse aux questions techniques, et la correction des anomalies découvertes après le transfert. Il doit aussi préciser que les livrables de réversibilité (documentation, scripts, export de données) sont fournis sans surcoût, parce qu'ils font partie intégrante du livrable contractuel.
Enfin, le contrat doit prévoir une pénalité en cas de livraison incomplète des éléments de réversibilité, parce qu'un prestataire qui sait qu'il peut facturer la passation au tarif qu'il choisit n'a aucune incitation à maintenir une documentation exploitable pendant le projet. La pénalité doit être proportionnée au préjudice (typiquement, le coût de reconstitution de la documentation manquante par le nouveau prestataire), donc elle doit être chiffrée dans le contrat, pas laissée à l'appréciation du juge.
La checklist d'une page à faire relire par votre conseil
Avant de signer un contrat de développement sur mesure, transmettez cette checklist à votre conseil juridique ou à votre DSI. Elle énumère les points qui doivent figurer dans le contrat pour que la sortie soit possible sans contentieux.
Propriété du code source :
- Clause de cession complète des droits patrimoniaux (reproduction, modification, adaptation, distribution, œuvres dérivées).
- Mention explicite de la cession du modèle de données et des schémas de base.
- Clause d'œuvre dédiée si vous souhaitez interdire la réutilisation du code dans un projet concurrent.
Moment du transfert :
- Transfert progressif, lot par lot, conditionné au paiement de la tranche correspondante.
- Ou transfert global à la recette définitive, avec une clause de garantie qui maintient vos droits d'usage entre la livraison et la recette.
Livrables de réversibilité :
- Code source complet et versionné (format de livraison précisé).
- Documentation technique à jour (architecture, API, déploiement, exploitation).
- Export complet des données en format exploitable, avec schéma documenté.
- Scripts de migration et jeux de données de test.
- Transfert des accès et des secrets, avec procédure de rotation.
Coût de sortie :
- Forfait de passation inclus dans le prix global, ou nombre de jours de support post-livraison.
- Liste des livrables fournis sans surcoût.
- Pénalité en cas de livraison incomplète, chiffrée dans le contrat.
Séquestre de code (optionnel) :
- Fréquence des dépôts (à chaque livraison de version).
- Périmètre du dépôt (code, documentation, données de test).
- Conditions de levée vérifiables sans négociation.
Cette checklist peut être annexée au contrat sous la forme d'un planning de réversibilité, qui détaille pour chaque livrable la date de remise, le format, et le responsable du contrôle. Elle transforme une obligation générale de cession en une série d'engagements vérifiables, donc opposables sans recours au juge.
Vous souhaitez comprendre comment structurer un développement sur mesure qui reste sous votre contrôle, ou discuter des arbitrages techniques et juridiques qui protègent votre investissement dans le logiciel ? Contactez-nous pour un échange sans engagement.
FAQ
Le code source m'appartient-il automatiquement si j'ai payé le développement ?
Non. En droit marocain comme en droit français, le code source reste la propriété de l'auteur (le prestataire) sauf clause de cession explicite dans le contrat. Le paiement vous donne un droit d'usage limité au périmètre contractuel, mais pas le droit de modifier, redistribuer ou faire évoluer le logiciel sans l'accord du prestataire. Pour obtenir la propriété complète, le contrat doit comporter une clause de cession des droits patrimoniaux qui couvre la reproduction, la modification, l'adaptation et la distribution, y compris pour les œuvres dérivées.
Quelle est la différence entre cession du code source et cession du modèle de données ?
Le code source est l'ensemble des fichiers qui composent le logiciel (modules, bibliothèques, scripts). Le modèle de données est la structure de la base (tables, relations, contraintes, index). Juridiquement, ils sont deux objets distincts : un contrat peut céder le code sans céder le schéma de base, ce qui vous laisse propriétaire du logiciel mais dépendant du prestataire pour toute modification de la structure de données. Une clause de cession complète doit mentionner explicitement les deux objets.
Que dois-je recevoir concrètement le jour où je change de prestataire ?
La réversibilité complète comprend six éléments : le code source versionné avec l'historique, la documentation technique à jour (architecture, API, déploiement), l'export des données en format exploitable avec schéma documenté, les scripts de migration et les jeux de test, le transfert des accès et des secrets (clés API, certificats, identifiants), et la formation de l'équipe de reprise. Chaque élément doit être livré dans un format précisé par le contrat, et la livraison doit être datée dans un planning de réversibilité.
Le séquestre de code est-il obligatoire pour protéger mon investissement ?
Non. Le séquestre de code est utile dans les contrats de longue durée ou pour les projets critiques, car il garantit que vous pourrez récupérer le code en cas de faillite du prestataire. Mais il ne remplace pas une clause de cession complète : un séquestre qui contient du code dont vous n'êtes pas propriétaire ne vous autorise pas à le modifier ni à le redistribuer. La protection optimale combine une cession progressive du code (lot par lot) avec un séquestre mis à jour à chaque livraison, et des conditions de levée vérifiables sans négociation.
Comment éviter que le coût de sortie soit facturé au tarif que le prestataire choisit ?
En chiffrant la réversibilité dans le contrat initial, sous la forme d'un forfait de passation inclus dans le prix global ou d'un nombre de jours de support post-livraison. Le contrat doit préciser que les livrables de réversibilité (documentation, scripts, export de données) sont fournis sans surcoût, et il doit prévoir une pénalité en cas de livraison incomplète. Cette pénalité doit être chiffrée, proportionnée au coût de reconstitution de la documentation manquante par le nouveau prestataire, car une pénalité laissée à l'appréciation du juge ne produit souvent aucun effet dissuasif.