Les slides de ma conférence à WordCamp Lyon, le 3 juin 2015. Rétrospective sur l'évolution des sites Internet et les rôles et responsabilités de client et prestataire en ce qui concerne la maintenance.
Un site WordPress
‣ L’installation WordPress (core)
‣ Une combinaison de plugins gratuits,
prémium et sur mesure
‣ Le thème que j’ai développé, qui peut
contenir des dépendances (typos, scripts,
librairies)
‣ (Thème enfant)
0 31 62 93 124
France
United States
United Kingdom
Bulgaria
Netherlands
Germany
Switzerland
Canada
Denmark
Serbia
Belgium
Hungary
Ireland
Japan
Norway
Pakistan
Poland
Romania
South Africa
Spain
Sweden
LES « NON »
‣ Je n’ai pas le temps / les ressources.
‣ Ce n’est pas intéressant comme travail.
‣ Les clients ne veulent pas payer / voient
pas la valeur.
‣ Ça ne fait pas partie de notre offre / ce
n’est pas notre activité.
‣ Je le laisse au client*.
Je suis particulièrement émue d'être ici parmi vous pour participer à ce tout premier WordCamp Lyon. Parce que c'est ici, à Lyon, que j'ai démarré non seulement ma vie en France mais aussi ma carrière dans le web.
Au fait on est combien lyonnais dans la salle ? Ou qui vit ici où dans les environs ?
Je vais vous faire visiter un peu…
C'était ici dans le salon de notre appartement rue Neuve au 3e étage au-dessus du Cordonnier que j'ai créé ma première agence web avec deux associés - c'était en 1998
L'année suivante, nous avons repris un local derrière la Place des Terreaux - c'était en mauvais état, on a eu un bon prix. On l'a retapé et l'a converti en loft open-space - c'était assez chouette. Mais malheureusement au bout d'encore un an, on a rencontré des difficultés, et on a du fermer l'agence.
Et juste au moment de penser à peut-être rentrer aux Etats-Unis, j'ai fait une série de belles rencontres, dont celle d'une petite bande d'amis, graphiste, développeur et homme d'affaires qui m'ont invité à partager un coin de leur local rue Romain, en bas des pentes de la Croix Rousse.
Je me suis mise à mon compte et là j'ai resté pendant 3 trois ans avant que la vie nous envoie sur nos chemins respectifs.
Et voilà que mes premiers sites Internet étaient créés bien avant le Web 2.0.
Le standard de résolution était de 800X600.
On utilisait beaucoup de tableaux pour construire nos mises en page.
On appelait les divs des "layers" ou des "calques" en français, et c'était encore assez expérimental et pas très stable.
Il avait encore Netscape et Explorer pour Mac. Oui on utilisait déjà du CSS, bien sûr,
mais surtout on utilisait beaucoup, beaucoup d'images.
Et même des images sans image.
Et n'oublions pas le Flash. On faisait bcp de Flash, j'adorais ça.
Ça vous manque pas ça ? Je vous épargne le son.
Bref, c'était une autre époque. C'était le début du web, et avant de voir l'arrivée des CMS, nous, les créateurs de sites, étaient largement responsable des mises à jour des contenus. Changer une photo? Il fallait passer par nous. Changer ou ajouter un texte, pareil, et d'autant plus que souvent les textes étaient contenus dans les images (oui, c'était un peu le Wild West). On ne parlait pas encore d'inté ou de dév front-end.
On était les "webmasters". En tout cas, en ce qui concernait la plupart des clients.
Quelque soient nos compétences précises, tant qu'on avait cette maitrise technique, on détenait les clés du royaume du web.
Et donc le concept de la maintenance était assez réduite. Une mise à jour était soit la modification du contenu du site, soit carrément une refonte. Et on voyait beaucoup de turnover, c'était assez commun pour la vie d'un site d’avoir une courte durée, ce qui heureusement nous garantissait pas mal du travail.
Au courant de l'année 2003, un shift nette a été ressenti. Les clients en avaient marre de devoir passer par nous pour effectuer la moindre changement, et franchement, nous aussi.
C'était en 2004 la première fois que j'ai travaillé avec un CMS, sous forme d'un modèle SaaS. PowerBoutique avait vraiment une énorme avance sur son temps. Ça existe toujours aujourd'hui, leur offre a bien sûr évolué depuis, mais à la base c'était une plateforme de vente en ligne, comme le nom l'indique.
Tout était mis à disposition, ou pour utiliser la phrase de l'époque
c'était du "clé en main". Ce qui comprenait :
L'hébergement (bien entendu car SaaS)
La gestion des contenus (pages statiques, pages produits) grâce à un backoffice et une interface utilisateur graphique.
Le système de paiement intégré
L'intégration de l'habillage graphique
(on ne parlait pas encore en terme de "thèmes", mais c'était possible de faire des choses assez originales, en utilisant des images et un système de gabarits similaires à ce qu'on connait aujourd'hui avec WordPress)
Où l’approche SaaS était désirable pour certains projets, il y avait une autre préoccupation récurrente de la part des clients qui a aidé à me diriger vers les solutions open source : la propriété intellectuelle. Un entrepreneur ou chef d’entreprise voulait s’assurer que le site dans lequel il investissait lui appartenait. Qu’il était libre de faire ce qu’il voulait avec son site une fois livré.
WordPress était encore dans son enfance, mais j'ai pu passé par certaines d'autres solutions populaires en France, ainsi que de nombreuses solutions faites maison.
Quelque soit le produit précis, les objectifs étaient les mêmes et le modèle était très séduisant pour les clients :
Ils sont devenus enfin autonomes sur la gestion de leur contenu.
Le coût initial du développent était souvent moindre car l'infrastructure existait déjà, et dans le cas d’un SaaS, il y avait la mensualisation des paiements.
Ils étaient plus engagés dans leur projets, plus impliqués - quand t'as la main sur qqc, ça la rend tout de suite plus concrète.
Dans le cas de l’open source, la promesse d’appartenance et une facilité d’évolution.
Et puis ce modèle était intéressant pour moi aussi.
Je gagnais en productivité, car plus besoin de réinventer la roue à chaque fois.
J’accélérais ma propre formation, apprenant du travail des autres.
Je pouvais les proposer des choses de plus en plus intéressantes, les sites devenaient plus riches et complexes
J’avais des clients heureux
Mais comme toute chose plus complexe, il y a une tendance à avoir des problèmes qui viennent avec.
Où avant je créais de simples sites en html ou flash, avec 100% de la maitrise sur mon code, et le contenu et toute la chaine de production, désormais en même temps que mes clients devenaient moins dépendants sur moi, moi je devenais plus dépendante sur ce modèle et ses auteurs.
Le shift du coup—ce changement—n'était pas qu'au niveau des attentes des clients, mais dans les rôles et les responsabilités - de client et de prestataire.
Sous ce modèle CMS, les sites Internet se transformaient en logiciel. Et avec tout logiciel vient forcément des mises à jour.
Dans le cas d'un SaaS, tout cela est complètement opaque. Ils ne nous parlent pas de leur code, le type de technologie ou langage de programmation utilisé. C'est un service, sous abonnement, avec un SAV et support technique, et c'est tout ce qu'il faut savoir.
Dans le cas d'un framework open source, hébergé par soit même, c'est différent. En tant que prestataire, outre être contributeur au projet, on n'est pas directement impliqué dans ce travail de mises à jour, mais on doit les suivre et les implémenter.
Pour le client, pour l'utilisateur, la question se pose.
Maintenance Matters (c’est important)
Pourquoi ?
Je pense que la question se résume en trois points :
Protéger contre les vulnérabilités (Sécurité)
Assurer son bon fonctionnement (Santé)
Pouvoir faire évoluer (Développement)
Quand on y pense, l’idée de la maintenance, de l’entretien, n’est pas unique aux sites ou aux logiciels. C’est un thème récurrent de la vie quotidienne.
Est-ce qu’on sait que ces choses sont importantes ? Mouai, plus ou moins.
Est-ce qu’on les fait toujours ? Pas forcément (et parfois pas de tout).
Est-ce que c’est notre job de s’en occuper ? Ça dépend. Et c’est une très bonne question.
Avant de partir faire une long voyage en voiture, mon mari et moi savons que notre voiture doit être dans un état optimal, non seulement pour ne pas tomber en panne, mais aussi pour optimiser la performance du véhicule si jamais on est amener à manœuvrer et ou faire un arrêt d’urgence. On vit en pleine compagne après tout, et chevreuil et conducteurs sous l’influence font partie de notre quotidienne.
On vérifie toujours que les pneus sont bien gonflés, mais quand il s’agit de vérifier les niveaux, le parallélisme ou bien les freins, on amène la voiture chez le garagiste. On n’est pas équipé de faire ce travail et on n’a pas les compétences
Quand je livre un site WordPress à un client, il est composé de :
L’installation WordPress (core)
Une combinaison de plugins gratuits, prémium et sur mesure
Le thème que j’ai développé, qui peut contenir des dépendances (typos, scripts, librairies)
(dans des rares cas un thème enfant)
C’est beaucoup de pièces, de composants, qui doivent fonctionner ensemble. C’est beaucoup d’occasions pour les choses de mal se passer.
Est-ce qu’il y a qqn ici qui n’a jamais rencontré un conflit lors d’une mise à jour ?
WordPress nous facilite les mises à jour grâce aux liens d’auto-update rajouté dans la version 2.7 en 2008. C’est une des fonctionnalités que j’apprécie le plus dans WordPress, mais est-ce qu’on devrait confier la tâche aux amateurs qui ne sont pas équipé pour résoudre les problèmes qu’ils peuvent rencontrer ?
Il m’a fallu du temps pour intégrer le concept de la maintenance dans mon offre. La dernière chose que je veux faire en tant que freelance, en tant que prestataire de service, et de vendre à qqn qqc dont il n’a pas besoin.
Initialement, je m’en occupais uniquement sur demande ou lors que j’intervenais sur un site pour autre chose. Ou je croyais avec nativité que les clients s’en occupaient. Après tout, ils voulait prendre la main sur leur site, n’est—ce pas ? Mais plus souvent que jamais, au regard de mon expérience, ils ne le font pas, et encore une fois ils ne seraient pas en mesure d’agir s’ils rencontraient un problème.
C’était au début de l’année dernière que j’ai commencé à m’y intéresser sérieusement à cette question. Et au départ, quand j’ai commencé à intégrer un plan de maintenance dans mon offre, c’était en option. Lors d’un devis de création de site, je proposais un suivi technique supplémentaire de 12 mois. Comme la plupart des gens présentés avec des options que 1) ils ne comprennent pas forcément, et 2) dont ils ne voient pas spécialement l’intérêt, je n’ai vendu aucun.
Par contre, j’ai commencé à vendre pas mal d’interventions pour nettoyer des sites qui se sont fait piratés, car, manque de mise à jour. Et je me suis dite, ceci est ridicule.
Donc, j’ai arrêté de présenter le service comme une option. Le résultat était impressionnant. Ça ne veut pas dire que j’oblige les gens de s’engager, mais une fois que l’idée était proposée comme intégrale et non anecdotique, soit la personne veut en savoir plus voire négocier (mais c’est rare), soit elle accepte simplement que ce service fait partie de la norme.
Vu mon succès, j’étais retournée voir tous les clients à qui je n’en avais jamais vraiment parlé, et ceux qui avaient déclinés mon offre lors qu’elle avait été présentée en annexe. Encore, résultats étonnants, beaucoup entre eux m’ont dit sans hésiter, je signe où ?
Je vous avoue que j’ai fais pas mal de tests pour bien définir mon offre et trouver les bonnes tranches de prix – et c’est toujours un travail en cours. Par exemple, est-ce que j’accepterai de m’occuper d’un site que je n’ai pas fait ? ou qui tourne sur un thème premium ? La réponse du moment est : parfois. On verra comment ça se passe.
J’ai du aussi apprendre et tester parler sur ce sujet. Oser en parler, insister en parler. J’ai aussi perdu deux clients en route. Mais ça valait largement le coup. On ne peut pas forcer des gens à nous croire quand on leur dit ce qui est dans leur meilleur intérêt.
Certains croient être toujours l’exception à la règle. D’autres il leur faut une mauvaise expérience avant de changer leur avis. Et d’autres encore semblent croire que payer pour la création d’un site leur donne tous les droits par la suite, alors que non, bien sûr que non.
Mais en général je pense que la majorité des gens comprennent ce concept de maintenance et son importance. Il suffit d’en parler ouvertement et souvent avec une transparence totale et une claire définition des rôles et des responsabilité de chaque partie concernée. Client & prestataire.
Agence 55
Freelancer 69
France 34
US 21
UK 15
Bulgarie 13
Oui 96
Non 29
Quand on parle de maintenir un site WordPress, qu’est-ce que ça implique ?
Sauvegardes (files / db)
Restauration (if needed)
Staging / déploiement
MAJ plugins
MAJ core
Renouvellement licences
MAJ thème (revue de code)
Renforcement de la sécurité (hardening)
Veille (pour être au courant des annonces spécifiques, problèmes connus, etc).
Nettoyage en cas d’attaque / infection.
Bien entendu, le moins de « pièces détachées » que tu as, le moins problématique le travail. Si vous avez les ressources de créer et maintenir vos propres plugins, par exemple – vous avez tout de suite une meilleure maitrise d’une partie de la chaine de production et une facilité de déployer les MAJs pour l’ensemble des sites qui s’en servent.
Il y a de plus en plus d’outils – plugins et services SaaS – qui peuvent aider avec le travail. Actuellement j’ai 16 sites sous plan de maintenance et dont je m’occupe tous les mois. Si j’arrive au point d’en avoir 30 ou 50, il faudra peut-être que repense mon workflow.
Aujourd’hui ma boite à outil est assez simple :
BackWPup
Save to DropBox
Trello for task tracking / note taking
Sucuri (phasing out)
Bitbucket for versioning
WP Migrate DB pro (staging and deployment)
Fetch (FTP)
Au cas par cas 41
Offre unique 34
Offre par niveaux 21
Une fois que qu’on s’engage, on devient responsable. Alors c’est important de bien définir ce que tu fais, ce que tu ne fais pas et pour ce dont tu prends réellement responsabilité. Un médecin n’est pas responsable si tu tombes malade. Donc par exemple je ne garantie pas qu’un site sous mes soins ne se fera jamais hacké, mais que le travail que je fais devrait réduire ce risque, et si jamais ça arrive, je ferai la nécessaire pour tout remettre en état.
Il est extrêmement important de penser à ce genre de détail quand s’engage sur la création d’un site et son suivi.
(Revenir à Mailchimp…)