La refonte du site web de la STM (Société de Transport de Montréal), tant en version classique que mobile, présentait une série d'exigences, de défis et de risques. Avec le lancement du site l'été dernier, il est temps de faire un retour sur le travail accompli, tant d'un point de vue organisationnel que technique. Cette présentation vise les gestionnaires de projet et développeurs (Drupal et Ruby on Rails). Sans trop entrer dans les détails techniques, nous nous concentrerons avant tout sur les principes de haut niveau qui ont gouverné le projet.

1. CAS DE LA
REFONTE DE
STM.INFO
DrupalCamp Montréal 2013
!

2. Bonjour !
Jan-Nicolas Vanderveken, associé, TP1, @nvanderv
Albert Albala, développeur, TP1, @alberto56
Frédéric Gouin, analyste applications, STM
Nicole Gruslin, conseillère corporative web, STM
2

3. Aujourd’hui
Contexte
Gestion de projet
Intégration avec les
systèmes de la STM
Tests automatisés et
intégration continue
Infrastructure et
performance
Site mobile
Tests utilisateurs
3
Contributions à la
communauté Drupal
Gestion du changement

4. Contexte
4

5. Des utilisateurs satisfaits
Site développé en 1996 - 1997
Mis en ligne en 1997
90 % de satisfaction
Dans le contexte actuel, STM.info doit avant tout faciliter les
déplacements des usagers et être disponible en tout
temps, même dans les périodes de pointe et de crise.
5

6. L’open source à la STM
La STM crée un blogue WordPress en 2008
En 2009, elle entreprend de choisir un outil pour la refonte de
ses propriétés web. Drupal est sélectionné.
L’open source fait désormais partie intégrante des outils
privilégiés par la STM (Drupal, Nuxeo, Liferay, etc.)
Début du projet STM.info : mi-2012
6

7. Philosophie
Nous avons, tout au long du projet, considéré STM.info
comme un service, et non comme un site web.
Comme pour ses services de déplacement, STM.info devait
être accessible au plus grand nombre possible.
Nous avons placé l’utilisateur au centre du projet.
Finalement, chaque solution était évaluée en fonction de sa
stabilité, de son évolutivité et de sa performance.
7

8. Gestion de projet
8

10. rue Stanley
rue Sainte-Catherine

11. L’objectif du client

12. Ce que le chargé de
compte explique

13. Ce que l’ergonome envisage

14. Ce que le designer propose

15. Ce que le développeur a compris

16. Ce que l’utilisateur voulait

17. Les équipes multidisciplaires
Encourage la discussion parmi les différentes expertises
Les expertises sont impliquées tôt dans le processus
Un plus grand sens d'autonomie et de ownership
Moins d’ego, moins de « divas », nulle part où se cacher
Une dimension sociale plus grande
Place l’utilisateur au centre des préoccupation
17

18. Ça prend du rythme !
Des cycles de deux semaines,
qu’on planifie un lundi sur deux.
Une démo client un vendredi sur deux.
Chaque matin, un meeting debout.
Et une démo d’agence chaque deux semaines.
18

19. Ça va vite! - Nicole Gruslin, STM

20. Nos musts :
Des équipes multidisciplinaires
Un espace de travail propice
Un rythme d’agence constant
Des produits plutôt que des plans

21. Intégration avec les
systèmes de la STM
21

22. Solution A : Drupal seul
Infos sur les
trajets
Infos sur les
autobus
22
?
Infos sur les
emplois
Site
Drupal

23. Solution B : Drupal + middleware
Infos sur les
trajets
Infos sur les
autobus
23
Infos sur les
emplois
Middleware
Rails
RESTful API
Site
Drupal

24. Avantages
Sous-équipes au sein de l’équipe de développement
Impératif de garder une bonne communication
Objets bidons (« Mock objects »)
Tests plus efficaces
Abstraction des APIs
Documentation des interfaces
24

25. Site mobile
25

26. Les grands objectifs
Optimiser les activités de déplacement pour les téléphones
intelligents (itinéraires, horaires, tarifs et état du service métro
et autobus).
Obtenir un design de marque cohérent, pour les trois
environnements ciblés par la STM : ordinateurs, tablettes
et téléphones intelligents.
Créer une solution évolutive tenant compte des grandes
tendances du marché et pouvant s’adapter.
26

28. L’écosystème mobile
Un site web adaptatif (dès le début)
Une application web (à 80% du développement)
Des applications natives (hors mandat)
28

29. Solution proposée
Optimisation mobile, en mode adaptatif, pour les sections
informationnelles du site.
Développer une application web mobile optimisée pour le plus
d’appareils mobiles intelligents possible.
Mettre à profit les API et le CMS développés à ce jour.
Rendre la carte disponible sur les téléphones intelligents.
Offrir à la clientèle une expérience optimisée et unifiée pour
les téléphones intelligents sur l’ensemble du site.
29

30. ACCUEIL ET
PAGES DE CONTENU
ACCUEIL ET
THÈMES DE DÉPLACEMENT
(ADAPTATIF)
THÈMES DE DÉPLACEMENT
ordinateur + tablette + téléphone intelligent
téléphone intelligent
(ADAPTATIF)
ordinateur + tablette

