Application Métier

Propriété du code : rester libre après la signature

Payer un développement ne transfère pas les droits : c'est la clause écrite qui décide de ce qui vous appartient. Nous listons les sept pièces à exiger avant de signer — dépôt de code, base, sauvegardes, nom de domaine, hébergement, documentation, comptes de service —, ce qu'une plateforme en abonnement ne remettra jamais, et comment vérifier tout cela en une réunion, sans être technique.

InnoTech-IT14 octobre 20269 min de lecture
Michael AGNASSIA

InnoTech-IT

Fondateur & Lead Developer @ InnoTech-IT

Expert en solutions digitales pour les TPE et PME. Développement full-stack, IA & applications web.

Propriété du code : rester libre après la signature

Vous avez payé pour un outil, et le jour où vous voulez changer de partenaire, vous découvrez que le code est chez lui, le domaine à son nom et la base dans un abonnement que vous ne pouvez pas emporter. C'est la situation que nous voyons le plus souvent dans les PME d'Île-de-France : un engagement de plusieurs années, des factures payées sans discussion, et aucune pièce en main le jour où il faut décider.

Réponse courte : la propriété du code ne se constate pas à la livraison, elle se décide au contrat. Ce qui doit vous être remis — dépôt de code, base de données, sauvegardes, nom de domaine, hébergement, documentation, comptes de service — s'écrit noir sur blanc avant la signature, à votre nom. Ce qui n'y figure pas ne se réclame pas après coup.

TL;DR

  • Payer un développement ne transfère pas les droits : c'est la clause écrite, et elle seule, qui dit ce qui vous appartient.
  • Sept éléments se remettent, et ils se nomment un par un : dépôt de code, base, sauvegardes, domaine, hébergement, documentation, comptes de service.
  • Une plateforme en abonnement vous loue un usage ; elle ne vous remet ni le code, ni l'exploitation de la base qui fait vivre votre activité.
  • Le tout se vérifie avant de signer, en une réunion : demandez la liste écrite, puis regardez à quel nom sont les comptes.

Le jour où vous arrêtez, il ne reste que ce que vous avez en main

Une PME ne change pas d'outil tous les ans : un outil métier ne vaut rien tant que les équipes ne l'ont pas adopté, et il coûte cher à remplacer. Le prestataire, lui, peut changer avant vous — arrêt d'activité, rachat, sous-traitance en cascade.

Ce qui survit à ce changement n'est ni la relation, ni la bonne volonté, mais ce qui est établi à votre nom. Deux questions suffisent à savoir où vous en êtes : à quel nom est enregistré votre nom de domaine, et sous quel compte est hébergé ce qui fait tourner votre outil ? Si la réponse est « chez nous » ou « sous notre compte », vous n'êtes pas propriétaire d'un actif, vous êtes locataire d'un service.

Un outil dont vous détenez ce que nous remettons quand nous développons une application métier se transmet, se revend et se reprend en main ; un outil dont personne ne peut reprendre le code vous oblige à racheter ce que vous avez déjà payé.

Propriété du code : deux personnages stylisés portent ensemble une caisse ouverte d'où sortent un boîtier et une liasse, une clé orange tenue par une troisième personne devant un atelier parisien clair — la remise des pièces, caisse par caisse

Un droit qu'on vous laisse utiliser n'est pas un droit qui vous appartient

Le premier malentendu tient en une phrase : la facture payée donne l'impression que tout est réglé. L'INPI le rappelle sans détour, le code source est une œuvre protégée par le droit d'auteur. Le code n'est donc pas une marchandise qui change de main avec le paiement : ce sont les droits cédés qui décident de ce que vous pouvez en faire.

Trois usages se confondent dans la plupart des devis. Utiliser l'outil : une licence suffit. Le faire évoluer : cela suppose d'avoir le code, de pouvoir le modifier et de le confier à quelqu'un d'autre. Le revendre, ou l'adosser à un projet que vous cédez : c'est un troisième droit, distinct des deux premiers. Un devis qui promet « la livraison de l'application » sans nommer ces droits ne vous donne ni le deuxième ni le troisième.

Nous posons donc la question par écrit : le client détient le code, le droit de le faire modifier par qui il veut, et rien ne reste en notre possession. Le jour où vous cédez l'entreprise ou récupérez la production en interne, cette clause devient la pièce la plus utile du dossier.

Ce qui doit être listé au contrat, et à quel nom

