skip to Main Content
Retour au sommaire         Vous êtes identifié comme visiteur, vous avez un accès libre et gratuit à 80% des contenus. Devenir abonné PREMIUM.
Modèles de documents de gestion de projetCette page vous propose des modèles de documents de gestion de projet. Ils sont destinés à vous inspirer pour la création de vos propres documents. Ils sont volontairement très généraux et vous devez donc les adapter aux spécificités de votre métier, aux particularités et à la culture de votre organisme. Soyez critique : ne conservez pas une rubrique qui ne vous parait pas pertinente.
Dans le souci de ne pas alourdir inutilement les modèles de document, les éléments de traçabilité (date de création du document, numéro de version, auteur et destinataires) sont présentés dans la première section.
Les documents sont regroupés par processus du projet. Un schéma présente chacun des processus et les documents qui lui sont associés. Faites un bon usage de ces modèles de documents de gestion de projet, et bien entendu n’hésitez pas à me faire part de vos remarques.
Méta-processus de gestion des projets de l'organisme
Les deux documents de cette section traitent de la façon dont la direction de l’organisme (entreprise, établissement, organisme public, association…) a décidé de gérer les projets : Quels sont les différents types de projet, qui fait quoi et qui est responsable de quoi en matière de gestion de projets, etc… Les sections suivantes traiteront des documents mis en œuvre dans la gestion de chaque projet.

Cliquez sur la barre correspondant au document qui vous intéresse

Directive pour la gestion du portefeuille de projets
Ce document contient les règles générales établies par la direction de l’organisme en ce qui concerne la gestion des projets. Le fait que l’intitulé fasse mention de la notion de « portefeuille de projets » manifeste la volonté de mettre tous les projets au service de l’ambition stratégique affichée par la direction de l’organisme.

Modèle commenté de Directive pour la gestion du portefeuille de projets

Directive pour la gestion du portefeuille de projets

– Définition d’un projet
La première chose que doivent savoir faire les acteurs de la l’organisme c’est de distinguer les activités qui seront traitées en mode projet de celles qui ressortent d’autres processus. Ce paragraphe peut être rédigé comme suit : Le projet se définit par opposition aux opérations courantes, comme la production ou la maintenance qui sont continues et répétitives. Toute activité temporaire visant un résultat unique est un projet et doit être gérée en mode projet conformément aux prescriptions du présent document. Il peut être utile de spécifier un seuil (de durée et/ou de charge de travail et/ou de budget) en deçà duquel le projet échappe à la procédure de management par projet.

– Définition d’un programme
Il arrive souvent qu’un ensemble de projets soit au service d’un même objectif stratégique. Cet ensemble de projets s’appelle un programme.

– Portefeuille de projets
L’ensemble des programmes et des projets de l’organisme constitue le portefeuille de projets.

– Typologie des projets
Il est souvent nécessaire de définir les différents types (catégories) de projet gérés par l’organisme : internes ou externes, technologiques ou informatiques, projets d’innovation, projets de changement etc… Cette catégorisation n’a d’intérêt que si la procédure applicable est sensiblement différente d’un type à l’autre.

– Cycle de vie des projets
Le déroulement d’un projet suit un parcours standardisé, que l’on appelle le cycle de vie. Le cycle de vie peut différer d’un type de projet à l’autre. Basiquement ce paragraphe peut être rédigé comme suit :
Les projets se déroulent en quatre phases successives :
. La phase d’exploration vise à valider l’opportunité du projet
. La phase de préparation vise à valider la faisabilité du projet
. La phase de mise en œuvre vise à réaliser le produit
. La phase de clôture.
Les phases du cycle de vie sont bornées par des jalons. Un document d’entrée fixe les conditions de déroulement de la phase a venir et un document de sortie en présente les résultats. Ces documents, au nombre de huit, font partie du processus de coordination du projet. Des trames-type de ces documents figurent en annexe.

– Instance de gestion du portefeuille de projets
Lorsque ce n’est pas la direction générale de l’organisme qui assure directement la gestion du portefeuille de projets, ce rôle est confié à un bureau des projets (en anglais PMO pour Project Management Office) qui rend compte directement à la direction.
Classiquement les missions du PMO (qui doivent être précisées ici) consistent à :
. Établir puis faire évoluer le processus, les documents et les outils de gestion de projets
. Centraliser les demandes de projet
. Juger de la pertinence des demandes de projet et décide de leur entrée au portefeuille de projets
. Définir les priorités entre projets
. Nommer les chefs de projet (et les directeurs de programme le cas échéant)
. Autoriser le franchissement des jalons du cycle de vie
. Arbitrer les conflits, notamment lorsque les ressources partagées entre les projets s’avèrent insuffisantes.
. Contrôler l’avancement des projets (et programmes) et agir en cas de constat d’une dérive.

– Outil de gestion du portefeuille de projets
A minima le portefeuille de projets est géré sur un simple tableur. Certains logiciels de planification se prêtent bien, sous réserve de personnalisation, à la gestion de portefeuille. Dans l’idéal c’est une application de gestion de portefeuille qui est utilisée. Indiquer ici quel outil doit être utilisé.

– Parties prenantes d’un projet
Décrire ici les rôles définis au sein et à l’extérieur de l’organisme, classiquement tout ou partie des rôles suivants : PMO, MOA, MOAS, MOAD, Sponsor, AMOA, MOE, Chef de projet, Equipe de projet, Experts métier. Ces rôles sont définis par ailleurs sur cette page et ailleurs sur ce site.

– Méthodes de gouvernance des projets
Indiquer si les projets gérés en structure matricielle. Si c’est le cas définir clairement la répartition des responsabilités entre chef de projet et responsables métier. Indiquer si certains projets d’importance capitale sont gérés en structure cellulaire (task-force). Indiquer si une ou des méthodes particulières sont utilisées et dans quels cas : méthodes agiles, gestion axée sur les résultats…

– Rôles et responsabilités dans les projets
Le plus simple pour cette partie est de faire référence au document « Matrice de responsabilité projets » qui suit, sur cette page.

– Outils informatiques de gestion des projets
Faire référence, s’il en existe, aux outils de planification et/ou aux applications collaboratives utilisées dans l’organisme. L’usage de ces outils est-il obligatoire ou conseillé, concerne-t-il tous les types et toutes les tailles de projets.

– Mission, autonomie et responsabilité du chef de projet
Définir clairement ce qui est attendu du chef de projet dans chacun des domaines suivants :
. Gestion du contenu du projet
. Gestion des travaux et des délais
. Gestion des coûts
. Gestion des risques
. Gestion de la communication
. Gestion des parties prenantes
. Gestion des contrats
. Retour d’expérience
Faire référence aux documents-type concernant ces domaines

– Equipe de projet
Décrire la façon dont est constituée l’équipe de projet, les règles de fonctionnement dans l’équipe et entre l’équipe et les métiers.

– Amélioration continue
Insister sur le fait que ce document n’est pas figé et qu’il évoluera au fil des retours d’expérience. Indiquer les modalités de ces mises à jour. Indiquer qu’il en est de même pour tous les documents du projet.

Autres dénominations :
– Plan de gouvernance des projets
– Manuel qualité projets

Matrice de responsabilité Projets

A quoi sert la matrice de responsabilité projets
Les parties prenantes d’un projet sont nombreuses et le rôle de chacune est déterminant. Pour que les projets se déroulent aussi harmonieusement que possible chaque acteur doit connaitre son rôle exact à chaque étape du déroulement du projet. Voilà à quoi sert la matrice de responsabilité projets. C’est une matrice « RACI » c’est à dire que le rôle de chacun est codé par l’une des lettres R (Réalise) A (Approuve ou Assume) C (Contribue) ou I (est Informé) . Insistons sur le fait que ce modèle est un exemple, à ne pas prendre au pied de la lettre : Les rôles diffèrent sensiblement suivant le contexte (projets internes, externes, publics…) et suivant le style de management du dirigeant (plus ou moins délégatif).
La signification des sigles et acronymes (CODIR, COPIL….) est rappelée sous le tableau

Modèle commenté de matrice de responsabilité projets

