Contrat développeur : 8 clauses que personne ne négocie

Un de mes clients a payé 45 000 € pour une application. Huit mois de développement avec une agence recommandée par un ami. Quand il a voulu changer de prestataire, il a découvert que le code source était hébergé sur le GitLab interne de l'agence. Pas de transfert prévu au contrat. L'agence a refusé de le donner.

Il a dû repartir de zéro. Quarante-cinq mille euros perdus.

Son contrat faisait pourtant 12 pages. Conditions de paiement, confidentialité, juridiction compétente — tout y était. Mais les clauses qui protègent vraiment le client quand les choses tournent mal ? Aucune.

Si vous êtes en train de recruter un développeur ou de signer avec une agence, cet article va peut-être vous éviter le même scénario.

Votre contrat protège votre prestataire, pas vous

Le contrat que vous signez avec un développeur freelance ou une agence, c'est leur contrat. Leur modèle. Relu par leur avocat.

Et il fait bien son boulot : il protège le prestataire. Les responsabilités sont plafonnées au montant de la prestation. Les délais sont "indicatifs". La propriété intellectuelle est floue — volontairement. Les conditions de rupture vous désavantagent.

Ce n'est pas malhonnête. C'est logique : personne ne rédige un contrat contre ses propres intérêts. Mais si vous signez sans négocier, vous acceptez un rapport de force qui ne joue pas en votre faveur.

Sur les 30 derniers contrats de développement que j'ai relus pour des clients, 27 ne contenaient aucune des 8 clauses ci-dessous. Les 3 autres en avaient deux ou trois, mal formulées.

Les 8 clauses à exiger avant de signer

1. Cession de propriété intellectuelle — complète et sans ambiguïté

"Le code vous appartient" — cette phrase ne suffit pas. J'ai vu des contrats qui mentionnaient un "transfert de propriété" mais excluaient les bibliothèques développées par l'agence, les composants réutilisables, ou le design system. En clair : vous possédez la coquille, pas les briques qui la font tenir.

Ce qu'il faut exiger : une cession complète, définitive et irrévocable de tous les droits patrimoniaux sur le code produit dans le cadre de la prestation. Code source, scripts de déploiement, fichiers de configuration — tout. Si le prestataire utilise des briques internes qu'il ne peut pas céder, ça doit être listé noir sur blanc. Et vous devez comprendre de quoi il s'agit avant de signer.

2. Accès aux environnements techniques — dès le jour 1

Un freelance a développé une application pour un de mes clients pendant huit mois. Un matin, plus de nouvelles. Téléphone coupé, mails sans réponse. Le client n'avait pas les identifiants de son propre serveur cloud. Trois semaines de batailles administratives avec le fournisseur pour récupérer l'accès à sa base de données de production. Trois semaines de site hors ligne.

Si vous n'avez jamais vécu ce scénario, tant mieux. Mais j'ai écrit un plan d'urgence complet pour quand ça arrive, et croyez-moi : c'est plus fréquent qu'on ne le croit.

La règle est simple : tous les comptes cloud, hébergement et services tiers doivent être créés au nom du client, avec les accès administrateurs transmis dès le premier jour du projet. Pas à la fin. Pas "quand ce sera stable". Le premier jour.

3. Hébergement du code source — sur votre dépôt

C'est la clause qui aurait évité à mon client de perdre ses 45 000 €. Le code doit être poussé sur un dépôt que vous contrôlez — votre GitHub, votre GitLab, votre Bitbucket. Pas celui de l'agence.

Si le prestataire insiste pour travailler sur son propre serveur "pour des raisons de process", c'est un signal d'alerte. Il peut travailler sur une branche de votre dépôt sans aucun problème technique. Il n'y a aucune raison valable pour que vous n'ayez pas accès à votre propre code en temps réel.

4. Documentation technique minimale

Personne n'aime documenter du code. Je suis développeur, je le sais. Mais quand un projet change de mains — et ça finit toujours par arriver — l'absence de documentation transforme une transition de 2 semaines en chantier de 3 mois.

Le minimum non négociable à exiger comme livrables :

• Un fichier README : comment installer et lancer le projet
• Un schéma d'architecture, même sommaire
• La procédure de déploiement en production
• La liste des services tiers utilisés avec leurs accès

