conduire un appel d’offres pour la mise en œuvre d’un

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

https://www.youtube.com/watch?v=WFUeoCyQI0A&list=PL3yendJbBRLPI_voclbz5-_OqlK_FCJsX&index=2

https://www.cci.fr/web/se-developper/tutoriels-marches-publics


Episode 2: Par où commencer?


https://www.youtube.com/watch?v=LzyjdaUcUYU


Episode 3: Cibler un appel d'offres


https://www.youtube.com/watch?v=fmHZOaN-wac


Episode 4: Les documents de la consultation


https://www.youtube.com/watch?v=tjgorS3KQ6c


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


https://www.youtube.com/watch?v=rPTPdRUH0ZA


Episode 6: Quelques conseils de rédaction


https://www.youtube.com/watch?v=5OFN0FKca9c


Episode 7: Le dépôt électronique


https://www.youtube.com/watch?v=xsGuHEOOwPY


Episode 8: Et maintenant le dénouement !


2.3 LES ENJEUX POUR L’ACHETEUR ET LE VENDEUR

https://www.youtube.com/watch?v=kKAq1Qa7mqM


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

http://www.francemarches.com/

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

https://www.marchesonline.com/appels-offres/avis/mise-en-oeuvre-d-une-solution-de-ged-et-d-archivage-pou/ao-7958775-1



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.

https://blog.hiscox.fr/dossier-de-reponse-appel-doffres/










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.

https://www.youtube.com/watch?v=Roxa59V_3Kg



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

Les pièges du cahier des charges

https://www.youtube.com/watch?v=toND0OLVcbE


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.



5.3.1 Objectifs de cette étape 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)

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


5.3.7 Documents à produire à l’issue de cette tâche

5.3.7 Documents à produire à l’issue de cette tâche 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.

6.3.1 Objectifs de cette étape 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

6.6.1 Objectifs de cette étape 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 ?

https://www.youtube.com/watch?v=N6CgqaXMphA

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

https://www.youtube.com/watch?v=xiY3lycLH8k


Illustration : Le cahier des charges d’un e-commerce

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

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

https://vimeo.com/169704944


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

Merci de votre attention

142