« Nous avons payé, donc nous en sommes propriétaires » : telle est l’hypothèse. Sa véracité dépend entièrement de ce que prévoit le contrat et, en l’absence de clause, le régime par défaut de nombreuses juridictions favorise le développeur.
Ce que la propriété devrait couvrir
Un contrat qui traite correctement ce point aborde séparément quatre éléments :
- Code source personnalisé écrit spécifiquement pour ce projet.
- Éléments de design — écrans, icônes, illustrations et fichiers sources modifiables, et pas uniquement les images exportées.
- Données — tout ce que l’application stocke, qui devrait sans ambiguïté appartenir au client.
- Documentation — spécifications, notes d’architecture, instructions de déploiement.
La clause à rechercher transfère au client la propriété des travaux personnalisés au moment du paiement final. Deux détails sont importants : le transfert doit avoir lieu au paiement plutôt qu’à une date ultérieure, et il doit préciser explicitement qu’il inclut les fichiers sources de design, souvent oubliés et difficiles à obtenir ensuite.
Ce dont vous ne pouvez pas être propriétaire
Certains composants font l’objet d’une licence plutôt que d’un transfert de propriété, ce qui est normal :
- Bibliothèques open source. Toute application moderne en utilise de nombreuses. Elles sont régies par leurs propres licences, dont la plupart autorisent librement l’utilisation commerciale. L’important est que ces licences soient compatibles avec votre utilisation — il est raisonnable d’en demander la liste.
- Composants commerciaux — bibliothèque de graphiques payante, police sous licence, modèle acheté. Ils sont assortis de licences qui peuvent être accordées par projet, par développeur ou par déploiement, et la licence doit vous être transférée ou être rachetée.
- Code de framework préexistant du développeur. De nombreuses agences réutilisent leurs outils internes d’un projet à l’autre. Cette pratique est légitime et généralement bénéfique, mais le code devrait vous être concédé sous licence à perpétuité plutôt que de rester indéfini — sinon une partie de votre application appartient à quelqu’un d’autre.
Les images issues de banques sont un problème récurrent. Les images sous licence pour une maquette ne le sont parfois pas pour une utilisation en production, et le découvrir après le lancement coûte cher. Demander d’où provient chaque image vaut les cinq minutes nécessaires.
Le dossier de transfert
Le test d’un transfert est simple : un développeur compétent qui n’a jamais vu ce projet pourrait-il en reprendre la gestion ? Cela nécessite :
- Le dépôt complet avec son historique, transféré vers un compte contrôlé par le client. L’historique des commits est important : c’est ainsi qu’un nouveau développeur comprend pourquoi les choses sont comme elles sont.
- Des instructions de déploiement suffisamment détaillées pour reconstruire l’environnement à partir de rien.
- La configuration de l’environnement — les paramètres existants, leur fonction et ceux qui sont secrets.
- Tous les identifiants des comptes — hébergement, domaine, base de données, services tiers, comptes de boutiques — transférés au client, qui en devient propriétaire.
- Le schéma de la base de données et les scripts de migration éventuels.
- L’inventaire des services tiers avec l’usage de chacun et son coût.
- Les fichiers sources de design.
- Les problèmes connus et les éléments reportés, consignés honnêtement.
Ce dernier élément mérite d’être demandé explicitement. Chaque projet comporte des compromis connus, et un développeur disposé à les documenter fournit au client quelque chose de véritablement précieux.
Vérifier que le transfert fonctionne
La vérification la plus solide consiste à demander à une personne indépendante de déployer l’application uniquement à partir du dossier de transfert, dans un environnement vierge, sans rien demander au développeur initial. Si cette opération réussit, le transfert est réel.
Effectuer cette vérification tant que la relation est encore bonne est bien plus facile que de le faire après sa fin. Il est raisonnable de conditionner une petite partie du paiement final à sa réussite.
Séquestre
Lorsque le développeur conserve le code — ce qui arrive parfois dans le cadre d’offres basées sur une plateforme ou d’abonnements — le séquestre du code source consiste à en déposer une copie auprès d’un tiers, qui la remet au client dans des conditions définies, par exemple lorsque le développeur cesse son activité.
Cette solution coûte de l’argent et ajoute des tâches administratives ; elle est surtout proportionnée lorsque l’application est critique pour l’activité et que le développeur est une petite structure. Pour la plupart des petits projets, un transfert de propriété clair accompagné d’un transfert vérifié offre davantage pour un coût moindre.
Tout régler avant de commencer
- Qui est propriétaire du code personnalisé et à partir de quand.
- Si les fichiers sources de design sont inclus.
- Comment le code préexistant du développeur est concédé sous licence.
- Que les données appartiennent sans ambiguïté au client, dans un format exportable.
- Ce que contient le dossier de transfert.
- Que les comptes soient créés au nom du client dès le départ.
Services Manboo associés
- Développement d’applications Flutter pour les MVP iOS et Android.
- Développement de logiciels métier pour les systèmes de CRM, de réservation, de gestion des stocks et de workflows.
- Développement de panneaux d’administration pour les tableaux de bord opérationnels et la gestion du back-end.
- Intégration d’API d’IA lorsque votre produit est prêt pour la recherche intelligente, le chat ou l’automatisation.
- Demander une étude du périmètre et une estimation du projet lorsque vous êtes prêt à planifier la première version.