Conduire un appel d'offres sur un systeme informatique

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.

10
Citez 5 mots en relation avec les appels d’offres

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 !
2.3 LES ENJEUX POUR L’ACHETEUR ET LE VENDEUR

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 (Des armées, de la culture,
des sports, du travail, …), 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.

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.
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.

29
Document à analyser
« Trouvez les clés de succès pour mieux répondre
aux appels d’offres » de www.francemarches.com
1 - Lecture complète du document
2 - Choix d’un chapitre
3 - Constitution de sous-groupes de travail (4 maxi)
4 - Elaboration d’une synthèse du chapitre choisi
5 - Présentation orale de la synthèse
6 - Debrief sur la prestation

30
« Trouvez les clés de succès pour mieux répondre
aux appels d’offres » de www.francemarches.com
Les sujets choisis par les sous-groupes
1 - L’accord-cadre
2 - La dématérialisation
3 - Les variantes
4 - Les options techniques ou « PSE »
5 - Les pénalités
6 - La sous-traitance
7 - Le lot
8 - La candidature
9 - Les offres
10 - L’offre non conforme
11 - MAPA (Marché à procédure adaptée)
12 - L’exécution financière
13 - Les avenants dans les marchés publics

31
« Trouvez les clés de succès pour mieux répondre aux appels d’offres »
de www.francemarches.com
Les sujets choisis par les sous-groupes
Chaque présentation de 15 minutes y compris les Q/R
3 - Les variantes
5 - Les pénalités
8 - La candidature
9 - Les offres
10 - L’offre non conforme
11 - MAPA (Marché à procédure adaptée)

Quoi : Sanctionnent un dysfonctionnement
Exemple : le plus souvent retard de livraison, manquements contractuels définis
Rédigées : par l’acheteur public (dans le CCAP)
Dérogations : CCAG
! Dernier article du CCAP doit récapituler les dérogations au CCAG a défaut, pénalité
nulle et non avenue
! Pénalité de retard s’applique automatiquement sans avertissement préalable
Comment :
• instruction d’un dossier de pénalité notifié au titulaire (délai de 30 jours)
• rédaction d’observations en vue d’une exonération par le titulaire (envoi AR)
• Instruction du dossier par personne publique (tribunal local)
• Possibilité du titulaire de saisir le juge administratif (modulation de la requète
Préconisations :
• Maintenir un dialogue de proximité avec l’acheteur public (et surtout le signataire du
contrat)
• En cas de retard, demander un report de délai acté par écrit par la personne publique
(greffe)
Des Questions ?
! Dernier article du CCAP doit récapituler les dérogations au CCAG a défaut, pénalité nulle et non avenue
! Pénalité de retard s’applique automatiquement sans avertissement préalable
Un exemple de synthèse : Les pénalités

33
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.

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 (centre de
services partagés) 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»).

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
Une exemple d’appel d’Offres: IA pour l’INPI (INST NAT DE LA PROPRIETE INDUSTRIELLE)
Le lien vers l’appel d’Offres

Que doit contenir un dossier de réponse à un appel d’offres ?
Le lien vers l’article : https://blog.hiscox.fr/dossier-de-reponse-appel-doffres/
Les entrepreneurs hésitent encore à répondre aux appels d’offres. En France, la
commande publique s’élève à près de 200 milliards d’euros par an. De plus, la
réforme des marchés publics en application depuis 2016 vise à faciliter l’accès
des petites et moyennes entreprises aux marchés publics.

6.3 ETAPE : Rédaction du cahier des charges
Le lien vers la vidéo :https://www.youtube.com/watch?v=Roxa59V_3Kg
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.

Le lien vers la vidéo : https://www.youtube.com/watch?v=toND0OLVcbE
Les pièges du cahier des charges

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.

3.1 METIERS
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.
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.

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
- 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 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.
Trois contraintes

Le Chef du Projet
 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,
 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.

Le Chef du Projet
• 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(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 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 69
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 INITIATE
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)
6.1 OBJECTIFS DE LA PHASE 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)
6.1 OBJECTIFS DE LA PHASE
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.

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.
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.

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 115
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 ?

7.1 CADRAGE DU PROJET
• 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 Exemples pratiques : Expression de besoin et cahier des charges
 Méthodologie Expression des Besoins
 Le cahier des charges de la ligue d’échecs de Picardie
 L’expression de besoin pour une signature électronique de contrat de travail
 L’Expression de besoins pour la mise en GEIDE de dossier RH

124
Zoom sur le cahier des charges

