Le rôle de la conception dans les projets

Tout le monde connaît des applications qui sont désespérément lentes, des sites Web tellement touffus que le visiteur finit par s’y perdre, des traitements fonctionnant normalement et qui soudain, sans prévenir, sortent des résultats aberrants, … Tous ces incidents sont des signes qui ne trompent pas. Tout professionnel vous le dira : « Il y a un problème de conception ». Il est même possible qu’il n’y ait pas eu de conception (¹) et cela se voit.

Normalement tout projet informatique comprend avant la réalisation (²) une phase de conception plus ou moins importante. Le nom de cette étape varie mais on la retrouve dans toutes les démarches : approche classique, prototypage, démarche en spirale, méthode agile, …. Cette étape est très importante car elle permet de s’assurer que rien d’important n’a été oublié, que l’application envisagée est techniquement réalisable et qu’elle fonctionnera convenablement.

L’expérience montre que sans une étape conception le projet dérive et fini par se « planter ». Plus de 65 ans de développement de logiciels montrent son importance. Jadis elle était assez succincte. En quelques jours on rédigeait un court document illustré par quelques schémas. Aujourd’hui on n’hésite pas à passer du temps à définir ce qu’il est souhaitable de faire faire à l’application et la manière de procéder pour y arriver. Mais jusqu’où faut-il aller ? Les méthodes agiles suppriment l’étape consacrée à l’élaboration du cahier des charges. Est-ce la bonne approche ?

Mais qu’est-ce qu’au juste la conception ?

Fausses conceptions sur la conception.

Avant d’aller plus loin il faut commencer par faire un sort à certaines vieilles lunes concernant la conception. En effet, il existe en ce domaine un certain nombre d’idées assez inexactes, voir franchement inexactes :

• La conception est du temps perdu. Les tenants de cette approche pensent qu’il est préférable de commencer très vite par programmer puis ensuite d’ajuster le code en fonction des retours des premiers utilisateurs (³). Ce type d’approche amène à réaliser une 2^ème puis une 3^ème version, … C’est du « quick and dirty » et plutôt du « dirty-dirty ».
• L’analyse fonctionnelle consiste à recueillir les besoins de tous les intéressés pour définir les spécifications de la future application. On va pour cela multiplier les entretiens, les groupes de travail et les travaux de synthèse. Cela correspondant au souhait d’être sûr de ne rien oublier. Il faut être claire : la conception n’est pas la collecte de toutes les doléances de tous les utilisateurs potentiels. C’est un préalable mais ce n’est pas la conception proprement dite.
• On conçoit l’application indépendamment des choix techniques et organisationnels qui sont ensuite effectués. Or la dimension fonctionnelle n’est qu’une partie des spécifications de la future application. Les performances, la sécurité, les contraintes qui s’imposent dans le domaine technique, la maintenabilité, la fiabilité des traitements, … sont des éléments importants à prendre en compte dans la conception de l’application.

La conception s’est autre chose. C’est une vision globale de la future application et la manière de la développer de façon à arriver à une solution efficace et élégante.

Le secret des projets à succès

Heureusement un grand nombre d’applications sont bien conçues. L’observation montre qu’il existe aussi un certain nombre d’autres applications mal foutues. Ce sont celles dont les utilisateurs se plaignent fréquemment. Et très souvent on constate que ceci est dû à des faiblesses de conception. L’expérience montre que l’absence de conception se traduit par le développement « d’usines à gaz » ou par des « plats de nouilles ». Ceci se traduit par un grand nombre de « bugs » qui, finalement, produisent de nombreux « plantages » d’exploitation (⁴).

A l’inverse une application efficace repose généralement sur une conception de qualité. Cela se manifeste par des temps de réponses excellents, une succession d’opérations simple, les traitements sont sûrs, les bases de données sont de qualité et fiables, la maintenance se fait sans peine, …. Lorsque la conception est de qualité cela se voit.

Ceci ne veut pas pour autant dire qu’il est nécessaire de rédiger un cahier des charges de 500 pages touffues et difficiles à comprendre. La qualité de la conception ne se mesure pas au nombre de pages produites mais à la quantité et la qualité du « jus de cervelle » qui sont investies dans le projet.

L’observation montre que la qualité de la conception se manifeste de deux manières :

• une économie de moyen. Peu de ressources sont nécessaires pour développer le projet. Celui-ci se déroule rapidement et arrive aux résultats attendus dans les délais prévus. Autre point significatif, l’application bien conçue a besoin pour fonctionner d’un volume de ressources informatiques raisonnables.
• une grande souplesse du système. Il est apparemment simple d’emploi et a une capacité d’évolution satisfaisante de sorte qu’il s’adapte sans trop d’effort à un changement du contexte.

Mais ces deux caractéristiques, économie de moyen et grande souplesse, ne sont pas propres à l’informatique. Elles concernent aussi d’autres domaines comme la conception et la réalisation d’ouvrages d’art comme les ponts, mais aussi le développement d’avions, de moteurs, … C’est le résultat de la mise en œuvre d’un savoir-faire particulier, c’est presque un tour de main. Ceci montre que la conception n’est pas une science mais plutôt un art.

L’expérience montre que certaines personnes sont de bons concepteurs et que d’autres ne le sont pas. Ce n’est pas un problème de formation. Il arrive que des personnes bardés de diplômes s’avèrent être des concepteurs médiocres alors qu’à l’inverse des personnes nettement moins diplômés sont excellents en ce domaine. Des formations aux techniques de gestion de projet améliorent leur efficacité mais elle ne permet pas d’acquérir la capacité à faire de bonnes conception. C’est, à la base, une affaire de talent et de créativité.

Le rôle du concepteur

Dans le processus de développement le concepteur joue un rôle particulièrement important. Mais les termes usuellement employés pour décrire la fonction de concepteur sont ambigus. Ce sont soit des analystes soit des chefs de projet :

• L’analyste. On précise souvent que c’est un « analyste fonctionnel ». En fait ce n’est pas analyste, car il n’analyse pas mais au contraire conçoit, et il ne limite pas son intervention au seul domaine fonctionnel. Il n’a pour mission de décomposer le futur système en unités élémentaires mais au contraire d’imaginer une solution globale cohérente. Le titre d’ «analyste» devrait être évité. Celui de «concepteur» serait préférable.
• Le chef de projet. Très souvent le concepteur est désigné par le terme de chef de projet mais au moment de la conception de l’application il n’y a pas encore de projet. De plus il travaille seul ou avec un ou deux collaborateurs. Le terme de chef de projet est en avance par rapport à la suite des événements. Par contre en phase de réalisation il peut devenir chef d’équipe mais il est difficile d’être à la fois concepteur et chef de l’équipe de réalisation car cela ne fait pas appel aux mêmes compétences.

En fait le rôle du concepteur ressemble assez à celui d’un architecte (⁵). Le concepteur informatique commence faire une étude généralement appelée expression des besoins ou étude de faisabilité. Ce premier travail ressemble beaucoup à l’étude faite par les architectes appelée «esquisse» ou «plan masse». Ensuite le concepteur va effectuer une analyse fonctionnelle qui se traduit par cahier des charges. Ce travail est assez voisin de celui de l’architecte appelé «avant-projet définitif» ou «dossier d’appel d’offre» (dossier d’APO).

On notera que la conception en informatique comme en architecture se fait en deux étapes : une conception globale (ou conception d’ensemble) suivie ensuite une conception détaillée. Un jour un stagiaire qui suivait un cours de gestion de projet m’a demandé pour quelle raison il y avait deux étapes. J’ai été perplexe et j’ai fini par lui répondre : «c’est l’habitude car on évite de mettre tous les œufs dans le même panier». On retrouve cela dans toutes les démarches d’ingénieries.