Une liste se vérifie ; une promesse ne se vérifie pas. Voilà les sept éléments à faire figurer, chacun avec son titulaire et sa procédure de remise, avant la première ligne de code.

  • Le dépôt de code, avec son historique de versions. Une archive posée sur un disque à la livraison ne dit ni comment l'outil a été construit, ni quels arbitrages ont été faits.
  • La base de données : un export complet, structure et données, et la procédure de restauration écrite. Sans la procédure, un export est un fichier, pas une sauvegarde.
  • Les sauvegardes : à quelle fréquence elles tournent, où elles sont stockées, qui peut lancer une restauration et en combien de temps.
  • Le nom de domaine, enregistré au nom de l'entreprise. Un domaine au nom du prestataire est le verrou le plus facile à poser et le plus difficile à faire sauter.
  • L'hébergement : un compte à votre nom, une facturation à votre adresse, un accès administrateur pour vos équipes. Sinon, votre activité dépend d'une carte bancaire qui n'est pas la vôtre.
  • La documentation : schéma d'architecture, accès, procédures d'exploitation, comptes rendus de recette. C'est elle qui rend votre outil reprenable par une autre équipe que la nôtre.
  • Les comptes de service : encaissement, signature électronique, envoi d'e-mails, stockage de fichiers, mesure d'audience et les interfaces par lesquelles votre outil parle à d'autres. À créer à votre nom dès le premier jour.

Une restitution n'est utile que si elle est exploitable ailleurs — c'est le repère que la CNIL donne pour les données personnelles avec le droit de recevoir ses données dans un format structuré, couramment utilisé et lisible par machine. Même exigence pour les échanges entre vos outils, une fois documentés : une donnée que vous ne pouvez pas sortir n'est pas vraiment la vôtre.

Propriété du code : personnage stylisé en train de signer une grande feuille sur une table d'atelier, une deuxième personne désigne une pile de dossiers et un trousseau de clés orange suspendu au mur derrière eux — ce qui s'écrit et ce qui se remet

Ce qu'une plateforme en abonnement ne vous remettra jamais

Rien n'interdit de travailler avec un outil que l'on loue. Le problème n'est pas le modèle, c'est ce que vous en attendez. Dans un abonnement, ce que vous payez est un usage, pas un actif : l'outil tourne sur l'infrastructure de son éditeur, les données vivent dans sa base, l'évolution se décide dans sa feuille de route, et « votre outil » est une configuration posée sur le sien.

Ce qui ne se remet pas dans ce modèle est facile à nommer. Le code, d'abord : il n'existe pas chez vous. Le schéma de données ensuite : vous exportez des objets métier, pas la structure qui permet de reconstruire un raisonnement. La logique enfin : vos règles particulières vivent dans des écrans que vous ne possédez pas. Vous pouvez quitter un abonnement ; vous ne pouvez pas emporter l'outil.

Cette asymétrie est connue du législateur européen, qui encadre le passage d'un fournisseur de services à un autre pour éviter les sorties impossibles. C'est un progrès réel, mais il ne décide pas à votre place ce que vous voulez posséder.

Ce que nous remettons systématiquement, et où c'est écrit

Une exigence que nous n'appliquons pas nous-mêmes ne vaut rien. Ce que nous livrons est publié, donc vérifiable avant de nous confier quoi que ce soit : le dépôt avec son historique, un accès complet aux comptes tiers configurés pour le projet, l'export de la base et la documentation d'architecture — sans négociation au cas par cas.

Nos conditions sont écrites au même endroit que nos prix : la propriété du code et des contenus y a sa réponse, et elle vaut pour un site comme pour une application métier. Six mois de maintenance sont inclus dans chaque forfait, puis les niveaux mensuels s'arrêtent quand vous le décidez, sans engagement de durée. Il n'y a donc pas de clause de sortie à négocier : la grille publiée, avec ses forfaits de suivi mensuel.

Nous ne sommes pas les seuls à pouvoir faire ce travail, et c'est exactement l'idée. Un outil qui vous appartient se confie à une autre équipe, se reprend en interne, s'audite : l'exploitation et les sauvegardes que nous assurons ensuite ne sont pas une prise d'otage, ce sont des services que vous pouvez arrêter. C'est ce que montrent les mises en service dont nous publions le détail : ce qui reste au client n'est pas une promesse, c'est un dossier qu'il ouvre sans nous.

