CMPI - Conduite et Maîtrise des Projets Informatiques (Didier Hallépée)

auteur : Didier HALLÉPÉE
Titre : CMPI - Conduite et Maîtrise des Projets Informatiques
éditeur : Les écrivains de Fondcombe
parution : 2010
Disponible sur Kindle

axiologie - du grec axia, la qualité – science de la qualité

On peut réaliser avec succès un projet informatique sans utiliser de méthode de conduite de projet. Dans ce cas, c’est l’expérience du chef de projet qui permet de faire face à tous les événements inattendus qui pourraient en entraver la bonne fin.

Cependant, dès que le projet dépasse une certaine ampleur, les capacités personnelles du chef de projet ne lui permettent plus de tout contrôler seul.

En outre, les différents responsables concernés tant chez le client que chez le réalisateur ont besoin d’être informés tout au long du projet afin de savoir que le contenu du projet sera conforme à leurs attentes et respectera les budgets envisagés.

Il est également nécessaire d’avoir des processus qui permettent aux différents acteurs un processus de décision éclairé et rapide face aux différents aléas.

Enfin, il faut aussi être en mesure de fournir tous les éléments permettant de pérenniser les investissements réalisés (organisation de la maintenance, de la production, capitalisation des résultats).

L’utilisation d’une méthode de conduite de projets permet de faciliter la maîtrise de ceux-ci et diminue notablement le coût des non conformités. Elle représente une économie importante sur le coût réel des projets.


Le jeune chef de projet qui souhaite évoluer vers une responsabilité de directeur de projet a bien du mal à trouver une méthode de référence facilement accessible. Il existe bien sûr des formations internes propres aux grandes SSII ou des méthodes reconnues commercialisées auprès des grands comptes. Par leur prix ou leur disponibilité, celles-ci ne sont pas accessibles aux petites ou moyennes structures.

La méthode CMPI, fruit de plus de 20 années d’expérience a été rédigée pour permettre le transfert de ces connaissances.

Elle est particulièrement bien adaptée aux petites et moyennes structures et à l’organisation de formations légères de chefs de projet.


La méthode CMPI est riche. Elle ne doit cependant pas être appliquée de façon dogmatique. Son application doit être adaptée à la taille et à l’importance des projets concernés. La souplesse et l’adaptabilité de la méthode CMPI sont un de ses avantages majeurs. Le maître mot dans l’application d’une méthode est pragmatisme.


L’application de la méthode CMPI s’appuie principalement sur les modèles de documents fournis avec celle-ci. Grâce au retour d’informations en provenance des utilisateurs de la méthode, les modèles de documents sont régulièrement enrichis, et de nouveaux modèles sont ajoutés chaque fois qu’un nouveau besoin est identifié. Cette évolutivité est également un avantage majeur de la méthode.

On peut réaliser avec succès un projet informatique sans utiliser de méthode de conduite de projet. Dans ce cas, c’est l’expérience du chef de projet qui permet de faire face à tous les événements inattendus qui pourraient en entraver la bonne fin.

Cependant, dès que le projet dépasse une certaine ampleur, les capacités personnelles du chef de projet ne lui permettent plus de tout contrôler seul.

En outre, les différents responsables concernés tant chez le client que chez le réalisateur ont besoin d’être informés tout au long du projet afin de savoir que le contenu du projet sera conforme à leurs attentes et respectera les budgets envisagés.

Il est également nécessaire d’avoir des processus qui permettent aux différents acteurs un processus de décision éclairé et rapide face aux différents aléas.

Enfin, il faut aussi être en mesure de fournir tous les éléments permettant de pérenniser les investissements réalisés (organisation de la maintenance, de la production, capitalisation des résultats).

L’utilisation d’une méthode de conduite de projets permet de faciliter la maîtrise de ceux-ci et diminue notablement le coût des non conformités. Elle représente une économie importante sur le coût réel des projets.


Le jeune chef de projet qui souhaite évoluer vers une responsabilité de directeur de projet a bien du mal à trouver une méthode de référence facilement accessible. Il existe bien sûr des formations internes propres aux grandes SSII ou des méthodes reconnues commercialisées auprès des grands comptes. Par leur prix ou leur disponibilité, celles-ci ne sont pas accessibles aux petites ou moyennes structures.

