Conduire un appel d’offres pour la mise en œuvre d’un système d’information

Conduire un appel d’offres pour la
mise en œuvre d’un système
d’information
1
Philippe DORNBUSCH
Manager du service Projets RH et de la Mission Handicap à la
DRH du Crédit Agricole IDF
Fondateur de l’entreprise Echecs & Stratégie

Le tour de table des participants à cette formation
2

3
Tu me dis, j’oublie
Tu m’enseignes, je me souviens
Tu m’impliques, j’apprends
Benjamin Franklin, (1706-1790), écrivain, inventeur et homme politique américain
L’importance de la mise en pratique pendant cette formation

Organisation pratique de cette journée 1
9h-9h30 Accueil des participants et tour de table
9h30 - 10h30 Introduction - Définition d’un appel d’offres
10h30 – 11h Pause
4
13h30 - 15h Des exemples d’appels d’offres
11h00 - 12h30 Les enjeux d’un appel d’offres
12h30 - 13h30 Pause Déjeuner
15h00 - 15h30 Pause
15h30 - 17h L’organisation recommandée

9h -10h30 La phase initialisation d’un projet (INITIATE)
10h30 - 11h Pause
5
13h30 - 15h Les principaux facteurs de risque
11h00 - 12h30 La phase définition du projet (DEFINE)
15h00 - 15h30 Pause
15h30 - 17h Exercice pratique

9h - 10h30 Etude de cas pratiques
10h30 - 11h00 Pause
6
13h30 - 15h00 Etude de cas pratiques
11h - 12h30 Etude de cas pratiques
15h00 - 15h30 Pause
15h30 - 16h30 Quiz individuel noté (10 questions)
16h30 - 17h Correction du Quiz et Conclusion de la formation

Conduire un appel d’offres pour la mise en œuvre d’un système d’information 7
Introduction
Des statistiques portant sur environ 10 000 projets SI (acronyme de Système
d’Information) à travers le monde indiquent que :
 29% des projets atteignent leurs objectifs,
 18% sont abandonnés,
 53% sont en deçà de leurs objectifs
De tels résultats sont révélateurs de difficultés structurelles, propres aux
projets de nature « SI », qu’il est important d’expliciter pour comprendre les
racines des bonnes pratiques de la gestion de projet SI, puis les mettre en
œuvre :
Difficultés à stabiliser les spécifications et le périmètre d’un projet
Complexité du processus de gestion de projet SI
Difficultés liées aux activités sous-traitées.

Introduction
La définition (ou « spécification ») d’un composant de SI n’est pas une science
exacte : Chaque nouveau projet est un « prototype », une « pièce unique »,
que ni les collaborateurs SI, ni les acteurs métier n’ont encore expérimenté.
En particulier, le projet de SI souhaité par le métier correspond généralement à
une transformation de ses processus. Il lui est donc très difficile de décrire avec
précision toutes les règles de gestion correspondant à un futur mode de
fonctionnement qu’il ne connait pas encore très bien lui-même.
Or, en matière de SI, la précision est particulièrement critique (« le diable est
dans les détails ») : la découverte tardive d’un oubli ou d’une imprécision de
spécification peuvent avoir des impacts très importants sur les coûts et les
délais.

Introduction
De surcroît, le nouveau composant de SI doit s’insérer dans un existant,
généralement complexe, d’où des problématiques d’interfaçages, de reprise
de données anciennes, de coordination de multiples acteurs.
Chacune de ces contraintes porte un risque de contretemps tardif, qu’il est très
difficile d’anticiper de façon exhaustive.
Enfin, le poids du facteur humain est très important :
 les spécifications d’un SI ne peuvent se mettre en équations, et restent le
fruit d’un travail d’échange, de communication et de formulation, également
porteur de risques d’imprécisions ou de malentendus,
 le projet ayant le plus souvent pour objectif d’améliorer un processus métier,
les collaborateurs impliqués, tant Métier que SI, sont tentés de vouloir
résoudre à cette occasion tous les problèmes du passé. Cette louable
motivation peut engendrer une expansion excessive du projet.

Introduction
C’est pourquoi, la qualité des études avant projet, du cadrage et du dossier de
lancement de projet qui aboutira sur le lancement d’un appel d’offres est
essentielle pour que le projet démarre sur des bases claires.
Un grand nombre d’ambiguïtés peuvent ainsi être éliminées au plus tôt.
Des objectifs de projets bien cadrés facilitent également la définition des
priorités et les arbitrages à prendre par la suite.
Enfin, cela permet d’éviter de mal choisir son fournisseur et d’établir une base
commune la plus précise possible de la cible vers laquelle le client et le
fournisseur souhaitent converger.
L’objectif de ce cours est d’expliciter le processus d’appel d’offres que va
conduire une société (donc du point de vue du client) afin de créer une relation
avec un fournisseur afin d’arriver à la construction commune d’un S.I.

Introduction
Après avoir passé en revue les enjeux d’un appel d’offres tant du point de vue
du vendeur que de l’acheteur, nous verrons en détail la structure
organisationnelle à mettre en œuvre pour conduire cet appel d’offres, puis les
instances de gouvernance permettant de piloter cet appel d’offres et de
prendre les décisions de lancement de projet ou d’arbitrages inhérentes à tout
projet.
Par la suite, nous identifierons l’ensemble des rôles et responsabilités qui
doivent être couverts par les différentes parties prenantes de l’appel d’offres.
Enfin nous détaillerons l’ensemble des actions à mener et des livrables à
produire pour arriver à la phase de contractualisation entre le client et son
fournisseur, dernière étape avant la mise en œuvre du projet.

Episode 1: Appel d’Offres - Pourquoi s'intéresser aux marchés publics?
Le lien vers la vidéo
L’Histoire d’Edgar en 8 épisodes

Episode 2: Par où commencer?

Episode 3: Cibler un appel d'offres

Episode 4: Les documents de la consultation

Episode 5: Le processus de réponse à un marché public

Episode 6: Quelques conseils de rédaction

Episode 7: Le dépôt électronique

Episode 8: Et maintenant le dénouement !

LES ENJEUX D’UN APPEL D’OFFRES
2.1 DEFINITION
Un appel d'offres est une procédure qui permet à un commanditaire (le client),
de faire le choix de l'entreprise (le soumissionnaire qui deviendra le
fournisseur) la plus à même de réaliser une prestation de travaux, fournitures
ou services à partir de critères de choix que le client aura défini. Le but est,
entre autre, de mettre plusieurs entreprises en concurrence pour fournir un
produit ou un service.
2.2 LES ENJEUX POUR LE VENDEUR
L’appel d’offres se traduit d’abord par une entrée de commandes potentielles.
Certaines entreprises ne vendent qu’en répondant à des appels d’offres.
C’est le cas de celles qui n’œuvrent qu’en rapport avec les administrations. A
titre d’exemple, citons les équipements pour hôpitaux, les fournisseurs
d’équipements et de systèmes pour les ministères (défense …), etc.

LES ENJEUX POUR LE VENDEUR
Les entreprises autres que celles ne visant que les marchés publics, sont
confrontées régulièrement à des appels d’offres émis par des organisations
privées.
Répondre à un appel d’offres impose de monopoliser une équipe, qui peut
compter jusqu’à plusieurs dizaines de personnes pendant plusieurs mois. C’est
particulièrement le cas lorsque la prestation qu’il s’agit de proposer est
complexe, par exemple lorsqu’elle concerne la fourniture de systèmes
technologiques élaborés (Informatique, électronique, télécommunications,
nucléaire, etc.).
Ainsi vers les années 2000, le gouvernement français, via l’Agence de
Régulation des Télécoms (ART), a lancé un appel d’offres portant sur
l’attribution de licences UMTS, indispensables aux opérateurs télécoms pour
fournir des services internet mobiles. L’importance du marché était telle que,
pour y répondre, certains opérateurs candidats ont constitué des équipes de
plusieurs dizaines de personnes, s’appuyant elles-mêmes sur plusieurs
centaines d’experts, internes et externes

Par exemple, un constructeur télécom scandinave, appelons le Erickia, a
monopolisé une équipe d’une cinquantaine de personnes pour soutenir un
opérateur qui, lui-même, mobilisait en interne un nombre équivalent
d’employés. Dans ce projet, plusieurs dizaines d’entreprises extérieures
soutinrent d’ailleurs l’opérateur : six fournisseurs d’équipements en
télécommunication en plus d’Erickia, environ autant d’entreprises de conseil
marketing, sans compter les SSII. Soulignons que quelques unes de ces
entreprises travaillaient à fonds perdus : elles ne facturèrent pas leurs services,
espérant un positionnement préférentiel à l’issue de la procédure, récompense
de leur soutien à l’opérateur…
Le calcul semblera à première vue audacieux. Cependant, nous rappellerons
que le relationnel, la confiance notamment, est un facteur indispensable pour
se démarquer de ses concurrents. L’ensemble de ces personnels, internes et
externes, travaillèrent sur le dossier environ neuf mois.