Propriété du code : trois personnages stylisés dans un atelier parisien lumineux remettent une caisse de matériel, un rouleau de plans et une clé orange à une cliente qui tend les mains — ce qui est remis le jour de la livraison

Comment vérifier tout ça en une réunion, sans être technique

Aucune compétence technique n'est nécessaire pour départager deux prestataires ici. Quatre questions suffisent, et la manière dont elles sont reçues dit déjà beaucoup : à quel nom est enregistré le nom de domaine ? Où est le dépôt de code, et peut-on en obtenir un accès en lecture dès maintenant ? Qui peut restaurer une sauvegarde, et en combien de temps ? Que se passe-t-il le jour où l'on veut partir, et que récupère-t-on précisément ?

Un prestataire qui travaille proprement répond en quelques minutes, parfois en partageant son écran. Un prestataire qui doit vérifier, temporiser ou promettre un document « la semaine prochaine » a déjà donné sa réponse : celui qui écrit votre code sait où il l'héberge et comment une sauvegarde se restaure.

Ce que vous payez construit un actif, ou vous louez un service

La question qui porte le plus loin : ce qu'une entreprise paie, elle le paie pour construire quoi ? Si la réponse est « un outil que vous pourrez confier à n'importe qui », vous achetez un actif et le prestataire devient remplaçable. Si la réponse est « un service que nous exploitons pour vous », vous louez — un choix défendable, à condition d'avoir décidé que c'était le vôtre et de garder la main sur les données qui font vivre l'entreprise.

Propriété du code : deux personnages stylisés autour d'un bureau, l'un tenant une liste à cases cochées et l'autre montrant du doigt un casier à clés orange fixé au mur, plantes et fenêtre sur une cour parisienne — les questions à poser avant de signer

Vous parlez directement à ceux qui codent, du cadrage au déploiement. Vos données et votre base restent sur votre infrastructure, pas chez un SaaS étranger. Le devis écrit tient le périmètre, et nous restons après la mise en ligne.

Si vous voulez savoir ce que vous détenez réellement aujourd'hui, prenez un rendez-vous en visio de 15 minutes et décrivez la situation : qui héberge, à quel nom, et ce que vous pouvez récupérer sans demander la permission. Si l'écrit vous convient mieux, décrivez-nous ce que votre contrat autorise aujourd'hui et nous vous dirons ce qui manque.

Questions fréquentes sur la propriété du code

Qui est propriétaire du code d'une application sur mesure ?

Celui à qui les droits ont été cédés par écrit. Le code étant protégé par le droit d'auteur, la facture ne suffit pas : c'est la clause qui nomme les droits transmis qui décide. Notre réponse tient en une ligne : le client détient le code, la documentation et les accès.

Que faut-il exiger dans un devis avant de signer ?

Une liste nominative, pas une intention. Le dépôt de code et son historique, l'export de la base avec sa procédure de restauration, le nom de domaine et l'hébergement au nom de l'entreprise, la documentation d'architecture, et les comptes de service créés pour vous. Ce qui manque à cette liste manquera le jour du départ.

Peut-on récupérer ses données en quittant une plateforme en abonnement ?

Les données personnelles, oui : la portabilité prévoit une restitution dans un format exploitable. Le reste dépend du contrat. Ce qui revient rarement, ce sont les règles métier configurées dans les écrans et la structure qui permet de les rejouer ailleurs. Exportez, et vérifiez que le contenu obtenu suffit à relancer l'activité.

À quel nom doivent être le nom de domaine et l'hébergement ?

Au nom de l'entreprise cliente, avec un accès administrateur pour ses équipes et une facturation à son adresse. C'est la garantie la plus simple à obtenir et la plus utile : elle vous protège d'une disparition de prestataire et de toute négociation forcée au moment de partir.

Comment vérifier la propriété du code chez un prestataire déjà en place ?

Demandez trois choses par écrit : l'emplacement du dépôt avec un accès en lecture, l'inventaire des comptes de service et de leur titulaire, la procédure de restauration d'une sauvegarde. Un prestataire organisé fournit cela en quelques jours. S'il refuse ou repousse, considérez que le code n'est pas encore à vous.

Cet article n'a pas de lead magnet configuré.

Mots-clés

propriété du code, code source, réversibilité, dépôt de code, dépendance au prestataire

Prêt à démarrer ?

Découvrez notre processus complet avant de lancer votre projet.

Voir notre processusDemander un devis