La méthode CMPI, fruit de plus de 20 années d’expérience a été rédigée pour permettre le transfert de ces connaissances.

Elle est particulièrement bien adaptée aux petites et moyennes structures et à l’organisation de formations légères de chefs de projet.


La méthode CMPI est riche. Elle ne doit cependant pas être appliquée de façon dogmatique. Son application doit être adaptée à la taille et à l’importance des projets concernés. La souplesse et l’adaptabilité de la méthode CMPI sont un de ses avantages majeurs. Le maître mot dans l’application d’une méthode est pragmatisme.


L’application de la méthode CMPI s’appuie principalement sur les modèles de documents fournis avec celle-ci. Grâce au retour d’informations en provenance des utilisateurs de la méthode, les modèles de documents sont régulièrement enrichis, et de nouveaux modèles sont ajoutés chaque fois qu’un nouveau besoin est identifié. Cette évolutivité est également un avantage majeur de la méthode.


Les documents essentiels sont également disponibles en anglais.

« Les problèmes d’aujourd’hui viennent des solutions d’hier. »
Peter SENGE

1. Les validations
Un projet informatique se découpe en phases, étapes et tâches.

D’une part, chaque étape (et donc chaque phase) ne peut être initialisée que si les pré-requis sont réunis.

D’autre part, chaque étape (et donc chaque phase) produit des livrables.

Les pré-requis d’une étape sont en général les livrables des étapes précédentes.

Il est donc important que les résultats des étapes précédents soient valides pour que les travaux effectués à partir de ceux-ci ne soient pas remis en cause (perte de temps et surcoûts).

C’est pourquoi, à la fin de chaque étape et de chaque phase, un processus de validation permet d’offrir un certain niveau de garantie aux intervenants des étapes suivantes.
1.1. Qui valide ?
La responsabilité des validations est prévue lors de la mise en place des différents comités.

Le prononcer formel des validations est de la responsabilité du Comité de Pilotage sur avis du Comité de Suivi de Projet.

Chaque fois que la validation d’une phase entraîne un engagement de dépenses significatif ou comprend une décision de fond (poursuivre ou arrêter le projet, impacts importants sur l’entreprise, etc.), l’avis formel du Comité Directeur de Projet est nécessaire.

Selon l’organisation de l’entreprise et le niveau de responsabilité des différents intervenants, le Comité de Pilotage peut déléguer s’il le juge nécessaire le prononcé de tout ou partie des validations au Comité de Suivi de Projet et au Comité d‘Exploitation.

Certains livrables doivent en outre être validés par les spécialistes auxquels ils sont destinés : dossiers utilisateurs par leur représentant à la maîtrise d’ouvrage, dossiers de production par le représentant de la Production, dossiers de maintenance par le représentant de la maintenance, etc. Il est bon que cette validation formelle soit explicitement prévue, même si ces personnes sont représentées au sein des différents comités.
1.2. La préparation des validations
Le Directeur de Projet et le Comité de Suivi de Projet sont en permanence informés de l’état d’avancement des travaux en cours. Ils sont donc à même de juger de l’état de finition des différents livrables prévus.

Il leur appartient donc d’organiser tout au long du projet une diffusion préparatoire des éléments suffisamment avancés vers les personnes ayant à se prononcer, afin que les avis soient recueillis au plus tôt et que le prononcer des validations soit l’aboutissement naturel d’un travail commun plutôt qu’une tâche supplémentaire en fin d’étape.
1.3. Le contenu des validations
En fin d’étape, chacun des livrables prévus doit être validé (éventuellement sur avis des spécialistes concernés lorsque leur aspect technique n’est pas de la compétence du comité).

Tant que tous les livrables de l’étape ne sont pas validés, la validation formelle de l’étape ne peut être prononcée.

Tant que toutes les étapes de la phase ne sont pas validées, la validation formelle de la phase ne peut être prononcée.

Lorsqu’une phase ou étape est formellement validée, l’étape ou la phase suivante peut être commencée.

