EXTRACTION ET EXPLOITATION DES DONNEES DU SYSTEME … · 2010-12-14 · diplÔme...

DIPLÔME D’EXPERTISE-COMPTABLE

SESSION DE MAI 2008

MEMOIRE

EXTRACTION ET EXPLOITATION DES DONNEES DU

SYSTEME D’INFORMATION DANS LE CADRE DU

COMMISSARIAT AUX COMPTES : METHODOLOGIE & OUTILS

RIVIERE Benoît-René

[email protected]

www.auditsi.eu

REMERCIEMENTS

Je remercie Claire FOURNIER pour ses conseils avisés dans la rédaction de mon mémoire

et Corinne DAUPHIN pour sa relecture attentive.

POUR ALLER PLUS LOIN

Cher lecteur,

Vous vous apprêtez à lire le mémoire qui m’a permis d’obtenir mon diplôme d’expertise-

comptable.

Si ce sujet vous intéresse, si vous souhaitez échanger sur le sujet, consultez mon site

internet intitulé « Audit & Systèmes d’Information» à l’adresse www.auditsi.eu. J’ai dédié ce

site à l’audit des systèmes d’information informatisés. Un espace vous est réservé dans la

rubrique Mémoire DEC (identifiant : mem2008, mot de passe : mem2008).

Vous pouvez également me contacter à [email protected].

Bonne lecture et à bientôt.

Note de synthèse

L’information est partout. Elle est multifonction : elle favorise la prise de décision, elle est un

vecteur de communication de l’entreprise avec son environnement et un élément de

cohésion interne. Sa valeur est inestimable tant son absence ou son altération rend

hypothétique la pérennité de l’entreprise et décrédibilise cette dernière aux yeux de ses

partenaires. L’information est une ressource incontournable dont l’entreprise maîtrise la

gestion à l’aide de son système d’information.

Le système d’information suit un processus progressif d’automatisation, d’informatisation ;

au point que le système d’information est devenu indissociable du système informatique.

L’évolution des technologies a donné un véritable élan à la gestion de l’information.

L’ensemble des activités administratives et opérationnelles est concerné par ce mouvement.

La complexité du système d’information est en rapport avec les besoins en information de

l’entreprise. Les flux physiques et financiers sont traduits en flux comptables. La gestion

commerciale, la gestion des stocks, la gestion de la production et bien d’autres modules du

système informatique déversent continuellement des flux d’écritures comptables dans la

comptabilité générale. Cette dernière n’est plus qu’un sous-ensemble du système

d’information.

Les comptes annuels prennent leur source dans le système d’information. Dans le cadre de

sa mission légale de certification des comptes, le commissaire aux comptes ne peut s’arrêter

à la révision des comptes. Il doit s’intéresser à la source de la comptabilité générale : le

système d’information. Le commissaire aux comptes évalue le contrôle interne, teste les

procédures, s’assure de la qualité du fonctionnement du système d’information. En fonction

des points forts et points faibles relevés, il ajuste son risque d’audit. Il établit son plan de

mission et rédige son programme de travail. Au fur et à mesure de l’accomplissement de sa

mission, les éléments probants sont recueillis.

Afin d’accroître son champ d’investigation, le commissaire aux comptes aura intérêt à faire

usage de l’extraction de données. L’extraction de données informatiques est un véritable

outil complémentaire de collecte d’éléments probants et de documentation des travaux

effectués. Elle s’adapte à toutes les étapes du processus de certification. Cet outil s’insère

dans la panoplie des techniques d’audit de l’auditeur pour peu que le cabinet ait repensé ses

méthodes de travail. En effet, le commissaire aux comptes n’est pas un spécialiste en

informatique et même s’il maîtrise l’analyse du fonctionnement général du système

d’information, il n’en connait pas pour autant tous les arcanes de son informatisation.

Le commissaire aux comptes et son équipe ont besoin d’une méthodologie leur assurant la

fiabilité des extractions et de méthodes d’exploitation des données permettant de tirer profit

des données extraites. C’est à ce besoin que se propose de répondre ce mémoire.

La méthodologie proposée suit un certain nombre d’étapes incontournables comme la

modélisation du système d’information et la détermination des champs de données à

extraire, la formulation de la demande d’extraction. La complexité du système d’information

rencontrée lors de la prise de connaissance et de l’évaluation du contrôle interne, l’auditeur

la retrouve au moment de modéliser le système d’information et de déterminer les champs

de données à extraire. L’auditeur doit apprendre à déjouer les pièges qui ne manquent pas

de se dresser et à mettre en œuvre des mesures de fiabilisation du processus de traitement

des données afin d’éviter des erreurs d’interprétation nuisibles à la communication du

commissaire aux comptes avec la société auditée. Une fois les données demandées

obtenues, l’auditeur opère des contrôles et des retraitements sur les données, de manière à

s’assurer de l’intégrité des données obtenues et à préparer leur exploitation. L’auditeur

dispose d’une palette de logiciels (spécialisés en analyse de données ou généralistes) et de

techniques (des plus simples aux plus évoluées) permettant de retraiter les données et de

ressortir rapidement les exceptions à des règles prédéfinies, les anomalies. Il est possible de

rapprocher des tables de données entre elles, de synthétiser des listes infinies de données

en un tableau de quelques lignes. Les extractions de données et l’exploitation qui en résulte

accroissent la gamme de contrôles offerte à l’auditeur, la taille des échantillons sondés. Le

suivi rigoureux de la méthodologie exposée et la maîtrise des techniques d’exploitation des

données sont un gage de succès.

Enfin, ce mémoire développe une dizaine des cas pratiques afin de mettre en application la

méthodologie proposée et les différentes techniques d’exploitation des données applicables

à l’ensemble des phases de sa mission d’audit. Ces cas, très variés dans leurs domaines

d’application respectifs, seront à adapter à chaque cas particulier. Il ne restera plus au

commissaire aux comptes qu’à analyser les résultats de l’exploitation des données,

recueillir, le cas échéant, des explications auprès de l’entité auditée et de tirer des

conclusions avec éventuellement une incidence sur la suite de la mission.

S O M M A I R E

INTRODUCTION ...................................................................................................................... 1

I. INTERVENTION DU COMMISSAIRE AUX COMPTES EN ENVIRONNEMENT

INFORMATISE ......................................................................................................................... 4

A. INFORMATION ET SYSTEME D’INFORMATION ..................................................................... 4

1) L’information ............................................................................................................ 4

a. L’information, élément de communication ....................................................................... 4

b. L’information, une ressource précieuse ........................................................................... 5

2) Système d’information ............................................................................................. 6

a. Définition .......................................................................................................................... 7

b. Positionnement du système d’information dans l’entreprise ............................................ 8

c. Flux d’information ............................................................................................................ 8

d. Les principaux composants du système d’information d’une entreprise .......................... 9

e. Interdépendance des composants du système d’information ........................................ 10

f. La comptabilité générale : un des maillons fonctionnels du système d’information ....... 10

g. Points d’entrées et interfaces ........................................................................................ 10

3) Environnement informatisé ................................................................................... 11

a. L’informatique au service du système d’information ...................................................... 11

b. Diversité des systèmes informatiques ........................................................................... 12

c. Dématérialisation des flux ............................................................................................. 16

d. Sécurité et sauvegarde ................................................................................................. 16

4) Contrôle interne et procédures ............................................................................. 17

a. Les processus clefs de l’entreprise ............................................................................... 18

b. Contrôle interne ............................................................................................................ 18

5) Particularités dans les PME .................................................................................. 19

a. Des moyens souvent limités ......................................................................................... 19

b. Des risques cernés ....................................................................................................... 19

B. L’INTERVENTION DU COMMISSAIRE AUX COMPTES ......................................................... 20

1) La mission du commissaire aux comptes ............................................................. 20

a. Une profession en mutation .......................................................................................... 20

b. Une mission avant tout légale ....................................................................................... 21

c. Une mission de prévention ........................................................................................... 21

2) L’organisation de la mission ................................................................................. 21

a. Articulation classique de la mission .............................................................................. 22

b. Analyse du système d’information ................................................................................ 23

c. Appréciation de l’environnement informatique .............................................................. 23

d. Appréciation du contrôle interne ................................................................................... 24

3) L’extraction de données et la mission du commissaire aux comptes .................. 24

a. Validation du système d’information et des procédures de contrôle interne ................. 25

b. Contrôle des comptes ................................................................................................... 25

c. Documentation des travaux effectués ............................................................................ 26

d. Organisation du cabinet : spécialisation ou généralisation des compétences ............... 26

4) La réglementation opposable à l’entreprise .......................................................... 26

a. La nécessité d’informer la direction ............................................................................... 26

b. Les prérogatives du commissaire aux comptes ............................................................. 27

c. La réglementation fiscale ............................................................................................... 27

II. EXTRACTION ET EXPLOITATION DE DONNEES DANS LE CONTEXTE DU

COMMISSARIAT AUX COMPTES : METHODOLOGIE ....................................................... 30

A. EXTRACTION DES DONNEES .......................................................................................... 30

1) Démarche auprès de l’entreprise .......................................................................... 31

a. Informaticiens et comptables : deux langages différents ............................................... 31

b. Formulation de la demande d’extraction (sources, critères, champs et format) ............. 33

c. Outils d’extraction à disposition de l’entreprise .............................................................. 37

2) Contrôle des données obtenues ........................................................................... 38

a. Représentation des données extraites .......................................................................... 38

b. Contrôle visuel ............................................................................................................... 39

c. Contrôle de la conformité avec la demande formulée .................................................... 39

d. Contrôle de la conformité avec les comptes audités ...................................................... 40

B. EXPLOITATION DES DONNEES ....................................................................................... 40

1) Outils informatiques .............................................................................................. 41

a. Outils spécialisés (IDEA / ACL) ..................................................................................... 41

b. Outils bureautiques (tableur et SGBDR) ........................................................................ 41

c. Avantages et inconvénients de chaque type d’outils .................................................... 42

d. Outils utilisés dans le cadre de ce mémoire .................................................................. 43

2) Retraitement préalable des données .................................................................... 44

a. Retraitements liés au format de fichiers ........................................................................ 44

b. Retraitement lié aux limitations d’EXCEL ...................................................................... 45

c. Retraitements liés au format des données .................................................................... 46

3) Techniques d’exploitation de données ................................................................. 47

a. Les filtres automatiques, les tris simples et les formats conditionnels .......................... 48

b. Les requêtes ................................................................................................................. 50

c. Les tableaux croisés dynamiques ................................................................................. 57

d. Exemples de traitements à opérer sur les données obtenues ...................................... 59

III. EXEMPLES D’OUTILS EXPLOITANT LES DONNEES EXTRAITES ............................ 62

A. CONTROLE DE COHERENCE DU SYSTEME D’INFORMATION .............................................. 63

1) Interfaces : contrôle de cohérence des informations transférées au sein du

système d’information ................................................................................................... 64

a. Objectif du contrôle ....................................................................................................... 64

b. Données à obtenir......................................................................................................... 64

c. Démarche et outils ........................................................................................................ 64

d. Résultat obtenu et interprétations ................................................................................. 66

2) Test d’intégrité référentielle .................................................................................. 67



c. Démarche et outils ......................................................................................................... 68

d. Résultat obtenu et interprétations .................................................................................. 69

3) Séparation des pouvoirs : identification des auteurs d’écritures ........................... 69

a. Objectif du contrôle ........................................................................................................ 69

b. Données à obtenir ......................................................................................................... 70



B. CONTROLE DE COHERENCE DE DONNEES ...................................................................... 73

1) Comptabilité auxiliaire : contrôle d’équilibre du lettrage ....................................... 73





2) Reconstitution des à-nouveaux ............................................................................. 75





3) Paye : évolution des charges sur un exercice ...................................................... 77





4) Trou de numérotation ........................................................................................... 79





5) Ventes : contrôle de taux de TVA ......................................................................... 82





6) Stocks : contrôle de la variation N/N-1 prix et quantité ........................................ 85





C. RISQUE DE FRAUDE ..................................................................................................... 89

1) Comptabilité générale : contrôle des exceptions .................................................. 90





2) Loi de Benford ....................................................................................................... 93





CONCLUSION ....................................................................................................................... 97

BIBLIOGRAPHIE ................................................................................................................... 99

ANNEXES ............................................................................................................................ 102

EXTRACTION ET EXPLOITATION DES DONNEES DU SYSTEME D’INFORMATION DANS LE CADRE DU COMMISSARIAT AUX COMPTES : METHODOLOGIE & OUTILS

Ecrit par Benoit-René RIVIERE – [email protected] – www.blog.auditsi.eu - Page 1

INTRODUCTION

La mission première du commissaire aux comptes est la certification des comptes. Il est le

garant de la transparence financière que le législateur a souhaité assurer aux différents

agents économiques intéressés (actionnaires, établissements financiers, salariés,

fournisseurs, clients, administration…). Au travers des diligences qu’il met en œuvre, il

s’assure que la société a établi ses comptes dans le respect des normes comptables et de la

réglementation applicables. L’élaboration des comptes annuels suit un processus qui prend

sa source dans le système d’information de l’entreprise. Le système d’information, épine

dorsale de l’organisation de l’entreprise, gère les informations de l’entreprise, de leur collecte

à leur restitution. Quelle que soit la nature des informations, financière (conséquence de

flux) ou technique (gestion du savoir), l’intégrité des informations conservées par l’entreprise

est essentielle à sa pérennité.

Dans le cadre de sa mission, le commissaire aux comptes évalue le système d’information,

les procédures et le contrôle interne. Cette évaluation s’affine tout au long des phases

successives de son intervention : prise de connaissance de l’entité auditée et de son

environnement, examen de la qualité du contrôle interne, de la fiabilité du système

d’information et des systèmes informatiques, appréciation de son risque d’audit et définition

du niveau de diligence à accomplir et bien entendu contrôle des comptes. Au cours des

différentes phases d’intervention, le commissaire aux comptes collecte les éléments

probants qui lui sont nécessaires pour orienter ses travaux, pour fonder et émettre son

opinion sur les comptes. Les éléments probants sont de natures diverses (observation

physique, demande d’information, vérification de calcul, examen analytique…) et contribuent

chacun à vérifier les différentes assertions d’audit. Durant l’exercice de sa mission, le

commissaire aux comptes sélectionne les méthodes les plus appropriées pour collecter les

éléments probants. Le commissaire aux comptes n’ayant matériellement pas le temps de

tout contrôler, l’ensemble de ses travaux repose, sauf exceptions, sur des sondages. En



présence d’environnements de plus en plus informatisés, de plus en plus complexes et de

volumes de données de plus en plus importants, le commissaire aux comptes doit intégrer

les contrôles informatiques dans ses méthodes de travail comme méthode complémentaire

d’audit. En effet, l’informatique lui permettra d’étendre la taille de ses échantillons, ses

sondages ainsi que le nombre des tests effectués par rapport à des contrôles plus

classiques. Cependant, le commissaire aux comptes, qui n’est pas nécessairement un

spécialiste informatique, se rend compte rapidement que la diversité des systèmes et des

logiciels rencontrés ne facilite pas l’extraction et l’exploitation des données. Il a besoin d’une

méthodologie sûre afin d’obtenir et de traiter les données informatiques nécessaires à

l’accomplissement de ses objectifs d’audit et de se constituer une base d’outils lui

permettant d’isoler les informations dissonantes.

Sans avoir la prétention de l’exhaustivité ou de l’omniscience, l’objectif de ce mémoire sera

ainsi de proposer au commissaire aux comptes une méthodologie et des outils afin d’extraire

et exploiter des données à partir du système d’information de manière sûre dans le but

d’orienter sa mission, de collecter des éléments probants, de contribuer à la documentation

de ses travaux conformément aux normes professionnelles. Pour remplir cet objectif, ce

mémoire est partagé en trois parties :

La première partie rappelle les notions fondamentales pour la bonne compréhension du

système d’information de l’entreprise par le commissaire aux comptes. C’est une approche

qui permettra de mettre en évidence le risque inhérent au système d’information.

La deuxième partie traitera de la méthodologie à mettre en œuvre pour extraire en toute

sécurité des données du système d’information de l’entreprise et des techniques de

traitement informatique permettant de présenter ces données en vue de répondre aux

objectifs d’audit fixés.

Enfin, la troisième partie présentera une dizaine de cas pratiques explorant les différentes

techniques d’exploitation des données présentées dans la deuxième partie tout en illustrant

les différents stades de la mission de certification exposés dans la première partie (validation

du fonctionnement du système d’information, contrôles de cohérence, recherche de fraude).



Les trois types d’objectifs d’audit abordés répondent à une large palette de contrôles mis en

œuvre habituellement par le commissaire aux comptes. Chacun des cas précisera l’exposé

du contexte, le but recherché, les données à obtenir de l’entité auditée, les techniques de

traitement à utiliser et les conclusions à en tirer. Chaque cas sera illustré d’exemples réels.

Le contenu de ce mémoire, la méthodologie et les cas pratiques, sont le fruit de mon

expérience professionnelle acquise quotidiennement au contact d’entreprises et de groupes

de sociétés, de tailles et de domaines d’activité variés ; chacun exposant des

problématiques particulières. C’est ce retour d’expérience que je me propose de vous faire

partager tout au long de ce mémoire.



I. INTERVENTION DU COMMISSAIRE AUX COMPTES EN ENVIRONNEMENT

INFORMATISE

Au cours de cette première partie, nous aborderons les notions d’information, de système

d’information. Nous verrons le caractère essentiel du système d’information au bon

fonctionnement de l’entreprise et de la transparence financière à la confiance des marchés

et des partenaires économiques de l’entreprise. Dans un second temps, seront évoqués la

mission du commissaire aux comptes et l’intérêt de l’extraction de données dans

l’accomplissement de ses diligences. La notion de risque inhérent sera introduite.

A. Information et système d’information

L’entreprise est environnée d’informations en provenance de sources diverses. Elle en émet

aussi pour ses besoins propres, pour ses clients, pour l’administration fiscale. L’information

relie l’entreprise à son environnement. Les informations sont gérées par l’entreprise à l’aide

d’outils plus ou moins élaborés en fonction de ses besoins et de ses ressources financières

et matérielles. Parce que si la gestion de l’information est vitale pour l’entreprise, elle

présente également un coût : coût d’acquisition, de traitement, de vérification, de mise à

jour…

1) L’information

a. L’information, élément de communication

Une information est un élément de connaissance susceptible d’être représenté à l’aide de

conventions pour être conservé, traité ou communiqué. L’information est multiforme,

d’origines diverses, canalisée par des moyens de communication variés.



L’information est multiforme dans la mesure où elle peut être représentée sous forme de

graphiques, de textes, de listes. Les supports de l’information sont tout aussi variés : fichiers

informatiques, éditions papier, films audiovisuels.

L’information a trois rôles principaux :

- L’information renseigne quotidiennement l’entreprise sur son

environnement. Elle émane de partenaires économiques (clients,

fournisseurs), financiers (banques, actionnaires)…

- L’information est un facteur d’organisation. En effet, elle favorise la

communication interne et la prise de décision. L’information donne la valeur

du patrimoine de l’entreprise (stocks, créances, dettes…).

- L’information est un vecteur de communication de l’entreprise vers

l’extérieur, elle véhicule l’image de l’entreprise, la stratégie commerciale.

L’entreprise fournit aux tiers les informations commerciales nécessaires au

développement de son activité (caractéristiques de ses produits, grilles de

prix…), elle publie les informations financières dont les financeurs et

organismes fiscaux et sociaux ont besoin.

b. L’information, une ressource précieuse

L'information est un élément de connaissance. Elle n’a pas de consistance, elle est

insaisissable et pourtant, l’entreprise ne peut s’en passer : l’information est indispensable à

sa survie.

L’information est une ressource précieuse. D’une part parce qu’elle a un coût (de collecte,

de conservation…) et d’autre part parce que son absence engendre l’incapacité pour

l’entreprise à comprendre son environnement, à prendre des décisions.

La valeur de l’information est volatile, l’information est une denrée périssable. Sa valeur

dépend beaucoup de celui qui en prend connaissance, selon qu’il soit le dirigeant, un

salarié… ou bien un concurrent.



La pérennité de l’entreprise peut être compromise lorsque son système d’information est

endommagé (erreur humaine, panne, incendie, intrusion, malversation, malveillance,

sabotage…) ou lorsque des informations sensibles sont divulguées ou volées (par erreur ou

à la suite d’espionnage industriel)… L’entreprise comprend la valeur de l’information quand

celle-ci lui fait défaut. La reconstitution de l’information après un sinistre est en effet très

coûteuse voire parfois impossible. Cependant, l’entreprise ne réalise généralement pas

aussitôt la compromission de son système d’information. Ceci est d’autant plus vrai que,

dans la majorité des cas, les entreprises victimes d’une défaillance grave de leur système

d’information ne se relèvent pas.

L’organisme américain Identity Theft Resource Center indique qu’au 18 décembre 2007, 79

millions de fichiers auraient été compromis aux Etats-Unis, soit quatre fois plus qu’en 2006.

Précisons que cette statistique est incomplète dans la mesure où la plupart des entreprises

ayant connu un problème de ce type n’ébruite pas le sujet. En effet, leur image en serait

affectée et elle pourrait perdre la confiance de leurs clients actuels et potentiels.

Les partenaires de l’entreprise attachent une importance particulière à la qualité de

l’information produite par son système d’information. Les clients (caractéristiques des

produits, prix, délais), les actionnaires (comptes annuels, budgets prévisionnels)… les tiers

ont besoin d’une information fiable et cohérente pour traiter avec les entreprises.

Etant donné le caractère stratégique et vital de l’information pour l’entreprise et ses

partenaires, la gestion de l’information doit être rationnalisée, encadrée, optimisée et

sécurisée. Pour remplir cette tâche, l’entreprise met en œuvre le système d’information.

2) Système d’information

Dans un environnement économique concurrentiel, ouvert sur le monde, les entreprises

cherchent à se distinguer de leurs concurrents, à les distancer, en concevant de nouveaux

produits toujours plus innovants, correspondant aux attentes de leurs clients. Un système



d’information efficient permet de garder une longueur d’avance en fournissant aux décideurs

la bonne information au bon moment.

a. Définition

Un système d’information est un ensemble de moyens techniques et humains mis en œuvre

par une organisation avec pour objectif de collecter, mémoriser, traiter, maintenir à jour et

restituer, sans perte ni altération, des informations.

Chacun des termes de cette définition a son importance. Chaque étape est incontournable.

De par l’information véhiculée, le système d’information assure la coordination des différents

services, leur permettant d’accomplir les missions qui leur sont dévolues, dans le but de

répondre à l’objectif que s’est fixé l’entreprise.

Les ressources techniques et humaines mobilisées par l’entreprise dans le déploiement et le

maintien de son système d’information dépendent directement de ses moyens financiers,

des volumes d’information à traiter et de ses besoins en information. L’entreprise devra

opérer des choix, notamment en matière de précision de l’information. De fait elle devra faire

la part des choses entre le temps nécessaire à l’obtention de l’information et la précision

souhaitée ; il en est ainsi en matière de détermination du coût de revient des produits

fabriqués. Il en est de même en matière de sécurité, de péremption de l’information. Plus les

volumes d’information sont lourds, plus leur gestion et leur mise à jour sont coûteuses.

Il existe deux types de systèmes d’information. Le système d’information de gestion et le

système d’information technique ou métier. Le premier, celui qui intéresse plus

particulièrement le commissaire aux comptes, gère l’information financière, comptable et

plus généralement l’information qui valorise les transactions, le patrimoine de l’entreprise. Le

deuxième, tout aussi important du point de vue de l’entreprise, traite les informations

techniques nécessitées d’une part pour l’accomplissement de l’activité de l’entreprise

(procédés de fabrication, fiches techniques, recettes produits…), et d’autre part pour la

conservation et l’utilisation des savoirs et des connaissances (système expert, base

documentaire, veille, gestion électronique de documents).



b. Positionnement du système d’information dans l’entreprise

Une entreprise c’est une stratégie, un produit, un marché, des clients, des ressources

humaines, financières, des règles de fonctionnement (hiérarchie, procédures, contrôle

interne).

Le système d’information s’intègre dans cet ensemble. Il en est l’épine dorsale sans lequel

l’entreprise se retrouverait dépourvue de capacité sensorielle et décisionnelle.

Le schéma qui suit a pour but de montrer le positionnement central du système d’information

dans l’entreprise. Il assure le traitement de l’information de provenances diverses, sa

restitution permanente.

PATRIMOINEDIRIGEANTS

CAPITAL HUMAINSTRATEGIE

StocksGestion commercialeGestion des achatsGestion de production

Contrôle interne

ActionnairesSalariésAdministration fiscaleBanquesClients & fournisseurs…

CLIENTS

CONCURRENTSMARCHE

L'ENTREPRISE

Comptabilité générale

Production & certification des comptes

Communication financière

Système d'information et de gestion

c. Flux d’information

Le système d’information traite des flux d’information qui sont la représentation

conventionnelle de flux physiques (marchandises, produits finis). Cette représentation

conventionnelle est la plupart du temps dictée par des impératifs comptables. Les flux

physiques sont retranscrits dans le système d’information à partir de documents (factures,

bons de livraisons…) et non pas à partir des biens physiques eux-mêmes.



Les flux d’information cheminent d’un bout à l’autre de la chaîne de l’information, à travers

les services concernés de l’entreprise.

d. Les principaux composants du système d’information d’une entreprise

Le système d’information de l’entreprise, nous l’avons vu, forme un tout indissociable qui

traite l’information et la diffuse au sein de l’entreprise permettant un fonctionnement organisé

et des réactions structurées face à son environnement.

Bien que formant un tout, le système d’information est formé de différents composants qui

eux-mêmes répondent à des objectifs propres. Ces objectifs sont définis par les différents

services de l’entreprise. Chaque service a des besoins précis et spécifiques ; spécifiques

mais complémentaires. Spécifiques car chaque composante permet à chaque intervenant

d’exécuter sa mission. Complémentaires car assemblés entre eux, ces différents

composants forment une chaîne de traitement qui assure la continuité des échanges de flux

d’informations au sein de l’entreprise.

Les principaux composants, liés à la gestion de l’information de gestion, que l’on retrouve le

plus communément sont principalement :

- la gestion des stocks et des achats,

- la gestion commerciale,

- la comptabilité,

- la paye et la gestion des ressources humaines.

Ces différents composants peuvent se subdiviser en fonction des besoins de l’entreprise.

Par exemple la comptabilité peut être compartimentée en comptabilité générale, analytique,

fournisseurs, clients, trésorerie… Cette fragmentation en sous-système s’opère tant au

niveau des services de l’entreprise que du système d’information.



e. Interdépendance des composants du système d’information

Tous les maillons qui composent le système d’information sont interdépendants. La

circulation de l’information ne s’arrête pas dans le périmètre du composant qui l’a générée.

Tous les composants communiquent les uns avec les autres, échangent. Les sorties

d’information des uns sont les entrées des autres. Une défaillance dans l’un d’entre eux et

c’est l’intégrité de l’ensemble du système qui est menacée.

f. La comptabilité générale : un des maillons fonctionnels du système d’information

La comptabilité générale n’est finalement qu’un maillon du système d’information, elle est la

résultante de différents autres sous-systèmes (production, gestion commerciale…). Son

poids est variable selon l’organisation de l’entreprise ; elle peut être le maillon essentiel de la

petite entreprise ou une simple étape préalable à la production des comptes annuels dans la

PME de plus grande taille.

g. Points d’entrées et interfaces

Le système d’information collecte les informations en provenance de l’extérieur. Par ailleurs,

nous avons également vu que le système d’information est composé de différents sous-

ensembles. Ces sous-ensembles communiquent entre eux de différentes manières suivant

leur niveau d’intégration.

Que les informations proviennent de l’extérieur ou qu’elles transitent à l’intérieur du système

d’information, le principe est le même : les flux transitent par un point d’entrée.

Trois méthodes d’intégration de données existent :

- la saisie manuelle

- l’interface (automatique ou semi-automatique) ; l’interface étant un logiciel

ou un module permettant la communication par conversion de format entre

deux logiciels.

- la base de données intégrée



Pour chacune de ces méthodes et quelle que soit la provenance de l’information, la piste

d’audit doit être assurée ; ce qui signifie que des procédures particulières assurent la

traçabilité de l’information (pièce comptable, utilisateur…) de son entrée dans le système

d’information à sa sortie (restitution). Ces procédures garantissent l’origine, la réalité,

l’intégrité et la qualité de l’information.

3) Environnement informatisé

L’informatique a envahi tous les domaines de l’entreprise. La plupart des tâches sont au

moins en partie automatisées ou liées à des processus informatisés à un point où finalement

le système d’information est devenu indissociable de système informatique. Pourtant ces

deux notions revêtent deux univers parallèles, l’un au service de l’autre.

a. L’informatique au service du système d’information

Le système informatique est au service du système d’information. Il permet d’automatiser le

traitement de l’information en épousant précisément les contours des règles de contrôle

interne, ni plus ni moins. Le système informatique ne doit pas ajouter de contraintes ni

accorder de souplesse aux règles définies par le contrôle interne. Si l’on prend l’exemple

d’un comptable affecté aux achats fournisseurs, sa fiche de poste indique que sa mission

principale consiste à saisir les factures d’achat dans le journal d’achat. Au niveau du

