Dans les années 1950, le monde de l’informatique est réglé par seulement deux langages de programmation: le Cobol et le Fortran. Aujourd’hui, il est non seulement impossible de les dénombrer, mais ils ont aussi essaimé dans d’autres disciplines, comme la gouvernance informatique, l’architecture, la maintenance de système ou le management de projet, qui ont eux-mêmes développé leurs propres standards.

Et pourtant, force est de constater que l’équilibre tant recherché entre les délais, les besoins et les coûts ne semble toujours pas atteint. Les organes de directions cherchent à maîtriser les projets informatiques et confirment le sentiment que les standards n’assument pas toujours le rôle que l’on voudrait leur voir jouer dans le succès des projets.

Forts de cette constatation, les développeurs et les entreprises inventent d’autres manières de travailler pour améliorer le taux de réussite des projets, et de nouvelles méthodes sont élaborées. Aucune ne se ressemble, mais chacune pointe du doigt le temps consacré à la documentation des projets qui alourdit les processus de décision. Le maître-mot est la suppression des procédures fastidieuses pour centrer l’effort sur l’objectif à atteindre.

Deux courants majeurs illustrent aujourd’hui ce phénomène:

  • Le premier consiste à accompagner le développement selon les principes définis par la «mouvance agile». 
  • Le deuxième, moins identifiable car peu formalisé, promeut une gestion de projets à l’instinct, c‘est-à-dire sans méthode ou principes prédéfinis.

Mais s’agit-il de tendances durables ou de simples modes? Face à ces nouveaux venus, quelle doit être la position des standards traditionnels qui accompagnent les utilisateurs parfois depuis plus de trente ans?

L’agilité avec la méthode Scrum: une démarche qui s’étend à la gestion de projet

Le «monde agile» propose de nombreuses méthodes qui reposent toutes sur le concept décrit en 2001 dans le «Manifeste agile» (1) signé par une vingtaine de personnalités issues du développement informatique. La méthode Scrum est parmi les plus utilisées et propose un outillage léger pour gérer les projets de développement. En s’appuyant sur le postulat agile selon lequel les besoins des utilisateurs ne peuvent pas être définis en une seule fois en amont du projet, Scrum présente un déroulement structuré au cours duquel les utilisateurs valident leurs besoins à intervalles courts et réguliers.

Les règles sont simples, peu nombreuses mais obligatoires, et c’est leur respect qui garantit la réussite du projet: 

  • Les développeurs sont soumis à des rapports courts, mais quotidiens.
  • Le système informatique est développé par tranches successives qui sont directement testées. 
  • Le résultat du test détermine de la suite à donner au projet. 
  • Seuls les développements aboutis peuvent être livrés par les développeurs.

Les utilisateurs peuvent ainsi au fur et à mesure tester le système et se rendre compte avant sa réalisation finale s’il correspond bien à leurs besoins.

Ainsi que le souligne une enquête de 2010, l’agilité est une réalité adoptée pour les développements informatiques par environ 35% des entreprises. (2) Et cette réalité fait école dans le domaine de la gestion de projet pure, qui cherche à améliorer depuis de nombreuses années la consolidation des besoins des utilisateurs.

La gestion de projet sans méthode établie au profit du résultat

Parallèlement, la gestion de projet connaît également la tendance inverse qui consiste à dire que toutes les méthodes, indépendamment de leur tendance idéologique, ralentissent les projets par excès de conformisme. Ainsi, la gestion de projet «à l’instinct», qui est pratiquée tacitement depuis des décennies, se voit érigée en méthode de travail. Le projet comporte deux étapes importantes: l’idée de départ qui donne l’impulsion, et le résultat final qui fournit un produit ou un service. Entre les deux, peu importent le chemin suivi et les rôles désignés.

Chez Google par exemple, pas de certification, pas de standard ou de processus officialisés. Le chef de projet est responsable de sa planification et s’organise comme bon lui semble. Libre à lui de choisir – ou de ne pas choisir– les méthodes, les outils et les standards qui lui conviennent. Comme l’expliquait un responsable de produit devant un panel de chefs de projets (3) cette absence de règles est considérée comme le moteur pour l’innovation nécessaire à la survie de l’entreprise. Elle est la condition sine qua non à la motivation des collaborateurs qui décident eux-mêmes du chemin à suivre.

Ici, l’absence de méthode officielle est une méthode en soi puisqu’elle est appliquée de manière consciente et assumée, voire même revendiquée. De nombreuses entreprises travaillent plus ou moins officiellement selon le même principe. Chacun se débrouille pour faire avancer ses dossiers en suivant le chemin le plus adapté pour l’activité en question. Le modèle est alors tacite et les bonnes pratiques des projets précédents servent d’exemples intuitifs.

Les standards traditionnels toujours d’actualité sur le marché de la gestion de projet côté utilisateurs