Le Comité de Pilotage (ou par délégation le comité de Suivi de Projet) peut prononcer une validation partielle d’étape autorisant la poursuite du projet. Ceci ne dispense pas de mener à bonne fin les travaux conduisant à la validation formelle de l’étape concernée. L’autorisation de poursuivre le projet sur une validation partielle doit préciser les tâches concernées et les limites de cette autorisation. En effet, il s’agit implicitement d’une autorisation de dépenses sans qu’il y ait garantie que les travaux concernés ne seront pas remis en cause. Dans sa décision, le Comité compare le risque encouru avec l’impact qu’aurait une équipe bloquée dans son avancement sur les coûts et les délais.
2. Les recettes formelles
Les validations assurent que le déroulement du projet est conforme : toutes les tâches prévues sont effectuées, tous les livrables sont fournis et leur contenu semble conforme aux attentes.

Ceci ne suffit pas pour garantir que l’ensemble du projet est cohérent, conforme aux engagements contractuels pris à l’issue de la phase de lancement et que les applications présenteront les qualités techniques attendues.

C’est pourquoi il a été prévu dans le déroulement du projet des jalons de recette permettant d’offrir toutes les garanties de bonne fin attendues :

 Contrôle de Livraison des Développements (CLD)
Effectué sous la responsabilité du Maître d’Œuvre à la fin des étapes de développement et test. Ce contrôle a pour but de garantir la complétude des développements conformément aux spécifications ainsi que leur bon fonctionnement en environnement de test avec jeux d’essai de test.

Cette conformité est matérialisée par le Certificat de Contrôle de Livraison.

 Vérification de Conformité des Développements (VCD)
Effectué sous la responsabilité du Maître d’Ouvrage après les étapes de développement et test. Ce contrôle a pour but de garantir la conformité des développements vis à vis des spécifications ainsi que leur bon fonctionnement en environnement de recette avec jeux d’essai de recette.

Cette conformité est matérialisée par le Certificat de Conformité des Développements.

 Vérification de Conformité de l’Architecture (VCA)
Effectué sous la responsabilité du responsable de Production durant l’étape d’intégration. Ce contrôle a pour but de garantir la conformité de l’architecture (matériels, logiciels système, utilitaires, progiciels) vis à vis des spécifications ainsi que sa bonne installation.

Cette conformité est matérialisée par le Certificat de Conformité de l‘Architecture.

 Vérification d’Aptitude Usine (VAU)
Effectué sous la responsabilité du responsable de Production à la fin de l’étape de mise en production. Ce contrôle a pour but de garantir la capacité de l’ensemble à fonctionner en environnement de production sur un ensemble représentatif d’utilisateurs et de données de production (mesure des performances).

Cette conformité est matérialisée par le Certificat d’Aptitude Usine.

 Vérification d’Aptitude au Bon Fonctionnement (VABF)
Effectué sous la responsabilité du Directeur de Projet (en collaboration avec les équipes de production) à la fin de l’étape de mise en production. Ce contrôle a pour but de garantir la capacité de l’ensemble à fonctionner en environnement de production sur un ensemble représentatif d’utilisateurs et de données de production (mesure des performances).

Cette conformité est matérialisée par le Certificat d’Aptitude au Bon Fonctionnement.

 Validation en Service Régulier (VSR)
Effectué sous la responsabilité du responsable de Production à la fin de l’étape de mise en production Ce contrôle a pour but de vérifier le bon fonctionnement de l’ensemble en environnement de production et en dimension réelles (validation des performances).

Cette conformité est matérialisée par le Certificat de Validation en Service Régulier.

 Vérification de Conformité de la Sécurité (VCS)
Effectué sous la responsabilité du Comité de Sécurité à la fin de l’étape de mise en production Ce contrôle a pour but de vérifier la conformité des dispositions de Sécurité et leur efficacité. C’est au cours de cette étape que peuvent être effectués des tests d’intrusion.

Cette conformité est matérialisée par le Certificat de Conformité de la Sécurité.
3. Le cycle des recettes
À l’occasion de ces différentes recettes, des dysfonctionnements ou des non conformités peuvent être identifiées.

Chacun de ces incidents est noté, documenté et classifié en fonction de sa gravité :
 Bloquant
Empêche le bon déroulement de l’étape de recette en cours
 Gênant
N’empêche pas le bon déroulement de l’étape de recette en cours, mais perturbe le fonctionnement de l’ensemble.
 Mineur
N’empêche pas le bon déroulement de l’étape de recette en cours et ne perturbe pas le fonctionnement de l’ensemble.

