Photo vintage femme pensive devant une machine à écrire
BLOG FUSEO

Implémentation d’un Système d’Information de Gestion : méthode classique ou méthode agile ?

Auteur :
Ariel Smadja

Les méthodes agiles de projet sont nées vers la fin des années 90 aux Etats-Unis en raison du taux d’échec important observé dans les années 80 et 90 dans la mise en œuvre de projets SI menés en méthode classique. Quels sont les apports des méthodes agiles dans la conduite de tels projets ?

Les méthodes classiques de projet

Depuis le début des projets de développement ou d’implémentation de SI, les méthodes classiques ont été utilisées.

Rigidité. Ces méthodes (cycle en cascade et cycle en V) se caractérisent d’une part, par leur aspect séquentiel et d’autre part, par la relation « client/fournisseur » entre la Maîtrise d’Ouvrage (MOA) et la Maîtrise d’Oeuvre (MOE). Elles induisent une véritable rigidité dans la conduite du projet.

En pratique. Chaque étape doit être validée avant de passer à la suivante (recueil des besoins, analyse, conception, développement/paramétrage, tests/recette, mise en production). Le planning doit être précis, les jalons définis à l’avance et les retours en arrière quasiment impossibles, sauf à remettre en cause les développements ou paramétrages précédemment validés, ce qui est souvent très coûteux.

Effet tunnel. Par ailleurs, la relation entre la MOA et la MOE suppose que la MOA fournisse ses « exigences » fonctionnelles à la MOE qui devra scrupuleusement les respecter lors du paramétrage. Dans certains projets, la MOA exprime ses besoins et les fournit à la MOE qui réalise le paramétrage pendant plusieurs mois avant que la MOA ne vérifie l’adéquation du paramétrage seulement à la fin du projet, lors de la phase de recettage. C’est ce qu’on appelle « l’effet tunnel ». Entre le début et la fin du projet, donc pendant que la MOE est dans le « tunnel », personne n’est en mesure de détecter si les exigences fonctionnelles ont été mal comprises ou, si les besoins fonctionnels n’ont pas, tout simplement, évolué.

A noter : le critère de réussite d’un projet en méthode classique est le respect du triptyque « Coût, Délais, Qualité ». On comprend aisément le risque d’échec. Quelle entreprise a un périmètre et des besoins fonctionnels stables pendant toute la durée d’un projet SI qui s’étale souvent sur plusieurs mois, voire plusieurs années ?    

Les méthodes agiles de projet

Elles privilégient les 4 notions suivantes :

• Les personnes et les interactions, davantage que les processus et les outils
• Des logiciels opérationnels
, plus qu’une documentation complète
• La collaboration avec le client
, davantage que la négociation contractuelle
• L’adaptation au changement
, plus que le suivi d’un plan

Un développement itératif. Les méthodes agiles, dont la plus connue est le « Scrum », privilégient les besoins des utilisateurs qui peuvent évoluer en cours du projet. L’efficacité des méthodes agiles est liée au principe de développement itératif qu’elles utilisent. Il consiste à découper le projet en plusieurs mini-projets définis avec les utilisateurs, qu’on appelle des itérations.

A noter. La relation entre MOA et MOE devient une relation de partenaires de travail avec des objectifs communs.  

Les étapes d’un projet SI

La méthode de projet retenue aura un impact sur chaque phase du projet. Les méthodes agiles introduisent souvent une dose de pragmatisme.

La phase de sélection du SI

Dans une approche classique. Cette phase commence traditionnellement par la rédaction d’un document de référence qui permettra d’évaluer la capacité des éditeurs et intégrateurs à répondre aux besoins de l’entreprise. Lorsque l’entreprise choisit d’adopter une méthode classique de gestion de projet, le document de référence prend la forme d’un cahier des charges ou d’une expression des besoins assez détaillée. Sa rédaction est souvent très consommatrice de temps et donc coûteuse. En effet, elle suppose de recueillir les besoins de tous les représentants des futurs utilisateurs du SI.

L'avantage de la méthode agile. Dans un contexte dans lequel les besoins d’aujourd’hui ne sont pas nécessairement ceux de demain, il peut être plus opportun de bien définir le périmètre fonctionnel pour guider le choix du futur système. On pourra ensuite demander la réalisation d’un Proof Of Concept (POC), via une petite maquette, aux éditeurs pressentis. Ce POC permettra de valider la couverture fonctionnelle et de tester l’évolutivité de la solution.

