Le contrôle interne du système d’information des …...Le système d’information, objet et...

Le contrôle interne dusystème d’informationdes organisationsGuide opérationnel d’application du cadre de référence AMFrelatif au contrôle interne

Le contrôle interne du système d’information des organisations

© CIGREF - IFACI

1. Préface ................................................................................................................................ 5

2. Résumé ............................................................................................................................... 7

3. Introduction ....................................................................................................................... 93.1. Contexte .................................................................................................................... 93.2. Publics cibles ............................................................................................................. 93.3. Rappel des objectifs .................................................................................................. 93.4. Périmètre retenu ....................................................................................................... 9 3.5. Les livrables ............................................................................................................. 103.6. Panorama des principaux processus métiers dans l’entreprise ........................... 10

3.6.1. L’entreprise vue comme une chaîne de valeur .......................................... 103.6.2. Les principaux processus de l’entreprise .................................................... 11

3.7. Les typologies de risques ....................................................................................... 133.8. Les acteurs du risque .............................................................................................. 143.9. Les points de contrôle existants ............................................................................ 16

4. Le contrôle du SI de l’entreprise ................................................................................. 174.1. Objectifs .................................................................................................................. 184.2. Périmètre retenu ..................................................................................................... 184.3. Démarche et rappel des principaux processus ..................................................... 184.4. Description du processus achats ........................................................................... 21

4.4.1. Processus ....................................................................................................... 214.4.2. Acteurs .......................................................................................................... 214.4.3. Risques .......................................................................................................... 224.4.4. Rapprochement entre risques et points de contrôles AMF ...................... 234.4.5. Rappel des principaux points de contrôles du guide

d'application AMF ........................................................................................ 244.4.6. Rapprochement entre points de contrôle AMF et exemples

de contrôle .................................................................................................... 254.4.7. Vue détaillée du processus achats ............................................................... 26

4.5. Description du processus ventes ........................................................................... 314.5.1. Processus ....................................................................................................... 314.5.2. Acteurs .......................................................................................................... 314.5.3. Risques .......................................................................................................... 324.5.4. Rapprochement entre risques et points de contrôles AMF ...................... 334.5.5. Rappel des principaux points de contrôles du guide


de contrôle .................................................................................................... 354.5.7. Vue détaillée du processus ventes ............................................................... 36

4.6. Description du processus consolidation financière ............................................. 434.6.1. Processus ....................................................................................................... 434.6.2. Acteurs .......................................................................................................... 434.6.3. Risques .......................................................................................................... 444.6.4. Rapprochement entre risques et points de contrôles AMF ...................... 454.6.5. Rappel des principaux points de contrôles du guide


de contrôle .................................................................................................... 474.6.7. Vue détaillée du processus consolidation financière ................................. 48

SO

MM

AIR

E

© CIGREF - IFACI

5. Le contrôle interne de la DSI ........................................................................................ 525.1. Objectifs .................................................................................................................. 535.2. Périmètre retenu ..................................................................................................... 545.3. Démarche suivie et principaux livrables ............................................................... 555.4. Les préalables au contrôle interne de la DSI ........................................................ 565.5. Gestion des compétences ...................................................................................... 58

5.5.1. Flowchart du processus de gestion des compétences de la DSI .............. 595.5.2. RACI du processus de gestion des compétences de la DSI ...................... 615.5.3. Matrice risques/contrôles du processus de gestion des compétences

de la DSI ........................................................................................................ 635.6. Projet et développement ........................................................................................ 68

5.6.1. Flowchart du processus de projet et développement ................................ 685.6.2. RACI du processus de projet et développement ........................................ 695.6.3. Matrice risques/contrôles du processus de projet et développement ...... 71

5.7. Maintenance et gestion des changements ........................................................... 895.7.1. Flowchart du processus de maintenance et gestion du changement ...... 905.7.2. RACI du processus de maintenance et gestion du changement .............. 935.7.3. Matrice risques/contrôles du processus de maintenance et gestion des

changements (applicatifs et techniques) .................................................... 955.8. Gestion des incidents ........................................................................................... 113

5.8.1. Flowchart du processus de gestion des incidents .................................... 1145.8.2. RACI du processus de gestion des incidents ............................................ 1155.8.3. Matrice risques/contrôles du processus de gestion des incidents .......... 116

5.9. Gestion de la sécurité logique et des accès physiques ....................................... 1205.9.1. Flowchart du processus de gestion d’attribution des droits d’accès ...... 1215.9.2. RACI du processus de gestion de sécurité logique et des accès ............. 1225.9.3. Matrice risques/contrôles du sous-processus d’accès aux programmes

et aux données ............................................................................................ 1235.10. Gestion de la sous-traitance et infogérance ....................................................... 129

5.10.1. Flowchart du processus de gestion de la sous-traitance ...................... 1305.10.2. RACI du processus de sous-traitance .................................................... 1325.10.3. Matrice risques/contrôles du processus de sous-traitance .................. 135

6. Annexes .......................................................................................................................... 1416.1. Annexe 1 – Charte CIGREF – IFACI ................................................................... 1426.2. Annexe 2 - Organismes et référentiels liés au contrôle interne ....................... 1436.3. Annexe 3 - Tableau de concordance entre les processus et les objectifs de

contrôle du cadre de référence de contrôle interne de l’AMF .......................... 1446.4. Annexe 4 – Exemples de typologies de risques .................................................. 1476.5. Glossaire ................................................................................................................ 149

7. Sources ............................................................................................................................ 152

SOM

MA

IRE


© CIGREF - IFACI

Figure 1 : Démarche et périmètre du contrôle du SI de l’entreprise ................................. 10

Figure 2 : Chaîne de valeur de l’entreprise .......................................................................... 11

Figure 3 : Cartographie des principaux processus de direction, opérationnels etsupport de l’entreprise ......................................................................................... 12

Figure 4 : Cartographie des principaux processus de l’entreprise ..................................... 12

Figure 5 : Typologie des risques d’entreprise ...................................................................... 13

Figure 6 : Typologie des points de contrôle ......................................................................... 15

Figure 7 : Les acteurs du risque – exemple de répartition des rôles et responsabilités ... 16

Figure 8 : Démarche suivie au sein du sous-groupe sur le contrôle du SI de l’entreprise ....................................................................................................... 19

Figure 9 : Les 14 catégories d’opérations concourant à l’élaboration de l’information comptable et financière publiée .......................................................................... 20

Figure 10 : Description du processus achats ......................................................................... 21

Figure 11 : Acteurs impliqués par étape du processus achats ............................................. 21

Figure 12 : Risques par étape du processus achats ............................................................... 22

Figure 13 : Rapprochement entre risques et points de contrôles AMF ............................... 23

Figure 14 : Rappel des principaux points de contrôle lié au processus achats ................... 24

Figure 15 : Rapprochement entre points de contrôle AMF et exemples de contrôle ........ 25

Figure 16 : Vue détaillée du processus achats ....................................................................... 26

Figure 17 : Description du processus ventes ......................................................................... 31

Figure 18 : Acteurs impliqués par étape du processus ventes ............................................. 31

Figure 19 : Risques par étape du processus ventes ............................................................... 32


Figure 21 : Rappel des principaux points de contrôle liés au processus ventes ................. 34


Figure 23 : Vue détaillée du processus ventes ....................................................................... 36

Figure 24 : Description du processus consolidation financière ........................................... 43

Figure 25 : Acteurs impliqués par étape du processus consolidation financière ................ 43

Figure 26 : Risques par étape du processus consolidation financière ................................. 44


Figure 28 : Rappel des principaux points de contrôle liés au processus consolidationfinancière ............................................................................................................... 46


Figure 30 : Vue détaillée du processus consolidation financière ......................................... 48

Figure 31 : Modèle de risques économiques ....................................................................... 147

Figure 32 : Nouvelle taxonomie des risques ....................................................................... 147

SO

MM

AIR

E

© CIGREF - IFACI

Le groupe de travail sur le contrôle du SI de l’entreprise a été piloté par Régis DELAYAT,DSI de SCOR. Nous tenons à remercier les personnes qui ont contribué à ces travaux :

• Samantha ANDRIAMAROHASY, DCNS• Thierry BLANCHARD, La Banque Postale• Carine CABALO, Groupe La Poste• Philippe ELBAZ, Les Mousquetaires• Jacques FASSEL, SCOR• Jean FERRE, L’Oréal• Jean-Claude HILLION, Banque de France• Maher KAMAL-RIZK, SCOR• Kacem MALTI, Rhodia • Guy NICOLAS, Nexans• Jean-Marie PIVARD, Nexans • Christine SHIMODA, L’Oréal • Isabelle TOURNASSOUD, EDF• Jean-Brice TULASNE, St Gobain

Le groupe de travail sur le contrôle interne de la DSI a été piloté par Farid ARACTINGI,Directeur Audit et Management des Risques de Renault. Nous tenons à remercier les per-sonnes qui ont contribué à ces travaux :

• Jean-Pierre BOUILLOT, Sanofi-Aventis, • Gilles BRUNET, France Telecom• Eric CORNAY, AXA• Philippe ELBAZ, Les Mousquetaires • Anne EMILIAN, Renault• Gilbert FENEUIL, Total • Annie GIRARD-LAOT, GDF Suez• Henri GUIHEUX, SCOR• Philippe HERVIAS, Sanofi-Aventis• Jean-Marc HOSPITAL, Renault• Alain ROGULSKI, Alcatel-Lucent• Cyrille ROY, AGF • Gérard VEDRENNE, Banque de France

L’étude a été coordonnée par Stéphane ROUHIER, chargé de mission au CIGREF etBéatrice KI-ZERBO, Directeur de la Recherche à l’IFACI et pilotée par Jean-François PEPIN,Délégué Général du CIGREF et Louis VAURS, Délégué Général de l’IFACI.

RE

ME

RCI

EM

EN

TS

L’objectif de ce document CIGREF-

IFACI est de sensibiliser les dirigeants

aux enjeux du contrôle interne et de la

maîtrise des systèmes d’information au sein

des organisations, tant publiques que privées,

tout en proposant aux managers des pistes

opérationnelles (démar che, check lists, …).

Il résulte des travaux communs réalisés par le

CIGREF et l’IFACI, dans le cadre de leur par-

tenariat signé le 9 octobre 2007. Celui-ci a été

décidé suite à l’élaboration début 2007 par un

groupe de place d’un cadre de référence du

contrôle interne, dont l’Autorité des Marchés

Financiers (AMF) recommande l’utilisation.

Le système d’information est en effet devenu

la colonne vertébrale d’une entreprise ou

d’une administration moderne, dont il irrigue

toutes les fonctions pour contribuer à la fois à

leur efficacité opérationnelle et à leur trans-

formation stratégique. Il est donc au cœur de

tous les métiers, et embarque les éléments de

standardisation, les besoins de spécificités et,

les contrôles de sécurité et de performance.

Dans une économie globalisée avec des pro-

cessus de plus en plus complexes, il est

devenu le garant de facto de la protection de

l’information, de la sincérité des opérations,

de la vitesse d’exécution et donc de l’excel-

lence opérationnelle. Et, de simple pour-

voyeur de systèmes et de technologies, la

Direction des systèmes d’information a vu

son rôle évoluer vers leur utilisation optimale

5


© CIGREF - IFACI

1. PRÉFACE

par les métiers et les utilisateurs au service de

la performance de l’entreprise.

Compte tenu de son rôle, la pertinence du

contrôle interne du système d’information,

c’est-à-dire sa bonne maîtrise, est un élément

clé de succès des organisations. Rappelons

que, selon le cadre de référence de l’AMF, un

bon contrôle interne contribue à la maîtrise

des activités d’une organisation, à l’efficacité

de ses opérations, à l’utilisation efficiente de

ses ressources, et doit lui permettre de pren-

dre en compte de manière appropriée les

risques significatifs. Le contrôle interne des

systèmes d’information est donc un sujet

prioritaire pour une organisation, et encore

plus actuellement où l’économie mondiale

subit une crise d’une rare intensité.

Dans ce contexte l’audit interne a, ces dix der-

nières années, renforcé continûment son

positionnement et son rôle. Il est de plus en

plus positionné comme partenaire des

organes dirigeants pour évaluer les enjeux et

les risques les plus importants et les plus

complexes des organisations. Il évalue l’en-

semble du système de contrôle interne et

fournit des conseils précieux pour leur pilo-

tage. Dans ce même esprit, le système d’infor-

mation devient aussi un moyen du contrôle,

puis qu’une mission d’audit sur un processus

ou une filiale utilisera largement les données

extraites des applications couvrant ce proces-

sus ou cette filiale.

Le système d’information, objet et moyen du

contrôle interne de l’entreprise, est donc un

sujet majeur sur lequel le CIGREF, association

de Grandes Entreprises utilisatrices de sys-

tème d’information et l’IFACI, association

professionnelle de l’audit et du contrôle

internes, ont décidé de collaborer, autour de

deux thèmes : le contrôle du système d’infor-

mation de l’entreprise et le contrôle interne

de la Direction des systèmes d’information.

Les résultats sont très opérationnels et facile-

ment adaptables aux caractéristiques propres

à chaque organisation. Ils sont à prendre en

compte dès la conception et le développe-

ment des applications et des systèmes. C’est

un outil au service des auditeurs, des contrô-

leurs, des informaticiens, mais aussi des

métiers, dont l’utilisation contribuera à l’amé-

lioration de l’efficacité des dispositifs de

contrôle interne et, fournira des réponses

concrètes aux questions centrales posées par

les organes de gouvernance.

6

© CIGREF - IFACI

Bruno MénardPrésident, CIGREF

Vice Président Systèmes d’Information,SANOFI-AVENTIS

Claude VietPrésident, IFACI

Directeur Audit Groupe, LA POSTE

Le contrôle interne a acquis ces dernières

années une dimension nouvelle, incontourna-

ble et consubstantielle à l’entreprise. Le

contrôle interne des organisations fait et

fera de plus en plus partie du paysage des

entreprises.

Cinq grands principes peuvent se dégager :

C’est aux managers d’instaurer une

culture et une dynamique du

contrôle par la mise en place d’une

organisation appropriée et d’un sys-

tème de management efficace (straté-

gie, politique, déploiement, ...).

Le contrôle interne doit être intégré

dans les processus de l’entreprise

(achat, vente, production, consolida-

tion, RH, …).

Les SI jouent un rôle clé dans une

bonne gouvernance d’entreprise et

dans un dispositif efficace de contrôle

interne. Ils sont non seulement un objet

mais aussi un levier du contrôle interne

des processus de l’entreprise.

Un principe de réalité, de propor-

tionnalité et de granularité doit s’ap-

pliquer dans tout dispositif de contrôle

interne. Il convient de penser à arbitrer

entre le coût et l’efficacité du dispositif.

Il faut enfin rester conscient du

caractère non exhaustif, des limites

intrinsèques et des arbitrages néces-

saires dans tout dispositif de contrôle.

Il est possible de formuler un certain nombre

de recommandations selon une démarche

PDCA (Plan Do Check Act) :

Planifier

• Etre clair sur la finalité, les objectifs et le

périmètre du contrôle ;

• en prérequis, avoir cartographié les pro-

cessus de l’entreprise et son patrimoine

informationnel.

Faire

• Avoir une démarche de contrôle au

« juste prix » ;

• avoir une démarche de contrôle en

partant des processus de l’entre-

prise, des risques associés et des

points de contrôle ;

• adapter la démarche à la culture et au

modèle d’organisation de l’entreprise,

ainsi qu’à la taille des entités contrôlées

(filiales notamment) ;

• utiliser les référentiels existants

(COBIT, ITIL, ISO 2700, …) ;

• coordonner les audits interne et

externe ;

• travailler en étroite collaboration entre

les différents acteurs « responsables »

dans l’organisation : direction de l’audit

interne, direction des systèmes d’infor-

mation, direction des risques, direction

juridique, direction de la sécurité, et

fonctions de contrôle interne sans pour

autant diluer les responsabilités ;

• s’appuyer sur la direction qualité et la

démarche qualité quand elles existent ;

• intégrer la démarche de contrôle

interne dans la construction des appli -

cations ou le pilotage du service infor-

matique.

7


© CIGREF - IFACI

2. RÉSUMÉ

Vérifier

• Les failles se situent souvent aux fron-

tières : il convient d’être attentif aux

risques à la jonction de plusieurs pro-

cessus ou lorsque les applications

transversales sont sous la responsabilité

partagée de plusieurs directions ;

• les points de contrôle applicatifs et

automatiques ainsi que les points de

contrôle non-applicatifs et manuels

sont indispensables et complémen-

taires ;

• évaluer régulièrement l’efficacité des

contrôles en place en fonction de l’évo-

lution du SI et de l’entreprise ;

• arbitrer le coût de mise en place d’un

contrôle avec les impacts du risque

identifié.

Mettre à jour

• Exploiter les résultats des audits interne

et externe et des revues ponctuelles des

prestataires externes pour améliorer le

système de management du contrôle

interne ;

• assurer un processus continu de mise à

jour de la cartographie des risques.

8

© CIGREF - IFACI

3.1. Contexte

Le CIGREF1 et l’IFACI2 ont signé une charte3 le 9 octobre 2007 visant à sensibiliser les dirigeants età aider concrètement les praticiens sur les enjeux du contrôle interne et de la maîtrise des systèmesd’information au sein des organisations, tant publiques que privées.

Cette initiative fait suite à la publication début 2007 du cadre de référence de contrôle interne del’AMF complété d’un guide d’application relatif à l’information comptable et financière.

Ce document précise qu’un dispositif de contrôle interne doit bénéficier de systèmes d’informa-tion adaptés aux objectifs actuels de l’organisation et capables de l’accompagner dans ses ambi-tions futures. La diffusion de bonnes pratiques dans ce domaine relève donc d’un impératif à lafois stratégique et opérationnel.

A cette fin, un groupe de travail commun aux deux associations professionnelles a été mis en place.

3.2. Publics cibles

Le document, coproduit par le CIGREF et l’IFACI, est destiné aux directeurs généraux, directeursmétiers, directeurs des systèmes d’information, directeurs d’audit interne, fonctions de contrôleinterne, consultants et auditeurs externes, soucieux de la mise en œuvre et de l’efficacité d’un dis-positif de contrôle interne.

3.3. Rappel des objectifs

L’objectif principal de ce document est le renforcement de l’efficacité du contrôle interne, en par-ticulier :

1. Enrichir la dimension SI du cadre de référence de l’AMF et mieux le relier aux référentielsexistants (COBIT, ITIL, ISO 2700x…).

2. Elaborer un guide d’application relatif au contrôle interne des systèmes d’information,incluant des listes de bonnes pratiques.

3. Aider la fonction SI et la fonction audit interne à mieux collaborer pour renforcer l’efficacitédu contrôle interne de l’entreprise.

3.4. Périmètre retenu

Le CIGREF et l’IFACI ont cherché à avoir une approche sélective et réaliste des risques.

9


© CIGREF - IFACI

1 www.cigref.fr - 2 www.ifaci.com - 3 Cf. Annexe 1

3. INTRODUCTION

http://www.ifaci.com

http://www.cigref.fr

Le groupe de travail aretenu une approchestructurée à partir desprocessus de l’entreprise,des risques associés, desobjectifs et des points decontrôle.

Les équipes mobiliséesont fonctionné en deuxsous-groupes mixtes, l’untraitant le contrôleinterne du SI de l’entre-prise, l’autre le contrôleinterne de la DSI.

Les deux sujets donnentlieu à un guide opéra-tionnel, dont la mise enœuvre devra être adaptéeau contexte de chaqueorganisation, à l’initiativedes propriétaires de pro-cessus.

3.5. Les livrables

• Une description des processus avec leurs principales étapes ;• une description des acteurs et de leurs rôles (RACI) ;• un diagramme de flux ;• une matrice risques / contrôles ;• quelques bonnes pratiques.

3.6. Panorama des principaux processus métiers dans l’entre prise

3.6.1. L’entreprise vue comme une chaîne de valeur

Avant de s’intéresser aux processus métiers de l’entreprise, on peut analyser l’entreprise demanière globale et transversale. L’entreprise peut être définie de plusieurs façons (approche struc-turelle, approche par les acteurs, système politique, etc.).

L’entreprise est, avant tout, une organisation dynamique qui mobilise des acteurs et des res-sources, au sein d’un écosystème, le long d’une chaîne de valeur et selon des processus. La finalitéde l’entreprise est de créer de la valeur pour les actionnaires et autres parties prenantes. Cette défi-nition est intéressante car on retrouve ces éléments (acteurs, ressources, rôles) et cette finalité dansl’analyse des principaux processus de l’entreprise.

10

© CIGREF - IFACI

Processus Risques

DSI

ContrôlesMÉTIERS

Applications

Système d'Information

Figure 1 : Démarche et périmètre du contrôledu SI de l’entreprise

Source : CIGREF - IFACI

3.6.2. Les principaux processus de l’entreprise

On classe généralement les processus en trois grandes catégories :• processus de direction ;• processus opérationnels ;• processus support.

Chaque macro-processus peut se découper en sous-processus / étapes. Il s’agit d’une typologiegénérique des processus : chaque entreprise peut avoir sa propre taxonomie.

11


© CIGREF - IFACI

Figure 2 : Chaîne de valeur de l’entrepriseSource : CIGREF - IFACI

Stratégie Conception Production Vente SupportGestion & contrôle

Ressources

Systèmed'information

Capital Processus

Salariés

Actionnaires

FournisseursClients

Autorités de

Contrôle

MarchésFinanciers

Presse

Partenaires

12

© CIGREF - IFACI

Figure 3 : Cartographie des principaux processus de direction,opérationnels et support de l’entreprise


Processus dedirection

• Stratégie• Organisation• Déontologie• Conformité• Gestion des Risques• Communication financière• Audit interne• Affaires Publiques• Communication interne• Relations sociales

Processus opérationnels

• Recherche &Développement

• Achats• Fabrication• Contrôle qualité• Distribution / Logistique• Marketing• Vente• Après-vente

Processussupport

• Contrôle de gestion• Trésorerie• Comptabilité• Investissements• Consolidation• Fiscalité• Juridique• RH• Services généraux• Informatique

Figure 4 : Cartographie des principaux processus de l’entreprise


Système d'information

Informatique

Comptabilité

Contrôle Gestion

Fiscalité

Trésorerie

Investissements

Système d'information

Consolidation

Juridique

RH

ServicesGénéraux

Achats

Fabrication

ContrôleQualité

Distribution

Marketing

Vente

SAV

R&D

Conformité

CommunicationFinancière

Affaires Publiques

GestionRisquesDéontologie

RelationsSociales

Audit Interne

CommunicationInterne

Stratégie

Organisation

13


© CIGREF - IFACI

L’informatique est ici considérée comme un des métiers supports de l’entreprise (Cf. figure 4). Enrevanche, dans cette représentation, le système d'information a été positionné autour de tous lesprocessus de l'entreprise, signifiant ainsi qu'il les irrigue tous, de manière transversale. L'efficacitéet la sécurité des processus dépendent directement du SI et de la pertinence des contrôles qui ysont intégrés.

Comme le précise le cadre de référence de l’AMF, le dispositif de contrôle interne assure le bonfonctionnement de l’ensemble des processus. Il permet la prise en compte appropriée des risquessignificatifs associés à leur mise en œuvre.

3.7. Les typologies de risques

Un des intérêts de la classification des risques dans une démarche de contrôle interne est de relierfinement les processus aux risques et aux points de contrôle associés. Il convient au préalabled’utiliser une cartographie des risques de l’entreprise.

Les risques informatiques doivent être intégrés dans la démarche de gestion des risques de l’en-treprise. Cette intégration passe par des méthodes communes et partagées afin de conserver unevision globale des risques.

On peut classer les risques en trois catégories : • risques financiers ;• risques opérationnels ;• risques de conformité.

Figure 5 : Typologie des risques d’entrepriseSource : CIGREF - IFACI

Risquesfinanciers

• Risques de contrepartie• Risques de taux• Risques de change• Risques de marché• Risques de liquidité

Risquesopérationnels

• Risques pays• Catastrophe naturelle• Fraudes, corruption• Failles de sécurité• Accidents de travail• Arrêts de production• Dommages aux actifscorporels

• Défaillances dansl’exécution et la gestiondes processus et dessystèmes

• Autres dysfonction-nements de l’activité

Risques deconformité

• Aspects légaux et régle-mentaires

• Risques de sanctions(administrative, judiciaire,disciplinaire)

• Risques de réputation etd’image

• Risques déontologiques• Risques contractuels

Il existe bien évidemment plusieurs autres formes de classification des risques.

• Le World Economic Forum distingue 5 catégories de risques (cf. annexe 4) : les risques écono-miques, sociétaux, environnementaux, technologiques et géopolitiques.

• Une autre classification (cf. annexe 4), proposée par Marsh Insurance, classe les risques en 5catégories : les risques aléatoires, financiers, opérationnels, organisationnels et stratégiques.

• On peut également mentionner des classifications de risques sectorielles telles que celle prévuepar le réglement CRBF 97-02 dans le secteur bancaire.

3.8. Les points de contrôle existants

Généralement on distingue les contrôles a priori (permettant de limiter l’occurrence d’un risque)et les contrôles a posteriori (visant à identifier et traiter les anomalies). On peut aussi distinguer les contrôles automatiques et les contrôles manuels.

Selon le référentiel COBIT, il existe trois grands types de contrôle : • les contrôles métiers (Business Controls) ;• les contrôles applicatifs (IT Applications Controls) ;• les contrôles généraux informatiques (IT General Controls).

Le contrôle du SI de l’entreprise repose sur les contrôles métiers et les contrôles applicatifs tandisque le contrôle de la DSI est basé sur la qualité des contrôles généraux informatiques.

Ce qui est important, c’est de ne pas oublier la finalité du contrôle (les objectifs) et d’être conscientde l’imperfection des outils, donc ne pas tout baser sur un seul type de contrôle. Il faut relier lescontrôles aux risques. L’efficacité des contrôles doit être régulièrement appréciée dans le cadred’un processus continu de réévaluation.

14

© CIGREF - IFACI

Figure 6 : Typologie des points de contrôle

Source : AFAI / C

OBIT

Cont

rôle

s m

étie

rTo

ut c

ontr

ôle

(tel

que

les

vérif

icat

ions

d'au

toris

atio

ns d

e tr

ansa

ctio

n, le

sra

ppro

chem

ents

exh

aust

ifs o

u no

n, ..

.)ef

fect

ué p

ar le

s en

tités

opé

ratio

nnel

les

dans

le c

adre

des

pro

cess

us m

étie

r.Ce

son

t sou

vent

des

con

trôl

es m

anue

lsqu

i s'a

ppui

ent s

ur d

es é

tats

pro

duits

par l

es a

pplic

atio

ns.

Cont

rôle

s ap

plic

atifs

On

appe

lle c

omm

uném

ent

"con

trôl

es a

pplic

atifs

" les

con

trôl

esin

tégr

és d

ans

les

appl

icat

ions

mét

ier.

Ils c

once

rnen

t, pa

r exe

mpl

e :

· l'e

xhau

stiv

ité,

· l'e

xact

itude

,· l

a va

lidité

,· l

'aut

oris

atio

n,· l

a sé

para

tion

des

tâch

es.

Cont

rôle

s gé

néra

uxin

form

atiq

ues

Les

cont

rôle

s gé

néra

ux s

ont c

eux

qui

sont

inté

grés

aux

pro

cess

us e

t aux

serv

ices

info

rmat

ique

s. Ils

con

cern

ent,

par e

xem

ple

:· l

e dé

velo

ppem

ent d

es s

ystè

mes

,· l

a ge

stio

n de

s ch

ange

men

ts,

· la

sécu

rité,

· l'e

xplo

itatio

n.

Resp

onsa

bilit

é de

s m

étie

rs

Cont

rôle

sm

étie

rs

Resp

onsa

bilit

é de

l'in

form

atiq

ueRe

spon

sabi

lité

des

mét

iers

Cont

rôle

sm

étie

rs

Serv

ices

auto

mat

isés

Cont

rôle

s ap

plic

atifs

Cont

rôle

s gé

néra

uxin

form

atiq

ues

Plan

iÞer

et o

rgan

iser

Acqu

érir

etim

plém

ente

r

Dél

ivre

ret

supp

orte

r

Surv

eille

r et é

valu

er

Exig

ence

s de

fonc

tionn

emen

t

Exig

ence

s de

cont

rôle

15


© CIGREF - IFACI

16

© CIGREF - IFACI

3.9. Les acteurs du risque

Au-delà de la démarche, ce qui importe c’est l’existence d’acteurs chargés de l’identification et dutraitement de ces risques.

Pour formaliser la gestion des risques, on a adopté le modèle RACI1 pour préciser les rôles et res-ponsabilités des acteurs à chaque stade du cycle de gestion du risque : identification, évaluation,traitement et surveillance du risque.

Vous trouverez, ci-après, un tableau indicatif des responsabilités respectives des différents acteursdu processus de management des risques.Ce tableau devra être adapté en fonction des spécificités de chaque organisation.

L’absence de certains acteurs peut être palliée, de même que certains acteurs peuvent avoir plu-sieurs rôles à un stade du processus.

Un des enjeux aujourd’hui porte sur la coopération, entre acteurs du risque, au sein des organisa-tions. Elle se fait au sein de structures de coordination et d’arbitrage à tous les niveaux de l’entre-prise.

Figure 7 : Les acteurs du risque –exemple de répartition des rôles et responsabilités


Identification desrisques

Evaluation desrisques

Traitement desrisques

Surveillance

Direction générale Approbateur Approbateur Informé Approbateur

Directeur métier * Approbateur Approbateur Approbateur Approbateur

Opérationnelsmétier

Réalisateur Réalisateur Réalisateur Consulté

Direction dessystèmes

d’informationRéalisateur Consulté

Risk ManagerGroupe

RéalisateurRéalisateur /Approbateur

Informé Informé

ResponsableSécurité SI

Informé Informé Réalisateur

Responsable ducontrôle interne

Consulté Consulté Consulté Réalisateur

Audit interneInformé /

Réalisateur **Informé /

Réalisateur **Informé Réalisateur

* le DSI est considéré comme un directeur métier** pour ses activités propres (plan d’audit, programme de travail des missions ...)

1 Le modèle RACI est un modèle qui permet de décrire les rôles et responsabilités des acteurs au sein d’une organisation, sur un processus donné.RACI définit 4 rôles - R: Responsible ou Réalisateur, A: Accountable ou Approbateur C: Consulted ou Consulté, I: Informed ou Informé.

4.1. Objectifs .................................................................................................................. 184.2. Périmètre retenu ..................................................................................................... 184.3. Démarche et rappel des principaux processus ..................................................... 184.4. Description du processus achats ........................................................................... 21

4.4.1. Processus ....................................................................................................... 214.4.2. Acteurs .......................................................................................................... 214.4.3. Risques .......................................................................................................... 224.4.4. Rapprochement entre risques et points de contrôles AMF ...................... 234.4.5. Rappel des principaux points de contrôles du guide


de contrôle .................................................................................................... 254.4.7. Vue détaillée du processus achats ............................................................... 26

4.5. Description du processus ventes ........................................................................... 314.5.1. Processus ....................................................................................................... 314.5.2. Acteurs .......................................................................................................... 314.5.3. Risques .......................................................................................................... 324.5.4. Rapprochement entre risques et points de contrôles AMF ...................... 334.5.5. Rappel des principaux points de contrôles du guide


de contrôle .................................................................................................... 354.5.7. Vue détaillée du processus ventes ............................................................... 36

4.6. Description du processus consolidation financière ............................................. 434.6.1. Processus ....................................................................................................... 434.6.2. Acteurs .......................................................................................................... 434.6.3. Risques .......................................................................................................... 444.6.4. Rapprochement entre risques et points de contrôles AMF ...................... 454.6.5. Rappel des principaux points de contrôles du guide


de contrôle .................................................................................................... 474.6.7. Vue détaillée du processus consolidation financière ................................. 48

17


© CIGREF - IFACI

4. LE CONTRÔLE DU SI DE L’ENTREPRISE

18

© CIGREF - IFACI

4.1. Objectifs

Ce chapitre s’intéresse au contrôle interne des métiers de l’entreprise, par le prisme des SI, com-posant essentiel de toute activité. Il a pour but de fournir aux lecteurs les éléments suivants :

• une cartographie stratégique des principaux processus et risques au niveau de l’entreprise ;• un guide d’application du cadre de référence AMF relatif au contrôle interne ;• un guide méthodologique sur trois processus représentatifs et standards d’entreprise : les

processus achat, vente et consolidation financière ;• une boite à outils relative aux points de contrôle et bonnes pratiques.


L’ensemble des macro-processus de l’entreprise et macro-risques associés a été cartographié. Ausein de ces macro-processus, les participants ont retenus trois processus clés en raison de leurcaractère générique, commun aux entreprises mais aussi parce qu’ils étaient évoqués dans le cadrede référence AMF. Il s’agit des processus suivants :

• le processus achats ;• le processus vente ;• le processus consolidation financière ;

4.3. Démarche et rappel des principaux processus

Pour chacun de ces trois processus, la démarche a porté successivement sur les points suivants : • description du processus ;• acteurs ;• risques associés ;• points de contrôles associés (en partant du cadre de référence AMF) ;• contrôles et bonnes pratiques (le cas échéant).

En revanche la réflexion n’a pas porté sur des éléments de contexte jugés trop spécifiques ou pro-pres à chaque entreprise, notamment le mapping pro cessus / applications (spécifique), la typologiedes applications, les particularismes sectoriels des organisations.

19


© CIGREF - IFACI

Figure 8 : Démarche suivie au sein du sous-groupe sur le contrôle du SI de l’entreprise


Étapes

Acteurs Risques

Points de contrôle AMF

Contrôles

Processus

Les participants se sont attachés à lister un maximum de contrôles afin de fournir une aide opéra-tionnelle et concrète au développement, au paramétrage ou à la maintenance des applicationsinformatiques relatives aux trois processus étudiés. L'atteinte d'un bon niveau de contrôle des pro-cessus passe de fait par l'intégration des contrôles identifiés dans les systèmes correspondants. Ilsne peuvent néanmoins à ce stade avoir de caractère exhaustif, et pourront être étendus à loisir enfonction des besoins de chaque entreprise. C'est la raison pour laquelle le document parle d'exem-ples de contrôles.L'important était de faire prendre conscience que la construction d'un système quel qu'il soit nepouvait se limiter à l'automatisation des différentes étapes des processus métiers, mais devait aussiimpérativement intégrer des routines de contrôle de leur bon fonctionnement.

20

© CIGREF - IFACI

A partir des 14 catégories d’opérations concourant à l’élaboration de l’information financièrepubliée, le groupe a retenu trois processus :

1) les achats fournisseurs et assimilés ;2) les produits des activités ordinaires, clients et assimilés ; et3) la consolidation.

Ces trois processus [en gras et en couleur] dans le tableau ci-après ont été étudiés dans leschapitres suivants.

Figure 9 : Les 14 catégories d’opérations concourant à l’élaborationde l’information comptable et financière publiée

Source : Cadre de référence AMF (chap 2 - p39-50)

N° de § Nom de l’opération

2.3.1 Investissement / désinvestissement / R&D

2.3.2 Immobilisations incorporelles, corporelles et goodwills

2.3.3 Immobilisations financières

2.3.4 Achats fournisseurs et assimilés

2.3.5 Coût de revient / stocks et encours / Contrats à long terme ou de construction

2.3.6 Produits des activités ordinaires / Clients et Assimilés

2.3.7 Trésorerie / financement et instruments financiers

2.3.8 Avantages accordés au personnel

2.3.9 Impôts, taxes et assimilés

2.3.10 Opérations sur le capital

2.3.11 Provisions et engagements

2.3.12 Consolidation

2.3.13Information de gestion nécessaire à l’élaboration des informations comptables et finan-cières publiées

2.3.14 Gestion de l’information financière externe

21


© CIGREF - IFACI

4.4. Description du processus achats

4.4.1. Processus

Le processus achats est découpé en sept étapes, résumées dans le graphique ci-dessous.

NB : le processus budgétaire a été volontairement exclu.

4.4.2. Acteurs

Les acteurs impliqués par étape sont décrits dans le schéma ci-dessous.

Figure 10 : Description du processus achatsSource : CIGREF - IFACI

Figure 11 : Acteurs impliqués par étape du processus achatsSource : CIGREF - IFACI

1. Recherche des

fournisseurs

2. Définitiondes

besoins

3. Sélectiondes

fournisseurs

4. Contractua-lisation

etcommande

5. Réceptionet

pilotage dufournisseur

6. Comptesfournisseurs

7. Processde

paiement

Directionachats,Métiers,

Comptabilité

Prescripteurs,Métiers

Directionachats

Direction juridique,Direction

achats

Directionmétiers,

Logistique

Directionjuridique,

Comptabilité

Directionjuridique,Trésorerie,

Métiers

1. Recherchedes

fournisseurs

2. Définitiondes

besoins

3. Sélectiondes

fournisseurs

4. Contrac-tualisation

etcommande

5. Réceptionet

pilotage dufournisseur

6. Comptesfournisseurs

7. Processusde

paiement

22

© CIGREF - IFACI

Figure 12 : Risques par étape du processus achats


4.4.3. Risques

Les principaux risques portent sur le non-respect des fournisseurs autorisés, le non-respect desmontants autorisés, le non-respect du principe de séparation des tâches, le manque de contrôlequalité à la réception, la fraude.

1. R

ech

erch

e d

esfo

urn

isse

urs

2. D

éfin

itio

nd

esb

eso

ins

3. S

élec

tio

nd

esfo

urn

isse

urs

4. C

on

trac

tua-

lisat

ion

etco

mm

and

e

5. R

écep

tio

net

pilo

tag

e d

ufo

urn

isse

ur

6. C

om

pte

sfo

urn

isse

urs

7. P

roce

ssd

e p

aiem

ent

- Ach

ats

e�ec

tués

aupr

ès d

efo

urni

sseu

rs

non

auto

risés

- Dép

ense

s no

n au

toris

ées

d'e�

ectu

ées

- Ris

ques

léga

ux

et Þ

nanc

iers

no

n m

esur

és- N

on re

spec

t de

s dé

léga

tions

de

sign

atur

eet

des

seu

ils Þ

nanc

iers

- Dél

it de

m

arch

anda

ge- C

laus

es

cont

ract

uelle

s lé

onin

es- N

on re

spec

t de

s co

nditi

ons

géné

rale

s d'

acha

ts

- Ana

lyse

de

mar

ché

insu

!sa

nte

- Ach

at a

uprè

s de

four

niss

eurs

non

aut

oris

és- S

olid

ité Þ

nanc

ière

du

four

niss

eur

- Ris

que

de

dépe

ndan

ce- R

isqu

e de

déf

aut d

e p

aiem

ent

- Oub

li de

(pet

its)

four

niss

eurs

in

nova

nts

- Ach

ats

non

optim

isés

man

que

d'an

ticip

atio

n ou

co

nsol

idat

ion

- Mau

vais

e dé

Þniti

on d

es b

esoi

ns o

u m

auva

ise

pré

visi

on- B

udge

t in

su!

sant

- Im

puta

tion

sur

lign

es d

e bu

dget

err

onée

s

- Ach

ats

aupr

èsde

four

niss

eurs

no

n au

toris

és

- Ach

ats

de

four

nitu

res

non

auto

risée

s- N

égoc

iatio

n su

rle

s co

ûts

pas

optim

isée

- Fra

ude

(col

lusi

on)

appe

l d'o

�re

non

enre

gist

ré- N

on c

onfo

rmité

avec

le c

adre

ré

glem

enta

ire- P

rodu

ctiv

ité

fonc

tion

acha

t mal

m

esur

ée- S

élec

tion

des

four

niss

eurs

se

ulem

ent

basé

e su

r le

prix

- Man

que

de

cont

rôle

qua

litat

ifet

qua

ntita

tif à

la ré

cept

ion

des

bien

s- F

raud

e / M

auva

is

enre

gist

rem

ent

- Cut-off

- Non

sép

arat

ion

des

tâch

es

(ou

non

resp

ect)

- Cut-o

- Fra

ude

/ Mau

vais

en

regi

stre

men

t- P

rodu

ctiv

ité d

u se

rvic

e co

mpt

able

du

four

niss

eur

pas

optim

isée

- Mau

vais

con

trôl

e d

e la

cha

îne

glob

ale

:co

mm

ande

, ré

cept

ion,

fa

ctur

atio

n- D

élai

s

- Fra

ude

/ mau

vais

enre

gist

rem

ent

- Dou

ble

paie

men

t - P

ratiq

ue n

on

prof

essi

onne

lle d

es

tran

sact

ions

- Cha

rge

de tr

avai

l, dé

lai d

e tr

aite

men

t en

tre

le d

épar

tem

ent

acha

ts e

t le

serv

ice

com

ptab

ilité

23


© CIGREF - IFACI

4.4.4. Rapprochement entre risques et points de contrôles AMF

Le schéma ci-dessous relie les risques aux points de contrôle (PC, par exemple PC4.1) décrits dansle cadre de référence AMF. Chaque entreprise peut avoir une démarche spécifique et relier ses pro-pres risques aux points de contrôles.

Figure 13 : Rapprochement entre risques et points de contrôles AMF


1. R

ech

erch

e d

esfo

urn

isse

urs

2. D

éfin

itio

nd

esb

eso

ins

3. S

élec

tio

nd

esfo

urn

isse

urs

4. C

on

trac

tua-

lisat

ion

etco

mm

and

e

5. R

écep

tio

net

pilo

tag

e d

ufo

urn

isse

ur

6. C

om

pte

sfo

urn

isse

urs

7. P

roce

ssd

e p

aiem

ent

Mau

vais

co

ntr

ôle

de

lach

aîn

e co

mp

lète

: co

mm

and

e,

réce

pti

on

,fa

ctu

re (P

C 4

.4)

No

n s

épar

atio

nd

es rô

les

(ou

no

n

resp

ect)

(PC

4.2

)

Frau

de

/ M

auva

isen

reg

istr

emen

t(P

C 4

.1)

No

n p

rise

en

com

pte

des

seu

ilsfin

anci

ers

(PC

4.3

)

Dép

ense

s n

on

au

tori

sées

effe

ctu

ées

(PC

4.8

)

Frau

de

(co

llusi

on

...)

(PC

4.1

)

Les

ach

ats

son

tef

fect

ués

ave

c d

esfo

urn

isse

urs

no

n

auto

risé

s (P

C 4

.1)

Man

qu

e d

e co

ntr

ôle

qu

alit

atif

et q

uan

tita

tif à

la

réce

pti

on

(P

C 4

.7)

Exp

osi

tio

n lé

gal

e et

fin

anci

ères

no

n

iden

tifié

e (P

C 4

.8)

Frau

de

/ M

auva

isen

reg

istr

emen

t(P

C 4

.1)

Frau

de

/ M

auva

isen

reg

istr

emen

t(P

C 4

.7)

Dép

ense

s n

on

au

tori

sées

effe

ctu

ées

(PC

4.8

)

Les

ach

ats

son

tef

fect

ués

ave

c d

esfo

urn

isse

urs

no

n

auto

risé

s (P

C 4

.1)

Les

ach

ats

son

tef

fect

ués

ave

c d

esfo

urn

isse

urs

no

n

auto

risé

s (P

C 4

.1)

24

© CIGREF - IFACI

4.4.5. Rappel des principaux points de contrôle du guide d'application AMF

Le tableau ci-dessous reprend les principaux points de contrôle tels que listés dans le guided'appli cation du cadre de référence AMF.

Figure 14 : Rappel des principaux points de contrôle lié au processus achatsSource : Cadre de référence AMF (chap 2 - p41-42)


2.3.4 Achats fournisseurs et assimilés

2.3.4.1Le processus achats est organisé et formalisé dans le cadre de procédures applicables partous les acteurs concernés.

2.3.4.2Il existe une séparation des fonctions de passation et d’autorisation des commandes, deréception, d’enregistrement comptable et de règlement des fournisseurs.

2.3.4.3Les achats importants font l’objet d’une commande formalisée, validée par une personneautorisée.

2.3.4.4Il existe un suivi et un rapprochement entre les bons de commande, les bons de réceptionet les factures (quantité, prix, conditions de paiement). Les anomalies éventuelles fontl’objet d’une analyse et d’un suivi.

2.3.4.5Il existe un dispositif permettant d’éviter le double enregistrement / paiement des facturesfournisseurs.

2.3.4.6 Il existe un contrôle des avances sur factures fournisseurs (autorisation, suivi, imputation).

2.3.4.7Il existe un suivi des réceptions refusées / litiges et un contrôle de la comptabilisation desavoirs fournisseurs correspondants ou des rabais, remises et ristournes (RRR).

2.3.4.8La gestion des règlements fournisseurs fait l’objet de contrôles par une personne indépen-dante et autorisée.

2.3.4.9Les comptes fournisseurs font l’objet d’un examen et d’une justification périodiques(exhaustivité, exactitude).

2.3.4.10Il existe une procédure permettant de s’assurer que les produits et charges ont été enregis-trés sur la bonne période.

2.3.4.11Il existe un dispositif permettant d’enregistrer les provisions pour factures non parvenuesou les charges payées d’avance de manière exhaustive et exacte.

25


© CIGREF - IFACI

Figure 15 : Rapprochement entre points de contrôle AMF et exemples de contrôle So

urce : CIGREF - IFACI

4.4.6. Rapprochement entre points de contrôle AMF et exemples de contrôle

Le schéma ci-dessous propose un rapprochement entre points de contrôle AMF et exemples decontrôle. Il s’agit d’exemples de contrôle, donnés à titre d’illustration. La liste n’est pas exhaustive.La plupart des contrôles mentionnés ci-après concerne essentiellement des aspects SI.

Proc

essu

s A

chat

s

2.3.

4 2)

Sép

arat

ion

des

fo

nct

ion

s d

e p

assa

tio

n e

t d

'au

tori

sati

on

des

co

mm

and

es, d

e ré

cep

-ti

on

, d'e

nre

gis

trem

ent

com

pta

ble

et

de

règ

le-

men

t d

e fo

urn

isse

urs

.Pr

ofil

uti

lisat

eur d

ans

l'ap

plic

atif

diff

éren

t se

lon

le

s tâ

ches

.Tr

ansa

ctio

n p

erm

etta

nt

d'id

enti

fier t

ou

s le

s ca

s d

e n

on

resp

ect

de

la s

épar

a-ti

on

des

tâc

hes

2.3.

4 1)

Pro

cess

us

ach

ats

org

anis

é et

form

alis

é

- Pro

cess

us

org

anis

atio

n-

nel

- Pro

cess

us

do

cum

enté

- In

tég

rati

on

des

pro

fits

et d

roit

s as

soci

és- T

raça

bili

té- S

égré

gat

ion

des

tâc

hes

2.3.

4 3)

Ach

ats

imp

or-

tan

ts fo

rmal

isés

par

un

e co

mm

and

e va

lidée

par

u

ne

per

son

ne

auto

risé

e.R

app

roch

emen

t in

form

atiq

ue

Dem

and

e d

'ach

at /

Bo

n d

e co

mm

and

e /

Bo

n d

e ré

cep

tio

n /

Fact

ure

Pro

cess

us

d'a

pp

rob

a-ti

on

élec

tro

niq

ue

des

dem

and

es d

'ach

ats.

Co

ntr

ôle

d'a

uto

risa

tio

nd

es m

od

ifica

tio

ns

de

tari

fs e

t tr

açab

ilité

2.3.

4 4)

Su

ivi e

t ra

pp

ro-

chem

ent.

An

om

alie

s év

entu

elle

san

alys

ées

et s

uiv

ies

Rap

pro

chem

ent

info

r-m

atiq

ue

Co

ntr

ôle

info

rmat

iqu

e en

tre

la c

om

man

de

et

la fa

ctu

re a

vec

blo

cag

eV

érifi

cati

on

qu

e le

sco

nd

itio

ns

de

pai

emen

tso

nt

app

liqu

ées

Au

tres

po

ints

de

con

trô

le (p

as n

éces

sai-

rem

ent

app

licat

ifs)

- Sig

nat

ure

d'u

ne

char

teen

tre

l'en

trep

rise

et

lefo

urn

isse

ur

- Fo

rmat

ion

en

inte

rne

/se

nsi

bili

sati

on

au

ris

qu

e d

e fr

aud

e et

de

corr

up

-ti

on

2.3.

4. 1

1) Il

exi

ste

un

d

isp

osi

tif p

erm

etta

nt

d'e

nre

gis

trer

les

pro

visi

on

s p

ou

r fac

ture

sn

on

par

ven

ues

ou

les

char

ges

pay

ées

d'a

van

ce d

e m

aniè

reex

hau

stiv

e et

exa

cte

2.3.

4 10

) Pro

céd

ure

po

ur

véri

fier q

ue

les

pro

du

its

et c

har

ges

so

nt

enre

gis

-tr

és s

ur l

a b

on

ne

pér

iod

eÉt

at d

es e

ng

agem

ents

per

met

tan

t d

e vé

rifie

rm

anu

elle

men

t l'e

xhau

sti-

vité

des

pro

visi

on

s p

ou

r FN

P à

la c

lôtu

reÉt

at in

form

atiq

ue

per

met

-ta

nt

de

just

ifier

le c

om

pte

40

8 fa

ctu

res

no

n p

arve

-n

ues

ave

c l'é

tat

des

co

mm

and

es n

on

livr

ées

/ n

on

réce

pti

on

née

s

2.3.

4 9)

Exa

men

et

just

ifica

tio

n p

ério

diq

ue

des

co

mp

tes

fou

rnis

-se

urs

(exh

aust

ivit

é,

exac

titu

de)

Rap

pro

chem

ent

auto

-m

atiq

ue

BG

/ B

alan

ce a

uxi

liair

eLe

ttra

ge

auto

mat

iqu

e d

es c

om

pte

s fo

urn

is-

seu

rs lo

rs d

e p

aiem

ent

auto

mat

iqu

e (le

ttra

ge

man

uel

po

ur l

es p

aie-

men

ts m

anu

els,

mo

ins

de

1% d

es p

aiem

ents

)

2.3.

4 8)

Ges

tio

n d

esrè

gle

men

ts fo

urn

isse

urs

con

trô

lés

par

un

ep

erso

nn

e in

dép

end

ante

et

au

tori

sée

Pro

fil u

tilis

ateu

r dan

sl'a

pp

licat

if d

iffér

ent

selo

n

les

tâch

esTr

ansa

ctio

n p

ou

r id

enti

-fie

r les

cas

de

no

n

sép

arat

ion

des

tâc

hes

"Exc

epti

on

rep

ort

" re

traç

ant

les

chan

ge-

men

ts a

pp

ort

és a

u fi

chie

r fo

urn

isse

urs

Vér

ifica

tio

n d

u fi

chie

rp

aiem

ent

fou

rnis

seu

rs

2.3.

4 7)

Exi

sten

ce d

'un

su

ivi d

es ré

cep

tio

ns

refu

sées

/ li

tig

es e

t co

ntr

ôle

de

la

com

pta

bili

sati

on

des

av

oir

s fo

urn

isse

urs

ou

d

es ra

bai

s, re

mis

es e

t ri

sto

urn

es (R

RR)

Ou

tils

info

rmat

iqu

esLe

s RR

R so

uve

nt

com

pta

bili

sés

en é

cart

d

e p

rix

par

so

uci

de

sim

plif

icat

ion

Suiv

i des

fact

ure

s av

eclit

ige

2.3.

4 6)

Exi

sten

ce d

'un

con

trô

le d

es a

van

ces

sur f

actu

res

fou

rnis

-se

urs

(au

tori

sati

on

, su

ivi,

imp

uta

tio

n)

Poss

ibili

té d

'avo

ir u

néc

héa

nci

er d

es

fact

ure

s d

'aco

mp

tes

fou

rnis

seu

rs p

ou

rp

erm

ettr

e le

ur s

uiv

iLi

en e

ntr

e le

s ac

om

pte

set

les

com

man

des

par

le n

° de

com

man

de

2.3.

4 5)

Dis

po

siti

f p

erm

etta

nt

d'é

vite

r le

do

ub

le e

nre

gis

trem

ent

&

pai

emen

t d

es fa

ctu

res

fou

rnis

seu

rsD

ou

ble

en

reg

istr

emen

t :

Co

ntr

ôle

au

tom

atiq

ue

sur l

e n

um

éro

de

fact

ure

Do

ub

le p

aiem

ent

:B

loca

ge

auto

mat

iqu

eem

pêc

han

t le

pai

emen

ten

do

ub

le d

'un

e m

ême

fact

ure

(po

ur l

esp

aiem

ents

au

tom

ati-

qu

es)

26

© CIGREF - IFACI

Figure 16 : Vue détaillée du processus achats

Etape

Acteurs

Description

Risques

Exemple de contrôles applicatifs

Contrôles transversaux au processus

Cadre de référence AMF : Processus

Achats / Fournisseurs et assimilés

1) Recherche

des fournis-

seurs

Direction

achats

1. Pilotage et évolution des fournisseurs : la fonc-

tion achats coopère avec les autres départements

pour anticiper les besoins futurs. Pendant ce

temps là les connaissances sur les fournisseurs, les

techniques, les innovations industrielles et les

évolutions du marché sont capitalisées. Les four-

nisseurs principaux (actuels et potentiels) sont

connus.

2. Recherche de solutions alternatives : cela inclut

des études sur les technologies et les modes

d’achat des biens et services critiques.

3. Liste des prestataires acceptés : la liste des pres-

tataires acceptés mise à jour est définie par

segment / famille de produits et selon des critères

pertinents. Cette liste doit être utilisée par les

acheteurs.

Analyse de marché / recherche

insuffisante

Les achats sont effectués auprès de

fournisseurs non autorisés

Les partenariats sont développés

avec les meilleurs fournisseurs

(Risque de dépendance)

Solidité financière du fournisseur

insuffisante

Risque de défaut de paiem

ent

Oubli de (petits) fournisseurs inno-

vants

2.3.4.1) Le processus acha

ts est organ

isé et

form

alisé da

ns le cad

re de procéd

ures app

lica-

bles par to

us les ac

teurs concerné

s.=>Processus organisationnel

=>Le processus doit être documenté

Intégration des profils et droits associés

Traçabilité

Séparation des tâches incompatibles

2.3.4.2) Il existe un

e sépa

ration

des fo

nction

sde

passation

et d

’autorisation de

scomman

des, de

réception, d’enreg

istrem

ent

comptab

le et d

e règlem

ent d

es fo

urnisseu

rs.

-Profil utilisateur dans le progiciel / logiciel

différent selon les tâches

-Il existe une transaction permettant

d’identifier tous les cas de non respect de

la séparation des tâches

2.3.4.3) Les ach

ats im

portan

ts fo

nt l’ob

jet

d’un

e comman

de fo

rmalisée, validée par une

person

ne autorisée.

-Rapprochem

ent informatique Dem

ande

d’achat / Bon de commande / Bon de

réception / facture

-Processus d’approbation électronique des

dem

andes d’achats / commande

-Contrôle d’autorisation des modifications

de tarif et traçabilité

2) Définition

des besoins

Prescripteurs,

métiers

1. Anticipation des besoins / consolidation des

besoins : les besoins sont identifiés en terme d’ob-

jectifs, d’attentes et de coût par les utilisateurs et

communiqués au département achats. Les achats

sont planifiés et regroupés par période et entre

unités / sites.

2. Validation : Les dem

andes d’achat sont ém

ises

pour tous les achats et approuvées par le respon-

sable du budget, selon les délégations de pouvoir

définies.

Des dépenses non-autorisées sont

effectuées, budget insuffisant

Les achats ne sont pas optimisés à

cause d’un manqué d’anticipation /

de consolidation

Mauvaise définition des besoins /

prévision incorrecte

Budget insuffisant,

Mauvaise imputation analytique et

comptable de la dépense / investis-

sement

4.4.7.

Vue détaillée du processus achats

27


© CIGREF - IFACI

Etape

Acteurs

Description

Risques





3) Sélection

des fournis-

seurs

Direction

achats,

métiers,

comptabilité

1. Dem

ande de devis / d’information : un nombre

de fournisseurs identifiés sont invités à envoyer

des offres détaillants leurs solutions, les prix, le

calendrier. L’appel d’offre doit aussi spécifier les

règles auxquelles chaque fournisseur devra se

conformer pendant le processus de sélection ainsi

que le calendrier, les dates clés et les livrables.

2. Analyse de l’offre : les différents devis sont

analysés par l’équipe en utilisant des critères

prédéterminés, applicables à tous les fournisseurs.

L’analyse est présentée dans un tableau de

synthèse pour faciliter la comparaison des

réponses de chaque fournisseur. Une présélection

des fournisseurs peut être faite avant d’aller plus

loin. Avant d’entrer dans les négociations avec les

fournisseurs, les objectifs des discussions doivent

être définis et documentés pour rendre les objec-

tifs clairs pour tout le monde.

3.Négociation et sélection : cela recouvre les

aspects financiers, juridiques et le calendrier. Les

questions concernant les spécifications seront

abordées si un expert technique (ou un utilisa-

teur) est impliqué. Plusieurs rounds de négocia-

tion peuvent être nécessaires, ce qui peut

impliquer de nouveaux devis. Après la négociation

avec chaque fournisseur, un fournisseur est sélec-

tionné, en utilisant des critères objectifs et docu-

mentés. Les critères peuvent être pondérés.

L’utilisateur valide la sélection de l’acheteur d’un

point de vue fonctionnel et technique, essentielle-

ment en fonction des spécifications définies préa-

lablement.



Achats de fournitures non auto-

risés

La négociation sur les coûts n’est

pas optimisée

Fraude (collusion, …

)

Appel d’offre non enregistré / ou

mal enregistré

Non conformité avec le cadre

réglementaire européen sur les

marchés publics

La productivité de la fonction achat

n’est pas correctement mesurée

La sélection des fournisseurs est

seulement basée sur le prix


suivi et u

n rapp

roch

emen

ten

tre les bo

ns de comman

de, les bon

s de

réception et les factures (q

uantité, prix, con

di-

tion

s de

paiem

ent). Les ano

malies éven

tuelles

font l’ob

jet d

’une

ana

lyse et d

’un suivi.

-Rapprochem

ent informatique, dem

ande

d’achat / Bon de commande / Bon de

réception / facture

-Contrôle informatique entre la commande

et la facture sur les quantités et les prix

avec blocage

-Etat informatique permettant de justifier

le compte 408 factures non parvenues

avec l’état des commandes non livrées/

non réceptionnées

-Vérification que les conditions de paie-

ment sont appliquées


dispo

sitif p

ermettant

d’évite

r le do

uble enreg

istrem

ent / paiem

ent

des factures fo

urnisseu

rs.

-Pour éviter le double enregistrem

ent

d’une facture, il existe un contrôle auto-

matique sur le numéro de facture

-Pour éviter le double paiem

ent, il existe un

blocage automatique qui empêche le

paiem

ent en double d’une mêm

e facture

(pour les paiem

ents automatiques)


con

trôle de

s av

ances sur

factures fo

urnisseu

rs (a

utorisation, suivi, impu

-tation

).-Possibilité d’avoir un échéancier des

factures d’acomptes fournisseurs pour

permettre leur suivi

-Lien entre les acomptes et les commandes

par le n° de commande

28

© CIGREF - IFACI

Etape

Acteurs

Description

Risques





4) Contrac-

tualisation et

commande

Direction

juridique,

direction

achats

1. Contractualisation et commande : la contrac-

tualisation des engagem

ents des fournisseurs

peut revêtir plusieurs formes (bon de commande,

commande ouverte, accord de site, accord d’entre-

prise). Les contrats sont soumis aux conditions

légales et contractuelles exam

inées avec le dépar-

tement juridique. Les contrats sont communiqués

à tous les départements concernés, dont le dépar-

tement des finances.

2. Autorisation : les engagem

ents d’achat (contrat,

commande) sont autorisés en fonction des délé-

gations de pouvoir, des seuils autorisés (par

montant et type d’achats) et en fonction de la

séparation des tâches.



Des dépenses non-autorisées sont

effectuées

Les risques légaux et financiers ne

sont pas mesurés (délit de

marchandage, prêt illicite de main

d’œuvre, clauses contractuelles

léonines, …

)

Pas de respect des délégations de

signature et des seuils financiers

Non respect des conditions géné-

rales d’achats et conditions géné-

rales de ventes


suivi des ré

ceptions

refusées

/ litiges et u

n contrôle de la com

ptab

i-lisation de

s av

oirs fo

urnisseu

rs correspon

-da

nts ou

des ra

bais, rem

ises et ristourne

s (à la

facture, à la com

man

de).

-Des outils informatiques existent mais pas

obligatoires et pas de blocage prévu

-Les RRR (rabais, remise, ristourne) sont

souvent comptabilisés en écart de prix par

souci de simplification

-Suivi des factures avec litige (risque de

payer l’intégralité du montant alors qu’il y

a eu un refus de livraison)

2.3.4.8) La ge

stion de

s règlem

ents fo

urnisseu

rsfait l’ob

jet d

e contrôles pa

r une

personn

e indé

-pe

ndan

te et a

utorisée.

-Profil utilisateur dans le progiciel différent

selon les tâches

-Il existe une transaction / test permettant

d’identifier tous les cas de non respect de

la séparation des tâches

-Existence d’un rapport d’exception

(«exception repo

rt »)qui retrace tous les

changem

ents (création, suppression,

changem

ent) apportés au fichier Fournis-

seurs (ex : modification des coordonnées

bancaires, création d’un fournisseur fictif,

changem

ent des conditions de paiem

ent

…)

-Vérifier qu’il n’y a pas de modification

possible du fichier paiem

ent fournisseurs

(par le trésorier)

5) Réception

et pilotage

du fournis-

seur

Direction

métiers,

logistique

1. Contrôle de la qualité et quantité : pour les

matériaux et biens physiques, une personne diffé-

rente de l’acheteur, vérifie que les biens reçus

correspondent bien à la commande, en termes de

type de produit et de quantités. Quand cela

s’avère nécessaire, le réceptionnaire peut

dem

ander à l’utilisateur final de vérifier la qualité

du bien si une expertise technique est requise.

Pour les services, l’acheteur vérifie que les services

reçus correspondent bien à la commande, en

termes de livrables, délais et indicateurs de

qualité. La réception est matérialisée par formu-

laire de livraison signé remis au fournisseur, inscrit

dans un progiciel (ERP) et comparé avec le bon de

commande initial.

2. Gestion des réclam

ations et pilotage du fournis-

seur : tous les départements impliqués dans la

réception des biens et services informent le

service des achats du moindre problème. Tous les

retours et les réclam

ations sont enregistrés et

suivis par le service des achats. Les résultats sont

utilisés pour « challenger » les fournisseurs ou

renégocier les conditions d’achats.

Manque de contrôle qualitatif et

quantitatif à la réception des biens

Fraude / Enregistrem

ent incorrect

Cut-off

Non séparation des tâches (ou non

respect)

29


© CIGREF - IFACI

Etape

Acteurs

Description

Risques





6) Compte

fournisseur

et gestion

fichier four-

nisseur

Direction

juridique,

direction

comptabilité,

direction

administra-

tive

1. Contrôle des factures : les factures sont compa-

rées avec les bons de livraison des produits /

services, soit physiquem

ent (papier) soit électroni-

quem

ent (via une application) par le département

en charge des comptes fournisseurs (comptabilité

fournisseur). Si les documents correspondent

(montant total, quantité, prix) la facture est

approuvée pour paiem

ent en fonction des prin-

cipes de délégation de pouvoirs et de séparations

de tâches. S’il y a des erreurs ou écarts, le départe-

ment contacte le fournisseur pour qu’il corrige la

facture, ou le réceptionnaire pour qu’il vérifie ce

qu’il a vraiment reçu, ou l’acheteur pour qu’il

vérifie les termes et prix négociés. Veiller au

respect des délais et aux processus de contesta-

tion qui doivent être formalisés dans le contrat.

2. Pilotage de la comptabilité fournisseur : des

procédures de clôture sont menées régulièrement

pour s’assurer de l’exactitude des positions de la

comptabilité fournisseurs. Par exemple les

comptes sont nettoyés régulièrement et réconci-

liés avec des parties tierces.

Cut-off


ent incorrect

La productivité du service comp-

table du fournisseur n’est pas opti-

misée

Mauvais contrôle de la chaine

globale : commande, réception,

facturation

Délais

2.3.4.9) Les com

ptes fo

urnisseu

rs fo

nt l’ob

jet

d’un

exa

men

et d

’une

justification

périodiqu

es(exh

austivité, exa

ctitud

e).

-Rapprochem

ent automatique Balance

Globale / Balance auxiliaire

-Lettrage automatique des comptes four-

nisseurs lors de paiem

ent automatique

(lettrage manuel à faire pour les paie-

ments manuels : - de 1%

des paiem

ents)

-Tous les comptes Fournisseurs ouverts

correspondent à des fournisseurs réels ;

oExem

ples : il n’y a pas de fournisseurs

génériques. Il existe des états qui

permettent d’obtenir les historiques des

changem

ents, modifications …

oSurveillance de la part de chaque Four-

nisseur dans le total des Achats, pour

identifier/lim

iter les risques de dépen-

dance

oBonne pratique – contrôle une fois par

mois (ou trimestre selon le type d’acti-

vité, les gam

mes de produits, les clients)

2.3.4.10

) Il existe un

e procéd

ure pe

rmettant de

s’assurer q

ue les prod

uits et cha

rges ont été

enregistrés sur la bo

nne pé

riod

e.-Il existe un état des engagem

ents qui

permet de vérifier m

anuellement

l’exhaustivité des provisions pour FNP à la

clôture

-Etat informatique permettant de justifier

le compte 408 factures non parvenues

avec l’état des commandes non livrées/

non réceptionnées

7) Processus

de paiem

ent

Direction

juridique,

trésorerie,

métiers

Une fois la facture approuvée, le fournisseur est

payé selon les termes négociés dans le contrat. Le

paiem

ent est lancé par la Trésorerie et autorisé par

la Comptabilité en conformité avec le principe de



ent incorrect

Erreurs de paiem

ent : fournisseur

ou paiem

ent incorrect ou double

etc.

Pratiques non professionnelles des

transactions

Charge de travail, délai de traite-

ment entre le département achats

et le service comptabilité

30

© CIGREF - IFACI

Etape

Acteurs

Description

Risques





2.3.4.11

) Il existe un

dispo

sitif p

ermettant d’en-

registrer les provision

s po

ur fa

ctures non

parven

ues ou

les ch

arge

s pa

yées d’ava

nce de

man

ière exh

austive et exa

cte.

-Idem

au point de contrôle précédent

(2.3.4.10)

Autres points de contrôle (pas nécessaire-

ment applicatifs)

-Signature d’une charte entre l’entreprise

et le fournisseur

-Formation en interne / tutoriel de sensibi-

lisation au risque de fraude et de corrup-

tion

31


© CIGREF - IFACI

4.5. Description du processus ventes

4.5.1. Processus

Le processus de vente se découpe en sept étapes, résumées dans le graphique ci-dessous.

4.5.2. Acteurs

Les acteurs impliqués par étape sont décrits dans le schéma ci-dessous.

Figure 17 : Description du processus ventesSource : CIGREF - IFACI

Figure 18 : Acteurs impliqués par étape du processus ventesSource : CIGREF - IFACI

1. Processus de

cotation

2. Processusde

commande

3. Processusde

livraison

4. Processusémission

defactures

5. Gestiondu

fichierclients

6. Gestiondes

réclamationsclients

7. Gestiondu

pricing &tarification

Logistique

Directionscommerciale,juridique,financière

Directionscommerciale,financière

Comptabilitéclients

Directionscommerciale

etcomptabilité

Directionscommerciale,juridiqueet SAV

Directions marketing,commercialeet contrôlede gestion

1. Processus de

cotation

2. Processusde

commande

3. Processusde

livraison

4. Processusémission

defactures

5. Gestiondu

fichierclients

6. Gestiondes

réclamationsclients

7. Gestiondu

pricing &tarification

32

© CIGREF - IFACI

Figure 19 : Risques par étape du processus ventes


4.5.3. Risques

Les principaux risques sont des risques liés à la fraude, des risques de non conformité aux lois etréglementations commerciales, des risques liés à la fiabilité du reporting financier et des risquesliés à la performance et à l’efficacité des opérations.

1. P

roce

ssu

s d

e co

tati

on

2. P

roce

ssu

sd

eco

mm

and

e

3. P

roce

ssu

sd

eliv

rais

on

4. P

roce

ssu

sém

issi

on

de

fact

ure

s

5. G

esti

on

du

fich

ier

clie

nts

6. G

esti

on

des

récl

amat

ion

scl

ien

ts

7. G

esti

on

du

pri

cin

g &

tari

ficat

ion

- Eng

agem

ents

non

auto

risés

pass

és a

vec

le c

lient

- Non

con

form

itéau

x lo

is e

tré

glem

enta

tions

- Ris

que

de c

hang

e- P

oliti

que

depr

ix in

cohé

rent

e- A

rriv

ée ta

rdiv

ede

s pr

opos

ition

sco

mm

erci

ales

- Ris

ques

clie

nt- R

isqu

e pa

ys

- Ris

que

prix

- Mau

vais

enga

gem

ent s

urde

s se

rvic

es e

nde

hors

du

prix

( liv

rais

on, e

tc.)

- Eng

agem

ents

non

auto

risés

pass

és a

vec

lecl

ient

- Ven

tes

à de

scl

ient

s no

nso

lvab

les,

etc.

- Rég

lem

enta

tions

clie

nt- M

auva

is s

ervi

ces

dus

à de

sin

form

atio

ns

inco

rrec

tes

sur

le c

lient

- Dél

ai o

u er

reur

da

ns la

com

man

de- D

éfau

t dan

s le

cons

eil a

u cl

ient

- Cla

use

d'ex

onér

atio

n de

resp

onsa

bilit

é- C

hang

emen

t dan

sl'e

nviro

nnem

ent

léga

l- D

émar

rage

du

proj

et a

vant

lasi

gnat

ure

- Dup

licat

ion

des

com

ptes

clie

nts

- Err

eurs

dan

s le

Þchi

er c

lient

- Non

con

form

itéau

x lo

is- E

ngag

emen

ts n

onau

toris

és p

assé

sav

ec d

es c

lient

s- A

ccès

par

des

pers

onne

s no

nau

toris

ées

au

Þchi

er c

lient

- Clie

nts

avec

des

créd

its n

on

auto

risés

insc

rits

dans

le s

ystè

me

des

vent

es- D

uplic

atio

n de

l'ent

ité lé

gale

dans

les

carn

ets

d'ad

ress

e- M

auva

ise

qual

itéde

s do

nnée

s

- Avo

irs in

exac

ts,

mal

enr

egis

trés

ou e

ngag

és- I

mpa

ct Þ

nanc

ier

des

récl

amat

ions

mal

repo

rté

- Eng

agem

ents

/av

oirs

non

au

toris

és p

assé

sav

ec d

es c

lient

s- P

erte

de

clie

nts

due

à un

mau

vais

proc

essu

s de

gest

ion

des

récl

amat

ions

- Pas

de

proc

essu

scl

air e

t par

tagé

de ré

solu

tion

des

inci

dent

s- M

auva

ise

déÞn

ition

/ ap

plic

atio

n du

proc

essu

s de

récl

amat

ion

- Ris

que

de

répu

tatio

n- R

isqu

e de

co

nten

cieu

x

- Eng

agem

ents

liés

aux

disc

ount

s et

raba

is p

as

corr

ecte

men

tca

lcul

és- E

ngag

emen

ts n

onau

toris

és p

assé

sav

ec le

s cl

ient

s- E

rreu

r dan

s le

ca

lcul

des

dis

coun

tset

raba

is- N

on c

onfo

rmité

aux

lois

et

régl

emen

tatio

ns- E

rreu

rs d

ans

les

prix

com

mun

iqué

sau

x cl

ient

s- P

erte

de

clie

nts

liée

à un

e m

auva

ise

réac

tion

clie

nts

- Mau

vais

e an

ticip

atio

n de

s pr

ix d

u m

arch

é(m

atiè

res

prem

ière

set

c.)

- Non

alig

nem

ent

entr

e éc

héan

cier

de p

aiem

ent /

fact

urat

ion

- Fac

ture

s en

dev

ises

pa

s co

rrec

tem

ent

enre

gist

rées

- Rab

ais

et d

isco

unts

pas

corr

ecte

men

ten

regi

stré

s- P

as d

e co

rres

pon-

danc

e en

tre

fact

ures

/ ve

ntes

/ liv

rais

ons

- Fac

ture

s m

anue

lles

frau

dule

uses

ou

mal

sai

sies

- Non

con

form

itéau

x lo

is e

t rég

lem

en-

tatio

ns- A

pplic

atio

n du

mau

vais

taux

de

TVA

- Fac

ture

dup

liqué

e- F

actu

re n

on

envo

yée

au c

lient

- Fac

ture

tard

ive

- Doc

umen

tatio

nan

nexe

non

join

teà

la fa

ctur

e

- Liv

rais

ons

non

auto

risée

s- N

on c

orre

spon

-da

nce

entr

e qu

anti-

tés

livré

es e

t qua

nti-

tés

enre

gist

rées

- Liv

rais

ons

non

corr

ecte

men

t enr

e-gi

stré

es- F

raud

e- V

ol o

u fr

aude

par

un tr

ansp

orte

ur o

uun

clie

nt n

on a

uto-

risé

- Non

co

rres

pond

ance

entr

e fa

ctur

es /

vent

es e

t liv

rais

ons

- Dél

ai d

e liv

rais

onno

n re

spec

té- C

ondi

tions

de

livra

ison

non

re

spec

tées

- Qua

lité

depr

odui

t ou

pack

agin

g no

nsa

tisfa

isan

te- T

emps

d'a

tten

teno

n op

timis

é

33


© CIGREF - IFACI

Figure 20 : Rapprochement entre risques et points de contrôles AMF


4.5.4. Rapprochement entre risques et points de contrôles AMF

Le schéma ci-dessous relie les risques aux points de contrôle décrits dans le cadre de référenceAMF. Chaque entreprise peut avoir une démarche spécifique et relier ses propres risques auxpoints de contrôles.

Ven

tes

à d

escl

ien

ts n

on

solv

able

s, à

des

clie

nts

aya

nt

dép

assé

leu

r p

lafo

nd

au

tori

sé,

ou

ne

resp

ecta

nt

pas

les

dél

ais

de

pai

emen

t(P

C 6

.10)

Les

en

gag

emen

tslié

s au

xd

isco

un

ts e

tra

bai

s n

e so

nt

pas

corr

ecte

men

tca

lcu

lés

(PC

6.5

)

Du

plic

atio

n d

esco

mp

tes

clie

nts

entr

aîn

ant

un

dép

asse

men

t d

eslim

ites

de

créd

it, d

es

stat

isti

qu

es

fau

sses

et

des

com

pte

s cl

ien

tsfa

ux

(PC

6.9)

Des

lim

ites

de

créd

its

inap

pro

pri

ées

son

t fix

ées

po

ur

cert

ain

s cl

ien

ts(P

C6.

10)

Les

avo

irs

ne

son

t p

asco

rrec

tem

ent

enre

gis

trés

(mau

vais

ecl

assi

ficat

ion

)(P

C6.

10)

No

n a

lign

emen

ten

tre

l'éch

éan

cier

de

pai

emen

tet

l'éc

héa

nci

erd

e fa

ctu

rati

on

(PC

6.12

)

Ris

qu

es c

lien

t(P

C6.

10)

L'im

pac

t fin

anci

erd

es ré

clam

atio

ns

n'e

st p

as re

po

rté

dan

s le

s te

mp

s à

la d

irec

tio

n

finan

cièr

e(P

C 6

.5/6

.9/6

.12/

6.14

)

Des

en

gag

emen

tsn

on

au

tori

sés

son

t fa

its

avec

des

clie

nts

(P

C6.

9)

Les

rab

ais

etd

isco

un

ts n

eso

nt

pas

corr

ecte

men

ten

reg

istr

és(P

C6.

5)

Des

fau

sses

fa

ctu

res

son

tém

ises

ou

des

fact

ure

s m

anu

elle

sn

e so

nt

pas

com

pta

bili

sées

dan

s le

sys

tèm

ein

form

atiq

ue

(PC

6.4)

No

n re

spec

t d

u

pri

nci

pe

de

sép

arat

ion

des

exer

cice

s (P

C 6

.1/6

.2/6

.3)

1. P

roce

ssu

s d

e co

tati

on

2. P

roce

ssu

sd

eco

mm

and

e

3. P

roce

ssu

sd

eliv

rais

on

4. P

roce

ssu

sém

issi

on

de

fact

ure

s

5. G

esti

on

du

fich

ier

clie

nts

6. G

esti

on

des

récl

amat

ion

scl

ien

ts

7. G

esti

on

du

pri

cin

g &

tari

ficat

ion

Les

avo

irs

ne

son

tp

as e

xact

s (m

auva

is

mo

nta

nt,

clie

nts

, etc

.).

Les

avo

irs

ne

son

t p

as

corr

ecte

men

t en

reg

is-

trés

(mau

vais

e cl

assi

fi-ca

tio

n).

Les

avo

irs

ne

son

t p

as c

orr

ecte

men

t en

gag

és (m

auva

ise

pér

iod

e, m

auva

is

mo

nta

nt,

etc.

).D

es e

ng

agem

ents

n

on

au

tori

sés

son

tp

assé

s av

es le

sclie

nts

. D

es a

voir

sn

on

au

tori

sés

/ill

égau

x so

nt

émis

env

ers

des

clie

nts

. Pas

de

po

litiq

ue

clai

re d

es

récl

amat

ion

s (P

C6.

5)

34

Figure 21 : Rappel des principaux points de contrôle liés au processus ventesSource : Cadre de référence AMF (chap 2 - p43-44)


2.3.6 Produits des activités ordinaires / Clients et Assimilés

2.3.6.1Les règles comptables adoptées par la société établissent clairement la distinction entreventes et prestations de service et indiquent si nécessaire les modalités de séparationadoptées pour les contrats à composantes multiples

2.3.6.2

Les produits des activités ordinaires provenant de la vente de biens ont été comptabiliséslorsque l’ensemble des conditions suivantes ont été satisfaites :- la société a transféré à l’acheteur les risques et avantages importants inhérents à lapropriété des biens ;

- la société a cessé d’être impliquée dans la gestion, telle qu’elle incombe normalement aupropriétaire, et dans le contrôle effectif des biens cédés ;

- le montant des produits des activités ordinaires peut être évalué de façon fiable ;- il est probable que des avantages économiques associés à la transaction iront à lasociété,

- les coûts encourus ou à encourir concernant la transaction peuvent être évalués de façonfiable.

2.3.6.3L'ensemble des livraisons effectuées (ou services rendus) donne lieu à facturation au coursde la période appropriée.

2.3.6.4Toutes les factures (séquentiellement numérotées) sont enregistrées dans les comptesclients ou directement en chiffre d’affaires.

2.3.6.5L'émission des avoirs est justifiée et contrôlée. Seuls les avoirs contrôlés sont enregistrésdans les comptes.

2.3.6.6 Les fonctions de facturation et de recouvrement sont effectivement séparées.

2.3.6.7Les fonctions de recouvrement et de gestion des comptes clients sont effectivement sépa-rées.

2.3.6.8 Tous les comptes clients ouverts correspondent à des clients réels.

2.3.6.9 Les soldes de comptes sont périodiquement et correctement justifiés.

2.3.6.10Les clients douteux sont correctement identifiés et les risques d’insolvabilité comptabilisésen conformité avec les règles applicables.

2.3.6.11Il existe un dispositif visant à exclure des produits des activités ordinaires, les produitsfacturés ou à facturer pour compte d’autrui.

2.3.6.12Il existe une procédure permettant de s’assurer que les produits et charges ont été enregis-trés sur la bonne période.

2.3.6.13Il existe un dispositif permettant d’enregistrer les factures à émettre ou les produitsconstatés d’avance de manière exhaustive et exacte.

2.3.6.14Les provisions pour dépréciation sont revues en vue de leur ré-estimation, le cas échéant(par exemple sur la base d'une balance âgée, ou des informations les plus récentes sur leslitiges avec les clients).


Le tableau ci-dessous reprend les principaux points de contrôle tels que listés dans le guided'appli cation du cadre de référence AMF.

35


© CIGREF - IFACI


Le schéma ci-dessous propose un rapprochement entre points de contrôle AMF et exemples decontrôles, à titre d’illustration. La liste n’est pas exhaustive.

Figure 22 : Rapprochement entre points de contrôle AMF et exemples de contrôle


Proc

essu

s Ven

tes

2.3.

6 13

) Il e

xist

e u

n d

isp

osi

tif

per

met

tan

t d

'en

reg

istr

er le

sfa

ctu

res

à ém

ettr

e o

u le

s p

rod

uit

s co

nst

atés

d'a

van

ce

de

man

ière

exh

aust

ive

et

exa

cte

- À p

arti

r de

la b

ilin

g d

ue

list,

il es

t p

oss

ible

de

fair

e u

ne

valo

risa

tio

n p

ar c

entr

es d

ep

rofit

s et

de

coû

ts, d

e fa

ire

lesu

ivi e

t le

s en

reg

istr

emen

ts- B

on

ne

pra

tiq

ue

- un

e fo

is

par

mo

is

2.3.

6 10

) Les

clie

nts

do

ute

ux

son

t co

rrec

tem

ent

iden

tifié

set

les

risq

ues

d'in

solv

abili

téco

mp

tab

ilisé

s en

co

nfo

rmit

éav

ec le

s rè

gle

s ap

plic

able

s- I

l exi

ste

des

co

mp

tes

gén

érau

x cl

ien

ts d

ou

teu

xIl

est

po

ssib

le d

e fa

ire

des

pro

visi

on

s et

de

les

ratt

ach

erp

ar e

xem

ple

à c

es c

om

pte

s d

e cl

ien

ts s

péc

ifiq

ues

- Bo

nn

e p

rati

qu

e - U

ne

fois

par

mo

is (o

u t

rim

estr

e se

lon

le

typ

e d

'act

ivit

é) p

ou

r fai

re

évo

luer

les

pro

visi

on

s

2.3.

6 1)

Exi

sten

ce d

e rè

gle

sco

mp

tab

les

étab

lissa

nt

clai

rem

ent

la d

isti

nct

ion

entr

e ve

nte

s et

pre

stat

ion

sd

e se

rvic

e (e

n a

mo

nt,

enp

aram

étra

ge)

- To

ut

ce q

ui e

st re

lati

f au

chiff

re d

'aff

aire

s p

asse

ob

ligat

oir

emen

t p

ar le

mo

du

le M

arke

tin

g e

tVe

nte

s d

u p

rog

icie

l- U

ne

fact

ure

fait

réfé

ren

ceà

un

art

icle

- Les

ser

vice

s n

e so

nt

pas

con

sid

érés

co

mm

e liv

rab

les

et n

e so

nt

pas

co

mp

tab

ilisé

sd

ans

les

mêm

es c

om

pte

s

2.3.

6 2)

Les

pro

du

its

des

ac

tivi

tés

ord

inai

res

pro

ve-

nan

t d

e la

ven

te d

e b

ien

s o

nt

été

com

pta

bili

sés

lors

qu

e le

s co

nd

itio

ns

suiv

ante

s so

nt

sati

sfai

tes

:- T

ran

sfer

t à

l'ach

eteu

r des

Ris

qu

es e

t av

anta

ges

- Fin

de

l'im

plic

atio

n d

u

ven

deu

r dan

s la

ges

tio

n d

es

bie

ns

céd

és ;

- Éva

luat

ion

fiab

le d

u

mo

nta

nt

des

pro

du

its

des

ac

tivi

tés

ord

inai

res

- Éva

luat

ion

fiab

le d

esav

anta

ges

éco

no

miq

ues

asso

ciés

à la

tra

nsa

ctio

n e

t d

es c

oû

ts e

nco

uru

s

2.3.

6 3)

L'e

nse

mb

le d

esliv

rais

on

s ef

fect

uée

s d

on

ne

lieu

à fa

ctu

rati

on

au

co

urs

de

la p

ério

de

app

rop

riée

- La

fact

ura

tio

n p

eut

être

fa

ite

la li

vrai

son

Idéa

lem

ent

fair

e le

co

ntr

ôle

un

e fo

is p

ar s

emai

ne

po

ur

évit

er d

'êtr

e d

ébo

rdé

lors

de

la c

lôtu

re- L

a b

ilin

g d

ue

list

gén

érée

en fi

n d

e m

ois

per

met

de

rece

nse

r ces

éca

rts

( co

ntr

ôle

man

uel

)- U

ne

fact

ure

(ou

no

te d

e cr

édit

) à é

met

tre

est

pas

sée

en p

rovi

sio

n

2.3.

6 4)

To

ute

s le

s fa

ctu

res

son

t en

reg

istr

ées

dan

s le

s co

mp

tes

clie

nts

ou

d

irec

tem

ent

en c

hiff

re

d'a

ffai

res

- To

ute

s le

s fa

ctu

res

son

ttr

aité

es p

ar le

log

icie

l et

pas

sen

t p

ar u

n c

om

pte

cl

ien

t- T

ran

ches

de

nu

mér

os

com

mu

nes

à to

ute

s le

s so

ciét

és p

ou

r les

do

cu-

men

ts d

e ve

nte

s- O

rdre

ch

ron

olo

giq

ue

etp

rop

re à

ch

aqu

e so

ciét

é p

ou

r les

piè

ces

com

pta

ble

s- B

on

ne

pra

tiq

ue

- tra

nsa

c-ti

on

dan

s le

mo

du

le v

ente

s p

erm

et d

'ass

ure

r le

con

trô

le (m

inim

um

un

e fo

is p

ar s

emai

ne)

2.3.

6 5)

L'é

mis

sio

n d

es

avo

irs

just

ifiée

et

con

trô

-lé

e. S

euls

les

avo

irs

con

trô

lés,

son

t en

reg

istr

és

dan

s le

s co

mp

tes

- Les

avo

irs

pas

sen

to

blig

ato

irem

ent

par

le

pro

gic

iel e

t co

rres

po

nd

ent

do

nc

à u

ne

com

man

de.

Ils

fon

t l'o

bje

t d

'un

typ

e d

e d

ocu

men

t p

arti

culie

r- U

ne

ann

ula

tio

n d

e fa

ctu

re n

e p

eut

être

cré

ée

qu

'en

réfé

ren

ce à

un

e fa

ctu

re- B

on

ne

pra

tiq

ue

- Co

ntr

ô-

les

dan

s le

s m

aste

rs d

ata

et ra

pp

roch

emen

ts v

ues

so

ciét

é d

ans

les

mo

du

les

ven

tes

& fi

nan

ce d

u

pro

gic

iel /

log

icie

l(v

érifi

er q

ue

les

dév

erse

-m

ents

se

son

t b

ien

fait

s)

2.3.

6 6)

Les

fon

ctio

ns

de

fact

ura

tio

n e

t d

e re

cou

vrem

ent

son

t ef

fect

ivem

ent

sép

arée

s ;

2.3.

6 7)

Les

fon

ctio

ns

de

reco

uvr

emen

t et

de

ges

tio

n d

es c

om

pte

s cl

ien

ts s

on

t ef

fect

ivem

ent

sép

arée

s- C

eci s

e fa

it a

u n

ivea

u d

es

rôle

s et

au

tori

sati

on

s. C

e n

e d

oit

pas

êtr

e la

mêm

ep

erso

nn

e. Il

fau

t p

rocé

der

à

un

co

ntr

ôle

de

la

dis

trib

uti

on

des

rôle

s. D

ans

cert

ain

esso

ciét

és (p

etit

es),

cett

esé

par

atio

n n

'est

pas

ef

fect

ive

2.3.

6 8)

To

us

les

com

pte

s cl

ien

ts o

uve

rts

corr

esp

on

-d

ent

à d

es c

lien

ts ré

els

- Il n

'y a

pas

de

clie

nts

gén

ériq

ues

il e

xist

e d

es

état

s q

ui p

erm

ette

nt

d'o

bte

nir

les

his

tori

qu

es d

es

chan

gem

ents

, mo

difi

ca-

tio

ns.

..- S

urv

eilla

nce

de

la p

art

de

chaq

ue

clie

nt

dan

s le

tota

l d

es v

ente

s, p

ou

r lim

iter

les

risq

ues

de

dép

end

ance

- Bo

nn

e p

rati

qu

e - c

on

trô

le

un

e fo

is p

ar m

ois

(ou

tr

imes

tre

selo

n le

typ

e d

'act

ivit

é), d

es g

amm

es d

e p

rod

uit

s, d

es c

lien

ts

2.3.

6 9)

Les

so

ldes

de

com

pte

s so

nt

pér

iod

i-q

uem

ent

et c

orr

ecte

-m

ent

just

ifiés

;- L

es b

alan

ces

clie

nts

(a

uxi

liair

es e

t g

énér

ales

) so

nt

rég

uliè

rem

ent

suiv

ies

Les

bal

ance

s âg

ées

per

met

ten

td

e su

ivre

l'év

olu

tio

n d

es

créa

nce

s cl

ien

ts- B

on

ne

pra

tiq

ue

- Un

e fo

is p

ar m

ois

2.3.

6 11

) En

fin, i

l exi

ste

un

d

isp

osi

tif v

isan

t à

excl

ure

d

esp

rod

uit

s d

es a

ctiv

ités

o

rdin

aire

s, le

s p

rod

uit

s fa

ctu

rés

ou

à fa

ctu

rer p

ou

r co

mp

te d

'au

tru

i- I

l n'y

a r

ien

dan

s le

pla

nco

mp

tab

le, n

i dan

s le

s sy

stèm

es

2.3.

6 12

) Il e

xist

e u

ne

pro

céd

ure

per

met

tan

t d

e s'

assu

rer q

ue

les

pro

du

its

et

char

ges

on

t ét

é en

reg

istr

és

sur l

a b

on

ne

pér

iod

e- V

oir

po

int

2 p

ou

r la

bili

ng

d

ue

list.

Dan

s le

s d

ocu

men

tsM

arke

tin

g e

t Ven

tes

figu

ren

tle

s d

iffér

ente

s d

ates

(f

actu

rati

on

, liv

rais

on

...)

- Bo

nn

e p

rati

qu

e - u

ne

fois

p

ar m

ois

2.3.

6 14

) Les

pro

visi

on

s p

ou

r d

épré

ciat

ion

so

nt

revu

es e

n

vue

de

leu

r ré-

esti

mat

ion

, le

cas

éch

éan

t (p

ar e

xem

ple

su

rla

bas

e d

'un

e b

alan

ce â

gée

o

u d

es in

form

atio

ns

les

plu

sré

cen

tes

sur l

es li

gn

es a

vec

les

clie

nts

)- L

a b

alan

ce â

gée

per

met

d'o

bte

nir

le m

on

tan

t d

es

créa

nce

s en

reta

rd. P

lusi

eurs

autr

es b

alan

ces

exis

ten

t d

on

t ce

lle d

es p

ost

es c

lien

ts

qu

i p

erm

ette

nt

de

con

naî

-tr

e l'o

rig

ine

des

liti

ges

et

les

rais

on

s d

es p

rovi

sio

ns

- Bo

nn

e p

rati

qu

e - c

f. p

oin

t 8

- Bo

nn

e p

rati

qu

e - b

ilin

g d

ue

list

pas

sée

en m

od

ule

fin

anci

er

36

© CIGREF - IFACI

Figure 23 : Vue détaillée du processus ventes

Etape

Acteurs

Description

Risques



Cadre de référence AMF : Produits des

activités ordinaires / Clients et assimilés

1) Processus

de cotation

Direction

commerciale

Direction

financière

Direction

juridique

Ce processus consiste à répondre aux

dem

andes des clients ou des pros-

pects, en rassem

blant l’information

nécessaire pour établir le compte,

négocier et contractualiser si possible.

Point de départ / Point de clôture

Dem

ande de cotation de la part du

prospect / client

Réponse au prospect / client et signa-

ture du contrat si possible

Des engagem

ents non autorisés sont passés

avec le client

Non conformité aux lois et réglementations

commerciales

Exposition à des risques de change non identi-

fiés

Rupture de la cohérence de la politique de prix

par région, par segment, par produit, par moyen

de transport

Perte d’opportunités de vente liée à l’arrivée

tardive des propositions commerciales

Risque client (Risque Financier & Marché)

(scoring)

Client refusant de payer (m

auvais contrôle de la

dette)

Risque pays ou de contrepartie

Risque prix (profitabilité, compétiteurs)

Mauvais engagem

ent sur des services en

dehors du prix (délai de livraison, etc.)

Pas de prise en compte du risque de change

2.3.6.1) Les rè

gles com

ptab

les ad

optées par

la société établissent clairem

ent la distinc-

tion

entre ven

tes et prestations de service (en

amon

t, en

param

étrage

).Exem

ples

-Tout ce qui est relatif au chiffre d’affaires

passe obligatoirem

ent par le module

Marketing et Ventes du progiciel (ERP)

ou d’un autre logiciel..

-Une facture fait référence à un article et

il existe un type d’articles spécifiques

pour les prestations de services. Au

niveau du groupe d’imputation articles,

une distinction est faite sur ce qui est

facturé (param

étrage).

-Les services ne sont pas considérés

comme livrables et ne sont pas compta-

bilisés dans les mêm

es comptes.

4.5.7.

Vue détaillée du processus vente

37


© CIGREF - IFACI

Etape

Acteurs

Description

Risques





2) Processus

decommande

Direction

commerciale

Direction

juridique

Direction

financière

Ce processus comprend :

-La réception du bon de commande

du client

-La génération du bon de commande

(incluant le prix, le type de produit,

les coûts de transport si nécessaire et

le code produit)

-La confirmation de la commande

(engagem

ent sur la quantité)


Bon de commande du client (oral,

papier ou en EDI)

Commande ouverte basée sur un

contrat cadre (oral, papier ou EDI)

Cotation

Commande confirmée pour la livraison

Commande annulée due à des

requêtes non résolues

Des engagem


avec le client

Ventes à des clients non solvables, à des clients

ayant dépassé leur plafond autorisé, ou ne

respectant pas les délais de paiem

ent.

Réclam

ations faites par le client (non respect

des termes de vente)

Mauvaise qualité de services due à des informa-

tions incorrectes ou insuffisantes sur le client

Délai ou erreur faite dans le processus de

commande

Défaut dans le conseil au client

Clause d’exonération de responsabilité dans le

contrat

Changem

ent dans l’environnem

ent légal

Dém

arrage du projet avant la signature du

contrat

2.3.6.2) Les produ

its de

s ac

tivités ordina

ires

prov

enan

t de la ven

te de bien

s on

t été com

p-tabilisés lorsqu

e l’ensem

ble de

s cond

itions

suivan

tes on

t été satisfaite

s :

-la société a tran

sféré à l’ach

eteu

r les

risque

s et ava

ntag

es im

portan

ts inhé

rents

à la propriété des biens ;

-la société a cessé d’être im

pliqué

e da

ns la

gestion, telle qu’elle incombe

normale-

men

t au prop

riétaire, et d

ans le con

trôle

effectif de

s bien

s cédé

s ;

-le m

ontant des produ

its de

s ac

tivités ordi-

naires peu

t être évalué

de façon fia

ble ;

-il est p

roba

ble qu

e de

s av

antage

s écon

o-mique

s associés à la tran

saction iron

t à la

société, et

-les coûts en

courus ou à en

courir con

cer-

nant la tran

saction pe

uven

t être évalué

sde

façon fia

ble.

2.3.6.3) L'ensem

ble de

s livraison

s effectué

es(ou services rend

us) d

onne

lieu

à fa

cturation

au cou

rs de la période

app

ropriée ;

Exem

ples :

-Pour 99%

des cas la facturation est faite à

la livraison. En fin de mois, il est possible

de décaler. Idéalement faire le contrôle

une fois par sem

aine pour éviter d’être

débordé lors de la clôture

-La billing du

e list(écart entre livraison et

facturation) générée en fin de mois

permet de recenser ces écarts par centre

de profits, articles, clients. (peut se

traduire par une ém

ission de provision)

(contrôle manuel)

-Une facture (ou note de crédit) à émettre

est passée en provision.

Confirmation de la picking

listbasée sur le

prélèvement des quantités. Seules les

picking listsconfirmées peuvent être factu-

rées.

3) Processus

de livraison

Logistique

Ce processus comprend l’arrivée des

véhicules de transport, leur pesée, leur

chargem

ent, l’impression des docu-

ments de livraison


Confirmation du bon de commande ou

ordre de transfert

Le produit quitte le site

Des livraisons non autorisées sont faites

Les quantités livrées ne correspondent pas à

celles enregistrées dans le livre des ventes

Les quantités physiques ne sont pas bien

pesées

Les livraisons ne sont pas correctement enre-

gistrées (fraude, mauvaise facture)

Fraude

Vol ou fraude de marchandises par un transpor-

teur ou un client non autorisé

Les factures ne reflètent pas les ventes ou les

livraisons (mauvaise quantité, prix, discounts,

taxes, fraude…

)

Difficultés à tracer les informations, au regard

des plaintes, de la commande à la livraison et à

la facture

Délai de livraison non respecté

Conditions de livraison non respectées

Qualité de produit ou packaging non satisfai-

sant

Temps d’attente non optimisé

38

© CIGREF - IFACI

Etape

Acteurs

Description

Risques





4) Processus

d’émission

de facture

Comptabilité

clients

Ce processus concerne la facturation

des ventes nettes de produits


Confirmation de la livraison des

produits

Facture envoyée au client

Non alignem

ent entre l’échéancier de paie-

ment et l’échéancier de facturation

Les factures en devises ne sont pas correcte-

ment enregistrées

Les rabais et discounts ne sont pas correcte-

ment enregistrés

Les avoirs ne sont pas correctement enregistrés

(mauvaise classification)

Les factures ne reflètent pas les ventes ou les

livraisons (quantité, prix, discount, taux de fisca-

lité erroné, fraude…

)Des factures manuelles frauduleuses sont

préparées ou des factures manuelles sont mal

rentrées dans le système


Application du mauvais taux de TVA

Les relations avec les clients peuvent être

dégradées, du fait d’une des opérations

suivantes :

Facture dupliquée

Facture non envoyée au client

Facture tardive

Documentation annexe non jointe à la facture

2.3.6.4) Tou

tes les factures (séq

uentiellemen

tnu

mérotées) son

t enreg

istrées da

ns les

comptes clients ou

directemen

t en ch

iffre

d’affaires.

Exem

ples

-Toutes les factures sont traitées par le

progiciel (ERP) ou logiciel et passent par

un compte client au niveau du module

des ventes. Il n’y a pas d’enregistrem

ent

de factures au niveau du module

finances.

-Tranches de numéros :

oCommunes à toutes les sociétés pour

les documents de vente

oOrdre chronologique et propre à

chaque société pour les pièces comp-

tables

-Bonne pratique - Une transaction dans le

module ventes du progiciel / logiciel

permet de le vérifier (M

ini une fois par

semaine)

39


© CIGREF - IFACI

Etape

Acteurs

Description

Risques





5) Processus

de gestion

du fichier

clients

Direction

commerciale,

Direction

comptabilité

Ce processus concerne la création, la

maintenance et la désactivation, dans

le système, dans le temps, des informa-

tions concernant les prospects et les

clients (informations techniques,

marketing, financières, etc.)


Création du fichier client / prospect

Mise à jour du fichier client / prospect

Désactivitation du fichier client / pros-

pect

Mise à jour du fichier m

aitre permet-

tant l’enregistrem

ent des transactions

Plusieurs comptes dupliqués sont créés par

client, conduisant à une surestimation du crédit

autorisé, des statistiques erronées et des

«accrua

ls »

Les clients payant comptant à la livraison sont

mal classifiés

Le fichier clients ne contient pas les bonnes

informations ou les informations complètes

(exemple : hiérarchie client manquante,

drapeaux signalant les liens capitalistiques

inter-sociétés…)

Non conformité aux lois, réglementations et

pratiques locales

Des engagem


avec des clients

Des personnes non autorisées ont accès au

fichier clients ou peuvent faire des change-

ments dans le fichier clients

Des clients avec des crédits non autorisés sont

rentrés dans le système des ventes. Risque de

dépendance clients

Duplication de l’entité légale dans les carnets

d’adresse

Duplication de fichiers clients dans le fichier

maitre

Mauvaise qualité des données

2.3.6.5) L'émission

des avo

irs est justifié

e et

contrôlée. Seu

ls les av

oirs con

trôlés son

ten

registrés da

ns les comptes.

Exem

ples

-Les avoirs passent obligatoirem

ent par

un module du SI (progiciel ou autre) et

correspondent donc à une commande.

Ils font l’objet d’un type de document

particulier.

-Une annulation de facture ne peut être

créée qu’en référence à une facture.

D’autres éléments (comme les ristournes

de fin d’année) peuvent faire référence à

une commande mais pas à une facture.

-Bonne pratique - Contrôles aussi dans le

fichier clients et rapprochem

ent vues

sociétés dans les modules ventes et

finance du progiciel ou logiciel (vérifier

que les déversements se sont bien faits,

toutes les factures clients vers la compta-

bilité).

2.3.6.6) Les fo

nction

s de

facturation et de

recouv

remen

t son

t effectivemen

t sép

arées.

2.3.6.7) Les fo

nction

s de

recouv

remen

t et d

ege

stion de

s comptes clients sont effective-

men

t sép

arées.

Exem

ples

-Ceci se fait au niveau des rôles et autori-

sation. Ce ne doit pas être la mêm

epersonne. Il faut procéder à un contrôle

de la distribution des rôles. Dans

certaines sociétés (petites), cette sépara-

tion n’est pas effective.

40

© CIGREF - IFACI

Etape

Acteurs

Description

Risques





6) Processus

de traite-

ment des

réclam

ations

clients

Direction

commerciale

Direction

juridique

Service

Après-vente

Ce processus concerne la notification

et la résolution des problèmes en

interne ou avec le client :

Quantité / Produit / Qualité / Prix /

problèmes de facturation / Erreurs de

livraisons / Conditions de paiem

ent

Le système doit être configuré pour

permettre de classifier les factures

d'avoir et d’analyser les points suivants

: erreurs de prix, erreurs de quantité,

problèmes de qualité, livraisons

tardives ou incomplètes, etc.


Plainte du client

Résolution du problème

Les avoirs ne sont pas exacts (mauvais montant,

client, etc)

Les avoirs ne sont pas correctement enregistrés

(mauvaise classification)

Les avoirs ne sont pas correctement engagés

(mauvaise période, mauvais montant, etc)

L’impact financier des réclam

ations n’est pas

reporté dans les temps à la direction financière

Des engagem


avec des clients

Des avoirs non autorisés / illégaux sont passés

avec des clients

Perte de clients due à un processus tardif ou

inefficace de gestion des réclam

ations

Pas de politique claire de réclam

ation

Entreprise mal organisée pour gérer de

manière appropriée les plaintes clients

(manque de ressources humaines et de bases

de données pour suivre les plaintes)

Pas de processus clair et partagé de résolution

des incidents

Gaspillage de temps et de ressources dans la

résolution du problème

Mauvaise définition du processus de réclam

a-tion / divergence ou mauvaise application du

processus

Risque de réputation

Risque contentieux

Gestion des retours

2.3.6.8) Tou

s les comptes clients ou

verts

correspo

nden

t à des clients réels.

Exem

ples

-Il n’y a pas de clients génériques. Comme

pour les achats, il existe des états qui

permettent d’obtenir les historiques des

changem

ents, modifications …

-Surveillance de la part de chaque client

dans le total des ventes, pour

identifier/lim

iter les risques de dépen-

dance

-Bonne pratique – contrôle une fois par

mois (ou trimestre selon le type d’acti-

vité, les gam

mes de produits, les clients)

2.3.6.9) Les solde

s de

com

ptes son

t périodi-

quem

ent e

t correctem

ent justifié

s.Exem

ples

-Les balances clients (auxiliaires et géné-

rales) sont régulièrement suivies. Les

balances âgées permettent de suivre

l’évolution des créances clients.

-Bonne pratique - Une fois par mois

2.3.6.10

) Les clients do

uteu

x sont correcte-

men

t ide

ntifiés et les risque

s d’insolvab

ilité

comptab

ilisés en

con

form

ité av

ec les règles

applicab

les.

Exem

ples

-Il existe des comptes généraux clients

douteux. Il est possible de faire des

provisions et de les rattacher à ces

comptes clients spécifiques. Les

pratiques diffèrent. Certaines entreprises

font des provisions au niveau d’un

compte général, d’autres au niveau des

comptes clients.

-Bonne pratique – une fois par mois (ou

trimestre selon le type d’activité) pour

faire évoluer les provisions

41


© CIGREF - IFACI

Etape

Acteurs

Description

Risques





7) Gestion du

pricing / tari-

fication

Direction

Marketing

Direction

Commerciale

Contrôle de

gestion

Ce processus comprend

1) Définition de la structure de prix et

les ajustem

ents

Les ajustem

ents peuvent avoir trait à :

-Différenciation produit

-Différenciation Service

-Segmentation marché

-Promotions (pour un nouveau

produit)

-Services logistique

-Changem

ent des prix (hausse ou

baisse)

NB: ces ajustem

ents peuvent résulter

de plusieurs types de transaction :

Rabais, Discounts, Produits gratuits,

Changem

ent de prix

2) Définition des étapes d’approbation

pour tout changem

ent de prix.

3) Entrée de la structure de prix et des

ajustem

ents dans le système, de façon

à ce que le prix soit automatiquem

ent

calculé quand les bons de commandes

et les factures sont générés.


Définition de la structure de la base de

prix et des ajustem

ents

-Feedback clients

-Market intelligence (segmentation)

-Stratégie Marketing (promotions,

nouveaux produits, logisitique,

import / export, etc.)

Le catalogue de prix est approuvé et

entré dans la table de prix

Notification au client

Les engagem

ents liés aux discounts et rabais

ne sont pas correctement calculés

Des engagem

ents non autorisés sont faits avec

des clients

Pas d’information correcte sur les prix pour

chaque client

Erreur dans le calcul des discounts et rabais


commerciales

Erreur dans les prix communiqués aux clients

Manque d’influence sur la place de marché –

manque de crédibilité

Perte de clients liée à une mauvaise relation

client / communication

Pas de prise en compte de l’évolution des prix

du marché (matières premières, etc.)

2.3.6.11

) Enfin, il existe un

dispo

sitif visan

t àexclure de

s prod

uits des activités ordinaires,

les prod

uits fa

cturés ou à facturer pou

rcompte d’au

trui.

Exem

ples

-Il n’y a rien dans le plan comptable, ni

dans les systèm

es.

2.3.6.12

) Il existe un

e procéd

ure pe

rmettant

de s’assurer que

les prod

uits et cha

rges ont

été en

registrés sur la bo

nne pé

riod

e.Exem

ples

-Voir point 2 pour la billing

due

list. Dans

les documents Marketing et Ventes figu-

rent les différentes dates (facturation,

livraison …)

-Bonne pratique – une fois par mois

2.3.6.13

) Il existe un

dispo

sitif p

ermettant

d’en

registrer les fa

ctures à émettre ou

les

prod

uits con

statés d’ava

nce de

man

ière

exha

ustive et exa

cte.

Exem

ples

-A partir de la billing du

e list, il est possible

de faire une valorisation par centres de

profits et de coûts, de faire le suivi et les

enregistrem

ents.

-Bonne pratique – une fois par mois

42

© CIGREF - IFACI

Etape

Acteurs

Description

Risques





2.3.6.14

) Les provision

s po

ur dép

réciation

sont re

vues en vu

e de

leur ré

-estim

ation, le

cas éché

ant (pa

r exemple sur la ba

se d'une

balance âg

ée, ou de

s inform

ations les plus

récentes sur les litiges avec les clients).

Exem

ples

-La balance âgée permet d’obtenir le

montant des créances en retard.

Plusieurs autres balances existent dont

celles des postes clients qui permettent

de connaître l’origine des litiges et les

raisons des provisions. Il y a des comptes

de provisions liés aux ventes.

-Bonne pratique – identique au point

2.3.6.8 (mois ou trimestre) la pratique

dépend aussi de la manière dont sont

traitées les provisions et s’il y a beaucoup

de mauvais payeurs

-Bonne pratique – billing

due

list– trans-

action pour factures passées dans le

systèm

e comptable (en module finance)

Autres contrôles (étape 7 du processus –

gestion du pricing et tarification)

-Produits financiers de couverture des

changes

-Approbation du catalogue des prix

-Validation et traçabilité des ajustem

ents

-Contrôles bloquants pour vérifier la

cohérence et l’exhaustivité des données

et des contrôles arithmétiques automa-

tiques.

43


© CIGREF - IFACI

4.6. Description du processus consolidation financière

4.6.1. Processus

Le processus de consolidation financière se découpe en cinq étapes, résumées dans le graphiqueci-dessous. Le processus de communication financière (étape 6) est un processus décrit séparé-ment dans le cadre de référence AMF. Nous le faisons figurer ici uniquement à titre indicatif. Iln’est pas détaillé par la suite en termes d’acteurs, de risques, de points de contrôle ni de contrôle.

4.6.2. Acteurs

Les acteurs impliqués par étapes sont décrits dans le schéma ci-dessous.

Figure 25 : Acteurs impliqués par étape du processus consolidation financièreSource : CIGREF - IFACI

1. Planificationde la

consolidation

2. Productiondes

comptessociaux

3. Rapproche-ment des

comptabilitésintersites

4. Établisse-ment desliasses de

consolidation

5. Productiondes

comptesconsolidés

Comptabilitéslocales


DAF,Comptabilités

locales


Serviceconsolidation

Figure 24 : Description du processus consolidation financièreSource : CIGREF - IFACI


consolidation

2. Productiondes

comptessociaux




consolidation

5. Productiondes

comptesconsolidés

6. Communi-cation

Financière

44

© CIGREF - IFACI

Figure 26 : Risques par étape du processus consolidation financièreSource : CIGREF - IFACI

4.6.3. Risques

Les risques portent principalement sur des non-connaissances de règles, le non-respect des calen-driers, des erreurs d’évaluation, des erreurs de paramétrage, des risques de fraude.


consolidation

2. Productiondes

comptessociaux




consolidation

5. Productiondes

comptesconsolidés

- Absence de calendrier / calen-drier incomplet- Calendrier de publication non respecté- Mauvaise priseen compte desmodiÞcations depérimètre- Principes et règlescomptables nonformalisés / pasà jour- Outil inadapté oumauvais paramé-trage de l'outil- Mauvaise déÞni-tion de liasse deconsolidation- Instructions peu claires - Manque de formation desresponsables Þnanciers locaux

- Non respect duplanning- Non exhaustivitédes comptesrapprochés- Écart non résoluentre les Þliales

- Oubli de passer certaines écritures- Non respect duplanning- Montants non alloués, comptesintérimaires avecdes soldes ouverts- Di!érences decours pour lesdi!érentes monnaies- Mauvaise évaluation des actifs- Non prise encompte de toutes lescomptabilités auxi-liaires- Mauvaisparamétrage des tables de correspon-dance- ReclassiÞcation desdonnées incorrectes /non justiÞées- Mauvaise interprétation des règles de comptabi-lité- Fraude

- Non respect derègles communi-quées par le Groupe- Non respect du planning- Manque de cohérence dansl'alimentation desliasses de consolida-tion- Liasse incomplète- Liasse non équili-bréeou mal remplie- Incohérence entre les données trans-mises et lessystèmes sources- Indisponibilité dusystème de consoli-dation

- Non respect duplanning- Mauvaise application desrègles de consolida-tion- Non respect /mauvaise interpréta-tion des normes comptables en vigueur dans le Groupe- Mauvaise élimina-tion des montants inter-sociétés- Erreur de saisie /erreur d'imputation- ReclassiÞcation incorrecte ou inco-hérente des don-nées - Fraude comptable- Indisponibilité dusystème de consoli-dation- Mauvais paramé-trage du logiciel de consolidation- Mauvaise reprisedes historiques

45


© CIGREF - IFACI

Figure 27 : Rapprochement entre risques et points de contrôles AMFSource : CIGREF - IFACI

4.6.4. Rapprochement entre risques et points de contrôle AMF

Le schéma ci-dessous relie les risques aux points de contrôle décrits dans le cadre de référenceAMF. Chaque entreprise peut avoir une démarche spécifique et relier ses propres risques aux dif-férents points de contrôle.

Absence decalendrier de

consolidation oucalendrier

incomplet / inapproprié.

Calendrier depublication non

respecté.Principes et règles

comptables nonformalisés et/ou

pas à jour.Mauvaise définition

de liasse deconsolidation

(contenu) (PC12.2)

Mauvaise prise encompte des

modifications depérimètre

(PC12.1/12.9)

Incohérence entreles données

transmises et lessystèmes source

(PC12.5/12.6)

Non respect de règlescommuniquées parle Groupe (PC12.1/

12.3/12.8). Non respect du planning.

Manque de cohérencedans l'alimentation

des liasses deconsolidation. Liasse

incomplète. Liassenon équilibrée ou

mal remplie (écartsentre les comptesde synthèse et les

annexes détaillées)(PC12.2)

Non exhaustivitédes comptes

rapprochés. Écartnon résolu entre

les filiales (PC 12.5/

12.6/12.10)

Mauvaise prise encompte des

modifications depérimètre ; nonprise en compte

d'une filiale significative dans

le périmètre(PC 12.2)

Mauvaise applicationdes règles de

consolidation. Nonrespect / mauvaiseinterprétation des

normes comptables en vigueur dans

le Groupe.Fraude comptable(habillage de bilan.

Sous / surestimationdes actifs)

(PC12.7/12.8/12.10/12.11/12.12)

Mauvaise évaluation des

actifs (PC12.5/12.6)

Oubli de passercertaines

écritures / erreursPC12.4)

Mauvaise éliminationdes montants

intersociétés (PC12.3)

Non respect du planning (PC12.2)


Erreur de saisie /erreur d'imputation

(PC12.4)

Reclassification desdonnées incorrectes

ou non justifiées(PC12.3/12.5)



consolidation

2. Productiondes

comptessociaux




consolidation

5. Productiondes

comptesconsolidés

Montants non alloués.Reclassification desdonnées incorrectes

ou non justifiée(PC12.11/12.12)

Différences de courspour les différentesmonnaies. Non priseen compte de toutes

les comptabilitésauxiliaires.Mauvaise

interprétation desrègles de

comptabilité(PC12.7/12.8)

46

© CIGREF - IFACI

Figure 28 : Rappel des principaux points de contrôle liés au processus consolidation financière

Source : Cadre de référence AMF (chap 2 - p48)


Le tableau ci-dessous reprend les principaux points de contrôle tels que listés dans le guide d'ap-plication du cadre de référence AMF.


2.3.12 Consolidation

2.3.12.1 Le périmètre de consolidation est tenu à jour et documenté

2.3.12.2Les liasses de consolidation sont établies en application de principes et règles comptableshomogènes au sein des sociétés intégrées.

2.3.12.3Les opérations réciproques sont identifiées et éliminées, en particulier les opérations finan-cières et les résultats internes (marges sur stocks, dividendes, résultats sur cessions d’immo-bilisations…).

2.3.12.4 Les écritures de consolidation sont enregistrées et suivies dans un journal spécifique.

2.3.12.5

Un contrôle permanent est effectué sur les variations de pourcentage de contrôle desfiliales et participations afin que les traitements appropriés puissent être mis en œuvre lorsdes arrêtés de comptes (périmètre de consolidation, modification de la méthode de conso-lidation…).

2.3.12.6L’accès aux informations nécessaires au traitement dans les comptes consolidés dessociétés mises en équivalence est organisé.

2.3.12.7 Les principes comptables applicables aux comptes consolidés sont homogènes.

2.3.12.8Les règles comptables appliquées définissent les critères de consolidation des filiales et lesméthodes appliquées.

2.3.12.9Les pourcentages d’intérêt et la situation de contrôle des filiales, participations et entitéscontrôlées sont analysés au regard de la situation de contrôle afin de vérifier l’adéquationde la méthode de consolidation appliquée à chacune.

2.3.12.10Les comptes sociaux des filiales sont rapprochés des comptes intégrés dans la consolida-tion, afin d’analyser et de suivre les écarts et les impositions différées.

2.3.12.11La variation entre situation nette consolidée de clôture et situation nette consolidée d’ou-verture est analysée et expliquée.

2.3.12.12 Les variations issues du tableau de flux de trésorerie sont analysées et expliquées.

47


© CIGREF - IFACI

Figure 29 : Rapprochement entre points de contrôle AMF et exemples de contrôleSource : CIGREF - IFACI


Le schéma ci-dessous propose un rapprochement entre points de contrôle AMF et exemples decontrôles. Il s’agit d’exemples de contrôle, à titre d’illustration. La liste n’est pas exhaustive.

Proc

essu

s Co

nsol

idat

ion

2.3.

12 8

) Les

règ

les

com

pta

ble

sap

pliq

uée

s d

éfin

isse

nt

les

crit

ères

de

con

solid

atio

n d

esfil

iale

s et

les

mét

ho

des

ap

pliq

uée

s

2.3.

12.1

2) L

es v

aria

tio

ns

issu

esd

u t

able

au d

e flu

x d

e tr

éso

reri

eso

nt

anal

ysée

s et

exp

liqu

ées

2.3.

12.1

1) L

a va

riat

ion

en

tre

situ

atio

n n

ette

co

nso

lidée

de

clô

ture

et

situ

atio

n n

ette

con

solid

ée d

'ou

vert

ure

est

anal

ysée

et

exp

liqu

ée

2.3.

12.1

0) L

es c

om

pte

s so

ciau

xd

es fi

liale

s so

nt

rap

pro

chés

des

com

pte

s in

tég

rés

dan

s la

co

nso

lidat

ion

, afin

d'a

nal

yser

et d

e su

ivre

les

écar

ts e

t le

sim

po

siti

on

s d

iffér

ées

2.3.

12.9

) Les

po

urc

enta

ges

d'in

térê

t et

la s

itu

atio

n d

eco

ntr

ôle

des

filia

les,

par

tici

pat

ion

s et

en

tité

s co

ntr

ôlé

es s

on

t an

alys

és a

u

reg

ard

de

la s

itu

atio

n d

e co

ntr

ôle

afin

de

véri

fier

l'ad

équ

atio

n d

e la

mét

ho

de

de

con

solid

atio

n a

pp

liqu

ée à

chac

un

e

2.3.

12 7

) Les

pri

nci

pes

com

pta

ble

s ap

plic

able

s au

xco

mp

tes

con

solid

és s

on

th

om

og

ènes

- Co

ntr

ôle

s au

tom

atis

ésco

hér

ence

des

do

nn

ées

- Est

imat

ion

au

tom

atiq

ue

des

mo

nta

nts

ave

c le

s fa

ctu

res

ou

com

pte

s o

uve

rts

- Co

urs

mo

nét

aire

s aj

ust

és

chaq

ue

jou

r- T

ran

sfer

t au

tom

atis

és d

es

do

nn

ées

inte

r-si

tes

- Cen

tral

isat

ion

au

tom

atiq

ue

des

do

nn

ées

- In

clu

re le

s rè

gle

s d

e co

mp

tab

ilité

dan

s le

s ap

plic

atio

ns

- Co

ntr

ôle

d'a

ccès

et

limit

es(d

'au

tori

té) d

e m

od

ifica

tio

ns

man

uel

les

- Sta

nd

ard

isat

ion

(cen

tral

isat

ion

)d

e la

str

uct

ure

des

co

mp

tes

- Éva

luat

ion

des

act

ifs s

elo

nd

es rè

gle

s p

réd

éfin

ies

2.3.

12.6

) L'a

ccès

au

xin

form

atio

ns

néc

essa

ire

autr

aite

men

t d

ans

les

com

pte

sco

nso

lidés

des

so

ciét

és m

ises

en é

qu

ival

ence

est

org

anis

é- S

écu

risa

tio

n d

es d

roit

s d

'acc

èsau

SI

- Pro

céd

ure

de

sau

veg

ard

e et

d

e re

stau

rati

on

test

ée

2.3.

12 5

) Un

co

ntr

ôle

p

erm

anen

t es

t ef

fect

ué

sur

les

vari

atio

ns

de

po

urc

enta

ge

de

con

trô

le d

es fi

liale

s et

par

tici

pat

ion

s

3.3.

12.3

) Les

op

érat

ion

sré

cip

roq

ues

do

iven

t êt

re

iden

tifié

es e

t él

imin

ées

2.3.

12.4

) Les

écr

itu

res

de

con

solid

atio

n s

on

t en

reg

istr

ées

et s

uiv

ies

dan

s u

n jo

urn

alsp

écifi

qu

e

2.3.

12.2

) Les

lias

ses

de

con

solid

atio

n d

oiv

ent

être

ét

ablie

s en

ap

plic

atio

n d

e p

rin

cip

es e

t rè

gle

s co

mp

tab

les

ho

mo

gèn

es a

u s

ein

des

so

ciét

ésin

tég

rées

:- F

aire

tou

rner

les

con

trô

les

etré

sou

dre

les

ano

mal

ies

(inco

hér

ence

, exh

aust

ivit

é)- F

erm

er l'

accè

s d

e fa

çon

ce

ntr

alis

ée à

la d

ate

bu

toir

- Pré

voir

des

co

ntr

ôle

s b

loq

uan

tp

ou

r vér

ifier

la c

oh

éren

ce e

tl'e

xhau

stiv

ité

des

do

nn

ées

etd

es c

on

trô

les

arit

hm

étiq

ues

- Dis

po

nib

ilité

s : I

TGC

- cf

. so

us

gro

up

e 1

et te

st p

réal

able

de

la c

apac

ité

du

sys

tèm

e à

sup

po

rter

des

co

nn

exio

ns

sim

ult

anée

s

2.3.

12.1

) Le

pér

imèt

re d

e co

nso

lidat

ion

do

it ê

tre

ten

uà

jou

r et

do

cum

enté

- Uti

liser

un

log

icie

l de

con

solid

atio

n (p

as e

xcel

)- P

aram

étra

ge

des

règ

les

de

con

solid

atio

n e

t él

imin

atio

nd

ans

l'ou

til

- Avo

ir u

n c

alen

dri

er- P

révo

ir le

s tr

ansf

erts

au

tom

atiq

ues

de

do

nn

ées

(si a

uto

mat

isat

ion

)- M

inim

iser

les

map

pin

gs

etfa

vori

ser l

es t

ran

sfer

tsau

tom

atiq

ues

de

do

nn

ées

- Pré

voir

des

co

ntr

ôle

sau

tom

atiq

ues

(blo

qu

ants

éven

tuel

lem

ent)

de

coh

éren

ceen

tre

État

s et

les

tota

ux)

- Clô

ture

des

co

mp

tes

en

fon

ctio

n d

es c

alen

dri

ers

48

© CIGREF - IFACI

Figure 30 : Vue détaillée du processus consolidation financière

Etape

Acteurs

Description

Risques



Cadre de référence AMF : Consolidation

financière

1) Planifica-

tion de la

consolida-

tion

Consolida-

tion centrale

1.Préparation du calendrier de conso-

lidation

2.Définition du périmètre consoli-

dable

3.Rédaction des principes et règles

comptables à suivre

4.Paramétrage du logiciel de consoli-

dation

5.Définition des tables de correspon-

dance des comptes et des éléments

statistiques

6.Envoi des instructions de consolida-

tion à destination de l’ensemble des

filiales en précisant les nouveautés

en terme comptable et de reporting

sur la période et le calendrier des

opérations pour la clôture

Absence de calendrier de consolidation ou

calendrier incomplet / inapproprié

Calendrier de publication non respecté

Mauvaise prise en compte des modifications de

périmètre

Principes et règles comptables non formalisés

et/ou pas à jour

Outil inadapté ou mauvais param

étrage de

l’outil

Mauvaise définition de liasse de consolidation

(contenu)

Instructions peu claires ou peu compréhensi-

bles

Manque de formation des responsables finan-

ciers locaux

2.3.12

.1)Le pé

rimètre de consolidation do

itêtre tenu

à jour et d

ocum

enté.

-Utiliser un logiciel de consolidation (pas

excel)

-Paramétrage des règles de consolidation

et d’élim

ination dans l’outil

-Avoir un calendrier

-Prévoir les transferts automatiques de

données (si automatisation)

-Minimiser les mappings, et favoriser les

transferts automatiques de données

-Clôture des comptes en fonction du

calendrier incluant les différentes tâches

à accomplir

-Contrôles automatisés de la cohérence

des données en amont (vérification de

seuils limites, cohérence, etc.)

-Cours monétaires ajustés chaque jour et

réconciliation des différences de taux de

change.

-Centralisation automatique des données.

Vérification de la cohérence des données

et reclassification si nécessaire

-Inclure les règles de comptabilité dans

les applications (avec des contrôles et

des rapports d’exception de non-

respect)

-Contrôle d’accès et lim

ites (d’autorité) de

modifications manuelles

-Standardisation (centralisation) de la

structure des comptes et vérification que

les entités ne génèrent pas de propres

comptes auxiliaires inconnus.

-Evaluation des actifs selon des règles

prédéfinies ou calculés automatique-

ment par une source externe

-Le rapprochem

ent intercos peut être fait

via le logiciel de consolidation ce qui

facilite le processus

2) Production

des comptes

sociaux (en

amont)

DAF filiale,

Comptabilité

locale

1.Ecritures d’arrêté des comptes (Ecri-

tures de régularisation, valorisation

des immobilisations, stocks et inves-

tissem

ents, évaluation des participa-

tions, conversion…)

2.Clôture des comptabilités auxiliaires

dans les différentes entités.

3.Centralisation dans le grand livre

4.Vérification des opérations de

centralisation (soldes, devises,…)

5.Analyse et production des comptes

sociaux.

Oubli de passer certaines écritures / erreurs

Non respect du planning

Montants non alloués, comptes intérimaires

avec des soldes ouverts

Mauvaise évaluation des actifs

Non prise en compte de toutes les comptabi-

lités auxiliaires

Mauvais param

étrage des tables de correspon-

dance (comptes)

Reclassification des données incorrecte ou non

justifiée

Mauvaise interprétation des règles de compta-

bilité

Fraude (manipulation des donnés comptables

et financières)

4.6.7.

Vue détaillée du processus consolidation finan

cière

49


© CIGREF - IFACI

Etape

Acteurs

Description

Risques




financière

3) Rappro-

chem

ent des

comptabi-

lités inter

filiales (en

amont)

DAF filiale,

Comptabilité

locale

En amont, un rapprochem

ent est

effectué entre toutes les entités du

groupe de leurs comptes inter compa-

gnies (comptes de bilan et du compte

de résultat : produits/charges) pour

permettre leur élim

ination lors du

processus de consolidation.


Non exhaustivité des comptes rapprochés

Ecart non résolu entre les filiales

2.3.12

.2) Les liasses de

con

solid

ation

doiven

t être étab

lies en

app

lication de

prin-

cipe

s et rè

gles com

ptab

les ho

mog

ènes au

sein des sociétés intégrées.

-Paramétrage des règles de consolidation

et d’élim

ination dans l’outil

-Cours monétaires ajustés chaque jour et

réconciliation des différences de taux de

change

-Standardisation (centralisation) de la

structure des comptes et vérification que

les entités ne génèrent pas de propres

comptes auxiliaires inconnus

-Evaluation des actifs selon des règles

prédéfinies ou calculés automatique-

ment par une source externe

-Exécuter les contrôles et résoudre les

anomalies (incohérences, exhaustivité)

-Fermer l’accès de façon centralisée à la

date butoir

-Prévoir des contrôles bloquants pour

vérifier la cohérence et l’exhaustivité des

données et des contrôles arithmétiques

automatiques

2.3.12

.3)Les opé

ration

s réciproq

ues do

iven

têtre iden

tifié

es et é

liminées, en

particu

lier les

opérations fina

ncières et les résultats

internes (m

arge

s sur stocks, divide

ndes, résul-

tats sur cession

s d’im

mob

ilisation

s…).

-Le rapprochem

ent intercos peut être fait

via le logiciel de consolidation ce qui

facilite le processus

-Analyse des écarts au-dessus des seuils

prédéfinis

4) Etablisse-

ment des

liasses de

consolida-

tion

DAF filiale,

Comptabilité

locale

1.Alignem

ent du calendrier local en

fonction du calendrier Groupe

2.Transfert des données des différents

systèm

es dans le système de conso-

lidation (par saisie manuelle ou

interface automatique) et saisie des

autres données

3.Rapprochem

ent des soldes de

comptes transférés avec les

systèm

es source et test de cohé-

rence des données transmises.

Non respect de règles communiquées par le

Groupe


Manque de cohérence dans l’alim

entation des

liasses de consolidation

Liasse incomplète

Liasse non équilibrée ou mal remplie (écarts

entre les comptes de synthèse et les annexes

détaillés)

Incohérence entre les données transmises et les

systèm

es source

Indisponibilité du système de consolidation

50

© CIGREF - IFACI

Etape

Acteurs

Description

Risques




financière

5) Production

de comptes

consolidés

Consolida-

tion centrale

1.Opérations d’élim

ination des opéra-

tions inter-sociétés

2.Ajustem

ents et reclassifications

nécessaires pour assurer la confor-

mité aux normes Groupe

3.Production d’analyses et de repor-

ting

4.Données réelles sont comparés aux

données prévisionnelles

5.Vérification de la cohérence des

données entre les différents états de

consolidation, etc.

6.Rédaction de l’annexe aux comptes

consolidés


Mauvaise application des règles de consolida-

tion

Non respect/mauvaise interprétation des

normes comptables en vigueur dans le Groupe

Mauvaise élimination des montants inter-

sociétés

Erreur de saisie /Erreur d’imputation

Manque d’analyse et/ou communication d’in-

formations incorrecte ou incohérente.

Fraude comptable (habillage de bilan, Sous- /

Surestimation des actifs)

Indisponibilité du système de consolidation

Mauvais param

étrages du logiciel de consolida-

tion

Mauvaise reprise des historiques

2.3.12

.4)Les écritures de

con

solid

ation sont

enregistrées et suivies dan

s un

journa

l spé

ci-

fique

: distingu

er ou av

oir p

lusieu

rs journa

uxpa

r typ

e d’écriture.

2.3.12

.5)Un contrôle perman

ent e

st effectué

sur les variation

s de

pou

rcen

tage

de contrôle

des filiales et participa

tion

s afin que

les trai-

temen

ts app

ropriés pu

issent être mis en

œuv

re lors des arrêtés de comptes (p

érim

ètre

de con

solid

ation, m

odification

de la

métho

de de consolidation…

).-analyse de la variation de la situation

nette comptable consolidée (si possible

automatisé)

2.3.12

.6) L’accès aux

inform

ations néces-

saires au traitemen

t dan

s les comptes con

so-

lidés des sociétés mises en éq

uiva

lence

est o

rgan

isé.

2.3.12

.7) Les princ

ipes com

ptab

les ap

plica-

bles aux

com

ptes con

solid

és son

t hom

o-gè

nes.

-Inclure les règles de comptabilité dans

les applications (avec des contrôles et

des rapports d’exception de non-

respect)

2.3.12

.8) Les rè

gles com

ptab

les ap

pliqué

esdé

finissent les critères de consolidation de

sfiliales et les métho

des ap

pliqué

es.

51


© CIGREF - IFACI

Etape

Acteurs

Description

Risques




financière

2.3.12

.9) Les pou

rcen

tage

s d’intérêt e

t la

situation de

con

trôle de

s filiales, pa

rticipa-

tion

s et entités con

trôlées sont ana

lysés au

rega

rd de la situa

tion

de contrôle afin

de

vérifie

r l’adé

quation de

la m

étho

de de conso-

lidation ap

pliqué

e à ch

acun

e.

2.3.12

.10) Les com

ptes sociaux

des filia

les

sont ra

pproch

és des com

ptes intégrés dan

sla con

solid

ation, afin

d’ana

lyser

et de suivre les écarts et les im

position

s diffé-

rées.

-Prévoir des contrôles automatiques

(bloquants éventuellement) de cohé-

rence (entre les états et les totaux)

-Contrôles automatisés de la cohérence

des données en amont (vérification de

seuils limites, cohérence, etc.)

-Tableau de passage situation nette -

conso

2.3.12

.11) La va

riation en

tre situation ne

tte

consolidée de clôture et situa

tion

nette

consolidée d’ouv

erture est ana

lysée et exp

li-qu

ée.

2.3.12

.12) Les variation

s issues du tablea

u de

flux de

trésorerie son

t ana

lysées et exp

li-qu

ées.

52

© CIGREF - IFACI

5. LE CONTRÔLE INTERNE DE LA DSI

5.1. Objectifs .................................................................................................................. 53

5.2. Périmètre retenu ..................................................................................................... 54

5.3. Démarche suivie et principaux livrables ............................................................... 55

5.4. Les préalables au contrôle interne de la DSI ........................................................ 56

5.5. Gestion des compétences ...................................................................................... 585.5.1. Flowchart du processus de gestion des compétences de la DSI .............. 595.5.2. RACI du processus de gestion des compétences de la DSI ...................... 615.5.3. Matrice risques/contrôles du processus de gestion des compétences

de la DSI ........................................................................................................ 63

5.6. Projet et développement ........................................................................................ 685.6.1. Flowchart du processus de projet et développement ................................ 685.6.2. RACI du processus de projet et développement ........................................ 695.6.3. Matrice risques/contrôles du processus de projet et développement ...... 71

5.7. Maintenance et gestion des changements ........................................................... 895.7.1. Flowchart du processus de maintenance et gestion du changement ...... 905.7.2. RACI du processus de maintenance et gestion du changement .............. 935.7.3. Matrice risques/contrôles du processus de maintenance et gestion des

changements (applicatifs et techniques) .................................................... 95

5.8. Gestion des incidents ........................................................................................... 1135.8.1. Flowchart du processus de gestion des incidents .................................... 1145.8.2. RACI du processus de gestion des incidents ............................................ 1155.8.3. Matrice risques/contrôles du processus de gestion des incidents .......... 116

5.9. Gestion de la sécurité logique et des accès physiques ....................................... 1205.9.1. Flowchart du processus de gestion d’attribution des droits d’accès ...... 1215.9.2. RACI du processus de gestion de sécurité logique et des accès ............. 1225.9.3. Matrice risques/contrôles du sous-processus d’accès aux programmes

et aux données ............................................................................................ 123

5.10. Gestion de la sous-traitance et infogérance ....................................................... 1295.10.1. Flowchart du processus de gestion de la sous-traitance ...................... 1305.10.2. RACI du processus de sous-traitance .................................................... 1325.10.3. Matrice risques/contrôles du processus de sous-traitance .................. 135

53


© CIGREF - IFACI

A l’instar des autres métiers, la DSI doit mettre en œuvre un dispositif de contrôle interne lui per-mettant de maîtriser ses risques pour atteindre ses objectifs opérationnels. Les objectifs ducontrôle interne, pour la DSI comme pour toute autre fonction, sont :

• la conformité aux instructions de la direction générale, aux lois et règlements ;• l’efficacité des opérations, en particulier à travers l’utilisation optimale des ressources affec-

tées et la maîtrise des processus ;• l’identification, l’analyse et l’évaluation des risques ;• la sécurité des personnes, la sauvegarde des actifs et la protection des données ;• la qualité de l’information financière, opérationnelle et de gestion.

Les spécificités de l’informatique, liées à sa technicité et à sa transversalité, donnent une dimen-sion particulière au contrôle interne de la DSI.Selon le cadre de référence de contrôle interne de l’AMF, le dispositif de contrôle interne doit pré-voir :

1. une organisation comportant une définition claire des responsabilités et s’appuyant sur dessystèmes d’informations, des procédures et des pratiques appropriées ;

2. la diffusion en interne d’informations pertinentes et fiables ;3. un système de recensement et d’analyse des principaux risques et des procédures de gestion

de ces risques ;4. des activités de contrôle proportionnées aux enjeux ;5. une surveillance du dispositif de contrôle interne.

Ces principes doivent être appliqués dans les DSI. Leur mise en œuvre est évaluée pour donnerune assurance sur l’efficacité du contrôle interne et identifier des pistes de progrès.

5.1. Objectifs

Ce chapitre fournit : • une illustration de l’application des objectifs et des composantes du cadre de référence de

l’AMF au contrôle interne de la DSI ;• une synthèse des préalables nécessaires à la mise en place d’un dispositif de contrôle interne

efficace au sein d’une DSI ;• une description de six processus représentatifs des activités d’une DSI, ainsi qu’une défini-

tion du rôle des principaux acteurs concernés par ces processus ;• des guides d’évaluation à destination des DSI, des contrôleurs internes et des auditeurs

internes. Ils facilitent la coopération entre les fonctions et permettent de vérifier le degré demaîtrise des processus.

54

© CIGREF - IFACI


Six processus ont été sélectionnés, car ils contribuent puissamment à l’atteinte des objectifs decontrôle interne rappelés précédemment :

• gestion des compétences ;• projet et développement ;• maintenance et gestion des changements ;• sécurité logique et gestion des accès physiques ;• gestion des incidents ;• contrats d’infogérance et pilotage de la sous-traitance.

Le tableau de concordance figurant en annexe 3 permet d’établir une relation entre ces processuset les objectifs de contrôle issus du cadre de référence de l’AMF.

Cependant, cette analyse n’est pas exhaustive. Ainsi, la continuité d’exploitation n’est pas traitée,et la gouvernance des systèmes d’information est partiellement abordée dans le processus de ges-tion de projets. Bien que ces domaines jouent un rôle important dans le contrôle interne de la DSI,le groupe de travail a préféré appliquer le principe de réalité en privilégiant la richesse du retourd’expérience sur un nombre limité de processus.

Le tableau ci-après précise le périmètre d’analyse de chaque processus. Enfin, les interfaces éven-tuelles avec d’autres processus sont identifiées.

Processus Périmètre

Projet et

développement

Maintenance et

gestion des

changements

Gestion des

incidents

Gestion de la sécurité

logique et des accès

physiques

Gestion de la

sous-traitance

Gestion descompétences

Gestion spécifique des compé-tences critiques (garantissant laréussite du SI) et des compétencesclés (critiques et rares sur le marché)

Projet etdéveloppement

Maîtrise des projets de développe-ment informatique y compris laconduite du changement

Maintenance et gestiondes changements

Maintenance et gestion des change-ments (applicatifs et techniques)

Gestion des incidentsGestion et résolution des incidentstouchant les applicatifs, lessystèmes, la sécurité …

Gestion de la sécuritélogique et des accèsphysiques

Environnement de contrôle interneet mise en œuvre de la politique desécurité des SI

Gestion de la sous-traitance

Maîtrise des services fournis par desprestataires externes dans les SI tanten projets, en maintenance qu'enexploitation

55


© CIGREF - IFACI

5.3. Démarche suivie et principaux livrables

Les travaux se fondent sur une approche par les risques. Pour chaque processus, le groupe de tra-vail a procédé à l’identification des :

• sous-processus et étapes clés ;• acteurs et de leur responsabilité respective ;• risques associés à chaque étape-clé ;• activités de contrôle permettant la maîtrise du risque identifié ;• bonnes pratiques à partir des référentiels existants et du retour d’expérience des contribu-

teurs, ce qui donne un caractère opérationnel aux documents produits.

Les six processus étudiés correspondent bien à la nomenclature COBIT et ces travaux sont compa-tibles avec les grands référentiels comme Val IT, ITIL, CMMI, ISO, eSCM…

ThèmeRéférentielsutilisés

Processus COBIT

Projet et dévelop-pement

VAL ITITIL

PO5 : Gérer les investissements informatiquesPO9 : Evaluer et gérer les risquesPO10 : Gérer les projetsAI1 : Trouver des solutions informatiquesAI2 : Acquérir des applications et en assurer la maintenanceAI4 : Faciliter le fonctionnement et l’utilisationAI5 : Gérer les changementsAI7 : Installer et valider les solutions et les modificationsDS1 : Définir et gérer les niveaux de servicesDS6 : Identifier et imputer les coûtsDS11 : Gérer les donnéesDS12 : Gérer l’environnement physique

Maintenance etgestion des chan-gements

IIA/GTAG 2 :Change andpatchmanage-mentcontrols

PO4 : Définir les processus, l’organisation et les relations de travailAI2 : Acquérir des applications et en assurer la maintenanceAI6 : Gérer les changementsAI7 : Installer et valider les solutions et les modifications

Sécurité logiqueet gestion desaccès physiques

ISO 27001DS5 : Assurer la sécurité des systèmesDS12 : Gérer l’environnement physique

Contrats d’infogé-rance et pilotagede la sous-trai-tance

eSCM DS2 : Gérer les services tiers

Gestion des inci-dents

ITILSoutien desservices/Gestion desincidents

DS8 : Gérer le service d’assistance client et les incidents

Gestion descompétences

PO7 : Gérer les ressources humaines de l’informatique

56

© CIGREF - IFACI

Les résultats des travaux sont structurés dans trois catégories de livrables qui sont cohérents entreeux tout en donnant un éclairage particulier sur le processus concerné.

• Le flowchart constitue l’une des valeurs ajoutées de ces travaux. Il schématise les fluxd’infor mations ainsi que les activités qui relient les étapes clés et les acteurs. Ce documentdonne une bonne compréhension des activités ;

• le RACI1 clarifie les responsabilités respectives des acteurs concernés et illustre l’évolutionde ces responsabilités à chaque étape ; ce tableau est illustré par les principaux livrables quiconstituent des preuves tangibles de la maîtrise des risques ;

• la matrice risques/contrôles avec le format suivant : - sous-processus (le cas échéant) ;- étapes-clés ;- référence à un référentiel existant (COBIT, ITIL, ISO...) ;- objectifs de contrôle ;- risque ;- activité de contrôle ;- bonnes pratiques.

Cette matrice est suffisamment opérationnelle pour mettre en œuvre le dispositif de contrôle oupour procéder à son évaluation. Elle devrait contribuer à l’amélioration de l’efficacité des activitésde la DSI et faciliter la comparaison des pratiques.

5.4. Les préalables au contrôle interne de la DSI

Le dispositif de contrôle interne de la DSI nécessite la préexistence d’un contexte favorable au bondéploiement du dispositif et à son amélioration continue.

Un de ces préalables consiste à avoir un niveau adéquat de sponsorisation du dispositif. A ce pro-pos, le cadre de référence de l’AMF préconise que la direction générale se tient régulièrementinformée des dysfonctionnements, des insuffisances et des difficultés d’application, voire desexcès, et veille à l’engagement des actions correctives nécessaires. Ce principe général doit êtreadapté en fonction des enjeux du contrôle interne dans la DSI.

L’efficacité du dispositif requiert l’application de règles du jeu telles que : • l’adoption et la communication d’une politique SI ;• une déclinaison de cette politique en objectifs de contrôle permettant d'évaluer la réalité de

son déploiement et son efficacité ;• une méthodologie orientée sur les risques qui facilite la définition et la priorisation des acti-

vités de contrôle ;• une définition des responsabilités et des pouvoirs assurant une séparation adéquate des

tâches ; elle est retranscrite dans les droits des utilisateurs et permet la gestion des flux d’in-formation en fonction des responsabilités ;

• la surveillance de l’application des politiques et des standards.

1 Le modèle RACI est un modèle qui permet de décrire les rôles et responsabilités des acteurs au sein d’une organisation, sur un processus donné.RACI définit 4 rôles - R: Responsible ou Réalisateur, A: Accountable ou Approbateur C: Consulted ou Consulté, I: Informed ou Informé.

57


© CIGREF - IFACI

Ces préalables sont retranscrits au niveau de chaque processus analysé.

La question du contrôle interne de la DSI renvoie spontanément aux politiques liées aux infra-structures et aux applications. Pourtant, dans un contexte de raréfaction des ressources et de ten-sion sur le marché des professionnels du SI, il convient de porter une attention particulière à lagestion des compétences et au contrôle de la sous-traitance. La continuité des compétencesdoit être assurée par un pilotage des rôles critiques et des rôles clés de la DSI. Il est guidé par lapolitique RH de l’entreprise et le schéma directeur des SI. La stratégie de sourcing concerne lesprocessus centraux de la DSI (réalisation, maintenance, exploitation, sécurité). De ce fait, l’exécu-tion et le pilotage des contrats tiers nécessitent des politiques (RH SI, Achats, Schéma directeurSI…) et des règles clairement définies.

De même, pour mener à bien un projet informatique, il est indispensable d’adopter et d’appli-quer des principes de bonne gouvernance comme la surveillance permanente de l’alignement desprojets SI avec la stratégie et les priorités de l’entreprise. En pratique, les projets sont priorisés parun comité d’investissements qui fonde sa décision sur une analyse des enjeux, des investissementset des risques. La validation des jalons essentiels du projet (expression des besoins, lancement,tests, recettes) est systématisée. La conduite du changement (analyse d’impacts, communication,formation, soutien et reprise des données) doit être engagée le plus en amont possible.

La maîtrise de la maintenance des applications exige une adéquation continue des fonctionnali-tés avec les besoins des métiers. Cette bonne gestion répond également à des impératifs de coût,de qualité et de sécurité. L’efficacité de ce dispositif repose sur la documentation et l’applicationd’un plan stratégique de maintenance, et des règles de gestion des changements qui prévoient lessituations d’urgence ainsi que la séparation effective des tâches notamment entre le développe-ment et l’exploitation.

La gestion des incidents doit être effectuée dans un contexte caractérisé par la multiplication destechnologies et l’hétérogénéité de plateformes toujours plus interconnectées. Ce processus néces-site l’utilisation d’une méthodologie préalablement définie pour l’identification des causes del’inci dent et la maîtrise de la cascade d’événements qui pourrait être générée par cet incident. Ilconvient notamment de mettre en place des dispositifs automatiques de surveillance des maté-riels, réseaux, systèmes d’exploitation, bases de données et applicatifs critiques.

Le processus lié à la sécurité logique et à la gestion des accès physiques garantit des donnéesintègres, en empêche une divulgation inappropriée et supporte la continuité de l'activité de l'en-treprise. La politique de sécurité précise les vulnérabilités identifiées et les objectifs de protection.Pour avoir des niveaux de protection proportionnés aux enjeux, il faut s’appuyer sur les résultats dela qualification des informations.

Les actions engagées au sein de la DSI doivent être cohérentes avec les autres démarches decontrôle interne engagées dans l’organisation.

58

© CIGREF - IFACI

5.5. Gestion des compétences

La gestion des compétences dans le domaine informatique est une constante depuis la montée enpuissance des systèmes d’information dans tous les métiers de l’entreprise et de l’admi nistration,et en parallèle depuis la tension sur la disponibilité des ingénieurs et techniciens informatiques. Enréalité, derrière « gestion des compétences » se profile un pilotage des rôles, et en particulier desrôles critiques (essentiels pour le bon fonctionnement de la DSI, et a priori non externalisables) etdes rôles clés (rôles critiques particulièrement rares sur le marché).

La gestion des rôles est donc la traduction concrète, au sein d’une DSI, de la gestion globale destalents dans l’organisation. Mais pourquoi une gestion des compétences spécifique à l’informa-tique par rapport aux autres services ? Parce que la diffusion du système d’information dans tousles processus métiers de l’entreprise ou de l’administration s’est doublée de la rareté des res-sources disponibles, le rendant critique et rendant toute l’organisation vulnérable à sa criticité. Demême que l’on travaille sur la continuité des infrastructures à travers des plans de secours et dereprise d’activité, de même il convient de travailler sur la continuité des compétences.

La gestion des compétences informatiques se fonde sur deux préalables : une politique RH globaledans l’entreprise, et un schéma directeur des SI. Leur combinaison débouche sur une politique RHSI dont la définition et la mise en œuvre sont décrites dans le processus ci-après.

59


© CIGREF - IFACI

5.5.1. Flowchart du processus de gestion des compétences de la DSI

Définition des parcours professionnels pour les emplois à compétences critiques

Définition des schémas de professionnalisation des emplois à compétences critiques

Définition de la politique RH SI clarifiant les activités externalisées et les compétences critiques et clés

Définition d’un référentiel commun de compétences SI

Définition des cartographies de compétence

Définition des emplois à compétences critiques et clés

Validation talents, définition d’une stratégie de fidélisation des talents

Organisation des remplacements et formations croisées

Sou

s-p

roce

ssu

s : V

isio

n m

oyen

-ter

me

emp

loi-

com

pét

ence

s

Schéma Directeur SI

Groupe

Politique RH Groupe

Politique RH SI

Carto compétences

Liste emplois compétences

critiques et clés

Parcours prof. compétences

critiques

Schémas prof. compétences

critiques

Liste des talents validée et

stratégie de gestion

Activité

Décision

Livrable

Légende

DSI RH

60

© CIGREF - IFACI

Sou

s-p

roce

ssu

s :

Ges

tio

n d

es o

bje

ctifs

et d

e la

per

form

ance Déclinaison en cascade des objectifs selon l’organisation

Définition des rôles et responsabilités dès la prise de fonctions

Mesure des résultats

Sou

s-p

roce

ssu

s : G

esti

on

des

co

mp

éten

ces

�de

la fo

nct

ion

SI e

n c

oh

éren

ce a

vec

l’act

ivit

é

Élaboration de plans de mobilité / recrutement externe et déploiement de ceux-ci

Détection des talents

Élaboration et mise en œuvre d’un plan de formation, pour l’ensemble du personnel et spécifique aux personnes occupant des emplois à compétences critiques

Sou

s-p

roce

ssu

s :

Gar

anti

e d

esco

mp

éten

ces

clés

de

la fo

nct

ion

SI

Détermination du dispositif par emploi à compétence clé

Mise en œuvre du dispositif

DSI RH

Schémas prof. compétences

clés

Parcours prof. compétences

critiques

Stratégie de gestion des

talents

Liste emplois à compétences

critiques et clés

Plan de chargeschéma directeur

Politique RH SI

61


© CIGREF - IFACI

Etape clé

DSI

DRH

Livrables majeurs de sortie

Commentaires

Sous-processus : Vision moyen-terme emploi-compétences

Définition d’une politique RH SI, clarifiant les

activités externalisées et les compétences

critiques clés

AR

Politique RH SI

Définition d'un référentiel commun de

compétences SI

AR

Référentiel Groupe mis à jour et

plan de communication associé

Définition des cartographies de compétences

AR

Cartographie des compétences

Définition des emplois à compétences

critiques et clés

AR

Liste des compétences critiques et

clés

Définition des parcours professionnels pour

les em

plois à compétences critiques

AR

Définition des parcours profession-

nels des compétences critiques

Définition des schém

as de professionnalisa-

tion des emplois à compétences critiques

AR

Schém

as de professionalisation des

emplois à compétences critiques

Validation talents, définition d’une stratégie

de fidélisation des talents

AR

Liste des talents validée et stratégie

de gestion

Organisation des remplacements et forma-

tions croisées

AR

Schém

as de backup et formations

associées

Sous-processus : Gestion des objectifs et de la performance

Déclinaison en cascade des objectifs selon

l’organisation

AR

CObjectifs déclinés dans l'organisa-

tion

Action réalisée par les managers des différentes entités, sous la

responsabilité du DSI et validée par le DSI.

Définition des rôles et responsabilités dès la

prise de fonctions

AR

CLettre de mission



Mesure des résultats

AR

CEntretiens annuels

Reporting sur le respect des objec-

tifs entités



5.5.2.

RACI du processus de ge

stion des com

péten

ces de la D

SI

62

© CIGREF - IFACI

Etape clé

DSI

DRH


Commentaires

Sous-processus : Gestion des compétences de la fonction SI en cohérence avec l’activité

Élaboration des plans de mobilité / recrute-

ment externe et déploiement de ceux-ci

AR

Plan de mobilité et de recrutement

externe et déploiement de ces plansLes managers des différentes entités, sous la responsabilité du

DSI, sont contributeurs de cette activité.

Détection des talents

AR

CListe des talents détectés

La détection des talents est réalisée par les managers des diffé-

rentes entités, sous la responsabilité du DSI et validée par le

DSI.

Élaboration et mise en œuvre d’un plan de

formation, pour l’ensemble du personnel et

spécifique aux compétences critiques

AR

C

Plans de formation pour l'ensemble

du personnel

Plans de formation spécifiques aux

compétences critiques

Plans de déploiement associés



Sous-processus : Garantir les compétences clés de la fonction SI

Détermination du dispositif par compétence

clé

AR

Dispositif de gestion des compé-

tences clés

Mise en œuvre du dispositif

AR

CReporting de déclinaison du dispo-

sitif



63


© CIGREF - IFACI

5.5.3.

Matrice risques / con

trôles du processus de ge

stion des com

péten

ces de la D

SI

Processus

Etapes-clés

N° de

réf

COBIT,

ITIL,

ISO…

Objectifs de

contrôle

Risque

Activité de contrôle

Bonnes pratiques

Vision moyen-terme emploi-compétences

Politique RH SI

PO7.1

S'assurer de l'exis-

tence, mise à jour

et partagée, d’une

politique RH SI

adéquate avec la

vision moyen-

terme

Politique RH SI

inexistante,

inadaptée ou

ignorée.

Revue de la politique RH SI et mesure

de son adéquation aux points majeurs

suivants :

1) déclinaison politique RH de l'entre-

prise ou l'administration ;

2) clarification des activités à externa-

liser ;

3) mise à jour autant que nécessaire

pour répondre aux enjeux du SI.

Mesure de l'appropriation de la poli-

tique RH SI par les acteurs majeurs

concernés.

Existence d'une politique RH SI répondant aux

conditions définies dans l'activité de contrôle.

Appropriation de la politique RH SI par l'en-

semble des managers.

Référentiel

commun de

compétences

SI

PO7.2


tence, de la mise à

jour et du partage

d’un référentiel

commun des

compétences SI

en intégrant la

vision moyen-

terme

Hétérogénéité des

référentiels de

compétences SI.

Revue du référentiel commun de

compétences SI et mesurer de son

adéquation aux besoins identifiés en

compétences SI dans le schém

a direc-

teur SI.

Mesure de son appropriation par les

managers SI.

Mise à jour annuelle du référentiel de compé-

tences SI et déclinaison de celle-ci par entité.

Intégration d'une thém

atique RH dans les

conventions annuelles présentant les change-

ments apportés par rapport à la version précé-

dente du référentiel de compétences.

Appropriation de ce référentiel par l'ensemble

des managers SI.

64

© CIGREF - IFACI

ProcessusEtapes-clés

N° de

réf

COBIT,

ITIL,

ISO…

Objectifs de

contrôle

Risque


Bonnes pratiques


Cartographies

de compé-

tences

PO7.3

S'assurer de la défi-

nition, de la mise à

jour et du partage

des cartographies

de compétences.

Inadéquation des

compétences avec

les activités

prévues au schém

adirecteur SI

Groupe.

Revue de l'existence d'un processus

d'établissement et de mise à jour des

cartographies.

Revue des cartographies des compé-

tences pour vérifier leurs mises à jour

sur la base du réel (situation actuelle,

situation cible ) et des besoins du

schém

a directeur SI Groupe.

Mesure de la connaissance des carto-

graphies de compétences par les

managers.

Les cartographies des compétences sont

construites à partir du référentiel de compé-

tences, et remises à jour sur la base du réel et des

besoins du schém

a directeur SI Groupe.

Les cartographies de compétences sont connues

de l'ensemble des managers.

Emplois à

compétences

critiques et clés

PO7.4


nition, de la mise à

jour et du partage

des compétences

critiques et clés

Non recencement

des compétences

critiques et clés.

Revue de l'existence d'un processus de

définition, de mise à jour et de partage

des compétences critiques et clés.

Revue de l'existence d'une liste préci-

sant les em

plois à compétences

critiques et clés mise à jour périodi-

quem

ent.

Mesure de la connaissance de cette

liste par les managers.

Le processus de définition, mise à jour et partage

des compétences critiques et clés fait l'objet

d'une boucle d'amélioration continue et permet

de définir une liste d'emplois à compétences

critiques et clés mise à jour périodiquem

ent.

Cette liste est connue par l'ensemble des mana-

gers.

Parcours

professionnels

des emplois à

compétences

critiques

PO7.1


tence de parcours

professionnels

pour les emplois à

compétences

critiques, mis à jour

et partagés.

Mauvaise gestion

des compétences

critiques.

Revue de l'existence de documents

clarifiant les parcours professionnels

des emplois à compétences critiques .

Mesure de l'appropriation de ces

documents par les managers

Existence de documents clarifiant les parcours

professionnels des emplois à compétences

critiques mis à jour autant que de besoin.

Ces documents sont connus par l'ensemble des

managers

65


© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT,

ITIL,

ISO…

Objectifs de

contrôle

Risque


Bonnes pratiques


Schém

as de

professionnali-

sation des

emplois à

compétences

critiques

PO7.4

S'assurer de l'éla-

boration, du

partage et de la

mise à jour des

schém

as de profes-

sionnalisation des

emplois à compé-

tences critiques

Pas de profession-

nalisation ou

professionnalisa-

tion insuffisante

des emplois à

compétences

critiques.

Revue de l'existence de schém

as de

professionnalisation associés à chaque

compétence critique recensée.

Mesure de l'appropriation de ces

schém

as par les managers.

Existence de schém

as de professionnalisation

appropriés pour chaque compétence critique.

Mise à jour des schém


sur la base des bilans sur les pratiques et de leurs

impacts sur la performance du SI.

Les schém

as de professionnalisation sont connus

de l'ensemble des managers

Validation des

talents et stra-

tégie de fidéli-

sation des

talents

PO7.1

S'assurer de la vali-

dation des talents,

de la définition du

déploiement d’une

stratégie visant à

fidéliser les talents

Fuite des talents.

Mesure de l'appropriation par les

managers de la stratégie de fidélisa-

tion des talents.

Mesure de la mise en œuvre du dispo-

sitif de validation des talents

Il existe un processus de validation des talents

détectés; celui-ci est mis en œuvre à 100%

.

Des listes à potentiels SI (talents) sont établies et

mises à jour.

Gestion dynam

ique des parcours professionnels

et donc de la rémunération.

La stratégie de fidélisation des talents est connue

de l'ensemble des managers.

Remplace-

ments et

formations

croisées

PO7.8

PO7.5

S'assurer de l'adé-

quation du dispo-

sitif d'organisation

des remplace-

ments et des

formations croi-

sées

Non existence de

schém

as de

backup pour les

positions critiques.

Revue de l'existence :

-d'un dispositif de clarification des

postes à position critique ;

-de schém

as de back-up pour les

postes à position critique par ailleurs

testés.

Mesure de la prise en compte, lors

d'une mutation sur un poste à compé-

tence critique, d'une période de recou-

vrem

ent.

Mise à jour des postes à position critique.

Mise en place de tables de succession.

Couverture de chaque poste à position critique

par un schém

a de backup.

Le schém

a de backup peut être déployé sans

difficulté, en cas de besoin.

66

© CIGREF - IFACI

ProcessusEtapes-clés

N° de

réf

COBIT,

ITIL,

ISO…

Objectifs de

contrôle

Risque


Bonnes pratiques

Gestion des objectifs et de la performance

Déclinaison

des objectifs

PO7.7

S'assurer de la

bonne déclinaison

des objectifs au

sein de l’organisa-

tion

Des objectifs

personnels non

adéquats avec l'or-

ganisation.

Revue de la définition en cascade de

lettres de mission suivant l'organisa-

tion et en adéquation avec les objec-

tifs de l'entité SI.

Existence de lettres de missions par entité et défi-

nition d'objectifs individuels cohérents avec ceux

de l'entité d'appartenance.

La responsabilité des objectifs clés tient compte

du potentiel et de l'expérience des hommes en

place.

Rôles et

responsabilités PO7.3


nition des rôles et

responsabilités dès

la prise de fonction

(recrutement,

mobilité ou réor-

ganisation)

Manque de clarifi-

cation des objec-

tifs.

Revue de l'existence d'une lettre de

mission fournie à chaque acteur,

prenant une nouvelle fonction.

Lettres de missions réalisées dès la prise de la

nouvelle fonction pour chaque acteur; chacune

d'entre elles clarifient les rôles et responsabilités

assignés.

Mesure des

résultats

PO7.7

S'assurer de la mise

en place d'un

dispositif adéquat

de mesure des

résultats

Pas d'évaluation

des performances

individuelles

Respect des objec-

tifs non mesuré.

Revue de l'existence d'entretiens pour

apprécier les performances indivi-

duelles et déceler les souhaits de

mobilité.

Revue du respect des objectifs ainsi

que de l'existence d'un plan d'action

associés visant à accroître la perfor-

mance.

Revue de l'existence d'un plan de

déploiement visant à ancrer le dispo-

sitif de contrôle interne, d'éthique et

de sécurité de l'information

Définition d'un canevas d'entretien annuel diffusé

et utilisé par l'ensemble des managers qui intègre

les spécificités SI.

Entretien annuel réalisé pour l'ensemble du

personnel suivant le canevas défini.

Plans d'action visant à accroître la performance,

établis périodiquem

ent sur la base de contrôle

des objectifs par entités et de façon individuelle.

Mise en place d'un dispositif de sensibilisation au

contrôle interne, à l'éthique et à la sécurité, ciblé

par type d'acteur en fonction de sa place dans

l'organisation et basé sur une mesure de l'appro-

priation par type de population.

67


© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT,

ITIL,

ISO…

Objectifs de

contrôle

Risque


Bonnes pratiques

Gestion des objectifs et de la performance

Plans de mobi-

lité / recrute-

ment externe

PO7.1


boration pério-

dique d’un plan de

mobilité

interne/recrute-

ment externe

adéquat

Retard / anticipa-

tion excessive des

mobilités et des

recrutements.

Des postes

critiques non

couverts.

Surcoût.


mobilité interne/recrutement externe

défini annuellement.

Mesure de la mise en œuvre de ce

plan de mobilité.

Un plan de recrutement externe / mobilité est

défini annuellement et déployé conformém

ent à

la trajectoire définie.

Le plan de recrutement externe/mobilité est anti-

cipé et tient compte de l'ensemble des éléments

suivants :

-le plan de charge ;

-la politique RH SI ;

-les parcours professionnels définis pour les

emplois à compétences critiques ;

-la stratégie de gestion des talents.

Détection des

talents

PO7.2


tence d'un

processus de

détection des

talents adéquat

Dém

otivation des

employés.


détection des talents défini.


processus.

Processus de détection des talents connu des

managers.

Détection des talents en émergence et apprécia-

tion périodique de ceux-ci.

Plan de forma-

tion

PO7.4


boration du plan

de formation

adéquat

Pas de plan de

formation permet-

tant des montées

en compétences

du personnel.


formation établi sur la base de

schém

as de professionalisation des

emplois à compétences critiques.


plan de formation et notamment

d'une sensibilisation à la sécurité.

Existence de plans de formation adéquats et mis

en œuvre pour l'ensemble du personnel.

Déclinaison des schém


en plans de formation pour les compétences

critiques.

Garantir les compétencesclés de la fonction SI

Dispositif par

compétence

clé

PO7.2

PO7.5

S'assurer de l'adé-

quation du dispo-

sitif de gestion de

chaque compé-

tence clé

Non gestion des

compétences clés.

Revue de l'association d'un dispositif

de gestion spécifique à chaque

compétence clé identifiée.

Mesure de la mise en œuvre des

dispositifs de gestion des compé-

tences clés.

Des dispositifs personnalisés de gestion de

chaque compétence clé définis, mis en œuvre et

partagés par l'ensemble des managers.

68

© CIGREF - IFACI

5.6. Projet et développement

Les projets informatiques sont souvent la vitrine d’une DSI, puisqu’ils jouent le premier rôle dansles grands projets de transformation, tant dans l’entreprise que dans le secteur public. Cette fortevisibilité s’accompagne souvent d’une mauvaise réputation, car nombre de projets dérapent encoûts ou en délais, voire avortent tout simplement.

En effet, les risques subis par les projets sont multiples et souvent concomitants :• risques liés à l’organisation et au contexte de l’entreprise ;• risques liés aux processus et aux moyens de développement ;• risques liés aux caractéristiques du produit.

C’est pourquoi, certains pré-requis en matière d’environnement de contrôle sont nécessaires pourcréer les conditions de réussite des projets informatiques :1. Afin d’abord de garantir l’alignement stratégique des projets sur les métiers, la politique infor-

matique et sa déclinaison en plan stratégique doivent être décrites et communiquées, et lesprojets priorisés selon leurs enjeux, investissements et risques par un comité de gouvernanceavant d’être lancés. La stratégie et les priorités de l’organisation doivent se refléter en perma-nence dans le portefeuille de projets.

2. Les organes de gouvernance de l’activité projets et développement (office des projets) et duprojet proprement dit (comité de pilotage) regroupent des représentants des directions métiers(maîtrise d’ouvrage) et des représentants de la DSI, incluant des structures de support : contrôlede gestion, assurance qualité. Ces organes valident la justification des projets et suivent son bondéroulement :• la performance opérationnelle et économique du projet est mesurée, discutée puis incluse

dans un tableau de bord de toute l’activité de projets et développements ;• le dispositif de management de la qualité et contrôle interne est décrit et opérationnel.

3. La politique de sécurité du système d’information, définie par la DSI, permet d’intégrer les exi-gences de sécurité appropriées dès le début du projet, et de les actualiser au fur et à mesure del’avancement.

4. Enjeu capital dans la réussite ou l’échec d’un projet, la conduite du changement (analyse d’im-pact, communication, formation, reprise des données, support) doit être appréhendée le plusen amont possible et mise en place dans le cadre du déploiement de la solution.

5. Les référentiels méthodologiques de la DSI en matière de gestion de projet comme de stan-dards de développement doivent être définis et communiqués, car ils sont les éléments opéra-tionnels fondamentaux pour maîtriser l’environnement informatique :• La méthode de conduite de projet intègre les étapes clés et les grands jalons de validation :

expression des besoins, recettes, mise en production, déploiement de la solution (y comprisla documentation associée) ; de même, elle explicite formellement les rôles et responsabili-tés : maître d’ouvrage, chef de projet, architecture, exploitation, formation, support.

• Les normes et procédures définies par la DSI (COBIT, Val IT, ITIL, CMMI, ISO, eSCM, …) per-mettent de garantir la standardisation, le contrôle qualité, et les principes de séparation defonctions et d’environnement (études et production).

5.6.1. Flowchart du processus de projet et développement

Cf. flowchart « Maintenance et gestion du changement » p.90

69


© CIGREF - IFACI

5.6.2. RACI du processus de projet et développement

Etape clé duprocessprojet et

développement Office des

projets

Maîtrise

d’Ouvrage

Etudes /

Développements

Production /

Exploitation

Architecture

Fonctions

Support (Contrôle

Interne, Sécurité, régle-

mentaire, juridique)

Livrables attendusProcessusCOBIT

Lancement /cadrage / validation

du projet

AR C C C C Expression de besoins

AI1PO5

AR C C C C Etude préalable et/ou d'opportunité

A AR C I I ICompte-rendu d'arbitrage ducomité en charge des projets SI(enjeux/gains/risques)

Conduite duchangement(activitéstransverses)

AR C C C C Dossier d’analyse d’impact

AI2AI4AI7

AR C I IPlan de formationPlan de communicationDocumentations utilisateur

A C AR Description du soutien

I C AR C Dossier d'exploitabilité

Gestion du projet(activitéstransverses)

A AR C C I I Schéma d'organisationPO4PO8PO10

A R AR R I I Plan projet / Planning du projet

I I AR C I I Tableau de Bord d'avancement

Conception AR R R C C

Cahier des charges, spécificationsgénéralesSpécifications détaillées fonction-nelles et techniques intégrant lescontrôles applicatifs, l'auditabilité etles contrôles de sécurité et de dispo-nibilité

AI2

Réalisation /Développement

I AR C I I

Développement, paramétrage, tests(MOE) unitaires et d'intégrationMigration/ConversionFeu vert pour mise en recettePlan Assurance Qualité

AI2

Qualification del'application :test/recette

I AR I IPlans de tests unitaires et d’intégra-tion par MOE et bilan

AI7I AR C C C CPlans de tests utilisateurs (jeux etscénarios de tests par MOA) et bilandes tests (PV de recette)

I AR R C I CMise en place d’un pilote et autori-sation pour le déploiement

Accompagnementutilisateurs /Formation

AR C I I C Plan et supports de formationAI4AI7

70

© CIGREF - IFACI

Etape clé duprocessprojet et

développement Office des

projets

Maîtrise

d’Ouvrage

Etudes /

Développements

Production /

Exploitation

Architecture

Fonctions

Support (Contrôle

Interne, Sécurité, régle-

mentaire, juridique)


Packaging, mise enproduction etdéploiement

C AR R I

Impacts sur la production identifiéset exploitabilité validéePackages prêts pour diffusion enproduction (Bons de livraison)Documents à jour (Dossiers d'exploi-tation et de configuration)Planification et feu vert pour miseen production

AI7DS1DS12

C R ARApplicatif disponible pour les utilisa-teurs

Bilan A AR C C C C

Bilan Post installationInventaire des anomalies résiduelles(levées des réserves)Plan d'actions pour les résoudre Clôture du projet

AI7

5.6.3.

Matrice risques/con

trôles du processus de projet et dévelop

pem

ent

71


© CIGREF - IFACI

Processus

N° de

réf

COBIT

Objectifs de contrôle

Risque


Bonnes pratiques

Environnement de contrôle

PO1.1

PO1.2

PO1.4

PO6.1

PO6.5

Stratégie et politique

La politique SI est décrite.

Un plan stratégique SI

moyen et long terme est

décrit. Il est en ligne avec la

stratégie Business de l'entre-

prise.

Déclinaison SI

incorrecte des

élém

ents du plan

stratégique Busi-

ness.

La politique des systèmes d’information

est communiquée.

L'alignem

ent des projets avec les objec-

tifs stratégiques SI est suivi régulière-

ment.

Des plans d'investissement SI sont

réalisés et révisés régulièrement.

La politique du système d’information doit traiter au

moins des domaines suivants (gouvernance, maîtrise

des technologies utilisées, sécurité logique et

physique du SI, exploitation informatique et conti-

nuité de service, gestion des risques, RH …). Elle peut

renvoyer vers des politiques sectorielles (comme la

politique de la sécurité des systèmes d’information).

PO6.2

PO9.1

PO9.4

Management des risques

Une cartographie des risques

SI est disponible, et est main-

tenue.

Non maîtrise des

activités SI.

Non utilisation de

la connaissance

des risques SI pour

définir la stratégie.

L'évaluation et l'acceptation des risques

SI sont menées périodiquem

ent, et s'ap-

puient sur la cartographie des risques.

Les impacts sur les activités sont évalués.

Le cadre d'évaluation des risques (m

atrice, outil de

gestion des risques …) permet d'associer à chacun

des risques des plans d'action adéquats et raisonna-

bles pour couvrir le risque, le minimiser ou le tolérer.

Des contrôles permettent de couvrir les risques iden-

tifiés dans la cartographie établie.

PO4.1

PO4.2

PO4.3

Organes de gouvernance

L'organisation autour des

projets SI garantit la bonne

gouvernance et la maîtrise

des investissements, confor-

mém

ent à la stratégie Busi-

ness de l’entreprise.

Non alignem

ent

des investisse-

ments SI avec les

objectifs Business.

Des comités d'investissements consti-

tués de toutes les parties prenantes sont

mis en place pour la gestion des investis-

sements et du pilotage des projets.

Les projets SI sont placés sous la responsabilité des

directions métiers. Elles disposent des budgets SI

pour les projets et les pilotent.

72

© CIGREF - IFACI

ProcessusN° de

réf

COBIT


Risque


Bonnes pratiques


PO8.2

PO8.3

Standards, procédures

Les référentiels de bonnes

pratiques du domaine sont

connus.

Une méthodologie de

gestion de projet et de déve-

loppem

ent informatique a

été retenue.

Les processus sont décrits et

placés sous assurance

qualité.

Non respect des

règles de bonnes

pratiques du

domaine SI.

Le managem

ent a défini et communiqué

les règles permettant de maîtriser l'envi-

ronnem

ent SI (organisation et activités).

Des comparaisons avec les pratiques communém

ent

utilisées ou déployées dans d'autres entreprises sont

réalisées.

Des normes/standards/référentiels internationaux

sont utilisés (C

OBIT/Val IT, ITIL, CMMI, ISO, eSCM …).

PO7.2

PO8.1

DS6.2

Maîtrise de l'activité

Le contrôle de gestion des

projets est opérationnel.

La séparation de fonctions

est documentée.

La gestion des compétences

est en place.

Le contrôle interne est docu-

menté.

Un système de managem

ent

de la qualité est en place.

Dérives non

contrôlées,

sécurité de l'infor-

mation et fraude,

gestion des

ressources non

efficiente.

Les investissements et charges SI sont

suivis.

Les rôles et responsabilités du personnel

SI sont formellement définis.

L'organisation des RH SI et le manage-

ment des connaissances sont correcte-

ment pilotés.

Le dispositif de contrôle interne

(contrôles généraux informatiques) est

décrit et opérationnel (activités de

contrôle identifiées et évaluées réguliè-

rement pour vérifier l'efficience).

Un processus d'assurance qualité est

clairement défini, maintenu et admi-

nistré pour toutes les activités SI.

Des indicateurs financiers pertinents sont mis en

place et permettent de comparer la performance du

SI avec d'autres entreprises comparables

(benchmark): investissem

ent SI/chiffres d'affaires par

exem

ple.

La performance des projets est mesurée suivant les 3

axes (coût, délai, qualité).

La gestion prévisionnelle des ressources humaines est

assurée. Elle permet d'anticiper les plans de forma-

tion, les recrutements de profils clés ...

73


© CIGREF - IFACI

Processus

Etapes-clésN° de

réf

COBIT


Risque


Bonnes pratiques

Cadrage des projets

Structure et processusde décision

PO5.2

PO5.3

PO5.4

PO5.5

Les décisions d’investis-

sement suivent un

processus décrit et sous

contrôle. Elles impli-

quent le bon niveau

managérial en fonction

des investissements

consentis.

Manque d’implica-

tion des comman-

ditaires, de la

direction générale

jusqu’à la fin du

projet (Sponsor)

La gouvernance de projet est en place

(comité d'investissement, comité de

pilotage qui se réunit régulièrement

avec MOA, MOE). Les comptes-rendus

et plan d’actions sont rédigés et suivis.

Des comités d'investissement SI sont créés, impli-

quant toutes les parties prenantes (direction géné-

rale, métier-BU, SI, responsable sécurité, juriste,

réglementeur, responsable fraude ...).

Le niveau hiérarchique pour l'acceptation des projets

est fonction de seuils d’investissement prédéfinis,

fonction de la taille de l'entreprise.

Portefeuille des applicationset des projets

PO1.6

PO10.1

Le patrimoine informa-

tionnel est connu et

maîtrisé.

Méconnaissance

en interne de l'en-

treprise

Dépenses SI non

sous contrôle

Mauvaise gestion

des investisse-

ments

Il existe une liste (portefeuille) des

applications en service et des projets

en cours avec une identification des

propriétaires.

La gestion de portefeuille d'applications et des

projets est centralisée. Un outil partagé (sur Intranet)

aide à maintenir à jour le portefeuille.

Des regroupem

ents d'applications/projets en

programmes sont opérés suivant des critères prédé-

finis (par processus métiers, par niveau de sensibilité

des applications).

Une cartographie de l'ensemble des applications est

disponible et tenue à jour.

74

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques

Cadrage des projets

Alignement du SI sur la stratégiede l'entreprise

PO1.2

Les décisions d’investis-

sement respectent et

soutiennent la stratégie

métier et SI.

Un consensus sur les

objectifs et

enjeux/risques des

projets est obtenu par

les parties prenantes.

Déclinaison incor-

recte du plan stra-

tégique

Les projets font l’objet de priorisation

en comité de direction sur critères

Les projets sont portés par le métier

qui les finance (identification d’un

sponsor).

Les applications les plus critiques (pour le Business, le

respect de la réglementation, la sécurité ...) sont repé-

rées.

Les applications sont classées suivant le niveau de

sensibilité des données manipulées (disponibilité,

intégrité, confidentialité) .

Le budget pour les applications et projets SI est

alloué au Business (unités d'affaires, branche métier).

La responsabilité des applications et des projets est

assumée par le Business (choix d'investissement, coût,

délai, qualité).

Etude d'opportunité et de faisabilité

AI11

AI1.2

AI1.3

AI1.4

PO10.9

Tous les projets font

l'objet d'une étude

d'opportunité avant

leur lancement.

Lancement de

projets sans valeur

ajoutée pour l'en-

treprise

Les projets font l’objet d’étude de faisa-

bilité, d’analyse de risque (y compris

sécurité), d'analyse d’impact métier et

organisationnel et d’un Business Plan.

Les projets font l'objet d'un scoring : enjeux, gains et

risques

Dans le cas de l'acquisition d'un progiciel, la sélection

est encadrée par une procédure et contrôlée (cahier

des charges, sélection, validation...)

La phase d'étude de faisabilité/opportunité ne doit

pas durer trop longtemps (6 mois pour les projets

importants). Elle doit servir à cerner les vrais besoins

métiers et leurs priorités et, à justifier le projet par un

calcul rigoureux du ROI (retour sur investissem

ent). Le

ROI est systématiquem

ent calculé et présenté en

comité d'investissement.

La décision de lancement de projet doit se faire sur la

base d'un cahier des charges précis, d'engagem

ent de

réalisation précis et d'identification des dépenses

engagées.

La qualité de l'instruction de cette étape est fonda-

mentale car elle est la base de la mise en œuvre du

projet. Des erreurs, oublis ou négligences commis

durant cette phase seront difficilement rattrapables,

ou alors avec un fort impact de coût et de délai.

L'étude de faisabilité conduit à envisager plusieurs

scénarii avec pour chacun les risques pesant sur le

projet.

75


© CIGREF - IFACI

Processus

Etapes-clésN° de

réf

COBIT


Risque


Bonnes pratiques

Conduite du changement

Analyse des impactsorganisationnels et processus

L'organisation à mettre

en place et les modes

de fonctionnem

ent

futurs sont anticipés et

opérationnels à la mise

en production de l'ap-

plication.

Sous-estimation

de l'ampleur des

changem

ents et

de leurs impacts.

Manque d'homo-

généité entre le

projet SI et les

choix organisa-

tionnels.

Mauvaise intégra-

tion du volet

social.

Les impacts organisationnels et

processus métier, notamment dans le

cas d'ERP, sont identifiés et anticipés.

La population cible est recensée et les

messages clés identifiés.

Les aspects RH sont pris en compte

(éventuellement communication au

comité d'entreprise).

Tous les impacts de la nouvelle application sont iden-

tifiés et mesurés. Les risques sont égalem

ent évalués.

Les domaines d'impact possible à analyser sont

notamment : organisation, processus, sécurité, fraude,

réglementation. Ces analyses sont réalisées et docu-

mentées avec les parties prenantes.

Formation et documentation

AI7.1

AI4.2

AI4.3

La nouvelle solution ou

les évolutions sont

appropriées par les

futurs utilisateurs.

Insatisfaction utili-

sateur

Les plans de formation des utilisateurs

sont anticipés.

Des sessions de formations sont orga-

nisées conformém

ent aux besoins de

mise à niveau des utilisateurs.

La documentation (utilisateurs, exploi-

tants, contrôle interne …) est dispo-

nible au dém

arrage de l'application.

Des plans de communication sont élaborés pour

prévenir les utilisateurs de l'arrivée d'une nouvelle

application. Ils présentent les messages clés, les

impacts identifiés, les plans de formations adaptés

aux populations recensées.

Des supports de communication sont produits.

Les formations sont adaptées aux populations

concernées. Des outils de type e-learning sont utilisés.

Dans le cadre de l'acquisition d'un progiciel, seule une

bonne maîtrise du progiciel en interne (centre de

compétences, expert métier/processus...) pourra

garantir une meilleure appropriation et une prise en

compte à moindre coût des besoins métier (par le

param

étrage).

76

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques


Soutien applicatif et métier

AI4.4

L'organisation du

soutien permettant

d'assister les utilisa-

teurs est opérationnelle

dès la mise en produc-

tion.

Soutien non

opérationnel au

lancement (dispo-

sitif d'assistance

inexistant ou

insuffisant).

Soutien débordé

Le soutien au dém

arrage de l'applica-

tion est suffisam

ment dimensionné

pour assurer le pic d'appels.

La chaîne de soutien est décrite, orga-

nisée en plusieurs niveaux, impliquant

tous les acteurs concernés (soutien

métier, soutien applicatif, soutien tech-

nique, experts)

Des scénarii d'appels au soutien sont élaborés. Ces

scripts de question/réponse sont utilisés par la Hot

Line pour identifier précisément l’objet de l’appel et

pour y répondre le plus rapidem

ent possible en l’ai-

guillant vers le bon niveau de soutien.

Des fiches consignes sont écrites pour les différents

intervenants de la chaîne de soutien.

Un soutien renforcé (task force) est mis en place en

phase post-installation (sur une durée lim

itée) pour

gérer les pics d'appels à la Hot-Line.

Exploitabilité de l'application

AI2.10

AI4.4

La capacité à exploiter

la solution est étudiée

et mesurée avec les

exploitants avant la

mise en production.

Application non

exploitable dans

de bonnes condi-

tions de perfor-

mance et de

satisfaction utilisa-

teurs.

Les critères d'exploitabilité sont prédé-

finis, notamment les exigences de sécu-

rité, les plans de

sauvegarde/restauration et niveau de

secours de l'application.

L'exploitabilité de l'application par

critère est mesurée avant sa mise en

production. Les points bloquants sont

identifiés et traités rapidem

ent.

L'exploitabilité est gérée comme un processus, initia-

lisée dès l'étude d'opportunité de l'application.

La progression, tout au long du projet, du niveau d'ex-

ploitabilité fait l'objet d'un suivi régulier au passage

de jalons du projet jusqu'à sa mise en production. Le

niveau d'exploitabilité est un des critères de mise en

production.

La disponibilité est prise en compte le plus tôt

possible dans le processus de conception.

77


© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques


Initialisation / Migration desdonnées

AI7.5

La phase de prépara-

tion / conversion /

migration des données

est anticipée, préparée

et planifiée.

Application non

opérationnelle ou

présentant des

dysfonctionne-

ments importants

liés à la qualité des

données.

La phase de conversion/migration de

données est anticipée et préparée. Elle

est gérée comme un projet.

Les principes de migration sont définis

(scénario, tables de trans-codification)

et la recette de la migration / conver-

sion est réalisée (exhaustivité et exacti-

tude des données migrées : qualité des

données).

Un plan de retour arrière après bascule

est prévu en cas de problèmes (restau-

ration des données).

Chaque nouvelle application vers laquelle des

données doivent être migrées possède sa propre stra-

tégie de migration de données et son propre plan.

La migration des données est gérée comme un sous-

projet. Il dém

arre dès l'étude d'opportunité du projet

et identifie les différents scénarii possibles (en fonc-

tion des risques).

Des tests préalables sont réalisés avant la bascule

réelle.

Gestion de projet

Organisation

PO4.6

PO4.7

PO4.8

PO4.9

PO10.3

L’organisation de

chaque projet est

décrite en impliquant

tous les acteurs.

La séparation effective

des fonctions est

assurée (Matrice de

séparation de fonc-

tion).

Responsabilités

non clairem

ent

définies.

Pilotage défec-

tueux.

Prise de décision

non contrôlée.

Manque d'implica-

tion de la direction

générale et des

commanditaires

(sponsor).

Des structures de pilotage sont en

place.

Ces instances de pilotage se réunissent

à chaque jalon majeur du développe-

ment des projets.

Elles peuvent décider de l’arrêt d’un

projet si nécessaire (le plus en amont

possible pour limiter les pertes).

Les rôles et les responsabilités

«Etudes/ Métiers / Développem

ent /

Exploitation » sont clairement définis.

La structure du projet doit être pérenne tout au long

du projet.

Une note d'organisation est réalisée et, si besoin, des

fiches de fonction sont établies.

Pour les projets importants (en investissement, à

risques, Business), le chef de projet (ou directeur de

programme) doit être rattaché au comité de direc-

tion.

Une définition claire du périmètre d'action des diffé-

rentes parties prenantes est élaborée (notamment

MOA vs MOE).

Exem

ple d'organisation de projet piloté par la

Maîtrise d'Ouvrage (MOA) :

-MOA (direction de projet), MOA déléguée (chef de

projet), assistance à MOA (support technique et

méthodologique, suivi projet, assurance qualité,

sécurité, contrôle interne, audit, communication) et

utilisateurs experts fonctionnels ;

-MOE (chef de projet), Equipe conception/réalisa-

tion, sous-traitants, équipe support (responsable

qualité, support méthodologique, sécurité, exploita-

tion, déploiement ...).

78

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques

Gestion de projet

Planification

PO10.12

Les projets font l'objet

d'une planification

initiale adaptée à leur

dimension.

Non maîtrise des

plannings.

Planning irréaliste

ou non représen-

tatif.

Fonctionnem

ent

en boîte noire

(aucune visibilité

sur l’avancement,

difficultés de réac-

tion en cas de

dérives).

Un planning initial est réalisé, revu si

nécessaire, en cours de projet.

Le projet est découpé en lots mesura-

bles pour éviter l’effet tunnel ou le

phénomène de boîte noire.

Les éventuels liens avec les projets connexes sont pris

en compte.

La montée en charge du projet (en effectif) est

maîtrisée.

La planification est réalisée à l'aide de diagramme de

Gantt et de la Méthode PERT (identification du

chem

in critique).

Suivi / pilotage

PO10.3

PO10.7

PO10.4

PO10.6

PO10.9

PO10.10

PO10.13

PO10.14

DS6.2

L'avancement du projet

est suivi régulièrement

(risques, charges

initiales, charges

consommées, reste à

faire, délais, qualité).

Non maîtrise du

projet.

Dérive non

contrôlée.

Des indicateurs de suivi de projet perti-

nents sont définis

Des points réguliers sont réalisés avec


Tout dépassement de budget fait

l’objet d’une alerte au managem

ent

(avec justification de l’écart).

Le comité de pilotage s'assure du respect des

budgets et de l'alignem

ent avec la stratégie. Il se

réunit régulièrement, les décisions y sont entérinées

et des comptes-rendus sont rédigés. Les risques du

projet sont suivis.

Un reporting des projets est assuré via des tableaux

de bord intégrant des indicateurs de performance

des projets (KPI). Il remonte jusqu’à la direction géné-

rale.

Les coûts complets (y compris coût de personnel

interne et externe) font l’objet d’un suivi régulier.

Un bilan de projet est systém

atiquem

ent réalisé après

déploiement.

Une communication régulière sur l'avancement du

projet, ses enjeux, est primordiale pour conserver la

mobilisation de tous les acteurs.

79


© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques

Gestion de projet

Méthode et outils

PO8.3

PO8.2

Tous les projets suivent

le mêm

e cadre métho-

dologique de conduite

de projet.

Méthode de travail

ne permettant pas

de garder la

maîtrise du dérou-

lement du projet.

Absence de cadre

méthodologique

de conduite de

projet.

Coûts sous-

estimés ou incom-

plets.

Une méthodologie de développem

ent

de projet est définie et suivie.

Cycle de vie des projets.

Des étapes de validation jalonnent le

projet = points de contrôle (jalons de

validation : lancement, tests, recette).

Des outils de planification et de suivi sont utilisés

pour faciliter les contrôles, et ils sont partagés.

Des comités de validation sont mis en place (investis-

sement, architecture technique, architecture fonction-

nelle, déploiement …).

Le jalon marque un événem

ent sensible de la réalisa-

tion du projet nécessitant un contrôle. Chaque jalon

permet de vérifier que les conditions nécessaires à la

poursuite du projet sont réunies. Les jalons sur le

projet sont prédéfinis et planifiés (échéancier) cf

plan

ification

du projet.

Des revues de codes peuvent être planifiées.

Appel à la sous-traitance

AI5.2

AI5.3

AI5.4

Les besoins en sous-

traitance sont identi-

fiés, justifiés et validés.

Coûts non justifiés

et non maîtrisés.

Dépassement

budgétaire.

Contractualisation

avec les presta-

taires externes

présentant des

points faibles ou

des lacunes.

Non respect de la

loi relative à la

sous-traitance

(n°75-1334 du

31/12/1975).

Absence d'enga-

gem

ent liant les

parties, dépen-

dance vis-à-vis des

prestataires.

Confidentialité et

propriété intellec-

tuelle non prises

en compte.

L’appel à la sous-traitance fait l'objet

d'une dem

ande justifiée par le chef de

projet (ressources insuffisantes, coûts

inférieurs, compétences particulières...).

Il est encadré par un appel d’offres

(sélection) sur la base d'un cahier des

charges validé. A l’issue de la sélection,

un contrat avec engagem

ent de

services (m

oyens/résultats) et clause de

confidentialité/auditabilité/droits de

propriétés est signé.

Les fournisseurs font l’objet de

contrôles en cours de missions et

d’évaluation à l’issue de la prestation.

Les tâches confiées à la sous-traitance sont clairement

définies et le cham

p d'action finem

ent délimité.

L'activité confiée à la sous-traitance ne devra pas

entraîner une dépendance forte en termes de compé-

tences et de technologie.

Se conformer aux exigences réglementaires, notam-

ment la loi n°75-1334 du 31 décem

bre 1975 relative à

la sous-traitance (version consolidée au 1erjanvier

2006).

Un transfert de compétences et de technologie doit

être prévu dès le départ du contrat (surtout dans le

cas d'acquisition de progiciel).

80

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques

Gestion de projet

Audit et contrôle

SE1.4

SE2.5

PO8.6

Des audits internes

sont prévus sur les

projets

majeurs/critiques

(évaluation de la

performance).

Le contrôle qualité est

en place et assuré tout

au long du projet.

Non atteinte des

objectifs initiaux

des projets.

Non-conformité

aux règles et stan-

dards du domaine,

de l'entreprise.

Des audits de projets sont systém

ati-

quem

ent planifiés pour les projets

majeurs (investissem

ent > à xk€, durée

> à 1 an …) ou à hauts risques (sécurité

par exemple).

Des revues qualité sont menées aux

jalons des projets.

Une évaluation de la sensibilité est menée durant les

premières phases du développem

ent.

Les aspects sécurité des données et contrôle interne

de la future application sont évalués lors de la

conception, de manière à y intégrer les concepts de

sécurité le plus tôt possible

(Idem

pour la sécurité logique, gestion des habilita-

tions dans l'application conformém

ent à la matrice de

séparation des tâches).

Des audits peuvent être menés avant le passage de

jalons ou en cas de crise.

81


© CIGREF - IFACI

Processus

Etapes-clésN° de

réf

COBIT


Risque


Bonnes pratiques

Gestion de projet

Bilan

AI7.9

Un bilan de mise en

œuvre est réalisé tel

que défini dans le plan

de mise en œuvre.

Le retour sur inves-

tissem

ents ne

répond pas aux

attentes du mana-

gem

ent.

Incapacité d'iden-

tifier que les

systèm

es ne

répondent pas aux

besoins des utilisa-

teurs finaux.

Mettre en place une procédure de bilan

de projet.

Utiliser des indicateurs d'évaluation de

projet.

Faire participer les responsables des

processus métiers, informatiques tech-

niques et de contrôle interne ou de

gestion des risques.

Etablir un plan d'action pour traiter les

problèmes identifiés.

Mettre en place une procédure de bilan de projet,

pour identifier, évaluer et rapporter dans quelles

mesures :

•les besoins ont été couverts ;

•les avantages attendus ont été obtenus ;

•le système est considéré utilisable ;

•les attentes des intervenants internes et externes

sont satisfaites ;

•des impacts inattendus sur l'organisation ont eu

lieu ;

•les principaux risques ont été jugulés ;

•la gestion du changem

ent, d'installation et de

processus d'accréditation a été effectué de manière

efficace et efficiente.

Consulter les responsables métier et informatiques

pour définir des indicateurs de succès, réalisation des

exigences et bénéfices obtenus.

Le formulaire de bilan fait partie du processus de

gestion du changem

ent. Faire participer les proprié-

taires des processus métiers ou parties tiers, le cas

échéant.

Exam

iner égalem

ent les exigences hors métier ou DSI

(par exemple, l'audit interne, la gestion des risques de

l'entreprise, la conformité réglementaire).

Etablir un plan d'action pour traiter les problèmes

restants, identifiés durant le projet. Faire participer les

responsables métier et informatiques dans son élabo-

ration.

82

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques

Conception et Développement (Fabrication)

Spécifications fonctionnelles et détaillées

AI2.1

AI2.2

AI2.3

AI2.4

AI2.5

AI2.9

Les besoins sont

exprimés et validés par

le métier (Business

Unit, sponsor, utilisa-

teurs…).

La mise en place des

contrôles applicatifs

automatisés (embar-

qués dans l'application)

et des contrôles opéra-

tionnels manuels sur

les processus métier est

anticipée (en lien avec

les risques).

Etude des besoins

incomplète et non

validée.

Non-conformité

des spécifications

aux besoins des

utilisateurs.

Manque d'homo-

généité entre le

projet SI et les

choix organisa-

tionnels.

Erreurs de traite-

ments non détec-

tées.

Les besoins sont exprimés par le métier

et les autres parties prenantes (par ex. :

sécurité, juridique). Un cahier des

charges (ou spécifications générales)

est rédigé et validé.

La sécurité est prise en compte dans les

développem

ents (sensibilité de l’appli-

cation, gestion des habilitations, niveau

de protection des données manipu-

lées).

Les spécifications détaillées sont rédi-

gées et validées (modèle de données,

de traitements…). Elles respectent les

spécifications générales. Les différences

sont tracées et validées par le Business.

Les besoins identifiés a posteriori sont

validés et planifiés avant prise en

compte. Les dem

andes de changem

ent

en cours de projet font l'objet d'estima-

tion (coûts, risques, impacts) et sont

validées par la MOA.

Les contrôles associés à l'application

(sur les données d'entrée/sortie, traite-

ments) sont décrits et maintenus sous

la responsabilité de la Maîtrise d'Ou-

vrage (MOA).

Ces contrôles font l'objet de

tests/recettes spécifiques.

Des utilisateurs clés sont identifiés et désignés. Ils

peuvent constituer un groupe utilisateur qui sera

consulté lors de la conception et de la validation fonc-

tionnelle.

L'engagem

ent ferme des directions métiers (Busi-

ness) directement impliquées est indispensable pour

arbitrer les choix fonctionnels et pour obtenir l'adap-

tation des processus et de l'organisation (surtout

dans le cadre de l'acquisition d'un progiciel).

Dans le cadre de l'acquisition d'un progiciel, les déve-

loppem

ents spécifiques doivent être limités. Il faut

utiliser au maximum le param

étrage proposé par

défaut. Au besoin adapter les processus métiers

(analyse d'impact préalable).

Un représentant sécurité est impliqué dans la concep-

tion.

Un gestionnaire (administrateur) de données est

nommé. Il administre les données au niveau de l'en-

treprise pour éviter les redondances d'information et

le niveau de sécurité exigé sur les données (contrôle

d'accès).

Les auditeurs et les contrôleurs internes sont impli-

qués dans la mise en place des contrôles applicatifs.

Les exigences de contrôle interne et de sécurité

incluent des contrôles applicatifs qui garantissent

l'exactitude, la complétude, l'opportunité et l'autorisa-

tion des entrées et sorties.

Dans le cadre d'ERP, le param

étrage des contrôles

prédéfinis dans le progiciel fait l'objet de validation

par les responsables de processus.

83


© CIGREF - IFACI

Processus

Etapes-clésN° de

réf

COBIT


Risque


Bonnes pratiques


Réalisation / Développement

AI2.7

AI2.8

La solution développée

respecte les spécifica-

tions fonctionnelles. Sa

maintenance et son

évolution doivent être

possibles.

Non maintien de la

solution

Les développem

ents respectent les

règles, normes et standards retenus par

l’entreprise.

Tous les objets développés sont gérés

en configuration (typologie, règle de

dénomination, versionnage …).

Chaque élém

ent développé

(programme/module logiciel) est iden-

tifié de manière unique. Toute modifi-

cation est enregistrée et tracée.

Des outils de modélisation (données, traitements,

objets) sont décrits.

Les normes d'écriture des programmes sources sont

décrites et respectent les bonnes pratiques en ce

domaine (indentation permettant une mise en forme

et une am

élioration de la lisibilité des programmes,

commentaires …).

Des revues de codes sources sont planifiées.

Les contrôles applicatifs importants embarqués dans

l'application sont repérés de façon claire dans le code

source.

Maquettage / Prototype

L'intérêt de la solu-

tion/application et sa

faisabilité sont vérifiés

avant de lancer la réali-

sation.

Développem

ent

engagé sans vérifi-

cation du concept

initial

Une maquette (ou prototype) est

réalisée pour valider les points fonc-

tionnels en suspens, l’ergonomie /

simplicité, et pour confirmer l’intérêt de

la solution (valeur ajoutée).

Les critères initiaux sont vérifiés avec les utilisateurs

très en amont pour valider le concept avant de

commencer la phase de conception/réalisation. Une

grande réactivité est dem

andée par tous les interve-

nants sur la phase de maquettage.

Le maquettage/prototype permet en particulier de

lever les incertitudes liées à la conception des SI, en

facilitant la dém

arche de planification qui précède la

conception et la réalisation. Cette maquette doit

pouvoir refléter les besoins des clients et donc doit

être testée et avalisée par ces derniers.

84

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques


Architecture technique et logicielle

AI2.4

Les développem

ents

s'intègrent dans l'archi-

tecture technique et

logicielle prédéfinie par

l'entreprise.

Non-conformité

aux préconisa-

tions.

Choix technolo-

giques non validés

voire erronés

et/ou non cohé-

rents avec le patri-

moine existant.

Mauvais dimen-

sionnem

ent des

architectures.

Mauvaise intégra-

tion dans le SI exis-

tant (interface).

L’architecture technique retenue pour

la solution est validée. Les choix tech-

niques sont validés. Ils respectent des

technologies validées par la DSI

(notamment en termes de sécurité).

Des comités de validation des architectures tech-

niques sont organisés. Tous les projets passent en

comités de validation pour valider les options tech-

niques prises. Des comptes rendus sont rédigés.

Les choix techniques et fonctionnels reposent sur des

solutions éprouvées et reconnues par l'entreprise. Il

existe un catalogue des solutions techniques propo-

sées par la DSI.

Les environnem

ents de tests et de production sont

préparés.

Qualification de l'application : tests/recettes

Tests d'intégration

AI7.4

Les tests techniques

(unitaires/intégration)

sont réalisés avant la

validation fonction-

nelle.

Les tests de non régres-

sion avec l'environne-

ment SI (applications

dépendantes) sont

effectués.

Tests techniques

insuffisants.

Un bilan de qualification est réalisé à

l’issue des développem

ents sur la base

de fiches de tests. Des comptes-rendus

sont rédigés.

Les tests techniques sont réalisés par la

MOE.

Les environnem

ents de test doivent être séparés des

environnem

ents de production pour des raisons de

sécurité.

Si possible, les bases de tests ne doivent pas

comporter de données réelles en production surtout

si les données, manipulées par l'application, sont

sensibles (données personnelles, données financières

et commerciales...).

En cas de nécessité liée aux tests, l'utilisation de

données réelles devra être justifiée et validée par la

MOA.

Des contrôles complémentaires (organisationnels,

procédures, techniques...) devront être mis en place

pour garantir la sécurité de l'information.

85


© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques

Qualification de l'application : tests/recettes

Recette fonctionnelle parles utilisateurs

AI7.2

La solution est

acceptée par les

métiers et un feu vert

pour la mise en produc-

tion est donné.

Recette fonction-

nelle non réalisée

par les utilisateurs

(MOA, Business).

Des cahiers de tests fonctionnels,

validés par la MOA, sont établis et

servent de support à la recette.

Une recette finale est réalisée avec les

utilisateurs et autres parties prenantes

(sécurité, juriste...) sur la base de

scénarii de tests et de fiches de tests.

La recette fait l'objet d'une description détaillée. Ce

dossier de contrôle est réalisé au plus tard à l'issue de

la phase de conception.

La recette est ensuite réalisée conformém

ent au

dossier de contrôle fourni par la MOA.

A l'issue de la recette, un Procès Verbal de Recette est

signé par la MOA et la MOE. Les réserves sont identi-

fiées et classifiées (bloquantes, non bloquantes). Les

plans d'action sont formalisés et suivis pour lever les

réserves au plus tôt.

Mise en place pilote

AI7.7

Une mise en place

pilote peut être néces-

saire avant généralisa-

tion de la solution pour

valider les points fonc-

tionnels et techniques

en suspens.

Non validation en

grandeur nature

sur une échelle

réduite avant mise

en production.

Une phase pilote est organisée pour la

vérification en situation réelle. Les

attentes et objectifs de la phase pilote

sont exprimés par les parties

prenantes. Les points en suspens sont

vérifiés. Toutes les réserves sont levées.

Le niveau de satisfaction des utilisa-

teurs est mesuré à l'issue de la phase

pilote. L'appropriation de la solution

par les utilisateurs est mesurée.

Une réunion de validation finale est

organisée par le sponsor avec toutes

les parties prenantes. Un « Go / No Go »

est prononcé par le sponsor au vu des

résultats des tests et des risques rési-

duels. La décision est tracée dans un

compte-rendu.

Un feu vert pour le déploiement est

donné par la MOA après accord de

toutes les parties prenantes (sécurité,

juriste, conformité).

Un bilan de Mise en Place Pilote (M

PP) est réalisé avec

les utilisateurs. Ils mentionnent des réserves identi-

fiées.

La MPP permet de tester la solution dans sa dimen-

sion technique. Elle permet égalem

ent de préparer le

déploiement, de mieux en apprécier la charge et d'en

identifier les difficultés a priori.

La MPP fait l'objet d'un plan de communication et de

formation à destination des premiers utilisateurs de la

nouvelle solution.

Les objectifs de la MPP sont identifiés et présentés

aux utilisateurs et un bilan est réalisé à la fin.

86

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques

Mise en production / exploitation

Gestion des livraisons

AI7.4

AI7.8

Les livraisons pour m

ise

en production sont

identifiées.

Un retour arrière à la

situation précédente

est toujours possible.

Non maîtrise des

versions installées.Les livraisons font l’objet de PV de

livraison à destination des exploitants.

Le détail des livraisons (composants logiciels) est

indiqué dans un bon de livraison à destination des

exploitants qui devront installer la nouvelle version.

L'identification des composants logiciels est impor-

tante car elle doit garantir qu'aucune modification du

logiciel n'est intervenue depuis la recette.

L'installation respecte les procédures de mise en

exploitation.

Procédures d'exploitation

AI7.4

AI7.8

DS11.5

Les procédures d'ex-

ploitation, notamment

sauvegardes/restaura-

tion, sont opération-

nelles. Elles sont

décrites dans des

procédures et mainte-

nues.

Continuité de

service non

assurée.

Toutes les procédures d'exploitation

font l'objet de fiches accessibles et lisi-

bles.

Ces procédures sont intégrées au manuel d'exploita-

tion, livré avec l'application par le prestataire qui a

réalisé l'application, adaptées éventuellement par

l'équipe d'exploitation.

Elles couvrent notamment la gestion de la sécurité

(sauvegarde, restauration, plan de secours...), archi-

vage, administration et surveillance de l'exploitation,

la qualité de service et l'assistance en cas de panne

(Cf. processus d’infogérance page 130).

87


© CIGREF - IFACI

Processus

Etapes-clésN° de

réf

COBIT


Risque


Bonnes pratiques


Engagement sur le niveau de serviceattendu

DS1.1

DS1.3

DS1.4

Le niveau de service

attendu est exprimé

par le sponsor et fait

l'objet de contrat enga-

geant les parties

(contrat de service ou

SLA : Service Level A

gree-

men

t).

Service rendu aux

utilisateurs non

conforme aux

exigences des

utilisateurs

(performances par

exem

ple).

Chaque application dispose d'un

contrat de service (interne ou externe)

qui définit les exigences de fonctionne-

ment du SI (disponibilité, performance,

KPI...).

Le contrat passé entre un fournisseur et une entre-

prise permet de sécuriser et fiabiliser les niveaux de

service, que l'entreprise considère comme cruciaux de

maintenir ou d'acquérir, pour répondre à ses objectifs

métier (non seulement des engagem

ents de disponi-

bilité du service mais égalem

ent l'assurance de l'adé-

quation du niveau de service fourni aux enjeux

stratégiques de l'entreprise et de ses métiers).

Les objectifs (en termes de performance, de disponi-

bilité par exemple) sont explicités et des indicateurs

permettent de suivre l'atteinte des objectifs. Des

pénalités doivent être définies en cas de non respect

des engagem

ents.

Des tableaux de bord sont réalisés mensuellement.

Levée des réserves

Les réserves identifiées

à l'issue de la recette

font l'objet d'un suivi

après déploiement en

vue de leur levée.

Dysfonctionne-

ments non réglés.

Un suivi rapproché en phase de post-

déploiement est en place pour lever les

points restant en suspens.

Une revue post-installation est réalisée pour s'assurer

que les points en suspens et les réserves sont levés.

La revue peut égalem

ent servir à capitaliser sur l'ex-

périence acquise pour en faire profiter les projets à

venir.

88

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques


Achats des ressources informatiques

DS12.1

Les achats de

ressources informa-

tiques sont anticipés.

L'arrivée des ressources

informatiques dans les

salles serveurs est

préparée (notamment

en termes d'environne-

ment technique, m²

disponibles, plan de

secours...).

Non anticipation

des besoins en

matériel.

Mauvaise gestion

des actifs.

L'arrivée des ressources informatiques

dans les salles serveurs est préparée

(notamment en termes d'environne-

ment technique).

Les achats en matériel informatique sont anticipés et

intégrés aux investissements de départ.

Les nouveaux biens sont répertoriés (actifs).

Les achats suivent le processus "achat" de l'entreprise.

Il existe une base de données répertoriant tous les

serveurs et autres matériels informatiques, ainsi que

leur localisation (salles serveurs). Des comités d'im-

plantation de serveurs peuvent être mis en place

pour décider du lieu d'installation en fonction de

critères prédéfinis.

5.7. Maintenance et gestion des changements

Le patrimoine applicatif d’une entreprise ou d’une administration représente un capital considéra-ble d’intelligence et de connaissance qui a coûté des milliers d’hommes.an, et il joue un rôleunique dans le fonctionnement opérationnel. Pour maintenir ces milliers d’applications et ces mil-lions de données, il manque souvent la discipline en matière de documentation et de normes.

Or, les principaux risques du processus de maintenance applicative sont :• les surcoûts liés à une insuffisance de planification ;• la régression fonctionnelle ou dégradation de la disponibilité des systèmes, à la suite de

changements incontrôlés ou non autorisés ;• les décalages entre les besoins et les fonctionnalités mises en œuvre.

La maîtrise de ces risques repose sur les points suivants, qui constituent des meilleures pratiques :1. Développer une stratégie de maintenance des applications : train de modifications, comité

d’entrée de charge, comité de priorisation.2. Formaliser et mettre en place une méthodologie et des procédures standardisées de gestion des

changements, applicatifs et techniques, incluant également les conditions des changementsurgents :• les rôles et responsabilités sont clairement répartis entre maîtrise d’ouvrage, études, archi-

tecture, sécurité, et exploitation ;• ces profils différents sont marqués dans les outils d'administration des habilitations, dont le

processus est global, indépendant, transparent et auditable ;• les critères de priorisation des changements, s'appuyant sur une approche par les risques ;• les étapes successives et les livrables associés (analyse d'impact, dossier d'exploitation, dos-

sier d'exploitabilité),• la procédure spécifique de gestion des changements urgents.

3. Mettre en place une séparation effective des tâches entre les « études » qui développent et tes-tent, et la « production » qui exploite, ainsi que les moyens nécessaires :• les environnements de développement, de tests, et de production sont distincts ;• les contrôles d'accès à ces environnements sont conformes aux exigences de séparation des

tâches.

89


© CIGREF - IFACI

5.7.1. Flowchart du processus de maintenance et gestion du changement

90

© CIGREF - IFACI

Maîtrise d'OuvrageÉtudes

DéveloppementsProduction Exploitation

ArchitectureContrôleInterne

Arbitrage

Légende

Activité

Décision

Documents / Données

Renvoi

Flux

Pilo

tag

e d

u c

han

gem

ent

Enre

gis

trem

ent,

Qu

alifi

cati

on

, Arb

itra

ge

Plan

de

mis

e en

œu

vre

EnregistrementQualification

Étude faisabilité

Propositionsur faisabilité

Clôture de lademande

Procédure exceptionnelle

d'urgence

Analyses plus fines,négociations

UrgenceRefusAccepté

Demande,expressionde besoin

Plan de miseen œuvre

métier


développement

Plan de miseen œuvretechnique

A

B

91


© CIGREF - IFACI




Acq

uis

itio

n e

t m

ise

en œ

uvr

eco

mm

un

es a

ux

pro

cess

us

« Pr

oje

t et

dév

elo

pp

emen

t »

& «

Mai

nte

nan

ce e

t g

esti

on

du

ch

ang

emen

t »

Spéc

ifica

tio

ns

Prép

arat

ion

des

pla

ns

de

test

s et

des

env

iro

nn

emen

ts

Spécifications fonctionnelles et techniques intégrant :contrôles applicatifs, auditabilité, sécurité et disponibilité des applications

Spécificationsfonctionnelles

validées

Spécificationstechniques

validées

Préparation des plans,scénarii et jeux de tests

utilisateurs et développeurs

Préparation des environnements


métier


développement

A

B

B

C D

92

© CIGREF - IFACI




Légende

Activité

Décision


Renvoi

Flux

Acq

uis

itio

n e

t m

ise

en œ

uvr

e co

mm

un

es a

ux

pro

cess

us

« Pr

oje

t et

dév

elo

pp

emen

t »

& «

Mai

nte

nan

ce e

t g

esti

on

du

ch

ang

emen

t »

Para

mét

rag

es, D

ével

op

pem

ent

et T

ests

Acc

om

pag

nem

ent

form

atio

n

Composant à mettre en production

Dossier d'exploitationDossier de demande de

changement

Mise à jour rétroactivede la documentation et

du référentiel

Préparation miseen production

Développement, Paramétrage, Test(Tests Unitaires-Tests d'Intégration)

FormationUtilisateurs

Potentiellement en modedégradé dans le traitementd'une demande "urgente"

Nouvelle versionapplication

en production

Bilan, clôture, demande, passage en mode maintenance

PV de recette

Composants àtester par lesutilisateursdisponibles

Tests utilisateurs(recette)

Feu vert pourmise en production

Packaging,Mise en production,

Déploiement

Approbationrecette

Non

Oui

BC D

Nouvelle versionapplication

en production

5.7.2. RACI du processus de maintenance et gestion du changement

93


© CIGREF - IFACI

Etapes clés

Maîtrise

d’ouvrage

Etudes /

Développements

Production

Exploitation

Architecture

Contrôle

interne


Enregistrement,qualification etarbitrage desdemandes

I R C C CProcédures et standards de gestiondes changements

AI2.9

R Expression de besoin AI2.9

I R I I I Reporting de suivi des changements AI6.4

AR AR C C C Etude préalable et/ou d'opportunitéAI2.6AI6.2AI6.3

AR AR I I I

Compte-rendu d'arbitrage ducomité en charge de la maintenancede l'application ou du systèmePlanification souhaitée

AI6.2

Plan de mise enœuvre

C AR C I IPlan de mise en œuvre avec planifi-cation négociée entre MOA et MOE

AI7.3

Spécifications AR AR A C C

Cahier des charges, spécificationsgénéralesSpécifications fonctionnelles ettechniques intégrant les contrôlesapplicatifs, l'auditabilité et lescontrôles de sécurité et de disponi-bilité

AI2.1AI2.2

Préparation desplans de tests etdes environne-

ments

I AR I C C Plans de tests unitaires par MOE AI7.2

AR AR C I IPlans de tests utilisateurs (jeux et scénarii de tests par MOA)

AI7.2

C AR AR I IEnvironnements de développe-ment, test et recette, disponibles

AI7.4

Réalisation I AR R I I

Développement, paramétrage, tests(MOE) unitaires et d’intégrationFeu vert pour mise en recettePlan assurance qualité

AI2.5AI2.7AI2.8

Recette

A R R I IValidation de l’environnement derecette par les utilisateurs

AI7.4

AR R I I IConservation des résultats des testsPV de recette

AI7.6AI7.7

Accompagnementutilisateurs /Formation

R C Plan et supports de formation AI7.1

94

© CIGREF - IFACI

Etapes clés

Maîtrise

d’ouvrage

Etudes /

Développements

Production

Exploitation

Architecture

Contrôle

interne


Lotissement, miseen production etdéploiement

C AR AR I I

Impacts sur la production identifiéset exploitabilité validéePackages prêts pour diffusion enproductionDocuments à jour (Dossiers d’ex-ploitation et de configuration)Planification et feu vert pour miseen production

AI7.8

I R AR I IApplicatif disponible pour les utilisa-teurs

AI7.8

Bilan AR AR C C CInventaire des anomalies résiduellesPlan d'action pour les résoudreDemande de changement clôturée

AI7.9

95


© CIGREF - IFACI

Processus

N° de

réf

COBIT


Risque


Bonnes pratiques


AI2.10

Maintenance des applica-

tions

Développer un plan straté-

gique de maintenance des

applications.

Surcoût lié à un

manque de planifi-

cation.

Ecart entre la mise

en œuvre et la

dem

ande d'évolu-

tion.

Définir un processus efficace et efficient

des activités de maintenance des appli-

cations.

Surveiller régulièrement l'activité de

maintenance et notamment les change-

ments urgents.

Maîtriser le volume d'activités de la

maintenance.

Le processus de maintenance doit intégrer :

•une gestion des priorités ;

•les besoins métier en tenant compte des ressources

disponibles ;

•un logigramme formalisé ;

•une analyse des risques pour évaluer les impacts de

maintenance sur les systèmes et infrastructures

existants, les interdépendances entre les systèm

eset les exigences de sécurité.

Pour faciliter la surveillance et la gestion de la mainte-

nance :

•regrouper les changem

ents par lots ;

•considérer toute maintenance conséquente

comme un projet de développem

ent.

Faire une revue de tous les changem

ents urgents qui

n'adhèrent pas au processus formalisé de gestion des

changem

ents.

Analyser régulièrement le modèle de maintenance

retenu et le volume d'activités associé pour y déceler

des tendances anormales qui indiqueraient des

problèmes sous-jacents de qualité et de performance.

Suivre les activités de maintenance, contrôler qu'elles

ont bien été réalisées avec succès et vérifier, si néces-

saire, que la documentation fonctionnelle ou tech-

nique a bien été mise à jour.

5.7.3.

Matrice risques/con

trôles du processus de maintenan

ce et ge

stion des chan

gemen

ts (ap

plicatifs et techniques)

96

© CIGREF - IFACI

ProcessusN° de

réf

COBIT


Risque


Bonnes pratiques


AI6.1

Standards et procédures

de gestion des change-

ments techniques et appli-

catifs

Formaliser et mettre en place

des procédures de gestion

des changem

ents permet-

tant une gestion standar-

disée des dem

andes de

changem

ents pour les appli-

cations, les systèm

es sous-

jacents, les infrastructures, les

procédures et les processus.

Prendre en compte les chan-

gem

ents urgents.

Changem

ents

incontrôlés ou non

autorisés.

Fonctionnalités et

disponibilité des

systèm

es dégra-

dées.

Ecarts entre les

besoins et les

fonctionnalités

mises en œuvre.

Disposer d'une méthodologie de

gestion projet de développem

ent et de

maintenance (SDLC), incluant les chan-

gem

ents urgents.

Diffuser les procédures et promouvoir

leur utilisation.

Se donner les moyens de contrôler leur

mise en application.

Cette méthodologie doit inclure :

•les rôles et responsabilités ;

•les critères de classification (techniques, applicatifs)

et de priorisation des changem

ents en s'appuyant

sur une approche des risques ;

•les étapes successives et les livrables associés

(analyse d'impact, dossier d'exploitation, dossier

d'exploitabilité...) ;

•la gestion des changem

ents urgents ;

•les moyens de lier les changem

ents aux objets

modifiés, recettés et mis en production (techniques

et applicatifs).

Intégrer l'impact lié à la sous-traitance dans le

processus de gestion des changem

ents, notamment

les aspects contractuels et le respect des contraintes

de conformité légales ou juridiques (CNIL, CFCI).

PO4.11

Séparation des tâches

entre études et production

Mettre en place une sépara-

tion des tâches effective

entre ceux qui développent,

testent et exploitent pour

assurer une distribution

correcte des changem

ents.

Changem

ents

incontrôlés ou non

autorisés.

Disponibilité

dégradée des

systèm

es.

Augmentation du

nombre de chan-

gem

ents en

production.

Disposer d'une organisation assurant

clairement la répartition des rôles et

responsabilités entre études, architec-

ture, sécurité, production et MOA pour

l'ensemble du périmètre (technique et

applicatif).

Disposer d'un environnem

ent de développem

ent de

tests et de production distincts, et mettre en place

des contrôles d'accès à ces environnem

ents

conformes aux exigences de séparation des tâches.

Mettre en place un processus qui permette le

contrôle des validations des dem

andes d'accès par les

responsables.

97


© CIGREF - IFACI

Processus

Etapes-clésN° de

réf

COBIT


Risque


Bonnes pratiques

Pilotage du changement

Enregistrement, qualification, arbitrage

AI2.9

Gestion des

demandes pour les

évolutions applica-

tives

Assurer le suivi des

dem

andes d'évolutions

applicatives depuis la

conception, la réalisa-

tion et la mise en

œuvre en s'appuyant

sur un processus d'ap-

probation bien établi.

Ecart entre les

attentes et la mise

en œuvre.

Mauvaise prise en

compte des

dem

andes.

Dem

andes appli-

quées à un

mauvais système.

Disposer d'un cadre de procédures et

de standards pour encadrer la gestion

des dem

andes de changem

ents (récep-

tion, enregistrem

ent et approbation).

Les diffuser et promouvoir leur utilisa-

tion.

Faire un suivi des dem

andes et donner

une visibilité claire de leur état à toutes


Les procédures doivent définir les rôles et les attentes

des différents acteurs.

Les règles de priorisation des dem

andes doivent être

définies afin de partager un socle d'analyse avec les

clients de la DSI.

Un outil de gestion des dem

andes permet de tracer

toutes les dem

andes (rejetées, en cours, acceptées,

terminées).

Il permet égalem

ent de contrôler la mise en place des

dem

andes selon la planification prévue.

AI6.4

Gestion et suivi des

changements tech-

niques et applicatifs

Mettre en place un

systèm

e de suivi et de

reporting pour assurer

le pilotage de la

gestion des change-

ments (applicatifs et

techniques).

Changem

ents non

traçables.

Ressources

allouées insuffi-

santes.

Disposer d'un outil de suivi de l'en-

semble des changem

ents permettant

de soutenir le processus de gestion des

changem

ents.

Se donner les moyens de contrôler son

utilisation.

Cet outil doit permettre :

•de renseigner des informations de la dem

ande

telles que la criticité, la charge et le planning ;

•de suivre le statut des changem

ents (rejetés,

acceptés, en cours, validés et déployés) ;

•d’avoir une traçabilité des étapes de validation des

changem

ents par les différents intervenants ;

•de prendre en compte les changem

ents urgents.

98

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques



AI6.2

Evaluation des

impacts, priorisation,

autorisation

Déclarer toutes les

dem

andes de change-

ment via un processus

structuré permettant

de déterminer l’impact

sur les systèmes opéra-

tionnels et sur leurs

fonctionnalités.

S’assurer que les chan-

gem

ents sont systém

a-tiquem

ent catégorisés,

priorisés, et acceptés.

Effets de bord non

désirés.

Impacts négatifs

sur la capacité et la

performance des

infrastructures

techniques.

Absence de

gestion des prio-

rités entre les

changem

ents.

Développer un processus permettant à

la MOA et la DSI d'émettre des

dem

andes de changem

ent sur les

infrastructures, systèm

es et applica-

tions. Tous les changem

ents passent

par ce processus.

Evaluer toutes les dem

andes de façon

structurée :

•associer les changem

ents à des caté-

gories et donner des priorités ;

•effectuer une analyse d'impact systé-

matique.

Impliquer la MOA et la DSI dans cette

évaluation.

Chaque dem

ande de changem

ent est

formellement approuvée par la MOA et

la DSI.

Le processus de gestion des changem

ents doit inté-

grer aussi bien les besoins fonctionnels que tech-

niques. Les catégories de changem

ents peuvent être

de type infrastructure, système d’exploitation, réseau,

applications, progiciels.

L’analyse d'impact de ces changem

ents doit porter

sur :

•l'infrastructure, les systèmes et les applications ;

•les contraintes contractuelles, légales ou vis à vis

des autorités de tutelle ;

•les interdépendances avec d'autres dem

andes de

changem

ents.

AI6.3

Changements urgents

Mettre en place un

processus pour définir,

développer, tester,

documenter, déclarer,

autoriser, les change-

ments urgents, pour

lesquels on ne peut pas

appliquer les processus

de changem

ents

normaux.

Incapacité à

répondre efficace-

ment aux besoins

de changem

ents

urgents.

Autorisations

d'accès excep-

tionnel non

supprimées après

le changem

ent.

Génération de

changem

ents non

autorisés, suite à

l'altération de la

sécurité et aux

accès non auto-

risés aux données

d'entreprise.

La gestion des changem

ents urgents

est documentée et intégrée au

processus global de gestion des chan-

gem

ents.

Tout changem

ent urgent est déclaré,

évalué et enregistré dans la base de

gestion des changem

ents.

Toutes les ouvertures nécessaires au

changem

ent urgent sont autorisées,

documentées, puis supprimées après la

réalisation du changem

ent.

Faire un bilan des changem

ents

urgents en impliquant toutes les

parties concernées.

Le bilan des changem

ents urgents, doit permettre

d'apporter une évaluation sur l’efficacité :

•de la gestion de la maintenance des systèmes et

des applications par la DSI ;

•du développem

ent et des environnem

ents de

tests;

•de la qualité des développem

ents ;

•de la documentation et les manuels ;

•de l'intégrité des données.

99


© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques



AI2.6

Mises à jour majeures

des systèmes exis-

tants ou simple évolu-

tion ?

Si l'évolution

dem

andée représente

un changem

ent signifi-

catif par rapport aux

fonctionnalités du

systèm

e existant, il faut

alors utiliser le mêm

eprocessus que celui

utilisé pour le dévelop-

pem

ent d'un nouveau

systèm

e.

Absence de

maîtrise des coûts

pour les grosses

évolutions.

Altération de la

confidentialité, de

l'intégrité et de la

fiabilité des

données traitées.

Altération de la

fiabilité du

systèm

e.

Evaluer l'impact de toute mise à jour

majeure, la classifier sur la base de

critères de création de valeur m

étier,

d'analyse de risques (impact sur les

systèm

es existants ...) et de coût/béné-

fice.

Tout changem

ent majeur doit s'ap-

puyer sur le mêm

e processus que celui

utilisé pour le développem

ent d'un

nouveau système.

Obtenir l'accord et l'approbation du

responsable métier et autres parties

prenantes pour considérer l'évolution

comme un projet de développem

ent.

Le propriétaire du processus métier et les autres

parties prenantes doivent bien comprendre les diffé-

rences d'organisation, de moyens et de délai entre

une maintenance standard et une mise à jour

majeure.

Plan de mise en œuvre

AI7.3

Plan de mise en

œuvre

Définir un plan de mise

en œuvre et obtenir sa

validation par les

parties concernées.

Allocation de

ressources insuffi-

santes pour

garantir l’implé-

mentation effec-

tive des

changem

ents.

Failles de sécurité.

Une politique de numérotation et de

fréquence des versions est établie en

amont.

Etablir un plan de mise en œuvre qui

prenne en compte une analyse des

risques fonctionnels, techniques et

métier.

Faire valider le plan par toutes les

parties prenantes (métier, études, sécu-

rité et technique) et obtenir leur enga-

gem

ent et implication dans toutes les

étapes de sa mise en œuvre.

Identifier et documenter les scenarii de

retour arrière et solutions de secours.

Le plan de mise en œuvre doit inclure :

•la stratégie générale de mise en œuvre ;

•les différentes étapes de mise en œuvre et leur

séquencement ;

•les moyens requis ;

•les interdépendances ;

•les critères d'acceptation par les responsables de

mise en œuvre en production ;

•les exigences de vérification des installations ;

•la stratégie de transition pour le support aux utilisa-

teurs et l'exploitation.

100

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques



AI7.5

Conversion des

systèmes et données

S’assurer que tous les

élém

ents nécessaires

au bon fonctionne-

ment du nouveau

systèm

e (matériels,

logiciels, données,

sauvegardes, archives,

procédures, documen-

tation…) et garantis-

sant la compatibilité

des interfaces avec les

autres systèmes sont

convertis de l’ancien

systèm

e.

Une piste d’audit des

résultats avant et après

conversion doit être

développée et main-

tenue.

Les anciens

systèm

es ne sont

plus disponibles

quand on en a

besoin.

Perte de confiance

dans le système et

les résultats de la

migration.

Problèmes d’inté-

grité de données.

Définir un plan de conversion de

données et de migration des infrastruc-

tures.

Lors de sa mise en œuvre :

•le calendrier de la bascule de la

conversion est contrôlé ;

•il n'y a pas eu de changem

ent de

valeur des données converties. S’il y a

une nécessité absolue exprimée par

le métier, documenter ces change-

ments et avoir une approbation

formelle du propriétaire des

données;

•le plan de secours, le plan de conti-

nuité et le retour arrière sont pris en

compte ;

•les sauvegardes et archives sont

effectuées et conformes aux

exigences légales.

Le plan de conversion de données doit intégrer des

méthodes de collecte, de conversion et de vérification

des données, identifiant et résolvant toute erreur

trouvée pendant la conversion. Ceci doit inclure des

méthodes de rapprochem

ent entre les données

sources et les données converties afin d'assurer

l’exactitude et l’intégrité des données.

Pendant le développem

ent de ce plan, passer en

revue le hardware, le réseau, les systèmes d’exploita-

tion, les logiciels, les transactions de données, les

fichiers maîtres, les sauvegardes, les archives, les inter-

faces avec les autres systèmes (internes et externes),

les procédures et la documentation systèmes.

Dans la planification des conversions de données et

de l’infrastructure de migration, on doit prendre en

compte l'intégralité des opérations dans la définition

des méthodes de développem

ent, y compris les

aspects "piste d' audit", "scenarii de sauvegardes et de

retour arrière". On doit privilégier une transition

douce sans perte de continuité d'activité et de

données. Si nécessaire et dans l'absence d'une alter-

native, arrêter l'application en production le temps de

la bascule.

101


© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques



AI7.5

Conversion des

systèmes

Les propriétaires des systèmes doivent

effectuer une vérification détaillée du

fonctionnem

ent initial du nouveau

systèm

e juste après son dém

arrage

pour s’assurer que la bascule est

réussie.

Sauvegardes et archives :

•S'assurer qu'une sauvegarde de tous les systèm

eset données a été effectuée avant la bascule de la

conversion en production. Des pistes d'audit

doivent être maintenues pour permettre de

retracer les étapes de la conversion. Un plan de

retour arrière doit être établi en cas de défaillance

de la conversion.

•S'assurer égalem

ent que les instructions des sauve-

gardes et la conservation des archives sont

conformes aux besoins métier et aux exigences

légales ou, aux autorités de tutelles.

•Considérer en mêm

e temps le plan de secours et de

continuité d'activité, ainsi qu'un retour en arrière si

ces considérations sont exigées par la direction des

risques, le métier ou des autorités de tutelle.

Acquisition et mise en œuvre

Spécifications

AI2.1

Conception générale

Traduire les exigences

métiers et les impéra-

tifs techniques de

développem

ent et faire

approuver les spécifica-

tions de la conception

pour s'assurer que la

conception répond

bien aux exigences.

Réévaluer les spécifica-

tions lorsque des écarts

techniques ou fonc-

tionnels significatifs

apparaissent durant le

développem

ent ou la

maintenance.

Spécifications non

formalisées et

dépendantes

d'hommes clés.

Périmètre du

développem

ent

mal défini.

Solution non

conforme aux

besoins métiers

exprimés.

Rédiger les cahiers des charges et

spécifications générales dans le respect

des normes et méthodes de concep-

tion en vigueur. Les faire approuver de

façon formelle par la MOA ou assimilé.

Pendant la phase de conception, impliquer :

•les utilisateurs ayant une compétence métier

reconnue dans le processus à faire évoluer ;

•les parties prenantes de la DSI pour valider les

aspects d'architecture, sécurité et contrôle interne.

Ne lancer aucun développem

ent sans approbation

préalable des spécifications par la MOA.

102

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques


Spécifications

AI2.2

Conception détaillée

Présenter en détail les

spécifications géné-

rales et les impératifs

techniques, en phase

avec la conception

générale.

Réévaluer les spécifica-

tions lorsque des écarts

techniques ou fonc-

tionnels significatifs

apparaissent durant le

développem

ent ou la

maintenance.

Traitement incor-

rect des transac-

tions ou des

données.

Coût supplémen-

taire de reconcep-

tion.

Rédiger les spécifications fonction-

nelles et techniques dans le respect des

normes et méthodes de conception en

vigueur.

Les faire approuver de façon formelle

par les parties prenantes (MOA, archi-

tecte).

Classifier les données d'entrée et de sortie en s'ap-

puyant sur le référentiel de données de l'entreprise.

Evaluer l'impact avec les systèm

es existants et définir

les principes d'intégration avec les applications

internes ou tierces.

Spécifier les données sources devant être collectées.

Déterminer les exigences de disponibilité et définir

les besoins de redondance, de sauvegarde et de

secours.

Définir les exigences relatives aux fichiers et bases de

données par rapport au stockage, leur localisation et

extraction.

Définir les étapes des traitem

ents, les types de trans-

action et règles de traitement (transformation,

calculs...).

Définir les caractéristiques des données de sortie

(destinataires, usage, niveau de détail, fréquence et

méthode de génération).

Concevoir l'interface utilisateur et/ou interfaces entre

les systèm

es.

Avoir une approche itérative avec la MOA, pouvant

inclure un prototype, pour faciliter la compréhension

de la conception finale.

103


© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques


Spécifications

AI2.3

Contrôles applicatifs

et auditabilité

S'assurer que les

contrôles métier sont

correctement traduits

dans les contrôles

applicatifs de façon à

ce que le traitem

ent

soit réalisé avec exacti-

tude, complétude et

dans les délais, et qu'il

soit autorisé et audi-

table.

Contrôles

compensatoires

coûteux.

Problème d'inté-

grité des données.

Ecarts entre les

contrôles applica-

tifs et risques réels.

Résultats des trai-

tements et réfé-

rentiels des

données non-

conformes avec les

besoins exprimés.

Violations de la

sécurité non

détectées.

Intégrer la définition des contrôles

applicatifs dès la phase de conception.

Les faire approuver de façon formelle

par les parties prenantes (MOA ,

contrôle interne).

Définir les contrôles em

barqués dans l'application en

s'appuyant sur les exigences de contrôle relatives aux

processus métier définis dans le cahier des charges.

Dans le cas d'un progiciel, étudier comment adapter

les contrôles du processus métier à ceux intégrés

dans l'application.

Valider la conception des contrôles avec les parties

prenantes (MOA, architecte, sécurité, contrôle

interne).

Les contrôles em

barqués supportent les objectifs de

contrôles généraux (sécurité, intégrité des données,

pistes d'audit) et incluent les contrôles d'accès, les

contrôles d'intégrité des bases de données.

Ces contrôles reçoivent l'approbation des responsa-

bles des parties prenantes.

AI2.4

Sécurité et disponibi-

lité des applications

Adresser les exigences

de sécurité et de dispo-

nibilité des applications

en se fondant sur une

approche des risques,

en s'appuyant sur la

classification des

données et les stan-

dards de sécurité de

l'entreprise.

Violations de la

sécurité non

détectées.

Contrôles

compensatoires

coûteux.

Ecarts entre les

contrôles de sécu-

rité et les risques

réels.

Intégrer la sécurité dès la phase de

conception.

Approuver les spécifications de façon

formelle par les parties prenantes

(MOA , sécurité).

Définir des solutions de sécurité de disponibilité dans

le respect :

•de la politique et des standards de sécurité de l'en-

treprise ;

•des bonnes pratiques (ISO 17799), des obligations

légales et de conformité avec les autorités de

tutelle (incluant le respect de la vie privée).

Prendre en compte l'infrastructure de sécurité et de

disponibilité déjà en place.

Traiter la gestion des droits et des privilèges, la

protection des données sensibles, l'authentification,

l'intégrité des transactions, les restaurations automa-

tiques (rollback).

104

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques


Préparation des plans de tests et des environnements

AI7.2

Plan de tests

Définir un plan de tests

et obtenir sa validation

par les parties concer-

nées afin de contribuer

à un alignem

ent entre

l’expression des

besoins et la solution

mise en œuvre.

Tests insuffisam

-ment automatisés.

Problèmes de

performance non

détectés.

Rôles et responsa-

bilités des tests

indéfinis.

Rédiger un plan de tests conformé-

ment au plan qualité.

Communiquer et présenter le plan à la

MOA ou assimilé et aux parties

prenantes de la DSI.

Le plan doit prendre en compte :

•les rôles et responsabilités ;

•la préparation des tests (jeux et scénarii de tests) ;

•l’installation ou la mise à jour de l’environnem

ent

de test ;

•les tests techniques (capacité, performance, sécu-

rité, maintenabilité) et fonctionnels ;

•la documentation de validation ;

•la gestion et la correction des erreurs ;

•l’approbation formelle de la solution testée ;

•les besoins de formation.

AI7.4

Environnements de

tests

Disposer d’un environ-

nem

ent de test dédié,

représentatif de l’envi-

ronnem

ent de produc-

tion pour permettre

une meilleure efficacité

et fiabilité des tests.

S’assurer que les

données sensibles ne

sont pas diffusées et

que les résultats des

tests sont conservés.

Tests insuffisam

-ment automatisés.

Problèmes de

performance non

détectés.

Compromission de

la sécurité du

systèm

e.

Disposer d'un environnem

ent de test

représentatif de l'environnem

ent de

production.

L'environnem

ent de test doit :

•être représentatif de la production en matière de

capacité, configuration et sécurité ;

•être séparé de toute interaction avec l'environne-

ment de production ;

•contenir des données assainies si elles proviennent

de l'environnem

ent de production et qu'elles revê-

tent un caractère privé ou confidentiel ;

•disposer de moyens de conservation des résultats

des tests et de la documentation, afin de pouvoir

réaliser leur revue et l’analyse telle que définies

dans le plan ;

•être protégé contre la divulgation.

105


© CIGREF - IFACI

Processus

Etapes-clésN° de

réf

COBIT


Risque


Bonnes pratiques


Réalisation

AI2.5

Configuration et

déploiement d'un

progiciel

Configuration et

déploiement d'un

progiciel pour

répondre à un objectif

métier.

Augmentation de

la dépendance à

l'égard des

personnes clés.

Documentation de

la configuration ne

reflétant pas la

configuration du

systèm

e.

Manque de docu-

mentation des

processus métier.

Echec des mises à

jour m

atériel et

des logiciels.

Exam

iner de façon détaillée les impacts

des changem

ents sur les applications

et systèmes existants, les aspects

contractuels et la personnalisation et le

param

étrage.

Faire approuver des spécifications rela-

tives à la customisation et au param

é-trage.

Suivre une approche par étape pour

valider la solution avec la MOA et les

parties prenantes de la DSI avant de

commencer la customisation et le para-

métrage.

Les procédures de tests intègrent bien

les objectifs de contrôle de logiciels, à

savoir : fonctionnalité, interopérabilité

avec les applications et l'infrastructure

existantes, les performances systèm

es,

les tests de charge et l'intégrité des

données.

Evaluer l'impact d'une mise à jour progiciel sur des

critères tels que le risque de mise en œuvre (im

pact

sur les systèmes existants, processus ou sécurité) et le

rapport coût / bénéfice.

Exam

iner :

•les problèmes d'interopérabilité avec les systèm

es,

technologies et infrastructures existants de l'entre-

prise dès la phase de conception ;

•l'impact de la personnalisation du param

étrage et

de la configuration sur les performances, l'efficacité

et la maintenance du progiciel et des autres appli-

cations et infrastructures existantes ;

•les aspects contractuels avec l'éditeur de logiciel

par rapport à la personnalisation, le param

étrage et

la configuration ;

•la disponibilité du code source du progiciel dans le

processus de personnalisation et de param

étrage.

Vérifier les accords de séquestre du code source

avec l'éditeur lorsque celui-ci n'est pas disponible.

Evaluer les risques de non maintenance du logiciel

en fin de contrat ;

•le niveau de la customisation et du param

étrage

nécessaire pour répondre au besoin du métier et

réévaluer l'adéquation du progiciel, celui-ci pouvant

avoir un impact sur la stratégie de mise à jour du

progiciel.

106

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques


Réalisation

AI2.7

Développement d’ap-

plications

(Développement

interne)

S'assurer que le déve-

loppem

ent des fonc-

tions dem

andées est

conforme aux spécifica-

tions, respecte les stan-

dards de développe-

ment et est docu-

menté. Veiller à ce que

tous les aspects juri-

diques et contractuels

soient identifiés et

traités lors de dévelop-

pem

ents réalisés par

des tiers.

Mauvaise utilisa-

tion des

ressources.

Effort non focalisé

sur les besoins

métier.

Nombre élevé de

pannes et défauts.

Incapacité de

maintenir efficace-

ment les applica-

tions.

1.Mettre en place des procédures de

développem

ent conformes aux

méthodologies de développem

ent

(SDLC

: System

s Develop

men

t Life

Cycle).

2.Le développem

ent s’appuie sur les

spécifications et prend en compte les

exigences métier, fonctionnelles et

techniques.

3.Etablir des points de contrôle et

étapes de validation dans le

processus de développem

ent (points

d’avancement formels avec la MOA).

4.Evaluer l’aptitude du logiciel déve-

loppé à être compatible ou s’intégrer

facilement aux applications et infra-

structures existantes.

A la fin du développem

ent, obtenir la validation

formelle de la MOA et des parties prenantes de la DSI

de toutes les fonctionnalités, de la sécurité, des

performances et de la qualité. En fin d'étape, se faire

confirmer auprès des responsables techniques et

d’exploitation que les applications sont prêtes et

aptes à être basculées dans l’environnem

ent de

production.

107


© CIGREF - IFACI

Processus

Etapes-clésN° de

réf

COBIT


Risque


Bonnes pratiques


Réalisation

AI2.8

Assurance Qualité

logiciel

S’assurer que les fonc-

tionnalités mises en

œuvre répondent bien

aux spécifications et

exigences de qualité,

que ce soit en termes

de développem

ent,

documentation, ou de

validation.

S’assurer égalem

ent

que les aspect légaux

et contractuels sont

identifiés et gérés pour

les applications déve-

loppées par des tiers.

Mauvaise qualité

des logiciels.

Répétition des

tests.

Tests inadaptés ou

insuffisants.

Détournem

ent de

données de test et

compromettant la

sécurité de l'entre-

prise.

Non respect des

exigences de

conformité.

Définir un plan d'assurance qualité des

logiciels.

Concevoir un processus d'assurance

qualité logiciels.

Effectuer des inspections de code, des

tests de chem

inem

ent des

programmes et des tests applicatifs.

Rapporter les résultats de ces contrôles

et tests.

Surveiller les exceptions de qualité.

Réaliser des mesures correctives et

contrôler leur m

ise en œuvre.

Dans le plan, sont spécifiés ou définis :

•les critères de qualité ;

•le processus d'assurance qualité ;

•la méthode d'assurance qualité ;

•les qualifications nécessaires pour assurer les fonc-

tions de contrôleur qualité ;

•les rôles et responsabilités pour la mise en œuvre

de la qualité.

Sont pris en compte :

•l'intégration de la qualité dans le processus de

développem

ent ;

•la présence ou l'absence de revues par des équipes

d'assurance qualité ;

•l'indépendance des contrôles vis-à-vis de l'équipe

de développem

ent.

Le processus de contrôle qualité des logiciels est basé

sur :

•les besoins projet ;

•la politique de l'entreprise ;

•la méthodologie de gestion de projets.

108

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques


Recette

AI7.6

Tests des change-

ments

S’assurer que les chan-

gem

ents dem

andés et

arbitrés ont été testés

dans l’environnem

ent

de test par une équipe

indépendante de

l’équipe de développe-

ment, conformém

ent

au protocole de recette

en vigueur et avant

mise en production.

Mauvaise utilisa-

tion des

ressources.

Dégradation géné-

rale de la sécurité.

Changem

ents

influant sur les

performances et la

disponibilité du

systèm

e.

Les tests sont conçus et réalisés par

une équipe de test indépendante de

celle du développem

ent. Impliquer les

propriétaires des processus métier et

utilisateurs finaux. Les tests sont effec-

tués uniquem

ent dans l'environne-

ment de test.

Les tests et les résultats attendus

doivent répondre aux critères de

qualité définis dans le plan de test.

Les scenarii de test (scripts) m

is en

œuvre doivent être clairs et doivent

inclure des tests de sécurité et de

performance.

Les tests sont effectués, évalués et

approuvés. Combiner intelligem

ment

les tests automatisés et les tests inter-

actifs utilisateurs.

Le résultat des tests est conservé et

communiqué aux parties prenantes.

Conformém

ent au plan de test, effectuer des tests de :

•sécurité, pour identifier et évaluer les faiblesses et

vulnérabilités. Ces tests incluent les contrôles

d'accès ;

•performance de l'application, en réalisant des séries

de mesures de temps de réponse (par exemple, vue

par l'utilisateur final, la base de données, le système)

et des tests de charge ;

•sur les échecs de traitement ou de transaction (fall-

back et rollback).

Identifier, conserver et classifier (mineur, important,

critique) les bugs rencontrés lors des tests. Rendre

disponible une piste d'audit des résultats des tests

effectués.

Les résultats des tests de non régression et des évolu-

tions sont communiqués à toutes les parties

prenantes pour faciliter la correction des bugs et

l'amélioration de la qualité.

109


© CIGREF - IFACI

Processus

Etapes-clésN° de

réf

COBIT


Risque


Bonnes pratiques


Recette

AI7.7

Tests finaux / Recette

Les tests s'achèvent par

une recette, qui permet

une évaluation et une

approbation formelle

des résultats des tests.

Problèmes de

performance

détectés.

Refus des fonc-

tions livrées par la

MOA (B

usiness

rejection of deli-

vered capa

bilities).

Les tests finaux doivent couvrir l'en-

semble des composants du SI impactés

par les changem

ents.

Tous les problèmes rencontrés pendant

les tests ont été consignés, catégorisés

et corrigés par l'équipe de développe-

ment.

Les résultats des tests sont revus et

documentés, puis présentés de

manière compréhensible au respon-

sable du processus métier et aux

parties prenantes de la DSI, afin d'en

faciliter l'évaluation.

Signature d'un PV de recette par le

propriétaire du processus métier et des

parties prenantes de la DSI, tel que

défini dans le plan de test.

Le périmètre de la recette comprend bien sûr, les

composants logiciel, mais aussi les configurations, les

procédures utilisateur, et les procédures d'exploita-

tion, de suivi et de support.

L'approbation formelle est obligatoire avant toute

mise en production.

110

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques


Accompagnement utilisateurs / Formation

AI7.1

Formation

Informer systématique-

ment :

•les utilisateurs des

changem

ents fonc-

tionnels et les former

en cas d’évolution

importante afin de

contribuer à la bonne

utilisation du

systèm

e ;

•l’équipe d’exploita-

tion des change-

ments techniques, et

les former en cas

d’évolution impor-

tante afin de contri-

buer à la bonne

exploitation du

systèm

e.

Incapacité de

détecter rapide-

ment les

problèmes venant

des systèmes ou

de leur utilisation.

Manque des

connaissances

requises dans

l’exécution des

tâches confiées

aux utilisateurs.

Erreurs résultant

des nouveaux

projets.

Etablir un plan de formation qui s'ap-

puie sur un processus. Il doit :

•faire partie intégrante des projets de

développem

ent ou de maintenance ;

•identifier et impliquer tous les

groupes concernés, aussi bien les

utilisateurs finaux que les exploitants,

le support technique, équipes de

développem

ent et prestataires de

services.

Adapter la stratégie de formation en

fonction du besoin (formation des

formateurs, certifications, eTraining...).

Etablir des supports de formation.

Evaluer la formation afin d'obtenir des

commentaires pouvant conduire à des

améliorations potentielles.

Le plan de formation doit :

•identifier les objectifs d'apprentissage, les

ressources, les principaux jalons, les dépendances et

chem

ins critiques pouvant influencer la réalisation

du plan,

•identifier les mem

bres du personnel qui doivent

être formés et ceux pour qui la formation est

souhaitable,

•étudier des stratégies de formation en fonction du

métier de l'entreprise, des risques associés (par

exem

ple, pour des systèmes critiques, un mode

formel d'accréditation de l'utilisateur susceptible

d’être mis en place), et de la réglementation (par

exem

ple, respect des lois sur la vie privée nécessi-

tant une adaptation de la formation au niveau

national).

Surveiller tous les changem

ents prévus pour s'assurer

que les besoins de formation ont été exam

inés et que

le plan de formation est adapté.

Ne pas exclure de reporter les changem

ents si la

formation n'a pas été effectuée et que cela risque de

mettre en péril la mise en œuvre de ces change-

ments.

111


© CIGREF - IFACI

Processus

Etapes-clésN° de

réf

COBIT


Risque


Bonnes pratiques


Lotissement, mise en production et déploiement

AI7.8

Mise en production

Après les tests,

contrôler le transfert

des changem

ents du

systèm

e vers l'environ-

nem

ent de production,

conformém

ent au plan

de mise en œuvre.

Obtenir l'approbation

des principales parties

prenantes telles que les

utilisateurs, le proprié-

taire du système et le

responsable d'exploita-

tion.

Si approprié, procéder à

une marche en double

(nouveau et ancien

systèm

e en parallèle

pendant un certain

temps) et comparer le

comportem

ent et les

résultats.

Pas de retour en

arrière possible à

la version du

systèm

e d'applica-

tion initiale.

Systèm

es exposés

à la fraude ou

autres actes de

malveillance.

Violations de sépa-

ration des droits.

Utiliser un processus formalisé pour la

mise en production des changem

ents

de l'environnem

ent de test vers l'envi-

ronnem

ent de production et mettre en

place un dispositif d'approbation

formel (signo

ff).

Dans ce processus de mise en produc-

tion :

•mettre à jour la documentation

(exploitation, configuration), faire des

copies des configurations avant acti-

vation du nouveau système ou des

modifications en production et

mettre à jour le plan de secours si

nécessaire ;

•archiver la version existante et la

documentation, gérer la configura-

tion des systèmes, logiciels d'applica-

tion et d'infrastructure ;

•conserver le code source des

programmes de la version à mettre

en production ;

•copier tous les programmes à utiliser

dans l'environnem

ent de production.

Signer un accord avec l’éditeur pour

récupérer les codes source en cas de

litige ou de faillite de l’éditeur.

Avoir l'approbation formelle (signo

ff)des responsa-

bles du processus métier et des parties prenantes de

la DSI (développem

ent, sécurité, architectes, assis-

tance aux utilisateurs et exploitation) et les dates de

bascule de mise en production des changem

ents et le

cas échéant, d’arrêt des anciens systèm

es ou applica-

tions.

Si la distribution de systèm

es ou logiciels d'applica-

tion est automatique, contrôler que les utilisateurs

sont informés et que la distribution est déployée :

•aux seules personnes autorisées et identifiées ;

•dans l'environnem

ent de destination défini ;

•avec la version correcte ;

•à la date d'activation approuvée.

Inclure dans le processus de livraison, une procédure

de retour en arrière en cas de mauvais fonctionne-

ment ou d'erreur d'installation.

Si la distribution est manuelle, maintenir un journal

d'opération avec les informations suivantes :

•logiciels et élém

ents de configuration, qui ont été

distribués ;

•destinataires des logiciels et élém

ents de configura-

tion et localisation de leur m

ise en œuvre ;

•les dates de mise à jour.

Conserver un journal exhaustif traçant ces opérations

et effectuer des contrôles sur pièce, de la distribution

de l'application à la date officielle de déploiement.

112

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques


Bilan

AI7.9

Bilan de mise en

œuvre

Réaliser un bilan tel

que défini dans le plan

de mise en œuvre, en

s'appuyant sur des

procédures en ligne

avec les standards de

gestion des change-

ments.

Le retour sur inves-

tissem

ent ne

répond pas aux

attentes du mana-

gem

ent.

Incapacité d'iden-

tifier que les

systèm

es ne

répondent pas aux

besoins des utilisa-

teurs finaux.

Mettre en place une procédure de bilan

de projet.

Utiliser des indicateurs d'évaluation de

projet.

Faire participer les responsables des

processus métiers, informatiques, tech-

niques et de contrôle interne ou de

gestion des risques.

Etablir un plan d'action pour traiter les

problèmes identifiés.

Mettre en place une procédure de bilan de projet,

pour identifier, évaluer et rapporter si :

•les besoins ont été couverts ;

•les avantages attendus ont été obtenus ;

•le système est considéré comme utilisable ;

•les attentes des intervenants internes et externes

sont satisfaites ;

•des impacts inattendus sur l'organisation se sont

produits ;

•les principaux risques ont été jugulés ;

•les gestions du changem

ent, d'installation et du

processus d'accréditation ont été effectuées de

manière efficace et efficiente.

Consulter les responsables métier et informatiques

pour définir des indicateurs de succès, la réalisation

des exigences et les bénéfices obtenus.

Le formulaire de bilan fait partie du processus de

gestion du changem

ent. Faire participer les proprié-

taires des processus métiers ou parties tiers, le cas

échéant.

Exam

iner égalem

ent les exigences hors métiers ou

DSI (par exemple, l'audit interne, gestion des risques

de l'entreprise, la conformité réglementaire).

Etablir un plan d'action pour traiter les problèmes

restants, identifiés durant le projet. Faire participer les

responsables métier et informatiques dans son élabo-

ration.

5.8. Gestion des incidents

Processus-clé du support informatique, la gestion des incidents a pour objectif le rétablissementd’un service, interrompu ou altéré par un événement qui ne fait pas partie des opérations stan-dards. La multiplication des technologies et l’interconnexion des systèmes et plateformes com-plexifie l’identification et le traitement des incidents : en effet, les symptômes visibles peuvent êtretrès éloignés des causes ayant engendré un incident. De même, un incident peut entraîner unemultitude d’autres incidents, qui à leur tour vont être traités par ce processus.

Ce contexte explique que la gestion des incidents s’interface avec de nombreux autres processusinformatiques, en particulier la gestion des changements et la gestion de la sécurité.

C’est pourquoi, ce processus doit être supporté par un traitement administratif rigoureux, qui estmodélisé de façon simplifiée en s’inspirant des référentiels COBIT (DS8) et ITIL (Soutien des ser-vices / Gestion des incidents). Les risques majeurs concernent le mauvais diagnostic, la lenteur decorrection de l’incident ou de retour à la situation normale, le découragement des utilisateurs, et infine l’image de marque de l’informatique.

La maîtrise de ces risques repose sur les points suivants, qui constituent des meilleures pratiques :1. identification et priorisation des systèmes par criticité (disponibilité et intégrité) ;2. existence, mise à jour et diffusion d’une documentation en adéquation avec tous les éléments

de la chaîne (systèmes et réseaux) ;3. formalisation, mise à jour et diffusion d’une procédure de gestion des incidents, précisant les

responsabilités des différents acteurs et les indicateurs de performance ;4. déploiement de dispositifs automatiques de surveillance et pilotage de tous les éléments de la

chaîne : matériels, réseaux, systèmes d’exploitation, bases de données et applicatifs.

Enfin, notons que la gestion de crise est exclue du champ du processus analysé, en raison de lanature singulière du traitement à appliquer pour préparer et lancer les actions de reprise d’activité.

113


© CIGREF - IFACI

5.8.1. Flowchart du processus de gestion des incidents

114

© CIGREF - IFACI

Pro

cess

sus

: Ges

tio

n d

es In

cid

ents

UtilisateursSupport

utilisateurProduction / Exploitation

RSSI Etudes /Développement

oui

non

Enregistrementet

documentationdes incidents

Diagnostic 1 niveau :analyse

d’impact, priorisation et classification

Peutêtre résolu

au 1 niveau?

Routage / escaladevers les groupes supports

compétents

Suivi de la résolution

et communication

Clôture del’incident

Diagnostic, investigationet résolution

Gestion deschangements

Collectedes incidents(web, email,téléphone)

Détectiond’incidents

(monitoring)

SLA / OLA

Légende

Activité

Décision


Renvoi

Flux

er

er

5.8.2. RACI du processus de gestion des incidents

115


© CIGREF - IFACI

Etapes-clésdu processus

Utilisateurs

Support

utilisateur

Production /

Exploitation

RSSI

Etudes /

Développements


Déclarationd'incidentutilisateur

AR I DS8.1

Déclarationd'incidentexploitation(manuel ouautomatique)

I AR DS8.1

Enregistrement etdocumentation des

incidentsI AR I

• Fiche d'incident• Base d'inventaire et de suivi desincidents

DS8.2

Diagnostic 1er

niveau :Analyse d'impact /priorisation classification

I AR C C CCompte-rendu de qualification del'incident

DS8.2

Routage / Escaladevers les groupessupports ad hoc

I AR R R RSupports de routage (mail, accuséde réception…)

DS8.3

Diagnostic /Investigation /Résolution(Production)

I I AR C C• Fiche d'incident mise à jour• Base de connaissances mise à jour

DS8.3

Diagnostic /Investigation /Résolution

(Sécurité des SI /contrôleinterne)

I I C AR C• Fiche d'incident mise à jour• Base de connaissances mise à jour

Diagnostic /Investigation /Résolution(Etudes)

I I C C AR• Fiche d'incident mise à jour• Base de connaissances mise à jour

Suivi de larésolution etcommunication

I AR I I• Fiche d'incident mise à jour• Tableau de bord et statuts

DS8.5

Clôture del'incident

R AR I I• PV d'acceptation par l’utilisateur• Fiche d'incident mise à jour

DS8.4

116

© CIGREF - IFACI

Processus

Etapes-clésN° de

réf

COBIT


Risque


Bonnes pratiques

Gestion des incidents

Enregistrement et documentation des incidents

DS8.2

S'assurer que tous les

incidents connus sont

déclarés.

S'assurer que la

description de l'inci-

dent est réalisée selon

la procédure en

vigueur (contenu,

support…).

Non-enregistre-

ment de l'incident.

Mauvaise descrip-

tion ou compré-

hension de

l'incident.

Revue périodique des fiches d'incident.

Vérification de la documentation de

chacun des cham

ps prévus dans la

fiche d'incident.

Existence d'une procédure de reporting des incidents

à jour et diffusée auprès de tous les utilisateurs des

systèm

es d'information (avec un point d'entrée

unique par mode de communication - téléphone /

mèl / web).

Existence d'une procédure "support utilisateur" d'en-

registrem

ent systém

atique et de documentation des

incidents.

Utilisation d'outils de monitoring permettant la décla-

ration automatisée d'incidents de production. Ces

outils ont une interface avec la base des incidents.

Utilisation d'un outil pour l'enregistrem

ent et la docu-

mentation centralisés des incidents permettant la

constitution d'une base d'incidents unique et centra-

lisée ainsi que l'élaboration de tableaux de bord.

Formations/informations régulières sur les procé-

dures, les outils, les retours d'expériences et les meil-

leures pratiques.

5.8.3.

Matrice risques/con

trôles du processus de ge

stion des inciden

ts

117


© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques


Diagnostic de 1erniveau : - analyse d'impact- priorisation et classification de l'incident

DS8.2

S'assurer que le diag-

nostic est réalisé pour

tous les incidents

déclarés.


nostic est réalisé dans

les délais prévus par la

procédure en place.

S'assurer que l'analyse,

la classification et la

priorisation sont

correctement réalisées.

Analyse d'impact

erronée.

Priorisation inadé-

quate de l'incident

(sur ou sous-

évaluation).

Classification

erronée de l'inci-

dent.

Diagnostic non

réalisé ou réalisé

tardivem

ent.

Mauvaise utilisa-

tion des systèmes

due à l’ignorance

de l'incident par

les utilisateurs.

Revue régulière du délai de réalisation

des diagnostics, identifier les cas d'ano-

malie de délais (pas de date, délais

dépassés…

).

Utilisation de grilles d'analyses docu-

mentées dans la procédure et permet-

tant l'analyse, la classification et la

priorisation de l'incident.

Vérification régulière de la classification

de l'incident et de la priorisation de sa

résolution conformes à la typologie de

l'incident et au degré de sensibilité des

données et/ou du système applicatif

concerné.

Existence et diffusion de documentation d'aide au

diagnostic incluant des grilles d'analyse.

Existence de SLA / OLA en relation avec le degré de

sensibilité des systèmes et des données.

SLA indiquant les délais maxima pour la réalisation

des diagnostics.

Communication des mesures conservatoires transi-

toires, du délai probable de résolution vers tous les

utilisateurs concernés des incidents ouverts.

Routage et escalade vers le(s) groupe(s)support compétent(s)

DS8.3


incidents diagnosti-

qués, classifiés et prio-

risés sont orientés vers

les groupes support

adéquats.

S'assurer que l'escalade

vers les groupes

support adéquats est

réalisée dans le respect

des procédures en

place (canal et moda-

lités d'information,

délais…

).

Non-traitem

ent

des incidents par

les groupes

support.

Traitement tardif

des incidents.

Vérifier que tous les incidents diagnos-

tiqués sont affectés à un groupe

support.

Vérifier l'existence d'incidents ouverts

diagnostiqués sans affectation à un

groupe support.

Existence d'alerte sur les incidents non

affectés après un délai prédéterminé

selon la priorisation de l'incident.

Procédure de routage indiquant les destinataires de

la notification d’incident en fonction des résultats du

pré-diagnostic et procédure d'escalade en cas de

non-résolution dans des délais prédéfinis (notam-

ment dans la SLA /OLA).

Outil de relance automatique.

118

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques


Diagnostic, investigation et résolution de l'incident

DS8.3


nostic, l’investigation et

la résolution sont

réalisés pour tous les

incidents déclarés.


nostic, l’investigation et

la résolution sont

réalisés dans des délais

prévus par la procédure

en place.

S'assurer que les causes

primaires des incidents

sont effectivem

ent trai-

tées.

S'assurer que la résolu-

tion de l'incident ne

sera pas conflictuelle

avec l'activité de l'utili-

sateur.

Diagnostic erroné.

Diagnostic tardif.

Résolution non

effectuée ou effec-

tuée tardivem

ent.

Perte de temps

dans la résolution

des incidents par

manque de capita-

lisation d'expé-

rience.

Récurrence des

incidents connus

en raison du

manque de résolu-

tion de la cause

primaire.

Application de

"worka

roun

d /

quick fix

"(solution

de contourne -

ment/ réparation

rapide) tempo-

raire, en conflit

avec les procé-

dures ou activités

utilisateurs.

Existence d'alerte sur les délais de trai-

tement et vérification de la réalisation

des relances après alerte.

Obtention d’accord formel des utilisa-

teurs selon la gravité de l’incident et en

cas d’application de “W

orka

roun

d /

quickfix“ (solution de contournem

ent/

réparation rapide temporaire ne

réglant pas la cause primaire de l’inci-

dent).

Documentation des systèmes à jour, disponible et

diffusée auprès des acteurs concernés.

Expertise des équipes support (gestion des compé-

tences).

Documentation systématique de la résolution d’inci-

dent dans une base de connaissance.

Documentation systématique des causes primaires

des incidents dans une base de connaissance.

Corréler les engagem

ents pris vis-à -vis des utilisa-

teurs internes avec ceux négociés avec les fournis-

seurs externes.

119


© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques


Suivi de la résolution et communication

DS8.5

S'assurer que le statut

des incidents est

traçable et justifiable à

tout moment.

S'assurer que les

séquences d'évolutions

des statuts des inci-

dents sont conformes

aux engagem

ents de

qualité et de délais

figurant dans les SLA et

OLA.

S'assurer que les enga-

gem

ents pris sont

réalistes ou adaptés

aux besoins.

S'assurer que les utilisa-

teurs sont informés

régulièrement de

l'avancement de la

résolution de l'incident.

Utilisation inadé-

quate des

systèm

es.

SLA et OLA non

mises à jour en

fonction des

évolutions des

besoins métier.

Le suivi des incidents est exploitable

(actualisation régulière, en phase avec

le statut d'avancement, validé par les

acteurs du dispositif, supervisé) et les

relances nécessaires effectuées.

Analyse régulière du reporting de suivi

des incidents pour vérifier si les succes-

sions de phases sont en adéquation

avec les engagem

ents pris (dont

communication aux utilisateurs).

Identifier les écarts pour prendre les

mesures correctrices nécessaires.

Vérifier que les incidents intervenant

en dehors des limites fixées par les SLA

ou OLA font l'objet d'une alerte.

Outil de workflow de résolution des incidents.

Existence d'un tableau de bord de suivi des incidents

reprenant les principaux indicateurs de performance

(nombre d'incidents par typologie et systèm

esconcernés, productivité du support utilisateur, % d'in-

cidents nécessitant un déplacement, durée moyenne

des incidents classés par gravité, délais de résolution

ou de non résolution, % incidents résolus au 1er

niveau, % incidents réouverts, % incidents résolus

dans les SLA, etc.).

Comités de suivi réguliers entre « support utilisateur»

et utilisateurs assurant la supervision des tableaux de

bord, de la bonne résolution des incidents, des

alertes…

Mise à jour périodique des SLA/OLA, en accord avec

les besoins des métiers.

Capitalisation régulière sur les retours d'expérience

de résolution des incidents, adaptation régulière des

procédures de gestion des incidents (gouvernance ad

hoc et processus d’actualisation).

Clôture de l'incident

DS8.4

S'assurer que la résolu-

tion de l'incident est

testée et validée par

l'utilisateur.


incidents résolus

validés sont clos.

Clôture d'un inci-

dent non résolu.

Non-clôture d'un

incident résolu

induisant une

perte de temps

par les groupes

support.

Signature obligatoire du PV de recette

par l'utilisateur pour clôture d'un inci-

dent.

Vérifier périodiquem

ent le statut

d'avancement des incidents non clos.

Vérification périodique que tout inci-

dent clos a obtenu la validation de l'uti-

lisateur (PV de recette).

Principaux indicateurs de performance (voir suivi).

Communication aux utilisateurs de la clôture d'inci-

dent.

Enrichissement / mise à jour des bases de connais-

sance et de cause principale.

Vérification par le support utilisateur de ces mises à

jour.

5.9. Gestion de la sécurité logique et des accès physiques

La sécurité logique et physique est un thème ancien et récurrent dès lors qu’on parle de contrôleinterne des systèmes d’information : cette antériorité ne signifie pour autant pas que ce sujet soitparfaitement sous contrôle. Au contraire, il convient dans chaque organisation de comprendre etqualifier les vulnérabilités et les menaces, afin de construire la réponse adéquate en matière d’exi-gences de sécurité devant peser sur le système d’information.

Notre définition de la sécurité logique comprend la confidentialité, la disponibilité et l’intégrité del'information, des applications et de l'infrastructure informatique. Le champ de la sécurité phy-sique a été limité au sujet des accès non autorisés.

C’est pourquoi, les activités de contrôle que nous décrivons ont pour finalité de s'assurer que lesservices informatiques sont capables de résister à des attaques et d'en surmonter les effets, notam-ment pour garantir la mise à disposition de données intègres, en empêcher une divulgation inap-propriée, et contribuer à la continuité de l'activité de l'entreprise.

Les conditions préalables au déploiement du processus de gestion de la sécurité logique et desaccès physiques concernent l'existence d'une politique de sécurité SI et la mise en place d'uneorganisation assurant son déploiement et sa mise à jour.

Les entreprises et les administrations publiques doivent fonder leur approche de la sécurité infor-matique sur un corps de règles et de directives, visant à structurer et faire connaître « la politiquede sécurité des systèmes d'information » et décrivant l'ensemble des principes fondateurs, les vul-nérabilités identifiées, les objectifs de protection et les règles à appliquer avec leur niveau d'exi-gence :

• les directives, dont l'application est impérative ; le non-respect d'une directive ne peut êtreque transitoire et doit donner lieu à une dérogation formalisée ;

• les recommandations, qui ont pour vocation à s'appliquer le plus largement possible sur leSI de l'entreprise.

Cette politique est déclinée en objectifs de contrôle permettant d'évaluer la réalité de son déploie-ment et son efficacité.

La politique définie est déployée et mise à jour par une organisation adaptée, couvrant tout ledomaine de la sécurité SI. Cette organisation dédiée est chargée de légiférer et de contrôler labonne application de la politique. Elle doit disposer d'un rattachement lui garantissant un niveaud'indépendance adéquat, notamment vis-à-vis des opérations.La politique et l’organisation doivent couvrir quatre thèmes clés :1. La gestion des risques, fondée sur l'évaluation et la réduction des risques.2. La qualification de l'information, fondée sur une classification de l'information destinée à

adapter le niveau de protection de celle-ci.3. La conformité des systèmes avec les politiques et standards de sécurité en vigueur. 4. La sensibilisation à la politique de sécurité SI, fondée sur une communication adéquate auprès

de chaque employé (en modes ”push et pull“).

Sur ces quatre thèmes, les managers ont un rôle important pour s'assurer que l'application desprocédures dont ils sont responsables est accomplie en pleine conformité avec les référentiels.

120

© CIGREF - IFACI

121


© CIGREF - IFACI

5.9.1.

Flow

chart du processus de ge

stion d’attribu

tion

des droits d’accès

Pro

cess

us

de

ges

tio

n d

'att

rib

uti

on

des

dro

its

d'a

ccès

au

x re

sso

urc

es in

form

atiq

ues

RSSI

Act

ual

isat

ion

rég

uliè

re

Fin

Fi

n

Ou

i

Ou

iO

ui

Ou

iO

ui

Ou

i

Ou

i

Ou

i

Ou

i

No

n

No

n

No

n

No

n

No

n

Rel

ance

du

p

roce

ssu

s d

e va

lidat

ion

Ori

enta

tio

n s

elo

n p

rofil

Post

eC

lé /

Cri

tiq

ue?

Post

e se

nsi

ble

?St

agia

ire?

Post

est

and

ard

?

Valid

atio

n O

K?

Valid

atio

n H

iéra

rch

iqu

e /

RH

Co

nd

itio

ns

pré

alab

les

: - e

xist

ence

d'u

ne

fich

e d

e p

ost

e d

éfin

issa

nt

les

rôle

s et

resp

on

sab

ilité

s d

e la

fon

ctio

n- d

eman

de

d'o

uve

rtu

re d

es d

roit

s d

'acc

ès n

éces

sair

es à

l'ex

erci

ce d

e la

fon

ctio

n

Valid

atio

n s

péc

ifiq

ue

par

le re

spo

nsa

ble

du

pro

cess

us

mét

ier

Ch

ang

emen

t d

e p

ost

e?

Arc

hiv

age

Rec

ycla

ge

du

mat

érie

l

Polit

iqu

e d

eSé

curi

té

Valid

atio

n h

iéra

rch

iqu

e /

RH d

e la

dat

e d

e d

épar

t d

u c

olla

bo

rate

ur

Valid

atio

n O

K?

Ferm

etu

re d

es d

roit

s d

'acc

èsp

hys

iqu

es e

t lo

giq

ues

exi

stan

ts

Res

titu

tio

n d

u m

atér

iel

Arc

hiv

age

des

do

nn

ées

avec

dro

its

d'a

ccès

rétr

ibu

ésD

estr

uct

ion

des

do

nn

ées

Net

toya

ge

com

ple

t d

es s

up

po

rts

log

iqu

es (d

isq

ues

du

rs)

Rec

ycla

ge

du

mat

érie

l

Lég

end

e

Act

ivit

é

Déc

isio

n

Do

cum

ents

/ D

on

née

s

Ren

voi

Flu

x

Ch

ang

emen

t d

e p

ost

ed

u c

olla

bo

rate

ur

Entr

ée d

u c

olla

bo

rate

ur

Iden

tific

atio

n d

'un

bac

kup

• Ges

tio

n d

u r

isq

ue

d'u

surp

atio

n• A

cco

rds

de

con

fiden

tial

ité

• Tra

çab

ilité

ren

forc

ée d

es a

ccès

et

sup

ervi

sio

n h

iéra

rch

iqu

e

• Lim

itat

ion

des

dro

its

d'a

ccès

en

cou

vert

ure

et

en d

uré

e• A

cco

rds

de

con

fiden

tial

ité

• Tra

çab

ilité

ren

forc

ée d

es a

ccès

• Su

per

visi

on

par

l'en

cad

rem

ent

Ferm

etu

re d

es d

roit

s d

'acc

ès p

hys

iqu

es

et lo

giq

ues

exi

stan

ts d

ans

le p

ost

e p

récé

den

t

Res

titu

tio

n d

u m

atér

iel

Ou

vert

ure

eff

ecti

ve d

es d

roit

s d

'acc

èsp

hys

iqu

es e

t lo

giq

ues

Att

rib

uti

on

du

mat

érie

l

• Sen

sib

ilisa

tio

n /

Fo

rmat

ion

à la

po

litiq

ue

de

sécu

rité

• Mo

du

le a

dap

té à

ch

aqu

e n

ivea

u d

e p

rofil

Sort

ie d

u c

olla

bo

rate

ur

Ap

plic

atio

n n

éces

sita

nt

un

e va

lidat

ion

sp

écifi

qu

e?A

rch

ivag

e d

es d

on

née

s?(V

alid

atio

n h

iéra

rch

ie)

Dir

ecti

on

Mét

iers

Fon

ctio

nR

esso

urc

esH

um

ain

es

Res

po

nsa

ble

hié

rarc

hiq

ue

Pro

du

ctio

n /

Exp

loit

atio

n

Serv

ices

Gén

érau

x

Fon

ctio

nR

esso

urc

esH

um

ain

es

Res

po

nsa

ble

hié

rarc

hiq

ue

Pro

du

ctio

n /

Exp

loit

atio

n

Serv

ices

Gén

érau

x

Res

po

nsa

ble

hié

rarc

hiq

ue

Pro

du

ctio

n /

Exp

loit

atio

n

122

© CIGREF - IFACI

5.9.2. RACI du processus de gestion de sécurité logique et des accès

Etapes-clésdu processus D

SI

Etudes /

Développements

Production /

Exploitation

Directions

métiers

RSSI

CommentairesProcessusCOBIT

Organisation de laDirection des systèmes

d’informationA R R R I

Définit le rattachement de lasécurité SI

PO4

Définition de lapolitique de sécurité etdes règles de sécurité

A I I I R PO6

Sensibilisation à lapolitique de sécurité

I C C R ALes responsables opérationnelsdoivent être largement impli-qués

PO6 / DS7

Conformité dessystèmes avec la

politique de sécuritéA R R C I DS5

Gestion des Risques A R R R CImplication directe du DSI dansl'animation du processus

PO9

Sécurité physique (accèsaux locaux)

A I R C C DS12

Gestion des accèsutilisateurs

I A A R CApprouve chaque acteur dansson domaine

DS5

Accès aux programmeset aux données

I A A R CApprouve chaque acteur dansson domaine

DS5

Surveillance des accèslogiques

A I R R ILes responsables opérationnelsdoivent être largement impli-qués

DS5

Sécurité réseaux A I R I C DS5

Séparation desinfrastructures

A I R I C DS5

Gestion des failles desécurité

I C R I A DS5

Gestion des servicesrendus par un tiers

A R R R C DS2

Gestion des certificats A C C I R DS5

Gestion des incidents A I R I R DS5

Robustesse du dispositifde protection

A R A C RApprouve chaque acteur dansson domaine

DS5

123


© CIGREF - IFACI

5.9.3.

Matrice risques/con

trôles du sou

s-processus d’accès aux program

mes et au

x don

nées

ProcessusN° de

réf

COBIT

ISO

27001


Risque


Bonnes pratiques

Accès aux programmes et aux données

DS5

ISO 11

S’assurer que les

processus existants

permettent d'identifier

tous les utilisateurs

(internes et externes) du

systèm

e.

Les utilisateurs non

identifiés peuvent

faire des change-

ments non auto-

risés dans les

programmes et les

données.

S'assurer que tous les utilisateurs s'identi-

fient pour accéder aux systèm

es d’infor-

mation.

Le principe admis est que toute personne physique doit

pouvoir être associée à un et un seul login. Ainsi, il ne

devrait pas exister de comptes génériques, utilisés par

plusieurs utilisateurs.

Toutefois, pour traiter les cas où le principe n’est pas

respecté (besoins métiers), une procédure est mise en

place afin de recenser et justifier l’ensemble des

comptes et de faire valider la liste par le responsable

métier.

Les comptes de service (comptes applicatifs, réseau)

sont nécessaires mais ils ne doivent pas être utilisés en

transactionnel par des utilisateurs.

DS5

ISO 11

S’assurer que les

processus existants

permettent d’authenti-

fier tous les accès aux

programmes et aux

données.

Transactions non

autorisées par les

utilisateurs dont

l’accès n’a pas été

authentifié.

Vérifier que toute procédure de login

(application, système d’exploitation, base

de données) prévoit une authentification

par mot de passe ou est associée à une

authentification forte en accord avec la

politique de sécurité de l’information.

Systèm

e de gestion de certificats ou clés permettant

d'authentifier de façon unique un utilisateur, un système

ou une application.

Pour le cas des authentifications fortes, une politique

d'utilisation de dispositifs de cryptage pourra être

définie et implémentée. Par ailleurs, en cas de rupture

du service de PKI (private key infrastruc

ture), une procé-

dure dégradée, prévoyant des mécanismes d’autorisa-

tion, est prévue et mise en œuvre. Le service concerné

peut être rendu inaccessible.

Toutes les exigences de sécurité identifiées devraient

être satisfaites avant d'autoriser l'accès à l'information

par des tiers et être prises en compte dans les accords

correspondants.

Des méthodes d'authentification appropriées devraient

être utilisées pour contrôler l'accès des utilisateurs

distants.

La conformité du système d'information avec la poli-

tique de sécurité est vérifiée périodiquem

ent, les

rapports sont formalisés, datés et validés.

124

© CIGREF - IFACI

Processus

N° de

réf

COBIT

ISO

27001


Risque


Bonnes pratiques


DS5

ISO

11.2

& 11.6.1

S’assurer que le mana-

gem

ent applique les

procédures adéquates

pour la création, la modi-

fication ou la suppres-

sion des comptes

utilisateurs.

Absence d'assu-

rance que les accès

au système (appli-

cations, bases de

données et

systèm

es d'exploi-

tation) sont auto-

risés, appropriés et

valides.

Vérifier que les dem

andes d'attribution

de droits d'accès aux utilisateurs nécessi-

tent une autorisation préalable de la part

du managem

ent.

Le processus de création/modification de

comptes utilisateur inclut une étape de

validation du respect du référentiel de


S'assurer qu'il existe des contrôles

compensatoires pour les éventuelles

dérogations à la politique de séparation

des tâches ( Cf. flowchart « processus de

gestion d’attribution des droits d’accès »,

p. 121).

Vérifier qu’un processus de traitement

des cas d'urgence est identifié et

respecté.

Définition de profils donnant des droits d’accès ou asso-

ciés à un ensemble de transactions.

Attribution des droits d’accès après autorisation et en

fonction des besoins métier et des règles de séparation

des tâches.

Les cas de non-respect de la politique de séparation des

tâches devraient donner lieu à une correction immé-

diate ou à la documentation d'un contrôle compensa-

toire.

Analyse périodique et aléatoire des accès aux données

de production par les utilisateurs privilégiés et super

privilégiés.

Les procédures sont les mêm

es pour le personnel infor-

matique et pour les utilisateurs. Sur la base d'une

analyse de risque, l'entité peut décider d’inclure ou non

la validation des pouvoirs spéciaux (utilisateur privilégié

et super privilégié).

Une procédure particulière doit être mise en œuvre

pour s'assurer de la mise à jour des droits des utilisa-

teurs en cas de changem

ent de fonction ou de départ

de l'organisation. L'initiation de ces mises à jour pourra

être réalisée par le département RH.

DS5

ISO

11.2.4

S’assurer que le système

de revue périodique des

comptes et des accès est

opérationnel.

Existence de

comptes multiples

ou d’anciens droits

non compatibles

avec la séparation

des tâches.

Accès étendus qui

ne sont pas

couramment

utilisés.

Vérifier que la DSI adresse régulièrement

aux directions métiers des informations

sur les comptes et les droits d’accès à

leur système.

S’assurer que les directions métiers vali-

dent ces informations, notamment en ce

qui concerne la cohérence de l’affecta-

tion des profils et des rôles.

Vérifier que la DSI a mis en œuvre les

modifications apportées par les métiers.

La gestion d'une date de fin de validité des droits

d'accès pour les prestataires (si le systèm

e le permet)

permet de s'assurer périodiquem

ent que les utilisateurs

concernés ne disposent plus d'accès au système après

cette date.

125


© CIGREF - IFACI

ProcessusN° de

réf

COBIT

ISO

27001


Risque


Bonnes pratiques


DS5

ISO

10.1.3

Assurer la gestion de la

séparation des tâches et

des profils.

L’application du principe

de séparation des tâches

doit faire l’objet d’une

validation attentive

concernant les transac-

tions sensibles.

Non respect du

principe de sépara-

tion des tâches.

Vérifier qu’une analyse de risques a

permis d’identifier les comptes utilisateur

pour lesquels la validation du respect du

référentiel de séparation des tâches doit

exister.

Le contrôle de la séparation des tâches peut être

préventif, lors de la création ou de la modification, ou

détectif, via des revues périodiques.

Le contrôle préventif permet de réduire plus efficace-

ment l'exposition au risque de fraude qu'un contrôle

détectif.

DS5

ISO

11.2.2

& 11.5.4

Assurer la gestion des

comptes privilégiés et

super privilégiés et l’uti-

lisation des outils

systèm

e.

Changem

ents inap-

propriés de la confi-

guration du

systèm

e et des

données critiques.

Vérifier que les accès aux comptes privi-

légiés et super privilégiés (système d’ex-

ploitation, base de données et

applications) sont restreints au seul

personnel ayant l'autorisation de les

utiliser.

S’assurer que l'utilisation de programmes

capables d'outrepasser les contrôles

systèm

es et applicatifs est restreinte et

rigoureusement contrôlée.

Sur la base d'une analyse de risque, les accès à des trans-

actions sensibles sont soumis au mêm

e processus d’au-

torisation que le processus standard de gestion des

droits d’accès.

Les profils étendus ne sont pas accessibles en temps

normal.

La liste des utilisateurs ayant des droits étendus

(système et base de données) est révisée tous les mois.

DS5

ISO

10.1.4

Assurer la séparation des

infrastructures héber-

geant les activités de

développem

ent, de test

et d'opérations d'exploi-

tation courantes.

Perturbations de

service.

Accès non autorisé

au système.

Vérifier l’isolement des réseaux suppor-

tant l'activité des utilisateurs et des

opérations informatiques.

S’assurer que les systèm

es critiques sont

isolés dans un environnem

ent physique

et logique dédié.

La sélection des systèmes critiques s'appuiera sur le

résultat du processus de qualification des informations.

126

© CIGREF - IFACI

Processus

N° de

réf

COBIT

ISO

27001


Risque


Bonnes pratiques


DS5

ISO

12.6.1

Maîtriser les vulnérabi-

lités techniques.

Accès non autorisé

au système.

Indisponibilité du

systèm

e.

S'assurer que des tests d'intrusion sont

régulièrement mis en œuvre pour identi-

fier et réduire les zones de vulnérabilité

effectives.

Vérifier que les informations sur les

vulnérabilités techniques des systèmes

d'information sont obtenues à temps,

l'exposition de l'organisation à ces vulné-

rabilités évaluée, et les mesures appro-

priées mises en place.

Un dispositif de veille approprié doit être mis en place,

notamment concernant la stricte implémentation des

patches de sécurité recommandés par les constructeurs

et les fournisseurs de logiciels.

DS12

ISO

9.1.2

S’assurer que l’accès aux

salles informatiques est

restreint et que les

règles de sécurité sont

définies et respectées.

Pertes sur les

données critiques.

Vérifier que l’accès aux locaux informa-

tiques est contrôlé et qu’il existe un

processus d'autorisation.

La liste des personnes ayant accès aux

salles informatiques est revue périodi-

quem

ent et les corrections nécessaires

sont effectuées.

Lorsqu’il existe des dérogations aux poli-

tiques de gestion des accès, ces déroga-

tions sont documentées.

Les prestataires externes sont accompagnés lors de

leurs interventions.

La procédure traite des cas d'urgence.

La liste des accès est revue tous les mois, elle est datée

et signée par le manager approprié.

Des mesures spécifiques concernent les interventions

de la sécurité, de l'entretien de la DSI et du personnel

assurant la maintenance technique.

Tout équipem

ent sensible doit être hébergé dans une

salle informatique appropriée.

DS5

ISO

10.1.1

& 10.1.2

S’assurer de la docu-

mentation des opéra-

tions d'exploitation et

de gestion des change-

ments.

L'erreur pouvant

entraîner l'indispo-

nibilité du système

ou l'altération de

données.

Vérifier que les procédures opération-

nelles sont documentées, maintenues et

rendues disponibles à tous les utilisa-

teurs qui en ont l'utilité.

S’assurer que les changem

ents effectués

sur les infrastructures sont contrôlés et

qu’ils peuvent être tracés.

Stan

dard Ope

rating

Procedu

re(SOP)

Les procédures standard permettent d'assurer la trans-

mission des pratiques à de nouvelles équipes, notam-

ment à des équipes externes intervenant en cas de crise.

Elles favorisent la continuité de service.

127


© CIGREF - IFACI

ProcessusN° de

réf

COBIT

ISO

27001


Risque


Bonnes pratiques


DS5

ISO

10.4.1

Protéger l'intégrité de

l'information en limitant

notamment la propaga-

tion de code malveillant.

Vulnérabilité à la

modification, à la

destruction, à l'in-

disponibilité ou au

vol des informa-

tions hébergées.

Des contrôles de détection, de préven-

tion et de rétablissement sont mis en

place pour se protéger des codes

malveillants.

Vérifier l’existence et la mise en œuvre de

procédures d'information des utilisa-

teurs.

Un dispositif antivirus devrait être installé sur l'ensemble

des postes de travail de tous les utilisateurs et sur l'en-

semble des serveurs.

Pour disposer de la base de signature anti virale la plus

large, le recours à plusieurs éditeurs de solution est

conseillé.

Un dispositif permettant la détection de transactions ou

d'échanges de données non autorisés devrait être mis

en place, notamment au niveau des passerelles entre le

réseau d'entreprise et Internet (web et messagerie).

DS5

ISO

10.7.2

Maîtriser la confidentia-

lité des données lors de

la mise au rebut d'un

matériel de stockage.

La présence de

données résiduelles

sur les supports de

stockage peut

entraîner la divul-

gation d'informa-

tions.

Les supports de stockage de données

devraient être mis au rebut de manière

certaine et sûre lorsqu'ils ne sont plus

utiles, en respectant des procédures

formelles de destruction définitive des

données contenues.

Cette activité est liée à la notion de classification de l’in-

formation.

Cet aspect doit égalem

ent être pris en compte lors de

prêt de matériel dont les dispositifs de stockage doivent

faire l'objet de nettoyage préalable.

DS5

ISO

10.8.4

Maintenir la sécurité de

l'information échangée à

l'intérieur de l'organisa-

tion ou avec une entité

externe.

La transmission

d'informations

sensibles par

messagerie électro-

nique, en particulier

via Internet, peut

entraîner leur divul-

gation.

L'information contenue dans les

messages électroniques devrait être

convenablement protégée.

Chiffrer les fichiers sensibles échangés.

Signature par l’entité externe d’accords de confidentia-

lité (Non

Disclosure Agreemen

t).

128

© CIGREF - IFACI

Processus

N° de

réf

COBIT

ISO

27001


Risque


Bonnes pratiques


DS5

ISO

10.10.1

Permettre la détection

d'activités de traitement

de l'information non

autorisées et tracer les

incidents de sécurité.

Sans consignation

des évènem

ents

liés à un système, la

traçabilité des

opérations ou des

accès effectuées sur

ce système n'est

pas assurée.

Les journaux contenant l'enregistrem

ent

des activités des administrateurs du SI,

des utilisateurs, les exceptions, les erreurs

et les évènem

ents de sécurité de l'infor-

mation devraient être produits et

conservés pour une période prédéfinie

par l’organisation.

S’assurer que les traces (log) font l'objet

d'analyse régulière, notamment sur les

transactions dites "sensibles".

Vérifier que les évènem

ents journalisés

sont régulièrement revus et analysés.

Les équipem

ents de journalisation et les évènem

ents

consignés devraient être protégés contre les accès non

autorisés et les falsifications.

Les erreurs et les évènem

ents de sécurité doivent

déclencher des actions appropriées de traitement des

incidents.

Les horloges de tous les systèm

es de traitement de l'in-

formation journalisés devraient être synchronisées sur

une source de temps précise et agréée.

DS5

ISO

11.5.5

& 11.5.6

Limiter les risques

d'accès non autorisés à

un système laissé sans

surveillance.

Sans lim

itation de

la durée du temps

de connexion, une

session active peut

être utilisée pour

accéder à une

application sensible

par une personne

non autorisée.

Les sessions inactives devraient être

désactivées automatiquem

ent après une

période définie d'inactivité.

Des restrictions du temps de connexion

devraient être utilisées pour fournir un

niveau de sécurité additionnel pour les

applications les plus sensibles.

Ces principes concernent les accès au réseau et les accès

aux applications.

129


© CIGREF - IFACI

5.10. Gestion de la sous-traitance et infogérance

Si la gestion de la sous-traitance est une problématique générale d’entreprise, elle doit faire l’objetd’une gouvernance spécifique au sein de l’informatique, compte tenu de son poids élevé, de sonextension à quasiment tous les domaines, et de la complexité des contrats, alors même que croîtcontinûment la criticité du SI dans le fonctionnement global de l’entreprise ou de l’administration.En effet, la sous-traitance informatique est passée d’un mode d’achat de prestations avec obliga-tion de moyens (jadis appelée régie) vers un mode d’achat de services avec obligation de résultats(par exemple, pour les projets d’intégration de systèmes ou d’infogérance récurrente).

Parallèlement à cette évolution, s’ajoute le phénomène de délocalisation qui, au-delà des effets demode, peut générer de véritables opportunités en matière de réduction des coûts, à condition deconsidérer de façon globale et transparente les problèmes des différences culturelles, des barrièreslinguistiques, des fuseaux horaires, des distances géographiques, voire des expertises techniques,et d’intégrer leur résolution dans la construction des solutions envisagées.

C’est pourquoi, la maîtrise de la sous-traitance est devenue une préoccupation essentielle des DSI,dans l’accomplissement de l’ensemble de leur mission qui vise à concevoir, maintenir et exploiterdes systèmes complexes, répondant aux besoins des métiers au meilleur rapport qualité/coût. Lasous-traitance moderne s’étend donc à tous les processus de production des systèmes d’informa-tion, depuis la réalisation des projets jusqu’à la maintenance et l’exploitation des systèmes, tout enintégrant les aspects de sécurité et de performance.

La gestion de la sous-traitance se fonde sur quatre préalables : un schéma directeur des SI, unepolitique RH SI, une politique globale d’achats, et une identification des niveaux de service (per-formance et continuité de fonctionnement) nécessaires aux métiers. Leur combinaison débouchesur la mise en place de contrats de service internes, d’une stratégie « make or buy » et d’un proces-sus de « sourcing » : on y inclut la sélection des prestataires, la signature des contrats, et le suivi deleur exécution, trois composantes majeures du pilotage de la performance de la sous-traitance.

130

© CIGREF - IFACI

5.10.1.Flowchart du processus de gestion de la sous-traitance

Sou

s-p

roce

ssu

s : P

olit

iqu

e, s

trat

égie

et

pro

cess

us

d’a

chat

Réalisation d’une veille marché :

offres, fournisseurs

Réalisation d’un retour d’expérience annuel sur grands

fournisseurs

Définition, mise à jour et partage d’une

stratégie de sourcing SI

Définition, mise à jour et partage d’un

processus de sourcing SI

Définition, mise à jour et partage des trames de contrats et des processus

de pilotage des sous-traitants SI

Signature des contrats conformément à la stratégie, processus de sourcing et aux

besoins métiers exprimés

Veilleréglementaireinformatique

Reporting nouvelles tendances

REX annuel grands

fournisseurs

Politique SI RH

Schéma directeur SI

Groupe

Politique achats Groupe

Stratégie de sourcing SI

processus de sourcing SI

Trames decontrats /

procédures de pilotage

Contrats fournisseurs

Réalisation d’une veille marché :


Réalisation d’un retour d’expérience

annuel sur grandsfournisseurs

Définition, mise à jour et partage d’une

stratégie de sourcing SI

Définition, mise à jour et partage d’un processus de sourcing SI

Définition, mise à jour et partage des trames de contrats et des processus

de pilotage des sous-traitants SI

Signature des contrats conformément à la stratégie, processus de sourcing et aux

besoins métiers exprimés

Responsabilité partagée avec la fonction Achats

DSI Sécurité des SI Études Production Juridique Achats

Activité

Décision

Livrable

Légende

131


© CIGREF - IFACI

DSI Sécurité des SI Études Production Juridique Achats

Sou

s-p

roce

ssu

s : e

xécu

tio

n d

es c

on

trat

s

Validation autorisation d’accès avec les profils et les ressources

Analyse de la Qualité de service

Analyse de la conformité des livrables des prestations au contrat, analyse facturation

Sou

s-p

roce

ssu

s : p

ilota

ge

des

co

ntr

ats

Mise à jour, archive et portage des contrats

Clarification par contrat de la structure de pilotage par domaine

Pilotage des contrats tiers par domaine (opérationnel, financier, contractuel, juridique) y compris des avenants

Gestion de la réversibilité du contrat

Analyse du reporting fournisseur

Mise à jour, archive et portage des contrats

Clarification par contrat de lastructure de pilotage par

domaine

Convention de service, plan de

réversibilité, plan de sécurité, plan

d’assurance qualité et accord de

confidentialité

Plan d’actions priorisées

Reporting sur écarts

éventuels, position sur facturation

Reporting sur écarts

éventuels


Accès autorisé au sous-traitant

Reporting global

Passageavenants

Contratsfournisseurs

Diffusion etarchivagecontrats


Procédures

Validation conjointe d’une convention de service, plan d’assurance qualité, plan de réversibilité et accords de confidentialité

Légende

Activité

Décision

Livrable

132

© CIGREF - IFACI

5.10

.2.R

ACI du processus de sous-traitance

Etapes-clés

du processus

DSI

Sécurié des SI

Etudes

Production

Juridique

Achats


Commentaires

Processus : stratégie et processus de sourcing SI

Réalisation d'une veille

marché : offres, fournisseurs

AC

RReporting sur nouvelles tendances,


Les managers informatiques (sous responsabilité

DSI), contribuent à cette veille via leurs contacts.

Réalisation d'un retour

d'expérience annuel des

grands fournisseurs

AC

RRetour d’expérience annuel grands

fournisseurs

Les managers des différentes entités sous la

responsabilité DSI, contribuent au retour

d’expérienceau travers des prestations dont ils

avaient la responsabilité du pilotage.

Définition, mise à jour et

partage d'une stratégie de

sourcing SI

AR

Stratégie de sourcing SI


portage d'un processus de

sourcing

AC

RProcessus de sourcing SI


partage de trame de contrats

et des processus de pilotage

des sous-traitants SI

AC

CR

Tram

es de contrats et procédures de

pilotage des sous-traitants SI

Les managers informatiques (sous la responsabilité

DSI), contribuent à l'établissement / mise à jour des

processus de pilotage des sous-traitants au travers

des retours d'expérience réalisés sur le pilotage des

prestations dont ils ont la responsabilité. Les

accords de confidentialité peuvent être proposés

dès cette étape.

Signature des contrats

conformément à la stratégie,

au processus de sourcing et

aux besoins Métiers

exprimés

AC

CR

Contrats établis conformém

ent à la

politique de sourcing et aux besoins

Métiers

Les managers informatiques (sous la responsabilité

DSI), contribuent au passage des contrats, lesquels

sont validés par le niveau ayant le pouvoir

d'engagem

ent financier adéquat.

133


© CIGREF - IFACI

Etapes-clés

du processus

DSI

Sécurié des SI

Etudes

Production

Juridique

Achats


Commentaires

Processus : exécution des contrats

Validation conjointe d’une

convention de service, d'un

plan de réversibilité, d'un

plan de sécurité, d'un plan

d’assurance qualité et

accords de confidentialité

AR

RR

CC

Convention de service, plan de

réversibilité, plan de sécurité, plan

d'assurance qualité validés

Accords de confidentialité signés

Validation autorisation

d'accès avec les profils et les

ressources

AR

CC

Accès autorisé au sous-traitant

Analyse de la qualité de

service fournisseur

AA

CPlan d'action priorisé pour anticiper

/ remédier aux éventuels

dysfonctionnem

ents

Analyse de la conformité des

livrables au contrat, analyse

facturation

ARC

RR

Reporting sur écarts éventuels avec

étude d'impact et plan d'action

Position sur facturation

134

© CIGREF - IFACI

Etapes-clés

du processus

DSI

Sécurié des SI

Etudes

Production

Juridique

Achats


Commentaires

Processus : pilotage des contrats

Mise à jour, archivage et

portage des contrats

AI

IR

CDiffusion de la liste des contrats

cadres

Archivage des contrats

Clarification par contrat de la

structure de pilotage par

domaine

AC

CR

CDocumentation et portage de la

structure de pilotage

Pilotage des contrats tiers

par domaine (opérationnel,

financier, contractuel,

juridique) y compris des

avenants

AC

RR

RR

Reporting global intégrant avenants

et plan d'actions associé

Avenants contrat

Gestion de la réversibilité du

contrat

AC

CR

CDéfinition et suivi du processus de

réversibilité

135


© CIGREF - IFACI

5.10

.3.Matrice risques/con

trôles du processus de sous-traitance

Processus

Etapes-clésN° de

réf

COBIT


Risque


Bonnes pratiques

Stratégie et processus de sourcing

Veille marché :offres, fournisseurs

DS2 :

gérer

les

services

tiers

S'assurer de l'existence

d'un processus apprio-

prié de veille du

marché.

Veille inappropriée

ou inexistante.

Revue de l'existence d'une non veille

fournisseurs.

Mesure de satisfaction des managers

des livrables fournis par le processus de

veille fournisseurs.

Existence d'un processus de veille qui permette d'an-

ticiper des ruptures dans tous les domaines SI perti-

nents au regard des enjeux Métiers.

90% des managers sont satisfaits des livrables fournis

par le processus de veille fournisseurs.

Retour d'expérience desgrands fournisseurs


et de la pertinence des

retours annuels grands

fournisseurs réalisés.

Retours d'expé-

riences inexistants

ou inadéquats.

Revue de l'existence d'un retour d'ex-

périence annuel par grand fournisseur,

qui tient compte des réserves majeures

émises et des litiges.

Existence de retours d'expérience annuels réalisés sur

l'ensemble des grands fournisseurs et synthétisant de

façon objective les forces et fragilités décelées sur la

base d'un système de notation partagé.

Stratégie desourcing SI

S'assurer de l’existence,

de la mise à jour et d'un

partage d'une stratégie

de sourcing SI, alignée

avec le schém

a direc-

teur SI Groupe, la poli-

tique SI RH et la

politique achats.

Stratégie de sour-

cing SI inadéquate

ou inexistante.

Stratégie de sour-

cing SI non

partagée.

Revue de l'existence d'une stratégie de

sourcing SI , répondant aux points

majeurs suivants :

•alignem

ent avec les besoins du

schém

a directeur SI Groupe, la poli-

tique SI RH définissant les activités à

externaliser, la politique achats ;

•clarification par domaine, des spécifi-

cités d'achat (prestation clé en main,

partenariat), de la liste de fournis-

seurs, des besoins à couvrir... ;

•validation par les mem

bres

adéquats: DSI, Dir achat, Dir RH.

Mesure de l'appropriation de cette stra-

tégie par les managers de la DSI.

Existence d'une stratégie de sourcing formalisée,

correctement validée et mise à jour avec les besoins

du schém

a directeur SI Groupe et anticipant les

besoins, de façon à garantir une massification et des

conditions d'achats plus attractives.

Stratégie de sourcing connue de l'ensemble des

acteurs concernés.

136

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques


Processus de sourcing

DS2 :

gérer

les

services

tiers

S'assurer de l'existence,

de la mise à jour d'un

processus de sourcing

SI adéquat et de son

portage.

Processus de sour-

cing inadéquat,

non partagé.


sourcing SI clarifiant comment se fait

l'identification du besoin, les règles de

mise en concurrence, l'analyse des

offres, la traçabilité de la phase de déci-

sion (acteurs impliqués et en ligne avec

les processus d’achat).

Mesure de l'appropriation des acteurs

impliqués dans sa mise en œuvre.

Existence d'un processus de sourcing SI formalisé et

déclinant la politique d'achat de l'entreprise ou de

l'administration.

Appropriation de la politique de sourcing SI par l'en-

semble des acteurs concernés.

Trames de contrats et processus de pilotage dessous-traitants SI


et d'un partage de

tram

es de contrats

adaptés reprenant le

processus de pilotage

des sous-traitants.

Tram

es de contrats

de sous-traitance

inadaptés aux

contraintes du

donneur d'ordres.

Pilotage inappro-

prié du sous-trai-

tant.

Revue de l'adéquation des contrats

types vis-à-vis de la prise en compte de

l'ensemble des exigences règlemen-

taires et propres au donneur d'ordres

(droit d'auditer, normes de développe-

ment...) et des processus et règles

(procédures de sécurité...).

Revue de la validation des trames de

contrats par les parties concernées

(opérationnelles, achats, juridiques,

sécurité...).

Revue de la connaissance des trames

de contrats et des processus de pilo-

tage du contrat sous ses différents

aspects (création, maintenance, surveil-

lance, renégociation) par les acteurs qui

en ont la charge.

Adéquation du processus de pilotage pour m

aîtriser

le sous-traitant et de la mise à jour sur la base de

retours d'expérience consolidés.

Existence de tram

es de contrats assurant une relation

équilibrée entre le donneur d'ordre et le sous-traitant

et enrichis sur la base de retours d'expérience conso-

lidés.

Appropriation des processus de pilotage par les

acteurs concernés.

137


© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques


Signature des contrats

DS2 :

gérer

les

services

tiers

S'assurer que la poli-

tique de sourcing est

correctement implé-

mentée à l'occasion de

chaque nouveau

contrat passé et tient

compte des engage-

ments de service

dem

andés par les

métiers.

Implémentation

inadéquate de la

politique de sour-

cing.

Non implémenta-

tion des niveaux

de service

dem

andés par le

métier.

Rapprochem

ent de toutes les factura-

tions d'un contrat.

Revue de la conformité des contrats

passés à la stratégie et au processus de

sourcing en place par les différents

acteurs concernés : DSI/responsable

achats/responsable RH.

Revue de la prise en compte des

besoins métiers pour définir le niveau

de service attendu.

Pas d'engagem

ent d'une prestation par un sous-trai-

tant, sans la signature d'un contrat par les 2 parties.

Conformité des contrats signés aux tram

es de

contrats, sauf dérogation dûment justifiée.

Utilisation autant que faire se peut des contrats

cadres en vigueur pour optimiser les coûts.

Correcte déclinaison des SLA métier en OLA à chaque

niveau de la chaîne, de façon à garantir une correcte

implémentation des besoins métiers.

Exécution des contrats tiers

Convention de service, (SLA), plan d'assurance qualité, plande réversibilité, plan de sécurité et accords de confidentialité

S'assurer de l'existence :

•d'une convention de

service, d'un plan de

réversibilité, d'un

plan de sécurité et

d'un plan d'assurance

qualité validé par les

deux parties ;

•d'accords de confi-

dentialité signés par

le sous-traitant,

répondant aux

exigences du client.

Non clarification

d'une convention

de service, d'un

plan de réversibi-

lité, d'un plan de

sécurité et d'un

plan d'assurance

qualité.

Des garanties en

termes de non-

divulgation non

définies.

Revue des éléments associés au

contrat: existence d'une convention de

service, d'un plan de réversibilité, d'un

plan de sécurité, d'un plan d'assurance

qualité et d'accords de confidentialité

signés.

Existence d'une convention de service, d'un plan de

réversibilité, d'un plan de sécurité et d'un plan d'assu-

rance qualité établis avant signature du contrat et

répondant à l'ensemble des exigences du client.

Existence d'un contrat signé avant dém

arrage.

Accords de confidentialité signés dès l'engagem

ent

du contrat.

138

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques

Exécution des contrats tiers

Autorisationd'accès

DS2 :

gérer

les

services

tiers

S'assurer que les autori-

sations d'accès sont

conformes au dispositif

de gestion des habilita-

tions en place.

Risque d'intrusion

dans le SI du

donneur d'ordre.

Revue des autorisations d'accès, qui

doivent être formalisées et respecter le

dispositif de gestion des habilitations

en vigueur.

Autorisations d'accès restreintes au seul besoin de la

prestation, nominatives et supprimées en fin de pres-

tation.

Qualité de service

S'assurer de la confor-

mité du reporting par

rapport aux engage-

ments : suivi et respect

des objectifs, solution

de contournem

ent si

besoin...

Reporting

manquant ou ne

permettant pas

d'anticiper les

dérives à venir.

Revue de l'existence de reporting

conforme aux engagem

ents et permet-

tant d'anticiper les dérives.

Existence et adéquation des reportings, pour anti-

ciper toute dérive dans l'exécution du contrat.

Existence dans le reporting d'un volet risques mis à

jour en termes de maîtrise vis-à-vis des risques dont

le sous-traitant est propriétaire.

Conformité des livrables aux engagementsAnalyse de la facturation

S'assurer de la confor-

mité des livrables aux

engagem

ents contrac-

tuels : documentations,

programmes… et

adéquation de la factu-

ration par rapport aux

contrats et aux livra-

bles.

Manque de qualité

des livrables, non

respect des délais,

non conformité

aux spécifications,

risque financier.

Revue de l'existence de contrôles inter-

médiaires conformém

ent aux engage-

ments dans la production des livrables.

Revue de la validation des facturations

en fonction du contrat et des livrables.

Existence d'un processus formalisé et mis en œuvre

permettant, au cours de la réalisation du contrat, d'ap-

précier l'adéquation des livrables par rapport aux

objectifs définis et de la facturation associée.

Mise en place de retours d'expérience formalisés sur

la qualité de la prestation et les litiges fournisseurs.

139


© CIGREF - IFACI

Processus

Etapes-clésN° de

réf

COBIT


Risque


Bonnes pratiques


Contrats

DS2 :

gérer

les

services

tiers


d'une liste de contrats à

jour et d'un archivage

adapté des engage-

ments fournisseurs.

Mauvaise décli-

naison des trames

de contrats

conclus.

Mauvaise maîtrise

des contrats.

Revue d'une mise à jour au fil de l'eau

de la liste des contrats cadres conclus

et d'une correcte diffusion.

Identification des contrats n'utilisant

pas de contrats cadres et contrôle

d'une validation managériale adéquate

associée.

Revue de la connaissance des engage-

ments fournisseurs par les acteurs assu-

rant le pilotage du contrat.

Mise à jour au fil de l'eau de la liste des contrats

cadres conclus et d'une correcte diffusion.

Identification des contrats n'utilisant pas de contrats

cadres et contrôle d'une validation managériale

adéquate associée.

Connaissance par l'ensemble des acteurs concernés

de la liste des contrats cadres.

Existence d'une présentation, dès engagem

ent du

contrat des engagem

ents contractuels à l'ensemble

des acteurs en charge du pilotage.

Structure de pilotagepar domaine

S'assurer que les

acteurs en charge du

pilotage du contrat

sont correctement

définis et acceptent

leur m

ission.

Structure de pilo-

tage insuffisam

-ment clarifiée.

Revue de l'existence dans le contrat

d'une disposition clarifiant les rôles et

responsabilités des acteurs du pilotage

et accepté par les acteurs concernés.

Existence d'un document formalisant la structure de

pilotage de chaque contrat, dès le début de la

mission, la gestion des interfaces et les modes d'arbi-

trage si besoin.

Partage de ce document par les acteurs concernés.

140

© CIGREF - IFACI

Processus

Etapes-clés

N° de

réf

COBIT


Risque


Bonnes pratiques


Pilotage des contrats tiers par domaine (opérationnel,financier, contractuel, juridique) incluant avenants

DS2 :

gérer

les

services

tiers

S'assurer d'un pilotage

des contrats tiers sous

les angles opérationnel,

financier, contractuel,

juridique et des

avenants associés.

Non maîtrise du

sous-traitant.

Revue d'un pilotage périodique du

contrat et de ses avenants sous les

différents angles lors des comités de

pilotage du sous-traitant au travers des

comptes-rendus établis.

Réalisation d'audits de sécurité et de

réversibilité.

Revue du respect des clauses d'ave-

nants passés.

Existence de comptes-rendus formalisés des réunions

tenues entre les acteurs de pilotage et si besoin arbi-

trées, indiquant la position à tenir en préalable aux

comités de pilotage du sous-traitant.

Pilotage périodique du contrat et de ses avenants

sous les différents angles lors des comités de pilotage

du sous-traitant, avec décisions tracées dans les

comptes-rendus établis.

Réalisation d'audits de sécurité, de réversibilité.

Avenants passés avant engagem

ent de toute presta-

tion complémentaire et clarification des préséances

vis-à-vis des clauses juridiques entre contrat de base

et les différents avenants.

Pour les contrats d'infogérance, mise en œuvre des

clauses de benchmarking.

Réversibilité du contrat

S'assurer de la défini-

tion d'un processus de

réversibilité, de l'esti-

mation de son coût, de

la capacité de l'organi-

sation à réaliser cette

réversibilité, des condi-

tions de reprise des

outils, de documenta-

tions…

Mauvaise gestion

de la réversibilité.


réversibilité associé à chaque contrat

clé. Revue d'une appréhension de sa

faisabilité dès que des signaux faibles

persistants apparaissent. Revue des

conditions de déclenchem

ent,

lesquelles font l'objet d'une validation

formelle par le niveau hiérarchique

dûment approprié.

Existence d'un plan de réversibilité associé à chaque

contrat clé...

Existence d'un suivi périodique de son applicabilité.

Existence d'un suivi continu d’une anticipation des

dérives pour prévoir des périodes où pourraient

survenir des conditions nécessitant une réversibilité.

Existence d'une étude d'impact dûment approuvée

avant déclenchem

ent de la réversibilité. Prise en

compte de l'étude d'impact dans la définition de la

solution de réversibilité.

141


© CIGREF - IFACI

6. ANNEXES

6.1. Annexe 1 – Charte CIGREF – IFACI ................................................................... 142

6.2. Annexe 2 - Organismes et référentiels liés au contrôle interne ....................... 143

6.3. Annexe 3 - Tableau de concordance entre les processus et les objectifs de

contrôle du cadre de référence de contrôle interne de l’AMF .......................... 144

6.4. Annexe 4 – Exemples de typologies de risques .................................................. 147

6.5. Glossaire ................................................................................................................ 149

143


© CIGREF - IFACI

6.2.

Annexe 2 - Organ

ismes et référentiels liés au con

trôle interne

Co

mp

tab

ilité

Au

dit

ext

ern

e /

CA

CC

on

trô

lein

tern

eA

ud

it in

tern

eA

ud

it

info

rmat

iqu

eIn

form

atiq

ue

Rég

ula

tio

n

Org

anis

mes

IASB

IFA

CC

OSO

IIAIS

AC

A

Réfé

ren

tiel

s

IFRS

Fin

anci

alR

apo

rtin

gA

ud

itin

g &

Ass

ura

nce

Inte

rnal

Co

ntr

ol

Fram

ewo

rk(C

OSO

1)

ERM

Fram

ewo

rk(C

OSO

2)

IPPF

(GTA

G, G

AIT

)

ITA

F (IT

assu

ran

cefr

amew

ork

)C

OB

ITVA

L IT

Bâl

e 2

Solv

ency

Org

anis

mes

Au

tori

té d

e N

orm

esC

om

pta

ble

sC

SOEC

HC

CC

CN

CC

IFA

CI

AFA

IC

IGRE

FA

MF

Au

tori

té d

eC

on

trô

lePr

ud

enti

el(b

anq

ue,

assu

ran

ce)

Réfé

ren

tiel

s

Plan

co

mp

tab

leg

énér

alN

orm

esd

'exe

rcic

ep

rofe

ssio

nn

el

Le c

on

trô

lein

tern

e d

u S

IC

adre

de

réfé

ren

ced

e co

ntr

ôle

inte

rne

CRB

F 97

-02

International France

« Le

co

ntr

ôle

inte

rne

du

SI

des

org

anis

atio

ns

»


144

ANNEXES

© CIGREF - IFACI

6.3. Annexe 3 - Tableau de concordance entre les processus et lesobjectifs de contrôle du cadre de référence de contrôle interne del’AMF

Objectifs dudispositif

Compétences

Projet et

développement

Maintenance

Incidents

Sécurité

Sous-traitance

Conformité auxlois et

règlements

« Les lois et les règlements en vigueur fixent desnormes de comportement. »« être informée en temps utile desmodifications »« connaître les diverses règles … applicables. »

« transcrire ces règles dans les procéduresinternes.»« informer et former les collaborateurs sur cellesdes règles qui les concernent. »

Application desinstructions etdes orientationsfixées par laDirection

Générale ou leDirectoire

« permettent aux collaborateurs de comprendrece qui est attendu d’eux et de connaîtrel’étendue de leur liberté d’action. »

« communiquées aux collaborateurs concernés,en fonction des objectifs assignés.»

« établies en fonction des objectifs poursuivispar la société et des risques encourus. »

Bonfonctionnementdes processusinternes de lasociété

notamment ceuxconcourant à lasauvegarde des

actifs

« exige que des normes ou principes defonctionnement aient été établis. »

« des indicateurs de performance et derentabilité aient été mis en place. »

Concerne aussi les « actifs incorporels » telsque le savoir-faire.

« ces actifs peuvent disparaître à la suited’erreurs ou résulter d’une mauvaise décision degestion. »

Fiabilité desinformationsfinancières

« procédures de contrôle interne susceptibles desaisir fidèlement toutes les opérations. »

« séparation des tâches qui permet de biendistinguer les tâches d’enregistrement, les tâchesopérationnelles et les tâches de conservation. »

« identifier les origines des informationsproduites, et leurs destinataires. »

« les opérations sont effectuées conformémentaux instructions générales et spécifiques. »

145


© CIGREF - IFACI

Composante ducadre deréférence

Compétences

Projet et

développement

Maintenance

Incidents

Sécurité

Sous-traitance

Préalables

« Les grandes orientations en matière decontrôle interne sont déterminées. »

« fondé sur des règles de conduite et d’intégritéportées par les organes de gouvernance etcommuniquées à tous les collaborateurs. »

Organisationappropriée

« une organisation appropriée qui fournit lecadre dans lequel les activités nécessaires à laréalisation des objectifs sont planifiées,exécutées, suivies et contrôlées. »

« Des responsabilités et pouvoirs clairementdéfinis »

« respecter le principe de séparation destâches ».

« une politique de gestion des ressourceshumaines qui devrait permettre de recruter despersonnes possédant les connaissances etcompétences nécessaires à l’exercice de leurresponsabilité et à l’atteinte des objectifs actuelset futurs de la société. »

« des systèmes d’information adaptés auxobjectifs actuels de l’organisation et conçus defaçon à pouvoir supporter ses objectifs futurs »

Gouvernance des SI non approfondiedans les travaux

Des systèmes d’information « protégésefficacement tant au niveau de leur sécuritéphysique que logique. »

« la conservation des informations stockées. »

La « Continuité d’exploitation doit être assuréeau moyen de procédures de secours ».

« les informations relatives aux analyses, à laprogrammation et à l’exécution des traitementsdoivent faire l’objet d’une documentation. »

« des procédures ou modes opératoires quiprécisent la manière dont devrait s’accomplirune action ou un processus. »

« des outils ou instruments de travail qui doiventêtre adaptés aux besoins de chacun et auxquelschaque utilisateur devrait être dûment formé »

146

ANNEXES

© CIGREF - IFACI

Composante ducadre deréférence

Compétences

Projet et

développement

Maintenance

Incidents

Sécurité

Sous-traitance

Diffusiond’informationspertinentes

« assurent la communication d’informationspertinentes, fiables, et diffusées en tempsopportun. »

« permettre d’exercer leurs responsabilités »

Système derecensement etd’analyse desrisques

« un système visant à recenser, analyser lesprincipaux risques identifiables au regard desobjectifs de la société et à s’assurer del’existence de procédures de gestion de cesrisques. »

Activités decontrôle

proportionnées

« des activités de contrôle proportionnées auxenjeux propres à chaque processus, etconçues pour s’assurer que les mesuresnécessaires sont prises en vue de maîtriser lesrisques susceptibles d’affecter la réalisationdes objectifs. »

« les activités de contrôle doivent êtredéterminées en fonction de la nature desobjectifs auxquels elles se rapportent et êtreproportionnées aux enjeux de chaqueprocessus. »

« une attention particulière devrait êtreportée aux contrôles des processus deconstruction et de fonctionnement dessystèmes d’information. »

SurveillancePermanente

« une surveillance permanente portant sur ledispositif de contrôle interne ainsi qu’unexamen régulier de son fonctionnement. »

Gouvernance des SI non approfondiedans les travaux.Responsabilités des principaux acteurs(DG, CA, AI, DSI, Direction métiers) àdéfinir.

« Cette surveillance prend notamment encompte l’analyse des principaux incidentsconstatés. »

« Surveillance et veille conduise, si nécessaire,à la mise en œuvre d’actions correctives et àl’adaptation du dispositif de contrôle interne »

147


© CIGREF - IFACI

6.4. Annexe 4 – Exemples de typologies de risques

Figure 31 : Modèle de risques économiquesSource : World Economic Forum - 2006

Figure 32 : Nouvelle taxonomie des risquesSource : Marsh Insurance – Repenser le risque - 2004

Economic Societal Environmental Technological Geopolitical

• Oil prices/Energy• Assetprices / indebted-ness

• Coming fiscalcrisis

• China• Critical infrastruc-tures

• Regulation• Corporate Gover-nance

• IntellectualProperty Rights

• Organized Crime• Global pande-mics

• Slow and chronicdiseases (indus-trialized world)

• Epidemic disease(developingworld)

• Liability regimes

• Tropical cyclones• Earthquakes• Climate change• Loss ofecosystemservice

• Convergence oftechnologies

• Nanotechnology• Electromagneticfields

• Pervasivecomputing

• Terrorism• European dislo-cation

• Current andfuture hotspots

Hazard Financial Operational Organizational Strategic

• Property/Casualty

• Political• Environmental• Regulatory

• Currency• Interest rate• Commodityprices

• Credit

• Inventory• Supply chain• Capacity• Informationsystems

• Governance gaps• Wrong organiza-tional structure

• Talent/Morale• M&A integration

• Technology• Brand collapse• One-of-a-kindcompetition

• Industryecono-mics collapse

• Customer shift• New project /investment

• Stagnation• Obsolete busi-ness design

148

ANNEXES

© CIGREF - IFACI

Article 4 du Règlement n° 97-02 du 21 février 1997

Typologie des risques relatifs au contrôle interne des établissements de crédit et des entreprisesd’investissement.

Risque Descriptif

Risque de crédit Le risque encouru en cas de défaillance d’une contrepartie.

Risques de marché Comprend le risque de change

Risque de taux d’intérêtglobal

Le risque encouru en cas de variation des taux d’intérêt du fait de l’ensembledes opérations de bilan et de hors-bilan, à l’exception, le cas échéant, desopérations soumises aux risques de marché mentionnés ci-dessus.

Risque de liquiditéLe risque pour l’entreprise assujettie de ne pas pouvoir faire face à sesengagements ou de ne pas pouvoir dénouer ou compenser une position enraison de la situation du marché.

Risque de règlement

Le risque encouru au cours de la période qui sépare le moment où l’instructionde paiement ou de livraison d’un instrument financier vendu ne peut plus êtreannulée unilatéralement et la réception définitive de l’instrument financieracheté ou des espèces correspondantes.

Risque opérationnel

Le risque résultant d’une inadaptation ou d’une défaillance imputable à desprocédures, personnels et systèmes internes ou à des événements extérieurs ycompris d’événements de faible probabilité d’occurrence mais à fort risque deperte.

Risque juridiqueLe risque de tout litige avec une contrepartie, résultant de toute imprécision,lacune ou insuffisance susceptible d’être imputable à l’entreprise au titre de sesopérations.

Perte potentiellemaximale

La mesure de l’impact le plus défavorable sur les résultats de variations desconditions de marché intervenant sur une période donnée et avec un niveau deprobabilité déterminé.

Risqued’intermédiation

Le risque de défaillance d’un donneur d’ordres ou d’une contrepartie àl’occasion d’une transaction sur instruments financiers dans laquelle l’entrepriseassujettie apporte sa garantie de bonne fin.

Risque de non-conformité

Le risque de sanction judiciaire, administrative ou disciplinaire, de pertefinancière significative ou d’atteinte à la réputation, qui naît du non-respect dedispositions propres aux activités bancaires et financières, qu’elles soient denature législatives ou réglementaires, ou qu’il s’agisse de normesprofessionnelles et déontologiques, ou d’instructions de l’organe exécutif prisesnotamment en application des orientations de l’organe délibérant.

149


© CIGREF - IFACI

6.5. Glossaire

Certaines définitions sont inspirées de Wikipedia

Activité de contrôle : « proportionnées aux enjeux propres à chaque processus, et conçues pours’assurer que les mesures nécessaires sont prises en vue de maîtriser les risques susceptiblesd’affec ter la réalisation des objectifs » (cf. Cadre de Référence AMF).

AMF (Autorité des Marchés Financiers) : Instaurée par la loi du 1er août 2003, l’AMF est le résul-tat de la fusion de trois anciennes autorités des marchés financiers : le CMF (Conseil des MarchésFinanciers), la COB (Commission des Opérations de Bourse) et le CDGP (Conseil de Discipline dela Gestion des Portefeuilles). L’AMF est aujourd’hui l’autorité chargée de la régulation des mar-chés financiers.

CMMI (Capability Maturity Model Integration) : Référentiel de bonnes pratiques, développépar l’université Carnegie Mellon, destiné à appréhender, évaluer et améliorer la qualité des déve-lopements logiciels. Le modèle CMMI définit une échelle de mesure de la maturité à 5 niveaux.

COBIT (Control Objectives for Business and Related Techonology) : Référentiel de gouver-nance et d’audit des SI développé par l’ISACA (Information Systems Audit and ControlAssociation) et promu en France par l’AFAI (Association Française de l’Audit et du conseilInformatique) et le CIGREF. COBIT est une approche orientée processus. COBIT décompose toutsystème informatique en 34 processus regroupés en 4 domaines.

COSO : Référentiel de contrôle interne défini par le Committee Of Sponsoring Organizations ofthe Treadway Commission. Il est utilisé notamment dans le cadre de la mise en place des disposi-tions relevant des lois Sarbanes-Oxley ou LSF pour les entreprises assujetties respectivement auxlois américaines ou françaises.

eSCM (e-Sourcing Capability Model) : Référentiel développé par l’université de CarnegieMellon et promu en France par l’association a-eSCM . Ce référentiel qui comprend deux volets (unvolet interne – client et un volet externe – fournisseurs) permet d’industrialiser et standardiser larelation clients / fournisseurs.

Hot-Line : Premier niveau d’appel au soutien (centre d’appels).

Help-Desk : Chaîne de soutien (deuxième niveau du soutien après la Hot-Line).

ISO 27000 : Ensemble de normes liées à la sécurité des SI. La suite contient des recommandationsdes meilleures pratiques en management de la sécurité de l'information, pour l'initialisation, l'im-plémentation ou le maintien de systèmes de management de la sécurité de l'information (SMSI,ou ISMS en anglais).

Incident : Tout événement qui ne fait pas partie des opérations standard et pouvant provoquerune interruption de service ou altérer sa qualité.

150

ANNEXES

© CIGREF - IFACI

ITIL (Information Technology Infrastructure Library) : Ensemble de bonnes pratiques pour lagestion de la production informatique. ITIL est une approche par processus, qui vise à améliorer laqualité des services des SI.

LSF : Loi sur la Sécurité Financière. Loi française adopté le 17 juillet 2003 visant à assurer un meil-leur contrôle des entreprises et à renforcer les dispositions légales en matière de gouvernementd'entreprise. Cette nouvelle loi s'applique à toutes les sociétés anonymes ainsi qu'aux sociétés fai-sant appel à l'épargne publique. La loi de sécurité financière repose principalement sur :

• une responsabilité accrue des dirigeants ;• un renforcement du contrôle interne ;• une réduction des sources de conflits d'intérêt.

Objectifs de contrôle : Résultat désiré ou but à atteindre par la mise en œuvre d’une activité decontrôle.

OLA : Operational Service Agreement (contrat de service interne à l’informatique entre un serviceinformatique et un autre service informatique).

OS : Système d’exploitation.

PV (procès verbal) de recette : Document qui valide la conformité du logiciel par rapport auxspécifications avant la mise en production. Il est signé par la Maîtrise d’Ouvrage (MOA).

Bon de livraison : Document fournit par la MOE « développement » à la MOE « exploitation ». Illiste les éléments techniques à installer sur les serveurs de production.

Qualification de l'information : Classification adaptée à la taille de l'entité, en matière de confi-dentialité, de valeur ou d'amplitude critique et qui permet de s'assurer que l'information bénéfi-ciera du niveau approprié de protection.

Risque : Possibilité que se produise un événement qui aura un impact sur la réalisation des objec-tifs. Le risque se mesure en termes de conséquences et de probabilité (Glossaire des normes del’IIA/IFACI).

RACI : Responsable, Approuve, Consulté, Informé – Méthode permettant d’attribuer des rôles àdes acteurs au sein d’une organisation.

RSSI : Responsable Sécurité des systèmes d’information.

Rôles critiques : Rôles essentiels pour le bon fonctionnement de la DSI, et a priori non externali-sables.

Rôles clés : Rôles critiques particulièrement rares sur le marché.

SLA : Service Level Agreement (contrat de service entre un service utilisateur et un service infor-matique).

151


© CIGREF - IFACI

SOX (Sarbanes Oxley) : Loi fédérale américaine de 2002 sur la réforme de la comptabilité dessociétés cotées et la protection des investisseurs imposant de nouvelles règles sur la comptabilitéet la transparence financière. Elle fait suite aux différents scandales financiers révélés dans le paysaux débuts des années 2000, tels ceux d'Enron et de Worldcom. La loi du 31 juillet 2002 a introduitnotamment :

• l'obligation pour les présidents et les directeurs financiers de certifier personnellement lescomptes ;

• l'obligation de nommer des administrateurs indépendants au comité d’audit du conseild’administration ;

• l'encadrement des avantages particuliers des dirigeants.Cette loi oblige aussi à mettre en œuvre un contrôle interne s'appuyant sur un cadre conceptuel.En pratique le COSO est le référentiel le plus utilisé.

152

© CIGREF - IFACI

Réalisation : ebzone communication (w

ww.ebzone.fr) - Im

pression : Im

primerie Com

pédit Beauregard

Sites institutionnels : • www.afai.fr• www.cigref.fr• www.ifaci.com• www.isaca.org

Rapports :• Rapport de l’AFAI – Contrôle interne et système d’information – Juillet 2008 – www.afai.fr

7. SOURCES

© CIGREF - IFACI - Paris - février 2009ISBN : 978-2-915042-02-3

http://www.afai.fr

http://www.isaca.org

http://www.ifaci.com

http://www.cigref.fr

http://www.afai.fr

12 bis, place Henri Bergson - 75008 Paris

Tél. : 01 40 08 48 00 - Fax : 01 40 08 48 20

Mel : [email protected] - Internet : www.ifaci.com

21, avenue de Messine - 75008 Paris

Tél. : 01 56 59 70 00 - Fax : 01 56 59 70 01

Mel : [email protected] - Internet : www.cigref.fr

Le contrôle interne du système d’information des …...Le système d’information, objet et...

Documents

Transcript of Le contrôle interne du système d’information des …...Le système d’information, objet et...