Légende : R=Réalise A=Approuve C=Contribue I=est Informé
ResponsabilitéDocument de référence
Comités
MOE
MOA
AMOA
Génèse du projetCODIRCOPILDir TechCDPMOADMOASUtil.AMOA
Instruit et formalise la demande de projetFiche de proposition de projetRC
Décide du passage en phase exploratoireRI
Phase exploratoireCODIRCOPILDir TechCDPMOADMOASUtil.AMOA
Choisit l’interlocuteur AMOAAR
Définit le projet pour la phaseFiche descriptive de projetIC-AR
Délimite le périmètreC-AR
Établit les spécifications fonctionnellesCahier des charges fonctionnel (CDCF)C-ACR
Estime le budget et le délaiC-AR
Evalue le bénéficeC-AR
Analyse les risques stratégiquesC-AR
Synthétise la phase exploratoireNote d’opportunitéIAR
Décide du passage en phase de préparationR
Phase de préparationCODIRCOPILDir TechCDPMOADMOASUtil.AMOA
Constitue le COPILACR
Nomme le MOAD (ou Sponsor)IAR
Nomme le chef de projetLettre de mission du CDPIARIII
Définit le projet pour la phaseCharte de projetAIRCI
Conduit l’avant-projetIIRAI
Établit le référentiel du besoinSpécification technique du besoin (STB)IIRAI
Elabore le budget de référenceBudget opérationnelIIRAI
Etablit le planning de réalisationDiagramme de GanttIIRAI
Analyse les risques opérationnelsIIRAI
Synthétise la phaseDossier d’étude de faisabilitéARCI
Décide le lancementARIIII
Phase de mise en œuvreCODIRCOPILDir TechCDPMOADMOASUtil.AMOA
Etablit le référentiel du projetPlan de projetAIRCI
Pilote le projet au quotidienPlan de projetIRII
Contrôle et arbitreRIIII
Accepte la propriété du produitProcès-verbal de recette définitiveIIIIAICR
Phase de clôtureCODIRCOPILDir TechCDPMOADMOASUtil.AMOA
Analyse le retour d’expérienceBilan de projetCCRCCCC
Acte la fin du projetProcès-verbal de clôtureIRIIIII
Glossaire :
Comités : Groupe de responsables
– CODIR : Comité de Direction. Groupe permanent qui réunit les principaux directeurs (les n-1 du dirigeant). Garant de la stratégie de la structure.
– COPIL : Comité de pilotage (du projet). Groupe constitué pour le pilotage stratégique du projet et dissout à son achèvement. Le COPIL réunit les principaux directeurs métier impliqués dans le projet, dont un représentant de la MOA et un représentant de la MOE.
MOE : Maitrise d’OEuvre. C’est l’entité en charge de la mise en œuvre du projet.
– Dir Tech : Directeur technique. C’est le supérieur hiérarchique du chef de projet
– CDP : Chef de projet. C’est la personne qui va assurer le pilotage du projet au quotidien.
MOA : Maitrise d’OuvrAge. C’est l’entité à l’initiative du projet et qui sera le bénéficiaire du résultat.
– MOAD : Maitre d’OuvrAge Délégué (ou Sponsor). C’est la personne désignée par la maîtrise d’ouvrage pour être l’interlocuteur direct du chef de projet.
– MOAS : Maitre d’OuvrAge Stratégique.
– Util : Utilisateurs
AMOA : Assistance à Maitrise d’Ouvrage. Il a une bonne connaissance du domaine. Il défend, en toute indépendance, les intérêts de la MOA.
Eléments de traçabilité documentaire
Chaque document que vous diffusez doit être daté, identifié et tracé. Cette règle n’est pas propre aux documents de gestion de projet, elle s’applique à tous les documents qui circulent dans un organisme. Les quatre tableaux ci-dessous devraient normalement figurer en début de tous les documents. De plus, chaque pied de page devrait rappeler à minima le nom du document et le numéro de version.

Nature du document

TitreCharte du projet "Palinodie"
ObjetCe document formalise la décision de lancer le projet "Palinodie" et définit les modalités de mise en œuvre.
Nombre de pages25

Rédacteurs

 Prénom et NomFonctionDateVisa
Rédigé parPaul DurandConsultant24-05-2018PD
Vérifié parSophie MoreauChef de projet25-05-2018SM
Approuvé parJean de BoissieuDirecteur Général25-05-2018JdB

Suivi des versions

Suivi des versions du document
VersionAuteurDate de diffusionDescription de l'évolution
V01Paul Durand21/05/2018Version originelle
V02Jean Teullier12-06-2018§ 2.3 : ajout des observations du comité technique
V03

Liste de diffusion

Liste de diffusion
Prénom & NomOrganismeRôle dans le projetEI
Sébastien VolotSTD consultantsAMOAX
Antoine BrunelSDAI IndustriesChef de projetX
.
E : pour Exécution ............I : pour Information
Documents du processus de coordination
Le premier des processus que nous allons explorer est le processus de coordination. Ce processus englobe tous les autres. Les adeptes de la logique du Project Management Institute (PMI) reconnaitront le domaine de connaissances d’intégration.
Modèles de documents de coordinationVoici quelques explications sur le schéma ci-dessus :
– La flèche horizontale orange, en arrière-plan, représente le cycle de vie du projet, ici décomposé en trois phases : Exploration, Préparation et Mise en œuvre. La phase de mise en œuvre regroupe la réalisation du produit et la finalisation du projet.
– Les losanges rouges représentent les jalons du projet : J0 est la revue de portefeuille à l’occasion de laquelle de nouveaux projets sont soumis à l’instance de direction qui décide de les ajourner ou d’en déclencher l’instruction. J1 est la revue d’opportunité, J2 la revue de faisabilité et Jf la réunion de clôture du projet.
– Les documents figurés ici en vert sont des documents de travail, élaborés par l’équipe de projet. Ces documents synthétisent le travail de la phase qui s’achève et fournissent à l’autorité supérieure les éléments de décision.
– Les documents figurés en bleu traduisent les décisions et les orientations fixées par l’instance de décision pour la phase à venir. Ils constituent la « feuille de route » du chef de projet et de son équipe.

Cliquez sur la barre correspondant au document qui vous intéresse

Fiche de proposition de projet

A quoi sert la fiche de proposition de projet ?
La fiche de proposition de projet précède l’existence du projet. Elle concrétise l’idée de projet et officialise la demande faite à l’instance de décision de bien vouloir mettre le projet à l’étude. Le but du document est de convaincre les décideurs que l’idée est digne d’intérêt. Le rédacteur doit se comporter en « vendeur » de l’idée, et mettre en avant les bénéfices que l’organisme peut tirer du projet. Dans les organismes qui ont su mettre en place un bureau des projets, la fiche de proposition de projet est le document d’entrée des projets dans le « portefeuille de projets »

Qui remplit la fiche, à quel moment ?
Pour ne pas priver l’entreprise de bonnes idées et pour encourager le changement, il est bon que le nombre de personnes autorisées à faire des propositions soit le plus large possible. Il faut distinguer l’initiateur (celui qui a émis l’idée) du rédacteur de la fiche. Une fois renseignée, la fiche de proposition est présentée pour décision à l’instance de pilotage.

Modèle commenté de fiche de proposition de projet

Fiche de proposition de projet

– Intitulé du projet
Une phrase de trois à cinq mots doit suffire à nommer le projet de façon non ambigüe (de façon que ce projet ne soit pas confondu avec un autre).

– Origine de la proposition
Vous devez simplement indiquer ici les prénom et nom de l’initiateur ainsi que, pour les organismes importants, son affectation. Indiquer aussi l’identité du rédacteur si ce n’est pas la même personne.

– Problématique et contexte
Tout projet vise à résoudre un problème ou combler une insatisfaction. Décrivez la situation qui motive la demande de projet. N’hésitez pas à entrer dans les détails et à forcer le trait : si le décideur sous-estime le problème, la demande sera refusée.

– Description de l’idée de projet
Décrivez en quelques mot en quoi consiste le projet : Lancer tel nouveau produit, remplacer telle machine vétuste, construire un bâtiment social, réorganiser le service après-vente, créer un site internet de vente en ligne…Soyez à la fois bref et précis.

– Finalité
Mettez-vous dans la tête du décideur et montrez-lui le bénéfice que procurera la mise en œuvre du projet. Bien entendu à ce stade vous n’avez pas de certitudes et encore moins de chiffres précis. Que cela ne vous empêche pas de faire des hypothèses. Les bénéfices ne sont pas forcément économiques. Mettez en évidence toutes les améliorations à attendre du projet et termes d’image, de connaissances acquise, de conquête de nouveaux marchés, etc…

– Cohérence avec la stratégie
Un projet, même prometteur, sera refusé s’il n’est pas en phase avec la stratégie de l’organisme. Indiquez dans quel axe thématique s’inscrit le projet (amélioration de la productivité, conquête de nouveaux marchés…) et montrez en quoi il contribue à la réalisation des objectifs de l’axe. Montrez également comment ce projet complète ou renforce d’autres projets déjà acceptés par la hiérarchie.

– Efforts à consentir
Tout projet consomme des ressources. Tentez une estimation du budget nécessaire, et/ou du nombre d’heures-salarié qui devront lui être consacrées. Annoncez un délai.

Autres dénominations :
– Fiche de demande de projet

Fiche descriptive de projet

A quoi sert la fiche descriptive de projet ?
La fiche descriptive de projet (ou fiche projet) est l’acte de naissance du projet. Elle en formalise l’existence et déclenche l’étude d’opportunité. Elle contient toutes les informations nécessaires à cette étude.

Qui remplit la fiche, à quel moment ?
La fiche descriptive de projet est rédigée immédiatement après l’acceptation de la proposition de projet par l’instance décisionnelle. C’est donc à un membre de la direction de l’organisme qu’il appartient de la rédiger.

Modèle commenté de fiche descriptive de projet

Fiche descriptive de projet

– ici, le NOM DU PROJET –

– Intitulé du projet
Cet intitulé sera repris sur tous les documents du projet. S’il est descriptif, vérifier qu’il est unique et qu’il sera compris par toutes les parties prenantes. Si c’est justifié par des préoccupations de secret, l’intitulé peut être un code qui n’aura pas de signification pour des personnes étrangères au projet. Dans le cas ou l’on a besoin de favoriser l’adhésion (voire l’enthousiasme) des parties prenantes, on peut choisir un nom sans aucun rapport avec l’objet du projet.

– Origine de la proposition
Rappeler l’identité de l’initiateur du projet, d’abord par respect pour celui-ci, ensuite parce que les personnes chargées de conduire l’étude d’opportunité peuvent avoir besoin d’éclaircissements de sa part..

– Contexte et objectifs
Décrivez la situation existante, le problème auquel le projet doit apporter une solution (ou le besoin à satisfaire, ou l’opportunité à saisir). Décrivez le résultat (la situation-cible, le changement..) qui devra être obtenu à la date de fin de projet.

– But du projet
Décrivez les bénéfices à moyen et long terme qui devraient résulter de la mise en œuvre du projet. Mettez en évidence la contribution du projet aux objectifs stratégiques de l’organisme.

– Parties prenantes
Qui est l’entité propriétaire du projet. Qui est l’individu promoteur du projet (le responsable des résultats finaux du projet). Quels sont les bénéficiaires du projet. Qui sont les utilisateurs futurs. La puissance publique est-elle impliquée ?

– Périmètre
Mentionnez en termes très généraux ce qui entre dans le cadre du projet et ce qui en est exclu.

– Risques et facteurs de succès
Si à ce stade des risques sont déjà identifiés, citez-les. A l’inverse mettez en évidence les conditions à réunir pour favoriser le succès du projet.