système d’information, ses droits d’accès au logiciel de comptabilité se limitent à la saisie de

mouvements dans les comptes 6x, 44566x et 401x dans le journal des achats.

De ce point de vue, les logiciels trop flexibles sont à proscrire par les dirigeants. Car si en

apparence ils simplifient la vie de l’utilisateur et coûtent moins chers à l’entreprise, dans la

réalité ils sont un vrai casse-tête pour le contrôle interne et les auditeurs. Ces logiciels ne

comprennent pas tous les verrous nécessaires à la stricte application des procédures ; qui

sont de fait contournables. Ces logiciels, comptables notamment, permettent de contourner

les procédures de contrôle en autorisant entre autres le lettrage non équilibré, la modification

de données calculées (comme un prix moyen pondéré) ou la suppression de documents

comptables sans conservation de traces, la réouverture d’exercices ou de périodes



clôturées… pire, certains contiennent des fonctions non documentées (pour ne pas parler

des portes dérobées) ; ces logiciels ne sont pas homologués par l’Administration fiscale et,

dans les cas extrêmes, font courir des risques de rejet de comptabilité par l’Administration,

expose la société à des contentieux fiscaux et surtout à des fraudes difficilement

détectables. Dans ce contexte, le commissaire aux comptes doit remettre en cause son

appréciation du contrôle interne de la société auditée et adapter son plan de mission en

fonction du niveau de risque mis en lumière.

Le commissaire aux comptes se doit d’intégrer dans son programme de travail, l’analyse du

fonctionnement des logiciels et l’adéquation de ceux-ci et de leur paramétrage avec les

procédures mises en place par l’entreprise.

Les besoins en traitement d’information dans le monde de l’entreprise sont tels, tant au

niveau des volumes de données à traiter que de la rapidité de restitution souhaitée, que le

fonctionnement du système d’information repose essentiellement sur les qualités du

système informatique, tant matériel que logiciel.

b. Diversité des systèmes informatiques

Chaque entreprise a sa propre organisation, son propre système d’information. En matière

de système informatique, il en est de même. La diversité des systèmes informatiques

dépend de la complexité de la structure des entreprises, de leurs besoins, de leurs moyens

financiers, de leur compétence.

Un système informatique se compose de matériels et de logiciels.

La partie matériel comprend les ordinateurs et terminaux informatiques (qui assurent

l’interface homme / système), les serveurs (qui stockent les données informatiques), les

moyens de communication (au premier rang desquels le réseau informatique qui relie tous

les composants du système informatique entre eux).

La partie logiciel regroupe deux types principaux de logiciels : les logiciels système qui

gèrent le fonctionnement du système d’informatique et les logiciels métiers qui quant à eux



ont pour objet d’accomplir les tâches assignées à un service donné (tenue de la comptabilité

par exemple). A cette occasion, précisons qu’il existe trois grandes familles de logiciels :

- les logiciels standard (progiciels), il s’agit de logiciels conçus pour être

utilisés tel quel par l’entreprise sans ajustement majeur aux spécificités de

l’entreprise.

- les logiciels sur-mesure écrits spécifiquement en fonction des besoins de

l’entreprise. A la base, cette famille de logiciels peut partir d’un logiciel

standard.

- Les logiciels maison, conçus par le service informatique de l’entreprise.

Le choix de telle ou telle famille n’est pas anodin, en effet il s’inscrit dans la durée (l’inertie

au changement est d’autant plus forte que l’infrastructure informatique est lourde et

coûteuse à déployer) et, suivant la famille de logiciels retenue, un risque court : abandon du

produit par l’éditeur (progiciel), perte de compétence en cas de faillite du prestataire

informatique (logiciel sur-mesure), de départ du salarié (logiciel maison) ; dans ces deux

derniers cas, la documentation et la détention de la propriété du code source sont

essentielles pour assurer la pérennité et le développement du système. Ce choix est

fonction des coûts (de mise en œuvre, de maintenance), des besoins spécifiques non

répondus par les progiciels, des compétences informatiques en interne, des temps de

développement... Quelles que soient les solutions informatiques retenues, le commissaire

aux comptes aura à cœur de s’assurer que les informaticiens auront intégré les règles

comptables et fiscales (numérotation séquentielle des factures, comptabilité « sans blanc ni

rature »…) de sorte que l’entreprise soit en conformité avec la législation. Plusieurs familles

de logiciels peuvent simultanément cohabiter dans le même système informatique (par

exemple, logiciel de comptabilité standard lié à un logiciel de gestion de production sur-

mesure). Ajoutons que suivant les besoins, d’autres applications plus légères sont souvent

développées sur tableur. Cet assemblage de composants informatiques forme un tout

hétérogène.



En vue de limiter cette hétérogénéité et d’intensifier le degré d’intégration du système

d’information, les grandes entreprises mettent en place des ERP (Enterprise Resource

Planning) ou en français PGI (Progiciel de Gestion Intégrée). Un PGI gère l’intégralité de la

chaîne de l’information pour l’ensemble des processus et fonctions de l’entreprise.

L’avantage de ce genre de système est que les données sont harmonisées, les reportings

facilités. Les compétences et les budgets nécessaires à leur mise en place et à leur

maintenance les rendent généralement inaccessibles aux PME.

Le choix de tel ou tel système résulte d’une réflexion orientée par les besoins en gestion de

l’information et en fiabilité, les compétences et les impératifs financiers.

Le matériel et le logiciel forment l’infrastructure informatique. Cette infrastructure est propre

à chaque entreprise. La qualité technique du système informatique est aussi primordiale que

celle du système d’information. En effet, une erreur dans le choix du matériel, des logiciels,

un manque de formation des utilisateurs, un système informatique sous-dimensionné ou mal

paramétré et c’est le système d’information qui se trouve paralysé et in fine le

fonctionnement de l’entreprise.

La conception et le déploiement de l’infrastructure sont généralement confiés à un

prestataire extérieur ou au service informatique. Cette infrastructure est mise en œuvre en

fonction du cahier des charges établi conjointement entre les différents services utilisateurs

(les besoins), la direction informatique (les compétences) et de la direction générale (les

ressources financières).

A coté de ce système informatique « officiel » coexistent de manière inévitable des outils

« officieux ». Elaborés pour répondre à des besoins spécifiques émis par tel ou tel service,

non gérés par le système informatique, ces outils échappent au contrôle de la direction

informatique bien que traitant souvent de points sensibles et significatifs (par exemple :

calcul des remises clients, des primes de fin d’année, états de valorisation des stocks,

facturation de prestations intra-groupe…). Pourtant, ces outils font courir des risques plus

importants du fait de l’absence de suivi et de contrôle dans leur processus de conception.



Ces applications sont souvent développées sur des tableurs et mettent fréquemment en

œuvre des macros.

Plus l’entreprise est importante, plus son besoin de gestion d’information augmente. Au fil du

temps, son système d’information s’étoffe. Il finit par reposer sur un véritable mécano de

logiciels et d’applications conçus tantôt par différents éditeurs tantôt en interne, sur des

systèmes informatiques hétérogènes (mêlant des plateformes WINDOWS, UNIX, MAC OS).

Ils ne sont généralement maîtrisés dans leur globalité que par leur concepteur. Ce qui pose

de sérieux risques de perte du savoir et de maîtrise de l’ensemble en cas de départ en

retraite, de démission (salarié) ou de faillite, de séparation (prestataire extérieur).

Dans le cadre de l’externalisation des fonctions informatiques, certaines entreprises confient

la gestion de leurs données et/ou des applications informatiques à un prestataire extérieur.

De plus en plus, des sociétés de service, fournisseurs d’applications hébergées (FAH),

proposent des logiciels hébergés à distance (comptabilité, gestion de la paye,

immobilisations, suites bureautique…) contre la facturation d’une redevance fixe. Les

avantages sont multiples, l’entreprise est complètement déchargée des compétences

informatiques (info-gérance), de la gestion de serveurs, de leur mise à jour, des

sauvegardes. La mutualisation des outils (logiciels et serveurs) permet de limiter les coûts,

coût régulier sans surprise (lissage des coûts)… D’un point de vue légal, rien ne s’oppose à

cette pratique, la loi impose cependant que les documents comptables ainsi que les

données informatiques soient localisés en France. D’un point de vue opérationnel,

l’entreprise définira contractuellement ses relations avec le prestataire et envisagera

concrètement les devoirs et responsabilités de chacun (sauvegarde et disponibilité des

données, devenir des données en cas de faillite du prestataire ou de litige). Le commissaire

aux comptes intègre dans son appréciation de l’environnement informatique les risques

spécifiques liés à cette pratique récente.



c. Dématérialisation des flux

Avec l’avènement des nouveaux outils de communication, les flux sont de plus en plus

dématérialisés. La dématérialisation ne concerne pas seulement les flux financiers mais

également les flux documentaires.

De nouvelles pratiques apparaissent, entre autres la gestion électronique de documents

(GED), la dématérialisation des documents (facture numérique, transmission de commandes

par internet notamment dans le secteur de la sous-traitance automobile) et leur archivage

(pour des raisons légales sur des durées variables de quelques mois à trente ans, voire à

vie).

Pour accompagner ces nouvelles façons de communiquer, les transactions sont de plus en

plus souvent cryptées et les documents signés numériquement.

d. Sécurité et sauvegarde

Dans un monde de plus en plus ouvert et concurrentiel, la disponibilité permanente de

l’information est primordiale. L’intégrité du système informatique doit être garantie de

manière à préserver en toute circonstance la qualité du système d’information et de

l’information.

L’article 34 de la loi du 6 août 2004 modifiant la loi du 6 janvier 1978 (loi « informatique et

libertés ») prescrit l’obligation de sécurité des bases de données contenant des données à

caractère personnel (c’est-à-dire des données permettant d’identifier des personnes

physiques). L’entreprise doit prendre toutes les mesures utiles à la préservation des

données pour éviter qu’elles ne soient divulguées à des tiers ou altérées sous peine de

sanctions pénales. Des données à caractère personnel, l’entreprise en gère dans différents

domaines : gestion des ressources humaines, gestion clients (particuliers)…

Bien entendu, la sécurisation du système informatique ne concerne pas uniquement la

gestion des données à caractère personnel. Mais face à la résurgence de la fraude et du

piratage à grande échelle (vol de fichiers clients entraînant des fraudes à la carte bleue, des

usurpations d’identité…), le législateur a souhaité responsabiliser les entreprises.



Les mesures de protection à la disposition des entreprises sont de trois types :

- sensibilisation des salariés et des tiers : la mise en place de chartes sur

l’utilisation des systèmes, d’internet, des sauvegardes, de la confidentialité

ainsi que des formations ciblées permettent de limiter les principales erreurs

commises par les salariés ou les tiers destinataires des informations (sous-

traitants, prestataires…),

- politique de sécurisation : authentification des utilisateurs avec droits

d’accès strictement définis, changement régulier des mots de passe,

- mesures techniques de protection (pare-feu, antivirus, analyse des fichiers

de journalisation (log) et de sauvegarde des données, sauvegarde, plan de

secours).

La sécurité informatique de chaque entreprise mixe ces trois sortes de mesures de manière

à limiter les risques.

4) Contrôle interne et procédures

L’article R.123-172 du Code de Commerce prescrit que tout commerçant est tenu d’établir

un document décrivant les procédures et l’organisation comptable lorsqu’il s’avère

nécessaire à la compréhension du système de traitement et à la réalisation des contrôles.

Le contrôle interne et les procédures sont deux notions complémentaires qui sont

intimement liées l’une à l’autre, presque indissociables. Les procédures étant les règles de

fonctionnement, le contrôle interne étant l’examen de la bonne application des procédures.

Le contrôle interne doit assurer à l’entreprise la maîtrise de l’information traitée et diffusée.

Le contrôle interne s’inscrit dans une politique globale visant à assurer la sécurité et

l’intégrité des données et plus largement des actifs de l’entreprise dans toutes les phases

des processus clefs.



a. Les processus clefs de l’entreprise

Un processus clef est un processus qui a un impact important sur la formation du résultat de

l’entreprise. Le processus clef incontournable, commun à la majorité des entreprises, est

bien entendu le processus vente.

D’une entreprise à l’autre, les processus clefs ne sont pas nécessairement les mêmes. Les

processus clefs habituels de l’entreprise dépendent de la nature de l’activité de l’entreprise.

Le processus Paye sera, entre autres, un processus essentiel dans les entreprises

prestataires de services facturant les prestations à l’heure.

b. Contrôle interne

La loi de sécurité financière (du 2 août 2003) a introduit la notion de contrôle interne dans la

législation française.

Le contrôle interne est l’ensemble des verrous mis en place par l’entreprise en vue

d’encadrer ses activités et d’en maîtriser ses contours. Le contrôle interne ne se limite pas

aux activités comptables, il concerne tous les domaines de l’entreprise (achats, service

commercial…).

Définition de droits d’accès (habilitations) aux applications et données informatiques,

séparation des tâches (enregistrement, détention des biens et valeurs, décision, contrôle),

délégations de pouvoirs sont quelques uns des moyens encadrant l’activité de l’entreprise.

L’entreprise se dote :

- d’une politique de gestion de l’information cohérente et sécurisée,

- d’une hiérarchie matérialisée par un organigramme fonctionnel (dont un

exemple figure en Annexe I.1) dans lequel chaque poste est défini avec

suffisamment de précision (cf un exemple de fiche de poste en Annexe I.2).

Les tâches affectées à chaque poste empêchent un salarié d’avoir la



maîtrise complète d’un même processus (exemple : facturation,

encaissement).

- d’un manuel de procédures. Ce manuel à l’usage tant des collaborateurs

que des contrôleurs internes et externes fixe les règles de fonctionnement

de toutes les activités de l’entreprise. Le degré de précision dans la

description des procédures dépend de la taille de l’entreprise (un exemple

de procédure extraite d’un manuel est reproduit en Annexe I.3).

L’entreprise doit mettre un niveau de contrôle interne adapté à sa structure. Un contrôle

interne adapté garantit la qualité de l’information, la rapidité des prises de décision tout en

n’entravant pas le fonctionnement de l’entreprise par des procédures trop lourdes.

5) Particularités dans les PME

a. Des moyens souvent limités

Les PME ont des moyens humains et matériels limités qui ne leur permettent pas de mettre

en oeuvre une structure de contrôle aussi approfondie que celles qui sont habituellement

recommandées. Leur structure plus légère leur octroie une souplesse et une réactivité plus

importante. Les niveaux hiérarchiques sont peu nombreux, les fonctions essentielles

regroupées en quelques mains. En contrepartie, le contrôle interne est insuffisant voire

inexistant. Les risques de fraude au détriment de l’entreprise sont aussi plus élevés.

De fait, les exceptions (absences maladie, congés) accroissent encore les risques.

b. Des risques cernés

La séparation des tâches n’est pas respectées non par volonté mais par manque de moyens

et de temps. Le dirigeant est omnipotent, omniscient… et incontournable.

La gestion des habilitations (droits d’accès aux logiciels) est souvent très rudimentaire.



Cependant, cet état des lieux ne doit pas non plus conduire à jeter la suspicion sur les PME.

En effet, le dirigeant de PME, souvent familiale, détient les principales clefs de contrôle.

Même si le risque de défaillance du contrôle peut provenir de salariés situés à des postes

clefs, la source principale de fraude potentielle provient de la direction.

B. L’intervention du Commissaire aux Comptes

Nous venons de constater que l’information est une ressource essentielle à la vie de

l’entreprise et que la qualité de la conception du système d’information est déterminante

pour garantir l’intégrité des informations traitées.

La qualité du système d’information est également déterminante pour le commissaire aux

comptes. En effet, il certifie que l’information financière communiquée aux actionnaires et

aux tiers est conforme aux principes comptables et à la réglementation. La comptabilité

résultant pour une large part du système d’information, le commissaire aux comptes

s’appuie sur le système d’information et le contrôle interne développé par l’entité auditée

pour conduire ses travaux.

1) La mission du commissaire aux comptes

a. Une profession en mutation

Ces dernières années, l’exercice de la mission du commissaire aux comptes a été

profondément remanié par ses propres instances et par le législateur. La création du H3C

(Haut Conseil au Commissariat aux Comptes), organe chargé de contrôler la profession

dont les membres commissaires aux comptes sont minoritaires et de l’homologation

progressive des Normes d’Exercice Professionnel (NEP) a contribué à cette rénovation.

La profession a été exposée sur la scène médiatique ces dernières années avec la mise au

grand jour de scandales financiers dont la faillite d’Enron en a certainement été le plus

retentissant. Plus récemment, suite à la perte de 4,9 milliards d’euros réalisée par la Société

Générale, Christine LAGARDE, Ministre de l’Economie, a remis au Premier Ministre un



rapport préconisant le renforcement du contrôle interne, l’inscription de la fraude interne

comme un élément à part entière du contrôle interne et réaffirmant le rôle essentiel du

commissaire aux comptes. La judiciarisation des relations des affaires fait du métier de

commissaire aux comptes une profession à risque.

b. Une mission avant tout légale

La mission principale du commissaire aux comptes est de certifier la régularité et la sincérité

des comptes. C’est une mission d’ordre public. Par la certification des comptes, le

commissaire aux comptes assure les actionnaires et les tiers de la fiabilité relative de

l’information financière publiée et de la cohérence des moyens de contrôle interne mis en

œuvre.

La mission du commissaire aux comptes est exclusive de toute immixtion dans la gestion.

Les Normes d’Exercice Professionnel, qui se sont progressivement substituées aux normes,

encadrent l’exercice de la mission du commissaire aux comptes. A la différence des

anciennes normes, les NEP sont homologuées par Arrêté du Ministère de la Justice. Elles

ont donc force de loi et s’imposent au commissaire aux comptes.

c. Une mission de prévention

Le commissaire aux comptes n’est pas un conseil de l’entreprise. Cependant, de par les

investigations qu’il entreprend, il a une connaissance particulière des systèmes de

l’entreprise. Dans le cadre de ses travaux, il apprécie la qualité du contrôle interne.

S’il le juge utile, le commissaire aux comptes communiquera à la direction de la société

auditée ses observations sur les points faibles et les points forts relevés tout au long de son

intervention dans une lettre de recommandation.

2) L’organisation de la mission

Le déroulement de la mission du commissaire aux comptes suit un enchaînement d’étapes

normées.



a. Articulation classique de la mission

La mission du commissaire aux comptes s’articule en plusieurs phases.

Les NEP 200 intitulées « Principes applicables à l’audit des comptes mis en œuvre dans le

cadre de la certification des comptes » (ex-Norme 2-101), 300 « Planification de l’audit » et

315 « Connaissance de l’entité et de son environnement et évaluation du risque d’anomalies

significatives dans les comptes » notamment définissent la mission du commissaire aux

comptes et ses modalités.

Les NEP ont revu la ventilation des étapes et leur importance relative les unes par rapport

aux autres.

Phase Contenu Acceptation, maintien Questionnaire d’acceptation du mandat (1ère

année) ou de maintien (exercices suivants), d’indépendance

Prise de connaissance de l’entreprise et de son environnement

Analyse du système d’information, appréciation du contrôle interne et évaluation du risque d’audit

Orientation et planification Définition des objectifs d’audit dans deux documents complémentaires : Plan de mission : analyse des risques (justifie les risques faibles et l’allégement des diligences liées), détermine les seuils de signification ; le plan de mission évolue en cours de mission en fonction des conclusions intermédiaires Programme de travail : ce document détaille les diligences mentionnées dans le plan de mission

Collecte des éléments probants Assistance aux inventaires physiques, confirmation directe…

Contrôle des comptes Conclusion et synthèses, rapport général La note de synthèse doit répondre aux

objectifs définis dans le plan de mission et entre autres conclut sur les risques élevés, elle justifie les diminutions de risque. Le rapport général certifie avec ou sans réserves les comptes ou refuse la certification.

Le commissaire aux comptes évalue son risque, le risque d’audit. Le risque d’audit étant « le

risque que le commissaire aux comptes exprime une opinion différente de celle qu'il aurait

émise s'il avait identifié toutes les anomalies significatives dans les comptes » d’après la

NEP 200. Le risque d’audit est lui-même composé du risque d'anomalies significatives dans

les comptes et du risque de non-détection de ces anomalies par le commissaire aux



comptes. Le but étant pour le commissaire aux comptes de réduire au maximum son risque

de manière à obtenir une assurance suffisante préalable à la certification des comptes. A cet

effet, il définit ses objectifs d’audit et met en œuvre un programme de travail en fonction des

zones de risque identifiées.

b. Analyse du système d’information

La comptabilité générale n’est qu’un maillon de la chaîne d’information. De ce fait, le

commissaire aux comptes ne peut raisonnablement s’arrêter à l’étude de ce seul chaînon.

Différents modules (gestion des stocks, paye, gestion de production…) déversent des

écritures en comptabilité générale. Il appartient au commissaire aux comptes d’appréhender

le système d’information dans son ensemble, d’en acquérir une connaissance suffisamment

importante. Il s’assure du cheminement des flux d’un bout à l’autre de la chaîne, de la

continuité de la piste d’audit, de l’origine de la pièce justificative jusqu’à son dénouement.

La liste des points faibles et forts est dressée, l’impact sur le plan de mission est précisé.

Le commissaire aux comptes doit développer et maintenir des compétences

pluridisciplinaires (production, comptabilité analytique… et informatique).

c. Appréciation de l’environnement informatique

Avant d’envisager d’extraire des informations, le commissaire aux comptes doit apprécier la

qualité du système d’information et des procédures de contrôle mises en œuvre par

l’entreprise. Ceci afin d’une part d’appréhender la fiabilité des informations gérées par

l’entreprise et de leur restitution et d’autre part d’apprécier le type d’information qu’il est

possible d’extraire.

Une cartographie des applications et interfaces est établie. Les principaux points d’entrée du

système d’information sont identifiés (interfaces, saisie manuelle…).

Ensuite, le fonctionnement du système d’information est modélisé. Des schémas simplifiés,

les Modèles Logiques de Données, représentent de manière simple la circulation de

l’information.



d. Appréciation du contrôle interne

L’auditeur évalue le contrôle interne de la société d’une part en s’assurant de son existence,

de sa suffisance par rapport au caractère significatif des processus clefs de l’entreprise et

d’autre part en vérifiant sa correcte application.

Il acquiert un degré de confiance au fur et à mesure de l’avancement de sa mission. Le

contrôle interne doit garantir la fiabilité de chaque étape d’assimilation et de restitution du

système d’information (collecte, traitement…).

Il ne rentre pas dans les attributions du commissaire aux comptes de rechercher les fraudes

ou malversations au préjudice de l’entreprise ou au profit des dirigeants mais de s’assurer

que la direction a mis en œuvre les outils nécessaires à sa prévention en fonction des

risques propres à l’entreprise. Le commissaire aux comptes veille notamment à ce que les

procédures soient correctement comprises des utilisateurs et appliquées (tests de

permanence).

La fraude est difficile à éviter et à déceler. Même le meilleur des contrôles internes ne peut

que la rendre plus complexe à mettre en œuvre. La fraude est un art qui consiste, à l’aide

d’artifices comptables ou juridiques, à dissimuler des malversations et à leur donner

l’apparence de la normalité. L’absence d’anomalie n’est pas l’absence de fraude. Cependant

la vigilance de l’auditeur et un faisceau concordant d’indices (insuffisances du contrôle

interne, rotation rapide du personnel, risques liés au système informatique…) concourent à

une détection plus probable de la fraude.

3) L’extraction de données et la mission du commissaire aux comptes

L’extraction de données consiste à prélever des extraits de données stockées dans le

système d’information, suivant différents critères. L’extraction de données s’inscrit dans la

démarche d’audit du commissaire aux comptes. On l’a bien compris, l’utilisation des

extractions de données autorise un accroissement de la taille des échantillons à sonder (à

partir de populations de données toujours plus importantes elles aussi) par rapport à des

méthodes de travail plus classiques. Les exceptions (anomalies) sont révélées beaucoup



plus rapidement. Enfin de nouveaux horizons de contrôles s’ouvrent à l’auditeur dont les

rapprochements et comparaisons de fichiers.

Les intérêts des extractions de données pour le commissaire aux comptes sont multiples :

test et validation de procédures, confirmation des points forts, vérification que les risques

décelés (points faibles) ne se sont pas concrétisés en anomalies ou fraudes.

L’utilisation des extractions de données se justifie durant les différentes étapes de la mission

du commissaire aux comptes.

Le commissaire aux comptes va envisager l’extraction de données à deux moments précis

de sa mission : lors de la validation du système d’information et des procédures de contrôle

interne et lors du contrôle des comptes.

a. Validation du système d’information et des procédures de contrôle interne

Les extractions de données et les retraitements opérés par l’auditeur sont une aide

précieuse pour :

- évaluer le risque d’audit,

- tester le fonctionnement du système d’information,

- tester la fiabilité du contrôle interne,

- vérifier la cohérence des données informatiques,

- et tester le risque de fraude.

b. Contrôle des comptes

Les extractions sont également utiles lors de la phase de contrôle des comptes : les

données peuvent être synthétisées, retraitées sous différentes formes pour contribuer à

l’élaboration de la revue analytique, de l’analyse de certains points particuliers (revue des

stocks…).



c. Documentation des travaux effectués

Le monde de l’informatique pousse à la dématérialisation et à l’absence de papier. Or, le

commissaire aux comptes a la nécessité de conserver la trace des travaux effectués malgré

l’absence de matérialité des supports et des traitements qu’il a effectués. Il doit donc

conserver les traitements effectués (requêtes rédigées, tris…), les résultats obtenus, les

commentaires ainsi que les incidences qu’il en a tirées sur son programme de travail.

d. Organisation du cabinet : spécialisation ou généralisation des compétences

Comme nous le verrons dans la deuxième partie de ce mémoire, l’extraction de données

nécessite la mise en place et le suivi d’une démarche rigoureuse et la maîtrise des principes

de fonctionnement des systèmes d’information et des systèmes informatiques. Cette

pratique nécessite des compétences mêlant des notions d’organisation d’entreprise,

d’informatique de gestion voire industrielle, un sens de l’écoute et de la communication ;

compétences qui ne sont pas nécessairement maîtrisées par l’ensemble des collaborateurs

du cabinet.

Suivant la taille du cabinet, l’opportunité de dédier cette tâche à une personne (ou un

service) donnée pourra apparaître comme une solution envisageable. Cependant, il est

nécessaire de sensibiliser l’ensemble de l’équipe d’audit au fonctionnement et à l’exploitation

du système d’information et de développer la parfaite communication en interne afin

d’optimiser les extractions. Ceci est d’autant plus vrai sur les mandats pour lesquels le

système d’information est (prétendument) simple.

4) La réglementation opposable à l’entreprise

a. La nécessité d’informer la direction

Le commissaire aux comptes précise l’étendue de ses travaux dans son plan de mission ;

plan de mission qui est communiqué à la direction de l’entité auditée.



Dans la mesure où les extractions de données sont susceptibles de porter sur des volumes

importants, des données sensibles, il est primordial d’obtenir l’autorisation préalable à

l’obtention des données. Le commissaire aux comptes est tenu de par le code de

déontologie de mettre en œuvre toutes les garanties nécessaires au respect du secret

professionnel et de la protection des données, y compris informatiques, qui lui sont

communiquées dans le cadre de ses investigations.

b. Les prérogatives du commissaire aux comptes

La question est claire : l’entreprise peut-elle s’opposer à l’extraction de données ?

De par le Code de commerce, le commissaire aux comptes peut se faire communiquer

l’ensemble des informations et documents qu’il juge nécessaires à l’accomplissement de sa

mission pour peu que lui-même se conforme au respect des textes et notamment qu’il

préserve la confidentialité des informations qu’il obtient. Les données informatiques sont

donc concernées. L’extraction est toujours effectuée par et sous la responsabilité du

personnel de l’entreprise auditée. L’entreprise pourra préférer communiquer les données

demandées sous forme papier, aucun texte ne la contraignant à fournir les données sous

forme de fichier. Cependant, il est normal que le commissaire aux comptes travaille sur le

même support que celui utilisé par l’entreprise auditée : des données informatiques. En cas

de refus, le commissaire aux comptes devra en tirer les conséquences utiles au bon

déroulement de sa mission et notamment envisager si besoin de réévaluer budgets temps et

honoraires.

c. La réglementation fiscale

La règlementation fiscale impose la conformité des logiciels aux normes (elle concerne

principalement la comptabilité mais également tous les systèmes qui se déversent en

comptabilité, par exemple la gestion des stocks) : traçabilité des écritures comptables,

chronologie et inaltérabilité des enregistrements (sans blanc ni rature), validation des

écritures et clôture irréversibles, extraction et archivage des données. Les éditeurs de

solutions informatiques ne s’y sont pas trompés et font de cette obligation légale un critère



commercial sur lequel ils communiquent (cf un exemple de brochure commerciale en

Annexe I.5).

La règlementation fiscale repose principalement sur deux textes publiés au Bulletin officiel

des impôts sur le thème du contrôle des comptabilités informatisées. Le premier, daté du

24/01/2006 (reproduit in extenso en Annexe I.6), encadre la relation administration fiscale –

contribuable et fixe les obligations de l’administré en matière de normes informatiques et de

