Contrat de développement : les sept clauses que je vous conseille de relire

Je signe ces contrats depuis l’autre côté de la table. Autant vous dire ce que je regarderais si j’étais à votre place — y compris les points où un prestataire a intérêt à rester flou.

Ce n’est pas un article juridique et je ne suis pas avocat. C’est une liste de sept endroits où j’ai vu des clients se retrouver coincés, alors que trois lignes ajoutées au bon moment auraient suffi.

1. La cession des droits sur le code

Ce qu’il faut : une cession intégrale, à titre exclusif, pour toute la durée de protection et tous supports, effective au fur et à mesure des paiements.

Le piège : une « licence d’utilisation ». Vous avez payé le développement, mais vous ne pouvez ni le modifier, ni le confier à un autre prestataire. C’est parfaitement légal, et ça change radicalement votre position de négociation lors du renouvellement.

La question à poser : « Si nous voulons confier la maintenance à quelqu’un d’autre l’an prochain, avons-nous le droit de lui donner le code ? »

Attention aussi aux composants tiers : le contrat doit préciser les licences utilisées. Une bibliothèque sous licence contraignante intégrée à votre application peut avoir des conséquences que personne n’avait anticipées.

2. La documentation comme livrable

Ce qu’il faut : la documentation technique et d’exploitation listée explicitement parmi les livrables, avec la recette conditionnée à sa remise.

Le piège : « une documentation sera fournie ». Sans définition ni conditionnement au paiement, elle arrive en fin de projet, écrite en deux jours, et n’aide personne.

Ce que je conseille de préciser : procédure d’installation depuis zéro, description de l’architecture et des choix structurants, documentation des interfaces, procédures d’exploitation courantes.

3. La réversibilité

Ce qu’il faut : une clause décrivant ce qui se passe à la fin — quels que soient les motifs. Remise du code et des données dans un format exploitable, transfert des accès, période d’accompagnement du repreneur, et un délai maximum.

Le piège : ne rien prévoir. La réversibilité se négocie très mal au moment où l’on se sépare, c’est-à-dire précisément quand on en a besoin.

Mon repère : une clause de réversibilité correcte tient en une demi-page et prévoit une assistance de quinze à trente jours. Si le prestataire résiste, la raison est rarement bonne.

4. La recette

Ce qu’il faut : qui recette, sur quels critères, dans quel délai, et ce qui se passe en l’absence de réponse.

Le piège classique — et il joue contre vous : la clause de recette tacite. « À défaut de retour sous dix jours, la livraison est réputée acceptée. » Vos utilisateurs sont en congés, le délai court, et vous avez accepté sans le savoir.

Ce que je conseille : un délai réaliste (vingt à trente jours ouvrés sur un lot significatif), une liste de critères convenue à l’avance, et une distinction claire entre anomalie bloquante, majeure et mineure — avec un traitement différent pour chacune.

5. Les demandes de changement

Ce qu’il faut : une procédure écrite. Qui peut demander, sous quelle forme, comment c’est chiffré, qui valide, et ce qui se passe pour le planning.

Le piège : ne rien prévoir, et traiter chaque demande comme une négociation. Au bout de trois, la relation se tend et les décisions ralentissent — ce qui coûte plus cher que les demandes elles-mêmes.

Un détail utile : prévoyez explicitement ce qui se passe pour les demandes refusées. Beaucoup de tensions viennent de demandes laissées sans réponse plutôt que de demandes refusées clairement.

Photo : energepic.com — licence CC0.

Photo : Ch�u Th�ng Phan — licence CC0.

6. Les engagements après mise en production

Ce qu’il faut : la garantie (durée, périmètre), puis les engagements de service si vous confiez l’exploitation — délais de prise en compte et de rétablissement par niveau de gravité, et ce qu’il advient en cas de dépassement.

Le piège : confondre garantie et maintenance. La garantie couvre les défauts de conformité pendant quelques mois. Elle ne couvre ni les évolutions, ni l’exploitation, ni les montées de version. Ce sont trois lignes budgétaires distinctes.

7. La propriété des données

Ce qu’il faut : une affirmation explicite que les données vous appartiennent, avec les conditions d’export dans un format standard et documenté, à tout moment.

Le piège : un export possible « sur demande » et facturé. Le coût d’export devient un verrou.

Si des données personnelles sont traitées, le contrat de sous-traitance RGPD est également obligatoire — ce n’est pas une formalité, c’est votre responsabilité de responsable de traitement.

8. Les composants tiers et leurs licences

Point rarement lu et parfois lourd de conséquences.

Une application assemble des dizaines de composants libres, chacun sous sa propre licence. La grande majorité ne pose aucun problème. Quelques-unes imposent en revanche des obligations lorsqu’on redistribue le logiciel — obligations sans effet si vous exploitez l’application pour vous-même, mais bien réelles si vous envisagez de la revendre.

Ce que je fais figurer au contrat : la remise d’un inventaire des composants et de leurs licences avec les livrables, et l’engagement du prestataire qu’aucun composant n’impose de contrainte incompatible avec l’usage prévu.

C’est une ligne de contrat, une page de livrable, et cela évite une découverte désagréable le jour où le projet change de nature.

La clause de réversibilité, dans le détail

La réversibilité figure dans presque tous les contrats et n’est presque jamais opérante, parce qu’elle reste au niveau du principe.

Ce qui la rend réelle tient en quatre précisions : quoi — code, données dans un format exploitable, documentation d’exploitation, accès aux hébergements et aux services tiers ; quand — un délai en jours à compter de la demande ; à quel prix — un forfait ou un volume de jours convenu à l’avance, jamais « aux conditions du moment » ; et avec quel accompagnement — un nombre de jours de transfert vers l’équipe entrante.

Sans ces quatre points, la clause existe mais ne s’exécute pas, et la négociation a lieu au moment le plus défavorable pour vous.

Le réflexe qui résume tout

Avant de signer, posez-vous une question simple : si nous devions changer de prestataire dans dix-huit mois, que se passerait-il ?

Déroulez le scénario ligne par ligne. Avons-nous le code ? La documentation ? Les données ? Les accès ? Quelqu’un d’autre pourrait-il reprendre, et en combien de temps ?

Si la réponse est confortable, le contrat est sain. Si elle est inconfortable, vous savez exactement quelles clauses renégocier — et vous êtes encore en position de le faire.