Quels types de projets peut-on retrouver en ESN (Forfait, Régie, TMA) ?

Vous vous souvenez de l’article sur notre blog : Les méthodes de gestion de projet : traditionnelles VS agiles ? Nous vous présentions différentes méthodes de gestion de projet : Cascade, Cycle en V, Scrum … Mais attention, en Entreprise de Service du Numérique (ESN), nous n’allons pas parler de Projet Scrum, ou de Projet en Cascade, mais plutôt de Projet Forfait, Régie ou TMA. A quoi correspondent ces types de projets ? Quelles méthodes de gestion de projet pourrons-nous retrouver ? C’est ce qu’on va voir dans cet article ! 😉

Projet au Forfait

Commençons par les projets au forfait ! Dans les projets au forfait, le prestataire (l’ESN dans notre cas) a une obligation de résultat avec son client. Cela veut donc dire tout simplement qu’il s’engage sur un prix fixe sur un périmètre de projet défini ! On parle souvent de projet Clef en main.

Prenons un exemple pour illustrer tout ça !

Pour faire simple, le prestataire va vendre au client un projet dont le coût total est de 35 000 euros. Ce coût a pu être proposé par le prestataire suite à une étude du projet, un découpage en tâches et une estimation en Jour/Homme. Le prestataire, à travers un devis, va proposer cette réalisation au client, en détaillant bien le périmètre et le but du projet. Si le client accepte la proposition du prestataire, ce dernier doit s’engager à livrer le projet complet pour le tarif de 35 000 euros.

Au final, si le projet a pris 200 J/H au lieu des 100 J/H initialement prévus, le client n’aura pas à payer le travail supplémentaire, puisqu’il s’est engagé pour un coût fixe.

En plus du coût du projet, le prestataire peut s’engager auprès du client sur une date de livraison (de recette ou production), qui sera mentionnée dans le devis.
L’estimation d’un projet au forfait est donc cruciale pour un prestataire, qui doit veiller, en plus de la qualité du projet, au coût et au délai.

Nous ne détaillerons pas dans cet article comment estimer un projet, mais si cela vous intéresse, n’hésitez pas à nous le faire savoir 😉 !

Quelles méthodes de gestion de projet pouvons-nous appliquer sur des projets au forfait ?

Comme dit plus haut, dans un projet au forfait, le prestataire va s’engager sur un prix fixe et surtout sur un périmètre défini. Il y a donc tout intérêt à définir au mieux le projet en amont du développement grâce à des spécifications (fonctionnelles/techniques) claires et précises. Ces spécifications, qui aideront fortement à l’estimation du projet, seront indispensables pour cadrer le projet entre le prestataire et le client.

Côté prestataire, l’équipe de développement pourra se baser sur ces spécifications pour réaliser le produit, l’équipe de test (s’il y en a une) pourra également utiliser ces spécifications pour définir des cas de test afin de veiller à la qualité du projet, et enfin le chef de projet pourra les utiliser pour faire l’intermédiaire entre les équipes MOE et les besoins clients.

Côté client, les spécifications permettront de vérifier que le prestataire a bien compris le besoin souhaité.

Le développement du projet ne pourra commencer que quand ces spécifications auront été validées !

Dans les projets au forfait, nous privilégierons les méthodes de gestion de projet dites traditionnelles (Cascade, Cycle en V, Spirale, etc.). Nous allons avancer étape par étape, en définissant clairement le besoin avec le client au départ. Ensuite, les spécifications, validées par le client, permettront de cadrer le projet et définieront le périmètre du développement. Une fois le développement terminé, le projet sera mis à disposition du client pour que ce dernier teste que tout correspond à son besoin : nous appelons ça la phase de recette. Une fois cette phase terminée, le produit est mis en production et le projet est considéré comme terminé.

Comme les méthodes traditionnelles définissent le besoin tout en amont du projet, que se passe-t-il si le besoin du client évolue ?

Il faut bien comprendre que dans un projet au forfait, le prestataire propose un certain nombre de tâches qui sont vendues à un coût fixe. Si le client souhaite bénéficier de tâches supplémentaires, qui sont hors périmètre par rapport à ce qui avait été défini, le prestataire devra réaliser une nouvelle estimation ainsi qu’un avenant au devis afin de vendre ces évolutions au client.

C’est pourquoi, lors de la phase de recette, il faudra être vigilant pour bien distinguer les bugs des évolutions :