42. Orientations technologiques
Optimiser le planificateur de trajet pour une expérience
mobile en misant sur un développement en Ruby on Rails.
C’est le volet applicatif.
Optimiser les pages intérieures pour les plateformes
mobiles en version adaptative, sous Drupal. C’est le volet
informationnel, en développement depuis le début du projet.
La gestion du site et l’entrée du contenu sont centralisées
dans Drupal. Une seule interface pour les webmestres.
42

43. visiteur
ordinateur + tablette
répartiteur de charge
téléphone intelligent
(HAProxy)
appel à
l’action
stm.info
m.stm.info
lien en pied de page
ordinateur + téléphones intelligents
application
mobile

44. Les avantages?
Un client web mobile ultra-léger qui met l’accent sur
l’expérience du client en déplacement.
Aucun changement à l’infrastructure nécessaire.
Développement accéléré utilisant l’architecture existante.
Environnement permettant de répondre aux besoins
spécifiques des utilisateurs de téléphones intelligents.
Gains de performance grâce à un accès direct aux API.
44

45. Tests utilisateurs
45

46. Beta public
TP1
Tests
d’accessibilité
AccessibilitéWeb
Yu Centrik
Tri de cartes
TP1 / Adviso
Tests
utilisateurs sur
maquettes
fonctionnelles
Yu Centrik
Beta panel
6000 clients
TP1 / Adviso
Focus group
sur le design
Callosum
Beta panel
3000 employés
STM
Tests
utilisateurs sur
version alpha
Yu Centrik
46

47. Tests automatisés et
intégration continue
47

48. Défi #1 : Tests de JavaScript
Drupal est excellent pour tester des pages statiques
Mise en place de tests avec Behat
Nécessité de tester Internet Explorer, Firefox, Chrome...
Défi : la prolifération des plateformes mobiles
48

49. Défi #2 : Bien définir les tests
Développement piloté par les besoins d’affaires, ou
« Behavior-driven development »
Utilisation d’exemples concrets pour les tâches à
accomplir dans Jira (agile)
Automatisation basée sur un langage commun
49

50. 1
2
3
4
5
6
7
8
9
10
11
12
13
Scénario: (Sprint 7, Story STMMEO-43) En tant que client, Je veux être!
en mesure de minimiser les correspondances dans mon itinéraire!
!
Soit je suis sur la page d'accueil!
Et je cherche le premier itinéraire entre "cote ste-ca" et "jean-talon [m"!
Alors je vois "Ligne orange" avant "Itinérare 2"!
Alors je vois "Ligne bleue" avant "Itinérare 2"!
Et j'appuie sur "Modifier l'itinéraire"!
Et j'appuie sur "Afficher les options"!
Et je mets dans les options "Minimiser les correspondances"!
Et j'appuie sur "Rechercher l'itinéraire"!
Alors je ne vois pas "Ligne orange" avant "Itinérare 2"!
Alors je ne vois pas "Ligne bleue" avant "Itinérare 2"!
/**"
* @Given /^je vois sur la carte la ligne verte mise en évidence$/"
*/"
public function jeVoisSurLaCarteLaLigneVerteMiseEnEvidence() {"
_assert_html($this, MARKUP_CARTE_LIGNE_VERTE_SELECTIONNEE);"
}"
!
50

52. Défi #3 : Tests d’APIs externes
Objets bidons
Développement et contribution du module Mockable
Importance de simuler tous les scénarios potentiels
(serveur externe non-disponible, temps de réponse
inacceptable, etc.)
52

53. Défi #4 : Internet Explorer
Selenium
Machine virtuelle
Batterie de tests relativement longue : 2 heures
Images de VM de Microsoft (un cauchemar!)
53

54. Intégration continue
Un serveur d’intégration continue Jenkins a été mis en
place plus tard dans le projet.
Les prochaines phases utiliseront l’intégration continue
dès le début.
54

56. Avantages et défis
Très peu de régressions se sont rendues en production
Découverte de bogues tôt dans le processus de
déploiement
Batterie de tests trop longue, nécessité de l’automatiser
davantage
À l’avenir, importance de mieux simuler l’environnement
de production
56

57. Infrastructure et performance
57

58. Infrastructure STM.info
Des dizaines de serveurs physiques et virtuels
Des centaines de milliers d’utilisateurs par jour, des
centaines de requêtes simultanées
Mise en cache : entre 60 secondes et 30 minutes
58

59. Leçon : bien utiliser la cache Drupal
Tests de charge
Identifier et reproduire une utilisation réaliste pour la STM
Cache Varnish à 30 minutes et cache Drupal anonyme,
sauf l’information importante (60 secondes) et les
formulaires (aucune cache)
Utilisation massive de AJAX
59

60. Contributions à la
communauté Drupal
60

61. Contributions à la communauté
Participation à plus de 100 « issues »
Près de 30 « patchs » soumises à divers modules,
Drupal core 7.x et 8.x
Blogue technique
Deux modules Drupal : Mockable et Representative Image
Partage de code avec NBCUniversal
61

62. Des questions ?
62