Modèle de contrat d’audit de sécurité gratuit (Word)

Sommaire

1. Quand utiliser ce contrat, et quand il ne convient pas
2. Ce que dit le droit français
3. Ce que contient ce modèle, article par article
4. Les pièges à éviter
5. Comment adapter ce modèle à votre situation
6. Ce que ce modèle ne remplace pas

Quand utiliser ce contrat, et quand il ne convient pas

Vous confiez un test d’intrusion sur vos systèmes. Une entreprise qui souhaite éprouver la sécurité de son application web, de son réseau ou de son infrastructure mandate un prestataire pour simuler des attaques et identifier les failles. Le contrat fixe le cahier des charges de la mission : systèmes visés, méthode retenue (boîte noire, grise ou blanche), fenêtres d’intervention et livrables attendus. Il transforme une opération sensible en cadre juridique maîtrisé.

Vous êtes prestataire d’audit et formalisez votre mission. Un cabinet SSI, un consultant indépendant ou une équipe spécialisée qui réalise des audits a besoin d’un contrat qui protège son intervention. L’enjeu est double : disposer d’une autorisation écrite couvrant exactement le périmètre testé, et cadrer sa responsabilité au regard des risques inhérents à toute manipulation de systèmes en production.

L’audit touche des systèmes traitant des données personnelles. Dès que les systèmes audités hébergent ou traitent des données de clients, de salariés ou de tiers, l’auditeur qui y accède peut agir comme sous-traitant au sens de l’article 28 du RGPD. Le contrat doit alors être adossé à un acte de sous-traitance et préciser le sort des données consultées ou collectées.

L’audit implique des sous-traitants ou des outils tiers. Lorsque le prestataire fait appel à des experts externes ou à des plateformes d’analyse, le contrat encadre cette sous-traitance : autorisation préalable du client, engagement de confidentialité en cascade, responsabilité du prestataire principal pour les tiers qu’il s’adjoint.

Quand ce modèle ne convient pas. Si la mission consiste principalement à corriger ou à administrer les systèmes, la qualification relève de l’infogérance ou de la maintenance, non de l’audit. Si le client est un opérateur d’importance vitale (OIV) ou une entité soumise à la réglementation NIS, des obligations réglementaires spécifiques s’ajoutent et appellent un encadrement dédié. Si l’audit vise une certification réglementée, le référentiel applicable prime sur le modèle générique. [À VÉRIFIER JURISTE : périmètre exact des obligations pesant sur les OIV et entités NIS2 selon le statut du commanditaire.]

Ce que dit le droit français

L’audit de sécurité est une prestation de services, non une vente. Le contrat d’audit de sécurité s’analyse en contrat d’entreprise, forme de louage d’ouvrage régie par les articles 1710 et 1779 du Code civil et par le droit commun des contrats. L’auditeur exécute une prestation intellectuelle et technique pour le compte du commanditaire, sans lien de subordination. Sa formation obéit aux conditions de validité des articles 1101 et suivants et 1128 du Code civil, et à l’obligation d’information précontractuelle de l’article 1112-1.

L’auditeur est en principe tenu d’une obligation de moyens. Rechercher des vulnérabilités suppose de l’expertise et de la diligence, sans garantie d’exhaustivité : aucun audit ne prouve l’absence totale de faille. L’auditeur relève donc d’une obligation de moyens, sauf pour des livrables déterminés, comme la remise d’un rapport à une échéance, qui peuvent relever d’une obligation de résultat. La responsabilité contractuelle se fonde sur l’article 1231-1 du Code civil, qui suppose une faute, un dommage et un lien de causalité.

L’autorisation écrite préalable est une condition de licéité. C’est le point le plus sensible de ce contrat. Sans mandat écrit couvrant le périmètre exact, l’auditeur qui accède à un système s’expose aux atteintes aux systèmes de traitement automatisé de données : accès et maintien frauduleux (article 323-1 du Code pénal), entrave au fonctionnement (article 323-2), atteinte aux données (article 323-3), et détention d’outils dédiés (article 323-3-1). Le mandat doit être daté, signé par une personne habilitée du système d’information et strictement borné aux systèmes, plages d’adresses IP et horaires convenus.

La confidentialité et le secret des affaires structurent la relation. L’auditeur découvre des informations parmi les plus sensibles de l’entreprise : architecture, failles, données. La confidentialité est renforcée par la protection du secret des affaires prévue aux articles L. 151-1 et suivants du Code de commerce. Le contrat organise le sort des vulnérabilités identifiées, dont la divulgation prématurée exposerait le commanditaire.

