Le code de votre application sur mesure vous appartient-il ? Par défaut en droit belge : non. Il appartient au prestataire qui l'a écrit, sauf clause explicite. Voici ce qu'un contrat sain doit prévoir, et les pièges à éviter.
Par défaut, le code appartient au prestataire
C'est le point qui surprend le plus de clients : en droit belge (et dans une majorité de juridictions européennes), le code source d'une application sur mesure n'est pas automatiquement la propriété de celui qui paye. C'est le développeur, en tant qu'auteur, qui est titulaire des droits patrimoniaux.
La conséquence pratique : sans clause de cession explicite dans le contrat, le client a payé pour une licence d'utilisation, pas pour la propriété. Et la portée de cette licence dépend... du contrat (ou de l'absence de contrat).
Ce qu'un contrat sain doit prévoir
| Clause | Ce qu'elle garantit |
|---|---|
| Cession des droits patrimoniaux | Vous devenez propriétaire du code livré, à titre exclusif et perpétuel. |
| Accès au repository Git | Vous avez le compte GitHub/GitLab principal, pas le prestataire. |
| Transmission de la documentation | README, schéma data, doc déploiement : vous repartez avec tout. |
| Portabilité technique | Stack standard, conventions documentées, autre prestataire peut reprendre. |
| Gestion du code open-source utilisé | Liste des dépendances avec leurs licences (BOM), conformité. |
| Clause de sortie / réversibilité | Modalités de transition en fin de contrat (transmission, formation, garantie). |
Le repository Git : preuve concrète d'accès
Au-delà des clauses juridiques, ce qui compte concrètement c'est l'accès opérationnel au code.
Compte client comme owner
Le repository Git doit être sous votre compte d'entreprise (GitHub Organization ou GitLab Group), pas sous le compte personnel du prestataire. Le prestataire est ajouté comme collaborateur, pas comme owner.
Accès admin permanent
Vous gardez les accès admin tout au long du projet et après. Possibilité de révoquer les accès du prestataire à tout moment sans perdre le code.
Documentation à jour
README expliquant comment lancer le projet, schéma de la base de données, doc déploiement. Sans ça, un autre prestataire ne peut pas reprendre sans des semaines de rétro-ingénierie.
Le cas particulier du no-code
FlutterFlow permet l'export du code Dart (utilisable hors plateforme), ce qui réduit la dépendance. Bubble, Glide, Softr ne le permettent pas vraiment. À considérer dans le choix initial.
Les pièges à éviter
- Contrat sans clause de cession : par défaut, vous n'êtes pas propriétaire. À exiger systématiquement.
- Repository sur compte perso du prestataire : si le prestataire part avec, vous perdez l'accès. À toujours mettre sur votre Organization.
- Hébergement chez le prestataire sans accès : votre app tourne, mais vous ne pouvez pas la déployer ailleurs sans son aide.
- Stack exotique non documentée : framework propriétaire, langage rare, pas de README. Lock-in technique.
- Absence de doc et de tests : même avec accès au code, un autre prestataire ne peut pas reprendre sans investir des semaines de rétro-ingénierie.
Pour discuter de la structure du contrat avant signature, prévoyez un premier appel. Voir aussi Applications & SaaS.
Questions fréquentes
Si le contrat ne dit rien sur la propriété du code, qui en est titulaire ?
Par défaut en droit belge, le développeur prestataire reste titulaire des droits patrimoniaux sur le code. Le client a une licence d'utilisation (implicite ou explicite), mais pas la propriété. C'est pour ça que la cession doit être écrite : sans clause, vous avez payé l'utilisation, pas la propriété.
Comment formuler la clause de cession ?
Une formulation type : « Le prestataire cède au client l'ensemble des droits patrimoniaux sur le code livré, à titre exclusif et pour toute la durée légale, dans le monde entier, pour tous usages. » À adapter selon le contexte. Un juriste peut affiner.
Et le code open-source utilisé dans l'app ?
Le code open-source reste sous sa licence (MIT, Apache, GPL, etc.). Le prestataire ne peut pas vous le « céder » au sens strict. Il doit simplement respecter les licences. Pour les licences permissives (MIT, Apache) : aucun problème pour usage commercial. Pour GPL : attention, contraintes de libération du code dérivé.
Et si je veux changer de prestataire après la livraison ?
Possible si trois conditions sont réunies : (1) vous êtes propriétaire du code (clause de cession), (2) vous avez accès complet au repository (compte client, pas prestataire), (3) la stack est standard (pas exotique) avec une doc minimale. Le contrat de livraison doit garantir ces points pour éviter tout lock-in.