Autres dénominations :
– Fiche projet

Note d'opportunité

A quoi sert la note d’opportunité ?
La note d’opportunité est un outil d’aide à la décision pour le maître d’ouvrage. Elle lui fournit une première évaluation de la pertinence du projet. Au vu de cette étude, l’instance de décision choisira d’arrêter là le projet ou de le poursuivre.

Qui remplit la fiche, à quel moment ?
La note d’opportunité peut être renseignée par un membre de l’organisme maître d’ouvrage ou par un acteur extérieur à l’organisme agissant dans le cadre d’une mission d’assistance à maîtrise d’ouvrage. En tout état de cause le rédacteur devra avoir un libre accès à de nombreuses informations dont certaines sensibles.

Modèle commenté de fiche descriptive de projet

Note d’opportunité de projet

– ici, le NOM DU PROJET –

– Description du projet
Faire un bref résumé de la fiche descriptive de projet.

– Analyse de cohérence
La première condition que doit remplir un projet est d’être en harmonie avec la raison d’être de l’organisme (entreprise, association, institution….) qui porte le projet, avec ses valeurs et avec son ambition stratégique. Ce paragraphe doit apporter la confirmation qu’il en est bien ainsi

– Avant-projet sommaire
Il est rare que l’on puisse juger de l’opportunité d’un projet sans avoir une idée même générale de ce qu’en sera le résultat. Un avant-projet sommaire a pu être nécessaire pour fournir une première approche. Si c’est le cas, citer les travaux qui ont été réalisés et leurs livrables : épures, maquettes, démonstrateurs, résultats d’études de marché ou d’enquêtes…

– Approche budget
L’avant-projet sommaire a également pour but de servir de base à une première évaluation du budget nécessaire. Cette première estimation du coût est toujours effectuée à l’aide de méthodes globales d’estimation qui fournissent une précision suffisante dans un objectif d’aide à la décision. Vous devez annoncer un budget, en insistant sur le caractère approximatif de la somme annoncée. Si possible donnez la fourchette de valeurs mini et maxi.

– Potentiel du projet
Si l’organisme maître d’ouvrage est une entreprise de droit privé, elle doit pouvoir espérer pour elle-même un bénéfice du projet. La plupart du temps ce bénéfice est un espoir d’un gain économique. Si c’est le cas vous devez produire une première approche de la rentabilité directe du projet. Un projet déficitaire peut néanmoins être légitime s’il promeut l’image de l’entreprise ou s’il est pour elle porteur de progrès (toute entreprise en phase de démarrage a joué cette carte). Le projet est dit porteur de progrès s’il permet à l’entreprise de s’approprier une nouvelle technologie, de conquérir de nouveaux marchés, etc… Un projet peut également être au service de la pérennité de l’entreprise. Pour les organismes publics ou du secteur associatif, le potentiel du projet est à chercher non dans son intérêt propre mais dans l’intérêt de son public cible.

– Analyse SWOT
L’étude d’opportunité comporte classiquement une analyse SWOT, qui préfigure les analyses de risque plus approfondies que l’on effectuera par la suite. L’acronyme SWOT vient des 4 mots anglais ci-dessous :
– Strengts, que l’on traduit par : Forces
– Weaknesses, que l’on traduit par : Faiblesses
– Opportunities, que l’on traduit par : Opportunités
– Threats, que l’on traduit par : Menaces
L’analyse SWOT consiste à résumer, généralement dans un tableau à deux lignes deux colonnes, ou comme dans l’exemple ci-dessous à l’aide d’une « mindmap »

Exemple d'analyse SWOT

Charte de projet

A quoi sert la charte de projet ?
A l’issue de la phase exploratoire le dossier d’étude d’opportunité est soumis à l’instance de décision. Celle- ci choisit de poursuivre ou pas. Si la décision de poursuivre le projet est prise, la charte de projet est rédigée. Elle formalise la décision de lancer le projet et fournit les données d’entrée de la phase de préparation. La charte de projet reprend une partie des rubriques de la fiche descriptive de projet et y rajoute les instructions à l’intention du chef de projet.

Modèle commenté de charte de projet

Charte de projet

– ici, le NOM DU PROJET –

– Commanditaire
Le commanditaire est la personne physique ou morale (ou le service de l’organisme) pour laquelle est réalisé le projet. Également appelée MOA pour « maîtrise d’ouvrage »

– Promoteur (Sponsor)
Le sponsor est la personne physique (l’individu), appartenant à la maîtrise d’ouvrage, et qui est garant du succès du projet

– Contexte
Il est important que tous les acteurs du projet aient une vision panoramique de l’environnement du problème : Le domaine concerné, les solutions existantes, l’historique du projet (travaux et études déjà réalisés, tentatives antérieures infructueuses), ce qui a motivé le commanditaire pour lancer ce projet. Le terme environnement peut couvrir notamment les domaines économique, commercial, concurrentiel, social, sociétal, technologique, juridique.

– Objectif
L’objectif du projet, c’est le résultat attendu par la MOA à la date de clôture du projet et que la MOE s’engage à lui fournir.

– But du projet
Le but, cest le pourquoi du projet, exprimé en terme de bénéfices attendus, à terme, par le commanditaire. Il est indispensable que les acteurs du projet aient bien compris ce qui motive leur « client », cela contribue à leur motivation et permettra, en cas de difficulté, de lui proposer des solutions alternatives.

– Enjeux
La plupart des parties prenantes du projet ont un enjeu (un intérêt personnel) dans la mise en œuvre du projet. Ces enjeux sont en général différents. Chaque acteur du projet sera motivé à la hauteur de ses enjeux personnels. Si cela vous semble important, citez ces enjeux.

– Impact
Les termes finalité et enjeux évoquent des conséquences positives et souhaitées du projet. Le mot impact désigne les effets positifs ou négatifs du projet, attendus (ou redoutés) dans les domaines environnemental, économique, sanitaire ou social.

– Gestion du projet
Qui est le chef de projet maîtrise d’œuvre. De qui est composée l’équipe de projet. Quel est le pouvoir du chef de projet. Dans quelles conditions peut-il solliciter les ressources de l’organisme ?

– Gouvernance du projet
Décrivez comment la MOA s’est organisée pour assurer la gouvernance (le pilotage stratégique) du projet, qui décide de quoi, à qui le chef de projet devra-t-il rendre compte et de quelle façon.

– Budget
Quel est, en unités monétaires ou à défaut en heures de travail des ressources, le budget du projet. Quelle est la part de ce budget qui sera consacrée à la phase de préparation.

– Echéancier
Quelles sont les dates-clé (jalons directeurs). A minima vous devez annoncer la durée de la phase de préparation et une estimation de la durée de la phase de mise en œuvre.

– Freins et facteurs-clé de succès
Il est important d’impliquer dès le début les parties prenantes du projet et de mettre en évidence les facteurs qui peuvent influer négativement ou positivement sur le déroulement et conditionner le succès. Par exemple la disponibilité des acteurs dont l’expertise vous est indispensable, l’accès aux sources d’information, la contribution de tous les membres de l’équipe, etc…

Dossier d'étude de faisabilité

A quoi sert le dossier d’étude de faisabilité ?
Le projet approche de sa phase de mise en œuvre. Le commanditaire va devoir prendre la décision en général irréversible de réaliser (ou pas) le système. Il a besoin de certitudes quant à l’atteinte de l’objectif. Vous devez passer en revue tous les domaines du projet et démontrer qu’il ne comporte pas d’impossibilité.

Modèle commenté de dossier d’étude de faisabilité

Dossier d’étude de faisabilité

– ici, le NOM DU PROJET –

– Cadrage du projet
Ce paragraphe reprend sans modifications et dans son intégralité la charte de projet, dans le but d’éclairer et de justifier les propositions qui vont suivre.

– Expression du besoin
S’il existe un référentiel du besoin, de type « Spécification Technique du Besoin » (STB) ou « Cahier Des Charges Fonctionnel » (CDCF) faire référence à ce(s) document(s). Dans le cas inverse, détaillez ici les exigences fonctionnelles, les solutions imposées et les exigences techniques.

– Présentation de la solution
Décrivez en détail le système prescrit : Son architecture générale, les principes techniques retenus, son fonctionnement, les composants matériels et logiciels choisis, son utilisation, sa maintenance…

– Justification des choix
Vous devez montrer en quoi les choix de conception proposés constituent la meilleure réponse au besoin exprimé. Une conception est toujours le résultat de compromis, n’hésitez pas à mettre en lumière les impasses que vous avez du faire et les fonctions que vous avez du dégrader, justifiez ces choix. Citez les autres solutions envisagées et les raisons pour lesquelles elles ont été écartées.

– Faisabilité technique
Un projet comporte très souvent un défi technique. A ce stade de l’étude vous devez apporter la preuve que le système donnera entière satisfaction. Dites quelles fonctions méritaient que l’on vérifie la possibilité de les réaliser. Quels moyens avez-vous mis en œuvre pous effectuer les vérifications (maquette, installation-pilote, appel à expert, calculs, enquête…). Quels résultats avez-vous obtenu ? S’il reste des incertitudes, annoncez-le très clairement de façon que le commanditaire prenne ses risques en connaissance de cause.

– Faisabilité économique
Quel est le budget du projet, en valeur monétaire ou en nombre d’heures de travail humain. S’il s’agit d’un projet à rentabilité contrôlée, donnez le détail de votre étude de rentabilité et ses résultats ( DRCI, VAN…)

– Faisabilité financière
Il est rare que le chef de projet ait à se prononcer sur le financement du projet. Si néanmoins c’était votre cas, indiquez les sources de financement (emprunt bancaire, autofinancement…), les conditions que vous avez obtenues et les garanties de financement.

– Faisabilité calendaire
La durée du projet est-elle compatible avec les exigences du commanditaire. Joignez un planning du projet (diagramme de Gantt)

