29 mars 2018

Brève - Actualités - CYBERSECURITE - Transposition de la Directive Européenne 2016/1148 "Network Information Security" (NIS)


La loi transposant en France la Directive européenne « Network Information Security » (NIS) de 2016 a été promulguée le 26 février 2018, devançant de quelques semaines la date butoir fixée au 9 mai. C’est une pièce maîtresse dans l’arsenal destiné à prévenir et limiter les effets de cyber-attaques pouvant toucher des secteurs clés de la société civile et de l’économie. Elle accroît les obligations et risques de certaines entreprises en matière de cyber-sécurité.

Jusqu’à présent, seule une catégorie limitée d’acteurs qualifiés d’« opérateurs d’importance vitale » (OIV) par la loi de programmation militaire de 2013 étaient soumis à des obligations très strictes en matière de cyber-sécurité. Eu égard à l’importance des enjeux et à la multiplication des attaques touchant d’autres secteurs d’activités tenus pour stratégiques (énergie, transport, banques et marchés financiers, santé, eau, infrastructures numériques…), la Directive étend certaines obligations à d’autres entreprises, qualifiées d’« opérateurs de services essentiels » (OSE), bien plus importantes en nombre.

La France a jusqu’au 9 novembre 2018 pour déterminer la liste des OSE affectés par les nouvelles règles de sécurité informatique, précisées et appliquées sous l’impulsion et le contrôle de l’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI), laquelle disposera d’un pouvoir d’audit et de sanctions. Ces OSE auront par exemple pour obligations de : (i) mettre en œuvre les nouveaux dispositifs adoptés, (ii) notifier à l’autorité administrative tout incident de sécurité et (iii) se soumettre, à leurs frais, aux contrôles imposés. En outre, bien que plus légères que celles pesant sur ces OSE, la loi renforce les obligations des « fournisseurs de services numériques » (FSN), à savoir : les places de marché en ligne, moteurs de recherche ou fournisseurs de services « cloud » actifs au sein de l’Union européenne. Ils devront aussi notifier les incidents de sécurité et encourent des sanctions financières en cas de manquement.

En cas de non-respect de ces obligations ou d’entrave au contrôle, les entreprises encourront des sanctions allant de 75.000 à 125.000 €. Sans parler des risques liés à la publication des atteintes à la sécurité qui pourra être décidée par l’ANSSI et à la pratique en vogue sur les réseaux sociaux du « name and shame » contre les firmes impliquées. Enfin, nous rappellerons que 77% des attaques des hackers sont dirigées contre des PME. Aucune entreprise n’est à l’abri du risque !

12 mars 2018

Newsletter - Le Réglement "RGPD" en 80 Jours

