Les parisiens bénéficient aujourd'hui d'un service de prêt de vélos sans toujours se douter des outils informatiques mis en oeuvre. Bertrand Kientz, DSI de JCDecaux, tire le bilan de Velib' où le SI a joué un rôle important pour la qualité du service.
Velib', ce seront à terme 20 600 bicyclettes en libre service disponibles dans 1 451 stations dans tout Paris en échange de la concession d'espaces publicitaires.
Il n'est pas tout à fait terminé. La ville de Paris a en effet décidé d'étaler le déploiement car notre soucis commun est de trouver les bons endroits pour les stations. Tant que toutes les stations ne sont pas construites, nous ne pouvons pas installer tous les vélos, faute de quoi les stations seraient rapidement saturées. Pour l'instant, nous sommes à environ 15 000 vélos pour un peu moins de 1 300 stations.
Pour faciliter le déploiement, nous créons parfois des stations auxiliaires ne comportant que des 'bornettes' pour accrocher les vélos, mais pas de borne monétique, la station auxiliaire étant en fait rattachée à une station normale voisine. C'est par exemple la configuration de la station au croisement avenue d'Italie / rue de Tobiac avec une station auxiliaire sur le trottoir d'en face.
L'offre CycloCity de JCDecaux a d'abord été déployée à Lyon, l'automatisation permettant de transformer le prêt de vélo en transport en commun (par opposition aux premières offres de ce type, comme ce qui avait été fait à La Rochelle).
Le Velib' de Paris en est une implémentation avec quelques nouveautés, notamment la GMAO. Les innovations réalisées à Paris seront bien sûr réutilisées dans les déploiements ultérieurs, à Séville, Aix, Marseille, Mulhouse, Toulouse, Rouen...
L'un de nos enjeux est d'ailleurs d''industrialiser' notre offre, de concevoir une offre unique déclinable et paramétrable en fonction des besoins de telle ou telle ville, les modèles économiques étant très variables.
L'une des particularités de CycloCity est de proposer de la monétique sur les bornes pour des usages ponctuels du service. La monétique a d'ailleurs été une des difficultés du projet, car la borne doit se connecter d'une part à la GRC centrale, mais aussi au système de paiement monétique de Ingenico et BNP Paribas, le tout au travers du réseau GPRS.
Quels sont les pics de consommation du service ?
Le pic absolu a été lié à la grève des transports en commun du 16 octobre, avec 180 000 trajets dans la journée pour seulement 12 000 vélos. Le pic quotidien le plus élevé, c'est le matin, avec environ 5 000 locations/heure. Après la fermeture du métro, le soir, nous avons encore 2 000 locations/heure. Un moment comme la Nuit Blanche est comparable à un pic du matin.
Les jours de septembre-octobre où il faisait beau, on dépassait souvent les 100 000 locations/jour avec de grosses pointes le week-end. En hiver, on est plutôt autour de 50 000 locations/jour, dont 15 à 20 000 transactions monétiques par jour pour les forfaits de courte durée.
Comment a été gérée la montée en charge, notamment en fin d'été lorsque les utilisateurs se sont beaucoup plein d'écrans bleus sur les bornes ?
Lorsqu'une borne est plantée, ce n'est pas trop pénalisant puisqu'il y a des bornes tous les 300 mètres. Depuis le début, nous respectons les deux critères les plus durs et les plus pénalisés dans notre contrat de concession : la fiabilité et la régulation.
Les logiciels du système central, en technologie .Net, n'ont jamais posé le moindre soucis. En cas de nécessité, la bascule entre serveurs redondants a bien marché, de même que la répartition de charge.
En fait, le problème de départ concerne le déploiement des versions de logiciels dans les bornes et les bornettes. La télédistribution est délicate à employer car nous utilisons le réseau GPRS et nous avons donc été amenés à déployer les mises à jour avec des clés USB, d'où des soucis de cohabitation de versions différentes dans le système à un moment donné.
Le plus gênant que nous ayons rencontré, c'était l'accumulation de bornettes en position 'indisponible' (avec lumière rouge), qui était due à une conjonction de problèmes matériels, logiciels et de cohabitations de versions différentes de programmes sur le système, ce qui provoquait des conflits d'accès aux bases de données.
Parmi les évolutions que nous avons introduites au fil du temps, il y a eu l'émission d'un bruit d'alerte encore plus perceptible que l'existant lorsque le vélo était mal raccroché à la borne. Les facturations liées à une poursuite de location avec un vélo pas réellement 'rendu' car mal raccroché engorgeaient en effet le call-center.
Comment détectez-vous les défauts ?
Le module de GMAO n'a pas pu être déployé dès le lancement de l'offre Velib', le 15 juillet 2007. Par contre, dès le départ, nous avons eu un reporting des incidents détectés par les bornettes, remontés au système central et destinés à être reversés dans la GMAO.
Aujourd'hui, la GMAO est déployée mais pas encore toutes les fonctions liées aux terminaux mobiles durcis des agents sur le terrain (des PDA Intermec sous Windows Mobile). Par exemple, aujourd'hui, un agent sur le terrain ne peut pas de lui-même bloquer un vélo qu'il détecte défectueux mais qu'il ne peut pas réparer tout de suite. Il faut encore qu'il passe par un appel au centre de maintenance. Les mainteneurs se déplacent avec des vélos électriques et utilisent les stocks de pièces de chaque station pour effectuer les petites réparations. Le cas échéant, faute de la possibilité d'une réparation sur place, le vélo est récupéré en site d'arrondissement, voire en site central.
Notre problème a été un niveau de vandalisme auquel nous ne nous attendions pas, ainsi que le vol de vélos. Des problèmes mécaniques ont été résolus progressivement, comme le tendeur de chaîne qui a été renforcé.
Les recettes liées à l'utilisation du service sont destinées à la ville de Paris, mais, si JCDecaux respecte les critères qualité, nous touchons jusqu'à 12% d'incentive sur les recettes de location et les recettes publicitaires liées au contrat, ce qui est loin d'être neutre dans notre modèle économique.
L'usage du réseau GPRS n'est-il pas problématique avec une gestion des comptes clients centralisée ?
Si une borne n'est pas reliée au système central par GPRS, il ne peut pas y avoir de location. Nous utilisons deux opérateurs pour le réseau : Bouygues et SFR, aucune borne n'étant sur le même réseau que sa voisine. Lorsqu'un des deux réseaux est en panne sur une zone, entraînant l'indisponibilité de la moitié des stations, cela nous pose de gros problèmes de régulation. Nous n'avons jamais eu le cas des deux opérateurs en panne en même temps dans la même zone, mais nous allons progressivement passer à des bornes double-opérateur.
Et le site web du service ?
Nous avons eu un problème d'engorgement lié en partie à l'effet de succès : 5 000 visites/jour, c'est au dessus de ce que nous avions anticipé. Mais le pire est venu de mashups parasites réalisés par des tiers : des robots d'interrogation engorgeaient le site web pour alimenter en informations, par exemple, un service audiotel.
Désormais, nous avons pris l'option de bloquer les programmes parasites par un arrêt des adresses IP. Par contre, nous développons des webservices 'propres' pour alimenter des sites partenaires (comme Infotraffic). Nous n'avons rien contre la création de services complémentaires au notre, pourvu que l'interface soit propre et ne plante pas notre site.
toute l'actualité "Projets"
Chiffres-clés
Evènements
Comment percevez-vous le DSI de transition comme Philippe Tassin interviewé dans CIO.PDF 15 ?
