L’essentiel
Une PME qui fait développer une application métier n’achète pas seulement du logiciel : elle achète, ou pas, la capacité de changer de prestataire un jour. Dix clauses suffisent à faire la différence entre un actif et une dépendance. La plus importante n’est pas le prix, c’est de savoir à qui appartiennent le dépôt Git et les comptes d’hébergement le jour de la livraison.
Le scénario qu’on voit trois ans plus tard
L’application fonctionne. Elle est devenue critique : les commerciaux l’utilisent tous les jours, elle contient l’historique client, elle génère les devis.
Et puis le prestataire devient injoignable, augmente ses tarifs, ou tout simplement arrête son activité.
L’entreprise découvre alors que le dépôt Git est chez lui, que le serveur est sur son compte, que le nom de domaine est enregistré à son nom, qu’il n’existe aucune documentation de déploiement, et qu’une seule personne au monde sait comment remettre l’application en ligne.
Rien n’a été volé. Tout était dans le contrat, ou plutôt tout n’y était pas. C’est la situation que les dix clauses ci-dessous évitent.
1. Un périmètre, pas une intention
Un devis qui dit « développement d’une application de gestion » n’engage à rien.
Le contrat doit renvoyer à des documents annexes qui, eux, sont précis : cahier des charges, spécifications fonctionnelles, planning, devis détaillé, conditions de maintenance, annexe RGPD. Et il doit indiquer lequel prime en cas de contradiction entre deux documents.
Sans cette hiérarchie, chaque désaccord devient une négociation commerciale plutôt qu’une lecture de contrat.
2. La propriété du code, ligne par ligne
C’est la clause que nous relisons en premier dans un contrat existant.
Une formule du type « le client dispose des droits nécessaires à l’utilisation de l’application » est insuffisante. Utiliser n’est pas posséder. Vous voulez pouvoir modifier, faire maintenir par un tiers, migrer, revendre.
Le contrat doit distinguer explicitement :
| Élément | Qui le possède à la livraison |
|---|---|
| Code développé spécifiquement pour vous | Vous, cession de droits écrite |
| Bibliothèques open source | Leurs auteurs, sous licence |
| Composants préexistants du prestataire | Lui, avec licence d’usage accordée à vous |
| Maquettes et design | Vous |
| Contenus et données | Vous |
| Scripts d’infrastructure et CI/CD | Vous |
| Documentation technique | Vous |
Le droit français ne transfère pas automatiquement les droits d’auteur sur un logiciel commandé : en dehors du cas du logiciel créé par un salarié dans ses fonctions, la cession doit être écrite et délimitée. C’est d’ailleurs pour cette raison que les marchés publics informatiques traitent la propriété intellectuelle dans des clauses dédiées, en distinguant les résultats de la commande et les connaissances antérieures du prestataire.
Le piège à repérer : « le site reste la propriété de l’agence tant que le client souscrit au contrat de maintenance ». Cette clause transforme une prestation en location sans le dire.
3. Le dépôt Git est à vous
La règle tient en une ligne.
Mauvais : un dépôt hébergé sur le compte de l’agence, sous son organisation. Bon : un dépôt créé sur le compte de votre entreprise, avec le prestataire invité comme collaborateur.
Même logique pour tout le reste : hébergement, base de données, nom de domaine, DNS, comptes de monitoring, comptes de paiement, comptes développeur Apple et Google. Le prestataire administre, vous possédez.
Le prestataire doit travailler dans votre infrastructure, pas construire votre infrastructure chez lui. Cette seule exigence élimine la quasi-totalité des situations de blocage.
4. La réversibilité se négocie avant, pas après
Certains contrats prévoient une maintenance raisonnable puis facturent très cher la sortie : récupération du code, export des données, transfert de serveur, documentation, passation au prestataire suivant.
À écrire noir sur blanc :
À l’expiration du contrat, quelle qu’en soit la cause, le prestataire restitue l’intégralité du code source, des données, des configurations, des secrets et de la documentation nécessaires à la reprise de l’application par un tiers, dans un délai déterminé et pour un coût déterminé.
Et ce coût doit être chiffré dans le contrat. Zéro, ou un forfait connu. Pas « selon devis ».
5. Des critères d’acceptation, pas un ressenti
Sans critères écrits, « terminé » devient subjectif et la recette s’éternise.
Pour chaque fonctionnalité, le contrat doit dire comment on constate qu’elle est faite. Exemple pour une création de client :
- le formulaire est accessible aux utilisateurs habilités ;
- le nom est obligatoire, le SIRET et l’email sont validés ;
- un doublon est détecté et signalé ;
- la création est tracée dans l’historique ;
- un message de confirmation s’affiche ;
- un test automatisé couvre le cas nominal et le cas d’erreur.
C’est fastidieux à écrire. C’est beaucoup moins fastidieux que d’en discuter trois mois plus tard.
6. Forfait, régie, ou les deux
Le forfait ferme rassure mais reporte toute la tension sur le périmètre : dès que le besoin bouge, vous entrez dans les avenants. La régie pure offre de la souplesse mais aucune visibilité budgétaire.
Le découpage que nous utilisons :
| Phase | Mode | Pourquoi |
|---|---|---|
| Cadrage | Forfait court | Le périmètre n’existe pas encore |
| Première version utilisable | Forfait | Le périmètre est défini et figé |
| Évolutions | Régie plafonnée | Le besoin vient de l’usage réel |
| Maintenance | Forfait mensuel | Charge récurrente et prévisible |
Le cadrage de projet se paie. C’est précisément ce qui rend le forfait suivant tenable.
7. Garantie et maintenance sont deux choses différentes
Quatre lignes à séparer explicitement dans le devis, sinon elles finissent toutes facturées :
- Garantie : correction des anomalies du périmètre livré, pendant une durée définie, sans surcoût.
- Maintenance corrective : correction des anomalies après la garantie.
- Maintenance préventive : mises à jour du framework, du runtime, des dépendances, de la base de données, correctifs de sécurité.
- Maintenance évolutive : nouvelles fonctionnalités.
La maintenance préventive est celle qu’on oublie et qui coûte le plus cher quand on l’oublie : une application non mise à jour pendant trois ans ne se met pas à jour, elle se réécrit. C’est l’un des points que nous traitons dans la gouvernance technique d’un projet.
8. Un SLA chiffré
« Nous intervenons rapidement » n’est pas un engagement.
| Niveau | Définition | Délai de prise en charge |
|---|---|---|
| P1 | L’application est inutilisable | À fixer en heures ouvrées |
| P2 | Une fonction majeure est dégradée | À fixer en jours ouvrés |
| P3 | Gêne mineure, contournement existant | À fixer en jours ouvrés |
Les valeurs se négocient selon la criticité réelle de l’application. Ce qui compte, c’est qu’elles existent et qu’elles figurent dans le contrat, pas dans un email.
9. L’annexe RGPD, si l’application traite des données personnelles
Dès que le prestataire manipule des données personnelles pour votre compte, il est sous-traitant au sens du RGPD, et la relation doit être encadrée par un contrat écrit.
La CNIL rappelle que ce contrat doit préciser l’objet et la durée du traitement, sa nature et sa finalité, le type de données traitées, les catégories de personnes concernées, ainsi que les obligations et droits du responsable de traitement.
À compléter avec les points opérationnels qui posent problème en cas d’incident : mesures de sécurité, notification des violations de données et dans quel délai, recours à des sous-traitants ultérieurs, localisation de l’hébergement, modalités de sauvegarde, et sort des données en fin de contrat, restitution ou destruction.
Si vos salariés utilisent par ailleurs des outils d’IA générative sur des données clients, le sujet dépasse le contrat de développement : voir encadrer l’usage de ChatGPT par vos salariés.
10. Le test qui vaut tous les audits
Posez cette question au prestataire :
« Si je demande demain à un autre développeur de reprendre l’application, combien de temps lui faut-il pour comprendre l’architecture et redéployer en production ? »
Une bonne réponse parle de documentation, de README, de procédure de déploiement, de variables d’environnement documentées, d’un environnement de développement reproductible. Une mauvaise réponse parle de confiance et de partenariat sur la durée.
La capacité à partir est le meilleur indicateur de la qualité d’un prestataire, et c’est aussi la raison pour laquelle les prestataires sérieux n’ont aucun problème avec ces dix clauses.
Comment nous travaillons sur ce point
Chez Neodigit, ces points sont dans le contrat, pas dans le discours commercial.
Le code source appartient au client et lui est remis. À la fin du projet, le dépôt et les comptes d’hébergement sont au nom du client. La documentation de déploiement fait partie des livrables, au même titre que l’application. Aucune clause ne conditionne la propriété du site ou de l’application à la souscription d’un contrat de maintenance.
Ce choix a une conséquence directe : nos clients peuvent partir quand ils veulent. C’est voulu.
FAQ
Qui est propriétaire du code d’une application développée par une agence ? Personne par défaut : en droit français, la commande d’un logiciel n’emporte pas automatiquement cession des droits d’auteur du développeur. La cession doit être écrite dans le contrat et délimiter ce qui est cédé. Sans clause explicite, le client dispose au mieux d’un droit d’usage.
Que faire si mon prestataire actuel détient mon dépôt Git et mon hébergement ? Demandez d’abord un transfert à l’amiable en invoquant votre contrat s’il prévoit une réversibilité. S’il n’en prévoit pas, la négociation se fait sur la base du rapport commercial. Dans tous les cas, exigez une copie complète du code et une sauvegarde de la base de données, puis traitez le transfert de propriété des comptes comme un prérequis du prochain contrat.
Un contrat au forfait protège-t-il mieux qu’une régie ? Il protège le budget, pas le périmètre. Un forfait signé sur un besoin flou produit des avenants, une régie sans plafond produit une dérive. Le découpage cadrage, puis forfait, puis régie plafonnée traite les deux risques séparément.
Faut-il un avocat pour un projet de quelques dizaines de milliers d’euros ? Pas nécessairement pour rédiger, mais une relecture ciblée des clauses de propriété intellectuelle, de réversibilité et de sous-traitance RGPD représente un coût marginal par rapport au budget du projet. C’est exactement sur ces trois points que se jouent les litiges.
Parlons de votre projet. Si vous avez déjà un devis ou un contrat en main, nous pouvons le relire ensemble sur ces dix points avant que vous ne signiez quoi que ce soit.