– Faisabilité juridique
La faisabilité juridique vise à démontrer que ni les pouvoirs publics ni des tiers ne peuvent faire obstacle au déroulement du projet par une action en justice. Elle nécessite d’examiner les textes, normes, règlements, brevets… auxquels le projet pourrait contrevenir.

– Risques opérationnels
Le fait que la faisabilité soit démontrée ne garantit en aucune façon le succès du projet ! Il vous reste à faire l’inventaire des risques, à évaluer leur impact sur le projet, à les hiérarchiser et enfin à proposer un plan d’action chiffré. Ne sous-estimez ni l’importance de cette analyse de risques ni la charge de travail que cela va entrainer.

Plan de projet

A quoi sert le plan de projet ?
Si la charte de projet répond à la question « que va-t-on faire ». Le plan de projet, quant à lui, répond à la question « comment va-t-on s’y prendre pour obtenir le résultat attendu » Il définit la façon dont le projet sera exécuté, surveillé et contrôlé, puis fermé.

Modèle commenté de plan de projet

Plan de projet

– ici, le NOM DU PROJET –

CADRAGE DU PROJET
Ce paragraphe reprend les rubriques de la charte de projet.

EXPRESSION DU BESOIN
Ce paragraphe renvoie aux documents de définition du besoin : Cahier Des Charges Fonctionnel (CDCF) et/ou Spécification Technique du Besoin (STB).

PRESENTATION DE LA SOLUTION
Ce paragraphe décrit le système prescrit et renvoie si besoin à un document détaillé (Avant-Projet Détaillé (APD)).

METHODOLOGIE
Il est possible que l’instance de gouvernance ou l’équipe projet ait choisi une démarche de conduite de projet ou des outils méthodologiques particuliers : méthode agile dans un projet informatique, analyse de la valeur dans un projet d’innovation, Khefren ou GAR dans des projets publics… Dans ce cas il faut l’annoncer clairement.

PARTIES PRENANTES, ROLES ET RESPONSABILITES

– L’instance de décision
L’instance de décision (souvent désignée par le vocable de COPIL, pour Comité de Pilotage) regroupe les personnes en charge de contrôler le bon déroulement du projet au nom du commanditaire et de prendre les décisions stratégiques.

– Les contributeurs experts
Si l’équipe de projet ne regroupe pas la totalité des expertises nécessaires au bon déroulement du projet, il faut à ce stade avoir identifié les experts que l’équipe pourra solliciter le moment venu et les conditions (y compris financières) de cette collaboration.

– L’équipe projet
L’équipe projet comporte à sa tête un chef de projet et un seul, interlocuteur privilégié de la MOA. Préciser les domaines d’expertise, les rôles, les missions et les responsabilités de chacun des membres de l’équipe. Anticipez si besoin sur les sanctions encourues par un membre qui ne jouerait pas le jeu.

– Les utilisateurs finaux
Paradoxalement, les utilisateurs finaux sont souvent les grands oubliés du projet. Comment avez-vous prévu de recueillir l’avis des personnes impliquées dans l’exploitation et la maintenance (pour un système technique), des clients finaux (pour un service), du public (pour un projet d’équipement collectif) ou des acteurs impliqués dans un projet d’événementiel.

MANAGEMENT DU CONTENU

– Les choix techniques
Chaque fois qu’il y aura lieu de faire des choix, qui décidera et en fonction de quelle procédure. Où, comment et par qui seront enregistrés les relevés de décision ? Précisez clairement où se situe la frontière entre les décisions qui relèvent exclusivement de la MOE et celles pour lesquelles il faut obtenir l’accord de la MOA.

– La procédure de réception des livrables
En complément du paragraphe précédent décrivez les conditions de recette des livrables et du produit final : Le moment, le lieu. Précisez de quoi et de qui vous aurez besoin ? A quels tests procéderez-vous ?

MANAGEMENT DES TRAVAUX

– Les conditions d’exécution des travaux
Certains travaux sont-ils exécutés dans un lieu dont l’accès est règlementé ? Dans quelles conditions certains matériels sont-ils mis à votre disposition ?

– La sécurité (des personnes, des données et des biens)
Le projet met-il en danger la sécurité des personnes (équipe projet, utilisateurs, tiers….) ou les biens, matériels ou immatériels (données informatiques). Si c’est le cas quelles mesures de prévention et de protection sont mises en place, qui est en charge de veiller à leur application ?

MANAGEMENT DE L’ECHEANCIER

– Planning directeur
Le planning directeur du projet est un planning synthétique du projet limité aux principaux jalons (jalons directeurs) C’est l’un des principaux outils du pilotage stratégique. Optez pour une représentation la plus visuelle possible (ligne de temps, jalons et livrables)

– Planning opérationnel
Le planning opérationnel est l’outil privilégié du chef de projet. Il est souvent réalisé sous la forme d’un diagramme de Gantt. A ce stade du projet il doit être réalisé.

– Reporting de l’avancement.
A quelle fréquence ferez-vous ce reporting, de quelle façon, sur la base de quels documents ?

MANAGEMENT DES COUTS
Même si les dépenses de votre projet mesurées en euro sont faibles, ce n’est pas le cas pour la quantité de travail à fournir. Non seulement vous devez à tout moment savoir si vous êtes en avance ou en retard, mais vous devez aussi savoir, pour chaque tâche achevée ou livrable produit, si le coût (en euro ou en travail humain) de cette tâche ou de ce livrable est conforme aux prévisions.
– Vous devez dès à présent avoir estimé les charges de travail (par tâche ou par livrable) et surtout ensuite imposer aux membres de l’équipe une saisie quotidienne des temps passés pour chaque tâche ou livrable.
– Votre rapport de fin de projet devra faire état du retour d’expérience sur ce point.

MANAGEMENT DE LA COMMUNICATION

– La confidentialité :
Au cours du projet, la MOE aura-t-elle accès à des données confidentielles de la MOA. Si oui il faut mettre par écrit les engagements de la MOE en terme de respect du secret. Ce point mérite de faire l’objet d’un document particulier (accord de confidentialité) signé par le responsable hiérarchique de la MOE. Si un tel document existe il y est fait référence ici.

– Les Outils de communication opérationnelle
Comment se fera la communication entre les membres de l’équipe projet et entre le chef de projet et le commanditaire ? Quel média (papier, messagerie électronique, application collaborative…) Quel contenu, sous quelle forme, à quelle fréquence.

– Le reporting
De quelle façon et à quelle fréquence allez-vous informer l’instance de pilotage (COPIL) de la progression du projet ?

– Les réunions
Quels types de réunions prévoyez-vous d’organiser : réunions de pilotage, séances de travail de l’équipe projet, réunions techniques avec les différents acteurs.
Pour chaque type de réunion , quelle fréquence, quelle durée, quel lieu, qui organise (convocation, ordre du jour, compte-rendu) qui anime, qui décide et éventuellement suivant quelle procédure. Qui rédige les compte-rendu, qui les valide, comment et sous quel délai sont-ils diffusés, à quels destinataires ?

– La communication promotionnelle
Y a-t-il lieu d’organiser la communication promotionnelle du projet, auprès de quels publics (internes, externes ?), par quels médias ? Suivant quel calendrier, qui décidera du contenu et de la forme ?

MANAGEMENT DES RISQUES
Il s’agit de faire ici l’inventaire des événements susceptibles de perturber le bon déroulement du projet et d’évaluer l’impact de ces risques sur le projet. Ce paragraphe est suffisamment important pour faire l’objet d’un document particulier (plan de management des risques)
Quelques conseils pratiques : Il ne sert à rien de lister des risques si vous ne proposez pas des parades pour en éviter la réalisation ou en limiter l’impact. Soyez pragmatiques : vous risquez plus le crash d’un disque dur ou l’indisponibilité d’une ressource que la chute d’un Airbus sur votre bureau ! Soyez précis : « ne pas finir à temps » n’est pas un risque mais l’impact d’un risque sur l’objectif de délai. Chaque risque retenu comme significatif doit être surveillé par un pilote nommément désigné.

Bilan du projet

A quoi sert le bilan de projet ?
Il n’est pas faux de dire que le bilan de projet est le document le plus important du projet. Et pourtant combien de projets s’achèvent sans que l’on ne trouve le temps d’en faire le débrieffing. Résultat de cet état de fait : les équipes projet font et refont les mêmes erreurs, ou sont confrontés et se plaignent des mêmes problèmes récurrents. S’ensuit à long terme le découragement et l’aigreur, jusqu’à ce que les meilleurs éléments démissionnent pour rejoindre des équipes plus dynamiques. Le bilan du projet est l’occasion de mettre en valeur ce qui s’est bien passé et de se donner les moyens de modifier les procédures pour que les futurs projets ne souffrent pas des mêmes erreurs.

Modèle commenté de bilan de projet

Bilan du projet

– ici, le NOM DU PROJET –

REALISATION DES OBJECTIFS

Réalisation du produit
Les exigences du cahier des charges étaient-elles complètes, suffisamment précises et réalistes. Le produit est-il conforme à ce qui était prévu. Y a-t-il eu des modifications importantes, si oui qu’est-ce qui les a motivées.

Respect du délai
Le planning de référence a-t-il été respecté. S’il y a eu des retards, quelle en est la cause. Les retards sont-ils exceptionnels ou habituels.

Respect du budget
Le budget prévisionnel a-t-il été respecté. Sinon, quels postes budgétaires ont dérivé, pour quelles raisons : prévisions erronées, mauvaise maitrise ou aléas. Faut-il modifier les tables de coûts standards (ou créer de telles tables).

RECAPITULATIF DES PRINCIPAUX SUCCES ET PROBLEMES

Succès
Ne négligez pas cette rubrique, il ne faut jamais oublier de citer les points positifs, si vous ne le faites pas vous-même il est peu probable que d’autres le fassent pour vous.

