Nous connaissons tous l’expression populaire qui dispose que les cordonniers sont toujours les plus mal chaussés. Chez Libre Logic, nous avons quelque peu expérimenté ce paradoxe avec notre site Internet.

En tant que cabinet de conseil en informatique, nous avons mené plusieurs missions de conseil et d’assistance à maîtrise d’ouvrage (AMO) auprès d’entités, publiques ou privées, qui souhaitaient refondre ou moderniser leurs sites Internet. Malgré cela, et pour diverses raisons que je détaille ci-après, notre propre site n’était à l’état de l’art.

Pour traiter ce sujet, nous avons fait ce que nous savons faire de mieux, à savoir piloter un projet informatique !

Pour faire les choses dans l’ordre, nous avons tout d’abord posé des constats sur la situation existante et nous avons ensuite ré-évalué nos besoins actuels. Ces éléments constituent la base factuelle qui nous permet de prendre une décision éclairée et pertinente quant aux suites à donner sur ce sujet.

En l’absence de cette phase préalable, il est fréquent de voir des projets informatiques guidés par l’orientation vers une solution technique, parce qu’elle est à la mode ou que l’on a envie de découvrir quelque chose de nouveau. Cette (absence de) méthode est une quasi-garantie de faire le mauvais choix. Cela se traduit généralement par une inadéquation entre le besoin “fonctionnel” et la solution “technique”, ce qui engendre une insatisfaction des utilisateurs et un délaissement voire un abandon de la solution.

Je ne m’étends pas davantage ici, notre méthodologie projet est détaillée dans un billet spécifique, et entrons sans plus attendre dans le vif du sujet.

1. Les constats

1.1 L’absence de maintenance technique

Nous utilisions pour notre site précédent le système de gestion de contenu (ou CMS, pour Content Management System) Wordpress, qui est utilisé par plus d’un tiers des sites Internet dans le monde à l’heure où j’écris ces lignes (voir ici).

Wordpress est un très bon outil, ce qui explique sa popularité, relativement accessible et surtout, cela nous intéresse particulièrement chez Libre Logic, il est open source. Wordpress a connu une expansion très rapide de son utilisation et son périmètre fonctionnel a lui aussi grandement évolué, notamment à travers les (dizaines de) milliers d’extensions existantes.

Comme toutes les solutions sur étagère de ce type, il nécessite néanmoins d’être régulièrement mis à jour, pour profiter des dernières versions disponibles ou, plus important, pour se prémunir des dernières vulnérabilités mises au jour. Celles-ci sont particulièrement nombreuses sur Wordpress et ses plugins et c’est quelque part la rançon du succès : plus un logiciel est répandu, plus il y a de chances pour que des personnes mal intentionnées passent du temps à essayer d’y dénicher des failles pour en tirer avantage.

Dans le cas d’une entreprise à taille humaine comme la notre, qui ne dispose pas d’une DSI ou de ressources totalement dédiées à la maintenance et l’exploitation de nos outils, le temps à consacrer pour faire de la veille sur les différents composants de notre Système d’Information (SI) et de leurs mises à jour est contraint et nous devons viser une efficience maximale. Concernant notre site, il en a notamment résulté qu’il avait régulièrement une ou plusieurs “versions” de retard par rapport à la dernière disponible.

1.2 L’absence de contribution

Par ailleurs, nous avions dressé le constat que la contribution de contenus sur notre site était trop complexe et chronophage.

D’une part notre collaborateur qui a porté la mise en oeuvre et maintenu notre site pendant plusieurs années a quitté Libre Logic pour se lancer dans une aventure entrepreuneuriale (si tu me lis, salut à toi !). La transition interne que nous avions organisée en prévision de son départ ne s’étant pas déroulée comme prévue, nous nous sommes retrouvés quelque peu démunis en terme d’historique des décisions prises, des actions réalisées et d’administration fonctionnelle de notre Wordpress.

D’autre part et depuis plusieurs mois, le rythme de publication des billets de blog pourra en témoigner, la dynamique de contribution à notre site s’était éteinte, ce qui a fini par créer un écart entre ce que reflétait notre site et ce que nous sommes aujourd’hui.

2. Nos besoins

Avant de débuter des actions sur notre site Internet, en bons consultants en assistance à maîtrise d’ouvrage (AMOA), nous avons tout d’abord cherché à identifier nos besoins. J’ai résumé dans les paragraphes suivants ceux qui sont revenus le plus souvent dans nos échanges, et ils sont en réalité assez basiques et sans doute partagé par beaucoup de structures.

2.1 Une partie “statique”…

La plupart des pages de notre site ne sont pas amenées à évoluer régulièrement. La page d’accueil, l’équipe, nos références clients et nos lieux d’implantations n’évoluent pas tous les jours ou toutes les semaines. Il ne nous est donc pas nécessaire de disposer d’un haut niveau de paramétrage pour administrer ces pages.

2.2 …et un espace “blog”

En revanche, nous disposons d’un espace de blogging, dont l’objet est d’être le plus vivant et dynamique possible, en recevant les contributions de l’ensemble de nos collaborateurs. Pour cette partie-là, nous avons donc besoin d’un processus de contribution le plus simple et allégé possible à savoir :

Proposition de contribution par un collaborateur -> Validation du responsable éditorial -> Publication.

2.3 Une administration et une maintenance simplifiée

Enfin et surtout, nous souhaitons disposer d’une solution qui requiert le moins de maintenance possible, tout en offrant de fortes garanties en terme de sécurité, de robustesse et de performance.

3. Conclusion

Nous avons posé nos constats sur l’existant et nous avons ensuite évalué nos besoins. Ces phases constituent un préalable qui nous mettent en situation de prendre une décision et de choisir parmi les options qui s’offrent à nous et que l’on peut résumer en 2 grandes catégories :

1. Continuer à maintenir notre site sur Wordpress ;
2. Changer de solution technique et, le cas échéant, en choisir une nouvelle.

Nous avons évalué ces différents scénarios au regard de nos besoins. Pour aboutir à un arbitrage, nous avons ensuite mis en face de chacun de ces scénarios la charge associée à leur mise en oeuvre.

Au regard de l’ensemble de ces éléments, nous avons rapidement écarté le scénario 1, qui nécessitait une charge conséquente pour remettre à niveau notre Wordpress existant, que ce soit d’un point de vue “fonctionnel” (ex : retrouver pour quelle raison tel ou tel module a été utilisé plutôt que tel autre) ou “technique” (montées de version) et ne répondait pas à nos besoins, comme nous avons pu l’identifier précédemment.

Nous sommes donc partis à la recherche d’une nouvelle solution pour administrer les pages de notre site. L’étude comparative des solutions que nous avons réalisée a été assez rapide car nous sommes très vite tombé sur une solution qui nous satisfaisait pleinement, et je ne vais pas faire durer un faux suspens - puisque la réponse est dans le footer des pages de notre site - nous avons sélectionné la solution Jekyll.

Un des avantages de cette solution est que nous avons très rapidement pu l’éprouver à travers la réalisation d’un PoC (Proof of Concept : pour ne pas dire prototype) qui nous a permis de valider que nous étions sur le bon chemin en quelques heures de travail. Jekyll permet en effet de déployer rapidement une version de site en local sur son propre poste local, sans requérir des compétences techniques ou web (HTML / CSS) très poussées.

Nous reviendrons dans un prochain post de blog sur la phase de “réalisation”, à savoir la création puis la mise en ligne notre site avec cette technologie.

À bientôt !