Contrat de développement : les clauses à exiger

Un contrat de développement se négocie une fois, au moment précis où les deux parties ont le plus envie de signer. Tout ce qui n'y figure pas ne se rattrape pas : trois ans plus tard, quand le prestataire ne répond plus ou que ses tarifs ont doublé, votre marge de manœuvre est exactement celle que le contrat vous a laissée. Voici la liste que nous garderions sous les yeux pendant la relecture — y compris là où elle dessert un prestataire comme nous.

La règle générale : achetez la capacité de partir

Aucune de ces clauses ne sert à préparer un divorce. Elles servent à le rendre possible, ce qui change tout l'équilibre de la relation pendant que tout va bien. Un prestataire qui sait que vous pouvez partir ne se comporte pas comme celui qui sait que vous ne le pouvez pas. La clause de réversibilité n'est pas un acte de défiance : c'est ce qui vous dispense d'en éprouver.

La seconde règle est plus prosaïque : une clause dont l'exécution n'est pas décrite n'existe pas. « Le prestataire fournira la documentation » n'engage personne tant que la nature, le format, le destinataire et le moment de la livraison ne sont pas écrits. Chaque point ci-dessous suit la même structure — la formulation à repérer, et ce qu'il faut demander à la place.

Ce que vous achetez : droits, code, données

1. 1

   Une cession des droits patrimoniaux, pas une licence

   Le piège : « le client bénéficie d'une licence d'utilisation perpétuelle, irrévocable et non exclusive ». Perpétuelle rassure et ne protège pas : une licence vous autorise à utiliser le logiciel, pas à le modifier, à le faire modifier par un tiers ni à le céder. Demandez une cession des droits patrimoniaux sur les développements spécifiques, énumérant les droits cédés — reproduction, représentation, adaptation, mise sur le marché — pour toute la durée légale et pour tous les territoires. Le droit français n'admet pas les cessions globales et vagues : une phrase courte et généreuse vous protège bien moins qu'une phrase longue et précise.

2. 2

   La propriété du dépôt de code et des accès

   Le piège : le code est « disponible sur demande » ou confié à un tiers séquestre. Ce qu'il faut demander : le dépôt est hébergé sur un compte au nom du groupement, avec un administrateur côté groupement dès le premier jour, et le prestataire y travaille en tant qu'invité. La différence n'est pas juridique, elle est pratique — le jour où la relation s'arrête, vous ne demandez rien à personne.

3. 3

   La propriété des données et un format d'export documenté

   Le piège : « les données du client demeurent la propriété du client ». Personne n'en doute ; la question est de savoir comment vous les sortez. Demandez un export complet dans un format ouvert, accompagné du dictionnaire de données correspondant, exécutable par vous à tout moment depuis l'application. Pas sur demande, pas en PDF, pas sous forme de prestation chiffrée le jour où vous partez.

4. 4

   Aucune brique propriétaire bloquante

   Le piège : un « framework maison » ou un « socle technique propriétaire », présenté comme un avantage de productivité. Demandez la liste des composants utilisés, leurs licences, et l'engagement écrit qu'aucun composant nécessaire au fonctionnement n'appartient au prestataire sans licence transférable. Un code source livré qui ne compile qu'avec une bibliothèque privée n'est pas un code source livré.

Ce que vous devez pouvoir faire sans lui

1. 1

   La documentation d'exploitation et la reconstruction de l'environnement

   Le piège : « la documentation sera fournie en fin de projet » — elle ne l'est jamais, ou elle arrive sous forme de manuel utilisateur. Ce qu'il faut demander : une procédure écrite permettant à un tiers compétent de reconstruire l'environnement complet à partir du dépôt, avec dépendances, variables de configuration, schéma de base et jeux de données de test. Faites-en un critère de recette : un développeur extérieur au projet suit la procédure et l'application démarre. C'est le seul test qui prouve que la livraison du code source signifie quelque chose.

