Audit & Systèmes d’Information

Ce week end, j’ai exhumé d’un vieux carton oublié depuis longtemps une relique de mon adolescence : une disquette 5 »1/4 (prononcer cinq pouces un quart). Les plus jeunes ne connaissent peut-être pas… Mais l’ancêtre du DVD-ROM et de la clef USB est la disquette ! Malheureusement, je n’ai pas de lecteur de disquette 5 »1/4 ! Donc impossible d’accéder à mes précieux fichiers… Tout à coup, je viens de réaliser que les nouvelles avancées technologiques condamnent au fur et à mesure de leur apparition les technologies antérieures… et les données liées à ses technologies. Ce problème peut sembler anecdotique mais malheureusement il touche insidieusement tous les secteurs de l’activité humaine : le cinéma perd à chaque heure qui passe des heures de films du début du XXème siècle, les fichiers stockés sur bandes ou cartes perforés dans les années 60-70 par les administrations et entreprises sont certainement inaccessibles et il en est de même pour les données générées lors des débuts de la micro-informatique (années 80) sur des systèmes aussi ésotériques que rares.

Il faut bien avoir conscience que les standards d’aujourd’hui apparaîtront obsolètes demain et seront supplantés par d’autres plus aboutis… et pas nécessairement rétrocompatibles. Se pose alors le problème de la portabilité et de l’accessibilité des données à terme dans une civilisation qui tend à dématérialiser tous ses écrits et ses arts. Les témoignages du passé qui ont traversé les époques et l’histoire malgré les guerres et les révolutions technologiques et que nous découvrons et redécouvrons tous les jours avec émerveillement (écrits antiques et religieux, pierre de Rosette, parchemin égyptiens…) sont lisibles encore actuellement par nous. Il n’est pas certains que nos écrits contemporains le soient encore dans un ou deux siècles ! Cette problématique est partagée par le responsable informatique de chaque entreprise. Régulièrement, le système informatique doit subir un toilettage plus ou moins profond qui se traduit tôt ou tard par un changement complet. A cette occasion, il se rend souvent compte que moultes données ne sont pas récupérables sur le nouveau système… sauf à dépenser des sommes importantes en frais de conversion.

Deux problématiques concomitantes se font jour :

- Les formats des supports (VHS, cassettes audio, disquettes 5 ¼, CD-ROM, DVD…) : au fur et à mesure de l’amélioration des techniques de stockage, les supports se font plus petits et peuvent contenir plus de données avec pour corolaire l’abandon des précédents formats. Notons cependant l’exception du CD (créé à la fin des années 70) remplacé par le DVD dans les années 90 avec des dimensions identiques permettant la rétrocompatibilité des lecteurs optiques.

- Les formats des fichiers : les fichiers images au format Jpeg, la musique au format MP3, les documents PDF… paraissent familiers aux utilisateurs d’aujourd’hui. Mais demain qu’en sera-t-il ? 

Pour ne rien arranger, les grands groupes d’électroniques se livrent à des guerres des formats (qui se souvient des disquettes 3″, du disque laser vidéo ou encore du récent HD DVD ?) à des fins mercantiles au détriment des utilisateurs (consommateur et entreprises). Celui qui remportent le combat est garanti de percevoir des redevances durant de longues années… Mais l’utilisateur et ses données ont à faire face à un problème de poids, celui de la conservation des matériels et des logiciels ou de la conversion des données sur un nouveau support et dans de nouveaux formats. L’abandon des formats propriétaires et la normalisation (pour ne pas dire la stabilisation) des standards au niveau international doit permettre à l’entreprise et plus généralement à la communauté d’accéder à des données dans le temps.