Problèmes rencontrés
Quels problèmes sont survenus. avaient ils été pris en compte dans l’analyse de risque. Avaient-ils été anticipés. Les a-t-on déjà rencontrés dans les projets précédents. Que peut-on faire pour ne plus les rencontrer dans les projets futurs.

Situations imprévues
Des évènements imprévus ont-ils modifié le cours du projet, en bien ou en mal. Pour les évènements aux conséquences négatives, pouvait-on les anticiper.

Respect de la méthodologie
Si une méthode de travail particulière avait été préconisée (méthode agile, analyse de la valeur, gestion axée sur les résultats…) Ce choix était-il justifié, a-t-il été respecté. Faut-il généraliser cette méthode aux projets futurs. Faut-il aménager la méthode pour l’adapter à l’organisme.

PERCEPTION DES UTILISATEURS DU PRODUIT

Implication des utilisateurs dans la conception
Les futurs utilisateurs du système (opérateurs de production ou de maintenance, administrateurs informatiques, usagers d’un service, résidants d’un immeuble…) ont-ils été consultés et/ou représentés lors de la prescription et de la conception du système. Leur avis a-t-il été correctement recueilli et pris en compte.

Satisfaction des utilisateur
La satisfaction des utilisateurs dépend de paramètres objectifs (la façon dont le produit réalise les fonctions d’usage) mais aussi de critères subjectifs qu’il est important de prendre en compte.

ACTIONS D’AMELIORATION PROPOSEES

Amélioration des prévisions de durée et de coût
Est-il possible d’extraire des standards de temps et de coûts, ou d’affiner les données existantes. Les méthodes d’estimation doivent-elles évoluer.

Bonnes pratiques à généraliser
Chaque projet est l’occasion d’améliorer les pratiques. A condition que l’ensemble des chefs de projet adoptent les comportements vertueux.

Pratiques à modifier pour éviter les problèmes
Il est courant de dire que 80% des problèmes rencontrés au cours d’un projet s’étaient déjà manifestés dans les projets précédents. Cette situation est anormale et elle dénote une mauvaise exploitation du retour d’expérience. Faites l’analyse des problèmes rencontrés et des pratiques à faire évoluer pour qu’ils ne se produisent plus.

Autres dénominations :
– Rapport de fin de projet
– Rapport de clôture

Procès-verbal de clôture

A quoi sert le procès verbal de clôture ?
Le procès-verbal de clôture est le document administratif qui officialise la fin du projet. Il est en effet important que toutes les parties prenantes soient informées de la « mort » du projet, sans quoi certains continueront à imputer des dépenses ou à pointer des heures sur le projet, d’autres continueront de solliciter le chef de projet pour telle ou telle modification qui n’a plus lieu d’être. Le procès-verbal de clôture ne se substitue pas au bilan et n’en reprend pas le contenu. Il ne contient aucun jugement ni commentaire sur les succès et les échecs. Il ne contient aucune prescription sur ce qui derait être changé pour les projets à venir.

Modèle commenté de procès verbal de clôture

Procès verbal de clôture

– ici, le NOM DU PROJET –

Clôture des comptes
Il doit être clair pour chacun qu’aucune nouvelle dépense ne peut plus être imputée au titre du projet. Le système a basculé dans sa phase de vie, les dépenses qu’il nécessite doivent désormais être imputées sur les budgets d’exploitation et de maintenance.

Libération des ressources
Le chef de projet est désormais affecté à d’autres activités, voire à un autre projet. Il ne doit plus être sollicité et en tout cas n’a plus aucun pouvoir pour agir sur un projet qui n’existe plus. De la même façon, les contributeurs, les entreprises et autres ressources n’ont plus à travailler sur le projet.

Documentation du projet
Il s’agit ici de faire la liste des documents produits au cours du projet. Ou sont-ils archivés ? Les leçons apprises ont-elles donné lieu à un enregistrement dans la base de bonnes pratiques ?

Autres dénominations :
– Lettre de clôture
– Note de clôture
Documents du processus de Gestion du contenu
L’expression « Processus de gestion du contenu » peut paraître énigmatique. Il s’agit tout simplement de la suite organisée des actions contribuant directement à apporter la réponse au besoin. Autrement dit à livrer au client les produits et solutions conformes à ses attentes. Toutes les autres activités du projet sont au service de celle-ci.
Les documents de gestion du contenuVoici quelques explications sur le schéma ci-contre :
Le processus de gestion du contenu est ici découpé ici en 4 phases pour la partie projet, plus la phase d’exploitation post-projet.
– La phase de recueil des exigences est de loin la plus importante et la plus difficile à réaliser. A l’issue de cette phase le besoin doit être décrit sous tous ses aspects et de façon suffisamment détaillée pour ne laisser place à aucun malentendu, à aucune interprétation voire à aucune malhonneteté de la part d’un maître d’œuvre indélicat. A ce stade et suivant les projets, la solution peut être décrite soit uniquement en terme de fonctions à assurer (projets d’innovation) soit en terme de fonctions à assurer et de solutions imposées.
– La phase de définition du système consiste à élaborer la réponse au besoin, dans le total respect des exigences définies à l’issue de la phase précédente. Elle se termine par la fourniture d’un dossier qui décrit sans aucune ambiguïté le système à réaliser.
– La phase de réalisation consiste tout simplement à rendre concret le système prescrit. Lorsque le système comporte des éléments matériels et/ou logiciels, le modèle de développement adopté est le plus souvent le cycle en Vé qui permet de coordoner harmonieusement les activités de production, de test et d’intégration.
– La réalisation est suivie d’une phase de qualification parfois très longue et coûteuse (comme par exemple en aéronautique). Cette phase consiste à démontrer que le système est apte à l’usage et peut donc être mis entre les mains des utilisateurs.
– A ce stade le projet est achevé, le système entre dans sa phase d’exploitation qui durera souvent des années (produits industriels, moyens de production, logiciels…), voire des siècles (bâtiments, ouvrages d’arts…). Cette phase post projet a été rajoutée ici car il lui correspond des documents bien particuliers destinés notamment aux utilisateurs et aux personnes chargés du soutien à l’exploitation (maintenance, sécurité…)

Documents de la phase de RECUEIL DES EXIGENCES

Dossier d'expression initiale du besoin

A quoi sert le Dossier d’expression initiale du besoin ?
Dans l’intitulé de ce document le terme « expression initiale » est très important. Il s’agit, en tout début de projet, de recueillir la demande telle qu’elle a été exprimée par l’initiateur du projet. Ce dernier (client, chef de produit, responsable marketing, commercial, technicien, dirigeant de l’entreprise ou autre) est rarement capable d’identifier le réel besoin et de le décrire. Néanmoins il faut s’imposer cette « photographie » du besoin exprimé au temps zéro du projet. Par la suite cette demande sera toujours complétée, souvent modifiée (toujours dans l’intérêt du projet et avec l’accord du commanditaire).

Modèle commenté de Dossier d’expression initiale du besoin

Dossier d’expression initiale du besoin

– ici, le NOM DU PROJET –

Description du domaine

Avant de parler dans les paragraphes suivants du produit lui-même (que ce soit un objet technique, un service, une solution informatique…) Il est important de situer le domaine dans lequel ce produit doit s’insérer. Quelle est l’activité pratiquée par les futurs utilisateurs, qui sont-ils, quelles sont leur principales caratéristiques. Quel est l’environnement physique du futur produit. Quel est le vocabulaire particulier du domaine, etc… Si besoin on décrit le cadre règlementaire. Ce paragraphe doit rester assez général, son seul but étant de donner la vision panoramique qui permettra de mieux comprendre la suite.

Description du problème

Ce paragraphe décrit le problème pour lequel ce projet a été créé. On nomme les parties prenantes, leurs rôles et responsabilités. On décrit la situation existante, on explique en quoi elle est insatisfaisante. On décrit ce qui doit être amélioré, mais aussi ce qui doit être conservé. On décrit la situation-cible en insistant sur les bénéfices qu’elle va apporter aux différentes parties prenantes : par exemple meilleur confort, bénéfice financier ou économies, image améliorée, meilleure productivité ou tout autre avantage.

Description du produit attendu

Dans ce paragraphe on décrit brièvement le produit attendu. Il ne faut pas trop entrer dans le détail et surtout veiller à ne pas imposer de solutions. Si des études ou des essais ont été réalisés, s’il existe des maquettes, c’est ici qu’il faut en faire état. Les paragraphes suivants vont décrire avec plus de précision ce qui est demandé

Exigences fonctionnelles

Ce paragraphe préfigure ce qui deviendra, une fois enrichi et mis en forme, le cahier des charges fonctionnel (CDCF). Pour l’instant il ne fait état que des exigences explicitement citées par le commanditaire. Rappelons qu’une exigence correspond à un comportement attendu du futur produit, indépendamment du moyen par lequel ce comportement sera obtenu. Les exigences fonctionnelles décrivent ce que doit faire le produit pour dépondre au problème posé.
Chaque fois que le niveau de performance attendu est connu il faut en faire état (Par exemple: le temps de réponse maximal pour une transaction, le nombre d’utilisateurs simultanés d’un serveur, le nombre de colis traités par une installation de tri, leurs dimensions minimales et maximales, etc…).

Exigences opérationnelles

De même que les exigences fonctionnelles répondent au besoin des utilisateurs, les exigences opérationnelles répondent aux attentes des services support : maintenance, sécurité, administrateurs système… Rappelons qu’à ce stade on se limite aux exigences exprimées par l’initiateur du projet. Il est fort possible que celui-ci n’ait pas formulé d’exigences de ce type. Elles seront exprimées plus tard et souvent regroupées dans le cahier des charges général (voir plus loin ce document)

Autres dénominations :
– Spécification Minimale de Besoin (SMB)
– Fiche d’expression du besoin
Cahier Des Charges Fonctionnel (CDCF)