A cela, il faut ajouter que, pour se préparer au cas où ils obtiendraient une
licence d’exploitation de réseaux de télécommunications, certains opérateurs
ont investi une dizaine de milliards d’euros uniquement pour les équipements
opérationnels. Et cependant, pour ce type de projets, les coûts d’avant-vente
pour chaque fournisseur, dont l’opérateur, ne représentaient que 5% du chiffre
d’affaires attendu.
Est-ce à dire que les enjeux financiers des appels d’offres sont tels que ce type
de démarche ne concerne que les grandes entreprises ?
Non ! Même si, sur des petites opérations, par exemple, une commande de
quelques milliers d’euros, le coût commercial de la réponse peut, en effet,
grever la marge bénéficiaire de l’offrant, parce qu’elle nécessite un à deux jours
de travail en avant-vente : Une demi-journée pour rencontrer le client
potentiel, autant pour répondre à l’offre, plus une demi-journée encore pour
négocier etc…

Dans le contexte de « petites offres », l’enjeu financier va donc autant consister
à diminuer les coûts de réalisation de l’offre, qu’à employer des méthodes pour
augmenter ses chances de gagner.
Ainsi les PME, sont elles aussi concernées, à condition de rester conscientes
d’un autre enjeu financier, fondamental pour les entreprises vendeuses :
limiter les coûts des propositions commerciales. Les coûts commerciaux
(salaires, charges directes et indirectes…) peuvent représenter jusqu’à 20% du
chiffre d’affaire potentiel de l’opération.
Pour l’entreprise qui répond à des appels d’offres, l’enjeu est aussi de défendre
son image. Dans la mesure où la réponse à l’appel d’offres a été
« intelligente », même si au final elle a été perdante, elle est susceptible de
positionner l’entreprise en position préférentielle sur des dossiers ultérieurs.

Une grande SSII française, appelons-la Sternum, eut vent d’un appel d’offres
portant sur la fourniture d’un SI de facturation. Les chances de gagner l’appel
d’offres étaient estimées à moins de 20 % compte tenu des éléments
rassemblés par l’entreprise : client mal connu, concurrence mieux placée sur ce
type d’appel d’offres. En toute logique économique, elle n’aurait pas du
répondre à l’appel d’offres. Toutefois, le client visé, appelons-le Safrum, était
jugé stratégique par Sternum.
La stratégie de Sternum a consisté à s’associer avec un éditeur de logiciels pour
fournir les briques technologiques de base du système de facturation. Dans ce
contexte, la valeur ajoutée de l’entreprise consistait à assurer l’intégration du
logiciel de facturation du partenaire éditeur avec les applications existantes
chez Safrum. Son but était de se montrer comme un expert des méthodes
d’intégration, avec une connaissance pointue sur les différents types
d’interfaçages. Elle développa des efforts très importants pour transmettre
cette image dans la réponse à l’appel d’offres.
La stratégie fut payante … à terme.

Comme il était prévisible, Sternum ne remporta pas l’appel d’offres, des
concurrents ayant démontré une connaissance supérieure des systèmes de
facturation. Toutefois conformément à ce qui était visé, l’entreprise fit une
forte impression quant à ses méthodes et outils d’interfaçages.
Cette image lui a permis de recevoir une nouvelle consultation quelques mois
après, où il était question de conseil pur sur de l’interconnexion de systèmes.
La réponse fut cette fois gagnante.
Cette première référence, inférieure à 50 000€, a donné lieu à bien d’autres
contrats, pour des montants de plusieurs dizaines de millions d’euros sur les
trois premières années. Après 5 ans, Sternum était la SSII la mieux implantée
chez Safrum.

2.3 LES ENJEUX POUR L’ACHETEUR
Emettre des appels d’offres donne à l’entreprise un avantage évident : il s’agit
de faire jouer la concurrence. Pour autant la démarche n’est pas sans receler
des écueils particuliers notamment en termes financiers. Le premier consiste à
ne considérer que la dernière ligne de la réponse : le tarif…Or faire le meilleur
choix ne signifie pas nécessairement acheter le moins cher. Nombre de
commerciaux pensent que les acheteurs sont obsédés uniquement par la
baisse des coûts. C’est, bien entendu, une attente. Encore faut-il la moduler en
fonction du type d’achat.
Lorsqu’une entreprise achète des biens ou services standard, avec peu de
valeurs de différenciation (cartons d’archives, stylos, services d’entretien etc.),
alors il est vrai que les acheteurs ne se concentrent que sur les prix. Autre
exemple, ils estiment que le service de ménage offert par la société A ou B sera
sensiblement le même, à tort ou à raison. Ils estiment que l’enjeu de l’achat
pour l’entreprise est insignifiant. Dès lors que l’enjeu est faible, les acheteurs se
focaliseront essentiellement sur le prix.

2.3 LES ENJEUX POUR L’ACHETEUR
Mais prenons un contre-exemple : une entreprise fournit des joints dans des
matériaux spécifiques pour les moteurs de fusée Ariane. Le montant de ces
joints ne pèse rien dans le prix total des moteurs. Pourtant, l’entreprise
acheteuse, au travers de ses techniciens ou de ses acheteurs selon
l’organisation, portera un regard fin sur la qualité des joints proposés, parce
que ce sont des pièces critiques pour le bon fonctionnement du moteur et la
négociation sur leur prix sera relayée à un second plan.
Dans le même ordre de criticité, vous pourrez constater que le prix des vannes
d’un pipeline pétrolier est très élevé au regard du coûts de revient de ces
éléments. L’entreprise acheteuse ne peut pas se permettre une fuite sur une
de ces vannes, l’enjeu se portera donc dans ce contexte, davantage sur la
qualité des fournitures que sur leur prix.
Cela dit les acheteurs et les vendeurs partagent un objectif d’importance :
réduire les coûts de consultation au plus bas.

POINTS CLES A RETENIR
 Pour le vendeur, l’appel d’offres peut représenter un important
investissement en temps et en moyen financier.
 Mais c’est aussi un moyen pour lui de conquérir des clients ou de se faire
connaître par eux au cas où une nouvelle opportunité venait à surgir.
 Pour l’acheteur, le choix du prestataire va dépendre de l’objet de l’appel
d’offres. Plus la solution est complexe, plus le nombre de critères sera
important. A l’inverse, plus l’objet de la consultation est simple, plus le facteur
coût sera important.
 Pour l’acheteur et le vendeur, l’intérêt commun est que la consultation coûte
le moins chère possible aux 2 parties.

Mise en œuvre d'une solution de GED et d'archivage pour le domaine RH en mode SaaS.
Description succincte:
Le Centre de services partagés RH (CSRH), prend en charge la gestion administrative de
la formation, la Gestion administrative (GA), la Gestion des temps et des activités (GTA),
la Gestion administrative des carrières (GAC) ainsi que la paye des salariés d’une partie
des départements de l’EPIC RATP. Sa mise en œuvre répond à une double logique de
mutualisation des coûts et d’amélioration de la qualité de service.
Une exemple d’appel d’Offres: GED et archivage RH pour la SNCF
Le lien vers l’appel d’Offres

Une exemple d’appel d’Offres: GED et archivage RH pour la SNCF
L'efficience de la fonction RH et de la
fonction managériale ainsi que
l'élargissement du mode CSP nécessitent
de développer la digitalisation des
processus afin de diminuer les tâches à
faible valeur ajoutée tel que le classement
des pièces, et de gagner en fiabilité,
instantanéité, fluidité et rapidité d'accès.
Il est attendu de la solution cible qu’elle
puisse permettre le stockage dématérialisé
des dossiers du personnel (Dossiers
administratifs – DA – on parlera de «GED
DA»), et qu’elle permette de stocker des
récapitulatifs de situation RH (on parlera de
«GED RH»).

Une exemple d’appel d’Offres: IA pour l’INPI (INST NAT DE LA PROPRIETE INDUSTRIELLE)
Le lien vers l’appel d’Offres
Création d'une plateforme utilisant
l'intelligence artificielle pour optimiser le
classement par proximité sémantique des
brevets
Description succincte :
Identification d'un partenaire capable de
créer, d'industrialiser et d'assurer la
maintenance d'une plateforme utilisant
l'intelligence artificielle pour optimiser le
classement par proximité sémantique des
brevets et leur visualisation sous forme de
cartes très détaillées