Certaines méthodes agiles comme Scrum ou Extreme Programming ont cherchés à ramener la conception à une seule étape d’initialisation ou de cadrage, souvent basée sur des scénarios d’utilisation. Ce sont en fait des études de faisabilité. Par contre toutes les méthodes agiles bannissent l’étape d’analyse fonctionnelle. Malheureusement cette étape a un double rôle fondamental : s’assurer que rien d’essentiel n’a été oublié et évaluer l’effort de programmation et de tests nécessaire pour arriver à une application opérationnelle. Résultat : la probabilité de dérive augmente.

Comme on le voit le rôle de la conception est fondamental. Qu’elle se fasse en une ou deux étapes, elle est indispensable et le concepteur est l’acteur principal de cette étape. Son rôle est de construire un système simple et efficace à partir d’un ensemble hétéroclite : des idées plus ou moins bien formulées, des demandes hétérogènes faites par les utilisateurs, de nombreux documents, différentes études techniques, des entretiens, les travaux de groupes de travail, des spécifications, …. En fait un bon concepteur est un homme de synthèse. C’est un véritable «artiste» : un homme de l’art connaissant tous les aspects de la réalisation de système d’information et capable d’effectuer les choix des solutions les plus efficaces.

Tentative de définition de la conception

Comme on le voit il n’est pas facile de définir ce qu’est la conception. C’est un peu comme la définition de l’escalier en colimaçon. Si vous demandez à quel qu’un ce que c’est-il hésite puis fini par faire un geste de la main pour montrer que cela monte en tournant. Bien sûr il existe dans le dictionnaire une définition : « c’est un escalier qui s’enroule sur lui-même ». C’est beau mais ce n’est pas d’une grande clarté. Une approche empirique est préférable.

Pour mieux cerner la définition du travail concepteur deux points clés se dégagent. Il doit d’abord avoir la capacité à intégrer toutes les contraintes et définir de manière claire le périmètre fonctionnel de l’application. Il va notamment définir ce qui fait partie de la future application et ce qui n’en fait pas partie. Il doit ensuite être capable de fixer un budget et un délai pour réaliser le projet. Il va pour cela effectuer des arbitrages budgétaires tout en tenant compte des contraintes de ressources et de délais.

Un de mes amis, qui est un excellent concepteur, à l’habitude de dire que : «la conception consiste à fermer des portes en disant : «ça je ne le ferais pas» ». Au-delà de la boutade il y a une réalité. Face à chaque demande et à chaque spécification il doit s’interroger sur l’effort nécessaire pour le réaliser et son utilité. Pour cela il suit une démarche qui n’est pas sans rappeler celle de l’analyse de la valeur. Souvent le concepteur dit : «ce sera dans la version 2». C’est la manière polie de «fermer les portes».

Il est plus facile de reconnaître une mauvaise conception

Mais comment définir une bonne conception ? En fait, il est plus facile de constater qu’une application a été mal conçue alors qu’il est plus difficile de définir pour quelle raison une autre application est bien conçue. En effet les systèmes mal conçus ont quelques caractéristiques communes :

• Lenteur. Les saisies sont lentes et les traitements poussifs. Les utilisateurs se plaignent souvent de devoir attendre devant les écrans qu’ils se déverrouillent. De même les contrôles sont fastidieux et peu efficaces.
• Touffue. Très vite l’utilisateur se plaint d’être perdu dans la succession des opérations et ne plus savoir ce qu’il doit faire. Les fonctions sont confuses, les libellés ne sont pas clairs, … Ceci fait que les utilisateurs commettent fréquemment des erreurs de navigation ou de sélection des traitements.
• Peu efficace. L’application informatique mise en œuvre n’a pas permis de dégager des gains significatifs (gains de productivité, augmentation du chiffre d’affaires et du bénéfice de l’entreprise).
• Sécurité insuffisante. Le système est jugé peu fiable par ses utilisateurs. Les données sont mal sécurisées. Les redémarrages sont longs et laborieux et il arrive que des données soient perdues. Pire, on s‘en aperçoit au bout de quelques semaines, voir de plusieurs mois après l’incident qu’il est très difficile voir impossible de reconstituer les données perdues.  

Ces symptômes sont en grande partie liés à des faiblesses de conception ou à la médiocrité de la réalisation. On le sait : une conception médiocre ne peut qu’entraîner une réalisation médiocre. Malheureusement ces défauts ne peuvent qu’être constaté qu’a posteriori lorsque l’application est mise en production et il est alors généralement trop tard pour corriger la faiblesse de la conception.

Autre signe qui ne trompe pas : lorsque l’application mal conçue devient opérationnelle on constate, que la maintenance nécessaire est anormalement élevée, difficile à effectuer et coûteuse. Malheureusement, à ce moment il est trop tard pour corriger ces défauts (⁶).

Il est préférable de détecter ce type de fragilité dès la phase amont. Malheureusement, l’expérience montre qu’il est difficile de constater à ce moment la faiblesse de la conception. Cependant il existe des signes annonciateurs. Ainsi si l’étude de faisabilité ne fixe pas de manière claire et non-ambigu le périmètre fonctionnel on risque de constater par la suite une dérive significative. Ensuite, lors de la phase fonctionnelle on constate que le document final type cahier des charges est verbeux, par clair et assez filandreux. C’est un critère simple : « si vous ne le comprenez pas ce n’est pas de votre faute. C’est dû au fait que la conception est faible, voire mauvaise ». Deux autres critères permettent d’évaluer ce document :

• Il est lourd et difficile à lire.
• Il part dans tous les sens.

Comme les fragilités de la conception peuvent avoir de graves conséquences il est important de veiller à avoir de bons concepteurs.

Trouver un bon concepteur

Malheureusement il est très difficile d’arriver à détecter a priori quelles sont les personnes qui ont de bonnes capacités de conception. Rien ne permet de présumer ces compétences. Tant qu’on n’a pas mis les personnes en situation on ne saura pas si elles ont des compétences de conception. Comme le dit le proverbe : «C’est au pied du mur qu’on voit le maçon».

Un minimum de connaissances est nécessaire : une bonne culture informatique, une solide pratique de la gestion et une connaissance approfondie du domaine à informatiser. C’est une base nécessaire mais ce n’est pas suffisant.

Il est pour cela nécessaire de tester un certain nombre de personnes pour découvrir celles qui ont de réelles compétences de conception. On a souvent d’heureuses surprises mais fréquemment de nombreuses déceptions.

Pour ces raisons il est nécessaire de cultiver dans l’entreprise ces compétences et surtout de les conserver. Pour choisir les personnes deux orientations sont envisageables  :

• une solide culture technique du type ingénieur ou équivalant. Ce sont fréquemment des informaticiens mais ce peuvent aussi être des ingénieurs mécaniques, électriques, chimiques, travaux publics, … Souvent de simples techniciens ont des capacités insoupçonnées.
• une forte culture d’entreprise notamment dans les domaines de la gestion et de management. Pour être efficaces il est indispensable que ces personnes aient aussi une bonne connaissance de l’informatique.

On constate qu’actuellement les entreprises recherchent plutôt des personnes du deuxième type capable de comprendre les préoccupations du management et les demandes des futurs utilisateurs tout en étant capable de dialoguer avec les informaticiens.

Souvent, n’ayant pas en interne ces concepteurs, les entreprises font appel à des SSII (⁷) et à des cabinets de conseils car elles ont souvent des concepteurs de bonne qualité car ils ont vu de nombreuses entreprises et effectuer une grande variété de missions. Mais il y a aussi parmi leurs collaborateurs des personnes nettement moins efficaces, à éviter.

L’absence de concepteur peut être fatale

Dans les entreprises qui se développent rapidement, notamment celles qui se sont résolument engagées dans leur transformation numérique, on constate que le nombre de projets est supérieur aux nombres de concepteurs disponibles. C’est une grave contrainte. Des demandes importantes sont bloquées ou, pire, des projets sont lancés sans conception où avec une conception réduite au strict minimum. Les résultats ne sont pas à la hauteur des espérances même pour des réalisations de taille limitées.