communication de données. Le deuxième est extrait de la Loi de finances du 25/12/2007 (cf

Annexe I.7) et précise les options à disposition de l’entreprise en matière d’accès aux

données au profit de l’administration fiscale.

La lecture de ces textes est intéressante, puisque rappelant les principes que les logiciels et

l’entreprise doivent respecter. Ce sont finalement pour une bonne part des principes

comptables que le commissaire est en charge lui-même de faire respecter dans le cadre de

sa mission.

L’extraction et l’archivage des données au format ASCII est une obligation à laquelle

l’entreprise ne peut se soustraire. Certains logiciels ne permettent toujours pas de répondre

à cette obligation. Le commissaire aux comptes a lui-même besoin de l’implémentation de

ces fonctionnalités. De toute façon, l’entreprise a besoin quotidiennement d’extraire et

d’exploiter des données issues de son système d’information, que ce soit pour établir ses

comptes consolidés (export des balances des comptes sociaux), établir des statistiques

commerciales…

La réglementation encadre le déroulement du contrôle des comptabilités informatisées et

fixe les droits et obligations du contribuable. A y regarder de plus près, la réglementation se

borne pour une bonne part à rappeler les prescriptions du Code de commerce en matière

d’organisation du système d’information, de documentation et de contrôle interne. Très

clairement, la réglementation vise l’éradication des logiciels trop « souples » (que certains

nomment même les « pourriciels ») qui favoriseraient la fraude au détriment de l’entreprise…

mais aussi de l’Etat.



L’information est une ressource précieuse que l’entreprise gère à l’aide du système

d’information. L’information financière, les comptes annuels établis par l’entreprise

tirent leur origine du système d’information. Dans le cadre de sa mission légale de

certification des comptes, le commissaire aux comptes s’intéresse au système

d’information, à son fonctionnement, à son contrôle. Le commissaire aux comptes est

confronté à des systèmes d’information variés et complexes. Les volumes

d’information traités par l’entreprise sont de nature diverse et en expansion au fur et à

mesure que le degré d’automatisation augmente. Le commissaire aux comptes n’a

d’autres choix que de réagir et d’informatiser lui aussi ses contrôles. L’extraction et

l’exploitation de données issues du système d’information s’inscrivent dans la

stratégie d’audit du commissaire aux comptes. Cette nouvelle méthode de travail

induit une nouvelle organisation du cabinet et de nouvelles méthodologies.



II. EXTRACTION ET EXPLOITATION DE DONNEES DANS LE CONTEXTE

DU COMMISSARIAT AUX COMPTES : METHODOLOGIE

Nous avons abordé dans la précédente partie les notions fondamentales liées à

l’information, à son traitement et à son caractère vital pour la pérennité de l’entreprise.

Nous avons également vu que le commissaire aux comptes, dans le cadre de sa mission

légale de certification des comptes, s’appuie sur le système d’information pour fonder son

opinion.

Nous allons maintenant étudier le cœur du sujet : l’extraction de données et leur

exploitation, sous forme d’une méthodologie, en évoquant les principaux outils existants.

Cette méthodologie n’a pas la prétention de l’exhaustivité mais a pour vocation d’aider le

commissaire aux comptes dans sa démarche de contrôle informatisé, en lui fournissant

un guide pratique.

Les développements qui suivent font appel à des termes techniques en rapport avec les

bases de données. Afin de ne pas alourdir l’exposé, les principaux termes techniques

sont définis dans le glossaire figurant en Annexe II.1. Par ailleurs, la plupart des notions

relatées dans cette partie sont mises en œuvre dans les cas pratiques traités dans la

partie III. Le tableau figurant en Annexe II.2 assure la liaison entre ces deux parties.

A. Extraction des données

Rigueur et méthodologie sont les maîtres mots d’une extraction de données réussie. En

effet en l’absence de rigueur et de méthode, l’auditeur risque de traiter des données qui

ne correspondent pas à celles qu’il a demandées et de tirer des conclusions erronées.



Le commissaire aux comptes doit documenter ses travaux de la même manière que pour

des contrôles classiques. A cet effet, il sécurise la démarche d’obtention et de traitement

des données en conservant les données d’origine obtenues de l’entité auditée, les

résultats intermédiaires et/ou les requêtes et les résultats finaux ayant conduit à des

conclusions sur les travaux d’audit inclus dans le programme de travail. La traçabilité des

données (par la conservation des données et traitements) est primordiale.

1) Démarche auprès de l’entreprise

a. Informaticiens et comptables : deux langages différents

En vu d’obtenir les données nécessaires à ses contrôles, le commissaire aux comptes

sera généralement orienté vers le service informatique.

Or, les informaticiens utilisent un jargon particulier. De la même manière que les

commissaires aux comptes ont le leur. Avant de définir la démarche d’obtention des

données proprement dite, le commissaire aux comptes doit garder à l’esprit cet aspect

des choses, qui peut s’avérer une difficulté… source d’incompréhension. En effet,

l’informaticien gère le système d’information dans son ensemble sans pour autant

connaître la nature et l’organisation précise des informations que ce système traite.

Il est donc pertinent que les extractions soient opérées par le service informatique sur les

demandes du commissaire aux comptes en liaison avec la direction financière. En effet,

la direction financière émet fréquemment des demandes d’extractions pour son propre

compte et sait traiter les principales difficultés liées à ces pratiques.

Le commissaire aux comptes doit donc gérer deux sources de difficultés :

- les difficultés liées à la manière d’énoncer sa problématique.

- les difficultés liées à la diversité des systèmes informatiques et aux

compétences des interlocuteurs.



Dans la mesure du possible, le commissaire aux comptes doit adopter le langage de

l’informaticien pour faciliter leur compréhension mutuelle.

Une fois franchie la barrière du langage, le commissaire aux comptes formulera ses

vœux en matière de données. Comme nous l’avons vu dans la première partie de ce

mémoire, la mission d’audit légal suit une chronologie. Avant d’envisager l’extraction des

données, le commissaire aux comptes prend connaissance de l’entreprise, de son

environnement, de ses systèmes. Au sujet du système d’information et, par extension, du

système informatique, il s’entretient avec le responsable informatique du fonctionnement

général dans un premier temps (prise de connaissance) puis du fonctionnement de

certains processus élémentaires en fonction des objectifs d’audit définis dans son

programme de travail. Cet entretien est essentiel au bon déroulement de la suite de la

mission. En effet, le commissaire aux comptes acquerra, lors de cet entretien, les

connaissances de base nécessaires à l’élaboration de la cartographie des applications et

des interfaces ainsi qu’à la modélisation du système d’information et à la conception du

Modèle Logique des Données (MLD).

La cartographie des applications et des interfaces présente schématiquement les

différents logiciels assurant le fonctionnement du système informatique ainsi que les

interfaces, c’est-à-dire les moyens de communication entre les applications. Un exemple

figure en Annexe II.4.

Le MLD présente de manière schématique les interactions entre les tables de données,

identifie les champs communs ou liés d’une table à l’autre ; sa lecture permet de déjouer

les pièges nombreux de champs présumés communs entre plusieurs tables. En effet,

certains libellés de champs sont trompeurs ou imprécis. L’exemple le plus courant

concerne les quantités : un stock de produits est suivi en nombre de bouteilles alors que

les produits sont facturés au carton. Sans une étude approfondie débouchant sur

l’élaboration d’un MLD, aucun rapprochement entre les quantités sorties du stock et les

quantités facturées n’est possible. Un exemple de MLD figure en Annexe II.5. Les

principales sources de confusion ainsi que les champs à appréhender sont résumés dans

l’Annexe II.7. En complément, l’auditeur se référera au cahier des charges rédigé en



amont de la conception du système informatique. Ce document décrit précisément le

contenu de l’ensemble des tables de données (cf un exemple en Annexe II.3).

Les données extraites à la demande du commissaire aux comptes ne reflètent que

partiellement le MLD. En effet, d’une manière générale, les extractions se limitent à une

période donnée ou à un échantillon de transactions. En outre, tous les champs de

données contenus dans les différentes tables ne seront pas sélectionnés. De même,

l’informaticien sera souvent tenté de fusionner des tables liées. Cette pratique part d’un

bon sentiment puisqu’elle simplifie la lecture des données de la part du commissaire aux

comptes et lui évite de se préoccuper de la liaison des tables les unes avec les autres.

Cependant cette simplification apparente du travail du commissaire aux comptes

dénature en partie ses contrôles, puisque ses contrôles visent précisément à tester le

cheminement des données dans le système d’information et donc d’une table à l’autre.

Il est donc essentiel, dans la mesure du possible, d’assister aux extractions et d’échanger

avec l’informaticien de manière à corriger au fur et à mesure tout écart avec la demande

formulée par le commissaire aux comptes. Par ailleurs, cela lui permet de prendre plus

ample connaissance avec le système informatique.

On l’a vu, les termes de la demande doivent être précis. Il est préférable de la formuler

par écrit, de manière à éviter des malentendus ou omissions. Mais avant toute demande,

encore faut-il déterminer précisément les contrôles à effectuer, de manière à éviter de

travailler sur un fichier incomplet et d’être obligé de demander une nouvelle extraction et

finalement de perdre du temps.

b. Formulation de la demande d’extraction (sources, critères, champs et format)

En fonction des objectifs d’audit poursuivis, des compétences disponibles au sein de

l’entreprise, du système d’information, des risques ou défauts déjà identifiés, le

commissaire aux comptes définit les échantillons de données qu’il souhaite obtenir. Il

s’agit là d’un préalable incontournable de manière à obtenir avec certitude les

informations demandées.



Il communique à la direction comptable ou au service informatique, selon les cas, les

données qu’il souhaite obtenir en précisant les sources, les critères, les champs et les

formats ; pour formuler sa demande, il se réfère au MLD. Il veille à laisser des délais

suffisants pour que sa demande soit traitée dans les meilleures conditions. Lorsqu’il

intervient dans un groupe de sociétés, le commissaire aux comptes prend soin de

préciser les sociétés concernées par sa demande.

Sources

Le commissaire aux comptes précise la source des données. La cartographie des

applications du système d’information recense l’ensemble des logiciels utilisés par le

système d’information ; chaque application constituant une source de données. Selon les

objectifs poursuivis, plusieurs sources peuvent être simultanément sollicitées.

Par exemple, si l’on se réfère à l’extrait de la cartographie des

applications ci-contre (le schéma complet figure en Annexe II.4),

pour tester l’exhaustivité du transfert de chiffre d’affaires facturé

dans la gestion commerciale vers la comptabilité générale, les

sources de données toutes désignées sont la gestion commerciale

RUBIS et la comptabilité générale TURQUOISE.

Critères

La Norme d’Exercice Professionnel 530 intitulée « Sélection des éléments à contrôler »

indique que le commissaire aux comptes dispose de trois méthodes de sélection des

échantillons : sélection exhaustive de la population, sélection d’éléments spécifiques et

sondages. En fonction de la méthode de sélection retenue, l’auditeur définit ses critères

d’extraction.

La sélection des critères est déterminante. En effet, la représentativité de l’échantillon

obtenu en dépend. Il est nécessaire d’appréhender cette représentativité dès

ComptabilitéTURQUOISEAS400

Gestion commerciale & Gestion des StocksRUBIS



l’élaboration de la requête de manière à éviter de se trouver dans l’obligation de

redemander une extraction. La représentativité peut généralement s’apprécier

approximativement (mais efficacement), en quantité ou en montant, en rapportant

l’extraction sur l’ensemble des données. Par exemple, en extrayant un mois de

facturation, on obtient un échantillon représentant environ 8 % du chiffre d’affaires de

l’exercice (pour un exercice de 12 mois et une activité sans saisonnalité prononcée).

Le choix des critères est assez étendu : fourchette de dates, de numéros de document,

montants compris dans un intervalle donné ou dépassant un certain seuil, état d’une

transaction ou d’un enregistrement (lignes d’écritures lettrées ou non, facturées ou

non…)…

Une des difficultés à appréhender est de retenir des critères permettant de rapprocher

plusieurs tables. Par exemple, le rapprochement d’une table « Bons de commande »

avec une table « Bons de livraison » ne donnera pas les mêmes résultats selon que le

critère d’extraction aura été un intervalle de dates ou un intervalle de numéros de bons

de commande. Dans le premier cas, les dates de bon de commande et de bon de

livraison ne correspondent pas, ce qui signifie que le rapprochement sera imparfait (des

bons de commandes non livrés ressortiront ainsi que des livraisons sans commande).

Alors que dans le second cas, tous les bons de commande et de livraison seront

rapprochés (sauf anomalie réelle).

Champs

Grâce au MLD, le commissaire aux comptes identifie les données dont il a besoin. Les

champs retenus doivent permettre à l’auditeur d’effectuer ses travaux. Par exemple,

l’extraction d’un grand livre général ou auxiliaire portera sur les champs représentant le

numéro de compte, le libellé d’écriture, la date du mouvement, les montants débités et

crédités, le code journal. L’auditeur aura intérêt à obtenir en outre : le code de la section

analytique (en vue d’effectuer des contrôles sur la comptabilité analytique), le code

lettrage (pour tester les équilibres de lettrage ou les opérations non lettrées), le code de

l’utilisateur à l’origine de l’écriture (afin de stratifier les écritures par utilisateur).



L’extrait de MLD ci-contre (dont

l’intégralité est représentée en

Annexe II.5) montre les liens

entretenus entre les bons de

commande et les bons de livraison.

Chaque commande (table

« entêteCommandes ») comprend

plusieurs lignes (1,n) de

commandes (table « Commandes »)

qui elles-mêmes ne sont

référencées que par une commande unique (1,1).

Le lien entre les bons de commande et les bons de livraison (table « entêteBL ») est le

champ « numCDE ».

Au risque de nous répéter, il faut bien prêter attention aux risques de faux amis

engendrés par des noms de champs quelquefois bien obscurs (cf. à ce sujet l’Annexe

II.7).

Formats

Les tables de données représentent sous une forme informatisée les transactions

réalisées par l’entité auditée. La représentation informatique revêt des formes

quelquefois bien différentes de celles usitées dans le langage commun.

Il est donc essentiel de se faire communiquer le format des données que l’on obtiendra

de manière à interpréter les données sans risque de confusion ou d’erreur.

1,n 1,n

1,1

1,1

entêteBL

numBL#numcde

Commandes

numLIG#numCDE#numBL#numBP#numBL#numFRE#réfPF

entêteCommandes

numCDE



Quelques exemples de formats très couramment rencontrés :

Type de données Formats et commentaires Exemple Dates Les dates sont stockées sous des

formats très divers, que ce soit JJ/MM/AAAA, AAAA/MM/JJ, JJMMAA…

Par exemple, pour le 12 mai 2007 : date : 12/05/2007, 2007/05/12, 120507…

Voire dans des champs différents, jj, mm, aaaa encore plus rare ss (siècle), aa (année).

jj : 12, mm : 05, aaaa : 2007 ss : 20, aa : 07

Montants Signification des montants négatifs

Représentation du signe ou du sens d’une transaction : F/A (facture/avoir), D/C (débit/crédit), +/-

Voire sous d’autres formes. Par exemple, moins dix pourra être stockés sous les formes : (10), -10, 10-

La décimale est généralement représentée sous la forme d’un point ou d’une virgule.

10.99 10,99

Dans des cas moins communs, la décimale n’est pas représentée, elle est implicite. C’est à l’auditeur de retraiter la donnée pour lui donner sa valeur réelle

1099

Séparateur de milliers : nul, espace, virgule, point…

1000, 1 000, 1,000, 1.000…

c. Outils d’extraction à disposition de l’entreprise

Il existe plusieurs moyens d’extraire des données. La méthode utilisée dépend de la

nature de l’application gestionnaire des données :

- accès direct aux données : les applications développées intégralement

ou en partie sur des tableurs permettent d’extraire les données

directement. Pour ce faire, il suffit de sélectionner les données

souhaitées puis de les copier dans le presse-papier WINDOWS.

- une option incluse dans le logiciel gestionnaire des données ou un

module externe permet de définir plus ou moins précisément les

paramètres de l’extraction. Les données sont exportées sous forme d’un

fichier texte ASCII.

- sur les logiciels les plus récents gérant des bases de données ORACLE

ou SQL SERVER, l’interrogation est pilotée par une requête SQL à

l’aide d’un module d’interrogation (MS/QUERY, CRYSTAL REPORT,



COGNOS IMPROMPTU) ou à l’aide d’un SGBDR (ACCESS par

exemple). Ces systèmes sont de plus en plus répandus : S1 CEGID,

SAGE LIGNE 1000 SQL SERVER… Cette dernière méthode d’extraction

offre des possibilités d’interrogation très étendues.

Certains logiciels, maintenant assez rares, n’offrent aucune possibilité d’extraction. Ces

logiciels ne sont plus conformes à la réglementation en vigueur. Le commissaire aux

comptes doit en informer la direction de l’entité auditée et s’enquérir auprès d’elle des

mesures correctrices qu’elle compte mettre en œuvre.

L’Annexe II.6 présente un exemple de demande d’extraction de données mettant en

pratique les éléments d’information exposés ci-avant.

2) Contrôle des données obtenues

Une fois les données demandées obtenues, différents contrôles, contrôles visuels et de

conformité, sont effectués. Au préalable, il est nécessaire de préciser le format des

fichiers obtenus pour pouvoir les traiter.

a. Représentation des données extraites

La détermination du format de fichier est un préalable essentiel à son traitement. En

effet, la connaissance du format du fichier définit le logiciel qui permettra de l’ouvrir.

Les données sont généralement extraites sous forme de fichiers EXCEL ou texte (ASCII).

D’autres formats nettement moins usités sont toutefois utilisables tel le DBF (format base

de données DBase qu’EXCEL sait interpréter).

Tout autre format de fichier (propriétaire, spool, PDF…) est usuellement à proscrire

puisqu’il ne permet généralement pas la récupération aisée des données sauf à disposer

d’un logiciel assurant la conversion au format EXCEL ou texte.



b. Contrôle visuel

Le contrôle visuel permet de s’assurer d’un coup d’œil rapide que les données seront

exploitables. Les données doivent apparaître clairement.

Pour effectuer ce contrôle, il suffit d’ouvrir le fichier avec le logiciel associé. Pour

reconnaître le logiciel associé, il faut ouvrir l’explorateur de fichiers Windows :

Le nom du fichier est associé à une icône symbolisant le logiciel ayant la faculté d’ouvrir

le fichier (ici de gauche à droite : Feuille de calcul EXCEL, Base de données ACCESS et

Fichier texte à ouvrir avec le Bloc-Notes).

Ci-après, fichier texte ouvert dans le bloc-note : aucune donnée lisible…

Ci-après, fichier texte ouvert dans le bloc-notes de Windows : les données sont lisibles.

c. Contrôle de la conformité avec la demande formulée

Avant d’entamer de quelconques travaux sur le fichier de données, il convient de

s’assurer que l’extraction obtenue correspond à la demande transmise au service

informatique.



Ce contrôle se fait dans la continuité du contrôle visuel, à l’aide du bloc-notes ou

d’EXCEL. Par exemple la copie d’écran précédente correspond à un grand-livre. Un

défilement rapide du fichier permet de se rendre compte que ce grand livre reprend les

écritures de l’ensemble de l’exercice, ce qui correspond à notre demande.

d. Contrôle de la conformité avec les comptes audités

Ce contrôle nécessite d’effectuer des calculs (totalisation) sur le fichier de données. Il est

donc nécessaire soit d’ouvrir le fichier de données dans un tableur type EXCEL s’il est

enregistré sous forme d’une feuille de calcul soit de l’importer dans EXCEL s’il est dans

un autre format, texte par exemple. Dans ce dernier cas, l’Annexe II.9 décrit la procédure

à suivre pour importer un fichier texte dans EXCEL.

Dans la mesure du possible, l’auditeur tentera de rapprocher le contenu du fichier de

données avec les comptes audités.

En fonction des données extraites, le rapprochement s’effectuera avec la balance

générale (la balance auxiliaire fournisseurs sera rapprochée du compte 401x, les états

stock seront rapprochés des comptes 3x…). Ce rapprochement est aisé lorsque

l’extraction de données porte sur un poste exhaustif. Lorsqu’il ne s’agit que d’un poste

partiel, le rapprochement s’opèrera avec le grand-livre.

B. Exploitation des données

Une fois les données obtenues, le commissaire aux comptes doit les retraiter pour les

adapter à ses logiciels d’audit et à ses besoins. Avant toute chose, il doit choisir ses

logiciels d’audit.



1) Outils informatiques

L’auditeur a le choix entre deux grandes familles de logiciels : les logiciels spécialisés ou

les logiciels bureautiques.

a. Outils spécialisés (IDEA / ACL)

Les logiciels spécialisés ou explorateurs de données ont été développés spécialement

pour procéder à l’analyse de données informatiques. Ils sont utilisés par les

professionnels de l’audit, qu’ils soient auditeurs internes, légaux ou contrôleurs des

impôts.

Les données à auditer sont importées dans le logiciel. Des requêtes prédéfinies sont

paramétrées. Ces requêtes permettent de faire ressortir les points recherchés par

l’auditeur.

L’avantage principal de ces logiciels est la sécurisation de la démarche d’audit. En effet,

les données auditées ne sont jamais altérées par les travaux de l’auditeur mais clonées.

De même, chacun des traitements effectués par l’auditeur est conservé sous forme

d’historique.

IDEA (une brochure présentant les caractéristiques principales du produit figure en

Annexe II.8) et ACL sont les principaux logiciels spécialisés dans l’audit de données

proposés sur le marché.

b. Outils bureautiques (tableur et SGBDR)

Les outils bureautiques à disposition du commissaire aux comptes sont de deux natures :

les tableurs et les systèmes de gestion de bases de données relationnelles (ou SGBDR).

Le tableur est un programme informatique qui manipule des feuilles de calcul. Les feuilles

de calcul permettent de gérer des tableaux de calcul, des bases de données simples,

d’effectuer des calculs évolués, de représenter les données sous forme de graphique de

différents types (diagrammes, courbes, camemberts…).



Le SGBDR quant à lui traite des tables de données. Il est capable de lier des tables entre

elles (par le biais de champs communs), de verrouiller les contraintes d’intégrité,

d’interroger plusieurs tables simultanément afin d’isoler les enregistrements répondant à

certains critères.

Le SGBDR peut être utilisé comme un logiciel d’audit de données tel ACL ou IDEA, la

principale différence étant l’absence des principaux avantages liés à la spécialisation de

ces outils (sécurisation de la démarche d’audit et requêtes prédéfinies).

Comme on le verra par la suite, le tableur et le SGBDR peuvent être utilisés pour

répondre aux mêmes problématiques ou de manière complémentaire.

EXCEL est un tableur. Ce logiciel permet de dresser des feuilles de calcul. Le traitement

de tables de données n’est pas sa spécialité. Il permet toutefois d’effectuer des

traitements élémentaires sur des tables de données (tris, sélection). Cependant, il n’est

pas possible d’effectuer des liaisons entre tables de données. Par contre, EXCEL est

pourvu d’une fonction qui permet, à partir d’une requête SQL écrite dans EXCEL ou

ACCESS, d’afficher le résultat dans EXCEL en vue d’une mise en forme particulière.

La suite Office de Microsoft comprend le tableur EXCEL et le SGBDR ACCESS

(uniquement dans la version professionnelle de la suite). La suite gratuite OpenOffice

comprend le tableur CALC et le SGBDR BASE.

c. Avantages et inconvénients de chaque type d’outils

Chaque type d’outils a ses avantages et ses inconvénients.

Du fait de la sécurisation de la démarche d’audit, les logiciels spécialisés devraient être

préférés aux autres solutions. Cependant, le coût des logiciels d’exploration de données

et la formation nécessaire à leur prise en main doivent être justifiés par une utilisation

intensive.

Comparaison des différents types de logiciels sur plusieurs critères de choix :



Accessibilité Coût Fiabilité de la démarche d’audit

Logiciel spécialisé

SGBDR

Tableur

Du moins au mieux

Indéniablement et malgré ses inconvénients, le tableur est le logiciel le plus utilisé. Sa

prise en main est aisée, il est polyvalent, flexible… et le plus rapidement opérationnel, ce

qui est primordial pour des contrôles uniques qui ne seront pas nécessairement

reproduits. La démarche d’audit pourra être sécurisée à condition de mettre en place des

méthodes rigoureuses que nous exposerons par la suite.

d. Outils utilisés dans le cadre de ce mémoire

Les techniques d’exploitation des données que nous évoquerons par la suite se baseront

principalement sur le SGBDR ACCES et sur le tableur EXCEL, tous deux, en version

2003, édités par MICROSOFT. Ce qui justifie ce choix, c’est que ces deux outils sont les

plus utilisés dans le monde de l’entreprise. Mais les méthodologies et cas décrits tout au

long de ce mémoire sont tout à fait transposables sur des tableurs ou SGBDR d’éditeurs

concurrents au prix de quelques adaptations.

Volontairement, une part essentielle des exemples sera développée sur ACCESS. D’une

part, parce que bon nombre d’auditeurs utilise déjà EXCEL au quotidien et d’autre part,

parce qu’ACCESS permet de traiter des volumes importants de données beaucoup plus

aisément qu’avec un tableur tout en limitant les risques d’erreurs liés aux formules de

calcul.



2) Retraitement préalable des données

Afin d’assurer la traçabilité des données, tout retraitement doit être précédé de deux

précautions :

- conserver une copie des fichiers obtenus de la société auditée avant tout

retraitement (tri…), de sorte qu’il sera toujours possible de retrouver les

données à l’origine de nos travaux.

- numéroter chaque ligne pour pouvoir à tout moment retrouver les

données d’origine.

Préalablement aux manipulations, les données informatiques obtenues de l’entité auditée

font l’objet de différents retraitements et de mises en forme.

a. Retraitements liés au format de fichiers

Que ce soit pour l’utiliser dans EXCEL ou dans ACCESS, le fichier texte transite

généralement par EXCEL en vue d’y subir des retraitements.

Le fichier texte n’est pas directement lisible pas EXCEL, il nécessite auparavant une

conversion en feuille de calcul. Pour ce faire, une procédure d’importation doit être mise

en œuvre. Cette procédure dépend de la nature du fichier texte :

- Fichier à séparateurs (délimité) : les champs de données sont séparés

par un caractère ou un code précis (par exemple une tabulation). Format

« *.CSV » par excellence (coma separated values, valeurs séparées par

des virgules). A noter que le séparateur adopté par EXCEL est le point

virgule (certainement pour éviter la confusion avec la virgule décimale).



- Fichier colonné (à largeur fixe) : les colonnes sont déterminées par leur

largeur.

La visualisation d’un fichier à séparateurs utilisant la tabulation pour

délimiter les champs, à l’aide d’un éditeur de texte, donnera l’illusion d’un

fichier à largeur fixe.

La procédure complète d’identification et d’importation des fichiers texte vers EXCEL est

décrite étape par étape dans l’Annexe II.9.

Une procédure similaire figure en Annexe II.12 pour importer un fichier texte directement

dans une table ACCESS.

A l’issue de la procédure d’importation dans EXCEL, le fichier texte se présente sous la

forme d’une feuille de calcul classique (tableau à double entrée telle une table de base

de données) prête à subir calculs et traitements. Fichier texte importé sous EXCEL :

b. Retraitement lié aux limitations d’EXCEL

EXCEL gère des tableaux composés au maximum de 65 000 lignes de 256 colonnes.

Il n’est pas rare qu’un grand livre dépasse cent mille lignes. Dans ce cas, le fichier texte

obtenu devra être scindé en plusieurs, EXCEL n’étant pas capable de le lire



intégralement. Pour scinder un fichier texte, il faut l’ouvrir avec un éditeur de texte, copier

les 65 000 premières lignes, les coller dans un nouveau fichier texte et procéder ainsi

autant de fois que nécessaire.

Cette contrainte a volé en éclats avec la version 2007 d’EXCEL puisque cette nouvelle

mouture gère des tableaux de 1 000 000 de lignes sur 16 000 colonnes.

ACCESS ne souffre d’aucune limite de ce genre. L’utilisateur pourra donc juger utile

d’importer les données directement dans une table si c’est la destination qu’il leur

réservait.

c. Retraitements liés au format des données

Malgré les normes informatiques, chaque système gère les données à sa manière. Cet

état de fait impacte les données importées.

Ce qui se traduit par des anomalies dans EXCEL lorsqu’il s’agit d’effectuer des calculs

sur les données nouvellement importées. Pour contrer ces problèmes, il faut retraiter les

données. Les exemples sont très divers : problème lié au stockage des dates, absence

de symbole décimal ou symbole décimal ne correspondant pas à celui utilisé par le

système (« . » ou « , »), signe « moins » à droite des montants, espace dans les

montants… Le tableau figurant en II.A.1b reprend les cas les plus communs.

Dans le même genre, des risques liés à des erreurs de saisie peuvent fausser des

calculs ultérieurs. Le cas le plus classique est le 0 (zéro) et la lettre O intervertis. Certains

calculs ne seront pas effectués sans que l’auditeur s’en aperçoive.

EXCEL affiche le texte et les nombres différemment. D’office, le texte est cadré à gauche

et les nombres à droite, ce qui constitue un moyen de déceler les anomalies de visu

rapidement. Cependant, le contenu de toutes les colonnes peut être cadré sur la droite

quel que soit son type.

