L'obligation de délivrance en IT : 4 clés pour éviter le contentieux
Mal-livré, mal testé, mal documenté… Combien de projets IT finissent devant les tribunaux parce que la « livraison » n’était pas celle promise ? D’après un article publié par Le MagIT, l’obligation de délivrance est désormais l’un des premiers motifs de litige entre donneurs d’ordre et éditeurs/SSII. Explications et check-list pour sécuriser vos prochains contrats.
Pourquoi l’obligation de délivrance dépasse la simple « date de Go Live »
Contrairement à une idée reçue, livrer un DVD ou un lien de téléchargement ne clôture pas l’engagement du prestataire. L’obligation de délivrance implique :
- la conformité aux spécifications fonctionnelles validées en début de projet ;
- l’absence de vices substantiels (bugs bloquants, performances dégradées) ;
- la transfert de connaissances (documentation, supports de formation, codes sources en escrow si nécessaire) ;
- l’interopérabilité promise avec le legacy ou des services tiers.
Dès lors qu’un de ces points fait défaut, l’acheteur peut invoquer une carence et refuser de payer, voire réclamer des dommages-intérêts.
Trois pièges qui transforme un projet en procès
- Le cahier des charges trop flou
Si l’objectif est rédigé en « langue métier » (« l’application doit être ergonomique »), l’interprétation devient subject. Préférez des exigences mesurables (KPI de temps de réponse, taux de disponibilité, nombre de clics). - La recette « sur les rails »
Tests unitaires passés, mais recette d’intégration bâclée ? Le logic peut s’effondrer en production. Prévoyez des campagnes de tests pilotées par des référents métiers avant la signature définitive. - Le changement de scope oral
« On pourrait aussi ajouter un export Excel ? » Accepté par mail sans avenant ? Vous venez de créer un précedent juridique. Toute modification doit être chiffrée, datée et annexée.
Check-list : 5 bonnes pratiques à copier-coller dans votre prochain MSA
1. Définissez des jalons partiels (sprints gates) avec des critères d’acceptation clairs et un veto exprès de l’acheteur.
2. Prévoyez une période de garantie d’éviction (3-6 mois) pendant laquelle le vendeur corrige gratuitement les défauts émergents.
3. Escrow du code source et documentation technique, libéré en cas de défaillance ou d’abandon.
4. Pénalités de retard progressives, plafonnées mais significatives, pour éviter l’effet « planning glissant ».
5. Clause de médiation obligatoire avant tout recours au tribunal : moins coûteux, plus rapide, et souvent suffisant.
Conclusion : la prévention vaut mieux que le procès
Un projet IT ne se conclut pas quand le développeur repart avec son chèque, mais quand l’utilisateur peut exploiter sereinement la solution sans dépendance excessive. En sécurisant dès l’avant-projet l’obligation de délivrance, la DSI limite le risque de vendor lock-in, protège son budget et préserve sa crédibilité auprès des métiers.
Et vous, avez-vous déjà dû refuser une livraison ? Quelles clauses avez-vous ajouté à vos contrats pour éviter les déconvenues ? Partagez votre retour d’expérience dans les commentaires !