Se mettre en conformité d’ici le 25 mai prochain avec le Règlement Général sur la Protection des Données (RGPD) est encore possible !
Accroissement des droits des personnes protégées. Le RGPD apporte des nouveautés importantes et approfondit bon nombre de droits des personnes concernées, tels que le droit à la portabilité des données personnelles, le « droit à l’oubli » ou le droit de ne pas faire l’objet de profilages, et accroît les obligations de sécurité et d’information du responsable du traitement et de son (ou ses) sous-traitant(s).
Data Protection Officer et responsabilités accrues du responsable du traitement. Le règlement européen modifie les relations entre responsable du traitement et sous-traitant et transforme le correspondant informatique et libertés (CIL) en « délégué à la protection des données » (DPO ou « Data Protection Officer »). La contrepartie de l’allégement des formalités administratives, c’est un poids accru de ce DPO mais aussi de nouvelles responsabilités mises à la charge du responsable du traitement (ex : étude d’impact sur la vie privée et notification des failles de sécurité aux personnes concernées et aux autorités de contrôle).
Analyse d’impact. C’est une dernière nouveauté. « L’analyse d’impact » évalue la nécessité et l’absence du caractère excessif des traitements de données par rapport à leur finalité. Toutefois, seuls les traitements « susceptibles d’engendrer un risque élevé pour les droits et libertés des personnes physiques » l’exigeront.
Accroissement des sanctions et des risques liés aux contrôles. Enfin, de nouvelles amendes administratives et sanctions (notamment financières) voient le jour en cas de violation. L’importance des contrôles a posteriori des autorités nationales (en France, par la CNIL) se voit également renforcée par la disparition des déclarations préalables.
Rappelons aussi que toute violation du RGPD par le responsable du traitement ou son sous-traitant est susceptible de conduire à la réparation intégrale du préjudice subi par les personnes affectées. Ainsi, eu égard aux standards actuels, le niveau de protection des personnes et les risques liés à la gestion de données sont accrus.
Quelles solutions ? Quelle stratégie ? Que faire ? Il vous faut agir, et commencer par identifier les besoins de votre structure et vous poser les bonnes questions. Faut-il par exemple adapter vos conditions générales de vente B2C ? Modifier vos contrats de sous-traitance portant sur la gestion de données ? Changer vos pratiques internes et mettre en place de nouvelles procédures ? Etc. Le nombre de questions et de changements à apporter dépendent de votre entreprise.
Illustrons notre propos par un exemple concret. La vérification et l’encadrement des engagements de vos prestataires (« sous-traitants ») sont d’autant plus indispensables qu’ils participent pleinement de la mise en conformité de votre entreprise (en qualité de « responsable du traitement ») avec les exigences nouvelles du RGPD. Eu égard aux obligations nouvelles des sous-traitants, le contrat de sous-traitance devra désormais prévoir notamment les éléments suivants :
·         la ou les finalités du traitement (à ce jour, seule la nature des prestations confiées au sous-traitant y figure) ;
·         la nature des données traitées par le sous-traitant ;
·         le type de personnes concernées par la collecte et le ou les traitements ;
·         le sort des données gérées à l’expiration du contrat ;
·         les engagements pris par le sous-traitant en termes de traitement et de sécurité des données (le responsable du traitement est plus que jamais tenu de les définir) ;
·         les mesures garantissant la protection des données personnelles dès l’origine des projets de traitement, dite aussi privacy by design (principe complété par celui de security by default qui veut dire que, par défaut, seules pourront être collectées les données nécessaires pour assurer la finalité de chaque traitement envisagé) ;
·         l’obligation de créer et tenir à jour une documentation concernant les mesures (techniques et organisationnelles) destinées à sécuriser les données personnelles ;
·         la définition de la collaboration entre les parties, notamment pour la mise en œuvre des droits des personnes concernées et pour régir les relations des parties au contrat de sous-traitance avec les autorités de contrôle ;
·         les mesures d’urgence à adopter par les parties en cas de fuite de données…

Cet exemple n’est qu’un cas concret parmi d’autres à traiter en vue de la mise en conformité de votre entreprise avec le RGPD dans les douze semaines qui vous séparent de son entrée en vigueur ! Le plus important est de lancer ce chantier si cela n’est pas encore fait.

L’équipe d’avocats spécialisés de KOBALT se tient à votre disposition pour vous aider à redéfinir votre stratégie de protection des données traitées et vous assurer de la mise en conformité de votre entreprise.


20 juin 2016

La clause de "recette" dans les contrats de prestations informatiques

FICHE PRATIQUE

 

CLAUSE ESSENTIELLE DES CONTRATS INFORMATIQUES

Clause essentielle des contrats de fourniture de développements logiciels ou d’une solution ou portant sur l’intégration de progiciels, la clause de « recette » présente la particularité d’être à la fois très juridique et très opérationnelle. Autrement dit, elle s’adresse et doit « parler » autant au juriste qu’aux personnels chargés de la conduite du projet, aussi bien côté client (« MOA ») que côté prestataire.


Objet de la clause de recette

Dans les contrats informatiques, elle a pour double objet d’organiser la « délivrance » conforme des documents et logiciels attendus par le client et sa « réception » au sens juridique du terme par le client (notions définies dans le Code Civil), c’est-à-dire la vérification de l’aptitude des "livrables" à être exploités conformément aux besoins exprimés par le maître de l'ouvrage au sein d’un référentiel défini par avance dans le contrat (tels que : cahier des charges, spécifications fonctionnelles et techniques détaillées, compte-rendu d’analyse préalable, etc.).


Obligation essentielle du maître de l'ouvrage (client)

