Observatoire francophone des TI

Approche prêt-à-porter de développement web

Approche prêt-à-porter de développement web

29 août 2012

Les administrations publiques qui doivent assurer une présence croissante sur le web sont confrontées à une réduction constante des fonds disponibles pour le faire.

Par ailleurs, le développement des technologies et des fonctionnalités associées au web est si rapide que les administrations publiques ont souvent beaucoup de mal à suivre le rythme.

Le cas étudié ici découle d’expériences effectuées par le Service des technologies de l’information de la Ville de Montréal visant à évaluer l’utilisation de logiciels libres pour répondre à l’ensemble des besoins web, tant en intranet qu’en Internet.

Parmi les logiciels libres les plus matures, on retrouve notamment ceux associés aux technologies du web. Pour les administrations publiques, ces derniers présentent des avantages potentiels significatifs:

  1. pas de frais de licences;
  2. code ouvert;
  3. vastes communautés de développeurs qui font évoluer le produit en continu;
  4. disponibilité de milliers de plugiciels couvrant une myriade de fonctionnalités;
  5. accès à des produits qui sont toujours à jour technologiquement.

Baptisé «Prêt-à-porter» (analogie avec le vêtement: on ne fait pas du sur mesure, et comme dans le cas du vêtement, on ne fait que de petites retouches, pas de développement, mais plutôt de la paramétrisation de plugiciels existants) le projet, après de nombreuses analyses, a débouché sur la standardisation de plusieurs logiciels libres pour répondre à une série de besoins web:

  1. Drupal, pour remplacer le portail Oracle utilisé actuellement pour déployer les sites Internet de la Ville de Montréal;
  2. WordPress, pour le déploiement de sites intranet et de certaines fonctionnalités Internet (blogues, minisites événementiels, observatoires, etc.);
  3. Mediawiki, pour la documentation technique;
  4. BuddyPress, pour réunir des communautés de pratique à l’interne et à l’externe
  5. LimeSurvey, pour l’administration de sondages en ligne.

Dans le cas du déploiement de solutions WordPress, le projet voulait répondre aux objectifs suivants:

  1. Réduire les coûts de réalisation de solutions web;
  2. Ne pas faire de développement de plugiciels (20 000 plugiciels disponibles);
  3. Utiliser un maximum de composantes réutilisables entre les instances;
  4. Offrir un déploiement rapide et à la demande de sites intranet, cyberbulletins et observatoires;
  5. Offrir des ensembles (Packages) plugiciels + thème adapté aux besoins identifiés;
  6. Rendre les utilisateurs autonomes dans la production de contenus;
  7. Partager les développements avec d’autres administrations publiques
  8. Expérimenter avec le design adaptatif (responsive) et le HTML5 ainsi qu’avec des versions de sites dédiés aux plateformes mobiles;
  9. Implanter des solutions Web qui respectent les standards (W3C) et qui sont indépendantes des plateformes (Device independence) (OS, navigateurs, mobiles).

Démarche suivie

Inventorier les fonctionnalités désirées

Nous avons commencé par faire un inventaire de toutes les fonctionnalités nous apparaissant pertinentes en s’inspirant de ce qui était déjà utilisé, mais surtout des nouvelles demandes provenant des utilisateurs.

Nous avons identifié à ce jour un peu moins de 70 fonctionnalités (par exemple calendrier d’événements, intégration de vidéos, etc.) que nous avons regroupées en trois sous-groupes, pour les utilisateurs (création de formulaires), pour les administrateurs (gestion des liens brisés), de sécurité (s’applique principalement à des instances Internet)

 Sélection des plugiciels