LES PARTIES PRENANTES AU SEIN DE L’ENTREPRISE
Dans un tout premier temps et avant même de lancer un appel d’offres SI, il
faut que les parties prenantes dans la mise en œuvre du SI au sein de
l’entreprise se rencontrent et apprennent à travailler ensemble.
Les projets SI (dont l’appel d’offres est une des étapes, c’est ce que nous
verrons plus tard), et plus généralement l’ensemble du Système d’Information,
résultent en effet d’une co-construction, d’un travail de partenariat entre
Métier et SI.
Chaque «discipline» y apporte son savoir faire et porte les responsabilités
associées

3.1 METIERS
Les « métiers » sont les commanditaires et bénéficiaires des Systèmes
d’Information.
Le terme « métier » désigne une compétence ou spécialité fonctionnelle, ou
encore « discipline » (ex : comptabilité, marketing, ressources humaines,
acheminement, contrôle de gestion, direction générale...), indépendamment
de toute notion d’organisation ou de structure.
Le « métier » assure la maîtrise d’ouvrage du SI dont il est bénéficiaire : -
expression des nouveaux besoins métier et de leur justification, - validation
métier des solutions SI proposées, - financement des solutions SI, - recettes de
conformité (tests) des solutions livrées.
Le métier est garant de la bonne articulation du SI au sein de ses processus
métier et de son organisation : - évolution et adaptation des organisations et
procédures, - accompagnement du changement associé à une nouvelle
solution SI, - suivi de la performance des processus métier.

3.2 FONCTION SI
La « fonction SI » vient en support des métiers de l’entreprise, elle est en
charge :
-d’assurer le maintien en conditions opérationnelles (MCO) conformément aux
niveaux de services convenus avec les métiers (continuité, sécurité, qualité …),
-de proposer, concevoir et mettre en œuvre les évolutions du SI en fonction
des besoins:
- d’alignement du SI par rapport aux évolutions stratégiques des métiers
- d’amélioration des processus, d’évolution des organisations, d’évolutions
réglementaires,
- d’évolutions technologiques ou de rationalisation d’architecture du SI.
Elle est redevable des coûts, des délais, de la qualité, de l’évolutivité du SI sur
le périmètre dont elle a la charge. Elle est garante de la pertinence et de la
pérennité des choix technologiques

3.3 METHODOLOGIE DE GESTION DE PROJET
La « fonction SI » vient en support des métiers de l’entreprise, elle est en
charge :
- d’assurer le maintien en conditions opérationnelles (MCO) conformément aux
niveaux de services convenus avec les métiers (continuité, sécurité, qualité …),
- de proposer, concevoir et mettre en œuvre les évolutions du SI en fonction
des besoins:
- d’alignement du SI par rapport aux évolutions stratégiques des métiers
- d’amélioration des processus, d’évolution des organisations, d’évolutions
réglementaires,
- d’évolutions technologiques ou de rationalisation d’architecture du SI.
Elle est redevable des coûts, des délais, de la qualité, de l’évolutivité du SI sur
le périmètre dont elle a la charge. Elle est garante de la pertinence et de la
pérennité des choix technologiques

- Est composé de deux premières phases permettant de cadrer le projet
• Phase INITIATE : Cadrage du besoin métier et étude d’opportunité ;
identification des pistes de solution à instruire en phase suivante
• Phase DEFINE : Identification de la solution et de la démarche retenue pour
le projet.
Chiffrages et décision de lancement du projet (<< GO >> ou « NO GO »).

Le projet proprement dit démarre à l’issue de la phase DEFINE qui est composé :
• Phase DESIGN : Conception générale du système
• Phase BUILD : Construction de la solution SI et préparation de la recette et du
déploiement
• Phase TEST : Tests et recette Métier
• Phase DEPLOY : Mise en service du système et accompagnement du démarrage.
Passage en mode récurrent (Mode « Run »)
- Phase CLOSE : bilan de projet post démarrage
- Est composé d’Activités récurrentes transverses de gestion de projet (Planning,
Budget, Risques, Ressources, Communication…)

3.3.2 Variantes du processus « Classique »
Le phasage « classique » donne lieu à des variantes adaptées à certains types
de projets (petits projets, ou projets d’infrastructure IT) ou à des façons de
travailler (sur base de progiciel, ou avec des outils ou technologies permettant
des livraisons itératives).
3.3.3 Définition et périmètre d’un projet S.I
Un projet de « Systèmes d’Information » a toujours pour finalité de permettre
la réalisation d’un objectif « Métier ».
Cas particuliers : Un projet SI peut s’inscrire dans le cadre d’un programme
métier plus vaste. Exemple : un programme de refonte de la relation clientèle
via la mise en place de plateformes de télé conseillers peut impliquer des
chantiers de nature RH (recrutements, formations…), immobilier et un chantier
de définition et outillage des divers processus d’interaction entre le client et le
télé conseiller. Seul ce dernier chantier est, par définition, un projet de
Système d’Information. Le présent document n’aborde pas les autres natures
de projets.

Dans le cas des projets de nature purement technique (ex : changement
d’exploitant), le commanditaire / sponsor est généralement une direction
générale et le rôle de représentant du commanditaire est confié à un manager SI.
Le « livrable » final d’un projet SI est constitué :
 d’une application (ou « un composant de SI »),
 accompagnée de sa documentation (documentation technique ainsi que
documentation utilisateurs),
 mise en service, et dont les utilisateurs et les exploitants sont formés aux
nouveaux processus et modes opératoires associés au Système.

3.3.4 Focus sur la phase d’avant-projet
L’objet de ce cours est de détailler la phase d’avant projet, qui démarre à partir
de la phase INITIATE et qui se finalise par la fin de la phase DEFINE.
Nous étudierons l’ensemble des étapes constituant ces 2 phases ainsi que
l’organisation supportant la mise en œuvre de l’ensemble de ces 2 phases.
Le contenu de ce cours s’arrête une fois que le contrat entre le Client et le
Fournisseur est signé : on passe dans la mise en œuvre proprement dite du
Projet.

 Le métier est responsable du « quoi » (du besoin),
 Le SI est responsable du « comment » (des solutions).
Les phases DEFINE et INITIATE qui constitue la méthodologie de gestion de
projet sont l’objet de ce cours. C’est à l’issue de ces phases que l’on va
déterminer la solution et la démarche retenue pour le projet.

Organisation recommandée pour conduire un appel d’offres
4.1 L’EQUIPE PROJET A DEFINIR POUR CONDUIRE UN APPEL D’OFFRES
Tout projet a pour définition d’avoir une durée de vie limitée et nécessite donc
une organisation humaine dédiée à ce projet (Ad hoc)
Il est à noter que l’organisation de projet :
• est temporaire pour la durée de vie du projet,
• définit des rôles et responsabilités dans le projet indépendamment de
l’organisation hiérarchique structurelle :
 une même personne peut tenir plusieurs rôles dans un même projet (ou
dans plusieurs),
 la « hiérarchie » du projet peut être à l’inverse de l’organisation
hiérarchique structurelle, un même rôle peut être tenu pour un projet par
une personne de la DSI et pour un autre projet par une personne d’une
Direction fonctionnelle, ou encore par une personne externe.

L’équipe projet à définir pour conduire un appel d’offres
Nous proposons ci-dessous une organisation générique. Il est bien évident
qu’elle dépend du type de projet (cf chapitre suivant) et de la culture
d’entreprise.

Rôles et responsabilités des membres de l’équipe projet
Le Sponsor
• Est un membre de le Direction Générale.
• Représente l’ensemble des clients internes du projet (le métier)
• S’assure de l’alignement du projet avec la stratégie de l’entreprise.
• Légitime au sein de la Direction Générale les moyens nécessaires au projet
(budget, ressources humaines dédiées au projet, mobilisation des Directions
fonctionnelles…).
• Participe au Comité de Projet

Le(s) Bénéficiaire(s) du projet
• Sont des représentants des intérêts des utilisateurs finaux du futur système.
• Au travers, notamment, de leur participation au Comité de Projet, ils ont
pour rôles de :
o Remonter les besoins des utilisateurs et s’assurer que le futur système y
répondra.
o Identifier les utilisateurs à même de participer à certains Ateliers
(Expression de besoins puis au cours du projet : spécifications
fonctionnelles, recette…),
o dégager la disponibilité nécessaire de ces utilisateurs et prendre les
mesures nécessaires pour garantir la poursuite des opérations courantes
malgré leur affectation au projet.
o Arbitrer entre les demandes des utilisateurs.
o Evaluer l’atteinte des résultats du projet et en faire part au Sponsor.