Une correction palliative peut être apportée à chaud pour permettre la continuité des recettes.

Dans tous les cas, les incidents doivent être résolus (individuellement si bloquants, par lots dans les autres cas) par des corrections à froid.

Lorsque ces corrections concernent les développements, le cycle de recette doit être de nouveau appliqué de manière rigoureuse (tests de non régression)

1. Répartition des coûts

(voir tableau)

Le tableau ci-dessus donne une répartition indicative des coûts de projet entre les différentes phases pour un projet de taille moyenne (0,2 à 2 M€).

Ces coûts sont estimés par rapport à une base 100 pour l’équipe de projet.

Les coûts client (maîtrise d’ouvrage et utilisateurs) et mise en service (production et maintenance) associés sont mentionnés pour mémoire sur la même base.

Les coûts de formation et les coûts de généralisation indiqués doivent être majorés en cas d’installation multi-sites.

En cas d’approche exclusivement à base de progiciels (pas de développements spécifiques pour adaptation du progiciel et utilisation d’interfaces standard), l’économie réalisée porte principalement sur la phase de développement et est estimée à environ 12% du coût du projet.

Cette répartition peut différer sensiblement en fonction du type de projet et de l’organisation concernée (développements internes, sous-traitance du développement, sous-traitance de la production, etc.) mais représente un bon niveau d’approximation.


2. Coûts de fonctionnement

(voir tableau)

Le tableau ci-dessus donne une répartition indicative des coûts de fonctionnement pour un projet de taille moyenne (0,2 à 2 M€).

Le coût des matériels concernés est un coût moyen mais peut être très différent selon le type d’architecture retenue et selon les capacités de mutualisation des coûts entre projets.

Les coûts de production incluent les coûts de maintenance du matériel.

Les coûts de maintenance incluent les coûts de fonctionnement du site de maintenance.

Notons que, à niveau de service équivalent, les coût d’investissement et d’exploitation sont équivalents entre une plate-forme de type main frame et une plate-forme de type Unix. En effet, il faut tenir compte de tous les surcoûts des différents dispositifs matériels, logiciels et humains destinés à fournir une qualité de service équivalente (cf. études du Gartner Group).

Cette répartition peut différer sensiblement en fonction du type de projet et de l’organisation concernée (développements internes, sous-traitance du développement, sous-traitance de la production, etc.) mais représente un bon niveau d’approximation.



3. Coûts de non respect de la méthode
Il arrive souvent que, dans l’espoir d’optimiser les coûts ou les délais, des économies soient réalisées sur les étapes de lancement, de conception, de recettes ou de mise en production.

Ces économies sont en général de fausses économies et représentent au mieux un déplacement des budgets vers le client ou vers la production au détriment de la qualité.

Classiquement, les économies faites sur la réalisation sont mises en évidence et les surcoûts générés sont ignorés car d’une part, ils ne concernent pas l’année de réalisation du projet et d’autre part ne sont pas mesurés.

Les exemples qui suivent, tirés d’expériences réelles, peuvent être considérés comme représentatifs.

Exemple 1 : Économies sur les phases de développement (Conception ou Vérification de Conformité des Développements)

(voir tableau)

Les économies réalisées par l’équipe de projet sont en réalité en partie déportées vers les coûts de maintenance et de production.

Pour une économie de 50% sur les coûts de projet, on constate en réalité un surcoût de 70% sur 1 an et de 200% sur 5 ans.



Exemple 2 : Économies sur les phases de mise en production ou mise en maintenance

(voir tableau)

Les économies réalisées par l’équipe de projet sont en réalité en partie déportées vers les coûts de maintenance et de production.

Pour une économie de 25% du coûts de projet (62,5% du coût de mise en production), on constate en réalité un surcoût de 30% sur 1 an et de 110% sur 5 ans.


4. Coût de la qualité
En milieu industriel, on considère généralement que le coût de la qualité représente environ 10% des coûts de production et que le coût des non conformité (lorsqu’on applique pas les normes qualité) représente environ 30% des coûts de production.

En conduite de projets informatiques, on peut considérer que l’application des méthodes qualité représente (tout confondu) jusqu’à 25% du coût du projet. Leur non application entraîne des non conformités dont le surcoût peut dépasse fréquemment les 200% du coût du projet (répartis entre la réalisation, l’utilisation, la production et la maintenance).

