Qui détient vraiment votre application ?
Vous avez payé l'application, mais le nom de domaine est au nom de l'agence, le code sur le compte du freelance, et personne n'a signé de cession de droits. Le jour d'un désaccord, ces détails décident de tout. Voici la liste à vérifier, avant d'en avoir besoin.
Payer n'est pas posséder
Beaucoup de dirigeants découvrent, au moment d'un changement de prestataire ou d'un désaccord, que l'application qu'ils ont payée ne leur appartient pas vraiment : les comptes sont au nom de quelqu'un d'autre, et parfois même les droits sur le code. Rien de malveillant en général, juste une commodité du début qui n'a jamais été corrigée.
La vérification tient en deux parties : les comptes, qui donnent le contrôle technique, et les droits, qui donnent le contrôle juridique.
Partie 1 : les comptes, un par un
Pour chaque ligne, notez au nom de qui est le compte (votre société, ou une personne), qui a les accès, et qui reçoit les factures et les alertes :
| Compte | Pourquoi c'est critique |
|---|---|
| Nom de domaine | Celui qui le détient peut faire pointer votre adresse ailleurs, ou la laisser expirer |
| Messagerie du domaine | Les réinitialisations de mot de passe de tous les autres comptes y arrivent |
| Hébergement | C'est là que tourne l'application |
| Base de données (Supabase, Firebase…) | Les données de vos clients |
| Paiement (Stripe…) | L'argent, et le compte bancaire où il arrive |
| Dépôt de code (GitHub, GitLab…) | Le code et son historique |
| Outil de génération (Lovable, Bolt…) | Souvent le seul endroit où le projet est modifiable facilement |
| Services d'envoi, d'analyse, d'IA | Leurs clés sont dans votre application, et leurs factures chez quelqu'un |
L'objectif : chaque compte au nom de votre société, avec une adresse e-mail générique de votre domaine (par exemple technique@votre-domaine.fr), et au moins deux personnes de confiance qui y ont accès. Pour les comptes au nom d'un tiers, demandez le transfert par écrit ; la plupart des services ont une procédure prévue pour ça.
Profitez-en pour retirer les accès des personnes qui n'en ont plus besoin : anciens prestataires, stagiaires, associés partis.
Partie 2 : les droits sur le code
C'est le point le plus souvent ignoré. En France, un logiciel est protégé par le droit d'auteur. Quand il est écrit par un salarié dans l'exercice de ses fonctions, les droits patrimoniaux reviennent à l'employeur. Dans tous les autres cas (agence, freelance, mais aussi associé ou dirigeant non salarié, stagiaire), ils restent en principe à leur auteur, sauf cession écrite qui précise ce qui est cédé, pour quels usages, quel territoire et quelle durée.
Concrètement, vérifiez dans votre contrat ou vos devis signés :
- qu'une clause de cession des droits sur le code existe, et qu'elle couvre l'exploitation, la modification et la redistribution ;
- qu'elle prend effet au paiement (et que vous avez bien tout payé), avec la remise du code source ;
- que le prestataire garde le droit de réutiliser ses outils génériques, mais pas votre code spécifique.
S'il n'y a rien d'écrit, une cession peut encore être signée après coup : c'est beaucoup plus simple tant que la relation est bonne. Sur ce point, un avocat vous fera gagner du temps ; ce guide ne remplace pas son conseil.
Partie 3 : ce que votre code emprunte
Votre application utilise des dizaines de bibliothèques publiques, chacune avec sa licence. La plupart (MIT, Apache, BSD) n'imposent presque rien. Certaines (GPL, AGPL) imposent de publier votre propre code dans certains cas. Si votre application est un produit que vous vendez ou distribuez, demandez à un développeur la liste des licences utilisées : c'est une commande, pas un audit.
La liste à tenir à jour
Gardez le tableau de la partie 1 dans un document partagé, et relisez-le une fois par trimestre et à chaque départ d'une personne ou d'un prestataire. C'est une demi-heure qui évite des semaines de bras de fer.
Ce que cette vérification ne couvre pas
Savoir si l'application peut être relancée par quelqu'un d'autre à partir du code, ce qu'elle coûte réellement, et dans quel état technique elle se trouve : voir notre guide Le développeur de votre application est parti : par où commencer ?. La fiche d'identité de notre diagnostic fait cet inventaire pour vous, compte par compte.
Vous préférez qu'on regarde avec vous ?
Le diagnostic couvre ce guide et toute la grille, soixante questions sur sept axes, pour 2 900 € HT : premiers constats sous 48 heures, rapport sous cinq jours ouvrés.