Le Directeur du Projet
• Est un Directeur fonctionnel (ou Métier) de l’entreprise ou l’un de ses
adjoints.
• Est le propriétaire du « business case » du projet : définit la raison d’être et
les objectifs du projet, les grandes lignes des besoins et justifie le rapport coût
/ bénéfice du projet.
• Définit et demande à la Direction Générale les moyens nécessaires au projet
(budget, ressources humaines dédiées au projet, mobilisation des Directions
fonctionnelles…).
• Est responsable du budget du projet et en contrôle l’utilisation, notamment
en cas de variation de périmètre.
• Vérifie l’atteinte des objectifs du projet.
• Préside le Comité de Projet et rend les arbitrages nécessaires.
• Rend compte à la Direction Générale de l’avancement du projet et de la
tenue de ses objectifs.
• S’appuie sur le Chef du Projet pour gérer l’opérationnel du projet.

Le(s) Référents(s) Fonctionnel(s) et/ou Technique(s) du projet
• Sont des représentant de haut niveau des « fournisseurs » internes et
externes du Projet.
• Au travers, notamment, de leur participation aux instances de gouvernance
du Projet, ils ont pour rôles de :
 Evaluer et confirmer la viabilité du projet.
 Donner tout conseil utile au bon déroulement du projet.
 Identifier les ressources de leur structure à même de participer au
projet, dégager la disponibilité nécessaire de ces ressources et prendre les
mesures nécessaires pour garantir la poursuite des opérations courantes
malgré leur affectation au projet.
 Conseiller aux définitions fonctionnelles, évaluer les impacts techniques,
pour s’assurer que la (les) solution(s) proposée(s) est (sont) réaliste(s).
 Le cas échéant, participer à la validation de certains livrables.

Le Contrôle Méthode et Qualité
• Explicite, en tant que de besoin, la méthodologie de gestion de projet de
l’entreprise aux différents acteurs du projet et leur apporte un support
méthodologique.
• Vérifie et approuve le Plan Qualité Projet.
• Effectue une analyse des risques du projet et la remet à jour périodiquement.
• Vérifie le respect des procédures définies dans le Plan Qualité Projet et la
Méthodologie de gestion de projet de l’entreprise.
• Alerte le Chef du Projet et le Directeur de Projet en cas de non conformité.
• Apporte au projet son expérience des projets antérieurs et sa connaissance
générale du SI de l’entreprise.

L’intégration Sécurité
• Porté par le RSSI (Responsable Sécurité Systèmes d’Information).
• Lance le Risk Assessment avec l’instance « Comité de projet ».
• Aide au déroulement de la démarche Risk Assessment.
• Injecte les Best Practices de Risk Assessment à chaque étape majeure du
projet (a minima : initialisation, cadrage, cahier des charges).
• Valide le passage analyse simplifiée vers analyse détaillée.
• Vérifie la prise en compte des risques résiduels par les instances
décisionnaires du projet.

Le Chef du Projet
• Maîtrise les techniques de gestion de projet, dispose de compétences
fonctionnelles sur les sujets concernés et de toute la disponibilité nécessaire.
• Rédige le Document d’Initialisation du Projet. Ce document rappelle le «
business case » du projet, et en fixe le budget, les livrables, les bénéfices
attendus, les ressources, les risques acceptés et le planning.
• Gère l’opérationnel du projet avec la responsabilité de livrer le projet dans les
délais, les coûts, le résultat et la qualité attendue.
• Identifie les travaux à réaliser et les livrables à produire, les répartit entre
différents Ateliers. Les Ateliers correspondent à des sous-projets fonctionnels
et/ou à des travaux spécifiques à une phase du projet, par exemple :
 définition des processus métiers associés au futur système,
 contractualisation avec les fournisseurs externes, o spécifications
fonctionnelles (ou identification des écarts pour un progiciel),
 architecture technique, réalisation / paramétrage, recette (stratégie /
préparation / exécution), tests de charge
 mise en production, déploiement (études d’impact / formation / assistance
au démarrage), gestion du changement / communication sur le projet…

Le Chef du Projet
• Désigne un Chef de File à la tête de chaque Atelier, anime et coordonne ces
Chefs de File. L’ensemble des Ateliers à dominante informatique (« Ateliers SI »
par opposition aux « Ateliers Métier ») auront de préférence un Chef de File
unique issu de la DSI.
• S’assure de la disponibilité et de la mobilisation de toutes les ressources
nécessaires au projet (une même ressource pouvant participer à plusieurs
Ateliers et/ou n’être qu’à temps partiel sur le projet).
• Suit les réalisations, valide ou fait valider les livrables.
• Identifie les écarts, risques et problèmes rencontrés dans le déroulement du
projet, détermine des plans d’actions pour y remédier.
• Est responsable de la tenue et du déroulement des réunions nécessaires au
projet (réunions de travail, réunions de pilotage).
• Rend compte au Directeur du Projet et au Comité de Projet de l’avancement
du projet et des difficultés rencontrées.
• Soumet au Comité de Projet les points à arbitrer.

Le Responsable de domaine MOA ou DSI
• Fournit une expertise dans son domaine
• Coordonne l’expertise issue de différents chefs de file de son domaine
• Dans son domaine, suit les réalisations, valide ou fait valider les livrables.

Conduire un appel d’offre pour la mise en œuvre d’un système d’information 54
Le Support Projet
• Rédige et met à jour le Plan Qualité Projet en conformité avec la
Méthodologie de Gestion de Projet.
• Elabore et tient à jour le planning du projet, y enregistre les réalisations,
alerte le Chef du Projet en cas de dérive.
• Consolide les plans de charges des ressources affectées en tout ou partie au
projet, alerte le Chef du Projet en cas d’incompatibilités entre les charges et les
disponibilités.
• Gère la documentation du projet (élabore le plan de classement, classe les
documents dans les répertoires appropriés, gère le versioning …). Diffuse les
documents et les mises à jour aux acteurs concernés.
• Gère les livrables du projet (élabore le plan de classement, classe les livrables
dans les répertoires appropriés, gère le versioning …).

Le Support Projet
• Met à jour périodiquement un tableau de bord synthétique du projet.
• Organise et prépare les réunions de pilotage du projet, dont le Comité de
Projet (ordre du jour et autres documents préparatoires). En rédige les
comptes rendus.
• Administre les outils utilisés par le projet (exemple MS Project pour le suivi
de projet, Mantis pour le suivi des anomalies…).
• Passe les commandes aux fournisseurs externes, effectue les réceptions.
• Elabore le budget, en suit la consommation, alerte en cas de dérive

Le Chef de File
• Est un expert dans son domaine.
• Reçoit ses instructions du Chef du Projet et a pour responsabilité de produire
les livrables qui lui ont été attribués, dans les délais convenus.
• Organise et pilote à cette fin le travail de son équipe et des autres acteurs
(internes, fournisseurs…) impliqués dans la production des livrables de son
atelier.
• S’assure de la qualité et de la conformité des livrables.
• Rend compte au Chef du Projet de l’avancement de ses travaux, ainsi que de
la survenance de difficultés ou de risques. Propose des plans d’actions pour y
remédier.
• S’assure du respect du Plan Qualité Projet par son équipe et par les autres
acteurs impliqués dans la production des livrables de son Atelier.

INSTANCES DE PILOTAGE DU PROJET
Le projet doit se doter d’instances de pilotage : Ces instances doivent en
particulier servir pour arbitrer quand nécessaire, obtenir des ressources
complémentaires etc.
Ce sont ces instances qui prendront les décisions lors de choix décisifs pour la
bonne conduite de l’appel d’offres :
• Sélection du fournisseur retenu
• Calendrier de l’appel d’offres
• Définition du périmètre de l’appel d’offres
• Décision de GO/NO GO pour le projet

INSTANCES DE PILOTAGE DU PROJET
Si les propositions de gouvernance peuvent venir du chef de projet, leur mise
en place ne peut se faire sans le directeur du projet, seul autorisé à inviter des
dirigeants en comité de pilotage.
La gouvernance d'un projet recouvre l'ensemble des instances à mettre en
place pour assurer un bon pilotage du projet. En fonction de la taille du projet,
on aura une complexité de gouvernance croissante:
• Projet interne à un département
• Projet mono-entreprise local
• Projet mono-entreprise global
• Projet multi-entreprises
• Projets internationaux

4.3.1 Gouvernance des projets internes
Dans le cadre de ces projets, la gouvernance se réduit à peu de choses. La
participation à la réunion de service ou de département, parfois un simple
point d'avancement avec le sponsor du projet suffit. La seule nouveauté
consiste à créer une réunion de projet.
4.3.2 Gouvernance des projets mono-entreprise locaux
Le projet reste au sein de l'entreprise mais est transverse à plusieurs
départements. On commence ici à vraiment parler d'un projet digne de ce
nom. La gouvernance de ce type de projet impose à minima 2 instances :
• Une réunion de projet, pour coordonner les équipiers.
• Un comité de pilotage, pour coordonner les différents directeurs de
départements impactés par le projet.