L’open source est très présent dans le monde de l’informatique “libre” (freeware en anglais) où les logiciels développés par des passionnés (seuls ou en équipes) sont distribués gratuitement ou presque. Dans ce domaine, gratuit ne rime pas avec mauvaise qualité, bien au contraire. De nombreux logiciels gratuits concurrencent férocement des logiciels payants édités par des multinationales à gros budget à commencer par LINUX contre WINDOWS. Ne nous y trompons pas l’enjeu n’est pas seulement financier, l’open source introduit la transparence que recherche bon nombre de directions informatiques d’entreprises et d’administrations (dont les militaires) sur le fonctionnement des logiciels intégrés à leurs systèmes informatiques.

En effet, l’éditeur d’un logiciel “open source” (en français code source libre) fournit, en plus du logiciel proprement dit, le code source (c’est-à-dire les lignes de programmes qui, compilées, produisent le logiciel, produit fini). Ce code source, fourni gracieusement, assure une totale transparence sur les techniques de programmation utilisées par les développeurs du logiciel. La communication du code source permet à la communauté des informaticiens de déceler d’éventuels problèmes de sécurité, de les corriger ou de signaler le problème aux développeurs pour correction. L’open source tranche donc complètement avec les logiciels propriétaires “fermés” dont le code source est tenu secret (la licence d’utilisation de ces logiciels prévoit généralement l’interdiction de la décompilation, c’est-à-dire la reconstitution du code source à partir du produit fini). En effet, l’utilisateur n’a pas connaissance directement des techniques de programmation mises en oeuvre et n’a aucun moyen de déceler d’éventuelles failles de sécurité ouvertes dans son système par ce logiciel, autrement que celles révélées dans les nombreux forums de discussion. Evidemment, l’utilisateur lambda ne dispose pas des compétences propres à analyser voire déchiffrer le code source d’un logiciel mais la communauté de développeurs bénévoles est riche d’étudiants, d’universitaires, de thésards… voire maintenant de retraités qui disposent de temps et de moyens. Cette communauté est très active à l’image de celle qui tourne autours des différents projets LINUX.

Extrait de code source en Visual C++ :

#include <CkMht.h>
#include <CkString.h>