2. 2

   La réversibilité et la sortie

   Le piège : une « clause de réversibilité » sans contenu. Ce qu'il faut demander : un délai, une liste de livrables (code à jour, export de données, documentation, comptes et accès, transfert des noms de domaine et des certificats), un prix ou une gratuité arrêtés d'avance, et l'obligation d'accompagner le repreneur pendant un nombre de jours défini. Un chiffrage de réversibilité négocié le jour où vous partez n'est pas une clause, c'est un rapport de force.

3. 3

   La continuité en cas de défaillance du prestataire

   Le piège : rien du tout, ou une responsabilité civile professionnelle citée sans montant. Ce qu'il faut demander : l'attestation d'assurance et ses plafonds annexées au contrat, et une clause déclenchant la remise automatique des livrables en cas d'ouverture d'une procédure collective. Si vous n'obtenez rien de mieux, exigez au minimum que la clause de réversibilité s'applique de plein droit, sans mise en demeure préalable.

Ce qui encadre la relation au quotidien

1. 1

   Une définition écrite de la recette et de ce que la signature déclenche

   Le piège : « la recette est réputée acquise en l'absence de retour sous huit jours ». Ce qu'il faut demander : un cahier de recette listant les cas testés, un délai réaliste, une distinction entre anomalie bloquante et réserve mineure, et l'énoncé explicite de ce que la signature déclenche — paiement du lot, départ de la garantie, fermeture du périmètre de ce lot. Une recette qui ne ferme rien laisse le sixième mois rouvrir ce que le deuxième avait validé.

2. 2

   Des engagements de maintenance et de correction avec de vrais délais

   Le piège : « maintenance corrective incluse pendant un an », sans délai d'intervention. Ce qu'il faut demander : des niveaux de gravité définis par écrit (bloquant, majeur, mineur), un délai de prise en compte et un délai de rétablissement par niveau, les plages horaires couvertes, et ce qui se passe quand un délai n'est pas tenu. Sans niveaux de gravité écrits, tout est mineur pour celui qui doit corriger.

3. 3

   Une clause d'avenant

   Le piège : aucune clause, ou « toute demande hors périmètre fera l'objet d'une facturation complémentaire ». Ce qu'il faut demander : la procédure elle-même — qualification écrite, chiffrage remis avant la décision, arbitrage, signature, mise à jour du document de périmètre — et l'interdiction explicite de démarrer un développement hors périmètre avant signature. Cette clause vous protège d'une facture surprise autant qu'elle protège le prestataire d'un travail non payé.

4. 4

   Une équipe nommée au contrat

   Le piège : « une équipe de développeurs seniors sera affectée au projet ». Ce qu'il faut demander : les personnes, leur rôle, leur taux d'affectation, et une clause de remplacement avec préavis, profil équivalent et période de recouvrement. Et la question la moins chère que vous poserez jamais : le développement est-il sous-traité, et à qui ?

Les trois clauses à ne jamais accepter

1. La licence perpétuelle présentée comme l'équivalent d'une cession de droits. Les deux ne sont pas comparables : l'une vous laisse utiliser, l'autre vous laisse décider. Un prestataire qui vous explique que « en pratique, c'est la même chose » vous dit exactement l'inverse de ce qu'il pense.
2. La recette tacite. Une clause qui rend une livraison acquise faute de retour dans un délai court transforme votre charge de travail en validation. Pendant l'arrêté annuel ou une campagne de déclarations, votre équipe permanente ne relira rien pendant trois semaines — et le contrat considérera que vous avez tout accepté.
3. L'hébergement et le nom de domaine au nom du prestataire. C'est la clause la plus discrète et la plus coûteuse de toutes : elle ne parle ni de droits ni de code, et elle suffit à rendre une sortie impossible sans coupure de service. Les comptes d'hébergement, le nom de domaine, les certificats et les accès à la base sont au nom du groupement, facturés au groupement, dès le premier jour.

Aucune de ces exigences ne fait monter le prix d'un projet bien mené. Elles font monter le prix — ou fuir — du prestataire qui comptait sur votre dépendance pour rentabiliser une affaire signée trop bas. C'est précisément à cela qu'elles servent : elles ne trient pas les contrats, elles trient les prestataires, et elles le font avant la signature plutôt que trois ans après.