Un service SaaS critique tombe en panne. Le responsable IT et le responsable des contrats cherchent ensemble le bon contrat sur un disque partagé. Quel était déjà le délai de rétablissement convenu ? Avons-nous droit à des pénalités de service ? Ce contrat arrive-t-il bientôt à échéance ? Quarante minutes plus tard, ils ont retrouvé le PDF, mais la panne persiste toujours. C’est à ce moment précis que vous réalisez que vous ne gérez pas réellement vos SLA. Vous vous contentez de les conserver.
Surveiller les SLA des fournisseurs IT ne revient pas à vérifier si un service fonctionne techniquement. La question est de savoir si l’engagement contractuel est respecté : la disponibilité, le délai de réponse, le délai de rétablissement et la compensation en cas d’écart. Ces engagements figurent dans des PDF, pas dans votre système. Et c’est là que le problème commence. Selon une étude de WorldCC, PwC et McKinsey, 95 pour cent des organisations n’ont pas une vision complète de leurs propres obligations contractuelles. Pour les contrats IT, avec leurs piles d’annexes, ce problème est le plus aigu.
Votre ERP sait qui est votre fournisseur IT, mais pas ce que vous avez convenu
Votre ERP ou votre système de gestion des dépenses fait exactement ce pour quoi il a été conçu. Il enregistre le fournisseur, le montant du contrat et les factures. Il rapproche les bons de commande et suit la durée du contrat. Pour la base administrative, c’est parfait.
Mais l’ERP ne connaît pas les normes du SLA. Il ne sait pas que vous avez convenu avec cet hébergeur une disponibilité de 99,9 pour cent. Il ne sait pas non plus que le délai de réponse pour un incident de priorité 1 est de quinze minutes. Ce contenu se trouve dans l’annexe du contrat. Et personne ne lit cette annexe au moment où les choses tournent mal.
La différence est celle qui existe entre l’enregistrement et la gestion. Votre système enregistre le fait que vous avez un contrat. Le contenu de ce contrat, les engagements et les obligations en cours, réside ailleurs. Le plus souvent dans Word, dans des PDF et dans la tête de quelques personnes. L’enregistrement reste dans votre système. La gestion, elle, se fait dans un tableau de bord des contrats au-dessus de ce système.
Pourquoi la surveillance technique n’est pas une surveillance des SLA
En tant que responsable IT, vous avez probablement une surveillance de la disponibilité en place. Un tableau de bord qui vérifie si un service est accessible et envoie une alerte en cas d’interruption. Utile, mais cela répond à une question technique : le service fonctionne-t-il encore ?
C’est différent de la question contractuelle : l’engagement est-il respecté ? Un service peut être techniquement disponible et pourtant se situer hors de la norme convenue, par exemple parce que le délai de réponse aux incidents est structurellement dépassé. Mesurer la disponibilité ne vous dit rien sur les pénalités de service, les procédures d’escalade ou les obligations de rétablissement.
Il y a un autre problème. Le rapport mensuel sur les performances provient souvent du fournisseur lui-même. C’est le boucher qui juge sa propre viande. Sans votre propre source dans laquelle la norme convenue figure à côté de la performance mesurée, vous n’avez aucun contrepoids indépendant. Vous croyez ce que le fournisseur rapporte, ou vous menez la vérification manuellement.
Quels engagements de SLA surveiller au niveau du contrat chez vos fournisseurs IT
Pour surveiller les SLA de vos fournisseurs IT au niveau du contrat, vous consignez pour chaque contrat ce qui a été convenu et si cet engagement est tenu. L’essentiel :
- Disponibilité : le pourcentage de disponibilité convenu et les plages de service durant lesquelles il s’applique
- Délai de réponse : le temps dans lequel le fournisseur réagit à un incident, par niveau de priorité
- Délai de rétablissement (MTTR) : le temps dans lequel un incident doit être résolu
- Nombre d’incidents : combien de pannes surviennent, et cela reste-t-il dans les limites convenues
- Pénalités de service : quelle compensation vous est due en cas d’écart structurel, et est-elle effectivement décomptée
Ne commencez pas par les cinq points en même temps. Placez d’abord la disponibilité et le délai de rétablissement à côté de la performance réelle, car ce sont les engagements qui comptent pendant une panne. Les pénalités de service viennent ensuite, car vous ne pouvez les décompter qu’une fois l’écart démontré. Chaque point s’accompagne de la même question : qui mesure, et où cet engagement est-il consigné ? Une norme de SLA que vous ne pouvez pas retrouver au moment décisif n’est pas un instrument de pilotage. C’est un dossier.
Que signifie la loi néerlandaise sur la cybersécurité pour vos contrats IT ?
La loi néerlandaise sur la cybersécurité (Cbw), la transposition nationale de NIS2, est entrée en vigueur le 15 août 2026. Sans période de transition générale. Environ 8 000 à 10 000 organisations y sont directement soumises, avec inscription au registre des entités via le NCSC.
Pour vous, en tant que responsable des contrats, l’enjeu porte sur la responsabilité de la chaîne d’approvisionnement. La loi vous oblige à maîtriser de manière démontrable les cyberrisques issus de votre chaîne de fournisseurs. Concrètement : vous devez savoir quels fournisseurs TIC vous avez, quelles exigences de sécurité et de continuité figurent dans ces contrats, et quels engagements restent en suspens. C’est précisément l’information qui, aujourd’hui, réside de manière éparpillée dans des PDF.
GRIP n’est pas un outil de cybersécurité et ne rend personne conforme à NIS2. GRIP vous donne prise sur le volet contractuel de ce devoir de diligence, afin que vous puissiez démontrer quelles exigences figurent dans quel contrat et ce qui reste en suspens. Le reste de votre politique de sécurité en est indépendant. Vous en apprendrez davantage sur ce volet contractuel dans cette explication sur NIS2 et les contrats fournisseurs.
Le vrai problème : plusieurs fournisseurs, un seul service
Dans la pratique, il est rare qu’un seul acteur fournisse un service complet. Prenez une application critique pour l’activité : elle tourne chez un fournisseur, l’hébergement passe par un deuxième, et la gestion relève d’un troisième. Chacun avec son propre SLA et sa propre définition de la disponibilité. Trois contrats, trois normes, trois méthodes de mesure.
En cas de panne, les responsabilités s’entremêlent. L’hébergeur pointe vers le fournisseur applicatif, qui pointe à son tour vers le prestataire de gestion. Et pendant ce temps, vous cherchez dans trois contrats différents qui est responsable de quoi. Sans une vue d’ensemble où ces engagements figurent côte à côte, vous perdez la discussion avant même qu’elle ne commence.
L’engagement de SLA et la performance dans une seule source
La solution ne commence pas par un SLA plus strict ou un outil de surveillance supplémentaire. Vous en disposez probablement déjà. La solution commence par une source unique dans laquelle la norme convenue, la performance mesurée, les obligations en suspens et la durée du contrat se rejoignent.
C’est ce que fait le tableau de bord des contrats de GRIP. Pour chaque contrat TIC, vous consignez les SLA convenus et vous placez la performance à côté. En cas de panne, vous voyez en quelques secondes quel est le délai de rétablissement convenu et si vous avez droit à une compensation. Lors d’un renouvellement, vous savez si ce fournisseur a tenu son SLA au cours des dernières années. Vous négociez alors sur des chiffres, et non sur une intuition.
GRIP ne mesure pas votre disponibilité. GRIP est l’endroit où l’engagement, les obligations et la performance se rejoignent. L’enregistrement reste dans votre ERP, la gestion se fait dans GRIP. Selon les propres chiffres de GRIP, les organisations qui abordent cela de manière structurée économisent jusqu’à 30 pour cent sur leur administration des contrats. GRIP est certifié ISO 27001 pour la sécurité de l’information et ISO 9001 pour la gestion de la qualité, avec l’ensemble des données contractuelles traitées en Europe.
Questions fréquentes
Quelle est la différence entre la surveillance des SLA et la surveillance de la disponibilité ?
La surveillance de la disponibilité mesure si un service est techniquement accessible. La surveillance des SLA vérifie si l’engagement contractuel est respecté : délai de réponse, délai de rétablissement, pénalités de service et procédures d’escalade. Un service peut fonctionner et pourtant se situer hors de la norme convenue.
Mon ERP peut-il surveiller les SLA de mes fournisseurs IT ?
Votre ERP enregistre le fournisseur, le montant du contrat et les factures, mais il ne connaît pas les normes de SLA ni les obligations en suspens. Ce contenu réside dans les annexes des contrats. Pour cela, vous avez besoin d’une couche de gestion des contrats au-dessus de votre ERP.
Quels indicateurs de SLA dois-je surveiller chez mes fournisseurs IT ?
L’essentiel porte sur la disponibilité, le délai de réponse, le délai de rétablissement (MTTR), le nombre d’incidents et les pénalités de service auxquelles vous avez droit en cas d’écart. Consignez pour chaque contrat qui mesure et où l’engagement est enregistré.
Que signifie la loi sur la cybersécurité pour mes contrats fournisseurs ?
Depuis le 15 août 2026, la Cbw vous oblige à maîtriser de manière démontrable les cyberrisques issus de votre chaîne de fournisseurs. Vous devez savoir quels fournisseurs TIC vous avez, quelles exigences de sécurité et de continuité figurent dans les contrats et quels engagements restent en suspens.
GRIP rend-il mon organisation conforme à NIS2 ?
Non. GRIP n’est ni un outil de cybersécurité ni un outil de conformité. GRIP vous donne prise sur le volet contractuel du devoir de diligence, afin d’avoir une vue démontrable des exigences figurant dans chaque contrat et de ce qui reste en suspens.
Comment garder une vue d’ensemble lorsque plusieurs fournisseurs IT fournissent ensemble un seul service ?
Dans les environnements multifournisseurs, vous placez les SLA de tous les contrats concernés côte à côte dans une source unique. Ainsi, en cas de panne, vous voyez immédiatement qui est responsable de quoi, au lieu de chercher dans plusieurs contrats.
Puis-je utiliser les performances de SLA lors du renouvellement d’un contrat ?
Oui. Si vous consignez pour chaque contrat si le SLA a été respecté, vous disposez, lors d’un renouvellement ou d’une renégociation, d’une position de négociation factuelle plutôt que d’une simple intuition.
Vous souhaitez voir comment réunir les engagements de SLA et les performances de vos fournisseurs IT dans une seule vue d’ensemble ? Découvrez le tableau de bord des contrats ou réservez une démonstration de GRIP.