Partnerblog
Les contrats de services constituent l’épine dorsale du paysage moderne des contrats IT en Belgique. Depuis l’introduction du Livre 7 du Code civil (C. civ.), le contrat de services (ou « contrat d’entreprise ») est devenu la forme contractuelle centrale pour la prestation de services informatiques, même si les contrats innommés (tels que les licences de logiciels) et les contrats de vente continuent également à jouer un rôle.
Ci-dessous, M. Stefan Van Camp, avocat chez Timelex, présente la place des contrats de services dans les contrats IT, la distinction entre les contrats basés sur un projet et les contrats opérationnels, ainsi que les principales questions de conformité qui se posent en pratique.
Contrats de services IT en Belgique : un aperçu
Place des contrats de services dans les contrats IT
Les contrats de services constituent la principale catégorie au sein des contrats IT. Ils comprennent deux grandes sous-catégories ayant une logique d’exécution différente :
Contrats de « réalisation » basés sur des projets : ils visent le développement et la livraison d’un résultat déterminé (« livrable ») dans un délai donné et conformément aux exigences du client. Les exemples typiques sont le développement de logiciels, les projets d’implémentation avec configuration, les intégrations et les migrations de données. Le client doit généralement accepter formellement le résultat.
Contrats opérationnels continus : dans ce cas, ce n’est pas un résultat unique qui est central, mais l’exécution continue et correcte d’un service. Les exemples incluent le SaaS (où l’élément de service prédomine), les contrats de maintenance, l’outsourcing et les services gérés (« managed services ») tels que la gestion des postes de travail, des serveurs et de la sécurité informatique.
Il existe également des contrats innommés qui ne sont pas régis par le Livre 7 du Code civil, mais par le droit général des obligations (Livre 5 du C. civ.). L’exemple le plus important est la licence de logiciel par laquelle un logiciel est mis à disposition sans services complémentaires. Selon une partie de la jurisprudence (notamment la Cour d’appel de Bruxelles en 2015 et celle d’Anvers en 2022), une licence de logiciel standard assortie d’un droit d’utilisation illimité peut être considérée comme un contrat de vente, ce qui entraîne l’application du Livre 7 du Code civil relatif à la vente.
Projet versus exploitation : une logique fondamentalement différente
La principale différence entre les contrats fondés sur un projet et les contrats opérationnels réside dans leur philosophie, leur structure et leur profil de risque.
Les contrats de projet sont orientés vers le résultat : l’accent est mis sur la livraison, dans les délais, d’un résultat conforme que le client accepte. L’évaluation s’effectue à des moments de contrôle déterminés (procédures de test et d’acceptation). En cas de non-conformité ou de retard, des sanctions telles que les clauses de dommages-intérêts, la réduction du prix, l’exécution forcée ou la résolution du contrat sont possibles. Les discussions relatives au budget et au périmètre du projet (« scope ») y sont souvent essentielles.
Les contrats opérationnels sont orientés vers l’exécution : l’objectif est une prestation de services permanente et conforme, mesurée au moyen d’un « Service Level Agreement » (SLA) comportant des KPI. La non-conformité se manifeste p.ex. par des temps d’arrêt (downtime), une résolution trop lente des incidents ou des performances insuffisantes. Les sanctions prennent généralement la forme de crédits de service (« service credits »), c.-à-d. des réductions de prix, ou de clauses de dommages-intérêts limitées. L’exécution forcée ou la résolution du contrat sont théoriquement possibles, mais elles sont souvent limitées contractuellement et sont moins évidentes que dans le cadre des projets.
Contrats d’implémentation : une forme hybride
Les contrats d’implémentation combinent souvent les deux logiques. Dans une première phase, un « livrable » est développé et implémenté dans le cadre d’un projet (configuration, développements spécifiques, intégrations, migration).
Après la livraison et l’acceptation, une phase opérationnelle suit, au cours de laquelle la solution est fournie et maintenue en continu sous forme de service (généralement SaaS).
Un exemple typique est l’implémentation d’un logiciel ERP ou CRM. Dans la phase opérationnelle, la disponibilité ininterrompue, la sécurité et la conformité sont au cœur des préoccupations. La réglementation en la matière (RGPD, NIS2, Cyber Resilience Act, AI Act) évolue rapidement et impose des obligations importantes tant au client qu’au prestataire de services, avec à la clé des risques significatifs de responsabilité.
Pas de distinction légale, mais une notion unique de conformité
Le législateur n’opère aucune distinction expresse entre les contrats de projet et les contrats opérationnels.
Le Livre 7 du Code civil adopte une notion large du contrat de services, mais semble avoir principalement envisagé le modèle fondé sur le projet (l’entreprise classique). Les termes « donneur d’ordre » et « prestataire » (art. 7.4.1 à 7.4.2 du C. civ.) se prêtent davantage aux projets qu’aux services SaaS.
Pour tous les contrats de services (ainsi que pour les contrats de vente), une même « notion uniforme de conformité » s’applique en théorie.
Cependant, l’appréciation concrète de cette conformité varie fortement selon le type de contrat, les prestations concernées et la manière dont celles-ci sont définies contractuellement.
Conformité dans les contrats de projet
Dans les projets, les critères de conformité découlent principalement du contrat : le périmètre (« scope »), les spécifications fonctionnelles et non fonctionnelles, les critères d’acceptation, la documentation, les demandes de modification (« change requests ») approuvées et la documentation interne du projet. Étant donné que les exigences évoluent souvent au cours des projets IT, en particulier dans les méthodes agiles, une documentation de qualité est essentielle.
S’y ajoutent des critères qui ne figurent pas expressément dans le contrat, mais qui résultent de la loi, des usages et du rôle spécialisé du prestataire de services : ce que le client peut « raisonnablement attendre » (art. 7.4.14 du C. civ.). Cela comprend le respect des exigences légales ainsi que des « règles de l’art », telles que l’existence de mécanismes de sauvegarde (backup), de sécurité, de reprise après sinistre (disaster recovery) et de retour en arrière (roll-back).
La qualité du client revêt ici une importance particulière. Le client doit informer le prestataire informatique de ses exigences, de ses contraintes et des dépendances pertinentes. Il peut ainsi utiliser des systèmes ou des méthodes de travail difficilement compatibles avec le logiciel ou la solution informatique envisagée. En principe, le prestataire informatique doit déjà être informé de ces éléments au stade précontractuel, afin qu’ils puissent être pris en compte lors du choix et de la conception de la solution.
Toutefois, il ne peut pas toujours être attendu d’une petite entreprise dépourvue d’expertise informatique interne qu’elle soit capable d’évaluer elle-même quelles circonstances sont pertinentes pour la solution choisie. Certains besoins, limitations ou dépendances peuvent lui échapper. Un tel client est donc en droit d’attendre davantage de recherches proactives et davantage de mises en garde de la part d’un prestataire informatique spécialisé qu’une entreprise disposant elle-même d’une expertise informatique pertinente.
Il existe ainsi une tension entre l’obligation d’information du client (art. 7.4.5 du C. civ.) et l’obligation d’investigation du prestataire. La jurisprudence récente tend à relativiser cette obligation d’investigation à mesure que le client dispose lui aussi de davantage de connaissances informatiques. En définitive, ce sont toutefois les circonstances concrètes, et en particulier le niveau d’expertise que l’on pouvait raisonnablement attendre de chacune des parties, qui demeurent déterminants.
Conformité dans les contrats opérationnels
Ici aussi, le périmètre et les spécifications techniques jouent un rôle, mais les principaux critères sont les suivants :
- les niveaux de service (service levels) et les KPI convenus ;
- les exigences légales applicables ;
- la sécurité de l’information ;
- la reprise après sinistre (disaster recovery), les plans de secours (contingency) et la continuité des activités ;
- la protection des données.
Un service peut être non conforme même s’il fonctionne correctement sur le plan fonctionnel, s’il ne respecte pas les exigences de sécurité, de continuité ou de protection de la vie privée. Cet aspect est particulièrement important compte tenu des lourdes sanctions prévues notamment par NIS2 et DORA (pour le secteur financier). Les prestataires sont souvent tenus contractuellement de permettre à leurs clients de respecter ces réglementations. S’ils ne remplissent pas suffisamment cette obligation, ils risquent eux-mêmes d’engager leur responsabilité.
Consommateurs et régimes particuliers
Le Livre 7 du Code civil contient également des régimes particuliers applicables aux consommateurs, tels que les règles relatives à l’acquisition de contenus et de services numériques (art. 7.2.38 et suivants du C. civ.). Ces dispositions sont intégrées dans le titre consacré à la « vente », bien qu’il ne s’agisse pas, sur le plan technique, de contrats de vente. Elles offrent une protection stricte des consommateurs fondée sur les directives européennes, tandis que les règles générales relatives aux contrats de services sont, pour l’essentiel, supplétives et donc non impératives.
Points d’attention pratiques
Le Livre 7 n’apporte pas de révolution fondamentale. Il codifie en grande partie la jurisprudence existante et clarifie le cadre général de la législation, en particulier pour les contrats de services. Toutefois, cette législation n’est pas spécifiquement conçue pour tenir compte des particularités propres aux contrats informatiques.
Plusieurs points pratiques importants découlent néanmoins des dispositions du Livre 7 :
- Résiliation : en principe, le client peut résilier un contrat de services à tout moment (art. 7.4.32 du C. civ.), moyennant le paiement des prestations déjà exécutées et du bénéfice manqué, sauf exclusion contractuelle expresse.
- Acceptation : dans les projets agiles, les validations intermédiaires de lots de code peuvent susciter des discussions quant à l’acceptation finale du système intégré, notamment lorsque de nouveaux défauts apparaissent à la suite de l’intégration. Le Livre 7 prévoit certains principes relatifs à l’acceptation, mais ceux-ci visent principalement l’acceptation de projets d’entreprise classiques. Dans les contrats IT, les modalités d’acceptation des différentes phases ainsi que de la livraison finale doivent être réglées de manière plus spécifique.
- Délai de conformité : l’article 7.4.17 du Code civil prévoit un délai de dix ans à compter de l’acceptation pour les vices cachés, à condition que le client les dénonce en temps utile. En pratique, des périodes de garantie plus courtes sont souvent convenues contractuellement, suivies d’un contrat de maintenance payant. Le délai de prescription est de deux ans, avec possibilité de suspension en cas de négociations sérieuses entre les parties.
- Propriété et droits intellectuels : l’article 7.4.12, § 1er, 2°, du Code civil impose au prestataire le transfert de propriété lorsque celui-ci découle de la nature du contrat. Dans le cas d’un logiciel développé sur mesure, cela n’implique toutefois pas automatiquement le transfert des droits d’auteur. Celui-ci doit être prévu formellement et, de préférence, expressément dans le contrat.
Les contrats de services demeurent donc au cœur des contrats IT. Toutefois, leur mise en œuvre concrète et les risques qui y sont associés diffèrent sensiblement selon qu’il s’agit d’un projet ponctuel ou d’un service continu. Une structure contractuelle claire, une définition précise des exigences du client, des SLA réalistes et une attention particulière portée à la conformité réglementaire sont essentielles pour prévenir les litiges.