MISE EN PLACE D`UN « GLOBAL BANKING » : CONDUITE DU

Transcription

UNIVERSITÉ DE MANNOUBA
INSTITUT SUPERIEUR DE COMPTABILITE ET D’ADMINISTRATION
DES ENTREPRISES
MÉMOIRE POUR L’OBTENTION DU DIPLÔME NATIONAL D’EXPERT
COMPTABLE
MISE EN PLACE D’UN « GLOBAL BANKING » :
CONDUITE DU PROJET ET RÔLES DE L’EXPERT
COMPTABLE
Elaboré par :
M. Mohamed Moussa
Dirigé par :
M. Islem Ridane
Année Universitaire : 2010-2011
A l’âme de mon père
A ma famille
A mes amis
A tous ceux que j’aime
REMERCIEMENTS
Je tiens à exprimer mes remerciements à mon encadreur M. Islem Ridane pour l’aide
qu’il m’a apporté et le temps qu’il m’a consacré pour mener à bien ce travail.
Mes remerciements s’adressent également à tous ceux qui ont contribué à ma formation
académique et professionnelle et en particulier les associés et les responsables de
mission du cabinet AMC Ernst & Young ainsi que mes enseignants à l’Institut Supérieur
de Gestion de Sousse et à l’Institut des Hautes Etudes Commerciales à Carthage.
Mes remerciements s’adressent aussi au management d’Attijari Bank qui m’a permis de
participer au projet du changement du système d’information de leur banque. Je remercie
également les différents acteurs qui ont contribué dans ce projet.
Je présente aussi, mes vifs remerciements aux membres du jury qui ont accepté d’évaluer
ce travail.
Mohamed Moussa
Sommaire
SOMMAIRE
SOMMAIRE ................................................................................................................................................................................................. 1
INTRODUCTION GÉNÉRALE .................................................................................................................................................................... 2
PREMIÈRE PARTIE : CONDUITE DU PROJET D’IMPLANTATION D’UN GLOBAL BANKING : ENJEUX DU CHANGEMENT ET
DÉMARCHE DE DÉPLOIEMENT ............................................................................................................................................................... 5
CHAPITRE 1 : ENJEUX DU CHANGEMENT DU SYSTÈME D'INFORMATION ....................................................................................... 6
SECTION 1 : MOTIVATIONS POUR LE CHANGEMENT VERS UN ERP................................................................................................................ 6
Paragraphe 1 : Etat des lieux de l’activité bancaire ........................................................................................................................... 6
Paragraphe 2 : Apports des ERP ..................................................................................................................................................... 24
SECTION 2 : COMMENT CHOISIR SON ERP ? ............................................................................................................................................ 30
Paragraphe 1 : Le marché des Global Banking ............................................................................................................................... 30
Paragraphe 2 : Critères et démarche du choix de l’ERP.................................................................................................................. 34
CHAPITRE 2 : PROCESSUS D’IMPLANTATION D’UN GLOBAL BANKING ........................................................................................ 46
SECTION 1 : CADRE DE RÉFÉRENCE DE CONDUITE DE PROJET ................................................................................................................... 47
Paragraphe 1 : Standards internationaux de gestion de projet ........................................................................................................ 48
Paragraphe 2 : Concepts de base de gestion de projet proposés par les standards internationaux ............................................... 51
SECTION 2 : DÉMARCHE ILLUSTRÉE DE MISE EN PLACE D’UN GLOBAL BANKING ......................................................................................... 63
Paragraphe 1 : Phase de lancement ................................................................................................................................................ 63
Paragraphe 2 : La configuration et l’homologation de la solution .................................................................................................... 70
Paragraphe 3 : La mise en production ............................................................................................................................................. 82
DEUXIÈME PARTIE : RÔLES DE L'EXPERT COMPTABLE DANS LES PROJETS D’IMPLANTATION DE GLOBAL BANKING :
DOMAINES D’INTERVENTION ET DÉMARCHE PRATIQUE D’ASSISTANCE DANS LA MIGRATION DES DONNÉES .................... 89
CHAPITRE 1 : L’IMPLANTATION DE « GLOBAL BANKING », DE NOUVELLES MISSIONS POUR L’EXPERT COMPTABLE ....... 90
SECTION 1 : LE BESOIN D’ASSISTANCE ET LA VALEUR AJOUTÉE DE L’EXPERT COMPTABLE .......................................................................... 90
Paragraphe 1 : Les acteurs du projet et le besoin d’assistance ....................................................................................................... 90
Paragraphe 2 : Valeur ajoutée de l’expert comptable et cadre d’intervention .................................................................................. 96
SECTION 2 : DOMAINES D’INTERVENTION DE L’EXPERT COMPTABLE DANS LE PROJET ............................................................................... 109
Paragraphe 1 : Assistance dans le choix de la solution ................................................................................................................. 110
Paragraphe 2 : Assistance dans le pilotage global du projet de mise en place ............................................................................. 114
Paragraphe 3 : Assistance dans la réalisation et l’homologation de la solution ............................................................................. 118
Paragraphe 4 : Assistance dans la conduite du changement ........................................................................................................ 125
Paragraphe 5 : Assistance dans la migration des données ........................................................................................................... 128
CHAPITRE 2 : GUIDE MÉTHODOLOGIQUE D’ASSISTANCE DANS LA MIGRATION DES DONNÉES ........................................... 129
SECTION 1 : PROPOSITION D’ASSISTANCE ET ACCEPTATION DE LA MISSION .............................................................................................. 129
Paragraphe 1 : La proposition d’assistance ................................................................................................................................... 130
Paragraphe 2 : la convention d’assistance..................................................................................................................................... 133
SECTION 2 : CONDUITE DE LA MISSION D’ASSISTANCE ............................................................................................................................. 136
Paragraphe 1 : Le diagnostic ......................................................................................................................................................... 136
Paragraphe 2 : Préparation de la migration ................................................................................................................................... 138
Paragraphe 3 : Mise en œuvre et recette définitive ....................................................................................................................... 159
CONCLUSION GÉNÉRALE .................................................................................................................................................................... 169
BIBLIOGRAPHIE .................................................................................................................................................................................... 171
ANNEXES................................................................................................................................................................................................ 175
TABLE DES MATIÈRES ......................................................................................................................................................................... 179
Page 1
Introduction Générale
INTRODUCTION GÉNÉRALE
Conscient de l’impact de l’évolution de la conjoncture économique mondiale et afin de mieux la gérer, la Tunisie
a entrepris un vaste programme de mise à niveau de tous les secteurs de l’économie nationale et notamment le
secteur bancaire.
La promulgation de la loi bancaire 2001-65 a permis la mise en place d’un environnement plus libéral pour
l'exercice des métiers bancaires en supprimant le cloisonnement historique entre les banques de développement
et les banques de dépôts. D’autres mesures règlementaires ont été prises pour préparer les banques au
passage à Bâle II et à respecter le dispositif international de lutte contre le blanchiment d’argent.
Par ailleurs, un vaste programme de modernisation du système bancaire et financier a été lancé depuis 1997:
développement de la monétique (SMT), la réalisation du système national de la télécompensation (SIBTEL), la
sécurisation des transports de fonds (IBS), la mise en place d’une centrale d'information (SED),…
Ces dernières années ont été également marquées par le désengagement progressif de l’Etat du capital de
certaines banques au profit de groupes bancaires internationaux. Cette présence de plus en plus forte des
acteurs privés dans le secteur bancaire tunisien a permis de rendre ce secteur de plus en plus concurrentiel et a
donné lieu à l’apparition de nouveaux produits financiers notamment dans les domaines monétiques et la
bancassurance,…
Pour accompagner ces développements et actions de modernisation du secteur bancaire, les banques se sont
retrouvées contraintes de mettre à niveau leurs processus, organisations et systèmes d’information. Sur ce
dernier point, la quasi-totalité des banques ont lancé des réflexions voire des actions pour la refonte et le
changement de leurs systèmes d’information. Certaines de ces actions ont déjà abouti (cas de l’Union
Internationale des Banques et Attijari Bank). Toutes ces réflexions et actions sont orientées vers une solution
globale de type « ERP bancaire » plus connue sous l’appellation « Global Banking ».
Le choix de la solution et la conduite du projet d’implantation d’un ERP bancaire sont qualifiés d’actions
complexes, longues et coûteuses. Si les bénéfices attendus de l’implantation d’un « Global Banking » sont
importants et offrent un certain nombre d’avantages, ces projets sont également porteurs des contraintes et des
risques : dépassement des budgets, dépassement de l’échéancier, insatisfaction des utilisateurs,… Dans ce
cadre, les organismes internationaux de normalisation (ISO, PMI1,..) ont arrêté des normes et des
recommandations pour la gestion de la qualité et des risques des projets.
Tous les standards internationaux de gestion de projet ont mis l’accent sur l’importance du rôle des ressources
humaines. En effet, la réalisation de projet de changement et de refonte du système d’information d’une banque
1
Project Management Institue (Cf. page 49)
Page 2
requiert une forte mobilisation de ressources. Cependant, obtenir ces ressources, dédiées au projet, n’est pas
toujours facile. Ce besoin en ressources peut être comblé en faisant appel aux services de conseil et
d’assistance des experts comptables. L'expert-comptable, conseillé privilégié des entreprises peut ainsi être
sollicité dans le choix de la solution et de son déploiement.
Le conseil en matière de systèmes d'information est un créneau à la fois nouveau et prometteur pour les experts
comptables. Les compétences de l’expert comptable dans des domaines d’activités diversifiés, sa maîtrise de la
règlementation et des processus de la banque et la confiance des dirigeants dans la qualité de ses services
procurent un avantage concurrentiel pour l’expert comptable pour accompagner les banques dans leurs projets
de refonte et changement de leurs systèmes d’information.
Ainsi, ce travail s’attachera à répondre à la problématique suivante : quelle est la démarche à adopter dans la
conduite d’un projet d’implantation d’un « Global Banking » ? Et quels rôles pour l’expert comptable
dans ce type de projet ?
Afin de répondre à cette problématique, nous essayerons particulièrement à répondre aux interrogations
suivantes :
 Pourquoi les banques sont-elles dans l’obligation de changer leur système d’information ?
 Quel cadre de référence à respecter dans la conduite de projet d’implantation d’un « Global Banking » ?
 Quelle est la démarche à appliquer pour le choix et l’implantation d’une solution de « Global Banking » ?
 Pourquoi les banques ont besoin d’assistance pour la réalisation de ce type de projet ? Quelle est la
valeur ajoutée que représente l’expert comptable par rapport aux autres professionnels ?
 Quels sont les domaines d’intervention de l’expert comptable dans ces projets ?
 Quelle approche doit adopter l’expert comptable pour réaliser une mission d’accompagnement d’une
banque dans la migration des données?
En vue de répondre aux questions posées dans la problématique et atteindre les objectifs qui lui sont fixés, ce
mémoire respectera la démarche suivante :
Dans la première partie nous essayerons de présenter le processus de choix et de conduite de projet de mise
en place d’un « Global Banking ». Pour ce faire, nous allons dans un premier chapitre présenter les motivations
des banques de procéder au changement de leur système d’information. On présentera également les critères et
le processus de choix de la solution à mettre en place.
Dans un deuxième chapitre, nous allons présenter la démarche d’implantation de la solution choisie. Ce
chapitre sera subdivisé en deux sections. La première traitera du cadre de référence de management de projet
Page 3
et ce en parcourant les principaux référentiels et standards internationaux en matière de gestion de projet. Au
niveau de la deuxième section, on détaillera les étapes pratiques de conduite du projet d’implantation d’un
« Global Banking ».
La deuxième partie essaye de mettre en évidence le rôle et la démarche de l’expert comptable dans la
réalisation d’un projet d’implantation d’un « Global Banking » et particulièrement l’assistance dans la migration
des données. Nous allons dans un premier chapitre présenter le besoin des banques aux services de
conseillers externes et la valeur ajoutée que peuvent apporter les experts comptables dans ce cadre. Nous
recenserons dans une deuxième section les différents domaines d’intervention dans lesquels les experts
comptables peuvent fournir des prestations d’assistance et d’accompagnement.
Le deuxième chapitre présentera un guide méthodologique pour l’expert comptable dans l’accompagnement
d’une banque dans la phase de migration des données à partir des systèmes sources vers le nouveau système.
Page 4
PREMIÈRE PARTIE : CONDUITE DU PROJET
D’IMPLANTATION D’UN GLOBAL BANKING : ENJEUX DU
CHANGEMENT ET DÉMARCHE DE DÉPLOIEMENT
Première Partie
Chapitre 1 : Enjeux du changement du système d’information
CHAPITRE 1 : ENJEUX DU CHANGEMENT DU SYSTÈME
D'INFORMATION
Pour décrire les enjeux du changement du système d’information et de l’implantation d’un Global Banking, il y a
lieu de dresser les éléments et facteurs incitant les banques tunisiennes à procéder à un tel changement
(Section 1) ainsi que de présenter les enjeux du choix de la nouvelle solution (Section 2).
SECTION 1 : MOTIVATIONS POUR LE CHANGEMENT VERS UN ERP
Les banques se sont retrouvées dans l’obligation de changer leur système d’information en raison des évolutions
importantes qu’a connu l’activité bancaire ainsi à cause des lacunes et insuffisances capitales que présentent
leurs systèmes actuels (Paragraphe 1) comparativement aux avantages et apports des solutions de type ERP
(Paragraphe 2).
Paragraphe 1 : Etat des lieux de l’activité bancaire
On se propose dans ce paragraphe de présenter les principales évolutions connues par le système bancaire (1)
et de donner un aperçu sur les systèmes d’information actuellement en place dans les banques tunisiennes en
mettant l’accent sur leur incapacité à supporter le nouvel environnement bancaire (2).
1. Des nouveaux défis pour les banques
Plusieurs évolutions ont modifié significativement le paysage bancaire tunisien au cours de ces dernières
années. Ces évolutions peuvent être rassemblées selon deux groupes : les évolutions d’ordre commercial
rendant le secteur bancaire de plus en plus libéral (1.1) et les évolutions d’ordre règlementaire et prudentiel
renforçant ainsi la culture de risque (1.2).
1.1.
Libéralisation du secteur bancaire
A l’instar du reste des activités économiques, le secteur bancaire tunisien s’est engagé depuis quelques années
dans un processus de libéralisation graduelle. La libéralisation du secteur bancaire est reflétée principalement
Page 6
Première Partie
dans l’émergence du concept de la banque universelle (1.1.1) et le désengagement progressif de l’ETAT et
l’ouverture du capital des banques à des groupes privés internationaux (1.1.2). Ces mouvements de libéralisation
financière ont permis d’accentuer la concurrence entre les banques d’une part (1.1.3) et de relancer le processus
de convertibilité totale du dinar d’autre part (1.1.4).
1.1.1. Emergence du concept de la banque universelle
Contrairement à l'ancienne loi bancaire2 prévoyant plusieurs types d’agrément, la loi 2001-65 du 10 juillet 2001
relative aux établissements de crédit a défini un cadre juridique unique pour l’exercice de l’ensemble des
activités bancaires reconnaissant ainsi la vocation universelle des établissements de crédit. Cette loi a contribué
au décloisonnement des activités bancaires en supprimant les spécificités de l’époque et les différences entre
les banques de dépôts et les banques d’investissement.
Au sens de l’article 2 de la loi 2001-65 du 10 juillet 2001 relative aux établissements de crédit, « est considérée
comme établissement de crédit, toute personne morale qui exerce, à titre de profession habituelle, les opérations
bancaires ». Les opérations bancaires comprennent :

la réception des dépôts du public : Les banques régies par la loi 2001-65 sont habilitées à recevoir du
public des dépôts quelles qu’en soient la durée et la forme. L’article 3 de la loi 2001-65 a défini les dépôts
comme étant « les fonds que toute personne recueille d'un tiers à titre de dépôt ou autrement avec le droit
d'en disposer pour les besoins de l'exercice de son activité professionnelle, mais à charge pour elle de les
restituer à leurs titulaires ».

l’octroi de crédits : L’article 4 de la loi 2001-65 a défini l’opération de crédit comme étant « tout acte par
lequel une personne, agissant à titre onéreux, met ou promet de mettre des fonds à la disposition d'une
autre personne ou prend, dans l'intérêt de celle-ci, un engagement par signature tel qu'un aval, un
cautionnement ou toute autre garantie ».

l’exercice, à titre d’intermédiaire, des opérations de change

la mise à la disposition de la clientèle et la gestion des moyens de paiement : Les moyens de
paiements, au sens de l’article 5 de la loi 2001-65, sont « toutes formes d'instruments permettant, par
quelque procédé technique que ce soit, de transférer des fonds d'une personne à une autre ». Ainsi, un
moyen de paiement doit permettre un transfert de fonds.
Les établissements de crédit peuvent aussi effectuer les opérations liées à leur activité telles que le conseil et
l'assistance en matière de gestion de patrimoine, de gestion financière, d'ingénierie financière et d'une manière
générale tous les services destinés à faciliter la création, le développement et la restructuration des entreprises.
2
Loi n° 67-51 du 7 décembre 1967
Page 7
Première Partie
Les établissements de crédit peuvent, en outre, prendre des participations au capital d'entreprises existantes ou
en création, conformément aux conditions prévues par la loi 2001-653.
Ces dispositions ne sont pas applicables aux banques off shore qui restent régies par la loi 85-108 portant
encouragement d'organismes financiers et bancaires travaillant essentiellement avec les non-résidents. Ces
banques peuvent collecter toute forme de ressources appartenant à des non-résidents, accorder tous concours
aux non-résidents, notamment sous forme de prises de participations au capital d'entreprises non résidentes et
de souscriptions aux emprunts émis par ces dernières, délivrer toute forme de cautions aux entreprises
étrangères non résidentes adjudicataires de marchés publics ou privés en Tunisie ainsi que transférer tous fonds
en devises leur appartenant ou appartenant à des non-résidents.
Le système financier tunisien comprend actuellement 29 banques dont 21 banques régies par la loi 2001-65 et 8
banques off shore régies par la loi 85-108. Il comporte également 11 bureaux de représentation et 14
établissements financiers (10 sociétés de leasing, 2 sociétés de factoring et 2 banques d’affaires) 4.
1.1.2. Le désengagement progressif de l’ETAT
Depuis quelques années, l’Etat tunisien a procédé à la cession de parts importantes du capital dans certaines
banques au profit de groupes bancaires étrangers. Il s’agit principalement des opérations de privatisation
suivantes :

Privatisation de l’Union Internationale des Banques (UIB) après la cession de la part de l’ETAT dans son
capital (52,34%) au profit du Groupe Français Société Générale.

Privatisation de l’ex-Banque du Sud après la cession de la part de l’ETAT dans son capital (33,54%). La
cession a été faite au profit du consortium Andalumaghreb constitué par le Groupe Marocain Attijari Wafa
Bank et le Groupe Espagnol Banco Santander Central Hispano S.A.

Privatisation de la Banque Tuniso-Koweïtienne (BTK) par la cession de 60% du capital de cette banque,
détenus par l’Etat tunisien en association avec l’Etat koweïtien, au groupe français Caisse d’Epargne.
Ces opérations de privatisation ont largement influencé la structure du secteur bancaire tunisien. Ce dernier
comporte de plus en plus de banques privées. En effet, le capital des banques peut être réparti en trois tiers : un
tiers détenu par l’Etat, un autre tiers par des investisseurs privés tunisiens et le reste par des banques privées
étrangères. Plusieurs banques sont désormais des filiales de banques étrangères (7 banques).
3
4

L’Union Internationale des Banques (UIB) : filiale groupe Société Générale.

L’Arab Tunisian Bank (ATB): filiale de l’Arab Bank Plc.
L’art 21 et l’art 22 de la loi 2001-65 présentent les limites relatives aux prises de participations par un établissement de crédit.
www.bct.gov.tn (Septembre 2010)
Page 8
Première Partie

La Citibank Tunisie : filiale du groupe américain Citigroup.

L’Arab Banking Corporation (ABC) : filiale du groupe Arab Banking Corporation.

L’Union Bancaire pour le Commerce et l’Industrie (UBCI) : filiale du Groupe BNP-PARIBAS.

Banque Tuniso-Koweitienne (BTK) : Filiale du groupe français Caisse d’épargne.

Banque Attijari de Tunisie (Attijari Bank) : filiale du consortium Andalumaghreb constitué par le Groupe
Attijari Wafa Bank et le Groupe Banco Santander Central Hispano S.A.
On note également la présence de certaines participations étrangères minoritaires :

Crédit Industriel et Commercial (CIC) détenant 20% du capital de la Banque de Tunisie (BT).

Groupe Banque Populaire, le fonds d’investissement de BLAKENEY MANAGEMENT et le Groupe
SANPAOLO – IMI Internazionale S.P.A détenant des parts dans le capital de la Banque Internationale
Arabe de Tunisie (BIAT).
L’Amen Bank est la seule banque du secteur privé qui reste sans avoir un partenariat étranger.
Ce processus de désengagement de l’ETAT demeure non encore achevé, d’autres opérations de privatisation
seront engagées prochainement. Ces actions de privatisation ont permis de passer d’un mode largement
contrôlé par l’ETAT à un mode plus libéral et concurrentiel.
1.1.3. Intensification de la concurrence
Le décloisonnement des services bancaires et la présence de plus en plus d’acteurs privés ont contribué à
amplifier la concurrence entre les différents acteurs présents sur la place bancaire en Tunisie. Cet
environnement compétitif est caractérisé essentiellement par :

l’expansion du réseau d’agences et la redéfinition du rôle de l’agence,

la multiplication des canaux de distribution,

l’apparition et le développement de nouveaux produits, marchés et activités, et

la promotion de la qualité des services bancaires.
1.1.3.1. Expansion du réseau d’agences
Ces dernières années ont été marquées par l’augmentation du nombre d’agences pour la plupart des banques.
Le réseau bancaire a passé à 1288 unités en septembre 2010 contre 939 unités en 2005 ce qui a porté le taux
de bancarisation de 1 agence pour 11,1 mille habitants en 2005 à 1 agence pour 8,1 mille habitants en
septembre 20105. Cette politique d’expansion du réseau poursuit comme objectif principal la proximité à la
clientèle et l’augmentation des parts de marché.
5
www.apbt.org.tn
Page 9
Première Partie
On assiste également à une spécialisation des agences par marché. Les banques distinguent généralement
entre la banque des particuliers et professionnels et la banque de l’entreprise avec séparation entre les grandes
entreprises et les institutionnels et les petites et moyennes entreprises. Des chargés de clientèle spécialisés sont
affectés à chacun de ces marchés. Avec cette nouvelle organisation, les agences n’assurent plus les activités
d’exécution et d’enregistrement. Désormais, ces activités de back office sont traitées par des centres spécialisés.
En effet, l’agence devient plutôt un espace d’information, de conseil et de vente.
1.1.3.2. Multiplication des canaux de distribution
Bien que les banques tunisiennes soient plutôt des banques de réseaux, on assiste au développement d’autres
canaux de distribution notamment à travers les guichets automatiques, les banques par serveur vocal, par
téléphonie mobile ou par internet,…
Cette multiplication des canaux de distribution est la conséquence du développement significatif de la monétique
et des technologies de communication.
Le réseau des distributeurs automatiques de billets a passé de 729 en 2005 à 1 427 en septembre 20106.
1.1.3.3. Développement de nouveaux produits, marchés et activités
La libéralisation des activités bancaires a favorisé l’apparition et le développement :

de nouveaux produits : produits d’épargne, produits de bancassurance, produits monétiques, produits de
couverture des risques de change, les package de produits,…

des nouveaux marchés essentiellement le marché des crédits à la consommation ;

des nouvelles activités notamment dans le domaine du conseil et de l’ingénierie financière.
1.1.3.4. Promotion de la qualité des services bancaires
La qualité est considérée actuellement comme étant la préoccupation majeure et quotidienne de l’ensemble du
staff de la banque. La qualité constitue un facteur clef de succès pour atteindre les objectifs fixés en termes de
parts de marché et de rentabilité. La loi du 2 mai 2006 portant amendement de la loi bancaire est venue poser
les mécanismes à même de hisser la qualité des services bancaires au niveau des standards internationaux,
mécanismes qui s’articulent notamment autour des axes suivants :

Les services bancaires de base : les établissements de crédit doivent offrir à la clientèle des services
bancaires de base qui sont fixés par le décret n°2006-1880 du 10 juillet 2006.

La convention de gestion de compte de dépôt : les conditions générales et particulières minimales sont
fixées par la circulaire de la Banque Centrale de Tunisie n°2006-11 du 18 Octobre 2006.
6
www.apbt.org.tn
Page 10
Première Partie

Le Médiateur Bancaire : le rôle du médiateur bancaire est de favoriser le règlement amiable des différends
qui peuvent naître entre les clients et la banque. Le décret n°2006-1881 du 10 Juillet 2006 a fixé les
conditions d’exercice de l’activité du Médiateur Bancaire.

Création de l’Observatoire des Services Bancaire : cet observatoire est chargé essentiellement d’assurer le
suivi de la qualité des services bancaires, rendus à la clientèle.
1.1.4. La convertibilité totale du dinar
La convertibilité totale du dinar reste un ambitieux défi pour l’économie tunisienne. La convertibilité totale du
dinar tunisien implique la liberté pour tout détenteur de dinars de les convertir en n’importe quelle devise
étrangère dans la quantité qu’il veut, où il veut et quand il veut sans être soumis à aucune limitation.
Cette convertibilité exige des taux de croissance économiques élevés, des indicateurs économiques
fondamentaux sains et soutenus, des réserves de change considérables, un système bancaire solide, une
monnaie stable, une maîtrise drastique des déficits, des taux de l’inflation, d’endettement, ...
En plus des mesures prises depuis les années 90 pour la convertibilité du dinar pour les opérations courantes et
de commerce extérieur, plusieurs nouvelles mesures ont été décidées dans le but d’avancer dans le processus
de convertibilité du dinar tunisien. On peut citer principalement :

L’introduction de nouveaux produits enrichissant la gamme des produits de change à savoir le « compte de
prestataires de services »7 et le « compte allocation touristique »8.

Augmentation des plafonds des transferts au titre de l’allocation des voyages d’affaires 9 et d’allocations
touristiques10.

Autorisation des banques à la cotation des options de change11.
Le processus de convertibilité totale du dinar tunisien n’est pas encore achevé, plusieurs réformes sont
attendues pour atteindre cet objectif ambitieux.
Circulaire de la BCT n°2006-22 du 11 décembre 2006.
Circulaire de la BCT n°2006-14 du 9 novembre 2006.
9 Circulaire aux intermédiaires agrées n° 2009-06
10 Circulaire aux intermédiaires agrées n° 2009-21
11 Circulaire de la BCT n° 2007-27 du 18/12/2007.
7
8
Page 11
Première Partie
1.2.
Renforcement de la culture de risque
Suite aux pertes substantielles et aux faillites enregistrées par des groupes bancaires internationaux12, les
autorités de règlementation et de contrôle bancaire internationales ont pris plus de conscience de la diversité des
risques auxquels sont exposés les métiers bancaires et de la nécessité à mettre en place les dispositifs
adéquats de gestion et de maîtrise de ces risques. Ces dernières années ont été marquées ainsi par la diffusion
à l’échelle internationale de nouvelles règles de contrôle interne et de bonne gouvernance ainsi que de nouvelles
normes prudentielles et comptables. Ces dispositifs ont montré leurs limites et insuffisances pour prévenir et
éviter la crise financière de 2007, chose qui a amené les régulateurs internationaux à réviser leurs travaux.
Pour le cas de la Tunisie, le Fonds Monétaire Internationale (FMI) a confirmé dans son dernier rapport sur la
Tunisie13 que « Le secteur financier tunisien n’a pas ressenti les effets de la crise financière mondiale » et que la
liquidité est abondante sur le marché tunisien contrairement à la tendance internationale caractérisée par un
assèchement des liquidités.
Sur le plan de la maîtrise des risques bancaires et dans le but de se conformer aux exigences internationales, la
Tunisie a entrepris un certain nombre de réformes, on cite principalement :

La circulaire 2006-19 du 28 novembre 2006 relative au contrôle interne.

La loi 2003-75 du 15 décembre 2003 relative au soutien des efforts internationaux de lutte contre le
terrorisme et à la répression du blanchiment d'argent.

Les amendements14 à la loi bancaire 2001-65 notamment celles relatives au renforcement des règles de
bonne gouvernance par l’obligation de mettre en place un système de contrôle interne approprié, un comité
exécutif de crédit, une structure chargée du contrôle de la conformité,…
D’autres réformes sont attendues et concernent essentiellement l’adoption du dispositif prudentiel international
« Bâle II » ainsi que la conformité totale aux normes comptables internationales « IFRS ».
1.2.1. Renforcement du contrôle interne et des règles de la bonne gouvernance
Dans l’exercice de leurs activités, les établissements de crédit supportent différents types de risques : risque de
crédit, risque sur les opérations de marché et le risque opérationnel. En fonction de leur taille et de la complexité
de leurs activités, les établissements de crédit devraient mettre en place des systèmes de gestion du risque à
savoir les processus de détection, de mesure et de contrôle des expositions aux risques pour toutes les
principales catégories de risques encourus. C’est dans ce cadre que la Banque Centrale de Tunisie a promulgué
la circulaire 2006-19 dont l’objectif principal étant de s’assurer que l’ensemble des risques de toute nature sont
analysés et surveillés et de contribuer à la détection précoce ainsi qu’à la prévention des difficultés.
La banque britannique Barings en 1995, la Banque Lehman Brothers en Septembre 2008,…
www.imf.org (Conclusions préliminaires de la mission de consultation au titre de l’article IV, 15 juin 2010)
14 Amendements introduits par la loi 2006-19 du 02 mai 2006
12
13
Page 12
Première Partie
Les principales dispositions introduites par cette circulaire sont :

définition des niveaux de contrôles des opérations à mettre en place : les contrôles permanents et les
contrôles périodiques ;

introduction et définition des risques du marché et des risques opérationnels ;

introduction du système de notation interne dans l’évaluation et la gestion du risque de crédit ;

l’obligation de procéder à des simulations de crise destinées à évaluer l’adéquation des fonds propres ;

Définition des modalités de fonctionnement du comité permanant d’audit.
Cette circulaire est opportune à plusieurs niveaux, en effet :

elle est porteuse d’un message fort de la nécessité d’instituer un niveau de rigueur élevé dans
l’organisation, le mode de fonctionnement opératoire et la maitrise des risques bancaires ;

elle reste totalement en phase avec les règlementations internationales, dans la mesure où elle est inspirée
largement du règlement français CRBF 97-02 sur le contrôle interne et inclut de ce fait les bonnes pratiques
dans ce domaine ;

les règles qu’elle institue sont les préalables indispensables pour permettre aux établissements de crédit
tunisiens d’intégrer les projets futurs attendus, notamment « Bâle II » et IFRS.
Sur un autre plan, selon une mission menée en 200615 par le fonds monétaire international (FMI) sur la
conformité de système bancaire tunisien aux principes fondamentaux arrêté par le comité de Bâle pour un
contrôle bancaire efficace, il a été conclu que plus de la moitié des principes ont été jugés « conforme » ou «
largement conforme » et aucun principe n’a été noté « non conforme ».
Les principales actions à mettre en œuvre, pour atteindre la pleine conformité aux principes du Comité de Bâle
sont :

améliorer les conditions d’octroi de crédits et le suivi de la qualité du portefeuille ;

renforcer le provisionnement des créances classées et réduire le taux des créances improductives ;

renforcer la maîtrise des risques et le dispositif de contrôle interne dans les établissements de crédit ;

mettre en place une surveillance sur base consolidée ;

adapter les contrôles de la BCT aux nouvelles dispositions fixées par la circulaire sur le contrôle interne sur
les prêts aux apparentés et abaisser la limite globale applicable à ces concours ;

mettre en force le système de sanctions ;

conclure des conventions avec les autres autorités de contrôle : CMF et ministère des finances.
15 Rapport FMI N° 7/98 (Mars 2007) http://www.imf.org
Page 13
Première Partie
1.2.2. Mise en conformité au dispositif prudentiel Bâle II
La simplicité de la démarche retenue en 1988 sous l’égide du ratio Cooke ou Bâle I est devenue inappropriée.
Fondée sur une approche strictement quantitative, le ratio Cooke ne permet plus d’appréhender la réalité des
risques encourus ni de tenir compte des nouveaux mécanismes de couvertures utilisés par l’industrie bancaire.
Conscient des limites du ratio Cooke, le comité de Bâle a engagé depuis 1998 des travaux en vue d’améliorer ce
dispositif. Les travaux du comité ont abouti à un nouveau dispositif dont l’application est devenue obligatoire en
2007. Selon le comité, ce nouveau dispositif a pour objectif premier « de mettre au point un cadre permettant de
renforcer encore la solidité et la stabilité du système bancaire international, tout en continuant d’assurer un degré
suffisant d’harmonisation afin d’éviter que les règles relatives à l’adéquation des fonds propres deviennent un
facteur sensible d’inégalité concurrentielle entre banques internationales16».
Pour réaliser ces objectifs, le dispositif repose sur une nouvelle approche fondée sur trois « piliers » afin d’aboutir
à une gestion des risques plus fine, exhaustive et préventive. Les trois piliers sont les suivants :

Premier pilier : Exigences minimales de fonds propres
Ce premier pilier indique le mode de calcul des exigences minimales de fonds propres relatives aux risques de
crédit, de marché et opérationnel. Le nouveau dispositif offre une série d’options pour déterminer les besoins en
fonds propres en regard du risque de crédit et du risque opérationnel ; les banques et les superviseurs pourront
opter pour l’approche la plus adaptée à l’activité des établissements et à l’infrastructure des marchés financiers
sur lesquels ils opèrent.

Deuxième pilier : Processus de surveillance prudentielle
Ce pilier définit les obligations à la charge des banques et des autorités de contrôle de manière à garantir que
les banques disposent de fonds propres adéquats pour couvrir l’ensemble des risques liés à leurs activités, mais
également à les inciter à élaborer et à utiliser de meilleures techniques de surveillance et de gestion des risques.

Troisième pilier : Discipline du marché
Ce pilier prévoit les exigences de communication financière permettant aux acteurs du marché d’apprécier des
éléments d’information essentiels sur les fonds propres, les expositions aux risques, les procédures d’évaluation
des risques et, par conséquent, l’adéquation des fonds propres de l’établissement bancaire.
La crise financière qui a, depuis 2007, fortement impacté les marchés financiers et plus globalement l’économie
mondiale, a permis de mettre en exergue la non-adéquation du Bâle II aux situations extrêmes.
Sous l’impulsion du G20 de Pittsburgh, l'instance de gouvernance du Comité de Bâle - le Groupe des
gouverneurs de banque centrale et des responsables du contrôle bancaire - a convenu du dispositif général de
16
Convergence internationale de la mesure et des normes de fonds propres, juin 2006, page 2
Page 14
Première Partie
Bâle III en septembre 2009 et le Comité a énoncé des propositions concrètes en décembre 2009. Les
documents consultatifs correspondants sont le fondement de la réponse du comité à la crise financière et font
partie des initiatives mondiales visant à renforcer le système réglementaire financier. Le groupe des gouverneurs
de banque centrale et des responsables du contrôle bancaire a ensuite convenu des principales caractéristiques
du nouveau dispositif, à sa réunion de juillet 2010, et du calibrage et de la transition pour la mise en œuvre des
mesures, à sa réunion de septembre 201017.
Pour la Tunisie, Bâle I est toujours d’actualité, une réforme est attendue pour l’adoption de Bâle II ou Bâle III. La
BCT n’a pas encore annoncé cette adoption, toutefois elle a commencé à introduire à travers la circulaire 200619 sur le contrôle interne de nouvelles mesures facilitant ainsi la transition vers les nouveaux dispositifs.
1.2.3. Lutte anti-blanchiment d’argent (Anti-money laundering : AML)
La loi n° 2003-75 du 10 décembre 2003, relative au soutien des efforts internationaux de lutte contre le
terrorisme et à la répression du blanchiment d'argent et les textes d’application 18 ont mis à la charge des
établissements de crédit un certain nombre d’obligation pour la contribution dans les activités de lutte contre le
blanchiment d’argent. Parmi ces obligations, on cite :
 L’obligation de vigilance

Obligation de vérification de l’identité des clients lors de l’entrée en relation. Les vérifications consistent à
s’assurer de l’identité du client, de l’authenticité des documents présentés et de leur cohérence.

Obligation de vérification de l’identité des clients occasionnels en cas d’un versement espèce d’une valeur
égale ou supérieurs à dix mille dinars ou en cas de réalisation d’une opération en devise égale ou
supérieure à la contre-valeur de cinq mille dinars.

Autorisation de la Direction Générale ou une structure mandatée lors de l’entrée en relation avec les clients
avec risque élevé : personnes occupant des postes politiques, activités générant des volumes d’espèces
importants : casinos, bureaux de change, pierres précieuses,…

Obligation de vérification de l’identité des correspondants transfrontaliers : vérification de l’existence
physique, réputations, obtention autorisation de la Direction Générale,…
 Détermination des risques AML (Profiling)
Le risque AML (risque de blanchiment) est le risque d’utilisation des comptes et des moyens de paiement mis à
la disposition de la clientèle à des fins de blanchiment. Ce risque doit être apprécié pour chaque client en
fonction de la nature de l’activité et des besoins, de la situation des revenus et du patrimoine et du volume des
http://www.bis.org/bcbs/basel3_fr.htm
Décret n° 2004-1865 du 11 Août 2004 ; Arrêté du Ministre des Finances du 10 Septembre 2004 ; Décisions de la commission
tunisienne des analyses financières (CTAF) N° 1 & 2 du 20 Avril 2006
Page 15
17
18
Première Partie
transactions et des opérations. Le niveau du risque varie entre risque élevé, risque moyen et risque faible. En
fonction du niveau du risque, la banque assure une vigilance particulière qui est accrue pour les risques élevés,
renforcée pour les risques moyens et suffisante pour les autres catégories de risques.
 Obligation de suivi des comptes et mouvements transactionnels (monitoring)
Les banques ont l’obligation d’assurer le suivi minutieux des mouvements des comptes et leur rapprochement à
la tendance transactionnelle habituelle en tenant compte du niveau de risque dégagé par client. En cas
d’opération anormalement élevée, elle sera considérée inhabituelle justifiant les investigations et analyses
renforcées.
 Obligation de déclaration des opérations suspectes (Déclaration de soupçon)
Les opérations suspectes détectées feront l’objet d’une déclaration auprès de la commission tunisienne des
analyses financières (CTAF). Une opération suspecte est toute opération financière incompatible avec la nature
du compte ou de l’activité ou qui présente un caractère complexe laissant présumer que les fonds s’y rattachant
sont d’origine illicite ou que le but recherché est le financement d’une activité ou d’une organisation terroriste.
1.2.4. Conformité avec les normes IFRS
Selon un rapport établi par la banque mondiale en octobre 2006 sur le respect des normes et codes : « Même si
les changements dans les pratiques comptables tunisiennes peuvent être considérés comme un pas important
vers l’harmonisation avec les IFRS, certaines différences fondamentales subsistent et les normes comptables
tunisiennes ne fournissent pas au grand public suffisamment d’informations sur les entreprises d’intérêt public ».
Ce rapport a indiqué les principales différences avec les normes internationales IFRS ainsi que les
recommandations de nature à accroître la qualité de l’information financière.
La méthode de calcul de provisions des créances douteuses constitue la principale différence pour les
établissements de crédit entre les normes internationales et les normes locales. En effet, ces provisions sont
aujourd’hui calculées conformément à la circulaire de la BCT N°91-24 qui prévoit une classification des actifs
selon des critères qualitatifs et quantitatifs ainsi que des taux de provisionnement pour chaque classe d’actifs
après déduction des garanties admises. Cette approche est différente de la méthode prévue par la norme IAS
39. Selon cette dernière, le montant de la perte doit être calculé par différence entre la valeur comptable de l’actif
et la valeur actualisée des flux de trésorerie futurs attendus, déterminée au taux d’intérêt effectif de l’instrument
financier à l’origine. Le calcul des provisions par application des règles IFRS peut fournir un résultat qui diffère
sensiblement de celui donné par l’application de la Circulaire 91-24.
Les autres différences concernent l’impôt différé (IAS12), les règles de prise en compte et d’évaluation des actifs
et passifs financiers (IAS39), les avantages au personnel (IAS19 et IFRS2),…
Page 16
Première Partie
L’adoption des normes internationales en Tunisie est désormais prévue pour la fin de 2014. Des réflexions sont
en cours au sein du conseil national de la comptabilité sur les scenarii de cette convergence vers les normes
IFRS.
2. Examen des systèmes d’information actuels
Après la présentation des différents systèmes d’information déployés actuellement dans les banques tunisiennes
(2.1), on procèdera à un examen critique de ces systèmes et on dégagera les insuffisances et les risques qui
leur sont associés (2.2).
2.1.
Présentation et genèse des systèmes actuels
Aujourd’hui les systèmes d’information opérationnels dans les banques tunisiennes sont de deux types :
2.1.1. Les systèmes non urbanisés appelés par certains « patchworks applicatifs »19
Ces systèmes sont le résultat de l’empilement des strates historiques d’informatisation successives et qui ont été
conçues en l’absence d’une vision globale d’architecture du système. Il en résulte des blocs applicatifs
hétérogènes utilisant des outils de développement et des bases de données différentes. La plupart de ces
applications sont développées en interne par les services de développement des banques. Ces systèmes sont
construits autour de systèmes périphériques utilisés au niveau des agences et des services centraux et un
système central. Ces systèmes peuvent être schématisés comme suit :
Agences
Agence1
Agence n
Services centraux
Salle des
marchés
Opérations
internationales
Portefeuille
Compensation
Monétique
Ressources
Humaines
Achats et
logistiques
Site Central
Interpréteur comptable (pour les applications périphériques qui ne
génèrent pas de lots comptables)
Consolidation des journées et lots comptables
Génération des balances et des mouvements comptables
Edition des relevés des comptes clients
Calcul d'arrêté et édition des échelles d'intérêts
19
Jean-Luc Deixonne, « Piloter un projet ERP », DUNOD, 2006, page 29
Page 17
Première Partie
Lot comptable ou CRE (compte rendu d’évènement) ;
Lot comptable ou CRE qui seront interprétés par les applications des agences pour impacter les comptes
clients: intérêts et commissions suite calcul d’arrêté, virement reçus de la compensation, sort des chèques ou
effets interbancaires ou inter-agence, tombée d’échéances de crédit,…
Flux d’information à destination des applications centrales : lot de remise chèque, lot des ordres de
virements, déblocages de crédits,…
Cette architecture est utilisée par la plupart des banques de la place, on cite à titre indicatif 20 : la Société
Tunisienne des Banques (STB), la Banque Nationale Agricole (BNA), la Banque de l’Habitat (BH), la Banque de
Tunisie (BT), la Banque Internationale Arabe de Tunisie (BIAT), l’Amen Bank.
Ces systèmes actuellement en place dans la majorité des banques sont le résultat de plusieurs évolutions qu’a
connu l’informatique dans les banques. Bien entendu ces évolutions sont étroitement liées à l’évolution de
l’informatique de gestion en général. Les principales phases de cette évolution sont 21:

La phase manuelle (avant les années 80) : dans cette phase, le taux de bancarisation et le volume des
opérations étaient très faibles. Chaque client dispose d’une fiche qui enregistre les transactions passées sur
son compte. Les flux entre agences et services centraux sont réalisés à travers des pièces de liaison
manuelle. Les différentes journées comptables sont centralisées au niveau du siège pour contrôle et
préparation des situations comptables consolidées.

La phase de l’ordinateur central (Mainframe) : au début des années 80 les banques se sont équipées de
systèmes centraux (Exemple : IBM 370) qui permettent la saisie des journées comptables des agences et
des services centraux et d’éditer les situations comptables et les relevés clients. La saisie s’effectue au
niveau central après la collecte des journées des agences et des services. Les programmes sont écrits
dans cette époque sur des cartes perforées. La lecture de ces cartes par l’ordinateur central permettra
l’exécution d’une tâche ou d’une action. Cette phase est caractérisée également par la capacité limitée de la
mémoire des disques. La phase de l’ordinateur central a connu plusieurs évolutions par la suite. Ces
évolutions concernent essentiellement :
-
Les langages de développement : Vers les fins des années 80, le COBOL est devenue le langage
de programmation le plus appliqué et les cartes perforées ont été abandonnées progressivement.
-
Les capacités de stockage sont devenues plus importantes avec l’apparition de nouveaux disques
plus puissants.
Emna KHAROUF & Gérard MAILLET, « La Tunisie face au défi de la modernisation du secteur bancaire »,
www.webmanagercenter.com - 26/02/2007
21 Les informations concernant l’évolution des systèmes d’information des banques ont été recueillies suite à des entretiens avec des
responsables informatiques d’une banque locale.
Page 18
20
Première Partie
Cette phase se caractérise par la vocation comptable du système d’information. Cette vocation a été maintenue
pour plusieurs années.

La fin des années 80 a été caractérisée par la généralisation des ordinateurs dans les agences et les
services centraux et l’apparition de nouvelles applications de gestion ; les premières applications
concernent essentiellement la paie et les opérations de caisse. Dans une première étape, ces nouvelles
applications n’étaient pas intégrées avec la comptabilité. La comptabilité continue à être générée dans le
système central après la saisie des journées et des pièces comptables. Dans une deuxième étape, des
interpréteurs comptables ont vu le jour permettant d’interpréter les évènements de gestion en écritures
comptables. Ainsi, les opérations bancaires couvertes par des applications de gestion, génèrent des flux
d’informations (CRE) permettant leur comptabilisation automatique. L’intégration de cette comptabilité dans
le système central se fait d’une manière manuelle, cette situation s’est améliorée progressivement par
l’apparition des nouvelles technologies de réseau vers la fin des années 90. Ces évolutions aussi bien dans
les langages de programmation et les technologies de communication ont permis d’informatiser les
différentes activités de la banque et de créer des liens automatisés entre ces différentes activités.
2.1.2. Les systèmes constitués autour d’un « Global Banking » :
Certaines banques de la place ont opté pour le changement de leur système d’information vers des solutions
intégrées de « Global Banking ». Les principales banques qui utilisent ces systèmes sont22 :

Attijari Bank : DELTA Bank (2009).

L’Union Internationale des Banques (UIB) : DELTA Bank (2007).

l’Arab Tunisian Bank (ATB) : Equation (2006).

Al Baraka Bank Tunisie (Ex- Best Bank) : Temenos (2003).

l’Arab Banking Coroporation (ABC) : Temenos (2003).

Banque Zitouna : Temenos (2010).
D’autres banques ont engagé des actions pour faire évoluer leur système vers un « Global Banking » :

La Banque Internationale Arabe de Tunisie (BIAT) : le projet d’implémentation du système Temenos (T24)
est en cours depuis 2009.

La Banque Tuniso-Libyenne (BTL) : le projet d’implémentation du système « Carthago » (depuis 2007).

La banque Tuniso-Koweitienne (BTK) : le projet d’implémentation du système « Idee » (depuis 2008).
Les banques optant pour un système de « Global Banking » dispose d’autres applications pour la gestion de
certaines activités spécifiques. Il s’agit essentiellement de la paie, les achats, la monétique,…
Page 19
22
Première Partie
2.2.
Insuffisances et lacunes des systèmes en place
Les évolutions qu’a connu le système financier et bancaire et les avantages que peuvent procurer les nouvelles
technologies d’information et de communication ont fait ressentir les banques de plus en plus les insuffisances et
les limites des systèmes dont elles disposent (2.2.1) et leur impact négatif sur les activités bancaires (2.2.2).
2.2.1. Les limites des systèmes non urbanisés
L’architecture et l’infrastructure technique des systèmes non urbanisés présentent les limites suivantes :

Faible intégration des différents blocs applicatifs : les flux et les échanges de fichiers entre applications et le
système central sont importants et complexes.

Duplication importante des données sur les opérations et sur les clients : Il existe plusieurs bases de
données pour les mêmes informations : référentiel client, informations crédits, soldes des comptes, …

Redondance des traitements : la comptabilité est générée au niveau de plusieurs systèmes: agences,
départements, site central…

Forte hétérogénéité en termes de systèmes d’exploitation, base de données et les langages et
environnements de développement.

Absence d’informations en temps réel notamment des informations sur les clients et leurs dépôts et
engagements.

Couverture fonctionnelle limitée : certains processus restent manuels dans les systèmes non intégrés :
retrait ou versement déplacé, gestion de la réservation des agios,…

Importance des coûts des ressources de développement et de maintenance des applications.
2.2.2. Impacts des insuffisances des systèmes non urbanisés sur l’activité des banques
Les insuffisances que présentent les systèmes non urbanisés ont des impacts négatifs sur les activités bancaires
aussi bien sur le plan opérationnel que sur le plan commercial.
2.2.2.1. Impacts opérationnels
 Importance des comptes de liaison et des comptes d’ordre
Toutes les banques de la place souffrent de l’importance des comptes d’ordre et des comptes de liaison non
justifiés. Ce point fait toujours l’objet de réserves par les commissaires aux comptes des établissements de
crédit. Les provisions pour passifs constituées sur les risques que peuvent inclure ces comptes impactent
lourdement le résultat et les capitaux propres des banques. Dans un système non urbanisé, le même processus
peut faire intervenir plusieurs applications à la fois ce qui nécessite dans la plupart du temps le recours à des
Page 20
Première Partie
comptes d’ordre ou des comptes de liaison. Ces comptes ne sont pas apurés au jour le jour essentiellement pour
des problèmes d’interfaçage et d’échanges de flux. Bien entendu cette situation a obligé les banques de mettre à
disposition des ressources pour le contrôle de ces comptes et l’apurement des anciens suspens.
 Problèmes dans l’intégration des journées comptables
Le souci quotidien de l’équipe d’exploitation informatique est la collecte des journées comptables des différentes
agences et départements pour leur intégration dans le système central. Ce processus présente toujours des
défaillances et des risques pour les banques notamment dans le cas des insuffisances des contrôles mis en
place. Il est possible que l’intégration ne soit pas effectuée ou qu’elle soit effectuée doublement ou qu’elle ait été
effectuée partiellement (journée tronquée). Les problèmes d’intégration ont des impacts importants sur la fiabilité
des comptes.
 Ecarts entre les différentes sources d’information
Dans les systèmes non urbanisés, il est possible que les mêmes informations soient dupliquées sur plusieurs
systèmes et que ces différentes sources présentent des différences importantes dues essentiellement aux
problèmes d’échanges de flux. Il s’agit essentiellement des données sur les soldes des comptes clients (système
agence et système central) et des encours de crédit (système agence et système du portefeuille central). La
situation est compliquée d’avantage notamment lorsque ces différentes sources ne sont pas conformes aux
soldes comptables.
 Non respect de l’obligation de tenue d’une comptabilité multi-devise
Rarement sont les systèmes non urbanisés qui assurent une comptabilité multi-devises. En effet, la tenue d’une
comptabilité multi-devises est devenue obligatoire suite à la promulgation des normes comptables sectorielles
applicables aux établissements de crédit et particulièrement la norme comptable 23 relative aux opérations en
devise dans les établissements de crédit dont la date d’application était prévue pour 1999. Certaines banques
n’ont pas réussi à ce jour de mettre à niveau leurs systèmes et applications pour respecter cette obligation qui
nécessite des changements lourds à plus d’un niveau : système agence, système central, système international
et système de trésorerie. Cette situation est à l’origine des problèmes de plusieurs banques dans les comptes en
devise et qui font l’objet de réserves des commissaires aux comptes.
 Complexité des processus
Les systèmes non intégrés sont caractérisés par la complexité des processus et la multiplicité des intervenants
et des applications pour la gestion d’un même processus. Par exemple, l’opération d’un virement inter-agence
nécessite l’intervention d’une structure centrale qui permet de collecter les ordres de virement des agences des
Page 21
Première Partie
donneurs d’ordre puis l’exécution du virement chez les agences bénéficiaires. La réalisation de cette opération
aura lieu dans au moins deux jours avec tous les risques possibles dans les échanges des flux entre l’agence du
donneur d’ordre, le service central et l’agence du bénéficiaire. Ces risques et retards dans l’exécution n’existent
plus avec un système intégré.
 Non-conformité à la règlementation et les standards internationaux
Les systèmes non urbanisés ne sont pas riches d’informations sur les clients, dossiers et opérations du fait qu’ils
ont été construits initialement avec une logique purement comptable. Ce manque d’informations ne permet pas
aux banques de se conformer aux exigences internationales applicables aux activités bancaires : les normes
IFRS, Bâle II et Lutte anti-blanchiment (AML),…
A titre d’exemple, les obligations incombant aux banques en termes de lutte anti-blanchiment ne sont pas
possibles si la banque ne dispose pas d’une gestion d’un référentiel client et de la possibilité d’introduire les
blacklist dans leur système pour contrôle au moment de l’entrée en relation.
 Erreurs fréquentes nécessitant des travaux de contrôle et des interventions manuelles
Les risques d’erreurs sont importants et multiples dans les systèmes non intégrés. Ces risques proviennent
particulièrement des échanges de flux et des retards d’intégration et d’interfaçage. Par exemple, le retard de
l’injection du ficher des rejets de chèques reçus de la compensation donne lieu à des crédits systématiques des
comptes clients alors que les chèques ne sont pas réellement réglés. Ces risques métiers ont amené les
banques à doter les structures de back office de ressources importantes pour veiller à identifier les problèmes et
les incidents et opérer les régularisations en temps utile. Ces systèmes de contrôle seront toujours insuffisants
pour identifier et régler toutes les problématiques. Il est possible aussi que les solutions apportées aux
problèmes identifiées ne soient pas bonnes et exactes et ne font qu’aggraver la situation.
2.2.2.2. Impacts commerciaux
 Mauvaise qualité de service
En raison de la complexité des processus et l’intervention de plusieurs acteurs et applications, les systèmes non
intégrés accusent des retards considérables dans l’exécution de certaines opérations notamment les opérations
inter-agence (virement inter-agence, retrait-déplacé,…).
De même, ces systèmes et architectures sont à l’origine des erreurs fréquentes qui peuvent impacter les
comptes clients : intégration double de lots, oubli d’intégration de lots, non-conformité entre l’extrait de compte
édité à partir de l’application agence et le relevé de compte édité à partir du système central,…
Page 22
Première Partie
Ces retards et erreurs ont un impact considérable sur la qualité des services et l’image de marque des banques
et en conséquence les parts de marché de la banque.
 Indisponibilité des informations en temps réel et son impact sur la prise de décision
Du fait du manque de l’intégration des applications et l’exécution des travaux d’intégration en fin de journée, les
informations ne sont pas toujours disponibles en temps réel notamment les opérations sur les comptes clients.
Par exemple, la décision du chef d’agence peut être impactée pour forcer ou rejeter le règlement d’un impayé ou
d’un chèque reçu de la compensation s’il dispose de l’information sur les opérations de virements ou versements
réalisées dans d’autres agences ou des opérations d’achat ou de retraits monétiques qui ne sont pas encore
comptabilisées. La disponibilité de l’information en temps réel est importante dans l’activité bancaire et elle peut
influer largement les décisions des gestionnaires.
 Contraintes pour le lancement de nouveaux produits et services
Les systèmes actuels présentent des limites et des contraintes pour le lancement et la gestion des nouveaux
produits et services permettant à la banque d’accroître ses parts de marché. Ainsi par exemple, il est difficile de
lancer un package incluant un ensemble de produits et services avec des tarifs bien déterminés du fait que ces
produits et services sont gérés sur plus d’une application : le calcul d’arrêté des comptes sur un système, les
cartes de paiement sur un deuxième système et les crédits sur un troisième système,…
 Impossibilité ou contraintes dans la segmentation de la clientèle
Aujourd’hui les banques sont dans l’obligation d’adapter et personnaliser leurs offres aux besoins spécifiques de
chaque segment de clientèle. Cette segmentation nécessite la disponibilité d’une base de données fiable et riche
en informations sur les clients et leurs mouvements et un système capable de classer les clients selon des
critères prédéfinis dans un segment donné. Ces conditions ne sont pas facilement accessibles dans des
systèmes non intégrés construits autour d’une logique comptable ignorant toute politique commerciale.
 Absence d’un outil CRM (Customer Relationship Management)
Les systèmes de gestion des relations clients (CRM) sont devenus indispensables dans l’exercice de toute
activité commerciale et particulièrement l’activité bancaire. Ces systèmes permettent aux gestionnaires des
banques de définir la stratégie commerciale vis-à-vis des clients en termes d’équipement en produits et services.
Avec un système non intégré, les informations nécessaires pour assurer les objectifs de la CRM sont
inexistantes ou insuffisantes et elles sont dispersées sur plusieurs applications. Il est difficile donc de mettre en
place ce type de système dans un environnement pareil.
Page 23
Première Partie
Paragraphe 2 : Apports des ERP
Les solutions dites « Global Banking » appartiennent à la famille des ERP avec une spécialisation dans le métier
bancaire. Après avoir défini ces concepts et leur historique et évolution (1), on essayera de dresser les
avantages que procurera ce type de solution (2) mais également les risques qui leurs sont associés (3).
1. Définitions, historique et transition vers la gestion par ERP
1.1. Evolution de l’informatique de gestion et naissance des ERP 23
L’informatique de gestion a subi des bouleversements considérables durant les trente dernières années. Les
avancées technologiques dans le domaine de l’électronique et des télécommunications ont rendu possible ces
évolutions capitales. On présentera les principales caractéristiques de chaque phase :

Dans les années 60 et 70, le rôle de l’informatique de gestion est limitée à stocker des volumes importants
de données, à les trier, les traiter puis les restituer sous une forme plus condensée et plus intelligible. Ce
rôle étant assuré par des machines puissantes appelées « Mainframes ». Cette époque représente l’époque
de l’informatique lourde, les investissements en matériel sont très élevés. Le rôle des utilisateurs consiste
uniquement à collecter les données et les saisir, l’accès à la machine par les utilisateurs est inexistant.

Les années 80 voient l’arrivée de machines qui se rapprochent progressivement vers les utilisateurs. Les
mini-ordinateurs donnent une dimension « départementale » de l’outil informatique. Le rapprochement des
rôles est clair : les mini-ordinateurs s’intéressent aux besoins opérationnels des départements ou des
divisions ; le « Mainframe » s’intéresse à la consolidation des données au niveau de l’entreprise.

Les années 90 sont caractérisées par le déploiement de l’informatique individuelle et l’émergence de
l’informatique du groupe. En effet, les micro-ordinateurs et les outils bureautiques ont donné naissance à
l’informatique individuelle qui s’ajoute aux deux autres niveaux : l’informatique départementale (miniordinateur) et l’informatique de l’entreprise (Mainframe). Par ailleurs, l’explosion des réseaux et des
télécommunications a permis de renverser la verticalité des trois niveaux précédents vers une architecture
horizontale permettant une meilleure intégration des composantes du système d’information. Toutefois,
cette intégration ne s’est pas effectuée de façon homogène. En effet, les applications de base qui sont
installées dans les différents départements ne permettent pas de partager un langage commun :
applications hétérogènes ne permettant pas une communication entre elles et rendent difficile la circulation
fluide d’informations. Les techniques d’interfaçages pallient pour partie cette désintégration des systèmes.
Pour partie uniquement, car la qualité et la cohérence des informations transmises entre les domaines de
l’entreprise reste très pauvre, parfois incohérente et toujours disponibles avec retard.
23
Jean-Louis TOMAS, « ERP et PGI sélection, méthodologie de déploiement et gestion du changement », DUNOD, 2007, page 3
Page 24
Première Partie
Le besoin d’une informatique globale, intégrant tous les composants de l’entreprise s’est fait de plus en plus
sentir. Cette volonté d’évolution vers plus d’intégration des applications spécifiques de chaque département, plus
de partage de données entre les utilisateurs et plus d’informations disponibles constitue l’un des facteurs
essentiels qui explique le succès grandissant des ERP auprès des entreprises.
1.2. Définitions et caractéristiques des ERP
L’ERP est l’abréviation du terme anglais « Entreprise Resource Planning » qui se traduit textuellement en
français par « Planification des ressources de l’entreprise ». Cette traduction textuelle n’a pas été retenue en
français, la traduction recommandée étant PGI ou Progiciel de Gestion Intégrée24. En pratique, différentes
appellations sont utilisées pour parler du même concept : progiciel, progiciel intégré, progiciel applicatif intégré,
progiciel de gestion, progiciel de gestion intégrée (PGI) et « Entreprise resource planning » (ERP).
Selon le grand dictionnaire terminologique, un ERP est «un logiciel qui permet de gérer l'ensemble des
processus opérationnels d'une entreprise, en intégrant l'ensemble des fonctions de cette dernière comme la
gestion des ressources humaines, la gestion comptable, financière, mais aussi la vente, la distribution,
l'approvisionnement, le commerce électronique. ».
Tel que défini par Robert Reix25 « un PGI est une application informatique paramétrable, modulaire et intégrée
qui vise à fédérer et optimiser les processus de gestion de l’entreprise en proposant un référentiel unique pour
toute l’entreprise et en s’appuyant sur des règles de gestion standards ». En s’appuyant sur cette définition,
les ERP présentent les caractéristiques suivantes :

Un ERP est paramétrable : produit standardisé par excellence, l’ERP est conçu à l’origine pour satisfaire
les besoins d’entreprises diverses. Ils existent généralement des versions différentes par secteurs d’activité
(automobile, textile, banque, etc…) et par langue d’utilisation. L’adaptation du produit aux besoins d’une
entreprise donnée se fait par paramétrage.

Un ERP est modulaire : c’est un ensemble de programmes ou modules séparables correspondant chacun
à un processus de gestion dont l’installation peut être effectuée d’une manière autonome.

Un ERP est intégré : les divers modules ne sont pas conçus de manière indépendante : ils peuvent
échanger des informations selon des schémas prévus. L’ERP garantit à tout instant une intégrité et une
cohérence parfaite des données pour tous les utilisateurs.

Un ERP s’appuie sur un référentiel unique : toutes les données ou les objets utilisés par les différents
modules sont définis d’une manière standardisée et unique et gérés par un seul type de langage de
Traduction recommandé en France par la DGLFLF : Délégation générale à la langue française et aux langues de France et au
Canada par l'OQLF : Office québécois de la langue française. http://fr.wikipedia.org/wiki/Progiciel_de_gestion_intégré
25 Robert Reix, « Systèmes d’information et management des organisations », Edition Vuibert, 2002
Page 25
24
Première Partie
développement et de base de données. De même les interfaces homme-machine sont définies de façon
identique pour tous les modules.

Un ERP vise à optimiser les processus de gestion : lors de la construction du progiciel, le concepteur
s’appuie sur des modèles de processus issues des « meilleures pratiques » du secteur.
La notion de « Global Banking » est issue du concept de la banque universelle qui correspond à la banque qui
offre tous les services bancaires à l’ensemble des clients. En Tunisie, ce concept a été généralisé par la loi
2001-65 qui a uniformisé les métiers des établissements de crédit. Les solutions « Global Banking » sont les
ERP ou progiciels spécialisés dans le métier bancaire. Ces solutions permettent de gérer l’ensemble des
activités et processus d’une banque universelle.
2. Bénéfices attendus par les banques de l’implantation d’un ERP
On présentera dans un premier temps les avantages des ERP comme solution de gestion pour les entreprises
(2.1). Par la suite, on exposera les avantages spécifiques pour les banques (2.2).
2.1. Avantages des ERP :
 Obtenir des informations fiables et pertinentes à un moindre coût
L’intégration fonctionnelle permet d’automatiser et consolider la production d’informations en assurant la fiabilité,
la cohérence et la pertinence. Elle permet de supprimer toutes les activités manuelles de recherche,
rapprochement, consolidation des informations (rapprochement entre bon de commande et facture,…).
 Recentrage sur le métier de base
Les entreprises optent aujourd’hui pour une stratégie de concentration sur le métier de base et abandon de
toutes les activités qui sont en dehors de ce périmètre. La mise en place d’un système ERP permet aux
entreprises d’abandonner les travaux de développements et de maintenance des applications informatiques
réalisées en interne et de se concentrer sur l’activité principale.
 Optimiser les coûts informatiques
L’installation d’un ERP va conduire, de part l’harmonisation des applications informatiques autour d’une même
technologie, à optimiser le coût de maintenance du système d’information.
 Supprimer les dysfonctionnements et la non-qualité
L’installation d’un ERP permet de supprimer les situations à la cause de dysfonctionnements ou de non qualité :
retard dans la génération d’un extrait incluant les opérations de la journée, risque d’injection de lots double,…
Page 26
Première Partie
 Introduire de nouvelles fonctionnalités
Les projets ERP sont toujours accompagnés par l’introduction de nouvelles fonctionnalités soit en automatisant
une fonctionnalité qui était manuelle dans l’ancien système (élaboration des reportings,…) soit en ajoutant de
nouvelles fonctionnalités (CRM, référentiel client centralisé,...).
 Maitriser de bout en bout les processus
Lorsque les fonctions de base de l’entreprise sont correctement assurées par l’ERP, ceci permet à l’entreprise de
mieux maîtriser et optimiser l’ensemble des activités d’un processus en réduisant les risques et les coûts et en
améliorant la qualité de service.
 Disposer d’un avantage concurrentiel
Les ERP permettent aux entreprises d’avoir un système d’information flexible et capable de répondre aux
nouveaux besoins des clients et leur offrir des produits et service de qualité dans des délais raisonnables.
 Harmoniser les pratiques de travail et instaurer un standard d’entreprise
Les ERP permettent la standardisation et l’harmonisation des méthodes de travail dans les entreprises : utiliser
un référentiel unique, utiliser les mêmes outils,…
2.2. Avantages spécifiques pour les banques
 Disposer d’un système en temps réel
La disponibilité d’une information en temps réel revêt une importance particulière dans le domaine bancaire. Il
s’agit principalement des informations sur les soldes des comptes clients : un chef d’agence peut forcer le
règlement d’un chèque reçu de la compensation lorsqu’il dispose de l’information d’un versement espèces
réalisé dans une autre agence.
 Avoir une visibilité client unifiée
Avec un système décentralisé et constitué par plusieurs blocs applicatifs, il n’est pas possible d’avoir une
visibilité claire et fiable sur les clients de la banque et leur situation et leur équipement en produits et services.
Ceci sera possible dans une architecture centralisée permise par les ERP.
 Un référentiel unique pour la majorité des activités et métiers de la banque
Une solution intégrée permet de gérer des référentiels uniques et harmonisés : référentiel client, référentiel des
produits et services, référentiel des utilisateurs et habilitations, référentiel des conditions, tarifs, cours,…
Ces référentiels permettent d’alimenter les divers modules de la solution.
Page 27
Première Partie
 Une amélioration de la fiabilité des traitements
La réduction du nombre des interfaces et des flux entre les modules et les applications permet d’assurer une
meilleure fiabilité des traitements et réduit le recours aux comptes d’ordre et de suspens.
 Une information de pilotage accessible et exploitable
Les solutions ERP sont riches en restitutions et états de sortie. Ces situations permettent un meilleur pilotage de
l’activité de la banque. De même l’alimentation d’une solution de « Data Warehouse » sera plus simple dans un
contexte d’ERP.
 Création et lancement rapide de produits et services
Les solutions ERP sont plus souples pour la création et la mise en place de nouveaux produits et services
adaptés aux besoins et attentes de la clientèle et procurant un avantage comparatif par rapport à la concurrence.
 Un accès aux canaux de distribution modernes
Les solutions ERP permettent aux banques de mettre à la disposition de ses clients tous les canaux de
communication possible : Web Banking, SMS, serveur vocal,…
 Une meilleure célérité des opérations et des processus
L’architecture intégrée et centralisée offerte par une solution ERP permet d’optimiser le temps de traitement de
certains processus notamment les opérations inter-agence.
 Une meilleure gestion des risques
Les solutions ERP sont conçues selon les bonnes pratiques du métier bancaire. Ainsi ces solutions offrent une
meilleure gestion des risques de l’activité bancaire :

Risque opérationnel : les solutions ERP sont riches par des contrôles système réduisant les risques
d’erreurs humaines et techniques.

Risque de crédit : les solutions ERP intègre des systèmes de « workflow » assurant une meilleure
instruction des dossiers de crédit. Elles incluent également des systèmes de gestion des limites et
autorisations ainsi que des systèmes d’évaluation du portefeuille engagement de la banque.

Risque de marché : les solutions ERP permettent à travers des systèmes de limites et de mesure qu’elles
offrent de mieux gérer les risques de marché : risque de change, risque de taux et le risque de liquidité.
 Une conformité aux règlementations
Les systèmes ERP sont multi-référentiels et incluent des fonctionnalités permettant de se conformer aux
principales exigences internationales applicables aux activités bancaires : les normes IFRS, Bâle II et Lutte antiblanchiment (AML),…
Page 28
Première Partie
3. Risques associés aux ERP
« Aussi importants que soient les bénéfices potentiels associés aux projets d’implantation de progiciels, autant
un échec peut avoir des impacts négatifs »26. Quatre principaux résultats indésirables sont potentiellement
associés à un projet d’implantation d’un ERP : la mauvaise qualité du système (3.1), le dépassement du budget
(3.2), le dépassement de l’échéancier (3.3) et l’insatisfaction des utilisateurs (3.4).
3.1. La mauvaise qualité du système
La mauvaise qualité du système constitue un des principaux résultats indésirables de ce type de projet. Dans la
littérature, les énoncés ayant trait à la mauvaise qualité du système proviennent de divers points de vue.
Certains auteurs l’abordent sous la perspective des fonctions soit la fiabilité : non satisfaction des besoins
fonctionnels, erreurs de traitements,….et d’autres, sous l’optique des problèmes d’ordre technique, soit
l’efficacité : incapacité d’éviter les goulots d’étranglement, processus informatique lourds,…
La mauvaise qualité du système d’information implanté peut avoir plusieurs impacts sur l’organisation : impacts
financiers lourds, incapacité de réaliser des opérations, dégradation de la qualité de service,…
3.2. Le dépassement du budget
Le dépassement du budget correspond au fait que le projet a consommé d’avantage de ressources que la
quantité qui était initialement prévue. Il peut arriver qu’un projet dépasse le budget de manière importante qu’une
décision d’abandonner le projet soit prise.
Le dépassement du budget est un résultat indésirable que mentionnent plusieurs écrits de la littérature
d’implantation d’ERP. Cette constatation concorde avec les résultats d’enquêtes réalisées dans ce domaine.
Selon Cosgrove Ware (2001), la moyenne des dépassements de budget représenterait 38 % des montants
initialement prévus.
3.3. Dépassement de l’échéancier
Le dépassement de l’échéancier correspond du fait que l’implantation de la solution a eu une durée plus
importante que ce qui était initialement prévu. Le non respect de l’échéancier peut avoir des impacts importants,
surtout en présence de dates butoirs (date pour se conformer à une exigence règlementaire)
Selon une enquête du Standish Group, près de 90 % des projets d’implantation d’ ERP des sociétés consultées
ne respecteraient pas l’échéancier prévu. Le non respect de l’échéancier et le dépassement du budget sont
fortement corrélés.
Jean-Grégoire Bernard, Suzanne Rivard et Benoit A. Aubert, « Evaluation de risque d’implantation de progiciel», Rapport CIRANO
(centre universitaire de recherche en analyse des organisations) Septembre 2002
Page 29
26
Première Partie
3.4. Insatisfaction des utilisateurs
L’insatisfaction des utilisateurs a deux dimensions : insatisfaction à cause du système lui-même ou du processus
d’implantation et insatisfaction à cause des conséquences organisationnelles du nouveau système.
Dans le premier cas, il est probable que le système soit perçu comme étant peu utile, ne présente pas
d’avantages relatifs ou ne convenant pas aux tâches que doivent accomplir les utilisateurs. De même le manque
de participation des utilisateurs dans le processus d’implantation peut aussi être une source d’insatisfaction.
D’un autre côté, les changements importants de l’organisation et des processus engendrés par l’implantation
d’ERP sont sources d’insatisfaction. En effet, les rôles et les responsabilités et les activités composant les
processus sont lourdement impactés par l’implantation.
L’insatisfaction des utilisateurs peut se traduire par une diminution de la productivité. Le phénomène peut
s’aggraver si l’organisation réduit considérablement son effectif suite à la réingénierie de ses processus.
SECTION 2 : COMMENT CHOISIR SON ERP ?
Le choix de la solution est la première étape du projet du changement du système d’information. Le choix de la
nouvelle solution n’est pas une chose facile et il conditionnera lourdement la réussite de l’ensemble du projet.
Dans un premier paragraphe on présentera le marché des « Global Banking » aussi bien à l’échelle nationale
qu’internationale. Au niveau du deuxième paragraphe, on exposera les principaux critères de sélection de la
nouvelle solution ainsi que la démarche pratique pour la sélection.
Paragraphe 1 : Le marché des Global Banking
Des éditeurs tunisiens de « Global Banking » ont vu le jour ces dernières années. On présentera dans un
premier temps les solutions offertes par des éditeurs tunisiens (1) puis dans un deuxième temps les principales
solutions à l’échelle internationale (2).
1. Le marché tunisien
Plusieurs sociétés de services en ingénierie informatique (SSII) tunisienne offrent des solutions de « Global
Banking ». Toutefois, ces sociétés restent sans référence dans les banques tunisiennes : aucune de ces
solutions n’est opérationnelle dans une banque. Certaines solutions ont été retenues dans le cadre d’appels
d’offres lancés par des banques de la place27 ou qui sont en cours d’implémentation. On présentera les
principales informations disponibles sur ces solutions.
27
www.africanmanager.com/articles/11903.html
Page 30
Première Partie
 La solution « Carthago »28

Informations sur l’éditeur
 Editeur : BFI
 Date de création : 1994
 Effectif : 220 personnes
 Capital social : 6,4 millions de dinars tunisiens
 Filiales internationales : Algérie, Maroc et Cameroun

Informations sur la solution
 Couverture fonctionnelle : la solution est organisée autour d’un noyau et de divers modules métiers.
Les modules métiers couvrent les principales activités de la banque : agence, crédit, étranger,
trésorerie, télécompensation,…La couverture fonctionnelle est jugée très satisfaisante.
 Autres caractéristiques : navigation web (technique J2EE), les composantes de la solution sont
autonomes et liées par des interfaces,…
 la solution « UniB@nk » 29

 Editeur : MEDSOFT
 Capital social : 1,5 millions de dinars tunisiens

 Couverture fonctionnelle : la solution est organisée autour d’un noyau et des applications
périphériques. Le noyau est composé du module référentiel, module comptabilité, module business
intelligence, module sécurité, module interface généralisée. Les applications périphériques sont
constituées du module agence, module engagements et le module étranger.
 Autres caractéristiques : navigation web (technique J2EE), les composantes sont autonomes et
interfacées avec l’interface généralisée.
 La solution « IBanK »30

 Editeur : IDEE
www.bfigroupe.com
www.medsoft.com.tn
30 www.idee.com.tn
28
29
Page 31
Première Partie

 Couverture fonctionnelle : selon le site internet de la société, le module couvre tous les métiers de la
banque mais il ne précise pas les modules constituant la solution.
2. Le marché mondial
Le marché mondial des « Global Banking » offre plusieurs solutions. Des classements sont réalisés
périodiquement par des revues ou des sites internet des principales solutions. Selon un classement réalisé en
juillet 201031, la solution « FlexCube » de « Oracle Financial Services Software » est classée à la tête des
solutions. La deuxième place étant réservée à la solution « T24 » de l’éditeur « Temenos ». Cette dernière
solution a été retenue pour plusieurs banques de la place :
Banque Internationale Arabe de Tunisie (BIAT) : les travaux d’implémentation ont démarré en janvier 2009

et les travaux devraient se poursuivre sur une période de deux ans32.

Banque Zitouna : solution opérationnelle depuis le démarrage de la banque en mai 2010.

Al Baraka Bank Tunisie (Ex- Best Bank) : solution opérationnelle depuis quelques années.
Bien qu’elle ne soit pas classée parmi les premières solutions du monde33, une autre solution est en train de
prendre place dans les banques tunisiennes, il s’agit de la solution « Delta Bank » installée et opérationnelle au
niveau de deux banques en Tunisie : l’Union Internationale des Banques (UIB) et Attijari Bank Tunisie. On
présentera les principales caractéristiques de ces trois solutions.
 La solution « T24 »34

 Editeur : Temenos (The Banking Software Company)
 Nationalité : Suisse-siège à Genève
 Effectif : 2900
 Références : 700 clients dans 120 pays

 Couverture fonctionnelle : la solution offre des fonctionnalités pour la banque de détail, banque de
financement et investissement, banque universelle, banque privée, banque islamique et la micro-
www.inntron.com/core_banking.html
http://www.tunisieactualite.com/les-journaux/7-le-t24-de-temenos-sinstalle-a-la-biat-.html
33 classée au 18ème place selon le même classement
34 www.temenos.com
31
32
Page 32
Première Partie
finance. Elle couvre l'ensemble des opérations : CRM, multi-canal, banque en ligne, cash, moyens
de paiement, crédits, dépôts, réglementaire, gestion d'actifs, trade finance, du Front au Back office.
 Autres caractéristiques : Disponibilité (24h/24 et 7j/7), navigation WEB, version française disponible
 La solution « Delta Bank »35

 Editeur : Delta Informatique
 Nationalité : France, siège à Tours
 Effectif : 250
 Référence : 140 banques dans 40 pays (forte présence en Afrique)

 Couverture fonctionnelle : la solution est construite autour d’un noyau central et des modules
périphériques : agence, engagement, international,…
 Autres caractéristiques : uniquement la CRM en navigation WEB, une version française disponible,
système non disponible pendant le traitement de fin de journée(TFJ). Performance
maximale enregistrée : 240 agences et 900 milles clients.
 La solution « Oracle FLEXCUBE »36

 Editeur : Oracle Financial Services Software Limited (Ex i-flex solutions)
 Nationalité : Inde, siège à Mumbai
 Effectif : plus de 10 000
 Référence : 765 banques dans plus de 125 pays

 Couvertures fonctionnelles : la solution couvre l’ensemble des activités des banques notamment
l’activité de trésorerie. La solution CRM n’est pas disponible.
 Autres caractéristiques : version française non disponible, navigation WEB, Disponibilité (24h/24 et
7j/7), Très bonne performance : la solution supporte une banque de plus de 3000 agences avec plus
de 16 millions de clients.
35
36
www.delta-informatique.com
www.oracle.com/us/industries/financial-service
Page 33
Première Partie
Paragraphe 2 : Critères et démarche du choix de l’ERP
Avant de présenter la démarche et le processus de sélection de la nouvelle solution (2), on va présenter les
principaux critères de sélection (1).
1. Critères de sélection
Les critères de sélection du progiciel peuvent être regroupés en cinq grandes familles 37:
1.1. Les critères stratégiques ou « politiques »
La décision du choix de la nouvelle solution peut être influée par les orientations stratégiques définie par les
parties influentes internes et externes à la banque. A titre d’exemples, on cite les situations suivantes :

La société mère peut exiger la solution qui doit être mise en place par la banque. Il s’agit d’un choix
stratégique pour toutes les filiales du groupe.

La banque centrale ou le ministère de tutelle peut exiger de privilégier les éditeurs nationaux ou un éditeur
bien déterminé.

L’existence d’un partenariat avec un éditeur sur d’autres aspects peut être une contrainte pour la banque
pour continuer à traiter avec le même éditeur.
1.2. Les critères fonctionnels
Il s’agit de vérifier que la solution répond aux besoins fonctionnels exigés par les utilisateurs de la banque :

Couverture fonctionnelle : les modules offerts par la solution couvrent les besoins de la banque. La décision
du choix est influée si la solution ne couvre pas un module jugé important : module risque, module
trésorerie, module étranger,…

Les règles de gestion de chaque module fonctionnel sont conformes à la règlementation en vigueur et
répondent aux besoins de la banque.

La solution assure une gestion en temps réel.

La solution permet de paramétrer et éditer les différents reportings.
1.3. Les critères techniques
Parmi les principaux critères techniques nécessaires pour l’évaluation, on cite :
37

L’environnement technique : système d’exploitation, système de gestion de base de données,…

L’environnement matériel : serveurs et postes de travail,…
Page 34
Première Partie

L’ouverture à d’autres applications, à d’autres systèmes d’exploitation ou système de base de données.

Volumétrie et performance : nombre d’utilisateurs, nombre de comptes, temps de réponse à des
transactions standards, temps d’exécution d’un traitement de fin journée,…

Le versionning : gestion des évolutions et des versions.

L’interface homme/machine : graphique, navigation intuitive, ergonomie et convivialité.
1.4. Les critères commerciaux
Il s’agit principalement des critères suivants :

Pérennité de l’éditeur : historique, actionnaires de référence, chiffres d’affaires, effectifs, produits et
services, filiales et représentations…

Principales références de l’éditeur et l’aboutissement des projets.

La mise à disposition de consultants fonctionnels et techniques.

Les services de maintenance et d’assistance.

Les conditions financières.
1.5. Les critères méthodologiques
Il s’agit d’apporter un jugement sur la démarche méthodologique préconisée par l’éditeur pour l’implémentation
de la nouvelle solution :

Démarche conforme aux bonnes pratiques et normes de gestion de projet.

Démarche simple qui peut garantir la réussite du projet ou inversement.

Démarche mise à l’épreuve précédemment et qui a donné ses fruits ou non encore appliquée

Nécessité de faire intervenir d’autres consultants externes pour la mise en place de la solution.
2. Processus illustré de sélection
Le choix d’une solution de type « Global Banking » constitue une opération délicate. Ce choix engage la banque
sur plusieurs années et nécessite des investissements importants aussi bien pour l’acquisition de la solution que
sa mise en place. La réussite de ce choix nécessite la mise en place d’une démarche de sélection rigoureuse
permettant de trouver un produit qui sera en mesure d’accompagner la banque dans la réalisation de ses
objectifs actuels et futurs. Plusieurs modèles de sélection ont été prévus par la littérature 38 et les cabinets
spécialisés39, on présentera ici une approche de sélection qui tiendra compte aussi bien de ces modèles que la
participation opérationnelle dans le choix d’une solution de « Global Banking » pour une banque tunisienne. Le
38
39
Jean-Louis Tomas, ERP & PGI, p117 ; Jean Luc DEIXONNE, Piloter un projet ERP, p194
Le cabinet ALDEA a conçu une méthode de 15 étapes pour la sélection de progiciel : www.aldea.fr
Page 35
Première Partie
processus de sélection inclut les quatre étapes suivantes : spécification des exigences (2.1), rédaction des
cahiers de charge et lancement des appels d’offres (2.2), évaluation des offres et sélection de la solution (2.3) et
conclusion du contrat avec l’éditeur (2.4).
2.1. Spécification des exigences
Ces exigences sont conçues dans le schéma directeur informatique de la banque. Le schéma directeur
informatique fait le point sur le système d’information actuel et propose des plans d’évolution possibles pour ce
dernier en fonction de la stratégie de la banque, des besoins des utilisateurs et des dysfonctionnements du
système actuel. Le schéma directeur informatique est construit autour des trois axes suivants : axe fonctionnel et
applicatif, axe organisation de la Direction système d’information et axe infrastructure technique.
La construction du schéma directeur est un projet à part entière. Ce projet peut être mené par des équipes
internes ou des consultants externes. La construction d’un schéma directeur informatique doit obéir à la
démarche suivante :
2.1.1. Etat des lieux et analyse de l’existant
Il s’agit de présenter l’état des lieux de chaque axe d’analyse :
 Axe fonctionnel :

présenter les principaux processus actuels et les insuffisances et faiblesses majeures dans ces processus ;

présenter les pistes d’amélioration des processus actuels ;

apprécier le degré de couverture du processus par les applications informatiques existantes : couverture
totale, partielle ou processus totalement manuel.
 Axe applicatif :

dessiner l’architecture applicative actuelle et tracer les différents flux entre les applications actuelles,

évaluer la performance technique des applications actuelles : capacité d’intégration, temps de
réponse/exécution, robustesse (fréquence des pannes), maintenance (développements supplémentaires),…

évaluer les performances fonctionnelles des applications actuelles : souplesse, couverture fonctionnelle,
adéquation de l’information (disponibilité des informations dans des formats standards),….
 Axe organisation Direction Système d’Information (DSI) :

organisation actuelle de la DSI et les processus clés de la DSI ;

la cartographie des compétences : maîtrise application métiers, gestion base de données, langages de
programmation, système d’exploitation,…

liste des projets en cours.
Page 36
Première Partie
 Axe infrastructure technique :

serveurs, bases de données, architecteur réseau,…

système de sécurité informatique.
2.1.2. Définition des objectifs et principes directeurs
Les objectifs et les principes directeurs seront définis par les décideurs de la banque :
 Axe fonctionnel et applicatif :

un système temps réel : mise à jour solde client en temps réel, optimisation opérations inter-agences,…

une vision client unifiée : regroupement des clients, vision sur l’exhaustivité de l’équipement client,…

une information de pilotage accessible et exploitable : disponibilité de reportings exhaustifs et fiables,…

une large couverture fonctionnelle : la solution doit comprendre une solution CRM,…

conformité réglementaire de la solution : IFRS, Bâle II, système de compensation,…
 Axe organisation Direction Système d’Information (DSI) :

aligner la DSI cible sur les meilleures pratiques du marché en termes d’organisation et de processus :
- un modèle centre de service : relation client et prestataire et une approche projet généralisée ;
- des relations MOA / MOE normalisées avec des canaux bien définis et des interlocuteurs désignés.

mettre en place une structure répondant aux attentes à la fois des collaborateurs DSI et de la banque :
- pour les collaborateurs : perspectives de carrière (progression, formation),…
- pour la banque : maîtrise du risque opérationnel, capacité à prendre en charge les demandes de
manière réactive et à mener à bien des projets ambitieux.
 Axe infrastructure technique :

dimensionner l’infrastructure de manière à supporter les besoins actuels et futurs de la banque (Volumétrie /
performance, Sécurité, disponibilité,…) ;

prendre en compte les critères de modernité et d’ergonomie dans le choix de la solution cible ;

favoriser l’homogénéisation des plateformes en privilégiant les technologies modernes ;
2.1.3. Benchmarking et grandes tendances
Il s’agit ici de réaliser une étude des grandes tendances sur les trois axes d’analyse du schéma directeur. La
réalisation de ces études se fait à partir des revues spécialisées, des communications fournies par des éditeurs,
des études comparatives réalisées par des cabinets spécialisés, des visites à d’autres banques,…
Pour l’axe fonctionnel et applicatif, il s’agit de :
Page 37
Première Partie

présenter les différentes solutions existantes sur le marché ;

réaliser des études comparatives entre les solutions à partir des informations publiées ou des analyses
effectuées par les cabinets spécialisés : éditeur, couverture fonctionnelle, références utilisant la solution,… ;

apprécier les retours d’expériences des banques.
2.1.4. Définition de la cible
La définition de la cible constitue un processus itératif incluant l’analyse des résultats des étapes précédentes
afin de construire les scénarii du système cible et de valider le scénario le plus approprié.
Le choix du scénario applicatif a des incidences directes sur les deux autres axes du schéma directeur :
organisation DSI et infrastructure technique. Plusieurs scénarii applicatifs peuvent être envisagés :

Développement et évolution du système en place en remplaçant de manière progressive les domaines
applicatifs défaillants et les intégrant dans une nouvelle architecture. Deux schémas sont possibles pour
l’évolution du système : développements spécifiques ou acquisition de progiciels externes et paramétrage et
intégration dans l’environnement existant.

Mise en place d’un « Global Banking » : refonte complète du système d’information sur la base d’un
progiciel. Minimisation des développements spécifiques par l’adaptation de la banque au fonctionnement
standard du progiciel. Intégration de certains composants de l’architecture actuelle dans le système cible
(salle des marchés, commerce extérieur,…).

Alignement à l’architecture applicative de la société mère : deux schémas sont possibles : utilisation de la
même plateforme dans une configuration multi-sociétés (contraintes règlementaires et faisabilité
technique,…), déploiement d’une plateforme clonée au site local.
Une analyse comparative des avantages et inconvénients de chaque solution permettra de retenir le scénario
applicatif le plus adapté au contexte de la banque. Ce choix déterminera l’organisation et l’architecture technique
cibles. Dans notre cas, on suppose que le scénario de mise en place du « Global Banking » est retenu.
2.1.5. Définition de la trajectoire de convergence vers la cible
Après la validation du scénario cible, il faut définir les actions et les projets à mettre en place pour la réalisation
du plan stratégique. On cite à titre d’exemples les actions suivantes :

améliorer les fonctionnalités de certaines applications ;

fiabiliser le référentiel client ;

modifier les processus de compensation et mettre en place des centres de traitements régionaux,…

réaliser le premier lot du projet « Global Banking » ;

mettre en place un système décisionnel de Datawarehouse,…
Page 38
Première Partie
2.2. Appel d’offres
A ce stade, le schéma directeur informatique a clairement défini les insuffisances du système en place ainsi que
les orientations et les principes directeurs du système cible. Il reste donc le lancement des appels d’offres pour le
choix de la solution qui peut répondre aux exigences et objectifs définis.
Le lancement des appels d’offres doit être précédé par la recherche des prestataires potentiels (2.2.1) et la
rédaction des cahiers des charges (2.2.2)
2.2.1. Recherche des prestataires
Il est plus judicieux que l’appel d’offres pour une solution de « Global Banking » soit réalisé sur un nombre réduit
d’éditeurs. Il est possible donc d’exploiter les résultats de travaux de benchmarking et de détermination des
nouvelles tendances informatiques réalisés dans le cadre de la construction du schéma directeur informatique
pour la détermination de la liste des éditeurs à consulter.
Ces travaux permettent d’exclure les éditeurs qui ne peuvent pas répondre aux exigences de la banque :
couverture fonctionnelle insuffisante, architecture technique complexe ou obsolète, pas de référence,…
2.2.2. Rédaction du cahier des charges
Une fois les éditeurs à consulter sont identifiés, il y a lieu de rédiger le cahier des charges afin de permettre
d’expliquer le projet, son contexte et ses objectifs aux différents prestataires et également leur fournir un support
commun sur lequel ils pourront établir leurs offres. Le cahier des charges est le document qui décrit les besoins
que devra remplir le nouveau système d'information. Ce document sera établi à partir des exigences
fonctionnelles et techniques identifiées lors de la construction du schéma directeur informatique. Le cahier des
charges est structuré comme suit :

Présentation de la banque : activités et métiers, historique, structure de capital et actionnaires de
référence, management, les principaux chiffres clés : nombre d’agences, nombre de comptes, effectif,…

Contexte de l’appel d’offres : objectifs stratégiques ayant motivé la construction du schéma directeur :
extension du réseau d’agence, nouveau positionnement sur le marché, conformité aux standards
internationaux,…

Objectifs de l’appel d’offres : appel d’offres en vue de l’acquisition d’un « Global Banking ».

Déroulement de l’appel d’offres : date limite d’envoi des réponses à l’appel d’offres par les éditeurs,
modalités de réponses (langue de réponse, support de réponse,…), modalités de réponses aux questions
des éditeurs (support, contact,…), règles de confidentialité,…

Présentation du système d’information actuel : présentation de l’architecture applicative actuelle,
présentation de l’architecture technique actuelle.
Page 39
Première Partie
Les orientations pour le système cible : ce sont les principes directeurs identifiés dans le cadre la

construction du schéma directeur : système temps réel, vision client, automatisation des processus,…
Dossier de réponse à remplir par les éditeurs : le dossier de réponse est structuré autour des

informations sur l’éditeur, les exigences fonctionnelles, les exigences techniques et l’offre commerciale. On
présentera les principales informations que doit contenir un appel d’offres d’un « Global Banking ».
 Questions Editeur :
Questions
Réponse Editeur
Présentation de l’éditeur
Raison sociale, adresse, registre de commerce, composition de l’actionnariat
Principaux indicateurs d’activité (CA, résultat) sur les 5 derniers exercices (indiquer la répartition
du CA entre les activités de licences, de maintenance et de service)?
Organisation et nombre de salariés de la société par représentation géographique
Répartition du personnel, dédié au progiciel proposé, par fonctions : R&D, Support produit,
Support à l’implémentation, Hotline, Commerciaux, Administratifs
Présentation du progiciel
Nom et ancienneté du progiciel avec lequel vous répondez à l’appel d’offres (détaillez par
module si besoin : numéro de version actuelle, date de première mise en production).
Quel est le langage de développement du progiciel ?
Décrivez les caractéristiques ergonomiques du progiciel, et en particulier celles du module
agence (présentation, navigation, …)
La solution contient-elle une fonction d’aide en ligne?
Références
Veuillez indiquer le nombre de versions exploitées simultanément par vos clients.
Veuillez indiquer la liste de vos références entrées en production, en insistant sur celles des 4
dernières années en précisant pour chacune :

la date de mise en exploitation de la solution ;

la couverture fonctionnelle (modules et N° de version) ;

les chiffres clés (nombre d’agences, nombre de comptes, nombres d’opérations) ;

les modalités de l’intégration (nombre d’intervenants, intégrateur, durée, budget) ;

le nom et les cordonnées d'un contact client.
Avez-vous des partenaires que vous recommandez pour l’intégration et la maintenance de votre
progiciel ? (précisez chez quels clients ils ont intégré votre produit)
 Questions fonctionnelles :
Dans cette partie, il est demandé aux éditeurs de décrire selon le canevas de leur choix les principales
fonctionnalités de chaque module : module central, module agence, module moyens de paiements, module
crédit, module risque, module commerce extérieur,…
Page 40
Première Partie
De même, des réponses précises seront demandées aux exigences fonctionnelles identifiées :
Questions
Réponse Editeur
Noyau central et Système comptable
Est-ce que la solution est implémentable sur un noyau comptable externe ?
Est-ce que la solution permet l’injection de lot comptable externe ?
Existe-t-il un système de lettrage automatique, quels sont les critères de lettrage paramétrables?
Est-ce que la solution est multi-devise ?
Est-ce que les schémas comptables des différents modules sont paramétrables ?
Existe-t-il un système de paramétrage des reportings et déclarations ?
Quelle est la structure des comptes ?
Existe-t-il une gestion des rapprochements bancaires ?
Est-ce que le système assure la calcul de la prime de fidélité sur les comptes épargne ?
Module Crédit
Le progiciel gère t-il les étapes d’instructions de crédit ?
Est-ce qu’il existe une comptabilisation hors bilan ?
Le système assure t-il la gestion des autorisations ?
Le système gère-t-il les conventions ?
Est-ce que le système gère les crédits avec des non clients ?
Est-ce que le système gère les crédits en pool ?
Est-ce que le système assure la gestion des produits islamiques ?
Est-ce que la solution gère les consolidations de crédits ?
Est-ce que le système peut assurer la gestion physique centralisée des titres de crédit ?
Module agence
Quel est le périmètre minimal à implémenter autour du module agence pour garantir la
cohérence fonctionnelle de la solution ?
Est-ce que les soldes clients sont mis à jour en temps réel ?
Est-ce qu’il est possible de gérer des placements en devise ?
Est-ce qu’il est possible de gérer des placements à taux variable ?
Existe-il un système de blocage de fonds clientélisé ?
Les opérations inter-agences impactent-elles les soldes clients en temps réel ?
Le système permet-il la réévaluation de la position de change manuel ?
Est-ce que la solution gère différents type de taux de change ?
Est-ce que la solution gère les transferts de compte entre agences ?
Module Moyens de paiement
Est-ce que la solution peut gérer la compensation selon la règlementation tunisienne ?
Est-ce que la solution peut gérer les valeurs en devises ?
Est-ce que la solution peut gérer les centres de traitement régionaux ou nationaux ?
Est-ce que la solution peut gérer la gestion physique centralisée des effets ?
Est-ce que la solution gère les virements gros montants : SGMT ?
Page 41
Première Partie
Questions
Réponse Editeur
Module risques
Est-ce que la solution gère les garanties ?
Est-ce que les garanties sont amorties au fur et à mesure du remboursement de crédits ?
Est-ce que la solution permet de gérer la classification des clients selon les critères d’impayés et
de gel de compte ? quels sont les autres critères paramétrables ?
Est-ce que la solution gère l’effet de contagion ?
Est-ce que la solution gère la réservation et la reprise des agios par client ?
Est-ce que la solution gère le calcul des provisions pour risque?
 Questions Techniques :
Questions
Réponse Editeur
Architecture technique
Quels sont les pré-requis techniques pour l’implémentation du progiciel en termes de :

Serveurs : configuration matérielle; système d'exploitation (type et version); base de
données (type et version)

Postes de travail : configuration matérielle, système d'exploitation (type et version);
outils bureautique

Réseau
Quels sont les outils techniques complémentaires nécessaires au fonctionnement de la solution
(serveur d’édition, compilateur, …) ? Sont-ils fournis avec la solution ?
Le progiciel peut-il fonctionner dans les agences en mode déconnecté?
Le système agence possède-t-il une base de données locale ? Si oui, décrivez les processus de
réplication avec les bases de données centrales.
Quels sont les différents composants permettant de sécuriser les accès, les données, le
transactionnel, etc.
Performances
Parmi les clients utilisant la solution en Production, quels sont les plus gros volumes gérés en
termes de :
 nombre d’agence (nombre et nom du client)
 nombre de clients et de comptes (nombre et nom du client)
 nombre de transactions (nombre et nom du client)
 nombre d’utilisateurs (nombre et nom du client)
Quelles sont les limites techniques du produit (nombre d’agences, clients, comptes,
transactions, utilisateurs, utilisateurs simultanés, …)
Page 42
Première Partie
 Questions commerciales :
Questions
Réponse Editeur
Licences et contrat
Est-il possible de scinder les droits d’utilisation des différents modules de votre progiciel ?
Précisez votre formule de pricing de licences (par module) afin de permettre des simulations
sur les évolutions de l’activité / nombre d’utilisateurs.
Services de support à l’intégration
Précisez votre mode habituel d‘intégration : support au client, intégrateur, partenariat avec
intégrateur.
Citez 2 références d’implémentation qui ont selon vous été des succès (respect des délais et du
budget) dans les 2 dernières années, ainsi que le nom et les cordonnées d'un contact client.
Donnez des exemples de budget d’intégration du progiciel (en jours-hommes) en fonction des
couvertures fonctionnelles choisies.
Services de support à l’utilisation
Existe-t-il une hot-line ? Si oui, veuillez en décrire les caractéristiques (taille, lieu géographique,
langue, horaires) et les modes de fonctionnement (type de support fourni – fonctionnel /
technique, temps de réponse et de résolution des incidents)
Existe-t-il un support 2ème niveau ? Si oui, veuillez en décrire les caractéristiques et les modes de
fonctionnement.
Avez-vous une filiale ou un partenaire qui soit en mesure d’assurer ce type de support avec une
présence locale en Tunisie ?
Services d’évolution du produit
Comment gérez-vous les développements spécifiques : qui les réalise (décrire les différentes
configurations possibles) ? Qui les maintient par la suite ?
Mettez-vous à disposition de vos clients un framework de développement pour qu’ils puissent
prendre en charge une partie de la maintenance de la solution ? Dans quelle mesure les clients
peuvent-ils avoir accès au code source ?
Quels types d’évolutions sont couverts par la maintenance contractuelle (montées de versions
mineures / majeures, fonctionnelles / techniques, réglementaires, …) ?
Quelles sont les évolutions fonctionnelles et techniques majeures prévues dans les prochaines
années, leur niveau d’avancement actuel, et leur date de mise en service planifiée.
Concernant les développements complémentaires demandés par un client, veuillez décrire les
modalités pratiques : comment sont gérées les spécifications, quelle partie est effectuée en
local vs. à distance, … ?
Documentation
La documentation technique existe-t-elle en français ?
La documentation utilisateur existe-t-elle en français ?
Conditions financières
Licences du progiciel (global ou détaillé par module et nombre d’agences)
Autres licences nécessaires à la mise en place (compilateur, base de données,…)
Prestations d’intégration
Fais de maintenance et d’assistance
Page 43
Première Partie
2.3.
Evaluation des offres et sélection de la solution
Cette phase doit permettre de sélectionner la solution la plus adaptée aux exigences de la banque. Trois étapes
sont préalables à la sélection : évaluation des réponses aux appels d’offres, acquisition de
connaissances approfondies et évaluation définitive et choix de la solution.
2.3.1. Evaluation des réponses
Le processus d’évaluation des réponses des éditeurs comprend les étapes suivantes :

Constitution des équipes d’évaluation : une équipe sera affectée à chaque partie des dossiers de réponse
des éditeurs : question éditeurs, questions fonctionnelles, questions techniques, questions commerciales.

Lecture comparative des réponses des éditeurs.

Une préparation d’éventuelles questions complémentaires qui seront envoyées aux éditeurs.

Une proposition d’une évaluation à chacune des réponses suivant une grille d’évaluation de ce type :
Note
A
B
C
D

Description
Pondération
0
1
2
3
Non Réponse
Réponse non satisfaisante
Réponse plutôt satisfaisante
Réponse totalement satisfaisante
Détermination de la note de l’éditeur pour chaque partie de dossier de réponse en appliquant les
pondérations de la grille d’évaluation.

Détermination de la note de chaque éditeur pour l’ensemble des parties des réponses en appliquant des
pondérations prédéfinies pour chaque partie :
Question /
Notes
Editeur
Fonctionnel
Technique
Commercial
Total

A
B
C
D
0
2
2
1
2
7
1
3
5
2
3
13
2
2
4
5
4
15
3
4
5
4
2
15
Nombre de réponses dans la note
indiquée
Total pond
11
16
12
11
50
0,22
0,32
0,24
0,22
Moy
1,73
1,75
2,00
1,55
1,76
Moyenne de la note = nbre de
réponses (A) * pondération (A) +
…+nbre de réponse (D) *
pondération (D) / total nbre réponses
Moyenne pondérée de l’éditeur =
moyenne par domaine *
pondération du domaine
Identification de la « short list » des éditeurs : deux ou trois éditeurs seront sélectionnés pour les étapes
ultérieures.
Page 44
Première Partie
2.3.2. Acquisition de connaissances approfondies
Une fois la « short list » est close, trois activités prennent place avec chacun des partenaires restant en course :

Visite d’un client partenaire où la solution est déjà opérationnelle : il s’agit d’avoir un retour
d’expériences d’une banque ayant le même niveau d’activité et qui vient de mettre en place la même
version du progiciel. Il faut tirer les principales leçons apprises notamment : mode d’implémentation,
lotissement du projet et durée de mise en place, performances du système, satisfaction des besoins,
conformité à la règlementation, qualité du support, processus des développements spécifiques,…

Présentation sur site et « gap analysis » : il s’agit d’organiser des chantiers de présentation des
principales caractéristiques et fonctionnalités de la solution. Il est possible de réaliser lors de ces
présentations, des démonstrations opérationnelles de certains modules ou transactions. Du coté de la
banque, ces présentations permettent d’acquérir des connaissances plus approfondies sur la solution et
d’arrêter une liste préliminaire des écarts fonctionnels entre les fonctionnalités du progiciel et les exigences
de la banque.

Rencontres des directions générales de la banque et de l’éditeur : ces réunions permettent de projeter
et de préparer les futures relations de partenariat. Les termes et les conditions d’un futur contrat pourront
aussi être abordés lors de ces réunions.
2.3.3. Evaluation définitive et choix de la solution
A ce stade la banque dispose de suffisamment d’informations pour faire un classement des éditeurs de la « short
list ». Il s’agit de réviser l’évaluation initiale en intégrant les nouvelles connaissances acquises notamment le
nombre d’écarts fonctionnel identifiés, les négociations commerciales réalisées,…
La décision finale appartient à la Direction Générale.
2.4.
Contractualisation
Une fois le choix est effectué, un contrat sera signé par les deux parties. Il est possible que plusieurs contrats
soient signés pour chaque composante de la prestation : licences du progiciel, prestation de mise en place et
contrat de maintenance.
Il est conseillé d’indiquer au niveau du contrat :

l’engagement de l’éditeur sur les performances du système ;

l’engagement de l’éditeur sur les développements spécifiques et les délais de livraison ;

l’engagement de l’éditeur sur un planning de mise en place.
Page 45
Première Partie
Chapitre 2 : Processus d’implantation d’un Global Banking
CHAPITRE 2 : PROCESSUS D’IMPLANTATION D’UN GLOBAL
BANKING
Selon une étude appelée « Chaos » réalisée par une société américaine de consulting « The Standish Group »
menée auprès de 365 chefs de projets de système d’information ; 31 % des projets informatiques sont arrêtés en
cours de route, 52 % n’aboutissent qu’au prix d’un important dépassement des délais et du budget et en offrant
moins de fonctionnalités qu’il n’en était demandé ; seuls 16 % des projets peuvent être considérés comme des
succès40.
L’implantation d’un Global Banking constitue un projet complexe et sa maîtrise suppose la mise en œuvre d’un
management de projet. Pour mieux situer la démarche du changement du système d’information, il sera
nécessaire de définir ces deux notions : « projet » et « management de projet »
Définition de la notion « projet »: parmi, les dizaines de définitions de « projet », on propose deux définitions :
(1) Tout d’abord, celle retenue par l’Organisation Mondiale de Normalisation. La norme ISO 10006 (version
2003) définit le projet comme « un processus unique qui consiste en un ensemble d'activités coordonnées
et maîtrisées, comportant des dates de début et de fin, entrepris dans le but d'atteindre un objectif conforme
à des exigences spécifiques, incluant des contraintes de délais, de coûts et de ressources. ». Dans cette
première définition, les projets sont caractérisés essentiellement par :

des phases uniques et non répétitives, composées de processus et d’activités,

la fixation d’objectifs spécifiques, précis, cohérents et mesurables dans le but de satisfaire une demande
ou un besoin exprimé ou potentiel,

une période de temps limitée, définie avant son lancement par un début et une fin,

la mobilisation de ressources, de moyens et de compétences multidisciplinaires sur une période plus ou
moins longue.
(2) La seconde définition est celle retenue par le Project Management Institue (PMI), Dans sa version de 2004,
le PMBOK propose la définition suivante : « Un projet est une entreprise temporaire décidée dans le but de
créer un produit, un service ou un résultat unique ». Dans cette définition, les projets se caractérisent
essentiellement par :
40

une période de temps limitée,

la création de livrables uniques qui peuvent être des produits, des services ou des résultats.
Jack T. MARCHEWKA, Information technology project management, 2003, page 22
Page 46
Première Partie

un développement par étapes et une progression par incréments.
Définition de la notion « management de projet » : on propose deux définitions également :
(1) La norme ISO 10006 présente la définition suivante : le mangement de projet correspond à la planification,
l’organisation, le suivi, la maîtrise, le compte rendu et l’application des actions correctives nécessaires, sur
une base continue, de toutes les activités du projet qui sont nécessaires pour atteindre les objectifs du
projet.
(2) Le PMBOK propose la définition suivante : Le management de projet est l'application de connaissances, de
compétences, d'outils et de techniques aux activités du projet afin d'en respecter les exigences. Le
management de projet comprend les points suivants :

déterminer les exigences,

définir des objectifs clairs et réalisables,

équilibrer les exigences concurrentes de qualité, de contenu, de délai et de coût,

adapter les spécifications, les plans et l'approche aux différentes préoccupations et attentes des diverses
parties prenantes.
Bien que la notion de projet ne soit pas nouvelle41, la discipline de management de projet est relativement
nouvelle. La gestion de projet ne devient un modèle de gestion que dans les années 1950 et 1960. À cette
époque, elle s’autonomise et se standardise, notamment parce que les différences sectorielles sont perçues
comme moins importantes que les sujets de préoccupation communs en matière de management des projets.
Les principaux travaux de normalisation ainsi que les concepts fondamentaux de gestion de projet seront
présentés au niveau de la section 1. Dans la section 2, on présentera la démarche de conduite d’un projet de
mise en place d’un Global Banking.
SECTION 1 : CADRE DE RÉFÉRENCE DE CONDUITE DE PROJET
Le management de projet s’est progressivement structuré. Les pratiques singulières sont devenues des modèles
contingents. Jusqu’au début du 20ème siècle, l’histoire de la gestion de projet se confond avec celle des
techniques ou des professions. À partir des années 1930, la gestion de projet se rationalise, sans pour autant se
constituer en modèle de gestion. Ce n’est que plus tard, à la fin des années 1960, que la gestion des projets
s’érige en véritable modèle sous l’impulsion des milieux professionnels américains réunis au sein du Project
Management Institute (PMI). Le rôle de PMI et des autres institutions professionnelles internationales est capital
dans la diffusion d’un modèle standard de management de projet.
41
Le projet des pyramides en Egypte.
Page 47
Première Partie
On présentera successivement les principaux travaux de normalisation dans la discipline de management de
projet (Paragraphe 1), puis on détaillera les principaux concepts de management de projet prévus par les
standards internationaux (Paragraphe 2).
Paragraphe 1 : Standards internationaux de gestion de projet
Les fortes évolutions qui ont marqué la conduite des projets, tant dans le champ d’application que dans les
méthodes et les pratiques ont conduit plusieurs organisations internationales à engager des travaux en vue de
définir un cadre de référence de gestion de projet. Les principales organisations ayant publié des normes de
management de projet sont : L’Organisation Internationale de Normalisation (ISO) (1), l’Association Française de
Normalisation (AFNOR) (2) et le Project Management Institue (PMI) (3).
1. L’Organisation Internationale de Normalisation (ISO)42
Dans le domaine de mangement de projet, l’ISO a publié depuis 1997, la première version de la norme ISO
10006 « Lignes directrices pour le management de la qualité dans les projets ». Cette version a été annulée et
remplacée par la version 2003. L’ISO 10006 (version 2003) fournit des conseils sur l’application du management
de la qualité aux projets. Elle est applicable à des projets de complexité variable, qu’ils soient petits ou grands,
de courte ou de longue durée, qui se situent dans des environnements différents, quel que soit le type de produit
ou de processus de projet. Cette norme ne constitue pas un guide en lui-même pour le management de projet,
mais elle se contente de donner des conseils sur la qualité dans le cadre des processus de management de
projet. Les différents processus de projet pour lesquels l’ISO 10006 a fourni des conseils se détaillent dans le
tableau suivant :
Article
Responsabilité de la direction (Article 5)
Management des ressources (Article 6)
Réalisation du produit (Article 7)
Mesure, analyse et amélioration (Article 8)
Processus
Processus stratégique
Processus relatifs aux ressources
Processus relatifs au personnel
Processus relatifs à la coordination
Processus relatifs au contenu du projet
Processus relatifs aux délais
Processus relatifs aux coûts
Processus relatifs à la communication
Processus relatifs aux risques
Processus relatifs aux achats
Processus relatifs à l’amélioration
Processus relatifs à la mesure et à l’analyse
Processus relatifs à l’amélioration continue.
L’ISO (Organisation internationale de normalisation) est le plus grand producteur et éditeur mondial de normes internationales. L'ISO
est un réseau d'instituts nationaux de normalisation de 157 pays, selon le principe d'un membre par pays, dont le Secrétariat Central,
situé à Genève, assure la coordination d'ensemble.
Page 48
42
Première Partie
En novembre 2007, l’ISO a lancé des travaux pour une nouvelle norme internationale de gestion de projet (ISO
21500). Cette norme fournira des lignes directrices génériques, en expliquant les principes fondamentaux et les
éléments constitutifs des bonnes pratiques en matière de gestion de projet. Elle sera applicable aux
organisations de toutes tailles, dans tous les secteurs, elle sera conçue pour les néophytes en matière de
gestion de projet et constituera un aide-mémoire pour les praticiens plus expérimentés43.
2. L’Association Française de Normalisation (AFNOR)
L’Association Française de Normalisation (AFNOR) est l'organisme officiel français de normalisation. Il est
membre de l’ISO auprès duquel il représente la France. L'AFNOR a été créée en 1926 ; elle est placée sous la
tutelle du ministère chargé de l'industrie. Elle compte environ 3 000 entreprises adhérentes. Les premiers
documents AFNOR dans le domaine du management de projet ont été réalisés dans les années 90, à l’initiative
de l’Association Francophone de Management de Projet (AFITEP). L’organisation du corpus normatif en matière
de management de projet est la suivante :

Le fascicule FD X50-115, document de base de l’ensemble du corpus normatif sur le management de projet
qui permet d’en avoir une vue globale. Il comprend les concepts, les définitions et les principes essentiels
nécessaires à son exercice.

Le fascicule FD X50-118 intitulé « Recommandations pour le management d’un projet ». Ce fascicule
expose les facteurs clés de la réussite d’un projet, les pièges à éviter et les recommandations générales en
matière de mangement de projet.

Un fascicule reprenant la norme internationale sur la qualité en mangement de projet (ISO 10006)

Des fascicules thématiques ; les thèmes abordés sont :

-
La maîtrise des risques du projet : FD X50-117
-
La maîtrise des coûts du projet FD X50-137
-
La maîtrise des délais : FD X50-138
Un fascicule portant sur le management par projet FD X50-116; l’objectif de ce fascicule est de décrire les
caractéristiques et les principes de mise en œuvre de ce mode de management de l’entreprise.

Des documents sectoriels complètent ce corpus générique.
3. L’Institut de Management de Projet (PMI)
Le Project Management Institute (PMI), fondé en 1969, est une association professionnelle à but non lucratif
qui propose des méthodes de gestion de projet. Son siège est aux Etats Unis, elle compte plus de 200 000
43
www.iso.org
Page 49
Première Partie
membres répartis dans 125 pays. Elle publie des standards relatifs à la gestion de projet et elle est en charge de
la certification des processus de gestion de projet.
Le Project Management Body of Knowledge (PMBOK) est le guide du Project Management Institute
définissant les champs de connaissances couvrant la gestion de projet. Il sert de base de référence, pour établir
les contenus de cours sur la gestion de projet et pour l'élaboration d'examen de certification.
Le Project Management Institute (PMI) a publié le premier volume Project Management Body of Knowledge
en 1987 avec la tentative de documenter et standardiser les informations et les pratiques du management de
projet. La première édition est publiée en 1996 suivit par la seconde édition en 2000. En 2004, la troisième
édition est publiée. Elle inclut des différences majeures avec la troisième édition. Actuellement, un groupe
international d'experts travaille sur l'écriture d'une quatrième édition.
Le Guide PMBOK – Troisième édition est organisé en trois sections :
(1) Cadre du management de projet : cette section définit les termes clés et offre une vue d'ensemble du
reste du Guide PMBOK.
(2) Norme du management d’un projet : cette section décrit les cinq groupes de processus de management
de projet nécessaires à tout projet : le groupe de processus de démarrage, le groupe de processus de
planification, le groupe de processus d'exécution, le groupe de processus de surveillance et de maîtrise,
le groupe de processus de clôture.
(3) Domaines de connaissance en management de projet : cette section organise les 44 processus de
management de projet en neuf domaines de connaissance :
-
Management de l'intégration du projet ;
-
Management du contenu du projet ;
-
Management des délais du projet ;
-
Management des coûts du projet ;
-
Management de la qualité du projet ;
-
Management des ressources humaines du projet ;
-
Management des communications du projet ;
-
Management des risques du projet ;
-
Management des approvisionnements du projet.
Page 50
Première Partie
Paragraphe 2 : Concepts de base de gestion de projet proposés par
les standards internationaux
Avant de détailler recommandations relatives aux principales activités de management de projet (2), il y a lieu de
présenter les caractéristiques principales du contexte de déroulement d’un projet telles que prévues par les
normes de management de projet (1).
1. Aspects majeurs du contexte de management de projet
1.1. Cycle de vie du projet
Le cycle de vie du projet définit les phases qui relient le début d'un projet à sa fin. Le déroulement d’un projet
comprend quatre phases fondamentales. Chacune des phases comporte plusieurs étapes ou sous-phases.
 Phase d’initialisation (phase 0) : La phase d’initialisation consiste à approfondir les enjeux et les
objectifs, puis commencer à définir le contenu du projet jusqu’à ce qu’il soit possible de statuer sur l’opportunité
ou non pour l’organisme de lancer le projet. Les enjeux, les opportunités et les moyens attribués du projet seront
alors résumés dans un document de cadrage.
 Phase de préparation (phase 1) : La phase a pour but d’aboutir à la définition détaillée du produit ou
service et de la manière dont il sera réalisé ainsi que de créer les conditions qui faciliteront cette réalisation.
Cette phase se termine par une revue de la pertinence de la solution par rapport au besoin et les risques que
présente sa mise en œuvre. Les principaux objectifs de cette phase sont :

consolider l’expression des besoins et des contraintes du produit ou du service à réaliser ;

choisir la solution à réaliser ;

préciser les enveloppes de coût et de délais du projet ;

mettre en place l’organisation des acteurs de la réalisation ;

anticiper les risques liés à la réalisation et à l’exploitation de la solution retenue.
 Phase de réalisation (phase 2) : La phase de réalisation consiste à la mise en œuvre de la solution
détaillée et validée par la précédente phase. Elle se termine par l’acceptation par l’organisme client du produit ou
du service réalisé.
 Phase de clôture (phase 3) : La phase de clôture sert à terminer le projet. Au cours de cette phase, on
procède au désengagement des ressources affectées au projet et on dresse le bilan du projet, afin de capitaliser
l’expérience acquise. La fin du projet est déclarée après constat de la conformité des éléments obtenus par
rapport aux conditions de clôture définies par le document de cadrage du projet.
Page 51
Première Partie
Les phases du cycle de vie du projet sont tout à fait différentes des processus de management de projet
décrits en détail dans le point 2.
Les phases du projet divisent le cycle de vie du projet en sections gérables : phase d’initialisation, de
préparation, de réalisation et de clôture. Les processus sont les processus nécessaires au management du
projet : mangement des délais, des ressources, du contenu,….
Les processus de management de projet et les phases du cycle de vie du projet se chevauchent et interagissent
tout au long du projet. A titre d’exemple le processus de management de l’intégration du projet intervient dans les
4 phases du projet ; phase d’initialisation : élaboration du contenu préliminaire du projet ; phase de préparation :
élaboration du plan du management du projet ; phase de réalisation : diriger et piloter l’exécution du projet ;
phase de clôture : clôturer le projet.
1.2. Organismes
Les normes de management de projet distinguent entre « l’organisme à l’origine du projet » et « l’organisme en
charge du projet ». L’organisme à l’origine du projet appelé également organisme client ou maître d’ouvrage est
celui qui décide d’entreprendre le projet. Il a la charge de spécifier l’objet du projet et les conditions de sa
réalisation. L’organisme en charge du projet ou l’organisme réalisateur ou maître d’œuvre réalise l’objet en
cohérence avec les spécifications et la stratégie de l’organisme client. Lorsque l’organisme réalisateur fait partie
de l’organisme client, on parle de projet interne.
1.3. Parties prenantes d’un projet
Les parties prenantes du projet sont les personnes et les organisations activement impliquées dans le projet, ou
dont les intérêts peuvent subir l’impact de l’exécution ou de l'achèvement du projet. L'équipe de management de
projet doit identifier ces parties prenantes, déterminer leurs exigences et leurs attentes et, dans la mesure du
possible, gérer leur influence. Les parties prenantes principales de chaque projet comprennent : le chef de projet,
le client/ l’utilisateur, l’entreprise réalisatrice, les membres de l’équipe du projet,…
2. Recommandations relatives aux principaux domaines d’activités/processus du
management d’un projet
Les normes de management de projet ont regroupé les activités de management de projet en neuf domaines
d’activité (processus selon PMBOK et l’ISO 10006). La qualité du management de projet résulte de la bonne
application des recommandations définies pour chaque domaine/processus. La description de chacun de ces
processus sera structurée comme suit : présentation des principaux objectifs du processus et présentation des
principales tâches couvertes par le processus.
Page 52
Première Partie
2.1. Management de l’intégration du projet
2.1.1. Objectifs du processus
Les objectifs de ce processus sont d’assurer la performance globale du projet. Ce processus contient tous les
dispositifs qui concourent à la qualité du produit du projet dans une perspective de développement durable. Dans
le cadre de ce domaine, il convient de veiller, à la fois aux performances de l’objet du projet (conformité en
termes de contenu, coût, délai,…) qu’à la performance des processus mis en œuvre dans le cadre du projet.
2.1.2. Principales tâches du processus
 Phase d’initialisation (phase 0) : Élaborer l'énoncé préliminaire du contenu du projet (PMBOK)/
document de cadrage (Normes AFNOR):
C’est le document qui fournit à haut niveau, une description narrative du contenu du projet. Ce document est
préparé généralement suite à l’un des évènements suivants : besoin commercial, demande de la clientèle, une
avancée technologique, une obligation juridique,… L’énoncé préliminaire du contenu du projet doit traiter les
aspects suivants : contexte et objectifs du projet, positionnement du projet par rapport aux objectifs de
l’organisme, retour sur investissement du projet, limites et risques du projet, livrables du projet, organisation
initiale du projet, l’échéancier récapitulatif, phases du projet et date clés, budget récapitulatif du coût du projet,…
L’annexe1 donne un exemple fourni par la norme AFNOR X50-118 du plan du document de cadrage d’un projet.
 Phase de préparation (phase 1) : Élaborer le plan de management du projet :
Ce document contient tous les éléments nécessaires à l’atteinte des objectifs du projet, il définit la manière dont
le projet est exécuté, surveillé, maitrisé et clôturé. Le plan de mangement de projet contient essentiellement: le
contexte et les objectifs du projet, les intervenants au projet, les instances de pilotage et de fonctionnement, le
phasage du projet, le budget et le suivi budgétaire, méthode de reporting et de communication, gestion de la
documentation, gestion des risques, gestion des modifications,…
L’annexe 2 donne un exemple fourni par la norme AFNOR X50-118 du plan d’un plan de mangement de projet.
 Phase de réalisation (phase 2) :

Diriger et piloter l'exécution du projet : il s’agit d’exécuter les actions et travaux définis dans le plan de
management du projet. Parmi ces actions, on peut citer :
- Recruter les membres du projet, les former et les diriger.
- Effectuer les activités permettant de réaliser les objectifs du projet.
- Collecter les données du projet et rendre compte du coût, de l’échéancier,…
- Créer, vérifier et valider les livrables du projet.
Page 53
Première Partie

Surveiller et maîtriser les travaux du projet : cette activité permet de surveiller et maîtriser les processus
utilisés pour le démarrage, la planification, l'exécution et la clôture du projet, afin d'atteindre les objectifs de
performance définis dans le plan de management du projet. Cette activité consiste essentiellement à :
- Evaluer la performance pour déterminer si des actions correctives ou préventives sont nécessaires et
recommander ces actions le cas échéant.
- Analyser, suivre et surveiller les risques du projet pour s’assurer que les risques sont identifiés et que les
plans appropriés des réponses aux risques sont exécutés.
- Fournir des prévisions pour mettre à jour l’information sur le coût et l’échéancier actuels.

Maîtrise intégrée des modifications : Les projets se déroulent rarement en parfaite conformité avec le plan
de management du projet, d’où la nécessite de la maitrise des modifications. La gestion des modifications
recouvre l’identification, l’évaluation, l’autorisation, la documentation, la mise en œuvre et la maitrise des
modifications. Avant qu’une modification ne soit autorisée, il convient d’en analyser la finalité, l’étendue et
l’impact, en particulier pour celles qui ont une incidence sur les objectifs du projet.
 Phase de clôture (phase 3) : Clôture des processus et du projet :
Ce processus consiste à définir les actions et activités nécessaires pour confirmer que le projet a répondu à
toutes les exigences des parties prenantes et pour vérifier que tous les livrables ont été fournis et acceptés et
pour valider que les critères d’achèvement et de sortie ont été respectés.
2.2. Gestion du contenu du projet
2.2.1. Objectifs du processus :
Le contenu du projet comprend une description du produit du projet, ses caractéristiques ainsi que la façon dont
celles-ci sont mesurées ou évaluées. Les processus de gestion du contenu du projet sont destinés à :
- traduire les besoins et les attentes des parties intéressées en activités à accomplir pour atteindre les
objectifs du projet et à organiser ces activités ;
- s’assurer que les activités mises en œuvre satisfont aux exigences décrites dans le contenu du projet.
 Phase de préparation (phase 1)

Planification du contenu : ce processus documente la façon dont le contenu du projet sera défini, vérifié et
maîtrisé, et comment la structure de découpage du projet sera élaborée et définie. L’équipe de management
du projet documente ces décisions et choix de management du contenu dans le « plan de management du
contenu du projet ». Les composantes de ce plan comprennent : le processus pour préparer l’énoncé détaillé
Page 54
Première Partie
du contenu du projet, le processus qui permet la création de la structure de découpage du projet, et qui
définit comment cette structure sera maintenue et approuvée et le processus qui spécifie comment obtenir la
vérification et l’acceptation formelles des livrables achevés du projet.

Définition du contenu : c’est le processus qui permet d'élaborer « un énoncé détaillé du contenu du
projet », cet énoncé décrit en détail les livrables du projet et le travail nécessaire à leur création et il servira
de base aux décisions futures pour le projet. L’énoncé détaillé du contenu du projet comprend généralement
les éléments suivants : les objectifs du projet ; la description du contenu du produit : caractéristiques du
produit, du service ou de résultat pour lequel le projet a été entrepris ; les exigences du projet : conditions
que les livrables du projet doivent satisfaire ; les limites et périmètre du projet : identifier ce qui est inclus
dans le projet et énoncer explicitement ce qui est exclu ; les livrables du projet ; les critères d’acceptation du
produit ; les contraintes du projet : budget prédéfini, date imposée ;les risques initiaux identifiés,…

Créer la structure de découpage du projet : cette structure est une décomposition hiérarchique, orientée
vers les livrables, du travail à exécuter par l’équipe du projet pour réaliser les objectifs du projet et créer les
livrables exigés. Cette structuration permet de découper le travail du projet en parties plus petites et plus
faciles à maîtriser. Le niveau du lot de travail est le niveau le plus bas de la structure de découpage du
projet, où le coût et l’échéancier du travail peuvent être estimés de façon fiable.

Vérification du contenu : ce processus consiste à obtenir l’acceptation formelle par les parties prenantes
du contenu achevé du projet et des livrables correspondants. La vérification du contenu diffère du contrôle
qualité : la vérification du contenu concerne principalement l’acceptation des livrables, tandis que le contrôle
qualité vise principalement à satisfaire les exigences de qualité spécifiée par ces livrables.

Maîtrise du contenu : ce processus consiste à maîtriser l’impact des modifications apportées au contenu du
projet.
2.3. Gestion des délais
L’objectif principal du processus de gestion des délais est d’obtenir une estimation des délais réaliste et
cohérente avec les objectifs du projet, d’assurer le respect de ces délais avec l’obligation de mettre en œuvre
des mesures correctives adaptées en cas de modification du contenu du projet.
Page 55
Première Partie
 Phase de préparation (phase 1) :

Identification des activités : ce processus permet d’identifier les livrables au niveau le plus bas de la
structure de découpage du projet, appelé lot de travail. Les données de sortie de ce processus sont :
- La liste des activités : il s’agit de déterminer les activités nécessaires pour réaliser le contenu du projet.
- La liste des jalons : cette liste identifie tous les jalons et indique si le jalon est obligatoire ou optionnel.

Séquencement des activités : ce processus consiste à identifier et à documenter les liens logiques entre
les activités. Ce processus donne lieu à un diagramme de réseau du projet, qui constitue une représentation
schématique des activités avec leurs liens logiques.

Estimation des ressources nécessaires aux activités : ce processus consiste à déterminer les
ressources (personnes, équipements ou matériel) et des quantités qui seront utilisées ainsi que du moment
auquel ces ressources seront disponibles pour exécuter les activités du projet. Ce processus est étroitement
lié au processus d’estimation des coûts.

Estimation de la durée des activités : il s’agit de faire une estimation du nombre de périodes de travail
nécessaires à l'achèvement de chacune des activités du planning. Toutes les données et les hypothèses à
l’appui de cette estimation doivent être documentées.

Élaboration du planning : l’élaboration du planning détermine les dates planifiées de début et de fin des
activités du projet. L’élaboration du planning se poursuit tout au long du projet au fur et à mesure que le
travail progresse, que le plan de management de projet est modifié.
 Phase de réalisation (phase 2) : Maîtrise du planning
La maîtrise du planning consiste à :
- déterminer l’état actuel du planning du projet en comparant le réalisé par rapport au budgété ;
- décider les actions à mettre en œuvre pour corriger les éventuels écarts ;
- influencer les facteurs qui génèrent des modifications du planning.
2.4. Gestion des coûts
Le management des coûts du projet comprend les processus de planification, d'estimation, de budgétisation et
de maîtrise des coûts nécessaires pour s'assurer que le projet soit réalisé en respectant le budget approuvé.
Page 56
Première Partie

Estimation des coûts : ce processus consiste à élaborer une approximation des coûts des ressources
nécessaires à l’achèvement de chaque activité du projet. L’estimation du coût s’exprime généralement en
unités monétaires.

Budgétisation : La budgétisation consiste à cumuler les estimations du coût des activités du planning ou de
lots de travail afin de fixer une référence de base du coût total destiné à mesurer la performance du projet.
 Phase de réalisation (phase 2) : Maîtrise des coûts
La maîtrise des coûts du projet consiste à :
- surveiller la performance des coûts pour détecter et comprendre les écarts par rapport au coût
budgété ;
- enregistrer avec exactitude toutes les modifications par rapport à la référence de base des coûts ;
- influencer les facteurs qui génèrent des modifications de la référence de base des coûts ;
- informer les parties prenantes concernées des modifications approuvées ;
- agir pour maintenir les surcoûts prévus dans des limites acceptables.
2.5. Gestion des ressources humaines
L’objectif principal de ce processus est de prévoir, maîtriser les ressources humaines et d’optimiser la
participation directe ou indirecte des personnes impliquées dans le projet. Ce processus vise à créer un
environnement au sein duquel les personnes peuvent contribuer de manière efficace et efficiente au projet.
2.5.2.
Principales tâches du processus

Planification des ressources humaines : ce processus permet de déterminer les rôles, les responsabilités
et les relations d’autorité au sein du projet, et de créer le plan de management des ressources humaines.
Dans le projet, les rôles peuvent être attribués à des personnes internes de l’entreprise ou des sous-traitants
externes. Les données de sortie de ce processus sont généralement :
- L’organigramme du projet : c’est une représentation de l’équipe du projet et leur relation d’autorité.
- Plan de mangement des ressources humaines : ce plan traite les aspects suivants : planification de
l’obtention des ressources : ressources internes ou externe ; calendrier d’intervention des ressources
Page 57
Première Partie
et besoins de recrutement ; critères de désengagement des ressources du projet ; besoins en
formation ; critères de reconnaissance et de récompense ; règles de sécurité.

Constituer l'équipe de projet : c’est le processus d’obtention des ressources humaines nécessaires pour
l’achèvement du projet. La sélection doit être fondée sur les descriptions de poste ou de fonction et prendre
en compte les compétences et les références obtenues lors de leurs expériences antérieures.

Développer l'équipe de projet : ce processus vise à améliorer les compétences des membres de l’équipe
afin d’augmenter leur capacité à achever les activités du projet (actions de formation) ainsi que d’améliorer le
sentiment de confiance et de cohésion chez les membres de l’équipe afin d’augmenter la productivité en
renforçant le travail d’équipe.

Diriger l'équipe de projet : ce processus consiste à suivre la performance des membres de l'équipe, fournir
des retours d'information et résoudre les problèmes et coordonner les modifications des ressources en vue
d'améliorer la performance du projet. L’équipe de management de projet observe le comportement de
l’équipe, gère les conflits, résout les problèmes majeurs et évalue les performances des membres de
l’équipe.
2.6. Gestion des communications
L’objectif principal de ce domaine est de manager pertinemment l’information et la communication du projet afin
de fournir en temps utile aux personnes concernées les informations, fiables et validées, nécessaires à
l’accomplissement de leur mission et d’assurer, autant que nécessaire, la traçabilité des opérations.
2.6.2. Principales tâches du processus :
 Phase de préparation (phase 1) : Planification des communications :
Ce processus détermine les besoins d'information et de communication des parties prenantes du projet. Ce
processus donne lieu à un plan de management de la communication, ce plan stipule essentiellement les
besoins en communication des parties prenantes ; l’information à communiquer y compris le format, le contenu
et le niveau de détail ; la personne chargée de communiquer l’information ; la personne ou les groupes qui
recevront l’information ; les méthodologies ou les technologies utilisées pour transmettre l’information ; la
fréquence de communication ;…
Page 58
Première Partie

Diffusion de l'information : ce processus permet de mettre l'information nécessaire à la disposition des
parties prenantes du projet en temps voulu.

Établissement du rapport d'avancement : ce processus permet de collecter et diffuser les informations sur
la performance aux parties prenantes. Les rapports d’avancement organisent et récapitulent l’information
recueillie, et présentent les résultats de toutes analyses par rapport à la référence de base des mesures de
performance : coût, délais, qualité,…

Manager les parties prenantes : ce processus concerne le management des communications afin de
satisfaire les exigences des parties prenantes du projet et de résoudre les problèmes majeurs avec elles.
2.7. Gestion des risques
L’objectif des processus relatifs aux risques est de réduire au minimum l’impact d’évènements potentiels négatifs
et de profiter pleinement des opportunités qui se présentent dans un but d’amélioration.

Planification du management des risques : ce processus permet de décider comment planifier et exécuter
les activités de management des risques d'un projet. Ce processus donne lieu à un plan de management
des risques. Ce plan comprend : la méthodologie : approches, outils et sources de données pouvant être
utilisés pour exécuter le mangement des risques dans le projet ; les catégories des risques44 ; les rôles et
responsabilités : définition des responsables et des rôles de l’équipe de management des risques ; le budget
et planning : coûts nécessaires au management des risques et fréquence d’exécution.

Identification des risques : ce processus détermine quels risques pourraient avoir un impact sur le projet et
documente leurs caractéristiques. L'identification des risques est un processus itératif car de nouveaux
risques peuvent se révéler pendant que le projet progresse dans son cycle de vie. Ce processus donne lieu
à un registre des risques qui indique les risques identifiés ainsi que les principales causes à l’origine de ces
risques : conflit social, manque de ressources,....

Analyse qualitative des risques : ce processus consiste à hiérarchiser les risques pour une analyse ou une
action ultérieure (planification des réponses aux risques) en évaluant leur probabilité d'occurrence et leur
44
L’annexe 3 donne les catégories et les sous-catégories de risques typiques
Page 59
Première Partie
impact sur les objectifs du projet si ces risques se concrétisent effectivement. L'évaluation de la probabilité
des risques examine la vraisemblance que chaque risque spécifique se concrétise. L'évaluation de l'impact
des risques étudie leur effet potentiel sur un objectif du projet tel que le temps, le coût, le contenu ou la
qualité, que cet effet soit négatif en cas de menace ou positif en cas d'opportunité.

Analyse quantitative des risques : ce processus consiste à effectuer l'analyse chiffrée des effets des
risques identifiés sur l'ensemble des objectifs du projet. Ce processus utilise des techniques telles que la
simulation de Monte-Carlo et l'analyse par arbre de décision.

Planification des réponses aux risques : ce processus permet d'élaborer des options et des actions pour
améliorer les opportunités favorables aux objectifs du projet et réduire les menaces à leur encontre.
- Trois stratégies de réponse pour les risques négatifs (menaces) : 1. Eviter (Exemple : prolonger
l’échéance, réduire le contenu,..) ; 2. Transférer (Exemple : utilisation d’une assurance, d’une caution de
bonne exécution,…) ; 3. Atténuer : réduire à un seuil acceptable (Exemples : augmenter le nombre de
test, choisir un fournisseur qui a plus de référence,…)
- Trois stratégies de réponse pour les risques positifs (opportunités) : 1. Exploiter (Exemple : affectation
au projet de ressources expérimentées pour réduire les délais et améliorer la qualité) ; 2. Partager
l’opportunité ; remettre la propriété de l’opportunité au tiers le plus capable de saisir l’opportunité au
bénéfice du projet ; 3. Améliorer : augmenter sa probabilité et ses impacts positifs.
 Phase de réalisation (phase 2) : Surveillance et maîtrise des risques :
Ce processus consiste à suivre les risques identifiés, surveiller les risques résiduels, identifier les risques
nouveaux, exécuter les plans de réponse planifiés et évaluer leur efficacité tout au long du cycle de vie du projet.
2.8.Gestion des achats et approvisionnements
L’objectif des processus de gestion des achats et des approvisionnements est de permettre l’acquisition de
produits, de prestations ou de services à l’extérieur de l’organisme en charge du projet et qui sont nécessaires
pour l’exécution des activités du projet.

Planifier les approvisionnements : ce processus implique d'envisager s’il faut acheter, de quelle manière,
quoi acheter, en quelle quantité et à quel moment. Ce processus donne lieu au plan de management des
Page 60
Première Partie
approvisionnements, ce plan décrit le management des processus d'approvisionnement depuis l'élaboration
de la documentation des approvisionnements jusqu'à la clôture du contrat.

Planifier les contrats : Ce processus prépare les documents nécessaires au soutien des processus
« Solliciter des offres ou des propositions des fournisseurs » et « Choisir les fournisseurs » ; il s’agit
principalement des documents d’approvisionnement et des critères d’évaluation.

Solliciter des offres ou des propositions des fournisseurs : ce processus est destiné à obtenir des
réponses, telles que les offres et les propositions des fournisseurs éventuels, sur la manière de satisfaire aux
exigences du projet.
Les offres sont les documents, préparés par les fournisseurs, qui décrivent leur capacité et leur volonté de
fournir les produits, les services ou les résultats demandés qui sont décrits dans la documentation
d'approvisionnement.

Choisir les fournisseurs : ce processus consiste à recevoir les propositions ou les offres et à les examiner
en fonction des critères d'évaluation applicables, afin de choisir un ou plusieurs candidats qui soient à la fois
qualifiés et acceptables comme fournisseurs. Une liste restreinte des candidatures retenues peut être établie
en fonction des offres préliminaires. Une évaluation plus détaillée peut alors être effectuée à partir des offres
plus détaillées et plus complètes qui sont demandées aux fournisseurs retenus sur cette liste restreinte.
Les fournisseurs choisis sont ceux qui ont été jugés être dans une fourchette compétitive d'après le résultat
de l'évaluation des offres ou des propositions, et qui ont négocié un projet de contrat qui deviendra le contrat
réel à l’issue de la décision d'attribution.

Administration du contrat : ce processus permet de s'assurer que la performance du fournisseur respecte
les exigences contractuelles et que l'acheteur agit conformément aux termes du contrat. Ce processus peut
amener à des actions correctives afin d’amener le fournisseur à se conformer aux termes du contrat.
 Phase de clôture (phase 3) : Clôture du contrat :
Il s’agit d’achever et effectuer le règlement final de chaque contrat. Les réclamations non résolues peuvent faire
l’objet de litiges après la clôture du contrat. Les termes et conditions du contrat peuvent prescrire des procédures
spécifiques pour sa clôture. La résiliation prématurée d'un contrat est un cas particulier de clôture de contrat et
peut avoir lieu suite à un accord mutuel entre les parties ou d'une carence de l'une d'entre elles. Les droits et les
responsabilités des parties en cas de résiliation prématurée sont stipulés dans une clause de résiliation du
contrat.
Page 61
Première Partie
2.9. Gestion de la qualité du projet45
Les processus de management de la qualité du projet permettent de s’assurer que la politique interne, les
processus, les procédures et les règles de projet de l’entreprise réalisatrice peuvent conduire le projet à réponde
aux besoins pour lesquels il a été entrepris.
 Phase de préparation (phase 1) : Planification de la qualité :
Ce processus comprend l’identification des normes qualité pertinentes pour le projet et la détermination des
moyens pour les respecter. Cette planification donne lieu à un plan de mangement de la qualité qui définit
comment l’équipe de mangement de projet va mettre en œuvre la politique qualité dans le projet.

Mettre en œuvre l'assurance qualité : il s’agit de l’application des activités planifiées et systématiques de
qualité afin de s’assurer que le projet utilise tous les processus requis pour répondre aux exigences.
L’amélioration continue des processus permet de réduire les gaspillages et les activités sans valeur ajoutée
et maximiser l’efficience et l’efficacité de la politique interne, des processus et des procédures de l’entreprise
réalisatrice. Un département d’assurance qualité supervise souvent les activités d’assurance qualité.
La mise en œuvre de l’assurance qualité passe par les audits qualité : il s’agit d’une revue structurée et
indépendante pour déterminer si les activités du projet respectent la politique interne, les processus, les
procédures et les règles de projet. L’objectif de cet audit étant d’identifier les aspects de la politique interne,
les procédures et les processus inefficaces et improductifs qui sont utilisés dans le projet.

Mettre en œuvre le contrôle qualité : il s’agit de surveiller des résultats spécifiques du projet pour
déterminer s'ils sont conformes aux normes qualité applicables, et identifier des moyens pour éliminer les
causes de performance insatisfaisantes. Les normes qualité comprennent les processus du projet et les
objectifs du produit. Les résultats de projet incluent les livrables et les résultats de mangement de projet tel
que les performances en termes de coût et de délais. Le contrôle qualité est exécuté par un département de
contrôle qualité.
45
Ce processus n’a pas été traité par les normes AFNOR.
Page 62
Première Partie
SECTION 2 : DÉMARCHE ILLUSTRÉE DE MISE EN PLACE D’UN
GLOBAL BANKING
Cette section essaye de présenter une démarche pratique d’implémentation d’une solution de Global Banking.
Trois phases principales ont été prévues par la littérature pour l’implémentation d’une solution de type ERP :

Phase 1 : phase de lancement (Paragraphe 1)

Phase 2 : phase de configuration et d’homologation de la solution (Paragraphe 2)

Phase 3 : phase de déploiement et mise en production (Paragraphe 3)
Des exemples ou des cas pratiques seront fournis lors de la description de ces phases pour illustrer et mettre
l’accent sur les spécificités de la mise en place d’un Global Banking.
Paragraphe 1 : Phase de lancement
Cette phase, à I’origine de I'implantation de tout projet, a pour but de supporter l'exécution de l'ensemble des
activités du projet. Les normes de gestion de projet ont mis l’accent sur l’importance de cette phase pour la
réussite du projet. Le principal livrable de cette phase est le plan de mangement du projet (1). Cette phase inclut
toutes les activités de préparation des moyens nécessaires à la réalisation du projet (2)
1. Le plan de management du projet
Le plan de management du projet représente tout au long de l’implantation le référentiel qui fournit la visibilité
nécessaire aux équipes du projet, au management et aux différentes parties prenantes l’état d’avancement des
travaux. Grâce à ce plan, il sera possible de lire, comprendre et prévoir les activités, les réalisations et les
problèmes potentiels. Les principales informations fournies par ce plan sont : le périmètre fonctionnel du projet ;
la stratégie de bascule ; le planning de mise en place ; l’organigramme du projet et les instances de pilotage ; le
plan des risques du projet ; le budget et les méthodes de reporting et de communication.
1.1. Périmètre fonctionnel du projet
Les solutions de type ERP disposent d’une large couverture fonctionnelle, le plan de mangement doit délimiter
ce périmètre fonctionnel. La définition précise du périmètre fonctionnel est une étape indispensable à la réussite
d’un projet ERP. Un périmètre large présente l’avantage de réduire les interfaces et exploiter les capacités
d’intégrations offertes par la solution et l’inconvénient d’augmenter les difficultés de mise en place : une
organisation plus large, un délai plus étendu,…
Page 63
Première Partie
Le périmètre fonctionnel des solutions de Global Banking couvre les domaines suivants :

Module système central : comptabilité et générateur de reporting

Module agence : opérations de caisse, placements et dépôts,…

Module engagements : autorisations, crédits amortissables, crédits de gestion,…

Module cautions et garanties

Module moyens de paiement : chèques, effets, virements, prélèvements, télécompensation,…

Module étranger : transferts, crédits documentaires, remises documentaires,…

Module commercial et canaux de distribution : CRM, serveur vocal, E-banking, SMS,…

Module recouvrement et contentieux.

Module trésorerie : change, marchés monétaires, swaps, dérivés, titres,…

Modules activités de support : Ressources Humaines, Immobilisations, achats et stocks, contrôle budgétaire
1.2. Stratégie de bascule
Les grandes lignes de la stratégie de bascule doivent être définies dans le plan de management du projet.
Toutes les étapes de planification et de réalisation de la solution dépendent de la stratégie de bascule retenue.
On distingue entre deux types de stratégie de bascule :

La bascule « big bang »: déploiement complet de la solution sur toutes les agences.

La bascule progressive : déploiement progressif de la solution sur des lots d’agences. La phase de
déploiement est appelée phase transitoire. Durant cette phase la banque fonctionne avec deux systèmes.
Le choix entre ces deux stratégies dépend essentiellement du nombre d’agences : plus le nombre d’agences est
important, plus la bascule « big bang » devient inappropriée. La bascule « big bang » comporte un certain
nombre de risques :

La gestion de changement pour un nombre important d’agences en parallèle demande des ressources
importantes notamment en formateurs et « help desk ». Généralement, les banques ne sont pas en mesure
de rendre disponible ce nombre important de ressources.

L’impact des dysfonctionnements identifiés après la bascule « big bang » devient très important pour la
banque et peut engendrer des conséquences graves qui peuvent mettre en cause la fiabilité des traitements
et des opérations.
La bascule progressive de son coté, présente l’inconvénient d’augmenter le nombre d’interfaces à développer
pour assurer l’interaction entre les deux systèmes durant la phase de déploiement ainsi que le nombre des
processus à tester : de nouveaux processus doivent être paramétrés ou développés et testés (exemple : retrait
espèce déplacé entre deux agences qui ont deux systèmes différents)
Les travaux exposés dans ce mémoire supposent une stratégie de bascule progressive.
Page 64
Première Partie
1.3. Planning de mise en place
Une fois le périmètre fonctionnel est délimité, il convient de définir le planning de mise en place. Ce planning
indique :

les principales phases du projet ;

les activités appartenant à chacune des phases du projet ;

le séquencement et les liens entre les activités du projet ;

les ressources nécessaires pour chaque activité ;

les livrables ou les résultats attendus de chaque activité ;

le temps nécessaire pour chaque activité.
Modèle de macro-planning et calendrier de mise en place
N°
Jalons
1 Constitution des équipes du projet
MOA
MOE
R
2 Commande des matériels et logistique
3 Installation Hardware, système
environnements
4 Livraison et installation du progiciel
et
Editeur
R
Daté début
Date Fin
R
préparation
des
R
M
M
R
5 Formation des équipes projet
M
M
R
6 Analyse détaillée des écarts (Gaps)
R
R
R
7 Définition du paramétrage
R
R
R
8 Paramétrage et tests unitaires des paramétrages
S
S
R
9 Développements spécifiques et tests unitaires
S
S
R
10 Développement et tests unitaires des interfaces
R
S
11 Développement et tests unitaires des outils de migration
R
S
12 Recette provisoire de la solution
R
S
M
13 Correction des anomalies de recette
M
M
R
14 Tests de correction des anomalies de recette
R
S
M
15 Tests de migration et simulation bascule
S
R
S
16 Bascule agence pilote
S
R
S
17 Formation des formateurs
S
18 Formation des utilisateurs
R
19 Adaptation des processus et support au changement
R
R
M
20 Recette définitive de la solution
R
M
21 Déploiement
R
M
R- Responsable de l’activité
S- Support au responsable de l’activité
M- Minimum d’implication requis (principalement pour transfert de compétences)
MOA : Equipe de maîtrise d’ouvrage (Equipes fonctionnelles)
MOE : Equipe de maîtrise d’œuvre (Equipes informatiques)
Page 65
Première Partie
1.4. L’organigramme du projet et les instances de pilotage
1.4.1. Organigramme du projet :
Un projet de Global Banking se construit principalement autour des 8 structures suivantes :
(1) Une équipe fonctionnelle : cette équipe a la charge du paramétrage de la solution et des tests. Exemples :
chantier comptabilité et référentiel, chantier opérations agence, chantier moyens de paiement, chantier
engagements et garanties, chantier opérations internationales,…
(2) Une équipe de développement : cette équipe prendra en charge les développements d’interface, de reprise
des données et des éditiques. Trois chantiers techniques à mettre en place : chantier reprise des données,
chantier interfaces et chantier éditiques et reportings.
(3) Une équipe d’architecture technique : elle a la charge de dimensionner et d’administrer l’environnement
technique.
(4) Une équipe exploitation : elle a la charge d’exécuter les travaux relatifs à l’exploitation de l’ERP (transferts de
fichier, intégration de lot, exécution de procédure, lancement de traitement fin de journée,…)
(5) Une équipe de coordination de la gestion du changement et de la communication : cette équipe a la charge
de définir l’impact de la solution sur l’organisation, de définir et mettre en place des procédures, de préparer
et assurer des formations et d’assurer la communication interne et externe.
(6) Une équipe de coordination des recettes : préparer et piloter la recette utilisateurs qui permet de s’assurer
que l’application répond correctement aux besoins exprimés par les utilisateurs.
(7) Une équipe de coordination de la bascule : élaborer les plans de bascule, assurer le pilotage des bascules à
blanc et des bascules réelles.
(8) Un project management office (PMO) : Le PMO permet d’assurer le respect des méthodologies de gestion
de projet ainsi que de fournir un support méthodologique et documentaire pour les différents intervenants
dans le projet.
Cet organigramme inclut aussi bien des intervenants internes de l’entreprise (informaticiens, experts métiers, les
équipes de l’organisation,…) que des intervenants externes (éditeur et autres consultants externes).
1.4.2. Gouvernance et instances du pilotage du projet :
Le pilotage d’un projet s’articule généralement autour des instances suivantes :

Comité de pilotage : ce comité a pour objet de s’assurer du bon avancement opérationnel du projet et du
respect des moyens. Ce comité est composé de membres de la direction générale, du chef du projet, de la
direction informatique, des directeurs des entités opérationnelles (finances, exploitation,…) ainsi que des
représentants de l’éditeur et de l’intégrateur.
Page 66
Première Partie

Réunions de chantier : elles ont pour but de s’assurer du bon avancement de chaque chantier fonctionnel
ou technique.

Réunion d’information de l’équipe projet : elle a pour but d’informer l’ensemble des membres et parties
prenantes sur l’état d’avancement.
1.5. Plan des risques du projet
Le plan des risques s’intéresse aux risques de très haut niveau et qui peuvent avoir un impact sur la bonne
marche générale du projet, sur la qualité des livrables ou sur la date de mise en production. A chaque risque
identifié, il faut estimer la probabilité de réalisation, le niveau d’impact sur le projet et la description des mesures
à prendre. Parmi les risques les plus répandus dans l’implantation d’un ERP, on peut citer :

la disponibilité insuffisante des experts opérationnels ;

le manque d’implication ou de support du management ;

le manque de délimitation du périmètre fonctionnel ;

l’importance des développements spécifiques.
1.6. Le budget
Un macro-chiffrage doit être fourni au niveau du plan de mangement du projet de la totalité des coûts du projet :
licences, infrastructures techniques, poste de travail, coût des ressources externes, coût des ressources internes
et coût de la logistique sur la durée du projet.
1.7. Méhodes de reporting et de communication
Une bonne communication est nécessaire pour la réussite du projet. La communication a pour objectif de
générer l’adhésion d’une part des responsables des services opérationnels qui seront impactés par la solution et
d’autre part des utilisateurs finaux. L’effort de communication évoluera en fonction des cibles qui sont d’une part
les personnes qui participent au projet ou qui seront impactées par le projet et d’autre part les personnes de
pilotage du projet. Pour la première cible ; le besoin en communication évolue au fur et à mesure de
l’avancement du projet : tout d’abord l’équipe du projet puis les responsables des activités impactées puis les
collaborateurs des activités impactées et enfin les clients et autres partenaires. Pour les personnes de pilotage,
elles ont un besoin permanent en information tout au long du projet.
Les outils de communication sont nombreux : journal interne, réunion d’information, évènement, flash report,…
Le contenu du plan de communication est fourni au niveau du paragraphe 1 (point 2.6.2).
Page 67
Première Partie
2. Activités préparatoires à la réalisation de la solution
Durant la phase de lancement, il faut s’assurer que l’ensemble des éléments dont l’implantation d’un ERP aura
besoin sont disponibles et prêts à fonctionner. Parmi ces éléments on mettra l’accent sur : le lieu de déroulement
des activités du projet ; la base documentaire du projet ; la plate-forme technique ; la mise à disposition et la
formation de l’équipe projet ; l’inventaire des procédures actuelles et des procédures cibles ; le catalogue des
produits et des conditions ; la cartographie des systèmes d’information existants ; la réunion de lancement.
2.1. Lieu de déroulement des activités du projet
Dans la mesure où un projet de Global Banking fait appel à un nombre important de ressources, un lieu de travail
doit être exclusivement dédié aux activités du projet. De préférence que la répartition des salles de travail se fait
en fonction de la répartition des chantiers fonctionnels et techniques. Les activités du projet doivent être
exercées dans la mesure du possible d’une manière séparée des activités courantes de la banque. Bien entendu
le lieu de travail doit être équipé de tous les équipements nécessaires au déroulement des activités du projet :
des rétroprojecteurs, des postes de travails suffisants, des tableaux,…
2.2. Base documentaire
L’ensemble de la documentation, notes, comptes rendus, fournis ou réalisés dans le cadre du projet devront être
centralisés dans une base documentaire automatisée accessible par les membres du projet selon des règles
d’habilitation à définir.
2.3. la plate-forme technique
Le projet de mise en place d’un Global Banking donne lieu à une mise à niveau de l’infrastructure technique de la
banque. Cette mise à niveau est dans la plupart du temps d’ordre contractuel. En effet, il est stipulé au niveau du
contrat avec l’éditeur de la solution que les exigences de performance en termes de temps des traitements batch
ou de temps de traitement des transactions simples ou complexes ou du taux d’occupation de la mémoire, ne
peuvent être réalisés que si une configuration minimale est mise en place. Cette configuration sera détaillée
également au niveau du contrat et concerne à la fois : l’appareil de production, l’appareil de backup, les postes
de travail des utilisateurs et l’architecture réseau. Pour bénéficier des évolutions éventuelles, il n’est pas
nécessaire que l’appareil de production soit disponible depuis le lancement du projet, les travaux de réalisation
peuvent démarrer sur un serveur moins puissant et qui sera utilisé par la suite comme un serveur de backup.
2.4.
Libérer et former de l’équipe projet
Libérer des opérationnels n’est pas une chose facile, il s’agit ici d’une tâche prioritaire de la direction du projet. Il
existe beaucoup de difficultés pratiques pour convaincre les intéressés et leur hiérarchie de quitter l’activité
Page 68
Première Partie
opérationnelle et rejoindre le projet pour une période de plus d’un an. Les expériences ont montré que la réussite
du projet dépend en grande partie de la qualité et la disponibilité des ressources notamment les experts métiers.
Une fois constituée, l’équipe de projet doit subir une formation afin qu’elle puisse acquérir un niveau de
connaissance suffisant. Il s’agit essentiellement de donner aux acteurs du projet la connaissance des outils qu’ils
vont utiliser tout au long de l’implantation ainsi qu’un bon niveau d’expertise dans les modules de l’ERP.
On distingue généralement entre quatre types de formation pour les équipes de mise en œuvre : sensibilisation,
navigation, utilisation et configuration.
(1) Formation de sensibilisation : elle consiste à donner aux intervenants une formation approfondie du module
dont ils sont responsables mais également des autres modules pour appréhender les flux entre les modules.
(2) Formation de navigation : elle permet aux utilisateurs de comprendre l’utilisation du poste de travail telle qu’il
est prévu par la solution : les fonctions du clavier, les menus, les icônes, les types d’affichage,…
(3) Formation d’utilisation : elle assure aux équipes la compréhension détaillée des fonctionnalités couvertes par
le module, de leur architecture, des données et des processus en jeu.
(4) Formation de configuration : elle consiste à étudier toutes les options, tous les paramètres et tous les choix
qui sont contenus dans un module. Cette formation aura lieu lors de la phase de configuration de la solution.
L’équipe d’infrastructure technique a également un besoin en formation pour pouvoir mettre en place les
composantes technique du nouvel environnement : plateforme matérielle, le système d’exploitation, la gestion du
réseau, le système de gestion de base de donnée, l’environnement de développement de l’ERP,…
L’éditeur de la solution est le responsable de toutes ces actions de formation. L’existence de guides utilisateurs
et de guides de paramétrage permettra de faciliter la réalisation de ces actions.
2.5. Inventaires des procédures actuelles et des procédures cibles
C’est pendant cette phase que les équipes projet vont définir les processus opérationnels qui seront ensuite
configurés. Certes des aménagements seront apportés durant l’implantation, mais la majorité des processus sont
définis dans cette phase. Quatre composantes interagissent dans la définition des processus :
(1) Les processus déjà utilisés dans la banque, il s’agit des processus « en cours »,
(2) Les processus que la banque souhaite utiliser demain, ce sont les processus « en devenir »,
(3) Les processus que l’ERP autorise par son architecture et ses fonctionnalités : processus « possibles »,
(4) Les processus qui seront effectivement implantés, ceux-ci résultent des trois domaines précédents.
Cette étape se chevauche avec l’étape de formation des équipes de projet, en effet l’apprentissage de la solution
ouvre des horizons qui peuvent modifier et améliorer la perception des processus « en devenir » que l’entreprise
planifie d’implanter.
Page 69
Première Partie
2.6. Catalogue des produits et services et leurs règles de gestion
Les banques offrent une panoplie de produits et services à leur clientèle. Chacun de ces produits et services
comporte des règles de gestion : conditions (tarifs, date valeur,…), profils de clientèle éligibles et autres
conditions d’éligibilité, canal de distribution, contraintes règlementaires, documents et garanties nécessaire,…
L’établissement de ce catalogue est un préalable nécessaire pour la configuration de la solution.
2.7. Cartographie des systèmes d’information existant
Il s’agit d’établir une cartographie des applications existantes, des interfaces, des plates-formes techniques qui
les supportent et des flux d’informations autour des bases de données. Ceci permettra dans les phases
suivantes d’apprécier le contexte d’intégration entre le progiciel et les autres applications éventuellement pour la
phase transitoire ou également pour la phase cible si des modules n’ont pas été inclus dans le périmètre du
projet et vont continuer à fonctionner dans les anciens systèmes.
2.8. La réunion du lancement
Le projet de changement de système d’information doit être perçu comme un projet d’entreprise et non pas un
projet informatique. C’est à travers la réunion de lancement que la direction générale et les directions
opérationnelles pourront prendre l’opportunité de montrer leur implication totale et leur détermination pour une
pleine réussite du projet. Tous les acteurs internes et externes du projet doivent être présents. Les objectifs
majeurs du projet doivent être clairement communiqués par le management du projet, compris et partagés par
tous les acteurs. L’organigramme du projet, les rôles et les responsabilités sont officiellement présentés lors de
cette réunion. Les grandes phases du projet sont également présentées.
Paragraphe 2 : La configuration et l’homologation de la solution
Au cours de cette phase, la solution sera paramétrée et validée afin qu’elle soit prête pour être déployée au
niveau de toutes les agences. Les principales étapes de cette phase sont :

le paramétrage et l’identification des écarts fonctionnels (Gap) (1) ;

la réalisation des développements : programmes de reprise des données, d’interfaces,… (2) ;

la phase d’homologation de la solution et les simulations de bascule (3).
1. Paramétrage et identification des écarts fonctionnels
Chaque module du progiciel inclut plusieurs fonctionnalités et plusieurs options de paramétrage. La solution sera
paramétrée de manière à appliquer les processus cibles définis par la banque durant la phase de lancement
(1.1). Les écarts entre les fonctionnalités et les options permises par la solution et les besoins fonctionnels de la
banque seront identifiés lors de cette étape (1.2).
Page 70
Première Partie
1.1.
Réalisation du paramétrage
La réalisation du paramétrage est la responsabilité des chantiers fonctionnels. Ces paramétrages sont réalisés
dans un premier temps sur un environnement de test appartenant à chaque chantier. Une fois testé et validé par
les équipes de mise en place, le paramétrage sera porté sur l’environnement de référence. Cet environnement
inclut tous les paramétrages validés par les différentes équipes de mise en place. L’environnement de référence
va servir par la suite à la réalisation des tests d’homologation ou de simulation de bascule.
Les pré-requis pour la réalisation du paramétrage de la solution sont :

La compréhension des fonctionnalités détaillées du progiciel, des options de paramétrage et de la
méthodologie de paramétrage (écrans, menus, scripts,…) : cette compréhension sera assurée
principalement par des actions de formation réalisées par les consultants fonctionnels de l’éditeur ainsi que
par les guides de paramétrage établis également par l’éditeur de la solution.

L’identification des processus cibles de la banque. La compréhension de ces processus permettra de
déterminer les besoins fonctionnels de la banque.
En cas d’inadéquation des fonctionnalités du progiciel avec les processus désirés par la banque, la banque doit
faire le choix entre l’adaptation de ses processus avec les options permises par le progiciel, ou la modification du
progiciel pour supporter les besoins de la banque (Cf. page 73, point 1.2).
Lors de cette phase, des décisions doivent être prise dans le choix des options de paramétrage. Ces décisions
doivent être correctement documentées en présentant les avantages et inconvénients de chaque option. La
préparation de ces fiches de décision est du ressort de l’équipe de mise en place, la prise de décision est du
ressort des responsables des unités opérationnelles et le cas échéant de la direction générale ou du comité du
pilotage. Les profils des utilisateurs et les habilitations correspondantes seront également définis et paramétrés
au cours de cette phase.
Avant d’être porté sur l’environnement de référence, le paramétrage doit faire l’objet de tests unitaires. Ces
tests permettent de s’assurer du :

fonctionnement unitaire des règles de gestion ;

fonctionnement unitaire du schéma comptable associé à la règle de gestion ;

fonctionnement des contrôles et des messages d’erreurs ;

adéquation de l’interface graphique (ergonomie, libellé,…) ;

fonctionnement unitaire des éditions liées.
Suite aux tests unitaires, trois situations peuvent avoir lieu :
(1) Le paramétrage effectué donne satisfaction et permet de répondre au besoin de la banque : ce paramétrage
sera porté sur l’environnement de référence.
Page 71
Première Partie
(2) Le paramétrage effectué ne donne pas satisfaction suite à une erreur de paramétrage : il y a lieu de corriger
le paramétrage et refaire les tests unitaires.
(3) Le paramétrage effectué ne donne pas satisfaction suite à un écart fonctionnel non identifié lors du premier
paramétrage : dans ce cas un arbitrage doit se faire entre l’adaptation aux options du progiciel ou la
demande de développement spécifique.

Exemple de planning des travaux de paramétrage pour le chantier comptabilité
Chantier comptabilité
1. Formation
1.1. Comptabilité Générale
1.2. Arrêtés de comptes
1.3. Lettrage
1.4. Rapprochements bancaires
1.5. Réévaluation
1.6. Reporting et générateurs de reporting
1.7. Opérations Diverses
2. Analyse
2.1. Définition de la structure des identifiants des comptes
2.2. Elaboration du plan comptable cible
2.3. Définition des produits comptes et des règles de fonctionnement
2.4. Définition des règles d'arrêté de compte (intérêts débiteurs, intérêts créditeurs, frais,…)
2.5. Définition des comptes soumis au lettrage et des règles de lettrage
2.6. Définition des comptes bancaires et des règles de rapprochement bancaires
2.7. Définition des règles de réévaluation
2.8. Détermination de la liste des reportings
3. Paramétrage & tests unitaires
3.1. Paramétrage du plan des comptes
3.2. Paramétrage des produits comptes
3.3. Paramétrage des règles d'arrêté de compte : méthodes de calculs et autres paramètres
3.4. Paramétrage des conditions générales d'arrêté des produits comptes
3.5. Paramétrage des schémas de comptabilisation des arrêtés de compte
3.6. Tests calcul d'arrêté des comptes
3.7. Tests comptabilisation des arrêtés des comptes
3.8. Tests des éditions relatives aux arrêtés des comptes
3.9. Paramétrage des comptes soumis au lettrage : comptes inter-agence ou intra-agence
3.10. Paramétrage des règles de lettrage : critère de lettrage, éditions de lettrage,…
3.11. Tests du lettrage
3.12. Paramétrage des comptes soumis au rapprochement bancaire
3.13. Paramétrage des règles de rapprochements bancaire
3.14. Tests de rapprochement bancaire
3.15. Paramétrage des règles de réévaluation
3.16. Paramétrage des schémas de comptabilisation de la réévaluation
3.17. Test de calcul et de comptabilisation de la réévaluation
3.18. Tests des reportings natifs fournis par le progiciel (Balance, grand livre,…)
Jour
estimé
91
9
1
3
1
1
1
1
1
34
1
15
5
5
2
2
1
3
48
1
1
2
2
2
15
5
2
1
1
2
1
1
3
1
1
2
5
Page 72
Première Partie

Exemple de planning des travaux de paramétrage pour le chantier Engagements
:
Chantier Engagements
1. Formation
1.1. Crédits amortissable
1.2. Autorisation de découvert et autres autorisations
1.3. Assurances liées aux crédits
1.4. Cautions
2. Analyse
2.1. Elaboration des fiches de produits crédits
2.2. Elaboration des fiches de produits caution
2.3. Elaboration fiches produits assurances liés au crédit
2.4. Processus d'octroi de crédit
3. Paramétrage
3.1. Paramétrage des produits crédits
3.2. Paramétrage des paramètres généraux des crédits
3.3. Paramétrage des schémas de comptabilisation des crédits
3.4. Test du cycle de vie de crédit : autorisation, déblocage, échéance, règlement anticipé, gestion impayé,…
3.5. Paramétrage des produits cautions
3.6. Paramétrage des paramètres généraux des cautions
3.7. Paramétrage des schémas de comptabilisation des cautions
3.8. Test du cycle de vie des cautions : engagement, blocage de fonds, main levée, exécution,...
3.9. Paramétrage des assurances liées aux crédits
3.10. Tests du fonctionnement et de comptabilisation des assurances
3.11. Paramétrage des règles de fonctionnement des autorisations de découvert
3.12. Test de fonctionnement et de comptabilisation des autorisations de découvert
3.13. Paramétrage des autres types d'autorisation : autorisation d'escompte, autorisation de caution,…
3.14. Test de fonctionnement et de fonction des autres types d'autorisation
1.2.
Jour
Estimé
116
9
3
2
1
3
18
5
5
3
5
89
5
3
3
25
5
3
3
20
2
5
2
5
3
10
Identification des écarts fonctionnels (Gap)
Est considéré comme écart fonctionnel (gap), toute différence entre les processus possibles du nouveau
progiciel et les processus actuels mis en œuvre dans la banque. Ces écarts peuvent aussi bien être
«positifs» dans le cas où la nouvelle solution apporte une amélioration : automatisation de procédure,
enrichissement des informations,… que «négatifs» lorsque la nouvelle solution ne permet pas de traiter un
processus selon la manière exigée par la banque.
Dans la mesure où le coût des développements spécifiques est important aussi bien en termes du coût financier
qu’en termes de délai de réalisation et de tests, les écarts recensés doivent passer par un processus de
validation afin d’éviter tout développement inutile. Ce processus doit comporter une documentation des écarts
recensés ainsi qu’une exigence de validation par des instances habilitées. Dans certaines situations, il sera plus
opportun de s’adapter à ce qu’offre le progiciel plutôt d’engager des développements spécifiques.
Les écarts d’ordre règlementaire sont généralement incontournables et la banque se trouve dans l’obligation de
réaliser des développements.
Page 73
Première Partie
L’identification des écarts fonctionnels est réalisée depuis le choix de la solution et se poursuit tout au long du
projet. Certains écarts ne sont identifiés qu’après la mise en production de la nouvelle solution. L’essentiel des
écarts sont identifiés au cours de la phase de configuration et d’homologation. Les écarts recensés et validés
doivent faire l’objet de spécifications fonctionnelles détaillées afin de permettre la réalisation des
développements.
2. Développements
Au cours de la phase de configuration, plusieurs développements seront réalisés. Ces développements
concernent les domaines suivants : reprise des données (2.1) ; les interfaces (2.2) ; les éditiques et reportings
(2.3) ; les écarts fonctionnels (2.4).
2.1.
Reprise des données
Les développements des programmes des reprises des données nécessitent au préalable l’identification du
périmètre des informations à reprendre. On distingue entre deux types d’informations à reprendre :

les informations comptables : les soldes et les mouvements comptables,…

les informations extra-comptable : le référentiel client, les conditions tarifaires spéciales, les dossiers de
crédit, les dossiers de placement, les dossiers de caution,…
Les programmes de reprise des données sont construits autour des étapes suivantes :

extraction et récupération des informations nécessaires à partir des applications source ;

centralisation des informations collectées sur un serveur et une base centralisée ;

traitement des informations collectées : application de filtres, de matrice de correspondance, des valeurs par
défaut,…

réalisation de l’intégration : des contrôles automatiques permettent de s’assurer de la validité et de la
cohérence des données intégrées ;

comptabilisation des opérations de migration : application des schémas comptables de migration.
Il n’est pas obligatoire que tous les dossiers soient repris d’une manière automatique. En effet, en fonction de la
volumétrie, un arbitrage doit avoir lieu entre développement de programmes de reprise ou réalisation de reprises
manuelles. (Exemple : la reprise des caisses ne nécessite pas généralement un programme de reprise
spécifique).
Les développements des programmes de reprise sont réalisés au sein du chantier technique « reprise des
données ». Les membres de ce chantier doivent être formés sur l’architecture du progiciel et sur les outils de
Page 74
Première Partie
reprise. Les développements réalisés seront testés unitairement au sein du chantier. Des corrections doivent être
portées en cas de dysfonctionnement ou manque de contrôle identifié.
En parallèle aux activités de développement et tests unitaires des programmes de reprise, des chantiers de
fiabilisation doivent être entrepris par la banque. Cette fiabilisation a pour objectif d’assurer une cohérence entre
les informations extra-comptables et les soldes comptables. Les actions de fiabilisation consistent principalement
à : des inventaires physiques ; des rapprochements entre les inventaires physiques et les soldes extracomptables ; des rapprochements entre les soldes extra-comptables et les soldes comptables ; des
rapprochements entre les différentes sources de données (lorsque la même information existe dans plusieurs
applications). Les écarts identifiés doivent être traités au cas par cas : suppression du dossier, création du
dossier,…Bien entendu, toutes les actions de fiabilisation doivent faire l’objet d’une analyse et documentation
suffisante et doivent passer par un circuit de validation des structures habilitées.

Exemple de tableau de bord de suivi des développements des programmes de reprise des données
de dossiers Extra-comptable :
Analyse
Risque
Engagement
Moyens de Paiement
Agence
Chantier
Fonctionnel
Matière
1
Bon de caisse et compte à terme
2
Blocage extra
3
Condition de banque spéciale
4
Mises à disposition non apurés
5
Chèques de banque non apurés
6
Caisse dinars et devises
1
Encours escompte et encaissement effets
2
Stock des chéquiers
3
Interdit de chéquier
4
Incident de paiement chèque
5
Virements permanents
6
Demande de chéquiers
1
Encours Crédit
2
EPS (caution + aval)
3
Impayé crédit
4
Autorisation de découvert
5
Convention
1
Garanties réelles et financières
2
Classe de risque
3
stock agios réservés
4
stock provision
5
client contentieux
Volumét
rie (nbre
dossier)
Source
Spécification (% avancement)
Approche
(automatique /
manuelle)
Mapping
Règles
de
reprise
Outils de
contrôle
Dév &
Tests
unitaires
(%)
Recette
(%)
Page 75
Première Partie
2.2.
Les interfaces
Quelle que soit la largeur de palette fonctionnelle d’un progiciel et quel que soit le nombre de modules qui seront
implantés, le progiciel a toujours besoins de coexister avec d’autres systèmes de l’entreprise soit parce que la
fonctionnalité requise n’existe pas dans le progiciel, soit que la solution de la banque est mieux adaptée à ses
besoins. Le nombre d’interfaces dépend essentiellement du périmètre fonctionnel du progiciel et de la stratégie
de bascule. Dans le cas d’une bascule progressive par lots, le nombre d’interfaces va augmenter, on parle ici
« d’interfaces jetables » qui seront utilisées uniquement durant la phase transitoire puis elles seront
abandonnées après la bascule de toutes les agences.
Plusieurs natures d’informations seront échangées à travers ces interfaces : mouvements comptables ; données
clients : information sur les clients ; données comptes : soldes, mouvements,… ; données dossiers de crédits et
autres dossiers,… ; fichiers de télécompensation,…
Les spécifications fonctionnelles d’une interface doivent prendre en compte les paramètres suivants :

niveau d’automatisation : totalement automatique, partiellement automatique, totalement manuelle ;

application source et application cible ;

sens unique d’échange ou sens double ;

fréquence d’échange ;

nature des données à transmettre ;

nature des traitements à faire.
Le développement des interfaces constitue une tâche délicate qui nécessite une parfaite connaissance
fonctionnelle et architecturale des deux extrémités. La participation de l’éditeur est requise pour l’extrémité du
progiciel et celle des informaticiens de la banque pour l’autre extrémité soit les systèmes de la banque.
Ces développements seront réalisés au sein du chantier technique « Interfaces ». Ce chantier sera également
responsable de la réalisation des tests unitaires des interfaces développées.
 Exemples d’interfaces :
Application Source
Gestion moyens généraux
Application monétique
Gestion trésorerie
Gestion trésorerie
Progiciel
Progiciel
Scénarisation des chèques
Scénarisation des effets
Télé compensation effets
Télé compensation chèques
Progiciel
Progiciel
Application Cible
Progiciel
Progiciel
Progiciel
Progiciel
serveur vocal
Web banking
Progiciel
Progiciel
serveur vocal
Progiciel
Télé compensation chèques
Télé compensation effets
Description de l'interface
Mouvements comptables
Fichier cours de change
Solde du compte /infos compte
Données clients + données comptes : soldes + mouvements
Liste des chèques scannés
Liste des effets scannés
Effets (reçus des confrères + rejet des confrères)
Chèques (reçus des confrères + rejet des confrères)
Chèques (présentation + nos rejets) interbancaire
Effets (présentation + nos rejets) interbancaire
Page 76
Première Partie
2.3.
Les éditiques et reportings
Les progiciels offrent généralement un certain nombre d’états natifs qui ne répondent pas totalement aux besoins
spécifiques de la banque. Le chantier technique « Editiques et Repoting » aura la charge de développer les
éditions non couvertes par le progiciel et de mettre en forme les éditions natives du progiciel (Excel, Acrobat
Reader, Word, csv,…)
A l’instar du reste des chantiers, le chantier « Editiques et Repoting » doit avoir une formation sur les outils de
développement des éditions, cette formation est dispensée par les consultants de l’éditeur.
Les besoins en états doivent être exprimés par les chantiers fonctionnels qui fournissent également les
spécifications détaillées des états demandés.
Des tests unitaires seront réalisés par le chantier « Editique et Reporting » qui permettront de valider les
développements réalisés.
 Exemples d’éditions et reporting à réaliser
Chantier
Agence
Agence
Agence
Agence
Comptabilité
Comptabilité
Comptabilité
Comptabilité
Engagements
Engagements
Engagements
Moyens de paiement
Moyens de paiement
Moyens de paiement
Moyens de paiement
Moyens de paiement
2.4.
Etat
Extrait de compte à la demande
Etat arrêté de caisse
Demande de chèque certifié
Etat des chèques de banque
Situation mensuelle comptable
Bilan et état de résultat
Relevé de compte mensuel
Echelle d’intérêts
Tableau d'amortissement
Titre de crédit
Etat des cautions par client
Etat des virements émis
Etat des effets payés
certificat de non paiement de chèque
Etat global des prélèvements émis
Etat des chèques reçus pour paiement
Les écarts fonctionnels (Gap)
Suite à l’identification et la validation des écarts fonctionnels, des spécifications détaillées seront rédigées par les
chantiers fonctionnels. Les développements sont réalisés généralement chez l’éditeur de la solution puis livrés
aux chantiers fonctionnels pour réaliser les tests unitaires. En cas de confirmation, les modifications de
programmes seront portées à la version de référence qui inclut également les paramétrages validés. La livraison
des développements doit faire l’objet de priorisation en fonction du caractère critique et obligatoire de la
modification demandée. Pour les livraisons dont l’échéance vient après la mise en production du progiciel, la
banque doit identifier des solutions de contournement permettant un fonctionnement normal : comptabilisation
par OD, utilisation de requête,…
Page 77
Première Partie
3. L’homologation de la solution
Les principaux objectifs de la phase d’homologation sont :

valider le système d’information en configuration phase transitoire et en configuration cible (3.1).

valider le processus de migration des données vers le nouveau système d’information (3.2).

valider la performance et la robustesse de l’architecture technique du système d’information cible (3.3).
3.1. Tests d’homologation ou de recette
Les tests d’homologation sont des tests effectués par des équipes indépendantes, des équipes de paramétrage
permettant de s’assurer de la capacité du nouveau système d’information constitué du progiciel et applications
interfacées à supporter les processus opérationnels de la banque. La réalisation de ces travaux doit suivre la
démarche suivante :
 Validation de la liste des processus opérationnels : il y a lieu de documenter aussi bien les processus
cibles que les processus transitoires. Les applications et les modules nécessaires à l’exécution de chaque
étape de processus doivent également être documentés.
 Rédaction des scénarios de recette pour chaque processus : il s’agit de déterminer les différentes
variantes d’un processus. Ces scénarios doivent décrire : les étapes détaillées du scénario ; le résultat
attendu de chaque étape ; les acteurs de chaque étape ; les modules et applications à utiliser.
Les scénarios de recette sont établis par les chantiers fonctionnels.
 Etablissement des cas de tests : le cas de test est une application d’un scénario de recette à une donnée
de la base de test. Les tests seront réalisés aussi bien sur des données migrées ou saisies directement sur le
nouveau système d’information.
 Préparation des environnements techniques de test : Les tests d’homologation seront réalisés sur des
environnements dédiés incluant les paramétrages et les développements validés. L’homologation des
processus de la phase transitoire et ceux de la phase cible doivent être réalisés sur des environnements
distincts incluant les paramétrages et les interfaces nécessaires à chaque phase.
 Constitution de l’équipe des testeurs : cette constitution sera effectuée après la construction des scénarios
de recette en fonction de la charge identifiée et des compétences requises pour l’exécution de chaque
scénario.
 Planning de tests : Les tests d’homologation se déroulent sur plusieurs cycles. L’environnement de test sera
réinitialisé au démarrage de chaque cycle pour intégrer les correctifs éventuels.
Page 78
Première Partie
 Déroulement des tests : le périmètre de tests et de validation comprend l’ensemble des traitements. On
distingue entre deux catégories de traitements :

Traitement des opérations saisies : il s’agit des opérations saisies dans la cadre de l’exécution des plans
de tests.

Traitement des opérations automatiques : il s’agit des opérations générées automatiquement par le
système suite au traitement de fin de journée : tombée d’échéance, traitement de la compensation,
abonnement des intérêts à recevoir de fin du mois, ré-indexation des échéances de crédits,…
Les cycles de recette seront ainsi composés d’opérations de saisie, d’intégration de fichiers interfacés, de
traitements de fin de journée, de validation des résultats, de constatation et remontée des anomalies.
 Gestion des anomalies : durant la phase d’homologation, des anomalies seront identifiées par les testeurs.
Ces anomalies doivent être portées sur une base centralisée de gestion des anomalies permettant ainsi
d’avoir une situation actualisée du statut des anomalies remontées. Les anomalies identifiées doivent passer
par le processus suivant :

identification de l’anomalie par les testeurs ;

validation et qualification de l’anomalie par l’équipe de mise en place ;

détermination des actions de régularisation : correction paramétrage, correction programme d’interface,
écart fonctionnel (Gap),…

livraison de la correction et installation sur l’environnement de test ;

répétition du cycle de tests jusqu’à clôture de l’anomalie.
 Déclaration de fin d’homologation : L’homologation est prononcée lorsque :

l’ensemble du périmètre des tests a été effectué ;

il ne subsiste aucune anomalie bloquante ou majeure ;

les autres anomalies font l’objet d’un calendrier de correction/livraison approuvé par la banque.
 Exemple 1 : Scénarios de recette du processus « Emission d’un ordre de virement simple »
Identifiant
MPA001-SC001
MPA001-SC002
MPA001-SC003
MPA001-SC004
MPA001-SC005
MPA001-SC006
MPA001-SC007
MPA001-SC008
MPA001-SC009
MPA001-SC019
MPA001-SC011
Intitulé scénario
Emission d'un virement même agence
Emission d'un virement clientèle inter agence
Emission d'un virement clientèle autre banque
Emission d'un virement d'un compte en TND vers un compte en TND
Emission d'un virement d'un compte en TND vers un compte en TND convertible
Emission d'un virement d'un compte en TND vers un compte en devises
Emission d'un virement d'un compte en TND convertible vers un compte dinars convertibles
Emission d'un virement d'un compte en TND convertible vers un compte devises
Emission d'un virement d'un compte en devises vers un compte en TND
Emission d'un virement d'un compte en devises vers un compte en TND convertibles
Emission d'un virement d'un compte en devises vers un compte en devises
Page 79
Première Partie
 Exemple 2 : Scénarios de recette du processus « Retrait espèce dinar»
Identifiant
AG021-SC001
AG021-SC002
AG021-SC003
AG021-SC004
AG021-SC005
AG021-SC006
AG021-SC007
AG021-SC008
AG021-SC009
AG021-SC010
AG021-SC011
AG021-SC012
AG021-SC013
AG021-SC014
Intitulé scénario
Retrait espèce: titulaire du compte par pièce de retrait (le compte permet le paiement)
Retrait espèce: titulaire du compte par chèque(le compte permet le paiement)
Retrait espèce: titulaire du compte par pièce de retrait (le compte ne permet pas le paiement):dérogation accordée
Retrait espèce: titulaire du compte par pièce de retrait (le compte ne permet pas le paiement): dérogation rejetée
Retrait espèce: titulaire du compte par chèque(le compte ne permet pas le paiement): dérogation accordée
Retrait espèce: titulaire du compte par chèque(le compte ne permet pas le paiement): dérogation rejetée
Retrait espèce: tierce personne par chèque (le compte permet le paiement)
Retrait espèce: tierce personne par chèque (le compte ne permet pas le paiement): dérogation accordée
Retrait espèce: tierce personne par chèque (le compte ne permet pas le paiement): dérogation rejetée
Retrait espèce: titulaire du compte Mineur
Retrait espèce: par un mandataire (suite procuration)
Retrait espèce par chèque sur un compte clôturé
Retrait espèce par chèque sur un compte en instance de fermeture
Retrait espèce sur compte de personnel
 Exemple 3 : Description d’un scénario de recette : « Retrait espèce client titulaire du compte majeur
avec provision »
Etapes du Scénario
Résultat attendu
1-Cliquer sur module front office
Acteurs
Transaction
progiciel
Caissier
Retrait espèce
2- Cliquer sur espèces, retrait espèce
Affichage de l’écran retrait espèce et
du code agence de l’utilisateur
Caissier
Retrait espèce
3- Dans la zone type, cliquer sur la
touche tabulation ; taper F4 pour
rechercher le type de retrait
Affichage des types de retrait
Caissier
Retrait espèce
Caissier
Retrait espèce
Caissier
Retrait espèce
Caissier
Retrait espèce
Caissier
Retrait espèce
Caissier
Retrait espèce
Caissier
Retrait espèce
Caissier
Retrait espèce
4- Sélectionner retrait espèce
5- Saisir le numéro de compte du client
et le RIB ou faire une recherche par F4
6- Effectuer un contrôle sur la date de
valeur par rapport aux conditions de
banque en vigueur
7-Affichage de contrôle de signature ;
valider ou abandonner l’opération
8- Si validation, décocher chèque client
et saisir la référence de la pièce de
retrait et le montant
9- Sélectionner la condition de
perception des frais
10- Valider l’opération
Affichage automatique de l’agence du
compte
Affichage automatique de l’intitulé et
de la date de valeur
La date doit correspondre à j-1 pour
un compte DAV, j-7 pour un compte
épargne
Affichage automatique des montants
de frais d’opération à prélever
Impact comptable traitement fin de
journée et impact sur le compte client
Transaction
Autres
3.2. Simulations de bascule
La phase d’homologation doit inclure des simulations de bascule. Ces simulations ont pour objectif de :

valider le processus de bascule (plan de bascule) ;
Page 80
Première Partie

valider les programmes développés de reprise des données ;

déterminer les actions de fiabilisation des données qui doivent être entreprises.
Le plan de bascule est le document qui indique toutes les actions nécessaires pour la réalisation d’une bascule y
compris le timing d’exécution, le responsable de l’action et la chronologie à respecter. On distingue
généralement entre :

les actions de pré-bascule : arrêt de flux pour certaines opérations, éditions de situations avant bascule,
installation de matériel,…

actions de bascule : centralisation, traitement et intégration des données, lancement de TFJ du bascule,…

actions après bascule : validation de la bascule, le suivi de l’apurement des valeurs en route, traitement des
rejets, …
Les simulations de bascule sont réalisées dans les conditions de bascule réelles :

elles sont réalisées sur des volumétries réelles ;

elles sont effectuées dans les mêmes horaires d’une bascule réelle : la bascule doit se faire au cours d’un
week-end de manière à permettre sa validation et la prise de décision de continuer ou retourner en arrière ;

elles font intervenir les équipes techniques, les chantiers fonctionnels et d’autres équipes externes au projet
dont notamment la comptabilité, les structures de back office et les utilisateurs des agences. Ces derniers
auront la charge notamment de valider les résultats de la simulation de bascule.
Les chantiers fonctionnels et techniques doivent analyser les causes de rejet et déterminer les actions de
régularisation. Les actions peuvent consister soit à une correction dans les programmes de reprise soit à des
actions de fiabilisation des données à basculer.
Les simulations de bascule permettent également de s’assurer de la bonne performance des programmes de
reprise, des actions d’optimisation peuvent avoir lieu si une mauvaise performance a été constatée.
L’environnement issu d’une simulation de bascule sert à mener des cycles d’homologation. Il permet
essentiellement de tester le cycle de vie des dossiers et informations migrées de l’ancien système.
3.3.Tests de montée en charge (stress test)
Les tests de montée en charge permettent de s’assurer de la performance du nouveau système aussi bien sur le
plan transactionnel (opérations et transactions lancées au cours de la journée) que sur le plan batch ou
traitements de fin journée avec des volumétries cibles : nombre de clients, nombres d’utilisateurs, nombre
d’agences, nombre de comptes,…
Pour la performance des transactions, la démarche consiste à simuler la connexion d’un nombre important
d’utilisateurs et la réalisation simultanée de transactions courantes notamment : édition d’un extrait de compte,
versement espèces, retrait espèces, virements émis,…
Page 81
Première Partie
Pour la performance des traitements de fin de journée, seront simulés des traitements avec un nombre important
d’agences et d’opérations, des traitements de la compensation, des traitements de fin du mois, des traitements
de calcul d’arrêté, des traitements de tombée d’échéances de crédit,…
Selon les réactions du système et les délais de réponse, des plans d’actions pour l’optimisation des processus
jugés non performants seront définis. Il existe plusieurs axes d’optimisation : configuration du matériel, la base
de données, les programmes du progiciel,...
Les tests de performance sont réalisés généralement par des cabinets spécialisés sur un environnement de test
dédié similaire à l’environnement de production.
Ces tests présentent une importance capitale dans le contexte de progiciel puisque tous les traitements sont
réalisés sur une seule base centralisée. Ainsi, tout problème majeur de performance peut causer l’arrêt des
activités de la banque. Par exemple, si un traitement de fin de journée ne se termine pas dans les délais, les
agences ne seront pas en mesure d’accéder au lendemain au système et réaliser les transactions courantes.
Paragraphe 3 : La mise en production
Au cours de cette phase, la solution paramétrée et homologuée sera déployée au niveau de toutes les agences.
Les principales étapes de cette phase sont :

la conduite du changement (1)

le déploiement de la solution (2)

la post-implémentation de la solution (3)
1. La conduite du changement
La phase de conduite de changement est une phase primordiale dans ce type de projet, si elle n’est pas bien
menée ou étudiée, cela risque d’endommager tout le projet. Il existe plusieurs types de comportements des
utilisateurs finaux suite au changement du système d’information allant du refus et la résistance jusqu’à
l’acceptation et l’appréciation du changement. La conduite du changement vise à ce que le nouveau système soit
compris et approprié par les utilisateurs finaux. Les principales actions de conduite de changement sont : la
communication (1.1), la formation des utilisateurs (1.2) et l’assistance au démarrage (1.3).
1.1. La communication
Il s’agit ici d’appliquer les principes du plan de communication, ce plan apporte essentiellement des réponses
aux questions suivantes :
 Qui ? : à qui est destinée la communication (management, équipe projet, utilisateurs, clients,…).
 Quoi ? : ce que chaque utilisateur a besoin d’apprendre (déterminé en fonction des besoins).
Page 82
Première Partie
 Comment? : quels supports de communication à utiliser pour que le message soit perçu d’une manière
optimale.
La communication doit se faire durant toute la durée du projet. Elle commence par la réunion du lancement qui
intéresse essentiellement l’équipe intervenant dans la mise en place de la solution, se poursuit au cours de la
phase de configuration de la solution pour permettre aux utilisateurs de connaître l’avancement du projet et les
principaux impacts et changements de la nouvelle solution et se termine par les actions de communication
destinées aux utilisateurs finaux. Ces dernières actions doivent mettre l’accent sur :

les insuffisances de l’ancien système ;

les objectifs stratégiques de la banque du nouveau système et les gains attendus ;

l’importance du projet pour le management et le futur de la banque ;

l’importance des investissements et des efforts déployés pour la réalisation de la solution ;

l’importance du rôle de chaque utilisateur pour la réussite du projet.
1.2. Formation des utilisateurs
C’est la dernière phase avant la mise en production du nouveau système. Les actions de formation visent à
assurer aux utilisateurs finaux une maîtrise du nouveau système d’information afin qu’ils puissent faire
fonctionner convenablement les processus opérationnels de la banque. Les actions de formation doivent se faire
le plus tard possible juste avant la mise en production pour que les utilisateurs puissent garder en mémoire les
informations apprises pendant celles-ci. Dans la mesure où la formation met en jeu des centaines voire des
milliers d’utilisateurs répartis sur des sites et des régions différentes, plusieurs actions préalables seront
nécessaires :

L’identification des sessions de formation nécessaires en contenu, profils utilisateurs concernés et nombre
de session nécessaires. Les sessions de formation sont organisées par profils utilisateurs. Par exemple au
niveau des agences, on distingue entre les profils suivants : le front office, les chargés d’affaire
« particulier », les chargés d’affaire « entreprise », le chef d’agence, le back office agence et le contrôleur
agence.

La préparation des supports de formation : les supports de formation doivent indiquer :
- les nouveaux processus de la banque et les différences par rapport aux processus actuels ;
- présentation théorique des manipulations à effectuer pour réaliser les étapes d’un processus
considéré (copies d’écran, documents,…) ;
- des exercices et des cas pratiques.

La préparation des environnements de formation : environnement technique, lieux et équipements
nécessaires aux formations.
Page 83
Première Partie
A la fin de chaque session de formation, des questionnaires sont distribués aux utilisateurs pour qu’ils puissent
évaluer la qualité de l’intervenant et la qualité des supports utilisés. A travers ces évaluations, il sera possible
d’ajuster le contenu, de changer les formateurs, de changer la démarche de présentation,… Les équipes de mise
en place sont les plus appropriées pour la préparation des supports de formation. Par ailleurs, les formateurs
sont généralement constitués des testeurs qui ont participé aux étapes d’homologation de la solution.
1.3. L’assistance au démarrage
Il s’agit de la dernière des phases de conduite de changement car elle débute lors de la mise en production de
l’outil auprès des utilisateurs. Lors du démarrage du projet, les utilisateurs sont amenés à utiliser en vie réelle les
nouveaux outils qui leur ont été enseignés. Pour cela, des équipes d’accompagnement doivent être présentes
sur le terrain pendant quelques temps afin de les aider à prendre une autonomie définitive sur le nouveau
système. Les équipes d’accompagnement doivent donc tout mettre en œuvre pour que les utilisateurs ne se
sentent pas submergés par le changement. Elles doivent être patientes et rassurantes, en veillant à donner les
réponses et supports qui leur sont nécessaires.
Les équipes d’accompagnement sont constituées des équipes de mise en place ou des équipes de testeurs qui
ont homologué la solution. L’assistance au démarrage doit s’arrêter lorsque les utilisateurs disposent d’une
autonomie suffisante pour assurer la réalisation des processus opérationnels de la banque.
2. Le déploiement de la solution
La phase de déploiement représente l’aboutissement du projet et la résultante de toutes les activités entreprises
depuis le début du projet. Le déploiement progressif des agences (2.3) sur le nouveau système d’information
suppose que toutes les actions préalables soient réalisées (2.1) et que la bascule précédente a été validée (2.2).
2.1. Les pré-requis de déploiement
 Pré-requis liés à l’homologation
Le démarrage du déploiement suppose que toutes les phases d’homologation sont finalisées : tests
d’homologation, simulation de bascule et stress test. Si des anomalies bloquantes n’ont pas été résolues et que
des solutions de contournement n’ont pas été identifiées, l’homologation ne peut pas être prononcée. Le plan de
bascule lui aussi est supposé être testé et validé au moment de déploiement.
 Pré-requis liés à la formation
Le démarrage du déploiement des agences suppose que les utilisateurs des modules centraux ont été formés
préalablement au lancement des agences pilotes (comptabilité, back offices, direction des risques,…) et que les
utilisateurs agence soient formés préalablement au déploiement de leur agence.
Page 84
Première Partie
 Pré-requis technique
Le démarrage du déploiement des agences suppose que :

la machine de production est installée et configurée ;

l’environnement de référence est constitué : il s’agit de l’environnement incluant les paramétrages et les
développements homologués ;

l’appropriation par les équipes de production informatique des travaux d’exploitation du nouveau système
d’information : réalisation des traitements de fin de journée, intégration de lots comptables, intégration de
lots compensation, lancement calcul d’arrêté, édition des relevés des comptes,…

configuration de la nouvelle application sur les postes de travail des utilisateurs ;

installation de l’architecture réseau en adéquation avec le nouveau système.
 Mise en place du dispositif du support
Le dispositif de support est constitué généralement autour des trois structures suivantes :

le support sur site : il s’agit des moniteurs accompagnant les utilisateurs pendant la période de démarrage ;

un support national situé au siège et permettant d’assister les agences dans leur appropriation du nouveau
système, de qualifier les anomalies remontées, d’assurer le suivi de la correction des anomalies par les
équipes de paramétrage et d’informer les agences de l’avancement des corrections d’anomalies ;

un support chez l’éditeur : les éditeurs des solutions disposent de structures de maintenance et de help
desk. Le help desk de l’éditeur est particulièrement important en cas d’incident grave lors d’un traitement de
fin de journée. La solution doit être livrée instantanément pour éviter les risques d’arrêt d’activité.
2.2. La validation d’une bascule
Le plan de bascule doit définir un responsable au moins pour la validation des différentes informations basculées
au nouveau système d’information. Les informations quantitatives doivent être validées d’une manière
exhaustive : soldes des comptes, encours de crédit, impayés, chèque à l’encaissement,…
Les informations qualitatives font généralement l’objet d’une validation par échantillonnage : données du
référentiel client, conditions spéciales, marges sur crédits, nature des taux,…Ces validations sont réalisées en
rapprochant les données de l’ancien système aux données basculées au nouveau système. Des outils de
contrôles automatisés peuvent faciliter la réalisation de ces rapprochements. La validation de la bascule fait
intervenir essentiellement la direction de la comptabilité, les responsables de l’agence en question, les directions
de back office qui assurent la gestion des dossiers migrés : compensation, portefeuille,…
Les rejets constatés lors d’une bascule doivent passer par des procédures de recyclage afin qu’ils puissent être
pris en compte par le nouveau système. Un rejet non traité peut bloquer les bascules ultérieures. La validation
Page 85
Première Partie
d’une bascule doit intervenir au cours du week-end de bascule. Le traitement des rejets peut avoir lieu après le
démarrage mais ne doit pas dépasser la date de bascule du lot suivant.
2.3. Le déploiement progressif
Avec une stratégie de bascule progressive ; le déploiement est réalisé selon la logique suivante :
 Bascule d’une première agence pilote
Cette bascule pilote est réalisée généralement sur une agence avec un volume opératoire moyen et un périmètre
de couverture opérationnel large : opérations avec des clients particuliers et avec des clients entreprises. Il est
préférable que l’agence soit à proximité des équipes du projet.
Cette bascule permet de dégager de nombreuses leçons dans tous les domaines qu’ils soient opérationnel,
fonctionnel, technique, organisationnel, méthodologique,…Ces leçons seront ensuite utilisées pour ajuster et
améliorer les déploiements ultérieurs.
Toutes les équipes doivent être mobilisées durant le déploiement de l’agence pilote : il est possible que des
écarts fonctionnels ou des dysfonctionnements majeurs soient identifiés. De même, de nouveaux besoins
peuvent être exprimés notamment en matière d’éditiques ou états. Des solutions rapides doivent être apportées.
La poursuite des opérations de déploiement ne peut s’effectuer que lorsque l’agence pilote a été pleinement
stabilisée et qu’une expérience initiale a été constituée.
Avec une seule agence pilote, il ne sera pas possible d’examiner la validité des processus faisant intervenir deux
agences basculées au nouveau système d’information.
 Bascule d’une deuxième agence pilote
Cette deuxième bascule permet essentiellement de mettre à l’épreuve de nouveaux processus : opérations entre
deux agences basculées ainsi que d’assurer la gestion d’un volume opératoire plus important et une couverture
transactionnelle plus large.
Ce deuxième lot pilote est réalisé dans un intervalle de temps plus court que le premier lot. Une fois que ce
deuxième lot pilote est stabilisé, que les anomalies identifiées ont été traitées et corrigées et que les
améliorations nécessaires ont été portées, une deuxième phase de déploiement commence qui consiste aux
déploiements par vague d’agences.
 Bascule par vagues d’agence
A ce stade, le processus de bascule est compris par les différents intervenants : chacun maîtrise ce qu’il doit
faire, quand et comment il doit intervenir. Le lotissement des agences tient compte :

de la répartition géographique des agences pour sécuriser les formations et l’assistance au démarrage.
Page 86
Première Partie

du volume opératoire des zones géographiques ; une zone avec volume important doit être basculée sur
plus d’un lot.
L’intervalle séparant les lots de bascule devient de plus en plus court par rapport aux lots pilotes. Deux ou trois
semaines sont suffisantes pour sécuriser une bascule et commencer la préparation de la prochaine bascule.
 Bascule finale
A l’issue de cette bascule certains processus et certaines interfaces relatifs à la gestion de la phase transitoire
seront arrêtés et la banque sera totalement en configuration cible.
3. La post-implémentation du nouveau système d’information
Le progiciel étant maintenant devenu une réalité et il est l’épine dorsale du système d’information pour vingt ans
ou plus. Trois nouvelles étapes seront entamées pour passer de la fin d’un projet à une période de maintien du
nouveau système d’information dans des conditions opérationnelles : stabiliser le passage en production (3.1),
exploiter le nouveau système et tirer profit de l’investissement (3.2), et faire évoluer le nouveau système (3.3).
3.1.
Stabilisation du passage en production
Le déploiement du nouveau système d’information génère toujours des perturbations opérationnelles qui
entraînent un niveau de service inférieur à celui connu avec l’ancien système. La stabilisation consiste donc à
retrouver le niveau de productivité et de service initial. Les principaux indicateurs qui permettent d’apprécier
l’atteinte de cette stabilisation :

le nombre d’anomalies déclaré et en attente de résolution est raisonnable ;

les volumes d’activité traités sont des volumes normaux ;

les niveaux de service et de qualité sont assurés, ceci peut être apprécié à travers des réunions avec des
clients importants ;

une pleine compréhension des nouvelles procédures et des nouveaux processus opérationnels : ceci peut
être mesuré par la baisse des réclamations aux structures de support et le désengagement des équipes de
mise en place ;

la clôture du premier exercice de bascule et la certification des comptes par les commissaires aux comptes.
3.2.
Pleine utilisation du nouveau système
Les troubles de l’après bascule étant maîtrisés, le fonctionnement opérationnel va s’instaurer. Les efforts et la
mobilisation de la phase projet sont déjà oubliés. Le transfert de connaissances et de compétences entre les
équipes du projet et les utilisateurs finaux étant assuré, la structure du projet disparaît et les opérationnels
Page 87
Première Partie
prennent le contrôle du nouveau système. L’enjeu est maintenant d’exploiter pleinement le nouveau système
pour atteindre les objectifs fixés et réaliser les gains attendus. Une pleine utilisation du système permettra
d’identifier les axes d’amélioration et d’évolution.
3.3.
Evolution du nouveau système
Une évolution permanente et continue est la seule façon de conserver un outil fiable, performant, compétitif et en
ligne avec les besoins actuels et les stratégies futures. Cette évolution ne peut toutefois s’envisager qu’à partir
du moment où le progiciel et ses systèmes périphériques ont atteint un niveau de stabilité et de fiabilité approuvé
par l’ensemble des acteurs opérationnels. Il ne sert à rien de modifier ou d’ajouter de nouvelles fonctionnalités à
un système dont les composantes ne sont pas encore stabilisées. Parmi les principales évolutions, on peut citer :

Les patchs : il s’agit des modifications réalisées par l’éditeur sur les fonctionnalités d’un ou plusieurs
modules. On distingue entre deux types de patch : ceux qui apportent un plus fonctionnel et ceux qui
représentent une solution à un problème déterminé sur une fonctionnalité actuelle. L’installation de ces
patchs sur la plate-forme de production doit passer par un processus de test et de validation similaire à
l’étape d’homologation. Des tests de non régression sont indispensables pour s’assurer que le nouveau
patch n’impacte pas des processus opérationnels.

Les modifications spécifiques : au cours de l’utilisation quotidienne de la solution, de nouveaux besoins,
obligations et des améliorations de processus peuvent apparaître. Lorsque ces besoins ne sont pas
couverts par le progiciel, des développements spécifiques seront demandés. Ces demandes doivent être
validées par le management de la banque et faire l’objet de spécifications détaillées. La même procédure de
test et de validation appliquée aux installations de patchs doit être appliquée pour ces modifications
spécifiques.

Les montées de version du progiciel : Les éditeurs changent d’une manière fréquente les versions de
leur produit. Généralement, il n’y a aucune obligation de passer sur la version récente du progiciel. La
banque doit faire une analyse rationnelle des avantages et inconvénients d’un changement de version.
Plusieurs raisons peuvent justifier la montée de version :
• accès à une nouvelle technologie telle que l’utilisation d’une interface web pour la navigation ;
• amélioration de fonctionnalités de certains modules ;
• installation d’un nouveau module.
La montée de version du progiciel constitue un projet à part entière qui inclut les différentes étapes de projet
de mise en place d’un nouveau système.
Page 88
DEUXIÈME PARTIE : RÔLES DE L'EXPERT COMPTABLE
DANS LES PROJETS D’IMPLANTATION DE GLOBAL BANKING
: DOMAINES D’INTERVENTION ET DÉMARCHE PRATIQUE
D’ASSISTANCE DANS LA MIGRATION DES DONNÉES
Deuxième Partie
Chapitre 1 : L’implantation de Global Banking, de nouvelles missions pour l’expert comptable
CHAPITRE 1 : L’IMPLANTATION DE « GLOBAL BANKING »,
DE NOUVELLES MISSIONS POUR L’EXPERT COMPTABLE
Nous allons démontré en premier lieu le besoin des banques aux services de consultants externes dans le cadre
de leur projet d’implantation de « Global Banking » ainsi que les avantages comparatifs que présentent les
experts comptables dans ce cadre (Section 1), nous détaillerons ensuite les différents domaines d’intervention
dans lesquels les experts comptables peuvent fournir des prestations d’assistance et d’accompagnement
(Section 2).
SECTION 1 : LE BESOIN D’ASSISTANCE ET LA VALEUR AJOUTÉE DE
L’EXPERT COMPTABLE
Le facteur humain revêt une importance particulière dans les projets de changement de système d’information.
En effet, l’implantation d’un ERP est avant tout un travail d’équipe qui fait intervenir un grand nombre d’individus
ayant des compétences, qualifications, expertises et connaissances différentes. Les banques opérant ce
changement seront confrontées au besoin d’être assistées dans la réalisation de certaines activités du projet. On
exposera dans un premier temps, les différents acteurs du projet et les facteurs justifiant le recours à des
consultants externes (Paragraphe 1). Puis on décrira les avantages comparatifs que présentent les experts
comptables par rapport aux autres professionnels ainsi que le cadre global d’intervention dans une mission de
conseil en système d’information (Paragraphe 2).
Paragraphe 1 : Les acteurs du projet et le besoin d’assistance
Avant de présenter les raisons incitant les banques à recourir à des consultants externes pour faire aboutir un
projet de changement de système d’information (2), on présentera les compétences en matière de ressources
humaines nécessaires pour la conduite de tels projets (1).
1. Acteurs du projet et compétences requises
L’implantation d’un ERP fait intervenir plusieurs personnes disposant de profils différents. C’est la combinaison
entre ces différents acteurs et compétences qui permettra au projet d’aboutir aux objectifs attendus.
Page 90
Deuxième Partie
1.1.
Le comité de pilotage
Le comité de pilotage est composé de la direction générale, du chef du projet, du directeur de l’informatique, des
directeurs des entités opérationnelles (comptabilité, exploitation, back offices,….), des représentants de l’éditeur
et de l’intégrateur et éventuellement les représentants de la société mère.
Parmi les attributions de ce comité, on peut citer :

évaluer et contrôler l’avancement du projet et s’assurer du respect du planning ;

mettre à la disposition les moyens nécessaires pour la réalisation des objectifs ;

arbitrer sur les décisions pouvant affecter le planning ou le budget ;

fixer les priorités lorsqu’il y a conflit ;

anticiper les actions futures et les problèmes à résoudre ;

tenir informés l’ensemble des unités de l’état d’avancement du projet ;

décider les dates de passage en production.
1.2.
Le chef de projet
Le chef de projet est le responsable pour mener le projet à terme dans les délais prévus, le budget alloué et les
spécifications préalablement établies. Le chef de projet organise et conduit le projet de bout en bout. Il assume la
responsabilité des différentes phases, depuis la traduction des besoins utilisateurs en spécifications
fonctionnelles et techniques, jusqu’à la recette utilisateur et la mise en production.
Le chef de projet est responsable de toutes les activités prévues par les normes de management de projet
décrites dans le chapitre 2 de la première partie.
Selon le référentiel métier des activités de l’informatique établie par le Cigref, « Club informatique des grandes
entreprises françaises »46, le chef de projet doit disposer des savoir-faire et connaissances suivantes :
Savoir-faire
 Pilotage et management de plusieurs projets
 Définition et suivi d'un budget prévisionnel
 Animation de réunions ou de comités de pilotage
 Pilotage des réponses aux appels d’offres
 Prise en charge de la relation avec les
fournisseurs
 Gestion du stress
 Capacité à déléguer
 Animation et motivation d'une équipe
46
Connaissances
 Méthodes,
outils et normes de conception et de
développement
 Architecture et fonctions du système d’information
 Démarche qualité
 Techniques de gestion des risques
 Normes et procédures de sécurité informatique
 Domaine fonctionnel
 Architectures techniques
 Notions juridiques
www.cigref.fr
Page 91
Deuxième Partie
1.3.
Le PMO (Project Management Office)
Le PMO est l’entité qui définit et maintient le référentiel des processus liés à la gestion de projet. Le PMO a pour
objectif de standardiser et d’industrialiser les projets47. Le PMO sert de support pour :

la mise à disposition des méthodes et des outils adaptés ;

le suivi formalisé des plannings, des budgets,…

la capitalisation des bonnes pratiques et le partage des savoir-faire consolidés dans une base documentaire
standardisée.
1.4.
Les acteurs opérationnels
Les équipes opérationnelles auront la responsabilité de passer l’ERP de l’état générique où se trouve chez
l’éditeur à l’état spécifique qui permet une pleine utilisation par la banque. Plusieurs personnes interviennent
dans les activités opérationnelles de mise en place de l’ERP. On distingue entre les opérateurs internes et ceux
externes.
1.4.1. Les acteurs internes
Les équipes internes de mise en œuvre sont constituées de profils métiers et fonctionnels et des profils
informatiques et techniques :
1.4.1.1. Les équipes métiers (Key-users)
Les équipes métiers sont les porteurs des besoins de la maîtrise d’ouvrage. Ce sont eux qui vont définir le
fonctionnement du système cible dans tout le détail. Leurs rôles consistent essentiellement à :

définir les processus cible ;

identifier les écarts fonctionnels ;

spécifier les options de paramétrage et les règles de gestion ;

valider les nouveaux schémas comptables ;

définir les règles de migration et fournir les tables de correspondance ;

réaliser les tests unitaires des paramétrages et développement réalisés ;

réaliser les travaux de recette et de contrôle des simulations de bascule.
Les équipes métier doivent avoir une connaissance parfaite et une expérience dans le domaine fonctionnel sur
lequel ils vont intervenir. Ils doivent en outre démonter leur capacité à exprimer des besoins, rédiger des
spécifications fonctionnelles ou cahiers des charges, réaliser des études, proposer des solutions,…
47
http://fr.wikipedia.org/wiki/Project_management_office
Page 92
Deuxième Partie
Par ailleurs, les équipes métiers doivent être disponibles. « C’est de cette disponibilité - ou plutôt de cette
indisponibilité – que proviennent les problèmes les plus sérieux durant la mise en place de l’ERP» 48. En pratique,
il n’est pas évident de rendre disponible des ressources de qualité intervenant dans les activités opérationnelles
quotidiennes pour intégrer les équipes du projet.
1.4.1.2. Les équipes techniques et informatiques
La mise en place d’un ERP fait intervenir des profils informatiques et techniques différents :

les configurateurs et responsables du paramétrage : Ces équipes auront la responsabilité de réaliser
les paramétrages spécifiés par les équipes métiers sur les différents environnements prévus par le projet
(environnement de test, environnement de référence, environnement de pré-production,…)

les développeurs : Ces équipes participent dans le développement des écarts fonctionnels (Gaps), des
programmes de reprise des données, des programmes d’interface,…

les équipes d’infrastructure technique : ces équipes interviennent sur plusieurs aspects :
configuration des serveurs, gestion des bases de données, mise à niveau de l’architecture réseau,
l’installation des logiciels,…

les équipes d’exploitation informatique : ces équipes auront la charge d’exécuter les travaux relatifs à
l’exploitation de l’ERP : transferts de fichier, intégration de lot, exécution de procédure de sauvegarde,
lancement de traitement de fin de journée (TFJ), lancement de calcul d’arrêté,…
1.4.2. Les acteurs externes
Il s’agit de l’éditeur et l’intégrateur de la solution. La plupart des grands éditeurs assurent eux-mêmes les
fonctions d’intégrateur pour leur ERP en s’appuyant notamment sur leur force de consultants internes.
1.4.2.1. L’éditeur
L’éditeur est celui qui a fabriqué la solution. Lorsqu’il ne cumule pas le rôle d’intégrateur, le rôle de l’éditeur de la
solution se limite à fournir les licences d’utilisation de la solution et assurer la maintenance et les évolutions du
produit. En fonction des dispositions contractuelles, l’éditeur peut accompagner la banque dans certaines
activités de mise en place : la formation, la migration des données,…
1.4.2.2. L’intégrateur
L’intégrateur accompagne la banque, à travers ses consultants techniques et ses consultants fonctionnels, dans
la réalisation des différentes étapes du projet de mise en place. Pour assurer cette fonction, l’intégrateur doit
48
Page 93
Deuxième Partie
disposer des connaissances importantes sur la solution. Des conventions de partenariat entre éditeurs et
intégrateurs permettent d’acquérir ces connaissances.
1.5.
les utilisateurs finaux
Il s’agit des personnes qui vont utiliser au quotidien le nouveau système pour réaliser leurs activités
opérationnelles. Les activités de gestion de changement permettent de garantir l’acceptation et l’utilisation
optimale du nouveau système : communication, formation, support sur place et support à distance.
2. Le besoin d’assistance par des consultants externes
On présentera dans un premier temps les raisons de recours aux consultants d’une manière générale dans le
domaine des affaires, puis on mettra l’accent sur les raisons spécifiques aux projets de changement de système
d’information.
2.1.
Les raisons générales pour engager un consultant
Il existe plusieurs raisons pour motiver des dirigeants d'entreprises à engager un consultant49 :

Expertise spécialisée : en général, le directeur d'une entreprise recourt aux services d'un consultant
lorsqu'il a besoin d'une expertise spécialisée et qu'il ne dispose pas des compétences requises à l'intérieur
de son entreprise. Ces cas concernent les nouvelles technologies ou les nouvelles méthodes de gestion.

Urgence : un consultant peut aussi être demandé lorsque surgit un besoin urgent et que les ressources
internes ne sont pas disponibles. Un consultant peut répondre rapidement à un problème précis, car il est
entraîné à agir promptement et il est souvent déjà familiarisé avec plusieurs aspects du problème pour les
avoir décelés, observés et analysés ailleurs.

Objectivité : un dirigeant d'entreprise peut désirer obtenir un point de vue objectif sur une situation
complexe qui implique plusieurs personnes à l'intérieur de l'entreprise. Même la personne la plus qualifiée
à l'intérieur d'une entreprise risque, dans l'analyse d'un problème et la définition de solutions pratiques,
d'être influencée par ses implications personnelles, ses habitudes et ses façons de voir les choses. Parce
qu'il est indépendant de l'entreprise, le consultant peut être impartial dans des situations où il est difficile
aux gens de l'intérieur de l'entreprise de l'être.

Confidentialité : parfois, le dirigeant d'entreprise désire effectuer une étude et garder confidentielle son
identité. Un consultant peut être très utile pour ce genre d'études qui concernent soit des études de
marché, des études d'acquisition de compagnies,...
49
http://fr.wikipedia.org/wiki/Consultant
Page 94
Deuxième Partie

Crédibilité et appui d'une décision : un consultant peut être demandé pour présenter un rapport dans le
but d'appuyer une décision qui a été prise par un directeur d'entreprise. Un directeur peut connaître
exactement ce qu'il veut et quelle décision prendre mais préfère se référer à un consultant pour obtenir le
support nécessaire dans la réalisation de son projet.

Disponibilité et capacité de travail : souvent, l'entreprise cliente manque de cadres disponibles pour
réaliser une étude ou un projet interne.
2.2. Les raisons de recours aux consultants dans les projets de changement de système
d’information :
Dans le cadre de changement du système d’information d’une banque, deux raisons essentielles obligent les
banques à faire appel aux services de consultants externes : l’indisponibilité des ressources et le manque ou
l’absence de compétences dans des activités principales de ce type de projet.
2.2.1. L’indisponibilité des ressources internes
La mise en œuvre d’un ERP requiert une forte mobilisation de ressources, plus le périmètre fonctionnel est
important, plus le besoin en ressources sera large. Obtenir ces ressources, dédiées au projet, constitue une
problématique sérieuse pour la conduite optimale du projet. Ces ressources, qui sont rares par nature, sont déjà
impliquées dans les activités opérationnelles de tous les jours. Une résolution de conflits de priorité et d’intérêt et
des arbitrages doivent se faire presque quotidiennement. Il est donc toujours délicat de libérer des ressources
opérationnelles pour intégrer le projet pour une période aussi importante que la durée du projet. Et même si la
banque réussit à libérer quelques ressources, celles-ci restent insuffisantes pour faire aboutir le projet. La
banque se trouve ainsi dans l’obligation de se faire assister par des consultants externes. Ce besoin en
ressources externes est plus ressenti dans les activités suivantes :

Les activités de pilotage du projet : le chef de projet ne peut pas à lui seul assurer toutes les activités de
management de projet. Ces activités, prévues par les standards internationaux, étant indispensable à la
réussite du projet en termes de contenu, coût et délais. Ainsi, le chef de projet doit être épaulé par des
consultants externes pour piloter les différentes activités et phases du projet.

Les activités de configuration de la solution : ces activités nécessitant des actions d’analyse, de cadrage, de
spécifications, de rédaction de procédures, de préparation de schémas comptables,… demandent ainsi la
mise à disposition d’un nombre important de ressources. Le recours à des consultants externes pour des
activités spécifiques de cette phase est généralement la solution aux lacunes que présentent les ressources
internes.
Page 95
Deuxième Partie
2.2.2. L’insuffisance ou la non compétence des ressources internes :
Les profils adéquats pour mener les activités du projet sont rares. Ils nécessitent d’une part la connaissance des
modes de fonctionnement existants et d’autre part la capacité de les remettre en cause pour permettre de
s’adapter à la panoplie des possibilités offertes par l’ERP. Ces profils, doivent en outre, disposer de
connaissances en matière de gestion de projet. Les lacunes des compétences internes se présentent
essentiellement au niveau de ce dernier point, soit les pratiques de gestion de projet.
En effet, les ressources internes ne sont pas habituées à mener des projets aussi importants que la mise en
place d’un « Global Banking » impactant toutes les activités et procédures de la banque. Ce type de projet
n’intervient dans la vie des banques que tous les quinze ou vingt ans. La non conduite du projet conformément
aux normes de gestion de projet, des normes de qualité et les bonnes pratiques dans les projets de changement
de système d’information risque à faire échouer tout le projet.
Dans le but d’augmenter les chances de réussite du projet, les banques doivent faire appel à des consultants
externes disposant d’un savoir faire dans des projets de même envergue. Ces consultants vont intervenir
particulièrement dans les activités de pilotage de projet qui sont à la charge du chef de projet. Ces consultants
apportent beaucoup en termes de méthodologie, organisation, rigueur, qualité des travaux, respect des délais,…
Il est possible, que d’autres compétences nécessaires pour la réalisation du projet ne soient pas existantes dans
la banque. Dans ce cas, la banque est dans l’obligation de recourir à des consultants externes pour combler ces
lacunes : rédaction des procédures, validation des schémas comptables, définition des habilitations des
utilisateurs,…
Paragraphe 2 : Valeur ajoutée de l’expert comptable et cadre
d’intervention
Les experts comptables présentent des atouts considérables par rapport aux autres professionnels pour assister
les banques dans leurs projets d’implantation de « Global Banking » (1). Bien qu’il s’agisse de missions non
normalisées, l’intervention de l’expert comptable dans ce type de mission aura lieu dans un cadre bien
déterminé(2).
1. Le marché des consultants et avantages comparatifs de l’expert-comptable
Le marché de conseil en management présente une panoplie de professionnels offrant des services d’assistance
dans l’intégration des ERP (1.1). Ces missions sont parfaitement adaptées aux profils des experts comptables
(1.2).
Page 96
Deuxième Partie
1.1. Le marché du conseil en système d’information
Le secteur du conseil en management se révèle en pratique difficile à cerner car il est extrêmement hétérogène.
En termes d’acteur d'abord, qui vont du consultant individuel à la multinationale, des acteurs en conseil en
management « pur », aux cabinets d’audit et d’expertise comptable 50dont les métiers de base sont les finances
et la fiscalité et les sociétés de services et d'ingénierie informatique (SSII) dont les métiers de base sont
l’ingénierie informatique et l’intégration de systèmes. En termes d'activités ensuite : les frontières sont floues
entre stratégie, organisation, management, systèmes d'information, politique de ressources humaines : tous ces
domaines interfèrent entre eux et rares sont les cabinets qui n'exercent que dans un des segments.
En Tunisie, les cabinets offrant des services de conseil en système d’information sont rattachés aux trois
organisations professionnelles suivantes :

La chambre syndicale nationale des bureaux d’étude, de conseil et de formation (CSNEECF) : créée en
1990 et rattachée à l’UTICA51. La branche couvre approximativement 2 000 acteurs, toutes formes de statuts
confondus. La chambre comprend 167 adhérents.

La Fédération Nationale des Technologies de l'Information et de la Communication 52 : fondée en 2006 sous
le patronage de l’UTICA. Elle se compose de huit chambres syndicales nationales : sociétés de services et
d'ingénierie informatique ; centres d'appels et relations client ; industries de montage informatique ;
installateurs d'équipement de communication ; publinets ; sociétés de services à valeurs ajoutées ;
informatique et bureautique ; importateurs et distributeurs de mobile.

L’ordre des experts comptables de Tunisie (OECT): créé en 1983 et placé sous la tutelle du Ministère des
Finances53. L’OECT inclut plus de 600 membres personnes physiques et plus de 200 membres personnes
morales.
Il n’existe pas suffisamment d’études statistiques concernant les activités de conseil en système d’information,
les principales informations disponibles sur ce secteur se détaillent ainsi :

150 bureaux opèrent dans les activités de conseil et étude avec un chiffre d’affaires total de plus de 50 MDT.
L'effectif total des bureaux atteint environ 1200 emplois54.

Les sociétés de services et d'ingénierie informatique (SSII) représentent près de 200 entreprises dont 120
spécialisées dans le développement de logiciels. Le chiffre d’affaires total est estimé à 24 millions Euros.
La possibilité d’intervenir sur les missions d’organisation et de mise en place de système d’information a été indiquée expressément
au niveau du site officiel de l’OECT. www.oect.org.tn
51 www.tunisieconsultance.org.tn
52 http://it.utica.org.tn
53
www.oect.org.tn
54 www.tunisieconsultance.org.tn
Page 97
50
Deuxième Partie
Ces sociétés sont localisées dans leur majorité (80%) dans la région de Tunis. Les SSII emploient près de
700 ingénieurs. 55
En France, le SYNTEC conseil en management est le syndicat patronal regroupant les acteurs majeurs de
conseil en management (plus de 84 cabinets de conseil représentant plus de 60% du marché de conseil en
France en termes d’effectifs et de chiffre d’affaires). Le Syndicat fait partie de la Fédération SYNTEC qui
regroupe les métiers du savoir et qui compte près de 1 250 groupes ou entreprises (Ingénierie, Études &
Conseil, Informatique, Formation, Relations Publiques,...). Les principales caractéristiques du marché de conseil
en mangement ainsi prévues par le dernier rapport de la SYNTEC conseil en management de l’activité
2009/2010 sont 56:

Le secteur du conseil a connu pour la première fois depuis cinq ans une croissance négative, évaluée à 7%. Cette baisse est plus forte que celle du PIB. Le secteur a enregistré une croissance de 6% en 2008
et 13% en 2007.

Malgré une nette baisse de l’activité en 2009, les effectifs des cabinets sont restés relativement stables,
enregistrant une baisse moyenne de -3,7% contre -3,3% en 2008 et +10% en 2007.

Concernant la répartition sectorielle de l’activité de conseil en management en 2009, les services
financiers conservent la première position en accusant toutefois une légère baisse de leur demande,
passant de 31% en 2008 à 26% en 2009, suivis par l'Industrie (23%) et le secteur public (17%).

Les cabinets spécialisés dans le conseil en technologie ont beaucoup souffert en 2009 des reports des
grands projets IT sous l’effet de la crise, notamment dans le secteur financier. La répartition du chiffre
d’affaires en 2007 par ligne de service se présente ainsi 57:
55
www.ssii.org.tn/secteur.asp
56 www.syntec-management.com
Bénédicte GUALBERT, « Le conseil en management francilien, un secteur dynamique et en constant évolution », mars 2009,
Chambre de commerce et d’industrie de Paris
Page 98
57
Deuxième Partie

Le marché est très concentré, malgré la multitude de petits cabinets. Le Syntec estime que les cabinets
qui réalisent un chiffre d'affaires d'au moins 56 millions d'euros ont capté 70 % du marché en 2007. Les
cabinets au chiffre d'affaires d'au moins 151 millions ont eu une part stable de 44 %. Inversement les
"petits" cabinets (de 1 à 3 M€ de chiffre d'affaires) représentent 3 % de l'activité mais 45 % des acteurs.
Historiquement, dans les années 1990, les grands cabinets d’audit dominent le marché de conseil en
management, ces cabinets disposent chacune d’une branche ou une filiale spécialisée en consulting à coté des
autres branches : audit, transactions,…Depuis l’année 2000 et suite aux différents scandales financiers
enregistrés, les grands cabinets d’audit ont vendu leurs activités de conseil, et ils se sont recentrés sur l'audit et
les autres services financiers :

Ernst & Young : l’activité de conseil a été cédée en 2000 à Cap Gemeni ;

Price Waterhouse Coopers : l’activité de conseil a été cédée en 2002 à IBM Global Services ;

Arthur Andersen : création d’Andersen Consulting en 1989 qui se sépare en 2000 de Arthur Andersen et
devient Accenture en 2001 ;

KPMG : séparation de la branche conseil en 2000 par la création de KPMG Consulting qui devient plus
tard BearingPoint (2002).
Mais aujourd'hui les grands cabinets d’audit créent de nouvelles structures distinctes qui leur permettent de
revenir légalement sur le marché du conseil auprès d'entreprises qui ne sont pas clientes de leur activité d'audit,
et ces structures occupent désormais une place importante sur le marché du conseil.
1.2. Les avantages comparatifs de l’expert comptable
La formation pluridisciplinaire de l’expert-comptable et sa connaissance parfaite de l’entreprise et
l’environnement des affaires lui permettent d’assurer, en complément de ses missions traditionnelles
d’assistance comptable et fiscale et d’audit des comptes, un grand nombre de missions pour répondre aux
nouveaux besoins des entreprises. Le site de l’Ordre des Experts Comptable de Tunisie cite l’informatisation des
entreprises parmi les prestations que peut fournir l’expert comptable aux entreprises : étude d’opportunités et de
besoins, adaptations des programmes, élaboration de cahier des charges, assistance au choix des logiciels de
gestion...
L’expert comptable se distingue des autres professionnels opérant dans le domaine de conseil en système
d’information principalement par l’intervention dans les missions d’audit légal ou contractuel des comptes des
établissements de crédit. Aucun des autres intervenants sur le marché n’a accès à ces missions d’audit. L’audit
des comptes permet de développer chez les experts comptables les aptitudes comportementales et les savoirfaire essentiels pour la réalisation d’une mission de conseil en système d’information :
Page 99
Deuxième Partie
 Aptitudes comportementales : l’intervention dans des missions d’audit permet de développer les aptitudes
suivantes :

La capacité d'adaptation : il s’agit de la capacité de s’adapter à un nouvel environnement technique, à de
nouveaux interlocuteurs, à de nouvelles méthodes de travail. Ceci sera rendu plus facile par
l’intervention dans l’audit des comptes où l’expert comptable est amené à intervenir dans plusieurs
secteurs d’activité, plusieurs cultures, plusieurs environnements,…

L'esprit d'équipe et le travail en équipe : la réalisation d’un projet de changement de système
d’information est un travail d’équipe à l’instar de la réalisation d’une mission d’audit des comptes.

Faire preuve de qualité d'écoute et de dialogue, pour partager des idées et convaincre ses vis-à-vis :
l’audit et le conseil sont basés en grande partie sur la communication orale et écrite.

Capacités d’analyse et de synthèse : elles sont importantes aussi bien dans les missions d’audit que
dans les missions de conseil qui nécessitent toutes les deux un diagnostic puis une analyse pour tirer les
conclusions et les actions.

L’objectivité : L’auditeur est reconnu par son objectivité et l’exercice d’un jugement professionnel exempt
de toute subjectivité. Cette qualité est aussi importante dans le conseil pour traiter les problèmes et
proposer les solutions sans aucune influence.

Le sens de l’organisation : La conduite des missions d’audit conformément à la règlementation et les
normes professionnelles en vigueur ainsi que les contrôles qualité instaurées au sein des cabinets
permettent à l’auditeur de développer le sens de l’organisation dans la réalisation de toute activité. Cette
organisation et ce souci de qualité est également important dans les activités de conseil.

La confidentialité : la confidentialité est l’une des premières caractéristiques de l’auditeur qui dispose
d’un accès illimité à toutes les informations des sociétés auditées. Le consultant s’engage lui aussi à
garder confidentielles les informations de nature non publique dont il est amené à avoir connaissance
dans le cadre de son intervention.

Disponibilité exemplaire : les collaborateurs d’audit sont habitués aux notions d’échéances et de
« deadline » notamment pour les sociétés cotées ou appartenant à des groupes internationaux ce qui les
amènent à présenter une disponibilité importante pour réaliser les missions dans les délais prévus avec
la qualité attendue. Cette disponibilité est également indispensable dans les projets de changement de
système d’information.
 Savoir faire : L’audit permet d’acquérir et de développer les connaissances et compétences suivantes :

Connaissance du marché et du cadre règlementaire des banques : la réalisation des missions d’audit
dans des établissements bancaires permet aux intervenants d’acquérir des connaissances approfondies
Page 100
Deuxième Partie
notamment sur le cadre règlementaire national et international, les acteurs sur le marché, les principaux
produits, les ratios significatifs, les problématiques et insuffisances du secteur… Ces connaissances sur
le marché bancaire sont importantes pour la conduite d’une mission de conseil qui doit tenir compte de
tous les risques et opportunités du marché pour garantir la réussite de l’intervention.

Connaissance des métiers de la banque : Les missions d’audit des comptes permettent aux experts
comptables de connaître dans les détails tous les métiers de la banque et tous les processus
opérationnels. En effet, l’auditeur est appelé dans le cadre de sa mission à examiner tous les processus
ayant un impact significatif sur les comptes pour évaluer l’efficacité des procédures et du contrôle
interne. Ainsi, l’auditeur constitue le seul professionnel sur le marché qui peut disposer des compétences
métiers aussi importantes. Bien entendu, ces compétences sont essentielles pour les projets de
changement de système d’information.

Connaissances des systèmes d’information des banques : Les normes d’audit de l’IFAC notamment la
norme ISA 315 prévoit un certain nombre de diligences pour l’auditeur pour la compréhension du
système d’information de la société auditée. Ces connaissances sont aussi utiles pour les missions de
conseil en système d’information.

Les normes de contrôle qualité : Les normes de l’IFAC notamment la norme internationale de contrôle
qualité ISQC 1 et la norme ISA 220 ont prévu des obligations pour les professionnels d’audit de mettre
en place un système de contrôle qualité destiné à fournir au cabinet l’assurance raisonnable que ce
dernier se conforme aux normes professionnelles et aux obligations règlementaires. La conformité des
experts comptables aux normes de contrôle qualité en matière d’audit est également utile pour la
conduite des missions de conseil et plus généralement la conduite de tout projet.
L’intervention de l’expert comptable dans les missions d’audit des comptes des banques lui a permis de maîtriser
les métiers de la banque et les spécificités du secteur. Il est difficile d’imaginer qu’il existe sur le marché d’autres
professionnels qui disposent de ces connaissances et compétences.
Parallèlement à cet avantage, l’expert comptable présente des points faibles par rapport aux autres
professionnels :

Par rapport aux cabinets de conseil et études : la présence de ces cabinets sur le marché de conseil en
système d’information leur ont permis d’avoir une expertise pointue importante dans la conduite de ce
type de projet. Ces cabinets se distinguent par leur savoir faire remarquable en matière de gestion de
projet. Par ailleurs, en raison des profils qui les constituent, essentiellement des ingénieurs et des
polytechniciens, ces cabinets présentent également l’avantage d’une connaissance plus approfondie que
Page 101
Deuxième Partie
les experts comptables des systèmes d’information : architecture techniques, outil de développement,
les sécurités informatiques, les normes et méthodes de conception fonctionnelles et techniques,…

Par rapport aux sociétés de services et d'ingénierie informatique (SSII) : ces sociétés disposent
généralement des compétences particulières dans les solutions qu’elles développent elles-mêmes. Le
point fort de ces sociétés étant la maîtrise parfaite du monde des systèmes d’information mais ceci reste
insuffisant pour mener un projet de changement du système d’information qui nécessite aussi la maîtrise
de l’activité bancaire ainsi que les normes et les bonnes pratiques de gestion de projet.
Compte tenu des compétences et des qualités acquises dans l’audit des banques, compte tenu de leurs relations
privilégiées et de la confiance dont ils jouissent auprès des entrepreneurs et du monde des affaires en général et
compte tenu de leur contact permanent avec le terrain, les experts comptables peuvent contribuer efficacement
dans la conduite d’un projet de changement du système d’information d’une banque vers une solution de
« Global Banking ».
2. Cadre de l'intervention de l'expert-comptable
Dans le cadre de la réalisation d’une mission de conseil en système d’information, on présentera les
recommandations spécifiques an matière de formation fournies par l’IFAC (2.1), les responsabilités de l’expert
comptable dans ce type d’intervention (2.2.) et on décrira la démarche générale d’une mission de conseil (2.3).
2.1.
Recommandations de l’IFAC en matière de formation
La mission de l'International Federation of Accountants (IFAC), telle qu'elle est définie au paragraphe 2 de ses
statuts est "de favoriser au niveau mondial le développement et l'essor d'une profession comptable dotée de
normes harmonisées qui soit en mesure de dispenser, dans l'intérêt du public, des services uniformes de qualité
élevée". Dans ce cadre, un comité éduction a été créé : International Accounting Education Standards Board
(IAESB). Ce comité est chargé d'élaborer des normes, des recommandations, des documents consultatifs et
autres documents d'information sur les conditions de formation théorique et pratique des professionnels
comptables préalables à la qualification et sur la formation et le développement professionnels continus des
membres de la profession comptable. Ce comité a publié 8 normes appelées IES (Interntional Education
standards) :
IES 1 : Conditions d’admission au programme de formation comptable professionnelle
IES 2 : Contenu des programmes de formation comptable professionnelle
IES 3 : Aptitudes professionnelles
Page 102
Deuxième Partie
IES 4 : Valeurs, Ethique et comportement professionnels
IES 5 : Conditions d’expérience pratique (le stage professionnel)
IES 6 : Evaluation des capacités et de la compétence professionnelle
IES 7 : La formation continue
IES 8 : compétences requises des professionnels de l’audit
L’IES 2 relative au contenu des programmes de formation des professionnels comptables stipule dans son
paragraphe 3 : « La section connaissances de base des programmes d'enseignement des professionnels
comptables se présente sous trois rubriques principales :

comptabilité, finance et connaissances connexes ;

connaissances en organisation et gestion ;

connaissances des technologies de l'information. »
Les recommandations relatives aux connaissances et aux compétences des technologies de l'information pour
les professionnels comptables ont été exposées dans IEPS 2 (International Education Practice Statements) :
Technologies de l'information pour les professionnels comptables. Cette norme est organisée autour de trois
sections : connaissances et compétences requises en technologies d’information avant l’intégration de la
profession, après intégration de la profession et connaissances spécifiques pour les professionnels d’audit.
Selon cette norme, le module technologies de l'information doit inclure les domaines de disciplines et les
compétences suivantes :
(1) Connaissances générales des technologies de l'information
L’IEPS 2 a classé ces connaissances selon les six domaines suivants :
Domaines
1. Stratégies des technologies d’information
Les candidats peuvent expliquer, décrire ou discuter de
l'importance de l'alignement des stratégies des
technologies de l’information avec la stratégie de
l'entreprise.
Thèmes
 La stratégie et la vision d’entreprise ou d’affaire
 Environnement actuel et futur des technologies de
l’information
 Le plan stratégique des technologies de l’information
 Gouvernance et évaluation des résultats de
planification des technologies de l’information
2. Architecture des technologies de l’information
Les candidats peuvent expliquer, décrire ou discuter les  Concepts généraux sur les systèmes d’information
liens entre l’architecture des technologies de  Traitement des transactions dans les systèmes
l’information.
d’information
 Composantes matérielles et immatérielles des
systèmes d’information
 Architecture des bases de données
 Les métiers informatiques
Page 103
Deuxième Partie
Domaines
Thèmes
3. Impact de l’informatique sur l’organisation et les processus
Les candidats peuvent expliquer, décrire ou discuter  Les parties prenantes et leurs besoins
l’impact de l’informatique sur l’organisation, les  Les activités et organisation des entreprises
processus métiers et les risques associés.
 Les risques et les opportunités liées aux technologies
de l’information
 Impact des technologies de l’information sur les
processus opérationnels
4. Développement et acquisition des systèmes d’information
Les candidats peuvent expliquer, décrire ou discuter les  Les étapes d’acquisition ou de développement de
étapes de l'acquisition de systèmes et les processus de
systèmes
développement et comprendre le rôle du comptable.
 Etudes de marché et études de faisabilité
 Analyse des exigences et conception initiale
 Etapes d’implémentation des systèmes
 Gestion de projet
 Maintenance des systèmes
5. Gestion des systèmes d’information
Les candidats peuvent expliquer, décrire ou discuter  Organisation de l’informatique
comment l’informatique est géré au sein d'une  Gestion des processus informatiques et évaluation de
organisation, en mettant l'accent sur les systèmes
leur efficacité
comptables, suivi de la performance, gestion des  Gestion des actifs et matériels informatiques
changements et les procédures de mise à jour de  La sécurité informatique
logiciels et de matériel.
 Gestion des changements
 Logiciels pour la profession
6. La communication et les technologies de l’information
Les candidats peuvent expliquer, décrire ou discuter les  Concepts généraux sur les systèmes informatiques de
avantages et les risques de l'informatique, en matière de
communication (Email, SMS,…)
communication.
 Avantages et risques associés aux systèmes de
communication supportés par l’informatique
(2) Connaissances de contrôle des technologies de l'information
Les candidats doivent démontrer leur capacité à expliquer, de décrire ou de discuter des sujets suivants :

l’environnement de contrôle interne des systèmes d’information ;

les objectifs de l’informatique dans l’entité ;

les évènements de risques informatiques et techniques d’identification ;

les évaluations des risques informatiques;

les réponses aux risques informatiques;

les activités de contrôle informatique.
(3) Compétences dans le contrôle des technologies de l'information
Les candidats doivent démontrer des compétences assurées par des expériences pratiques dans les différents
sujets de contrôles informatiques: environnement de contrôle interne, identification des risques, évaluation des
risques, évaluation des activités de contrôle,…
Page 104
Deuxième Partie
(4) Compétences dans l’utilisation des technologies de l'information
Les candidats doivent démontrer des compétences d’utilisation des systèmes informatiques dans les trois
domaines suivants :

savoir utiliser les systèmes et les outils informatiques appropriés pour répondre à des problèmes
comptables ou commerciaux ;

faire la preuve d’une bonne compréhension des systèmes d’information dans les domaines comptables
et commerciaux;

appliquer les méthodes de contrôle aux systèmes d’information liés à la gestion du personnel.
(5) Compétences de gestionnaire, évaluateur ou concepteur des systèmes d'information.
Les candidats doivent posséder des compétences dans au moins l’une des fonctions informatiques suivantes :

Gestionnaire de système d’information : élaboration plan stratégique informatique, définition de
l’organisation de la direction informatique, définition des processus informatiques, définition et mise en
place des contrôles informatiques, gestion des phases d’acquisition et d’implémentation des systèmes
d’information, gestion des changements,…

Evaluateur des systèmes d’information : évaluation des contrôles informatiques, évaluation du
système de sécurité, réalisation des tests de performance, évaluation des procédures d’archivage et de
documentation,…

Concepteur de système d’information : analyse des besoins des parties prenantes, réalisation des
spécifications fonctionnelles, application des méthodes de gestion de projet, application des méthodes
de gestion de changement,….
Les compétences dans ces domaines consistent :

à décrire ou expliquer certaines ou toutes les attributions et rôle de chaque fonction ;

participer efficacement à tout ou partie des activités attribuables à chaque fonction/
En Tunisie, l’obligation d’enseignement des technologies de l’information trouve son fondement dans les textes
suivants :

L’arrêté du ministre de l'éducation et des sciences du 20 mai 1994, fixant le régime des études et les
conditions d'obtention des diplômes nationaux de premier cycle et de maîtrise en études comptables, a
prévu dans son article 12 que l’enseignement du module « Système d’information » est obligatoire avec un
volume horaire hebdomadaire de 4 heure 30 minutes.

L’arrêté du ministre de l'enseignement supérieur du 22 février 1996, fixant le régime des études et des
examens en vue de l'obtention du certificat d'études supérieures de révision comptable ainsi que
l'inscription des sujets de mémoires et les modalités de leur soutenance, a prévu dans son annexe sur le
Page 105
Deuxième Partie
contenu des programmes de formation que l’enseignement des « systèmes d’information » est inclus au
niveau du sous-module : « politique générale » qui fait partie du module « Gestion intégrée ».
Dans la mesure où les textes sus-indiqués n’ont pas précisé le contenu détaillé de la formation en «systèmes
d’information », il est possible que les formations dispensées ne soient pas totalement en phase avec les
recommandations de l’IEPS 2. Il est donc nécessaire l’intervention de l’Ordre des Experts Comptable en Tunisie
(OECT) pour l’implémentation des dispositions de l’IEPS 2 dans le système éducatif et la formation
professionnelle des futurs experts comptables ainsi que dans les programmes de formation continue des
membres de l’ordre.
2.2.
Responsabilités de l’expert comptable dans les missions de conseil en système
d’information
Cette responsabilité peut être civile, pénale et disciplinaire.
2.2.1. La responsabilité civile
La responsabilité civile relative aux activités de conseil est régie par l’article 89 du code des obligations et des
contrats qui stipule « Un simple conseil ou une recommandation n'engage pas la responsabilité de son auteur, si
ce n'est dans les cas suivants :

s'il a donné ce conseil dans le but de tromper l'autre partie ;

lorsque, étant intervenu dans une affaire, en raison de ses fonctions, il a commis une faute lourde, ne
pouvant être commise par une personne dans sa position, et qu'il en est résulté un dommage pour l'autre
partie ;

lorsqu'il a garanti le résultat de l'affaire ».
De son coté, l’article 843 du même code précise que le locataire de services est responsable de « sa négligence,
son imprudence et de son impéritie ».
Dans tous les cas, la responsabilité civile de l’expert-comptable ne sera engagée qu'à la condition que le lien de
causalité entre la faute et le préjudice subi soit prouvé.
Dans les activités de conseil, l’expert comptable a généralement une obligation de moyens plutôt une obligation
de résultat. Dans les obligations de moyens, il est plus difficile de démonter la faute de l’expert comptable et son
lien direct ave le préjudice subi par l’entreprise.
Si l’expert comptable s’engage au niveau du contrat de service sur des résultats : respect de délais, un bénéfice
financier déterminé,…il sera plus facile de déterminer la faute et engager sa responsabilité civile.
Dans les contrats de service, il est possible de limiter la responsabilité civile de l’expert comptable aux montants
des honoraires convenus.
Page 106
Deuxième Partie
2.2.2. La responsabilité pénale
La responsabilité pénale des experts comptables qui peut être engagée dans les activités de conseil résulte des
deux textes suivants :

L’article 254 du code pénal : « Sont punis de six mois d'emprisonnement et de cent vingt dinars d'amende,
les médecins, chirurgiens et autres agents de la santé, les pharmaciens, sages-femmes et toutes autres
personnes qui, de par leur état ou profession, sont dépositaires de secrets, auront, hors le cas où la loi les
oblige ou les autorise à se porter dénonciateurs, révélé ces secrets »

L’article 32 du code pénal ; « Est considéré complice et puni comme tel 3/ celui qui, en connaissance du
but, a aidé l'auteur de l'infraction dans les faits qui l'ont préparée ou facilitée… ». Il est possible que les
juges puissent voir dans certains agissements professionnels un signe suffisant d’une collusion et d’une
complicité avec l’auteur principal des fautes.
En matière pénale, la responsabilité pénale est engagée si les trois éléments suivants sont réunis :

l’élément légal : la faute est sanctionnée par un texte légal ;

l’élément matériel : matérialisation de la faute commise ;

l’élément moral : la faute est intentionnelle.
2.2.3. La responsabilité disciplinaire
Conformément au décret n°89-541 fixant les modalités d’organisation et de fonctionnement de l’ordre des
experts comptables, la chambre de discipline instituée au sein de l’ordre peut être saisie dans les cas suivants :

les infractions au code des devoirs professionnels et au règlement intérieur de l’ordre : non établissement
de lettres de mission, concurrence déloyale,…

condamnation d’un membre de l’ordre par les tribunaux à une peine entraînant sa privation du droit
d’exercer une profession commerciale ;

toute réclamation ou toute plainte relative à des faits susceptibles d’entraîner des poursuites disciplinaires.
Suite à de telles poursuites disciplinaires, la chambre de discipline, peut prononcer, à l’encontre de l’expertcomptable et suivant la gravité de la faute qu’il a commise un avertissement, un blâme écrit, une suspension de
l'ordre d’un à cinq ans voire même la radiation.
2.3.
Démarche dans les missions de conseil aux entreprises
En dépit de la diversité des interventions en matière de conseil aux entreprises, la littérature 58dans ce domaine
a normalisé ces interventions selon plusieurs étapes qui sont communes à toutes les missions de conseil :
l’entrée en contact et le contrat, le diagnostic, le plan d’actions, la mise en œuvre et la conclusion de la mission.
58
Linda Stroth & Homer Johnson, The Basic principles of effective consulting, Lawrence Erlbaum Associates, 2006 ; Milan Kubr; Le
conseil en management. Guide pour la profession, 1998
Page 107
Deuxième Partie
2.3.1. L’entrée en contact et le contrat
Cette phase inclut les activités suivantes :

Les contacts initiaux : ces contacts peuvent avoir lieu selon plusieurs moyens : appels d’offres, demandes
de consultation, offres de services, manifestation d’intérêts,…

Le diagnostic préliminaire : ce diagnostic est réalisé essentiellement à travers une réunion avec les
responsables de la société pour mieux comprendre les besoins et le cadre d’intervention.

La stratégie d’intervention et le plan de mission : le consultant doit préparer à la lumière des
informations collectées un plan d’intervention indiquant la démarche et le planning.

La proposition d’assistance : c’est la matérialisation de la compréhension du besoin de la société et la
capacité et la volonté de réaliser l’intervention. La proposition inclut essentiellement le plan de mission et
l’offre financière.

Le contrat d’assistance : Après avoir été sélectionné par le donneur d’ordre, un contrat de service sera
conclu entre les deux parties indiquant les obligations réciproques de chaque partie.
2.3.2. Le diagnostic
La phase de diagnostic inclut les cinq étapes suivantes :

Identifier et comprendre le problème : avant de commencer la collecte des données, le consultant doit
avoir une compréhension suffisante du problème, objet de son intervention. Il doit déterminer les questions
importantes qui doivent être abordées pour résoudre ce problème.

Déterminer les données qui doivent être recueillies pour étudier le problème : cette étape consiste à
déterminer les informations qui sont nécessaires pour répondre aux interrogations identifiées importantes
pour traiter le problème.

Déterminer les sources des données : il s’agit de définir les sources des informations à collecter : sources
internes ou externes.

Décider la méthode de collecte des données : entretien, collecte de la documentation, questionnaire ou
observation directe.

Analyser les données recueillies et information du client des conclusions obtenues: il s’agit ici
d’examiner les informations recueillies, de tirer les conclusions et d’informer le client sur les faits constatés
et les recommandations proposées.
Page 108
Deuxième Partie
2.3.3. Le plan d’actions
Il s’agit de définir les actions nécessaires pour la mise en place des solutions et recommandations proposées.
Pour faciliter la décision du client sur les actions à entreprendre, le plan d’actions doit inclure :

une présentation des différentes solutions et scénarios possibles ;

une comparaison et évaluation des solutions proposées ;

la définition de la trajectoire pour la mise en place des solutions proposées.
2.3.4. La mise en œuvre
Après la validation des actions avec le client, le consultant participe dans la mise en œuvre de ces actions. Le
rôle du consultant peut aller du pilotage jusqu’à la participation effective dans la réalisation des actions. On
distingue généralement entre trois modèles de conduite de mission :

Le modèle faire : le consultant est le seul responsable de l’exécution du plan d’actions.

Le modèle faire faire : le rôle du consultant se limite à piloter et accompagner les équipes du client dans la
réalisation des actions.

Le modèle faire avec : dans ce cas, les travaux nécessaires pour l’exécution du plan d’actions seront
réalisés conjointement par les consultants et les équipes internes du client.
Au cours de la phase de mise en œuvre, le consultant doit prêter une attention particulière au respect du
planning et la gestion du changement.
2.3.5. La conclusion de la mission
La fin de la mission est caractérisée par la production d’un rapport final indiquant l’avancement dans la
réalisation des objectifs de l’intervention et mettant l’accent sur l’apport du consultant.
SECTION 2 : DOMAINES D’INTERVENTION DE L’EXPERT COMPTABLE
DANS LE PROJET
Dans le cadre d’un projet de changement du système d’information, l’expert comptable peut accompagner les
banques et leur apporter ses services d’assistance dans les différentes étapes du projet depuis l’expression du
besoin pour le changement jusqu’à la mise en production. Les domaines d’intervention de l’expert comptable
sont multiples, ils peuvent être regroupés selon les cinq activités suivantes :

sélection et choix de la solution ;

pilotage global du projet de mise en place ;
Page 109
Deuxième Partie

réalisation et configuration de la solution ;

conduite du changement ;

migration des données vers le système cible.
On présentera pour chaque activité, la nature des prestations que peut fournir l’expert comptable à la banque,
ainsi que les modalités d’exécution de ces prestations et les types de livrables qu’il peur établir. Toute
intervention de l’expert comptable sur un domaine spécifique doit être précédée par la conclusion d’une
convention d’assistance ainsi qu’un diagnostic de l’existant. Ces éléments communs à toute intervention ne
seront pas détaillés.
Paragraphe 1 : Assistance dans le choix de la solution
La sélection d’un progiciel bancaire est un projet à part entière incluant plusieurs phases. L’expert comptable est
en mesure d’assister les banques dans la réalisation des activités requises pour chacune de ces phases.
1. Assistance dans la construction du schéma directeur informatique
La définition d’un schéma directeur informatique est une étape préalable au choix de la solution à mettre en
place. Ce schéma permet de définir les insuffisances du système actuel et les principales orientations et
exigences pour le système futur. Il définit également les grandes lignes et actions nécessaires pour atteindre
l’architecture cible. Les missions qui peuvent être confiées à l’expert comptable dans le cadre d’une mission
d’assistance à la réalisation d’un schéma directeur informatique se détaillent ainsi selon un ordre chronologique :
 Etat des lieux et analyse de l’existant :

définir la démarche de construction du schéma directeur ;

préparer les supports du premier comité de pilotage de lancement du projet ;

animer les travaux du comité de pilotage de lancement de projet ;

arrêter la démarche définitive après prise en compte des recommandations du comité de pilotage ;

constituer les ateliers de travail pour la description de l’existant sur les trois axes d’analyse du schéma
directeur : axe fonctionnel/applicatif, axe architecture technique, axe organisation direction système
d’information. Les ateliers de travail sont constitués des consultants de l’expert comptable ainsi que des
responsables opérationnels. Il est possible de faire appel à des spécialistes informatiques pour traiter les
aspects techniques : système d’exploitation et base de données, sécurité informatique, réseau,…

établir les canevas et les modèles à utiliser pour la réalisation de l’analyse de l’existant : canevas de
couverture des processus par des applications, canevas de description des processus,…
Page 110
Deuxième Partie

définir les critères et des grilles d’évaluation de la performance technique et fonctionnelle des applications
existantes ;

réaliser les comptes rendus des réunions de travail ou des entretiens ;

réaliser les synthèses des travaux ;

valider les résultats obtenus avec les responsables concernés et ajuster les synthèses éventuellement ;

préparer les supports du comité de pilotage incluant des conclusions sur l’analyse de l’existant, les
insuffisances et les pistes d’amélioration.
 Définition des objectifs et principes directeurs

établir la liste des objectifs et principes directeurs possibles ;

identifier les décideurs à interviewer ;

mener des entretiens individuels et apprécier le degré d’importance de chaque principe exigé (haute,
moyenne ou faible) ;

arrêter et valider par le comité de pilotage la liste définitive de l’ensemble des objectifs et principes
directeurs du nouveau système d’information.
 Benchmarking et grandes tendances

réaliser des études comparatives des systèmes et organisations utilisés par les banques de la place ;

réaliser des études sur les systèmes utilisés par des banques étrangères ayant des activités similaires et
une taille similaire ;

réaliser des études sur les principaux éditeurs de solutions de « Global Banking » ;

planifier et organiser des visites à d’autres banques ;

réaliser les comptes rendus de visite.
 Définition de la cible

identifier et documenter les différents scénarii du système cible : évolution du système actuel, migrer tout ou
une partie des modules fonctionnels vers un Global Banking, migrer vers la solution de la société mère,…

identifier les principales actions à mener pour la réalisation de chaque scénario ;

identifier la charge de réalisation de chaque scénario ;

identifier les risques de chaque scénario ;

identifier les impacts de chaque scénario ;

évaluer les avantages et inconvénients de chaque scénario notamment sur la base de degré d’adéquation
avec les principes directeurs ainsi que les efforts et risques de réalisation ;

préparer les supports de comité de pilotage de validation du scénario cible ;
Page 111
Deuxième Partie
 Définition de la trajectoire de convergence vers la cible

identifier et valider les actions urgentes « Quik Wins » ;

construire et valider la feuille de route pour la réalisation de la cible ;

piloter la réalisation et l’avancement des « Quik Wins » ;
2. Assistance dans la rédaction du cahier des charges
Pour garantir la qualité des réponses des éditeurs, la banque peut faire appel aux services de l’expert comptable
pour l’assister dans la rédaction du cahier des charges. Le cahier des charges doit définir dans les détails les
questions à poser aux éditeurs et qui permettent d’évaluer l’adéquation de sa solution par rapport aux exigences
de la banque. L’intervention de l’expert comptable consiste à :

arrêter et valider la démarche de rédaction du cahier des charges ;

constituer les équipes de rédaction du cahier des charges. Trois équipes sont à prévoir : une équipe qui
s’intéresse aux exigences fonctionnelles, une autre traite les exigences techniques et une troisième équipe
s’intéresse aux questions sur l’éditeur et ses services commerciaux. Les équipes doivent inclure des
personnes internes de la banque ;

définir les règles à respecter : éviter les questions ouvertes dans un domaine particulier, privilégier les
questions ouvertes sur d’autres domaines,…

préparer le canevas et la structure du cahier des charges. Pour les marchés publics, le cahier des charges
doit obéir à un certain formalisme règlementaire59. ;

affecter les différentes parties du cahier des charges aux équipes de rédaction ;

fournir les questions standards d’un cahier des charges de choix d’un système d’information : questions sur
l’éditeur, questions commerciales,…

s’assurer que les exigences fonctionnelles et techniques définies dans le cadre de la construction du
schéma directeur sont incluses dans le cahier des charges ;

s’assurer du respect des délais de réalisation du cahier de charge et remonter des alertes ou risques
éventuellement ;

tenir des réunions de validation avec les responsables concernés ;

consolider les travaux de rédaction dans un seul document et s’assurer de sa cohérence et l’absence de
redondance.
59
Décret 2002-3158 du 17 décembre 2002 tel que modifié par les textes subséquents portant réglementation des marchés publics
Page 112
Deuxième Partie
3. Assistance dans l’évaluation des offres
Les réponses des éditeurs à l’appel d’offre doivent faire l’objet d’une évaluation objective. L’expert comptable
peut assister la banque dans la réalisation de ces travaux d’évaluation :

définir et valider le processus d’évaluation ;

définir les grilles d’évaluation des réponses et de notation des éditeurs ;

constituer des équipes de lecture et d’évaluation des réponses des éditeurs ;

participer dans les travaux de lecture et d’attribution des notes ;

demander les informations complémentaires si les réponses sont ambigües ou incomplètes ;

consolider les travaux de notation des éditeurs et faire un classement des éditeurs ;

présenter les résultats des travaux d’évaluation au management de la banque en indiquant les avantages et
inconvénients de chaque solution ;

valider la « short list » des éditeurs.
L’intervention de l’expert comptable continue aussi après la validation de la « short list » :

identifier les banques à visiter ;

coordonner les visites entre les responsables des deux banques ;

préparer les interrogations à poser aux banques à visiter ;

établir les comptes rendus de visite ;

organiser des séances de présentation avec les éditeurs sélectionnés : définition du périmètre, des ateliers
et des populations concernées ;

identifier les écarts fonctionnels ;

valider la liste des écarts fonctionnels avec les participants et l’éditeur ;

tenir des réunions avec la direction générale de l’éditeur ;

établir les comptes rendu de réunion ;

mettre à jour les évaluations des éditeurs et proposer un nouveau classement ;

identifier la meilleure offre et présenter les avantages comparatifs avec les autres solutions ;

préparer les supports de la réunion de sélection de la solution ;

piloter la réunion de sélection.
Page 113
Deuxième Partie
4. Assistance dans l’établissement des contrats avec l’éditeur
L’expert comptable peut assister la banque dans la définition des termes des contrats à signer avec l’éditeur.
Son intervention consiste à apporter un examen critique aux projets de contrats et fournir toute modification et
amélioration qui permet de préserver les intérêts de la banque. Il peut s’agit par exemple :

ajouter des clauses sur la performance du système ;

préciser les règles de facturation des développements spécifiques ;

préciser les règles de facturation des prestations de mise en place notamment les remboursements de frais.

préciser les responsabilités en matière de mise en place ;

définir avec précision certaines notions importantes : recette provisoire, recette définitive, Gap (écart
fonctionnel), anomalies,…

définir le périmètre des travaux de maintenance.
Paragraphe 2 : Assistance dans le pilotage global du projet de mise
en place
Le changement du système d’information d’une banque constitue un projet lourd et complexe constitué de
plusieurs étapes faisant intervenir plusieurs personnes et nécessitant la mise en œuvre de plusieurs actions. Le
pilotage ou le management des différentes activités du projet relève de la responsabilité de la direction du projet.
Cette dernière fait appel dans la plupart du temps aux services de consultants externes pour l’assister dans ces
activités de pilotage. On présentera en premier lieu les activités de pilotage d’un projet de changement de
système d’information et dans un second temps la démarche d’assistance de l’expert comptable dans les travaux
de pilotage.
1. Présentation des activités du pilotage
Les activités de pilotage incluent toutes les activités de planification, organisation, suivi, maîtrise et compte rendu
de tous les aspects d’un projet et de la motivation des personnes impliquées pour atteindre les objectifs du
projet. Il s’agit en effet des neuf domaines/processus définis par les normes de gestion de projet 60: management
de l’intégration du projet, management du contenu du projet, management des délais, Management des coûts,
management des ressources humaines, management des communications, management des risques,
management des approvisionnements et management de la qualité.
60
Cf. Partie 1, chapitre 2, Section 1
Page 114
Deuxième Partie
La réalisation de ces différentes activités de management est de la responsabilité de la direction du projet qui est
responsable à l’aboutissement du projet à ses objectifs en terme de délais, coûts, contenu et qualités prévus.
2. Démarche d’assistance de l’expert comptable :
Toutes les activités de pilotage de projet peuvent faire l’objet d’une assistance à l’exception des activités de prise
de décision et de validation des choix ou options qui restent du ressort du comité de pilotage et de la direction
interne du projet. On présentera pour chaque domaine de management du projet les activités d’assistance qui
peuvent être réalisés par l’expert comptable :
 Management de l’intégration du projet

établir le plan de management du projet ;

planifier les travaux et les actions ;

proposer des démarches et des méthodologies ;

définir des procédures ;

piloter les réunions et établir les comptes rendus ;

coordonner entre les différents acteurs ;

suivre l’avancement des travaux et la réalisation des actions ;

remonter les alertes et les risques et proposer les solutions ;

proposer des modifications au plan de management : planning, phases,…

piloter et animer l’équipe du projet ;

préparer les supports des comités de pilotage ;

animer les réunions du comité de pilotage.
 Management du contenu du projet

définir le périmètre précis du projet ;

découper le projet en constituants afin de répartir les responsabilités ;

définir l’organisation du projet : chantiers fonctionnels, chantiers techniques,…

définir les livrables attendus de chaque partie intervenante ;

s’assurer que la réalisation des travaux est conforme au périmètre défini et qu’aucun aspect n’a été omis ;

proposer et documenter les changements dans le périmètre du projet.
 Management des délais

identifier les activités et actions nécessaires pour réaliser le projet ;

définir la séquence des activités ;
Page 115
Deuxième Partie

déterminer les ressources nécessaires à la réalisation de chaque activité ;

estimer la durée de réalisation de chaque activité ;

établir le planning détaillé de mise en place ;

s’assurer que l’exécution des travaux est conforme au planning défini ;

remonter les risques et les alertes et proposer des solutions ;

proposer et documenter les modifications au planning.
 Management des coûts

proposer des règles d’élaboration, de suivi et de reporting des coûts du projet ;

définir les sources de coût du projet : licences, matériels, consultants, équipes internes,…

fournir une estimation des coûts et élaboration du budget ;

suivre les coûts : comparer les réalisations par rapport au budget ;

proposer des actions pour corriger les écarts enregistrés ;

proposer et argumenter la mise à jour du budget.
 Management des ressources humaines

définir l’organigramme du projet ;

définir les rôles et les responsabilités

identifier les besoins en ressources pour chaque activité ;

définir les compétences requises pour chaque ressource ;

constituer les équipes du projet ;

définir les besoins en formation ;

définir le système d’évaluation et le système de reconnaissance et de récompense ;

suivi des consommations des membres du projet ;

gérer les conflits et résoudre les problèmes majeurs ;

évaluer les performances ;

proposer et organiser des actions de formation ;

contrôler en permanence l’adéquation des ressources aux responsabilités confiées ;

proposer des modifications de ressources.
 Management de la communication61
61

définir les besoins en informations des parties prenantes du projet ;

définir les règles de communication : format, périodicité, destinataires, niveau de confidentialité,…
Cf. page 125, Paragraphe 5 : Assistance dans la conduite du changement
Page 116
Deuxième Partie

administrer les flux d’information : veiller à la qualité des informations produites, faire respecter les règles de
confidentialité,…

organiser des actions de communication ;

préparer les supports des actions de communication.
 Management des risques

identifier les sources de risques pouvant avoir des impacts sur le projet ;

évaluer les risques : probabilité d’occurrence et impacts éventuels ;

planifier les réponses aux risques identifiés : éliminer, accepter, réduire, transférer,…

suivi des risques et des résultats de réponses aux risques tout au long du projet ;

identifier les nouveaux risques et proposer les solutions correctives.
 Management des approvisionnements

identifier les achats et marchés nécessaires ;

proposer une procédure de traitement des approvisionnements ;

rédiger les cahiers des charges ;

définir un système d’évaluation des offres ;

évaluer les offres et participer dans le choix des fournisseurs ;

apprécier les contrats et les conventions conclues ;

vérifier l’exécution du contrat et sa conformité par rapport aux exigences contractuelles ;

gérer la fin du contrat : réception définitive, proposer des résiliations,…
 Management de la qualité

définir le plan d’assurance qualité du projet (PAQ)62 : identifier les règles de qualité à respecter : méthodes
et outils appliqués, livrables exigés, procédures de travail, cadre normatif utilisé,…

s’assurer de l’exécution et de l’application des dispositions du plan assurance qualité tout au long du projet

mettre à jour le plan assurance qualité.
Un plan d'assurance qualité (PAQ) sert à décrire l'ensemble des dispositions spécifiques prises pour assurer la qualité du produit
fourni dans le cadre d'un projet ainsi que la qualité du processus de développement.(www.wikipedia.org)
Page 117
62
Deuxième Partie
Paragraphe 3 : Assistance dans la réalisation et l’homologation de
la solution
Dans le cadre de la configuration et la validation du nouveau système, la banque peut faire appel aux services
de l’expert comptable pour l’assister dans la réalisation des différents travaux. A titre de rappel, cette phase du
projet consiste à :

paramétrer la nouvelle solution selon les exigences fonctionnelles de la banque (1),

réaliser les développements spécifiques nécessaires au déploiement (2), et

exécuter les tests nécessaires pour l’homologation de la solution et les processus de migration (3).
1. Assistance dans les activités de paramétrage
L’intervention de l’expert comptable dans les activités de paramétrage concerne :

les travaux d’analyse et de conception nécessaires avant tout paramétrage (1.1) ;

la réalisation des tests unitaires (1.2).
La contribution dans la réalisation de ces travaux nécessite au préalable la participation dans les actions de
formation dispensées par l’éditeur de la solution ainsi que la revue de la documentation. Sur un plan pratique,
l’intervention de l’expert comptable consiste à affecter des ressources à chaque chantier fonctionnel. Les
principaux chantiers étant : le chantier comptabilité et référentiel, le chantier engagements et risque, le chantier
agence et le chantier moyens de paiement.
1.1. les travaux d’analyse et de conception
L’expert comptable peut assister la banque principalement dans les activités suivantes :
1.1.1. Elaboration des processus cibles à mettre en place
Le changement du système d’information est toujours accompagné par des changements dans les processus
métier de la banque. Les nouveaux processus résultent d’une adéquation entre les besoins de la banque et
l’offre de l’éditeur. Si la solution ne permet pas la réalisation d’un processus selon les exigences de la banque et
que l’adaptation à ce que permet la solution n’est pas satisfaisante ou elle est contraire à la règlementation, il
s’agit d’un écart fonctionnel ou Gap.
La démarche d’assistance pour la réalisation des processus cibles obéit aux étapes suivantes :

décrire les processus actuels : processus octroi de crédit, compensation chèques, change manuel, mise à
disposition, placements bons de caisse,….
Page 118
Deuxième Partie

identifier les dysfonctionnements au niveau des processus existants ;

identifier les pistes d'amélioration des processus existants ;

recueillir les exigences des expert-métiers ;

définir les processus exigés ;

analyser les écarts entre processus exigés et les options et spécificités de la solution ;

proposer les solutions de contournement ;

organiser des ateliers d’arbitrages par rapport aux écarts identifiés : alignement à la solution ou
développement spécifique ;

formaliser les processus cibles en tenant compte des arbitrages validés.
1.1.2. Elaboration des processus de la phase transitoire
Lorsque la stratégie de bascule retenue prévoit une bascule progressive par lots d’agences ou par module
fonctionnel, l’expert comptable peut assister la banque dans la définition des processus de la phase transitoire. Il
s’agit essentiellement des processus faisant intervenir à la fois des agences basculées au nouveau système et
des agences non basculées : opération de retrait espèce déplacé, opération de versement espèce déplacé,
opérations de transfert de fonds inter-agence, virement inter-agence, remise chèque ou effet inter-agence,…
L’expert comptable doit :

identifier les processus qui sont impactés par le régime transitoire ;

proposer un processus de gestion du régime transitoire ;

tenir des réunions avec le chantier interface pour apprécier la faisabilité et la complexité ;

arrêter les processus transitoires y compris les schémas comptables ;

définir les besoins de développement.
1.1.3. Elaboration du nouveau plan de comptes
Dans la plus part du temps, le changement du système d’information est accompagné par un changement du
plan de comptes. L’expert comptable peut être sollicité pour réaliser le nouveau plan de comptes. Ce dernier doit
obéir aux principes suivants :

conforme à la norme comptable 22 relative au contrôle interne et l’organisation comptable dans les
établissements bancaires ;

conforme aux exigences de la nouvelle solution notamment en termes de nature et structure des comptes ;

contient les attributs d’information que les autres référentiels ne permettent pas de gérer.
Page 119
Deuxième Partie
1.1.4. Elaboration/Formalisation des schémas comptables cibles
Dans les solutions de progiciel, les schémas comptables sont définis à l’avance pour tout le catalogue des
transactions possibles par la solution. L’intervention de l’expert comptable consiste à :

s’assurer de la validité des schémas proposés notamment par rapport aux exigences règlementaires ;

proposer les comptes à mouvementer pour toutes les transactions à paramétrer ;

centraliser et formaliser dans un document de référence (manuel comptable), les transactions bancaires et
les schémas comptables correspondants.
1.1.5. Elaboration des fiches de produits et services
Une grande partie des activités de paramétrage est dédiée au paramétrage des produits et services offerts par la
banque ainsi que leurs règles de gestion : clientèle éligible, tarifs, règles d’arrêté…
L’expert comptable peut dans ce cadre assister la banque pour l’établissement des fiches des différents produits
et services commercialisés:

définir les différents produits comptes, règles de fonctionnement, les règles d’arrêtés,…

définir les produits placements de la clientèle, règles de fonctionnement, conditions standards de
rémunérations,...

définir les produits crédits, règles d’éligibilité, conditions standards, documents exigés,…

définir les produits cautions et les règles de gestion ;

définir les services et packages : abonnement web banking, virements permanents,…
1.1.6. Définition de la matrice opération-comptes
Afin de sécuriser les transactions dans le système cible, il faut définir les comptes éligibles à toute transaction
paramétrée. A titre d’exemples :

l’opération de retrait espèce ne peut pas être autorisée sur un compte de dépôt à terme ou un compte
général. Elle n’est possible que sur des comptes courants ou comptes épargne ;

l’opération de versement dinar n’est pas possible sur un compte en dinar convertible ;

l’opération de retrait espèce n’est pas possible sur un compte indisponible.
La démarche de l’expert comptable consiste donc à formaliser la liste des transactions paramétrées et définir
avec les responsables métiers le périmètre d’application de chaque transaction. Il est possible d’utiliser les
contrôles existants dans le système actuel pour construire cette matrice.
Page 120
Deuxième Partie
1.1.7. Définition des profils et habilitations des utilisateurs
Il s’agit d’affecter les menus et les programmes de la solution aux différents utilisateurs de la banque. La
démarche consiste généralement à :

prendre connaissance des fonctionnalités de chaque programme de la solution ;

définir les profils et les fiches de fonction de chaque profil :
- agence : chef d’agence, front office, caissier, contrôleur,…
- comptabilité : responsable, lettrage, comptabilité clients, contrôles comptes généraux,…
- informatique : responsable production, gestionnaire de base de données,….

affecter les programmes à chaque profil ;

valider avec les équipes métier l’affectation des programmes aux profils ;

classer les utilisateurs selon les profils définis.
1.2.
La réalisation des tests unitaires.
Avant que les paramétrages réalisés ne soient portés sur l’environnement de référence, l’expert comptable peut
assister la banque dans la réalisation des tests unitaires. Il s’agit principalement de vérifier que l’opération testée
a respecté les règles de gestion paramétrées et que les schémas comptables définis ont été respectés. Des
comptes rendus des tests unitaires doivent être établis pour matérialiser et documenter le transfert de
paramétrage vers l’environnement de référence.
2. Assistance dans les activités de développement
Les travaux de développement concernent le développement des programmes d’interfaces, le développement
des écarts fonctionnels et le développement des éditiques et reportings.
Tout développement doit être précédé de spécifications fonctionnelles. L’expert comptable peut assister la
banque dans la réalisation de toute ou partie de ces spécifications.
2.1.
Spécifications des éditiques et reportings
Il s’agit ici d’un chantier important qui peut être pris en charge par l’expert comptable. En effet, la règlementation
bancaire a exigé des banques un nombre important de déclarations notamment en matière comptable et risque.
Le volume devient plus important si la banque appartient à un groupe où des reportings complémentaires sont
demandées par la société mère. Le périmètre des éditiques inclut également les éditions et états à destination
des clients ou les utilisateurs internes de la banque.
Page 121
Deuxième Partie
La démarche consiste à :

définir les exigences de la banque en terme d’états et éditions (périmètre par module fonctionnel, format de
sortie, périodicité…) ;

prendre connaissance des états existants en natif dans la solution ;

apprécier l’adéquation des états natifs aux besoins de la banque ;

identifier les états nécessitant des développements spécifiques ;

établir des spécifications détaillées des états à développer.
Les spécifications consistent à fournir :

la forme de l’état de sortie ;

le format de génération : Excel, word, Acrobat Reader,….

les périodicités de génération : quotidienne, mensuelle,…

la méthode de génération : à la demande ou automatique (après chaque TFJ par exemple) ;

les utilisateurs des états et les profils habilités à les générer ;

les règles de gestion de chaque rubrique constituant l’état : source d’alimentation (comptable, dossier de
crédit, référentiel client, évènements…), attributs d’information à utiliser, calcul à effectuer,…
Exemples d’états pouvant faire l’objet d’assistance dans la spécification :

états financiers : bilan, état de résultat, notes aux états financiers ;

déclarations mensuelles comptables à destination de la banque centrale ;

liasse de consolidation à destination de la société mère ;

tableau des créances et engagements ;
2.2.
Spécifications des écarts fonctionnels ou « Gaps »
L’expert comptable peut assister les banques dans les spécifications des écarts fonctionnels identifiés et ayant
fait l’objet des validations nécessaires. Ces spécifications doivent être établies conformément aux normes et
standards du projet si elles existent. Dans le cas contraire, l’expert comptable doit proposer une structure de
spécifications qui doit être appliquée pour tous les « gaps » identifiés. Cette proposition doit être validée par
l’éditeur. Les spécifications des « gap » peuvent être structurées comme suit :

objet du document ;

définitions et abréviations utilisées ;

question ouvertes et non résolues : points non clairs au jour de rédaction ;

besoins de la banque : origine du gap, dispositions règlementaires, besoin métier justifiant le gap,…
Page 122
Deuxième Partie

spécifications fonctionnelles détaillées : lister les besoins en incluant tous les éléments significatifs
permettant le développement de la solution :
-
schémas comptables ;
-
description du processus bancaire ;
-
liste des éléments de tarification (date de valeur, liste des commissions,…) ;
-
liste et format des éditions liées ;
-
éventuelle suggestion des écrans à modifier/créer.
2.3.
Spécifications des programmes d’interface
Bien qu’il s’agit dans la plus part du temps de problématiques techniques, l’expert comptable peut intervenir dans
les spécifications des programmes d’interface notamment dans les situations suivantes :

rédiger les spécifications nécessaires pour la gestion des processus transitoires ;

définir les spécifications pour les interfaces d’ordre comptable : contrôles comptables à effectuer (équilibre,
date, création compte, création client,…), matrice de correspondance à appliquer,…

définir les schémas comptables à générer pour les interfaces qui seront maintenues même après la phase
transitoire : l’interface entre deux applications nécessite l’utilisation de comptes d’ordre spécifique,…
3. Assistance dans les activités d’homologation
A l’issue de cette étape, le nouveau système sera homologué pour un déploiement effectif dans les agences.
L’expert comptable peut assister la banque dans les activités principales de cette étape :
3.1.
Définition du plan de tests
Il s’agit de décrire la stratégie de tests notamment :

la démarche et les processus à appliquer : la démarche de réalisation des travaux d’homologation inclut
plusieurs étapes : rédaction des scénarios de tests, réalisation des tests sur plusieurs cycles, gestion des
anomalies,…

les intervenants dans chaque étape : les chantiers fonctionnels se chargeront de la rédaction des scénarios
et des cas de tests, une équipe dédiée se chargera de la réalisation des tests, les chantiers fonctionnels et
les consultants de l’éditeur se chargeront de la résolution des anomalies,…

le planning et les objectifs de chaque cycle de recette ;
Page 123
Deuxième Partie

les modèles et canevas : modèles de conception des scénarios de test et des cas de tests, modèle de PV
de validation d’un scénario de test,…

les outils : outil de suivi des tests, outil de gestion des anomalies,…
3.2.
Rédaction des scénarios de recette et détermination des cas de tests
L’expert comptable peut assister la banque dans les travaux de rédaction des scénarios de recette et la
détermination des cas de tests :

définir et diriger les équipes de rédaction des scénarios : chaque chantier fonctionnel se chargera de la
rédaction des scénarios des processus qui viennent de le paramétrer ;

participer dans les travaux de rédaction des scénarios ;

veiller à ce que tous les cas possibles pour un processus ont été identifiés et formalisés en distinguant entre
processus transitoires et processus cibles ;

veiller à préciser les résultats attendus de chaque étape du scénario : message d’erreur, édition, schémas
comptables,…

veiller à ce que les cas de test choisis incluent aussi bien des données saisies ou des données migrées
dans le cadre de simulation de bascule.
3.3.
Réalisation des tests
Pour assurer une appropriation du nouveau système par les futurs utilisateurs internes, les banques n’ont pas
intérêt à confier à l’expert comptable des travaux de tests et de validation des processus du nouveau système
d’information. L’intervention de l’expert comptable doit être limitée à ce niveau à la coordination des travaux de
tests : préparation des environnements techniques, coordination des traitements de fin de journées,…
3.4.
Gestion des anomalies
A ce niveau, l’intervention de l’expert comptable peut consister à :

définir le processus de gestion des anomalies ;

préparer les spécifications pour le développement d’un outil de gestion des anomalies ;

tenir et piloter les réunions avec les équipes de paramétrage et les consultants de l’éditeur pour discuter des
anomalies et des solutions ;

proposer éventuellement des solutions de résolution ;

établir des synthèses périodiques sur les anomalies et l’avancement dans la résolution pour la direction du
projet et le comité de pilotage.
Page 124
Deuxième Partie
Paragraphe 4 : Assistance dans la conduite du changement
La conduite de changement consiste à définir les actions de communication, de formation et d’accompagnement
qui préparent les utilisateurs à l’utilisation du nouveau système. La banque peut recourir aux services de l’expert
comptable pour l’assister dans toute ou partie des actions de conduite du changement. Il est important que
l’expert comptable ait une connaissance approfondie du nouveau système à travers notamment la participation
dans les travaux de mise en place pour pouvoir participer dans la réalisation des actions de conduite de
changement.
1. Assistance dans les actions de communication
La communication est une composante essentielle d’un projet. Les actions de communication doivent être
structurées et se dérouler en phase avec le projet. L’intervention de l’expert comptable à ce niveau consiste dans
l’établissement du plan de communication du projet (1.1) ainsi que la participation dans la réalisation de
certaines actions de communication (1.2).
1.1.
Elaboration du plan de communication
Le plan de communication est le document qui définit la stratégie de communication dans le projet. Le plan de
communication doit permettre de répondre aux interrogations suivantes63 :

A quel moment l’action de communication sera-t-elle réalisée? (date)

A quel groupe de personnes sera destinée l’action? (groupe cible)

Quel est le contenu de l’action de communication? (message)

Quelle méthode de communication faut-il utiliser pour transmettre le message? (moyen: e-mail, newsletter,
séance d’information, dépliant, affiche, …)

Qui transmettra le message? (expéditeur)

Combien de fois cette action précise sera-t-elle répétée? (périodicité: unique, hebdomadaire, mensuelle, …)
(fréquence)

Quel matériel et infrastructure seront nécessaires pour la bonne exécution de l’action de communication:
brochure, document d’information, …? (logistique)

63
Qui est le responsable de la réalisation de l’action? (responsable)
« Etablir le plan de communication d’un projet », Direction générale Communication externe, Bruxelles, Décembre 2005
(www.fedweb.belgium.be)
Page 125
Deuxième Partie
1.2.
Assistance dans la réalisation des actions de communication
Les principales actions de communication seront réalisées sous le pilotage du service de communication de la
banque. L’expert comptable peut intervenir dans les activités suivantes :

préparation des supports de présentation de la réunion de lancement (Kickoff du projet) ;

animation de la réunion de lancement ;

assistance dans la mise en place d’une « flash info » qui constitue un support de communication interne sur
l’avancement du projet ;

préparation et animation de toute réunion d’information réalisée au cours du projet : démarrage de la
recette, démarrage de la bascule, fin du projet.
2. Assistance dans les actions de formation
L’expert comptable peut assister la banque dans les différentes actions liées à la formation :
2.1.
Elaboration du plan de formation
Le plan de formation doit traiter des aspects suivants :

les besoins en formation : formateurs, utilisateurs agence, utilisateurs comptabilité, utilisateurs back office,
équipe de production informatique,…

le programme de formation pour chaque profil identifié ;

le processus et les intervenants dans la réalisation des supports de formation et l’animation des formations;

le planning de formation : ce planning doit tenir compte du planning de mise en place du nouveau système.
Par exemple, pour les utilisateurs des agences, les actions de formation doivent être planifiées au plus tôt
15 jours avant la bascule réelle ;

les lieux de réalisation des sessions de formation ;

les pré-requis des actions de formation : installation application, base de formation dédiée, équipements de
formation,…

les canevas de support de formation et la structure à respecter ;

les questionnaires d’évaluation de formation.
2.2.
Réalisation des supports de formation
Dans le cas, où l’expert comptable a participé pleinement dans les activités de configuration et d’homologation
de la solution, il sera en mesure d’assister la banque dans la préparation des supports de formation. Les
supports de formation sont établis pour chaque profil d’utilisateur et doivent inclure :
Page 126
Deuxième Partie

une description des nouveaux modules et processus ;

des cas pratiques ;

les différences et les apports par rapport à l’ancien système.
Les supports de formation doivent être établis de manière à constituer des documents de référence et des points
de repère pour les utilisateurs non seulement lors des sessions de formation mais également lors de l’utilisation
effective du nouveau système.
2.3.
Animation des sessions de formation
Le périmètre de formation dans les projets de changement de système d’information est important. La banque
peut faire appel aux services de l’expert comptable pour l’animation des sessions de formation. La réalisation de
cette tâche nécessite une formation approfondie sur le nouveau système et les nouveaux processus.
3. Assistance dans les actions de support et d’accompagnement
Les actions de support et d’accompagnement couvrent les activités contribuant à permettre aux utilisateurs
d’assurer leurs missions en utilisant le nouveau système d’information. On distingue entre l’accompagnement sur
site et l’assistance à distance. Il est envisageable que ces activités soient sous-traitées totalement ou
partiellement auprès d’un expert comptable.
3.1.
Support sur site
L’expert comptable peut mettre à la disposition de la banque des collaborateurs qui accompagneront les
utilisateurs pendant les premiers jours de la bascule. Ces collaborateurs doivent avoir des connaissances
suffisantes sur le nouveau système et ses fonctionnalités notamment à travers la participation opérationnelle
dans les chantiers du projet ou à travers des formations dédiées. Au fur et à mesure de la migration des
agences, le savoir faire de ces collaborateurs s’améliore et le niveau de maîtrise du nouveau système augmente.
L’accompagnement sur site n’a plus d’utilité lorsque les agences acquièrent un niveau d’autonomie satisfaisant.
3.2.
Support à distance
A ce niveau, l’expert comptable peut assister la banque sur les volets suivants :

définition du processus de gestion des anomalies utilisateurs ;

spécification pour le développement d’une solution de gestion des anomalies utilisateurs ;
Page 127
Deuxième Partie

mise en place d’une structure de support à distance (helpdesk) et des outils de travail : l’expert comptable
peut affecter des collaborateurs pour cette structure. Cette structure peut assurer la résolution immédiate de
certains problèmes. Pour d’autres problèmes remontés, elle assure leurs affectations aux personnes
concernées ainsi que le suivi de leurs régularisations.

établissement et mise à jour régulière du FAQ du projet (Frequently Asked Questions).
Paragraphe 5 : Assistance dans la migration des données
Dans le cadre de leur projet de changement du système d’information, les banques peuvent faire appel aux
services de l’expert comptable pour mener à bien les travaux de migration des données vers le système cible.
L’intervention de l’expert comptable est réalisée autour des activités suivantes :

définition de la stratégie de bascule pour chaque module fonctionnel ;

définition du plan de comptes et des matrices de correspondance ;

définition des informations à migrer et les règles de migration ;

fiabilisation des données à migrer ;

définition des outils de contrôle des reprises de données ;

élaboration du plan de bascule ;

contrôle des simulations de bascule ;

assistance dans la réalisation des différentes phases de bascule.
L’ensemble de ces activités d’assistance seront détaillées au niveau du chapitre suivant.
Page 128
Deuxième Partie
Chapitre 2 : Guide méthodologique d’assistance dans la migration des données
CHAPITRE 2 : GUIDE MÉTHODOLOGIQUE D’ASSISTANCE
DANS LA MIGRATION DES DONNÉES
L’objectif de ce chapitre est de proposer une méthodologie aux experts comptables de conduite d’une mission
d’assistance pour une phase spécifique de projet de changement du système d’information d’une banque qui est
la phase de migration des données. Avant de présenter la démarche pour la conduite de cette mission
d’assistance (Section 2), on présentera les règles de proposition et d’acceptation de la mission (Section1).
SECTION 1 : PROPOSITION D’ASSISTANCE ET ACCEPTATION DE LA
MISSION
L’élément déclencheur de toute proposition d’assistance est l’appel d’offres ou la demande de consultation
lancés par le maître d’ouvrage qui est la banque qui souhaite être assistée dans la migration de ses données au
nouveau système d’information qu’elle est en train de mettre en place. Cet appel d’offres peut être général et
concerner les différentes activités du projet ou spécifique et concerner une activité déterminée du projet de
changement du système d’information. On s’intéressera dans ce qui suit uniquement à l’assistance dans l’activité
de migration des données. Deux étapes sont préalables à la réalisation de cette mission : la proposition de la
mission d’assistance (Paragraphe 1) et la conclusion d’une convention ou contrat d’assistance (Paragraphe 2).
Il n’existe pas de normes spécifiques à l’échelle nationale ou internationale concernant l’acceptation et la
réalisation de missions d’assistance y compris le conseil en système d’information. Toutefois, certains principes
impactant la conduite de ces missions ont été prévus par des dispositions règlementaires, il s’agit notamment :

Des règles d’incompatibilité prévues par l’article 252 du code des sociétés commerciales qui interdit le
cumul entre les fonctions de commissaire aux comptes et la perception d’honoraires et avantages au titre de
fonctions autres que celles de commissaire aux comptes de la société, des administrateurs, de toute
entreprise possédant le dixième du capital de la société ou dont la société possède au moins le dixième du
capital.

De l’obligation d’établir une convention ou une lettre de mission définissant les obligations réciproques des
deux parties. Cette obligation est prévue par les articles 7 et suivants du code des devoirs professionnels
des experts comptable de Tunisie approuvé par l’arrêté du ministre de finance du 26 juillet 1991.
Page 129
Deuxième Partie
Paragraphe 1 : La proposition d’assistance
La proposition d’assistance est le document de réponse établi par l’expert comptable à l’appel d’offres de la
banque demandant l’assistance. Un diagnostic préliminaire (1) sera indispensable pour planifier l’intervention (2)
et préparer la proposition d’assistance (3).
1. Le diagnostic préliminaire
Le diagnostic initial est assuré à travers une réunion avec la direction du projet. Cette réunion est bénéfique
aussi bien pour l’expert comptable que le client (la banque) :
 Pour l’expert comptable :

comprendre les objectifs stratégiques du projet directement des responsables du projet ;

identifier les différentes parties prenantes et intervenantes dans le projet ;

s’informer de l’organisation générale, du planning global et des échéances importantes du projet ;

comprendre les besoins du client et ses attentes suite à une éventuelle intervention ;

discuter des rôles et des responsabilités en cas de participation dans le projet ;

discuter des modalités de coordination entre les différents intervenants dans le projet.
 Pour le client (la banque demandant l’assistance)

s’informer du savoir faire du cabinet et des qualifications des membres clés ;

s’informer des références du cabinet dans des missions similaires ;

apprécier la valeur ajoutée que peut apporter l’expert comptable dans le projet.
D’autres outils permettent aux experts comptables de mieux cerner le contexte d’intervention dont notamment la
revue de presse, les communications financières et les rapports des commissaires aux comptes, le cadre
juridique et règlementaire et les dernières mises à jour ou recommandations des autorités de tutelle,…
2. La planification préliminaire : la stratégie d’intervention ou le plan de mission
A travers les éléments recueillis, l’expert comptable doit faire une planification préliminaire de son intervention
éventuelle afin que celle-ci soit réalisée de manière efficiente.
La planification implique l’élaboration d’une stratégie générale pour la conduite de la mission désignée
également plan de mission. Le plan de mission constitue l’un des éléments importants de la proposition
d’assistance et éventuellement la convention d’assistance.
Page 130
Deuxième Partie
Exemple : Plan de mission d’une intervention d’assistance dans la migration des données :
Etapes
Diagnostic
Principaux Objectifs
- acquérir une connaissance de la banque et
de son environnement ;
- acquérir une connaissance du projet et de
son périmètre ;
- prendre connaissance des processus et de
la qualité des données ;
- planifier et orienter la mission.
Activités
- Collecte de la documentation
- Entretiens avec les différentes parties
prenantes du projet
Définition de la stratégie de bascule pour
chaque module fonctionnel
Définition du plan des comptes et de la matrice
de correspondance
Préparation de
la Migration
- identifier et réaliser toutes les activités
préalables à la bascule ;
- mettre à l’épreuve les solutions et options
retenues.
Définition des informations à migrer et des
règles de migration
Fiabilisation des données du système source :
identification des anomalies et assistance dans
la fiabilisation
Définition des outils de contrôle
Réalisation de la
Migration
- assister les équipes de la banque dans les
travaux de validation de bascule ;
- s’assurer de la bonne exécution des actions
de bascule.
Livrables
Livrables interne :
- Dossier de la mission
- PV d’entretien
Intervenants
30 jours
homme
Livrables externe
- Plan de mission détaillé
- Description détaillée de la stratégie
de déploiement pour les différents
modules
- Plan comptable cible
- Matrice de correspondance
- Tableau de bord des informations à
migrer indiquant les sources et la
démarche
- Schémas comptables de migration
- Comptes rendus de réunion
- Rapport d’anomalie
- Rapport d’avancement
- Compte rendu de réunion
- Spécifications outils de contrôle
- Tests de cohérence
Elaboration du plan de bascule
- Plan de bascule
Contrôle des simulations de migration
- Rapport de simulation de bascule
- Assistance dans la validation de la bascule
- Participer dans le pilotage des travaux de
bascule
Charges
- Rapport de bascule
100 jours
homme
100 jours
homme
300 jours
homme
500 jours
homme
100 jours
hommes
100 jours
hommes
15 jours
homme par
simulation
15 jours
homme par
bascule réelle
Page 131
Deuxième Partie
La planification préliminaire permet à l’expert comptable:

d’accorder une attention appropriée aux aspects essentiels de l’intervention ;

identifier et résoudre les problèmes potentiels ;

assister l’expert comptable dans la sélection des membres de l'équipe à affecter à la mission ayant des
niveaux appropriés d'aptitude et de compétences pour répondre aux besoins du client ;

faciliter la direction et la supervision des membres affectés à la mission et la revue de leurs travaux.
3. La proposition de mission :
La proposition d’assistance doit s’organiser autour des points suivants :

Une reformulation du contexte de la banque, de ses métiers, des objectifs stratégiques,…

Une reformulation du projet avec ses enjeux, son périmètre, recadrage de la mission,…

Une présentation de la manière de compréhension des attentes du client (banque) : présentation des
principaux objectifs attendus par la banque et la manière dont les services de l’expert comptable peuvent
répondre à ces objectifs.

La présentation du cabinet de l’expert comptable, les principaux indicateurs commerciaux, organisationnels,
le réseau auquel il est rattaché, les publications,…

Les références dans des projets semblables en termes de fonctionnalités et du volume en indiquant l’état
d’avancement.

La présentation de l’ensemble des composantes nécessaires pour la réalisation de tout le projet en
indiquant ceux qui font l’objet de la proposition et ceux qui sont à la charge du client ou autres parties.

Le mode de coordination entre la partie du projet qu’il prend en charge et celle qui restera à la charge du
client (banque) ou autres intervenants.

Description de la démarche et la méthodologie pour la réalisation de la mission d’assistance (plan de
mission) : découpage de l’intervention en étapes, pour chaque étape : présentation de l’objectif de l’étape ;
les principales activités de l’étape ; le planning détaillé ; les intervenants et acteurs de l’étape ; les livrables
de l’étape et le processus de validation.

La méthode de suivi et du pilotage du projet que le cabinet compte mettre en place.

La méthode de gestion des éléments perturbants.

Les intervenants et les responsabilités de l’équipe de l’expert comptable : le CV de chaque intervenant doit
mettre en évidence les références des missions similaires ou d’autres missions dans le secteur bancaire
avec indication du rôle joué et la période d’intervention.
Page 132
Deuxième Partie

Un chiffrage détaillé du projet découpé par phase ou tâche. Les coûts sont exprimés en jour-homme. Ce
chiffrage sera ensuite exprimé en offre financière. Cette offre doit indiquer les tranches de règlement, les
règles pour le remboursement de frais,…
Du coté de la banque, un système d’évaluation des propositions permettra de sélectionner l’offre la plus
appropriée à ses besoins.
Paragraphe 2 : la convention d’assistance
Suite à l’acceptation de la proposition de service, une convention d’assistance doit être signée par les deux
parties : l’expert comptable en qualité d’assistant à la maîtrise d’ouvrage et la banque en tant que maître
d’œuvre. L’article 9 du code des devoirs professionnels des experts comptable de la Tunisie stipule que : «
l’acceptation de la mission par les parties doit être matérialisée par une lettre de mission ou une convention
comportant la signature de l’expert comptable et du client ». L’article 8 du même code indique que « la
convention ou la lettre de mission précise notamment :

la définition précise de la mission à accomplir ;

la périodicité ou la durée de la mission ;

le montant des honoraires et les modalités du règlement ;

les conditions générales de collaboration. »
Sur un plan pratique, les conventions d’assistance sont composées de deux parties : conditions générales
d’exécution de services (1) et le contrat d’application (2).
1. Condition générales d’exécution de services
Cette première partie du contrat indique les principes et les règles autour desquels le contrat sera exécuté par
les deux parties. Le contenu de cette première partie du contrat est constitué des clauses suivantes :
 Obligations générales des deux parties :

Obligations de l’expert comptable :
- réalisation des travaux conformément au contrat avec ses deux parties ;
- application des règles édictées par la profession ;
- ne pas procéder aux changements répétés des consultants.

Obligations de la banque :
- réaliser toutes les obligations lui incombant conformément au contrat ;
Page 133
Deuxième Partie
- communiquer à l’autre partie toutes les informations utiles ou nécessaires aux travaux après avoir
vérifié qu’elles sont complètes et exactes ;
- prendre les décisions dans les délais et procéder aux validations nécessaires ;
- désigner un correspondant investi d'un pouvoir de décision au nom de la banque ;
- avertir directement l’autre partie de toute difficulté ou problème existant ou potentiel pouvant
affecter l’exécution des travaux.
 Conventions en matière d’honoraires

faire référence au contrat d’application indiquant les honoraires et les échéances de paiement ;

intérêts de retard à calculer en cas de retard de paiement ;

nature des frais remboursables : frais de déplacement, frais d’hébergement,… et modalités de
remboursement : sur justificatifs, montant forfaitaires,…
 Confidentialité :

engagement des parties à ne pas divulguer les informations confidentielles reçues de l’autre partie ;

définition des informations confidentielles : il s’agit des informations de toute nature, visuelles ou
orales, sur quelque support que ce soit, relatives à la structure, l’organisation, les affaires, les politiques
internes diverses, les projets, et le personnel de chacune des parties. Ont également le caractère
confidentiel, les rapports, courriers, informations et avis qui sont fournis au cours de la mission ;

exceptions aux règles de confidentialité (par exemple les informations portées à la connaissance des
autres membres du cabinet qui ne sont pas affectés au projet).
 Propriété intellectuelle

droits de la banque d’utiliser en interne les résultats de travaux effectués spécifiquement par l’expert
comptable dans le cadre du contrat.

l’interdiction pour la banque de distribuer, commercialiser ou mettre à disposition à des tiers les
résultats de travaux effectués spécifiquement par l’expert comptable dans le cadre du contrat sans
l’assentiment exprès de ce dernier.

l’obligation pour la banque d’obtenir à ses charges toute autorisation nécessaire pour l’utilisation d’un
produit faisant l’objet de propriété intellectuelle appartenant à des tiers.
 Limitation des responsabilités

indication des cas où la responsabilité de l’expert comptable peut être engagée : il s’agit du cas d’un
préjudice réel, direct et certain subi par le client. Le client doit rapporter la preuve que la faute de
l’expert comptable est la cause de ce préjudice ;
Page 134
Deuxième Partie

montant maximum que l’expert comptable est condamné à payer pour dommages et intérêts des
préjudices : ce montant est généralement plafonné au montant du contrat.

délai d’action à l’encontre de l’expert comptable : ce délai peut être limité dans le temps, par exemple
un an après la livraison définitive ou la cessation du contrat.
 Résiliation : indication du délai nécessaire pour résiliation du contrat : généralement la non réparation de la
situation d’un manquement par l’une des parties à l’une de ses obligations prévues par le contrat dans un
délai de trente jours à compter d’une mise en demeure adressée par lettre recommandée avec accusée de
réception donne droit à l’autre partie la faculté de dénoncer le contrat.
 Force majeure :

Indication des effets de force majeure sur le contrat : généralement, il s’agit de la suspension
d’exécution. Dans le cas où la force majeure se prolonge sur une durée à définir par le contrat, le
contrat peut être résilié sans indemnisation des deux parties.

Indication des règles d’information de l’autre partie du cas de force majeure.
 Cessibilité et sous-traitance : indication des règles nécessaires pour la cessibilité ou la sous-traitance à
des tiers des droits et obligations nés du contrat : exigence du consentement exprès et préalable de l’autre
partie.
 Droit applicable et juridiction compétentes : Indication du droit applicable et Indication des juridictions
compétentes en cas de litige : tribunal de commerce.
2. Contrat d’application
Le contrat d’application fournit des éléments sur l’étendue et les termes de l’intervention de l’expert comptable.
Ce contrat indique principalement les éléments suivants :
 Objet et périmètre de la mission : description brève de l’objet de l’intervention et du contexte de sa
réalisation : assistance dans la migration des données dans le cadre du changement du système
d’information de la banque.
 Détail des prestations et des livrables :

description des étapes de réalisation de la mission ;

indication des principales tâches pour chaque étape ;

indication des livrables de chaque étape ;

indication du calendrier d’exécution de chaque étape.
Page 135
Deuxième Partie
 L’équipe de la mission :

indication de la liste des intervenants et de leur profil ;

rappeler l’obligation de ne pas procéder à des changements répétitifs des membres de l’équipe ;

règles et conditions de demande de remplacement d’un membre de l’équipe ;

règles et conditions de demande de réduction du nombre d’intervenants sur la mission.
 Honoraires et modalités de paiement :

Mode de facturation :
- Facturation en régie : indication du taux horaire de chaque profil intervenant (Partner, manager,
consultant,…).
- Facturation au forfait : indication du montant des honoraires pour toute la mission.

Modalités de paiement :
- Facturation en régie : facturation à la fin de chaque mois en fonction de la consommation.
- Facturation au forfait : répartition du forfait en tranches en fonction de l’avancement du projet.
 Remboursement des Frais : indication de la nature des frais à la charge du client et du mode de
facturation et des modalités de paiement.
SECTION 2 : CONDUITE DE LA MISSION D’ASSISTANCE
Bien que la migration des données constitue l’une des dernières phases d’un projet de changement de système
d’information, l’intervention de l’expert comptable doit avoir lieu depuis le démarrage du projet. Trois principales
étapes seront nécessaires pour la réalisation d’une mission d’assistance à la migration des données : Le
diagnostic (paragraphe 1), la préparation de la migration (paragraphe 2) et la réalisation et la validation de la
migration (paragraphe 3).
Paragraphe 1 : Le diagnostic
A ce stade, la convention d’assistance indiquant les grandes lignes de l’objet et de la démarche de l’intervention
a été conclue avec la banque. Toutefois, il sera toujours utile de définir un plan d’actions complet. Ceci implique
de diagnostiquer soigneusement la mission qui a été attribuée. Un diagnostic efficace inclut cinq étapes
indépendantes64 :
64
Linda Stroth & Homer Johnson, The Basic principles of effective consulting, Lawrence Erlbaum Associates, 2006, page 61
Page 136
Deuxième Partie
1. Identifier et comprendre le problème :
Dans le cadre d’une mission d’assistance dans la migration des donnés, le problème principal étant comment
assurer une migration au nouveau système d’information fiable, sécurisée et conformément aux échéances
arrêtées par le mangement. Pour répondre à cette problématique principale, l’expert comptable aura besoin des
réponses aux interrogations suivantes :

quel est le périmètre de la migration ?

quelle est la qualité des informations du système source ?

quels sont les principales différences entre le système source et le système cible ?
2. Déterminer les données qui doivent être recueillies pour étudier le problème :
Une fois que les questions importantes pour la compréhension des aspects principaux de la mission ont été
identifiées, cette étape consiste à déterminer les informations qui sont nécessaires pour répondre à ces
interrogations. Pour la réalisation d’une mission d’assistance dans la migration des données, on cite à titre
indicatif les informations suivantes :

l’organigramme du projet et les instances du pilotage ;

l’organigramme de la banque et le réseau des agences ;

le périmètre fonctionnel du projet et périmètre des activités non couvertes par le progiciel ;

les grandes lignes de la stratégie de bascule : bascule « big bang » ou bascule progressive ;

le planning de mise en place ;

l’architecture applicative du système source et la description des flux existants ;

l’architecture applicative cible ;

le manuel comptable dans le système source : plan comptable, schémas comptables, reportings,…

la structure des comptes et la gestion du plan comptable dans le système source et le système cible ;

l’existence d’un système comptable multi-devise conforme aux normes comptables ;

les travaux de contrôles comptables réalisés périodiquement ;

les insuffisances du système comptable actuel ;

les réserves et les recommandations des commissaires aux comptes et de l’audit interne ;

les chantiers de fiabilisation et d’apurement en cours ;

les écarts entre les soldes comptables et les soldes extra-comptables ;

les écarts entre les soldes des comptes généraux et les soldes des comptes auxiliaires ;

la volumétrie des opérations, des mouvements comptables, des comptes et des dossiers ;

les sources des données comptables et extra-comptables ;
Page 137
Deuxième Partie

existence de plusieurs sources de données pour les mêmes dossiers et écarts entre les différentes sources

la liste des produits comptes et les règles d’arrêté ;

le catalogue des produits et des conditions : crédits, placements, engagements par signatures,…

les principes comptables et les règles de comptabilisation dans le système cible ;

la documentation fournie par l’éditeur sur les modules inclus dans le périmètre fonctionnel : guide
utilisateurs, guide de paramétrage, documents de formations,…

les schémas comptables cibles (obtenu lors de la phase du paramétrage du nouveau système).
3. Déterminer les sources des données :
Il s’agit ici de déterminer les sources des informations identifiées comme nécessaire pour la réalisation de la
mission. Les informations peuvent être recueillies aussi bien des personnes intervenantes directement dans le
projet que d’autres personnes externes au projet.
4. Décider la méthode de collecte des données :
L’expert comptable peut s’appuyer sur l’une des techniques suivantes pour recueillir les informations jugées
nécessaire : les interviews, le recueil de la documentation et des informations, les observations directes des
exécutions de travaux et les questionnaires.
Pour une mission d’assistance dans la migration des données, les deux premières techniques permettent
l’obtention de la quasi-totalité des informations nécessaires à la conduite de la mission.
5. Analyser et tirer des conclusions des données recueillies :
La fin de la phase de collecte des données signale le début de la phase d’analyse, d’évaluation et de préparation
des actions préalables et nécessaires à la réalisation de la migration des données (paragraphe 2). Le plan de
mission sera également ajusté et mis à jour pour tenir compte des nouveaux éléments recueillis.
Paragraphe 2 : Préparation de la migration
A ce stade, les principales informations nécessaires pour la compréhension de la mission et de son contexte
sont obtenues. L’expert comptable est en mesure de réaliser les principales activités préparatrices d’une
migration des données. Les travaux de l’expert comptable seront menés au sein du chantier « reprise des
données », ce chantier constitue à la fois un chantier fonctionnel et un chantier technique. Les activités
fonctionnelles du chantier seront réalisées par l’expert comptable en collaboration avec les équipes métiers de la
Page 138
Deuxième Partie
banque et le reste des chantiers fonctionnels et techniques du projet. Les activités techniques du chantier
notamment le développement des programmes de reprise des données seront réalisés par les équipes
informatiques affectées au chantier.
Les interventions de l’expert comptable sur les différentes phases du projet du changement du système
d’information dans le cadre d’une mission d’assistance à la migration des données peuvent être résumées
comme suit :
Phase du projet
Phase de lancement
Intervention de l’expert comptable
1. Définition de la stratégie de bascule pour chaque
module fonctionnel
2. Définition du plan des comptes et des matrices de
correspondance
Phase de configuration et d’homologation de la solution
Phase de déploiement et de mise en production
3. Définition des informations à migrer et des règles de
migration
4. Fiabilisation des données du système source
5. Définition des outils de contrôle
6. Elaboration du plan de bascule
7. Contrôle des simulations de migration
1. Gestion de la phase transitoire (Parag 3)
2. La migration totale (Parag 3)
1. Définition de la stratégie de bascule par module fonctionnel
Les grandes lignes de la stratégie de bascule sont arrêtées par le management du projet dans son plan de
management du projet65. A titre de rappel, on distingue entre deux stratégies de bascule :

La bascule « big bang »: déploiement complet de la solution sur toutes les agences

La bascule progressive : déploiement progressif de la solution par lots d’agences.
On retiendra dans ce qui suit une stratégie de bascule progressive par lots d’agence. En effet, pour les banques
de détail avec un nombre d’agences important (plus de cinquante agences), une stratégie de bascule
progressive est plus appropriée notamment en raison de l’insuffisance des ressources de support qui sont
capables de servir un nombre important d’utilisateurs au même temps en cas de bascule « big bang ». Cette
stratégie de bascule constitue une ligne directrice pour l’expert comptable qu’il doit approfondir pour définir les
modalités de mise en place. En effet, dans un contexte de progiciel, composés de plusieurs modules, l’expert
comptable doit assister la banque dans le choix de la méthode de bascule des différents modules du progiciel.
Une stratégie de bascule sera définie et proposée pour chaque module inclus dans le périmètre fonctionnel du
projet.
65
Cf. page 64, point 1.2.
Page 139
Deuxième Partie
Ainsi, il est possible que la stratégie globale de bascule soit progressive par lots d’agence et que certains
modules de la solution soient basculés en « big bang ».
Le choix d’une démarche dépend essentiellement des difficultés que peut poser une gestion d’une même activité
sur deux systèmes différents. A titre d’exemple, la gestion de la compensation des valeurs notamment entre une
agence basculée et une agence non basculée nécessite beaucoup de travaux de développements et comporte
beaucoup de risques, il est donc possible d’envisager que la bascule de ce module soit en « big bang ».
Pour identifier la démarche adéquate pour chaque module, l’expert comptable doit procéder comme suit :

analyser les processus et les flux pour chaque module ;

identifier les processus pouvant être impactés par le régime transitoire ;

réfléchir à des solutions pour la gestion de la phase transitoire ;

présenter aux équipes informatiques notamment « le chantier interfaces » les solutions proposées afin
d’apprécier la faisabilité et la complexité des développements ;

ajuster les solutions en fonction de l’analyse et du feedback des équipes informatiques.

valider les grandes lignes des solutions obtenues pour la gestion de la phase transitoire et la démarche de
bascule de chaque module par le mangement de projet ;

préparer les spécifications détaillées des solutions validées.
Pour une banque de détail adoptant une stratégie de bascule progressive par lot d’agence, une bascule « big
bang » est la plus appropriée pour les modules suivants :
 Le système central et les autres fonctionnalités comptables :
Le système central est le système qui centralise les mouvements comptables issus des autres modules. Il assure
principalement les fonctionnalités suivantes : le calcul et la comptabilisation des agios sur les comptes de la
clientèle (les échelles d’intérêt) ; les éditions comptables : balances, grand livre, journal,… ; le lettrage des
comptes de liaison ; le rapprochement bancaire ; la saisie des opérations diverses ; la réévaluation ;…
Le système central est le noyau dur de tout système d’information. Ce système, qui est alimenté à partir des
autres applications, est lui aussi une source d’information pour le reste des applications : soldes comptables,
mouvements comptables, situation des comptes,… Il est difficile de concevoir une architecture avec deux noyaux
durs à la fois notamment pour les raisons suivantes :

Nécessité de développement d’un système centralisateur qui consolide entre les deux noyaux en utilisant
une seule nomenclature comptable : charges de développement importantes pour une solution jetable.

Développements importants et non durables au niveau des autres applications alimentées à partir d’un
système centralisateur qui sera valable uniquement pendant la phase transitoire.
Page 140
Deuxième Partie

Les développements d’interfaces avec le système central offert par le progiciel seront toujours utiles pour
les applications non couvertes par le périmètre fonctionnel du progiciel et qui seront maintenues dans le
système d’information cible.
En conclusion, il est plus opportun que la bascule du système central comptable soit effectuée en « big bang ».
Cette bascule doit avoir lieu avant le démarrage de la bascule des agences. Ainsi, la migration au nouveau
système d’information sera scindée en deux étapes :

Une bascule du référentiel comptable de toute la banque pour toutes les agences : le nouveau global
bancaire constituera désormais le système de référence en matière d’informations comptables.

Une bascule progressive des agences : la bascule sera limitée aux dossiers de gestion (encours crédits,
impayés, caisses,…), il n’y a plus besoin de migrer les soldes et mouvements comptables.
La bascule du référentiel comptable suppose :

bascule des soldes comptables à une date bien déterminée (à la fin d’un mois au cours de l’exercice) ;

bascule d’un historique de mouvements comptables raisonnable (généralement un historique d’une année) ;

bascule des suspens des comptes de liaison et des suspens des rapprochements bancaires ;

bascule des conditions spéciales d’arrêtés : taux débiteurs, taux créditeurs, frais de tenue de comptes,…

développements d’interfaces permettant l’alimentation quotidienne du système central du nouveau progiciel
à partir des applications existantes ;

changement des interfaces d’alimentation des applications existantes à partir du système central, ces
applications seront désormais alimentées à partir du nouveau système central.
 Le référentiel client :
Le référentiel client est la base d’informations sur les clients de la banque. Cette base de données client est
utile pour les analyses d’activités et la budgétisation, les déclarations règlementaires et le développement des
actions commerciales. Cette base est constituée à partir de l’application front office au niveau des agences et ce
lors de l’entrée en relation avec de nouveaux clients (fiche client). De sa part, cette base alimente l’ensemble des
applications du système d’information de la banque.
Le référentiel client nécessite qu’il soit centralisé au niveau d’un point d’accès unique pour les mêmes raisons
indiquées pour le référentiel comptable. La bascule « big bang » du référentiel client suppose :

la bascule de toute la base clientèle en une seule fois à une date déterminée dans le nouveau système ;

l’alimentation quotidienne du nouveau système par les fiches client créées dans l’ancien système ;

la modification des interfaces existantes : toutes les applications seront désormais alimentées à partir du
référentiel client du nouveau système d’information.
Page 141
Deuxième Partie
 Le module compensation de valeurs:
Le module compensation présente les difficultés du volume important des transactions ainsi que du nombre
important des processus : compensation émise et compensation reçue /compensation même agence, interagence ou inter-bancaire / compensation électronique ou manuelle / sort positif ou négatif.
Une analyse approfondie doit être effectuée pour chaque processus pour déterminer les possibilités d’une
bascule progressive. On présente au niveau du tableau suivant les circuits de la compensation des chèques et
les difficultés que peut présenter une bascule progressive :
interbancaire
Même
agence
Circuit
sens
Difficultés
Emise /
Pas de problème particulier
Reçue
Impact développement
RAS
Emise
- Préparation du fichier de compensation consolidé à
Développement d’une solution permettant la
destination de la SIBTEL.
consolidation des fichiers de compensation des
- Gestion de deux compensations au même temps avec
deux systèmes à destination de la SIBTEL.
les risques et les contrôles qui en découlent.
Reçue
- Obligation de traitement du fichier de compensation
reçue et dispatching en fonction qu’il s’agit d’une
agence basculée ou une agence non basculée.
- Gestion de deux compensations au même temps avec
les risques et les contrôles qui en découlent.
Développement d’une solution permettant le
traitement du fichier reçu de la SIBTEL. Cette
solution permet de découper le fichier consolidé
en deux fichiers, l’un est à destination des
agences basculées et l’autre à destination des
agences non basculées.
 Agence basculée vers agence basculée
Traitement total au niveau du nouveau système du coté
RAS
des deux agences et application des nouveaux schémas
comptables.
inter-agence
 Agence non basculée vers agence non basculée
Traitement total au niveau de l’ancien système du coté
RAS
des deux agences et application des anciens schémas
comptables.
 Agence basculée vers agence non basculée
Le processus sera comme suit :
Un développement s’impose pour la gestion ce type de - la remise sera traitée comme une opération
interbancaire vers une banque fictive
Emise / flux.
- Traitement informatique permettant de
Reçue
supprimer ces remises du fichier à destination
du SIBTEL et les intégrer parmi le fichier de
compensation reçue de la SIBTEL en fonction
 Agence non basculée vers agence basculée
de la destination : agence basculée ou agence
Un développement s’impose pour la gestion ce type de non basculée : ainsi l’agence réceptrice va
flux.
traiter les remises comme des valeurs reçues
de la compensation.
- Le sort des valeurs sera traité comme un sort
interbancaire, la solution informatique doit
supprimer ces informations sur le sort du fichier
à destination de la SIBTEL et les inclure dans le
fichier reçu de la SIBTEL.
Page 142
Deuxième Partie
Le choix de la méthode de bascule du module de compensation reste tributaire du contexte et des systèmes
utilisés par la banque. Une bascule « big bang » est plus sécurisée pour ce module en raison du coût des
développements et des risques que comporte la bascule progressive. En cas d’option pour une bascule totale du
module compensation, cette bascule intervient après le déploiement du reste des modules de la nouvelle
solution sur toutes les agences.
2. Définition du plan de comptes et de la matrice de correspondance
Le changement de système d’information nécessite la mise en place d’un nouveau référentiel comptable (2.1)
ainsi que l’établissement de matrices de passage entre l’ancien et le nouveau référentiel (2.2).
2.1.
Elaboration du nouveau plan comptable
2.1.1. Nécessité du changement
Ce changement est motivé par les éléments suivants :

la structure des comptes dans le système cible est différente de la structure du système en place ;

l’ancien plan de comptes n’est pas structuré conformément aux bonnes pratiques bancaires notamment la
norme comptable 22 relative au contrôle interne et l’organisation comptable dans les établissements
bancaires ;

la saturation de l’ancien plan de comptes ;

nécessité de gestion de certains attributs d’informations par le plan comptable lorsque les autres référentiels
ne permettent pas cette gestion (référentiel client ou produits).
2.1.2. Préalable et éléments à prendre en considération
Pour établir le nouveau plan de comptes, l’expert comptable doit tenir compte des éléments suivants :

La norme comptable 22 relative au contrôle interne et l’organisation comptable dans les établissements
bancaires. Cette norme a proposé un plan de comptes pour les établissements bancaires. La nomenclature
proposée est basée sur la logique suivante :
- La classification des comptes de bilan et de hors bilan est définie selon trois critères essentiels :
 la création de la monnaie en tant que critère essentiel de l’activité bancaire,
 l’origine de cette monnaie ou la nature de la contrepartie,
 la liquidité des fonds concernés.
- La classification des comptes de résultat est définie selon trois critères essentiels :
 la correspondance avec le découpage des comptes du bilan et du hors bilan.
Page 143
Deuxième Partie
 Les agents économiques,
 La nature de la charge ou du produit.
Le plan de compte proposé par la norme 22 est structuré sur 8 classes.

La gestion du référentiel comptable dans le système cible : les nouvelles solutions distinguent entre les
comptes élémentaires et les comptes ou chapitres de regroupement. Le chapitre de regroupement constitue
un attribut du compte élémentaire.
- Les comptes élémentaires sont les comptes à mouvementer par les opérations bancaires. On distingue
entre trois types de comptes élémentaires :
 Les comptes de la clientèle : il s’agit des comptes communiqués aux clients. A chaque
compte client correspond un identifiant bancaire défini par l’annexe 1 de la note aux banques
N°94-21 du 23 juin 1994.
 Les comptes clientélisés de dossiers : il s’agit des comptes techniques appartenant à des
clients et enregistrant les soldes et les mouvements sur les dossiers : crédits, bons de caisse,
impayés, blocages comptables, chèques à l’encaissement,… Ces comptes techniques ne
sont pas communiqués aux clients.
 Les comptes généraux : il s’agit du reste des comptes de la comptabilité : comptes charges
et produits, comptes de régularisation, comptes titres, comptes d’immobilisations,…
- Les comptes ou chapitres de regroupement : tout compte élémentaire doit être rattaché à un chapitre
de regroupement. L’ensemble de ces chapitres de regroupement constitue le plan comptable de la
banque. Le chapitre comptable n’enregistre pas des mouvements comptables et sert essentiellement à
définir les attributs des comptes élémentaires (sens standard, compte clientèle, compte soumis au
lettrage,…) ainsi qu’à la préparation des déclarations règlementaires et autres reportings.

La gestion cible des attributs d’information : un attribut est un critère d’information rattaché à une opération
ou à un ensemble d’opérations, ou encore à un tiers, qui permet soit de ventiler le solde d’une rubrique
comptable, soit de compléter cette rubrique d’une caractéristique supplémentaire (nombre, volume, ...).
L’expert comptable doit établir une matrice des attributs nécessaires pour la préparation des déclarations et
des reportings par rapport aux systèmes ou référentiels qui gèrent ses attributs. Les attributs d’informations
sont gérés sur trois niveaux :
- Le référentiel client : résidence, secteur d’activité, agent économique, groupe d’affaire, classe,…
- Les informations sur les dossiers : durée initiale, durée résiduelle, nature de taux, durée impayés,
durée de gel de compte,…
- Le référentiel comptable : devise, agence, existence d’une fusion de compte, rubrique d’imputation,…
Page 144
Deuxième Partie
L’expert comptable peut, suite à ces travaux, identifier des attributs qui ne sont pas gérés par aucun système ou
qui sont gérés par des applications interfacées avec la nouvelle solution. Dans ces cas, il sera envisageable de
gérer ces attributs au niveau du plan de comptes. On cite à titre d’exemples les cas suivants :
- Pour la distinction entre produits taxables et produits non taxables nécessaires pour le calcul du prorata de
déduction de TVA, il sera opportun de distinguer au niveau des comptes de commissions entre les
commissions sur des clients taxables et celles sur des clients non taxables.
- Si l’activité de trésorerie ne sera pas migrée au nouveau système et pour éviter les retraitements manuels
pour la préparation des reporting, il sera possible de distinguer au niveau des comptes entre les opérations
réalisées avec des banques résidentes, banques non résidentes installées en Tunisie et banques installées
à l’étranger.
2.1.3. Livrables de l’expert comptable
On distingue entre trois livrables à produire par l’expert comptable :

Le plan des chapitres comptables ou comptes de regroupement : il s’agit ici de définir la nomenclature
comptable de la banque. Cette nomenclature doit être structurée comme suit :
- Le premier chiffre constitue la classe (8 classes) ;
- Les deux chiffres suivants désignent la nomenclature commune à toutes les banques et permettant
d'identifier une grandeur économique ou monétaire homogène, d'arrêter les comptes et d'établir les
états financiers réglementaires ;
- Les autres chiffres caractérisent, de gauche à droite, des niveaux de généralité décroissante,
représentant des opérations de plus en plus détaillées. Ils permettent d’établir une homogénéité entre
les comptes de bilan, les comptes de hors bilan et les comptes de charges ou produits correspondants
à un même produit.

Attributs de chaque chapitre ou compte de regroupement : les principaux attributs à fournir : rubrique
d’affectation du chapitre au niveau des états financiers ainsi qu’au niveau des déclarations mensuelles à la
BCT ; sens standard du chapitre : débiteur, créditeur ou indifférent ; nature de chapitre : comptes clients,
compte techniques, ou compte général ; chapitre soumis au calcul d’arrêté ; chapitre soumis à un lettrage ;
chapitre soumis au report à nouveau,…

Définition des comptes élémentaires généraux : une distinction doit être faite entre les comptes de clientèle
et les comptes techniques de dossier dont la création et l’attribution d’un numéro est automatique par le
système et les autres comptes généraux dont la création est manuelle. L’expert comptable doit établir la
nomenclature de ces comptes généraux et les attributs de ces comptes :
Page 145
Deuxième Partie
- chapitre de regroupement : le compte hérite systématique les attributs du chapitre indiqué ;
- devise de fonctionnement : dinar, devise ou indifférent ;
- unités de gestion : comptes à créer au niveau des agences ou dans un département déterminé.
2.2.
Elaboration de la matrice de correspondance
La matrice de correspondance est l’outil permettant de faire le lien entre l’ancien plan de comptes et la nouvelle
nomenclature. En fonction des exigences de la solution à mettre en place, les matrices de correspondance
peuvent se faire aussi bien pour les comptes de la comptabilité générale que pour les comptes de la comptabilité
auxiliaire. Généralement, les comptes de la clientèle ne subissent aucun changement.
Chaque ancien compte de la comptabilité générale doit lui correspondre un ou plusieurs nouveaux comptes dans
le système cible. Il existe trois types de relations :

Relation un à un : à chaque ancien compte correspond un seul nouveau compte.

Relation plusieurs à un : plusieurs anciens comptes seront regroupés dans un seul compte dans le système
cible. Par exemple, les comptes de position de change : il est possible que dans l’ancien système un
compte de position de change est créé dans chaque devise, il sera donc plus judicieux d’utiliser le même
compte pour toutes les devises.

Relation un à plusieurs : un ancien compte peut lui correspondre plusieurs comptes dans le système cible
en fonction d’une règle de défalcation à définir. Il s’agit par exemple des comptes qui jouent à la fois le rôle
d’encours et d’impayés, la distinction se fait selon l’unité de gestion. Si l’unité de gestion est une agence, il
s’agit donc d’impayés ; si l’unité de gestion est le « département portefeuille », il s’agit d’encours de crédit.
L’élaboration de la matrice de correspondance nécessite au préalable la compréhension des anciens comptes et
des schémas comptables de leur utilisation. Le libellé des anciens comptes peut, dans certains cas, s’avérer
insuffisant pour identifier leur correspondance. Il faut donc comprendre l’utilisation exacte du compte pour
déterminer la correspondance. Les difficultés se présentent particulièrement pour les comptes d’attente.
La matrice de correspondance sera utilisée pour :

la réalisation de la bascule du système comptable ;

l’alimentation quotidienne du nouveau noyau comptable à partir des applications de l’ancien système avant
le démarrage des migrations des agences ;

l’alimentation quotidienne du nouveau noyau comptable par les mouvements des applications qui restent
interfacées avec le nouveau système même après la bascule de toutes les agences. La migration de ces
applications vers le nouveau plan de comptes doit être entreprise une fois le nouveau système est mis en
place. Ceci permettra d’éviter la gestion parallèle de deux plans de comptes et les travaux de maintenance
et de mise à jour de la matrice de correspondance.
Page 146
Deuxième Partie
L’expert comptable peut assister la banque dans l’élaboration d’autres matrices de correspondance :

Matrice des produits comptes.

Matrice des autres produits et service : crédits, placements, engagements par signature,…

Matrice des unités de gestion : il est possible de fusionner des unités de gestion dans le système cible
notamment pour les unités comptables de départements centraux.

Matrice des codes opérations.
3. Définition des informations à migrer et des règles de migration
L’opération de migration consiste à alimenter les tables du nouveau système d’information de la même manière
que si les opérations ou les dossiers ont été réalisés ou crées directement sur la nouvelle solution. L’expert
comptable peut assister la banque dans les domaines suivants :

détermination des informations à migrer pour chaque module (3.1) ;

détermination des règles de migration pour chaque type d’information (3.2) ;

pilotage des travaux de « mapping » entre les applications source et le système cible (3.3).
3.1.
Détermination des informations à migrer pour chaque module
On distingue entre trois grandes familles d’informations à reprendre :

les informations comptables : les soldes des comptes, les mouvements comptables,…

les informations extra-comptables ayant une représentation comptable : les encours de crédits, les impayés,
les encours de cautions et avals,…

les informations qualitatives n’ayant pas une représentation comptable : le référentiel client, les conditions
spéciales,…
On présente au niveau du tableau suivant les principales informations à reprendre par module fonctionnel :
Module
Module comptabilité
Référentiel client
Matière ou information à migrer
Comptabilité générale
Comptabilité auxiliaire
Historique de mouvements comptables
Suspens comptes de liaison
Suspens rapprochement bancaire
Conditions spéciales des échelles d'intérêts
Comptes fusionnés
Historique des taux de réévaluation
Toutes les informations sur les clients en distinguant entre les personnes physiques et les
personnes morales : type de document d'identification, numéro de document d'identification,
adresse, nationalité, résidence, secteur d'activité, …
Page 147
Deuxième Partie
Module
Matière ou information à migrer
Caisse dinars et caisse devise, caisse chèques de voyage
Stock de timbre et lettre de change
Bon de caisse et compte à terme
Avances sur bons de caisse et compte à terme
Module Agence
Chèque certifié et chèques de banque non apurés
Blocage extra comptable
Blocage comptable
Mise à disposition non apurés
Echéanciers de crédits
Conditions de crédit : type de crédit, nature taux (fixe ou variable) ; taux d'intérêt, marge,…
Impayés sur crédit
Autorisation de découvert
Module Engagement
Autorisation de crédits de gestion
Conventions
Assurances liés aux crédits
Encours des cautions et avals
Module Engagements par signature Conditions des dossiers : type d'engagement, taux de commission, date de délivrance,…
Conditions spéciales
Encours escompte et encaissement effet
Impayés escompte effet
Effets reçus pour paiement
Encours des chèques : chèques en recouvrement
Stock des chéquiers
Interdits de chéquier
Incidents de paiement chèque : préavis, papillon, certificats de non paiement,…
Blocages sur chèque impayés
Module compensation et Moyens de
Demandes de chéquiers
Paiement
Frais d’huissier sur chèques impayés non régularisés
Chèques reçus pour paiement
Virements permanents
Virements Emis en instance
Virements reçus et non exécutés
Prélèvements émis non exécutés
Prélèvement reçus en instance
Condition spéciales : commissions sur chèques, effets, virements, prélèvement
Crédit documentaire import/ export
Remise documentaire import/export
Valeurs en recouvrement sur l'étranger : chèques, effets, chèques de voyage
Les domiciliations de titre de commerce extérieur
Module Etranger
Les transferts émis et non exécutés
Les transferts reçus en instance
Les contre-garanties reçues des banques étrangères
Garanties réelle : hypothèque, nantissement de matériel,…
Garantie financière : nantissement bons de caisse, compte à terme,…
Classe de risque et le rating du client
Module risque
Stock agios réservés par client et par nature de produit
Stock provisions par client
Liste des clients contentieux
Les saisies arrêts
Page 148
Deuxième Partie
3.2.
Détermination des règles de migration pour chaque type d’information
Après la détermination des informations à migrer au nouveau système, l’expert comptable doit assister la banque
dans la définition des règles de bascule. Il s’agit essentiellement de définir :
 L’approche de reprise: manuelle ou automatique
Le choix de l’approche de reprise dépend essentiellement de la volumétrie des informations. En effet, pour une
volumétrie faible, une approche de reprise manuelle est plus appropriée et permet d’éviter des charges de
développements importantes. Une reprise manuelle implique la saisie du dossier directement sur le nouveau
système. En cas d’options pour cette approche, il faut analyser les différents impacts et agir en
conséquence notamment par l’annulation des écritures comptables qui peuvent être générées. L’approche
manuelle est principalement utilisée pour la reprise des caisses dinar et devise, du stock de chèques de voyage,
des dossiers de mise à disposition non apurés, de certaines conditions spéciales,…
L’approche automatique implique le développement d’outils d’extraction des applications source et d’outils
d’intégration dans le système cible. L’intégration dans le système cible peut générer des écritures comptables qui
doivent être spécifiées pour chaque type de dossier.
 Les schémas comptables de migration :
Les schémas comptables de migration permettent de matérialiser et pister l’opération de bascule ainsi que de
constater tout écart éventuel que les actions de fiabilisation n’ont pas réussi à les éliminer. L’opération de
bascule des informations comptables ou ayant une représentation comptable peut dégager deux types d’écarts :
les écarts entre les soldes de la comptabilité générale et ceux de la comptabilité auxiliaire et les écarts entre les
soldes comptables et les soldes de gestion ou extra-comptables.
Dans une démarche de bascule « big bang » du référentiel comptable et une bascule progressive des modules
métiers ; l’approche et les schémas de migration peuvent être présentés comme suit :
(1) Reprise de la comptabilité générale :
Il s’agit ici d’appliquer la matrice de correspondance à la situation des comptes généraux arrêtée à la date de
bascule convenue. Pour réaliser cette bascule, il n’y aura pas besoin de constater des écritures comptables, il
s’agit d’une reprise de solde uniquement sans mouvements comptables. L’équilibre par agence et par devise
existant dans la balance de l’ancien système sera transféré à la balance éditée par le nouveau système.
(2) Reprise de la comptabilité auxiliaire :
Certains comptes de la comptabilité générale sont gérés en comptes auxiliaires. Il s’agit principalement des
comptes de la clientèle et certains comptes de dossiers : bons de caisse, compte à terme, impayés,…
Page 149
Deuxième Partie
Chaque mouvement comptable sur les comptes gérés en comptes auxiliaires sera constaté aussi bien sur la
comptabilité auxiliaire que sur la comptabilité générale. La comptabilité auxiliaire n’est pas une comptabilité
équilibrée, elle renseigne uniquement les soldes et les mouvements sur les comptes auxiliaires.
La reprise des comptes de la comptabilité auxiliaire dans le nouveau système nécessite une écriture comptable.
Il s’agit de débiter ou créditer le compte auxiliaire (maintenir le même numéro que l’ancien système ou appliquer
une matrice de correspondance) en contre partie du compte général auquel appartient le compte auxiliaire en
question. Si les comptes généraux accusent un solde après les écritures de bascule de la comptabilité auxiliaire,
ce solde correspond à l’écart entre la comptabilité générale et la comptabilité auxiliaire.
(3) Reprise des dossiers des agences ayant une image comptable :
La reprise des dossiers ayant une image comptable nécessite des écritures comptables. Il sera opportun de
créer des comptes d’attente appelés « compte de bascule » pour chaque type de dossier à reprendre. Ces
comptes serviront à constater l’opération de bascule et les écarts qui en découlent pour chaque type de dossier.
Pour chaque opération de bascule d’un dossier, deux écritures sont nécessaires :
 Ecriture de reprise de l’information extra comptable : il s’agit de débiter ou créditer le compte cible en
contre partie du compte de bascule de la matière en question pour le montant extra-comptable.
 Ecriture de vidage du solde comptable concerné : il s’agit de vider le compte comptable logeant la
matière concernée en contre partie du compte de bascule pour le solde comptable du compte.
Le solde du compte de bascule correspond donc à l’écart entre le solde de gestion et le solde comptable.
Exemples : Ecritures comptables de reprise d’un dossier de bon de caisse :
 Reprise extra-comptable :
Sens
Compte
Montant
Débit
Cpte de bascule des bons de caisse
Montant extra du bon de caisse
Crédit
Cpte cible (généralement un compte clientélisé crée
automatiquement par le programme de reprise)
Montant extra du bon de caisse
 Vidage du solde comptable :
Sens
Compte
Montant
Débit
Cpte comptable logeant le solde des bons de caisse en
question (compte général ou compte clientélisé)
Solde comptable
Crédit
Cpte de bascule des bons de caisse
Solde comptable
Page 150
Deuxième Partie
En plus des écritures de reprise des dossiers extra-comptables et de vidage des soldes comptables, l’opération
de bascule peut nécessiter d’autres écritures notamment pour se conformer aux nouveaux schémas comptables.
On cite les deux exemples suivants à titre indicatif :
Reprise des charges comptabilisées d’avance sur les bons de caisse précomptés : cette reprise est

obligatoire dans le cas où le paiement de ces intérêts est constaté directement dans les comptes de charge,
alors que dans le nouveau schéma comptable, ces intérêts sont comptabilisés dans un compte de charges
payées d’avance à la date de mise en place. Pour régulariser cette situation, le programme de reprise doit
prévoir une régularisation comptable :
Sens
Compte
Montant
Débit
Compte de charges payées d’avance
Montant total des intérêts du placement
Crédit
Compte de charges d’intérêts (compte résultat)
Montant total des intérêts du placement

Certaines banques procèdent à la comptabilisation des intérêts non courus matérialisés par des effets dans
la comptabilité générale. Cette comptabilité matière n’est pas applicable dans le nouveau schéma, il
convient donc à l’occasion de la bascule des dossiers de crédits d’annuler ces écritures.
3.3.
Pilotage des travaux de « mapping » entre les applications source et le système cible
L’opération de bascule est une opération d’alimentation des tables du système cible à partir des tables d’un
système source. En effet, une fois que le périmètre des modules et des informations à basculer est défini,
l’éditeur de la solution fournit aux informaticiens de la banque les tables et les champs qui doivent être alimentés.
Des travaux de « mapping » avec les applications source seront réalisés pour toute information demandée. Ce
travail fait intervenir les équipes informatiques du « chantier reprise des données » ainsi que les informaticiens
responsables sur les applications sources : personnes ayant participé dans leur développement ou les
responsables de leur maintenance.
Il est possible que les informations demandées ne soient pas toutes disponibles dans le système source soit
parce qu’elles ne sont pas gérées, soit suite à un problème de fiabilité des données. Dans ces situations, il
convient de fiabiliser les données du système source (Cf. paragraphe suivant) ou appliquer des règles de gestion
pour déterminer les informations à renseigner.
Pour bien mener ces travaux, l’expert comptable peut intervenir et piloter ces différentes actions. L’intervention
de l’expert comptable consiste essentiellement à :

s’assurer que tous les domaines sont couverts et que des vis-à-vis sont désignés pour chaque domaine du
coté de la banque et du coté de l’éditeur-intégrateur ;

vérifier que l’avancement des travaux est conforme au planning du projet ;
Page 151
Deuxième Partie

proposer des solutions pour les problèmes rencontrés ou s’assurer de la validité des solutions retenues ;

rédiger et diffuser les comptes rendus de réunion et s’assurer que les actions convenues sont réalisées
dans les délais définis ;

remonter des alertes au management de projet
4. Fiabilisation des données du système source
La bascule des données vers un nouveau système nécessite toujours des actions de fiabilisation des données
du système source. L’intervention de l’expert comptable à ce niveau peut concerner les aspects suivants :
détermination du périmètre des informations à fiabiliser (4.1), pilotage des travaux de fiabilisation (4.2) et
assistance dans la fiabilisation des données (4.3).
4.1.
Détermination du périmètre des informations à fiabiliser
Pour identifier le périmètre des travaux de fiabilisation à mener, l’expert comptable doit réaliser des missions de
diagnostic et d’analyse de la qualité des données de chaque famille d’informations à migrer (informations
comptables, informations extra-comptables ayant une représentation comptable et les autres informations
qualitatives n’ayant pas une représentation comptable). Il peut utiliser pour la réalisation de ces missions : les
résultats de travaux de contrôles comptables réalisés par les entités de la banque, les recommandations et les
réserves des commissaires aux comptes, les rapports des missions d’audit interne, les résultats des missions
d’inventaires physiques, les résultats des simulations de bascule, des requêtes sur demande,…
Un rapport de synthèse doit être établi par l’expert comptable selon les axes suivants :

Rapprochement comptabilité générale et comptabilité auxiliaire : il s’agit de présenter les écarts
constatés entre les comptes généraux et les comptes auxiliaires. Il est important de déterminer si ces
écarts sont en train d’évoluer d’une période à une autre.

Rapprochement entre les différentes sources de la comptabilité auxiliaire : les comptes auxiliaires sont
gérés aussi bien dans les applications de front office que dans le système central. Il y a lieu donc de
présenter l’état différentiel entre ces situations pour des périodes différentes.

Rapprochement des dossiers physiques et des soldes de gestion : conformément à la norme comptable
22, les opérations d'inventaire physique dans les banques couvrent :
- les disponibilités: caisse dinar, caisse devise, caisse DAB, les chèques de voyages, les timbres;
- les créances détenues et matérialisées par des titres (effets à l’escompte et titres de crédit) ;
- le portefeuille effets commerciaux ;
Page 152
Deuxième Partie
- les cautions et avals et autres engagements par signature ;
- les garanties reçues de la clientèle : nantissement dépôts, garantie reçue des banques,…

Rapprochement des soldes de gestion et des soldes comptables : il s’agit de présenter les écarts
constatés et leurs évolutions pour toutes les informations extra-comptables ayant une représentation
comptable : caisses, encours crédit, impayés, blocages comptables, bons de caisse, dépôts à terme,
chèques à l’encaissement, effets à l’escompte, chèques de banque, chèques certifiés, effets en
recouvrement, crédit documentaire import, garanties financières,…

Qualité des informations du référentiel client : les informations du référentiel client sont multiples. Il s’agit
à ce stade d’indiquer pour chaque information du référentiel client, le nombre de clients pour lesquels
ces informations n’existent pas (type d’identification, numéro d’indentification, personne physique ou
personne morale, adresse, résidence, nationalité, spécimen de signature…)
Les différentes anomalies présentées dans le rapport de synthèse constituent une matière pour les chantiers de
fiabilisations à mener.
4.2.
Pilotage des travaux de fiabilisation
L’expert comptable peut assister la banque dans le pilotage des opérations de fiabilisation. Le pilotage consiste
essentiellement à :

mettre en place une procédure claire de fiabilisation décrivant la démarche, les actions, les intervenants, les
responsabilités, les instances de décision,…Le processus de fiabilisation comprend les étapes d’instruction
de l’écart ; identification de l’origine de l’écart ; détermination de l’action de régularisation ; validation de
l’action de régularisation ; réalisation de l’action de régularisation ;

suivre l’avancement des travaux de fiabilisation et mettre à jour périodiquement le rapport de synthèse des
écarts et anomalies ;

rédiger et diffuser les comptes rendus de réunion ;

s’assurer de la bonne documentation des travaux de fiabilisation et de l’existence de la piste d’audit ;

remonter des alertes au management de projet et proposer des solutions de régularisation.
4.3.
Assistance dans la fiabilisation des données
Les travaux de fiabilisation font intervenir les différentes structures de la banque : les agences, la comptabilité,
l’audit et le contrôle interne, l’informatique,… L’expert comptable en tant que consultant externe peut s’associer à
ces structures internes et participer dans la réalisation des actions de fiabilisation. Multiples actions peuvent être
Page 153
Deuxième Partie
entreprises dans le cadre des travaux de fiabilisation. On cite les actions suivantes pour chaque axe de
fiabilisation :

Ecarts entre la comptabilité générale et la comptabilité auxiliaire
- Déterminer l’origine des écarts : il s’agit d’identifier la période où l’écart a été créé. L’écart est dû soit à
des mouvements comptables sur les comptes généraux qui n’ont pas impacté les comptes auxiliaires ou
inversement.
- Identifier les écritures manquantes ou passées en plus au niveau de la comptabilité générale ou dans la
comptabilité auxiliaire.

Ecarts entre les différentes sources de la comptabilité auxiliaire
- Identifier l’origine des écarts : l’écart peut être expliqué soit par des injections comptables qui ont été
réalisées dans un système et non pas dans l’autre système, soit suite à un problème d’interface qui a
empêché la remontée des informations sur la création de comptes réalisée au niveau de système
agence vers le système central.
- Identifier et veiller à intégrer les journées comptables manquantes.
- Réaliser la remontée des informations de création de comptes vers le système central.

Ecarts entre dossiers physiques et soldes de gestion :
- Réaliser d’autres opérations d’inventaires physiques et confirmer les écarts définitifs entre dossiers
physiques et soldes de gestion.
- Ajuster les soldes de gestion aux soldes physiques :
 Si les dossiers de gestion sont supérieurs aux dossiers physiques : apurer les dossiers de gestion.
(Exemples : annuler des cautions ou des garanties financières qui n’ont pas de supports
physiques, apurer des effets à l’encaissement qui n’ont pas d’existence physique,…).
 Si les dossiers physiques sont supérieurs aux soldes de gestion : créer dans le système le dossier
physique. (Exemples : création d’un dossier de crédit, création d’un dossier de caution,…).

Ecarts entre soldes de gestion et soldes comptables :
- Identifier l’origine des écarts : l’écart est dû dans la plupart des cas aux opérations diverses (OD) qui
impactent les soldes comptables et n’impactent pas les soldes de gestion.
- Supprimer les dossiers extra-comptables de l’ancien système : cette suppression doit être validée par
des responsables habilités. Les informations à supprimer doivent être conservées dans d’autres tables
de stockage. (exemple : suppression d’un impayé expliqué par la constatation du règlement de l’impayé
par OD comptable au lieu du module approprié).
Page 154
Deuxième Partie
- Créer des dossiers extra-comptables : il s’agit du cas où un dossier a été créé par OD comptable et non
pas par le module approprié (exemple : blocage comptable sur un compte client).

Qualité des informations du référentiel client : la fiabilisation du référentiel client constitue un chantier
lourd qui nécessite des ressources importantes. Il y a lieu donc de prioriser les actions de fiabilisation :
- Fiabiliser les comptes clients qui ne sont pas rattachés à des clients ou qui sont rattachés à des clients
fictifs. Un client est identifié par un document d’identification et un numéro de document d’identification.
- Fiabiliser les adresses clients : il s’agit ici de fiabiliser les adresses des comptes client ayant fait l’objet
de rejet d’envoi de relevés bancaires.
- Fiabiliser les autres informations qui sont obligatoires dans le système cible et qui sont manquantes dans
le système source.
La fiabilisation de ces données est réalisée soit en consultant directement les dossiers physiques des fiches
clients, soit en invitant le client à fournir des informations actualisées pour renseigner de nouvelles fiches.
Il est possible que les actions de fiabilisation n’arrivent pas à apurer toutes les anomalies dans les délais
convenus. Dans ce cas, la banque est contrainte d’appliquer des règles par défaut pour renseigner les
informations manquantes :
- Un compte où l’identification n’a pas été réalisée : création d’une nouvelle nature de document
d’identification « compte » et renseigner le numéro du compte client comme numéro d’indentification.
- La notion de résidence peut être renseignée à partir de la nature des produits comptes dont le client
dispose. Il en est de même pour la personnalité juridique : personne physique ou personne morale.
5. Définition des contrôles pour la validation de la bascule
L’expert comptable peut assister la banque dans la définition des contrôles, des outils et de la démarche pour la
validation de l’opération de bascule. On s’intéresse ici aux contrôles pour la validation de la reprise des données
et non pas aux contrôles de vieillissement des données reprises dans le système cible. Ces contrôles permettent
de s’assurer que :

les informations reprises dans le système cible reflètent fidèlement et exhaustivement la situation existante
dans le système source ;

les règles de gestion qui ont été définies pour la réalisation de la reprise ont été correctement appliquées ;

les informations reprises sont cohérentes entre elles et avec les paramétrages réalisés.
Les contrôles à définir sont soient des contrôles manuels soient des contrôles informatiques. Ils peuvent être
exécutés par échantillonnage ou de manière exhaustive. Ils peuvent être exécutés avant le chargement des
données dans le système cible, ou au moment du chargement ou après le chargement.
Page 155
Deuxième Partie
On présente des exemples de contrôles selon le type d’informations à reprendre :
 Contrôles de la reprise des soldes comptables :
En considération de la volumétrie importante des comptes, il est plus approprié de développer un outil de
contrôle permettant de s’assurer que l’ensemble des comptes de la comptabilité générale et auxiliaire ont été
repris dans le système cible et que la matrice de correspondance et les schémas comptables de reprise ont été
correctement appliqués. Le principe de l’outil est de calculer une balance des comptes à partir des mêmes
sources de données et en appliquant les mêmes règles, puis l’outil doit permettre de rapprocher entre la balance
calculée et la balance générée par le système cible et de dégager les écarts éventuels. Trois types d’écarts sont
possibles : Comptes repris en plus, comptes non repris et comptes repris avec solde différent. L’outil peut être
interactif de manière à tracer une piste croisée allant du nouveau compte vers l’ancien compte ou inversement.
D’autres contrôles de cohérence peuvent être prévus et intégrés dans le programme de reprise :

code devise, code unité de gestion, code produit inexistants dans les tables de paramétrage ;

compte client affecté à un chapitre de regroupement paramétré comme chapitre général et inversement ;

rattachement compte à un client inexistant ;

identifiant compte client (RIB) inexistant.
 Contrôles de la reprise de l’historique des mouvements comptables :
Une reprise d’un minimum d’historique de mouvements doit être réalisée dans le système cible. Ces données sur
les mouvements sont très volumineuses (des millions d’enregistrements), un contrôle automatique de type
vérifier l’égalité pour chaque compte entre la somme du solde historique et les mouvements avec le solde repris
permet de s’assurer de la validité des mouvements repris.
Les contrôles de cohérence permettent de s’assurer de :

l’existence du compte dans la table des comptes ;

l’existence de l’unité de gestion ou la devise dans les tables de paramétrage,

l’indication de la date valeur pour les mouvements sur des comptes clients,…
 Contrôles de la reprise des dossiers extra-comptables ayant une représentation comptable :
Ces contrôles permettent de s’assurer que la même image existante dans le système source après les actions
de fiabilisation a été reprise dans le système cible ainsi que de s’assurer que les règles et les schémas de
bascule ont été correctement appliqués. Pour atteindre ces objectifs, des outils de contrôle automatique peuvent
être développés et mis en place. Ces outils reposent sur les principes suivants :

Faire des rapprochements automatiques entre les soldes de gestion des applications sources et les soldes
comptables pour les différents dossiers des agences à migrer.
Page 156
Deuxième Partie

Faire des rapprochements automatiques entre les données chargées dans le système cible et les données
issus du système source.

S’assurer que les écarts identifiés avant le chargement dans le système cible sont logés dans les comptes
de bascule décrit dans le point 3.2.
Des tests de cohérence pour chaque type de dossier peuvent être intégrés dans les programmes de reprise :

le total des échéances en principal doit correspondre au montant du crédit débloqué ;

dossier de crédit non rattaché à un compte clôturé ou un compte en contentieux ;

toute avance sur bon de caisse doit être rattachée à un dossier de bon de caisse ;

rattachement de chaque garantie au moins à un dossier d’engagement ;

l’échéance des effets à l’encaissement doit être supérieure ou égale à la date de bascule ;

existence d’un blocage comptable pour tous les chèques en état ARP.
 Contrôle de la reprise du référentiel client :
Dans la mesure où il s’agit d’informations qualitatives et volumineuses, le contrôle ne peut être que manuel et ne
peut se faire que sur un échantillon de fiches clients. Il s’agit ici de définir la méthode de sélection d’un
échantillon représentatif. La sélection de cet échantillon peut se baser sur la nature de document d’identification :
carte d’identité nationale, numéro de passeport, numéro de carte de séjour, registre de commerce,…
6. Elaboration du plan de bascule
Le plan de bascule retrace toutes les actions nécessaires pour la réalisation d’une bascule. L’expert comptable
peut piloter les travaux de construction de ce plan. Le plan de bascule fait intervenir plusieurs utilisateurs et il est
établi autour des trois volets suivants :
 Les actions de pré-bascule :

Habilitations : préparer la liste des utilisateurs et leur affectation aux profils prédéfinis ;

Formation et support: dispenser les formations, identifier les structures de support sur place et à distance,…

Logistique : équiper les agences par des nouveaux imprimés, matériel d’impression ou de scannarisation,…

Techniques et réseau : installer les applications, mettre à niveau l’architecture réseau,…

Arrêts des flux : certaines transactions doivent être arrêtées avant un certain moment du jour de la bascule
pour faciliter les opérations de bascule : transfert au contentieux, envoi d’effets pour recouvrement,…

Inventaires physiques : caisses, cautions et avals, garanties financières,…

Rapprochements soldes comptables et des soldes de gestion des systèmes sources ;

Editions des situations sur l’ancien système et validation de ces situations par le responsable d’agence
Page 157
Deuxième Partie
 Les actions de bascule

centralisation des données à partir des applications source ;

traitement des données sources et préparation des fichiers de bascule ;

intégration des données dans le système cible ;

saisie des dossiers à reprendre manuellement ;

lancement du traitement de fin de journée de la bascule ;

paramétrage des accès et des habilitations ;

génération du rapport de bascule.
 Les actions post-bascule

validation de la bascule : exécution des contrôles de validation de bascule ;

traitement des rejets de bascule : recyclage des rejets et réintégration dans le système cible ;

suivi de l’apurement des valeurs en route : chèques à l’encaissement, effets reçus pour paiement,…

désactivation des anciennes applications.
Le plan de bascule doit fournir pour chaque action : une description détaillée de l’action, le responsable de
l’action, le timing d’exécution de l’action et l’ordre d’exécution de l’action (chronologie d’exécution).
7. Contrôle des simulations de migration
Dans le cadre de sa mission d’assistance dans la migration des données, l’expert comptable peut assister la
banque dans le contrôle des simulations de bascule. Son intervention sera limitée au contrôle de la reprise des
données, il n’intervient pas dans les tests de vieillissement des données dans le système cible. Les simulations
de bascule sont réalisées dans des conditions similaires à la bascule réelle. Les travaux de l’expert comptable
consistent essentiellement à :

dérouler les tests de contrôle définis pour chaque nature d’information (Cf. page 155, point 5) ;

analyser les écarts qui sont dégagés ;

définir les actions de fiabilisation complémentaires ;

analyser les rejets d’intégration et définir les actions de régularisation ;

apporter des redressements aux schémas comptables, aux règles de reprise, au plan de bascule ;

améliorer les fonctionnalités des outils de contrôle automatique ;

identifier les contrôles manquants et ajuster le plan de tests ou de contrôles ;

définir les solutions pour le recyclage des données rejetées ;

tester les solutions de recyclage des données ;
Page 158
Deuxième Partie

proposer des modifications dans le planning de bascule ou le lotissement des agences ;

établir le rapport de simulation de bascule à destination de la direction du projet et du comité de pilotage
indiquant le bilan de la simulation et les principales conclusions.
Les équipes techniques de leur coté procèdent à travers les simulations de bascule à analyser les programmes
de reprise : programmes d’extraction des donnée à partir des applications sources, programme de traitement des
données et programme d’intégration dans le système cible. Des améliorations peuvent être apportées à ces
programmes permettant une meilleure performance.
Les travaux de contrôle de simulation de bascule exécutés par l’expert comptable doivent être réalisés
conjointement avec les équipes de la banque. La validation ne peut être prononcée que par ces derniers.
Paragraphe 3 : Mise en œuvre et recette définitive
La stratégie globale de migration étant une stratégie progressive par lots d’agence, le passage en production
sera découpé en deux phases : la phase transitoire au cours de laquelle il y a une cohabitation entre l’ancien et
le nouveau système (1) et la phase cible où toute la banque opère sur le nouveau système d’information (2). Les
principales actions des phases de mise en œuvre doivent être exécutées par les équipes de la banque
contrairement aux phases de préparation de la migration où l’expert comptable peut jouer un rôle plus important
que les équipes internes dont l’intervention peut se limiter à valider les solutions et propositions fournies par
l’expert comptable. La démarche de l’expert comptable dans l’assistance de la banque dans la migration des
données sera illustrée par une application pratique au module crédit (3).
1. Le fonctionnement en configuration transitoire
Durant cette phase la banque fonctionne avec deux systèmes. L’expert comptable assistera la banque dans la
validation des différentes étapes de cette phase :
1.1.
La bascule du noyau comptable et du référentiel client :
Le périmètre de cette bascule couvre les soldes de la comptabilité générale et auxiliaire, un historique de
mouvements comptables, les suspens des comptes de liaison, les suspens des états de rapprochement
bancaires, les conditions spéciales des échelles d’intérêts, les comptes fusionnés, les informations du référentiel
client. L’intervention de l’expert comptable consiste à :

assister les équipes de la banque dans le déroulement des tests de contrôle et de validation ;

recueillir les validations des personnes habilitées et s’assurer que les tests de validation ont été réalisés ;
Page 159
Deuxième Partie

préparer un rapport de bascule ;

définir ou proposer les actions de régularisation en cas d’anomalie ou rejet ;

piloter la réalisation des actions de régularisation (compte rendu de réunion, suivi des avancements,…) ;

documenter les opérations de bascule réalisées.
1.2.
L’alimentation quotidienne du noyau central :
Il s’agit d’alimenter le noyau central du nouveau système des informations comptables (création comptes et
mouvements comptables) et des informations clients produites par les anciennes applications.
L’expert comptable doit assister la banque dans la définition et la mise en place des contrôles permettant de
garantir que toutes les informations clients, comptes et mouvements comptables issus des applications sources
ont été remontées et ont été intégrées dans le noyau central du nouveau système. Il est possible pour assurer
ces contrôles de :

Concevoir un tableau de bord indiquant la situation des intégrations des journées comptables. Il y a lieu de
distinguer entre les trois cas suivants : journée reçue et intégrée, journée reçue et rejetée et journée non
reçue. L’expert comptable peut assister la banque dans la définition d’un processus de régularisation des
différentes anomalies possibles sur les journées comptables. On cite les exemples suivants :
- Rejet d’une journée suite à l’absence du compte général dans le noyau central : la comptabilité doit
intervenir pour créer le compte.
- Rejet d’une journée comptable suite à l’absence d’un compte dans la matrice de correspondance : la
comptabilité doit mettre à jour la matrice de correspondance.
- Rejet d’une journée comptable suite au rejet clients : l’équipe référentiel client doit fiabiliser les
données clients dans le système source et l’équipe informatique doit assurer la remontée de ces
nouvelles informations au noyau central.

Prévoir un système d’accusé de réception qui consiste à envoyer des mails quotidiens aux responsables
des journées comptables au niveau des agences ou au niveau des départements indiquant, pour chaque
journée intégrée dans le système central, le nombre de mouvements et le total des mouvements par devise
et par sens. Les responsables des journées doivent réclamer tout écart constaté avec les données des
applications sources.
1.3.
La bascule des agences pilotes
La bascule des agences pilotes revêt une importance particulière dont la mesure où les équipes de la banque ne
maîtrisent pas parfaitement le processus de bascule. L’expert comptable doit accompagner la banque sur les
aspects suivants :
Page 160
Deuxième Partie

mettre en place une structure de coordination des actions de bascule : cette structure a pour objectif
principal de veiller au respect des actions définies dans le plan de bascule ;

s’assurer que l’ensemble des pré-requis définis par le plan de bascule ont été correctement réalisés et
apporter les solutions nécessaires aux problèmes survenus ;

assister la banque dans la réalisation des tests de validation de la bascule ;

s’assurer que les tests de validation ont été totalement exécutés ;

assister la banque dans l’analyse des écarts et des rejets constatés ;

proposer les solutions pour la régularisation des anomalies enregistrées ;

veiller à la réalisation des actions de régularisation ;

apporter les modifications nécessaires au plan de bascule et ou plan de tests ;

préparation du rapport de bascule.
1.4.
La bascule progressive du reste de réseau des agences
Après la bascule des agence pilotes, les équipes de la banque sont plus autonomes pour conduire les actions de
bascule du reste des agences. L’intervention de l’expert comptable est limitée à s’assurer de la bonne exécution
des actions définies par le plan de bascule. Pour assurer cette mission, l’expert comptable peut maintenir sa
position en tant que membre de l’équipe de coordination des actions de bascule. Il est possible que l’intervention
de l’expert comptable ne s’étende pas à la bascule de ces lots d’agences et sera déclarée clôturée après la
bascule des agences pilotes.
2. Le fonctionnement en configuration cible :
A ce stade, la nouvelle solution est déployée pour l’ensemble des agences. La banque étant en cours de
stabilisation de son nouveau système. La mission de l’expert comptable dans l’assistance dans la migration des
données est arrivée à sa fin. La fin de l’intervention est prononcée soit après la bascule des agences pilotes soit
après le déploiement total de la nouvelle solution.
Dans la cadre des projets d’évolution du nouveau système, la banque peut faire appel aux services de l’expert
comptable notamment pour les projets suivants :

mise à niveau des applications interfacées avec le nouveau système notamment en matière de plan de
comptes. En effet, ces applications continuent à appliquer l’ancienne nomenclature comptable ce qui
nécessite une mise à jour permanente des matrices de correspondance ;

installation d’un nouveau module ou un complément d’un module qui n’a pas été inclus dans le périmètre
fonctionnel initial : cette installation nécessite l’exécution des différentes étapes décrites dans ce chapitre.
Page 161
Deuxième Partie
3. Application pratique au module crédit
La démarche d’assistance qu’on vient de présenter décrit les étapes et les travaux que l’expert comptable peut
accomplir dans une mission d’assistance à la migration des données d’une banque. On essaye maintenant
d’appliquer cette démarche à la bascule du module crédit.
Le module crédit assure principalement les fonctionnalités suivantes : gestion des demandes de crédit, gestion
des études de crédit, gestion des contrats de crédit et des tableaux d’amortissement, gestion des déblocages de
crédit, gestion des tombées d’échéances, gestion des recouvrements d’impayés, gestion des rééchelonnements
et des tombées anticipée de crédit, gestion de la ré-indexation des crédits, gestion des autorisations,…
Nous allons décrire la démarche à suivre par l’expert comptable pour la migration du module crédit depuis la
phase de diagnostic jusqu’à l’installation en production.
3.1.
Diagnostic :
Au cours de cette phase, l’expert comptable doit prendre connaissance :

des applications de gestion des crédits dans l’ancien système et les différents flux qui existent entre-elles ;

des schémas comptables utilisés ;

des différents produits de crédits et les règles de gestion de chaque produit ;

des résultats des inventaires physiques : titres de crédit et autres crédits matérialisés par des effets ;

des volumes de dossiers de dossier de crédit par produit ;

des contrôles comptables existants : rapprochements entre les soldes de gestion et les soldes comptables ;

des documents de formation ou des manuels utilisateurs sur le module crédit de la nouvelle solution.
3.2.
Stratégie de bascule du module
La stratégie globale de bascule étant une stratégie progressive par lots d’agence. Etant donné le volume
important ainsi que l’absence de difficultés particulières pour un régime transitoire, la même stratégie progressive
est la plus appropriée pour ce module. Toutefois, certains types de crédits présentent des exceptions nécessitant
une analyse approfondie pour déterminer les solutions de bascule à appliquer :

Les crédits en devise : ces crédits présentent la particularité qu’ils sont intégrés dans les processus de
l’activité de commerce extérieur et sont traités par le module trésorerie devise.

Les crédits au personnel : un processus différent est appliqué à ce type de crédit notamment en ce qui
concerne le remboursement des échéances : cession sur salaire et non pas prélèvement sur compte.

Les crédits sur des non clients : ces crédits font intervenir le module moyens de paiement notamment les
prélèvements qui seront exécutés sur des comptes domiciliés dans d’autres banques.
Page 162
Deuxième Partie
L’expert comptable doit analyser chacun de ces types de crédit et proposer des solutions de gestion dans le
système cible. Ces propositions doivent être conçues conjointement avec les équipes informatiques et les
chantiers de paramétrage.
3.3.
Définition des informations à migrer et des règles de migration
En considération de la volumétrie importante des dossiers de crédit, l’approche de bascule de ce module ne peut
être qu’une approche automatique.
3.3.1. Détermination des informations à migrer

Informations à représentation comptable : il s’agit essentiellement des encours en principal, des impayés
en principal, des impayés en intérêts, des impayés en intérêts de retard, des autorisations de découvert,
des crédits notifiés et non débloqués et des autorisations sur crédits de gestion.

Informations qualitatives : les principales informations sont :les échéanciers de crédit, le type de crédit ou
du produit, la date de mise en place, la date de déblocage, la date de première échéance, la date dernière
échéance, le mode de remboursement, le type de taux : fixe ou variable, la marge appliquée,…
3.3.2. Définition des règles de migration
L’expert comptable doit apporter des éléments de réponse aux problématiques suivantes :

Reprise des échéanciers : est-il nécessaire de réaliser cette reprise ou il est suffisant de reprendre les
éléments des dossiers de crédit et établir les échéanciers directement dans le système cible ? Pour
répondre à cette problématique l’expert comptable doit comparer entre les échéanciers des deux systèmes
pour les différents modes de remboursement pour des crédits ayant les mêmes conditions. Si aucune
différence n’a été constatée, il est envisageable que la reprise des échéanciers ne soit pas nécessaire.

Détermination des sources d’information : multiples sources interviennent dans la gestion des crédits :
- Des applications spécifiques permettent de gérer des catégories de crédits déterminées : crédits au
personnel, financements en devise,…
- Les autorisations sur crédit ou autorisations de découvert sont gérées sur d’autres systèmes.
- Un même crédit peut être géré dans plus d’un système : le système de front office qui gèrera
l’établissement de l’échéancier, le déblocage et les impayés sur crédit et le système central appelé aussi
« le portefeuille central » qui gère en plus de la conservation physique des titres, la préparation des
tombées d’échéances et autres modifications dans le cycle de vie du crédit.
L’expert comptable peut être confronté aux trois situations suivantes:
Page 163
Deuxième Partie
Situation
Solution
L’information existe dans une seule source
Correspondance directe avec les tables cibles
La même information existe mais elle est dupliquée dans
plusieurs sources.
Exemples
 Les échéanciers de crédit sont conservés dans le système
agence et dans le système portefeuille central
 Les impayés sur crédits sont indiqués dans la base des
impayés ainsi qu’au niveau des échéanciers
 Les autorisations de découvert existent dans le système
agence, le système de saisie des autorisations notifiées, et
le système de calcul des échelles d’intérêts
L’expert comptable doit assister la banque dans le choix
de la source la plus appropriée. Le choix dépendra de la
fiabilité de la source. Cette fiabilité est mesurée par :
 Des rapprochements entre les soldes de gestion et les
soldes comptables.
 Des résultats des inventaires physiques
 La compréhension et l’analyse des flux et des règles de
gestion de chaque source
Dans tous les cas, des travaux de fiabilisation seront
appliqués à la source qui sera retenue.
L’information n’existe pas
Exemples
 Les intérêts de retard : ces intérêts ne sont décomptés
L’expert comptable doit assister la banque dans la
dans l’ancien système qu’au jour de l’encaissement. Dans
définition de la règle de gestion qui permet de déterminer
le nouveau système, ils sont décomptés périodiquement.
l’information demandée.
 Montant des intérêts perçus d’avance : il est possible que
l’information sur ces intérêts ne soit pas stockée dans
l’ancien système.
Une fois les différentes sources d’information ont été identifiées, l’expert comptable assurera le pilotage des
travaux de correspondance entre les systèmes sources et le système cible.
3.3.3. Définition des schémas de bascule
L’expert comptable doit avoir une compréhension suffisante des schémas actuels et des schémas cibles pour
déterminer toutes les écritures de bascule nécessaires.

Reprise des encours en principal
Reprise de dossier extra
Vidage du solde comptable
1er Cas : les encours de crédit sont comptabilisés au niveau de l’agence à basculer
Ecriture détaillée pour chaque dossier de crédit repris
Age
Compte
sens
Montant
Montant
Client Compte d’encours (1)
D
Extra
Montant
Client Compte de bascule (2)
C
Extra
(1) Le compte d’encours peut être selon les options de
paramétrage retenues soit un compte général pour le
produit de crédit en question ou un compte technique
crée automatiquement par le programme de reprise
(2) Un compte de bascule sera créé pour chaque compte
d’encours prévu selon la classification des crédits dans
l’ancienne nomenclature comptable.
Ecriture globale pour chaque agence à basculer si le
compte d’encours est général (Ecriture par dossier si le
compte d’encours est clientélisé dans l’ancien
système)
Age
Compte
sens
Montant
Solde
Client Compte de bascule
D
comptable
(3)
Solde
Client Ancien compte d’encours C
comptable
(3) Le solde comptable correspond au solde de l’agence
dans chaque compte d’encours.
Page 164
Deuxième Partie
2ème
Cas : les encours de crédit sont comptabilisés au niveau du portefeuille central
Même schéma de comptabilisation que le premier cas


Age
Compte
sens
Montant
PTF
Cpte de liaison
D
Mnt Extra
PTF
Ancien compte d’encours C
Mnt Extra
client Compte de bascule
D
Mnt Extra
client Cpte de liaison
C
Mnt Extra
Dans la mesure où il n’est pas possible d’identifier le solde
de l’agence à basculer, le nivellement se fait selon le
montant extra. L’écart de bascule sera dégagé à la fin de la
bascule de toutes les agences et sera logé dans l’ancien
compte d’encours tenu au niveau du portefeuille central. Le
compte de bascule sera nul dans notre cas.
Reprise des impayés en principal et en intérêts
Age
Compte
sens
Montant
Compte d’impayés en
Client
D
Mnt Extra
principal ou en intérêts(1)
C
Mnt Extra
(1) Les comptes d’impayés peuvent être selon les options de
paramétrage retenues soit des comptes généraux pour le
produit de crédit en question ou des comptes techniques
crées automatiquement par le programme de reprise
d’impayé prévu dans l’ancienne codification comptable
Ecriture globale pour chaque agence à basculer si les
comptes d’impayés sont des comptes généraux
(Ecriture par dossier si les comptes d’impayés sont
clientélisés dans l’ancien système)
Age
Compte
sens
Montant
Client
Compte de bascule
D
Solde
comptable (3)
Ancien compte d’impayé
Solde
C
(principal / Intérêts)
comptable
(3)Le solde comptable correspond au solde de l’agence
dans chaque compte d’impayés
Client
Reprise des impayés en intérêts de retard
1er Cas : les intérêts de retard sont comptabilisés dans l’ancien système
Même schéma de comptabilisation que les impayés en
principal ou impayés en intérêts
Même schéma de comptabilisation que les impayés en
principal ou impayés en intérêts
2ème Cas : les intérêts de retard ne sont pas comptabilisés dans l’ancien système
Age
Compte
sens
Montant
Compte d’impayés en
Montant
Client
D
intérêts de retard(1)
Extra
Comptes de produits ou
Montant
Client
C
d’agios réservés (2)
Extra
(1) Les comptes d’impayés peuvent être selon les options de
paramétrage retenues soit des comptes généraux pour le
produit de crédit en question ou des comptes techniques
créés automatiquement par le programme de reprise
(2) Selon les schémas comptables retenus, les impayés sur
intérêts de retard seront directement constatés en agios
réservés ou dans des comptes de produits.
Page 165
Deuxième Partie

Reprise des engagements de financement : autorisation de découvert, crédit notifié non débloqué,…
1er Cas : les engagements de financement sont comptabilisés dans l’ancien système
Ecriture détaillée pour chaque engagement repris
(Ecriture hors bilan)
Age
Compte
sens Montant
Client Compte d’engagement (1)
D
Mnt Extra (3)
C
Mnt Extra
(1) Les comptes d’engagement de financement peuvent
être selon les options de paramétrage retenues soit des
comptes généraux pour le produit de crédit en question
ou des comptes techniques créés automatiquement par
le programme de reprise
d’engagement de financement prévu dans l’ancienne
codification comptable.
(3) Il s’agit du montant non encore utilisé et non pas le
montant total de l’autorisation
Ecriture globale pour chaque agence à basculer si les
comptes d’engagement de financement sont des
comptes généraux (Ecriture par dossier si les comptes
d’engagement de financement sont clientélisés dans
l’ancien système)
Age
Compte
sens Montant
Solde
Client Compte de bascule
D
comptable (3)
Ancien compte d’engagement
Solde
Client
C
de financement
comptable
(4) Le solde comptable correspond au solde de l’agence
dans chaque compte d’engagement de financement
2ème Cas : les engagements de financement ne sont pas comptabilisés dans l’ancien système
(Ecriture hors bilan)
Age
Compte
sens
Montant
Compte d’engagement de
Montant
Client financement (général ou D
Extra
clientélisé)
Compte de contrepartie
Montant
Client
C
(1)
Extra
(1) Il s’agit du compte de contre partie Hors bilan de
l’engagement de financement en question

Régularisation des discordances de schémas comptables entre les deux systèmes:
Discordance
Ecriture de régularisation
I- Comptabilisation des intérêts perçus d’avance :
Ecriture par dossier de crédit repris
Ancien système
Age
Compte
sens Montant
- Comptabilisation en produits à la date d’encaissement
Client Compte du produit (1)
D
Total intérêts
- Régularisation par produits perçus d’avance en fin du
Client
Cpte
prdt
perçus
d’avance
(2)
C
Total intérêts
mois
(1) Le compte de produit rattaché à la nature de crédit
- Annulation de l’écriture de régularisation au lendemain
(2) Le compte de produits perçus d’avance qui a été
Nouveau Système
- Comptabilisation en produits perçus d’avance à la date paramétré dans le schéma cible pour la constatation des
intérêts pour le type de crédit concerné
d’encaissement (mise en place crédit)
(3)
Il faut forcer la date de début da calcul pour les
- Constatation du produit couru à la fin de chaque mois.
abonnements futurs à la date de mise en place du dossier.
II- Comptabilisation des échéances en intérêts non Ecriture par dossier de crédit repris
échus
Age
Compte
sens Montant
Ancien système
Total intérêts
Compte Intérêts Exigible
D
Comptabilisé dans la comptabilité générale au niveau du PTF
non échus
portefeuille central
Total
intérêts
Nouveau Système
PTF
Compte Encours intérêts
C
non
échus
Non comptabilisé
Page 166
Deuxième Partie
3.4.
Fiabilisation des données
L’expert comptable doit établir un rapport synthétisant la qualité des informations sur les crédits. Ce rapport
présente la situation des écarts entre les soldes comptables et les soldes de gestion des différentes sources
d’informations ainsi que les résultats des inventaires physiques les plus récents des titres de crédit et autres
effets. Ce rapport doit définir les actions de fiabilisation qui doivent avoir lieu et les dates limites de réalisation de
ces travaux. L’intervention de l’expert comptable peut se limiter au pilotage des travaux de fiabilisation et elle
peut s’étendre à la participation dans ces travaux.
Une attention particulière doit être fournie à la documentation des travaux de fiabilisation et à la piste d’audit.
3.5.
Définition des outils de contrôle
 Outils de contrôle informatisés :
L’expert comptable doit fournir des spécifications pour le développement des outils permettant d’assurer :

Un rapprochement automatique pour chaque agence entre les soldes extra-comptables des applications
sources et les soldes comptables des encours, impayés et engagements de financement.

Un rapprochement automatique pour chaque agence entre les soldes extra-comptables des applications
sources et les soldes extra-comptables dans le système cible (après intégration) des encours, impayés et
engagements de financement.

Un rapprochement automatique entre les écarts dégagés avant l’intégration des données et les soldes des
comptes de bascule.
 Tests de cohérence :
L’expert comptable doit fournir aux équipes informatiques les tests de cohérence qui seront vérifiés lors du
chargement des dossiers dans le nouveau système. En cas d’anomalie, le dossier en question ne pourra pas
être chargé :

le total des échéances en principal doit correspondre au montant du crédit débloqué ;

le dossier de crédit n’est pas rattaché à un compte clôturé ou un compte en contentieux ;

absence de dossier avec des échéances impayées suivies d’échéances payées ;

la nature du taux (fixe ou variable) pour le crédit repris est conforme à la nature du taux paramétrée dans le
système cible pour le type de crédit en question ;

la date de déblocage est supérieure à la date de mise en place ;

la date de la première échéance est supérieure à la date de déblocage ;

le taux d’intérêt de mise en place est égal au TMM de la date de mise en place majoré de la marge ;
Page 167
Deuxième Partie

le nombre d’échéance du dossier est conforme à la période maximale paramétrée pour le type de crédit en
question ;

l’échéancier d’un crédit court terme dont les intérêts sont perçus d’avance doit être formé uniquement de
deux lignes : ligne pour l’échéance en intérêts et une ligne pour l’échéance en principal ;

le montant des impayés ne doit pas dépasser le montant de l’échéance en question ;

le compte de bascule correspondant à la nature du crédit à reprendre est crée dans l’agence concerné ;

l’échéance des autorisations est supérieure à la date de bascule.
3.6.
Plan bascule
Les spécificités applicables au module crédit concernent les actions d’arrêts de flux :

arrêt de déblocage de crédit dans l’ancien système avant un certain nombre de jours de la bascule de
manière à garantir que tous les dossiers débloqués ont été créées dans le « portefeuille central » ;

arrêt des opérations de transfert au contentieux avant un certain nombre de jours de la bascule de manière
à s’assurer que tous les dossiers transférés au contentieux ont été déchus dans l’ancien système ;

arrêt des opérations de remboursement anticipé ou des opérations de rééchelonnement avant un certain
nombre de jour de la bascule de manière à s’assurer que ces opérations ont été réalisées dans l’ancien
système.
D’autres actions d’arrêts de flux peuvent être envisagées en fonction des processus de la banque.
3.7.
Simulation de migration
Il s’agit ici d’assister la banque dans le déroulement des tests de contrôles qui ont été définis. L’expert comptable
doit particulièrement identifier les actions d’ajustement et d’amélioration dans les différents aspects de la
bascule : plan de bascule, schémas comptables de bascule, planning de bascule, performance des programmes
de bascule,…
3.8.
Bascules réelles
La validation d’une bascule réelle doit être prononcée par les équipes internes de la banque, l’intervention de
l’expert comptable consiste essentiellement à s’assurer que toutes les actions de bascule ont été réalisées
conformément au plan de bascule.
Page 168
Conclusion Générale
CONCLUSION GÉNÉRALE
La motivation initiale de ce travail est née du constat de l’absence des experts comptables dans les grands
projets de changement de systèmes d’information entrepris ces dernières années par des banques tunisiennes.
Ces banques ont fait appel plutôt à des cabinets de conseil de renommé internationale66, pour les accompagner
et les assister dans la réalisation de leur projet de migration vers une solution de «Global Banking », et ce pour
des coûts considérables. Ces coûts importants, allant parfois à la moitié du coût total du projet, sont justifiés par
la mobilisation de plusieurs consultants pour une période aussi importante que la période de la réalisation du
projet.
Ce travail a essayé donc de mettre en exergue cette importante opportunité offerte aujourd’hui par le marché
bancaire tunisien aux experts comptables. Cette opportunité trouve ses fondements par les besoins urgents auxquels toutes les banques sont confrontés aujourd’hui à mettre à niveau leur système d’information d’une part et
par la capacité de l’expert comptable à contribuer efficacement dans ce changement d’autre part.
Nous avons commencé ce travail par démontrer le besoin du changement. Ce besoin sans cesse, d’évolution et
de modernisation est dicté par deux catégories de facteurs : l’évolution des métiers, de la règlementation et de
l’environnement bancaires d’une part et l’évolution considérable des technologies et des architectures
informatiques d’autre part. « Il n’est pas exagéré de considérer aujourd’hui l’outil informatique comme un levier
important de différenciation concurrentielle dans le secteur bancaire »67. Ce constat est parfaitement valable
lorsqu’on constate que toutes les banques de la place ont déjà opéré le changement, ou elles sont en cours de
changement ou de réflexion pour réaliser ce changement. La solution choisie par toutes étant l’ERP, appelé
« Global Banking » dans le jargon bancaire.
Le choix de la solution et la réalisation du changement incluent plusieurs étapes et font appel à plusieurs
ressources humaines et financières et comportent plusieurs facteurs de risque. Dans ce cadre, nous avons
présenté les principaux cadres de référence adoptés à l’échelle internationale pour la conduite et la gestion de
projets. Cette description des travaux de normalisation, applicables aux différents types de projet, a été
accompagnée par la présentation d’une démarche pratique et adaptée aux projets de choix et d’implantation de
« Global Banking ». Cette description pratique des étapes et des actions découle principalement de la
participation opérationnelle dans les différentes phases d’un projet de changement réalisé par une banque
66
67
Accenture (Attijari Bank), Euro group (BIAT)...
Michel Lafitte, Les grands projets de système d’information, Revue Banque (2003), préface
Page 169
Conclusion Générale
locale. Cette description permet essentiellement de mieux appréhender les enjeux pratiques, les contextes et les
facteurs de risque de ce type de projet. La démarche qui a été présentée a été mise à l’épreuve et a permis au
projet d’aboutir aux objectifs assignés.
Dans la deuxième partie de ce travail, on s’est intéressé à démontrer la capacité éprouvée pour l’expert
comptable d’intervenir, de participer et d’assister les banques dans leur projet de changement. En effet, chaque
étape du projet, est l’occasion pour l’expert comptable de montrer ses atouts et ses compétences pour participer
et contribuer dans ce type de projet. Plusieurs rôles et actions peuvent être réalisés par l’expert comptable :
pilotage, conception, organisation, tests, formation,...Les différentes missions qui peuvent être confiées à l’expert
comptable ont été recensées et décrites pour voir de près l’adaptation de ces types d’intervention aux profils et
compétences de l’expert comptable. Un focus a été donné à l’une des activités du projet qui est l’étape de
migration des données vers le nouveau système. Cette analyse détaillée permet de fournir des éléments
pratiques pour une mission d’accompagnement dans cette phase spécifique du projet.
Les métiers de l’expert comptable doivent évoluer pour tenir compte des nouveaux besoins et des opportunités
qu’offre le marché. Les technologies de l'information et de la communication font connaître à l'humanité l'une de
ses plus merveilleuses époques. Evoluer dans un environnement en perpétuel mouvement requiert une extrême
vigilance car les écarts sont très vite creusés selon la capacité des uns et des autres à suivre la cadence et à se
former. Le marché de conseil en système d’information est peu ou quasi-non exploité par les experts comptables
pour plusieurs raisons : méconnaissance du domaine, difficulté de pénétrer un marché monopolisé par les
grands cabinets de conseil, spécialisation nécessitant des investissements humains et matériels conséquents,…
Toutefois, ce marché à forte valeur ajoutée peut devenir une source de développement pour les experts
comptables. L’intégration de ce marché nécessite un recours massif à la formation et à la spécialisation.
Page 170
Bibliographie
BIBLIOGRAPHIE
OUVRAGES

Michel LATIFFE, « les grands projets de systèmes d’information dans les établissements bancaires »,
Revue Banque, 2003

Jean-Luc DEIXONNE, « Piloter un projet ERP », DUNOD, 2006

Jean-Louis TOMAS, « ERP et PGI sélection, méthodologie de déploiement et gestion du changement »,
DUNOD, 2007

Henri Kloetzer, « La maîtrise d’ouvrage des projets informatiques », Hemes Sciences, 2002

Stephen Harwood, ERP, The implementation cycle, Butterworth-Heinemann, 2003

Linda Stroth & Homer Johnson:The Basic principles of effective consulting, Lawrence Erlbaum Associates, 2006

Jack T. MARCHEWKA, Information technology project management, 2003
NORMES

La norme ISO 10006: lignes directrices pour la gestion de projet

La norme AFNOR FD X50-115 : Management de projet - Présentation générale

La norme AFNOR FD X50-117 : Gestion du risque - Management des risques d'un projet

La norme AFNOR FD X50-118 : Recommandations pour le management d'un projet

A guide to the project management body of knowledge, Third Edition (PMBOK Guide), Project management
Institute, Edition 2004

International Education practice Statement (IPES2) : Information Technology for professional accountant,
IFAC Education committee

Guideline 3 : Acquisition of informational technology, IFAC’s Information Technology Committee

Guideline 4 : The implementation of information technology solutions, IFAC’s Information Technology
Committee

Guide sur l’assistance à la maîtrise d’ouvrage en informatique, Commission technique des marchés en
France, www.minefe.gouv.fr
Page 171
Bibliographie

Convergence internationale de la mesure et des normes de fonds propres, Comité de Bâle sur le contrôle
bancaire (juin 2006), www.bis.org
MÉMOIRES

Natouri Christine, L’expert comptable et la refonte de l’organisation des systèmes d’information
comptables : approche par l’intégration d’applications, 2002 (mémoire pour l’obtention du diplôme
d’expertise comptable en France)

Sofiane Gargouri, Les métiers de l’expert-comptable dans le contexte des nouvelles technologies de
l’information et de la communication : de l’étude d’impact à l’organisation de la réaction, 2003 (mémoire
pour l’obtention du diplôme d’expertise comptable en Tunisie)

Seddiqi Nasser, Contribution de l’expert comptable à la conception et à la mise en place du système
d’information comptable d’un établissement de crédit, 2007 (mémoire pour l’obtention du diplôme
d’expertise comptable en France)

Vincent ESPIE, Problématique et méthodologie d’implantation d’un ERP, 2002 (Mémoire de thèse
professionnelle pour l’obtention du Mastère Spécialisé en Management des Systèmes d’Information et des
Technologies)

Ingrid Berghman, L’accompagnement du changement : facteurs clés de succès d’un projet d’ERP, 2003
(Mémoire de thèse professionnelle pour l’obtention du Mastère Spécialisé en Management des Systèmes
d’Information et des Technologies)
REVUES , ARTICLES ET RAPPORTS


T. BAHOURY, « Global Banking : Ou l’occasion, pour la Tunisie, de devenir un acteur de l’industrie du
software ? » www.webmanagercenter.com - 22/04/2005

« A la recherche d'une solution "Global Banking" », www.webmanagercenter.com - 24/03/2005

« Réforme du secteur bancaire : Engagement irréversible sur la voie du libéralisme du secteur »,
l'Economiste Maghrébin N°377

José DIZ, « Les critères à privilégier pour choisir son ERP », 29 septembre 2004, www.Zdnet.fr
Page 172
Bibliographie

« The ERP selection Proces, survival Guide», www.relevant.com

Conclusions préliminaires de la mission de consultation au titre de l’article IV, Rapport FMI, 15 juin 2010,
www.imf.org

Mise à jour de l’évaluation de la stabilité du système financier- Évaluation détaillée de la conformité aux
principes fondamentaux de Bâle pour un contrôle bancaire efficace, Rapport FMI N° 7/98 (Mars 2007),
www.imf.org

Jean-Grégoire Bernard, Suzanne Rivard et Benoit A. Aubert, « Evaluation de risque d’implantation de
progiciel», Rapport CIRANO (centre universitaire de recherche en analyse des organisations), Septembre
2002

J. Carlton Collins, «23 Steps for Choosing the Right ERP Accounting Software Package», 2003,
www.accountingsoftwareadvisor.com

«Les enjeux d'une démarche de sélection de progiciel », www.aldea.fr

Le Cigref (Club informatique des grandes entreprises françaises), « Retour d’expérience ERP », Septembre
1999.

Le Cigref (Club informatique des grandes entreprises françaises), « Parties prenantes du système
d’information : un nouveau regard sur la maîtrise d’ouvre et la maîtrise d’ouvrage », Octobre 2003

Le Cigref (Club informatique des grandes entreprises françaises), « Référentiel métiers des activités de
l’informatique », Mars 2010.

Gita SRIVATSAN, «ERP : Role of chartered accountant», The chartered accountant journal- juillet 2006,
www.icai.org

Santhana KRISHNAN, «Professional opportunities for chartered accountants in information technology
sector», The chartered accountant journal- août 2006, www.icai.org

Bénédicte GUALBERT, « Le conseil en management francilien, un secteur dynamique et en constant
évolution », mars 2009, Chambre de commerce et d’industrie de Paris

Fatma M’SELMI, « Enquête sur les bureaux d’études et de conseil membres de la CSNEECF », Mai 2008

Michel le SOURD, « L’expert comptable face à l’informatique sa responsabilité », Revue Française de
comptabilité N°209, 1990.
Page 173
Bibliographie

« Etablir le plan de communication d’un projet », Direction générale Communication externe, Bruxelles,
Décembre 2005 (www.fedweb.belgium.be)

Maxime LEQUINT & Marjorie PHILIPPON, « Accompagnement au changement lors de la mise en place
d’un projet ERP », février 2007, www.mlequint.net

Jean-Grégoire BERNARD, Suzanne RIVARD, Benoît AUBERT, « Evaluation du risque d’implantation de
progiciel », Septembre 2002, www.cirano.qc.ca

Thierry ROBY, « Maîtrise d’ouvrage et Maîtrise d’ouvre dans les projets de mise en œuvre de système
d’information », 2006, ww.droit-ntic.com

Gilles GAREL, Vincent GIARD & Christophe MIDELR, « Management de projet et gestion des ressources
humaines », 2001, www.iae-paris.com

CHRISTOPHE DESHAYES, « L ’ERP, le Processus… et le Consultant », 2004, www.journaldunet.com
SITES WEB DE REFERENCE

www.projet-online.com

www.ifac.org

www.ifacnet.com

www.oect.org.tn

www.gestiondeprojet.net

www.entreprise-erp.com

www.datamigrationpro.com

www.wikipedia.org
Page 174
Annexes
ANNEXES
Annexe 1 : Plan du document de cadrage d’un projet (Norme AFNOR FD X 50-118)
Page 175
Annexes
Annexe 2 : Sommaire Indicatif d’un plan de management de projet (Norme AFNOR FD X 50-118)
Page 176
Annexes
Page 177
Annexes
Annexe 3 : Exemple de structure de découpage des risques d’un projet (PMBOK, chapitre 11 :
management des risques du projet)
Page 178
Table des matières
TABLE DES MATIÈRES
SOMMAIRE ................................................................................................................................................................................................. 1
INTRODUCTION GÉNÉRALE .................................................................................................................................................................... 2
PREMIÈRE PARTIE : CONDUITE DU PROJET D’IMPLANTATION D’UN GLOBAL BANKING : ENJEUX DU CHANGEMENT ET
DÉMARCHE DE DÉPLOIEMENT ............................................................................................................................................................... 5
CHAPITRE 1 : ENJEUX DU CHANGEMENT DU SYSTÈME D'INFORMATION ....................................................................................... 6
SECTION 1 : MOTIVATIONS POUR LE CHANGEMENT VERS UN ERP ................................................................................................................ 6
Paragraphe 1 : Etat des lieux de l’activité bancaire ........................................................................................................................... 6
1.
Des nouveaux défis pour les banques ...................................................................................................................................................... 6
1.1.
Libéralisation du secteur bancaire .................................................................................................................................................. 6
1.1.1.
Emergence du concept de la banque universelle ..................................................................................................................... 7
1.1.2.
Le désengagement progressif de l’ETAT .................................................................................................................................. 8
1.1.3.
Intensification de la concurrence ............................................................................................................................................... 9
1.1.3.1. Expansion du réseau d’agences ......................................................................................................................................... 9
1.1.3.2. Multiplication des canaux de distribution .......................................................................................................................... 10
1.1.3.3. Développement de nouveaux produits, marchés et activités ........................................................................................... 10
1.1.3.4. Promotion de la qualité des services bancaires ............................................................................................................... 10
1.1.4.
La convertibilité totale du dinar ................................................................................................................................................ 11
1.2.
Renforcement de la culture de risque ........................................................................................................................................... 12
1.2.1.
Renforcement du contrôle interne et des règles de la bonne gouvernance ............................................................................ 12
1.2.2.
Mise en conformité au dispositif prudentiel Bâle II .................................................................................................................. 14
1.2.3.
Lutte anti-blanchiment d’argent (Anti-money laundering : AML) ............................................................................................. 15
1.2.4.
Conformité avec les normes IFRS .......................................................................................................................................... 16
2.
Examen des systèmes d’information actuels .......................................................................................................................................... 17
2.1.
Présentation et genèse des systèmes actuels ............................................................................................................................. 17
2.1.1.
Les systèmes non urbanisés appelés par certains « patchworks applicatifs » ....................................................................... 17
2.1.2.
Les systèmes constitués autour d’un « Global Banking » : ..................................................................................................... 19
2.2.
Insuffisances et lacunes des systèmes en place .......................................................................................................................... 20
2.2.1.
Les limites des systèmes non urbanisés ................................................................................................................................. 20
2.2.2.
Impacts des insuffisances des systèmes non urbanisés sur l’activité des banques ............................................................... 20
2.2.2.1. Impacts opérationnels ....................................................................................................................................................... 20
2.2.2.2. Impacts commerciaux ....................................................................................................................................................... 22
Paragraphe 2 : Apports des ERP ..................................................................................................................................................... 24
1.
Définitions, historique et transition vers la gestion par ERP .................................................................................................................... 24
1.1.
Evolution de l’informatique de gestion et naissance des ERP...................................................................................................... 24
1.2.
Définitions et caractéristiques des ERP ........................................................................................................................................ 25
2.
Bénéfices attendus par les banques de l’implantation d’un ERP ............................................................................................................ 26
2.1.
Avantages des ERP : .................................................................................................................................................................... 26
2.2.
Avantages spécifiques pour les banques ..................................................................................................................................... 27
3.
Risques associés aux ERP ...................................................................................................................................................................... 29
3.1.
La mauvaise qualité du système................................................................................................................................................... 29
3.2.
Le dépassement du budget .......................................................................................................................................................... 29
3.3.
Dépassement de l’échéancier....................................................................................................................................................... 29
3.4.
Insatisfaction des utilisateurs ........................................................................................................................................................ 30
SECTION 2 : COMMENT CHOISIR SON ERP ? ............................................................................................................................................ 30
Paragraphe 1 : Le marché des Global Banking ............................................................................................................................... 30
1.
2.
Le marché tunisien .................................................................................................................................................................................. 30
Le marché mondial .................................................................................................................................................................................. 32
Paragraphe 2 : Critères et démarche du choix de l’ERP.................................................................................................................. 34
1.
Critères de sélection ................................................................................................................................................................................ 34
1.1.
Les critères stratégiques ou « politiques » ................................................................................................................................... 34
1.2.
Les critères fonctionnels ............................................................................................................................................................... 34
1.3.
Les critères techniques ................................................................................................................................................................. 34
1.4.
Les critères commerciaux ............................................................................................................................................................. 35
1.5.
Les critères méthodologiques ....................................................................................................................................................... 35
2.
Processus illustré de sélection ................................................................................................................................................................ 35
2.1.
Spécification des exigences.......................................................................................................................................................... 36
Page 179
Table des matières
2.1.1.
Etat des lieux et analyse de l’existant...................................................................................................................................... 36
2.1.2.
Définition des objectifs et principes directeurs ........................................................................................................................ 37
2.1.3.
Benchmarking et grandes tendances ...................................................................................................................................... 37
2.1.4.
Définition de la cible................................................................................................................................................................. 38
2.1.5.
Définition de la trajectoire de convergence vers la cible ......................................................................................................... 38
2.2.
Appel d’offres ................................................................................................................................................................................ 39
2.2.1.
Recherche des prestataires ..................................................................................................................................................... 39
2.2.2.
Rédaction du cahier des charges ............................................................................................................................................ 39
2.3.
Evaluation des offres et sélection de la solution ........................................................................................................................... 44
2.3.1.
Evaluation des réponses ......................................................................................................................................................... 44
2.3.2.
Acquisition de connaissances approfondies ........................................................................................................................... 45
2.3.3.
Evaluation définitive et choix de la solution ............................................................................................................................. 45
2.4.
Contractualisation ......................................................................................................................................................................... 45
CHAPITRE 2 : PROCESSUS D’IMPLANTATION D’UN GLOBAL BANKING ........................................................................................ 46
SECTION 1 : CADRE DE RÉFÉRENCE DE CONDUITE DE PROJET ................................................................................................................... 47
Paragraphe 1 : Standards internationaux de gestion de projet ........................................................................................................ 48
1.
2.
3.
L’Organisation Internationale de Normalisation (ISO) ............................................................................................................................. 48
L’Association Française de Normalisation (AFNOR) ............................................................................................................................... 49
L’Institut de Management de Projet (PMI) ............................................................................................................................................... 49
Paragraphe 2 : Concepts de base de gestion de projet proposés par les standards internationaux ............................................... 51
1.
Aspects majeurs du contexte de management de projet ........................................................................................................................ 51
1.1.
Cycle de vie du projet ................................................................................................................................................................... 51
1.2.
Organismes ................................................................................................................................................................................... 52
1.3.
Parties prenantes d’un projet ........................................................................................................................................................ 52
2.
Recommandations relatives aux principaux domaines d’activités/processus du management d’un projet ............................................ 52
2.1.
Management de l’intégration du projet ......................................................................................................................................... 53
2.1.1.
Objectifs du processus ............................................................................................................................................................ 53
2.1.2.
Principales tâches du processus ............................................................................................................................................. 53
2.2.
Gestion du contenu du projet ........................................................................................................................................................ 54
2.2.1.
Objectifs du processus : .......................................................................................................................................................... 54
2.2.2.
2.3.
Gestion des délais ........................................................................................................................................................................ 55
2.3.1.
2.3.2.
2.4.
Gestion des coûts ......................................................................................................................................................................... 56
2.4.1.
2.4.2.
2.5.
Gestion des ressources humaines................................................................................................................................................ 57
2.5.1.
2.5.2.
2.6.
Gestion des communications ........................................................................................................................................................ 58
2.6.1.
2.6.2.
Principales tâches du processus : ........................................................................................................................................... 58
2.7.
Gestion des risques ...................................................................................................................................................................... 59
2.7.1.
2.7.2.
2.8.
Gestion des achats et approvisionnements .................................................................................................................................. 60
2.8.1.
2.8.2.
2.9.
Gestion de la qualité du projet ...................................................................................................................................................... 62
2.9.1.
2.9.2.
SECTION 2 : DÉMARCHE ILLUSTRÉE DE MISE EN PLACE D’UN GLOBAL BANKING ......................................................................................... 63
Paragraphe 1 : Phase de lancement ................................................................................................................................................ 63
1.
Le plan de management du projet ........................................................................................................................................................... 63
1.1.
Périmètre fonctionnel du projet ..................................................................................................................................................... 63
1.2.
Stratégie de bascule ..................................................................................................................................................................... 64
1.3.
Planning de mise en place ............................................................................................................................................................ 65
1.4.
L’organigramme du projet et les instances de pilotage ................................................................................................................ 66
1.4.1.
Organigramme du projet : ........................................................................................................................................................ 66
1.4.2.
Gouvernance et instances du pilotage du projet : ................................................................................................................... 66
1.5.
Plan des risques du projet ............................................................................................................................................................ 67
1.6.
Le budget ...................................................................................................................................................................................... 67
Page 180
Table des matières
2.
1.7.
Méhodes de reporting et de communication ................................................................................................................................. 67
Activités préparatoires à la réalisation de la solution ............................................................................................................................... 68
2.1.
Lieu de déroulement des activités du projet ................................................................................................................................. 68
2.2.
Base documentaire ....................................................................................................................................................................... 68
2.3.
la plate-forme technique ............................................................................................................................................................... 68
2.4.
Libérer et former de l’équipe projet ............................................................................................................................................... 68
2.5.
Inventaires des procédures actuelles et des procédures cibles ................................................................................................... 69
2.6.
Catalogue des produits et services et leurs règles de gestion ..................................................................................................... 70
2.7.
Cartographie des systèmes d’information existant ....................................................................................................................... 70
2.8.
La réunion du lancement .............................................................................................................................................................. 70
Paragraphe 2 : La configuration et l’homologation de la solution .................................................................................................... 70
1.
Paramétrage et identification des écarts fonctionnels ............................................................................................................................. 70
1.1.
Réalisation du paramétrage .......................................................................................................................................................... 71
1.2.
Identification des écarts fonctionnels (Gap) .................................................................................................................................. 73
2.
Développements ...................................................................................................................................................................................... 74
2.1.
Reprise des données .................................................................................................................................................................... 74
2.2.
Les interfaces ................................................................................................................................................................................ 76
2.3.
Les éditiques et reportings ............................................................................................................................................................ 77
2.4.
Les écarts fonctionnels (Gap) ....................................................................................................................................................... 77
3.
L’homologation de la solution .................................................................................................................................................................. 78
3.1.
Tests d’homologation ou de recette .............................................................................................................................................. 78
3.2.
Simulations de bascule ................................................................................................................................................................. 80
3.3.
Tests de montée en charge (stress test) ...................................................................................................................................... 81
Paragraphe 3 : La mise en production ............................................................................................................................................. 82
1.
La conduite du changement .................................................................................................................................................................... 82
1.1.
La communication ......................................................................................................................................................................... 82
1.2.
Formation des utilisateurs ............................................................................................................................................................. 83
1.3.
L’assistance au démarrage ........................................................................................................................................................... 84
2.
Le déploiement de la solution .................................................................................................................................................................. 84
2.1.
Les pré-requis de déploiement ..................................................................................................................................................... 84
2.2.
La validation d’une bascule........................................................................................................................................................... 85
2.3.
Le déploiement progressif............................................................................................................................................................. 86
3.
La post-implémentation du nouveau système d’information ................................................................................................................... 87
3.1.
Stabilisation du passage en production ........................................................................................................................................ 87
3.2.
Pleine utilisation du nouveau système .......................................................................................................................................... 87
3.3.
Evolution du nouveau système ..................................................................................................................................................... 88
DEUXIÈME PARTIE : RÔLES DE L'EXPERT COMPTABLE DANS LES PROJETS D’IMPLANTATION DE GLOBAL BANKING :
DOMAINES D’INTERVENTION ET DÉMARCHE PRATIQUE D’ASSISTANCE DANS LA MIGRATION DES DONNÉES .................... 89
CHAPITRE 1 : L’IMPLANTATION DE « GLOBAL BANKING », DE NOUVELLES MISSIONS POUR L’EXPERT COMPTABLE ....... 90
SECTION 1 : LE BESOIN D’ASSISTANCE ET LA VALEUR AJOUTÉE DE L’EXPERT COMPTABLE .......................................................................... 90
Paragraphe 1 : Les acteurs du projet et le besoin d’assistance ....................................................................................................... 90
1.
Acteurs du projet et compétences requises ............................................................................................................................................ 90
1.1.
Le comité de pilotage .................................................................................................................................................................... 91
1.2.
Le chef de projet ........................................................................................................................................................................... 91
1.3.
Le PMO (Project Management Office) .......................................................................................................................................... 92
1.4.
Les acteurs opérationnels ............................................................................................................................................................. 92
1.4.1.
Les acteurs internes ................................................................................................................................................................ 92
1.4.1.1. Les équipes métiers (Key-users) ...................................................................................................................................... 92
1.4.1.2. Les équipes techniques et informatiques ......................................................................................................................... 93
1.4.2.
Les acteurs externes ............................................................................................................................................................... 93
1.4.2.1. L’éditeur ............................................................................................................................................................................ 93
1.4.2.2. L’intégrateur ...................................................................................................................................................................... 93
1.5.
les utilisateurs finaux ..................................................................................................................................................................... 94
2.
Le besoin d’assistance par des consultants externes ............................................................................................................................. 94
2.1.
Les raisons générales pour engager un consultant ...................................................................................................................... 94
2.2.
Les raisons de recours aux consultants dans les projets de changement de système d’information : ........................................ 95
2.2.1.
L’indisponibilité des ressources internes ................................................................................................................................. 95
2.2.2.
L’insuffisance ou la non compétence des ressources internes : ............................................................................................. 96
Paragraphe 2 : Valeur ajoutée de l’expert comptable et cadre d’intervention .................................................................................. 96
1.
Le marché des consultants et avantages comparatifs de l’expert-comptable ......................................................................................... 96
1.1.
Le marché du conseil en système d’information ........................................................................................................................... 97
1.2.
Les avantages comparatifs de l’expert comptable ........................................................................................................................ 99
Page 181
Table des matières
2.
Cadre de l'intervention de l'expert-comptable ....................................................................................................................................... 102
2.1.
Recommandations de l’IFAC en matière de formation ............................................................................................................... 102
2.2.
Responsabilités de l’expert comptable dans les missions de conseil en système d’information ............................................... 106
2.2.1.
La responsabilité civile .......................................................................................................................................................... 106
2.2.2.
La responsabilité pénale ........................................................................................................................................................ 107
2.2.3.
La responsabilité disciplinaire................................................................................................................................................ 107
2.3.
Démarche dans les missions de conseil aux entreprises ........................................................................................................... 107
2.3.1.
L’entrée en contact et le contrat ............................................................................................................................................ 108
2.3.2.
Le diagnostic.......................................................................................................................................................................... 108
2.3.3.
Le plan d’actions .................................................................................................................................................................... 109
2.3.4.
La mise en œuvre .................................................................................................................................................................. 109
2.3.5.
La conclusion de la mission ................................................................................................................................................... 109
SECTION 2 : DOMAINES D’INTERVENTION DE L’EXPERT COMPTABLE DANS LE PROJET ............................................................................... 109
Paragraphe 1 : Assistance dans le choix de la solution ................................................................................................................. 110
1.
2.
3.
4.
Assistance dans la construction du schéma directeur informatique ...................................................................................................... 110
Assistance dans la rédaction du cahier des charges ............................................................................................................................ 112
Assistance dans l’évaluation des offres ................................................................................................................................................. 113
Assistance dans l’établissement des contrats avec l’éditeur ................................................................................................................. 114
1.
2.
Présentation des activités du pilotage ................................................................................................................................................... 114
Démarche d’assistance de l’expert comptable : .................................................................................................................................... 115
Paragraphe 2 : Assistance dans le pilotage global du projet de mise en place ............................................................................. 114
Paragraphe 3 : Assistance dans la réalisation et l’homologation de la solution ............................................................................. 118
1.
Assistance dans les activités de paramétrage ...................................................................................................................................... 118
1.1.
les travaux d’analyse et de conception ....................................................................................................................................... 118
1.1.1.
Elaboration des processus cibles à mettre en place ............................................................................................................. 118
1.1.2.
Elaboration des processus de la phase transitoire ................................................................................................................ 119
1.1.3.
Elaboration du nouveau plan de comptes ............................................................................................................................. 119
1.1.4.
Elaboration/Formalisation des schémas comptables cibles .................................................................................................. 120
1.1.5.
Elaboration des fiches de produits et services ...................................................................................................................... 120
1.1.6.
Définition de la matrice opération-comptes ........................................................................................................................... 120
1.1.7.
Définition des profils et habilitations des utilisateurs ............................................................................................................. 121
1.2.
La réalisation des tests unitaires................................................................................................................................................. 121
2.
Assistance dans les activités de développement .................................................................................................................................. 121
2.1.
Spécifications des éditiques et reportings .................................................................................................................................. 121
2.2.
Spécifications des écarts fonctionnels ou « Gaps » ................................................................................................................... 122
2.3.
Spécifications des programmes d’interface ................................................................................................................................ 123
3.
Assistance dans les activités d’homologation ....................................................................................................................................... 123
3.1.
Définition du plan de tests ........................................................................................................................................................... 123
3.2.
Rédaction des scénarios de recette et détermination des cas de tests ..................................................................................... 124
3.3.
Réalisation des tests ................................................................................................................................................................... 124
3.4.
Gestion des anomalies ............................................................................................................................................................... 124
Paragraphe 4 : Assistance dans la conduite du changement ........................................................................................................ 125
1.
Assistance dans les actions de communication .................................................................................................................................... 125
1.1.
Elaboration du plan de communication ....................................................................................................................................... 125
1.2.
Assistance dans la réalisation des actions de communication ................................................................................................... 126
2.
Assistance dans les actions de formation ............................................................................................................................................. 126
2.1.
Elaboration du plan de formation ................................................................................................................................................ 126
2.2.
Réalisation des supports de formation........................................................................................................................................ 126
2.3.
Animation des sessions de formation ......................................................................................................................................... 127
3.
Assistance dans les actions de support et d’accompagnement ............................................................................................................ 127
3.1.
Support sur site ........................................................................................................................................................................... 127
3.2.
Support à distance ...................................................................................................................................................................... 127
Paragraphe 5 : Assistance dans la migration des données ........................................................................................................... 128
CHAPITRE 2 : GUIDE MÉTHODOLOGIQUE D’ASSISTANCE DANS LA MIGRATION DES DONNÉES ........................................... 129
SECTION 1 : PROPOSITION D’ASSISTANCE ET ACCEPTATION DE LA MISSION .............................................................................................. 129
Paragraphe 1 : La proposition d’assistance ................................................................................................................................... 130
1.
2.
3.
Le diagnostic préliminaire ...................................................................................................................................................................... 130
La planification préliminaire : la stratégie d’intervention ou le plan de mission ..................................................................................... 130
La proposition de mission : .................................................................................................................................................................... 132
1.
2.
Condition générales d’exécution de services ........................................................................................................................................ 133
Contrat d’application .............................................................................................................................................................................. 135
Paragraphe 2 : la convention d’assistance..................................................................................................................................... 133
Page 182
Table des matières
SECTION 2 : CONDUITE DE LA MISSION D’ASSISTANCE ............................................................................................................................. 136
Paragraphe 1 : Le diagnostic ......................................................................................................................................................... 136
1.
2.
3.
4.
5.
Identifier et comprendre le problème ..................................................................................................................................................... 137
Déterminer les données qui doivent être recueillies pour étudier le problème...................................................................................... 137
Déterminer les sources des données : .................................................................................................................................................. 138
Décider la méthode de collecte des données : ...................................................................................................................................... 138
Analyser et tirer des conclusions des données recueillies : .................................................................................................................. 138
1.
2.
Définition de la stratégie de bascule par module fonctionnel ................................................................................................................ 139
Définition du plan de comptes et de la matrice de correspondance ...................................................................................................... 143
2.1.
Elaboration du nouveau plan comptable .................................................................................................................................... 143
2.1.1.
Nécessité du changement ..................................................................................................................................................... 143
2.1.2.
Préalable et éléments à prendre en considération ................................................................................................................ 143
2.1.3.
Livrables de l’expert comptable ............................................................................................................................................. 145
2.2.
Elaboration de la matrice de correspondance ............................................................................................................................ 146
Définition des informations à migrer et des règles de migration ........................................................................................................... 147
3.1.
Détermination des informations à migrer pour chaque module .................................................................................................. 147
3.2.
Détermination des règles de migration pour chaque type d’information .................................................................................... 149
3.3.
Pilotage des travaux de « mapping » entre les applications source et le système cible ............................................................ 151
Fiabilisation des données du système source ....................................................................................................................................... 152
4.1.
Détermination du périmètre des informations à fiabiliser............................................................................................................ 152
4.2.
Pilotage des travaux de fiabilisation............................................................................................................................................ 153
4.3.
Assistance dans la fiabilisation des données ............................................................................................................................. 153
Définition des contrôles pour la validation de la bascule ....................................................................................................................... 155
Elaboration du plan de bascule ............................................................................................................................................................. 157
Contrôle des simulations de migration................................................................................................................................................... 158
Paragraphe 2 : Préparation de la migration ................................................................................................................................... 138
3.
4.
5.
6.
7.
Paragraphe 3 : Mise en œuvre et recette définitive ....................................................................................................................... 159
1.
Le fonctionnement en configuration transitoire ...................................................................................................................................... 159
1.1.
La bascule du noyau comptable et du référentiel client : ........................................................................................................... 159
1.2.
L’alimentation quotidienne du noyau central : ............................................................................................................................ 160
1.3.
La bascule des agences pilotes .................................................................................................................................................. 160
1.4.
La bascule progressive du reste de réseau des agences .......................................................................................................... 161
2.
Le fonctionnement en configuration cible : ............................................................................................................................................ 161
3.
Application pratique au module crédit.................................................................................................................................................... 162
3.1.
Diagnostic : ................................................................................................................................................................................. 162
3.2.
Stratégie de bascule du module ................................................................................................................................................. 162
3.3.
Définition des informations à migrer et des règles de migration ................................................................................................. 163
3.3.1.
Détermination des informations à migrer............................................................................................................................... 163
3.3.2.
Définition des règles de migration ......................................................................................................................................... 163
3.3.3.
Définition des schémas de bascule ....................................................................................................................................... 164
3.4.
Fiabilisation des données ........................................................................................................................................................... 167
3.5.
Définition des outils de contrôle .................................................................................................................................................. 167
3.6.
Plan bascule................................................................................................................................................................................ 168
3.7.
Simulation de migration .............................................................................................................................................................. 168
3.8.
Bascules réelles .......................................................................................................................................................................... 168
CONCLUSION GÉNÉRALE .................................................................................................................................................................... 169
BIBLIOGRAPHIE .................................................................................................................................................................................... 171
ANNEXES................................................................................................................................................................................................ 175
TABLE DES MATIÈRES ......................................................................................................................................................................... 179
Page 183

MISE EN PLACE D`UN « GLOBAL BANKING » : CONDUITE DU

Transcription

Documents pareils

Télécharger

Formation - Créative Virginie

CURRICULUM VITAE

CPESI / EIA

Curriculum Vitae - IAE - Université de Franche

Plaquette ATHENEO ERP

Téléchargez l`édition N°192

référentiel du BTS Comptabilité et Gestion

Christiane Logie LES BUTS D`UN MUSEE DE BANQUE CENTRALE

LF103 de décembre 2013 - Didier Maurin Finance

Affectations des inspecteur stagiaires du Trésor public - FO