Le rapport d’audit est protégé par le droit d’auteur. Le rapport, produit intellectuel structuré, constitue une œuvre susceptible de protection au titre de l’article L. 111-1 du Code de la propriété intellectuelle. À défaut de clause organisant la propriété du livrable, l’auditeur conserve ses droits d’auteur. Le contrat précise donc la remise du rapport et l’étendue de l’usage concédé au commanditaire.

Les données personnelles éventuellement traitées relèvent du RGPD. Si l’audit conduit l’auditeur à accéder à des données personnelles hébergées sur les systèmes testés, il agit comme sous-traitant et l’article 28 du RGPD impose un acte juridique contraignant. Par ailleurs, la divulgation de bonne foi d’une vulnérabilité à l’Agence nationale de la sécurité des systèmes d’information (ANSSI) bénéficie de la protection de l’article L. 2321-4 du Code de la défense. Pour les commanditaires soumis à des régimes sectoriels (OIV au titre des articles L. 1332-6-1 et suivants du Code de la défense, entités NIS), des obligations supplémentaires s’appliquent. [À VÉRIFIER JURISTE : référence exacte de la loi de transposition NIS2 et statut du référentiel PASSI de l’ANSSI, non codifié.]

Ce que contient ce modèle, article par article

Article 1. Objet et périmètre de l’audit. L’article fondateur décrit la mission : nature de l’audit (test d’intrusion, audit de configuration, revue de code), systèmes et applications concernés, plages d’adresses IP, méthode retenue (boîte noire, grise ou blanche) et exclusions expresses. Un périmètre flou est la première source de litige et le principal risque pénal ; il doit être arrêté sans ambiguïté.

Article 2. Autorisation d’intervention. Le cœur du dispositif. Le commanditaire déclare être titulaire des droits sur les systèmes testés et autorise expressément l’auditeur à y accéder dans les limites du périmètre. L’autorisation est datée, signée par une personne habilitée et annexée au contrat. Elle constitue le mandat qui écarte la qualification d’accès frauduleux au sens des articles 323-1 et suivants du Code pénal.

Article 3. Modalités d’exécution et réception. Fenêtres d’intervention, mesures de précaution pour éviter toute interruption de service, points de contact, procédure d’alerte en cas de découverte critique, puis remise et validation des livrables. L’article distingue les phases de l’audit et fixe les conditions de recette du rapport.

Article 4. Obligation de moyens et diligence. Le modèle qualifie expressément la prestation en obligation de moyens, tout en identifiant les livrables déterminés soumis à un engagement de résultat. Cette qualification commande le régime de responsabilité et doit refléter la réalité de la mission.

Article 5. Confidentialité et secret des affaires. L’auditeur s’engage à ne divulguer aucune information découverte, en particulier les vulnérabilités identifiées. L’article précise la durée de l’obligation de confidentialité, qui survit à la fin du contrat, et s’appuie sur la protection du secret des affaires du Code de commerce.

Article 6. Sécurité et sort des données collectées. L’article détaille les mesures de sécurité que l’auditeur applique aux preuves, journaux et données recueillis pendant l’audit, puis organise leur restitution et leur suppression à l’issue de la mission, avec preuve de destruction. Si des données personnelles sont concernées, il renvoie à un acte de sous-traitance conforme à l’article 28 du RGPD.

Article 7. Propriété du rapport. L’article organise le sort du livrable : remise du rapport au commanditaire, étendue de l’usage concédé, restrictions de diffusion. Il évite que la titularité des droits d’auteur de l’auditeur ne prive le commanditaire d’un usage utile du document.

Article 8. Assurance et responsabilité. L’auditeur justifie d’une assurance de responsabilité civile professionnelle adaptée aux risques de la mission. L’article fixe un plafond de responsabilité et une limitation, dans le respect des bornes légales, et rappelle que ces stipulations ne jouent ni pour la faute lourde ou dolosive, ni au point de vider l’obligation essentielle de sa substance.

Article 9. Non-interruption du service. L’auditeur s’engage à conduire ses tests de manière à ne pas compromettre la disponibilité des systèmes en production, avec une procédure d’arrêt immédiat en cas d’incident. Cet article protège le commanditaire contre le risque d’indisponibilité provoqué par l’audit lui-même.

Article 10. Sous-traitance. L’article encadre le recours de l’auditeur à des tiers, soumis à autorisation préalable du commanditaire et à un engagement de confidentialité équivalent. Le prestataire principal demeure responsable des sous-traitants qu’il s’adjoint.

