|
|
|
L'importance des contrôles
internes
2009/2010
Credit Agricole Corporate & Investment Bank Malik DJAFRI
Maître d'apprentissage : Sébastien Romaire-Denizet
Tuteur enseignant : Cécile Hardouin
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sommaire
Glossaire 4
Table des figures 5
Introduction 6
I. Les contrôles internes 7
· La notion de contrôle interne 7
· Les différents types de contrôles 9
· Les études préalables à la mise en
place des contrôles 12
II. L'organisation des contrôles 16
· Cadre des contrôles 16
· Qui les met en place ? 18
· Comment sont-ils décidés ? 22
· La mise en place technique des contrôles. 23
· Comment évoluent-ils ? 23
III. Limites de ces contrôles 25
· Les couts 25
· La confidentialité 25
· Le suivi 26
· La mise en place 26
Conclusion 29
Bibliographie 30
Annexe : 32
Remerciements
Je tiens en premier lieu à remercier tous ceux qui ont
contribué à la réalisation de ce mémoire, que cela
soit par leurs conseils, ou leurs commentaires avisés.
Un grand merci donc à, Sébastien
Romaire-Denizet, mon maître d'apprentissage dont l'aide fut
précieuse lors de mes recherches ainsi qu'à Guillaume Zuili, chef
du service « Courtage et Confirmation » chez CA-CIB pour m'avoir
accueilli durant cette année en apprentissage.
Je n'oublie pas non plus l'équipe pédagogique
de l'Université Paris Ouest Nanterre La Défense pour m'avoir
permis de suivre cette formation tout au long de l'année, ainsi que
Cécile Hardouin, mon tuteur pédagogique pour ses précieux
conseils.
Et enfin, je remercie Nathalie Boché, chargée de
mission du CFA, pour son support et son suivi tout au long de cette
année.
Glossaire
AMF : Autorité des Marchés
Financiers. Il s'agit d'un organisme public indépendant, doté de
la personnalité morale et disposant d'une autonomie
financière.*
AS : Application Security BDD :
Bases De Données.
CACIB : Credit Agricole Corporate &
Investment Bank, Banque d'investissement et de financement du groupe
Crédit Agricole. Il s'agit de l'entreprise dans laquelle j'effectue mon
master MIAGE en apprentissage.
CCM : Continuous Control Monitoring.
COSO : Committee Of Sponsoring Organizations,
une commission à but non lucratif qui établit en 1992 une
définition standard du contrôle interne
DRP : Disaster Recovery Plan
ERP : Enterprise Resource Planning. Progiciel
de gestion intégré.
IS : Infrastructure Security
LSF : Loi sur la Sécurité
Financière. Législation financière française.
J-SOX : SOX Japonais. Législation
financière japonaise.
SAP : Systems, Applications, and Products for
data processing. Progiciel de gestion intégré. SI :
Système d'Information.
SIT : Security for IT
SOX : Sarbanes-Oxley Act. Législation
financière américaine.
TVA : Taxe sur la Valeur Ajoutée.
Val IT : Enterprise Value : Governance of IT
investments. Référentiel pour la gouvernance des investissements
informatiques.
Table des figures
Figure 1 : Matrice des contrôles internes
(p.11)
Figure 2 : une application utilisant plusieurs
bases de données (p.12) Figure 3 : Diagramme de flux
d'une facturation (p.13)
Figure 4 : Diagramme du service DSI (p.18)
Figure 5 : Différents niveaux de
contrôles existants (p.19)
Figure 6 : Solution proposée (p.20)
Figure 7 : Evolution des risques
souhaitée en fonction du temps (p.22) Figure 8 :
Evolution du nombre de contrôles en fonction du temps (p.23)
Figure 9 : Cas d'une mise en place ascendante (p.27)
Figure 10 : Cas d'une mise en place descendante
(p.28)
Introduction
Au fil des dernières années, le contrôle
interne a pris une part de plus en plus importante dans les entreprises. En
effet le contrôle interne est devenu une solution à une suite
d'événements : une organisation non stable ainsi qu'une
série d'incidents a entraîné une fragilité
croissante des processus de reporting financier. Les dirigeants de grandes
entreprises se sont intéressés de plus en plus aux
contrôles internes entrainés par une seconde facette, il s'agit de
la législation qui impose une transparence de plus en plus accrue.
L'évolution rapide des technologies informatiques ont
poussé, voire même obligé, les entreprises à
utiliser des systèmes d'informations. En effet, les systèmes
d'informations permettent d'être totalement indépendant de cette
évolution. Ces systèmes sont devenus indispensables dans une
entreprise, sans quoi, l'entreprise se fragilise. Toutes les opérations
fonctionnelles d'une entreprise passent à un moment ou à un autre
par un système d'information. Dans le cas extrême des applications
de gestion, en particulier les ERP, ce n'est plus le système qui
s'adapte à l'entreprise mais l'entreprise qui est structurée et
organisée autour du système (que se soit la façon de
communiquer entre service ou bien la manière de travailler).
Auparavant, les organisations étaient souvent
structurées en départements et secteurs relativement
indépendants les uns des autres (Comptabilités, Ressources
Humaines, etc.). Ainsi, le flux des informations et du matériel
fonctionnait de manière verticale. Puis la gestion « verticale
» a tendu à disparaitre pour faire place à une gestion par
processus. Ces derniers, transversaux, ont pour but d'organiser le travail de
manière à créer une chaîne orientée vers la
satisfaction du client (interne ou externe).
Le but de tels contrôles est de s'assurer que tout se
déroule de manière conforme aux règles et aux lois qui les
régissent. C'est aussi le rôle de l'audit informatique. Les
démarches se ressemblent énormément. Les entreprises
doivent adapter leurs contrôles.
Face à ces préoccupations de contrôle, les
lois ont évolué : - LSF (Loi sur la Sécurité
Financière) : France
- SOX (Sarbanes-Oxley Act) : Etats-Unis
- J-SOX (SOX japonais) : Japon
I. Les contrôles internes
· La notion de contrôle interne
D'après l'AMF, le contrôle
interne se définit de la façon suivante : « le
contrôle interne est l'ensemble des sécurités contribuant
à la maîtrise de l'entreprise. Il a pour but d'un
côté d'assurer la protection, la sauvegarde du patrimoine et la
qualité de l'information, de l'autre l'application des instructions de
la Direction et de favoriser l'amélioration des performances. Il se
manifeste par l'organisation, les méthodes et les procédures de
chacune des activités de l'entreprise, pour maintenir la
pérennité de celle-ci » et ses objectifs sont les
suivants :
· veiller à « la conformité aux lois et
règlements »
· assurer « l'application des instructions et des
orientations fixées par la Direction générale ou le
Directoire » de l'entreprise,
· maintenir « le bon fonctionnement des processus
internes de la société, notamment ceux concourant à la
sauvegarde de ses actifs»
· garantir « la fiabilité des informations
financières ».
Le contrôle interne doit prendre en compte plusieurs
paramètres :
· l'organisation qui influe sur le système
d'information,
· la diffusion de l'information qui doit être
idéalement fluide et sans anomalie,
· le dispositif d'habilitation (identification),
· des activités de contrôle
adaptées,
· une surveillance permanente.
D'après le référentiel
COSO, « le contrôle interne est un processus
mis en oeuvre par les dirigeants à tous les niveaux de l'entreprise et
destiné à fournir une assurance raisonnable quant à la
réalisation des trois objectifs suivants :
· l'efficacité et l'efficience des
opérations,
· la fiabilité des informations
financières,
· la conformité aux lois et règlements
»
Les définitions énoncées ci-dessus sont
totalement indépendantes de la façon dont sont traitées
les données. C'est-à-dire qu'il existe une définition
adaptée au niveau d'informatisation de l'entreprise. (ANNEXE 1)
De nos jours, la majeure partie des entreprises sont
informatisées et possèdent donc un système d'information
dans lequel se trouvent toutes les données qu'elles exploitent et
traitent d'une manière spécifique à leur métier. Il
paraît donc évident que la majorité des contrôles se
fasse au sein de ce système informatique, en effet c'est là que
se trouvent les données et donc les principales sources d'erreurs de
toutes sortes.
Vous l'avez bien compris, le contrôle interne est
présent dans toutes les entreprises afin de vérifier qu'elles
effectuent correctement leur travail. Il vérifie que l'entreprise
respecte la loi mais aussi que toutes les opérations respectent
scrupuleusement les différents processus mis en place. En plus de cela,
le contrôle interne apporte la preuve de ce bon fonctionnement. Il faut
savoir qu'il n'y a pas de personne extérieur qui vienne effectuer ces
vérifications mais l'entreprise doit présenter les conclusions
des contrôles et apporter la preuve qu'elle les réalise de
manière correcte.
· Les différents types de
contrôles
Il existe dans le monde des contrôles, une multitude de
types. Ils peuvent se représenter de façon matricielle. D'une
part, nous pouvons les diviser selon le niveau de contrôle et d'autre
part selon le niveau d'automatisation. Nous allons détailler
ci-après ces deux critères.
Afin de couvrir l'ensemble des processus et des données,
il est nécessaire de prendre en compte quatre niveaux de contrôles
:
- Les contrôles opérationnels :
c'est le premier niveau de contrôle. Ils sont mis en oeuvre par
les équipes opérationnelles. Ils permettent de repérer les
erreurs et de limiter les fraudes. Ce sont pour l'essentiel des contrôles
applicatifs dont le but est de s'assurer que des données erronées
ne se sont pas glissées dans celles qui ont été saisies et
que les traitements effectués sont conformes à ce qui
était prévu. Les contrôles possibles sont très
variés.
- Les contrôles d'ensemble : le
deuxième niveau est assuré par les responsables encadrant les
opérationnels, dont la mission est double : s'assurer que tout se passe
bien et vérifier que les flux sont sous contrôle.
- La détection des situations anormales :
c'est le troisième niveau. Il fait appel à
différentes fonctions de contrôle spécialisées comme
la gestion de la sécurité, le contrôle de gestion, la
gestion de la qualité, etc. Toutes ces fonctions ont à la fois
une mission technique spécialisée, comme d'améliorer la
qualité ou le niveau de la sécurité, et une mission de
surveillance générale du fonctionnement des principaux processus.
Ici il existe une composante préventive et une composante corrective.
- L'audit : enfin, le niveau de
contrôle ultime est assuré par l'audit, interne ou externe. A ce
niveau, l'audit informatique, et notamment l'audit des applications, est le
moyen le plus efficace pour maîtriser les principaux processus de
l'entreprise.
Comme on peut on le voir, il existe une sorte de
hiérarchie dans les contrôles mis en place. A la base de cette
hiérarchie, il y a les contrôles réalisés par les
opérationnels qui se trouvent au coeur du métier au jour le jour
; et au sommet, il y a l'audit informatique qui possède un certain recul
sur le métier et possède une vision d'ensemble.
L'ensemble de ce dispositif repose, en grande partie, sur
l'engagement du management qui est chargé de mettre en place des outils
nécessaires de contrôle et de s'assurer de leur utilisation
correcte : une faiblesse ou une défaillance de l'encadrement peut avoir
des conséquences importantes. Dans chaque étape de ce dispositif,
il existe une intervention humaine, elle est plus ou moins présente.
Elle peut être totale comme quasi inexistante. Voyons maintenant les
différents niveaux d'automatisation des contrôles :
- Contrôle automatisé
Les contrôles automatisés correspondent aux
contrôles que l'on retrouve dans le code même des applications, ils
correspondent à des vérifications adaptées aux
métiers. Ce sont des choix de contrôle qui sont
décidés lors de la réalisation de l'application.
Il parait évidant que la chose la plus importante dans
ce type de contrôles est la façon dont ils ont été
codés. Deuxième chose, il ne doit pas y avoir de version non
valide en production c'est-à-dire à disposition de
l'opérationnel. Enfin, le contournement de ces contrôles ne doit
jamais être possible, que ce soit via un utilitaire de l'application, via
une requête de base de données, via le réseau ou encore via
le système d'exploitation. Le contrôle doit être un passage
obligatoire dans tout les cas possibles.
Malgré toutes ces précautions, une
question peut nous venir à l'esprit : après le codage de ces
contrôles, comment vérifier qu'ils sont conformes et comment
vérifier que la personne qui donne sa validation n'a pas de parti pris
?
- Contrôle semi-automatique
Ce type de contrôle est appelé ainsi car il
mêle l'intervention humaine et la technologie (automatisation). Il
nécessite un codage préalable qui fournit, à un
opérationnel ou un manager, un voyant représentant l'état
des données dans le système d'information au moment du
contrôle. Grace à celui-ci, la personne devant son écran
prend une décision concernant la conformité ou non des
données contrôlées.
Ce contrôle est réalisé à partir
d'une donnée fournie par un outil informatique, donc les questions que
l'on peut se poser sont les mêmes que celles vues
précédemment. Comment peut-on vérifier que cette
indication automatisée est la bonne et représente
réellement l'image des données ?
- Contrôle manuel
Ces contrôles sont les plus sensibles à l'erreur
humaine. En effet, il n'y a aucune intervention informatique, les
données sont fournies à une personne pour vérification.
Elle se fait visuellement, bien évidement ce type de contrôle
nécessite la vérification de personne de confiance qui n'aurait
pas de mauvaise intention. Rien n'empêche cette personne de prendre une
décision qui est totalement contraire aux règles de gestion
dictées par l'entreprise. Soit parce que cette décision
dépend de l'appréciation (dans ce cas, deux personnes
différentes peuvent ne pas prendre la même décision) soit
pour nuire à l'entreprise (fraude).
Il devient donc évident qu'il est important
d'éviter au maximum ce genre de contrôle. Le risque d'erreur et de
tentative de fraude est trop important. Idéalement il ne devrait pas en
exister.
Figure 1 : Matrice des contrôles internes
· Les études préalables
à la mise en place des contrôles
Avant de mettre en place une politique de contrôle
interne, il est nécessaire de réaliser une série
d'études préalable afin de comprendre les enjeux, les
procédures et les systèmes. Il est également important de
s'assurer de l'adéquation des contrôles avec les objectifs.
Identifier les flux de données
La première étape est de connaitre les
différents flux d'informations présents dans l'entreprise. En
effet, les données présentes dans un système d'information
respectent un cycle de vie, c'est-à-dire qu'à un moment
précis d'un processus, la donnée peut avoir une forme
différente et/ou se trouver à une autre étape du cycle de
vie. Il parait normal de connaitre ces différentes étapes et la
façon dont le flux d'informations les parcourt. Ceci revient à
étudier les chaînes de traitement des données (saisie,
modification, mise à jour, archive...)
Une fois que cette première partie est
réalisée, nous pouvons nous servir de ces informations pour
réaliser des contrôles de cohérence (état du
système d'information)
Cette première étude met en évidence
toutes les bases de données utilisées (dans le cas d'une
application multi bases) et toutes les interactions les liant entre elles. La
figure cidessous représente une application gérée par le
service dans lequel je travaille au sein de CA-CIB :
Figure 2 : une application utilisant plusieurs bases de
données
Dans cette application, il existe deux bases, une
récupérant les données brutes issues d'une extraction de
plateforme extérieure, et une deuxième se chargeant de stocker
les données transformées par l'application et les
différents traitements. Cette pratique permet de dissocier les
données brutes, issues de l'extraction, des données
manipulées.
Prenons maintenant une application avec une base de
données simple comme celle concernant une application de facturation.
Cet exemple va nous permettre d'étudier les différentes
transformations qui peuvent être apportées aux données.
Voici le schéma représentant les flux de données d'une
application de facturation :
Figure 3 : Diagramme de flux d'une facturation
Le point d'entrée de données dans le
système est la saisie manuelle des commandes. Nous avons donc des
données brutes qui n'ont pas été modifiées.
Après une vérification en comparant si les produits existent bien
dans le référentiel, les données sont une première
fois modifiées par un traitement qui permet de créer des bons de
livraison. Après livraison des produits, un second traitement manipule
une seconde fois les données afin d'éditer les factures. Enfin,
les données sont archivées après un passage par la
comptabilité.
Une fois que l'étude des flux de données a
été effectuée, nous connaissons la structure des bases de
données et comment les données sont manipulées par les
traitements. Il s'agit maintenant de nous intéresser aux données
en elles-mêmes.
Contrôler les données
Contrôler les données n'est pas si simple qu'il
n'y paraît. En effet, le contrôle doit être adapté aux
risques estimés par l'étude préalable. Cela implique que
chaque donnée présente dans le système d'information
possède un niveau de risque : Qui décide qu'une
donnée est plus ou moins risquée ? Et pourquoi ?
Trouver un juste milieu dans les contrôles signifie ne
pas tomber dans l'excès (ce qui couterait beaucoup) et ne pas être
trop laxiste (ce qui mettrait l'entreprise en péril). Pour donner un
exemple, il n'est pas nécessaire de contrôler les données
concernant l'adresse ou encore le numéro de téléphone d'un
client. Ces données ne sont pas critiques et ne mettent pas en
péril l'entreprise car dans le contexte des marchés financiers
l'adresse d'un client n'est pas utile (sauf peut être le pays afin de
détecter un client risqué). Un contrôle placé sur
ces champs ne sera qu'une partie du budget alloué perdue. En revanche,
vérifier l'intégrité des données concernant les
comptes des clients est d'une énorme importance pour la
pérennité et la crédibilité de l'entreprise.
Des contrôles sont donc effectués sur ces
données pour les mettre à jour mais aussi les archiver. Garder
une trace de toutes les données passant par le système
d'information est nécessaire dans certaines situations précises
que nous allons détailler plus tard dans ce mémoire.
Les premiers types de contrôles mis en place sont
placés très tôt dans le processus tel que les
contrôles de saisie. Cela évite de manquer d'une donnée
plus tard dans le processus. Il est nécessaire de posséder et de
contrôler la présence du numéro de compte d'un particulier
avant que l'on arrive à l'étape de facturation. Ces
contrôles permettent d'éviter les erreurs lors des
traitements ultérieurs. Il est également
possible d'obliger l'utilisateur responsable de la saisie
de respecter un formatage particulier (par exemple : «
AA-000-AA » pour les nouvelles
plaques d'immatriculation). Enfin, le contrôle
idéal est de posséder dans l'entreprise un
référentiel qui nous permet d'utiliser ces
données connues de l'entreprise sans crainte car
elles sont vérifiées en amont.
A un niveau au dessus de ces contrôles de saisie, il y a
les contrôles des traitements en eux-mêmes. Les traitements issus
des choix de l'entreprise doivent se dérouler correctement. Prenons
comme exemple une application permettant de gérer des confirmations de
transactions : il est important de vérifier que toutes les
transactions
donnent lieu à une confirmation de la part de la
banque, ou encore, vérifier que pour toute
confirmation émanant de la banque il existe une
confirmation de la contrepartie (la personne
avec qui la transaction se fait).
|
Au niveau de la base de données, des contrôles
doivent permettre de repérer tout dysfonctionnement de celle-ci. Une
donnée qui disparait ou un chainage entre plusieurs bases de
données peut provoquer des conséquences dramatiques.
|
|
Vérifier l'existence de pistes
d'audit
|
Une piste d'audit permet d'avoir la trace de toutes les
données qui ont été présentes dans le
système d'information à n'importe quel moment. Pour cela, il
existe deux solutions : enregistrer tous les états des données au
fur et à mesure, enregistrer les manipulations de données.
|
|
Grace à ces enregistrements, il est possible de
récupérer une donnée à n'importe quel moment de son
cycle de vie. Il suffit d'effectuer les manipulations dans le sens inverse pour
obtenir l'état des données au moment voulu.
Si une entreprise ne possède pas de piste d'audit sur
ses données, appelée également « chemin de
révision », elle fragilise de manière conséquente ses
contrôles internes. En effet, il devient impossible de retracer les
différentes manipulations faites sur la ou les bases de
données.
En conclusion, la maîtrise des données
est un point fondamental de la démarche de contrôle interne. Elle
impose de prévoir des dispositifs adaptés, notamment la gestion
des flux de données, leur contrôle et l'existence de chemins de
révision.
II. L'organisation des contrôles
Certaines entreprises réalisent des contrôles
manuels et ponctuel alors que d'autres mettent en place des contrôles
automatiques et permanents.
· Cadre des contrôles
L'objectif est ici de mettre en place un contrôle
permanent, selon une démarche appelée aujourd'hui CCM, pour
« Continuous Control Monitoring ».
Dans cette démarche, les contrôles embarqués
dans les applications constituent un des points clés permettant de
s'assurer des contrôles suffisants :
- les données saisies,
- l'exhaustivité des traitements,
- l'intégrité des bases de données, - les
accès.
Avant d'engager une telle démarche, il est
intéressant de mesurer le degré de maturité du
contrôle interne de l'entreprise sur une échelle à quatre
niveaux, en fonction du degré d'automatisation des contrôles et de
leur valeur ajoutée :
- traditionnel : contrôles manuels essentiellement,
- intermittent : contrôles manuels ou automatisés
réalisés de façon espacée, - périodique :
contrôles en grande partie automatisés et récurrents,
- continu : contrôles très automatisés,
réalisés au fil de l'eau.
Pour se situer dans ce modèle de maturité,
l'entreprise doit donc se poser les questions suivantes :
- quel est le niveau d'automatisation des contrôles ?
- sont-ils très variables en fonction des processus ou
des unités considérées ?
- quelle est la valeur ajoutée de ces contrôles, et
la Direction souhaite-t-elle la renforcer ?
Le champ d'application peut être très variable dans
l'entreprise elle-même, et concerner les systèmes suivants :
- ERP : SAP, Oracle, JD Edwards, Peoplesoft, ...
- autres systèmes applicatifs : Supply Chain, Customer
Relationship Management, ... - systèmes techniques :
sécurité réseau, infrastructure, help desk,
contrôles d'accès.
Les indicateurs utilisables dans une démarche CCM sont de
nature très variés et déterminés en fonction des
objectifs de contrôle poursuivis. Ce sont par exemple :
- passage de seuil : achats supérieurs à
10.000.000 €,
- accès aux transactions sensibles : liste des
utilisateurs concernés,
- changements interdits dans les fichiers maîtres :
modification de coordonnées bancaires,
- transactions interdites : déblocage d'un paiement indu,
- doublons : clients en double dans les fichiers,
- enregistrements mal renseignés : absence de code
TVA,
- mauvaise ségrégation de fonction :
possibilité de créer un client et de payer sa facture,
- cohérence des dates : réception des biens le
jour même de la création de la commande.
Rares sont encore les entreprises françaises à
avoir adopté des approches d'ensemble pour le CCM, même si
beaucoup d'entre elles sont en recherche d'outils et de solutions.
La démarche CCM porte ses fruits si l'entreprise
constate que son environnement de contrôle est renforcé de
manière durable, avec un gain d'efficacité, une automatisation
visible des alertes, beaucoup de prévention, et moins d'anomalies
détectées au cours des audits.
· Qui les met en place ?
En général, les contrôles internes sont
mis en place par un service spécifique. La particularité de ce
service : les personnes qui les composent ne possèdent pas les
compétences techniques pour exploiter les failles qui sont
éventuellement découvertes.
Au sein de CA-CIB, le service de contrôles IT se compose
de la façon suivante :
- IS : Infrastructure Security un service contrôlant les
outils IT (base de données entre autre)
- AS : Application Security, un service contrôlant toutes
les applications (Habilitation et qualité de codage)
- DRP : Disaster Recovery Plan, un service gérant les
cas de crise. (en cas de chute d'un des 3 pôles présents en
île de France) : Dans ce cas, il est primordial de pouvoir relancer
toutes les applications présentes sur les serveurs afin que
l'activité de la banque ne s'arrête pas. C'est d'ailleurs autour
de cette cellule que mon second projet se situe. L'application DRPMT a pour but
de gérer les PSI (Plans de Secours Informatiques). Plusieurs tests sont
réalisés chaque année, une sorte de simulation permettant
de réaliser les différentes tâches d'un PSI. Comme cela,
dans le cas d'un réel PSI, la succession de tâches est
déjà connue et préparée. Cela permet de pallier
à toutes éventualités.
Voici un organigramme représentant l'ensemble de ces
cellules.
Contrôles Contrôles
Figure 4 : Diagramme du service DSI
Tous ces contrôles sont gérés et mis en
place par une seule personne mais afin de vérifier ces contrôles
il est nécessaire d'avoir un niveau supérieur de contrôle,
c'est pour cela qu'il existe au sein de CACIB différents niveaux de
contrôles qui se comptent au nombre de trois ;
- Le niveau 1.0 : contrôle de base (présenté
dans l'organigramme ci-dessus) - Le niveau 2.1 : contrôle permettant de
vérifier les contrôles 1.0
- Le niveau 2.2 : dernier niveau de contrôles qui est
là pour vérifier les deux premiers niveaux.
Figure 5 : Différents niveaux de contrôles
existants
Nous pouvons remarquer qu'il s'agit d'une limite étant
donné qu'il y a toujours un niveau de contrôle qui n'est pas
contrôlé. (Ici le niveau 2.2)
Pourquoi avoir trois niveaux et pas quatre ou cinq
?
La réponse est triviale, il peut y avoir autant de
niveaux que l'on veut mais il y aura toujours un niveau non
contrôlé. Bien entendu, une solution a été
pensée afin que tous les niveaux soient contrôlés par un
autre et donc qu'il ne se trouve pas d' « électron libre ».
Voici comment cela peut être mis en place :
Figure 6 : Solution proposée
La solution que je propose est très simple mais
demande la création d'un nouveau niveau (3.0). Ceci a aussi une
conséquence sur le niveau 2.1. En effet, il se retrouve avec deux
niveaux à contrôler : le niveau 1.0 mais aussi le niveau 3.0. Le
risque encouru est qu'il y ait une sorte d'accord entre deux niveaux (par
exemple niveau 1.0 et 2.2) car dans ce cas il devient facile de dissimuler une
information. Cet inconvénient existe-t-il dans la solution actuelle ? Le
problème reste le même, voire est encore plus grave. Si nous
reprenons la même situation avec un accord tacite entre le niveau 1.0 et
2.2, le contrôle du niveau 2.1 est « court-circuité ».
Mais la différence est dans le fait que le niveau 2.2 n'est pas
contrôlé à son tour, il reste donc libre de faire ce que
bon lui semble. Dans la solution que je propose, le niveau 3.0 peut, en
contrôlant le niveau 2.2 mettre en évidence l'anomalie.
Comment éviter les accords officieux entre les niveaux
? Une solution est de renouveler régulièrement les personnes
présentes dans le niveau 2.1. De cette façon, il ne peut y avoir
d'accord pérenne entre les niveaux. L'idéal serait d'ajouter
à cela un changement des contrôles afin de pouvoir placer les
anciennes personnes du niveau 2.1 dans les services techniques de mise en
place. Cependant il est d'une importance capitale de supprimer les
habilitations que ces personnes avaient auparavant.
· Comment sont-ils décidés ?
Un responsable a pour but de repérer les endroits
où les contrôles sont nécessaires en fonction des risques
encourus. Il possède un budget et donc doit trouver le juste milieu
entre les risques à couvrir en fonction de ses possibilités
financières. En plus de cela, il existe une règle qui veut que la
valeur des risques non couverts par un contrôle soit mise sur un compte
bloqué pendant plusieurs années. En conséquence, voici
l'évolution des risques recherchée par ce responsable :
Figure 8 : Evolution du nombre de contrôles en fonction du
temps
· La mise en place technique des
contrôles.
Selon le type de contrôle décidé, il est
mis en place par une équipe qui a la charge de la partie technique.
Comme nous l'avons vu dans la partie précédente, au sein de
CACIB, il existe 2 services qui mettent en place les contrôles
décidés : l'équipe ITS () et l'équipe BCI ().
Si le contrôle concerne une infrastructure (une base de
données, un serveur), il sera chargé à ITS de le mettre en
place. Si le contrôle concerne une application, ce sera BCI qui le
fera.
Il est important de souligner que ces mises en place ne se
font pas rapidement. Il y a un tout un processus à respecter. Les
évolutions de contrôles sont des projets à part
entière, il faut donc passer par toutes les étapes d'un projet
informatique classique.
· Comment évoluent-ils ?
Bien sûr, afin de réduire les risques, il est
nécessaire que les contrôles évoluent chaque année.
Dans l'entreprise CACIB, les contrôles suivent la stratégie de la
maison mère CASA. La direction générale dicte une
stratégie et des objectifs. Un exemple serait : « les risques
opérationnels doivent être divisés par deux en un an.
» Afin de suivre cette évolution, des évaluations des
risques sont réalisées chaque année. Cela permet à
chaque équipe de connaitre son évolution par rapport à
l'année précédente.
Des cas exceptionnels peuvent avoir pour conséquence un
renforcement des contrôles, comme lorsque les résultats des
contrôles se dégradent ou encore lorsqu'un élément
extérieur influe comme une tentative de fraude dans une autre banque.
Certaines situations peuvent mener à une série de contrôles
: dans le cas de départs massifs de traders, il est important de
vérifier qu'ils ne possèdent plus les habilitations pour
effectuer des transaction et vérifier également qu'ils ne partent
pas avec des données de la banque.
Il faut savoir que le nombre de contrôles ne diminue
jamais, il est en constante augmentation. En effet, on pourrait penser qu'en
temps de crise par exemple, une restriction budgétaire pourrait baisser
son nombre, mais en réalité la seule chose qui diminue est le
nombre de projets prévus à l'évolution de ces
contrôles. La démarche est toujours croissante quelque soit le
contexte.
III. Limites de ces contrôles
Comme énoncé précédemment, les
contrôles internes sont présents dans une entreprise pour
répondre à un risque. En effet, il n'existe pas de contrôle
qui ne soit pas en réponse d'un risque. Bien entendu la mise en place de
ces contrôles possède des limites :
· Les couts
L'une des plus grosses limites des contrôles internes
est bien sur le cout qu'il engendre. En effet, le fait de mettre en place un
contrôle interne parfaitement opérationnel et idéalement
adapté à une entreprise demande une étude approfondie de
celle-ci et d'en adapter certains comportements. Tout cela coute
énormément à l'entreprise en étude et en mise en
oeuvre. Le fait que ce cout soit parfois supérieur à la somme qui
risque d'être perdue n'arrange en rien le point de vue de l'entreprise.
Dans ce cas, il est plus intéressant financièrement de ne pas
mettre en place de contrôle mais opérationnellement, cela comporte
un risque important. C'est en partie pour cela que certaines entreprises ne
sont pas très regardantes au sujet de ces contrôles.
· La confidentialité
Le problème de confidentialité de la politique
de contrôle peut aussi poser quelques problèmes. Dans un certain
nombre d'entreprises cette politique de contrôle n'est pas
confidentielle, il est donc possible à n'importe quel employé de
connaitre toutes les vérifications effectuées sur les processus
internes. Si les objectifs de cet individu est de frauder en passant outre les
contrôles, il est possible pour lui d'étudier la politique de
l'entreprise afin d'y parvenir.
D'autre part, il est difficile de garder confidentiel une
politique de contrôle, en effet, lorsqu'un projet d'évolution
débute, les techniciens sont à fortiori au courant du
déroulement des opérations. De plus, lorsqu'un problème
est rencontré lors d'un contrôle, il est normal de demander des
comptes au service concerné et donc la faille et encore une fois
forcément connue.
· Le suiviLes employés du
service mettant en place les contrôles n'ont pas les connaissances
techniques pour profiter des failles du système. Mais
que se passe-t-il lorsqu'un de ces employés profite d'une
possibilité de reconversion pour atteindre un poste plus technique.
Cette hypothèse pose un problème, en effet, cet employé
aura les connaissances nécessaires pour frauder son entreprise.
On se retrouve donc dans un cas de figure identique à
l'affaire Kerviel. En effet, ce dernier a travaillé sur la mise en place
des contrôles internes liés aux processus concernant les
transactions de « trading ». Malheureusement pour sa
société, il est devenu par la suite trader. Ainsi, M. Kerviel
connaissait tous les moyens de passer outre les contrôles qu'il avait en
partie lui-même mis en place. Cette négligence a eu de lourdes
conséquences financières pour la banque dans laquelle il
travaillait. Cette affaire a contribué à un durcissement des lois
encadrant la finance mondiale.
· La mise en place
Lorsque la décision est prise de modifier un
contrôle dans un processus, il est impératif que la communication
concernant cette nouvelle règle se fasse dans un ordre précis.
Deux possibilités s'offrent à l'entreprise :
- Mise en place ascendante : la modification se fait
au niveau le plus bas (le plus critique) et l'information remonte aux
contrôles de niveau supérieur. L'avantage de cette façon de
diffuser l'information, est que la décision est appliquée sans
latence.
- Mise en place descendante : la décision est
appliquée par les niveaux les plus hauts puis l'information se diffuse
vers les plus critiques. La décision n'est pas mise en place directement
mais aucune donnée n'est perdue lors du changement
Prenons un exemple, une information doit passer 3
étapes de contrôles avant de sortir du système. La
décision est prise d'interdire toute transaction de type A. Dans le cas
d'une mise en place ascendante, ces informations ne passeront plus
l'étape 3 mais pourront passer les étapes
précédentes le temps que l'information y parvienne. Cette
méthode a pour conséquence une perte d'informations (celles qui
se trouvent entre les étapes). Le changement est en quelque sorte
à contrecourant du flux d'information.
Figure 9 : Cas d'une mise en place ascendante
En revanche, dans le cas d'une mise en place descendante,
aucune donnée n'est perdue. Le changement se fait d'abord sur
l'étape 1 et donc les informations seront déjà
filtrées. Par contre, le temps que le changement arrive à
l'étape 3, des données ne prenant pas en compte ce dernier,
certaines seront encore dans ce système.
Figure 10 : Cas d'une mise en place descendante
Conclusion
Nous avons pu voir qu'il est difficile de mettre en place des
contrôles. C'est pour cela que ce service est géré par une
personne de responsabilité qui connait parfaitement la banque et qui est
digne de confiance. Une décision peut être totalement
différente en fonction d'une multitude de critères. Le nombre de
contrôles est en constante augmentation, mais une crise économique
ou un quelconque autre événement extérieur peut ralentir
cette évolution et donc peut faire apparaître des failles.
Les contrôles internes sont faits pour prévenir les
cas de figure suivants :
· Risques opérationnels : Les
risques étant liés à l'applicatif et aux personnes
opérationnelles, cela consiste à effectuer les contrôles de
base.
· Risques de fraude : Risque qu'une
personne puisse porter préjudice à l'entreprise de
l'intérieur.
· Risques de malveillance : risque qu'une
personne extérieure à l'entreprise puisse profiter d'une faille
du système pour soutirer des informations ou porter atteinte à
l'entreprise.
Mes diverses recherches m'ont montré que la mise en
place de nouveaux contrôles se fait au cas par cas. Si deux
contrôles sont à mettre en place mais qu'il n'est possible d'en
réaliser qu'un seul pour raison budgétaire, c'est celui qui aura
la criticité la plus forte en fonction du contexte qui aura la
priorité.
Le principal facteur reste l'environnement de
l'entreprise. Une décision sera différente selon l'état du
marché, les restrictions budgétaires ou encore les
différents événements pouvant avoir comme
conséquence une certaine crainte. Dans le secteur bancaire, les
processus sont souvent répétitifs en interne mais l'environnement
est en perpétuel mouvement. C'est cela qui rend la tache
difficile.
Bibliographie
1. Val IT : Création de valeur pour l'entreprise : la
gouvernance des systèmes d'information - ITGI - édition
française AFAI Version 4.1 2006 :
www.isaca.org et
www.afai.fr
2. IT control Objectives for Sarbanes-Oxley - Version 2
septembre 2006- Ce texte est téléchargeable à partir du
site :
www.itgi.org et
www.isaca.org
3. Prise en compte de l'environnement informatique et incidence
sur la démarche d'audit - Compagnie Nationale des Commissaires aux
Comptes (avec la participation de l'AFAI)
4. Approche et méthode de la mission de diagnostic du
contrôle interne ou comment répondre aux obligations de la loi sur
la sécurité financière - Conseil Supérieur de
l'Ordre des Experts Comptables (encours avec la participation de l'AFAI)
5. La nouvelle pratique du contrôle interne - Traduction
du COSO Report (version 1) - IFACI. Editions d'organisation. 1994
6. Le management des risques de l'entreprise - Cadre de
Référence - Techniques d'application - Traduction du COSO II -
IFACI. Editions d'Organisation. 2005
7. Le dispositif de contrôle interne : Cadre de
référence AMF (Autorité des Marchés Financiers) -
Édité par l'IFACI et disponible sur le site de l'AMF :
www.amf-france.org
8. An audit of Internal Control Over Financial Reporting
Performed in Conjunction with An Audit of Financial Statements Auditing
Standard N°2- PCAOB (The Public Compagny Accouting Oversight Board) -
Août 2007 :
www.pcaobus.org
9. An audit of Internal Control Over Financial Reporting That
Is Integrated with An Audit of Financial Statements Auditing Standard N°5-
PCAOB (The Public Company Accounting Oversight Board) - Juin 2007 :
www.pcaobus.org
10. Japan SOX : On the Setting of the Standard and Practice
Standards for Management Assessment and Audit concerning Internal Control Over
Financial Reporting - Business Accounting Council - Février 2007
11.
Mise en oeuvre d'un contrôle interne efficace via un ERP :
LSF,SOX, 8e Directive européenne, US GAAP, IFRS - Pascal Kerebel -
AFNOR
12. Contrôle interne - Frédéric Bernard,
Rémi Gayraud, Laurent Rousseau - Maxima, 2006
13. Livre blanc "Sécurité Financière et
Système d'Information" - Jean-Yves Galley, Pierre Bernassau
14. L'approche processus mode d'emploi- Éditions
Organisation - Septembre 2006 - 2ème édition
15. Audit 2ème édition. Gestion des risques
d'entreprise et contrôle interne. Hamzaoui - Pearson Education France.
16. Sarbanes-Oxley IT Compliance Using Open Source Tools,
2nd Edition - 2007 - Christian B. Lahti, Roderick Peterson- ISACA
17. Sarbanes-Oxley Guide for Finance and Information Technology
Professionals, 2nd Edition - Sanjay Anand - 2006- ISACA
18. Manager's Guide to Sarbanes-Oxley Act: Improving Internal
Control to Prevent Fraud - Scott Green - 2004- ISACA
19. IT Control Objectives for BASEL II: The Importance of
Governance and Risk Management for Compliance - IT Governance
20. Institute - 2007 - ISACA
21. Information Technology Audits - Lynford Graham, Xenia Ley
Parker-2007-ISACA
22.
Annexe :
Les systèmes d'information participent aux 5
composantes du contrôle interne telles que définies par le cadre
de l'AMF. Le tableau ci-après indique, pour chacun des thèmes
abordés dans le cadre de l'AMF, les recommandations faites par AFAI
précisant la façon dont ces thèmes peuvent être pris
en compte.
| 