4.3.3 Gouvernance des projets mono-entreprise globaux
Il se rajoute ici une dimension supplémentaire: la dimension géographique,
multi-sites. On commence à voir alors apparaître un niveau de gouvernance
supplémentaire : celui permettant d'impliquer les directions de sites et les
directeurs de fonction locaux, de manière générale les managers
intermédiaires (ceux n'étant pas dans le comité de pilotage mais impactés par
le projet). Pour gérer cette dernière dimension, pas de règles préétablies. Cela
dépend fortement de l'organisation de l'entreprise, du poids des acteurs locaux
etc.
4.3.4 Gouvernance des projets multi-entreprises
La configuration est la même que le cas précédent mais avec la prise en
compte des aspects contractuels ou de partenariats entre les différents
acteurs. On se retrouvera alors avec une instance supplémentaire : une revue
de contrats, une instance de gestion du partenariat etc.

4.3.5 Gouvernance des projets et programme internationaux
On cumule ici le plus souvent tous les facteurs de complexité :
• Plusieurs sociétés
• Plusieurs sites
• Plusieurs pays et cultures
• Plusieurs projets
Il faut donc des instances pour piloter les projets entre eux, pour piloter le
programme dans son ensemble, pour assurer la coordination avec les sites,
pour maîtriser les partenariats ou contrats. On arrive alors à une complexité
forte de la gouvernance.

Exemple d’instance de Pilotage pour des projets mono entreprise globaux

La réussite de la phase d’appel d’offres va dépendre d’une part
de la réalisation de tout un ensemble d’activités qui doivent être
affecté à des personnes identifiées au sein de l’entreprise.
 D’autre part, des instances de gouvernance doivent être définies dans
lesquelles seront abordées, selon l’instance, l’ensemble des sujets concernant
le projet en général et l’appel d’offres en particulier.

5 La phase d’initialisation d’un projet (INITIATE)
5.1 OBJECTIFS DE LA PHASE
A partir de l’expression d’un besoin métier, l’objectif de la phase INITIATE est de
fournir une première appréciation rapide de l’opportunité de la demande et
des pistes de solutions qu’il sera pertinent d’investiguer par la suite.
Pour ce faire, l’expression du besoin métier doit être précisée (ses enjeux,
résultats attendus, périmètre, …), et les grandes pistes de solution SI doivent
être identifiées, incluant un 1er ordre de grandeur de leurs coûts et délais.
Cette première approche des bénéfices attendus rapportés aux coûts et délais
de mise en œuvre peut éventuellement conduire à abandonner la demande.

5.2 ETAPE : CADRAGE DU PROJET
5.2.1 Objectifs de cette étape
L’objectif de cette étape est de produire par le chef de projet un premier niveau
d’éléments clé synthétiques permettant d’initier un projet. Ces éléments seront
obtenus à partir d’interview du commanditaire (en général le sponsor ou le directeur
de projet) par le chef de projet
A cette étape, les éléments à faire préciser par le commanditaire sont les suivants :
- Qui est le client ? A qui répond le besoin ?
- Quels sont les objectifs du projet ?
- Quel est le délai souhaité dans la réalisation du projet ?
- Y a t-il un budget et si oui quel est son ordre de grandeur ?
- A quoi sert le projet ?
- Quelle rentabilité est attendue ?
- Y a t-il un impact prévisionnel à prévoir suite à la mise en œuvre du projet ?
- Sur quels moyens humains au sein de l’entreprise va-t-on s’appuyer pour conduire
le projet ?

5.2 ETAPE : CADRAGE DU PROJET
5.2.1 Objectifs de cette étape (suite)
Outre les éléments de réponse aux questions listées ci-dessus, la rencontre du
commanditaire (Directeur du projet) avec le chef de projet doit permettre aux
2 acteurs clés du projet :
- de définir une direction commune vers laquelle il souhaite aller,
- d’établir des règles de fonctionnement commune,
- de définir un vocabulaire commun (appréhender le vocabulaire <<métier>>
pour le chef de projet et le vocabulaire <<Gestion de Projet et S.I>> pour le
commanditaire).
- de s’entendre sur une organisation à établir pour conduire le processus
d’avant-projet.
5.2.2 Documents à produire à l’issue de cette tâche
Une première version du business case.

Une fois la validation de la faisabilité du projet obtenue à partir des premiers
éléments indiqués dans le business case, nous passons à l’étape de préparation
du projet qui revient essentiellement à structurer le projet et à détailler les
différents points clés du projet.
5.3.2 Définir une structure de pilotage
Le chef de projet devra mettre en place la structure pilotage et opérationnelle
du projet qui servira au pilotage de l’appel d’offres dans un premier temps et
au pilotage du projet avec le fournisseur sélectionné dans un second temps.
Elle devra être définie avec toutes les parties prenantes. Le résultat obtenu
sera un organigramme de projet (cf chapitre 4.1). Cette étape est primordiale
car un manque de ressources, le flou des organisations ou des rôles portés par
chacun peut être une cause d’échec de projets.
5.3 Etape : préparation du projet

5.3 Etape : préparation du projet
5.3.3 Identifier les fonctionnalités attendues et leurs niveaux d’importance
Le chef de projet travaillera avec un représentant du métier nommé par le
directeur de projet sur la liste des fonctionnalités attendus par l’application
avec un classement par ordre d’importance (« Business Value » ou services
rendus au métier).
L’idée est d’identifier les fonctionnalités considérées comme indispensables,
importantes ou optionnelles. Ces critères serviront en entrée du cahier des
charges dans un premier temps et lors d’analyse des solutions dans un second
temps.
Cette liste permettra des arbitrages budgétaires et servira de base aux
arbitrages des développements spécifiques versus solutions standard.

5.3.4 Initier un Risk Assessment (Sécurité du SI)
L’objectif de cette étape est de définir une première expression de besoins
Sécurité SI et de les prendre en compte dans les aspects calendaires et
budgétaires de l’appel d’offres.
Le niveau de risque préliminaire du SI sera défini en fonction des réponses aux
questions suivantes :
1. Montant du budget
2. Projet soumis à un cycle de réalisation court ou long
3. En fonctionnement normal :
- L’application doit être en permanence accessible ou utilisable par tous
les services concernés.
- Une indisponibilités de l’application (ou SI) est tolérée sous réserve
qu’elle soit momentanée, signalée et sans conséquence pour le service
fourni.

4. Suite à un incident majeur (exemple : destruction d’un site informatique,
panne électrique générale et durable, etc.) après 1 journée :
-L’activité de l’entreprise est fortement perturbée, voire bloquée
- L’activité est perturbée ou dégradée mais sans conséquence majeure à ce
stade
- Sans impact important
5. La perte des données/information traitées par l’application (ou SI), ne
pouvant plus être retrouvée, est :
- Intolérable pour l’activité
- Perturbant pour l’activité sans être bloquant
- Sans impact important
6. Si les données sont altérées, il existe un moyen de retrouver l’information
par une autre source (éventuellement moyennant un délai)
7. Si les données/informations traitées utilisées par l’application sont altérées
durant un laps de temps réduit, cela nuit gravement au service rendu

9. L’application (ou SI) est interconnectée avec d’autres applications ou SI de
l’entreprise
10. Tout ou partie de l’hébergement de l’application ou SI ou des
données/informations manipulées par l’application ou SI sera externalisée
11. Indiquer le nombre d’utilisateurs de l’application
12. L’application sera accédée par des utilisateurs externes à l’entreprise
(prestataires, clients, partenaires externes …)
13. Dans les données/informations qui seront traitées/utilisées par
l’application, y aura t-il :
-Des informations commercialement sensibles
- Des informations RH
- Des informations concernant les méthodes ou outils de travail de l’entreprise
- Des informations concernant la stratégie de l’entreprise
- D’autres types d’informations qui si elles étaient divulguées pourraient porter
atteinte à l’image du groupe ou avoir un impact financier ?

14. Quelle est la part des données sensibles par rapport à l’ensemble des
données disponibles dans l’application
15. Existe t-il des contraintes réglementaires qui nécessitent la mise en place
d’un contrôle dans le temps des données/informations manipulées
(preuve/traçabilité) ou d’un archivage spécifique
16. L’application cible manipule des données à caractère personnel (données
permettant l’identification directe ou indirecte d’une personne), des données
sensibles (l’origine raciale ou ethnique, l’appartenance syndicale…) au sens de
la Loi Informatique et Libertés ou concerne-t-elle des traitements sensibles
(contenant des appréciations sur les difficultés sociales des personnes,
contenant des données biométriques….)