Face à cette situation deux solutions sont envisageables selon l’importance du projet :

• Dans le cas d’un petit projet la solution consiste à faire du « versionning » en développant des versions successives. C’est la démarche proposée par le mode agile. On sort une nouvelle version tous les 2 mois. Cela peut être des versions offrant de nouvelles fonctions ou des réécritures successives de versions antérieures (on parle dans ce cas de «ravaudage»).

Cette démarche à l’avantage de permettre de limiter les risques de dérives fonctionnelles des projets. Par contre elle risque de se traduire par des coûts supérieurs à ce qui étaient prévus à l’origine. A cela s’ajoute le coût élevé de la maintenance nécessaire demandée par une application développée de cette manière. Il peut devenir si élevé qu’il est souvent préférable de réécrire entièrement l’application à «iso-fonctionnalités».

• Dans le cas de grands projets, si on n’a pas en interne de concepteur ayant le savoir-faire nécessaire, il faut commencer par voir s’il n’est pas possible de dégager un concepteur faisant fonction de chef de projet en le remplaçant par un chef d’équipe de développement capable de contrôler les équipes sans toucher au contenu des fonctions à développer.
  Si ce n’est pas possible il faut alors envisager de sous-traiter la conception de la future application. Dans ce cas une attention particulière doit être portées aux personnes déléguées par les sociétés de service ou de conseil. Il faut étudier avec soins les CV des personnes proposées et leurs références et avoir un long entretien préalable avec elles.

Si on ne dispose pas de la personne ayant les compétences nécessaires il est préférable de ne pas lancer le projet et d’attendre de trouver la personne compétente.

Il est aussi possible de découper en plusieurs petits projets plus facile à maîtriser par des personnes moins expérimentées. On parle dans ce cas de «saucissonnage». Faut-il encore que l’application s’y prête ?

Contrairement à ce qui est souvent dit, la qualité de la conception n’est pas une affaire d’outils ou de méthodes. Ils sont utiles mais ils ne font pas le travail de conception. Celle-ci est d’abord une affaire de compétences. Les entreprises doivent cultiver ce type de savoir-faire. Si ce n’est pas le cas, leurs projets risquent de dériver, voire d’échouer. L’expérience montre que des applications développées dans ces conditions risquent d’être lourdes et peu efficaces. A l’inverse les systèmes d’information efficaces reposent toujours sur une conception de qualité faite par un concepteur compétent. Cette constatation ne souffre pas d’exception.

1 - Le terme conception utilisé en France n’est pas parfait. Le terme anglais de « design » est plus juste même s’il est un peu trop restrictif.

2 - Parfois on fait l’inverse : on commence par programmer puis au bout d’un certain temps les programmeurs s’interrogent et se demandent comment « raccrocher les morceaux ». On cherche alors à dégager une sorte de conception. Généralement le résultat est assez décevant. Il est de loin préférable de commencer par la conception pour ensuite effectuer la programmation.

3 - C’est le fameux « Fixe and Code » des débuts de l’informatique. Cette démarche a en règle générale donnée des résultats décevants et elle a été progressivement abandonnée au profit de démarches plus structurées commençant par une phase de conception. Mais aujourd’hui encore on constate que cette démarche est encore pratiquée avec des résultats toujours aussi décevants. Si l’application se limite à développer 2 ou 3 programmes, il est vrai que le risque est limité. Au-delà on entre dans la « terra incognita ».

4 - La terminologie des professionnels est sur ce sujet particulièrement riche. « L’usine à gaz » est une application lourde et peu efficace. L’utilisateur doit faire beaucoup d’efforts pour finalement constater un résultat décevant. « Les plats de nouilles » sont des programmes mal bâtis. Ils sont foisonnants, avec de nombreux renvois en tout sens ce qui les rendent peu lisibles. Le terme « bug » est rentré dans le langage courant. C’est une erreur dans une instruction qui se traduit finalement par un « plantage ». Le terme est charmant mais la réalité est mal vécue par les utilisateurs qui, lorsqu’ils tombent sur un « bug », perdent une partie des données qu’ils viennent de saisir.

5 - Dans quelques entreprises on les appellent «architecte fonctionnel». Mais ce titre est, en fait, assez peu utilisé.

6 - On peut effectuer une analogie avec le bâtiment. Lorsqu’une maison est terminée, si on s’aperçoit au bout de quelques mois que d’importantes fissures apparaissent et si on estime qu’elles sont dues à des fondations insuffisantes (ou à une absence de fondations) il est alors difficile de corriger ces défauts. On peut faire des injections de béton mais il n’est pas sûr que ce soit suffisant.

7 - On les appelle de plus en plus souvent les entreprises de services du numérique (ESN).

N'oubliez pas la note de cadrage

Un projet informatique d'une certaine taille est toujours une opération complexe faisant appel à de nombreuses compétences. Ceci est dû au fait que dans le cadre d'un projet il est nécessaire de recourir à de nombreuses activités différentes. De plus un nombre élevé de personnes sont concernées directement ou indirectement par un projet. Souvent elles ont des démarches différentes et des points de vue assez éloignées les uns des autres. Pour ces raisons il est nécessaire de mettre ces personnes et ces activités en bon ordre pour mener le projet dans les délais et les budgets prévus. C'est le rôle des notes de cadrage.

Pour organiser un projet on commence par s'efforcer d'identifier l'ensemble des tâches le constituant. Ce sont des activités précises confiées à une personne en lui accordant un délai de réalisation déterminé. C'est par exemple l'animation d'un groupe de travail, la mise au point d'un document ou la rédaction d'un programme. Un projet informatique comprend plusieurs centaines de tâches, voir dans le cas des grands projets plusieurs milliers de tâches. Pour mener à son terme le projet dans le délai prévu il est nécessaire de mettre en ordre ces tâches. Pour cela on a pris l'habitude de les regrouper en étapes ou en phases.

Les étapes sont de natures très différentes. Elle concerne des opérations de conception, de réalisation, de tests et de mise en place. Très souvent on décompose les étapes trop lourdes et trop complexes en étapes plus courtes et donc plus facile à maîtriser. Ainsi il est habituel de décomposer l'étape de conception en deux : conception globale (généralement appelée l’expression des besoins) et conception détaillée (souvent appelée analyse fonctionnelle). Selon les projets il y a entre 5 et 10 étapes. La difficulté de cet organisation tient au fait que ce ne sont pas toujours les mêmes personnes qui participent à ces différentes opérations et donc il faut gérer les passages de relais entre les différentes équipes.

Au cours d'une même étape de nombreux participants interviennent simultanément. Mais pour que leurs actions soient efficaces il est important de déterminer dans quel ordre ils agissent et de manière plus générale comment sont coordonnées leurs opérations. C'est le premier objectif de la gestion de projet. Il est ainsi possible d'améliorer de manière significative son déroulent.

Les risques de dérives des projets sont nombreux

Naturellement les projets informatiques ont tendance à dériver. D'ailleurs si ce risque n'existait pas il est probable qu'on aurait jamais eu l'idée d'organiser les développements de logiciels en mode projet.

Les origines de ces dérives sont nombreuses. Une des causes les plus fréquente est le fait que les différents intervenants s’attendent les uns les autres. Une personne attend qu'une autre lui délivre un document mais ce dernier l'ignore et pendant ce temps il fait autre chose sans se rendre compte qu'il risque de mettre tout le projet en retard. Un projet est une succession de passages de balles qui doit doivent se faire sans anicroche.

Trois situations critiques peuvent survenir et se traduire par des dérives significatives :

·      Détecter les tâches qui peuvent avoir été oubliées. Au cours d'une étape une ou plusieurs tâches importantes sont oubliées mais on ne s'en aperçoit que plus tard lorsqu'on a besoin de leurs résultats et on constate leur absence. Il est alors nécessaire de les réaliser toutes affaires cessantes. Cela ne peut que se traduire par un allongement des délais et une dérive des coûts.