Article 11. Prix et modalités de paiement. Montant de la prestation, échéancier, délai de paiement conforme au plafond de l’article L. 441-10 du Code de commerce, pénalités de retard. La rémunération peut être forfaitaire ou fondée sur un nombre de jours d’audit.

Article 12. Droit applicable et litiges. Droit français, langue du contrat et attribution de juridiction, le cas échéant précédées d’une étape de règlement amiable.

Les pièges à éviter

Intervenir sans autorisation écrite bornée. C’est le risque majeur. Un audit conduit sans mandat daté, signé par une personne habilitée et strictement limité au périmètre convenu expose l’auditeur aux poursuites pénales des articles 323-1 et suivants du Code pénal, même avec l’accord verbal du client. Toute extension du périmètre en cours de mission exige une autorisation complémentaire écrite, jamais un simple courriel ambigu.

Laisser le périmètre imprécis. Un cahier des charges qui ne liste ni les systèmes, ni les plages d’adresses IP, ni les exclusions ouvre la porte à deux dangers : l’auditeur qui déborde sur des systèmes non couverts, et le commanditaire déçu de ne pas voir tester ce qu’il croyait inclus. Le périmètre se décrit de façon exhaustive et se fige avant le début des tests.

Promettre une sécurité garantie. Rédiger le contrat comme si l’audit certifiait l’absence de faille transforme une obligation de moyens en obligation de résultat que nul auditeur sérieux ne peut tenir. L’audit établit un état des lieux à un instant donné ; il ne délivre pas un brevet d’invulnérabilité. La qualification de la prestation doit rester fidèle à cette réalité.

Négliger le sort des données collectées. Un audit produit des preuves, des journaux et parfois des extractions de données sensibles. Sans clause organisant leur restitution puis leur suppression avec preuve, ces éléments demeurent chez l’auditeur et constituent un risque durable pour le commanditaire. La destruction doit être documentée, pas simplement promise.

Omettre l’assurance et la non-interruption de service. Tester un système en production peut provoquer une indisponibilité. Un contrat qui ne prévoit ni assurance de responsabilité civile professionnelle, ni engagement de précaution, ni procédure d’arrêt d’urgence laisse le commanditaire sans recours utile si l’audit dégrade le service. Ces garanties se vérifient avant le lancement, pas après l’incident.

Comment adapter ce modèle à votre situation

Quelques champs se renseignent systématiquement : l’identité des parties, la description de la mission et de son périmètre, la méthode retenue, le prix et le calendrier. Le reste du texte convient à la plupart des audits de sécurité courants.

L’autorisation d’intervention mérite le plus grand soin. C’est elle qui distingue une prestation licite d’une infraction pénale. Vérifiez que la personne qui signe dispose bien du pouvoir d’engager l’entreprise sur ses systèmes, que le périmètre annexé correspond exactement à ce qui sera testé, et que toute extension fera l’objet d’un avenant écrit. Pour un audit en boîte blanche, précisez les accès et informations fournis à l’auditeur.

L’encadrement des données s’ajuste selon la nature des systèmes audités. Dès que l’audit peut conduire à accéder à des données personnelles, l’acte de sous-traitance conforme à l’article 28 du RGPD n’est pas optionnel, et le sort des données collectées doit être arrêté noir sur blanc. Si le commanditaire est soumis à un régime sectoriel, comme le statut d’OIV ou les obligations issues de la réglementation NIS, ajoutez les engagements réglementaires correspondants.

Adaptez enfin la clause de propriété du rapport et le plafond de responsabilité au contexte. Un audit ponctuel appelle une remise simple du livrable au commanditaire ; une mission récurrente ou un audit destiné à être communiqué à des tiers, comme un client ou un régulateur, impose de préciser l’étendue exacte de la diffusion autorisée.

Ce que ce modèle ne remplace pas

Un modèle est un point de départ, pas un avis. Il ne connaît ni le statut réglementaire du commanditaire, ni la sensibilité exacte des systèmes testés, ni le rapport de force entre les parties. Trois situations appellent une relecture par un professionnel : un commanditaire soumis à un régime sectoriel spécifique, comme le statut d’opérateur d’importance vitale ou les obligations issues de la transposition de la directive NIS2 ; un audit impliquant l’accès à des données personnelles à grande échelle ou à des données sensibles, qui appelle un acte de sous-traitance renforcé ; et une mission dont le périmètre touche des systèmes hébergés chez des tiers, dont l’autorisation propre doit alors être obtenue.

C’est la raison pour laquelle ce modèle signale ses propres limites, plutôt que de se présenter comme suffisant en toute circonstance.