5.3.5 Initier les budgets
5.3.5 Initier les budgets
A ce niveau de connaissance de la cible, on préparera un macro budget afin
d’obtenir un ordre de grandeur. En effet, sans retour des différents
soumissionnaires, il est difficile de faire une estimation fiable et précise. On
pourra établir un budget à partir de projet similaire par analogie. A ce niveau
du projet, la précision des budgets est de +/- 40% avec le coût final réel du
projet.
5.3.6 Liste des besoins en production
Le chef de projet devra définir un premier niveau de service attendu en
production :
-Nombre d’utilisateurs au total/Nombre d’utilisateurs en simultané
- Exigences fonctionnelles du service
- Exigences du niveau de qualité de service (RTO/RPO)
- Exigences opérationnelles du service (ouverture du service)
- Programme de transition, c'est-à-dire comment le service va être mis en
œuvre

Des documents sont obligatoires à cette étape :
• le business case, complété
• le document « Project Initialisation Document » (PID), complété (voir annexe
« modèle de PID »)
• le document « Risk Assessment », complété sur les 4 axes DICT (Disponibilité,
Intégrité, Confidentialité, Traçabilité)

La valeur ajoutée de cette phase INITIATE est précisément
d’écarter au plus tôt les « fausses pistes », et d’orienter la suite
des études sur les axes de solutions apparaissant les plus pertinents.
 En conséquence :
- c’est une phase d’étude courte
- il n’est pas nécessaire de converger sur une seule solution à ce stade : c’est
l’objet de la phase suivante (phase DEFINE)
- les coûts et délais ne sont que des ordres de grandeur, susceptibles d’être
remis en cause à la lumière de la phase DEFINE

6 La phase définition du projet (DEFINE)
La phase DEFINE est particulièrement importante puisqu’elle a pour objectifs
de définir le projet, dans l’ensemble de ses dimensions :
- Le contenu fonctionnel et technique de la solution SI associée aux nouveaux
processus métier
- La démarche et délais nécessaire pour concevoir, réaliser et déployer cette
solution. Ex : le choix « progiciel » ou « développement itératif » doit se faire
en fin de « DEFINE ».
- Les coûts projets et les coûts de fonctionnement futurs

6 La phase définition du projet (DEFINE)
Pour ce faire, cette phase est organisée en deux temps :
- Une étude des scénarios (« Evaluate Alternatives ») permet aux décideurs
d’identifier l’alternative répondant au mieux aux besoins métiers, ainsi qu’aux
contraintes diverses, économiques ou techniques.
- Sur la base du scénario retenu, le cadrage et le dossier de lancement du
projet sont finalisés, et précisent notamment l’organisation du projet, son
planning et ses coûts). La phase se termine par la décision de lancement du
projet (ou d’arrêt le cas échéant) via la signature d’un contrat entre le client et
son fournisseur.

6.2 Etape : Lotissement du projet
Le lotissement a pour but de diminuer la complexité d’un projet en le
découpant en sous-ensembles (les « lots ») intrinsèquement cohérents et plus
faciles à gérer.
Le lotissement d’un projet est effectué en fonction de « produits livrables »
clairement délimités. Chaque produit livrable est fabriqué selon une liste de
tâches. Cette liste de tâche est valorisée en termes de charge (nombre de
jours-homme), puis en terme de délai (planification Gantt), enfin en terme de
coûts (avec taux journaliers internes, externes, investissements, …).
.

6.2 Etape : Lotissement du projet
Pour un projet simple, celui-ci ne sera constitué que d’un lot unique.
Le lotissement a pour avantage en phase de mise en œuvre de limiter l’effet
tunnel : en effet, mécaniquement, il permet d’obtenir plus tôt en production
un système avec moins de fonctionnalités.
Cela permettra au Client et au fournisseur d’ajuster le cas échéant les lots
suivants (changer l’ordre des fonctionnalités, voire en enlever) et surtout si le
contrat est bien construit pour le client, cela permettra d’arrêter à la suite de la
mise en production du premier lot (limiter la casse) le projet si le résultat
attendu est insatisfaisant et ne pas continuer les études et la mise en
production des lots suivants.

6.3 ETAPE : rédaction du cahier des charges
Le cahier des charges est un document qui contient la liste des besoins, des
exigences et des contraintes qu'il faut respecter lors de la réalisation d'un
projet.
La plupart des projets sont mis en œuvre avec l’assistance d’un ou plusieurs
prestataires externes. Le cahier des charges est un des documents clés qui
servira de support aux prestataires sollicités pour élaborer leurs offres.
Le chef du projet est responsable de sa finalisation, tout en s’appuyant sur
toutes les ressources qualifiées dans le projet, y compris avec le concours
d’experts techniques et d’utilisateurs expérimentés de filiales. Le chef de Projet
peut demander à faire appel à un tiers pour l’assister dans cette étape de
rédaction du cahier des charges
Selon la taille du projet, cette tâche peut démarrer parallèlement aux tâches
précédentes mais n’est validée qu’après confirmation budgétaire.

6.3.2 le cahier des charges : Aide à la rédaction des différentes sections
Le cahier des charges doit être présenté en plusieurs sections :
• La présentation de l’entreprise et la présentation du projet, qui définit le
cadre du projet, ses objectifs et son périmètre ainsi qu’un macro-planning
souhaité. Cette section est préparée par les chefs de projet fonctionnel et DSI.
• La section traitant des caractéristiques fonctionnelles doit être préparée par
le(s) chef(s) de file métier. Des utilisateurs expérimentés dans le domaine
fonctionnel peuvent concourir à la rédaction du cahier des charges. Dans
l’éventualité où l’expression des besoins n’apporterait pas suffisamment de
détails, des analyses de l’existant et des besoins futurs peuvent être réalisées
via des interviews d’utilisateurs au sein de l’entreprise préalablement à la
rédaction du cahier des charges.
Dans cette section, il est recommandé de réutiliser la liste des fonctionnalités
hiérarchisées issues du P.I.D. (Project Initiation Document)
Initialisation Projet (ou P.I.D) : "Baseline" du projet en matière de Qualité (Q)
Coûts (C) Délais (D) et Risques (R)

• La section traitant des caractéristiques techniques attendus du Système
d’Information doit être préparée par le(s) chef(s) de file DSI avec le concours
d’experts techniques. Elle devra notamment inclure la description de
l’architecture technique des Systèmes d’Information existant de l’entreprise et
les exigences techniques relatives au futur système, notamment, en matière
de sécurité
Dans cette dernière section, les niveaux de services attendus (SLAs),
l’organisation de l’exploitation et du support (exemple : infogérés vs internes)
doivent très clairement apparaître.
SLAs (Service Level Agreement ou contrat de niveau de service) à prévoir

L’objectif du cahier des charges est de définir les exigences du projet. Dans la
partie technique doivent être traités les sujets suivants :
• Disponibilité du système vis à vis de l’infrastructure actuelle et des
utilisateurs ;
• Intégrité des données et des traitements qui seront réalisés ;
• Confidentialité (module d’authentification, contraintes sur les mots de
passes, cryptage éventuel des données…),
• Traçabilité,
• Reprise de données des systèmes actuels ;
• Volumétrie des données ;
• Contraintes de sauvegarde et d’archivage des données ;
• Contraintes liées à la réglementation en vigueur ;
• Contrôles d’applications (fonctionnels et techniques) à implémenter ;
• Support utilisateurs à prévoir
• Exploitation, support technique à prévoir
• SLAs (Service Level Agreement ou contrat de niveau de service) à prévoir

Par ailleurs, un questionnaire est joint au cahier des charges en vue de lancer
l’appel d’offres. Ce questionnaire comporte au minimum un volet commercial
dont l’objectif est d’obtenir des éléments de mesure de la pérennité et de la
capacité financière du prestataire, de sa capacité professionnelle à délivrer à
l’entreprise les produits et prestations attendus dans le cadre du projet et
d’estimer le coût et les conditions de fourniture de ces produits et services.
Dans le cas d’un appel d’offres de recherche de progiciel le questionnaire
comprend, outre le volet commercial pris en charge par les chefs de projet DSI
et fonctionnel, un volet fonctionnel pris en charge par le chef de projet
fonctionnel et un volet technique pris en charge par le chef de projet DSI
assisté des experts techniques.

6.4 ETAPE : RECHERCHE DE PRESTATAIRES
La recherche de différents prestataires dont les produits et les gammes de
services pourraient répondre aux demandes du projet peut s’effectuer en
utilisant plusieurs ressources :
• Les bases de données internes à l’entreprise de recensement des
fournisseurs,
• Recherche sur Internet, catalogues spécialisés, participation à des salons et
conférences, …
• Assistance d’une société spécialisée et indépendante des prestataires,
experte sur le marché des progiciels et prestataires de services informatiques,
telle que le CXP.
(Le Groupe CXP est le premier cabinet européen indépendant d’analyse et de
conseil dans le domaine des logiciels, des services informatiques et de la
transformation numérique).