Même si, avec une vision budgétaire étroite, on ne considère que les surcoûts imputés à la réalisation du projet, ceux-ci dépassent largement les économies réalisées en n’appliquant pas les normes de qualité.


5. Suivi, qualité, sécurité

Dans les estimations de projet, il est bon de se rappeler que :
 L’encadrement et le suivi de projet représentent environ 10 % du coût du projet
 La qualité représente environ 10 % du coût du projet
 La sécurité courante représente environ 5% du projet lorsqu’il n’y a pas de dispositions particulières.

Notons que le livre est accompagné d'un CD où figurent les formulaires standard facilitant la mise en oeuvre de la méthode.

Les différents éléments contractuels ne sont pas décrits en un document unique. Usuellement, ils sont répartis entre le Contrat, le Plan d’Assurance Qualité et la Convention de Service.

Pour chacun de ces documents, le corps du document a priorité sur les annexes. Sauf conventions particulières, l’ordre de priorité des documents contractuels est : Contrat, puis Plan d’Assurance Qualité, puis Convention de Service puis dispositions particulières prises lors de l’exécution.

Lorsque des avenants viennent contredire des dispositions antérieures, l’abandon de ces dispositions doit être explicite et les signataires doivent avoir qualité pour répudier ces dispositions (de préférence, les signataires de l’avenant sont les signataires du document initial).

Contrat
Le Contrat établit les conventions entre les différentes entités concernées par le projet.

Il peut y avoir un contrat global ou des contrats entre chaque paire d’entités concernées.

Plan d’Assurance Qualité
Le Plan d’Assurance Qualité englobe à la fois les exigences externes et les dispositions techniques et organisationnelles (c’est à dire, pour l’essentiel, la description des processus mis en place pour la réalisation de la Prestation), prises pour satisfaire les exigences définies

Le Plan d’Assurance Qualité est un document qui précise les dispositions prises par le Prestataire et par le Client pour répondre aux exigences Qualité portant sur le service fourni au Client. (Norme Z 67-801-1)

Lorsque la Prestation comporte à la fois du développement et du service (reprise d’un existant, mise en production, assistance, etc.), le Plan d’Assurance Qualité porte sur les dispositions s’appliquant à l’ensemble de la Prestation. Les dispositions propres au développement sont regroupées dans le Plan Qualité Projet.

Convention de Service
La Convention de Service est un accord précisant les modalités d’exécution par le Prestataire du Service fourni au Client. Il représente la vision externe du service (tel qu’il apparaît aux utilisateurs) et constitue la mise en forme opérationnelle des exigences du Contrat adapté aux différentes catégories d’utilisateurs, s’exprimant en résultats tangibles pour ceux-ci et quantifiés sous forme d’indicateurs.

Il est recommandé de réserver le corps du document à la description du service et à la définition des indicateurs, puis de préciser dans des annexes les conditions d’exécution détaillées et les valeurs attendues pour les indicateurs définis.

La Convention de Service n’est nécessaire que si a Prestation inclut un service (reprise d’un existant, mise en production, assistance, etc.).

La notion de Convention de Service peut également apparaître en cours de projet lorsqu’il s’agit de définir le futur : conditions d’exploitation et de maintenance.

Plan de Développement
Le Plan de Développement complète le Plan d’Assurance Qualité.

Il détaille toutes les phases et étapes du projet, les pré-requis, les livrables, les moyens à mettre en œuvre et les conditions de passage à la phase ou l’étape suivante.

Le Plan de Développement est établi en début de projet et permet aux principaux acteurs du projet d’avoir une vision suffisante des tâches à effectuer pour en assurer la maîtrise.

La description des tâches établie dans le Plan de Développement est la base contractuelle de la planification et du suivi de projet.

Convention Sécurité
Lorsque les conditions particulières du projet l’exigent, les dispositions relatives à la sécurité doivent faire l’objet d’une convention écrite.

En général, ces dispositions existent mais sont de l’ordre de la tradition orale. Dans ce cas, leur mise en application peut réserver quelques surprises.

Sur un projet, 3 groupes d’acteurs jouent un rôle essentiel et déterminant :
 Les décideurs