Et qu’en est-il des standards traditionnels qui proposent souvent des démarches basées sur des modèles divisés par phases? Facile à appréhender, ils partent du principe qu’un projet débute par une initialisation et se termine par une finalisation. Entre ces deux pôles, les besoins des utilisateurs sont recensés, analysés et réalisés (illustration 1).



Illustration 1: le modèle de phases HERMES

Ces modèles correspondent à un mode de pensée logique largement répandu dans tous les domaines des entreprises puisque cette succession d’étapes est ancrée dans la majorité des activités de la société occidentale. Ces standards sont donc faciles à présenter et les acteurs du projet issus de la direction, ou de l’opérationnel, les assimilent rapidement.
Dès lors, bien qu’ils ne représentent plus qu’une partie minoritaire des méthodes utilisées dans le développement informatique, il n’est pas étonnant de les retrouver comme des valeurs sûres dans la gestion de projet côté utilisateurs.

Certaines méthodesi (4) proposent des modèles génériques adaptés à tous les types de projets. D’autres, comme HERMES, décrivent, outre les activités liées au management de projet, les différentes étapes spécifiques à la réalisation d’un système informatique. A côté des standards du marché, il faut encore citer les méthodologies développées en interne. Par exemple Cali (5) ou HERMES PF (6), une version adaptée de la méthode de la Confédération. Bien intégrés à la culture de l’entreprise, ces modèles se fondent sur la démarche des étapes successives. Il est intéressant de noter que la mise en place de ces méthodes s’accompagne d’une professionnalisation générale du métier de chef de projet. Les responsables hiérarchiques accordent toujours plus d’importance à travailler avec des collaborateurs dotés d’une certification qui atteste de leurs compétences dans le domaine.

Conjuguer les tendances

Cela dit, les critiques ne sont jamais très loin, et les attentes, même parmi les plus fidèles, sont grandes. Les standards traditionnels doivent être capables de puiser dans les nouvelles tendances pour se renouveler tout en capitalisant sur les qualités qui constituent leur base, afin de proposer aux utilisateurs des outils en accord avec leur temps et leurs besoins.

Pour HERMES, l’opportunité de se renouveler se présente actuellement. Début 2010, l’Unité de stratégie informatique de la Confédération USIC a lancé un projet de réédition de la méthode. HERMES, développée depuis 1975, est le standard pour la gestion de projets informatiques de la Confédération suisse et le standard en matière de gestion de projet dans le domaine de la cyberadministration de l’association eCH (plate-forme des standards de développement du e-gouvernement en Suisse). La méthode connaît un véritable engouement. Outre la Confédération, les cantons et les villes sont de plus en plus nombreux à l’adopter, de même que des entreprises privées. Son utilisation ne se limite plus aux seuls projets informatiques, puisque la méthode sert de fil rouge aussi pour les projets organisationnels. Depuis son lancement en 2007, plus de 1000 personnes ont effectué la certification HERMES, les publications sont largement diffusées, avec environ
22 000 livres distribués depuis 2003, et les formations proposées par la Confédération comptent 400 participants en moyenne annuelle.

Les attentes envers la nouvelle version de la méthode baptisée HERMES 5 sont donc grandes, et chacun imagine les solutions à intégrer pour améliorer le travail sur le terrain. Toutefois, les premières exigences recensées ont mis à jour une contradiction majeure dans la droite ligne des tendances analysées précédemment. 

  • D’une part, tout le monde s’accorde à dire que HERMES doit être simplifié au niveau de son contenu et qu’il convient d’alléger la production documentaire. 
  • D’autre part, chacun souhaite ajouter à la méthode une matière qui manque actuellement. La nature de ce supplément varie selon la fonction ou le domaine dans lequel travaille l’utilisateur: les aspects financiers, la gestion de programme, la maintenance, les sciences humaines, la cyberadministration, le requirements engineering, l’audit, la planification, etc.

Pour faire face à cette demande d’allègement documentaire doublée d’une formalisation accrue de nouveaux domaines, l’équipe de projet a décidé de travailler en collaboration étroite avec les utilisateurs de HERMES et les experts des domaines voisins. Une démarche en trois étapes a été élaborée afin de pouvoir livrer des propositions de solutions fin 2010 au comité de projet.

La première étape consiste à identifier les atouts de la méthode HERMES. Ceux-ci sont souvent les mêmes que dans les autres méthodes de bonne qualité disponibles sur le marché; ils garantissent la pérennité du produit. 

  • Une structure solide: HERMES est basé sur un méta-modèle structurant. Le modèle de phase est ainsi constitué de plusieurs types de projets et de sousmodèles transversaux à l’ensemble des phases. Au sein de chaque phase, le projet est réparti en résultats, rôles et démarches dont les interactions sont définies. Cette colonne vertébrale solide et rigoureuse permet de manier les différents éléments et de ne conserver que les plus adaptés à la situation sans pour autant se heurter à des incohérences structurelles. 
  • Le résultat comme objectif: le résultat principal est le système socio-technique à produire, c’est-à-dire le logiciel et ses interactions avec l’environnement dans lequel il est implémenté. Pour l’atteindre, HERMES propose des résultats intermédiaires qui évoluent au fil du projet.
  • Une description claire des rôles et responsabilités: les rôles dans HERMES sont souvent cités en exemple par les utilisateurs. Ils positionnent clairement les acteurs, que ces derniers figurent dans le projet, dans la ligne hiérarchique ou dans les instances de contrôle.
  • Une démarche identifiée: la transparence de la démarche est le garant de la survie du projet en cas de changement d’équipe. Par ailleurs, l’assurance qualité du projet permet de répondre à un contrôle dans un temps restreint.