L’obligation de recetter les livrables, contrepartie de l’obligation essentielle de délivrance conforme pesant sur le fournisseur, est une obligation essentielle du client. Dans le commun intérêt des parties, elle doit être rédigée avec le plus grand soin, de façon à la fois précise et détaillée.

L’expression des besoins, autrement dit le référentiel de conformité, décrira les livrables documentaires à fournir au client en cours de projet et, pour les livrables logiciels, les fonctionnalités et niveaux de service et de performances attendus du système informatique ou de l’application à délivrer. C'est la conformité des livrables à ce référentiel qui sera testée lors de la recette.

La phase de recette, c'est-à-dire la procédure de tests et de validation de la conformité des livrables aux spécifications contractuelles ne doit pas être confondue avec les tests réalisés par le prestataire avant la fourniture des "livrables", qui ne sauraient se substituer à ceux que doit obligatoirement réaliser le client, avec ses propres équipes et au besoin avec l’aide du prestataire ou d’un tiers (du type assistant à la maîtrise d’ouvrage).


Le périmètre de la recette et le "protocole de recette"

Le périmètre de la recette (total ou partielle, provisoire ou définitive) et la procédure à suivre pour parvenir à la recette définitive des livrables devront être clairement indiqués au contrat. Cela suppose aussi bien la rédaction d’une clause de recette générale dans le corps du contrat que l’élaboration d’un "protocole de recette" détaillé, rédigé en premier lieu par les opérationnels et revu par un juriste, prévoyant la procédure étape par étape et phase par phase. Ce document sera intégré en annexe au contrat (p. ex dans le "PAQ"), soit à idéalement à sa signature, soit en début de projet (et au besoin mis à jour en cours de projet). La clause de recette y renverra explicitement.


Quelques précisions à apporter dans la clause de recette

La clause de recette précisera l’objet et le périmètre de la recette, les délais impérativement liés aux différentes phases (intermédiaire ou modulaire, documentaire, provisoire, définitive...), les modalités et conditions de signature du procès-verbal de recette et les conséquences (i) d’une absence de réserves dans les délais indiqués et (ii) d’une acception avec ou sans réserves ou d’un refus de la recette des livrables par le client (réparation des anomalies non levées après recette avec réserves, résolution en cas d’impossibilité constatée d’exploiter les livrables ou d’un taux d’anomalies bloquantes et semi-bloquantes trop important et non levées).

