Qui héberge votre code n'est pas qui le possède

Deux PME, deux lectures opposées du même geste technique

Une dirigeante refuse de migrer le code de son application vers l'hébergement interne de son prestataire, pourtant gratuit et illimité, et préfère continuer à payer 120 euros par mois pour rester sur une plateforme tierce. Elle justifie ce choix par une phrase qu'on entend souvent sous une forme ou une autre : « le code nous appartient, je préfère que ça reste chez un tiers neutre ». Le détail qui change tout, c'est qu'elle a, dans les deux cas, exactement les mêmes droits d'accès au dépôt. Rien, dans le choix de l'hébergeur, ne renforce ni n'affaiblit sa position.

À l'inverse, une autre entreprise laisse sereinement son prestataire héberger l'intégralité du code sur son infrastructure interne, sans jamais vérifier ce que son contrat dit sur la cession de propriété intellectuelle. Le jour où la relation se tend, elle découvre que rien, dans ses conditions contractuelles, ne lui garantit la propriété du code tant que le dernier acompte n'est pas réglé. Les deux entreprises se trompent de question. L'une s'inquiète d'un détail d'infrastructure qui ne pèse pas sur ses droits, l'autre néglige la seule clause qui les fixe réellement.

Ce que l'hébergement du code change, concrètement, et ce qu'il ne change pas

L'endroit où vit physiquement votre code (un GitLab auto-hébergé chez votre prestataire, une organisation GitHub à votre nom, un serveur interne) détermine qui a la main opérationnelle au quotidien, pas qui possède légalement le résultat. Un prestataire peut vous donner un accès intégral, y compris en lecture et en écriture, à un dépôt qu'il héberge lui-même. Vous pouvez tout aussi bien n'avoir aucun accès réel à un dépôt qui porte votre propre nom d'organisation. L'hébergement est un choix d'infrastructure, réversible en quelques heures par un export standard, pas un acte juridique.

Ce qui compte réellement : la continuité d'accès, pas l'adresse du serveur

La vraie question à poser à votre prestataire n'est donc pas « où est hébergé mon code », c'est « quel accès continu ai-je, aujourd'hui, à une copie à jour de ce dépôt, et à quelle fréquence est-elle synchronisée ». Un accès en lecture permanent, exporté ou répliqué régulièrement sur une infrastructure que vous contrôlez, protège davantage votre continuité d'activité qu'un changement d'hébergeur facturé chaque mois sans y toucher.

Une équipe technique qui attendait depuis plusieurs mois la livraison d'un module confié à un sous-traitant externe en a fait l'expérience à l'envers : le sous-traitant a cessé de répondre, et le projet s'est retrouvé bloqué sans qu'aucun plan de reprise n'ait été préparé en amont. Le constat est venu après coup, trop tard pour éviter plusieurs semaines perdues.

Deux leviers distincts auraient pu limiter ce blocage, et ils ne se confondent pas. Le premier est contractuel : une clause de continuité qui oblige le sous-traitant à fournir, à intervalle régulier, un export exploitable du code produit. Le second est purement opérationnel : un accès en lecture déjà configuré sur le dépôt, qui permet de rapatrier une copie sans attendre l'accord de personne. Le premier protège vos droits en cas de litige prolongé. Le second protège votre continuité d'activité dans les jours qui suivent une rupture. Un projet bien protégé a les deux, pas un seul des deux au hasard de ce que le prestataire a accepté de configurer.

« Ça aurait pris moins de temps de récupérer leur code, de faire un listing des fonctionnalités, de dire ce qu'on veut rajouter, et de vibe coder un truc en deux jours juste pour que ce soit fonctionnel, et de l'héberger de notre côté, que de faire ça. »

Ce constat a posteriori illustre exactement la distinction qui compte : reprendre la main a demandé de récupérer une copie du code et de l'héberger ailleurs, une opération purement opérationnelle, réglable en quelques jours. La propriété légale n'était presque jamais le point de blocage réel sur ce type de situation, l'absence d'accès continu à une copie exploitable l'était.

Ce que dit réellement votre contrat de développement sur mesure