Dans un deuxième temps, les atouts des nouvelles tendances seront décryptés avec des experts de chaque domaine dans le cadre d’ateliers. L’objectif est d’en retirer les aspects transposables pour HERMES.

En ce qui concerne l’agilité, des travaux préparatoires apportent déjà quelques solutions. Dans un document publié par l’USIC (7), les auteurs constatent que la combinaison de Scrum et de HERMES est réalisable, et apporte même des avantages aux deux méthodes qui s’avèrent alors complémentaires.

Concrètement, la solution proposée consiste d’abord à fusionner les phases «Conception», «Réalisation» et «Introduction» en une phase générale appelée «Développement agile selon Scrum», comme l’expose l’illustration 2.

Illustration 2: HERMES pour la gestion de projets – Scrum pour le développement

Ainsi, les restrictions liées à la séquentialité des phases sont supprimées et les étapes de travail peuvent être réalisées à n’importe quel moment de manière incrémentielle et itérative.

Les résultats liés à HERMES comme la documentation, les séances ou les points de décisions sont intégrés à l’issue de la phase d’«Analyse» dans la liste des tâches, soit le Product Backlog. Ainsi, pour chaque livraison de système, l’utilisateur peut modifier la liste des tâches en fonction des tests effectués. Le risque de se retrouver lors de la phase d’«Introduction» avec un produit qui ne correspond pas au besoin est donc fortement réduit.

Parallèlement, les activités hors développement de système, telles que la préparation de la formation, l’assurance qualité ou l’intégration aux processus métiers, peuvent être réalisées selon la démarche prévue par HERMES.

Comme dans cet exemple qui impacte la démarche de la méthode, les résultats des ateliers seront toujours liés à l’un des éléments structurants de la méthode (phase, démarche, rôle, résultat) afin de garantir une intégration cohérente des nouvelles tendances.

Pour finir, la troisième étape consiste à examiner ces nouveaux aspects sous l’angle de leur intégration concrète à la méthode HERMES. Le 28 septembre prochain aura lieu à Berne une journée ouverte à tous les utilisateurs de la méthode qui souhaitent participer à l’élaboration d’HERMES 5. (8) Les participants seront d’abord informés des thèmes sélectionnés lors des ateliers. Une présentation didactique des sujets cadres permettra à chacun de choisir le domaine dans lequel il souhaite s’exprimer. Ensuite, des échanges ciblés se feront dans le cadre de petits groupes. L’objectif est de trouver ensemble un chemin susceptible de répondre aux attentes de chacun. L’étude des différents thèmes doit se faire dans une optique pratique, proche des besoins du terrain, afin de livrer des solutions réalistes et non pas des visions théoriques.

Un standard innovant et pratique

Grâce aux enseignements tirés de ces trois étapes, l’équipe de projet pourra travailler sur des modèles de solutions à proposer au comité de projet. Les phases de «Conception» et de «Réalisation» de la nouvelle version de la méthode bénéficieront ainsi de l’apport des autres tendances et standards du marché, ainsi que des besoins des utilisateurs. Le standard HERMES 5 sera à la fois plus moderne et plus proche des réalités du quotidien.

(1) http://agilemanifesto.org/ (version du 28.5.2010)
(2) Dave West, Tom Grant (et al.), Agile Development: Mainstream Adoption Has Changed Agility, Forrester, 20 janvier 2010.
(3) Christian Miccio, «Innovation und holprige Wege», exposé donné au congrès de la swiss project management association (spm), Zurich, 17 Mars 2010.
(4) comme Prince2® du gouvernement anglais, ou PMBoK® du Project Management Institute
(5) la méthode de Swisscom
(6) chez Postfinance
(7) Unité de stratégie informatique de la Confédération USIC, Studie HERMES und Agilität am Beispiel von Scrum, avril 2010. Disponible à l’adresse: http://www.hermes.admin.ch/dienstleistungen/hilfsmittel/projektmanagement-generell/hermes-und-agilitat-am-beispiel-von-scrum (version du 27.5.2010).
(8) Information et inscription en allemand sur le site http://www.hermes.admin.ch

Sur l’auteur:
Hélène Mourgue d’Algue
, responsable de la méthode HERMES à l’Unité de stratégie informatique de la Confédération, USIC Membre du comité de direction de la swiss project management association (spm).

Source:
eGov Präsenz 2/10