Pour bien comprendre la problématique, nous allons jouer au jeu des quatre erreurs.

Voici un tableau EXCEL (cf. ci-dessous) spécialement conçu pour la circonstance. Nous



avons quatre colonnes C à F (libellées Montant 1 à Montant 4) qui sont totalisées sur la

ligne 9. Bien que contenant les mêmes données, les totalisations sont toutes différentes.

Sur une liste aussi courte, il est possible de déceler rapidement les erreurs. Sur un listing

de cinquante pages, même avec un œil aiguisé, les erreurs sont quasi-indécelables à

l’œil et le contrôle manuel des formules se révèle fastidieux. Qu’observe-t-on ? Dans la

première colonne, deux erreurs de saisie été commises, la première en cellule C4 (la

lettre O a été saisie à la place d’un chiffre zéro) et en C6 (un point a été saisi à la place

d’une virgule), pour autant la formule de totalisation en C9 est correcte mais ne signale

pas l’erreur (les chiffres erronés ne sont tout simplement pas retenus dans l’addition).

Dans la colonne numéro 2, les mêmes erreurs se sont glissées et en plus la formule de

total oublie la ligne 7 (qui a dû être ajoutée manuellement a posteriori). Colonne 3, la

seule erreur se situe au niveau de la totalisation où l’on observe que le montant a été

saisi manuellement. La seule colonne correcte est la quatrième. Au final, il faut se rendre

à l’évidence que l’incidence de simples fautes d’étourderie s’avère significative.

Pour conclure sur ce point, l’auditeur doit toujours considérer les fichiers EXCEL en

provenance de tiers avec circonspection. En effet, contrairement aux fichiers textes, ils

peuvent contenir des formules (les données affichées à l’écran ne sont donc pas figées),

des données calculées (totaux, moyennes…) à partir de formules erronées, des données

ou des colonnes cachées…

3) Techniques d’exploitation de données

Maintenant que les données ont été correctement mises en forme, l’auditeur peut se

concentrer sur leur exploitation. En fonction de ses objectifs d’audit, l’auditeur dispose de



différentes méthodes de traitement des données en fonction du ou des logiciels (EXCEL /

ACCESS) qu’il utilise. Nous abordons ci-après les principales fonctionnalités intéressant

l’auditeur.

a. Les filtres automatiques, les tris simples et les formats conditionnels

EXCEL offre une panoplie d’outils simples à utiliser qui sont suffisants dès lors que

l’auditeur ne cherche pas à traiter plusieurs tables de données simultanément.

Les copies d’écran qui serviront d’illustration à notre propos sont tirées du cas pratique

traité en III.B.6 (contrôle des stocks).

Les filtres automatiques :

Les filtres automatiques permettent de n’afficher qu’une partie des données de la feuille

de calcul. Pour cela, l’auditeur sélectionne les données à afficher ou exclure en cliquant

sur les en-têtes de champs de données. C’est une forme rudimentaire de requête.

Cette fonctionnalité offre la possibilité à l’auditeur de restreindre ses investigations sur un

sous-échantillon de données. Par exemple, dans un état d’inventaire, il se focalise sur les

produits finis (PF) en cliquant sur PF (cf copie d’écran ci-après).

Pour activer cette fonction, il faut sélectionner les en-têtes de colonnes puis dans le

menu « Données », cliquer sur « Filtrer » puis « Filtres automatiques ».

L’auditeur souhaitera mesurer le caractère représentatif de son sous-échantillon par

rapport à l’échantillon d’origine. Pour ce faire, EXCEL propose la fonction SOUS.TOTAL.



La fonction SOUS.TOTAL effectue des calculs sur les données affichées après

application d’un filtre.

Le fonctionnement de la fonction SOUS.TOTAL(fonction ;plage) est assez simple, calqué

sur la fonction SOMME : fonction indique le type de résultat souhaité (1 : moyenne, 4 et

5 : respectivement valeurs maxi et mini, 9 : somme…).

Si nous reprenons l’exemple de notre stock, l’auditeur a choisi de ne travailler que sur les

produits finis (PF).

Le stock total (tous types de produits) se monte à 1 478 K€ (cellule H19 :

=SOMME(H24:H49994)), le stock de produits finis s’élève à 1 433 K€ (cellule H20 :

=SOUS.TOTAL(9;H24:H49994)) et représente près de 97 % de l’ensemble des stocks.

Dernière fonction intéressant l’auditeur : SOMME.SI(plage ;critère ;somme_plage). Cette

fonction n’additionne que les cellules d’une plage de données répondant à un certain

critère. Par exemple, si l’auditeur souhaite obtenir la somme des valorisations de stock

dont la valorisation individuelle est supérieure à 1000 €, il entrera la formule suivante :

=SOMME.SI(H24:H49994;">1000") et obtiendra 1 340 K€. Le paramètre somme_plage

est facultatif. Il est nécessaire de l’indiquer si le critère est appliqué à une plage différente

de la plage à additionner.

Tris simples

Cette fonctionnalité permet de classer les données selon l’ordre croissant ou décroissant.

On y accède à partir du menu « Données » puis « Trier ». Plusieurs colonnes peuvent

être triées en même temps. Par exemple, des opérations comptables pourront être triées

par date puis par numéro de compte.



Il est possible d’utiliser cette fonctionnalité concomitamment aux filtres automatiques.

Dans ce cas, on clique sur l’en-tête de champs et on sélectionne « Tri croissant » ou « Tri

décroissant ».

b. Les requêtes

Une requête interroge une table ou un ensemble de tables en fonction de critères plus ou

moins élaborés et ressort les enregistrements répondant aux critères.

Les requêtes SQL sont rédigées au sein d’ACCESS, logiciel de gestion de bases de

données relationnelles.

Le but de ce mémoire n’est pas la prise en main d’ACCESS mais bien son utilisation

dans le cadre de l’audit légal du CAC. Cependant, le lecteur trouvera en Annexe II.10 les

rudiments nécessaires à la création d’une base de données, d’une table (ainsi qu’à

l’insertion de données dans une table) et d’une requête.

Les requêtes ont deux utilités principales :

- elles permettent de trier, mettre en forme les données préalablement à

un autre traitement

- elles permettent d’isoler des données, d’effectuer des calculs ou des

regroupements selon des critères déterminés



Requête de base :

Les requêtes sont écrites de deux manières soit sous forme visuelle, soit en SQL. Les

deux méthodes sont complémentaires ; cependant dans certains cas, seul le mode SQL

est utilisable du fait de la complexité des requêtes.

Formulation d’une requête sous forme visuelle (mode création) :

Formulation de la même requête en SQL :

Pour des raisons pratiques, les requêtes exposées dans ce mémoire seront présentées

sous leur forme SQL.

Le SQL (Structured Query Language) est un langage utilisant un nombre restreint de

termes en anglais. La formulation est rigide mais efficace. L’architecture d’une requête

simple est de la forme suivante :



SELECT a, b, c,… La clause SELECT fournit la liste des champs à retenir dans le résultat

FROM table1 La clause FROM indique les tables concernées par la clause SELECT

WHERE condition La clause WHERE contient les critères de sélection

ORDER BY a; La clause ORDER BY trie le résultat de la requête dans l’ordre des champs mentionnés Le point-virgule ponctue la requête

Cette requête affiche les champs « a », « b », « c »,… de la table « Table1 » répondant à

certaines conditions dans l’ordre alphanumérique ou numérique du champ « a ».

Cette architecture est immuable et ne souffre aucune fantaisie.

Exemple :

SELECT [Stock N].Référence, [Stock N].Désignation, [Stock N].Quantité, [Stock N].PU, [Stock N].ValeurStock FROM [Stock N] WHERE ((([Stock N].ValeurStock)>15000));

Dans cet exemple, à partir de la table Stock, on sort les champs Référence, Désignation,

Qté (quantité), PU (prix unitaire) et ValeurStock pour lesquels la ValeurStock et

supérieure à 15 000 €.

Résultat :

Requête1 Référence Désignation Quantité PU ValeurStock06104875 RS48 CORPS REGARD H31 40X40 INT 2406 7,13 17145,2906104880 RS48 REH. REGARD 40X40 INT HT33 3150 6,21 19571,9109404603 COURONNEMENT 265 61,92 16422,8809404608 PANNEAU ANTI-BRUIT LG3.96XLg0.37 RAL5014 137 126,2 17296,3806441400 GBA LG400 STD HT81 (dont 4 clavettes) 71 225,36 16000,704734010 COUVERTINES Lg0.51XHt0.91 LI/BG 333 114,31 38095,1310872016 BETOVET TRAVERT.BARCELONE 6CM B2 8711 4,96 43164,6404732302 CORNICHE LI/BG 21 730,58 15342,27

Définition des critères (clause WHERE) :

La clause WHERE est facultative ; si cette clause n’est pas définie, c’est l’ensemble de la

table qui sera affichée à l’écran en tant que résultat de la requête. Les conditions

s’expriment sous forme de comparaison de champs entre eux ou entre un champ et une

valeur fixe. La comparaison s’opère à l’aide d’opérateurs booléens : = (égal à), < (plus

petit que), > (plus grand que). Plusieurs conditions peuvent être cumulées à l’aide des

mots-clefs OR (ou) et AND (et).



Par exemple, si l’auditeur souhaite obtenir toutes les lignes du stock dont le prix unitaire

(PU) est supérieur à 1 000 € ainsi que toutes les valorisations (ValeurStock) supérieures

à 15 000 €, il rédige sa clause conditionnelle de cette façon :

WHERE ((([Stock N].PU)>1000)) OR ((([Stock N].ValeurStock)>15000))

Pour obtenir toutes les lignes du stock dont le prix unitaire (PU) est supérieur à 1 000 € et

dont les valorisations (ValeurStock) sont supérieures à 15 000 €, il rédige sa clause

conditionnelle de cette façon :

WHERE ((([Stock N].PU)>1000)) AND ((([Stock N].ValeurStock)>15000))

Calculs et traitements:

Il est possible d’effectuer des calculs plus ou moins complexes à l’intérieur même de la

requête (dans la clause SELECT) :

SELECT Référence, Désignation, Quantité, PU, ValeurStock, Quantité*PU-ValeurStock as écartvalo

La partie ajoutée à la clause SELECT calcule la différence entre d’une part, le produit de

Quantité et de PU et d’autre part ValeurStock. Le résultat du calcul est stocké dans un

nouveau champ (lui-même interrogeable ultérieurement) qui se nomme écartvalo.

Les calculs et traitements mêlent indifféremment des opérateurs (+, -, *, /), des

opérateurs booléens et des fonctions.

Les fonctions les plus utilisées sont décrites ci-après :

- ABS(champ) : ôte le signe d’un nombre : ABS(-1) renvoie 1.

- IIF(condition,résultat1,résultat2) : cette fonction permet de renvoyer le

résultat 1 ou le résultat 2 en fonction d’un critère prédéfini. Par exemple,

pour éviter une division par zéro, la formule iif([B]=0,0,[A]/[B]) renvoie le

résultat 0 (zéro) quand le champ [B] est nul, dans le cas contraire la

division de [A] par [B] est effectuée. La fonction IIF est également utilisée

lorsqu’un champ numérique est vide. En effet, si ce champ est intégré



dans une formule de calcul, le calcul ne sera pas exécuté puisque le

contenu du champ n’est pas numérique. La formule iif([champ] is

null,0,[champ]) remplace les champs vides par zéro.

- LEFT(champ,x) : retient les x caractères les plus à gauche du champ. La

fonction RIGHT (droite) suit le même principe pour les caractères les

plus à droite. Par exemple, LEFT(« 681110 »,4) donne « 6811 ».

- LEN(champ) : donne le nombre de caractères compris dans le champs.

- VAL(champ) : convertit une chaîne alphanumérique en un résultat

numérique intégrable dans une formule de calcul.

Ces fonctions sont également utilisables dans la clause WHERE.

Il est tout à fait possible de rédiger des requêtes nettement plus complètes avec des

calculs et des critères multiples.

Sous-requête :

Le résultat d’une requête peut être à son tour interrogé par une autre requête. Les

requêtes sont imbriquées les unes dans les autres. Ces imbrications offrent la possibilité

d’effectuer des calculs dans des sous-requêtes ainsi que des liaisons inter-tables puis

des regroupements dans la requête principale.

Par exemple, l’auditeur, ayant calculé les écarts de valorisation, ne va s’intéresser qu’aux

plus importants, supérieurs à son seuil de signification (5 000 €) :

SELECT Référence, écartvalo FROM (SELECT Référence, Désignation, Quantité, PU, ValeurStock, Quantité*PU-ValeurStock as écartvalo FROM Stock WHERE ValeurStock>15000) WHERE écartvalo>5000;

La requête principale (en italique gras) interroge le résultat de la sous-requête (en

italique).



Les requêtes « regroupement » :

Les requêtes « regroupement » permettent de regrouper toutes les lignes d’une même

table ou d’une sous-requête dont le contenu de certains champs est commun.

Ainsi, pour reprendre notre état de stock, si plusieurs lignes font référence au même code

article, l’auditeur souhaitera les regrouper en une seule et, par exemple, additionner les

quantités.

Requête :

SELECT [Stock N].Référence, [Stock N].Désignation, Sum([Stock N].Quantité) AS SommeDeQuantité FROM [Stock N] GROUP BY [Stock N].Référence, [Stock N].Désignation;

Les champs qui servent de critère de regroupement sont mentionnés dans la clause

GROUP BY. Les champs qui ne servent pas de critère de regroupement font l’objet d’un

calcul : d’une addition (SUM()) comme dans l’exemple proposé, d’une moyenne

arithmétique (AVG()), d’un dénombrement (COUNT())…

Extrait du résultat :

Requête1 Référence Désignation SommeDeQuantité00000150 PALETTE 18100000300 CHEVRON 6X8 160800000512 ELINGUES DIAM 12 MM(F.UT: 500KG) 1200000516 ELINGUES DIAM 16 MM(F.UT:1000KG) 4800000520 ELINGUES DIAM 20 MM(F.UT:1600KG) 6400000524 ELINGUES DIAM 24 MM 15

Une clause HAVING positionnée à la fin de la requête permettra d’ajouter un critère afin

de restreindre le nombre de lignes compris dans le résultat de la requête. Par exemple,

pour ne retenir que les résultats dont la quantité est supérieure à 1 000 :

HAVING (((Sum([Stock N].Quantité))>1000))

Une requête « regroupement » sera utile pour obtenir une balance à partir d’un grand

livre.



Les requêtes « UNION »

La requête UNION assemble le contenu de deux tables ou le résultat de deux requêtes

dont la structure est impérativement identique. Une table A composée de six lignes et

une table B composée de neuf lignes donneront quinze lignes.

Imaginons que l’auditeur dispose de deux états de stock, l’un du dépôt n° 1 et l’autre du

dépôt n° 2, une requête UNION rédigée ainsi lui permettra de ne plus disposer que d’un

seul état :

SELECT [Stock1].Référence, [Stock1].Désignation, [Stock1].Quantité, [Stock1].PU, [Stock1].ValeurStock FROM [Stock1] UNION SELECT [Stock2].Référence, [Stock2].Désignation, [Stock2].Quantité, [Stock2].PU, [Stock2].ValeurStock FROM [Stock2];

Les mêmes références présentes sur les deux dépôts apparaîtront sur deux lignes

distinctes. Une requête de regroupement appliquée sur ce résultat agrégera

opportunément ces références sur une seule ligne.

Les requêtes « jointure »

Les jointures combinent deux tables (ou requêtes) en les joignant à l’aide d’un champ

commun (identifiant / clef étrangère).

La combinaison s’opère avec les opérateurs INNER JOIN, LEFT JOIN et RIGHT JOIN.

INNER JOIN comprend tous les enregistrements dont le contenu d’un champ est

commun à deux tables. LEFT JOIN comprend tous les enregistrements de la première

table (celle située à sa gauche) ainsi que ceux de la deuxième table (celle de droite) dont

le contenu du champ de jointure est commun. RIGHT JOIN opère le même traitement

mais en sens opposé.

Exemple de requête « jointure » :

SELECT FacturesCIALE.numpièce, FacturesCIALE.codetiers, FacturesCIALE.date, FacturesCIALE.TTC, FacturesCIALE.libellétiers FROM FacturesCPTA RIGHT JOIN FacturesCIALE ON FacturesCPTA.réfpièce = FacturesCIALE.numpièce WHERE (((FacturesCPTA.numpièce) Is Null));



Le but de cette requête est de lister les factures générées en gestion commerciale mais

ne figurant pas en comptabilité générale. Cette requête s’inscrit dans le cadre de la

validation du fonctionnement du système d’information dans la mesure où elle teste le

fonctionnement de l’interface entre la gestion commerciale et la comptabilité. Deux tables

sont confrontées FacturesCPTA (comptabilité) et FactureCIALE (gestion commerciale) à

l’aide d’une jointure « RIGHT JOIN ». Le champ commun aux deux tables est le numéro

de facture : « numpièce », identifiant de la table FacturesCIALE et « réfpièce », clef

étrangère de la table FacturesCPTA. La requête renvoie toutes les factures comprises

dans la gestion commerciale (table FacturesCIALE située à droite de RIGHT JOIN)

qu’elles aient ou non une correspondance dans la comptabilité. La clause WHERE ne

retient ensuite que les factures commerciales dont la correspondance en comptabilité est

nulle.

Les requêtes SQL dans EXCEL :

Enfin, précisons qu’EXCEL offre la possibilité d’exécuter des requêtes à partir du menu

« Données », « Données externes », puis « Importer des données ». Cette fonctionnalité

d’EXCEL permet d’importer automatiquement, dans une feuille de calcul, le résultat de

requêtes rédigées en SQL sous EXCEL ou sous ACCESS. Nous n’entrerons pas dans le

détail, la rédaction de ces requêtes répondant aux mêmes spécifications que celles

rédigées dans ACCESS (le lecteur se référera à l’Annexe II.11 qui donne toutes les

explications utiles à la mise en œuvre de cette fonctionnalité). L’attrait majeur de cette

fonctionnalité est d’éviter les « copier / coller » de résultats de requêtes entre ACCESS et

EXCEL.

c. Les tableaux croisés dynamiques

Un tableau croisé dynamique (TCD) est une synthèse générée à partir d’un tableau (ou

table) de données. En fonction des champs de données sélectionnés, une liste de

données de plusieurs milliers d’enregistrements est résumée en quelques dizaines de

lignes. Cette fonctionnalité est présente sur les tableurs modernes comme EXCEL.



La puissance fabuleuse de cet outil est mise à contribution soit sur les données brutes

extraites du système d’information, soit sur des données préalablement retraitées à

l’aide, par exemple, de requêtes.

L’exemple qui suit présente succinctement un extrait de données brutes et le TCD qui en

découle. Cet exemple est expliqué au chapitre B. 3 de la IIIème partie.

Extrait des données brutes : journaux comptables résumés par utilisateur et compte

Utilisateur Journal Compte3 SommeDeDébSommeDeCrédNbOccurrencesIF ACH 401 11,03 258615,84 75IF ACH 445 126,11 0 53IF ACH 607 247868,27 11,12 73IF ACH 608 10621,55 0 75IF BNP 401 601796,96 0 212IF BNP 411 4613,69 1020299,77 549IF BNP 413 0 485049,79 22IF BNP 425 0 76,22 1IF BNP 467 0 466,53 1IF BNP 512 1508071,77 606410,65 755IF BNP 627 70,1 0 4IF BNP 658 0,44 0 1IF BNP 791 0 2250 1IF CAE 411 187,51 1792397,65 1779IF CAE 445 3,17 0 1IF CAE 467 0 1256,97 1IF CAE 511 1793637,53 0 1778

Extrait du TCD (l’Annexe III.2 en reproduit l’intégralité) :

Somme de NbUtilisateurJournaCompt IF LL LM MB PEC PP SAL SC SH SL SY THOM Total

ACH 401 75 332 576 983411 14 14445 53 306 555 914607 73 318 576 967608 75 9 84609 37 80 117

Total ACH 276 1016 1787 3079

Ce TCD résume les journaux comptables (colonne de gauche) par compte et par

utilisateur.

A l’aide de cette synthèse, l’auditeur perçoit d’un coup d’œil quels sont les utilisateurs qui

saisissent des écritures, dans quels journaux et dans quels comptes. Par exemple IF a

saisi 75 lignes d’écritures dans les comptes 401x du journal d’achats (ACH).



En double-cliquant sur l’un des résultats, EXCEL ouvre un nouvel onglet et affiche les

lignes de données à l’origine du résumé.

Le TCD est utile toutes les fois que l’auditeur a besoin de résumer de longues listes de

données pour en retirer l’essentiel.

Quelques exemples d’usage du TCD :

- bouclage des réciprocités intra-groupe à partir des balances générales

des différentes sociétés composant un groupe

- analyse de l’évolution d’un compte (de trésorerie par exemple), mois par

mois, voire jour par jour…

L’auditeur sélectionne les champs de données à afficher avec parcimonie sous peine

d’obtenir un TCD comprenant de trop nombreuses colonnes et lignes qui s’avèrera

finalement illisible.

L’Annexe II.13 donne les différentes étapes à suivre en vue de constituer un TCD.

d. Exemples de traitements à opérer sur les données obtenues

Les traitements à opérer par l’auditeur sur les données sont très variés.

En voici quelques exemples :

- Calcul du solde de la balance générale, du grand livre,

- Calcul de l’équilibre des écritures, du lettrage,

- Rapprochement de postes (stock, journal de paye…) avec la balance

générale,

- Test d’intégrité référentielle et rupture de la piste d’audit (tester que les

factures de ventes sont rattachées à un client et à un bon de livraison),



- Vérification de la chronologie des écritures (numéro de pièce et date) :

détecter des factures effacées puis recréées ultérieurement avec le

même numéro…,

- Détection des doublons (factures, enregistrements…),

- Détection de rupture de séquence de numérotation (numéro de pièce,

ticket Z manquant…),

- Test de cohérence de données, test des assertions d’audit… : quantité *

prix unitaire = total, quantité livrée = quantité facturée, quantité livrée =

quantité sortie du stock, quantité négative (stock, livraison, facture (retour

marchandises ?)…),

- Détection du chiffre d‘affaires comptabilisé sans facture,

- Détection des factures non comptabilisées,

- Analyse de la concentration d’un portefeuille client à partir de la balance

auxiliaire (TTC) ou mieux du grand livre (HT),

Certains de ces exemples sont développés dans la IIIème partie de ce mémoire. La

diversité des exemples évoqués ci-dessus démontre l’attrait que représente l’exploitation

des données informatiques pour le commissaire aux comptes. Le système d’information

recèle des sources inépuisables de données. Il appartient au commissaire aux comptes

de cerner, en fonction des zones de risques identifiées, les objectifs d’audit appropriés

afin de tester le fonctionnement du système d’information et de valider la cohérence des

données.

Le choix des outils d’exploitation et de retraitement des données dépend des objectifs et

des compétences techniques de l’auditeur. D’autant que l’auditeur dispose fréquemment

de plusieurs solutions pour répondre à un même problème. Par exemple, pour créer une

balance à partir d’un grand livre, il faut ni plus ni moins additionner tous les montants

débiteurs et créditeurs pour chaque compte différent rencontré soit à l’aide d’une requête



de regroupement ACCESS (GROUP BY), soit à l’aide d’un tableau croisé dynamique

EXCEL.

Ces différentes méthodes d’exploitation des données sont mises en application dans les

cas pratiques développés dans la partie III de ce mémoire.

Dans cette deuxième partie, nous nous sommes attachés à présenter les bases

d’une méthodologie d’extraction et d’exploitation de données issues du système

d’information. Cette méthodologie, accessible à tous, est basée sur des logiciels

bureautiques et ne nécessite pas d’investissement dans des logiciels spécialisés.

Dès le début, nous avons mis l’accent sur la rigueur et la méthode nécessaires à la

garantie de la fiabilité des travaux du commissaire aux comptes et de l’assurance

raisonnable qu’il se doit d’acquérir (notamment sur la conservation et la traçabilité

des données) en préalable à l’émission de sa certification des comptes.



III. EXEMPLES D’OUTILS EXPLOITANT LES DONNEES EXTRAITES

Dans la précédente partie de ce mémoire, nous avons abordé les aspects techniques de

l’extraction et de l’exploitation des données informatiques. Nous allons maintenant mettre

en pratique les différentes notions d’exploitation des données extraites à l’aide de cas

concrets. Les requêtes, tableaux croisés dynamiques, tris et filtres seront développés

plus amplement ce qui s’avère être un prétexte tout trouvé pour démontrer l’apport

essentiel des extractions et plus généralement des traitements informatiques dans la

mission du commissaire aux comptes.

Chaque cas pratique sera repositionné dans le contexte de la mission du commissaire

aux comptes et exposera la problématique, les données à obtenir (difficultés), les outils

utilisés, la démarche suivie, le résultat obtenu et le cas échéant l’incidence sur la mission

du commissaire aux comptes ; la démarche technique de traitement des données sera

expliquée ; bien entendu, toutes les étapes d’obtention, de sécurisation, de contrôle et de

traitement des données étudiées dans la précédente partie ne seront pas rappelées. Le

lecteur est invité à s’y reporter en cas de besoin.

Toutes les applications qui sont présentées ci-après n’ont que valeur d’exemple illustrant

les techniques et méthodologies détaillées dans la précédente partie. Bien d’autres

exemples auraient pu être abordés mais leur nombre aurait dépassé le cadre de ce

mémoire. Chaque dossier étant un cas particulier (du fait de l’extrême diversité des

systèmes informatiques, les données sont traitées de manière différentes), il conviendra

d’adapter ces exemples.

Les extractions répondent à différents types d’objectifs. Les exemples que nous allons

étudier sont classés en trois catégories d’objectifs d’audit :



- le contrôle de la cohérence du système d’information : à l’aide de

ces contrôles, l’auditeur s’assure que l’information circule sans altération

ni omission entre les différents composants du système d’information.

- le contrôle de la cohérence des données : l’auditeur vérifie la

cohérence des données et leur conformité avec des règles comptables,

fiscales, légales…

- le risque de fraude est mesurable grâce à une loi mathématique et

décelable grâce à l’observation du fonctionnement d’ensemble de la

comptabilité ; qui plus est, ces méthodes sont assez simples à mettre en

œuvre.

A. Contrôle de cohérence du système d’information

Dans la première partie de ce mémoire, nous avons vu que le commissaire aux comptes

s’appuie sur le système d’information dans le cadre de la certification des comptes. Il

s’assure de la fiabilité des processus à l’origine de l’information financière produite par la

société auditée. Le commissaire aux comptes vérifie notamment que l’information circule

sans incident entre les différents modules du système d’information et que les

procédures sont correctement appliquées. Les exemples qui suivent visent précisément à

accompagner le commissaire aux comptes dans ses contrôles, d’une part en validant les

interfaces (exemples 1 et 2) et d’autre part en recherchant l’origine des transactions

(exemple 3).



1) Interfaces : contrôle de cohérence des informations transférées

au sein du système d’information

a. Objectif du contrôle

Le commissaire aux comptes est amené à valider le fonctionnement du système

d’information. Les interfaces, points de liaison entre les différents modules du système

d’information, sont un des éléments déterminants de la fiabilité de l’ensemble.

Pour illustrer ce propos, nous allons prendre pour exemple le transfert du chiffre

d’affaires entre la gestion commerciale et la comptabilité générale. L’auditeur aura à

cœur de rapprocher la facturation générée par la gestion commerciale du chiffre

d’affaires comptabilisé et par conséquent tester l’exhaustivité du chiffre d’affaires. Bien

d’autres contrôles sont possibles comme le rapprochement des bons de livraisons avec

la facturation, les sorties de stock avec les bons de livraison…

b. Données à obtenir

Deux tables de données sont à requérir, d’une part la facturation issue de la gestion

commerciale et d’autre part le journal des ventes figurant en comptabilité. Pour chacune

des tables, le numéro de facture (élément commun aux deux tables) et le montant TTC

sont les deux champs minimaux à obtenir. Le montant TTC comptabilisé s’obtient assez

facilement, il suffit pour cela d’extraire les montants débiteurs et créditeurs sur les

comptes 411x dans le journal de vente.

Les échantillons obtenus comprennent 6962 enregistrements pour les factures

comptabilisées et 7976 enregistrements pour les factures issues de la gestion

commerciale.

c. Démarche et outils

Trois contrôles sont à mettre en œuvre :



- vérifier que les montants comptabilisés correspondent aux montants

facturés,

- vérifier que les factures émises par la gestion commerciale ont été

transférées en comptabilité exhaustivement,

- vérifier que les factures comptabilisées sont toutes issues de la gestion

commerciale.

Avant tout, on va créer deux tables dans ACCESS, la première se nommera

FacturesCIALE et la seconde FacturesCPTA. La copie d’écran suivante présente la table

FacturesCPTA en mode création, avec les champs et leurs types :

Pour répondre au premier objectif, à partir d’ACCESS, rédiger la requête suivante :

Test : ReqCAok (1) (2) (3) (4) (5) (6)