6.4 ETAPE : RECHERCHE DE PRESTATAIRES
• Chef du projet ou Chefs de file qualifiés
• Entreprise partenaire ayant déjà travaillé sur le sujet.
Le nombre de prestataires consultés dépend des enjeux et caractéristiques du
projet (les domaines fonctionnels et/ou d’expertise technique recherchés
limitent quelquefois significativement la liste des candidats potentiels). Au
moins trois prestataires doivent être recensés et consultés pour chaque appel
d’offres.

6.5 Etape : Lancement de l’appel d’offres
Le chef du projet doit valider avant envoi l’appel d’offres qui doit comporter les
documents suivant :
• Le règlement de la consultation,
• La lettre d’intention de réponse,
• Le cahier des charges validé,
• Le questionnaire validé comportant le volet commercial ainsi que, lorsqu’il
s’agit d’un appel d’offres de recherche de progiciel, les volets fonctionnels et
techniques,
• Une première version de contrat « très ciblée », en adéquation avec la
prestation attendue, sur la base d’un modèle fourni par la Direction Juridique.

6.6 Etape : Etude des offres
Le chef du projet et les chefs de file nécessaires (tant MOA que MOE) se
réunissent afin d’étudier l’ensemble des offres reçues. Ils peuvent
éventuellement demander au prestataire des compléments de réponse écrits
afin d’obtenir des éclaircissements ou clarifier certains points commerciaux,
techniques, fonctionnels ou juridiques.
FOCUS : il est obligatoire de soigneusement analyser chaque réponse sous
l’angle solution standard vs développement spécifique. Le but est de limiter les
spécifiques à leur strict minimum nécessaire au métier. Pour cela, il est
demandé :
• de réutiliser la liste des fonctionnalités issues du cahier des charges,
• de l’enrichir avec le critère « complexité »
• de l’enrichir avec le critère « plan projet » (budget et planning)
L’appréciation des deux derniers critères peut se faire soit en interne de
l’entreprise, soit avec l’aide des soumissionnaires.

La partie commerciale du questionnaire et les trois derniers bilans fournis par
le prestataire permettent à l’équipe projet de déterminer la pérennité d’un
engagement avec le prestataire. Si ces éléments ne sont pas suffisants, le chef
du projet peuvent demander l’assistance de la Direction Juridique.
Un premier niveau de sélection permet d’obtenir une ‘short-list’ de prestataires
ne comportant plus que 2 ou 3 offres.
Les résultats de cette première étape de sélection sont présentées lors d’une
réunion du comité de pilotage qui valide le choix de la ‘short-list’.
Le chef du projet et les chefs de file nécessaires organisent ensuite un
ensemble de réunions avec les prestataires ‘short-listés’ dans l’objectif
d’approfondir la connaissance de leur offres.

Les prestataires sélectionnés dans la ‘short-list’ sont notamment invités à venir
défendre leurs offres lors de réunions de présentation organisées dans les
locaux de l’entreprise en présence, éventuellement, d’utilisateurs expérimentés
de filiales et d’experts techniques, et des membres du comité de pilotage.
Dans le cas d’un appel d’offres de recherche de progiciel, il est demandé aux
prestataires ‘short-listés’ de réaliser des présentations de leur progiciel ainsi
que des démonstrations réalisées sur la base de scénarios imposés par le(s)
chef(s) de file). Ces présentations permettent de jauger la capacité des
progiciels à répondre aux exigences fonctionnelles et techniques exprimées
dans le cahier des charges. Des scénarios de mesure des volumes de données
transitant sur le réseau sont généralement prévus.
Les réunions de présentation et de démonstration basées sur les scénarios se
déroulent, selon les thèmes de ces réunions en présence d’experts techniques
et/ou d’utilisateurs expérimentés de filiales.

Best Practice :
Les Proof of Concept utilisent majoritairement des fonctionnalités standard de
chaque solution. Il est utile de demander l’illustration d’un besoin non couvert
par le standard. Ceci permet de se rendre compte de la faisabilité puis de la
difficulté. Ces deux critères ont une influence directe sur les budgets.

6.6.2 Exemple de notation d’un éditeur : Partie fonctionnelle d’un
progiciel de CR
Dans cet exemple, l’équipe projet a décidé d’établir la notation fonctionnelle de
l’application selon 8 critères fonctionnels : les appels entrants, l’activité
commerciale, la gestion des affaires, les articles/prestations, les devis simples,
les devis complexes, les contrats, les statistiques et les outils bureautique

6.6.2 Exemple de notation d’un éditeur : Partie fonctionnelle d’un
progiciel de CRM
A chacun de ces critères a été affectée une note qui correspond à la couverture
fonctionnelle du Progiciel. Si le critère est à 100%, cela veut dire que le
progiciel couvre totalement les fonctionnalités attendus par le client. Si le
critère est à 0, cela veut dire que le progiciel ne le couvre pas du tout.
Si un critère est constitué de plusieurs fonctionnalités, le coefficient
d’importance associée à la note de cette fonctionnalité dépendra de sa
Business Value : plus elle sera importante pour le business et plus le coefficient
et donc la note en sera importante.

6.7 Etape : Sélection du prestataire
Le chef du projet et les chefs de file nécessaires organisent une réunion du
comité de pilotage à laquelle participent éventuellement des utilisateurs
expérimentés et/ou des représentants des filiales et des experts techniques. Ils
présentent au comité de pilotage une synthèse des offres ‘short-listées’
mettant en relief les avantages et inconvénients de chacune.
Le comité de pilotage, avec éventuellement des utilisateurs expérimentés de
filiales, choisit le prestataire qui sera retenu pour la réalisation du projet sur la
base des travaux résultant de l’étude des offres.

Le chef du projet et les chefs de file nécessaires organisent une réunion du
comité de pilotage à laquelle participent éventuellement des utilisateurs
expérimentés et/ou des représentants des filiales et des experts techniques. Ils
présentent au comité de pilotage une synthèse des offres ‘short-listées’
mettant en relief les avantages et inconvénients de chacune.
Le comité de pilotage, avec éventuellement des utilisateurs expérimentés de
filiales, choisit le prestataire qui sera retenu pour la réalisation du projet sur la
base des travaux résultant de l’étude des offres.
La décision du choix n’est communiquée définitivement aux short-listés que
lorsque les négociations avec le prestataire retenu ont abouti.
Le Directeur de projet est le garant devant la direction générale du « meilleur
usage » des spécifiques :
• Spécifiques à forte valeur ajoutée métier,
• Périmètre clairement délimité
• Impact sur la maintenabilité suffisamment cernés.

Il bénéficie de toute l’aide de l’équipe projet pour arbitrer. En particulier, le chef
de Projet DSI a le devoir d’éclairer chaque alternative en termes de complexité,
coût, délais, maintenabilité.
La décision doit « embarquer » un avis de la DSI sur les impacts :
- d'architecture applicative (cohérence de développer une fonctionnalité
spécifique dans telle brique , alors qu'on pourrait utiliser un paramétrage dans
un autre progiciel)
- de maintenabilité du système
- de coût de développement, mais aussi de maintenance.
Ces arbitrages sont obligatoirement enregistrés et validés dans une instance de
niveau suffisant (a minima Copil).

6.8 Etape : Etablissement du contrat
L’élaboration du contrat se base sur :
• le contrat première version qui avait été proposé dans l’appel d’offres,
• les remarques ou réserves formulées par le prestataire sur ce contrat,
• le résultat des négociations.
Le contrat doit prévoir des clauses sur les points suivants :
• Le calendrier du projet qui est annexé au contrat,
• Un système de pénalité en cas de non-respect du calendrier,
• Une clause sur le respect de la confidentialité,
• La propriété intellectuelle des développements qui seront réalisés,
• Une clause sur le Plan d’Assurance Qualité proposé pour le projet
• Un sommaire du P.A.Q. en annexe (ce P.A.Q. sera finalisé en étape de
spécifications détaillées)
• L’existence et descriptif du fonctionnement du comité de suivi et/ou du
comité de pilotage du projet,
• La mise à disposition au Client des résultats (documentés et positifs) d’une
recette interne qui sera réalisée par le prestataire