• Un bug : anomalie sur une fonctionnalité prévue au départ qui ne fera pas l’objet d’un sur-chiffrage. Par exemple, si le prestataire était amené à développer un tableau contenant un ensemble d’objet Voitures, si le client clique sur le bouton Page suivante du tableau et que l’application renvoie une erreur 500, il s’agit bien ici d’une anomalie.
• Une évolution : fonctionnalité non prévue dans le scope initial qui devra faire l’objet d’un sur-chiffrage. Par exemple, si le prestataire était amené à développer un tableau contenant un ensemble d’objet Voitures, si le client remonte que le tableau n’est pas triable alors que cela n’était pas prévu, il s’agit bien ici d’une évolution.

Dans un projet au forfait, il est donc primordial de bien définir le besoin, afin que chaque partie prenante du projet soit en phase avec la réalisation à apporter. Les specifications ne sont pas nécessairement obligatoires, mais c’est un risque important à prendre en compte pour éviter des incompréhensions voir même des conflits.

Plus le projet au forfait est conséquent, plus il est important de bien définir le besoin ! >

Agilité incompatible avec projet au forfait ?

A première vue, il est difficile voir impossible d’utiliser des méthodes agiles dans des projets au forfait. En fonctionnement agile, le besoin est en perpétuelle évolution avec la réalisation, et va donc en contradiction avec le projet au forfait qui lui doit être cadré et spécifié.

En revanche, il est toujours possible de découper un projet en différents lots, afin de réaliser plusieurs sous-projets au forfait. Par exemple :

• Lot 1 : connexion utilisateur et profil
• Lot 2 : administration
• Lot 3 : fonctionnalité 1
• Lot 4 : fonctionnalité 2
• Lot 5 : statistiques
• …

Ainsi, chaque lot pourrait être défini via des spécifications, avec un temps de développement avoisinant des sprints que l’on pourrait retrouver en Scrum. Le besoin pourra donc être défini au fur et à mesure des lots et permettra une plus grande flexibilité par rapport à une méthode Cycle en V classique.

Néanmoins, il est tout à fait possible d’intégrer des concepts de la méthode eXtreme Programming dans des projets au forfait. La proposition initiale pourrait contenir un temps dédié à la Revue de code, ou encore à l’écriture de tests automatisés par exemple.

Projet en Régie

Dans les projets en régie, le prestataire a une obligation de moyen envers son client, contrairement à une obligation de résultats dans les projets au forfait. Quand on parle de moyen, on parle surtout de collaborateur : le prestataire va mettre à disposition un ou plusieurs collaborateurs pour le client, pendant une durée définie.

On peut imaginer cela comme si notre client avait un collaborateur embauché, mais ici le collaborateur ne lui appartient pas puisqu’il appartient à la société prestataire.

Comment cela se passe-t-il au niveau contractuel ? Contrairement au forfait, le prestataire va par exemple proposer 2 personnes à temps plein, à un tarif journalier de 350 euros, pendant 100 J/H, pour un total de 70 000 euros. Pendant cette durée, aucun périmètre de projet ne sera défini contractuellement. Si par exemple le prestataire avait estimé le projet à 200 J/H, que celui ci se déroule sur une régie de 200 J/H, et que le projet est terminé en 160 J/H, le client aura donc encore 40 J/H à disposition. Cela lui permettra de commencer un nouveau projet par exemple, où d’améliorer la qualité du projet développé initialement.

Pour résumer, l’obligation de moyen signifie que le prestataire s’engage à fournir au client un nombre de collaborateurs défini sur une période définie à un tarif journalier défini.

Dans les faits, nous pouvons retrouver plusieurs sortes de régies. Par exemple, il peut y avoir des régies qui vont durer 30 jours pour un petit projet ou pour renforcer une autre équipe sur un projet en cours, comme il peut y avoir des régies qui n’ont pas réellement de date de fin, avec des collaborateurs qui pourraient très bien travailler pour un même client pendant 3 ans.

Quelles méthodes de gestion de projet pouvons-nous appliquer sur des projets en régie ?

Sur des petites régies, il va être compliqué de mettre en place des méthodes de gestion de projet, mais pour les plus longues, il peut être intéressant de travailler avec des méthodes agiles. Bien évidemment, cela dépend du client et de la manière dont il souhaite travailler. Mais si ce dernier est disponible et prêt à travailler et à suivre le prestataire de façon régulière, il vaut mieux travailler de manière itérative sur des périodes courtes (1 à 4 semaines).