Le cahier des charge contient :
Ce que demande le commanditaire du projet
Le contexte
Les finalités
Les objectifs
Ce que propose le chef de projet
Les livrables
L’équipe
Le calendrier
Le prix

Le lien vers la vidéo : https://www.youtube.com/watch?v=Roxa59V_3Kg

Le lien vers la vidéo :https://www.youtube.com/watch?v=Roxa59V_3Kg
Le cahier des charges

Le cahier des charges fonctionnel
Le lien vers la vidéo : https://www.youtube.com/watch?v=N6CgqaXMphA
Comment élaborer un cahier des charges fonctionnel ?

Gestion des projets | 27/11/2016 - © 2013 IAE de Lille - Ecole Universitaire de Management
Au terme de la démarche d'émergence d’un besoin, le porteur d'idée doit être en capacité
d'argumenter son idée dans un contexte de projet.
Pour cela, il structure son idée autour d'une note d'opportunité qui reprend l'ensemble
des éléments travaillés durant cette phase à partir de :
• La bête à cornes
• L'arbre d'objectifs
La note d'opportunité se compose de trois parties :
1. La définition du contexte
2. Les objectifs attendus
3. Les orientations de l'action
La définition du contexte exprime le besoin, le public cible et ce sur quoi il convient d'agir.
C'est la présentation de la problématique à partir de laquelle il importe d'apporter une
amélioration. C'est aussi le moment d'exprimer les causes environnementales qui
expliquent ce besoin (juridiques, légales,...)
La bête à cornes est l'outil qui aidera à structurer ce contexte.
Zoom sur la phase d’émergence du besoin

Bien souvent, l'analyse des objectifs reste à l'état de « ressenti ».
Sa formalisation apporte un gain de temps et d'objectivité important pour le projet.
La bête à cornes permet de mettre sur papier l'ensemble des problématiques qui
vont impacter le projet.
En effet, avant d'imposer un « comment » ou une solution, il faut prendre en
compte l'ensemble des besoins et objectifs, pour aboutir, de manière structurée, à
la solution optimale.
Un projet n'a de sens que s'il satisfait le besoin
Il s'agit de préciser ce qu'on veut modifier ou sur qui on veut agir
Il s'agit de répondre à la question : Quoi ?
Il s'agit de répondre aux questions pourquoi ? : Besoin
et pour quoi ? : objectifs
La bête à cornes : Outil d’analyse fonctionnelle
Conduire un appel d’offres pour la mise en œuvre d’un système d’information

La bête à corne est un outil
d’analyse fonctionnelle du besoin.
En matière d’innovation, il est tout
d’abord nécessaire de formuler le
besoin sous forme de fonctions
simples (dans le sens de « fonctions
de bases ») que devra remplir le
produit ou le service innovant.
La bête à cornes : Outil d’analyse fonctionnelle
Conduire un appel d’offres pour la mise en œuvre d’un système d’information

Gestion des projets | 27/11/2016
Dès le lancement d’un projet d’innovation, il est nécessaire d’expliciter simplement le besoin
primaire, c’est-à-dire l’exigence principale.
Son but doit être de satisfaire un besoin exprimé ou non par l’utilisateur.
L’usage d’un nouveau produit ou service doit générer des fonctions de services que la bête à
cornes permet d’identifier et de caractériser.
Les fonctions sont exprimées sous formes de verbes à l’infinitif.
UN EXEMPLE SIMPLE DE LA BÊTE À CORNES : UN SCALPEL DE CHIRURGIE
« A qui mon produit rend-il service ? » : un chirurgien
« Sur quoi agit mon produit ? » : le patient
« Quel est le but de mon produit ? » : Couper ou Disséquer de manière très précise des
éléments organiques
La solution technique issue de cette analyse : Un couteau léger, très maniable, très pointu et
au fil de lame très fin.
A quoi sert la bête à cornes ?

Le lien vers la vidéo : https://www.youtube.com/watch?v=xiY3lycLH8k
Comment concevoir un cahier des charges

Illustration : Le cahier des charges d’un e-commerce
Le lien vers la vidéo : https://www.youtube.com/watch?v=nwoDxrF5jr4

La Rédaction du cahier des charges
Le lien vers la vidéo : https://vimeo.com/169704944
Le cahier des charges fonctionnel d’un projet digital

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 sur un systeme informatique

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Conduire un appel d'offres sur un systeme informatique

Semelhante a Conduire un appel d'offres sur un systeme informatique (20)

Mais de Echecs et Stratégie

Mais de Echecs et Stratégie (20)

Conduire un appel d'offres sur un systeme informatique