C’est essentiellement la direction générale assistée s’il y a lieu par le responsable financier, le responsable des ressources humaines et le responsable juridique.
 Les futurs utilisateurs
Ils sont représentés par la maîtrise d’ouvrage, la Direction cliente du projet, les comités utilisateurs.
 L’informatique
C’est non seulement la maîtrise d’œuvre du projet, mais aussi les futurs exploitants et mainteneurs de la solution qui sera mise en place.

Ces 3 pôles ont des préoccupations, des objectifs et des priorités différents et complémentaires. Les événements extérieurs susceptibles d’avoir une influence sur le projet peuvent être perçus de façon très différente.

Pour que le projet soit un succès (aux points de vue contenu, conduite, coût et efficacité), l’implication de ces 3 groupes (chacun à son niveau) est essentielle. L’absence d’implication d’un de ces groupes ou une opposition non constructive entre eux conduit généralement à une situation d’échec.

La prise en compte des inévitables aléas doit faire intervenir ces 3 pôles.


De même, une prestation complexe peut faire intervenir Client, Prestataire, Fournisseurs, Sous-traitants. Chacun a, là aussi, des préoccupations, des objectifs et des priorités différents et complémentaires. Le succès de la Prestation passe par une implication forte de chacune de ces entités dans une stratégie gagnant-gagnant.

Les contraintes qualité sont décrites dans le Plan d’Assurance Qualité. Ces contraintes sont en général l’application au projet des contraintes générales décidées au niveau de la société (au moins pour les projets informatiques).

Ces contraintes doivent être prises en compte et appliquées tout au long du projet par ses différents acteurs.

A la fin de chaque étape importante du projet, le Responsable Qualité fera un audit qualité du projet. En principe, les différentes recettes du projet ne peuvent pas être prononcées si cet audit n’a pas été effectué.

Les contraintes de sécurité sont décrites dans la Convention Sécurité. Ces contraintes sont en général l’application au projet du Plan Sécurité général de la société et du Plan Sécurité Informatique.

Ces contraintes doivent être prises en compte et appliquées tout au long du projet par ses différents acteurs.

A la fin de chaque étape importante du projet, le Responsable Sécurité fera un audit Sécurité. En principe, les différentes recettes du projet ne peuvent pas être prononcées si cet audit n’a pas été effectué.

Il est recommandé de prévoir systématiquement un paragraphe sécurité dans chacun des documents de projet, en particulier dans les dossiers d’étude d’opportunité, de conception, de test, de recette, de mise en production et de mise en maintenance.

La sécurité prend en compte tous les éléments susceptibles d’avoir un impact direct ou indirect sur la pérennité des investissements informatiques. Elle se décline en :

 5 composantes : I O A F L
Infrastructure, Organisation, Architecture, Flux, Logique
 5 axes : D I C Q T
Disponibilité, Intégrité, Confidentialité, Qualité, Traçabilité
 5 stades : L C D R X
Lancement, Conception, Développement, Recettes, eXploitation & Maintenance

Au cours de chacun de ces 5 stades, la sécurité sera déclinée à la fois par composante et par axe.

Il est bon de se souvenir que la sécurité s’intègre dans une politique d’ensemble qui dépasse le projet. La sécurité de l’ensemble a la fragilité de son maillon le plus faible.

But
La rédaction d’un document se fait généralement entre plusieurs étapes. Des diffusions provisoires peuvent avoir lieu avant validation définitive. Le document définitif peut également subir des évolutions et connaître des versions successives.

Il est nécessaire de pouvoir reconnaître la version applicable d’un document afin que chacun ait l’assurance que la version en sa possession est bien la version de référence.

Pour cela, le plan d’assurance qualité précise la gestion des versions de documents, le mode d’identification de l’état des documents ainsi que la mention correspondante à l’intérieur du document.

La normalisation des documents et la gestion de la documentation permettent d’assurer fiabilité et traçabilité des documents.

Cependant, c’est le processus de validation des documents qui assure la fiabilité du contenu.

Mise en œuvre
Les principes et les circuits de validation des documents sont décrits dans le plan d’assurance qualité (ou en annexe de celui-ci).

Ces principes sont établis en début de projet sous la responsabilité du directeur de projet et sont applicables par tous tout au long de la vie de celui-ci.

Les besoins de validation sont établis par type de document. L’identification de l’état du document doit être formalisée et intégrée dans la gestion de la documentation.