A noter : cette approche permet de réduire significativement le temps et le budget consacrés à la phase de choix. Le temps ainsi gagné autorise un démarrage plus rapide de la phase de mise en œuvre qui sera réalisée en collaboration étroite avec les utilisateurs.  

Conseil : profitez du temps que permet de gagner cette démarche pour rencontrer plus d’éditeurs, parmi lesquels des acteurs spécialisés qui proposent des solutions « verticalisées » (pré-paramétrées pour votre secteur).

La constitution de l'équipe projet

En parallèle de la démarche de choix de la future solution, l’équipe qui participera à la phase de mise en œuvre devra être identifiée.

A noter : le succès d’un tel projet repose sur une forte implication des équipes internes. Cela est d’autant plus vrai lorsqu’une méthode agile de projet est retenue. En effet, celle-ci supposera des ateliers de travail réguliers entre les équipes internes et l’intégrateur, afin de présenter les besoins, puis de valider le paramétrage, au fur et à mesure de l’avancement du projet  


La phase de mise en œuvre

Les avantages de la méthode agile. Lorsque la solution et l’intégrateur ont été sélectionnés et que l’équipe projet a été identifiée, la phase de mise en œuvre peut rapidement commencer. Afin d’éviter l’effet tunnel, la mise en œuvre d’une méthode agile est recommandée. Dans ce cadre, le cycle du projet sera rythmé par des itérations de quelques semaines.

Une mise en oeuvre rythmée par des itérations. Pour définir les priorités et s’assurer de la correcte adéquation des besoins des utilisateurs avec le paramétrage, des réunions d’expression de besoins seront planifiées. A leur issue, l’équipe d’intégration (MOE) va s’engager sur le paramétrage/développement qui sera livré à la fin de l’itération, appelée « sprint » dans la méthode « Scrum ».

En pratique. De brèves réunions d’une quinzaine de minutes sont organisées régulièrement pendant le sprint, théoriquement tous les jours, afin de contrôler l’avancement du paramétrage. A la fin du sprint, une démonstration des derniers développements et paramétrages est faite aux utilisateurs.

Livraison de mini-projets. En cas de validation, la MOE effectue une livraison partielle ou totale du paramétrage (mini-projet). Et ainsi de suite jusqu’au paramétrage complet de la solution qui aura été découpé en plusieurs mini-projets. Ils pourront être mis en production au fur et à mesure de leur validation.

A l’inverse des méthodes classiques, dans lesquelles le paramétrage est validé à la fin du projet, les méthodes agiles permettent donc une validation progressive du paramétrage et des ajustements fréquents en fonction de l’évolution des besoins des utilisateurs.


La conduite du changement

La démarche de collaboration permanente entre la MOE et les futurs utilisateurs durant les sprints, favorise l’appropriation du nouveau système par les utilisateurs. Alors qu’en méthode classique le déploiement d’un nouveau SI se heurte souvent à de fortes résistances, en méthode agile, le changement est intégré dans la phase de paramétrage, ce qui réduit considérablement la résistance des utilisateurs. Toutefois, quelle que soit la méthode de projet choisie, l’accompagnement au changement restera indispensable. Il se traduira par la formation des utilisateurs n’ayant pas participé au projet, l’adaptation des pratiques au sein de l’entreprise et la communication auprès des parties prenantes externes.


Alors, méthode classique ou agile ?

Sachant qu’aucune méthode ne garantit à 100% la réussite d’un projet, il faudra choisir la méthode qui correspond le mieux à son contexte.

Des critères de choix seront pris en compte :
• la disponibilité des utilisateurs,
• les priorités données au calendrier et au budget,
• la stabilité ou l’évolutivité des besoins fonctionnels, peuvent être retenus.

Pour consulter le tableau comparatif des méthodes classique et agile, téléchargez l'article complet en version PDF


Un projet de mise en place  d’un SI est un véritable projet d’entreprise dont la réussite dépend largement du niveau d’implication des utilisateurs futurs. Les méthodes agiles qui permettent une appropriation progressive de la solution par les utilisateurs et des ajustements permanents de paramétrage lors des itérations peuvent aussi largement y contribuer. Il s’agit d’une bonne alternative aux méthodes classiques pour éviter le fameux effet tunnel, à l’origine de nombreux échecs.

Retrouvez cette publication dans sa version originale ici :
Alertes & Conseils Gestion FinanceAlertes & Conseils Gestion Finance
Découvrir les offres Fuseo
Flèche