void ChilkatSample(void)
    {
    CkMht mht;

    bool success;
    success = mht.UnlockComponent(”30-day trial”);
    if (success != true) {
        printf(”Mht component unlock failed\n”);
        return;
    }

L’intérêt de transparence et de sécurité se comprend très bien pour des militaires qui se doivent de comprendre le fonctionnement des systèmes qu’ils emploient sur des théatres d’opérations extérieurs. Les failles de sécurité sont concernées mais pas seulement. Les “backdoors” (ou portes dérobées) sont la hantises des militaires et plus généralement des directions informatiques : la plus imprenable des citadelles protégée de parefeus piratée parce que la porte de derrière est restée ouverte… Le pire cauchemar de tout responsable informatique. Cependant, l’opacité des systèmes propriétaires conviendra à l’utilisateur moyen peu au fait de ces problèmes de sécurité (que les mises à jour quotidiennes et automatiques de Microsoft rassurent).

Lorsqu’une erreur, voire une fraude découlant éventuellement sur un scandale financier, est découverte, la direction de l’entreprise se trouve confrontée à quatre sources de difficultés : isoler la faille dans les procédures, évaluer l’ampleur des dégâts (financiers et sur la pérennité de l’organisation), trouver et poursuivre les coupables et communiquer avec les tiers intéressés (notamment lorsque la fraude est médiatisée). Pour les organisations les plus averties, un plan de crise sera mis en œuvre.

Mais au final, lorsque le mécanisme de fraude aura été analysé et que les procédures auront été corrigées, que le préjudice aura été chiffré et que les fraudeurs auront été désignés, qui devra assumer la responsabilité de la négligence ? Qui devra endosser le rôle du bouc émissaire ?

Le dirigeant ?

Les différents collaborateurs qui, isolément, agissent dans la chaîne de décisions ?

Le commissaire aux comptes ?

Même si c’est lui qui définit la stratégie de l’entreprise et qui est responsable, aux yeux des tiers, de l’arrêté des comptes et du contrôle interne, le dirigeant n’a qu’une vue d’ensemble des processus. Malgré son expérience et l’acuité de ses travaux d’audit, le commissaire aux comptes n’a qu’une appréciation globale de la qualité du contrôle interne.

Chaque membre de l’organisation est responsable individuellement d’une partie du contrôle du processus mais pas coupable de la défaillance collective du système de contrôle. Responsable mais pas coupable… Un air de déjà vu, non ? Si cette notion peut se comprendre pour des dirigeants ou des professionnels au fait du problème, pour le grand public, il s’agit là d’une idée difficile à accepter. Les réactions aux dernières grandes affaires en sont la démonstration.

Le fraudeur se tapit derrière un masque, une façade. Il profite des points faibles du système (voire de défaillances), il développe des stratégies de contournement. La fraude est dissimulée par des artifices (comptables, juridiques…) donnant l’illusion de la réalité et de la normalité (par rapport à la loi et aux règles de contrôle interne). Le fraudeur se construit une personnalité sage en vue d’acquérir la confiance de sa hiérarchie… et d’endormir la méfiance des auditeurs. En effet, on n’accorde pas sa confiance à n’importe qui !

Mais qui donc est le fraudeur en entreprise ?

Sans vouloir faire peur, c’est Monsieur Tout Le Monde !

Voici quelques critères qui doivent attirer l’attention :

• - C’est une personne de confiance : il conserve les moyens de paiement, les clefs du coffre…
• - C’est un pilier de l’entreprise : gentil, disponible, serviable, ne refuse jamais d’aider ou de terminer des dossiers urgents tard le soir ou le week end…
• - Il ne prend jamais de vacances, arrive toujours le premier et repart le dernier…

Vous connaissez ce genre de personnes ? Pas de panique ! Ce ne sont pas pour autant des fraudeurs. Il suffit de garder l’oeil ouvert et de veiller à certains points :

• - rémunérer les collaborateurs à leur juste valeur (sinon ils pourront être tentés de se servir eux-même),
• - veiller à la stricte séparation des fonctions,
• - évaluer la qualité du contrôle interne, cerner ses points faibles, les corriger ou mettre en place les procédures atténuant les risques (il ne faut pas hésiter à communiquer sur le sujet afin de dissuader le fraudeur potentiel).

La fraude existe à tous les niveaux, elle est de toute nature (détournement d’espèces, de marchandises, fausses heures supplémentaires…)… et le contexte économique actuel ne va pas arranger les choses. Un homme averti en vaut deux !

A l’aide de la revue analytique, le commissaire aux comptes (ainsi que l’expert-comptable d’ailleurs) oriente ses contrôles de comptes, prépare son programme de travail. Une analyse sommaire de la balance générale permet déjà de déceler des anomalies (par exemple un compte 486x créditeur) et de mettre en place des points de contrôle (par exemple une variation du compte 1013x doit être justifiée par des documents juridiques).

Cette analyse est aisée à automatiser. Il suffit pour ce faire d’opposer une table de points de contrôle à la balance générale. C’est précisément cette automatisation que j’ai paramétrée sur la revue analytique que j’ai interfacée avec la base de données du logiciel AUDITSOFT (cf précédent article sur ce blog) et que je me propose de vous expliquer ci-après.

La mise en œuvre de ce cas pratique nécessite ACCESS.

Pour résumer, voici comment j’ai mis en application cet outil :

Table de points de contrôle :

J’ai tout d’abord créé une table des points de contrôle dans ACCESS dont voici un extrait :

 J’ai réparti les points de contrôle en deux catégories (champ « Type_cond ») :

• - Les anomalies apparentes qui décelées attirent l’attention du réviseur. Ce type de contrôles vise à détecter les exceptions à des règles comptables.
• - Les points à justifier qui concernent des sujets d’attention pour lesquels le réviseur doit obtenir des documents justificatifs de la part des services comptables.

Cette table fonctionne de la façon suivante :

Les colonnes « Réfb » et « Réfh » définissent la tranche de compte concernée par le point de contrôle. La colonne « Sens » fait figure de critère déclenchant avec « D » pour débiteur, « C » pour créditeur et « M » pour sens du solde indifférent. Si la tranche débute par « VARIATION_ », ce n’est pas le solde qui sera utilisé comme critère déclenchant mais la variation du solde N / N-1 du compte.

Enfin, le champ « Libellé_cond » donne au réviseur une indication sur le point d’attention à traiter.

Par exemple :

Avec ce point de contrôle, chaque compte débiteur (« D ») inscrit dans cette tranche (dont le compte 1013x) sera traité comme une anomalie.

Ma requête gère les comptes de la balance générale (par exemple 1013x), les comptes de regroupement (par exemple 1x, 10x, 101x) et les postes des états financiers (par exemple capital social, capitaux propres). Pour simplifier l’exposé ci-après, je limiterai les exemples aux comptes de la balance.

Table « balance »

Deux balances générales sont nécessaires : N & N-1. Il faudra les regrouper avec une requête de regroupement (« GROUP BY ») puis adjoindre au numéro de compte « /1 » pour N et « /2 » pour N-1.

Requête confrontant la balance générale avec les points de contrôle

Ces deux tables définies dans ACCESS, il ne reste plus qu’à les confronter à l’aide d’une requête. Le but de cette requête est de lister la liste des comptes dont le solde ou la variation répond à un certain critère.

(1) Liste la balance N (« Right([réf],1)=1 ») : numéro de compte et solde.

(2) La balance N est fusionnée avec le résultat de la requête suivante.

Les sous-requêtes (5) et (7) fournissent les balances générales N & N-1, puis sont fusionnées l’une avec l’autre (6) avant d’être retraitées en variation N/N-1 (3) (4).

Résultat

Extrait du résultat de la requête :

Le résultat fourni est intéressant puisqu’il présente deux anomalies (le résultat N-1 n’a pas été affecté et les charges constatées d’avance sont créditrices) et attire l’attention sur deux points à justifier (des immobilisations produites par l’entité ont été comptabilisées et le compte 1512x a varié pendant l’exercice).

Conclusion

A partir d’une simple balance générale, l’auditeur dispose d’une batterie de contrôles de base à effectuer. C’est tout l’intérêt de cet outil d’analyse.

Il est parfaitement adaptable à d’autres types de contrôle (toutes les fois que l’on a besoin de confronter une liste de données à des critères de contrôle).

La découverte d’un détournement au sein de l’entreprise est une mauvaise surprise et un drame révélant un excès de confiance et une trahison. L’évaluation du préjudice financier est susceptible de s’accompagner d’un retraitement fiscal. En effet, en cas de détournement, s’il est démontré que la direction de l’entreprise avait connaissance des agissements frauduleux de son salarié ou bien que l’entreprise n’a pas mis en œuvre un contrôle interne suffisant pour décourager la fraude, le préjudice subi par l’entreprise et non remboursé par le salarié indélicat n’est pas déductible du résultat imposable. Sur ce point l’arrêt du Conseil d’Etat du 5 octobre 2007 (n° 291049, 3e et 8e sections) est très clair.

Cette double peine (préjudice comptabilisé en charges et absence de déduction fiscale) doit finir de convaincre les entreprises d’évaluer les risques de fraude qu’elles encourent et de mettre en œuvre les mesures de prévention adéquates. Le calibrage du contrôle interne, s’il ne permet d’éviter de manière absolue toute manœuvre frauduleuse, garantira au moins la déductibilité fiscale de ses effets.

Le système informatique stocke les flux d’informations traités par le système d’information dans des bases de données. Les documents comptables (factures, bons de livraison, bons de commande…) que l’on connaît sous forme papier ont leur représentation numérique dans les bases de données. Ils sont toujours représentés par deux tables de données :

• - Une table d’entêtes : cette table recense les documents comptables (un enregistrement par document). Les champs de données sont principalement le numéro de document (identifiant unique), code tiers, date…
• - Une table des lignes : cette table enregistre le détail des documents. Par exemple, pour une facture, cette table précise le numéro de facture, la référence du produit, la quantité, le prix unitaire, le numéro du bon de livraison… Chaque enregistrement correspond à une ligne de la facture.

Ces deux tables sont indissociables l’une de l’autre.

Lors des extractions de données en rapport avec le détail des documents comptables, l’auditeur veillera à toujours utiliser ces deux tables surtout si son objectif est de rapprocher le détail de factures avec d’autres documents ou flux (par exemple rapprocher des sorties de stock avec des facturations de produits).

Les différents scandales financiers des années passées (dont les plus retentissants auront été ENRON, PARMALAT, KERVIEL début 2008, MADOFF fin 2008) ont eu des origines différentes mais ont tous présenté des similitudes : opacités des marchés ou des méthodes comptables et juridiques employées, contournement des procédures le tout en vue de tromper les investisseurs ou le public. Les différentes instances de contrôles (auditeur interne, commissaire aux comptes, commission bancaire, AMF…) ont été bernées elles aussi. Les processus clefs ont pu être parfaitement maîtrisés mais la complexité des flux (notamment des produits financiers) finit par rendre incompréhensible leur retranscription comptable des dirigeants et des contrôleurs.

Afin de rétablir la transparence que les agents économiques sont en droit d’attendre, nous avons assisté à un renforcement de l’arsenal législatif (SARBANES OXLEY, LSF…) consacrant l’évaluation du contrôle interne. En contrepartie, les auditeurs légaux donnent plus l’impression (du point de vue de certains chefs d’entreprise) de remplir des questionnaires passepartout et d’ouvrir le parapluie avec des lettres d’affirmation à rallonge alors qu’ils doivent essayer d’apporter de la valeur ajoutée à l’entité auditée. Il est nécessaire de retourner aux fondamentaux et notamment au bon sens et à la réflexion.

D’autant qu’il y aura toujours des petits malins qui parviendront à contourner les règles à leur profit.

Un sursaut de la part des acteurs concernés est souhaitable. La crédibilité des chefs d’entreprise et des auditeurs vis-à-vis des salariés… et des citoyens est en jeu.

Un ERP (Entreprise Resource Planning ou en Français : Progiciel de Gestion Intégré) est un logiciel qui assure la gestion commerciale (GRC), la gestion des stocks, la gestion de la production, la tenue de la comptabilité… Un ERP centralise donc l’enregistrement de l’ensemble des flux financiers et physiques de l’entreprise. Les ERP modernes stockent leurs données dans des bases de données. L’extraction de données à l’aide d’un module de requêtes aidera la direction financière à établir les situations comptables et l’auditeur à répondre à ses objectifs d’audit.

HYPERION, module de requête, couplé à DIVALTO, un ERP installé dans de nombreuses PME, assurent précisément l’exécution de ces tâches. Après authentification de l’utilisateur, le module accède au catalogue de tables de la base de données de l’ERP. L’interrogation et l’extraction de données sont maintenant accessibles aisément à l’utilisateur. Le résultat est exportable dans EXCEL ou ACCESS pour d’autres traitements (analyse, mise en forme…).

Utilisez-vous des logiciels d’extraction de données ou d’interrogation de base de données ? Dans quel cadre utilisez-vous des extractions ou interrogations ? (audit, contrôle de gestion, situations comptables…).

Je prépare un article sur le thème de la pratique des extractions de données dans l’entreprise / en cabinet. Vos retours d’expérience sur ce sujet me seront précieux. Je vous remercie d’avance de votre participation.