SELECT * FROM (SELECT FresCIALE.numpièce, FresCIALE.MtTTC, FresCPTA.MtTTC, FresCIALE.MtTTC-FresCPTA.MtTTC AS ecart FROM (SELECT réfpiècecourt, sum(montantTTC) as MtTTC FROM FacturesCPTA GROUP BY réfpiècecourt) as FresCPTA INNER JOIN (SELECT numpièce, sum(TTC) as MtTTC FROM FacturesCIALE GROUP BY FacturesCIALE.numpièce) as FresCIALE ON FresCPTA.réfpiècecourt = FresCIALE.numpièce) WHERE abs(ecart)>0.01 ORDER BY ecart;

(3) Les lignes d’écritures comptables figurant dans les journaux de ventes sont

regroupées par numéro de facture, les montants TTC (mouvements des comptes 411x

débiteurs et créditeurs) sont additionnés ; de sorte que l’on obtient une liste de factures

avec les montants TTC.



(4) Les factures commerciales sont regroupées selon le même principe. Puis ces deux

listes sont confrontées (INNER JOIN) à l’aide du champ commun aux deux listes (ON

FresCPTA.réfpiècecourt = FresCIALE.numpièce), à savoir le numéro de facture.

(1) (2) Les différents champs utiles à nos travaux sont sélectionnés et l’écart entre le

montant TTC facturé et comptabilisé est dégagé.

(5) Seuls les écarts supérieurs à un centime sont intégrés à la liste ; ce seuil est

volontairement très bas dans la mesure où aucun écart ne peut a priori être toléré à ce

niveau (validation du fonctionnement du système d’information).

(6) Les écarts sont classés par ordre numérique.

Il faut bien voir que cette requête ne prend en compte que les factures qui sont présentes

dans les deux tables. Elle vérifie que les factures créées en gestion commerciale sont

comptabilisées pour le même montant. D’où les deux autres requêtes.

Les requêtes à rédiger pour répondre aux deux autres objectifs de contrôle sont

reportées en Annexe III.1.

d. Résultat obtenu et interprétations

Le résultat des trois requêtes est le suivant :

- La première requête ne ressort aucun écart supérieur à un centime

d’euro. Les factures communes aux tables facturation commerciale et

comptabilité générale sont donc de même montant.

- Les deux autres requêtes ne révèlent aucune ligne, n’indiquant aucune

discordance entre la facturation commerciale et la comptabilité. Des

écarts auraient pu apparaître. La gestion peut comprendre des factures à

montant nul non comptabilisées : certaines entreprises génèrent une

facture lorsqu’elles envoient des échantillons gratuits à leurs clients ou

prospects. Un autre cas moins commun est évoqué au point B. 4.d. Ces



factures ne sont pas transférées en comptabilité. A l’inverse, toutes les

factures comptabilisées ne sont pas issues de la gestion commerciale.

Ces factures constatent généralement des transactions exceptionnelles

(cessions d’immobilisations, ventes de produits ou de prestations non

référencés en gestion commerciale…), comptabilisées directement en

comptabilité, quelques fois en journal d’OD.

Les écarts issus de ce genre de contrôles doivent faire l’objet d’une recherche

d’explication approfondie dans la mesure où le fonctionnement même du système

d’information est concerné.

2) Test d’intégrité référentielle


L’appréciation du fonctionnement du système d’information, dans la continuité des

travaux évoqués dans l’exemple précédent, conduit le commissaire aux comptes à suivre

la piste d’audit. La piste d’audit ou chemin d’audit suit un déroulement logique,

prédéterminé, clairement établi sans détour, étape par étape. Les flux d’information,

reflets de flux physiques ou financiers, sont retracés par le système d’information. Il est

possible de remonter la chronologie des événements en partant des documents

comptables. En cas de rupture dans le cheminement, l’intégrité des flux, des opérations

comptables sera menacée. De fait, la rupture de la piste d’audit laisse des informations

orphelines.

L’intégrité référentielle garantit que la donnée d’une table qui fait référence à une autre

table ne puisse être supprimée de la table « parente » ; par exemple, un compte du plan

comptable ne peut être supprimé s’il a été mouvementé par une écriture. Les requêtes 2

et 3 de l’exemple précédent de par leur conception testent l’intégrité référentielle.



L’exemple que nous allons développer recherchera les factures qui auront été émises

sans bon de livraison préalable. Dans une activité de vente de produits finis, la

facturation sans bon de livraison appuyant la livraison n’est pas la norme.


Deux tables de données seront à solliciter :

- D’une part, la table des lignes de bons de livraison (intitulée BL). Pour

mémoire, un bon de livraison est retranscrit en informatique en deux

tables : la table des en-têtes qui contient les informations générales

(code client, date de livraison…) et la table de lignes qui comprend les

références et quantités des biens livrés. Les factures sont codifiées de la

même manière. Les champs utiles à nos travaux sont : le numéro de BL

(identifiant principal), le code article et la quantité.

- D’autre part la table des lignes de facture (intitulée Lignesfactures) avec

les champs numéro de facture, numéro de bon de livraison, code article

et quantité.


Dans ACCESS, la requête suivante liera les deux tables :

Test : Factures avec BL inconnus (1) (2)

SELECT Lignesfactures.numfre, Lignesfactures.datefre, Lignesfactures.numclient, Lignesfactures.raisonsocclt, Lignesfactures.numbl, Lignesfactures.datevalidbl, Lignesfactures.codeart, Lignesfactures.désigart FROM Lignesfactures WHERE (((Lignesfactures.numbl) Not In (select [NUMBL] from [BL] group by [NUMBL])));

(1) La requête renvoie les champs numéro et date de facture, numéro et nom de client,

numéro et date de bon de livraison, code et désignation d’article des enregistrements de

la table Lignefactures pour lesquels (2) le numéro de bon de livraison n’existe pas dans

la table des livraisons.




La requête ne ressort qu’un seul résultat :

Test : Factures avec BL inconnus numfre datefre numclient raisonsocclt Numbl datevalidbl codeart désigart 07L0667 20070531 30547 GENIE CIVIL

PHOCEEN1207040173 20070425 04739000 PLUS VALUE

ARMATURE BATIMENT

Il y a donc eu une facturation n’ayant pas pour origine une livraison. Cependant l’intégrité

référentielle n’est pas remise en question. En effet, il s’agit d’un complément de prix

facturé à un client avec son accord sur un article donné. La piste d’audit ne prend donc

pas sa source d’une livraison mais d’un accord écrit dû à une différence sur le prix d’une

matière première entrant dans le coût de fabrication.

3) Séparation des pouvoirs : identification des auteurs d’écritures


Dans la première partie, nous avons vu que chaque salarié d’une entreprise a des

fonctions précises. Ces fonctions sont décrites dans des fiches de poste. Dans le cadre

de l’approche par les risques, le commissaire aux comptes a durant la phase de prise de

connaissance résumé les fonctions des salariés dans une grille de séparation des

tâches. Cette grille doit mettre en lumière le manque éventuel de séparation des

fonctions comptables et les risques liés à ces manquements.

Cette grille établie, le commissaire aux comptes peut s’interroger sur la réelle application

de cette séparation. En effet, les habilitations octroyées dans le système informatique à

chaque salarié peuvent avoir été paramétrées sans respecter strictement les fiches de

poste.

A ce stade, le commissaire aux comptes tirera pleinement partie de la traçabilité offerte

par certains systèmes informatiques. Ces systèmes enregistrent à ce titre les données

nécessaires à la révision de la piste d’audit, à savoir les références de la pièce

justificative à l’origine de la comptabilisation (ce qui est un minimum) ainsi que l’utilisateur

à l’origine du déclenchement de la comptabilisation de l’écriture. Le commissaire aux



comptes dispose alors des moyens utiles au rapprochement des droits des utilisateurs

tels que définis par les fiches de poste avec les auteurs des écritures comptabilisées.

C’est tout l’objet de l’exemple suivant qui s’appuiera sur les Annexes I.1 (organigramme

fonctionnel), I.2 (fiches de poste) et I.3 (grille de séparation des fonctions).

Dans cet exemple, nous ventilerons les écritures du grand livre par journal (ventes,

achats, banque…), par indicatif de compte (641x, 512x, 607x…) et par code utilisateur.


Pour effectuer ce contrôle, il suffit d’obtenir un grand livre. L’un des champs de données

devra indiquer le code utilisateur. La période demandée n’est pas anodine. En effet, il est

préférable d’obtenir un grand livre sur les périodes de l’année les plus sensibles,

notamment au moment des congés annuels où les services comptables doivent gérer

des absences.

Le grand livre obtenu (35 849 lignes d’écritures) s’étend de juillet à août, période sensible

pour la société auditée (activité de négoce de poissons), puisqu’elle doit faire face à une

pointe d’activité l’été (approvisionnement de nombreux restaurants sur la côte normande)

et à un service comptable en effectif « allégé » du fait des congés annuels.

Extrait de la table GL (grand livre) dans ACCESS :

GL NumLIG NumECR Compte Libellé Débit Crédit Journal Date Utilisateur Pièce 1 15934 61320008 FACTURE LA POINTE 10500 0 ACF 20070701 LL 5519 2 15934 44566000 FACTURE LA POINTE 2058 0 ACF 20070701 LL 5519 3 15934 401XR08 FACTURE LA POINTE 0 12558 ACF 20070701 LL 5519


Dans ACCESS, rédiger la requête suivante :



Test : GL classé par utilisateur (1)

SELECT GL.Utilisateur, GL.Journal, Left([Compte],3) AS Compte3, Sum(GL.Débit) AS SommeDeDébit, Sum(GL.Crédit) AS SommeDeCrédit, Count(GL.Crédit) AS NbOccurrences FROM GL GROUP BY GL.Utilisateur, GL.Journal, Left([Compte],3);

(1) La requête regroupe le grand livre par code utilisateur et par racine de compte (3

positions).

Le résultat de la requête se résume à une liste (en l’occurrence de 207 lignes) qui n’est

pas très lisible à première vue.

Extrait du résultat de la requête :

Test : GL classé par utilisateur Utilisateur Journal Compte3 SommeDeDébit SommeDeCrédit NbOccurrencesIF ACH 401 11,03 258615,84 75IF ACH 445 126,11 0 53IF ACH 607 247868,27 11,12 73IF ACH 608 10621,55 0 75IF BNP 401 601796,96 0 212IF BNP 411 4613,69 1020299,77 549

Pour rendre ce résultat plus visuel, nous allons le transformer en un tableau croisé

dynamique. Pour ce faire, nous allons copier le résultat de la requête dans EXCEL et

créer un tableau croisé dynamique avec en ligne les codes journaux et racines de

comptes, en colonnes les codes utilisateurs et en données le nombre de lignes

d’écritures.


Voici un extrait du TCD (le TCD complet est présenté en Annexe III.2) :



Somme de NbUtilisateurJournaCompt IF LL LM MB PEC PP SAL SC SH SL SY THOM TotalACF 215 1 1

218 1 1401 275 42 19 336411 7 7445 249 37 14 300602 31 31604 19 19606 38 8 4 50608 5 5611 8 8613 12 12615 68 1 69616 5 5621 7 7622 11 11623 3 3624 43 43625 4 32 14 50626 11 11628 1 1635 1 1651 5 5709 10 1 11

Total ACF 815 121 51 987ACH 401 75 332 576 983

411 14 14445 53 306 555 914607 73 318 576 967608 75 9 84609 37 80 117

Total ACH 276 1016 1787 3079

Ce tableau est un véritable tableau de bord de l’activité comptable de l’entreprise. En

effet, il affiche pour chacun des utilisateurs tous les journaux et les comptes

mouvementés. Par exemple, l’utilisateur SAL a comptabilisé des achats dans le journal

ACH pour un total de 1787 lignes.

Il ne reste plus au commissaire aux comptes qu’à rapprocher ce tableau de la grille de

séparation des fonctions, conclure sur son respect et émettre ses éventuelles

observations et recommandations.

Par exemple, LL (responsable administratif et financier) est à l’origine de la

comptabilisation de 815 lignes d’écritures dans le journal ACF (frais généraux) sur les

987 figurant en comptabilité, d’un tiers des lignes d’écritures (soit 1016 lignes) du journal

ACH (achats de marchandises), des écritures de trésorerie et des OD. Ces constats

rapprochés à ses attributions résumées de sa fiche de poste amènent l’auditeur à

remarquer que LL cumule des fonctions de détention de moyen de paiement, de

signature (fonctions « officielles ») avec des fonctions d’enregistrement liées (fonctions



de fait). Si ces cumuls sont saisonniers, le commissaire aux comptes doit tout de même

en tenir compte dans l’appréciation de son risque et l’orientation de ses contrôles.

B. Contrôle de cohérence de données

Les données informatiques stockées dans le système d’information, quelle que soit leur

origine, répondent à des spécifications techniques tantôt issues des procédures, tantôt

de la législation ou de principes comptables intangibles.

Le commissaire aux comptes, dans le cadre de ses investigations courantes, s’attache à

contrôler la cohérence des documents comptables avec la comptabilité, le respect des

procédures comptables. Les cas pratiques qui suivent ont pour but d’aider l’auditeur à

s’assurer de la cohérence de données et des traitements les ayant générées. Les

anomalies relevées fourniront une information précieuse, preuves d’insuffisance des

procédures ou pire de fraudes.

1) Comptabilité auxiliaire : contrôle d’équilibre du lettrage

L’un des principes de base de la comptabilité est la partie double. C’est donc tout

naturellement que le commissaire aux comptes cherchera à tester cet équilibre que ce

soit pour des écritures comptables ou des journaux.


Dans l’exemple qui suit, nous nous assurerons que l’équilibre du lettrage des comptes

auxiliaires est respecté.

Le lettrage des comptes auxiliaires permet de rapprocher des créances ou dettes avec

des règlements. Le lettrage doit faire correspondre des montants débiteurs et créditeurs

d’égal montant. Cependant certains logiciels comptables autorisent des lettrages partiels

(non équilibrés). De fait, les grands livres des écritures non lettrées risquent d’induire le



commissaire aux comptes en erreur en soustrayant de son analyse des dettes ou

créances non soldées.

Cet exemple est très aisément déclinable pour tester l’équilibre des écritures ou des

journaux.


Pour procéder à ce contrôle, il suffit d’obtenir un grand livre en prenant soin d’obtenir,

dans l’un des champs, les codes de lettrage.

L’exemple se base sur le grand livre (plus de 143 mille lignes pour un exercice) d’une

entreprise de négoce de produits d’emballage (palettisation, hôpitaux, liquide, gants à

usage unique…)

Extrait du grand livre (table ACCESS GL) :

GL compte date journal pièce Libellé lettrage débit crédit 401000 101105 ACH 11050045 FACT N9UF CEGETEL K 1038,7 401000 101105 ACH 11050049 FACT S.T.I.O. E 8747,76 401000 101105 ACH 11050050 FACT SOCOTEC EQUIPEMENTS NORMANDIE D 354,65 401000 111105 ACH 11050156 AVOIR INICIATIVAS PLASTICAS S.L. K 289,49


La requête ci-après additionne les montants débiteurs et créditeurs et calcule un solde

lettrage de toutes les écritures par compte et code lettrage. La clause HAVING permet de

ne retenir que les lettrages non équilibrés.

Equilibre lettrage (1)

SELECT [GL].comptegal, [GL].lettrage, Sum([GL].débit) AS SommeDedébit, Sum([GL].crédit) AS SommeDecrédit, Sum(nz([débit],0)-nz([crédit],0)) AS solde FROM [GL] GROUP BY [GL].comptegal, [GL].lettrage HAVING (([GL].lettrage) Is Not Null) AND (abs(Sum(nz([débit],0)-nz([crédit],0)))>0.01);




Dans notre cas, tous les lettrages sont équilibrés, aucune ligne ne ressort.

Dans le cas contraire, il aurait fallu ressortir les écritures dont le lettrage est partiel et

obtenir des explications de la part de l’entité auditée.

2) Reconstitution des à-nouveaux

Les à-nouveaux sont la résultante du bilan N-1.


L’objectif du présent contrôle est de s’assurer que les à-nouveaux de l’exercice sont

conformes au bilan de clôture N-1.


Le grand-livre intégral N-1 ou la balance générale N-1 et le journal des à-nouveaux N ou

le grand livre N.


Une fois le grand livre N (table GL N) et la balance générale N-1 (table BG N-1) importés

dans des tables ACCESS, une requête en trois éléments sera rédigée :

- (5) le premier élément établit le journal des à-nouveaux, pour cela les

lignes d’écritures du journal « RAN » sont additionnées par compte.

- (2) le deuxième élément calcule les soldes des comptes à fin N-1. Une

difficulté se fait jour ; (3) en effet, les comptes de gestion (6x et 7x) à fin

N sont repris en à-nouveau dans le compte de résultat (12x).



- (1) (6) enfin, ces deux éléments (le solde N-1 (issu de la balance N-1) et

le report à nouveau (issu du grand livre N)) sont confrontés (4) et les

éventuels écarts mis en lumière.

Test : RAN (1)

SELECT comptegal, sum([solde N-1]) as [BG N-1], sum(RAN) as ANV,sum([solde N-1]-RAN) as ECART

(2) FROM (select comptegal, sum(solde) as [solde N-1],0 as RAN (3) FROM (SELECT IIf(Left(compte,1)="6" or left(compte,1)="7","120000",compte) as comptegal, débit-

crédit as solde FROM [BG N-1]) GROUP BY comptegal

(4) UNION (5) SELECT [GL N].comptegal, 0 as [solde N-1],Sum(nz([débit],0)-nz([crédit],0)) AS RAN

FROM [GL N] GROUP BY [GL N].comptegal, [GL N].codejal HAVING ((([GL N].codejal)="RAN"))) (6) GROUP BY comptegal;

On est parti de la balance N-1. Si l’on était parti du grand livre, il aurait fallu le transformer

en balance ; pour ce faire, la requête suivante aurait été nécessaire :

ReqTransf GL en BG (1)

SELECT [GL N-1].cptegal, Sum([GL N-1].déb) AS débit, Sum([GL N-1].créd) AS crédit FROM [GL N-1] GROUP BY [GL N-1].cptegal;

(1) La requête regroupe les numéros de compte et additionne tous les mouvements

débiteurs et tous les mouvements créditeurs.


Extrait du résultat obtenu :

ReqRAN & BG N-1 comptegal BG N-1 ANV ECART 101309 -700000 -700000 0 104200 -2322,04 -2322,04 0 106119 -70000 -70000 0 106809 -1232833,44 -1232833,44 0 120000 -258368,64 -258368,64 0 145000 -13747,87 -13747,87 0 164100 -130844,82 -130844,82 0 164300 -121685,99 -121685,99 0 164800 -151649,56 -151649,56 0

Si on souhaite n’obtenir que les anomalies, c’est-à-dire les écarts différents de zéro, il

suffit d’ajouter une clause HAVING en fin de requête (juste avant le point virgule) :

HAVING sum([solde N-1]-RAN)<>0.



Dans notre exemple, aucun écart n’apparaîtra. Les à-nouveaux figurant au bilan

d’ouverture correspondent donc à la balance auditée lors de l’exercice précédent.

3) Paye : évolution des charges sur un exercice

Dans le cadre de l’audit des comptes, l’auditeur est fréquemment amené à s’interroger

sur l’évolution de certains comptes, que ce soit pour effectuer une revue analytique,

analyser la cohérence ou la saisonnalité de mouvements ou d’une activité sur un

exercice ou entre plusieurs exercices. Cette analyse de l’évolution de comptes ou de

postes concernera tout aussi bien la trésorerie, les achats de matières, les ventes ou

encore les charges de personnel. Cette évolution peut être mise en concurrence avec

une autre afin d’en tirer des conclusions.


C’est précisément cette comparaison que nous nous emploierons à mettre en œuvre.

Nous allons prendre l’exemple du poste des charges de personnel. Sur un même

exercice, l’évolution des salaires bruts et des charges sera comparée et un taux de

charges sociales moyen sera calculé.

Différents paramètres expliquent les évolutions de masse salariale d’un mois sur l’autre :

saisonnalité de l’activité (CDD, primes), les départs (indemnités de licenciement,

transaction…), les provisions (congés payés, primes de fin d’année), le 13ème mois, les

primes de vacances…


Pour réaliser ces travaux, un grand livre conviendra parfaitement.


Dans ACCESS, il convient de rédiger la requête suivante :



RA 641x - 645x - 70x (1) (2) (3) (4) (5)

SELECT aaaamm, sum(solde641) AS 641x, sum(solde645) AS 645x, sum(solde70) AS 70x FROM ( SELECT Left([comptegal],3) AS compte3, Year([Dateécrit]) & "/" & IIf(Len(Month([Dateécrit]))=1,"0","") & Month([Dateécrit]) AS aaaamm, Sum(IIf([débit] Is Null,0,[débit])-IIf([crédit] Is Null,0,[crédit])) AS solde641, 0 as solde645, 0 as solde70 FROM [GL] GROUP BY Left([comptegal],3), Year([Dateécrit]) & "/" & IIf(Len(Month([Dateécrit]))=1,"0","") & Month([Dateécrit]) HAVING (((Left([comptegal],3))="641")) UNION SELECT Left([comptegal],3) AS compte3, Year([Dateécrit]) & "/" & IIf(Len(Month([Dateécrit]))=1,"0","") & Month([Dateécrit]) AS aaaamm, 0 AS solde641, Sum(IIf([débit] Is Null,0,[débit])-IIf([crédit] Is Null,0,[crédit])) AS solde645, 0 AS solde70 FROM [GL] GROUP BY Left([comptegal],3), Year([Dateécrit]) & "/" & IIf(Len(Month([Dateécrit]))=1,"0","") & Month([Dateécrit]) HAVING (((Left([comptegal],3))="645")) UNION SELECT Left([comptegal],2) AS compte3, Year([Dateécrit]) & "/" & IIf(Len(Month([Dateécrit]))=1,"0","") & Month([Dateécrit]) AS aaaamm, 0 AS solde641, 0 AS solde645, -Sum(IIf([débit] Is Null,0,[débit])-IIf([crédit] Is Null,0,[crédit])) AS solde70 FROM [GL] GROUP BY Left([comptegal],2), Year([Dateécrit]) & "/" & IIf(Len(Month([Dateécrit]))=1,"0","") & Month([Dateécrit]) HAVING (((Left([comptegal],2))="70")) ) GROUP BY aaaamm;

(1) (5) La requête regroupe en un seul résultat la totalisation mensuelle des comptes :

- (2) de salaires bruts 641x,

- (3) de charges sociales 645x et

- (4) de chiffre d’affaires 70x.

Précision : l’expression « IIf(Len(Month([Dateécrit]))=1,"0","") » stipule que si la longueur de la

chaîne alphanumérique du mois tient sur un chiffre (janvier à septembre), un zéro est

ajouté à gauche de sorte que le mois est représenté sur deux positions, par exemple

septembre 2007 sera stocké sous la forme 2007/09 et non pas 2007/9. Cette forme de

présentation aaaa/mm est retenue dans le seul but d’être classée facilement dans l’ordre

numérique des années et mois, ce que ne permettrait pas la présentation mm/aaaa.

Le résultat de la requête est le suivant :

RA 641x - 645x - 70x aaaamm 641x 645x 70x 2006/07 -61481,05 -22255,82 1182175,26 2006/08 84033,6 35253,18 704671,9499999992006/09 93270,7 33540,58 1283881,62 2006/10 86702,39 35836,31 1079546,66 2006/11 77706,88 31506,77 1175471,05 2006/12 137185,4 57743,21 997923,949999999



RA 641x - 645x - 70x aaaamm 641x 645x 70x2007/01 83659,77 34416,82 1331612,962007/02 83573,08 34922,04 1194818,352007/03 86295,08 35831,77 1256277,092007/04 93929,77 39655,47 1091592,062007/05 88826,74 36010,2 1159051,612007/06 264376,71 106994,06 1287161,73


Le résultat de la requête est intégré dans une feuille de travail spécifique réalisée sur

EXCEL, reproduite en Annexe III.3.

Cette feuille permet à l’auditeur d’analyser les principales variations mois par mois, de

dresser des constats et d’orienter ses contrôles de comptes. Dans le cas présent, de

nombreux faits expliquent les variations de masse salariale d’un mois sur l’autre ainsi que

de taux de charges sociales, tels que des reprises ou dotations de charges à payer, des

versements de primes…

4) Trou de numérotation

L’absence de « trou » dans la numérotation des pièces comptables est une des règles

prescrites par la réglementation comptable. En effet, la rupture dans la séquence de

numérotation est révélatrice de la suppression de pièces comptables, ce qui d’un point de

vue fiscale est prohibé et du point de vue de l’auditeur met en lumière une défaillance

potentielle dans les procédures.


Pour illustrer notre propos, nous allons rechercher dans la facturation commerciale la

présence de ruptures dans la numérotation des factures.




Un extrait de la table des en-têtes de facture de la gestion commerciale fournira notre

base de travail. Sur le principe, le seul champ indispensable est le numéro de facture.

Dans l’exemple retenu, la table de facturation commerciale extraite représente plus de

sept mille factures pour un mois de facturation.


Dans ACCESS, la requête suivante est écrite :

Test : Trou séquence numérotation (1) (2) (3) (4)

SELECT FacturesCIALE.numpièce, TTC FROM [SELECT FacturesCIALE.numpièce-1 as np2, FacturesCIALE.numpièce as numpièce2 from FacturesCIALE]. AS FacturesCIALE2 RIGHT JOIN FacturesCIALE ON FacturesCIALE2.np2 = val(FacturesCIALE.numpièce) WHERE (FacturesCIALE2.numpièce2 is null);

(2) Dans un premier temps, à partir de la liste des factures, on crée une sous-requête

(nommée « FacturesCIALE2 ») qui renvoie la liste des numéros de facture décrémentés

de un sous le champ np2 (ainsi la facture 60706954 devient 60706955) associée à la

liste des numéros d’origine (sous le champ numpièce2).

(3) Puis la table « FacturesCIALE » est liée à la sous-requête (2) à l’aide d’une jointure

(RIGHT JOIN) ; les champs de liaison étant np2 et numpièce.

(1) (4) Les numéros de facture n’apparaissant pas dans les deux tables sont listés.

Pour comprendre le fonctionnement de cette requête, nous allons nous appuyer sur des

extraits de la table « FacturesCIALE » et du résultat de la sous-requête FacturesCIALE2 :

Table FacturesCIALEChamp numpièce np2 numpièce2Contenu […] 60706947 60706948

60706948 60706948 6070694960706949 60706949 6070695060706950 60706950 6070695160706951 60706951 6070695260706952 60706952 6070695360706953 60706953 6070695460706954 RUPTURE 990509520 990509521990509521 990509521 990509522990509522 990509522 990509523990509523 990509523 990509524990509524 […] […]

FacturesCIALE2



Lorsque la requête parvient sur le numéro de facture 60706950 de la table

« FacturesCIALE », elle trouve son homologue dans la table « FacturesCIALE2 » (champ

np2), ce qui signifie que la facture 60706951 existe (60706951-1 = 60706950). Tandis

que lorsque la requête arrive sur la facture 60706954, elle ne trouve aucune

correspondance dans la sous-requête FacturesCIALE, preuve qu’une rupture se fait jour.

Cette requête n’est applicable qu’à condition que la numérotation des factures ne

comprenne que des chiffres. Par ailleurs, il faut également que la numérotation soit

strictement continue, ce qui exclut les numérotations incluant l’année ou le mois (du type

« F2007/09/0832 »).

Sur des listes importantes, la requête peut mettre plus de dix minutes avant d’afficher un

résultat. Pour rendre la requête plus rapide, il faudrait créer une table temporaire, y

insérer une liste de factures dépourvue de rupture (les fonctions MIN et MAX appliquées

à la liste permettant d’obtenir le premier et le dernier numéro de facture) puis de

rapprocher l’échantillon et la table temporaire. Malheureusement, ACCESS ne permet

pas ce genre de traitement en SQL. La forme de requête retenue n’est pas très élégante

mais malgré mes recherches et consultations, je n’ai pas trouvé d’autres solutions en

SQL.


La requête renvoie le résultat suivant :

Test : Trou séquence numérotationnumpièce TTC

60706954 711,11990509626 78,68

De par le fonctionnement de la requête, en l’absence de rupture dans la séquence de

numérotation, seule la dernière ligne de l’échantillon audité devrait ressortir (puisque par

définition, la dernière facture interrompt la continuité de la suite numérique). La deuxième

ligne du résultat correspond bien à la dernière facture de notre échantillon ; par contre, la

première ligne est une anomalie.



Avant d’envisager de plus amples investigations, visionnons des extraits de la table

« FacturesCIALE » :

FacturesCIALE Numpièce DateF TTC

60700001 03/07/2006 112,6760700002 03/07/2006 224,3560700003 03/07/2006 158,95

[…] […] […]60706952 31/07/2006 -27,1860706953 31/07/2006 59,5960706954 31/07/2006 711,11990509521 01/07/2006 73,53

[…] […] […]990509624 28/07/2006 87,94990509625 28/07/2006 148,76990509626 28/07/2006 78,68

Nous observons, qu’effectivement la séquence de numérotation est rompue après la

facture n° 60709654. Après entretien avec le service comptable, nous apprenons que la

société émet des factures pour le compte d’un fournisseur en contrepartie d’une

commission. Ces factures font l’objet d’une numérotation spécifique afin de différencier

les factures propres des factures tiers.

5) Ventes : contrôle de taux de TVA

Beaucoup de données gérées par le système d’information sont l’aboutissement d’un