Cette clause renverra explicitement aux définitions des termes essentiels à sa mise en œuvre (prévoir un article "définitions"), dont les documents constituant le référentiel de conformité, les notions de recette provisoire et définitive (s'il y a lieu), les non-conformités ou « anomalies », etc. On aura soin de décrire synthétiquement  les notions d'anomalies les unes par rapport aux autres en les situant sur une échelle de criticité (ex : bloquante/semi-bloquante/mineure).

Compte tenu de son objet juridique essentiel (la vérification de l’obligation de délivrance conforme), la clause renverra également à la validation, par les deux parties, des spécifications fonctionnelles et techniques et le cas échéant aux performances (ex: temps de réponse, délai de traitement, etc.). et les niveaux de services attendus (un "SLA" pourra être ajouté au besoin, surtout si le prestataire assurera ensuite la tierce maintenance de la solution livrée). Côté client, il faudra se souvenir que les besoins doivent avoir été expressément spécifiés pour entrer dans le champ contractuel et donc dans l’objet de la phase recette.


Quelques précisions à apporter dans le "protocole de recette"

Le "protocole de recette" (plus opérationnel que la clause proprement dite, bien qu’il ait des effets juridiques indéniables) prévoira la ou les procédures de recette (en cas de phases successives) de façon détaillée, les modalités de notification des anomalies, dysfonctionnements ou non-conformité après la phase de tests (fiches d’anomalies, cahier d’incidents...), leurs délais de résolution par le prestataire suivant leur taux de criticité, leur taux d’acceptabilité par le client au stade de la recette provisoire ou définitive non assortie de réserves (ex : 0% pour les anomalies bloquantes, 0% pour les semi-bloquantes, X% pour les mineures) ou assortie de réserves (taux à prévoir également ici), les modalités de "levée" des anomalies ou dysfonctionnements signalés lors de la phase de recette initiale dans un nouveau délai ou dans le cadre de la "garantie" en cas de recette avec réserves (voir prochainement notre Fiche pratique sur la "clause de garantie" dans les contrats informatiques).

Ce protocole annexé précisera également, pour les livrables logiciels, les protocoles de tests ou jeux d’essai que devra élaborer le client, avec ou sans collaboration du prestataire, afin de « dérouler » la procédure de recette avant le signalement des anomalies ou non-conformités.


Recette provisoire et recette définitive

A noter aussi, en pratique on distingue fréquemment dans les contrats de prestations informatiques, surtout pour les projets d’une certaine importance, une phase dite de « recette provisoire » de la procédure de "recette définitive". Juridiquement, la recette dite définitive correspond à la réception proprement dite des livrables, celle qui a pour effet de constater la conformité des livrables fournis sans réserves après tests et corrections éventuelles des anomalies. Elle couvre les "vices apparents".

Eu égard aux définitions des termes ayant cours dans les marchés publics (cf. les "CCAG TIC") et à la pratique dans les marchés privés de prestations informatiques, on peut définir la procédure de recette "provisoire", parfois dénommée "Vérification d’Aptitude au Bon Fonctionnement" (VABF) comme l’aptitude de la solution ou du système informatique livré à fonctionner en conformité avec les spécifications dans le cadre d’une simulation de situations réelles, c’est-à-dire sur la base de jeux d’essais déroulés dans un environnement de tests de la solution ou du système informatique. Quant à la recette "définitive", encore nommée parfois "Vérification de Service Régulier" (VSR), elle peut être définie comme « la réception de la solution dans le cadre de son exploitation sur un environnement de production, suivant les niveaux de services définis et mesurables » (cf. Y. Bismuth, Pratique Contractuelle - La clause de recette dans les contrats informatiques, Communication Commerce Electronique, Mars 2012, pp. 47-48).

Le recours à une telle distinction n’a rien d’indispensable. A défaut de précision, la clause de recette sera censée se référer à la recette définitive.


Le procès-verbal de recette

Il convient surtout de se référer à des notions claires et à une procédure parfaitement encadrée afin d’apporter un maximum de sécurité juridique au prestataire et au maître de l’ouvrage. A cet égard, l’on ne saurait trop recommander de veiller à préciser les modalités de signature du procès-verbal de recette provisoire et/ou définitive (avec ou sans réserves), les délais et les effets attachés aux dépassements et les modalités de l’acceptation et d’émission ou non de réserves en phase de recette avant la signature essentielle du procès-verbal de recette.

En effet, "l'acquisition" de la recette reste en principe soumise à la signature d'un procès-verbal de recette sans réserves, c'est-à-dire après levée de toutes les anomalies ou non-conformités considérées comme un obstacle à l'acceptation conformément aux prévisions du contrat.


La question de la "recette tacite"

A noter, toutefois, les tribunaux admettent parfois la "recette tacite" définitive d’une solution livrée, faute pour le client d’avoir émis en temps utile des réserves écrites concernant des livrables qu’il utilise depuis un certain temps sur un environnement de production.

Il est cependant envisageable d’exclure un tel effet en fixant des conditions d’acceptation plus strictes ou en poussant plus loin l’exigence, à la condition toutefois que le refus du client repose toujours sur des conditions objectives et ne constitue pas un manquement à son obligation de coopération ou un abus de droit.


Que se passera-t-il en cas de refus de la recette ?

Enfin, les conséquences du refus de signature du procès-verbal de recette (si bien entendu il n'est pas abusif ou la conséquence d'une coupable passivité du maître de l'ouvrage) ne doivent pas négligées.

Quelle sera l'issue du projet ? Fin du contrat au moyen de la clause de résolution ? Réécriture du code défectueux par le prestataire ? Achèvement du projet par un prestataire tiers à ses frais ?

Ceci revient à dire que la clause de recette devra envisager par avance tous les scénarios possibles au plan opérationnel et juridique. C'est pourquoi cette clause est centrale et ne doit jamais être négligée.



 

Guillaume LELU