La validation des documents peut être faite :
 Par défaut : c’est la dernière version identifiée et référencée qui s’applique.

 Par décision : un processus d’approbation du document est mis en œuvre. La version applicable est la version ainsi validée. Mention de la validation est faite au niveau de la gestion de la documentation et, chaque fois que possible, au niveau du document lui-même.

 Par visa : une version écrite du document est formellement signée par les responsables concernés. C’est cette seule version qui fait foi. Les copies non authentifiées qui seraient diffusées ne sont mises à disposition qu’à titre de facilité d’organisation.

But
La charte de réunion précise l’organisation générale des réunions du projet

Le respect de cette charte permet d’augmenter l’efficacité des réunions, d’en faciliter l’organisation et de minimiser les pertes de temps fréquentes que l’on peut rencontrer dans ces circonstances.

Cette charte est proposée en début de projet et est appliquée tout au long de celui-ci.

L’expérience montre que la mise en place d’une telle charte est acceptée sans problème en début de projet et est alors assez bien respectée. Il est par contre beaucoup plus difficile de modifier en cours de projet les habitudes prises.

Contenu
Le contenu de la charte s’applique à tous les types de réunions. La charte peut cependant préciser les dispositions particulières à certains types de réunion.

Participants à la réunion
La liste des participants à la réunion doit être établie avant la réunion. Cette liste précise pour chacun :
 À quel titre il participe à la réunion,
 Si sa participation est systématique ou optionnelle,
 Quel est le remplaçant en cas d’absence,

Sont systématiquement précisés l’organisateur de la réunion, l’animateur et le responsable du compte rendu.

Pour les réunions régulières (comité, suivi, etc.), une liste type des participants est établie en début de projet. Cette liste peut évoluer au cours du projet.

Ordre du jour de la réunion
L’ordre du jour de la réunion doit être établi et communiqué à l’avance par son organisateur.

Pour les réunions régulières (comité, suivi, etc.), une ordre du jour type est établi en début de projet. Cet ordre du jour peut être complété ponctuellement ou être complété au cours du projet en fonction des nécessités.

L’ordre du jour précise le cas échéant les points à traiter en priorité.

Convocation aux réunions
La convocation à la réunion est à la charge de l’organisateur.

Elle précise les lieu, date et heure et l’ordre du jour.

Elle est envoyée à tous les participants (avec copie aux remplaçants éventuels). Pour les participants occasionnels, la convocation met en évidence la nécessité de leur présence s’il y a lieu.

La charte de réunion prévoit le délai à prévoir entre la convocation et la réunion. Pour les réunions régulières, le calendrier de réunion est complété à chaque réunion et figure sur le compte-rendu.

La charte de réunion prévoit également le mode de diffusion de cette convocation et des documents joints.

L’organisateur de la réunion est responsable de la logistique de la réunion (réservation de salle, réservation de matériels, etc.).

Conduite de la réunion
La charte de réunion prévoit les points qui sont systématiquement abordés ainsi que la durée respective à leur accorder (validation du dernier compte rendu, calendrier des prochaines réunions, etc.).

En fin de réunion sont systématiquement rappelées les décisions prises ou à prendre. Ce point figure sur le compte rendu.

La charte de réunion précise comment sont prises les décisions collégiales et le niveau d’engagement des participants (et des organisations qu’ils représentent) face aux décisions prises.

Compte rendu de la réunion
La charte de réunion précise qui est la personne chargée de la rédaction et de la diffusion du compte-rendu ainsi que les dispositions de relecture et de (pré)validation à respecter.

La charte de réunion prévoit la liste des destinataires du compte rendu de réunion (cette liste peut en effet être plus riche que la liste des participants).

Pour les réunions régulières, la validation du compte rendu est systématiquement faite au début de la réunion suivante et les remarques éventuelles sont systématiquement intégrées dans le compte rendu de cette nouvelle réunion.

La charte de réunion prévoit le délai et les moyens de diffusion du compte rendu.

La gestion des comptes rendus est rappelé dans la charte et fait intégralement partie de la gestion des documents de projet.

Horaires et duréeLes horaires et la durée sont destinés à être respectés. Les retards systématiques sont à proscrire : ils sont un manque de respect à l’égard des autres participants, une nuisance pour l’efficacité et une perte de temps (et donc d’argent) pour l’entreprise.

