Partnerblog
Dienstencontracten vormen de ruggengraat van het moderne IT-contractenlandschap in België. Sinds de invoering van Boek 7 van het Burgerlijk Wetboek (BW) is het dienstencontract (of “aanneming”) de centrale contractsvorm voor IT-dienstverlening, al blijven ook onbenoemde overeenkomsten (zoals softwarelicenties) en koopcontracten een rol spelen.
Hieronder schetst mr. Stefan Van Camp, advocaat Timelex, de plaats van dienstencontracten binnen
IT-overeenkomsten, het onderscheid tussen projectgebaseerde en operationele contracten, en de belangrijkste conformiteitsvragen die in de praktijk rijzen.
IT-dienstencontracten in België: een overzicht
Plaats van dienstencontracten binnen IT-contracten
Dienstencontracten zijn de voornaamste categorie binnen IT-contracten. Ze omvatten twee grote subcategorieën met een verschillende uitvoeringslogica:
Projectgebaseerde “maak”-contracten: gericht op de ontwikkeling en oplevering van een bepaald resultaat (“deliverable”) binnen een bepaalde termijn en conform de vereisten van de klant. Typische voorbeelden zijn software-ontwikkeling, implementatie met configuratie, integraties en gegevensmigratie. De klant moet het resultaat doorgaans formeel aanvaarden.
Doorlopende operationele contracten: hier staat niet een eenmalig resultaat centraal, maar de voortdurende, correcte uitvoering van een dienst. Voorbeelden zijn SaaS (waar het dienstenelement domineert), onderhoudscontracten, outsourcing en managed services (beheer van werkposten, servers, security).
Daarnaast bestaan er onbenoemde overeenkomsten die niet door Boek 7 BW maar door het algemene verbintenissenrecht (Boek 5 BW) worden beheerst. Het belangrijkste voorbeeld is de softwarelicentie waarbij software ter beschikking wordt gesteld zonder bijkomende diensten. Volgens sommige rechtspraak (o.m. Hof van Beroep Brussel 2015 en Antwerpen 2022) kan een licentie voor standaardsoftware met een onbeperkt gebruiksrecht als een koopcontract worden beschouwd, waardoor alsnog Boek 7 BW (koopregels) van toepassing kan zijn.
Project versus operatie: fundamenteel verschillende logica
Het belangrijkste verschil tussen projectgebaseerde en operationele contracten ligt in filosofie, structuur en risicoprofiel.
Projectcontracten zijn resultaatgericht: de nadruk ligt op tijdige oplevering van een conform resultaat dat de klant aanvaardt. De beoordeling gebeurt op gefixeerde ijkmomenten (test- en aanvaardingsprocedures). Bij niet-conformiteit of vertraging zijn sancties zoals schadebedingen, prijsvermindering, gedwongen uitvoering of ontbinding mogelijk. Budget- en scopediscussies zijn hier vaak fundamenteel.
Operationele contracten zijn uitvoeringsgericht: het doel is permanente, conforme dienstverlening, gemeten via een Service Level Agreement (SLA) met KPI’s. Niet-conformiteit uit zich bijvoorbeeld in downtime, trage storingsoplossing of onvoldoende performantie. Sancties zijn meestal service credits (prijsverminderingen) of beperkte schadebedingen. Gedwongen uitvoering of ontbinding zijn theoretisch mogelijk maar worden vaak contractueel beperkt en zijn minder evident dan bij projecten.
Implementatiecontracten: hybride vorm
Implementatiecontracten combineren vaak beide logica’s. In een eerste fase wordt een projectmatige “deliverable” ontwikkeld en geïmplementeerd (configuratie, maatwerk, integraties, migratie).
Na oplevering en aanvaarding volgt een operationele fase waarin de oplossing als dienst (meestal SaaS) continu wordt aangeboden en onderhouden.
Een typisch voorbeeld is de implementatie van ERP- of CRM-software. In de operationele fase staan ononderbroken beschikbaarheid, security en compliance centraal. De regelgeving hieromtrent (GDPR, NIS2, Cyber Resilience Act, AI Act) neemt snel toe en legt zware verplichtingen op aan zowel klant als dienstverlener, met aanzienlijke aansprakelijkheidsrisico’s tot gevolg.
Geen wettelijk onderscheid, maar één conformiteitsbegrip
De wetgever maakt geen uitdrukkelijk onderscheid tussen project- en operationele contracten.
Boek 7 BW hanteert een ruim dienstencontractbegrip, maar lijkt vooral het projectgebaseerde model (klassieke aanneming) voor ogen te hebben gehad. De termen “opdrachtgever” en “opdrachtnemer” (artikel 7.4.1–7.4.2 BW) passen beter bij projecten dan bij SaaS.
Voor alle dienstencontracten (en ook voor koop) geldt in theorie één ‘uniform conformiteitsbegrip’.
De concrete toetsing verschilt echter sterk naargelang de contractsoort, de prestaties en de contractuele omschrijving ervan.
Conformiteit bij projectcontracten
Bij projecten worden conformiteitscriteria primair afgeleid uit de overeenkomst: scope, functionele en niet-functionele specificaties, acceptatiecriteria, documentatie, goedgekeurde change requests en interne projectdocumentatie. Omdat vereisten tijdens IT-projecten vaak evolueren (zeker bij agile methodes), is goede documentatie cruciaal.
Daarnaast gelden criteria die niet uitdrukkelijk in het contract staan maar voortvloeien uit wet, gebruiken en de gespecialiseerde rol van de dienstverlener: wat de klant ’redelijkerwijze mag verwachten’ (artikel 7.4.14 BW). Dit omvat naleving van wettelijke vereisten en “regels van de kunst”, zoals backup-, security-, disaster recovery- en roll-back-mogelijkheden.
De hoedanigheid van de klant is hierbij van belang. De klant moet de IT-dienstverlener informeren over zijn vereisten, beperkingen en relevante afhankelijkheden. Zo kan hij systemen of werkmethoden hanteren die moeilijk verenigbaar zijn met de beoogde software of IT-oplossing.
In principe moet de IT-dienstverlener daarvan reeds in de precontractuele fase op de hoogte worden gebracht, zodat hiermee bij de keuze en uitwerking van de oplossing rekening kan worden gehouden.
Van een kleine onderneming zonder interne IT-expertise kan echter niet steeds worden verwacht dat zij zelf kan inschatten welke omstandigheden voor de gekozen oplossing relevant zijn. Bepaalde behoeften, beperkingen of afhankelijkheden kunnen voor haar latent blijven. Een dergelijke klant mag daarom meer proactief onderzoek en meer waarschuwingen van een gespecialiseerde IT-dienstverlener verwachten dan een onderneming die zelf over relevante IT-expertise beschikt.
Er bestaat aldus een spanningsveld tussen de mededelingsplicht van de klant (artikel 7.4.5 BW) en de onderzoeksplicht van de dienstverlener. In recente rechtspraak bestaat een tendens om die onderzoeksplicht te relativeren naarmate ook aan klantenzijde meer IT-kennis aanwezig is. Uiteindelijk blijven evenwel de concrete omstandigheden, en in het bijzonder de deskundigheid die van beide partijen mocht worden verwacht, doorslaggevend.
Conformiteit bij operationele contracten
Ook hier spelen scope en technische specificaties een rol, maar de voornaamste criteria zijn:
- overeengekomen service levels en KPI’s;
- toepasselijke wettelijke vereisten;
- informatiebeveiliging;
- disaster recovery, contingency en bedrijfscontinuïteit;
- gegevensbescherming.
Een dienst kan niet-conform zijn omdat zij wel functioneel werkt, maar niet voldoet aan beveiligings-, continuïteits- of privacyvereisten. Dit is vooral relevant gezien de zware sancties onder NIS2 en DORA (voor de financiële sector). Dienstverleners worden vaak contractueel verplicht hun klanten in staat te stellen deze regels na te leven; doen zij dat onvoldoende, dan riskeren zij zelf aansprakelijk te worden gesteld.
Consumenten en bijzondere regimes
Boek 7 BW bevat ook bijzondere regimes voor consumenten, zoals de regels voor de aanschaf van digitale inhoud en diensten (artikel 7.2.38 e.v. BW). Deze zijn ondergebracht in de titel “koop”, hoewel het technisch geen koopcontracten zijn. Ze bieden strikte consumentenbescherming gebaseerd op Europese richtlijnen, terwijl de algemene dienstencontractregels overwegend niet-dwingend zijn.
Praktische aandachtspunten
Boek 7 brengt geen fundamentele hernieuwing met zich. De bestaande rechtspraak wordt gecodificeerd en het algemeen kader van de wetgeving is duidelijker, in het bijzonder voor dienstencontracten. Maar deze wetgeving is niet specifiek gericht op de eigenheid van IT-contracten.
Enkele belangrijke praktische punten vloeien wel voort uit de bepalingen van Boek 7:
- Opzegging: de klant kan een dienstencontract in principe te allen tijde opzeggen (artikel 7.4.32 BW), mits betaling van geleverde prestaties en gederfde winst, tenzij dit contractueel wordt uitgesloten.
- Aanvaarding: bij agile-projecten kunnen tussentijdse goedkeuringen van codepakketten discussie opleveren over de eindaanvaarding van het geïntegreerde systeem (waarbij nieuwe gebreken aan het licht kunnen komen ingevolge de integratie). Boek 7 bevat enkele principes aangaande de aanvaarding, maar deze zijn meer gericht op de aanvaarding van klassieke aannemingsprojecten. In IT-contracten moet de aanvaarding van bepaalde fases en van de eindoplevering meer specifiek geregeld worden.
- Conformiteitstermijn: artikel 7.4.17 BW voorziet een termijn van 10 jaar vanaf aanvaarding voor verborgen gebreken, maar de klant moet tijdig klagen. In de praktijk worden kortere garantietermijnen bedongen, gevolgd door betalend onderhoud. De verjaringstermijn bedraagt 2 jaar (opschortbaar bij ernstige onderhandelingen).
- Eigendom en intellectuele rechten: artikel 7.4.12 §1, 2° BW verplicht de dienstverlener tot eigendomsoverdracht wanneer dit uit de aard van het contract voortvloeit. Voor maatwerksoftware betekent dit niet automatisch overdracht van auteursrechten; dit moet formeel en bij voorkeur uitdrukkelijk in het contract worden geregeld.
Dienstencontracten blijven dus de kern van IT-overeenkomsten, maar hun concrete invulling – en de daaraan verbonden risico’s – verschillen sterk naargelang het gaat om een eenmalig project of een doorlopende dienst. Een heldere contractstructuur, duidelijkheid aangaande de vereisten van de klant, realistische SLA’s en aandacht voor compliance zijn essentieel om geschillen te voorkomen.