calcul. Il en est ainsi de la plupart des taxes. Le commissaire aux comptes, dans le cadre

de ses investigations, est amené à vérifier par sondage le calcul de ces taxes.


Ces contrôles portent notamment sur la TVA et en l’occurrence dans le cas pratique que

nous allons maintenant aborder, la TVA collectée sur le chiffre d’affaires.

Ce contrôle est effectué lorsqu’un doute sur les taux de TVA appliqués apparaît ou que

des inversions de comptabilisation HT / TVA se font jour.




Un grand livre général avec les champs classiques (compte, date, numéro de pièce,

débit, crédit, code journal) suffit.


Dans ACCESS, coller le grand livre dans la table GL puis rédiger la requête suivante :

Jal VTE -> TAUX DE TVA par op° (1) (2) (3) (4) (5) (6)

SELECT * FROM (SELECT datefre, pièce, SommeDeHT, SommeDeTVA, iif(sommedeHT=0,-1,round(sommedeTVA/sommedeHT*100,2)) AS TxTVA FROM (SELECT datefre, pièce, Sum(HT) AS SommeDeHT, Sum(TVA) AS SommeDeTVA FROM (SELECT gl.date as datefre, gl.pièce, IIf([débit] Is Null,0,[débit])-IIf([crédit] Is Null,0,[crédit]) AS HT,0 as TVA FROM gl WHERE (((gl.journal)="VTE") AND (((Left([compte],1))="7") OR ((Left([compte],1))="6"))) UNION SELECT gl.date as datefre, gl.pièce, 0 as HT,IIf([débit] Is Null,0,[débit])-IIf([crédit] Is Null,0,[crédit]) AS TVA FROM gl WHERE (((gl.journal)="VTE") AND ((Left([compte],4))="4457"))) GROUP BY datefre, pièce) ORDER BY pièce) WHERE TxTVA<>19.60 and TxTVA<>5.50;

(4) Les montants HT (comptes 7x) des journaux de vente (VTE) sont additionnés par

pièce de vente (facture) ; par extension, les comptes 6x (escomptes) figurant au journal

de vente sont intégrés dans le calcul.

(5) Cette requête effectue le même calcul qu’en (4) mais avec la TVA. Les requêtes (4) et

(5) sont réunies (UNION) puis regroupées (3).

(2) A partir du résultat de la sous-requête (3), le taux de TVA appliqué à l’écriture

comptable est calculé en rapportant le montant de la TVA (sommedeTVA) au montant HT

(sommedeHT) ; si le montant HT s’avérait être nul, le taux de TVA serait arbitrairement

fixé à -1.

(1) Enfin, à partir du résultat de la sous-requête (2), seules les lignes dont le taux de TVA

est différent de 5,5 % et 19,6 % seront retenues (6).

Bien entendu, les taux de TVA retenus doivent être adaptés à la législation en vigueur.

Quant au code journal de vente, il est modifié pour tenir compte de celui retenu dans la

comptabilité auditée. A ce sujet, si plusieurs journaux de ventes sont utilisés, par



exemple VTE1 et VTE2, la clause « (gl.journal)="VTE") » sera utilement remplacée par

« ((gl.journal)="VTE1") OR (gl.journal)="VTE2")) ».


Sur le cas qui nous occupe, la requête a renvoyé 1175 lignes. En voici un court extrait :

Jal VTE -> TAUX DE TVA par op°

datefre pièce SommeDeHT

SommeDeTVA TxTVA

10705 2005070003 8,64 1,69 19,5610705 2005070050 -28,23 -5,53 19,5910705 2005070051 -56,46 -11,07 19,6110705 2005070052 -28,23 -5,53 19,5910705 2005070053 -28,23 -5,53 19,5910705 2005070114 -36,04 -7,06 19,5910705 2005070118 -9,74 -1,91 19,6110705 2005070153 -21,59 -4,23 19,5940705 2005070159 -980 0 040705 2005070160 -2257,92 0 040705 2005070171 -1216,2 0 040705 2005070182 -69 -13,52 19,5960606 2006060180 -856,06 -131,61 15,37

L’analyse des résultats de la requête nous amène à les ventiler en trois catégories :

- Dans la première, la plus représentative, les taux de TVA sont voisins de

19,60 % : 19,59, 19,61… Il s’agit de différences d’arrondi. Ces résultats

n’entraînent aucune incidence pour nos contrôles.

- La deuxième fait état de taux de TVA nuls. Il s’agit de factures en

franchise de TVA (export).

Requête1 compte date journal Pièce Libellé lettrage débit Crédit 411000 40705 VTE 2005070159 Facture 2005070159 A 980 707400 40705 VTE 2005070159 Facture 2005070159 980

- Dans la troisième catégorie, les taux de TVA calculés ne se rapprochent

ni des taux en vigueur ni de zéro. Après analyse, il ressort que certaines

factures comprennent des articles facturés au taux normal et d’autres au

taux réduit, ce qui génère des taux moyens compris entre 5,50 % et

19,60 %.

Requête1 compte Date journal Pièce libellé lettrage Débit crédit



Requête1 compte Date journal Pièce libellé lettrage Débit crédit 411000 60606 VTE 2006060180 facture 2006060180 F 987,67 445700 60606 VTE 2006060180 facture 2006060180 117,5 445710 60606 VTE 2006060180 facture 2006060180 14,11 707100 60606 VTE 2006060180 facture 2006060180 599,5 707150 60606 VTE 2006060180 facture 2006060180 256,56

Bien entendu, cette requête n’est pas applicable dans tous les secteurs d’activité. En

effet, l’utilisation de cette requête sur des sociétés pratiquant la taxation à la marge sur

les ventes de biens d’occasion (concessionnaires automobiles, marchands de biens…)

ou réalisant des exportations ou des ventes en franchise renverrait beaucoup trop de

résultats à contrôler pour être efficace.

6) Stocks : contrôle de la variation N/N-1 prix et quantité

Le commissaire aux comptes a assisté à l’inventaire physique des stocks et encours, il a

effectué des prises d’inventaire, s’est assuré de la correcte application des procédures, a

vérifié qu’elles sont appropriées. Il a apprécié les écarts entre l’inventaire physique et

l’inventaire permanent.

Le contrôle des stocks est une phase incontournable du contrôle des comptes. Le

commissaire aux comptes doit s’assurer que les états d’inventaire ayant servi de base à

la comptabilisation des stocks sont conformes d’une part en quantité en les rapprochant

avec les feuilles de comptage et ses prises d’inventaire et d’autre part en valeur en

rapprochant les prix unitaires avec des factures d’achat (marchandises, matières

premières).

Cependant, face aux milliers de lignes que comprennent certains états d’inventaire, les

contrôles s’avèrent assez rapidement lourds à mener. Là encore, grâce à l’informatique,

l’auditeur automatisera de multiples contrôles.


L’application qui sera présentée ci-après remplira un triple objectif :



- faciliter les contrôles de valorisation,

- faciliter l’analyse des variations N/N-1,

- faciliter la révélation des principales erreurs.


Il faut obtenir de la société auditée les états d’inventaire N & N-1 mentionnant pour

chaque produit : la référence article, la désignation, la quantité, le prix unitaire, le total.

Les états d’inventaires sont établis sous EXCEL (cf échantillon ci-après) et comprennent

plus de 1300 lignes pour l’exercice N et 1500 lignes pour N-1.


A partir des états d’inventaire N & N-1 importés dans ACCESS, le résultat de la requête



suivante permet de déceler d’éventuelles erreurs de calcul (valorisation différente de

quantité x PU) ou de cohérence (quantité négative…).

ReqCompareStocks (1) (2) (3) (4) (5)

SELECT Référence, Désignation, Famille, SousFamille, Typeproduit, SommeDeqtéN AS QtéN, SommeDePUN AS PUN, SommeDeVSN AS VSN, [SommeDeqtéN-1] AS [QtéN-1], [SommeDePUN-1] AS [PUN-1], [SommeDeVSN-1] AS [VSN-1], SommeDeqtéN-[SommeDeqtéN-1] AS VarABSQté, SommeDePUN-[SommeDePUN-1] AS VarABSPU, iif([SommeDeqtéN-1]<>0,(SommeDeqtéN-[SommeDeqtéN-1])/[SommeDeqtéN-1],999999999) AS VarRELQté, iif([SommeDePUN-1]<>0,(SommeDePUN-[SommeDePUN-1])/[SommeDePUN-1],999999999) AS VarRELPU, QtéN*PUN-VSN AS EcartValoN, [QtéN-1]* [PUN-1]- [VSN-1] AS [EcartValoN-1], iif(qtéN<0 or Isnumeric(qtéN)=0,"X","") AS ErrQtéN, iif([qtéN-1]<0 or Isnumeric([qtéN-1])=0,"X","") AS [ErrQtéN-1], iif((PUN<=0 and QtéN<>0) or Isnumeric(PUN)=0,"X","") AS ErrPUN, iif(([PUN-1]<=0 and [QtéN-1]<>0) or Isnumeric([PUN-1])=0,"X","") AS [ErrPUN-1], iif(Abs([EcartValoN])>0.01 or Isnumeric(EcartValoN)=0,"X","") AS ErrValoN, iif(Abs([EcartValoN-1])>0.01 or Isnumeric([EcartValoN-1])=0,"X","") AS [ErrValoN-1] FROM (SELECT Référence, Désignation, Famille, SousFamille, Typeproduit, Sum(qtéN) AS SommeDeqtéN, Max(PUN) AS SommeDePUN, Sum(VSN) AS SommeDeVSN, Sum([qtéN-1]) AS [SommeDeqtéN-1], Max([PUN-1]) AS [SommeDePUN-1], Sum([VSN-1]) AS [SommeDeVSN-1] FROM (SELECT [Stock N].Référence, [Stock N].Désignation, [Stock N].Famille, [Stock N].SousFamille, [Stock N].Typeproduit, iif([Stock N].Quantité Is Null,0,[Stock N].Quantité) AS qtéN, iif([Stock N].PU Is Null,0,[Stock N].PU) AS PUN, iif([Stock N].ValeurStock Is Null,0,[Stock N].ValeurStock) AS VSN, 0 AS [qtéN-1], 0 AS [PUN-1], 0 AS [VSN-1] FROM [Stock N] UNION SELECT [Stock N-1].Référence, [Stock N-1].Désignation, [Stock N-1].Famille, [Stock N-1].SousFamille, [Stock N-1].Typeproduit, 0 AS [qtéN], 0 AS [PUN], 0 AS [VSN], iif([Stock N-1].Quantité Is Null,0,[Stock N-1].Quantité) AS [qtéN-1], iif([Stock N-1].PU Is Null,0,[Stock N-1].PU) AS [PUN-1], iif([Stock N-1].ValeurStock Is Null,0,[Stock N-1].ValeurStock) AS [VSN-1] FROM [Stock N-1]) GROUP BY Référence, Désignation, Famille, SousFamille, Typeproduit);

(3) La requête extrait les champs référence, désignation, quantité, prix unitaire… des

états d’inventaire N ; des champs N-1 à zéro sont créés dans la perspective d’un

regroupement avec la table N-1

(4) La requête effectue la même tâche que la requête (3) mais avec les données de

l’exercice N-1). Cette requête et la requête (3) sont réunies (UNION).

(2) Les requêtes (3) et (4) sont regroupées (GROUP BY) (5) ; si une même référence

figure plusieurs fois sur l’état d’inventaire, les quantités et les valorisations totales sont

additionnées, le prix unitaire retenu est le plus élevé (MAX).

(1) A partir du résultat de la requête (2), des calculs sont effectués ; par exemple :

« iif([SommeDeqtéN-1]<>0,(SommeDeqtéN-[SommeDeqtéN-1])/[SommeDeqtéN-1],999999999) AS

VarRELQté » : cette expression calcule la variation relative N/N-1 des quantités (à condition

que la quantité N-1 ne soit pas nulle).

« [QtéN-1]* [PUN-1]- [VSN-1] AS [EcartValoN-1] » : détermine l’éventuel écart entre la valorisation

quantité N-1 x prix unitaire N-1 et la valorisation de l’état d’inventaire N-1.



« iif(qtéN<0 or Isnumeric(qtéN)=0,"X","") AS ErrQtéN » : si la quantité N est inférieure ou égale à

zéro, la réponse est « X » sinon c’est une chaîne vide. Le « X » servira par la suite à

mettre en évidence des anomalies.

Pour résumer, cette requête permet de faire ressortir les valorisations des stocks N et N-

1, les variations N/N-1 ainsi que les écarts de valorisation et les anomalies. Les

anomalies relevées par cette requête sont de plusieurs natures : quantités négatives, prix

unitaire négatif ou nul, écart de valorisation (notamment dû à des confusions entre la

lettre O et le chiffre zéro…).

Le résultat de la requête est collé (dans la zone jaune) dans un tableau EXCEL dont un

extrait est reproduit en Annexe III.4.


L’utilisation de ce tableau est assez simple. Il donne un éventail complet des contrôles

que l’auditeur peut avoir à effectuer sur des états d’inventaire. Par ailleurs, ce tableau

mêle différentes notions abordées dans la deuxième partie de ce mémoire.

Ainsi :

- La partie « Récapitulatif » donne la totalisation du stock N et N-1

(SOMME()), le nombre de lignes (NB)) et les écarts N / N-1. Ces mêmes

informations sont fournies pour une sélection de lignes (SOUS.TOTAL())

dont les critères sont indiqués par l’utilisateur (à l’aide de filtres de

données).

- La partie « Détail » mentionne toutes les informations nécessaires à la

revue de l’état d’inventaire. Il est possible de trier les lignes et de

sélectionner des critères (filtres) pour, par exemple, n’afficher que telle

ou telle famille de marchandises. La représentativité du stock affiché par

rapport au stock global est calculée.



- Enfin, grâce aux formats conditionnels, les anomalies révélées par la

requête par des « X » ressortent en couleur attirant de suite l’attention de

l’auditeur. Par ailleurs, il est possible, à l’aide des filtres, de n’afficher que

les lignes comportant des anomalies. L’auditeur peut ainsi concentrer

ses travaux sur ces lignes et en mesurer en quelques instants leur

caractère significatif (en visualisant dans la zone « Récapitulatif » le ratio

de représentativité relative).

Dans le cas qui nous intéresse, la plupart des anomalies relevées sont des écarts

d’arrondis. Des erreurs de saisies plus manifestes se sont fait jour. Le total des écarts de

valorisation de l’exercice N se monte à 6 K€ dont 3 K€ sur une seule ligne. Cet écart,

rapporté à la valorisation totale du stock soit 1 478 K€, n’est pas significatif. Malgré les

quelques anomalies relevées, la valorisation calculée est acceptable.

C. Risque de fraude

Comme nous l’avons déjà évoqué dans la première partie de ce mémoire, il n’est pas

dans les attributions du commissaire aux comptes de rechercher la fraude. Néanmoins,

la NEP 240 intitulée « Prise en considération de la possibilité de fraude lors de l’audit des

comptes » précise qu’il est du devoir du commissaire aux comptes d’évaluer le risque

d’anomalies significatives dues à des erreurs ou à des fraudes et de mettre en oeuvre

des procédures d’audit appropriées. A l’aide d’outils simples, le commissaire aux

comptes a les moyens de détecter rapidement des anomalies ou des risques particuliers.

Bien entendu, ces outils n’ont pas vocation à se substituer aux méthodes traditionnelles

d’enquête du commissaire aux comptes dans l’évaluation du risque de fraude mais au

contraire à l’accompagner en l’orientant ou en complétant ses axes de recherche.

Dans ce cadre, nous aborderons deux méthodes de détection, la première s’appuie sur

l’organisation des écritures comptables, la seconde sur une théorie mathématique, la loi

de Benford.



1) Comptabilité générale : contrôle des exceptions


L’organisation de la comptabilité est pour une bonne part normée et répond à une logique

d’ensemble assez aisément modélisable.

Par exemple, le compte « 411x. Clients » enregistre au débit la facturation TTC de

l’entreprise dans un journal de vente et au crédit les encaissements TTC dans des

journaux de caisse et de banque. D’autres types d’écritures usuelles peuvent apparaître

(effet à recevoir, avoirs, escompte).

La revue exhaustive de visu du grand livre est inenvisageable du fait du volume

d’écritures à passer en revue. Par contre, l’informatique peut aider le commissaire aux

comptes. En effet, comme l’on vient de le dire, la logique générale de la comptabilité est

normée et modélisable. Il est donc possible de faire ressortir les écritures qui ne

répondent pas à des critères définis ; ces écritures, les exceptions, feront l’objet de la

part du commissaire aux comptes d’un examen particulier et d’une demande

d’explications. S’agissant de l’évaluation du risque de fraude, le commissaire aux

comptes va ainsi à l’essentiel sans perdre de temps.

Pour le compte « 411x », il s’agit généralement d’écritures d’OD de reclassement en

« 416x. Clients douteux » ou de passage en pertes et profits. Dans des cas moins

fréquents (mais courant dans certains secteurs d’activité, tels la grande distribution), on

trouve des compensations « 411x » – « 401x ».

Nous aborderons deux exemples précis :

- l’un donnera une sorte de tableau de bord de la comptabilité,

- l’autre fournira les exceptions à des critères prédéterminés par l’auditeur.




Les données à obtenir sont un grand livre général (nous avons retenu pour l’exemple qui

nous occupe un extrait de grand livre d’une taille honorable : plus de 35 000 lignes pour

deux mois) avec les champs : numéro de compte, code journal, débit et crédit.


Dans ACCESS, créer une table GL (pour grand livre) comportant au moins les champs

cités ci-dessus.

Ci-contre, les champs

créés dans la table GL.

Ci-après, un court

extrait du contenu de la table GL :

GL NumLIG NumECR Compte Libellé Débit Crédit Journal Date Utilisateur Pièce

1 15934 61320008 FACTURE LA POI 10500 0 ACF 20070701 LL 55192 15934 44566000 FACTURE LA POI 2058 0 ACF 20070701 LL 55193 15934 401XR08 FACTURE LA POI 0 12558 ACF 20070701 LL 5519

Puis, rédiger la requête suivante :

Test : GL classé par journaux et comptes (D&C) SELECT GL.Journal, Left([Compte],3) AS Compte3, Sum(GL.Débit) AS Déb, Sum(-[Crédit]) AS Créd,

Count(GL.Crédit) AS NbOccurrences FROM GL GROUP BY GL.Journal, Left([Compte],3);

L’objectif de cette requête est de regrouper les lignes d’écritures comptables par code

journal et par racine de compte (3 positions). Toutes les lignes d’écritures dont le numéro

de compte sur trois positions et le code journal sont communs sont additionnées en débit

et en crédit, le nombre de lignes concernées est additionné. Le résultat obtenu est le

suivant (extrait) :

Test : GL classé par journaux et comptes (D&C) Journal Compte3 Déb Créd NbOccurrencesACF 215 119400 0 1ACF 218 8810,73 0 1ACF 401 4756,64 -763233,89 336ACF 411 0 -3139,18 7ACF 445 101605,8 -262,15 300ACF 602 99256,75 0 31



L’air de rien, le résultat de cette requête nous présente en seulement 116 lignes (alors

que nous partons d’une base de plus de trente cinq mille lignes d’écritures) un résumé de

l’activité comptable. L’inconvénient c’est que tel qu’il est présenté, il est illisible. Afin de

rendre ce résultat exploitable, nous allons copier le résultat de la requête et le coller dans

EXCEL. Enfin, nous allons constituer un tableau croisé dynamique afin de présenter en

colonne les journaux et en ligne les comptes.


Voici un extrait du tableau croisé dynamique obtenu ; la version complète figure en

Annexe III.5.

Journal Compte3 Données ACF ACH ACP BNP EAR VTE Total 164 Somme de Déb 12511,9 26149,25

Somme de Créd -0 0

215 Somme de Déb 119400 119400

Somme de Créd -0 0

218 Somme de Déb 8810,73 8810,73

Somme de Créd -0 0

771 Somme de Déb 0

Somme de Créd -1229,84

791 Somme de Déb 0 0

Somme de Créd -2250 -2250

Total Somme de Déb 767991 1667670 637635 3022104 521991 3866253 17766741

Total Somme de Créd -767991 -

1667670 -637635-

3022104 -521991-

3866253 -17766741

Il s’agit-là d’un véritable tableau de bord. En effet, l’ensemble des schémas d’écriture

transparaît journal par journal. Le tableau est à double entrée : on peut le lire en colonne

(journal) ou en ligne (compte). Par exemple, le journal d’achats (ACH) révèle que les

seuls comptes utilisés sont : 401x, 411x, 607x, 609x. Le 401x est débité dans le journal

d’achat ce qui semble correspondre à des avoirs. Le compte 411x est mouvementé dans

le journal d’achat ce qui semble anormal ; une requête permet de constater qu’il s’agit de

compensations avec des factures de centrales d’achat (grande distribution). Dans l’autre

sens, on constate que le compte 411x est débité dans différents journaux autres que de

vente et notamment des journaux de trésorerie. Il s’agit d’annulations de règlements

saisis deux fois et de traites (36 lignes).



D’une manière générale, il est possible assez simplement d’obtenir les exceptions à

l’utilisation normale d’un compte. Pour en revenir au compte client (411x), il suffit

d’extraire les lignes d’écriture dont le journal de vente est crédité (débit=0) ou les

journaux de trésorerie sont débités.

Test : Exceptions 411x SELECT gl.Compte, gl.Date, gl.Libellé, gl.Journal, gl.Débit, gl.Crédit

FROM gl WHERE (((gl.Journal)="VTE") AND ((gl.Débit)=0) AND ((Left([compte],3))="411")) OR (((gl.Journal)="EAR" Or (gl.Journal)="CL" Or (gl.Journal)="CAI" Or (gl.Journal)="CAE" Or (gl.Journal)="CA" Or (gl.Journal)="BNP") AND ((gl.Crédit)=0) AND ((Left([compte],3))="411"));

Une fois la liste des exceptions obtenue, il suffit de retrouver les pièces comptables

incriminées. Dans notre cas, il s’agit d’avoirs ou de compensations.

Ces contrôles permettent d’aider le commissaire aux comptes à valider le fonctionnement

général de la comptabilité générale et l’adéquation de la comptabilité avec les procédures

comptables.

2) Loi de Benford

La loi de Benford est une théorie mathématique qui démontre que dans toute liste de

nombres la fréquence d’apparition du premier chiffre significatif est prédéterminée. Ainsi

par exemple, les nombres commençant par le chiffre 1 doivent représenter 30 % de

l’ensemble. Pour de plus amples explications sur cette loi mathématique, vous trouverez

des éléments d’information en Annexe III.6.

Cette loi mathématique est assez simplement transposable à des listes de nombres de

nature comptable ou financière (grand livre, journal comptable, stocks…). Cependant,

l’échantillon soumis à la loi de Benford doit être d’une taille suffisante afin d’obtenir un

résultat le plus précis possible. Ceci est d’autant plus facile avec les ordinateurs récents

qui sont capables de traiter des tables de données de plusieurs dizaines de milliers de

lignes en quelques instants.


Nous allons confronter un journal de banque d’un exercice complet comprenant plus de

vingt mille lignes à la loi de Benford en vue de déceler d’éventuelles anomalies.




On va donc traiter un journal de banque SG ; les champs de données à obtenir sont

assez courants : code journal, débit et crédit.

La loi de Benford étant applicable à n’importe quelle liste de nombres, on aurait aussi

bien pu traiter un grand livre, une balance, un état d’inventaire…


Dans ACCESS, rédiger la requête suivante :

Test : loi de Benford (1) SELECT chiffre, Count(chiffre) AS CompteDechiffre

(2) FROM (SELECT journal,Left(Abs(IIf(gl.débit Is Null,0,débit*100)-IIf(gl.crédit Is Null,0,crédit*100)),1)

AS chiffre FROM gl WHERE journal="SG")

(3) GROUP BY chiffre;

(2) A partir du grand livre (table GL), la requête sélectionne, pour toutes les lignes

correspondant au journal SG :

- le code journal,

- effectue l’opération débit moins crédit, retire l’éventuel signe (fonction ABS) puis ne

retient que le chiffre de gauche (fonction LEFT), le résultat de cette opération est nommé

chiffre. Les montants débit et crédit sont multipliés par cent afin d’exclure le zéro en

première position des nombres, le zéro n’étant pas un chiffre significatif du point de vue

de la loi de Benford.

On obtient dans cette sous-requête la liste de tous les chiffres significatifs du journal SG.

(3) La requête finale regroupe tous les chiffres significatifs identiques et (1) retient le

chiffre significatif (chiffre) et un décompte pour chacun d’eux. Ce qui nous donne le

résultat suivant :



Test : loi de Benford chiffre CompteDechiffre 1 6271 2 3900 3 2716 4 1891 5 1519 6 1366 7 1125 8 1065 9 1087

Le chiffre 1 apparaît 6271 fois en première position.

Le résultat de la requête est collé dans un tableau EXCEL prévu à cet effet.

Premier chiffre significatif à

gauche

Fréquences absolues

observées

Probabilités théoriques

Benford

Fréquences théoriques

Benford

Fréquences Ecarts observés Loi de X² Anomalie / OK

C fi pi npi fi-npi Xi²=(fi-npi)²/npi

<15.51 6 271 0,30103 6 304 33 0,17 OK2 3 900 0,17609 3 687 -213 12,27 OK3 2 716 0,12494 2 616 -100 3,80 OK4 1 891 0,09691 2 029 138 9,42 OK5 1 519 0,07918 1 658 139 11,66 OK6 1 366 0,06695 1 402 36 0,92 OK7 1 125 0,05799 1 214 89 6,57 OK8 1 065 0,05115 1 071 6 0,03 OK9 1 087 0,04576 958 -129 17,31 ANOMALIE !

20 940 1,00000 20 940 0 62,15

Les deux premières colonnes représentent les chiffres significatifs et le nombre

d’occurrences pour chacun d’eux résultant de la requête SQL. La troisième colonne

correspond à la probabilité de trouver chaque chiffre significatif, la quatrième est la

fréquence théorique obtenue en multipliant la population totale de l’échantillon (20 940)

par la probabilité, la cinquième est l’écart entre les fréquences observées (colonne 2) et

théoriques (colonne 4). La colonne 6 est le résultat du Khi² (colonne 5 au carré divisé par

la colonne 4).


La feuille de travail EXCEL est reproduite en intégralité en Annexe III.7.

D’après la loi de Benford, les nombres commençant par un 9 sont surreprésentés. Il est

donc nécessaire de rechercher des explications. Etant donnés les volumes de données, il



peut être souhaitable d’affiner ce résultat en distinguant les encaissements des

décaissements.

Par ailleurs, la loi de Benford permet de pousser l’analyse jusqu’au deuxième chiffre

significatif.

Dans le cas qui nous intéresse, les sondages effectués n’ont pas révélé de fraude

avérée.

Les différents cas pratiques détaillés dans cette partie présentent différents

aspects de la mission d’audit du commissaire aux comptes. Toutes les phases de

la mission sont concernées par les extractions de données, que ce soit pour aider

à l’appréciation du système d’information, l’orientation de la mission,

l’accompagnement du contrôle des comptes ou l’évaluation du risque de fraude.

L’extraction de données est un outil complémentaire aux autres méthodes de

collecte des éléments probants qui permet de répondre concrètement aux

nouveaux enjeux exposés aux commissaires aux comptes : d’un côté les nouvelles

normes d’exercice professionnel et de l’autre côté la complexité croissante des

systèmes d’information.



CONCLUSION

Le système d’information collecte, retraite, stocke et restitue l’information. Il irrigue tous

les services de l’entreprise. Les volumes d’information concernés s’accroissent, les

applications informatiques sont de plus en plus pointues, le nombre de tâches non

informatisées s’amenuise. La comptabilité générale puise les informations dont elle a

besoin dans le système d’information. La valorisation du patrimoine de l’entreprise

dépend tout autant de la gestion commerciale, pour ce qui est de l’évaluation du montant

des créances, que de la gestion des stocks et de la gestion de production, pour

l’évaluation des stocks et encours de production.

Dans le cadre de sa mission de certification des comptes, le commissaire aux comptes

est donc amené à apprécier la fiabilité du fonctionnement du système d’information et la

qualité du contrôle interne. En effet, la comptabilité tient sa légitimité du système

d’information et des moyens de contrôle mis en place. Cependant, le commissaire aux

comptes se trouve rapidement confronté à la complexité et à la diversité des systèmes

d’information.

Il en résulte qu’il doit intégrer dans son approche d’audit les extractions de données

informatiques afin de traiter d’égal à égal avec l’entreprise auditée. L’exploitation de ces

données lui offre l’opportunité d’accroître considérablement la taille des échantillons de

données audités, la rapidité de certains contrôles et sa palette de contrôles. Ainsi, ses

investigations le conduiront à effectuer des rapprochements de données sur plusieurs

exercices ou entre tables de données ; rapprochements inenvisageables sur des

échantillons importants avec des méthodes classiques.

La question n’est pas de savoir si l’utilisation des extractions doit être opérée mais

comment elle doit être intégrée dans le programme de travail et mise en œuvre par les



auditeurs. Cette manière de travailler n’est pas sans soulever des problématiques

particulières, notamment en termes de formation et de sensibilisation des collaborateurs