A quoi sert le CDCF ?
Le cahier des charges fonctionnel d’un produit décrit le besoin en terme de fonctions à assurer par ce produit. Il est rédigé en termes d’obligation de résultat et ne doit pas évoquer les moyens à mettre en œuvre ni les dispositifs qui réaliseront les fonctions. L’élaboration d’un cahier des charges fonctionnel a été formalisée en 1991 par l’AFNOR dans la norme NF X 50-151. Le cahier des charges fonctionnel traduit la demande du client-utilisateur, il doit être rédigé dans un langage et avec des termes compréhensibles par celui-ci.

Dans quel cas utiliser le CDCF ?
Le cahier des charges fonctionnel est un outil puissant et incontournable pour la création d’objets techniques comme les machines industrielles (marchés B to B) et produits grand public (marchés B to C)

Quelques règles pour la rédaction du CDCF
– Les fonctions sont hiérarchisées (d’où l’intitulé « arbre fonctionnel) : une fonction de haut niveau est décomposée en sous-fonctions, et ainsi de suite jusqu’à pouvoir caractériser la fontion de plus bas niveau.
– La rédaction de la fonction répond à un formalisme précis : chaque phrase commence par un verbe à l’infinitif et exprime une action ou un comportement du produit. Une bonne façon de ne pas se tromper est de formuler mentalement le début de phrase « Le produit doit….. »
– La colonne « critère » répond à la question « comment va-t-on vérifier que le niveau de performance du produit est satisfaisant pour la fonction considérée ».
– Dans la colonne « niveau » on indique, si possible sous une forme numérique, la valeur attendue pour le critère.
La colonne « Flexibilité » permet d’indiquer au concepteur s’il doit absolument atteindre la performance indiquée ou si, en cas de difficulté (et pour de bonnes raisons) la performance de la fonction peut être légèrement dégradée.

Modèle commenté de Cahier Des Charges Fonctionnel

Cahier Des Charges Fonctionnel

– ici, le NOM DU PRODUIT –

(On ne peut pas parler de CDCF du projet lui-même mais seulement du (ou des) CDCF du (ou des) produit(s) à créer à l’occasion du projet.)

Projet concerné : Intitulé du projet qui intègrera ce produit
Ci-dessous (en rouge) un exemple pour un avion léger de loisir biplaces
Pour information, ce type d’appareil appartient à la catégorie des ULM (Ultra-Légers Motorisés) de classe 3

Cahier des charges de l’Avion Léger de Loisir (ALL)

Arbre fonctionnelCactérisation des fonctions
Le produit "ALL" doit....CritèreNiveauFlexibilité
Transporter deux personnes et leurs bagages
Offrir un habitacle spacieuxHauteur x longueur x largeur1,5 x 2 x 1,4 mF1
Supporter la charge utileMasse300 KgF1
Atteindre en peu de temps un point distant
Etre rapideVitesse de croisière150 Km/hF2
Avoir un grand rayon d'actionDurée de vol à charge maximum2 heuresF1
Respecter la règlementation des ULM de classe 3 biplaces
Ne pas décrocher à basse vitesseVitesse de décrochageinférieure ou égale à 65 km/hF0
Avoir une puissance limitéePuissance maximale75 KwF0
Flexibilité : ............F0 : Impératif ............F1 : Négociable............F2 : Très négociable
Backlog de produit

A quoi sert le backlog de produit ?
Le backlog de produit (il n’existe pas de traduction satisfaisante en langue française de l’expression originale « product backlog ») est un outil de recueil du besoin d’apparition récente. Sa grande richesse est d’utiliser pour la description des fonctions une phraséologie bien plus naturelle que pour le CDCF (Cahier Des Charges Fonctionnel). Une remarque importante : on ne peut pas parler de backlog du projet mais seulement du (ou des) backlog(s) du (ou des) produit(s) à créer à l’occasion du projet.)

Dans quel cas utiliser le backlog de produit ?
Le backlog de produit est utilisé dans le domaine des technologies de l’information (informatique et internet). C’est l’un des outils de la méthode agile « SCRUM ». S’il est cité ici c’est que son utilisation peut être fortement conseillée pour les projets d’innovation, même lorsqu’il s’agit de créer un objet technique.

Quelques règles pour la rédaction du backlog de produit
– L’équivalent d’une fonction dans le cas du CDCF est ici une « user story », ce que l’on peut traduire par « récit utilisateur ». La rédaction d’une user storie est bien plus intuitive que la rédaction d’une fonction. Il suffit de se mettre à la place de l’un des acteurs concernés par le produit et de parler en langage naturel avec une phrase de la forme « En tant que……. je veux…… dans le but de….. » comme dans l’exemple ci-dessous
– Le critère de poids (ici de la valeur 1 à la valeur 100) mesure au choix soit la difficulté de réalisation (comme dans les méthodes agiles) soit l’importance pour l’utilisateur (comme dans la méthode d’analyse de la valeur)

Modèle commenté de backlog de produit

Backlog de produit

– ici, le NOM DU PRODUIT –

Projet concerné : Intitulé du projet qui intègrera ce produit

Ci-dessous (en rouge) un exemple pour une application de gestion des payes
.

Backlog du produit « site de vente en ligne »

IdUser stories : En temps que.... Je veux.... afin de ....PoidsPriorité
En tant que salarié, je veux....
1Déclarer mes heures travaillées afin d'être payé à temps131
2Pouvoir modifier ma feuille de temps afin de corriger une érreur202
En tant que supérieur hiérarchique, je veux....
3Approuver (ou pas) les feuilles de temps de mes employés afin d'éviter les fraudes et erreurs51
En tant que Responsable du personnel, je veux...
4Exécuter des rapports de synthèse afin de rendre des comptes hebdomadaires à la Direction402
5Créer de nouveaux comptes afin d'ajouter les nouveaux embauchés131
6Déclencher des rappels automatiques afin de relancer les retardataires83
7Archiver les feuilles de temps en vue d'une utilisation ultérieure31
Poids : - 1 - 2 - 3 - 5 - 8 - 13 - 20 - 40 - 100 -
Priorité : ............1 : Impératif ............2 : Négociable............3 : Peut être différé
Cahier Des Charges général

A quoi sert le Cahier Des Charges général
Contrairement au cahier des charges fonctionnel et au cahier des charges spécifique qui est différent pour chaque produit, le cahier des charges général regroupe les exigences permanentes des services support (maintenance, sécurité, administrateur système…). C’est un document « sur étagère ». Il est le recueil des exigences habituelles du maître d’ouvrage en matière de standards techniques : choix de composants, architecture du système, langages de programmation, charte graphique… Il fait état des règles à respecter et des performances à atteindre en terme de fiabilité, de maintenabilité, d’ergonomie, de sécurité et de sureté de fonctionnement. Il peut contenir également les exigences réglementaires et normatives. Le cahier des charges général évolue et s’enrichit par le retour d’expérience des projets qui s’achèvent.

Modèle commenté de Cahier Des Charges général

Cahier Des Charges général

– ici le nom de l’organisme maître d’ouvrage –

Type de produits : ici la famille de produits à laquelle s’applique ce document

Objet

Ce document énonce les exigences permanentes de l’organisme maître d’ouvrage pour ce qui concerne la conception, l’installation et la qualification des équipements dans lesquels il investit.

Conditions d’application

Ce paragraphe définit les conditions dans lesquelles les prescriptions du cahier des charges général doivent être prises en compte, ces conditions peuvent être rédigées comme suit :
– Le présent document constitue une obligation contractuelle lorsqu’il est référencé sur les commandes d’achat.
– Toute exception aux conditions exigées par ce document devra faire l’objet d’un accord écrit.

Exigences réglementaires, normatives et juridiques

Ce paragraphe cite les lois spécifiques et les standards particuliers à prendre en compte pour la conception du produit, par exemple :
– La règlementation en vigueur sur le territoire français (et éventuellement sur d’autres territoires)
– La directive européenne sur la compatibilité électromagnétique (CEM)
– Les textes sur la protection des données à caractère personnel
– La conformité à des référentiels propres à certaines industries (militaire, aéronautique, sanitaire, alimentaire…)
– Le respect des « règles de l’art » propre au métier (bâtiment, mécanique, informatique…)
– Le respect de la propriété intellectuelle de logiciels tiers intégrés au système. Le respect d’accord commerciaux…

Contraintes d’environnement

Ce paragraphe regroupe les informations sur l’environnement dans lequel va devoir s’insérer le nouveau dispositif.
– Environnement physique. Le concepteur doit savoir si le système aura au cours de son cycle de vie à être soumis à des conditions exceptionnelles de température, d’empoussièrement, de bruit, d’humidité, de vibrations, de chocs, voire à des atmosphères corrosives ou explosibles.
– Raccordement aux énergies et fluides, valeurs de tension électrique, de pression…
– Connexion aux réseaux informatiques existants
– Dimensions et poids maximum des sous-ensembles pour un matériel.
– Formats d’échanges de données pour les systèmes d’information. Interfaces avec des logiciels ou bases de données

Conventions de nommage

Ce paragraphe donne les règles à appliquer pour le choix des noms, codes et identifiants. Cela peut concerner :
– Le nom et les numéros de version des documents
– Pour les projets informatiques, le nom des tables, des champs et des vues des bases de données, les variables…
– En électricité, le repérage des câbles et des borniers

Exigences opérationnelles