Dans les projets en régie, nous pouvons tout de même retrouver des phases de spécification et de phase de recette/validation. Ces phases seront étalées dans le temps, au fur et à mesure des sprints réalisés. Egalement, il est plus simple d’intégrer des concepts de l’eXtreme Programming, comme le pair programming dans le cas où le client souhaite un nouveau collaborateur sur le projet, afin de faciliter l’intégration et la connaissance dans l’équipe. Comme le projet sera développé de manière itératif, il sera également plus pertinent de mettre en place de l’intégration continue, de faire des petites livraisons, de l’écriture de tests automatisés ou de la revue de code.

Il n’est également pas impossible de travailler en méthode traditionnelle, cela dépend de l’équipe mise en place et de la volonté du client.

Attention cependant à ne pas tomber dans le piège de vouloir appliquer une méthode particulière car elle est populaire. Une méthode, ça s’apprend, ça se travaille, et surtout ça s’adapte selon le contexte. Essayez de faire du Scrum avec un client très peu disponible par exemple : vous vous en mordrez les doigts !

Les estimations peuvent également être présentes dans les projets en régie. Elles ne seront pas contractualisées, mais pourront être de mise afin de planifier les projets. Nous pourrons retrouver du chiffrage par complexité (comme le planning poker) ou bien du chiffrage en J/H. Ces chiffres pourront également aider à définir un nombre de jours de régie idéal pour terminer un sujet.

Projet TMA

Pour finir, nous pouvons retrouver dans une ESN des projets TMA (Tierce Maintenance Applicative). Ici, le prestataire ne travaillera pas sur un nouveau projet, mais sur un projet existant. L’objectif est de maintenir à jour une application, en développant des évolutions ou en corrigeant des bugs.

Les projets TMA sont un peu particuliers puisqu’ils peuvent se dérouler soit en mode projet au forfait, soit en mode projet en régie. Ils sont souvent définis à l’aide d’un outil de ticketing/bug tracking (Mantis, Trello, Jira, Redmine etc.), contenant les évolutions à réaliser et les bugs à corriger (un ticket = un bug/évol).

Si le projet TMA se déroule en mode forfait, cela veut dire du point de vue contractuel que chaque ticket va être chiffré précisément et vendu à un coup unique. Il faut voir cela comme un mini projet au forfait. Ces tickets pourront être regroupés dans des packages qui feront office de lot. Ensuite chaque lot pourra faire l’objet d’un devis, ou bien à la fin de chaque mois, chaque ticket terminé pourra être vendu.

Si le projet TMA se déroule en mode régie, cela veut dire que l’équipe va traiter des tickets sans s’engager sur un coût fixe. L’équipe pourra néanmoins macro-chiffrer un ticket afin de donner de la visibilité au client, pour qu’il priorise certains tickets par exemple.

Quelles méthodes de gestion de projet pouvons-nous appliquer sur des projets TMA ?

Dans les projets TMA, nous vous privilégierons la méthode Kanban, qui peut donner une bonne visibilité des tickets à réaliser, répartis par statut (A faire, En cours, A tester, A livrer, …). Chaque ticket devra suivre un certain workflow avant d’être clotûré.

Comme les projets TMA peuvent se dérouler en mode forfait ou en mode régie, nous pouvons retrouver un mix des méthodes traditionnelles et agiles. Nous pouvons très bien imaginer une méthode Scrum, où à chaque sprint, l’équipe traite un nombre de tickets en fonction d’une complexité. Ou alors nous pouvons imaginer une méthode Cycle en V, où l’équipe définit en amont précisément les évolutions ou bugs à corriger à travers des spécifications et une proposition commerciale contenant un coût fixe pour le lot de tickets.

Tout cela dépend du type de projet et encore une fois du client et de l’équipe 😊

Conclusion

Pour bien résumer cet article, il faut retenir qu’en ESN, nous pouvons trouver trois types de projets :

• Projets au forfait : obligation de résultat, il s’agit d’un contrat qui fixe la vente d’un projet à prix fixe sur un périmètre défini.
• Projets en régie : obligation de moyen, il s’agit de la mise à disposition d’un ou plusieurs collaborateurs, à un tarif journalier fixe sur une durée définie.
• Projets TMA : maintenance d’une application existante pour y ajouter des évolutions ou corriger des bugs, qui peut se dérouler en mode forfait ou en mode régie.

Sur chaque type de projet, il est possible de retrouver plusieurs méthodes de gestion de projet. Tout dépend du client et de l’équipe bien évidemment, mais nous privilégierons les méthodes traditionnelles pour les projets forfait, afin de bien cadrer et spécifier le besoin en amont de la réalisation. Ces méthodes pourront très bien s’appliquer pour des projets en régie, même s’il est plus judicieux d’envisager des méthodes agiles, surtout si le client peut s’impliquer fortement.