L’environnement juridique avec lequel le DSI doit composer est de plus en plus complexe. C’est un lieu commun que de l’affirmer mais c’est malheureusement une certitude. Comme tout responsable dans une entreprise, le DSI ne peut faire abstraction des contraintes et risques juridiques qui entourent son action.
Les principes de la responsabilité
Quelques retours sur les grands principes de la responsabilité d’un salarié sont nécessaires pour bien comprendre les enjeux.
La notion de responsabilité renvoie en droit à différentes constructions juridiques. Nous nous concentrerons ici sur la responsabilité pénale, la responsabilité civile et la responsabilité disciplinaire. Toutes ces constructions ont en commun d’organiser un système de sanction en quatre étapes.
Tout d’abord, il faut supposer une norme de comportement, écrite ou non écrite. Ensuite, un manquement par rapport à cette norme : telle action ou telle abstention d’un individu va être évaluée au regard de ce qu’une personne raisonnablement compétente et diligente aurait dû faire dans la même situation. Une procédure de sanction, lorsque le manquement à cette norme est avéré, conduira à une peine. Enfin, lorsque le manquement a causé un dommage, une réparation sera allouée à la victime de ce dommage.
Quelles responsabilités ?
La responsabilité pénale est celle qui vient d’abord à l’esprit lorsque l’on parle de responsabilité. Dans ce domaine, le principe fondamental est qu’il n’y a pas de responsabilité sans texte. Les infractions pénales sont donc nécessairement fixées dans des lois ou des règlements. Elles sont codifiées dans le code pénal mais également disséminées dans de nombreux autres règlements ou lois non codifiés.
Les risques pour un DSI de voir sa responsabilité pénale engagée sont plus limités que pour d’autres fonctions dans l’entreprise. On songe notamment à tous les salariés qui ont dans leurs attributions l’hygiène et la sécurité physique des personnels. Ces salariés sont directement concernés par les infractions pénales liées à la mise en danger de la vie d’autrui. Ce n’est pas le cas du DSI. Il y a peu d’actions qu’un responsable informatique puisse engager qui entrent dans la sphère pénale.
Cependant, le champ d’investigation n’est pas entièrement vide. On relèvera quelques infractions dont le DSI doit nécessairement se préoccuper.
Autorisant les salariés des SSII à intervenir dans ses locaux, le DSI est bien sûr concerné par le délit de marchandage (Art. L. 8231-1 code du travail), défini comme « toute opération à but lucratif de fourniture de main-d’oeuvre qui a pour conséquence de causer un préjudice au salarié qu’elle concerne ou d’éluder l’application de dispositions légales ou conventionnelles ». Un délit « voisin » est celui du prêt de main d’oeuvre illicite (Art. L. 8241-1 code du travail) défini comme « toute opération à but lucratif ayant pour seul objet le prêt de salarié ». Ces délits sont punis d’un emprisonnement maximum de deux ans et d’une amende de 30 000 euros.
L’utilisation des logiciels est également une source de responsabilité pénale pour le DSI. L’utilisation de progiciels, en dehors des termes de leur licence, peut être constitutive du délit de contrefaçon, prévu par le code de la propriété intellectuelle (art. L.335-2) et réprimé par un maximum de 3 ans d’emprisonnement et 300 000 euros d’amende.
Evoquons enfin la sécurité du traitement informatisé des données personnelles. Le défaut de sécurité d’un traitement de données personnelles, conduisant à une atteinte à leur confidentialité, est puni par l’article 226-17 du code pénal d’un maximum de 5 ans d’emprisonnement et de 300 000 euros d’amende.
Si les condamnations pénales d’un responsable informatique au fondement de ces textes sont pour ainsi dire inexistantes, la commission de ces délits a cependant des conséquences sur le plan de la responsabilité civile de l’entreprise.
Le terrain de la responsabilité civile est beaucoup plus vaste que celui de la responsabilité pénale. Tout dommage causé à autrui oblige celui par la faute duquel il est advenu à le réparer. C’est notre principe fondamental de responsabilité civile posé par l’article 1382 du code civil. Tout dommage que l’action d’un DSI causerait à autrui serait en réalité de la responsabilité de son employeur, par l’effet de l’article 1384 alinéa 5 du code civil. Lorsqu’un salarié, dans le cadre du travail qui lui est confié par son employeur, cause un dommage à un tiers, c’est l’entreprise qui devrait indemniser le tiers, et non le salarié lui-même.
Bien évidemment, cette action ou inaction du salarié ayant causé un dommage à un tiers, peut constituer pour le salarié en question un manquement vis-à-vis de son employeur. Ce manquement peut conduire à une sanction disciplinaire à l’encontre du salarié. Le droit du travail prévoit toute une gamme de sanctions : avertissement ; mise à pied disciplinaire ; rétrogradation disciplinaire ; changement d’affectation ; licenciement disciplinaire.
Le DSI peut-il lui même causer un dommage à son employeur ? Très certainement. Peut-il être condamné à le réparer ? De manière exceptionnelle seulement. La jurisprudence de la Cour de cassation a posé le principe selon lequel le salarié est responsable à l’égard de son employeur uniquement en cas de faute lourde équivalente au dol, c’est-à-dire lorsque par son comportement fautif à l’origine du dommage, il avait l’intention de nuire à son employeur (Cass. soc. 31 mai 1990).
L’invasion du droit « mou »
Après avoir rappelé brièvement les différents régimes de responsabilité, attachons-nous à présenter des règles juridiques plus substantielles que le DSI va rencontrer dans son action.
Nous avons déjà présenté les textes pénaux à prendre en considération. Ils sont peu nombreux et bien connus depuis plusieurs décennies.
Un domaine s’est développé considérablement au cours des dix dernières années, que nous qualifierons de droit « mou ». Il s’agit d’un ensemble de textes -pas des lois ou des règlements stricto sensu – qui requièrent d’atteindre certains objectifs ou de mettre en oeuvre certaines démarches, sans fixer précisément leur caractère obligatoire, ni les sanctions en cas de non-respect.
Nous devrons nous limiter à deux exemples.
A la suite du scandale Enron, les Etats-Unis ont adopté la loi dite « Sarbanes-Oxley » dont l’un des objectifs a été d’améliorer la transparence et la sincérité des comptes des entreprises cotées. Dans la même logique, la France a adopté le 1eraoût 2003 la loi de sécurité financière.
Depuis cette loi, le président du conseil d’administration d’une société cotée doit rendre compte dans un rapport des procédures de contrôle interne et de gestion des risques mises en place par la société, en détaillant notamment celles de ces procédures qui sont relatives à l’élaboration et au traitement de l’information comptable et financière (art. 225-37 du code de commerce).
Les procédures de contrôle et de gestion des risques liés au traitement de l’information comptable impliquent nécessairement le système d’information de l’entreprise. On remarquera que la loi est extrêmement peu disserte sur la nature des procédures en question à mettre en oeuvre. L’Autorité des Marchés Financiers, garante de l’information des investisseurs et du bon fonctionnement des marchés financiers, a alors adopté un document intitulé « Les dispositifs de gestion des risques et de contrôle interne – Cadre de référence ».
On y trouve des principes généraux : « Les systèmes informatiques […] doivent être protégés efficacement tant au niveau de leur sécurité physique que logique afin d’assurer la conservation des informations stockées. Leur continuité d’exploitation doit être assurée au moyen de procédures de secours. Les informations relatives aux analyses, à la programmation et à l’exécution des traitements doivent faire l’objet d’une documentation. »
Mais également des prescriptions plus précises. Le Guide recommande ainsi de répondre aux questions suivantes :
Les relations avec les prestataires informatiques sont-elles contractualisées? Des indicateurs de performance et de qualité sont-ils définis et font-ils l’objet de revue périodique ? Le degré de dépendance de la société vis-à-vis de prestataires informatiques est-il analysé ? Des vérifications chez les prestataires par la société sont-elles prévues contractuellement et réalisées ?
Existe-t-il des indicateurs permettant de mesurer la qualité de service (par exemple : rejets des données, temps de réponse anormaux, rupture de service…) ? L’analyse et la mise en place d’actions correctives sont-elles envisagées ?
Les autorisations et droits d’accès aux systèmes ainsi que les environnements hébergeant ces systèmes prennent-ils suffisamment en compte la séparation des tâches ?
Des principes de sécurité d’utilisation sont-ils établis et communiqués (ex : gestion des mots de passe, transferts de données, accès à internet…)? Des principes de sécurité physique sont-ils définis et communiqués ? Des principes de sécurité logique sont-ils définis et communiqués ? Les accès aux données et programmes sont-ils sécurisés par profil d’utilisateur ? Une traçabilité des transactions est-elle possible, analysée, vérifiée ?
Des mesures de continuité de service sont-elles mises en place en lien avec les besoins métiers ? Font-elles l’objet de tests périodiques ? Les obligations de conservation des informations, données et traitements informatiques concourant directement ou indirectement à la formation des états comptables et financiers sont-elles respectées ?
Etc. Etc.
Ces règles, qui font parfois écho à d’autres règles de droit « mou », notamment le règlement n°97-02 du 21 février 1997 sur le contrôle interne des établissements de crédit, invitent à porter une attention particulière sur la dépendance du système d’information de l’entreprise par rapport aux prestataires tiers. Le recours à des prestataires certifiés SAS 70 est parfois encouragé, sans être pour autant obligatoire.
Evoquons pour finir le devenir de la législation sur la protection des données personnelles. Cette législation, qui repose aujourd’hui sur notre loi du 6 janvier 1978 Informatique et Libertés et une directive européenne de 1995, va être profondément modifiée dans les années à venir par un règlement européen. La Commission européenne a ainsi rendu public, le 25 janvier 2012 un projet de règlement relatif à la protection des données personnelles et la libre circulation de ces données.
Parmi les bouleversements induits par ce futur règlement, figure l’obligation pour les entreprises d’intégrer la protection des données personnelles dès la conception de leurs applicatifs. C’est ce que l’on résume par l’expression « Privacy by design ». Aussi, lorsqu’un traitement présentera « des risques spécifiques pour les droits et libertés », le responsable du traitement devra mener à bien « une étude d’impact du traitement envisagé sur la protection des données personnelles ». Quel devra être le contenu de cette étude ? Tout reste à inventer.
On le voit, la conception et le maintien en condition opérationnelle d’un système d’information doit répondre aussi, et de plus en plus, à des impératifs juridiques. Nous n’avons fait qu’effleurer le sujet.
