Ce billet de blog est la version longue d’un article publié le 8 décembre 2022 par le Project Management Institute de Lévis (Québec). Il a été écrit par Camille Bouin, Customer Success Manager chez Padam Mobility.
Appartenir à une entreprise SaaS (Software as a Service) revient à appartenir à une structure qui évolue au rythme des développements techniques du logiciel métier.
Cependant, il est important de ne pas perdre de vue le marché pour lequel est développé ledit logiciel.
J’évolue dans le secteur du transport public et plus particulièrement du Transport à la Demande (TàD).
Le TàD un service de transport souple, alternative à la voiture et au taxi et qui s’adapte aux différents publics et cas d’usages. Ceci, tout en réduisant l’impact écologique du transport sur l’environnement.
Je travaille pour l’entreprise Padam Mobility, qui propose un algorithme d’optimisation des transports, ainsi qu’une suite comprenant l’ensemble des interfaces nécessaires à l’exploitation d’un service de TàD : des interfaces usagers pour faciliter les déplacements de vos usagers, une interface conducteur adaptée à tout type d’exploitation, et une interface de gestion destinée aux opérateurs et autorités organisatrices de transport.
Dans ce secteur, j’ai pu constater que gérer des projets de digitalisation de transports, dans un contexte d’évolution constante du logiciel, induit une forte complexité.
L’objectif de cet article est de comprendre les interactions et analyser les enjeux entre la digitalisation de TàD ainsi que les évolutions du logiciel, afin d’y apporter des pistes de solutions.
Dans un premier temps, nous nous pencherons sur la gestion des projets de transports. Nous nous consacrerons ensuite aux projets techniques dans un second temps. Enfin nous appréhenderons leurs modes de fonctionnement parallèles.
La gestion de projets de transport
Mon cœur de métier repose sur la gestion de projets de mise en place de services de Transports à la Demande en zones rurales et périurbaines.
Dans ce secteur, les projets peuvent présenter des enjeux complexes à bien des égards :
- l’évolution de la numérisation des outils de gestion des services de TàD et les défis en termes de conduite du changement que cela engendre (en vert dans le graphique ci-dessous),
- les enjeux politiques des collectivités locales, et les délais qui en découlent (en violet dans le graphique ci-dessous),
- les enjeux des transporteurs dans un contexte de manque de main-d’œuvre (en rouge dans le graphique ci-dessous),
- la pression de l’opinion publique des usagers finaux du service sur les politiques et les transporteurs (en orange dans le graphique ci-dessous),
- l’évolutivité de l’offre de service et de la demande en fonction de l’actualité (en jaune dans le graphique ci-dessous),
- les contraintes financières et les variations dans les budgets alloués (en gris dans le graphique ci-dessous).
La gestion du projet, tant au niveau de son contenu que de la conduite du changement, ou celui du suivi et respect des délais représente donc un défi au quotidien. De plus, les marchés publics peuvent prendre du temps à se valider et obtenir des dates définitives de lancement de projets peut s’avérer compliquer. Une fois le projet débuté, les équipes projet doivent souvent être capables de délivrer l’offre de Transport à la Demande dans un délai de 2 à 3 mois en fonction de la complexité du projet.
Les enjeux mentionnés précédemment sont souvent décuplés avec l’évolutivité du marché et l’importance grandissante de la prise en compte de l’impact environnemental dans le secteur du transport. Ce dernier point a de forts impacts sur les évolutions du logiciel à développer pour répondre aux besoins clients.
La gestion des projets techniques
Pour répondre aux évolutions constantes du marché du Transport à la Demande, le logiciel doit rester en constante évolution.
La stratégie de développement du logiciel d’une entreprise SaaS, par nature, doit se faire dans un objectif de réponse à un besoin commun à l’ensemble ou à la majorité des utilisateurs, et non pas à un besoin unique ou spécifique. Partant de ce principe, il n’existe donc pas d’équipe technique dédiée à un client spécifique.
Le plus souvent, on retrouve une gestion de projets effectuée en parallèle, au sein des équipes produit (avec un focus sur la recherche des besoins) et développement (avec un focus sur la mise à disposition de la solution en tant que telle).
Ces équipes sont organisées selon la méthode « agile », avec des cycles de développement courts d’environ deux mois, séparés en sprints de deux semaines. Si la gestion de projet selon la méthode agile est plus poussée et permet une certaine rapidité d’évolution, la complexité du logiciel vient ajouter des difficultés dans au développement, rendant certaines évolutions incertaines tant au niveau de leur délai que de leur faisabilité technique.
Mais quelles interactions peut-on observer entre un modèle SaaS reposant sur une gestion agile des évolutions techniques, et la gestion des projets de déploiements de TàD?
Deux fonctionnements parallèles
Les deux modes de gestion parallèles présentant des enjeux et des délais différents, on peut très rapidement dériver vers des incohérences et des difficultés pour mener à terme les projets.
Un exemple concret est celui de l’intégration de systèmes de Transports à la Demande dans un projet plus global de solutions de MaaS (Mobility as a Service) ou de Mobilité servicielle. Dans ce cadre, la numérisation du TàD doit trouver sa place dans les normes de transport standard et être capable de s’intégrer dans des logiciels plus globaux de calculateurs d’itinéraires. Il devient alors nécessaire de normer et standardiser un mode de transport qui, par définition, était extrêmement flexible.
La mise en place d’un service de TàD doit donc se faire en s’adaptant aux normes, ou en en créant de nouvelles.
Les développements techniques doivent ensuite se baser sur ces normes en cours de création pour être éprouvées. Les interdépendances des tâches sont bien souvent trop fortes pour être capables de suivre un planning précis. Toujours dans cette idée, il se peut qu’un logiciel se retrouve obsolète, voire inutilisable juste après sa sortie, dès lors qu’un changement s’opère sur le marché du MaaS ou du TàD. Dans ce cas, le projet technique est en péril.
Au Canada, les projets de TàD voient généralement le jour lorsqu’ils sont reliés à des outils de billettique pour le paiement en ligne. Un projet technique de mise en place de billettique intégré avec les outils de TàD était déjà lancé chez Padam Mobility pour répondre à des besoins sur un autre marché, le Royaume-Uni. Cependant, les attentes et nécessités du marché canadien ne coïncidaient pas forcément à tous les développements prévus. Cette réalité tendait donc à mettre en danger le projet de déploiement de TàD.
Dans ces deux exemples, les enjeux des projets de TàD ou de développement techniques ne convergent pas forcément ou sont très interdépendants. Cela nécessite de trouver des solutions adéquates pour ne pas mettre en péril l’ensemble des projets.
Pistes de résolution
Pour répondre aux difficultés évoquées précédemment, il existe plusieurs leviers d’action. Ils doivent néanmoins être actionnés en garantissant que l’intégration soit totale. Que ce soit entre le projet technique agile et le projet de mise à disposition d’une solution digitale pour le TàD.
Pour que le projet de TàD soit un succès, comme dans le cas de la billettique, il est primordial de réaliser une relève précise du nouveau besoin et de s’orienter vers le projet technique en cours. La réunion de sprint ou mi-sprint exposera alors les nouveaux besoins et trouver une approche permettant de les intégrer au développement en cours. L’agilité du projet est extrêmement intéressante dans le sens où elle permet de faire évoluer le développement en fonction de l’évolution du besoin.
Les itérations et échanges se déroulent suivant un calendrier précis mêlant les contraintes temporelles des deux projets. L’itérativité de la solution permet de répondre à des échéances contraignantes. Une première version d’un développement permet de prendre en compte le MVP (Minimum Viable Product) du besoin du client nouvellement arrivé. Ils s’agit cependant de ne pas perdre de vue la version finale, qui reste dans la feuille de route des développements pour les futurs cycles.
Gardons en tête que les projets de TàD présentent des contraintes non prédictibles et évolutives. Celles-ci induisent de grands risques temporels dans les projets.
En conclusion, dans le secteur du Transport à la Demande, l’agilité des projets techniques et l’écoute des besoins clients, sont les deux éléments clés permettant d’atteindre le succès simultané des deux types de projets menés en parallèle.
Cet article pourrait vous intéresser : Aides pour les transports en commun, grandes absentes des nouvelles mesures de l’État.
Vous souhaitez être accompagné dans votre projet de TàD ? Nous contacter
