Signer un contrat de service de sécurité informatique sans le lire comme un document opérationnel (et pas comme une simple “offre”) est l’une des erreurs les plus coûteuses pour une PME. Le risque n’est pas seulement de payer trop cher, c’est surtout de découvrir, le jour d’un incident, que “ce n’était pas inclus”, que les délais d’intervention ne sont pas définis, ou que personne n’est responsable de la notification RGPD.
Un bon contrat de cybersécurité doit répondre à une question simple : qui fait quoi, sur quoi, avec quels délais, quelles preuves, et quelle responsabilité.
Pourquoi un contrat de sécurité doit être plus précis qu’un contrat IT classique
Un contrat de sécurité n’est pas un contrat “de moyens” vague. Il encadre des activités où les attentes sont mesurables (détection, réaction, continuité) et où les conséquences juridiques et business sont immédiates (arrêt de production, fuite de données, extorsion, atteinte à l’image).
En France, les bonnes pratiques convergent vers une approche structurée “prévenir, détecter, réagir, se rétablir”, telle que promue par des organismes de référence comme l’ANSSI. Le contrat doit traduire cette logique en clauses claires, opposables et pilotables.
Les éléments indispensables d’un contrat de service de sécurité informatique
1) Le périmètre exact (et les exclusions)
C’est la base, et c’est souvent la zone la plus floue.
Le contrat doit préciser :
- Les actifs couverts : postes, serveurs, VM, firewall, Wi-Fi, Microsoft 365/Google Workspace, applications métiers, VPN, sites distants, télétravail.
- Les environnements : on-premise, cloud public, cloud privé, cloud local, hybride.
- Les plages horaires et zones géographiques (interventions à distance, sur site, multi-îles).
- Les exclusions : équipements non managés, applicatifs tiers non supportés, obsolescence non corrigée, systèmes non conformes aux prérequis.
À exiger : une annexe “inventaire et architecture de référence” mise à jour (au minimum à chaque changement majeur, idéalement en continu dans le cadre de l’infogérance).
2) Les niveaux de service (SLA) orientés sécurité
Un contrat de cybersécurité ne se limite pas à “support 24/7”. Il doit définir des SLA (engagements de service) et, si possible, des indicateurs techniques (SLI) avec objectifs (SLO).
Exemples utiles (à adapter) :
- Délai de prise en compte d’une alerte critique.
- Délai de qualification (vrai incident ou faux positif).
- Délai de contention (isolement d’un poste, blocage d’un compte, règle firewall).
- Délai de rétablissement (selon criticité, dépend aussi de vos PRA/PCA).
Astuce pratique : refusez les formulations du type “intervention dans les meilleurs délais”. Exigez des délais chiffrés, associés à une matrice de criticité.
3) La supervision et la détection (SOC, logs, alerting)
Si le prestataire propose une supervision de sécurité (ou un SOC), le contrat doit préciser :
- Les sources de logs (firewall, EDR/antivirus, serveurs, annuaire, messagerie, cloud, applications).
- La rétention (combien de temps les journaux sont conservés) et où ils sont stockés.
- Les cas d’usage couverts (détection de ransomware, authentifications anormales, exfiltration, élévation de privilèges).
- Le mode d’alerte : téléphone, ticket, mail, astreinte, escalade.
Sans ces points, “SOC” peut vouloir dire une simple console avec quelques alertes, ou une vraie capacité de corrélation et d’escalade. Ce n’est pas la même promesse, ni le même niveau de risque.
4) La gestion des incidents (runbook, escalade, preuves)
La clause “incident” est celle qui vous sauve, ou vous expose.
Le contrat doit inclure :
- Une définition d’incident de sécurité (et la différence avec un incident IT classique).
- Une procédure d’escalade nominative (qui appelle qui, et à partir de quel niveau).
- Les actions autorisées sans validation (par exemple : isoler un poste, réinitialiser un mot de passe, bloquer un compte compromis).
- Les livrables : rapport d’incident, chronologie, impacts, mesures correctives.
Pour les incidents impliquant des données personnelles, clarifiez aussi la coordination RGPD : qui collecte les faits, qui évalue la notification, qui rédige les éléments.
5) La prévention continue (vulnérabilités, correctifs, durcissement)
Un service de sécurité informatique sérieux ne peut pas être uniquement réactif.
Le contrat doit préciser :
- Le cadre de patch management : qui patch, quoi, à quelle fréquence, avec quelles fenêtres de maintenance.
- La gestion des vulnérabilités : scans (internes/externes), fréquence, priorité, suivi.
- Le durcissement (hardening) : politiques de mots de passe, MFA, verrouillage session, chiffrement, configuration firewall, segmentation réseau.
Point clé : la sécurité dépend souvent d’un partage de responsabilités. Le contrat doit rendre explicite ce qui relève de votre équipe et ce qui relève du prestataire.
6) Sauvegardes, PRA et continuité (RPO, RTO)
Dans beaucoup d’entreprises, “sécurité” et “continuité” sont traitées séparément, alors que le ransomware les relie.
À intégrer contractuellement :
- Exigences de sauvegarde (fréquence, copies hors ligne ou immuables si applicable, chiffrement, tests de restauration).
- Objectifs de continuité : RPO (perte de données acceptable) et RTO (temps de reprise).
- Règles de tests (au minimum tests périodiques de restauration).
Si vous avez déjà un chantier PRA, alignez le contrat avec votre stratégie. À ce sujet, vous pouvez vous appuyer sur le guide AITEC dédié au plan de reprise d’activité pour PME aux Antilles.
7) Confidentialité, RGPD et traitement des données
Même si votre objectif est “technique”, le contrat a des implications juridiques.
À vérifier :
- Les rôles RGPD : responsable de traitement, sous-traitant, sous-traitant ultérieur.
- La présence d’un accord de traitement des données (DPA) si le prestataire traite des données personnelles (support, logs, hébergement, sauvegarde).
- Les mesures de sécurité décrites (contrôles d’accès, chiffrement, journalisation).
- Les conditions de notification, d’assistance, et de conservation.
Références utiles : les ressources de la CNIL pour les obligations RGPD et la relation responsable de traitement/sous-traitant.
8) Gouvernance : reporting, comités, audits, plan d’amélioration
Sans gouvernance, vous pilotez “au ressenti”. Le contrat doit définir :
- La fréquence des reportings (mensuel, trimestriel) et leur contenu (incidents, tendances, patching, vulnérabilités, disponibilité).
- Les comités de pilotage (participants, ordre du jour type, décisions attendues).
- Les possibilités d’audit (technique, organisationnel) et les modalités.
Pour cadrer le démarrage, un audit initial est souvent le bon point d’entrée. AITEC détaille l’approche et l’intérêt d’un audit dans son article sur l’importance d’un audit IT.
9) Réversibilité et fin de contrat (le “plan de sortie”)
La réversibilité est trop souvent oubliée, puis devient un blocage.
Le contrat doit préciser :
- Ce qui vous est restitué : configurations, documentations, inventaires, procédures, journaux, éléments de preuve.
- Les formats (export) et délais.
- L’accompagnement à la transition (vers un autre prestataire ou en interne).
- Le sort des accès, comptes, clés, certificats.
Objectif : éviter que la sécurité devienne une dépendance opaque.
10) Responsabilités, limites, assurances et sous-traitance
Vous devez comprendre le régime de responsabilité :
- Obligation de moyens vs obligation de résultat (selon la prestation).
- Limites de responsabilité et exclusions (à lire mot à mot).
- Gestion des sous-traitants (sous-traitant ultérieur, localisation, engagement).
- Assurances professionnelles.
Attention : une limitation de responsabilité trop basse peut rendre le contrat inutile en pratique. À l’inverse, un prestataire sérieux expliquera ce qu’il prend en charge, et ce qui dépend de vos décisions (par exemple, refuser un patch critique).
Tableau de contrôle : les clauses à exiger (et les preuves à demander)
| Partie du contrat | Ce qui doit être écrit clairement | Ce que vous devez obtenir (preuve) |
|---|---|---|
| Périmètre | Liste des actifs, sites, utilisateurs, environnements, exclusions | Inventaire, schéma d’architecture, liste des prérequis |
| SLA sécurité | Délais chiffrés par criticité, plages horaires, astreinte | Matrice de criticité, exemples de tickets, procédure d’escalade |
| Détection/SOC | Sources de logs, corrélation, rétention, stockage, alerting | Modèle de rapport, liste de cas d’usage, rétention écrite |
| Incidents | Runbook, actions autorisées, rapport post-incident, RACI | Procédure incident, modèle de rapport, contacts d’urgence |
| Vulnérabilités/patching | Fréquence, responsabilités, fenêtres de maintenance | Planning type, workflow validation, exemples de recommandations |
| Sauvegardes/PRA | RPO/RTO, tests, responsabilité restauration | Compte-rendu de tests, procédure de restauration |
| RGPD/confidentialité | DPA, sous-traitants, localisation, notification | DPA signé, liste des sous-traitants, mesures techniques |
| Gouvernance | Reportings, comités, KPI, plan d’amélioration | Exemple de tableau de bord, calendrier des comités |
| Réversibilité | Restitution, délais, formats, assistance de transition | Clause de sortie, liste livrables, délais garantis |
| Financier | Forfait vs à l’acte, conditions de changement, pénalités | Grille tarifaire, conditions de révision, règles hors périmètre |
Les “signaux d’alerte” dans un contrat de cybersécurité
Voici des points qui méritent au minimum une renégociation ou un éclaircissement écrit :
- SLA sans délais chiffrés, ou seulement des délais “de prise en charge” sans délai de résolution.
- SOC annoncé sans précision sur les logs, la rétention, l’escalade, ni rapports.
- Clause RGPD absente alors que le prestataire a accès à des données (support, sauvegarde, supervision).
- Réversibilité floue, payante sans cadrage, ou dépendante d’un “temps passé” non plafonné.
- Exclusions trop larges (par exemple “tout incident provenant d’un mail” ou “tout incident lié à une mise à jour”).
Spécificités Antilles-Guyane : ce que votre contrat doit anticiper
Dans les Antilles et en Guyane, quelques réalités opérationnelles doivent apparaître noir sur blanc :
- Interventions sur site : délais, conditions, coûts éventuels, stock de matériel, continuité en cas d’indisponibilité de transport.
- Connectivité : procédures en cas de coupure Internet, accès de secours, priorisation des actions à distance.
- Hébergement et localisation : si vous recherchez de la proximité (latence, souveraineté, support), formalisez les attentes de localisation et de support.
Selon votre stratégie, il peut aussi être pertinent d’aligner le contrat de cybersécurité avec votre contrat d’infogérance aux Antilles-Guyane, afin d’éviter les zones grises entre “exploitation” et “sécurité”.
FAQ
Un contrat de service de sécurité informatique doit-il forcément inclure un SOC 24/7 ? Non. Tout dépend de votre exposition et de votre budget. En revanche, le contrat doit préciser votre niveau de surveillance (horaires, délais, sources de logs) pour éviter les attentes implicites.
Quelle différence entre SLA “support” et SLA “sécurité” ? Le SLA support traite souvent la disponibilité et les incidents utilisateurs. Le SLA sécurité doit cadrer la détection, la qualification, la contention et le reporting d’incidents cyber.
Que doit contenir la clause RGPD avec un prestataire cybersécurité ? Au minimum, les rôles (responsable/sous-traitant), un DPA si nécessaire, les mesures de sécurité, la gestion des sous-traitants et l’assistance en cas de violation de données.
Comment cadrer la réversibilité sans se faire piéger ? En listant précisément les livrables à restituer, les formats, les délais et l’assistance de transition. Une réversibilité “au temps passé” sans plafond est un risque.
Faut-il exiger des pénalités si les SLA ne sont pas tenus ? C’est recommandé lorsque le service est critique. À défaut de pénalités, exigez au minimum des mécanismes de pilotage (KPI, comités, plan d’amélioration) et des engagements de transparence.
Besoin d’un regard expert sur votre contrat ou votre périmètre de sécurité ?
Si vous comparez plusieurs prestataires, ou si vous souhaitez sécuriser un contrat existant, un audit court (périmètre, risques, niveaux de service attendus) permet souvent d’éviter les angles morts.
AITEC accompagne les entreprises en Martinique, Guadeloupe et Guyane sur l’infogérance et la cybersécurité, avec une expertise locale et un support adapté. Vous pouvez demander un audit et un échange pour cadrer un contrat de service de sécurité informatique réellement opérationnel via le site AITEC.