du cabinet, de sécurité des données, de documentation des travaux d’audit. C’est

l’ensemble de l’organisation de la mission du commissaire aux comptes qui doit être

repensé.

Les extractions de données imposent au préalable une phase de réflexion concrétisée

par la mise en œuvre d’une véritable méthodologie visant à fiabiliser le processus

d’obtention et d’exploitation des données et le choix d’un logiciel d’analyse et de

techniques d’exploitation des données. L’ensemble des outils méthodologiques et des

cas décrits dans ce mémoire ne sont que le reflet de mon expérience professionnelle

acquise au fil des missions d’audit effectuées.

La complexité apparente des méthodes exposées dans ce mémoire ne doit pas

détourner l’auditeur de ces outils et des horizons nouveaux qui lui sont ouverts en

matière d’analyse et de diagnostic. Seules la pratique régulière et méthodique et la

persévérance lui garantiront le succès dans cette démarche.

Les extractions et les traitements de données ne doivent pas être perçus comme un

gadget ou comme une contrainte supplémentaire issue des NEP mais comme un outil

puissant d’analyse et de diagnostic. Ces analyses offrent l’opportunité au commissaire

aux comptes de capitaliser sur la valeur ajoutée de sa mission. Elles forment un vecteur

de communication privilégié vers la direction financière sur lequel le commissaire aux

comptes doit s’appuyer pour valoriser ses travaux. Un véritable dialogue s’instaure dans

le but partagé par les deux parties d’une constante perfection de la fiabilité du système

d’information, des procédures, du contrôle interne et en définitive de la qualité de

l’information financière produite par l’entreprise et communiquée à l’ensemble des tiers

intéressés.



BIBLIOGRAPHIE

Ouvrages

- CNCC : « Prise en compte de l’environnement informatique et incidence sur la

démarche d’audit », Collection Guide d’application CNCC EDITION, 2003, 260

pages

- CNCC – CSOEC : « Progiciels de comptabilité – Critères de conception et de

choix », CNCC – CSOEC, 3ème édition 2004, 280 pages

- GALLET O. : « Halte aux fraudes : prévenir et détecter les fraudes en entreprise »,

DUNOD, 2005, 208 pages

- PIGE B. : « Audit et contrôle interne », Editions Management et Société, 2ème édition

2003, 216 pages

- RADKE H. D. et SPONA H. : « Grand Livre ACCESS 2000 », MICRO

APPPLICATION, 1ère édition 1999, 1 076 pages

- SCOTT BARKER F. : « Programmation ACCESS Versions 2000 et 2002 »,

CAMPUSPRESS, 2002, 939 pages

Mémoires

- LAFON O. : « Mise en place d’une stratégie d’audit légal intégrant l’intégration de

fichiers informatiques dans un cabinet de dimension régionale », novembre 2001

- MESSAGER S. : « PME et progiciels de gestion intégrés : impacts sur les missions

du commissaire aux comptes », mai 2002

Articles extraits de revues et journaux

- « Entreprises : comment lutter contre la fraude », p. 11, Les Echos, 23-24 novembre

2007



- « La prise en compte de la possibilité de fraudes lors de l’audit des comptes », p. 8,

Revue Française de Comptabilité n° 404, novembre 2007

- « Savoir prévenir et détecter la fraude », pp. 16 à 20, Revue Fiduciaire Comptable

341, juillet-août 2007

- « Le management de la sécurité de l’information », pp. 4 à 5, Sécurité informatique –

Sécurité des systèmes d’information (publication du CNRS), n° 58, décembre 2006

- « Le contrôle interne de l’information comptable », pp. 18 à 20, Revue Fiduciaire

Comptable 334, décembre 2006

- « Evaluer votre contrôle interne », pp. 33 à 56, Revue Fiduciaire Comptable 332,

octobre 2006

- « Les contrôles sur les systèmes comptables informatisés », pp. 27-48, Revue

Fiduciaire Comptable 328, mai 2006

- « Contrôle des comptabilités informatisées », pp. 6 à 22, Revue Fiduciaire

Hebdomadaire 3136, 10 février 2006

- « La manipulation des logiciels « souples » est réprimée pénalement », pp. 36-38,

Audit n°178, février 2006

- « Pour lutter contre les logiciels à risques », pp. 30-32, Audit n°175, juin 2005

- « La contraignante traçabilité des écritures comptables », La Tribune, 15/04/2005

- « Quand les logiciels « souples » facilitent la fraude », pp. 30-32, Audit n°174, avril

2005

- « Logiciels comptables et bases de données », page 19, Revue Française de

Comptabilité 375 mars 2005

- « Le langage SQL », pages 16 et 17, Revue Française de Comptabilité 372

décembre 2004

- « SQL et SCD (schéma conceptuel de données) », page 20, Revue Française de

Comptabilité 371, novembre 2004

- « L’informatique au secours du contrôle fiscal », page 2, Astuces et Conseils Impôts

18/11/2004

- « Contrôle interne dans les PME-TPE », pp. 15 à 16, Revue Française de

Comptabilité 364 mars 2004



- « Contrôle interne et système d’information », pp. 16 à 18, La Profession Comptable

n° 253 02/2004

- « L’audit légal en milieu informatisé », Revue Fiduciaire Comptable 297, mars 2003

- « Pour mieux gérer Sarbanes-Oxley : les logiciels d’exploration de données peuvent

vous aider à vous conformer à la Loi Sarbanes-Oxley », www.camagazine.com,

03/2003

- « La détection des fraudes comptables », Revue Française de Comptabilité 321,

avril 2000

Sites internet

- www.acl.com : site de l’éditeur du logiciel d’exploration de données

- www.afai.fr : le site de l’association de l’audit et du conseil informatiques

- www.infocert.org : le site de l’organisme certificateur « NF Logiciel Comptabilité

Informatisée »

- http://sqlpro.developpez.com/ : point de rencontre de nombreux développeurs

spécialisés en bases de données

- http://fr.wikipedia.org/wiki/Loi_de_Benford : article décrivant la loi de Benford

Formations

- « Utilisation d’IDEA dans l’audit des données », Michel PIRON, 2008

- « La détection des fraudes », CNCC Formation, 2007

- « Intégrer les outils informatiques dans l’audit des stocks », CNCC Formation, 2006,

Michel Piron

- « Organisation du contrôle interne et diagnostic », ASFOREF, 2005

- « Examen du contrôle interne », M&G Formation, 2001, Cécile Fontaine

Conférences

- « Le contrôle fiscal informatique », Ordre des Experts-Comptables Rouen-

Normandie et Direction Générale des Impôts du Calvados, 2007



ANNEXES

ANNEXES EN RAPPORT AVEC LA 1ERE PARTIE

Annexe I.1 – Organigramme fonctionnel (exemple)

Annexe I.2 – Fiches de poste (exemples)

Annexe I.3 – Procédure (exemple)

Annexe I.4 – Grille de séparation des fonctions

Annexe I.5 – Brochure commerciale Logiciel conforme BOI et certifié NF

Annexe I.6 – Contrôle des comptabilités informatisées (BOI du 24/01/2006)

Annexe I.7 – Contrôle des comptabilités informatisées

(Extrait de la Loi de finances du 25/12/2007)

ANNEXES EN RAPPORT AVEC LA 2EME PARTIE

Annexe II.1 – Glossaire

Annexe II.2 – Résumé de la méthodologie d’extraction et d’exploitation des données avec

références au mémoire

Annexe II.3 – Exemple de détail de table de données extrait de la documentation d’un

logiciel de comptabilité

Annexe II.4 – Exemple de cartographie des applications et des interfaces

Annexe II.5 – Exemple de modèle logique de données

Annexe II.6 – Exemple de demande d’extraction de données



Annexe II.7 – Tables de données : Identification des principaux champs composant

un enregistrement – Principales sources de confusion

Annexe II.8 – Brochure commerciale du logiciel IDEA

Annexe II.9 – Fichier texte : importation dans EXCEL

Annexe II.10 – SGBDR : Introduction à ACCESS

Annexe II.11 – Introduction aux requêtes SQL sous EXCEL

Annexe II.12 – Fichier texte : importation dans ACCESS

Annexe II.13 – Créer un tableau croisé dynamique

ANNEXES EN RAPPORT AVEC LA 3EME PARTIE

Annexe III.1 – Exemple de requêtes validant l’exhaustivité du transfert des factures et

du chiffre d’affaires

Annexe III.2 – Grand livre ventilé par journal, compte et utilisateur (TCD)

Annexe III.3 – Revue analytique du cycle social

Annexe III.4 – Analyse des stocks

Annexe III.5 – Risque de fraude – Tableau de bord résumé de la comptabilité générale

(TCD)

Annexe III.6 – Risque de fraude – La loi de Benford

Annexe III.7 – Risque de fraude – Exemple d’application de la loi de Benford



ANNEXE I.1 :

Organigramme fonctionnel (exemple)



ANNEXE I.2 :

Fiches de poste (exemples)



ANNEXE I.3 :

Procédure (exemple)

Le document qui suit est la description de la procédure d’achat de véhicules d’occasion (VO)

extraite du manuel de procédures d’un concessionnaire automobile.

Liste des abréviations utilisées dans ce document :

BB : Buy Back (rachat suite à ventes assorties d’une option de reprise)

LLD : Location longue durée

LOA : Location avec option d’achat

RVO : Responsable Véhicules d’Occasion

VN : Véhicule neuf



ANNEXE I.4 :

Grille de séparation des fonctions

Exemple de grille de séparation des fonctions d’un service comptable :

Client : SOCIETE XXX Réf. : B4/bDate maj :

Retour sommaire généralIntervenant :

PERSONNEL CONCERNE =>SL LL IM MB, SS,

EB, AS Cf grilles Cf grilles

Titre Resp. info & contentieux RAF Resp.

comptable Comptables B4/c B4/a

Réf. fiche de poste 9 7 10 12

Service Info & contentx SOC DIRECT°

FONCTIONSSI- attribution des droits & habilitations XCourrier- ouverture XCourrier- signature X XAchats- bons de commande B4/c <=////////Achats- bons de réception B4/c <=////////Achats- vérification factures XAchats- bons à payer XAchats- comptabilité O XVentes- ouverture de comptes XVentes- attribution plafond crédit XVentes- contentieux - relation assurance crédit XVentes- bons d'expédition B4/cVentes- facturation XVentes- contrôle-tarifs-calculs B4/c <=////////Ventes- relances XVentes- avoirs XVentes- comptabilité transfert gescom XVentes- déclaration CA centrales achat XCaisse- visa des pièces XCaisse- tenue du brouillard XCaisse- détention des espèces XCaisse- comptabilité XBanques- établissement des chèques XBanques- bordereaux de remises XBanques- signatures XBanques- comptabilité XBanques- rapprochement banque XPaie- embauche B4/a <=////////Paie- signature contrat XPaie- établissement bulletins XPaie- livre de paie XPaie- règlements XPaie- déclarations sociales X

X : fonction habituelle, O : fonction occasionnelle

Conclusion

SL dispose de pouvoirs étendus (paramétrage SI, attribution droits accès, création clients & plafond crédit)LL : ses fonctions sont équilibrées (fiche de poste) ; mais ses droits d'accès sont larges (SI)Les autres comptables ont des fonctions d'enregistrements distinctes de la détention des avoirs

SYSTEME D'INFORMATION ET D'ORGANISATION COMPTABLE

GRILLE DE SEPARATION DES FONCTIONS

Comptabilité



ANNEXE I.5 :

Brochure commerciale Logiciel conforme BOI et certifié NF



ANNEXE I.6 :

Contrôle des comptabilités informatisées (BOI du 24/01/2006)

BULLETIN OFFICIEL DES IMPÔTS DIRECTION GÉNÉRALE DES IMPÔTS

13 L-1-06 N° 12 du 24 JANVIER 2006

CONTROLE DES COMPTABILITES INFORMATISEES NOR : BUD L 06 00012 J



ANNEXE I.7 :

Contrôle des comptabilités informatisées

(Extrait de la Loi de finances du 25/12/2007)



ANNEXE II.1 :

GLOSSAIRE

Les principaux termes techniques liés aux bases de données introduits dans ce mémoire

sont définis dans ce glossaire afin de ne pas alourdir les exposés.

ASCII (American Standard Code for Information Interchange) : norme de codification des

caractères standardisée ; cette norme, utilisée par la majeure partie des systèmes

informatiques, favorise les échanges d’informations ; cf Fichier texte.

Base de données : une base de données est un ensemble de données organisé et

structuré. Plus généralement, une base de données regroupe des tables de données et de

requêtes.

Champ (ou colonne) : donnée élémentaire d’une table de données ; un champ représente

un type d’information qui sera commun à tous les enregistrements d’une même table. Un

champ est défini par un nom, un type de données (texte, numérique, date…) et une taille

maximale. Par exemple le champ « nom » est commun à toutes les occurrences d’une

même table.

Clef étrangère : une clef étrangère est une clef principale contenue dans une autre table.

Par exemple, dans la table grand livre, le numéro de compte est une clef étrangère. Elle

assure le lien avec la table plan comptable dont le numéro de compte est la clef principale.

Clef principale (ou identifiant) : une clef principale est un champ dont le contenu est propre

à chaque enregistrement et permet d’identifier sans risque de confusion un membre d’une



même population. Le numéro de sécurité sociale est un identifiant car il est unique et propre

à chaque personne.

Enregistrement (ou ligne) : un enregistrement est constitué d’un ensemble de champs se

rapportant à une même occurrence. Ainsi, un enregistrement concernant un plan comptable

contiendra les champs « numéro de compte », « libellé de compte », « compte

mouvementé »…

Fichier texte (ou ASCII par abus de langage) : l’environnement informatique utilise plusieurs

types de fichiers (binaires, WORD, EXCEL…). Le fichier texte a différentes fonctions (fichier

de paramétrage, d’échange de données) et est lisible à l’aide d’un éditeur de texte.

Identifiant : cf. clé principale

Intégrité relationnelle (ou référentielle) : l’intégrité référentielle est un ensemble de règles

qui prévient la suppression de données « parent » liées à des données « enfant » ainsi que

les doublons. Par exemple, un compte du plan comptable ne doit pas pouvoir être supprimé

s’il a été mouvementé par une écriture. Dans le cadre de nos missions d’audit, l’identification

des contraintes d‘intégrité référentielle permet d’assurer la traçabilité des données.

Modèle Logique de Données (MLD) : le MLD résume sous forme schématique le

fonctionnement d’un système d’information et plus précisément les relations entretenues

entre les tables de données. Les relations inter-tables sont définies par les clés primaires et

les clés étrangères (cf ces termes). Le MLD s’inscrit dans la démarche d’analyse des

systèmes d’information MERISE qui comprend plusieurs niveaux de description (niveaux

conceptuel, organisationnel, logique et physique).

Requête : une requête est un moyen d’interroger une ou plusieurs tables de données. Cette

interrogation se pratique à l’aide d’un langage spécialisé : le SQL (cf. ce terme).

SGBDR (Système de Gestion de Bases de Données Relationnelles) : un SGBDR est un

système de gestion de base de données qui entretient des relations dynamiques entre les

différentes tables et leurs contenus.



SQL (Structured Query Language, langage de requête structuré) : le langage SQL est

composé d’instructions qui, assemblées, permettent d’interroger des tables de données, de

fusionner des tables, d’effectuer des calculs plus ou moins complexes, en fonction de

critères multiples.

Table (de données) : une table de données est composée d’enregistrements (lignes), eux-

mêmes constitués de champs (colonnes), qui se rapportent à un domaine commun. Tous les

champs d’une même table sont structurés de la même manière (taille, type de données

reçues…). Par exemple, la table des clients liste les données en rapport avec les clients de

l’entreprise (numéro, nom, adresse…).

Tableau croisé dynamique (TCD) : un tableau croisé dynamique est une fonctionnalité

proposée par la plupart des tableurs modernes qui permet de présenter de manière

synthétique des ensembles de données en fonction des champs de données que l’on

souhaite mettre en lumière. Ces tableaux sont dits dynamiques car la mise à jour des

données d‘origine met à jour instantanément le TCD.



ANNEXE II.2 :

Résumé de la méthodologie d’extraction et d’exploitation des données

avec références au mémoire

L’extraction de données et son exploitation s’inscrivent dans la démarche générale de la

mission du commissaire aux comptes.

Certaines notions sont abordées sous différents aspects dans chacune des parties de ce

mémoire. Le tableau qui suit assure la liaison entre les différentes parties concernées.

Référence 1ère partie

Approche générale

Référence 2ème partie

Méthodologie

Référence 3ème partie

Cas pratiques Mission du commissaire aux comptes Analyse du système d’information

A. Information & système d’information B. L’intervention du commissaire aux comptes

A. Cohérence du système d’information B. Cohérence des données

A.4. Contrôle interne

A.3. Séparation des fonctions

Cartographie des applications et des interfaces, identification des tables de données et des contraintes d’intégrité référentielle, modélisation du système d’information, identification des données à obtenir en fonction des objectifs d’audit poursuivis

A.3. Environnement informatisé B. L’intervention du commissaire aux comptes

A. Extraction des données

A.1. Test interface C. Fraude A.2. Intégrité référentielle

Méthodes d’exploitation des données Requêtes SQL (ACCESS)

B.3 Quasiment l’ensemble des cas traitent le SQL

Requêtes SQL (EXCEL)

B.3

Tableau croisé dynamique

B.3 A.3 C.1

Tris, filtres, formats conditionnels

B.3 B.6



ANNEXE II.3 :

Exemple de détail de table de données extrait de la documentation d’un

logiciel de comptabilité

Le manuel de l’utilisateur du logiciel de comptabilité RUBIS FINANCE de LOGINOR fournit

une abondante documentation des tables de données interrogeables par requête.

Liste des tables disponibles (extrait) :



Liste des champs de la table Ecritures comptables (extrait) :



ANNEXE II.4 :

Exemple de cartographie des applications et des interfaces

Ce schéma explique succinctement l’origine des données intégrées dans la comptabilité

ainsi que la destination des données comptables. Le mode de communication des données

(interfaces) est mentionné.

Logiciels RUBIS & TURQUOISE (LOGINOR) : hébergés sur serveur AS 400SAGE : applications WINDOWS

Interfaces : interface automatiqueinterface manuelle

PRO

DU

CTI

ON

CO

MPT

AB

LE

CARTOGRAPHIE DES APPLICATIONS

ComptabilitéTURQUOISEAS400

PaieSAGE

Gestion commerciale & Gestion des StocksRUBIS

Comptes annuelsExpert-comptable

Comptes consolidésExpert-comptable

Certification CAC

La cartographie des applications et interfaces est un des éléments de compréhension du

fonctionnement général du système informatique.



ANNEXE II.5 :

Exemple de modèle logique de données (MLD)

Le MLD peut être représenté sous forme :

- d’une liste de tables