On regroupe dans ce paragraphe tout ce qui concerne le concept « FMDS », à savoir fiabilité, maintenabilité et sécurité. Voici quelques commentaires sur ces exigences :
– Exigences de fiabilité. La fiabilité est l’aptitude du système à fonctionner sans incidents pendant une durée définie. L’unité de mesure de la fiabilité est le MTBF, en anglais mean time between failures, que l’on traduit en français par temps moyen de bon fonctionnement. On déterminera notamment les critères de robustesse auxquelles devra satisfaire le système.
– Exigences de maintenabilité. On appelle maintenabilité l’aptitude du produit à être maintenu ou remis en état de fonctionnement. Par exemple pour un bien matériel on imposera un temps moyen d’intervention pour panne. On fournira la liste des composants ou au minimum la liste des marques de composants pouvant être utilisés. Pour un système informatique on imposera le découpage en « briques logicielles » plus facile à tester qu’un ensemble monolithique, on demandera que des commentaires soient insérés dans le code. On pourra aussi imposer le traçabilité automatique des événements anormaux, des aides au diagnostic ou même l’auto-diagnostic. On prévoira des possibilités de fonctionnement en mode dégradé.
– Exigences de disponibilité. Le taux de disponibilité d’un système est le pourcentage de temps pendant lequel ce système est en état de fonctionnement, rapporté au temps pendant lequel on a besoin qu’il fonctionne. Il est possible par exemple d’exiger pour une installation industrielle un taux de disponibilité de X%.
– Exigences de sécurité. La sécurité concerne les atteinte à l’intégrité physique des personnes ou des biens dues à des événements involontaires. Le système ne doit pas soumettre les utilisateurs à de risques électriques, mécaniques, thermiques…
– Exigences de sûreté de fonctionnement. La sûreté concerne les incidents dus à des actes volontaires (actes d’incivilités, actes de malveillance, vols, agressions, actes terroristes). Le système doit être protégé contre les agressions prévisibles. Ceci concerne surtout les systèmes d’information.

Exigences d’utilisabilité

Les exigences regroupées dans ce paragraphe portent sur la relation entre le système technique et l’utilisateur.
– Ergonomie. L’ergonomie est un terme général qui date de bien avant l’informatique. Quelques exemples d’objets sur lesquels peuvent porter des exigences d’ergonomie : Les postes de travail (hauteur des sièges et plans de travail, éclairage, contrastes, position des organes de commande, position des objets devant être manipulés, postures et efforts, …), Les interfaces graphiques : facilité de compréhension et de mémorisation des commandes, convivialité, langue(s) et terminologie des interfaces, symboles…
– Affordance. L’affordance est la capacité d’un objet à suggérer sa propre utilisation.
– Exigences culturelles et politiques
– Dispositifs anti-erreurs (également nommés « Poka-Yoke » ou détrompeurs)
– Réaction de la part du produit (ou feedback). Il s’agit de la façon par laquelle le système informe l’utilisateur que l’action demandée a bien été réalisée.
– Accessibilité et utilisabilité par des personnes handicapées.

Exigences liées aux évolutions futures du système

La vie d’un système est ponctuée de modifications, d’évolutions, de mise à jour. Ces opérations doivent être anticipées, ainsi que la fin de vie du système.
– Exigences de scalabilité. La scalabilité est la capacité du système à maintenir son niveau de performance face à une montée en charge de production.
– Exigences d’évolutivité. Il est souvent nécessaire d’anticiper sur des évolution possibles du dispositif. Cela peut se traduire par l’obligation faite au concepteur de laisser de la place libre dans un coffret électrique, de surdimensionner tel ou tel composant, de prévoir des emplacements mémoire libres…
– Exigences liées au retrait de service. Le retrait de service d’un système peut être plus ou moins coûteux suivant la façon dont il a été conçu. Il faut prévoir la dépollution, le recyclage ou même la réutilisation de tout ou partie du système.
– Exigences de portabilité des programmes informatiques.

Standards d’image et de marque

La plupart des grandes entreprises imposent que les matériels dans lesquels elles investissent portent l’identité visuelle de la marque.
– Logo, couleurs pour les matériels
– Charte graphique pour les documents

Exigences liées à la qualification et à la mise en service

– L’acceptation du produit par son propriétaire (souvent appelée recette) se passe généralement en deux temps : une validation avant mise en service (la recette provisoire) et une validation en condition d’exploitation (la recette définitive). Cette procédure étant la même quel que soit le projet il est logique d’en faire état dans le cahier des charges général. Le produit est qualifié lorsqu’il a satisfait aux recettes provisoire puis définitive.
– De la même façon les conditions dans lesquelles vont se passer les travaux d’installation et de mise en service du système méritent d’être précisées. Par exemple, dans quelles conditions la MOA donne-t-elle accès à ces locaux, doit-elle fournir une assistance ou mettre des moyens techniques à disposition. Est-il demandé une formation des exploitants et du personnel de maintenance. Si des réserves subsistent après recette définitive, comment se passe la « levée des réserves ». A quel moment se matérialise le transfert de propriété.

Documentation de la solution

Ne doivent être cités ici que les documents qui concernent directement le système et qui de ce fait font partie de la fourniture. Il est nécessaire de définir le format des documents (papier, numérique ou en ligne), les règles de traçabilité, de pagination. Les documents concernés sont en général les suivants :
– Dossier technique de la solution : plans, schémas et nomenclatures
– Manuel d’installation et configuration
– Consignes de sécurité
– Manuel d’exploitation
– Manuel de maintenance faisant état de la liste des composants de rechange à tenir en stock, de la liste des outillages nécessaires pour le démontage et les réglage, des modes opératoires et procédures de sécurité.

Autres dénominations :
– Exigences générales
– Spécification technique générale
– Cahier des charges technique