6.8 Etape : Etablissement du contrat
Le contrat doit prévoir des clauses sur les points suivants (suite) :
• La description d’une phase de recette qui donnera lieu à une série de tests
afin de s’assurer que le système délivré répond bien à l’ensemble des
spécifications (dont les spécifications techniques relatives au respect des
procédures de sécurité des systèmes d’information et des réseaux) qui seront
préalablement définies et validées,
• Le devoir de conseil du prestataire sur l’exhaustivité de cas représentatifs
dans les tests préparés par le Client en vue de la recette,
• La gestion des anomalies qui pourraient être détectées, ainsi que le suivi du
traitement de ces anomalies,
• Une clause sur le respect par le personnel du prestataire intervenant dans les
locaux du Client sur les dispositions de son règlement intérieur,
• Les clauses de paiement liés aux phases de projet (en particulier les clés de
paiement liées aux recettes par lot, à la recette provisoire, à la VSR (Vérification
de service régulier).
In fine, le contrat doit être revu et validé par un Chef de file « Juridique »
avant signature avec le fournisseur

Le périmètre du projet et les spécifications de la solution
ne sont connus avec précision qu’à l’issue de la phase « DESIGN ».
Il en est de même pour les estimations de coûts et délais.
 Cela a des conséquences importantes :
- Un objectif majeur de la phase DEFINE est de limiter le risque de variation des
estimations, afin que la décision de lancement du projet soit prise sur des
bases solides. Cette phase est donc primordiale, et les études doivent être
approfondies à un niveau de détail permettant de lever au mieux les
incertitudes.

Conduire un appel d’offre pour la mise en œuvre d’un système d’information 100
7 Principaux facteurs de risque à couvrir pendant Initiate et Define
Un facteur de risque est une difficulté, avéré ou potentielle, susceptible de
mettre en péril le résultat final du projet. L’objectif des questions ci-dessous est
de fournir au chef de projet un ensemble de questions sur les risques les plus
rencontrés en phase INITIATE ET DEFINE

7.1 CADRAGE DU PROJET
• Les objectifs et enjeux du projet sont-ils clairs ?
• Le(s) client(s), le(s) demandeur(s) du projet sont identifiés. : A qui profite le
résultat à atteindre ? Qui pose le problème ?
• Le commanditaire du projet est identifié : Celui qui défend l'opportunité du
projet et qui représente le ou les clients, qui l’inscrit dans les plans. • Les faits à
l'origine de la demande sont identifiés : Que révèle l'analyse des faits (idées
diagnostic, insatisfactions…) ?
• Les enjeux prioritaires sont-ils identifiés et hiérarchisés ?
• Existence/clarté/qualité de la justification du projet :
o Justification économique : (quelle durée de retour sur Investissement ?)
o Enjeux autres qu’économiques
• Les besoins sont formalisés : Quels sont les besoins à satisfaire ? Quels sont
les besoins prioritaires ? Sur quelles hypothèses sont-ils basés ? Comment
sont-ils satisfaits aujourd'hui ?
• Il est opportun de lancer le projet maintenant : Risques à attendre, à ne rien
faire, par rapport à la stratégie Entreprise

7.2 CLARTE ET STABILITE DU PERIMETRE
• Le sujet est-il innovant pour le métier ?
• Risque d’arrivée d’évolutions réglementaires ?
• Autre motif qui n’aurait pas permis de cerner l’ensemble des besoins ou
contraintes à ce stade ?
7.3 MAITRISE, STABILITE ET PERENNITE DE LA SOLUTION
• Technologie innovante ? ou nouvelle pour les équipes SI ?
• Progiciel : maîtrisé en interne ?
• Risque que l’on ait sous estimé l’importance des développements spécifiques ?
• Comment a-t-on procédé pour s’assurer de la couverture/adéquation aux
besoins ? • L’exploitant futur maîtrise t-il la solution ?
• Risque de pérennité d’un fournisseur de la solution ?

7.4 URBANISME ET ARCHITECTURE APPLICATIVE
• Les scénarios de solution applicative ont-ils été travaillés en amont avec les
architectes ?
• Insertion dans l’existant/Interfaçages : complexes ?
• La solution prévue contribue-t-elle à simplifier l’architecture applicative
d’ensemble ?
• A-t-on examiné des pistes de réutilisation de solutions existantes, les pistes
de synergie ou de mutualisation ?
7.5 SECURITE
• Les risques spécifiques à la sécurité SI ont-ils été analysés et pris en compte ?
• Le projet comporte t-il des risques élevés de cette nature ?
7.6 PERFORMANCES
• Problématique spécifique de performances ? (volumétries hors normes,
augmentation de trafic réseau à anticiper…)

7.7 IMPACTS SUR LES UTILISATEURS
• Modification significative de l’organisation ou des process ?
• Risque de rejet de la solution et ou des nouveaux modes de travail associés ?
• Risque social ?
7.8 LES ATTENDUS DU PROJET
• Les enjeux (impact, finalités) du projet : Le but du Sponsor, ce qui fonde la
justification du projet : enjeux stratégiques, économiques, commerciaux,
techniques, ...
• Les enjeux sont-ils formalisés ?
• Les indicateurs d’atteinte des enjeux sont définis ?
• Comment mesurer que les enjeux seront atteints ? Sur quelles références ?
Valeurs cibles ?
• L'intérêt pour l'entreprise est établi. Étude macro-économique, stratégique,
...

• Les risques stratégiques sont formalisés. Risques sur l’atteinte des enjeux : la
stabilité des besoins, la robustesse des hypothèses, la pertinence des objectifs
retenus, l’image de l’entreprise, les approvisionnements et les flux produits,
l’environnement et la prévention des risques…
• Les objectifs du projet sont formalisés : Objet, quantité, délai, ...
• L'objet du projet est spécifié. Cahier des charges fonctionnel initial de l'objet :
performances, coût de revient, et/ou coût d’usage de l'objet.
• Les indicateurs de réussite du projet sont formalisés.
• Comment mesurer que le projet a atteint ses objectifs ? Sur quelles
références ? Valeurs cibles ?
• Les limites, le périmètre du projet sont formalisés. Ce qui est inclus, ce qui est
exclu du projet, fonctions, organisations, processus et projets impactés ...
• Les contraintes sont formalisées.

8 Conclusion
A travers ce cours, nous avons vu dans le détail l’ensemble des processus
nécessaire à la bonne gestion d’un appel d’offre pour la mise en œuvre d’un
système d’information. Si l’on fait une analogie avec le football, cette phase est
la première mi-temps de la partie.
La seconde mi-temps est le projet conduit en commun par le client et son
fournisseur. On peut considérer la fin de la partie comme étant la mise en
production du système. Comme toute partie de football, la configuration de la
deuxième mi-temps, c’est à dire du projet, dépendra de la manière dont se sera
déroulée la phase d’avant projet.
Si la gouvernance du projet, les budgets et la contractualisation ont bien été
menés au cours de la première phase avec rigueur et méthode, on aura
d’autant plus de chance de réussir la seconde phase.
Si à l’inverse, cette phase a été mal définie ou gérée dans la précipitation pour
diverses raisons, on aura toutes les difficultés à rattraper les écueils déjà
existants.

9 ANNEXES
9.1 GLOSSAIRE DE LA DOCUMENTATION D’AIDE AU PILOTAGE DE L’APPEL
D’OFFRES
Tous les documents du projet doivent être versionnés et archivés. Le respect de
ces action doit garantir une traçabilité suffisante des évènements et évolutions
en cours de projet.
Le JCP : Le Journal de Conduite de Projet (JCP) est la boîte à outils du chef de
projet : Il lui permet de piloter tout en traçant l'ensemble des événements
importants de la vie du projet. Ce document peut également servir de support
à la communication :
- vers l'équipe projet (COSUI)
- vers les sponsors (COPIL)"
Initialisation Projet (ou P.I.D) : "Baseline" du projet en matière de Qualité (Q)
Coûts (C) Délais (D) et Risques (R)
Document des Parties prenantes : Contacts des intervenants dans le projet
ainsi que leurs disponibilités

9 ANNEXES
Suivi du planning : Echéancier du projet confronté au statut de traitement de
chaque tâche.
Suivi du budget : Analyse de la variance du budget en confrontant budget
initial, consommé et reste à faire
Suivi des risques : Tableau permettant d'identifier les risques, de les évaluer, et
de suivre leur traitement (actions préventives /curatives) tout au long du
projet.
Suivi des changements : Tableau permettant de tracer les différentes
demandes clients en cours de projet, et d'en analyser l'impact
Suivi des actions : Tableau permettant de suivre les actions décidées lors des
réunions et comités
Compte rendu RIDA : Relevé des informations, décisions et actions issues des
réunions et comités qui jalonnent le projet.

9.2 MODELE DE DEMANDE DE PROJET SI

9 ANNEXES

Conduire un appel d’offres pour la mise en œuvre d’un système d’information

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Conduire un appel d’offres pour la mise en œuvre d’un système d’information

Similaire à Conduire un appel d’offres pour la mise en œuvre d’un système d’information (20)

Plus de Echecs & Stratégie

Plus de Echecs & Stratégie (12)

Dernier

Dernier (20)

Conduire un appel d’offres pour la mise en œuvre d’un système d’information