La charte précisera les conditions d’attente en cas de retard et les conditions de prolongation de la réunion lorsque l’ordre du jour n’est pas épuisé.

Téléphones mobiles
Les téléphones mobiles peuvent représenter une nuisance importante dans le déroulement des réunions. Cependant, certains intervenants peuvent être soumis à des contraintes de production ou de sécurité les obligeant à être joignables à tout moment.

La charte précisera les dispositions à prendre à l’égard des téléphones mobiles (par défaut : sonneries coupées durant les réunions) et les dérogations éventuelles (par défaut : obligation de sortir de la salle pour répondre).

Divers
Des documents types seront prévus pour les convocations, l’ordre du jour, les présentations de transparents et le compte-rendu, conformément aux normes de présentation adoptées pour le projet.

Sécurité
Dans le cas où des aspects de sécurité doivent être pris en compte dans le projet, la charte précisera les dispositifs particuliers de sécurité à adopter (accueil des participants externes, confidentialité des convocations et comptes rendus, information sur la confidentialité, accréditations diverses, etc.).

A l'heure d'aujourd'hui, je n'ai pas encore eu l'occasion d'utiliser cette méthode, je l'ai juste étudié dans le cadre de la réalisation d'un mémoire sur la qualité pour le passage de mon double diplôme dont le premier concerne le management et l'autre la qualité (Master M2IRT Option PSI et Master MPQO IIDC).

Ce mémoire a été effectué en binôme, nous avions libre choix sur le thème que nous devions aborder le but étant d'étudier et démontrer que nous parlions de qualité.

Notre démarche à d'abord été de se poser la question de ce qui serait intéressant et utile à notre arrivé sur le marché du travail et qui pour nous, posait le plus de problème dans nos entreprise ou dans les différents témoignages que l'on entendait. Nous avons donc axé nos recherches sur une méthode de gestion de projet informatique dans laquelle la qualité avait une place importante et active.

Après quelques recherches sur internet nous sommes tombés sur un article de wikipédia nous renvoyant vers une méthode française appelée CMPI.

Nous avons tout d'abord pris connaissance de la méthode, et commencé à réfléchir sur une problématique pour notre mémoire.

La problématique que nous avons choisi de développer a été "La méthode CMPI un outil de progrès ?".

Nous avons ensuite pris contact avec M Hallépée afin d'une part pour savoir si nous pouvions étudier sa méthode et d'autre part si il serait d'accord d'être notre "Directeur de Mémoire". Il nous a donné son accord et nous a épaulé, éclairé et corrigé sur les parties pour lesquelles nous avions quelques interrogations.

Nous avons passé notre soutenance, la méthode a été fort bien accueilli car comme je l'ai dis plus haut, de plus en plus d'entreprises cherchent des méthodes de gestion de projets informatiques.

La méthode CMPI est un outil qui regroupe un ensemble de bonnes pratiques avec des injections de qualité provenant de référentiels connus.

Elle peut aussi bien être utilisée dans sa totalité que par partie. Je pense que pour une personne qui commence dans le monde des projets informatiques cette méthode lui permettra d'avoir une bonne idée de comment mener un projet informatique.
Le plus gros défaut de cette méthode reste qu'elle n'est pas connue, c'est pour cela que j'invite quiconque à prendre connaissance de cette méthode.

Je tiens tout particulièrement à remercier M Hallépée pour toute l'aide qu'il nous a procurée.

Bonne lecture à tous,

Michaël BIARD

Encore bravo pour l'excellent travail fait à l'occasion de votre mémoire.

J'ai été très honoé que vous ayez choisi la méthode CMPI comme thème central de celui-ci.

J'ai pu voir au cours de vos travaux que vous en aviez tiré la substance et je suis sûr que ce que vous en avez appris vous accompagnera avec profit tout au long de votre carrière.

Et si les circonstances ne vous permettent pas de satisfaire vout goût de la perfection, c'est bien parcequ' nous ne sommes pas dans un monde parfait. Le pragmatisme que vous avez également pu apprendre dans la méthode CMPI vous aidera à vous adapter et à tirer le meilleur parti des possibilités de l'instant.

Bonne chance pour votre avenir