Retard de livraison et résolution du contrat informatique
Deux arrêts d'appel retiennent des solutions opposées sur le même grief. L'écart tient à la rédaction de la clause de calendrier.
3 min de lecture
La question se pose dans la plupart des projets informatiques en difficulté : un retard de livraison autorise-t-il le client à mettre fin au contrat aux torts du prestataire ? La réponse n’est pas acquise. Un retard, même important, ne suffit pas à lui seul.
Deux arrêts d’appel, saisis du même grief, retiennent des solutions opposées. Leur comparaison montre ce qui fait pencher la balance.
Résolution refusée : un retard signalé et partagé
Dans la première affaire, le développement d’une plateforme métier avait pris du retard. Le client demandait la résolution du contrat aux torts du prestataire.
La cour l’a refusée, en relevant deux éléments : les retards avaient été signalés au client au fur et à mesure, et ils étaient imputables aux deux parties1.
Ces deux constats se tiennent. Un prestataire qui informe est un prestataire qui exécute son obligation d’information ; et un client qui a lui-même contribué au retard — arbitrages tardifs, spécifications mouvantes, indisponibilité de ses équipes — ne peut pas en faire grief à son seul cocontractant.
Résolution admise : un calendrier impératif
Dans la seconde affaire, la cour a au contraire admis la résolution décidée par le client2.
Ce qui a emporté la décision tient d’abord à la rédaction du contrat. Le calendrier n’y était pas indicatif : il était stipulé « sans décalage possible de sa part », et « toute modification du planning devait faire l’objet d’un accord des deux parties ». Autrement dit, les parties avaient elles-mêmes érigé le respect du planning en obligation, et privé le prestataire de la faculté de le décaler unilatéralement.
S’y ajoutait un second élément : le client avait constaté et démontré de nombreux dysfonctionnements. La cour a jugé que ces manquements persistants étaient suffisamment graves pour justifier la rupture.
Ce qui distingue les deux décisions
| Résolution refusée | Résolution admise | |
|---|---|---|
| Statut du calendrier | Non caractérisé comme impératif | Stipulé sans décalage unilatéral possible |
| Information du client | Retards signalés au fil de l’eau | — |
| Origine du retard | Imputable aux deux parties | Imputable au prestataire |
| Défaillances techniques | Non retenues | Constatées et démontrées par le client |
Aucune des deux décisions ne pose que le retard est, ou n’est pas, une cause de rupture. Toutes deux examinent ce que le contrat disait du calendrier, qui a causé le décalage, et ce que le client est capable de prouver.
Conséquences pour la rédaction
Qualifier le calendrier. Un planning annexé au contrat sans mention de sa portée sera discuté pendant des mois. Écrire que les dates sont indicatives, ou au contraire impératives, est une décision de négociation à part entière — et elle se prend en connaissance de ce qu’elle emporte.
Verrouiller les décalages. La clause qui a emporté la conviction de la cour ne disait pas seulement que le calendrier était ferme : elle subordonnait toute modification à l’accord des deux parties. C’est cette seconde phrase qui prive le prestataire de l’argument du décalage unilatéral.
Documenter en continu. Les deux arrêts se jouent sur la preuve : d’un côté un prestataire qui a signalé, de l’autre un client qui a démontré. Le compte rendu de comité de pilotage, la réserve écrite au moment de la recette et le courriel d’alerte pèsent, au contentieux, plus lourd que la clause elle-même.