Ce n'est pas du perfectionnisme. C'est de la survie. Si vous voulez comprendre ce que ça implique concrètement de reprendre un code sans documentation, le tableau n'est pas joli.

5. Clause de réversibilité — votre porte de sortie

La réversibilité, c'est ce qui se passe le jour où vous quittez votre prestataire. Sans cette clause, vous êtes dans un mariage sans possibilité de divorce.

Elle doit préciser :

• Le délai de transfert : 30 jours maximum après la fin du contrat
• Le format de livraison : code source complet, bases de données, documentation, accès aux services
• L'accompagnement du prestataire sortant : un nombre d'heures dédié à la transition avec le nouveau prestataire
• Les pénalités en cas de non-respect

C'est la clause que les agences rechignent le plus à signer. C'est aussi celle qui en dit le plus sur leurs intentions à long terme.

6. SLA et temps de réponse — des chiffres, pas des promesses

Un de mes clients avait un contrat qui mentionnait une "haute disponibilité". Son site e-commerce est tombé un vendredi à 18h. Le prestataire a répondu le lundi matin. Le contrat ne définissait ni le pourcentage de disponibilité, ni le temps de réponse, ni les plages horaires couvertes. "Haute disponibilité" ne voulait rien dire.

Un SLA qui vous protège vraiment inclut :

• Un taux de disponibilité chiffré — et la définition précise de ce qui compte comme indisponibilité (un SLA à 99 % autorise quand même 87 heures de panne par an)
• Un temps de réponse garanti selon la criticité : 2 heures pour un bug bloquant, 24 heures pour un bug mineur
• Les plages horaires couvertes : heures ouvrées uniquement, ou 24/7 ?
• Des pénalités financières en cas de dépassement — sans pénalité, le SLA n'est qu'une déclaration d'intention

7. Garantie post-livraison

Projet livré, facture payée. Deux semaines plus tard, trois bugs critiques apparaissent en production. Le prestataire répond : "La prestation est terminée. C'est de la maintenance, c'est facturé en supplément."

Sans clause de garantie, il a techniquement raison.

Exigez une période de garantie de 3 à 6 mois après la recette finale. Pendant cette période, tout dysfonctionnement lié au code livré est corrigé sans facturation supplémentaire. C'est la norme dans le bâtiment, dans l'automobile, dans l'industrie. Il n'y a aucune raison que le développement logiciel fasse exception.

8. Pénalités de retard

Un fondateur que j'accompagnais avait signé avec une ESN pour un projet à 60 000 €. Livraison prévue en 4 mois. Livraison réelle : 11 mois. Aucune clause de pénalité dans le contrat. Le retard lui a coûté un lancement raté et un concurrent qui a pris le marché pendant qu'il attendait.

Les pénalités de retard ne servent pas à punir. Elles servent à aligner les intérêts. Même un montant modeste — 1 % du montant total par semaine de retard, plafonné à 10 ou 15 % — change la dynamique. Le prestataire a une raison financière concrète de tenir ses délais, pas juste une promesse orale.

Précisez aussi ce qui constitue un retard : la date de livraison doit être liée à des jalons définis, pas à une estimation vague envoyée par email.

Checklist : 8 points à vérifier avant de signer

Passez votre contrat à travers cette grille. Si plus de deux cases restent décochées, renégociez avant de signer.

Faites relire votre contrat par un œil technique

Votre avocat vérifiera que le contrat est juridiquement solide. C'est nécessaire. Mais un avocat ne sait pas si la clause de "transfert des environnements" couvre tout ce qu'il faut transférer. Il ne sait pas que "livraison du code source" sans les scripts de déploiement ne vaut rien en pratique. Il ne repèrera pas qu'un SLA à 99 % autorise en fait 87 heures de coupure par an — et qu'un site e-commerce ne peut pas se permettre ça.

Ces subtilités sont techniques. Il faut un œil technique pour les attraper.

C'est une des raisons pour lesquelles des fondateurs font appel à un directeur technique externe avant de signer — pas pour coder, mais pour relire un contrat, challenger un devis, ou vérifier qu'un prestataire s'engage réellement sur ce qu'il promet. Si le coût de développement est un sujet pour vous, les quelques heures investies dans une relecture technique du contrat peuvent vous faire économiser des dizaines de milliers d'euros. Et surtout des mois de retard.

Négociez ces 8 clauses avant de signer. Pas après.