L`audit et ses outils informatisés

P 04-18 AUDIT*:Mise en page 1
11/05/07
9:58
Page 4
Dossier : Audit
L’audit et ses outils informatisés
“
Cet article veut éclairer l’usage des techniques d’audit
assisté par ordinateur, dans le cadre notamment du concept émergent
d’audit continu, au travers des normes de l’ISACA et des démarches
de l’IIA et du GAO.
”
José Bouaniche
CISA, CIA, CISSP
L'auditeur a à sa disposition tout
un ensemble d'outils informatiques
sur chaque phase de mission :
Étape préliminaire
Il faut aussi y ajouter les logiciels
spécifiques aux audits de sécurité
informatique, comme les scanners.
Outils de requêtes et collecte d’information,
outils d’éditions, outils d’accès à Internet, etc.
Conduite de mission Outils de restitution
Outils de gestion documentaire
Outils de planification
Outils de gestion de papier de travail
Travail terrain
Outils de détection d’anomalies, de fraudes, etc.
basés sur l’analyse de données nombreuses ou
des techniques d’échantillonnage.
Outils de calculs et de comparaisons pour réaliser
des tests analytiques et statistiques
Outils pour rechercher et croiser des informations
Etc.
Il y a aussi des outils plus spécialisés
qui permettent de réaliser des
tests d'audit en milieu informatisé,
généralement à la disposition des
auditeurs informatiques, comme
par exemple :
L'ensemble des outils logiciels utilisables dans les phases d’audit
constitue les CAATs (techniques
d’audit assisté par ordinateur ou
« computer assisted audit techniques »).
Générateur de données de tests
Préparation automatique de fichiers
de tests
Utilitaires standards
Livrés avec les systèmes d’exploitation, pour extraction/fusion de
fichiers, tris de données, etc.
Logiciels de gestion
des changements
Logiciels vérifiant l’intégrité et la
pertinence des modifications de
programmes
L’audit continu,
essai de définition
R
elativement à l’utilisation des
CAATs, une nouvelle démarche
d’audit est depuis peu mise en
exergue, qui permettrait entre
autres d’améliorer la capacité des
auditeurs internes ou externes à
répondre aux obligations vis-à-vis
des autorités de régulations américaines (section 404 du « SarbaneOxley Act »).
Même si les outils existent depuis
de nombreuses années (voir tableau
page 5), le concept reste encore en
débat1.
Nous avons essayé de rassembler
ci-dessous les principes qui nous
ont semblé les plus pertinents, en
référence aux normes professionnelles de l’IIA et de l’ISACA.
Pour S.M. Groomer2, l'audit continu
est "une méthode ou une démarche
qui permet aux auditeurs de fournir
une assurance écrite sur un sujet
en utilisant une série de rapports
émis simultanément, ou après un
Notes :
1
. Voir par exemple “continous auditing from a
practical perspective” de Kevin Handscombe in
Information Systems Control Journal, volume 2,
2007, qui émet des réserves sur l’article de
Srinivas Sarva “continuous auditing through
leveraging technology” in Information Systems
Control Journal, volume 2, 2006.
2. Cité dans "the wave of the future" de Douglas
E. Ziegenfuss in Internal Auditor, April 2006.
La Revue / Mai 07
(04)
P 04-18 AUDIT*:Mise en page 1
11/05/07
9:58
Page 5
SCARF (systems control audit
review file) et EAM (embedded
audit modules)
Consiste à introduire des logiciels d'audit écrits spécialement à l'intérieur
du système d'applications de l'entreprise, de sorte que les systèmes applicatifs
soient "pilotés" de manière sélective.
SNAPSHOT
Consiste à prendre des images tout au long du "chemin de traitement" (processing path) suivi par une transaction. On enregistre les évolutions de données
sélectionnées, pour une révision ultérieure pratiquée par l'auditeur.
AUDIT HOOKS
Parties de logiciels embarqués sur des systèmes applicatifs, pour fonctionner
comme des drapeaux rouges. Ils doivent permettrent à l'auditeur d'agir
avant qu'une erreur ou une irrégularité ne soient allées trop loin.
ITF (integrated test facilities)
Cette technique consiste à introduire des entités fictives dans les fichiers
de production. L'auditeur peut demander au système de travailler soit avec
les programmes de production, soit avec les programmes de test, afin que
les programmes mettent à jour les entités fictives.
CIS (continuous and intermittent
simulation)
Le système déclenche une simulation d'exécution d'instructions de l'application, afin de s'assurer de la fiabilité de la transaction. Le déclenchement est
fait sur certains critères prédéterminés (montant ou autre). Sinon le simulateur
attend jusqu'à la prochaine transaction qui présentera les critères voulus.
> Les techniques d’audit continu
court délai, à des évènements relatifs au sujet traité3."
David Coderre, auteur notamment
du GTAG4 sur l'audit continu, en
donne la définition suivante5 : "une
structure unifiée qui réunit évaluation des risques et des contrôles,
planification d'audit, outils d'analyse numériques et toutes autres
techniques et technologies d'aide
à l'audit."
Pour ce GTAG6, l'audit continu
est une nécessité. En effet, il se
positionne classiquement dans
l'évaluation, face aux risques, des
dispositifs de contrôles permanents
de l'entreprise. Or ces derniers
sont de plus en plus automatisés,
systématiques et fréquents. Donc,
pour apporter une plus-value, l'audit
doit se mettre au diapason d'un
contrôle permanent toujours plus
en cohérence dynamique avec le SI
de l'entreprise, et se positionner
lui aussi comme un dispositif de
plus en plus automatisé, systématique et fréquent : c'est l'audit
continu7.
• l'évaluation continue des risques,
qui met en lumière les processus
ou les systèmes qui présentent un
niveau de risque mal appréhendé
par le système de contrôles permanents.
Comme pour l'audit classique, les
efforts déployés sur l'audit continu
sont fonction du risque d'audit sur
le process ou le système. De même,
ils sont inversement proportionnels
à la qualité des contrôles permanents exercés par le management
et le personnel.
Par ailleurs, ce GTAG rappelle
qu'en l'absence de contrôles permanents adéquats, l'audit doit réaliser
des tests approfondis de corroborations, la plupart du temps sous
forme de dispositifs informatisés.
Les programmes ou les requêtes
informatiques réalisés dans ce
cadre peuvent alors être livrés aux
entités auditées à l'issue de la mission pour enrichir les dispositifs de
contrôle permanent.
L'audit continu se compose alors
essentiellement de deux volets :
Ainsi l'audit continu a tout son
sens, que le contrôle permanent
soit continu ou non.
• l'évaluation continue du contrôle,
qui se focalise sur la détection au
plus tôt des déficiences de contrôle ;
D’autre part, il faut noter que ce
GTAG donne les conseils nécessaires à un déploiement raisonné de
La Revue / Mai 07
(05)
procédures de contrôles informatisés, et à leur supervision par le
directeur de l’audit interne.
En conclusion, on peut inférer de
ces éléments une définition « syncrétique » : « l’audit continu est une
démarche d’audit caractérisée par
l’usage intensif de CAATs, exercés
avec une fréquence proportionnée
aux évènements ou risques à traiter ».
Notes :
3. Continuous auditing is "a process or methodology that enables independant auditors to provide written assurance on a subject matter using
a series of auditors' reports issued simutaneously
with, or a short period after, the occurence of
events underlying the subject matter". C'est cette
même définition que l'on retrouve dans un travail
de recherche de 1999 du CICA (Canadian Institute
of Chartered Accountants) selon Sean Chen in
« Continuous auditing : risks, challenges and
opportunities » The international journal of management and technology, Volume 1, Number 1,
2003.
4. Les GTAGs (Global Technology Audit Guide) sont
une collection de cahiers d'une cinquantaine de
pages, publiée par l'IIA (Institute of Internal Auditors). Destinés d’abord aux directeurs d'audit
interne, ils sont publiés régulièrement depuis
2005. Le troisième GTAG traite de l'audit et du
contrôle continu.
5. D. Coderre "a continuous view of accounts"
in Internal Auditor, April 2006.
6
. Les auteurs en sont David Coderre de la Royal
Canadian Mounted Police, avec John G. Verver,
ACL Services Ltd. et Donald J. Warren, Center for
Continuous Auditing, Rutgers University.
7
. Voir aussi à ce propos l'article de Dan Kneer
“continuous assurance : we are way overdue”
dans Information Systems Control Journal,
volume 1, 2003.
P 04-18 AUDIT*:Mise en page 1
11/05/07
9:58
Les normes ISACA
éclairent les concepts utilisés
Page 6
Risque inhérent
(inherent risk)
C’est un risque indépendant de la mission d’audit,
qui apparaît en fonction de la nature de l’entreprise,
c’est-à-dire de son environnement, marché, et
catégorie, mais aussi de la culture d’entreprise
et du style de management qui lui est propre.
Risque de contrôle
(control risk)
Risque qu’une erreur significative existe sans
être prévenue ou détectée à temps par le système
de contrôle interne.
L
'audit continu relève essentiellement (mais non spécifiquement)
de trois items des normes professionnelles ISACA :
S3 : professional ethics and standards
S12 : audit materiality
S14 : audit evidence
L'item S3 est le socle fondamental
de toute mission d'audit puisqu'il
pose la rigueur morale et les "due
professional care" dans l'exercice
de la profession, et impose l'utilisation des normes.
Risque de non
Risque qu’un auditeur utilise une procédure de test
détection (detection inadéquate et conclue qu’il n’y a pas d’erreur alors
risk)
qu’en réalité il y en a.
Par exemple, le risque de non détection de failles
de sécurité dans un système d'information doit être
considéré comme élevé car l’exhaustivité en ce
domaine peut difficilement être atteinte.
À l'opposé, le risque de non détection lié à l'absence
de plan de secours informatique est généralement
bas car la documentation de ces plans existe ou
n'existe pas, ce qui peut être très facilement vérifié.
S3
Professional ethic
& standards
Audit materiality
>
>
S12
<>
S14
Risque d’audit
(overall audit risk)
Audit Evidence
Les items S14 (preuve d'audit) et
S12 (matérialité ou seuil de signification) situent la problématique de
l'utilisation d'outils logiciels et de
toute autre technique lors d'une
mission. Ils sont en interrelation
car la qualité et l'étendue de la
preuve d'audit est fonction du niveau
de matérialité attendu.
C’est la combinaison des catégories individuelles
des risques évaluée pour chaque objectif spécifique
de contrôle.
L’auditeur fera en sorte que le risque d’audit soit
limité à un niveau suffisamment bas sur le domaine
audité. Pour ce faire il déploiera une approche d’audit en conséquence.
> Les différents types de risques d’audit
Les commentaires de S12 rappellent
que le risque d'audit est composé
du risque inhérent, du risque
de contrôle et du risque de (non)
détection.
particulièrement éclairant sur :
– la confiance à accorder aux données traitées.
• Appropriée, c'est-à-dire suffisamment documentée pour être
démonstrative.
Les commentaires font aussi référence au guide normatif G13 "use of
risk assessment in audit planning"
pour plus de détails. Ils explicitent le
lien entre risque d'audit et seuil de
signification (materiality).
• Fiable, c'est-à-dire que le support
de la preuve initiale est suffisamment crédible et infalsifiable.
Les CAATs doivent être
utilisées avec prudence
Les commentaires normatifs des
S14 et S12 fixent le vocabulaire.
Ainsi, dans le S14, une preuve
d'audit doit être appropriée, fiable et
suffisante8.
• Suffisante, c'est-à-dire qu'elle
répond aux objectifs de la mission
tout en étant suffisamment éclairante pour qu’une personne prudente et informée aboutisse aux
mêmes conclusions que l’auditeur.
Enfin, les preuves doivent naturellement être sécurisées et bénéficier
d'un délai de rétention approprié.
I
l n'y a donc ni norme ni guide
dédié spécifiquement à l'audit
continu au sens strict. On trouve
par contre un texte plus générique
relatif à l'usage des techniques
d’audit assisté par ordinateur, le
guide G3 "use of computer-assisted
audit techniques document". Il est
La Revue / Mai 07
(06)
– la compétence de l'auditeur pour
l'utilisation de CAATs ;
– la confiance à accorder aux CAATs
elles-mêmes ;
Ainsi :
• l’usage d’outils informatiques
passe préalablement par la compréhension des théories sous-jacentes
à leur usage ;
• l’utilisation de tout outil pendant
Notes :
8. On notera que pour l’IIA, une preuve d’audit
doit être pertinente, suffisante et concluante.
Une information est pertinente si elle conforte
les constatations et recommandations de l’audit
et répond aux objectifs de la mission. Une information est suffisante si elle est fonctionnelle,
appropriée et probante, de sorte qu’une personne
prudente et informée aboutisse aux mêmes
conclusions que l’auditeur. Une information
concluante est fiable et facilement accessible
par l’utilisation de techniques d’audit appropriées.
P 04-18 AUDIT*:Mise en page 1
11/05/07
9:58
Page 7
la phase terrain est sous-tendue
par la pertinence de l'outil relativement à la preuve d’audit attendue,
et sa fiabilité qui doit toujours être
testée ;
• l’utilisation de données, qu’elles
soient informatisées ou non, doit
être précédée par l’appréciation de
leur qualité. Il est en effet dangereux
de tirer des conclusions à partir de
prémisses fausses, ce qui est le
cas dès que les données de base
utilisées par les auditeurs n’ont
pas de garantie de fiabilité ou
qu’elles ne couvrent pas le périmètre
prévu.
La qualité des données
doit être interrogée
S
ur ce sujet, les normes d’audit
du GAO9 stipulent :
« Quand les données informatisées
constituent une part importante ou
intégrale du matériel d’audit et que
la fiabilité des données est cruciale
pour réaliser les objectifs d’audit, les
auditeurs doivent s’assurer que les
données sont pertinentes et fiables.
Cette assurance doit être acquise,
que les données soient fournies aux
auditeurs ou que les auditeurs les
obtiennent pas leurs propres
moyens. Pour déterminer le niveau
de fiabilité des données, les auditeurs
peuvent :
• soit conduire une revue des
contrôles généraux et d’application
des systèmes informatisés, en y
effectuant des tests ;
• soit conduire d’autres tests et procédures, si les contrôles généraux et
d’applications ne sont pas passés
sous revue ou sont considérés
comme non fiables.
Quand l’objectif principal de l’audit est
la fiabilité d’un système informatisé,
les auditeurs devraient systématiquement conduire une revue des
contrôles généraux et d’applications
de ce système.
Quand les données informatisées
sont utilisées (ou citées dans le rapport) par l’auditeur à titre d’information
et n’ont pas d’impact sensible sur
les résultats d’audit, on considère
qu’il suffit de citer la source des données dans le rapport afin de satisfaire
aux normes pour ce qui est de
l’exactitude et de l’exhaustivité. »
Le choix d’outils d’audit doit
s’opérer avec méthode et précaution
Le GAO propose une démarche
structurée10 permettant d’optimiser
l’effort de test sur les données en
préalable aux tests d’audit (voir
schéma ci-dessus).
L
Bien sûr, il aura d'abord fallu s'interroger sur les données à obtenir,
en travaillant sur la qualité de la
preuve11.
e journal Internal Auditor de
l’IIA fait paraître chaque année
en août, depuis 1995, une évaluation
d'ensemble de l’utilisation des logiciels d’audit dans la communauté
internationale. L'article la présentant est généralement restreint
à un commentaire des résultats
obtenus, mais il va quelquefois plus
Notes :
9. United States General Accounting Office GAO’s government auditing standards.
10. Pour une introduction à cette problématique, voir “facing the data integrity challenge” de Raymond
Wessmiller, senior computer specialist au GAO, in www.itaudit.org volume 5 May 1 2002. Pour
approfondir la démarche du GAO relative à la fiabilité des données, voir “Assessing the reliability of
computer-processed data” applied research and methods, October 2002, GAO-03-273G.
11
. Voir par exemple “getting the most from duplicate-payment audits” de Richard Lanza in
www.itaudit.org, volume 5, March 1, 2002, et, pour approfondir, « evidence-gathering techniques » June
1994 – Office of the Auditor General of Canada.
La Revue / Mai 07
(07)
P 04-18 AUDIT*:Mise en page 1
11/05/07
9:58
loin, comme ce fut le cas en 2003
et 2004.
Voici un résumé des conseils qu’on
pouvait trouver en août 200312, relativement à l'ensemble des types de
logiciels pour l’audit.
Les besoins doivent guider les
choix. Les experts interrogés signalent que fréquemment les auditeurs
internes n’arrivent pas à utiliser
correctement les logiciels d’audit
pour la simple raison qu’on a
choisi un outil qui ne convient pas
au travail à réaliser. Bien souvent,
les auditeurs ne savent pas ce qu’il
est possible de faire du fait de leur
méconnaissance de l’offre du marché. Ils ont ainsi tendance à ne
s’intéresser qu’à l’automatisation
des tâches qu’ils réalisent manuellement, limitant ainsi l’étendue des
possibilités. Voici les étapes nécessaires à l’expression des besoins
du service d’audit :
Définir les missions, objectifs, et
priorités. Il est recommandé de
travailler avec la direction de l’entreprise pour déterminer au mieux
les missions, objectifs et priorités
d’audit qui pourraient être appuyés
par des logiciels.
S'inscrire dans l’environnement
technologique de l'entreprise.
Apprécier les risques. Comme
toute utilisation de logiciel, ceux
d’audit présentent des risques et
peuvent poser plus de problèmes
qu’ils n’en résolvent, par exemple
en réalisant des alertes inutiles
nécessitant des contrôles supplémentaires de la part des opérationnels. De même, il faudra s’interroger
pour savoir si les bénéfices attendus
des logiciels d’audit vaudront l’investissement réalisé. Les coûts de
paramétrage ou customisation, de
formation des utilisateurs, de maintenance et de changement de version
de logiciels complexes peuvent
difficilement être rentabilisés, s’ils
le sont jamais.
Page 8
Étudier les options. Il y a une multitude de solutions à disposition
des auditeurs internes. Il faut en
effet savoir qu’il vaut mieux utiliser
le logiciel adéquat relativement au
travail à réaliser plutôt que de se
focaliser sur un seul outil qu’on
torturera pour lui faire faire tout et
n’importe quoi. Ainsi, beaucoup de
services d’audit utilisent des bases
de données bureautiques ou des
tableurs. Il faut bien savoir que
ceux-ci ont des limites et que vouloir
leur faire faire plus que ce dont ils
sont capables en standard pourra
coûter cher en terme de maintenance ou de fiabilité des outils, et
pourra avoir des conséquences sur
la qualité de la preuve d’audit. Si
leurs limites sont correctement
prises en compte, les tableurs peuvent en conséquence être utilisés
pour tout ce qui est des analyses
de régression, de ratio, de tendances
ou de mesures de la performance.
Si les auditeurs ont besoin d’outils
plus puissants ou sophistiqués, ils
devront s’intéresser aux outils en
place dans l’entreprise sur les
domaines de la business intelligence, des bases de données d’entreprise ou encore de gestion
d’entreprise. Mais les auditeurs
pourront peut-être être encore
mieux servis par des outils spécifiques qu’ils auront développés ou
fait développer, par exemple dans
le domaine de l’analyse des
risques, la détection des fraudes
ou l’automatisation des papiers de
travail. Il y a enfin la solution
d’acheter des logiciels du marché.
Évaluer le logiciel. Il faudra aussi
évaluer le logiciel sur différents
critères comme la simplicité d’utilisation, la lisibilité des restitutions,
la qualité de la documentation, le
support technique, la réputation du
fournisseur, la gestion des versions,
les coûts et naturellement la couverture fonctionnelle des besoins.
La liste est loin d’être exhaustive.
Faire fonctionner l’outil. Il ne faut
surtout pas oublier que l’outil ne
permet pas de s’exonérer du travail
préalable de compréhension des
données à traiter : que signifientLa Revue / Mai 07
(08)
elles (quel est leur sens), couvrentelles nos besoins d’audit, sont-elles
fiables et utilisables ?
Enfin, plus le logiciel est complexe,
plus il faudra de temps de formation
et d’expérience avant de pouvoir en
tirer un éventuel bénéfice. Pour ce
faire, le service d’audit doit être sûr
de pouvoir utiliser ses logiciels
d’audit sur la plupart des missions
afin de pouvoir développer l’expérience des auditeurs pour leur utilisation judicieuse.
Privilégier l'existant et les logiciels
libres. Dans le numéro d'août 2004
d'Internal Auditor, l'article13 consacré
à l’enquête annuelle sur les outils
d’audit préconise d'abord de voir
si les logiciels en place dans
les services opérationnels ou de
contrôle de gestion (par exemple)
ne peuvent pas être réutilisés par
l'audit (IDEA, SQL14, SAS et les outils
bureautiques comme ACCESS ou
EXCEL en sont des exemples).
Cet article souligne aussi la qualité
professionnelle des logiciels libres
et préconise aux auditeurs en
quête d’un outil de regarder vers
les logiciels libres AVANT d’envisager une solution commerciale.
Par exemple, il propose de balayer
Internet pour voir si des logiciels
libres ou gratuits ne sont pas disponibles pour remplir les fonctions
attendues, plutôt que de se précipiter
sur des offres commerciales. Ceci
est particulièrement vrai pour tout
ce qui concerne les audits informatiques et notamment de sécurité15.
Notes :
12
. “Choosing the right tools” par Tim McCollum
et David Salierno, Internal Auditor, August 2003.
13. Voir « Get the most out of audit tools » par
Russel A. Jackson, Internal Auditor August
2004.
14
. Voir par exemple “Data analysis with SQL”
de Tim McCollum in www.itaudit.org volume 5,
September 1, 2002.
15
. Voir « open source tools for security and
control assessment » de K.K. Mookhey, dans
Information Systems Control Journal volume 1,
2004.
P 04-18 AUDIT*:Mise en page 1
11/05/07
9:58
On trouvera facilement aussi, gratuitement à disposition sur le Net,
des feuilles EXCEL préprogrammées pour faire des travaux analytiques (ratios, tendances, tirage
aléatoire et analyse statistique),
notamment sur www.auditnet.org.
En conclusion :
de nombreuses solutions
s’offrent à l’auditeur
L
es outils de l’auditeur sont
donc nombreux. Des articles et
autres livres blancs paraissent
Page 9
régulièrement sur cet thème, plus
ou moins liés à des logiciels commerciaux. Ils concernent tous les
types de CAATs, sur les périmètres
d'analyse des risques, de gestion
des papiers de travail, de restitution,
d'examen analytique16, d'analyse
statistique, de détection de fraudes17,
etc.
généralisé19, des réseaux de neurone20, de l’audit par les risques21,
d'outils analytiques22 comme la
loi de Benford23, l’analyse de
régression24 ou encore l’analyse
de ratios25. Outre les articles dont il a déjà été
fait référence, on trouve ainsi couramment des articles consacrés à
l'audit et aux CAATs, et traitant de
data mining18, des logiciels d’audit
Notes :
16
. Rappelons que l'examen analytique consiste à comparer des données de
même type sur des périodes équivalentes et antérieures et à établir des relations entre elles. Par exemple comparer les facturations mensuelles de
sous-traitance informatiques au niveau des prestations fournies (temps
machine, volume de pages imprimées, ..), analyser des écarts et des tendances,
étudier et analyser les éléments exceptionnels résultant de ces comparaisons.
20
. « Using neural network software as a forensic accounting tool » par
Michael et Virginia Cerullo in ISACA Control Journal volume 2, 2006.
21. Voir l’utilisation d'EXCEL pour optimiser les tests de contrôle guidés
par les risques dans « optimizing controls to test as part of a risk based
audit strategy » par Mukul Paarek in ISACA Control Journal volume 2, 2006.
. Voir notamment “using EXCEL as an audit software” de Richard
17. Voir l'article « how to use a new computer audit fraud prevention 22
Lanza sur le site audinet.org. Il fournit une panoplie complète de tests anaand detection tool » dans Information Systems Control Journal
volume 1, 2004, où Richard Lanza expose en 4 pages une démarche pratique
d’audit de fraude et propose par type de tests d’audit les logiciels courants
qu’il considère comme adaptés à la situation. Cet article résume son opuscule
« proactively detecting occupational fraud using computer audit report »,
en vente sur le site de l'IIA.
18. « Data mining and the auditor's responsability » par Bob Denker in
lytiques et d’analyse de données assortis de leur mise en application sur
EXCEL.
23. Voir “Assessing Data Authenticity with Benford's Law” par Bassam
Hasan, in ISACA Control Journal volume 6, 2002, ou encore la suite d'articles
de Mark J. Negrini “Digital Analysis: a computer-assisted data analysis
technology for internal auditors” parus sur le site www.ITaudit.org.
ISACA InfoBytes.
24. Voir l’article de Richard Lanza “using regression analysis to conti-
19. « Managing data integrity and accuracy effectively : the case for data
nuously monitor exceptions” qui présente la technique d’analyse de régression, ainsi que son application sur EXCEL.
analysis software » par Rich Lobb in ISACA Control Journal volume 5, 2001, ou
encore « general audit software: effective and efficient tool for today's IT audits »
par Tommy Singleton in ISACA Control Journal volume 2, 2006.
25. “Ratio analysis, an understated data analysis technique” par Dave
Coderre in www.ITaudit.org.
Pourquoi piloter un portefeuille de projets alors que
l’on pilote déjà les projets individuellement ? Les entreprises sont fréquemment confrontées à gérer une
centaine de projets et une vision globale du
portefeuille de projets s’impose. Tant au plan de leur
suivi que de leurs apports à la stratégie de l’entreprise. Placer en perspective la valeur du portefeuille
de projets et la stratégie de l’entreprise, met en
évidence l’équilibrage nécessaire dans l’allocation
des ressources et des efforts. Étayé par des exemples, l’ouvrage montre, en particulier, l’apport des
outils de pilotage « balanced scorecard » dans
cette approche.
C’est à ce thème que s’intéresse cet ouvrage
écrit par une équipe mixte de contrôleurs de gestion et de directeurs de projets. Un vaste champ
de travail pour les contrôleurs de gestion.
La Revue / Mai 07
(09)