SortiesPF (numLIG, #numCDE, numligcde, #réfPF, qté, date, #numBL)

LigCommandes (numLIG, #numCDE, #numBP, #numBL, #numFRE, #réfPF, qté)

- ou sous forme d’un schéma

1,n

1,n 1,n 1,n

1,11,n

1,1

1,n

1,1

Légende : Tables gérées par la Gestion des stocks de PF

Tables gérées par la Gestion commerciale

entêteBL

numBL#numcde

EntêteFactures

numFRE

Commandes

numLIG#numCDE#numBL#numBP#numBL#numFRE#réfPF

SortiesPF

numLIG#numBL#réfPF

EntêteBP

numBP#numcde

entêteCommandes

numCDE

NB : Par souci de simplifier le MLD, les attributs (champs) ne sont pas rappelés.

Avec xxx désignant les identifiants et #xxx les clefs étrangères



Chaque système informatique est particulier. On remarquera ici que les numéros de bons de

livraison et de facture sont systématiquement reportés sur les lignes de commande (table

commande) ce qui n’est pas habituel ; généralement le numéro de bon de livraison figure sur

la ligne de facture.

Ce tableau est une autre manière de modéliser une table de données :

Table de données COMMANDES Description Cette table contient les lignes des commandes, bons de préparation, bons de

livraison et factures ; chaque enregistrement comprend toute la chaîne du processus commandes à factures.

Origine des données Module Gestion Commerciale Liste des champs de données

Nom Type Contenu Numéro NUM AUTO Numéro de ligne créé par nos soins #NumCDE NUM ENTIER Numéro bon de cde #NumBL NUM ENTIER Numéro #NumBP NUM ENTIER Numéro bon de préparation #NumFRE NUM ENTIER Numéro facture / avoir Annéexp NUM ENTIER Année expédition Moisexp NUM ENTIER Jourexp NUM ENTIER Annéefre NUM ENTIER Année facturation Moisfre NUM ENTIER Jourfre NUM ENTIER Codeart NUM ENTIER Numligcde NUM ENTIER Numéro de ligne sur le bon de commande Qtécde NUM REEL Qté commandée Tarifbasesté NUM REEL Tarifbaseeuro NUM REEL Tarifhabituel NUM REEL Qtéexpéd NUM REEL lignefréeBL TEXTE lignecptabée TEXTE CDEANNUL TEXTE = A quand la commande est annulée Qtéàprép NUM REEL Qtépréparée NUM REEL Qtéliv NUM REEL Qtéfrée NUM REEL Légende : identifiant, #clef étrangère



ANNEXE II.6 :

Exemple de demande d’extraction de données

La présente annexe retrace les différentes étapes d’une extraction de données, de la

définition de l’objectif d’audit (naissance d’un besoin) à l’obtention des données

informatiques :

Prise de connaissance, analyse et modélisation du système d’information

Le commissaire aux comptes, après avoir pris connaissance de l’entreprise auditée, analysé

le système d’information et défini ses objectifs d’audit, va effectuer sa demande d’extraction

de données.

L’exemple qui suit s’appuie sur la cartographie des applications et des interfaces de

l’Annexe II.4 et sur le MLD de l’Annexe II.5.

Définition de l’objectif d’audit

Parmi ses objectifs d’audit, dans le cadre de la validation de la procédure de ventes, le

commissaire aux comptes souhaite s’assurer que la séquence de numérotation des factures

est dépourvue de rupture.

Identification de la source de l’information

Pour répondre à cet objectif, il lui faut obtenir un extrait de la table des en-têtes de factures.

L’auditeur identifie le logiciel qui génère les factures à partir de la cartographie des

applications. Il s’agit de RUBIS. D’après le MLD, il constate que les en-têtes de factures sont

stockés dans la table « EntêtesFactures ». C’est donc cette dernière qui fera l’objet d’une

extraction.



Définition de la taille de l’échantillon et des critères d’extraction

L’auditeur détermine la taille de l’échantillon de données sur lequel il souhaite travailler. Il

sait que l’entreprise auditée connait un pic d’activité sur les mois de juillet, août et décembre.

Arbitrairement, il se focalisera sur le mois de juillet. Son échantillon représentera environ

15% de la population des factures de ventes d’une année.

Définition des champs de données à obtenir

Le seul champ de données nécessaire est le numéro de facture. Pour des raisons pratiques,

l’auditeur demandera à obtenir quelques éléments complémentaires facilitant l’identification

des factures : date, nom du tiers facturé, total facturé TTC.

Formulation de la demande d’extraction auprès de l’entité auditée

L’auditeur prend contact avec le service informatique et communique sa demande : « Nous

aurions besoin de la liste des factures de ventes émises par le logiciel RUBIS sur le mois de

juillet 2007 pour la société xxx. Les champs souhaités sont : numéro de facture, date de la

facture, code client, nom du client, total facturé TTC. »

Extraction des données par l’informaticien

L’informaticien effectue son extraction directement à partir de la table de données à l’aide de

COGNOS IMPROMPTU.

Le résultat de l’extraction est transmis à l’auditeur sous la forme d’un fichier texte.

Contrôle et exploitation des données obtenues par l’auditeur

Le format des champs de données est des plus classiques et ne présente aucune difficulté

particulière pour l’auditeur. La seule particularité c’est que RUBIS gère les dates sur quatre

champs séparés : jour, mois, siècle et année (sur deux chiffres). Le 17 juillet 2007 est donc

retranscrit ainsi : j : 17, m : 07, s : 20, a : 07. Il appartiendra par la suite à l’auditeur de

retraiter ces champs pour ne plus en avoir qu’un seul.



Il ne reste plus à l’auditeur qu’à effectuer les contrôles et retraitements des données.

Ensuite, il exploitera les données. En l’occurrence, le cas pratique développé en III.B.4

expose une manière de rechercher des ruptures de séquence numérique.



ANNEXE II.7 :

Tables de données : Identification des principaux champs composant

un enregistrement – Principales sources de confusion

Les tables de données gérées par les systèmes de gestion comprennent des quantités

assez importantes de champs de données qui remplissent chacun un rôle particulier. La

plupart du temps, les champs utiles au commissaire aux comptes sont aisés à isoler.

Néanmoins, certains libellés de champ recèlent des sources d’erreurs potentielles pour

l’auditeur, d’autres sont essentiels à la compréhension des transactions représentées.

Cette annexe n’a pas vocation à être exhaustive mais présente les cas les plus

fréquemment rencontrés.

Quantité :

Le principal problème au niveau des quantités concerne les unités de mesure utilisées. Un

produit peut être géré en quantité unitaire (unité de gestion) mais facturé (unité de

facturation) au poids (certains produits alimentaires, films plastiques…), m², au carton, au

millier…

Prix :

Prix HT, TTC, brut ou net de remise, unitaire ou total, prix par unité de gestion ou facturée…

Attention aux devises utilisées.



Identificateur d’état ou de position :

Certains champs au libellé très court ou sibyllin sont pourtant importants pour interpréter un

enregistrement.

Il en est ainsi des factures et des avoirs. Certains systèmes comprennent un champ de

données dans la table « factures » qui indique pour chaque ligne de facturation le sens

créditeur ou débiteur de la transaction, par exemple, un « F » pour une facture, un « A »

pour un avoir. Si ce champ n’a pas été identifié et que les quantités sont positives (y compris

pour les avoirs), les avoirs seront confondus avec les factures ce qui faussera toute analyse.

Dans une table d’écritures comptables, l’identificateur du sens de l’écriture pourra être un

champ intitulé « sens » contenant « D » pour débit ou « C » pour crédit.

Par ailleurs, certains systèmes de gestion permettent de suivre les documents annulés par

un opérateur (par exemple, bons de commande ou bons de livraison). Ces documents sont

soit supprimés de la table principale et stockés dans une table annexe pour consultation

ultérieure, soit conservés dans la table principale avec les autres enregistrements. Il est

impératif d’identifier ces enregistrements ; en effet, dans le cas de commandes annulées, il

est évident qu’aucune livraison n’étant intervenue, un écart apparaîtrait en cas de tentative

de rapprochement.

Enfin, l’identificateur d’état peut donner une indication sur l’état d’avancement d’un

traitement donné. Par exemple, pour la table « factures », un indicateur peut éventuellement

indiquer si la facture a été transférée en comptabilité.

Date :

La date fait toujours référence à la réalisation d’un événement ; le tout étant d’identifier

l’événement : facturation, livraison (à ce sujet, certains systèmes différencient date de départ

et date de réception effective par le client), comptabilisation…



Numéro et référence :

Ces champs forment des critères de requête de choix. En effet, ils sont généralement

uniques leur donnant le titre d’identifiant. Ainsi, deux factures ne peuvent porter le même

numéro. Cependant, certains systèmes ajoutent des radicaux ou des suffixes à des numéros

lors de leur report dans d’autres tables. Par exemple, le champ « numfact » de la table

« entêtefacture » prendra une forme numérique incrémentée de un en un du type « 62503 ».

Ce champ pourra être reporté dans le champ intitulé « numfact » de la table « ligneBL » en

ajoutant un préfixe « F » (pour facture) et un suffixe, par exemple indiquant l’établissement

de facturation, et donner un numéro « F62502/1 ». Le rapprochement des bons de livraison

et des factures nécessitera un retraitement préalable.



ANNEXE II.8 :

Brochure commerciale du logiciel IDEA



ANNEXE II.9 :

Fichier texte : importation dans EXCEL

L’importation dans EXCEL se déroule en deux étapes : tout d’abord identification du type de

fichier texte puis importation des données et identification des champs de données.

Identification du type de fichier texte

Dans le menu Fichier, sélectionner « Ouvrir » puis dans « Type de fichiers », sélectionner

« Fichiers texte », enfin cliquer sur le fichier à traiter.

Un assistant d’importation apparaît (cf copie d’écran « étape 1 sur 3 » plus loin)



Deux alternatives se présentent alors :

- soit le fichier est à « séparateurs » : le fichier est dit à séparateur lorsque les

champs de données sont séparés par des caractères (tabulation, point virgule…) et

que les colonnes ne sont pas alignées.

- soit le fichier est « colonné » : le fichier est colonné lorsque les colonnes

apparaissent distinctement.

Importation des données et identification des champs de données

Importation d’un fichier texte à séparateurs (type *.CSV)

La copie d’écran ci-après fournit un exemple de fichier à séparateurs (étape 1 sur 3 de

l’importation) :

Dans ce cas, cocher la case intitulée « Délimité » puis cliquer sur « Suivant ».

A noter :



o Il est possible de ne commencer l’importation qu’à partir d’un certain numéro

de lignes (ce qui est utile par exemple pour ne pas importer les en-têtes de

colonne).

o Suivant l’origine du fichier (application sous environnement MS/DOS,

WINDOWS, MAC OS, voire codifiée sous des standards étrangers), il est

quelquefois nécessaire de sélectionner une origine de fichier. Toutefois, le

format proposé par défaut (WINDOWS ANSI) convient généralement.

La fenêtre de l’étape 2 sur 3 de l’importation apparaît :

Il faut cocher la ou les cases correspondant au séparateur de champ. Dans le cas présent,

le séparateur est la tabulation (cas le plus fréquent). Une fois le bon séparateur coché, les

colonnes apparaissent clairement. Les champs de données (colonnes) sont identifiés

automatiquement.

Ceci fait, il suffit de cliquer sur le bouton « Suivant » pour passer à la dernière étape.

Au cours de la dernière étape, l’importateur propose de donner un format pour chaque

colonne de données (date, nombre, texte). Cette étape est facultative ; généralement

EXCEL parvient à attribuer les formats automatiquement.



Cependant, il peut arriver qu’avec des données retranscrites dans des formats inhabituels,

EXCEL ne parviennent pas à identifier le format à affecter aux colonnes. Le bouton

« Avancé… » permet dans ce cas d’aider EXCEL dans cette identification en lui précisant le

séparateur de décimale, des milliers et la position du signe négatif.

Une fois le format de chaque colonne paramétré et validé, les données sont importées dans

EXCEL et apparaissent dans une nouvelle feuille de calcul :



Importation d’un fichier texte colonné

La copie d’écran qui suit (étape 1 sur 3 de l’importateur) donne un exemple de fichier

colonné :

Dans ce cas, cocher la case intitulée « Largeur fixe » puis cliquer sur « Suivant ».

La fenêtre de l’étape 2 sur 3 de l’importation apparaît :



Il s’agit d’aider EXCEL à isoler les colonnes (champs de données) les unes des autres.

EXCEL pré-identifie un certain nombre de colonnes en fonction des espaces contenus dans

le fichier et les matérialise avec des traits. Cependant, il se trompe souvent en créant des

colonnes imaginaires. Par ailleurs, si deux colonnes sont collées l’une à l’autre sans espace,

EXCEL ne détectera pas deux colonnes mais une seule.

Comme indiqué sur la copie d’écran, il est possible en cliquant avec la souris de créer,

supprimer ou modifier des colonnes.

Une fois toutes les colonnes identifiées, cliquer sur le bouton « Suivant ».

L’étape finale d’importation (3/3), identique en tout point à celle des fichiers à séparateurs,

surgit. En cliquant sur le bouton « Terminé », le fichier est importé dans une nouvelle feuille

EXCEL.

Cette nouvelle feuille de calcul est enregistrable aux formats ASCII mais également EXCEL,

au choix de l’utilisateur en fonction de la destination qu’il réserve à ces données.



ANNEXE II.10 :

SGBDR : Introduction à ACCESS

Le but de cette annexe est d’exposer succinctement comment créer une nouvelle base de

données et une requête. Les explications seront agrémentées de copies d’écran. Pour plus

de détails, le lecteur est invité à se reporter à la littérature foisonnante sur le sujet et

notamment aux ouvrages mentionnés dans la bibliographie.

Cette initiation se base sur la version 2003 d’ACCESS encore très utilisée en entreprise.

Création d’une nouvelle base

Ouvrir ACCESS, dans le menu « Fichier », sélectionner « Nouvelle base de données… »

puis « Base de données vide ». Il vous sera demandé de nommer la base de données et de

l’enregistrer. Nous la nommerons « Analyse GL ».

Ceci fait, ACCESS se présente ainsi :



A partir de cette fenêtre, l’auditeur peut à loisir créer et gérer entre autres :

- des tables de données, c’est le passage obligé,

- des requêtes,

- des formulaires (les formulaires sont des grilles de saisie plus ou moins

sophistiquées) ; exemple de formulaire ACCESS :

- des états (les états permettent de présenter le résultat des requêtes sous des

formes plus visuelles qu’un simple tableau colonnes/lignes de type EXCEL) ;

exemple d’état (extrait) :



Ces deux dernières fonctionnalités ne sont pas abordées dans le cadre de notre étude ; bien

qu’elles puissent se révéler utiles dans la présentation des travaux de l’auditeur, elles n’en

sont pas pour autant indispensables.

Création d’une table

La méthode la plus classique et la plus simple pour créer une table consiste à cliquer sur

« Créer une table en mode création ».

Une grille de saisie vierge apparaît. Trois

colonnes intitulées : nom du champ, type de

données et commentaires sont à renseigner

pour chacun des champs de données à créer.

Sur la copie d’écran ci-contre, le premier

champ s’intitule « compte », nous l’avons

défini comme devant contenir du texte.

La colonne commentaire a toute son

importance puisqu’elle est susceptible de

contenir des informations sur le format des

données, les contraintes de contenu…

Une fois les différents champs paramétrés, il suffit d’enregistrer la table en lui donnant un

nom, ici « gl » pour grand livre.

Insertion de données dans une table

Maintenant que la table est créée, on peut y insérer des données.

Pour ce faire, il faut sortir du « mode création »

et entrer en mode « Feuille de données ».



Pour des raisons pratiques, les données à traiter sont préalablement importées et contrôlées

dans EXCEL. Les colonnes sont réorganisées pour être dans le même ordre que les

champs dans ACCESS.

Puis, les données à traiter dans ACCESS sont sélectionnées, copiées depuis EXCEL (Menu

« Edition », « Copier ») et enfin collées dans la table ACCESS (Menu « Edition »,

« Coller ») :

A y regarder de plus près, l’on observera qu’une table de données ressemble à s’y

méprendre à une feuille de calcul EXCEL. La ressemblance s’arrête là.

La table est prête à être retraitée par des requêtes.

Création d’une requête

Pour créer une requête, nous avons deux choix principaux : un mode visuel et un mode

SQL. Le premier s’adresse à l’auditeur profane, il suffit de sélectionner les tables et/ou

requêtes à interroger, de sélectionner les champs en les glissant vers la zone de travail, le

tout sans connaissance approfondie en SQL. Le deuxième s’adresse à des auditeurs plus

confirmés puisqu’il nécessite le maniement du langage SQL. Par ailleurs, l’usage de ce

mode s’avère nécessaire pour créer certains types de requêtes non représentables

visuellement comme les requêtes UNION.

Il est possible de passer du mode visuel au mode SQL et vice versa.



Pour illustrer notre propos, nous allons créer une balance générale à partir du grand livre.

Pour commencer, cliquer sur « Requêtes » puis sur « Créer une requête en mode

création ».

Pour passer du mode visuel « mode création » au « mode SQL », il suffit de cliquer sur les

icônes suivantes :

Le « mode Feuille de données » permet de visualiser le résultat de la requête, que le

développement de la requête soit achevé ou non.

Requête en mode visuel :



Requête en mode SQL :

Extrait du résultat de la requête (Mode « Feuille de données ») :



ANNEXE II.11 :

Introduction aux requêtes SQL sous EXCEL

En matière de requêtes SQL, EXCEL permet deux utilisations : soit la rédaction littérale de

requêtes, soit l’appel de requêtes préalablement rédigées dans ACCESS.

Le premier choix n’est pas recommandé, l’éditeur de requêtes sous EXCEL n’étant pas très

pratique. Le second choix s’avère plus judicieux dans la mesure où l’utilisateur bénéficie de

l’interface assez fonctionnelle d’ACCESS. C’est donc ce second choix qui fera l’objet de

notre étude dans la présente annexe.

Avant de commencer à travailler dans ACCESS, il est donc entendu qu’une base de

données comprenant au moins une requête doit être disponible.

Dans EXCEL, entrer dans le menu « Données externes » puis « Importer des données… ».



Sélectionner la source de données, en l’occurrence ici, la base de données ACCESS

intitulée « Requêtes 2007 ». Au passage, on remarquera la diversité des sources

interrogeables (dont des fichiers EXCEL).

Une fois la base ouverte, la fenêtre de propriétés des liaisons présente les paramétrages

disponibles.

Seul l’utilisateur averti se risquera à modifier les paramètres de la liaison. Dans la plupart

des cas, il n’est nul besoin de modifier le paramétrage proposé par défaut.



EXCEL demande maintenant à l’utilisateur de choisir la requête à lier. Nous choisirons la

requête intitulée « Test : loi de Benford ».

Il ne reste plus qu’à indiquer où le résultat de la requête doit être inséré : sur une feuille

existante (notre choix) ou sur une nouvelle feuille de calcul. Un tableau croisé dynamique

peut être créé prenant pour base le résultat de la requête.

Le résultat de la requête ACCESS s’affiche dans EXCEL.

Toutes les modifications qui seront apportées aux tables

ou requêtes à l’origine de ce résultat impacteront

automatiquement EXCEL.

Le champ d’application offert par les liaisons est infini et

évite à l’utilisateur les copier/coller entre ACCESS et

EXCEL.



ANNEXE II.12 :

Fichier texte : importation dans ACCESS

L’importation de données contenues dans un fichier texte dans ACCESS suit, dans les

grandes lignes, le même principe que l’importation de données dans EXCEL ; le lecteur est

invité à se reporter à l’Annexe II.9 pour plus d’informations.

L’importation de données nécessite au préalable la création d’une nouvelle base de données

dont la démarche est résumée dans l’Annexe II.10.

Pour importer des données, aller dans le menu « Fichier », puis « Données externes » et

« Importer ».

Sélectionner le type de fichiers « Fichiers Texte » puis le fichier texte à importer :



L’importateur de texte se met en route et affiche à l’écran une prévisualisation des premières

lignes du fichier. Il propose à l’utilisateur de déterminer s’il s’agit d’un fichier à séparateurs

ou colonné (pour la distinction entre les deux options, se reporter à l’Annexe II.9).

Si l’on prend le cas d’un fichier colonné, choisir « Longueur fixe » puis « Suivant ».

Pareillement à EXCEL, l’importateur propose d’office des colonnes (champs de données)

que l’utilisateur aura loisir d’ajuster. En cliquant sur « Avancé… », les paramètres de chaque

champ de données identifié sont modifiables.



L’utilisateur est appelé à indiquer la destination des données importées : soit dans une

nouvelle table, soit dans une table pré-existante.

Si ce n’est déjà fait, l’utilisateur est invité à paramétrer chaque champ individuellement (nom

et type de données : texte, date, nombre…). Au sujet du type de données, l’utilisateur

portera une attention particulière à son choix ; en effet, un choix erroné (par exemple

numérique alors que les données sont en réalité alphanumériques) entraînera des erreurs

d’importation (génération d’une table d’erreurs *_Importerrors) et nécessitera de

recommencer l’opération. Un champ (colonne) peut être exclu de l’importation à la demande

de l’utilisateur.



Sauf avis contraire de l’utilisateur, ACCESS se propose de créer un champ de données

auto-numéroté en guise de clé primaire (clé principale). L’utilisateur dispose de deux autres

alternatives : soit choisir un autre champ, soit ne pas définir de clé principale.

Dernière étape, donner un nom à la table (dans le cas d’une importation dans une nouvelle

table de données) :



La table apparaît maintenant dans la liste des tables de la base de données et est prête à

répondre aux requêtes.



ANNEXE II.13 :

Créer un tableau croisé dynamique

Dans cette annexe, sera expliquée étape par étape la création d’un tableau croisé

dynamique (TCD). Nous prendrons comme exemple le TCD de l’Annexe III.2.

Les données de base

Pour construire un TCD, nous avons besoin de données de base, par exemple un grand

livre, organisées :

Utilisateur Journal Compte3 SommeDeDébSommeDeCrédNbOccurrencesIF ACH 401 11,03 258615,84 75IF ACH 445 126,11 0 53IF ACH 607 247868,27 11,12 73IF ACH 608 10621,55 0 75IF BNP 401 601796,96 0 212IF BNP 411 4613,69 1020299,77 549IF BNP 413 0 485049,79 22IF BNP 425 0 76,22 1IF BNP 467 0 466,53 1IF BNP 512 1508071,77 606410,65 755IF BNP 627 70,1 0 4IF BNP 658 0,44 0 1IF BNP 791 0 2250 1IF CAE 411 187,51 1792397,65 1779IF CAE 445 3,17 0 1IF CAE 467 0 1256,97 1IF CAE 511 1793637,53 0 1778

Construction du TCD

EXCEL est doté d’un assistant de TCD. Il s’active depuis le menu « Données » puis

« Rapport de tableau croisé dynamique… ». La fenêtre de l’assistant apparaît (étape 1/3) :



Différentes options nous sont proposées. Cependant, dans tous les cas que nous étudierons

dans le cadre de ce mémoire, seule la source « Liste ou base de données Microsoft Office

Excel » adjointe au type de rapport « Tableau croisé dynamique » nous sera utile. Ceci dit,

l’option « Source de données externe » offre la possibilité de lier le TCD au résultat d’une

requête EXCEL ouvrant cet outil à de fabuleuses perspectives d’analyse adaptées en temps

réel aux données stockées.

Une fois les deux options de TCD sélectionnées et le bouton « Suivant » cliqué, la deuxième

étape de l’assistant s’affiche :

Il s’agit dès lors de localiser les données à analyser, qu’elles figurent sur la feuille de calcul

en cours (« Plage ») ou sur une autre feuille (« Parcourir »).

Après validation de la plage de données à analyser, la destination du TCD doit être précisée

au cours de la troisième et dernière étape :



Il est préférable de choisir « Nouvelle feuille » afin de bien distinguer le TCD des données de

base.

Avant de fermer l’assistant, il nous reste à disposer les champs de données à analyser sur le

TCD, pour ce faire nous cliquons sur « Disposition… » :

Les en-têtes de colonnes des données de base sont repris à droite et font office de nom de

champ de données. Pour les disposer sur le TCD, il suffit de glisser ceux qui font l’objet

d’une analyse dans les zones Page, Ligne, Colonne et Données.

Dans notre cas, les champs « Journal » et « Compte3 » sont glissés dans la zone Ligne,

« Utilisateur » en Colonne, et « NbOccurrences » en Données.

Une fois tous les champs nécessaires disposés, nous obtenons ceci :



Chaque champ de données peut être personnalisé dans son mode d’affichage. Pour cela, il

suffit de double-cliquer dessus. Ce que nous faisons pour « NbOccurences » : d’office la

somme des occurrences est calculée mais nous aurions pu préférer la moyenne, le

dénombrement… Le format numérique et d’autres options peuvent, à cette occasion, être

affinés.

Tous les réglages étant opérés, cliquer sur les boutons « Ok » pour fermer la fenêtre

« Disposition » puis « Terminer » pour clore l’assistant. Un nouvel onglet logeant le TCD est

créé automatiquement.

Somme de NbOccurUtilisateurJournaCompte3 IF LL LM MB PEC PP SALACF 215 1

218 1401 275 42411 7445 249 37602 31604 19606 38 8



ANNEXE III.1 :

Exemple de requêtes validant l’exhaustivité du transfert des factures et

du chiffre d’affaires

Requête n°2 : cette requête liste les factures générées par la gestion commerciale

absente de la comptabilité.

Test : FreCIALE absente CPTA (RIGHT JOIN) (1)

SELECT FacturesCIALE.numpièce, FacturesCIALE.FouA, FacturesCIALE.codetiers, FacturesCIALE.date, FacturesCIALE.TTC, FacturesCIALE.libellétiers FROM FacturesCPTA RIGHT JOIN FacturesCIALE ON FacturesCPTA.réfpiècecourt = FacturesCIALE.numpièce WHERE (((FacturesCPTA.numpièce) Is Null));

(1) Cette requête rapproche les numéros de facture de la gestion commerciale avec ceux

figurant en comptabilité et sort les factures n’apparaissant pas en comptabilité.

Requête n°3 : cette requête liste les factures enregistrées en comptabilité générale et

ne figurant pas dans la gestion commerciale

Test : FreCPTA absente CIALE (RIGHT JOIN) (1)

SELECT FacturesCPTA.numpièce, FacturesCPTA.libellétiers, FacturesCPTA.codetiers, FacturesCPTA.montantTTC FROM FacturesCIALE RIGHT JOIN FacturesCPTA ON FacturesCIALE.numpièce=FacturesCPTA.réfpiècecourt WHERE (((FacturesCIALE.numpièce) Is Null));

(1) Cette requête rapproche les numéros de facture comptabilisés avec ceux figurant en

gestion commerciale et sort les écritures dont l’origine n’est pas la gestion commerciale.

Ces deux requêtes auraient pu être rédigées avec une clause NOT IN ; elles ne l’ont pas été

car l’exécution de ces requêtes est nettement moins rapide qu’avec RIGHT JOIN.



ANNEXE III.2 :

Grand livre ventilé par journal, compte et utilisateur (TCD)

Somme de NbOccurrences Utilisateur Journal Compte3 IF LL LM MB PEC PP SAL SC SH SL SY THOMAS Total ACF 215 1 1 218 1 1 401 275 42 19 336 411 7 7 445 249 37 14 300 602 31 31 604 19 19 606 38 8 4 50 608 5 5 611 8 8 613 12 12 615 68 1 69 616 5 5 621 7 7 622 11 11 623 3 3 624 43 43 625 4 32 14 50 626 11 11 628 1 1 635 1 1 651 5 5 709 10 1 11 Total ACF 815 121 51 987 ACH 401 75 332 576 983 411 14 14 445 53 306 555 914 607 73 318 576 967 608 75 9 84 609 37 80 117 Total ACH 276 1016 1787 3079 ACP 401 1 230 231 607 1 230 231 608 21 21 Total ACP 2 481 483 BNP 164 2 2 401 212 139 81 432



409 1 1 411 549 10 559 413 22 22 425 1 1 445 5 5 455 1 1 467 1 6 7 512 755 170 82 1007 580 2 2 606 1 1 612 2 2 627 4 16 1 21 658 1 1 661 2 2 758 1 1 768 1 1 791 1 1 Total BNP 1546 359 164 2069 CA 164 4 4 421 9 9 425 5 5 427 5 5 431 2 2 437 4 4 445 2 2 512 43 43 580 6 6 625 2 2 627 2 2 661 4 4 Total CA 88 88 CAE 411 1779 4 1783 445 1 1 467 1 1 511 1778 4 1782 658 11 11 709 1 1 758 9 9 Total CAE 3580 8 3588 CAI 401 42 19 61 411 96 19 115 425 18 7 25 531 173 50 223 580 17 5 22 Total CAI 346 100 446 CL 401 29 99 157 285 411 106 2 108 445 1 3 4 467 7 1 8 511 43 43 512 153 134 157 444 580 22 6 28 612 2 2 622 1 1



627 19 19 658 2 2 4 661 1 1 758 5 5 771 1 1 Total CL 370 269 314 953 EAR 411 299 1 95 96 96 587 413 299 1 95 96 96 587 445 10 10 658 4 4 709 10 10 758 2 2 Total EAR 624 2 190 192 192 1200 OD 401 3 2 5 411 7 5 4 10 26 416 1 1 421 2 2 425 2 2 427 2 2 431 2 2 437 2 2 445 19 19 462 1 1 467 3 4 7 641 2 2 645 12 12 658 2 1 2 10 15 758 1 1 765 1 2 3 Total OD 12 60 4 6 20 102 VTE 411 241 19 764 16 10 5707 2468 4588 36 13849 445 18 15 62 11 11 4 28 149 707 184 1 71 1 10 133 93 139 35 667 708 14 19 33 16 3440 1379 2467 7368 709 347 162 312 821 Total VTE 457 54 930 44 20 9638 4106 7534 71 22854 Total 6865 2619 54 1397 481 44 2269 20 9828 4304 7897 71 35849



ANNEXE III.3 :

Revue analytique du cycle social



ANNEXE III.4 :

Analyse des stocks

Extrait du tableau (partie gauche) :



Extrait du tableau (partie droite) :



ANNEXE III.5 :

Risque de fraude – Tableau de bord résumé de la comptabilité générale

(TCD)

Reproduction intégrale du TCD :

Journal

Compte3 Données ACF ACH ACP BNP CA CAE CAI CL EAR OD VTE Total

164 Somme de Déb 12511,85 13637,4 26149,25

Somme de Créd -0 -0 0

215 Somme de Déb 119400 119400

Somme de Créd -0 0

218 Somme de Déb 8810,73 8810,73

Somme de Créd -0 0

401 Somme de Déb 4756,64 1463,33 6170,81 1230832 1901,52 1561765 2885,53 2809774,7

Somme de Créd -763234 -1663523 -628712 -10356 -0 -63,75 -2055 -3067944

409 Somme de Déb 59700 59700

Somme de Créd -0 0

411 Somme de Déb 0 0 10182,16 3006,46 0 12447,7 1188,6 3900,12 3763658 3794383,2

Somme de Créd -3139,2 -615,68 -1020912 -1793084 -50276 -101663 -520739 -3912,2 -94842,6 -3588997

413 Somme de Déb 0 519799 519798,9

Somme de Créd -485050 -1188,6 -486238,4

416 Somme de Déb 2054,97 2054,97

Somme de Créd -0 0

421 Somme de Déb 156119 0 156119,19

Somme de Créd -0 -149521 -149521,1

425 Somme de Déb 0 2550 6960 0 9510

Somme de Créd -76,22 -0 -0 -8430 -8506,22

427 Somme de Déb 839,78 0 839,78

Somme de Créd -0 -1204,8 -1204,81

431 Somme de Déb 83920 0 83920

Somme de Créd -0 -81629 -81629

437 Somme de Déb 47490,3 0 47490,25

Somme de Créd -0 -13404 -13404

445 Somme de Déb 101606 70184,2 872,01 11,76 3,17 240,89 90,98 393191 3367,72 569567,5

Somme de Créd -262,15 -43,84 -0 -0 -0 -130000 -0 -393322 -169821 -693449,1

455 Somme de Déb 27670 27670

Somme de Créd -0 0



467 Somme de Déb 2755 0 0 13179,1 15934,12

Somme de Créd -2466,53 -1256,97 -43460,6 -3132,5 -50316,64

511 Somme de Déb 1794137 0 1794136,6



Somme de Créd -2818,95 -1792004 -179482

512 Somme de Déb 1619757 310000 2108524 403828

Somme de Créd -1400536 -312448 -1936142 -364912

531 Somme de Déb 50276,3 50276,2

Somme de Créd -51312 -51311,5

580 Somme de Déb 50000 0 42450 360000 45245

Somme de Créd -100000 -310000 -0 -42450 -45245

602 Somme de Déb 99256,8 99256,7

Somme de Créd -0

604 Somme de Déb 16824,5 16824,4

Somme de Créd -0

606 Somme de Déb 59312,2 183,95 59496,1

Somme de Créd -995,54 -0 -995,54

607 Somme de Déb 1584710 631367 2216076,4

Somme de Créd -807,79 -6268,2 -7076,0

608 Somme de Déb 6963,55 11308,6 97,41 18369,5

Somme de Créd -0 -0 -2654,4 -2654,4

609 Somme de Déb 3,89 3,8

Somme de Créd -2679,12 -2679,1

611 Somme de Déb 89119,8 89119,7

Somme de Créd -0

612 Somme de Déb 3020,46 1058,3 4078,7


613 Somme de Déb 47653,8 47653,8

Somme de Créd -0

615 Somme de Déb 27484,2 27484,1

Somme de Créd -0

616 Somme de Déb 65487,9 65487,8

Somme de Créd -0

621 Somme de Déb 2118,14 2118,14

Somme de Créd -0

622 Somme de Déb 23575,7 180,79 23756,5


623 Somme de Déb 1945,6 1945,

Somme de Créd -0

624 Somme de Déb 60168,3 60168,2

Somme de Créd -284,77 -284,7

625 Somme de Déb 4676,55 332,66 5009,2


626 Somme de Déb 12275,1 12275,0

Somme de Créd -0

627 Somme de Déb 3526,15 223,03 1685,51 5434,6

Somme de Créd -30,6 -0 -0 -30,


Somme de Créd -0

635 Somme de Déb 731,75 731,7

Somme de Créd -0

641 Somme de Déb 204638 204638,3

Somme de Créd -0

645 Somme de 95033 9503



Déb

Somme de Créd -45354 -45353,66



658 Somme de Déb 0,44 0,78 0,43 84,64 3,6 89,89

Somme de Créd -0 -0 -0 -0 -0,83 -0,83

661 Somme de Déb 1092,75 7323,96 1111,28 9527,99

Somme de Créd -0 -0 -0 0

707 Somme de Déb 91414,5 91414,47

Somme de Créd -3540035 -3540035

708 Somme de Déb 136,04 136,04


709 Somme de Déb 14558,7 16,13 827,68 7676,37 23078,86

Somme de Créd -0 -0 -0 -104,87 -104,87

758 Somme de Déb 0 0 0 0 0 0

Somme de Créd -2 -2,99 -0,06 -62,8 -2,49 -70,34


Somme de Créd -2751,6 -2751,61


Somme de Créd -424,09 -424,09


Somme de Créd -1229,84 -1229,84



Total Somme de Déb 767991 1667670 637635 3022104 622448 1797163 101588 4047014 521991 714886 3866253 17766741

Total Somme de Créd -767991 -1667670 -637635 -3022104 -622448 -1797163 -101588 -4047014 -521991 -714886 -3866253 -17766741



ANNEXE III.6 :

Risque de fraude – La loi de Benford

Découverte dès 1881 et démontrée en 1996, la loi de Benford indique que la fréquence

d’apparition du premier chiffre significatif d’un nombre répond à une distribution

prédéterminée résumée dans le graphique ci-après (Graphique extrait de l’article publié sur

Wikipedia) :

Le premier chiffre significatif d’un nombre est le chiffre le plus à gauche différent de zéro.

Par exemple : le premier chiffre significatif de 1325,72 est 1, le premier de 0,753 est 7.

Ce graphique montre que la fréquence d’apparition du chiffre 1 est de 30 %, celui du 2 de

17%...

Le décompte des chiffres significatifs observés dans l’échantillon des données auditées est

rapproché des fréquences théoriques calculées à partir de la loi de Benford. L’écart entre les



fréquences observées et les fréquences théoriques est soumis au test du KHI DEUX (X²).

Tout résultat du test supérieur à 15,5 révèle une anomalie avec au plus 5 % de risque de se

tromper.

Si la fréquence d’apparition des chiffres significatifs d’une liste donnée diffère sensiblement

de celle de la loi de Benford, on peut supposer que nous sommes en présence d’anomalies

ou, dans le cadre de données comptables ou financières, de fraudes.

Ceci dit, l’absence d’anomalie révélée par la loi de Benford ne signifie pas nécessairement

qu’il n’y a aucune fraude. Il s’agit simplement d’un indicateur.

L’application de la loi de Benford connaît tout de même une exception : les nombres ne

doivent pas être contraints ou biaisés par un paramètre qui entraînerait une

surreprésentation d’un chiffre donné. Imaginons le cas d’une billeterie qui vend des entrées

au prix unique de 6 €. La fréquence d’apparition du chiffre 6 attirera l’attention sans qu’il y ait

pour autant d’anomalie réelle.

Une fois les conclusions tirées, il suffit d’extrapoler le résultat de l’échantillon sur la

population toute entière avec un niveau de confiance de 95 % et le cas échéant rechercher

les éléments probants étayant la fraude.

Le lecteur pourra utilement se référer aux articles intitulés « La détection des fraudes

comptables » (cf. bibliographie) et « Loi de Benford » consultable à cette adresse URL :

http://fr.wikipedia.org/wiki/Loi_de_Benford notamment pour en savoir plus sur l’histoire de la

découverte de cette loi et comprendre la règle mathématique prescrivant la fréquence

d’apparition.



ANNEXE III.7 :

Risque de fraude – Exemple d’application de la loi de Benford

Dossier : XXXExercice 30/06/2007

BR, le 03/09/2007

Objectif : Analyse du risque de fraude

Travail effectué : Extraction du journal de banque SOCIETE GENERALE

Premier chiffre significatif à

gauche

Fréquences absolues

observées

Probabilités théoriques

Benford

Fréquences théoriques

Benford

Fréquences Ecarts observés Loi de X² Anomalie / OK

C fi pi npi fi-npi Xi²=(fi-npi)²/npi

<15.51 6 271 0,30103 6 304 33 0,17 OK2 3 900 0,17609 3 687 -213 12,27 OK3 2 716 0,12494 2 616 -100 3,80 OK4 1 891 0,09691 2 029 138 9,42 OK5 1 519 0,07918 1 658 139 11,66 OK6 1 366 0,06695 1 402 36 0,92 OK7 1 125 0,05799 1 214 89 6,57 OK8 1 065 0,05115 1 071 6 0,03 OK9 1 087 0,04576 958 -129 17,31 ANOMALIE !

20 940 1,00000 20 940 0 62,15

Conclusion :

Analyse du risque de fraude : Loi de Benford

Le chiffre 0 est sur-représenté par rapport à la loi de Benford.

Il convient d'analyser les écritures correspondantes.

0

1 000

2 000

3 000

4 000

5 000

6 000

7 000

1 2 3 4 5 6 7 8 9

EXTRACTION ET EXPLOITATION DES DONNEES DU SYSTEME … · 2010-12-14 · diplÔme...

Documents

Transcript of EXTRACTION ET EXPLOITATION DES DONNEES DU SYSTEME … · 2010-12-14 · diplÔme...