Contrat de développement d'application : check-list client
Une check-list opérationnelle, et non un modèle juridique, pour rendre le périmètre, la recette, les droits et la sortie vérifiables.
Un contrat de développement d'application doit préciser le périmètre de la V1, les livrables, les responsabilités, les hypothèses de calendrier, les paiements par jalon, la recette, la gestion des changements, les droits sur le code et le design, le contrôle des comptes critiques, les composants tiers, la sécurité et les données, la correction des anomalies, la maintenance, la résiliation et la réversibilité. Cette check-list prépare le travail avec un juriste; elle ne remplace pas un conseil adapté au droit applicable.
Estimez votre app avec un bref questionnaire
CommencerLes questions à rendre incontestables
| Sujet | Ce que le contrat doit dire | Preuve concrète |
|---|---|---|
| Périmètre | Profils, plateformes, parcours, intégrations et exclusions | Cahier des charges versionné |
| Livrables | App, serveur, administration, design, tests et documentation | Dépôts, fichiers, environnements et comptes nommés |
| Contributions | Ce que chaque partie fournit et à quelle date | Responsable et échéance par dépendance |
| Calendrier | Les hypothèses de chaque jalon | Plan avec validations et dépendances |
| Paiements | L'événement qui déclenche chaque règlement | Jalon accepté ou autre fait défini |
| Recette | Tests, délai d'examen, anomalies et validation | Cas de test, numéro de version et résultat écrit |
| Évolutions | Comment coût et délai sont révisés | Demande de changement approuvée |
| Droits | Cession ou licence pour chaque catégorie de création | Étendue, territoire, durée et usages autorisés |
| Comptes | Titulaire des stores, du cloud, des domaines et fournisseurs | Comptes d'entreprise et rôles |
| Données et sécurité | Mesures, accès et obligations des parties | Annexe de sécurité et traitement |
| Support | Différence entre anomalie, évolution et maintenance | Gravité, canal, délai et limite |
| Réversibilité | Ce qui est rendu si la relation s'arrête | Paquet de transfert et assistance prévue |
Une case vide n'est pas forcément un mauvais signal sur le prestataire. C'est une hypothèse qui doit cesser d'être implicite.
Un périmètre rattaché à une version
Le contrat peut renvoyer à un document d'exigences produit et à un cahier des charges technique. La date ou le numéro de version doit éviter qu'un ancien document réapparaisse plus tard.
« Module de réservation » ne dit pas si les plannings du personnel, acomptes, annulations, fuseaux horaires, rappels et remboursements sont inclus. Les rôles, parcours, règles, états et interfaces avec d'autres systèmes doivent être décrits.
Les exclusions sont aussi utiles. Reprise de données, rédaction, tablette, traduction, site web ou maintenance ne sont pas automatiquement compris. Les hypothèses concernant les API, le contenu et les accès méritent la même précision.
Prévoir le changement sans perdre le contrôle
Un produit évolue à mesure que l'équipe apprend. Interdire tout changement est irréaliste; les accepter dans des messages dispersés est dangereux.
Une demande de changement doit présenter l'objectif, la partie touchée, l'effet sur le coût et le délai, ainsi que les tâches éventuellement reportées. Le contrat indique qui peut l'approuver.
Dans un fonctionnement agile, le backlog peut être repriorisé dans une capacité définie. Ajouter un nouveau profil ou une intégration n'est cependant pas une simple permutation de tickets.
Faire correspondre paiement et recette
Un acompte peut réserver l'équipe et financer le démarrage. Les échéances suivantes sont plus faciles à contrôler lorsqu'elles correspondent à un résultat observable : maquettes validées, parcours central opérationnel en test, version candidate ou transfert terminé.
« Serveur réalisé à 80 % » ne constitue pas une recette. Un résultat testable serait : un utilisateur crée son compte, réserve, effectue un paiement de test et un administrateur retrouve puis rembourse l'opération.
Définissez le délai de recette, les anomalies bloquantes, la procédure de correction et la version examinée. Les conséquences du silence, d'une mise en production ou d'une validation tardive doivent être formulées selon le contrat et le droit applicable.
Traiter séparément chaque droit
L'application rassemble du code mobile et serveur, de la configuration d'infrastructure, une base de données, des fichiers de design, des illustrations, de la documentation et des éléments de store.
Le contrat précise pour chaque ensemble s'il y a cession ou licence, à quel moment, pour quelle durée, sur quel territoire et avec quels droits de modification, d'exploitation ou de transfert. Pour pouvoir changer de prestataire, le client doit disposer des droits et matériaux nécessaires à la maintenance.
Il faut distinguer les créations nouvelles des outils et bibliothèques préexistants du prestataire. Les SDK, polices, images et composants open source ont leurs propres licences.
L'OMPI propose un guide consacré aux principaux contrats des applications mobiles, utile pour comprendre cette superposition de droits.
En France, une formule générale ne remplace pas une rédaction adaptée de la cession. Le modèle commenté de Convention.fr illustre les sujets à examiner, mais doit être adapté et vérifié.
Une livraison de code exploitable
« Le code source sera remis » peut aboutir à une archive sans historique ni procédure de construction. Nommez les dépôts, branches, instructions, dépendances, tests, configuration de publication et documentation.
Un accès du client pendant le développement limite le risque final. En cas de transfert, GitHub conserve de nombreux éléments, mais signale des particularités sur les droits, paquets et pages. Le titulaire de l'organisation et la facturation doivent aussi être vérifiés.
Un développeur extérieur au projet devrait pouvoir générer une version de test à partir des éléments remis. La check-list de documentation et de transfert couvre cette vérification.
Mettre les comptes au nom de l'entreprise
App Store Connect, Google Play Console, domaine, cloud, paiement et services essentiels devraient généralement être créés sous l'identité durable du client. Le prestataire reçoit des rôles adaptés.
Apple et Google permettent le transfert d'une application, mais tous les réglages, historiques ou services associés ne suivent pas de la même façon. Mieux vaut décider du titulaire avant le premier lancement.
Précisez aussi qui paie les abonnements, reçoit les alertes et peut modifier la production. Une carte bancaire personnelle expirée peut interrompre un produit pourtant correctement livré.
Vous avez une idée d'app et voulez clarifier la suite ?
Revoir mon idéeRépertorier composants tiers et coûts récurrents
Demandez la liste des dépendances importantes, licences et abonnements. Un inventaire simple peut suffire pour un petit produit; une nomenclature logicielle plus formelle convient aux environnements exigeants.
Le contrat peut prévoir qui approuve un fournisseur et comment réagir à une hausse de prix, un changement de licence ou l'arrêt d'un service. Open source ne signifie pas absence d'obligations.
Il ne s'agit pas d'obtenir des droits impossibles sur le SDK d'un tiers, mais de garantir une utilisation licite, le bon compte et une solution de remplacement.
Encadrer sécurité et données
« Sécurisé et conforme au RGPD » reste trop vague. Authentification, autorisations, chiffrement, journaux, sauvegardes, vulnérabilités et notification d'incident doivent être rattachés à des responsabilités.
Lorsque le prestataire traite des données personnelles pour le compte du client, un accord de sous-traitance peut être requis. La Commission européenne publie des clauses contractuelles types entre responsable et sous-traitant.
Définissez les environnements qui peuvent recevoir des données réelles, les autorisations d'accès, les sous-traitants ultérieurs et la restitution ou suppression en fin de contrat.
Distinguer anomalie, évolution et maintenance
Une anomalie est un écart par rapport aux exigences acceptées. Une évolution modifie le comportement. La maintenance couvre les nouvelles versions des systèmes, les SDK, la surveillance et les améliorations.
Fixez une période de correction, des niveaux de gravité, un canal et des limites. Un support gratuit sans fin est imprécis; qualifier chaque défaut de nouvelle demande l'est tout autant.
Après la sortie, un accord distinct peut préciser capacité et temps de réponse. Le guide du coût de maintenance d'une application décrit les travaux qui continuent.
Organiser la réversibilité
La collaboration peut s'arrêter pour une raison stratégique, financière ou opérationnelle. Le contrat traite alors les travaux terminés et en cours, les sommes dues, licences, données, secrets et capacité réservée.
Prévoyez un socle de transfert à chaque grand jalon payé : code à jour, design éditable, documentation, environnements, dépendances et anomalies connues. L'assistance supplémentaire peut avoir une durée et un tarif définis.
Le client doit pouvoir retirer les accès sans casser la production. Le prestataire doit pouvoir confirmer la restitution ou la suppression convenue des données.
Signaux d'alerte
Soyez attentif à une phrase vague comme « le client possède l'application », à une recette déclarée unilatéralement, au code livré seulement après un paiement final indéfini, aux comptes personnels, à l'absence de procédure de changement ou aux composants tiers non déclarés.
Vérifiez aussi l'ordre de priorité entre devis, cahier des charges et contrat. Une liste fonctionnelle détaillée perd sa valeur si le contrat la qualifie de non contraignante.
La préparation du projet chez Appfyl
Avant la revue juridique, Appfyl structure la V1 par profils, parcours, opérations d'administration, intégrations et dépendances client. Le cahier des charges contractuel peut ainsi s'appuyer sur des faits.
Nous identifions également les comptes d'entreprise, démonstrations de jalons et actifs de transfert au démarrage. La recette porte sur des parcours fonctionnels plutôt que sur des pourcentages abstraits.
Les questions à poser à une agence mobile facilitent la comparaison. Le brief d'estimation Appfyl aide à organiser les fonctions avant de finaliser le devis et le contrat.
Voir comment Appfyl transforme un périmètre en produit lancé. Voir les cas Appfyl.
Transformer la recherche en plan
Appfyl transforme votre idée en plan d'app clair, liste de fonctions et premier plan de travail.
Discuter du plan de l'appPoints clés
- Périmètre, paiement et recette doivent renvoyer à des résultats vérifiables.
- Créations nouvelles, outils existants et composants tiers ont des régimes distincts.
- Stores, infrastructure et fournisseurs doivent rester sous un contrôle durable.
- Anomalie, évolution et maintenance ne se confondent pas.
- La réversibilité doit exister avant le dernier jour du projet.
- Cette check-list prépare une revue juridique, elle ne la remplace pas.
Liens utiles
Questions fréquentes
La cession ou licence souhaitée doit être écrite et revue sous le droit applicable. Le client a généralement besoin de droits et de matériaux suffisants pour exploiter, modifier et confier la maintenance à un tiers. Les outils préexistants et composants externes peuvent rester licenciés séparément.
Uniquement si le jalon est vérifiable. Une facturation au temps peut convenir à un périmètre évolutif si budget, priorités et comptes rendus sont contrôlés. Les deux modèles peuvent être combinés.
La version, l'environnement, les cas de test, la période d'examen, les anomalies bloquantes et la validation écrite. Les parcours complets et opérations d'administration sont prioritaires.
Pour une application commandée par une entreprise, le contrôle direct du client est généralement plus durable. Le prestataire reçoit des rôles, tandis que l'identité juridique, les contrats et la facturation restent chez le propriétaire du produit.
Il fournit une liste de sujets, mais ne connaît ni l'architecture, ni le marché, ni les données, ni la négociation. Il faut préparer les faits, puis faire adapter et vérifier le texte.