·   Effectuer certaines tâches trop en avance sur le planning théorique. Une faible coordination se traduit par des initiatives individuelles qui aboutissent à réaliser des travaux en avance par rapport à des dates plus raisonnables pour les effectuer. Dans ces conditions on est amené à présumer certains résultats. Or ils peuvent ensuite être infirmés par les travaux qui sont ensuite effectués. Dans ces conditions certains travaux doivent être refait.

C'est par exemple le cas lorsqu'on effectue la définition de l’architecture technique en même temps que les travaux d’expression des besoins. Or, on le sait bien, l'architecture technique ne peut être définie que lorsque l’analyse fonctionnelle est terminée. Dans ces conditions il alors nécessaire de refaire la définition de l'architecture technique.

·      Eviter que certaines tâches soient faites en double.  Il arrive que le même travail soit fait à la fois par les utilisateurs et par les informaticiens, par exemple la définition des écrans et des états. C'est une lourde charge de travail et qui pèse sur les délais. Il est important de veiller à ne faire qu'une seule fois le travail et à bien le faire.

Comme on le voit les risques de dérives sont importants. Pour les limiter il est nécessaire d'identifier les tâches à effectuer, décider qui va les accomplir et à quel moment il va le faire. Leur identification et leur affectation est un point clé de la gestion de projet. 

Se poser les bonnes questions

Pour organiser efficacement une étape d’un projet on commence par identifier les différentes tâches qui doivent être effectuées et ensuite on va les affecter aux différents participants concernés. Pour cela on s'efforce de répondre aux cinq questions traditionnelles :

·      Qui fait,

·      Quoi,

·      Où,

·      Comment

·      Quand.      

Ces questions se résument par le sigle traditionnel : QQOCQ. Certains préfèrent le QQOQCCP correspondant à : Qui, Quoi, Où, Comment, Combien et Pourquoi. Effectivement il peut être intéressant de répondre aux questions : Combien et Pourquoi. A mon avis cela n'apporte pas grand-chose mais dans certains cas cela peut être utile.

Le sigle QQOCQ est une traduction du sigle anglais 5 W pour Who, What, Where, When et Why. En français ce sont : Qui, Quoi, Où, Quand et Pourquoi.

Cette démarche n'est pas nouvelle. Elle remonte à l'antiquité. C'est une méthode d’exposé des circonstances d’une situation définie proposée par un professeur de rhétorique grec : Hermagoras de Temnos et reprise quelques siècles plus tard par Saint-Augustin. En latin On considère : le Quis, Quid, Quando, Ubi, Cur, Quem ad modum, Quibus adminiculs qu'il est possible de traduire par : Qui, Qu’est-ce, Quand, Où, Pourquoi, De quelle façon, Ce qui permet.

De manière concrète pour chaque tâche on va s'attacher à répondre à ces cinq questions. On établit pour cela un tableau avec en ligne les différentes tâches identifiées qui doivent être effectuées au cours de l'étape et en colonne les différentes questions de base : Qui fait Quoi, Où, Comment et Quand. Ceci permet d'identifier sans ambiguïtés toutes les tâches à effectuer et les différents acteurs concernés.

Bien entendu, d'une étape à l'autre la liste des tâches sont différentes par contre d'un projet à l'autre on retrouve à peu près la même liste de tâches. Il est pour cette raison utile d’avoir une liste des tâches standard. 

Définir la règle du jeu de l’étape

On va reprendre de ce tableau la liste des tâches et les responsables à qui elles sont affectées. C'est la base de la note de cadrage. On va indiquer pour chaque tâche le rôle que va jouer chaque intervenant. On appelle ce tableau un RACI car on indique dans chaque case du tableau le rôle de chacun à l'aide des quatre lettres suivantes :

Exemple RACI

·      R : responsible. : responsable

·      A : accountable : ou peut le traduire par « autorité » mais ce sont ceux qui doivent rendre des comptes

·      C : consulted. : consulté

·      I : informed : informé.

Exemple de tableau RACI

On s'aperçoit souvent qu'il n'est pas toujours simple d’identifier sans ambiguïté le responsable à chaque tâche. Des fois il n'a aucun responsable et des fois il y en a plusieurs. Ceci explique les confusions parfois constatées.