En l'absence d'une clause de cession explicite, le droit d'auteur sur un code reste par défaut la propriété de celui qui l'a écrit, votre prestataire, même si vous avez réglé plusieurs acomptes en cours de projet. C'est une règle de bon sens juridique rarement lue avant signature : payer pour un travail ne transfère pas automatiquement la propriété intellectuelle du résultat, sauf si le contrat l'organise explicitement. Un développeur Leando le formule sans détour face à une cliente convaincue du contraire : le code appartient au prestataire tant qu'il n'est pas payé intégralement, quelle que soit la plateforme sur laquelle il réside.

Le déclencheur de la cession : livraison, recette, ou paiement intégral

Trois déclencheurs possibles coexistent dans les contrats de développement sur mesure, et un seul s'applique chez vous : la cession à la livraison du code, la cession à la validation de la recette fonctionnelle, ou la cession au paiement intégral du projet. Ces trois options ne sont pas équivalentes pour vous. La première vous expose si un dernier paiement traîne après une livraison déjà faite. La troisième protège votre prestataire si vous suspendez un paiement en cours de litige. Aucune n'est universellement la norme, ce qui signifie qu'elle doit être lue, et négociée si besoin, avant de signer, pas découverte en situation de tension.

Deux autres points méritent une lecture attentive dans la même clause. D'abord, la nature exacte de ce qui est cédé : une cession totale de propriété intellectuelle ne se formule pas comme une simple licence d'utilisation, et les deux ouvrent des droits très différents si vous voulez un jour faire évoluer le code par une autre équipe. Ensuite, le sort du code en cas de résiliation anticipée du contrat : sans mention explicite, rien ne garantit que le travail déjà payé jusqu'à l'arrêt du projet vous revienne automatiquement.

Sur un projet de pilote technologique mené avec un sous-traitant industriel, cette même logique de négociation précoce s'applique à l'exclusivité et à la réutilisation d'un composant, pas seulement au code applicatif : plus le résultat devient visiblement précieux, plus la négociation devient difficile et coûteuse. Le bon moment pour fixer ces règles est toujours le même : avant que l'enjeu ne soit connu de tous.

Possédé, pas hébergé : la question à poser avant de changer quoi que ce soit

Avant de refuser ou d'accepter une proposition d'hébergement de votre prestataire, posez une seule question : qu'est-ce que ce changement modifie réellement, mon accès opérationnel ou ma propriété légale ? Si la réponse porte sur l'accès (un export plus simple, une synchronisation plus fréquente, une autonomie technique accrue), discutez-en sur des critères pratiques, fréquence de sauvegarde, format d'export, délai de reprise en cas de rupture. Si la réponse prétend porter sur la propriété, c'est le contrat qu'il faut rouvrir, pas l'hébergeur qu'il faut changer.

Ce principe exclut une erreur symétrique, tout aussi fréquente : croire qu'héberger soi-même son code, sur sa propre organisation GitHub par exemple, suffit à sécuriser sa propriété intellectuelle. Si le contrat sous-jacent n'a jamais organisé la cession, le prestataire garde un droit d'auteur sur le code qu'il a écrit, même s'il vit sur votre infrastructure à vous. L'hébergement donne un sentiment de contrôle qui peut être complètement déconnecté de la réalité juridique, dans un sens comme dans l'autre.

Cette distinction rejoint directement ce que un freelance qui livre du code sans structure laisse souvent de côté : la clarté de ce qui a été contractuellement cédé, et à quel moment précisément, compte autant que la qualité technique du livrable lui-même.

Ce que ce principe ne dispense pas de faire

Clarifier la propriété contractuelle ne remplace pas une vigilance opérationnelle sur votre dépendance réelle à un prestataire, qu'il s'agisse d'un éditeur SaaS qui détient vos données ou d'un développeur sur mesure qui détient votre code. Les deux dépendances se traitent différemment : la première par un audit fonctionnel et un plan de sortie, la seconde par une clause de propriété claire et un accès continu à une copie exploitable. Confondre les deux conduit à négocier le mauvais levier au mauvais moment.

La prochaine fois que votre prestataire vous propose de changer d'hébergeur, ou que vous hésitez à centraliser votre code chez lui pour des raisons de confiance, relisez d'abord la clause de cession de propriété intellectuelle de votre contrat de développement. C'est elle, et non l'adresse du serveur, qui répond à la question que vous vous posez vraiment.