Pour chacune des fonctionnalités, nous avons fait des recherches (on a notamment utilisé des articles du type Les 100 meilleurs plug-ins WordPress pour identifier quelques plugiciels qui semblent répondre aux besoins identifiés dans un premier temps. Parfois on n’en trouve qu’un ou deux, parfois beaucoup plus. On essaie de se limiter à trois ou quatre.

 Quelques critères utilisés pour cette sélection initiale:

  • Compatibilité annoncée avec la version de WP utilisée (il y a deux façons de l’évaluer, ce qui est annoncé et ce qui est rapporté par les utilisateurs);
  • Date de la dernière mise à jour (plus d’un an, ça devient inquiétant, moins de trois mois c’est rassurant et donc s’assurer que le développement est actif);
  • Le nombre de téléchargements (il faut relativiser un peu en fonction du type de fonctionnalité);
  • La cote;
  • Compatibilité rapportée par les utilisateurs;
  • Dans notre cas, très important, le support de la localisation (i.e. la capacité d’un plugiciel ou d’un thème de fonctionner en plusieurs langues).

Phase de tests

Ensuite, nous avons testé individuellement dans une instance de blogue vanille (utilise le thème de base Twenty Ten dans notre cas) pour valider le fonctionnement et déterminer ce qui répond le mieux au besoin, tant du point de vue fonctionnel qu’ergonomique (très important).

L’aspect contextuel (à savoir si le plugiciel n,entre pas en conflit avec les autres et si l’affichage fonctionne bien dans le thème retenu) sera évalué ultérieurement lors d’un prototypage.

Sélection d’un thème

Pour la sélection des thèmes, nous nous sommes fait une petite grille d’analyse afin de choisir des gabarits de présentation répondant aux utilisations types (cyberbulletin, site intranet, observatoires) avec la possibilité d’une personnalisation visuelle, de préférence avec la possibilité de le faire avec l’outil d’administration.

Notons que de plus en plus, les thèmes incorporent certaines fonctionnalités qui remplacent certains plugiciels).

Tant pour les plugiciels que pour les thèmes, la localisation est très importante pour nos besoins. Nos sites doivent être impeccables au niveau du français.

Prototypage

Finalement, il faut mettre tout ça ensemble en réalisant un (ou deux) prototype pour vérifier si le tout fonctionne harmonieusement. Étonnamment, peu de mauvaises surprises à cet égard, ci ce n’est parfois certains petits problèmes d’affichage qui seront généralement résolus par l’adaptation de la feuille de style dans un thème enfant.

C’est parfois aussi l’occasion de valider quel est le thème le plus adapté au besoin.

Un important défi pour nous était de s’assurer que les sites fonctionnent adéquatement sous IE7 qui est malheureusement le seul navigateur disponible pour l’ensemble des employés. Nous travaillons actuellement à l’implantation d’au moins un autre navigateur, plus moderne, sur les postes de travail afin de garantir la meilleure expérience possible à nos usagers, d’autant plus que nous n’avons pas l’intention de supporter IE7 dans le cas de sites Internet.

Leçons apprises

  • Le coeur de WordPress étant mis à jour environ tous les deux mois, nous recommandons de procéder aux mises à jour des instances et des plugiciels à la même cadence.
  • Prévoir une forte résistance des équipes de maintenance et d’évolution qui sont peu familières avec les paradigmes du libre (ouverture des serveurs vers l’extérieur, recours à la communauté pour trouver des solutions, documenter pour partager et réutiliser les solutions), etc.
  • Prévoir de former les équipes de développeurs non pas à la programmation, mais à changer leurs façons de travailler;
  • Ne jamais modifier la programmation des plugiciels pour répondre à tous les besoins des clients. Rappelons-nous qu’il s’agit ici d’une approche «utile maintenant, parfait trop tard»;
  • La mise en place de toute solution PAP est extrêmement rapide si on suit la recette qui précède (on parle de quelques semaines à personnel réduit).

Prochaines étapes

  • Mise en place progressive de l’offre de services PAP;
  • Mise en place des processus de maintenance et d’évolution;
  • Transmission à la communauté WordPress des traductions effectuées;
  • Partage des solutions avec d’autres administrations publiques.

En savoir plus

 

 

Version imprimable Version imprimable

Vu 1 292 fois