A partir de cette liste de tâches il est possible de fixer pour chacune la date de début, la durée probable et en déduire la date de fin. Il est aussi possible d'estimer la charge de travail nécessaire en nombre de jours en distinguant celle des informaticiens (la maîtrise d'œuvre) et celles des utilisateurs (la maîtrise d'ouvrage). C’est le cœur de la planification des projets.

Le contenu de la note de cadrage

Une note de cadrage est un document court. Généralement elle fait 2 à 3 pages. Elle est généralement rédigée en une demi à une journée par un professionnel expérimenté. Ce document a pour premier objectif de définir le qui fait quoi (^[1]). Pour cela on établit deux listes et un tableau:  

·   La liste des tâches en se basant sur des listes de tâches standard qui sont adaptées aux particularités du projet,

·      La liste des participants au projet : informaticiens et utilisateurs (maîtrise d’œuvre et maîtrise d’ouvrage),

·       Le tableau d’affectation des tâches aux personnes. C’est le rôle du tableau RACI.

Ces deux listes et ce tableau est la base de la note de cadrage.

Il est possible de leur ajouter différents tableaux complémentaires :

·      Une évaluation de la charge de travail nécessaire pour réaliser l'étape. Cette estimation peut être faite globalement ou détaillée par tâche. Elle peut concerner exclusivement le personnel de l'équipe informatique (la maîtrise d'œuvre seule) ou l'ensemble des personnels concernés y compris les utilisateurs participants aux opérations au cours de cette étape (la maîtrise d'œuvre et la maîtrise d'ouvrage).

·     Les délais de réalisation des différentes tâches en tenant compte de leurs dates de début et dates de fin. Cela peut être une évaluation globale ou une estimation tâche par tâche. Il est ainsi possible de fixer une date probable de fin de l'étape.

Ces informations sont très utiles pour informer les différents intervenants la charge de travail qui leur est affecté et les contraintes de délai qu'ils doivent respecter.

On peut envisager d'ajouter à ces données quelques informations générales concernant le projet :

·       Le domaine de la future application (à qui et à quoi elle servira).

·       Les objectifs à atteindre qui ont été fixés à l'origine du projet.

·       La démarche suivie et notamment la liste des étapes (le découpage du projet).

·       La description des livrables de l'étape (par exemple le plan des documents à livrer).

Il n'est pas nécessaire d'en faire des pages mais de rappeler quelques orientations qui permettront d'éviter d'éventuelles dérives.

Quelques règles simples

Pour établir la note de cadrage il est nécessaire d’appliquer quelques règles de simples comme par exemple :

·      Rédaction de la note de cadrage. Généralement elle est rédigée par le chef de projet. C'est la première chose qu'il doit faire lorsque un projet lui est confié. Il peut arriver que la note de cadrage soit établie par le maître d’ouvrage ou par un assistant à maître d'ouvrage ([2]). La première note de cadrage qui est établie au moment où on décide de réaliser une étude de faisabilité est un cas particulier. Elle est généralement appelée la note de lancement et elle est, très souvent, rédigée par le décideur demandeur du projet.

·    Validation du document. Les différentes notes de cadrage sont validées par le comité de pilotage pour s'assurer du consensus de l’ensemble des parties prenantes. Au début du projet le comité de pilotage n'a pas encore été désigné. Il est alors difficile de trouver une instance de validation. Ce travail peut être confié au comité de direction ou à une commission informatique. Ce n’est pas la meilleure solution mais c’est mieux que l’absence de validation.

·   Clarté du texte. Il est important d'avoir un document court et clair. Un document trop volumineux ne sera pas lu par les décideurs. De plus il sera long à rédiger or, au moment d'un lancement d'une nouvelle étape, il faut aller vite. Il ne faut pas que la note de cadrage dépasse 3 pages. Au-delà c'est déjà un document d'analyse qui risque d'anticiper sur des travaux qui seront effectués ultérieurement. 

·      Avoir un modèle de référence. Pour aller vite il est pratique que le rédacteur ait à sa disposition un modèle de référence de la note de cadrage et qu'il adapte au cas particulier qu'il va prendre en charge. Cette collection de notes de cadrages de référence couvrant les différentes étapes du projet doivent être maintenu par la direction des études de la direction des systèmes d'informatique, et plus particulièrement par le responsable méthode, s'il existe.

·       Liste des tâches standards. D'un projet à l'autre on retrouve à peu près les mêmes tâches aux différentes étapes du projet. Il est pour cette raison souhaitable de mettre à la disposition des chefs de projets une liste des tâches standard correspondant à chaque étape (^[3]). A défaut on peut s’inspirer du découpage d’un projet analogue.

·      Trouver la bonne maille. Il est recommandé de ne pas décomposer l'étape en tâches trop petites. En moyenne elles durent de 1 à 5 jours par tâche, rarement plus. On commence la rédaction d'un programme le lundi, on le test et le termine le vendredi. On a intérêt à regrouper les opérations voisines en une seule tâche par exemple la programmation, les tests techniques et la documentation d'un programme est une même tâche et non en trois. De même si un groupe de travail se réunit une fois par semaine pendant trois mois, soit environ 10 réunions, on considère que ce ne sont pas dix tâches mais une seule. Par contre la rédaction du cahier des charges, qui représente une grosse charge de travail, peut être décomposé en plusieurs tâches par exemple une tâche par chapitre important.

·     Ne pas oublier le style. Une attention particulière doit être portée au style de la note de cadrage. Il doit être simple et direct. On doit éviter d'employer des termes trop généraux car ils sont souvent source d'ambiguïté et donc de confusion.

·    S’assurer du consensus. Il est important de s'assurer qu'il existe un réel consensus de l’ensemble des intervenants et des différentes parties prenantes. Il est nécessaire qu'il y ai un accord sur les objectifs recherchés, les délais de réalisation et de mise en place. Enfin un accord explicite doit exister concernant la charge de travail nécessaire pour mener à bien l'étape.

·      Limiter le volume de travail. L'expérience montre qu'il n'est pas souhaitable de passer trop temps à établir la note de cadrage. Un professionnel expérimenté disposant d'un modèle et d'une liste des tâches standard n'a pas besoin de plus d'une journée de travail. Par contre il peut arriver qu'il passe plus de temps ensuite à la faire valider par l'ensemble des parties prenantes, surtout si elles sont réticences au projet.

Ces différentes règles sont simples à appliquer et ne posent pas de problèmes. Faut-il encore les appliquer. Or, très souvent, croyant bien faire, on en fait trop. On finit pas faire de la rédaction de la note de cadrage une étape avant celle qui est à réaliser. Ce n’est pas raisonnable. Il est nécessaire d’aller vite.

Rédaction et validation de la note de cadrage

Dans le cadre d'un projet il est nécessaire d'établir au moins quatre notes de cadrage  correspondant aux principales étapes :

·       L’expression des besoins souvent appelé l'étude de faisabilité ou business case. Dans certains cas on l’appelle la note de lancement.

·       Le cahier des charges correspondant à l'étape d'analyse fonctionnelle.

·      La réalisation. Elle peut comprendre une ou plusieurs étapes. Il peut y avoir aussi plusieurs itérations dans le cas de démarches agiles avec des livrables intermédiaires. 

·       Les tests. Cette note de cadrage particulière s’appelle souvent un plan de tests.

Mais souvent dans un projet il peut y avoir un nombre supérieur à quatre étapes. Dans ce cas on a un plus grand nombre de notes de cadrage.

L'expression des besoins et le cahier des charges peuvent être regroupés en une seule étape comme c'est notamment le cas dans les méthodes agiles. On note que chaque méthode s'est attachée à donner un nom particulier à cette étape : la phase d'exploration, l'initialisation, l'établissement de scénarios, le backlog, l'inception, le use case,... En fait ce sont tous des études de faisabilité plus ou moins complètes.

La maîtrise d’ouvrage a la responsabilité de s'assurer qu'avant le début de chaque étape une note de cadrage a été établie. S'il n'y a pas de chef de projet ou s'il a "oublié" de la rédiger le maître d'ouvrage peut rédiger ce document à sa place. Il arrive parfois que la direction informatique rédige la note de cadrage notamment pour les étapes de réalisation et de tests. Ce n'est pas la meilleure solution mais parfois "faute de grives on mange des merles".

Dans tous les cas le comité de pilotage joue un rôle important. Il a pour mission de s'assurer qu’à chaque étape une note de cadrage est rédigée par le chef de projet et qu'elle est conforme aux baselines du planning et du budget du projet. En cas de dérive par rapport à ces objectifs il est à même de prendre alors des décisions de redressement.

Aller plus loin que la note de cadrage

Dans le cas de projets complexes ou comportant des risques élevées on peut avoir une démarche plus structurée. C'est le rôle des Plans de Management de Projet souvent appelés PMP. C'est un document reprenant les différentes notes de cadrages correspondant aux différentes étapes du projet. Il est lancé au départ du projet. L'étape à venir est détaillée et les suivantes sont plus sommaires. Au fur et à mesure de l'avancement du projet des versions successives sont établies éliminant les étapes terminées et complétant le texte des étapes à venir. Souvent on isole en tête du document les dispositifs communs aux différentes étapes : le comité de pilotage, l'instance de coordination, la mesure de l'avancement, le suivi du budget, le tableau de bord du projet, ...

On peut aller plus loin avec les PDL, Plans de Développement de Logiciel, ou les PDP, Plans de Développement de Projet. Ce sont des documents plus ambitieux avec une définition de l'organisation du projet et de ses différentes instances de coordination, la définition des différents livrables, leurs règles de validation,.... Cette démarche concerne des projets complexes réalisés par plusieurs équipes se trouvant dans des pays différents et parlant des langues différentes, ayant des méthodes de travail différentes, …. On trouve des PDL ou des PDP dans le cas de développement de systèmes d'exploitation, des logiciels de gestion de bases de données ou des systèmes d'armes.

Au-delà de la note de cadrage

Il est aussi possible d'aller plus loin en mettant en place d’un PAQ : Plan d’Assurance Qualité. Dans ce cas on quitte le management de projet pour s'approcher d'une démarche qualité. Les deux approches sont assez voisines mais elles n'ont pas les mêmes objectifs ni les mêmes coûts. En effet la mise en place d'un PAQ a un coût non-négligeable. Il est de l’ordre de 10 % du coût du projet soit une somme équivalente au coût du management de projet. Mais si les risques de dérives ou de non-qualités sont élevés ce surcoût est parfaitement justifié. Ceci fait qu'on ne mettra en place un PAQ que si on estime que c’est nécessaire. Il est pour cela important d’évaluer les risques et les enjeux.

Mais dans la plupart des projets on n'a pas besoin de PMP, de PDL, de PDP ou de PAQ. Une simple note de cadrage par étape est largement suffisante. Par contre l'absence de ces notes de cadrage est une grave faiblesse qui peut se traduire par de graves dérives de charge, de délais et de coûts. L'absence de note cadrage explique les fragilités de nombreux projets trop souvent constatés. Les auditeurs chargés d'évaluer des projets le savent bien. La plupart des projets rencontrant de graves difficultés n'ont pas de note de cadrage. C'est un point d'audit bien connu.  

---

^[1] - Par analogie avec le théâtre on parle de "la distribution des rôles". Ainsi chacun sait ce qu'il doit faire.

[2] - Cette solution peut poser quelques problèmes car lorsque le chef de projet est nommé il arrive qu’il constate qu’il n’a pas forcement la même vision des travaux à effectuer

^[3] - Les entreprises ayant défini un découpage WBS (Work Breakdown Structure) standard il suffit de le reprendre tel quel.

Le rôle vital des comités de pilotage

De nombreux projets sont réalisés sans qu’un comité de pilotage soit mis en place. On trouve encore des responsables qui déclarent : "à quoi cela peut servir ?", "cela ne sert à rien", "c'est une perte de temps", " c’est un truc de consultant voulant augmenter ses honoraires", .... Dans d'autres cas il existe bien un comité de pilotage mais il n'en a que le nom. Il regroupe quelques personnes de bonnes volontés choisies un peu au hasard et qui ne savent pas très bien ce qu'on attend d'eux.

Souvent on considère que les comités de pilotage constituent un luxe dont il serait possible de se passer. Il existe encore des chefs de projet qui affirment qu'il suffit de rencontrer les différentes responsables de l'entreprise afin de les interroger sur leurs besoins. A leur avis c'est largement suffisant pour maîtriser le projet. Les échecs à répétition d’un certain nombre de projets montre que c'est une illusion. En fait l’absence d’un comité de pilotage est une des causes les plus fréquentes des dérives de projets.

L'observation montre que la présence d'un comité de pilotage est un facteur clé de réussite des projets. C'est une bonne pratique connue, malheureusement, elle est trop souvent oubliée. Ainsi, sous prétexte qu'un projet a une petite taille certains considèrent qu’il n'est pas nécessaire de mettre en place un comité de pilotage. Dans d'autres cas, lorsque le projet est trop complexe ou s’il se déroule dans un délai trop court, on décide qu'un comité de pilotage est sans objet. Ceci explique qu'aujourd'hui encore on constate la dérive d’un trop grand nombre projets.

Trop de projets n'ont pas de comité de pilotage

Il est important de comprendre les raisons qui incitent un certain nombre de chefs de projets et de maîtres d'ouvrage à ne pas mettre en place de comité de pilotage. Il est important de comprendre leurs raisons. Elles sont de différents ordres :

―       Certains chefs de projets affirment que les comités de pilotage sont inutiles dans leur cas car leur équipe est soudée et ses membres savent parfaitement ce qu'ils doivent faire : "Dans ces conditions il est inutile de mettre en place un comité de pilotage car il n’apportait à rien".

―       D'autres pensent que la mise en place d'un comité de pilotage va alourdir et compliquer la gestion des opérations : "Les professionnels doivent assurer leurs responsabilités", "Un comité de pilotage développe la bureaucratie et dilue les responsabilités", "Nos décideurs ne sont pas demandeurs de ce type de réunions", ....

―       La préparation d'une réunion du comité de pilotage représente une charge de travail non négligeable et finalement elle retarde les projets : "Il faut préparer des documents, établir une présentation et rédiger un compte-rendu. C'est une charge de travail significative pour un résultat aléatoire ".

―       Rien n'est décidé dans le cadre des réunions des comités de pilotage : "Cela commence par une présentation préparée d'avance, puis ensuite chacun cherche à se faire valoir", "Dans ces comités on ne décide jamais rien", "Ce sont des réunions purement formelles",.....

―       C'est trop souvent un tribunal chargé de juger le chef de projet : "Je n'ai pas vocation au martyr", "Chez nous on a la mauvaise habitude de tout critiquer", "Dans un comité de pilotage il n'y a personne pour arbitrer entre les informaticiens et les utilisateurs", ....

―       Les comités de pilotage sont souvent considérés comme des comités "Théodule" où viennent des personnes car ils n'ont rien de mieux à faire : "ils viennent boire du café ou du jus d'orange et écoutent d'une oreille distraite ce qui se dit", "on envoie au comité de pilotage les second couteaux qui ne peuvent rien décider", "lorsqu'il y a un véritable problème à traiter et qu'il est nécessaire de prendre d'urgence une décision ils rapportent le problème aux vrais décideurs et ensuite ils apportent leur réponse à la prochaine réunion", .....

Toutes ces réticences expliquent le fait que trop souvent des projets importants n'ont pas de comité de pilotage ou, s'il y en a un, il n'a pas la bonne composition et il ne joue pas le rôle qu'il devrait assurer.

Le comité de pilotage n'est pas la cerise sur le gâteau

Trop souvent on présente l'existence du comité de pilotage comme la cerise sur le gâteau. L'image est séduisante mais elle est en grande partie inexacte. Ce n'est pas la cerise sur le gâteau mais le gâteau lui-même. S’il n’y a pas un comité de pilotage performant le projet ne peut que dériver et finalement se diluer. C’est un des facteur clé de succès.

En effet, la réussite d'un projet repose en grande partie sur une coordination efficace entre toutes les parties prenantes concernées et sur une solide maîtrise de l'enchaînement des opérations. Ce sont les deux fonctions clés que doit assurer le comité de pilotage. Si les principales parties prenantes n'ont pas participé aux choix effectués il y a peu de chances qu'elles se reconnaissent dans les solutions adoptées. De plus la coordination entre les différentes parties-prenantes est un point très important. Ainsi, par exemple, une fois que la rédaction des programmes est terminée il est nécessaire que les utilisateurs soient prêts à les tester. Si cela n’a pas prévu et discuté avec les intéressés, le projet ne peut que déraper.

Cependant, le comité de pilotage n'a pas responsable du déroulement du projet. Si les choix techniques sont irréalistes ou si les développements sont réalisés par des personnes peu compétentes, le comité de pilotage a beaucoup de mal à corriger ces erreurs.

Par contre si les spécifications de la future application sont inadaptées ou si les futurs utilisateurs sont aux "abonnés absents" le comité de pilotage peut intervenir et corriger ces errements. Or, on le sait, si certains projets rencontrent ces types de difficultés ils ne peuvent que se traduire par la dérive traditionnelle des projets informatiques qui est de l’ordre de 40 %.

Dans ces conditions l'absence d'un comité de pilotage peut amener à constater ex-post une dérive significative d’un projet. A l'inverse les succès obtenus par les comités de pilotage sont dus à la conjonction de trois facteurs :

―       Définir un cadre de référence. Il doit préciser la manière de découper le projet en étapes ou en tâches, d'établir le planning du projet, de calculer la charge nécessaire de développement et de tests, d'estimer le montant du budget de projet, ... ([1])

―       Avoir un regard distant sur le projet. Le comité de pilotage a pour rôle de rappeler régulièrement aux maîtrises d’œuvre les objectifs du projet, de détecter d'éventuelles dérives et de réagir rapidement.

―       Arbitrer entre des demandes contradictoires. Il est fréquent que les différentes parties prenantes n'ont pas les mêmes attentes et il est nécessaire d'arriver à établir des compromis entre eux.

Ces trois facteurs permettent aux comités de pilotages d'améliorer de manière significative la maitrise du développement des projets.

Les rôles du comité de pilotage

Un comité de pilotage est avant tout un organe de régulation du projet. Il assure simultanément différents rôles :

―       Organiser le dialogue entre les différents managers de l'entreprise notamment sur le contenu du futur projet. Ce débat préalable permet d'éviter des déceptions lors de la recette de l'application qui se traduisent par des difficultés de démarrage pouvant aller jusqu'au blocage lors de la mise en œuvre de l’application. La discussion entre tous les décideurs concernés est importante. Pour cette raison il est nécessaire de s'assurer que toutes les parties prenantes se sont complétement exprimés sur le contenu du projet.

―       Fixer les objectifs et les orientations du projet. C'est le rôle clé du comité de pilotage. Deux systèmes d'information ayant les mêmes fonctions peuvent avoir une organisation et des résultats très différents selon les priorités qui ont été fixées par le comité de pilotage. Lors de l'étude d'expression des besoins des objectifs et des orientations doivent avoir été déterminés par le maître d'ouvrage. Il est ensuite nécessaire que le comité de pilotage les valide et s'assure que le cahier des charges permet effectivement de les atteindre.

―       Effectuer les arbitrages notamment entre la richesse fonctionnelle de la future application, son budget, ses délais et la qualité attendue. C'est un équilibre difficile à trouver car les attentes des différents parties prenantes concernées sont variables et hétérogènes. Les discussions et les négociations se déroulent au sein du comité de pilotage. Le chef de projet et le maître d'ouvrage ont la responsabilité de l'informer de manière complète afin qu'il puisse faire des choix éclairés.

―       Valider, arrêter le planning et le budget. Une fois le cahier des charges rédigé le comité de pilotage à la responsabilité de confirmer ces choix. Les nouveaux plannings et budgets du projet à l’issu de ce travail d’analyse fonctionnelle sont souvent assez différents de ceux qui ont été défini à l'origine. C'est un sujet essentiel de discussion au sein du comité de pilotage car il est toujours possible d’envisager de s'y prendre autrement.

―       Suivre le projet au cours des différentes étapes. Le comité de pilotage doit s’assurer que tout se passe comme prévu, notamment au cours de l'étape de réalisation. Pour cela on va périodiquement évaluer l’avancement du projet et rapporter cet indice à la charge de travail consommée de façon à détecter d'éventuelles dérives. Il est alors possible de prendre les mesures nécessaires pour les corriger. 

Comme on le voit le comité de pilotage a un rôle d’animation et en même temps une mission de contrôle du projet au sens large du terme. Il doit s'assurer que tout se passe comme prévu et que le résultat de chaque étape est conforme à ce qui est attendu, par exemple que le document appelé "cahier des charges" a un contenu conforme, qu'il est complet et qu'il est bien aligné sur le document de référence antérieur, généralement appelé dossier d'expression des besoins. De même au cours de chaque étape le comité de pilotage doit s’assurer que le travail prévu est effectivement terminé et que la consommation de la charge est conforme à ce qui est prévu.

Le rôle clé du cahier des charges 

Dans ce contexte l'étape d'analyse fonctionnelle débouchant sur le cahier des charges est un moment très importante et le comité de pilotage joue un rôle clé dans l'élaboration et la validation du cahier des charges.

Bien entendu, le comité de pilotage ne va pas rédiger le cahier des charges. Il n’en a pas le temps ni forcement les compétences. Il n'a pas non plus la responsabilité de son établissement. Ce travail incombe aux futurs utilisateurs sous l’autorité de la maîtrise d'ouvrage. Si c'est nécessaire ils se font aider par une assistance à la maîtrise d'ouvrage.

Parfois la maîtrise d'œuvre (l'équipe informatique) assure ce travail mais il risque d’être ensuite contesté lors de la mise en place de l’application.

De manière plus générale le comité de pilotage a la responsabilité de s'assurer que ces opérations se sont déroulés normalement, conformément à ce qui était prévu.

Le comité de pilotage n'a pas la possibilité d’effectuer la validation détaillée du cahier des charges. Ses membres n'ont ni la compétence ni le temps de le faire. Par contre il a la responsabilité de s'assurer qu'il y a bien eu une validation, que les corrections nécessaires ont été effectuées et que toutes les parties prenantes ont bien été consultées. En cas de doute il peut nommer un groupe de travail chargé de valider le document et de lui rendre compte. Dans ce cas, il faut le savoir, le projet perd un à deux mois, parfois plus, par rapport au planning initial.

Soyons précis, le comité de pilotage a la responsabilité de s'assurer qu'il y a bien eu une double validation, fonctionnelle et technique, qu'elle a été faite par les personnes concernées et qu'un nouveau budget et un nouveau planning alignés sur ceux établis à l'origine. De plus il doit vérifier que toutes les parties concernées ont effectivement participé à la validation. Si ce contrôle n'est pas effectué il arrive qu'on s'aperçoit ensuite, en cours de réalisation, voir lors des tests, que des fonctions importantes ont été oubliées ou que le budget prévu est nettement insuffisant.

Le rôle particulier du comité de pilotage dans le suivi des opérations

Durant les phases de conception du projet mais surtout au cours de l'étape de réalisation et de tests le comité de pilotage a la responsabilité de s'assurer que le planning et le budget du projet sont respectés. Pour cette raison un tableau de bord du projet doit être régulièrement établi dont ses membres sont les principaux destinataires. Généralement il est établi tous les mois par le chef de projet ou l’assistance à la maitrise d’ouvrage. Il permet de suivre un certain nombre d'indicateurs concernant :

―       L'avancement du projet,

―       La charge de travail consommée,

―       Le planning constaté par rapport au planning prévu,

―       Les dépenses engagées et constatées,

―       Différents ratios de productivité et d'efficacité.

Le tableau de bord permet de rapprocher les valeurs actuelles de ces différents indicateurs et les valeurs objectifs ou prévues.

Par contre le comité de pilotage ne va pas se réunir pas tous les mois pour analyser le tableau de bord du projet. Normalement il se réunit aux moments clés du projet comme à la fin d'une étape ou au début de l'étape suivante. S'il se réunit tous les mois il est possible que ce ne soit pas un vrai comité de pilotage mais plutôt un comité d'avancement chargé de suivre les opérations et de prendre les décisions correctives nécessaires. S'il se réunit périodiquement ce n'est plus un comité de pilotage mais un comité chargé de l'avancement suivant le détail des opérations.

Cependant le comité de pilotage n'a pas à se substituer au chef de projet ni d’essayer de diriger le projet à sa place les opérations. Au contraire, son rôle est de le renforcer et de l'aider à mener à bien sa mission.

A défaut de tableau de bord il est utile de communiquer a minima aux membres du comité de pilotage chaque mois le planning et le relevé des dépenses effectuées au titre du projet. Il est important que ces documents soient transmis aux intéressés accompagnés d'une courte note d'explication. Il n'est, par contre, pas utile de réunir le comité de pilotage pour commenter ces chiffres car tout décideur expérimenté sait les lire. Par contre en cas de dérive significative, de défaillance d'un fournisseur important ou si on constate que la solution technique envisagée ne donne pas les résultats attendus, le président du comité de pilotage peut prendre l’initiative de réunir en urgence.

Le comité de pilotage n'est pas un groupe de travail parmi d’autres

Comme nous venons de le voir trop souvent on confond le comité de pilotage avec d'autres instances concourant au projet comme :

―       Le comité projet ou le comité d'avancement. Il se réunit tous les mois dans les premiers jours du mois pour faire le point sur le projet et régler les différents problèmes qui peuvent survenir. Il est chargé de mesurer l’avancement du projet. Il comprend les principaux responsables de l’équipe de réalisation (la maitrise d’œuvre) et des représentants de la maîtrise d’ouvrage ([2]).

―       Un groupe de validation. Il est constitué à la fin de l'étape d'analyse fonctionnelle afin de s'assurer que le cahier des charges est complet et qu'il est conforme aux demandes figurant dans le document d'expression des besoins. S'il trouve des absences ou des incohérences il demande à l'équipe projet de corriger ou de compléter le cahier des charges.

―       Un groupe d'information. Il a pour but d'informer sur le contenu du projet toutes les personnes intéressées. Viennent à ses réunions toutes les personnes qui le souhaitent. C'est une réunion ouverte. Ces réunions se tiennent deux ou trois fois au cours de l'étape de l'analyse fonctionnelle puis ensuite une ou deux fois au moment des tests.

―       Un groupe de travail. Il regroupe quelques personnes concernées par l'étude d'un point particulier ou pour effectuer un travail spécifique comme de recenser tous les écrans qu'il sera nécessaire de développer ou de rédiger un ou plusieurs chapitres du cahier des charges. Par contre l’idée de faire dessiner par un groupe de travail tous les écrans risque d'entraîner des dérives importantes dans le temps car cela représente une importante charge de travail. Il est préférable de faire faire ce travail par des professionnels puis de faire valider le résultat par un groupe de travail.

―       Une réunion de l'équipe de développement. C'est une instance très utile pour informer et motiver les développeurs. Le but de ces séances est de leur rappeler les objectifs du projet, de faire le point sur l'avancement des opérations, de leur signaler les difficultés rencontrées, de leur présenter les solutions adoptées, d’analyser les causes des retards constatés sur le planning d'origine, ...et surtout de rappeler à chacun l’importance de son rôle.

Ces différentes instances ont leur utilité et leur rôle mais elles ne doivent pas être confondues avec le comité de pilotage qui est un organe tout à fait spécifique car son rôle est de garantir l’évolution régulière du projet.

Nécessité d'avoir dans le comité de pilotage des décideurs de bon niveau

La composition du comité de pilotage est un point très important à examiner. Pour être efficace ce doit être un groupe de taille limitée ne comprenant que des décideurs (^[3]). Ils doivent être choisis en fonction de leur intérêt particulier pour le projet. Généralement ils sont directement concernés par la mise en œuvre de la future application, et ils veulent s'assurer de ses orientations et de l'avancement du projet.

Le chef de projet et le maître d'ouvrage participent au comité de pilotage. Leur rôle est de décrire l'avancement du projet, les résultats obtenus, les difficultés rencontrées, ... Pour cette raison ils n’est pas souhaitable qu’ils dirigent pas les débats. C'est, normalement, le rôle du président du comité de pilotage. Généralement on choisis pour assurer ce rôle le décideur le plus directement concerné par le projet. On peut aussi choisir une personne ayant déjà eu à gérer des projets complexes du même type.

Parfois on nomme le chef de projet où le maître d'ouvrage président du comité de pilotage. Ce n'est pas une solution conseillée car, dans ce cas, cette personne est à la fois juge et partie. Lorsqu'un problème délicat survient ils risquent de ne pas avoir une attitude neutre à l'écoute de l'ensemble des parties prenantes.

De même, comme nous l'avons vu, il n'est pas nécessaire que toute l'équipe informatique participe au comité de pilotage. Ils ont souvent le sentiment de perdre leur temps car leurs préoccupations sont assez loin des discussions entre les autres membres du comité de pilotage. Ils sont plus intéressés de participer à un comité projet ou un comité d'avancement. De même il n’est pas indispensable de faire venir les chefs d'équipe de la maitrise d’œuvre au comité de pilotage sauf s'ils sont directement concernés par un des points de l'ordre du jour ([4]).

Autre point important : le comité de pilotage n'est pas un tribunal chargé de juger le chef de projet. Ce n'est pas non plus un face à face entre les informaticiens et les utilisateurs. C'est au contraire un lieu de discussion, de recherche de solutions en vue de l'établissement de compromis entre des visions et des approches différentes.

On a parfois tendance à faire du comité de pilotage un organe où toutes les départements de l'entreprise sont représentés de façon à en faire une sorte une assemblée générale. Cela risque de faire beaucoup de monde autour de la table alors seuls quelques personnes sont directement concernés. Dans ces conditions les débats sont chaotiques et il devient difficile de faire prendre des décisions. Les comités efficaces ont en général une taille réduite.  

Cas pratique. Une entreprise du secteur de l'industrie lourde décide de lancer un projet informatique permettant d'améliorer la coordination et le suivi des commandes clients entre les différents départements. Son budget est de 5 millions d’euros. Le comité de pilotage comprend cinq personnes :

―       Le directeur commercial,

―       Le directeur de production,

―       Le directeur informatique,

―       Le maître d'ouvrage,

―       Le chef de projet.

Ce sont tous des décideurs. Le président du comité de pilotage est le directeur de production car il est responsable de l'équipe de planification de la production qui aura ensuite la responsabilité d’assurer le fonctionnement courant de la future application.

On notera que généralement le directeur général n'est pas membre du comité de pilotage. Ce n'est pas nécessaire. Cependant, dans certains cas sa présence peut être utile notamment si on estime que des décisions délicates doivent être prises au cours du projet.

Le rôle clé du président du comité de pilotage

Le choix du président du comité de pilotage est une décision importante. Si on choisit une personne trop autoritaire on risque de subir des tensions et des conflits. Au contraire si c'est une personne trop laxiste le projet risque de s'enliser. Le président idéal doit être une personne patiente et raisonnable.

Son rôle principale est d'animer les réunions du comité de pilotage. Il doit notamment veiller à ce que toutes les parties prenantes puissent s’exprimer. En cas de difficulté il doit s'efforcer de trouver des compromis acceptables par toutes les parties prennantes.

Le président du comité de pilotage peut être amené à prendre des décisions comme :

―       Nommer le chef de projet. La nomination du chef de projet par le président du comité de pilotage est un moyen efficace permettant de développer une relation de confiance entre eux. Cependant ce n'est pas toujours le cas car il peut avoir été nommé avant que soit désigné les membres du comité de pilotage. Le président du comité de pilotage peut aussi être amener à remplacer le chef de projet. C’est une situation plus délicate.

―       Valider les notes de cadrage ou le PMP, Plan de Management de Projet. Ces documents définissent le fonctionnement d'une étape à venir ou de l'ensemble du projet et notamment la répartition des tâches entre les différents intervenants. L'existence de ces documents est pour le comité de pilotage l’assurance d’une meilleure maîtrise du projet ([5]).

―       Valider le principe de la sous - traitance d'une partie ou de l'intégralité du projet. Il peut arriver que face à des difficultés notamment des retards constatés par rapport au planning initial le président du comité de pilotage décide qu'il est nécessaire de sous-traiter une partie du projet ([6]).

―       Convoquer le comité de pilotage en urgence. En cas d'incident grave risquant de mettre en difficulté le projet il peut décider qu'il est nécessaire de faire le point et, le cas échéant prendre des décisions. 

―       .....

Comme on le voit le choix du président du comité de pilotage est une décision importante et elle a une forte influence sur la maîtrise du projet.

Pour avoir une gestion de projet efficace il est d’abord nécessaire d'avoir une démarche fiable et éprouvée et ensuite de la confier à un chef de projet efficace et compétent. Le comité de pilotage n'est pas là pour dicter au chef de projet la méthode de gestion de projet ni à lui imposer la manière de gérer le projet. De même il n'a pas à se substituer à un chef de projet insuffisant. Par contre il a la responsabilité de détecter les fragilités de la méthode employée ou les limites des compétences du chef de projet.

---

[1] - Ce cadre de référence peut être une simple note de cadrage, un plan de management de projet (PMP) ou un plan d’assurance qualité (PAQ). Ce peut aussi être une méthodologie de gestion de projet mais dans ce cas on reste au niveau des principes et il manque dans ce document les modalités pratiques du projet.

[2] -  La composition du comité d’avancement et du comité de pilotage est très différente. Généralement le comité de pilotage ne comprend pas tous les membres de l'équipe projet mais seulement le chef de projet et si c'est nécessaire, un ou deux collaborateurs pour l'assister. Le participants du comité de pilotage sont pour l’essentiel des décideurs des différents métiers concernés par le projet.

^[3] - Un décideur est une personne ayant de larges responsabilités. Selon une jolie formule on dit : "qu'il a charge d'âmes".  

[4] - Il faut prendre garde au fait que leur présence peut être interprétée par les autres membres du comité de pilotage comme la volonté de « faire la salle » pour inverser le rapport de force.

[5] - Dans certains cas il existe un Plan d’Assurance Qualité (PAQ). Dans ce cas le comité de pilotage a la responsabilité de valider ce document et de s’assurer de son application effective.

[6] - Par contre le choix du ou des prestataires relève de la maitrise d’œuvre sous le contrôle de la maîtrise d’ouvrage.