Cet article comporte 43 commentaires
  1. bonjour merci beaucoup pour ce site vraiment il est très enrichissant . SVP je me suis chargée de faire la gestion de projet au sein d’une industrie et j’ai besoin des exemples des documents associés à chaque étape de projet(initiation, planification,……..) je sais que ça reste confidentiel mais seulement des fichiers (word , excel..)qui peuvent être utiles pour ma recherche.
    merci.

    1. Bonjour Belaid

      Malheureusement je ne dispose pas de documents-type aux formats standard. C’est à chaque entreprise de créer les siens en fonction de la typologie de ses projets, du degré de culture projet des acteurs, des objectifs de la direction… Par contre je vous encourage à vous inspirer de cette page.
      Bon travail !

      1. Bonjour,
        Je suis également à la recherche de ce type de document devant en mettre en place dans la société où je suis.
        Voici mon adresse mail : chef__r@hotmail.fr
        Il y a deux _ entre le f et le r.
        Merci de votre aide.
        Cordialement,

      2. Bonjour Mrahmouni
        Moi aussi je suis très intéressé par ce genre de document stndard afin de les adapter aux exigences des futurs projets que je dois piloter dqns peu de temps.merci jlevoumba@gmail.com
        Salutations

      3. j’ai en charge la gestion d’un projet que j’ai initié et j’ai besoin des exemples des documents associés à chaque étape de projet(initiation, planification, etc ….). je souhaite que tu m’apporte ton aide.
        Merci !

    1. Bonjour Juliette
      Ce site traite uniquement de gestion de projets, pour votre question voyez plutôt les sites et blogs traitant d’agriculture et d’agro-alimentaire.
      Bonne chance dans votre recherche
      Cordialement

    1. Bonjour Maiga
      Pour ce qui est d’un exemple de projet, s’il s’agit d’un vrai projet c’est à ma connaissance introuvable (les projets d’entreprise sont confidentiels) et pas forcément transposable à votre cas. Reste les études de cas. C’est l’option que j’ai adopté pour mon livre « Comprendre la planification de projet », basé sur un cas fictif facilement compréhensible. Cela dit mon livre ne parle que de la planification, le management de projet c’est bien plus large..
      Bonne chance dans votre recherche.

  2. Merci beaucoup pour très grande contribution dans la gestion de projets. ces modèles sont très utiles, chacun trouvera un document de base assez parlant qui pourra être enrichi.

  3. Bonjour,
    J’ai un travail à faire concernant la documentation d’un projet.Est ce que on trouve juste les documents du processus de coordination ou il y en a d’autres que je dois intégrer dans mon travail.
    Si vous avez un autre fichier qui porte sur cel je serai très reconnaissante.

    Merci bien.

    1. Bonjour

      Il y a de nombreux documents dans la vie d’un projet. Je pense que vous pouvez faire état des documents de gestion du contenu, notamment CDCF (Cahier des charges fonctionnel), STB (Spécification technique du besoin) et Procès-verbal de recette. Peut-être aussi les documents de gestion des risques, le plus important étant le Registre des risques. Je pense qu’un inventaire complet vous mènerait beaucoup trop loin.

      Cordialement

      1. Bonjour,

        Je vous remercie pour votre retour. Je suis sidérée par la qualité du site. J’apprécie énormément vos cours ainsi que l’intérêt personnalisé que vous portez à l’égard de chaque commentaire écrit. Je vous remercie. Vous êtes pour moi l’exemple.

  4. Au Top !!!!

    Votre Topic a répondu a toutes les questions que je me posais sur mon projet d’étude !
    Certain professeurs devraient vraiment se poser les bonnes questions sur la manière dont ils enseignent.

    Dans tous les cas votre document est très bien de mon point de vue, clair, nette et directe.

    Merci

    1. Bonjour Pegaze

      Je suis ravi que vous ayez trouvé sur ce site la réponse à vos questions. C’est le cas de beaucoup d’étudiants, de professionnels… et même de professeurs !

      Bon succès dans vos études.

  5. Bonjour professeur ,

    en cherchant sur internet le format et les différents livrables d’un projet informatique à maitriser par un AMOA ,

    je suis tombée sur votre site , et là je vois que c’est le site à mon ex-professeur !

    En fait , j’ai trouvé (avec ma modeste compréhension) suite à plusieurs petites recherches que les livrables les plus importants sont les suivants (je vous laisse me corriger s’il vous plait) :

    1.EDB : c’est le document qui explicite le besoin d’un MOA ou client
    2.EDF(Etude de faisabilité) : Un document réalisé par un MOE permettant de démontrer que le projet ne comporte aucune impossibilité (ou le document d’avant vente?)
    3.CDC : un document contractuel entre le client et le fournisseur pour formaliser le besoin auquel le MOE ou le fournisseur doit répondre
    4.SFG : après validation du CDC, ce document est rédigé par le MOA pour décrire les besoins Métiers
    5.SFD : après validation du SFG par le MOA, ce document est rédigé par le MOE pour décrire de façon détaillée les spécifications fonctionnelles et techniques du projet(contient le diagramme de GANTT ou la roadmap)
    6.STD : Après validation du SFD par les Métiers,ce document permet de décrire techniquement comment seront réalisés les besoins Métiers
    7.Plan de test : est un document recensant les différents processus de test à suivre ainsi que l’ensemble des documents de tests (FTU,..)
    8.DAT(dossier d’architecture technique) : permet de décrire l’architecture logicielle et matérielle pour le déploiement de la solution
    9.PV de recette : est un document à valider par les Métiers contenant tous les livrables finaux pour déclencher la mise en production du projet
    10.Dossier de test : contient les différents plans de tests et leurs fiches
    11.Manuel utilisateur : c’est un document qui permet de guider le commanditaire dans l’utilisation de la solution

    n.b : des formats de livrables , si vous en avez ils me seront très utiles

    Merci d’avance de votre aide

    1. Bonjour cher ancien élève !
      J’ai déplacé votre commentaire vers cette page qui me paraît plus appropriée à votre sujet.
      Je suis globalement d’accord avec votre inventaire. Je prépare un nouveau paragraphe pour cette page qui portera sur le processus de gestion du contenu du projet qui décrira la plupart des documents dont vous faites état.
      Juste quelques remarques :
      1- L’acronyme CDC ne me plait pas beaucoup car on ne sait jamais si c’est le cahier des charges du projet ou le cahier des charges fonctionnel (CDCF) de la solution.
      2- Concernant la SFD (Spécification Fonctionnelle Détaillée) je trouve anormal d’y trouver le diagramme de Gantt. C’est mélanger le processus de gestion du projet (Gantt) et le processus de gestion du contenu (la solution à produire). Le terme « Fonctionnel » exprime bien le fait qu’il s’agit des fonctions du produit et rien d’autre.
      3- Au manuel utilisateur j’ajouterai un manuel de maintenance (ou dossier technique) , les préoccupations de l’utilisateur au quotidien sont bien différentes de celles du développeur qui aura un jour à mettre le nez sous le capot.
      Je n’ai pas pour l’instant de documents-type à vous fournir, c’est en cours de préparation.
      Cordialement

      1. Bonjour ,

        merci pour votre réponse rapide et surtout joyeuses fêtes !

        =>j’attendrai les ‘documents-type’ avec impatience

        Franchement le diagramme de GANTT (ou la roadmap) j’en ai mis dans mon dernier SFD sachant que je me suis inspirée d’un SFD d’un ancien projet !

        En fait, il y avait trois documents contenant ce diagramme (le premier document de planification MS project , le SFD et le ‘project status report’ qu’on affichait à chaque RAP pour voir l’avancement)

        A votre avis le diagramme de gantt on le met dans quel document dans la liste que je vous ai citée précédemment ?ou il est indépendant de tout ça ?

        Merci d’avance

        Cordialement

  6. Bonjour, Je vous félicite pour votre site, une mine d’or.

    Pourriez-vous me dire si les utilisateurs ayant un abonnement Premium ont-ils accès à d’autres documents que les « Les documents du processus de coordination » contenus dans la rubrique « Modèles de documents » ?

    Est-ce que les abonnés Premium voient « plus de choses » que les non abonnés concernant les 9 « Les documents du processus de coordination ». Des versions plus longues ?

    Dans votre réponse Armand (19/05/2016 at 8 h 47 min), vous aviez écrit qu’un Cahier des charges était en cours de rédaction. Y-a-t-il du nouveau sur ce sujet ?

    Merci

    1. Bonjour Pur

      Merci pour vos compliments sur le site.

      Pour la page « Modèles de documents » les abonnés PREMIUM n’ont pas plus d’informations que le visiteur. Les contenus PREMIUM sont systématiquement signalés.
      Je travaille actuellement sur les documents du processus de gestion du contenu (dont les cahiers des charges) et du processus de gestion des risques. Je peux éventuellement vous donner à titre privé un accès à la page brouillon, mais vous risquez d’être déçu : qui dit brouillon dit… Brouillon.
      Cordialement.

  7. Merci pour cet article très complet.. Je dois vendre à ma direction un projet un peu ambitieux de mise en place d’une gestion documentaire efficace et vos modèles vont me permettre d’organiser mes idées et d’être, je l’espère, plus efficace dans ma communication.

    1. Bonjour
      Je suis heureux que ces modèles de documents vous soient utiles.
      Bon succès dans votre projet de gestion documentaire.
      Cordialement

    1. Bonjour Catherine
      Oui, le plan-type des documents de projet peut parfaitement être adapté pour un mémoire. Voici quelques conseil que je donne toujours à mes étudiants :
      – Si un intitulé de paragraphe ne vous semble pas pertinent, supprimez le paragraphe sans regret.
      – Pas de généralités, soyez factuelle et précise. Vous décrivez VOTRE travail.
      – N’utilisez jamais d’abréviations ou d’acronymes sans les avoir explicités auparavant.
      – Commencez toujours par une description « panoramique » du contexte de votre travail. Les étudiants bâclent souvent ce paragraphe qui est pourtant, à mon sens, le plus important puisqu’il englobe et qu’il éclaire tout le reste.
      – N’abordez jamais un point dont vous doutez de la pertinence, ou que vous n’êtes pas capable de développer et de défendre.
      – Faites vérifier l’orthographe !
      Bon mémoire et bonne soutenance

  8. bonjour

    svp j’aimerais savoir si le cahier des charges n’est pas obligatoires ?
    et aussi ou est ce qu’elle se situe dans ces différents modeles?

    merci

    1. Bonjour Armand.
      Votre question appelle plusieurs éléments de réponse :
      – Le Cahier des charges ne figure pas encore sur cette page car il n’appartient pas au processus de coordination mais au processus de gestion du contenu. Cette partie est en cours de rédaction.
      – L’expression « Cahier des charges » est un peu large, il faut distinguer notamment le cahier des charges fonctionnel, la spécification technique du besoin, les cahiers des charges techniques…
      – Quant au mot « obligatoire », ne confondons pas « obligatoire » et « indispensable ». Le cahier des charges est indispensable chaque fois qu’une entité confie une mission à une autre entité. Par contre on ne peut pas dire que le cahier des charge soit « obligatoire » dans les marchés privés, au sens ou aucun texte règlementaire ne l’impose. Beaucoup de marchés privés sont passés de gré à gré, sur la base d’habitudes ou de standards non écrits. Je ne dis pas que cette façon de faire soit à conseiller mais elle existe.
      – Comme je le note plus haut, le cahier des charges intervient chaque fois qu’une entité confie une mission à une autre. C’est notamment le cas au moment de déclencher la mise en œuvre du projet.
      Cordialement

  9. Bonjour,

    Informations très interessantes. j’aimerais avoir un exemple pour monter un projet de formation continue.
    Merci pur votre info.

    1. Bonjour Valérie
      Je n’ai pas d’exemple formalisé sur les projets dans le domaine de la formation continue. De plus votre question est très générale : Vous voulez créer un organisme de formation continue ?
      Cordialement

  10. Bonjour Michel Estève,

    Merci beaucoup pour votre site absolument génial qui nous renseigne sur le management.

    Je suis en train de travailler sur un projet du lancement d’une société et j’aimerais que vous m’aidiez sur les éléments à prendre en compte sur le bilan des risques.

    Dans l’attente de votre retour.

    Cordialement,

    Cédric KWIDI

    1. Bonjour Cédric
      Je vous propose de télécharger et d’exploiter la fiche http://methodo-projet.fr/wp-content/uploads/2016/02/Modèle_d-affaire_Pro.pdf que j’ai créée à l’intention des porteurs de projet d’innovation créateurs d’entreprise. Votre question sur les risques est extrêmement pertinente : je recommande à tous les créateurs de travailler sérieusement, avec un maximum de pragmatisme et de réalisme sur les risques stratégiques (concrètement : en considérant que j’arrive au bout de mon projet, qu’est-ce qui pourrait faire qu’il ne m’apporte pas les bénéfices que j’en attends. Par exemple pas de rentabilité (pas assez de clients ou des couts trop élevés), manque de trésorerie, procès avec un concurrent ou un client….). Bien entendu à chaque risque identifié il faut l’évaluer et si nécessaire lui apporter des réponses.
      Bon succès dans votre projet

  11. bonjour je suis très intéressé de vos modèles, et j’aimerai avoir une idée sur le comment budgétiser mon projet en informatique multimédia. au faite le but de mon projet est de créer un petit entreprise qui vente des produits informatiques, de faire la maintenance réseau, de faire du photocopie, scanner, reliure,en bref tout ceux qui est informatique multimédia

    1. Bonjour Amady
      Premier élément de réponse, vous pouvez télécharger la fiche http://methodo-projet.fr/wp-content/uploads/2016/02/Modèle_d-affaire_Pro.pdf . Elle est conçue pour les projets d’innovation mais elle pose tous les problèmes sur lesquels vous devez travailler. Dons votre cas vous allez vous insérer dans un paysage concurrentiel existant, il est important de faire (ou de faire faire par un spécialiste) une étude de marché quantitative. Sur le plan économique vous devez au minimum faire un budget d’investissement (tout ce que vous devez dépenser avant de vendre la première cartouche d’encre) et un compte de résultat prévisionnel sur au moins deux ans. Un dernier conseil : faites-vous accompagner dans votre projet par la chambre de commerce (ou la chambre des métiers) à laquelle vous allez être rattaché.
      Bon succès dans votre projet

    1. Bonjour Myke
      Malheureusement non, et pour une raison toute simple : il faudrait que les templates soient au format Word pour être utilisables par le plus grand nombre, et pour ma part je n’utilise pas Word (je suis resté fidèle à Ragtime, logiciel génial mais très peu connu).
      Désolé

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Back To Top