« On a payé la facture, donc le site nous appartient. » Cette phrase, on l'entend au moins une fois par mois dans les réunions de reprise de projet. Et à chaque fois, il faut expliquer la même chose : en droit français, régler une prestation ne transfère aucun droit d'auteur. Rien. Le virement bancaire achète un travail, pas un patrimoine immatériel.
Le problème dépasse largement la question juridique. Un client peut détenir une cession de droits impeccable, signée, tamponnée, et se retrouver totalement paralysé parce que le dépôt Git vit sur le compte GitHub de l'agence, que les clés d'API sont dans la tête d'un développeur parti en freelance, et que personne n'a jamais documenté la procédure de déploiement. Propriétaire sur le papier, prisonnier dans les faits.
Trois plans se superposent et il faut les traiter séparément : le code écrit spécifiquement pour vous, les briques tierces sous licence, et les accès techniques. La vraie question n'est pas « à qui appartient ce code ? » mais plutôt : demain matin, sans votre prestataire actuel, êtes-vous capable de faire évoluer votre outil ?
Le principe juridique que la plupart des contrats passent sous silence
L'article L. 111-1 du Code de la propriété intellectuelle pose une règle simple. L'auteur d'une œuvre de l'esprit, et un logiciel en est une, détient les droits sur celle-ci du seul fait de sa création. Pas besoin de dépôt, pas besoin de formalité. Le développeur qui tape la première ligne devient titulaire.
Une exception existe : l'article L. 113-9 prévoit que les droits sur un logiciel créé par un salarié dans l'exercice de ses fonctions sont automatiquement dévolus à son employeur. Voilà pourquoi une équipe interne ne pose pas de difficulté particulière.
Mais cette dévolution automatique ne joue ni pour le prestataire indépendant, ni pour l'agence. Zéro. Le freelance qui développe votre plateforme en reste titulaire tant qu'un écrit ne dit pas le contraire.
Payer une prestation n'est pas acheter des droits
Deux contrats radicalement différents cohabitent dans l'esprit des clients, et c'est là que naît la confusion.
Le contrat de prestation de services crée une obligation de faire : le prestataire s'engage à développer, livrer, tester. Il exécute une mission. Le contrat de cession de droits, lui, organise un transfert de patrimoine : des prérogatives quittent le patrimoine de l'auteur pour rejoindre celui du client. Ce sont deux objets juridiques distincts, et régler le premier ne déclenche pas le second.
Sans clause de cession écrite, quelle est votre situation réelle ? Vous bénéficiez au mieux d'un droit d'usage implicite, déduit de l'économie du contrat. Vous pouvez exploiter le site pour l'usage prévu. Vous ne pouvez ni le modifier, ni l'adapter, ni le confier à un tiers pour qu'il le fasse évoluer, ni le revendre. Le jour où vous changez d'agence, la nouvelle équipe intervient techniquement sur un code dont elle n'a pas le droit de produire une œuvre dérivée.
Le formalisme exigé par la loi
Une cession valable ne s'improvise pas en une ligne. Le Code impose que l'acte mentionne, à peine de nullité, chaque droit cédé de façon distincte : reproduction, représentation, adaptation, traduction, mise sur le marché. Chacun doit être nommé. Une énumération globale ne suffit pas.
S'ajoutent trois délimitations obligatoires. L'étendue de l'exploitation, sa destination, le territoire concerné, et la durée de la cession. Un contrat qui reste muet sur le territoire ou la durée fragilise le transfert.
D'où le piège des formules lapidaires qu'on croise partout : « le client est propriétaire des livrables », « la propriété des développements est transférée au client à réception ». Ces clauses rassurent en lecture rapide. Devant un tribunal, elles offrent une prise sérieuse à qui voudrait les contester, faute d'énumération et de délimitation. Une phrase de dix mots ne remplace pas un article de cession correctement rédigé.
Le droit moral, incessible
Voici la précision qui surprend systématiquement. Même après une cession totale, l'auteur conserve son droit moral, et notamment son droit à la paternité. Ce droit est perpétuel, inaliénable, imprescriptible. Aucune clause ne l'efface.
Concrètement ? Les mentions d'auteur dans les en-têtes de fichiers relèvent de ce droit et supprimer massivement ces commentaires expose théoriquement à une contestation. En revanche, le crédit visible en pied de page du site public, du type « réalisation : agence X », relève de la négociation commerciale pure. Il se retire, il se conserve, il se monnaie. Beaucoup de contrats l'imposent pendant douze ou vingt-quatre mois en contrepartie d'une remise. À négocier au devis, pas après.
Ce que recouvre concrètement « le code source »
Parler du « code source » comme d'un bloc homogène est la première erreur d'analyse. Ce qu'on livre à la fin d'un projet est un assemblage de couches aux statuts juridiques incompatibles entre eux.
Le code spécifique développé pour vous
C'est la seule partie réellement cessible en exclusivité. Elle regroupe la logique métier propre à votre activité, les modèles de données, les intégrations sur mesure avec votre ERP ou votre CRM, les feuilles de style, les gabarits produits pour votre identité visuelle, les scripts d'import spécifiques.
Sur un projet type, cette couche représente souvent moins de la moitié du volume total. Parfois beaucoup moins.
Le socle réutilisable du prestataire
Point de friction majeur, et généralement le plus mal anticipé. La plupart des agences ne repartent pas de zéro à chaque projet. Elles ont construit au fil des années un framework interne, une bibliothèque de composants, un starter kit, des modules d'authentification, une couche d'administration maison. Ce socle est réutilisé d'un client à l'autre : il constitue leur outil de production.
Exiger la cession exclusive de ce socle revient à demander à un menuisier de vous vendre son atelier avec la table. Aucune agence sérieuse n'acceptera, et celle qui accepte devrait vous inquiéter, car elle vend le même socle en exclusivité à trois autres clients.
La solution réaliste tient en une formule à faire figurer dès le devis : licence perpétuelle, non exclusive, transférable, incluant le droit de modification. Décryptons. « Perpétuelle » signifie qu'elle ne s'éteint pas à la fin du contrat. « Non exclusive » reconnaît que l'agence continue de l'exploiter ailleurs, ce qui est légitime. « Transférable » vous autorise à la céder si vous vendez votre société, point critique en cas de rachat. Et le droit de modification vous permet de faire intervenir un autre prestataire dessus, ce qui est tout l'enjeu.
Sans ces quatre qualificatifs, la licence peut se révéler inutilisable au pire moment.
Les dépendances open source
Cette couche échappe à tout le monde. Ni le prestataire ni le client ne « possèdent » les bibliothèques open source intégrées au projet : elles demeurent la propriété de leurs auteurs respectifs et restent régies par leur licence d'origine.
Ce que vous détenez, c'est un droit d'usage, dans les conditions fixées par ces licences. Rien de plus, mais rien de moins non plus, et ces conditions méritent qu'on s'y arrête.
Les briques propriétaires et les SaaS
Thèmes achetés sur une marketplace, extensions premium, composants sous licence commerciale, API tierces facturées à l'usage : chacun a ses règles.
La distinction déterminante oppose les licences nominatives, souscrites au nom de l'agence, aux licences transférables ou souscrites directement au nom du client. Le scénario classique se répète des dizaines de fois par an : l'agence achète un thème premium avec sa licence développeur multi-sites, l'installe chez vous, la relation prend fin, et six mois plus tard les mises à jour de sécurité cessent d'arriver parce que votre installation n'est plus rattachée à une licence active. Le site fonctionne, jusqu'à la première faille non corrigée.
Même logique pour les abonnements SaaS. Un outil de recherche, une passerelle de paiement, un service d'envoi d'e-mails : si le compte est au nom de l'agence, l'API key qui fait tourner votre production dépend d'un contrat auquel vous êtes étranger.
L'angle mort des licences open source
Aucun projet moderne ne se construit sans dépendances open source. Une application web contemporaine en embarque couramment plusieurs centaines, dépendances indirectes comprises. La question n'est donc jamais « faut-il en utiliser ? » mais « lesquelles, et sous quelles conditions ? ».
Permissives contre copyleft : la distinction qui engage votre business
Deux familles s'opposent.
Les licences permissives, MIT, Apache 2.0, BSD, autorisent l'usage, la modification et la redistribution, y compris dans un produit propriétaire et commercial, sous réserve de conserver la mention d'attribution et le texte de la licence. Elles ne contaminent rien. Ce sont les plus confortables pour un usage commercial.
Les licences copyleft, GPL en tête, imposent que toute œuvre dérivée soit redistribuée sous la même licence, code source inclus. La LGPL assouplit le mécanisme pour les bibliothèques liées dynamiquement, ce qui change beaucoup de choses en pratique.
L'AGPL mérite un traitement à part, et c'est probablement le piège le plus sous-estimé du secteur. Là où la GPL déclenche son obligation lors de la distribution du logiciel, l'AGPL la déclenche par la simple mise à disposition en ligne. Vous n'avez rien distribué ? Peu importe. Vos utilisateurs accèdent au service via un navigateur, et l'obligation s'active. Pour un SaaS, une bibliothèque AGPL enfouie dans le back-end peut théoriquement obliger à publier le code source de toute la plateforme. Ce genre de découverte se fait rarement au bon moment.
La contamination : quand une dépendance impose sa licence à tout votre produit
Prenons un cas concret, du genre qu'on voit émerger pendant les audits.
Une entreprise fait développer une plateforme métier qu'elle compte commercialiser en marque blanche auprès de son réseau de franchisés. Le développement se passe bien, le produit tourne. Deux ans plus tard, un fonds entre au capital et lance une due diligence technique. L'audit révèle qu'une bibliothèque de génération de rapports, publiée sous GPL, a été intégrée au cœur du moteur applicatif.
Les options sont toutes coûteuses. Réécrire le module concerné, ce qui suppose de le retrouver, de l'isoler et de refaire le travail. Acquérir une licence commerciale auprès de l'éditeur, quand celui-ci propose un double licensing, ce qui n'est pas systématique. Ou publier le code source du produit, ce qui anéantit le modèle de commercialisation.
Dans un contexte de levée de fonds ou de cession d'entreprise, ce type de découverte ne se contente pas de coûter cher. Il décale le calendrier, entame la confiance et pèse sur la valorisation.
Le brevet caché d'Apache 2.0
Nuance que peu de prestataires abordent spontanément, et qui a pourtant son poids sur les projets à composante technique forte.
Apache 2.0 comporte une clause de licence de brevet explicite : les contributeurs concèdent aux utilisateurs une licence sur les brevets qu'ils détiendraient et que couvre leur contribution. Cette protection est absente de MIT, qui reste silencieuse sur le sujet.
Le mécanisme est assorti d'une contrepartie. Si vous engagez une action en contrefaçon de brevet contre un contributeur au titre du logiciel, votre licence de brevet s'éteint automatiquement. Autrement dit, Apache 2.0 offre une couverture réelle en échange d'une forme de non-agression. Sur un produit qui touche à des technologies brevetables, cette différence entre MIT et Apache 2.0 vaut plus qu'une ligne dans un tableau comparatif.
Exiger un inventaire de licences
Comment savoir ce que contient réellement votre application ? En demandant un SBOM, pour Software Bill of Materials, c'est-à-dire la nomenclature logicielle du projet.
Le principe est emprunté à l'industrie : de même qu'un constructeur connaît chaque pièce de ses véhicules, un éditeur doit connaître chaque composant de son logiciel. Le document liste les dépendances, leurs versions, leurs licences et leurs relations. Des formats standardisés existent, SPDX et CycloneDX, et les outils qui les génèrent sont largement disponibles et automatisables dans une chaîne d'intégration continue.
Le conseil opérationnel tient en une phrase : faites de la remise de cet inventaire une condition de recette du projet, au même titre que la documentation technique. Cela coûte quelques heures au prestataire. Cela vous évite de découvrir une AGPL trois ans plus tard, dans une salle de réunion, face à un avocat qui la découvre en même temps que vous.
Le dépôt Git : là où se joue la propriété réelle
Passons du droit à la pratique, parce que c'est ici que la plupart des reprises de projet déraillent.
Posséder le code sans posséder l'historique
Recevoir une archive ZIP contenant le code à la livraison n'équivaut pas à récupérer un dépôt Git complet. La différence paraît technique. Elle est structurante.
L'historique des commits, ce n'est pas de l'archivage sentimental. C'est la mémoire du projet. Chaque commit raconte une décision : pourquoi cette fonction contourne le comportement standard, quel bug a justifié ce correctif étrange, quelle contrainte client a imposé cette exception dans le calcul des remises. Un développeur qui reprend un projet passe une part considérable de son temps à comprendre l'intention derrière le code. L'historique lui répond.
Il permet aussi des choses très concrètes. Revenir en arrière proprement après une régression. Identifier par bissection le changement exact qui a cassé une fonctionnalité, en quelques minutes plutôt qu'en deux jours. Comprendre l'ordre des migrations de base de données. Voir qui a écrit quoi, et à quelle période.
Sans historique, le prochain prestataire hérite d'une photographie figée, sans contexte. Il redécouvrira tout, à vos frais, et il commencera par surestimer le budget de reprise, parce que c'est la seule attitude raisonnable devant une base opaque.
Sur quel compte vit votre dépôt ?
Trois configurations, trois niveaux de risque très différents.
Premier cas : le dépôt est hébergé sur l'organisation GitHub ou GitLab du prestataire, et vous disposez d'un accès en lecture. Cela paraît satisfaisant au quotidien. Sauf que cet accès est révocable d'un clic, et qu'il l'est effectivement le jour où la relation se tend. Un litige sur une facture, et vous perdez la visibilité sur votre propre code.
Deuxième cas : le dépôt vit sur votre organisation, sous votre compte de facturation, et le prestataire y figure comme collaborateur. C'est la configuration saine. Vous administrez les droits, vous gardez la main sur les branches protégées, et la fin de la relation se traduit par un simple retrait d'accès. Cette organisation ne coûte quasiment rien à mettre en place au démarrage du projet. Elle devient une négociation pénible si on l'aborde à la fin.
Troisième cas : le dépôt n'existe que sur le poste du développeur, sans hébergement distant, ou sur un compte personnel gratuit. Situation critique, plus fréquente qu'on ne l'imagine sur les petits projets. Un disque dur qui lâche, un freelance injoignable, et le code source disparaît. Littéralement.
Ce qui ne se trouve pas dans le dépôt
Voilà le point qu'on traite le plus rarement, et qui bloque le plus souvent les reprises.
Un dépôt Git bien tenu exclut délibérément un ensemble d'éléments sensibles, et c'est une bonne pratique de sécurité. Les fichiers d'environnement contenant la configuration de production. Les clés d'API des services tiers. Les certificats et les paires de clés SSH. Les variables secrètes stockées dans le pipeline d'intégration continue. Les identifiants de connexion à la base de données.
S'y ajoutent des éléments moins évidents mais tout aussi bloquants : les scripts de déploiement s'ils vivent sur un serveur d'orchestration, la configuration du serveur web, les tâches planifiées, les jeux de données de référence indispensables au fonctionnement.
Récupérer un dépôt complet, avec tout son historique, sans ces éléments, revient à recevoir les plans d'un bâtiment sans les clés ni le compteur électrique. Le contenu est là. L'immeuble ne s'ouvre pas.
La transmission de ces secrets doit passer par un canal sécurisé, gestionnaire de mots de passe partagé ou coffre-fort applicatif, jamais par e-mail ni par messagerie instantanée. Et elle doit s'accompagner d'une rotation : les clés connues d'une équipe qui quitte le projet se régénèrent.
Vérifier avant de payer le solde
Il existe un test unique qui résume tous les autres, et il devrait figurer dans chaque procès-verbal de recette.
Faites cloner le dépôt sur une machine vierge, par une personne extérieure au projet, et demandez-lui d'obtenir une application fonctionnelle en suivant uniquement le fichier README. Sans appeler le développeur. Sans poser de question.
Si l'opération réussit en quelques heures, votre livraison est complète. Si elle échoue, si elle nécessite trois appels téléphoniques et un fichier envoyé en urgence, alors la livraison est incomplète, quelle que soit la qualité du code par ailleurs. Cette vérification coûte une demi-journée de prestation externe. Elle se négocie infiniment mieux avant le versement du solde qu'après.
Les accès et les comptes : la propriété qui n'est pas du code
On peut détenir la totalité du code source et rester incapable de mettre son site en ligne. Cette partie de la propriété ne s'écrit pas en lignes de programmation.
Cartographier les titulaires
L'exercice prend une heure et évite des semaines de blocage. Établissez la liste de tout ce qui porte un nom de titulaire.
Le nom de domaine et le compte chez le bureau d'enregistrement. L'hébergement et son contrat. La gestion de la zone DNS, qui n'est pas forcément chez l'hébergeur. Les certificats TLS. Les comptes Google Analytics et Search Console. Le gestionnaire de balises. Les régies publicitaires et leurs moyens de paiement. Les services tiers payants : paiement en ligne, envoi transactionnel, moteur de recherche, stockage objet, service de cartographie. Les boîtes mail et le service de messagerie. Les comptes de la chaîne de développement, dépôt et intégration continue.
Pour chaque ligne, une seule question : qui est le titulaire du compte, et qui paie ?
Le réflexe à installer dès le premier jour : chaque compte est créé au nom de votre entreprise, avec une adresse e-mail générique qui ne dépend d'aucune personne physique, et le prestataire y est ajouté comme utilisateur avec les droits nécessaires. Pas l'inverse. Ce n'est ni une marque de défiance ni une lourdeur administrative, c'est simplement la bonne configuration, et un prestataire expérimenté la proposera de lui-même.
Le cas du nom de domaine déposé par l'agence
Le cas reste courant, souvent par commodité au démarrage : l'agence dépose le domaine sur son propre compte pour aller vite, et personne n'y revient jamais.
Tant que tout va bien, aucune conséquence. En cas de rupture, le domaine devient un point de blocage total. Il porte le site, les adresses e-mail, l'historique de référencement, la reconnaissance de vos clients. Sans lui, il n'y a rien à reprendre.
Le transfert obéit à une procédure encadrée. Le titulaire actuel doit déverrouiller le domaine chez son bureau d'enregistrement et fournir le code d'authentification, souvent appelé auth code ou code de transfert. Le nouveau bureau d'enregistrement initie ensuite le transfert, qui se valide en quelques jours selon l'extension. Point à connaître : un domaine transféré est généralement bloqué pour un nouveau transfert pendant soixante jours, et un domaine dont le titulaire vient de changer peut l'être également. Ces délais s'anticipent, surtout si le domaine arrive à échéance.
Si le domaine est déjà chez le prestataire, la modification du titulaire se demande maintenant, pendant que la relation est bonne. Pas au moment de la rupture, où elle se transforme en levier de négociation.
La documentation comme livrable contractuel
Un projet correctement documenté comporte au minimum : une description de l'architecture technique et des flux entre composants, la justification des choix structurants, la procédure d'installation en environnement de développement, la procédure de déploiement en production et la marche à suivre en cas de retour arrière, la description des tâches planifiées, et un journal des décisions importantes.
Cette documentation n'est pas un supplément d'âme. Sans elle, la propriété du code reste théorique : vous détenez un actif que personne ne sait remettre en route dans un délai raisonnable. Elle se contractualise comme un livrable à part entière, avec son propre critère de recette.
Ce qu'il faut écrire noir sur blanc dans le contrat
La clause de cession et son déclencheur
Recommandation qui protège les deux parties : conditionner le transfert des droits au paiement intégral du prix. Le prestataire conserve un levier légitime face aux impayés, et le client obtient une date de transfert claire et vérifiable.
Le contrat doit aussi prévoir l'hypothèse que personne n'aime évoquer au moment de la signature : que devient le code si le projet s'arrête en cours de route ? Abandon par le client, résiliation anticipée, défaillance du prestataire. Sans clause, le travail déjà payé reste dans les limbes juridiques, et vous financez un développement inexploitable. La rédaction usuelle prévoit une cession au prorata des sommes versées, avec remise de l'état d'avancement du code et de sa documentation.
Le périmètre exclusivité contre licence
Un tableau vaut mieux qu'un paragraphe. Annexez au contrat une liste des composants du projet, avec pour chaque ligne le régime applicable.
Cession exclusive pour le code spécifique. Licence perpétuelle, non exclusive, transférable, avec droit de modification pour le socle réutilisable du prestataire. Licence tierce non maîtrisée, avec mention de la licence exacte, pour les dépendances open source et les composants commerciaux.
Cette annexe force une conversation utile au moment du devis. Et elle rend visible, avant signature, la proportion du projet qui n'appartiendra jamais complètement à personne.
La clause de réversibilité
La clause qui manque presque partout, alors qu'elle est la plus protectrice.
Elle organise la fin de la relation, quelle qu'en soit la cause. Son contenu type : le délai de mise à disposition des livrables après la fin du contrat, quinze ou trente jours calendaires par exemple ; le format exact des remises, dépôt Git complet avec historique, dump de base de données, secrets par canal sécurisé, documentation à jour ; le volume d'accompagnement à la reprise, en nombre de jours d'assistance au prestataire entrant ; la procédure de transfert des comptes et des domaines ; et la durée pendant laquelle le prestataire sortant reste joignable pour des questions ponctuelles.
Le point décisif : chiffrez ces éléments dans le contrat initial. Un délai et un volume de jours négociés à froid coûtent une ligne de devis. Négociés le jour de la rupture, dans un climat dégradé, ils coûtent beaucoup plus, et parfois ils ne s'obtiennent pas du tout.
L'entiercement pour les projets critiques
Pour les applications dont dépend directement l'activité, il existe un dispositif plus robuste : l'entiercement, ou dépôt du code chez un tiers de confiance. L'Agence pour la protection des programmes est l'organisme de référence en France, et des acteurs privés proposent des services comparables.
Le principe : le prestataire dépose périodiquement le code source et sa documentation auprès du tiers, qui les conserve sous scellés. Le client n'y accède que si un événement prévu au contrat se réalise. Cessation d'activité du prestataire, procédure collective, manquement caractérisé à l'obligation de maintenance après mise en demeure restée sans effet.
Le dispositif a un coût, en frais annuels et en discipline de dépôt. Il se justifie quand l'arrêt de l'application menacerait sérieusement l'exploitation, typiquement une plateforme métier, un outil de production, une application avec des utilisateurs finaux payants. Pour un site vitrine de douze pages, c'est disproportionné. Le bon critère n'est pas le budget du projet mais le coût d'une indisponibilité prolongée.
Le sort des données
Dernier volet, souvent oublié parce qu'il ne concerne pas le code : vos données.
Le contrat doit préciser le format d'export disponible, sa complétude, et le délai de mise à disposition. Un export partiel, ou dans un format propriétaire illisible ailleurs, revient à ne pas restituer.
S'y ajoutent les obligations du RGPD. Lorsque le prestataire traite des données personnelles pour votre compte, il agit comme sous-traitant au sens de l'article 28, et un contrat de sous-traitance doit encadrer la relation. Ce texte prévoit qu'au terme de la prestation, le sous-traitant restitue ou supprime les données, selon votre choix, et détruit les copies existantes. La suppression se documente : demandez une attestation. Elle vous sera utile le jour d'un contrôle.
Votre check-list de vérification avant la recette finale
À passer en revue avant de signer le procès-verbal et de régler le solde. Chaque point se répond par oui ou par non, sans nuance.
- Une clause de cession explicite, détaillant les droits cédés, l'étendue, la destination, le territoire et la durée, est signée par les deux parties.
- Le socle réutilisable du prestataire fait l'objet d'une licence écrite : perpétuelle, non exclusive, transférable, avec droit de modification.
- L'inventaire des dépendances et de leurs licences a été remis.
- Aucune licence copyleft n'entre en conflit avec votre modèle économique, notamment aucune AGPL si vous exploitez un service en ligne.
- Le dépôt Git est complet, historique inclus, et hébergé sur votre organisation avec votre compte comme propriétaire.
- Les secrets, clés d'API et variables d'environnement ont été transmis par canal sécurisé, et la rotation des clés sensibles est planifiée.
- La documentation permet un déploiement autonome de bout en bout.
- Tous les comptes tiers, domaine compris, sont au nom de votre entreprise.
- Une procédure de réversibilité écrite fixe des délais et un volume d'accompagnement chiffrés.
- L'installation a été reproduite avec succès sur un environnement neuf par une personne extérieure au projet.
Neuf réponses positives sur dix ne suffisent pas. Le point manquant est précisément celui qui posera problème.
Les signaux d'alerte chez un prestataire
Certains comportements se repèrent tôt et méritent une clarification immédiate.
Le refus de donner accès au dépôt pendant le déroulement du projet, sous prétexte que « le code sera livré à la fin ». Un contrat totalement muet sur la propriété intellectuelle, ce qui n'est pas un oubli mais un choix. Des réponses évasives sur les licences des composants utilisés, ou une incapacité à les énumérer. Un hébergement imposé sans alternative possible, avec un tarif nettement supérieur au marché. L'absence de toute documentation, présentée comme une évidence du métier. Du code livré uniquement compilé, minifié ou obfusqué. Une dépendance à un back-office propriétaire de l'agence, non cédé et non licencié, sans lequel le site n'est plus administrable.
Aucun de ces signaux ne rend un prestataire malhonnête. Certains relèvent de l'habitude, d'autres d'un modèle économique assumé. Mais chacun modifie l'équilibre de la relation en votre défaveur, et chacun se discute avant la signature. Après, c'est un rapport de force.
Conclusion
La propriété du code source est moins une question de titre qu'une question de capacité. Un client qui détient juridiquement son code, mais qui ne peut ni le déployer, ni le comprendre, ni le faire évoluer sans son prestataire actuel, n'est pas réellement propriétaire. Il détient un actif immobilisé.
La bonne nouvelle, c'est que tout ce qui précède se règle au moment du devis, quand le contrat n'est pas signé et que le rapport de force joue en votre faveur. Une clause de cession correctement rédigée, un dépôt Git sur votre organisation, un inventaire de licences, une clause de réversibilité chiffrée : quatre exigences qui ne coûtent presque rien à ce stade et qui deviennent inatteignables une fois la relation dégradée.
La mauvaise nouvelle, c'est que la majorité des projets se lancent sans aucun de ces éléments, et que le sujet ressurgit toujours au plus mauvais moment. Si vous avez des contrats en cours ou des livrables déjà reçus dont vous ne savez pas exactement ce qu'ils recouvrent, un audit des contrats et des accès permet de faire le point et de corriger ce qui peut encore l'être. Nous accompagnons régulièrement ce type de mise à plat, y compris sur des projets livrés depuis plusieurs années.
