Un service SaaS critique tombe en panne. Le responsable IT et le responsable des contrats cherchent ensemble le bon contrat sur un disque partag\u00e9. Quel \u00e9tait d\u00e9j\u00e0 le d\u00e9lai de r\u00e9tablissement convenu ? Avons-nous droit \u00e0 des p\u00e9nalit\u00e9s de service ? Ce contrat arrive-t-il bient\u00f4t \u00e0 \u00e9ch\u00e9ance ? Quarante minutes plus tard, ils ont retrouv\u00e9 le PDF, mais la panne persiste toujours. C’est \u00e0 ce moment pr\u00e9cis que vous r\u00e9alisez que vous ne g\u00e9rez pas r\u00e9ellement vos SLA. Vous vous contentez de les conserver.<\/p>\n\n\n\n
Surveiller les SLA des fournisseurs IT ne revient pas \u00e0 v\u00e9rifier si un service fonctionne techniquement. La question est de savoir si l’engagement contractuel est respect\u00e9 : la disponibilit\u00e9, le d\u00e9lai de r\u00e9ponse, le d\u00e9lai de r\u00e9tablissement et la compensation en cas d’\u00e9cart. Ces engagements figurent dans des PDF, pas dans votre syst\u00e8me. Et c’est l\u00e0 que le probl\u00e8me commence. Selon une \u00e9tude de WorldCC, PwC et McKinsey, 95 pour cent des organisations n’ont pas une vision compl\u00e8te de leurs propres obligations contractuelles. Pour les contrats IT, avec leurs piles d’annexes, ce probl\u00e8me est le plus aigu.<\/p>\n\n\n\n
Votre ERP ou votre syst\u00e8me de gestion des d\u00e9penses fait exactement ce pour quoi il a \u00e9t\u00e9 con\u00e7u. Il enregistre le fournisseur, le montant du contrat et les factures. Il rapproche les bons de commande et suit la dur\u00e9e du contrat. Pour la base administrative, c’est parfait.<\/p>\n\n\n\n
Mais l’ERP ne conna\u00eet pas les normes du SLA. Il ne sait pas que vous avez convenu avec cet h\u00e9bergeur une disponibilit\u00e9 de 99,9 pour cent. Il ne sait pas non plus que le d\u00e9lai de r\u00e9ponse pour un incident de priorit\u00e9 1 est de quinze minutes. Ce contenu se trouve dans l’annexe du contrat. Et personne ne lit cette annexe au moment o\u00f9 les choses tournent mal.<\/p>\n\n\n\n
La diff\u00e9rence est celle qui existe entre l’enregistrement et la gestion. Votre syst\u00e8me enregistre le fait que vous avez un contrat. Le contenu de ce contrat, les engagements et les obligations en cours, r\u00e9side ailleurs. Le plus souvent dans Word, dans des PDF et dans la t\u00eate de quelques personnes. L’enregistrement reste dans votre syst\u00e8me. La gestion, elle, se fait dans un tableau de bord des contrats<\/a> au-dessus de ce syst\u00e8me.<\/p>\n\n\n\n En tant que responsable IT, vous avez probablement une surveillance de la disponibilit\u00e9 en place. Un tableau de bord qui v\u00e9rifie si un service est accessible et envoie une alerte en cas d’interruption. Utile, mais cela r\u00e9pond \u00e0 une question technique : le service fonctionne-t-il encore ?<\/p>\n\n\n\n C’est diff\u00e9rent de la question contractuelle : l’engagement est-il respect\u00e9 ? Un service peut \u00eatre techniquement disponible et pourtant se situer hors de la norme convenue, par exemple parce que le d\u00e9lai de r\u00e9ponse aux incidents est structurellement d\u00e9pass\u00e9. Mesurer la disponibilit\u00e9 ne vous dit rien sur les p\u00e9nalit\u00e9s de service, les proc\u00e9dures d’escalade ou les obligations de r\u00e9tablissement.<\/p>\n\n\n\n Il y a un autre probl\u00e8me. Le rapport mensuel sur les performances provient souvent du fournisseur lui-m\u00eame. C’est le boucher qui juge sa propre viande. Sans votre propre source dans laquelle la norme convenue figure \u00e0 c\u00f4t\u00e9 de la performance mesur\u00e9e, vous n’avez aucun contrepoids ind\u00e9pendant. Vous croyez ce que le fournisseur rapporte, ou vous menez la v\u00e9rification manuellement.<\/p>\n\n\n\n Pour surveiller les SLA de vos fournisseurs IT au niveau du contrat, vous consignez pour chaque contrat ce qui a \u00e9t\u00e9 convenu et si cet engagement est tenu. L’essentiel :<\/p>\n\n\n\n Ne commencez pas par les cinq points en m\u00eame temps. Placez d’abord la disponibilit\u00e9 et le d\u00e9lai de r\u00e9tablissement \u00e0 c\u00f4t\u00e9 de la performance r\u00e9elle, car ce sont les engagements qui comptent pendant une panne. Les p\u00e9nalit\u00e9s de service viennent ensuite, car vous ne pouvez les d\u00e9compter qu’une fois l’\u00e9cart d\u00e9montr\u00e9. Chaque point s’accompagne de la m\u00eame question : qui mesure, et o\u00f9 cet engagement est-il consign\u00e9 ? Une norme de SLA que vous ne pouvez pas retrouver au moment d\u00e9cisif n’est pas un instrument de pilotage. C’est un dossier.<\/p>\n\n\n\n La loi n\u00e9erlandaise sur la cybers\u00e9curit\u00e9 (Cbw), la transposition nationale de NIS2, est entr\u00e9e en vigueur le 15 ao\u00fbt 2026. Sans p\u00e9riode de transition g\u00e9n\u00e9rale. Environ 8 000 \u00e0 10 000 organisations y sont directement soumises, avec inscription au registre des entit\u00e9s via le NCSC.<\/p>\n\n\n\n Pour vous, en tant que responsable des contrats, l’enjeu porte sur la responsabilit\u00e9 de la cha\u00eene d’approvisionnement. La loi vous oblige \u00e0 ma\u00eetriser de mani\u00e8re d\u00e9montrable les cyberrisques issus de votre cha\u00eene de fournisseurs. Concr\u00e8tement : vous devez savoir quels fournisseurs TIC vous avez, quelles exigences de s\u00e9curit\u00e9 et de continuit\u00e9 figurent dans ces contrats, et quels engagements restent en suspens. C’est pr\u00e9cis\u00e9ment l’information qui, aujourd’hui, r\u00e9side de mani\u00e8re \u00e9parpill\u00e9e dans des PDF.<\/p>\n\n\n\n GRIP n’est pas un outil de cybers\u00e9curit\u00e9 et ne rend personne conforme \u00e0 NIS2. GRIP vous donne prise sur le volet contractuel de ce devoir de diligence, afin que vous puissiez d\u00e9montrer quelles exigences figurent dans quel contrat et ce qui reste en suspens. Le reste de votre politique de s\u00e9curit\u00e9 en est ind\u00e9pendant. Vous en apprendrez davantage sur ce volet contractuel dans cette explication sur NIS2 et les contrats fournisseurs<\/a>.<\/p>\n\n\n\n Dans la pratique, il est rare qu’un seul acteur fournisse un service complet. Prenez une application critique pour l’activit\u00e9 : elle tourne chez un fournisseur, l’h\u00e9bergement passe par un deuxi\u00e8me, et la gestion rel\u00e8ve d’un troisi\u00e8me. Chacun avec son propre SLA et sa propre d\u00e9finition de la disponibilit\u00e9. Trois contrats, trois normes, trois m\u00e9thodes de mesure.<\/p>\n\n\n\n En cas de panne, les responsabilit\u00e9s s’entrem\u00ealent. L’h\u00e9bergeur pointe vers le fournisseur applicatif, qui pointe \u00e0 son tour vers le prestataire de gestion. Et pendant ce temps, vous cherchez dans trois contrats diff\u00e9rents qui est responsable de quoi. Sans une vue d’ensemble o\u00f9 ces engagements figurent c\u00f4te \u00e0 c\u00f4te, vous perdez la discussion avant m\u00eame qu’elle ne commence.<\/p>\n\n\n\n La solution ne commence pas par un SLA plus strict ou un outil de surveillance suppl\u00e9mentaire. Vous en disposez probablement d\u00e9j\u00e0. La solution commence par une source unique dans laquelle la norme convenue, la performance mesur\u00e9e, les obligations en suspens et la dur\u00e9e du contrat se rejoignent.<\/p>\n\n\n\nPourquoi la surveillance technique n’est pas une surveillance des SLA<\/h2>\n\n\n\n
Quels engagements de SLA surveiller au niveau du contrat chez vos fournisseurs IT<\/h2>\n\n\n\n
\n
Que signifie la loi n\u00e9erlandaise sur la cybers\u00e9curit\u00e9 pour vos contrats IT ?<\/h2>\n\n\n\n
Le vrai probl\u00e8me : plusieurs fournisseurs, un seul service<\/h2>\n\n\n\n
L’engagement de SLA et la performance dans une seule source<\/h2>\n\n\n\n