Audit des systèmes informatisés.

...

CHAPITRE II L’AUDIT DES APPLICATIONS

- 1 -Présentation de l’audit des applications

-

L’audit des applications a pour objet de valider les traitements effectués dans une application particulière, par exemple une comptabilité, une chaîne de facturation et de gestion de stocks, une paie, etc. L’audit d’application complète l’audit du contrôle interne dans les mesures où :

- il peut servir de test qui permet de s’assurer du respect des normes et des méthodes de travail ;

- la qualité du contrôle interne peut évoluer dans le temps, de sorte qu’un contrôle interne jugé satisfaisant au moment où les investigations sont menées ne garantit pas nécessairement qu’une qualité équivalente était en vigueur quand les anciennes applications ont été conçues et réalisées ;

- un bon contrôle interne ne peut jamais exclure toute négligence ou erreur humaine, de nature à compromettre la qualité d’une application particulière ;

- a contrario, des lacunes dans le contrôle interne augmentent le risque de dysfonctionnement des applications, sans qu’il soit cependant possible d’établir un lien direct et obligatoire entre ces lacunes et celles des applications.

Pour quelles raisons les résultats issus des traitements informatiques peuvent-ils être erronés ?

Cette question peut servir de fil conducteur à la réflexion sur le contenu des audits d’application.

Les causes principales de dysfonctionnement relèvent de facteurs internes, propres à l’application informatique ou à ses conditions techniques d’exploitation, et de facteurs externes tenant à son environnement.

- L’erreur de logiciel

La mauvaise conception ou la mauvaise réalisation du logiciel est la première idée qui vient à l’esprit comme facteur de nature à compromettre la validité des résultats.

La distinction entre erreur de réalisation et erreur de conception est parfois difficile à cerner.

L’erreur de conception est le plus généralement due :

- soit à une mauvaise compréhension du problème par les informaticiens ou encore à un exposé incomplet ou inexact du besoin par les utilisateurs ; ceci conduit à réaliser des programmes qui fonctionnent, dans le sens où ils produisent des résultats, mais qui sont inexploitables dans la mesure où ces résultats sont erronés ou incomplets. Le choix d’un logiciel ne répondant pas aux besoins peut être rattaché à l’erreur de conception ;

- soit à une mauvaise prise en compte des contraintes techniques aboutissant par exemple à des temps de réponse, ou de production des résultats, inadaptés aux objectifs poursuivis.

L’erreur de conception risque de provoquer des remises en cause profondes de l’application, conduisant dans certains cas extrêmes à sa refonte complète. Le respect d’une méthodologie rigoureuse de développement doit permettre de limiter autant que possible ce type d’erreur dont la rectification est toujours coûteuse.

Les défauts de réalisation des travaux pris en charge par les programmeurs et les analystes-programmeurs ont des conséquences techniques plus limitées, dans la mesure où les rectifications nécessaires ne sont pas de nature à remettre en cause les grandes lignes du projet.

Les bogues ou erreurs de programmation, qui conduisent à une interruption du traitement ou à la production de résultats erronés, sont les erreurs de réalisation les plus connues. Les essais de fonctionnement avant la mise en exploitation du logiciel permettent de limiter la présence de ces anomalies.

Par ailleurs, une opération de maintenance inadaptée peut rendre inopérants des programmes qui étaient corrects avant la maintenance. Il arrive en effet qu’à l’occasion d’une modification destinée à améliorer le fonctionnement de certains programmes d’une application, une autre partie du logiciel soit altérée. Afin de limiter ces phénomènes, il importe de procéder à des essais de fonctionnement non seulement au démarrage de l’application, mais aussi après modification des programmes.

- L’erreur d’exploitation

Les erreurs d’exploitation peuvent trouver leur origine, soit dans les problèmes techniques (comme par exemple l’impossibilité de relire un support magnétique), soit dans des erreurs de manipulation (comme par exemple l’omission ou le double traitement d’un fichier).

Le service d’exploitation doit normalement être en mesure de réagir à ces différents incidents (ce qui suppose notamment que des consignes claires aient été données aux opérateurs), et d’effectuer lui-même des contrôles qui permettent de valider la production avant de la distribuer.

Il est prudent et souvent indispensable de mettre à disposition des utilisateurs des outils de contrôles synthétiques qui leur permettent de vérifier à posteriori la validité des traitements.

- La mauvaise utilisation de l’application

Les systèmes modernes présentent une grande facilité d’utilisation (une ‘’convivialité’’), permettant de guider l’utilisateur, et de lui imposer des contraintes de moins en moins importantes.

Toutefois, des contraintes existent toujours, et il importe que l’utilisateur en ait connaissance et les respecte.

Ces contraintes peuvent tenir par exemple à la nécessité :

- de mettre à jour les paramètres de l’application (telles que les tables des rubriques mémorisant les taux de cotisation sociales ou les montants des plafonds dans une application de paie) ;

- de saisir régulièrement les données ; ainsi, les quantités en solde restituées par une application de gestion de stocks ne peuvent être correctes si les entrées ne sont pas faites régulièrement ;

- respecter les consignes d’utilisation du produit ; par exemple la clôture d’exercice dans une comptabilité donne généralement lieu à un certain nombre de traitement qui doivent être déclenchés dans un ordre strict (solde des comptes de gestion, archivages des écritures, clôture d’exercice et reprise des à nouveaux) et rendent impossibles la saisie ultérieure d’écritures sur l’exercice clos.

Par ailleurs, il peut arriver